FaceNiff is an Android app that sniffs Facebook session ids. You must be connected to the same WiFi as the victim. It is said to be working even when WPA2 is present. How is it possible? I can decrypt other connected users' communication in WPA2?
TL;DR: FaceNiff probably exploits WPA's "Hole 192" and uses ARP poisoning to set up a Man-in-the-Middle attack. The steps, in short, are:
- Eve uses the Group Temporal Key (GTK) to inject ARP packets into the network, with the network's gateway IP paired to her MAC address.
- Clients register Eve's MAC address as their new gateway.
- Clients send packets encrypted with their private keys (PTKs) to the AP, but addressed to Eve. (Packets must still go to the AP because it is the "hub".)
- AP decrypts the packets, re-encrypts them with Eve's PTK (since they're addressed to her), and re-broadcasts them. The packets are now effectively cleartext to Eve.
- Session hijacking ensues.
According to an article at The Register, it would seem that ARP poisoning is indeed involved.
The app works even on networks protected by WPA and WPA2 encryption schemes by using a technique known as ARP spoofing to redirect local traffic through the attacker's device. An attacker would have to know the security password, however.
So, for WPA2 networks, FaceNiff is most likely exploiting "Hole 196". AirTight has an article that does a great job of explaining exactly what Hole 196 is, and (pasted below) how it can be exploited so that Eve can sniff WPA2 traffic as if it were in the clear.
In a WPA2 network, a malicious insider broadcasts fake packets (with the AP's MAC address as the transmitter's address) encrypted using the shared group key (GTK) directly to other authorized Wi-Fi clients in the network. One example of an exploit that can be launched using GTK is the classic ARP poisoning (man-in-the-middle) attack (demonstrated at Black Hat Arsenal 2010 and Defcon18).
In the ARP poisoning exploit, the insider can include for instance an ARP Request message inside the GTK-encrypted packet. The ARP Request has the IP address of the actual gateway, but the MAC address of the attacker's machine. All clients that receive this message will update their ARP table - mapping the attacker's MAC address with the gateway's IP address.
All "poisoned" Wi-Fi clients will send all their traffic, encrypted with their respective private keys (PTKs), to the AP, but with the attacker's MAC address as the destination. The AP will decrypt the traffic and forward it to the attacker, now encrypting it using the attacker's PTK. Because all traffic reaching the attacker (from the AP) is encrypted with the attacker's PTK, the attacker can decrypt the traffic (including login credentials, emails and other sensitive data).
The attacker can then choose to forward the traffic to the actual gateway of the network, so that the victim Wi-Fi clients do not see any abnormal behavior and continue their communication.
See Is WPA2 WiFi protected against ARP poisoning and sniffing?. From your note about it using arp spoofing, you can figure that the Hole 196 factor is involved.
It seems that it uses ARP spoofing internally (I noticed some mentions of ARP in FaceSniff's changelog).