Squid Web Proxy authentication failure vulnerability explained
4 Nov. 1999
Summary
As we reported earlier: Squid Web Proxy Authentication Failure Vulnerability, a vulnerability in Squid allows users to gain access to the web proxy using a "username/password" shifting technique.
The following explains how this vulnerability can be recreated.
Credit:
This explanation was provided by: Oezguer Kesim.
1) You use a plain squid-2.2-STABLE5 or below. Also, external authentication is active using an external authentication program, which basically follows the implementation guidelines given on the squid web pages.
2) Your ACL's for external authentication apply often enough so that external authentication actually happens maybe every 20 seconds to 20 minutes. This also depends on your password-cache settings.
3) In general, users enter correct user:password pairs.
4) No other user has sent a user:passwd pair with a new-line at the end to the proxy so far (we are describing the effect when it occurs for the first time).
The exploit:
1) Create a base64-encoded "user:passwd\n" string, for example:
# echo "foo:bar" | mimencode
# Zm9vOmJhcgo=
Note that
# echo -n "foo:bar" | mimencode
(Note the -n option) will strip the trailing new-line and can't be used.
The new-line at the end is essential for the exploit to work, since most external authenticators will read two lines from the proxy and send two results back to the proxy, shifting all subsequent responses to authentication request by one.
2) Telnet to your proxy and send a valid but not authorized request:
# telnet proxy 8080
Trying 123.123.123.123
Connected to proxy.home.net
Escape character is '^]' GET http://some.domain.net HTTP/1.0 Proxy-Authorization: Basic Zm9vOmJhcgo=
Please notice the last extra new-line needed for the Protocol (it has nothing to do with the exploit, though).
An ACL must match the given domain (here, some.domain.net), which uses the external authentication program.
3) You will see the response for your user:passwd pair and due to the assumption above, this answer is accurate.
Now, once a different user sends his user:password pair - which in turn is correct in general (as stated in the assumptions above) - he will get the authentication response of your empty line and most probably will be a HTTP/1.0 407 Proxy Authentication Required answer. But then, the user will try again and get the correct answer of his or her first try.
Now, the second answer (which most probably will be OK) is pending!
4) Try to connect again with another fake user:password (without an extra new-line), most likely using your favorite browser. Now you can profit from the pending OK in step 3 and get the page you want.
That's it. Please notice, that when caching is active, you can surf as long as the name:password pair is available in the cache - which can be quite long.
