Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

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:

Image001

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:

Screenshot 2020-09-02 at 16.49.21

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:

  1. Because the traffic came from an internal address, the proxy allowed it instead of requiring authentication
  2. 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?

Latest SpiderLabs Blogs

Using AWS Secrets Manager and Lambda Function to Store, Rotate and Secure Keys

When working with Amazon Web Services (AWS), we often find that various AWS services need to store and manage secrets. AWS Secrets Manager is the go-to solution for this. It's a centralized service...

Read More

Facebook Malvertising Epidemic – Unraveling a Persistent Threat: SYS01

The Trustwave SpiderLabs Threat Intelligence team's ongoing study into how threat actors use Facebook for malicious activity has uncovered a new version of the SYS01 stealer. This stealer is designed...

Read More

Tips for Optimizing Your Security Operations Framework

Building an effective Security Operations framework that provides the right balance of people, processes, and technologies can take years.

Read More