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!
7.11.09
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.
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.
Subscribe to:
Posts (Atom)