[Dailydave] Wireless Disclosures

Fri Mar 23 12:24:28 EDT 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To be honest I'm not sure where everyone got the idea that iPhone or
Apple products don't probe for known SSIDs.  All the
comments/emails/tweets that I have received about this particular
topic and the ARP disclosure seem to have a few things in common which
I hope to clear up today.

Misconception #1:  Apple products don't probe for known SSIDs.

The truth is Apple products _do_ probe for known SSIDs (and no, there
is no limit as to how many).

Here is a screenshot of an iPhone probing for known SSIDs[1]

Misconception #2:  Apple products are immune to KARMA-like attacks.

The truth is Apple products _are_ vulnerable to fake AP attacks.  I
refer you back to misconception #1 for a moment.  An attacker gets to
pick which network they want to become (that you are probing for) to
have your device automatically connect to it.  Once your device joins
their network the attack surface against your device and your personal
data increase exponentially.

In fact you can watch SILICA do this very attack[2] against an iPhone.

To be fair I will mention that devices will [obviously] take
encryption/authentication into account.  So unless you know the keys
for some of the target's probed-for networks you will only be
successful when impersonating open networks.  But once you get them to
connect to your open network then you can break into their
phone/laptop and pull off their wireless keys in plaintext for all
stored networks.

Misconception #3: Apple keeps an internal list of MAC addresses of APs
which I've connected to therefore I'm safe from all this stuff you are
talking about.

The truth is this would make the usage of WiFi unbearable for the
impatient.  This would be a trade for security over convenience.
Consider the following scenario:

You work for CompanyX that has a large corporate building with WiFi
access points with the name "Corp-Wireless".  Let's say there are 3 APs:

AA:BB:CC:DD:EE:FF Corp-Wireless
AA:BB:CC:11:22:33   Corp-Wireless
AA:BB:CC:A1:B2:C3  Corp-Wireless

The real world connects to Corp-Wireless once and never has to worry
about when leaving the coverage area of AA:BB:CC:DD:EE:FF to
automatically connect to AA:BB:CC:A1:B2:C3.  If misconception #3 were
true you would personally have to connect to each AP on your own _and_
you would also see in your list of detected wireless networks 3 MAC
addresses with the name Corp-Wireless to choose from.  Your mom
doesn't know or care what hexadecimal is as she prefers the human
readable string "homeAP" and "tmobile" :)

This very convenience is also another reason why misconception #1 and
#2 aren't true.

Misconception #4:  The ARP disclosure you revealed at INFILTRATE
doesn't effect me or my enterprise.

Penetration testers, stalkers, identity thieves, possibly law
enforcement (and Google?) disagree with you.  No matter what network
you connect to (encrypted/unencrypted alike) you may be disclosing the
last 3 APs that you have connected to in ARP traffic.  This is a
privacy issue.  You may not care if everyone knows which local Holiday
Inn you go to over the weekends but your CEO sure does.

This becomes even more interesting when tracking a target over a
period of time.  Eventually you will reveal all access points that you
have connected to.  This looks very interesting plotted on a map.

Also, don't miss a very interesting point.  If you connect to a
wireless network that is protected with WEP or WPA/TKIP and you
disclose your IP address in the ARP traffic on another network that an
attacker can sniff then you are giving the attacker some
[known-]plaintext that can be used to revive _and_ speed up older
attacks.  For example, if I know your IP address on your disclosed WEP
network then I can derive your WEP key even though we are nowhere near
your WEP network (by attacking your laptop/phone directly).

At INFILTRATE I also disclosed a creative/intrusive way to keep a
phone from falling asleep long enough to brute force the IP to revive
this attack.  But of course this takes time but with the ARP
disclosure no creativity is needed to crack the WEP key.

Here is a screenshot of the ARP disclosure[3]

Misconception #5:  <something about SSID probing> and <something about
ARP disclosures>.

SSID probing and the ARP disclosure are not directly related.  These
are two separate issues.

The best solution, in my opinion, to battle these misconceptions is
give you all a chance to see this all for yourself.  As a SILICA
developer/wireless penetration tester this stuff is in my face all the
time.  I wrote STALKER to help demonstrate the impact that information
disclosures can have (even, small seemingly insignificant
disclosures).  So to help you see this with your own eyes I'll show
you how I do it in Linux using compat-wireless drivers on an Atheros
chipset in monitor mode (this is one of many methods, of course):

1) iw dev
2) make note of the phy device name in step 1
3) sudo su (we need root for the next stuff)
4) iw phy <device from step 1> add monwifi type monitor
5) ifconfig monwifi up
6) iwconfig monwifi channel <channel you want to listen on>
7) open up wireshark[4] on the monwifi interface
    a) optionally use the filter wlan.fc.type_subtype == 0x04 to only
see probe requests
8) watch your beloved Apple product contradict what you've heard about
SSID probing
9) if you didn't see any Probe Requests from your iPhone then keep
watching ...
10) send a retraction to @MarkWuergler :)

Depending on your driver these commands won't work.  So ask Google how
to put your wireless card in monitor mode and then jump to step 7 and
substitute your interface name.

While you are in the this mode you can also watch the ARP disclosure
happen.  Connect your iPhone to a network that doesn't have DHCP
enabled (this is a simple trigger but make sure you are on the right
channel before you connect).

Happy discovering,

Mark Wuergler
Immunity, Inc.

[1]
https://lists.immunityinc.com/pipermail/dailydave/attachments/20120322/f23b2715/attachment-0001.png
[2] http://partners.immunityinc.com/movies/Access_point_impersonation.mp4
[3] http://t.co/YkGi1cjY
[4] http://www.wireshark.org/download.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9so7IACgkQorg+tja2+6CkOwCfSsXrjpYz7J22nqhYMR4/NUt0
0WEAn3xjjbtPZjy/jYfhTXkUs1fXOmmw
=CcTC
-----END PGP SIGNATURE-----