Compromising a Network Using an "Info" Level Finding
Anyone who has ever read a vulnerability scan report will know that scanners often include a large number of findings they classify as "Info". Typically this is meant to convey general information about the target systems which does not pose any risk.
Many people who read such reports will generally ignore all of the "Info" findings, and focus only on anything labeled "Critical" or "High". However, this can be dangerous for a number of reasons. Not only will scanners often report information that might indicate the scan was not configured correctly as an "Info" finding, but other potentially very serious risks can also be reported as "Info" findings because the scanner is unaware of the context.
So on a recent external network pentest, the vulnerability scanner flagged up a number of "Info" findings:
The most interesting findings are the discovery of open HTTP proxies. The scanner identified 3 systems that could be used as HTTP proxies, and sure enough, configuring these devices as a proxy in Firefox I was able to browse the Internet while appearing to come from the affected device's address.
Now, this is already bad enough, since an arbitrary external attacker could browse the internet using the vulnerable client's address space. Potentially this could be used to attack third parties or perform malicious activities such as spamming online forums.
But what about if instead of browsing the public Internet, you request internal addresses from the proxy? Now on a modern IPv6 network, even if you knew the address range being used by the client, enumerating it would be impractical as the smallest subnet size typically used would be a "/64" giving 18446744073709551616 possible addresses. Thankfully in this instance, the target was using a legacy IPv4 internal network giving a much smaller possible address space. It was possible to issue HTTP requests for sequential IPv4 addresses typically used for internal networks (see: RFC1918) and monitor the responses given by the proxy.
The error messages returned by the proxy were relatively helpful, for instance:
# telnet TARGET 8080
Trying TARGET...
Connected to TARGET.
Escape character is '^]'.
GET http://192.168.30.33 HTTP/1.0
HTTP/1.1 503 Service Unavailable
Server: squid/3.5.15
Mime-Version: 1.0
Date: Wed, 19 Aug 2020 05:23:26 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3446
X-Squid-Error: ERR_CONNECT_FAIL 61
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from proxy
X-Cache-Lookup: MISS from proxy:8070
Via: 1.1 proxy(squid/3.5.15)
Connection: close
(…)
<blockquote id="error">
<p><b>Connection to 192.168.30.33 failed.</b></p>
</blockquote>
<p id="sysmsg">The system returned: <i>(61) Connection refused</i></p>
(…)
Once an address was reached which was live, but did not have an HTTP service available a "Connection refused" error message was returned. While some other addresses returned various web content or authentication requests:
# telnet TARGET 8070
Trying TARGET...
Connected to TARGET.
Escape character is '^]'.
GET http://192.168.200.38/ HTTP/1.0
HTTP/1.1 401 Unauthorized
Date: Wed, 19 Aug 2020 05:27:50 GMT
WWW-Authenticate: Digest realm="192.168.200.38", qop="auth", nonce="2869c81e"
Cache-Control: no-cache
Content-Length: 2478
Content-Type: text/html;charset=iso-8859-1
X-Cache: MISS from proxy
X-Cache-Lookup: MISS from proxy:8070
Via: 1.1 proxy (squid/3.5.15)
Connection: close
It was soon possible to map out the internal network and identify a significant number of devices with HTTP services running on the default port 80.
While I was able to reach and interact with internal devices, a typical HTTP proxy has various limitations.
- You can communicate with servers that speak the HTTP protocol, using standard methods such as GET and POST.
- You may be able to communicate with arbitrary non HTTP services using the CONNECT method which is intended for HTTPS sites, however:
- This only works if the proxy does not perform SSL interception, in which case traffic is forwarded directly through to the remote end.
- Most proxies limit the CONNECT method to certain ports by default, such as 443 - the default port for HTTPS.
So given the limitation of the CONNECT method, we were basically limited to HTTP services and anything on port 443. So we went through the previously enumerated systems looking for anything that might get us further into the network.
One interesting discovery was the web interface for a Ricoh printer. This printer was accessible using the default credentials for this model of printer, and once logged in as the admin user it was possible to configure other services on the printer. One of the services offered was an SFTP server that would allow you to upload print jobs to the printer. The SFTP service uses SSH which by default runs over port 22, however as we had administrative control of the web interface it was possible to reconfigure this service to run on port 443 instead. Now we were able to use the proxy to CONNECT to the SSH service.
While this SSH service would not allow an interactive shell, it did permit port forwarding. Thus, using the "-D" option to SSH it was possible to bind a socks proxy locally which would forward traffic over the SSH connection, enabling connection to any port that the printer itself can reach. This was achieved by using the tool "corkscrew" with SSH in order to tunnel the connection over the HTTP proxy, and then the "-D" option of SSH to enable the socks proxy:
ssh admin@PRINTER -o "ProxyCommand corkscrew PROXY 8080 PRINTER 443" -oKexAlgorithms=+diffie-hellman-group1-sha1 -oCiphers=+3des-cbc -oHostKeyAlgorithms=+ssh-dss -D 1080 -N -v
The ciphers and algorithms options were required as this printer used an old version of SSH that only supported algorithms that have been deprecated in the current version of OpenSSH. Using this new socks proxy, tunneled over ssh and tunneled over the HTTP proxy it was now possible to connect to internal hosts on any port, including the standard SSH port:
$ proxychains ssh -oKexAlgorithms=+diffie-hellman-group-exchange-sha1 admin@10.6.3.2
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-127.0.0.1:1080-<><>-10.6.3.2:22-<><>-OK
Password:
In this instance, another copy of SSH is used with the "proxychains" tool to connect to port 22 of another internal device over the socks proxy created by the first SSH instance. The port restrictions of the HTTP proxy lifted, further attacks against the internal network could commence.
The story behind the open proxy.
Upon reporting the open proxy and what it could be used for, the response was "Impossible!" followed by "We have access lists on the proxy!". The proxy was supposed to be configured to allow clients coming from internal addresses to use it, and to require authentication for anything else, similar to the default configuration of some proxies:
And indeed a configuration much like this was present on the proxy, so what was going wrong?
The answer is Network Address Translation (NAT). The proxy was not directly connected to the Internet, and a firewall sat between the Internet connection and the proxy. This firewall was translating inbound connections so that what the proxy saw, was connections coming from the internal address of the firewall rather than from external addresses. This was the cause of 2 major problems:
- Because the traffic came from an internal address, the proxy allowed it instead of requiring authentication
- Because all traffic hitting the proxy came from the same address, the logs on the proxy became largely worthless as it was not possible to identify the true source of traffic.
So here we have 2 things which are often overlooked in vulnerability scans - an open proxy, and a printer with default credentials. Both of these findings are common and both are generally considered unimportant. However, with the right circumstances, these can result in a serious breach.
There are thousands of open proxies on the Internet, people routinely discover them and distribute lists of them. They are primarily used by users to hide their true source address when browsing, but how many would also allow access to internal resources?