I’m speaking at Hackers 2 Hackers Conference 9th edition – 2012 @ São Paulo, Brazil!

Hi folks! I’m glad to inform that my paper “Advanced DDoS techniques: Layer 7, load-balancing and mobile tools” was accepted by the 9th Hackers 2 Hackers Conference (H2HC).

The event will take place on October 20-21 and it seems to be another success just like previous editions.

Don’t forget to check the event’s website for full line-up. If you can, enroll and enjoy!

WPA faces new threat ‘Hole 196’ and new key bruteforcing service

WPA was hit hard these days by a rumor of a new threat called ‘Hole 196’.

The hole would allow GTK (Group Temporal Key) spoofing forcing users to send the rogue AP their private key information leading to a awesome no-footprinted (medium is over air!) man-in-the-middle attacks.

To understand transient keys over WPA, Md Sohail Ahmad from AirTight said:

WPA2 uses two types of keys: 1) Pairwise Transient Key (PTK), which is unique to each client, for protecting unicast traffic; and 2) Group Temporal Key (GTK) to protect broadcast data sent to multiple clients in a network. PTKs can detect address spoofing and data forgery. “GTKs do not have this property,” according to page 196 of the IEEE 802.11 standard. (…) Because a client has the GTK protocol for receiving broadcast traffic, the user of that client device could exploit GTK to create its own broadcast packet. From there, clients will respond to the sending MAC address with their own private key information.

The solution would be some kind of GTK signing so it could be validated though the endpoint (holding the PTK) protecting itself from this spoof attack.

The discussion now is around if it is really a flaw/threat or is just another shenanigan from AirTight to gain attention from venture fundings, but it seems (this time) to be a legitimate issue.

I’ve read on Bruce that a new service called “WPA Cracker“. The service consists into brute-forcing your WPA keys with (a rich and huge database of) dictionary attacks, in many languages on their cracking-cluster of several machines.

Back in 2008, Chad Perrin has discussed that cloud computing could be used to distributed cracking / bruteforcing. Some projects have managed that like Free Rainbow Tables (DistRTGen @ Boinc).

The Church of WiFi maintains a huge database of WPA Rainbow Tables but the caveat is that keys are salted with the network’s SSID.

Yes, the Church Of Wifi has put a large rainbow table collection online. However, there are a few ways in which this collection has not met our needs. The first is that since each handshake is salted with the ESSID of the network, you have to build a unique set of rainbow tables for each network that you’d potentially like to audit. The Church Of Wifi has gone to heroic efforts to build tables for the 1000 most popular ESSIDs, but we find that this is often not enough. If someone has enabled WPA encryption on their wireless network, chances are that they’ve changed their ESSID to something that’s not very common as well.

Additionally, since they had to build so many sets, they had to limit the size of their dictionary in order to keep the resulting tables manageable. We feel that 1,000,000 words is really not large enough to do a comprehensive search, and that the way the dictionary was constructed discounts some of the specifics for WPA network password requirements. WPA Cracker provides a service that can crack the PSK of a network with any ESSID, using a dictionary that is several orders of magnitude larger.

From WPA Cracker’s FAQ on “Aren’t there Rainbow Tables?”

That’s a good approach since keys tend to have a fixed size (or better, users tend to make them the least necessary to attend the requisites) so you don’t spend computational power trying password that wouldn’t fit them.

WPA Cracker may not be a threat at all, since even with a huge cluster it’s limited do dictionary attacks. If you use a dictionary password, you deserve to be cracked.

Mitigating the risk on an ARP poison attack

ARP poisoning is a technique quite simple to be applied and allows traffic to be sniffer over a switched network. It can be used to sniff the connection on-the-fly and capture plain-text password or hashes. ARP poison also allows combination with other attacks such as DNS spoof and packet filters in order to deploy client side exploits transparently.

This attack can only be performed from the local network because ARP packets aren’t routed so you can’t hop between LANs but it can be performed from any machine on the same network so it is a serious concern when dealing with unhappy employees, interns and industrial espionage. It is even a greater concern if you have public (or WEP encrypted) WIFI access in the same network (terrible mistake).

Countermeasures

ARP can’t really be blocked because they resolve IP addresses to MAC addresses. ARP packets must flow thru the network (unless you have ALL your MAC addresses statically configured) so machine can talk to each other. ARP doesn’t verify the requests and responses so any machine is able to respond to an ARP request in behalf of another machine making all traffic pass thru him. This is the ARP poison attack and is one of the most popular MITM techninques.

Subnetting

A well designed network is effective against several attacks, including and ARP poison attack. Since ARP packets can’t be routed the attack is retained at the local network so you may consider break your network into smaller subnets (VLANs). Note that attack still can be escalated if a machine that communicates to other lans is compromised.

Encryption

Encrypted traffic can be sniffed but can’t be understood. IPSec is feasible too but you can secure your services under SSL so you don’t need to encrypt all your network traffic that could slow down your network.

Static ARPs

You may write your ARP tables statically so it doesn’t need to be updated via requests and responses. This can be tough to manage so you might consider issuing this to login scripts or other configuration management software. Its like maintaining an hosts file.

Inline IDSs and ARP watchers

Using an inline IDS within your routers may early detect ARP storms and isolate the attacker. Some software may be put to watch ARP tables for changes. One ARP watch solution under UNIX systems is arpalert.