Ivan Ristić

Clientless SSL VPN products break the Web

Dan Goodin, of The Register, pointed me to a very interesting advisory issued today that again confirms that convenience trumps security, every single time. This particular problem concerns the so-called clientless SSL VPN products, which basically work like a reverse proxies on steroids. When you're on the road, you log into one of these devices and they provide you with a "window" through which you can access the sites you'd normally only see on your own network. Now, I've known about these products for a long time but, never having actually used one, I didn't think much about how they work. Now that I know, I am terrified. They basically map all the sites you're accessing into a single super-site, rewriting everything behind the scenes to maintain the illusion of a browser within a browser.

For example, if your internal's site address is internal.example.com and your clientless SSL VPN's address is vpn.example.com, while you're on the road you access your internal site through https://vpn.example.com/internal.example.com/.

It's pretty slick in how it's very convenient and works with any browser, but it kills the same-origin policy. A single rogue web site that you access through this VPN window is able to take over all your sessions, interact with all your sites and monitor whatever is that you're doing.

And the best part? The problem has been known since at least 2006. You can get more information from Dan's article or from the advisory.

Shameless self-promotion: ModSecurity Handbook, the guide to the world's most popular web application firewall, is now available for instant download.

HTTP parser for intrusion detection and web application firewalls

For a couple of months now I've been working on a new HTTP parser (library), which I am designing for use in intrusion detection systems and web application firewalls. I suppose that HTTP parser is not really an adequate name for this library, because it sounds narrow in scope. In truth, the library will cover all the protocols and encodings used in web applications.

The first user of the parser will be the Open Information Security Foundation (OISF), which is currently building a new IDS from scratch (first release expected on December 31st). The parser itself is going to be released under an open source licence and supported long term.

The biggest challenge with a parser like that is the desire to support an entirely passive mode. Whereas normal parsers are free to interpret the input stream in any way they're pleased for as long they appear to get the job done, a passive parser must be able to decipher traffic intended for multiple web servers, and thus also needs to be aware of the quirks in their processing. Also, without the ability to terminate traffic, opportunities for evasion are rife. The really interesting part of this project is figuring out all the possible ways to evade the parser. I think this is the first time that I will have the time to think like an attacker for as long as I need to do the job properly. I am currently experimenting with the idea of parser personalities, whereas the user is allow to tweak exactly how the parser behaves on per-connection basis. This approach makes it possible to use one set of rules for an Apache web server, and another for an IIS web server.

For the first release of the parser to goal is to be able to parse HTTP streams reliably. In the subsequent versions I will work in the parser's security properties (such as the ability to see through evasion attacks).

A couple of weeks ago, at DeepSec in Vienna, I gave a lightning talk about my work. Matt Jonkman kindly allowed me to use some of the time of his own talk. I am attaching the slides here:

• Download Ivan Ristic - The Challenges of HTTP Intrusion Detection (PDF)

ModSecurity Handbook available for pre-order and early access

ModSecurity Handbook, which I announced a couple of days ago, is now available for pre-order and early digital access. We managed to meet our self-imposed deadline and have everything ready for November 24th, actually.

This book is a big deal, in more ways than one:

1. It took me more than 5 years to gather courage to start writing another book (after Apache Security, which I started writing in 2004).
2. This book is about ModSecurity, a project that is very dear to my heart. It makes me very happy that I will document everything I know about it.
3. I am releasing the book early because I want to interact with the readers while the content is still not finalised. With Apache Security I ended up being terribly unhappy because I was writing in isolation and because I couldn't seek feedback from the readers prior to publication.
4. To publish this book (and all my subsequent books), my wife and I started a publishing company and dealt with all the stuff that publishers have to deal with. The learning curve wasn't very difficult because of my previous experience in publishing, but there was a lot of things to do.
5. This book will be a living book. I intend to keep it up to date at all times, keeping up with the changes in ModSecurity. We've invested a significant amount of time into polishing a single-source publishing system, where the manuscript is kept as XML (DocBook, stored in a Subversion repository) and automatically converted to any of the supported formats (only PDF at the moment, but several forms of PDF, HTML and ePub in the near future). The system allows me to make changes and push updates instantly to all the readers!

The work is far from done, of course. First, I need to finish the book, first of all. Second, we'll have to figure out how to promote it effectively, and I somehow suspect that will be the hardest part. Perhaps, when it's all done, I'll write a blog post called "Adventures in Computer Book Publishing".

Update: The official Reference Manual and Data Formats Guide guide have been added to the book. There's about 230 pages of material right now, with the final count expected to be close to or over 300.

Initial test for SSL renegotiation added to SSL Labs

I've added an initial implementation of the test that determines if an SSL server is vulnerable to the Authentication Gap MITM attack. At this point the assumption is that no server supports the safe renegotiation TLS extension, which means that a warning is displayed if renegotiation is found to be supported.

In the following days, as the implementations of the safe renegotiation TLS extension start to arrive, I will improve the test to take that into account.

Announcing ModSecurity Handbook

It is a pleasure to announce my next book, ModSecurity Handbook, which features an in-depth coverage of ModSecurity, an open source web application firewall. I am very happy because, finally, ModSecurity will have the documentation it deserves.

The main highlights are the following:

• Step-by-step instructions for those just starting out
• Detailed explanations of the internals, and advanced techniques for seasoned users
• Includes the official ModSecurity Reference Manual and Data Formats Guide
• Available in digital format (PDF, HTML and ePub, although not all straight away) and as paperback (once the first edition is complete)
• Continually updated as ModSecurity evolves (with the updates included with purchase)
• Readers can talk to me to shape the book to work better for them

The complete table of contents is available on the book's web site.

I estimate that the book is about 75% complete. In a week's time (on November 24th) it will be available for early access and pre-order. The idea with the early access is to avoid the problem I experienced with Apache Security -- writing in isolation. This time, I want to engage with my readers before my book is published.

Also, it is pretty important that this book is (and will be) continually updated. I have the entire publishing workflow automated so whenever I make a change to the book, the update is automatically made available to the readers. With this feature, again, I want to avoid the painful experience that I had with Apache Security, where for years I wanted to provide updates but I couldn't. (Apache Security readers, fear not, the second edition is being worked on.) In the future, I hope to evolve the publishing toolchain to enable readers to make comments straight to the HTML version of the book that is kept online.

Not just CSRF: SSL Authentication Gap used for credentials theft

Most people associate the recent SSL Authentication Gap vulnerability with mild CSRF, but a couple of days ago Anil Kurmus published an improved attack technique that enabled him to access victims' encrypted data streams. He wrote a proof of concept that could have been used to retrieve someone's Twitter credentials. Twitter's SSL servers no longer support renegotiation so the attack no longer works, but the same principle will still work with other sites. Anil's attack technique was posted to Full Disclosure last Wednesday, but it was ignored. It was subsequently picked up by Dan Goodin from The Register.

In researching the possible attack vectors made possible with the SSL authentication gap problem, most focused on trying to use the credentials included with hijacked requests (i.e., session cookies or Basic Authentication credentials). Anil realised that, although he was not able to decrypt the hijacked requests he was still able to include them as payload in arbitrary requests of his own. So all he needed was a site that has some sort of publishing functionality that can be used to reveal data. With the Twitter attack, he simply published the hijacked data as his Twitter status message.

The attack works because the hijacked information is used in a parameter of the attacker's request. Below is a partial attack example to describe the concept:

POST /statuses/update.xml HTTP/1.0
Authorization: Basic [attacker's credentials]

status=POST /statuses/update.xml HTTP/1.1
Authorization: Basic [victim's credentials]

This attack technique is best suited to exploit APIs protected using Basic Authentication. It will work equally well for session hijacking, but hijacking the credentials in the case of sites that use form-based authentication may be more difficult due to the presence of the ampersand characters in victims' data streams.

Marsh Ray (who discovered the SSL authentication gap issue), hinted that information theft might be possible in a comment to Eric Rescorla's blog post, but he said he was more interested in fixing the problem rather than seeking interesting ways to abuse it.

Planned usability improvements for ModSecurity 2.6

After leaving Breach Security in February I took a break from ModSecurity. On the one hand, I was tired. On the other, I needed time to figure out what role I will have in the project, or if I wanted to have a role at all. Over time my interest in ModSecurity started to come back. Even more interestingly, I started to look at it with a fresh perspective. What would a newcomer make of it? In doing so I came up with a long list of small problems that need fixing. The beauty of my new position (a contributor) is that I no longer need to think where the project is heading next, but can spend as much (or little) time as I like working on the things that I have interest in.

Here's my list:

1. It is not clear what happens when an operator fails. I think a level 1 error message is emitted, but there is no effect on rule processing. This is a small anomaly that needs fixing. I believe the user should be given an option to be strict (block) or relaxed (not block). [MODSEC-12]
2. The variable REQUEST_URI is used directly from the Apache's structures. As a consequence the value may change between phases. ModSecurity should have one robust variable that refers to a path, to avoid small problems. The MODSEC-98 improvement fixed this issue.
3. At the moment we provide a raw REQUEST_URI and expect the users to use transformation functions to deal with evasion. That is inconveniencing our users; we should have REQUEST_URI pre-normalised. And, because we rely on Apache for normalization at the moment, doing normalization ourself would give use better control over the process and increase consistency. (For example, Apache does not always do the right thing when deployed in proxy mode.)
4. The REQUEST_BODY variable contains request bodies, but the variable is only available when the for urlencoded bodies. This is because in most cases it doesn't make any sense to store the entire request body in memory (think file uploads). There's a hack to force a request body into memory (ctl:forceRequestBody), but we need to provide a consistent way to deal with the inspection of request bodies.
5. Phase information should not be allowed in SecDefaultAction. That is something for rules to be concerned about.
6. Transformation options should not be allowed in SecDefaultAction, because transformations need only be configured on the per-rule basis. In fact, the entire situation with how SecDefaultAction works is murky and needs improvement.
7. SecArgumentSeparator should not be a main-only directive.
8. SecComponentSignature should not be a main-only directive.
9. ModSecurity should refuse to accept the rules that use variables in phases when they are not available. Why wait for the users to discover the problem the hard way?
10. There's no reason that non-existent response types are specified with "(null)". We should change that to "null", keep the old variant, but remove it from the documentation. This had been fixed, but I missed it.
11. The performance-tracking information (Stopwatch) -- which was just copied over from ModSecurity 1.9.x -- does not provide useful performance measurement. Done. Implemented Stopwatch2, which is a great improvement.
12. The users have been complaining about an elusive mod_deflate compatibility issue for ages now. It needs fixing. Done (MODSEC-89).
13. Allow main and virtual host configuration and phase 1 rules to be overridden in <Location> configuration contexts. Done (MODSEC-98).
14. Use international-friendly spelling: change "sanitise" to "sanitize". Done (MODSEC-95).
15. Use international-friendly spelling: change "normalise" to "normalize". Done (MODSEC-103).
16. Remove the obsolete PDF UXSS functionality. Done (MODSEC-96).

SSL and TLS Authentication Gap vulnerability discovered

A serious vulnerability has been discovered in the way web servers utilise SSL (and TLS, up to the most recent version, 1.2), effectively allowing an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. Both the Apache web server and the IIS have been found to be vulnerable.

The problem is with the renegotiation feature, which allows one part of an encrypted connection (the one taking place before renegotiation) to be controlled by one party with the other part (the one taking place after renegotiation) to be controlled by another. A MITM attacker can open a connection to an SSL server, send some data, request renegotiation and, from that point on, continue to forward to the SSL server the data coming from a genuine user. One could argue that this is not a fault in the protocols, but it is certainly a severe usability issue. The protocols do not ensure continuity before and after negotiation.

To make things worse, web servers will combine the data they receive prior to renegotiation (which is coming from an attacker) with the data they receive after renegotiation (which is coming from a victim). This issue is the one affecting the majority of SSL users.

The following example demonstrates how the flaw can be exploited by an attacker to send an arbitrary request using the authentication credentials of a victim. The red parts are sent by the attacker and the blue parts are sent by the victim.

GET /path/to/resource.jsp HTTP/1.0
Dummy-Header: GET /index.jsp HTTP/1.0
Cookie: sessionCookie=Token

The good news is that, although the attacker can execute an arbitrary request, he will not be able to retrieve the corresponding response. On the negative side, the client will see something different from that what she requested.

You can see that GET attacks are essentially trivial to execute. To date, no one has claimed a successful execution of a POST request using this flaw. Until someone does, that means that an application that only makes changes in response to POST requests will probably not be vulnerable. Further, an application not vulnerable to CSRF attacks will probably be safe too, because the attacker won't be able to generate or predict the token required for the request to go through.

Mitigation options:

1. If you can, disable renegotiation. There isn't normally a configuration option to do this, but patches are being developed and will be available soon. The majority of web sites do not use renegotiation so disabling it won't be a problem. Those that do will need to make changes to their sites to make them work without it.
2. Use a web application firewall to monitor the contents of all request headers to spot what seems like an embedded HTTP request line. The good news is that the embedded request line will not be obfuscated, making it easier to detect. I do not believe that this advice can help the bypass of the client certificate authentication, though.
3. If you can, monitor all connections that make use of the renegotiation feature. That won't help you if renegotiation is an integral feature of your web site, but it may do if it is rarely used.

Further information:

• Marsh Ray's blog post (Marsh discovered the problem a couple of months ago) contains a detailed description of the problems in the attachment.
• The post by Martin Rex to the TLS mailing list that prompted public disclosure.