Information Assurance

Information Assurance

On the Apache HTTP Server 2.2.14 and earlier editions, as well as Microsoft Internet Information Services using machines had a vulnerability in the TLS and SSL protocol implementations. What happened is that they used an OpenSSL version prior to 0.9.8L. These servers would attempt to renegotiate handshakes with existing connections.

Below is a diagram from the IBM websites that displays the process of negotiating handshakes for servers:

However, the problem is that server handshake renegotiations in the implementation would create new connections with the same privileges as the existing connection, making an in-session handshake renegotiation. This made it possible for SSL protocol plaintext injections and man-in-the-middle attacks.

How the attacks work:
The client or end-user connects to a malicious machine, potentially knowingly (if, for example, the client mistakes the malicious server as a benign one). Then, every time the client wished to connect to the server that is the target of attacks, it would send its certification through the malicious machine, which could parallel the connection process to negotiate handshakes with the target server. Since the user is actually an accepted user on the target server, the handshake negotiations would succeed. The malicious machine would maintain the guise of being the target machine by sending all the target server's messages to the end user, and sending all end-user messages to the target server, thereby engaging in a man-in-the-middle role.

TLS basically begins with Client Hello messages, and ends with a Server Hello Done message and an encryption key shared between the client and the server. The only problem is that by renegotiating connections with the same privileges, the malicious machine in the middle can at this point gain the encryption key between the client and the server. Furthermore, the connection is established directly between the malicious machine and the target server, and NOT the client and the target server.

Furthermore, the malicious machine could have plaintext inserted into the Apache server without the client ever having knowledge of it.

One piece of code from the bugtraq thread links is below:
char *req =
"GET /highsecurity/index.html HTTP/1.1\r\n"
"Host: example.com\r\n"
"Connection: keep-alive\r\n"
'\r\n"
"GET /evil/doevil.php?evilstuff-here HTTP/1.1\r\n"
"Host: example.com\r\n"
"Connection: close\r\n"
"X-ignore-what-comes-next: ";

The client then completes the second request with his own request:
char *originalRequest =
"GET /good.html HTTP/1.1\r\n"
"Cookie: AuthMe=Now\r\n"
"\r\n";

This actually ends up ignoring the second request by the client. Meaning that the executed code is only:
GET /highsecurity/index.html HTTP/1.1
Host: example.com
Connection: keep-alive
GET /evil/do.php?evilStuff=here HTTP/1.1
Host: example.com
Connection: close
X-ignore-what-comes-next: GET /index.html HTTP/1.1
Cookie: AuthMe=Now

Doing this then, client users could be entirely shut out of the server, while malicious attacks are conducted.

What could have prevented the problem?
If the OpenSSL TLS/SSL implementation did not implement renegotiation of handshakes in-session, or if the protocol did not inherit privileges of the parent connection, this problem would not occur. Furthermore, this problem could have been avoided if there was a way to insure the gap in authentication or encryption was non-existent.

What can be done to work around it:
The current OpenSSL implementation entirely blocks handshake renegotiation. This destroys some e-commerce businesses that rely on handshake renegotiation, but it is the fastest workaround. However, in the long-run, there will probably be patches that will address handshake renegotiation without inheriting privileges.

What can be done from preventing it from occurring in the future:
This problem is very problematic, as a connection to any machine that guises as another machine can create authentication gaps. However, if privileges are restricted on any inherited connection or in-session new connections, the issue could be alleviated.