The thing to keep in mind here is that this really isn't a problem yet. You
won't see any WLAN viruses' base on driver level exploits any time soon for
one very important reason, proximity. We wanted these issued raised and
fixed before the distance of a wifi connection for your average user will be
measured in kilometers instead of the meters it is today.

Don't go rip your wifi cards out just yet, but you should always adhere to
good security techniques. Even without a driver level exploits
man-in-the-middle attacks over wifi networks are a threat that you can
mitigate by doing things like verifying the SSL certs for things you can
connect to and don't do anything you want to remain personal or private over
clear text on these access points. Also, for things like instant messaging,
grab something like Adium X that supports encrypted IM conversations across
multiple platforms. I know iChat does as well, but I am a big fan of
something called OTR (http://www.cypherpunks.ca/otr/) which Adium supports.

On 8/14/06, Massimo Marino <fwa266m (at) mac (dot) com [email concealed]> wrote:
>
> David,
>
> thanks for your reply. Always good to hear from the source than from
> articles written here and there. Although sometimes they are the only
> source, alas.
>
>
> From your saying, is currently the best protection not to use at all
> autojoin feature? After all, if we were to select manually and a malicious
> host was trying to impersonate one we expect at a certain location wouldn't
> it be suspicious to see *two* incarnations of the expected APs.
>
>
> You also said in a previous email "Normally with these types of exploits
> the wireless driver you exploit will either die or cease working correctly".
> In the state of the arts, is this, for the moment, the most probable result
> from naively connecting to a malicious host?
>
>
> I travel a lot and all of this does concerns me greatly, as you might
> imagine.
>
>
> Thanks again for your contribution.
>
>
> Cheers
>
>
> M
>
> On 14 Aug 2006, at 15:36, David Maynor wrote:
>
> To address your statement that we refused to show the demo in a
> controlled environment is incorrect as the demo was actually shown live to 3
> people at Blackhat. There were people speculating we wouldn't show it in a
> controlled environment, but they were wrong as we did. There were also the
> people that offered us money for live demos as long as the could sniff the
> connection and get a copy of the exploit code. They didn't want a demo, they
> wanted the exploit code.
>
>
> There are several GLARING errors in that post on smallworks.com.
>
>
> Our comment that the machine does not need to be associated to an access
> seems to be a sticking point for these "experts." They kind of get something
> right with the management frames and such but then use that as a reason
> there is something wrong. Any wireless expert should know how Probe
> Requests/Probe Responses work. This is how wireless cards find APs they will
> join automatically. Although you don't have to be connected/associated to an
> access point, I can impersonate on of the APs you would autojoin, then
> attack you. I did not come up with the way to do this BTW, you can read more
> about it here: http://www.theta44.org/software/karma.README Or you can
> just go google "K2 Karma Wifi" and find it all yourself. This technique was
> also rediscovered by Simple Nomad of the NMRC:
> http://www.nmrc.org/pub/advise/20060114.txt
> Before somebody jumps to the conclusion this only affects Windows, it
> affects Mac as well.
>
>
> So just doing a Google search debunked half of his post. And now my
> favorite part:
> "More likely: it doesn't. In the presentation, Maynor uses a "third-party
> wireless card". It looks like a ExpressCard/34 802.11 card, but the
> non-'Pro' Macbook doesn't have Express Card slots, and the card they hold is
> too big to be a USB device, yet the Macbook they use is definitely *black*
> ."
>
>
> It was a USB device wrapped in paper but he goes off on a tangent about
> how it had to be an ExpressCard and other such nonsense while assuming the
> attack is specific to a default Mac. He does not leave this idea alone
> either, he keeps coming back to the ExpressCard idea, as to be honest most
> of his argument is based on this and would crumple like a house of cards if
> he was found to be incorrect. We stated at Blackhat and Defcon it was a USB
> device. To be fair he did later post an update that debunked most of his own
> posting, although I am still accused of pretending it's a ExpressCard
> despite the many public claims its a USB device.
> http://www.smallworks.com/archives/00000456.htm
>
>
> And last but not least he says we wrote our own driver. In hindsight for
> our purpose of showing the attack is possible and not singling out any
> vendor, that would have been a great idea. However drivers are so full of
> bugs writing our own driver is not required.
>
>
> He then goes on to incorrectly interpret the Intel Driver problems and
> patches. He focuses on the privilege escalation and does not address that
> clearly in the Intel advisory it states remote code execution is possible.
>
>
> Beware of technical posts that use the terms like presume and post many
> excerpts from technical articles to support his claims. He chooses things to
> support his argument and dismissed things that didn't. It's amazing he spent
> a lot of time theorizing about this but never once contacted Jon or I. He
> also seems to have forgotten to mention that a few months ago there was a
> remote overflow in the net80211 layer of FreeBSD:
> ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:05.80211
.asc
>
>
>
> But then again that's not worth mentioning because it doesn't support his
> argument.
>
>
> On 8/14/06, fwa266m (at) mac (dot) com [email concealed] <fwa266m (at) mac (dot) com [email concealed]> wrote:
> >
> > http://www.smallworks.com/archives/00000455.htm
> >
> > Any comment on the above article. I am not expert on IEEE 802.11
> > standard requirements but it seems - at first look - a first possible
> > debunk.
> >
> > I am very sorry I can't find the link where I read it, but apparently
> > Ellch and Maynor refused to show the hack with a third party MacBook
> > in controlled environment - whatever that means - raising the
> > suspicion they need to have physical access to the machine before hand.
> >
> > Cheers
> >
> > M
> >
>
>
>
>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><span style="FONT-FAMILY: Arial">The thing to keep in mind here is that this really isn't a problem yet. You won't see any WLAN viruses' base on driver level exploits any time soon for one very important reason, proximity. We wanted these issued raised and fixed before the distance of a wifi connection for your average user will be measured in kilometers instead of the meters it is today.
</span></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><span style="FONT-FAMILY: Arial"> </span></p>
<p class="MsoNormal" style="MARGIN: 0in 0in 0pt"><span style="FONT-FAMILY: Arial">Don't go rip your wifi cards out just yet, but you should always adhere to good security techniques. Even without a driver level exploits man-in-the-middle attacks over wifi networks are a threat that you can mitigate by doing things like verifying the SSL certs for things you can connect to and don't do anything you want to remain personal or private over clear text on these access points. Also, for things like instant messaging, grab something like Adium X that supports encrypted IM conversations across multiple platforms. I know iChat does as well, but I am a big fan of something called OTR (
<a href="http://www.cypherpunks.ca/otr/">http://www.cypherpunks.ca/otr/</a>
) which Adium supports. </span></p><br><br>
<div><span class="gmail_quote">On 8/14/06, <b class="gmail_sendername">Massimo Marino</b> <<a href="mailto:fwa266m (at) mac (dot) com [email concealed]">fwa266m (at) mac (dot) com [email concealed]</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>
<div style="WORD-WRAP: break-word">David,
<div><br> </div>
<div>thanks for your reply. Always good to hear from the source than from articles written here and there. Although sometimes they are the only source, alas.</div>
<div><br> </div>
<div>From your saying, is currently the best protection not to use at all autojoin feature? After all, if we were to select manually and a malicious host was trying to impersonate one we expect at a certain location wouldn't it be suspicious to see *two* incarnations of the expected APs.
</div>
<div><br> </div>
<div>You also said in a previous email "Normally with these types of exploits the wireless driver you exploit will either die or cease working correctly". In the state of the arts, is this, for the moment, the most probable result from naively connecting to a malicious host?
</div>
<div><br> </div>
<div>I travel a lot and all of this does concerns me greatly, as you might imagine.</div>
<div><br> </div>
<div>Thanks again for your contribution.</div>
<div><br> </div>
<div>Cheers</div></div>
<div><span class="sg">
<div><br> </div>
<div><span style="WHITE-SPACE: pre"></span>M</div></span></div>
<div><span class="e" id="q_10d0cfbe8886c744_2">
<div><br>
<div>
<div>On 14 Aug 2006, at 15:36, David Maynor wrote:</div><br>
<blockquote type="cite">
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">To address your statement that we refused to show the demo in a controlled environment is incorrect as the demo was actually shown live to 3 people at Blackhat. There were people speculating we wouldn't show it in a controlled environment, but they were wrong as we did. There were also the people that offered us money for live demos as long as the could sniff the connection and get a copy of the exploit code. They didn't want a demo, they wanted the exploit code.
</font></div>
<p style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"> </font></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">There are several GLARING errors in that post on <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://smallworks.com/" target="_blank">smallworks.com
</a>.</font></div>
<p style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"> </font></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">Our comment that the machine does not need to be associated to an access seems to be a sticking point for these "experts." They kind of get something right with the management frames and such but then use that as a reason there is something wrong. Any wireless expert should know how Probe Requests/Probe Responses work. This is how wireless cards find APs they will join automatically. Although you don't have to be connected/associated to an access point, I can impersonate on of the APs you would autojoin, then attack you. I did not come up with the way to do this BTW, you can read more about it here:
</font><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.theta44.org/software/karma.README" target="_blank"><font face="Times New Roman" color="#800080">http://www.theta44.org/software/karma.README
</font></a><font face="Times New Roman"> Or you can just go google "K2 Karma Wifi" and find it all yourself. This technique was also rediscovered by Simple Nomad of the NMRC: </font><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.nmrc.org/pub/advise/20060114.txt" target="_blank">
<font face="Times New Roman" color="#800080">http://www.nmrc.org/pub/advise/20060114.txt</font></a></
div>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">Before somebody jumps to the conclusion this only affects Windows, it affects Mac as well. </font></div>
<p style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"> </font></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">So just doing a Google search debunked half of his post. And now my favorite part: </font></div>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">"</font><span><span style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Verdana">More likely: it doesn't. In the presentation, Maynor uses a "third-party wireless card". It looks like a ExpressCard/34
802.11 card, but the non-'Pro' Macbook doesn't have Express Card slots, and the card they hold is too big to be a USB device, yet the Macbook they use is definitely <b>black</b>."</span></span></div>
<p style="MARGIN: 0in 0in 0pt"><span><span style="FONT-SIZE: 8.5pt; COLOR: black; FONT-FAMILY: Verdana"> </span></span></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">It was a USB device wrapped in paper but he goes off on a tangent about how it had to be an ExpressCard and other such nonsense while assuming the attack is specific to a default Mac. He does not leave this idea alone either, he keeps coming back to the ExpressCard idea, as to be honest most of his argument is based on this and would crumple like a house of cards if he was found to be incorrect. We stated at Blackhat and Defcon it was a USB device. To be fair he did later post an update that debunked most of his own posting, although I am still accused of pretending it's a ExpressCard despite the many public claims its a USB device.
</font></div>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.smallworks.com/archives/00000456.htm" target="_blank">http://www.smallworks.com/archives/00000456.htm
</a></font></div>
<p style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"> </font></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">And last but not least he says we wrote our own driver. In hindsight for our purpose of showing the attack is possible and not singling out any vendor, that would have been a great idea. However drivers are so full of bugs writing our own driver is not required.
</font></div>
<p style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"> </font></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">He then goes on to incorrectly interpret the Intel Driver problems and patches. He focuses on the privilege escalation and does not address that clearly in the Intel advisory it states remote code execution is possible.
</font></div>
<p style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"> </font></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">Beware of technical posts that use the terms like presume and post many excerpts from technical articles to support his claims. He chooses things to support his argument and dismissed things that didn't. It's amazing he spent a lot of time theorizing about this but never once contacted Jon or I. He also seems to have forgotten to mention that a few months ago there was a remote overflow in the net80211 layer of FreeBSD:
</font></div>
<div style="MARGIN: 0in 0in 0pt"><a onclick="return top.js.OpenExtLink(window,event,this)" href="ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:05
.80211.asc" target="_blank"><font face="Times New Roman" color="#800080">
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:05.80211
.asc </font></a></div>
<p style="MARGIN: 0in 0in 0pt"><font face="Times New Roman"> </font></p>
<div style="MARGIN: 0in 0in 0pt"><font face="Times New Roman">But then again that's not worth mentioning because it doesn't support his argument. </font></div><br><br>
<div><span class="gmail_quote">On 8/14/06, <b class="gmail_sendername"><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:fwa266m (at) mac (dot) com [email concealed]" target="_blank">fwa266m (at) mac (dot) com [email concealed]</a></b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:fwa266m (at) mac (dot) com [email concealed]" target="_blank">
fwa266m (at) mac (dot) com [email concealed]</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.smallworks.com/archives/00000455.htm" target="_blank">
http://www.smallworks.com/archives/00000455.htm</a> <br><br>Any comment on the above article. I am not expert on IEEE 802.11<br>standard requirements but it seems - at first look - a first possible<br>debunk.<br><br>I am very sorry I can't find the link where I read it, but apparently
<br>Ellch and Maynor refused to show the hack with a third party MacBook<br>in controlled environment - whatever that means - raising the<br>suspicion they need to have physical access to the machine before hand.<br><br>Cheers
<br><br>M<br></blockquote></div><br></blockquote></div><br> </div><
/span></div>
<div></div></div></blockquote></div><br>

[ reply ]