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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <BLU0-SMTP18080CFFF18AE2F07DA92F1EE5B0@phx.gbl>
Date: Mon, 12 Mar 2012 13:25:01 +0700
From: Security Mailing List <s3clist@...mail.com>
To: bugtraq@...urityfocus.com
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