Last week, James Kettle from PortSwigger, creator of one of the must-have security tools Burp Suite, spoke at Black Hat USA about “Cracking the Lens: Targeting HTTP’s Hidden Attack-Surface.” This awesome talk looked at how to gather information on backend systems behind the network and security stacks such as load balancers and CDNs.
The idea is that if, for example, you get the IP address of a web application that’s protected by a cloud-based web application protection such as Incapsula, you can bypass the web application protection and directly attack your victim. At Incapsula protecting against that is part of the process when we onboard clients. I’ll discuss this in detail under the section “I’m an Incapsula customer – what should I do?”.
This attack, and other similar attacks, may be done using the Burp Collaborator module of Burp. Burp Collaborator allows you to check web applications by injecting URLs “all over” the HTTP protocol. This includes headers, specific cookies, addition to headers, parameters, and URLs, and does it in many ways, for example by adding the URL, adding it as a network address, or as an SQL command. The goal is to see if you’re getting any reply from those attempts, and know from which attempt the data leaked. This lets you find injection points and out-of-band injection points such as by sending a URL to a backend system which then contacts that URL. This may let an attacker get information such as the IP address of the service that contacted him, as well as perform attacks such as SSRF.
The Host Header and What We Do with It
When a client sends a host HTTP header to Incapsula such as Incapsula-customer.com for example, we use that to know which client we need to send the traffic to.
According to the HTTP 1.1 Protocol RFC, when sending traffic to a custom port, the host header should include the port, delimited by a colon from the hostname.
Suppose a client is sending traffic to the host Incapsula-customer.com over port 8888, the client should send:
Host: Incapsula-customer.com:8888
When our reverse proxy servers at Incapsula are receiving this, they ignore the port altogether. If the host belongs to an Incapsula customer, we inspect the traffic, perform all the magic that we do such as security, bot detection, caching, and apply application delivery rules. Then if all is well and verified as not an attack we proxy the HTTP request to the client.
Kids, Beware of the Big Bad @
If a client sends a host header, they may add undesired content after the port. If that content is an attack such as an SQL injection or remote code execution, it will be blocked by our security engine. However, if it’s not, it will be forwarded to the client. In this case, suppose a client sends the following HTTP header:
Host: Incapsula-customer.com:8888@test.incapsula.com
The host header will be sent as is to the client, as it has no attack signature. Then, if under any circumstances, the customer’s backend takes this host and treats it as a username:password@URL uri (such as root:Aa123456@mysystem.com), it will send this from the backend IP address, exposing it to the attacker.
Under What Circumstances Does That Happen?
We didn’t do a thorough research about this, but couldn’t actually find a situation where this actually does try to resolve the host header when it gets such a request. But it’s possible that some systems may do that.
Mitigation
So, getting the information about this attack vector was “out-of-band” for us in terms of the vulnerability response procedure. It did not come from our vulnerability response process where we track new vulnerabilities constantly. We got this information when it went public in Black Hat. In the night between Thursday and Friday (July 27th and 28th) we researched this, and set a silent rule to run on Incapsula CDN for several hours. This is our vulnerability response process that lets us inspect a rule without actually blocking global traffic and prevent false positives.
One may wonder why we would even bother to run this silently, as sending an extra @ after the port is a violation of the RFC (God forbid). From our experience, when protecting 100,000s of web applications, not everybody follows the RFC, and we can’t just block legitimate traffic for clients who are not sending HTTP traffic according to RFC.
After those few hours, we moved this mitigation to blocking mode. The only attack we observed was a self-generated one we did to test the mitigation on live production traffic:
Ever since we issued this mitigation, we haven’t seen anyone trying to use it.
I’m an Incapsula Customer – What Should I Do?
Nothing specific, any attempts like that will be blocked. Well, there’s one thing you should do as part of the onboarding to Incapsula, and if you haven’t done it – now’s the time. You should block all external IPs on your firewall except for Incapsula IPs, so all traffic to your web application must go through us. You can find this in our knowledge base page.
What If I Find a Vulnerability in Incapsula?
Please contact us ASAP if you even think there might be a vulnerability in our systems. We will promptly get on top of it. Although we do not have a bounty program, we will try sending you some cool swag!
Bottom Line
Although we find the risk of this to be very low we decided to go for an emergency configuration upload to be on the safe side. As a reminder, Incapsula security content is updated almost daily to add new protection against the ever-changing web threats.
I’m also taking this opportunity to plug our team: We’re looking for more researchers and innovation developers for our research group. Read more here.
Try Imperva for Free
Protect your business for 30 days on Imperva.
