Showing posts with label Wireshark. Show all posts
Showing posts with label Wireshark. Show all posts

Thursday, September 30, 2010

Wireshark makes mistake; Calls CCMP encrypted wireless data frames as TKIP !

Have you ever been bugged by Wireshark protocol analyzer tool? If yes, what was the last anomaly you found in it? For me, it seems to be wireless data frame dissector making mistake in decoding wireless data frame encryption type.

Wireshark, earlier known as Ethereal, is one of the most popular open source protocol analysis tool and frequently used by network and security analysts all over the world to analyze the performance or security of a protocol/network.


Figure 1: WPA2-CCMP Enabled APs

Just a few days back, I was analyzing an IEEE 802.11i enabled Wi-Fi network and found an anomaly in the behavior of the wireless network operation as shown by the Wireshark version 1.4.0. Wireless data frames exchanged between a WPA2-AES configured wireless client and an access point was marked as CCMP encrypted, which was obvious but a few data frames were marked as TKIP encrypted which raised the suspicion. 


Figure 2


How could WPA2-AES (and Mixed mode) configured wireless client or AP transmit TKIP encrypted data frames?

So, I decided to investigate it further. This blog post is about my findings on this issue.

As we all know, there are three types of data frame encryption algorithms used in Wi-Fi networks depending upon the type of security configured for example WEP secured WiFi network uses WEP encryption technique while WPA and WPA2 secured WiFi network use TKIP and CCMP respectively.

Can we accurately identify the encryption type just by analyzing the information present in the wireless data frame encryption header? And the answer is Yes.  How? Let’s first take a close look of encrypted data frames and see how it appears in the air.

1.    WEP Encrypted Data Frame Format
Figure 3: WEP Frame Format


WEP encrypted data frames contain only 4 bytes of encryption header. First three bytes are Initialization Vector (IV) which is used in the WEP encryption/decryption process.  Two most significant bits of the fourth byte are used to indicate the encryption key number to be used in the data frame encryption/decryption. Least significant six bits are always kept zero. 


2.   TKIP Encrypted Data Frame Format
Figure 4: TKIP Frame Format


TKIP encrypted data frame contains eight bytes of encryption header. Third and first bytes along with the last four bytes of the header are used in the TKIP encryption/decryption process.  Second byte is called WEPSeed. WEPSeed is not used in TKIP encryption but it is set to (TSC1 | 0x20 ) & 0x7F.

Three most significant bits of the fourth byte are used to indicate the key number and the presence of extra four bytes in the encryption header. Least significant three bits are always kept zero.


3.   CCMP Encrypted Data Frame Format
Figure 5: CCMP Frame Format

CCMP encrypted data frame contains eight bytes of encryption header (shown as CCM header in Figure 4). First and second bytes along with the last four bytes of the header are used in the CCMP encryption/decryption process.  Third byte is reserved and always kept as zero.

Three most significant bits of the fourth byte are used to indicate the key ID and presence of extra four bytes in the CCMP header. Least significant three bits are always kept zero.



Now one can easily identify WEP encrypted data frames as it contains only four bytes of encryption header and six least significant bits of the fourth byte are always zero while TKIP and CCMP encrypted data frames have only five least significant bits of the fourth byte as zero.

Distinguishing between a TKIP encrypted data frame and a CCMP encrypted data frame is bit tricky. We can make use of the difference in first three bytes of encryption header of TKIP and CCMP.

Test1: All TKIP encrypted data frames should have WEPSeed byte (2nd byte of eight bytes encryption header) set to (TSC1 | 0x20) & 0x7F.

Test2: All CCMP encrypted data frames should have third byte of eight bytes CCMP header set to zero.

Let's examine the packet trace in the light of above two tests. Let's assume that selected data frame shown in Figure 2 is correctly identified by Wireshark as TKIP encrypted data frame. So, TSC1 is 0x91, WEPSeed is 0xAB and TSC0 is 0x00. According to Test 1,

WEPSeed = (TSC1 | 0x20) & 0x7F

              = (0x91 | 0x20) & 0x7F
              = 0xB1 & 0x7F
              = 0x31

But the actual WEPSeed present in the data frame is 0xAB.

Hence the condition to be a TKIP encrypted data frame is not satisfied by the selected frame shown in Figure 2.

According to Test 2, CCMP encrypted data frames have third byte zero. Third byte of the selected frame in Figure 2 is actually 0 which confirms that it is CCMP encrypted data frame.

So we have confirmed that frame shown in Figure 2 is not TKIP encrypted but CCMP encrypted data frame and there is some problem with the Wireshark dissector.

Few CCMP encrypted data frames may have encryption header such that third byte is zero but second byte is equivalent to (First Byte | 0x20) & 0x7F. Under these conditions it would be difficult to find out encryption type just by seeing encrypted data frames.

It would be difficult to build a perfect detector but few other conditions can be taken into account in order to predict encryption type. For example in TKIP encrypted data frames, third byte of the encryption header is LSB of Transmit Sequence Counter (TSC) while in CCMP encrypted data frames, first byte of the encryption header is LSB of Packet Number (PN). This means in two consecutive transmitted frames, third byte will increment if the frame is TKIP encrypted else first byte will increment if the frame is CCMP encrypted.

Though, the difficulty of building perfect Wireshark detector to detect encryption type of data frame can be understood, why the designers of the standard chose to assign different name and meaning to individual octet of encryption header is vague.


If you know any reasons of the dissimilarity of TKIP and CCMP encryption header, kindly do share with us.

Saturday, June 27, 2009

No Privacy Ensured in WPA/WPA2-PSK Protocol: Choose Your WLAN Security Circumspectly


In a wired network environment, it is not possible to see others communication by passively monitoring the wired interface. Which means you can not really snoop into someone’s IM chat or email or browsing activity. But what’s about wireless network. Is your wired network’s privacy guaranteed over wireless? If you have just learnt about the weaknesses of an Open or WEP enabled WiFi networks and planning to upgrade to WPA/WPA2, hold on for a while. Privacy is also not guaranteed in a WPA/WPA2-PSK protocol.


WiFi is one of the popular wireless technologies widely adopted as local area networking protocol today. But there is some security issues associated with it and hence its implications should be understood well in advance before use. For example unguided medium is used for transmission, which means, any communication of an Open WiFi network can be seen from hundreds of meters away from the network. WEP configuration does no better than Open AP as the encryption technique is known to be broken and does not provide security cover for more than few minutes if attacked.


WPA and WPA2 are two other more robust WiFi security configurations than WEP and support two different authentication mechanisms (i) IEEE 802.1x authentication framework (ii) Pre Shared Key or PSK. IEEE 802.1x based configuration is known as Enterprise mode configuration and PSK mode configuration is known as Personal mode configuration. While enterprise mode configuration requires certificate for client and server and infrastructure in place for deployment, personal mode simply requires a “passphrase” which acts like a password for WiFi network access. The ease of deployment of a personal mode secured WiFi network makes it an obvious choice for home and personal WiFi networks.


There are few attacks known to exist against WPA-WPA2-PSK mode configuration. For example dictionary attack is known to be effective against WPA/WPA2-PSK or Personal mode networks; it can be easily circumvented by prudently choosing “Passphrase” of more than 8 characters and a mix of special characters and alphabets. Recent attack on “TKIP” which is one of the WPA/WPA2 supported encryption techniques, can be mitigated by reducing re-keying interval or by changing underlying encryption technique to AES (advanced encrypted system).


The key point here is that the known attacks from a malicious outsider against WPA or WPA2-PSK based networks can be fixed but the protocol is also found to suffer from an insider threat. In an enterprise environment, where WiFi enabled devices are configured with single key, there is a very high likelihood of this secret key getting shared among trusted users and finally becoming public. Once this happens, the privacy of an authorized user is lost. Any malicious user present inside the network can capture wireless traffic and decode it with the help of single shared key. There are tools freely available on Internet which can be used to decode frames e.g. Wireshark Protocol Analyzer. More technical details can be found at:

http://wiki.wireshark.org/HowToDecrypt802.11


This implies that one can easily snoop into one’s internet browsing activity and steal valuable information or data flowing in the air.


So the final word about WPA/WPA2-PSK mode is that it is safe to setup a home or personal WiFi network , it 's use should be avoided in an environment where the network key is shared and distributed among its users. Wired equivalent user’s privacy is not guaranteed in a WPA/WPA2-PSK enabled WiFi network and hence, a judicious decision should be made while choosing security cover for the network.