Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

External service interaction (DNS) false positives

Chris | Last updated: Sep 11, 2017 02:19PM UTC

Hello, in the new versions of burp I am getting a huge amount of false positives of this vulnerability. In all last pentests, burp puts the payload in the HTTP request line, my machine tries to resolve this domain and finally all the instances of these DNS requests are coming from my machine. Am I doing something wrong?

Liam, PortSwigger Agent | Last updated: Sep 11, 2017 02:20PM UTC

This behaviour could be caused by Burp being configured with an upstream proxy. Are you using an upstream proxy with Burp Suite?

Burp User | Last updated: Sep 11, 2017 03:53PM UTC

My setup is Ubuntu 16.04.3 LTS, burp 1.7.27, no upstream proxy. This happens only in the new versions of burp.

Liam, PortSwigger Agent | Last updated: Sep 11, 2017 04:00PM UTC

Thanks for the additional information. A few more questions: Is it possible to send us an example of the payload? Do you have any extensions installed? Are you using a corporate proxy? Are you using any antivirus software?

Burp User | Last updated: Sep 11, 2017 04:58PM UTC

GET http://<39 character string>.burpcollaborator.net/ HTTP/1.1 Host: www.XXXXXXXX.com Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close The Collaborator server received a DNS lookup of type A for the domain name <39 character string>.burpcollaborator.net. The lookup was received from IP address <MY EXTERNAL IP ADDRESS> at 2017-Sep-04 19:38:56 UTC. This happened also with 2 JSON requests. Here is one: { "description": "http:\/\/<39 character string>.burpcollaborator.net?Admin", "parent": 1, "roleType":{ "id":"ADMIN" } } Extensions in use: WSDLer, Backslash Powered Scanner (This was loaded after the false positives) NO corporate proxy, no antivirus

Liam, PortSwigger Agent | Last updated: Sep 12, 2017 01:25PM UTC

We're not sure why that payload in appearing in that location. Can we ask which country you are located and your ISP?

Burp User | Last updated: Feb 22, 2018 10:40PM UTC

Hi, The ISP is irrelevant. When I am setting the OS DNS resolver to google, this has been resolved by google. When I set to my ISP, this is resolved by my ISP. I have this problem still in version 1.7.32. I suspect this is because I have set the scope to a subnet. So Burp tries to see if whether the altered URL belongs in scope so tries to resolve it.

Liam, PortSwigger Agent | Last updated: Feb 26, 2018 10:30AM UTC

Do you get the same results when you don't set the scope to a subnet? Do you have any extension installed on your instance of Burp?

Burp User | Last updated: Mar 12, 2018 06:53PM UTC

Hello, I'm having somewhat the same issue but with HTTP requests as well. If I run the below request through Intruder a large # of times or through the scanner, I get false positives from my own IP reaching out: GET http://<CHARS>.burpcollaborator.net HTTP/1.1 Host: www.xxxxx.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0 Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Liam, PortSwigger Agent | Last updated: Mar 13, 2018 09:01AM UTC

This behaviour could be caused by Burp being configured with an upstream proxy or antivirus software. Are you using an upstream proxy with Burp Suite? Have you tried turning off any other software that could cause this issue?

Burp User | Last updated: Mar 20, 2018 08:22PM UTC

Hi Liam, As I have stated already: NO upstream proxy, NO antivirus. Also the ISP is irrelevant. I have changed several ISPs since then (traveling) and the issue still remains.

Liam, PortSwigger Agent | Last updated: Mar 21, 2018 08:39AM UTC

Hi Chris, I was addressing Jarad with those questions. If you don't wish to use the Support Center, you can email support@portswigger.com, ensuring your issue gets it's own individual ticket. Do you get the same results when you don't set the scope to a subnet? Do you have any extension installed on your instance of Burp?

Mikhail | Last updated: May 28, 2020 03:42PM UTC

Hey there! I have the same issue now. I don't have any upstream proxy configured. When I send a request to the target system from the Burp Repeater nothing happens. When I open the payload in the browser on the same machine as the Burp I get DNS requests from my ISP's DNS server (which is Ok) and from some random IP assigned to some AWS EC2. I have checked that these IPs do not belong neither to my company's infrastructure nor to my endpoint protection provider's infra. These external DNS calls never happen when I open the payload in the browser of another machine. I also has noticed using TCPview that about the time of those DNS request appearance, my Burp instance launches a new short-lived thread that connects to some EC2. Could this be a coincident? Please check and confirm if none of your services were running 2020-May-25 between 21:38:10 UTC and 22:52:11 UTC on the following hosts: • 35.171.100.103 - ec2-35-171-100-103.compute-1.amazonaws.com • 35.170.83.209 - ec2-35-170-83-209.compute-1.amazonaws.com • 35.171.100.106 - ec2-35-171-100-106.compute-1.amazonaws.com I would appreciate also if you could share any ideas where this false positives may come from, where else I should check.

Uthman, PortSwigger Agent | Last updated: May 29, 2020 09:03AM UTC

I have replied to this on another thread asking for further details. Can you please email us with those details?

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