Despite billions being spent on security, many organizations continue to fail miserably in preventing information leakage through their corporate proxy servers and web gateways. In most cases, the reason is that people are unaware of how the underlying technology and protocols operate nor which features should be enabled or disabled.
Below you will find guidance on two of the most common ways in which information is unwittingly leaked by corporate proxies. If you want the answers immediately without the commentary, jump to the The Real Meat of the Post. Better yet, browse to our Proxy Testing Tool to see if your proxy is leaking information onto the internet.
Proxies and web gateways are wonderful pieces of technology which make easy work of giving many users access to the internet via a single connection. In the case of web gateways, in addition to providing internet policy control, caching and network address translation (NAT), many are configured as anti-malware scanning devices. Sadly though, proxy and web gateway effectiveness is only as good as the people configuring them.
While a “Click-Next” installation experience and a nicely polished user interface are an administrator’s wet dream, they tend to hide many of the product’s more advanced features from immediate view.
The size or maturity of the organization doesn’t seem to matter either. Whether it’s a mom and dad operation or a 200,000+ employee multinational, it seems that the moment internet access is established all configuration and customization activity grinds to a screeching halt on account of disrupting the said internet connectivity. And while a “Click-Next” installation experience and a nicely polished user interface are an administrator’s wet dream, they tend to hide many of the product’s more advanced features from immediate view.
Most organizations are well versed in protecting information leakage by way of documents and emails e.g., intellectual property, financial data, corporate strategy. However, organizations struggle to understand that Advanced Persistent Threats (APT) are also interested in learning and understanding technical aspects of their infrastructure. Understanding the architecture of the network, for example, may aid the enemy in uncovering additional attack vectors.
Organizations struggle to understand that APTs are also interested in learning and understanding the technical aspects of their infrastructure to identify additional attack vectors.
Visiting a website may seem like a relatively benign activity, but when a corporate user does this through an improperly configured proxy or web gateway, in many cases they leak information. This plays straight into the hands of nefarious individuals who may use so-called “watering hole” tactics, where a legitimate website is compromised (or trojanized) in the hope that end users from a targeted organization will visit, are used as stepping stones to conduct further attacks. A typical watering hole attack goes along these lines:
One person browsing to an attacker-controlled website may reveal only a small subset of such information, but when 25% of the 200,000+ workforce do the same, the combined data points can reveal much of the internal network architecture as well as the security maturity of an organization.
A simple HTTP GET request via an improperly configured proxy can expose any number of hidden metadata to the hosting server. Although there are many proxy-related header metadata which may be stamped into a HTTP request, two header fields stand out: (1) Via and (2) Forwarded.
The “Via” header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on requests) or between the origin server and the client (on responses), similar to the “Received” header field in email. Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain. For example:
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy Via: 1.1 192.0.2.43 (McAfee Web Gateway 18.104.22.168.11234)
The “Forwarded” HTTP header field (sometimes implemented as X-Forwarded) is an optional header field that, when used, contains a list of parameter-identifier pairs that disclose information that is altered or lost when a proxy is involved in the path of the request. In the example below, the proxy is forwarding a request on behalf of a user with IP 192.0.2.43.
Forwarded: for=192.0.2.43 Forwarded: for="[2001:db8:cafe::17]", for=unknown X-Forwarded-For: 192.0.2.43
Let’s first have a look at a typical request from a properly configured proxy which does not leak any internal information.
In contrast, Figure 2 shows a packet capture in which the HTTP request headers are leaking (exposing) internal corporate information due to a poorly configured web gateway.
Although the “Forwarded” and “Via” header fields have legitimate roles to play within a hierarchical internal proxy architecture, due to the sensitive nature of the data passed in these header fields, it is recommended that they should be turned off by default on all outbound proxies and web gateways.
The following excerpt is taken directly from RFC7239 – Forwarded HTTP Extension:
The “Forwarded” HTTP header field can reveal internal structures of the network setup behind the NAT or proxy setup, which may be undesired. This can be addressed either by using obfuscated elements, by preventing the internal nodes from updating the HTTP header field, or by having an egress proxy remove entries that reveal internal network information.
And while a “Click-Next” installation may allow your organization to deploy a proxy with relative ease, keep in mind that it could also hide advanced features which, if improperly configured, may leak internal information onto the internet. Proper product training and education for your administrators are paramount to ensuring information isn’t being leaked by your supposedly “secure” infrastructure.
[Photo credit: Jason Ford — shamelessly borrowed from the Economist’s “The leaky corporation”.]
Relying on websites that the group trusts makes this strategy efficient, even with groups that are resistant to spear phishing and other forms of phishing. ^
Interesting reading and familiar sight.
Yep, I find that even very mature companies fail in this space. I think it it may have something to do with the fact that most people see proxies as devices that pull content from the internet — they don’t pay much attention to request headers, nor are periodic packet scans performed on outbound traffic to ensure device security conformance.