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:

Tricks & skills in Ubuntu

To delete unused kernels, use the following command:
sudo aptitude purge ~ilinux-image-.*\(\!`uname -r`\)

To delete the RC packages, use the following command:
dpkg -l | grep ^rc | cut -d' ' -f3| sudo xargs dpkg -P

Use this command to remove the unused configuration files:
dpkg -l |grep ^rc|awk '{print $2}' |sudo xargs dpkg -P

Make sudo regards http_proxy etc., add in file /etc/sudoers:
Defaults env_keep += "http_proxy"

TCP communication over Qt

1.QTcpSocket

QTcpSocket is used as the TCP socket in Qt. It's used both in client and server side.

To perform as a client, following steps are used:
a) call QTcpSocket.connectToHost() to connect to a server;
b) when connected, QTcpSocket.connected() will be emitted;
c) communicate with the server.

The following code shows a simple client sending "Hello, world" to the server.

// client.h
#include <QtNetwork>
#include <QtCore>

class Client: public QObject
{
Q_OBJECT
public:
Client(QObject* parent = 0);
~Client();
void start(QString address, quint16 port);
public slots:
void startTransfer();
private:
QTcpSocket client;
};

// client.cc
#include "client.h"
#include <QHostAddress>

Client::Client(QObject* parent): QObject(parent)
{
connect(&client, SIGNAL(connected()), this, SLOT(startTransfer()));
}

Client::~Client()
{
client.close();
}

void Client::start(QString address, quint16 port)
{
QHostAddress addr(address);
client.connectToHost(addr, port);
}

void Client::startTransfer()
{
client.write("Hello, world", 13);
}

// main.cc
#include "client.h"
#include <QApplication>

int main(int argc, char** argv)
{
QApplication app(argc, argv);

Client client;
client.start("127.0.0.1", 888);

return app.exec();
}


2.QTcpServer

In Qt, the class QTcpServer is used as a TCP server. Generally, the following steps are used:
a) call QTcpServer.listen() to start listening;
b) QTcpServer.newConnection() signal will be emitted when a new connection comes;
c) call QTcpServer.nextPendingConnection() to get the socket object (QTcpSocket) connecting to the client.

The following code shows a simple server receiving and printing a string from its client.

#include <QtNetwork>
#include <QtCore>

class Server: public QObject
{
Q_OBJECT
public:
Server(QObject * parent = 0);
~Server();
public slots:
void acceptConnection();
void startRead();
private:
QTcpServer server;
QTcpSocket* client;
};

// server.cc
#include "server.h"
#include <iostream>
using namespace std;

Server::Server(QObject* parent): QObject(parent)
{
connect(&server, SIGNAL(newConnection()), this, SLOT(acceptConnection()));

server.listen(QHostAddress::Any, 888;
}

Server::~Server()
{
server.close();
}

void Server::acceptConnection()
{
client = server.nextPendingConnection();

connect(client, SIGNAL(readyRead()), this, SLOT(startRead()));
}

void Server::startRead()
{
char buffer[1024] = {0};
client->read(buffer, client->bytesAvailable());
cout << buffer << endl;
client->close();
}

// main.cc
#include "server.h"
#include <QApplication>

int main(int argc, char** argv)
{
QApplication app(argc, argv);
Server server;
return app.exec();
}


P.S.You should add QT += network in the project file created by qmake -project.

===========================

Added on 12.1.2009

QUdpSocket is the encapsulation class for UDP communication in Qt. Following steps are generally used:
a) call QUdpSocket.bind() to listen on a specified address and port, which performs like QTcpServer.listen();
b) call QUdpSocket.writeDatagram() to send UDP messages;
c) when datagrams arrive, QUdpSocket.readyRead() will be emitted, and one can call QUdpSocket.readDatagram() to receive UDP messages.

Due to the lazy nature of human being, no example on UDP will be available.