RE: Android wireless accepts fake response (No interaction requires) (Vulnerability ?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Isn't this just roaming?  If the two APs have the same SSID and
authentication, then they're one ESSID and the BSSIDs are irrelevant. 
And if iOS and Win don't move between APs, how can they exist in
multi-ap environments?

____
From: Security Mailing List [s3clist@xxxxxxxxxxx]
Sent: Monday, March 12, 2012 2:25 AM
To: bugtraq@xxxxxxxxxxxxxxxxx
Subject: Android wireless accepts fake response (No interaction
requires) (Vulnerability ?)

## Android wireless accepts fake response (No interaction requires)
(Vulnerability ?) ##

:: Description ::

I have found Android device's behavior which I deem it is inappropriate.
I am not sure if it can be classified as a vulnerability. The problem
appears when an Android device have connected to hidden SSID wireless
networks. The default behavior of most OSes is to shout out to see if
there is an expected hidden SSID over there. A legitimate access point
would reply with a probe response. However, a rouge access point could
also reply with a fake probe response and continue further negotiation
until it captures WPA handshake. Android devices will automatically and
gratefully accept the fake response while other OSes, including Windows,
iOS, prevent this attack by checking BSSID (MAC address) in the probe
response packet if it match of legitimate access point. The response
will be discarded if the BSSID does not match.

This means that if your company uses hidden SSID wireless network. I
could steal you WPA key when your employees join any conferences. All of
attack processes require no user interactions, no social engineering.

:: Affected Versions ::
Android 2.3
Android 3.0
Other versions may be affected but I have not tested

:: Reproduce The Attack ::
1. Prepare two access points with the same SSID and same WPA key
2. Enable hidden SSID on both APs
3. Turn off on AP
4. Connect an Android device with the running AP
5. Turn off the first AP
6. Turn on the other AP
7. See your Android device automatically connect to the second AP
Note: If you repeat the same process with iPhone or Windows PC, you will
see that both devices will refuse to connect to the second AP because
BSSID of the second AP does not match with the first one.

:: Report Timeline ::
[+] 31 Jan 2012 :: Reserve CVE-ID from primary CNA (was assigned
CVE-2012-0940)
[+] 2 Feb 2012 :: Submit in-depth details about this vulnerability to
android security team.
.... (No response) ....
[+] 12 March 2012 :: Submit to Full Disclosure

Wiswat Aswamenakul


[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux