IC cards are vulnerable to MITM attacks

Researchers from Cambridge found a vulnerability in IC cards using EMV, which is used worldwide (with over 730 million cards in circulation) in chip and pin credit/debit cards. Note that the authors claimed that “the protocol is broken”. The details will be published at IEEE Security and Privacy Symposium in May this year, and a working draft is available now.

With this vulnerability, criminals are able to launch Man-In-The-Middle (MITM) attacks easily and use stolen cards without knowing the correct PIN. The attack works for both online and offline transactions on terminals. Fortunately, it can’t work for ATM transactions.

Let’s see how it works. The EMV protocol can be split into three steps:
1 Card authentication – assure which bank issued the card and the data hasn’t been tampered.
1.1 The terminal requests the list of available applications (e.g. card use at shops, ATM functionality, etc.), and selects one of them.
1.2 The terminal reads the information of the card-holder, including card details (e.g. primary account number, start and expiry date), backwards compatibility data, and control parameters for the protocol. Some information is signed by RSA, and the certificate chain is also included in the information.

2 Card-holder verification – assure the PIN entered matches the one stored on the card.
2.1 The terminal sends the inputed PIN to the card for verification.
2.2 If the inputed PIN matches the one stored on the card, 0×9000 is returned to the terminal. Otherwise, 0×63Cx is returned, where ‘x’ is the number of further PIN verification attempts the card allows. Note that the response is NOT directly authenticated.

3 Transaction authorization – assure the bank authorizes the transaction.
3.1 The terminal asks the card to generate a cryptographic MAC over the transaction details, including e.g. the transaction amount, currency, type, a random nonce generated by the terminal, and the terminal verification result. Note that the terminal verification result merely enumerates possible failure conditions, and doesn’t indicate which particular method is used in case of success.
3.2 The card sends back also a sequence counter identifying the transaction, a variable length field containing data generated by the card, and the MAC. The MAC is usually generated using 3DES with a symmetric key shared between the card and the issuer.
3.3 The terminal sends the response to the bank for transaction authorization.
3.4 If the check passes, the bank sends back a two byte long response code, and a MAC over the message sent from the card and the response code.
3.5 The response is forwarded by the terminal to the card. If the card verifies the response from the bank, it updates some internal states to note that the bank authorizes the transaction.
3.6 The terminal asks the card to generate a transaction certification, signifying that it’s authorizing the transaction to proceed. It will be sent to the bank and stored locally for further use.

Due to the above two flaws, the bad boy is able to launch the MITM attack like this:
1) It hijacks the communication in step 2, sending 0×9000 to the terminal to fool it into believing the PIN verification succeeds.
2) As the PIN is never sent to the card, it will be fooled into believing the terminal doesn’t support PIN verification, and the PIN retry counter is not modified.
3) As the terminal verification result doesn’t tell the particular method used, the terminal believes the PIN verification succeeds and the card believes the PIN verification is not attempted.
4) The variable length field containing data generated by the card generated in step 3.2 is issuer-specific, and not specified in EMV. Therefore, the terminal can’t decode it, and the issuing bank doesn’t know which card-holder verification scheme is used.

Also, the researchers found that EMV failed to provide adequate evidence to produce in dispute resolution and litigation, among other issues. And we should be aware that this vulnerability is not implementation-specific, but the fundamental protocol is broken!

SSL renegotiation vulnerability exploited

This post has been moved to http://www.zionsoft.net/2009/11/ssl-renegotiation-vulnerability-exploited/

The SSL renegotiation vulnerability revealed earlier this month has been demonstrated by a Turkish grad student, named Anil Kurmus, to steal user names and passwords of Twitter. The code is also available in the wild.

Yes, it’s totally true that even the attacker can inject a small amount of message at the beginning, he’s still unable to read the encrypted data. But let’s see how Kurmus’ attack works. (Of course, this hole has been patched by Twitter)

You can update your Twitter status with its API by posting your new status to http://twitter.com/statuses/update.xml, as well as your user name and password. The message is something like below:
POST /statuses/update.xml HTTP/1.1
Authorization: Basic username:password
User-Agent: curl/7.19.5
Host: twitter.com
Accept:*/*
Content-Length: 22
Content-Type: application/x-www-form-urlencoded
status=your new status

All that the attacker need to do is to inject a POST request header, and post the victim’s POST request to his own twitter account:
POST /statuses/update.xml HTTP/1.1
Authorization: Basic username:password
User-Agent: curl/7.19.5
Host: twitter.com
Accept:*/*
Content-Length: 140
Content-Type: application/x-www-form-urlencoded
status=POST /statuses/update.xml HTTP/1.1
Authorization: Basic username:password
…

The red part is injected by the attacker, and the blue part is submitted by the victim. Then the server would be fooled to post the victim’s credential, and now, the attacker gets the user name and password of the victim.

Quite simple, but really destructive!

The details of the SSL renegotiation attack

This post has been moved to http://www.zionsoft.net/2009/11/details-of-ssl-renegotiation-attack/

This MITM attack is against all versions of the SSL/TLS protocols, allowing an attacker to inject any amount of data into the beginning of the application protocol stream.

I assume you understand how SSL/TLS works, especially the renegotiation part, which is the weak point leading to the following three attacks. Also, a basic understanding of the HTTP protocol is recommended.


1st scenario: when the client certificate is required
In the ideal case, the client certificate is requested when the server sends its certificate. However, in the real world, it’s requested only when the client requests something that needs the client certificate. Instead of a brand new handshake procedure, this would trigger the server to start a renegotiation.
Unfortunately, as HTTP has no way to instruct the client to resubmit the request after the renegotiation, the server has to reply with the requested content after the renegotiation, resulting a gap of authentication.

The sequence of this attack is summarized below:
1) client –> attacker : handshake1
2) attacker –> server: handshake2
3) attacker –> server: request something
4) attacker <– server: renegotiation, requesting client certificate
5) client <–> attacker <–> server: attacker forwards handshake1, and handshake3 is built which is only readable by the server and the client
6) client <– attack <– server: the server responds with the content requested at step 3

Now, the client gets what he hasn’t required…


2nd scenario: different cipher suites used
Some websites are configured that different resources are protected by different cipher suites. If the client requests a resource protected by another cipher suite, a renegotiation is needed. However, the request from the client is buffered by the server for future use, resulting to this attack. Just have a look at the following example.

The attacker sends a request:
GET /index.html HTTP/1.1
Host: server_address
Connection: keep-alive
GET /evil.html HTTP/1.1
x-ignore:

The second request is completed by the client:
GET /good.html HTTP/1.1
Host: server_address
Cookie: client_cookie

Unfortunately, the second request is consider by the server as below:
GET /evil.html HTTP/1.1
x-ignore: GET /good.html HTTP/1.1
Host: server_address
Cookie: client_cookie

The client get /evil.html instead of /good.html……


3rd scenario: client initiated renegotiation
This attack is based on the fact that the client can also launch a renegotiation, and the server would buffer the previous request and use them after the renegotiation. It’s reasonable to believe that this is the most dangerous scenario as it requires nothing special from the server. Here is the details:
1) The attacker builds an SSL connection with the server, and sends the request:
GET /evil.html HTTP/1.1
R
x-ignore:

Here, the R would trigger a renegotiation, while the x-ignore: is an unfinished header line without line termination, which would be buffered and used by the server later.

2) The attacker forwards the messages, and builds a connection between the client and the server.

3) The client sends a request to the server:
GET /index.html HTTP/1.1
Host: server_address
Connection: keep-alive

However, due to the injected request from the attacker, the server considers the whole request as:
GET /evil.html HTTP/1.1
R
x-ignore: GET /index.html HTTP/1.1
Host: server_address
Connection: keep-alive

It will return the /evil.html rather than /indes.html as expected.

Now, I’d like to notify you again that all these attacks are against the SSL/TLS protocols, rather than the implementations, which means that either the client or the server could smell anything about the attacker. To summarize, the attacker tries to renegotiate the SSL connection before the client really communicates with the server, and the request made by the attacker before the negotiation will be replied to the client, which may lead to serious attacks. Quite easy to understand and implement, right?

A draft has already been proposed to fix this problem by cryptographically binding renegotiation handshakes to the enclosing TLS channel, which is not supported by current clients and servers. The fix is to include the digest data from the FINISHED message of the previous handshake in CLIENT-HELLO or SERVER-HELLO of the renegotiation.

Finally, I’d like to remind you about the vulnerabilities of DNS and BGP discovered last year, as I consider the attack against SSL is equally disastrous as those two.

UPDATED: The final fix for this issue is available as RFC 5746.

WPA is next to death!

Last November, German researches found the first vulnerability in WPA/TKIP, which allows the attacker to break some short packets with most fields known, e.g. ARP request/response, within 12-15 minutes, and inject up to 7 packets.

Two months earlier, Japanese researchers improved the attack:

In 2008, Beck and Tews have proposed a practical attack on WPA. Their attack (called the Beck-Tews attack) can recover plaintext from an encrypted short packet, and can falsify it. The execution time of the Beck-Tews attack is about 12-15 minutes. However, the attack has the limitation, namely, the targets are only WPA implementations those support IEEE802.11e QoS features. In this paper, we propose a practical message falsification attack on any WPA implementation. In order to ease targets of limitation of wireless LAN products, we apply the Beck-Tews attack to the man-in-the-middle attack. In the man-in-the-middle attack, the user’s communication is intercepted by an attacker until the attack ends. It means that the users may detect our attack when the execution time of the attack is large. Therefore, we give methods for reducing the execution time of the attack. As a result, the execution time of our attack becomes about one minute in the best case.

Now, Halvorsen with others made another progress, enabling hackers to inject a huge number of malicious bytes within approximately 18 minutes and 25 seconds:

Beck and Tews described the first practical cryptographic attack on IEEE 802.11i TKIP in November 2008, and this paper continues this line of protocol cryptanalysis. We show that their attack on TKIP can be used to create an ARP poisoning attack and a cryptographic DoS attack. Moreover, we are able to decrypt DHCP ACK packets, which are over 12 times longer than the ARP packet used by Beck and Tews. Our method of analysis recovers 596 bytes of keystream that can be used in new attacks on other control protocol messages.

We should remember that the attacks would always improve. Therefore, switch your network to WPA2/CCMP right now!

Chinese version of GTalk is NOT encrypted!

My friend just told me that the Chinese version of Google Talk is NOT encrypted, while the English version is encrypted. As shown below, when using the Chinese version, the message (in the red circle) is not encrypted at all! One thing you should know is that the Chinese version is higher than the English version, which suggests Google might remove the encryption on purpose. It reminds me of the shit of TOM-Skype, which watches the text conversation of users.

Here goes the screen shot of the Chinese version (1.0.0.105), and you can see the text transmitted unencrypted at all:

Here goes the screen shot of the English version (1.0.0.104), which is obviously encrypted using TLS 1.0 as the first 3 bytes are 0×17 0×03 0×01:

You’re watched on TOM-Skype

Security experts from University of Toronto Citizen Lab report that TOM-Skype, Skype’s China venture with TOM, text messages sent between TOM-Skype users and between Skype users and TOM-Skype users, are scanned for phrases like “Taiwan independence” or “Falun Gong” or for opposition to the Communist Party of China. When these keywords are found, the messages and information, such as usernames of subscribers, are stored on publicly accessible Web servers along with an encryption key that could be used to unlock the data.

Jennifer Caukin, a spokewoman of Skype admitted the breach.