Try putting a fresh 10.4.8 install on an Intel Mac and running the new Broadcom exploit against it. Now try it with the patch Apple released a month after the Black Hat presentation. Is this the same bug? Did they reverse engineer Apple's patches to find this? Why are they NOT claiming that this is the infamous bug? Why would they bother faking an exploit in the first place? Why isn't Apple listed as a vulnerable vendor in the MoKB advisory? My opinion is that the rabid response the Gruber's fans have turned them off from ever "addressing" the Mac community with any "proof" they have to offer.
Regarding the old Airport bug I found -- its the hardware I happened to have. If you want to send me a shiny new Intel Mac, I would be more than happy to start dumping wireless driver bugs for that platform as well. Hardware hacking is expensive dammit:-)
Current drivers for the first-generation cards (the non-extreme) ones. This limited the bug to Mac hardware shipped between 1999 and 2003. We have some reproducable crashes in the latest Atheros-based cards as well (all new Intel Macs), but need to finish the research before we talk about it.
This particular one was only in the first-generation Airport drivers. It may affect Windows users of the Proxim/Orinoco/Lucent chips as well, but we didn't have any hardware to test on.
The bug I found is not due to the card "complying with a standard", its because the first-generation Airport driver (the latest one available at that), has a bug that allows someone to run code in your kernel from a distance. Maybe I missed the "ieee80211b-pwned" spec, but this doesn't seem like good behavior.
Why is that Apple supporters are in such denial about their favorite products having security flaws? This bug was one of many in the Airport drivers and one an even bigger set of wireless exploits that we plan on releasing. A Broadcom bug was released today which likely affects more systems than Apple has ever shipped.
Compile the Metasploit Lorcon wrapper: $ cd trunk/external/msflorcon $ make
Plug in a support network card (I use a WPN511 with the madwifi-old driver in Gentoo)
Load the Metasploit Console (as root, since it needs raw WiFi access) # trunk/msfconsole
Play with some of the demo modules:-)
This is an example of sending fake beacon requests to flood the Windows Wireless Network Browser: msf > use auxiliary/dos/wireless/fakeap msf auxiliary(fakeap) > show options
Module options:
CHANNEL 11 yes The default channel number
DRIVER madwifi yes The name of the wireless driver for lorcon
INTERFACE ath0 yes The name of the wireless interface
Type the "run" command, or use "set VARIABLE VALUE" to change these options.
The reason I don't consider it "0day" is that a public tool exists that will discover this bug in its default configuration (AxMan). Anyone who took the time could run the tool, discover the bug, and write the exploit. The tool was released on August 1st and this particular bug was reported to Microsoft in late July. Since all of this information was *widely* publicized at the time of release ( a couple dozen articles on AxMan ), I have hard time considering any of the bugs it turns up "0day" in the normal sense. We need a new term, but "negative day" probably isn't it either. The remaining 3-4 easily exploitable bugs (of the ~100 or so that were never included in the Month of Browser Bugs) will likely stay unpublished until a patch is available.
Its funny to see how releasing an exploit accelerates patch development. I have been waiting on the Spline and KeyFrame patches for over a month already, but it wasn't until the xsec guy rediscovered these that Microsoft decided to release a patch. Maybe there is something to this "full-disclosure" thing after all =)
No, you misread. The timing attack is easiest to do if the *attacker* has two WiFi cards and the victim is running some service or another (to help with the timing). All Mac's expose port 5353 to the world, regardless of firewall setting (mDNS/Bonjour), so the listener requirement is met by default. All Windows systems listen on port 137 by default (even through XP SP2 firewall default policy). Read a little closer next time.
Look at the stock price for ISSX, compare that to the purchase price of about $28/share. There is a total "premium" of 7% above the market value of the ISS stock. The only entity making money on this deal is the brokerage firm that handled the transaction.
Re:Not sure how it works...
on
Computer Voodoo?
·
· Score: 5, Informative
This trick even works non-destructively:
dd if=/dev/hda of=/dev/hda bs=512
A friend of mine showed me this method a few years ago and it has helped recover failing drives over a dozen times since.
I agree with Dave on this. Using Metasploit in its current form isn't much fun on the Zaurus. I have been working on something similar off and on for the last two years (using two Z 5500's) and the biggest problem is the user interface and automation. While it is possible to script up some ninja magic with Metasploit, the time required to do it right may be worth the price of the Immunity's SILICA device.
As version 3.0 of the Framework gets closer to release, expect the situation to change. The new plugins and auxiliary modules will allow this type of automated hackery and tool integration. If anyone wants to help, we are always looking for sharp developers. The 3.0 codebase is written almost entirely in Ruby and we even have some developer documentation. Anyone interested should send an email to hdm[at]metasploit.com with a list of their skills and any specific areas they want to work on. The 3.0 beta 1 release can be obtained from the following URL:
Slashdot Mirror
Try putting a fresh 10.4.8 install on an Intel Mac and running the new Broadcom exploit against it. Now try it with the patch Apple released a month after the Black Hat presentation. Is this the same bug? Did they reverse engineer Apple's patches to find this? Why are they NOT claiming that this is the infamous bug? Why would they bother faking an exploit in the first place? Why isn't Apple listed as a vulnerable vendor in the MoKB advisory? My opinion is that the rabid response the Gruber's fans have turned them off from ever "addressing" the Mac community with any "proof" they have to offer. Regarding the old Airport bug I found -- its the hardware I happened to have. If you want to send me a shiny new Intel Mac, I would be more than happy to start dumping wireless driver bugs for that platform as well. Hardware hacking is expensive dammit :-)
I wonder what happens if you use the new Broadcom exploit on a new Intel Mac that does not have Apple's September security update... :-)
Current drivers for the first-generation cards (the non-extreme) ones. This limited the bug to Mac hardware shipped between 1999 and 2003. We have some reproducable crashes in the latest Atheros-based cards as well (all new Intel Macs), but need to finish the research before we talk about it.
This particular one was only in the first-generation Airport drivers. It may affect Windows users of the Proxim/Orinoco/Lucent chips as well, but we didn't have any hardware to test on.
The bug I found is not due to the card "complying with a standard", its because the first-generation Airport driver (the latest one available at that), has a bug that allows someone to run code in your kernel from a distance. Maybe I missed the "ieee80211b-pwned" spec, but this doesn't seem like good behavior.
Why is that Apple supporters are in such denial about their favorite products having security flaws? This bug was one of many in the Airport drivers and one an even bigger set of wireless exploits that we plan on releasing. A Broadcom bug was released today which likely affects more systems than Apple has ever shipped.
Doh, wrong button :-)
A remote exploit for a widely-deployed wireless driver from Broadcom was published today. This is the first remote public exploit that abuses a driver flaw to execute arbitrary shellcode :-)
A w idely-deployed wireless driver</a> from Broadcom was <a href="http://projects.info-pull.com/mokb/MOKB-11-1 1-2006.html">published today</a>. This is the first remote published, public exploit that abuses a driver flaw to execute arbitrary shellcode :-)
Install the latest Lorcon snapshot:
:-)
$ http://www.802.11mercenary.net/lorcon/
Grab the latest version of metasploit 3:
$ svn co http://metasploit.com/svn/framework3/trunk/
Compile the Metasploit Lorcon wrapper:
$ cd trunk/external/msflorcon
$ make
Plug in a support network card (I use a WPN511 with the madwifi-old driver in Gentoo)
Load the Metasploit Console (as root, since it needs raw WiFi access)
# trunk/msfconsole
Play with some of the demo modules
This is an example of sending fake beacon requests to flood the Windows Wireless Network Browser:
msf > use auxiliary/dos/wireless/fakeap
msf auxiliary(fakeap) > show options
Module options:
CHANNEL 11 yes The default channel number
DRIVER madwifi yes The name of the wireless driver for lorcon
INTERFACE ath0 yes The name of the wireless interface
Type the "run" command, or use "set VARIABLE VALUE" to change these options.
msf auxiliary(fakeap) >run
The reason I don't consider it "0day" is that a public tool exists that will discover this bug in its default configuration (AxMan). Anyone who took the time could run the tool, discover the bug, and write the exploit. The tool was released on August 1st and this particular bug was reported to Microsoft in late July. Since all of this information was *widely* publicized at the time of release ( a couple dozen articles on AxMan ), I have hard time considering any of the bugs it turns up "0day" in the normal sense. We need a new term, but "negative day" probably isn't it either. The remaining 3-4 easily exploitable bugs (of the ~100 or so that were never included in the Month of Browser Bugs) will likely stay unpublished until a patch is available.
Its funny to see how releasing an exploit accelerates patch development. I have been waiting on the Spline and KeyFrame patches for over a month already, but it wasn't until the xsec guy rediscovered these that Microsoft decided to release a patch. Maybe there is something to this "full-disclosure" thing after all =)
-HD
No, you misread. The timing attack is easiest to do if the *attacker* has two WiFi cards and the victim is running some service or another (to help with the timing). All Mac's expose port 5353 to the world, regardless of firewall setting (mDNS/Bonjour), so the listener requirement is met by default. All Windows systems listen on port 137 by default (even through XP SP2 firewall default policy). Read a little closer next time.
Look at the stock price for ISSX, compare that to the purchase price of about $28/share. There is a total "premium" of 7% above the market value of the ISS stock. The only entity making money on this deal is the brokerage firm that handled the transaction.
This trick even works non-destructively: dd if=/dev/hda of=/dev/hda bs=512 A friend of mine showed me this method a few years ago and it has helped recover failing drives over a dozen times since.
I agree with Dave on this. Using Metasploit in its current form isn't much fun on the Zaurus. I have been working on something similar off and on for the last two years (using two Z 5500's) and the biggest problem is the user interface and automation. While it is possible to script up some ninja magic with Metasploit, the time required to do it right may be worth the price of the Immunity's SILICA device.
As version 3.0 of the Framework gets closer to release, expect the situation to change. The new plugins and auxiliary modules will allow this type of automated hackery and tool integration. If anyone wants to help, we are always looking for sharp developers. The 3.0 codebase is written almost entirely in Ruby and we even have some developer documentation. Anyone interested should send an email to hdm[at]metasploit.com with a list of their skills and any specific areas they want to work on. The 3.0 beta 1 release can be obtained from the following URL:
http://metasploit.com/projects/Framework/msf3/
-HD