Abusing Reverse Proxies, Part 2: Internal Access

Introduction

As seen in Part 1: Abusing Reverse Proxies: Metadata, open proxies can allow an attacker to access cloud metadata API services. However, even without metadata services available, open proxies can be a boon for an attacker.

A primer on open proxy types:

• Forward: typical use case is allowing private network users to access the internet via a common egress point. This allows an organization to make rules for which types of internet services are accessible to users.

• Reverse: typical use case is to allow internet users access to certain services accessible to the internet via the gateway and block access to other backend systems. This is done for many reasons including load balancing, failover, security, etc., and when helps limit attack surface from the internet.

In most security scanners, open proxy checks perform basic tests to determine if they can be abused in some obvious way—primarily by connecting to a common or custom domain name. However, that methodology leaves a lot untested, including the high severity issues of being able to use the proxy to connect to other ports on itself or even hosts on the "inside" of the network.

A new batch of nuclei templates focuses on reverse proxies, which if misconfigured can allow attackers access to services on the proxy's "localhost" interface, and possibly other internal hosts. These templates focus on the following use-cases:

• Access to metadata services
• Access to the proxy's localhost interface on any port
• Access to other systems on the private network

Reverse Proxy Misconfiguration

It's easy for an application team to misconfigure a reverse proxy to allow unintended access. For example, with Apache mod_proxy a simple mistake is to allow access with this statement: <Proxy "*">. This allows proxy users access to any host via the proxy and not just the intended access.

Open Proxy: Internet

An open internet proxy could allow an attacker to abuse services in an unintended way by using the open proxy to hide the original source of the traffic. This could be abused for many reasons, including DOS attacks, spamming, scanning, or other scenarios. Nuclei has a pre-existing template for this - request-based-interaction.

Open Proxy: localhost

If a proxy allows a connection to the proxy's localhost interface (either via localhost or 127.0.0.1) it may be possible to access restricted content or services. When combined with an ability to access any port (common with a proxy which allows access to *), this can be easily used as a simple port scanner against the proxy as well.

Open Proxy: Internal

This scenario is similar to the "Open Proxy: localhost" situation, however, it allows access to other private network hosts (which can also be on any port). Using this type of situation, an attacker may be able to identify hosts/ports which can be accessed via the proxy and can be used as a rudimentary private network mapper.

Important Notes for Testing

When abusing proxies in this nature, it's important to note a few things:

• The request line in the request must be an absolute URI, as specified in RFC.
• The Host header must match the host portion of the absolute URI.

Here is a complete proxy request, for reference:

GET http://127.0.0.1:21 HTTP/1.1
Host: 127.0.0.1

Examples:

Connecting to SSH/SMTP
As mentioned previously, an improperly configured HTTP proxy can be abused to connect to non-HTTP ports. In some situations, it may be possible to create an interactive session for some services, however in most cases it will likely, at minimum, disclose sensitive information about the target services.
Here are two examples found when testing against a bug bounty target:

Abusing an Internal Proxy

Finding Hosts
Once the ability to connect to the private network through a proxy is identified, it's possible to perform both host and port discovery. The nuclei template attempts to connect to common private network IPs (such as 192.168.0.1) as well as a few common internal hostnames. If you identify a vulnerable proxy, internal host and port fuzzing can be a quicker way to find more.

Using Burp Intruder with a battering ram attack, for example, can quickly test a variety of hostnames. An additional payload set for the port can also help for discovery.

Also note that even if an open port isn't initially found, you may get proxy errors that reveal helpful information. This may help finding valid DNS entries and subsequently hunt for ports.

Pay close attention to the response codes from the proxy—these can also be used to find helpful information.

Browsing Internal hosts
Once an internal host has been identified to have an HTTP port open, a request to the root of the web server ( / )will show the raw HTML contents.

Conclusion

Almost any type of open proxy should be reported to the target client. By looking closely at the proxy's responses, a lot of information can be gained from any type of internal request and subsequent attacks can be more tailored and automated.

This concludes the two part series on open proxies. If you have further questions or ideas, please join our Discord community server or @pdnuclei