Hi Cyrill,
On 19 Jul 2005 at 13:46, Cyrill Osterwalder wrote:
That is basically correct. But SSL may be vulnerable to the same kind of
attack in the following scenario that we have seen in reality: A web
application server uses the SSL session ID to implement the session tracking.
Some clients connect through a SSL forward proxy that pools outgoing SSL
sessions. Of course, that is not the proper way to handle SSL in a forward
proxy. However it can happen in this scenario that other clients jump on
another SSL (and therefore application) session.
I'm not sure I follow. You say SSL is handled in a *forward* SSL proxy? But
that proxy
typically does *not* have the SSL server side certificate. So if it terminates
the SSL
connection from the client (and establishes a new SSL connection to the server,
pooling
this connection among several clients), then the client will see a nasty
certificate
warning. Do people actually do this?
*) Proxy vendors - do not to share TCP connections to the server
among several clients. Yes, it improves performance, but it's also
insecure and enables/aids 3 different attacks (the one described
here, HTTP Request Smuggling and HTTP Response Splitting).
We are developing a secure reverse proxy server with a strong focus on
security AND performance. It is indeed possible to handle NTLM authentication
in a reverse proxy and pooling server connections WITHOUT being vulnerable to
your described attacks. We are able to do this with our reverse proxy
(product name is AirLock, technology paper available here:
http://www.seclutions.com/en/downloads/AirLock_Whitepaper.pdf ) by binding
the NTLM authentication not only to the TCP connection on the client side but
also to the secure session management on AirLock. Just for the completeness
of your request to proxy server vendors I think you should cover this
possibility as well. By using our method of NTLM authentication through a
secure reverse proxy you do not make your system vulnerable to this attack,
even if back-end connections are pooled for performance.
I suppose you're talking about a scenario wherein AirLock (which is a kind of
Web
Application Firewall - WAF, as far as I understand) sits in front of a web
server. Now,
suppose the root page (/) of the application is protected by NTLM
authentication. Client 1
goes through AirLock, authenticates to the webserver (NTLM) and acquires a
session token
from AirLock. A second client arrives (no session token, since this is his
first request),
requesting the root page (/). Unless AirLock performs the NTLM authentication
itself, I
don't understand (from your description) how it can prevent this request from
arriving at
the web server (and assuming AirLock pools connections, it will do so on the
connection of
the first client).
Also the other two
attack methods can be prevented using URL protection and filtering
techniques.
As for HTTP Response Splitting, yes, this can be prevented by WAFs, provided
they also look
at POST requests (whose parameters are found in the body of the HTTP request,
rather than
in the URL).
As for HTTP Request Smuggling, kindly refer to my earlier submission to this
mailing list,
titled "Can HTTP Request Smuggling be blocked by Web Application Firewalls?"
http://www.securityfocus.com/archive/107/402974
Alternatively, use NTLM over HTTPS (SSL) to avoid this
vulnerability, but make sure that the SSL is terminated on the web
server, not some SSL accelerator (which may in itself facilitate the
attack, e.g. if it shares a TCP connection to the server among
several clients).
That is a valid request regarding this specific type of attack. However,
terminating SSL on the Web server (instead of a separate device in front of
it) introduces many other risks and vulnerabilities. If SSL is terminated on
the Web server, it is not possible to recognize any other attack methods
(e.g. application or Web server specific attacks) before they get to the Web
server.
I think you mean "block"/"defend", rather than "recognize". There are several
passive and
semi-passive IDS products that can decrypt SSL traffic (given the server's
private key, of
course).
This may be too late! More information on such attack methods and why
SSL should always be terminated in front of a Web server is illustrated in
our technology whitepaper already mentioned above:
(http://www.seclutions.com/en/downloads/AirLock_Whitepaper.pdf).
There's a trade-off, true. It also assumes that the WAF itself isn't
vulnerable...
Thanks for your comments and your interest in the writeup,
-Amit
