Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

OS Command Injection FP?

Pickfordmatt | Last updated: Jan 13, 2016 05:09PM UTC

Hi all, Burp active scan has found potential OS Command Injection using nslookup as the example. I'm unable to replicate this and the IP that burp collaborator shows is from google rather than the server of which the wbapp resides on. Anyone ever seen this before? Request: message=aaaaaaa'"`0%26nslookup%20ke2pt3qow3ixymvllsb78bv5rwxsngk4cr2fr.burpcollaborator.net.%26`' Response: The Collaborator server received a DNS lookup of type A for the domain name ke2pt3qow3ixymvllsb78bv5rwxsngk4cr2fr.burpcollaborator.net. The lookup was received from IP address 74.125.44.70 at Wed Jan 13 11:07:59 GMT 2016. Thanks, Matt Pickford

PortSwigger Agent | Last updated: Jan 14, 2016 09:10AM UTC

This could well be a real vulnerability. The source IP address of DNS lookups is normally not an IP address belonging to the application, due to the distributed nature of DNS. When an app performs a lookup, this normally goes to the organization's ISP or other configured DNS server. This might then delegate the query to another server until it eventually reaches the Collaborator server. Since Google provide a free public DNS service, many people use this, which explains why the source address might come from Google. Another possibility is that this wasn't a successful command injection, but something somewhere pulled the domain name out of the payload and looked it up for some purpose. This is sometimes done by WAFs or other security products. If this is going on, you would expect to see the issue getting reported right across the application, in all kinds of different functions and parameters. It would be interesting to know if that is the case, and if so whether you can identify the component that is performing the lookups.

PortSwigger Agent | Last updated: Feb 19, 2016 09:17AM UTC

Thanks for this feedback. It would be interesting to know which component is performing the DNS lookups. Until you know that, you can't say for sure whether the findings are false positives or not. We wouldn't expect that the use of Google Analytics would explain the lookups, because interaction with Analytics is all via the client side, and the Scanner sending these requests to the server wouldn't normally result in any interaction with Analytics. It's quite possible that request data, or web server logs etc., are being processed by some back-end component (not the application server) in a way that is resulting in lookups, and you would need to understand exactly how they are being triggered to determine whether the issues are actually false positives. Any further data you can obtain and share would be appreciated, so that we can fine-tune Burp's techniques if that proves necessary.

Burp User | Last updated: Mar 22, 2016 06:42PM UTC

I have noticed quite often that I am getting OS Command injection findings with the use of Collaborator as it receives a DNS query from a Google address. Often this is occurring on AWS instances that I am testing that are not using Google DNS (although some are using Google Analytics). Packet captures looking for DNS requests on the application server do not show any such requests. In my most recent test the results came from tests that placed nslookup commands in the url directly (http://web.site/' '"`0&nslookup h2ksxqc542rsfh.burpcollaborator.net.&`' I would love to be able to give the customer more detail regarding the false positive, or to better understand where the false positive is originating, and thus be able to ask the right questions to verify it. As of right now I am having the customer place a packet capture on the application server and re-running the tests to see if the lookup originates at the server.

Burp User | Last updated: Jun 27, 2017 01:39AM UTC

We have found that the most likely reason for this in our application is that the address is going out to an email handled by gmail which is then scanning the hostname in the message and inspecting it for the security issues. The dns lookup and some http requests will get spawned from gmail security scanner.

PortSwigger Agent | Last updated: Jun 27, 2017 07:43AM UTC

Hi Oliver, Thanks for coming back with further details. We have had a few similar reports since then. Scanning of traffic seems to be increasingly common. We now have a long-term plan to perform context-based obfuscation of Collaborator payloads. We'll let you know when we make progress.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.