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

[Security Mailing List <s3clist () hotmail com>]

You are not wrong. However, in this case, the point is to capture "WPA
handshake"(not WPA key) in order to brute-force for WPA key. This attack
allows an attacker to capture your "WPA handshake" even though the
legitimate access point is not there. The attacker could create a fake
access point to steal "WPA handshake"(from a client) when you attend
conferences. This attack would not work with iPhone, iPad or other PCs
with Windows OS because they would discard fake probe response at the
first place.

Nevertheless, I do not confirm this behavior as a vulnerability. I
personally do not see much opportunity to exploit this behavior. The
only opportunity I can think about is the situation where attacking
clients is much easier than making my way to the area that the
legitimate access point covers. Moreover, an attacker needs to
brute-force "WPA handshake" to get the WPA key.
 
:: An example of the attacking situation::
If an office of my client is on the high floor of a building and
physical security is so strict, I cannot find my way to the area a
legitimate access point covers. I can change my attack vector to wait
for my client's employees to buy some coffee at the ground floor and,
therefore, I can steal "WPA handshake" for the employees. Then, I need
to spend some times cracking for WPA key. If I successfully crack the
key, I, now, can connect with Android devices of my client's employees
and they might think that they are connecting with their very powerful
access points of their workplace. At this point, I could launch
karmetasploit-style attacks in order to get malware into the device.
Every process here does not require me to get network my client's networks.




On 3/13/2012 2:54 AM, Zach C. wrote:
> > I could steal your WPA key when your employees join any conferences
> I don't think WPA works this way... otherwise merely looking at someone's
> init packet would allow anyone to "steal the WPA key" in this way. I would
> think you'd have to know the shared secret to begin with. Or brute-force it.
>
> This *could*, however, allow an easy enough MitM for unprotected traffic,
> but you could sniff that out of the air anyway. I don't really see it being
> useful otherwise...
>
> Am I wrong somewhere?
> On Mar 12, 2012 8:14 AM, "Security Mailing List" <s3clist () hotmail com>
> wrote:
>
> > ## 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