APPLICATION PROXY VULNERABILITIES | Hacking Exposed 5th Edition

In general, application proxy vulnerabilities are few. Once you have secured the firewall itself and implemented solid proxy rules, you'll be hard pressed to bypass a proxy firewall. But never fear, misconfigurations are common.

Hostname: localhost

Popularity:	4
Simplicity:	2
Impact:	9
*Risk Rating:*	5

With some older UNIX proxies, it was easy to miss restricting local access. Despite authentication requirements for your users when accessing the Internet, it was possible for an internal user to gain local access on the firewall itself. Of course, this attack requires knowledge of a valid username and password on the firewall, but you'd be surprised how easy these are to guess sometimes. To check your proxy firewalls for this vulnerability, you can do the following when you receive this login screen:

 C:\>  nc -v -n 192.168.51.129 23  (UNKNOWN) [192.168.51.129] 23 (?) open Eagle Secure Gateway. Hostname:

Type in localhost .
Enter a known username and password (or guess a few).
If authentication works, you have local access on the firewall.
Run a local buffer overflow (such as rdist) or a similar exploit to gain root.

Hostname: Localhost Countermeasure

The fix for this misconfiguration depends largely on the specific firewall product. In general, you can provide a host-restriction rule that limits the access from a particular site. The ideal countermeasure is to not allow localhost logins.

Unauthenticated External Proxy Access

Popularity:	8
Simplicity:	8
Impact:	4
*Risk Rating:*	7

This scenario is more common with firewalls that employ transparent proxies, but we do see it from time to time. A firewall administrator will go to great lengths to secure the firewall and create strong access rules but then forget to block outside access. This risk is twofold: (1) an attacker can use your proxy server to hop all around the Internet, anonymously attacking web servers with web-based attacks such as CGI vulnerabilities and web fraud, and (2) an attacker can gain web access to your intranet. We've come across a firewall configured this way, and it allowed us to access the company's entire intranet.

You can check whether your firewall is vulnerable by changing your browser's proxy settings to point to the suspected proxy firewall. To do this in Netscape, perform the following steps:

Select Edit Preferences.
Select the Advanced and Proxies subtrees.
Check the Manual Proxy Configuration button.
Select the View button.
Add the firewall in question in the HTTP address and select the port it is listening on. (This is usually 80, 81, 8000, or 8080 but will vary greatly; use nmap or a similar tool to scan for the correct port.)
Point your browser to your favorite website and note the status bar's activity.

If the browser's status bar displays the proxy server being accessed and the web page comes up, you probably have an unauthenticated proxy server.

Next, if you have the IP address of an internal website (whether its address is routable or not), you can try to access it in the same manner. You can sometimes get this internal IP address by viewing the HTTP source code. Web designers will often hard-code hostnames and IP addresses in the HREFs of web pages.

Unauthenticated External Proxy Access Countermeasure

The prevention for this vulnerability is to disallow proxy access from the external interface of the firewall. Because the technique for doing this is highly vendor dependent, you'll need to contact your firewall vendor for further information.

The network solution is to restrict incoming proxy traffic at your border routers. This can be easily accomplished with some tight ACLs on your routers.

WinGate Vulnerabilities

The popular Windows 95/NT/2000 proxy firewall WinGate (http://www.wingate.com) has been known to have a couple of vulnerabilities. Most of these stem from lax default parameters, including unauthenticated telnet, SOCKS, and Web. Although access to these services can be restricted by user (and interface), many simply install the product "as is" to get it up and running forgetting about security.

Unauthenticated Browsing

Popularity:	9
Simplicity:	9
Impact:	2
*Risk Rating:*	7

Like many misconfigured proxies, certain WinGate versions ( specifically 2.1d for Windows) allow outsiders to browse the Internet completely anonymously. This is important for attackers who target web server applications in particular, because they can hack to their heart's content with little risk of getting caught. As a general rule, you have little defense against web attacks, because all traffic is tunneled in TCP port 80 or encrypted in TCP port 443 (SSL).

To check whether your WinGate servers are vulnerable, follow these steps:

Attach to the Internet with an unfiltered connection (preferably dial-up).
Change your browser's configuration to point to a proxy server.
Specify the server and port in question.

Also vulnerable in a default configuration is the unauthenticated SOCKS proxy (TCP 1080). As with the open Web proxy (TCP 80), an attacker can browse the Internet, bouncing through these servers and remaining almost completely anonymous ( especially if logging is turned off).

Unauthenticated Browsing Countermeasure

To prevent this vulnerability with WinGate, you can simply restrict the bindings of specific services. Perform the following steps on a multihomed system to limit where proxy services are offered :

Select the SOCKS or WWW Proxy Server properties.
Select the Bindings tab.
Check the Connections Will Be Accepted on the Following Interface Only button and then specify the internal interface of your WinGate server.

The Real Treat for the Attacker: Unauthenticated Telnet

Popularity:	9
Simplicity:	9
Impact:	6
*Risk Rating:*	8

Worse than anonymous web browsing is unauthenticated telnet access (one of the core utilities in the hacker's toolbox). By connecting to telnet on a misconfigured WinGate server, attackers can use your machines to hide their tracks and attack freely .

To search for vulnerable servers, perform the following steps:

Using telnet, attempt to connect to a server.

If you receive the following text, enter a site to connect to:

 [root]#  telnet 172.29.11.191  Trying 172.29.11.191... Connected to 172.29.11.191. Escape character is '^]'. Wingate>  10.50.21.5

If you see the new system's login prompt, you have a vulnerable server. Here's an example:
```
 Connecting to host 10.50.21.5...Connected SunOS 5.6 login: 
```

Unauthenticated Telnet Countermeasure

The prevention technique for this vulnerability is similar to the "unauthenticated browsing" vulnerability mentioned earlier. Simply restrict the bindings of specific services in WinGate to resolve the problem. You can do this on a multihomed system by performing the following steps:

Select the Telnet Server properties.
Select the Bindings tab.
Check the Connections Will Be Accepted on the Following Interface Only button and then specify the internal interface of your WinGate server.

File Browsing

Popularity:	9
Simplicity:	9
Impact:	9
*Risk Rating:*	9

Default WinGate 3.0 installations allow anyone to view files on the system through their management port (8010). To check whether your system is vulnerable, run all the following:

 http://192.168.51.101:8010/c:/ http://192.168.51.101:8010// http://192.168.51.101:8010/..../

If your system is vulnerable, you'll be able to browse each file in the directory and navigate in and out of directories at will. This is dangerous because some applications store usernames and passwords in the clear. For example, if you use Computer Associates' Remotely Possible or ControlIT to remotely control your servers, the usernames and passwords for authentication either are stored in the clear or are obfuscated by a simple substitution cipher (see Chapter 13).

File Browsing Countermeasure

Upgrade to the current version of WinGate at http://www.wingate.com.