Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

More info on "External service interaction (DNS)"

Davide | Last updated: Jul 31, 2017 03:07PM UTC

While reviewing a web application, I got the "External service interaction (DNS)" issue. I googled for it and I got a grasp on what it could be possibly be, but I'd wish to have some suggestions on how to create a valid POC for this issue. In the vulnerable header I tried to put my own server IP, while observing the log of all the incoming requests. Sadly nothing showed up. Am I missing anything? Is there anything I can do to create a valid POC or it's simply not vulnerable at all? In this case, the endpoint could be used to create some kind of DOS attack to another server or it's a too far remote possibility?

PortSwigger Agent | Last updated: Aug 01, 2017 07:02AM UTC

Hi, Thanks for your inquiry. External service interaction isn't always a vulnerability, but it does indicate behavior that would be interesting to investigate further. For example, there are some variants of SSRF that do not cause an HTTP interaction because of firewall rules. But DNS interactions allow testers to detect the issue, and they can be manually exploited to access private services behind the firewall. To reproduce a DNS interaction you must use a domain name, not an IP address. If you have control of DNS for a domain, you can setup delegation of a sub-domain to a DNS server that you control, and monitor the traffic using tcpdump. Alternatively, you can use the Burp Public Collaborator. With Burp, go to Burp Menu > Generate Collaborator Payloads. This lets you generate payloads that you can use in manual requests, and poll to see if there have been interactions,. Please let us know if you need any further assistance.

PortSwigger Agent | Last updated: Aug 01, 2017 07:11AM UTC

Hi Marco, Thanks for your message. I'm struggling to understand your situation. Can you email support@portswigger.net with some screenshots of the issue that Burp reported, and your attempts to replicate it?

Burp User | Last updated: Sep 07, 2017 10:07PM UTC

Hello, I have the same problem. I have my own server and domain name. Burp Collaborator is working. DNS and host IP information seems for vulnerable website. But I can't see on my own server. I listen to port(80 and others, interface) with tcpdump, netcat etc. I haven't found any documentation in this regard, i'll be glad if you can help me. Thanks.

Burp User | Last updated: Jun 26, 2019 08:16AM UTC

Hi, I am having the same problem as posted here. I am getting External Service Interaction(DNS) issue in scan report but I see no dns lookups occurring when I listen to port 53 udp using tcpdump. I am running a native server application in debian. The scan report says "The payload u72x15172vaxayb9exobisogf7l29v8jy6oud.burpcollaborator.net was submitted in the SSL SNI value and the HTTP Host header." I've tried aborting SSL handshake in my server if the SNI value contains "burpcollaborator" string and also tried denying HTTP response if the HTTP GET request "Host" header contains "burpcollaborator" string. Any suggestions?

PortSwigger Agent | Last updated: Jun 26, 2019 10:13AM UTC

Hi Kiran, Thanks for following up. If you run tcpdump on your Collaborator server, then have Burp trigger the interaction, can you see the interaction within Burp? Can you see it in tcpdump? It's possible your TCP dump filter is wrong, so this will help you verify it. If you're trying to manually trigger the issue, the problem is likely to be around the SNI value, which is not easy to configure in Burp. The way to do it is to set the target hostname in Repeater to be the SNI value you want. Then you need to use Project Options > Connections > Hostname Resolution to unsure this value will resolve to the correct target IP address. This should allow you to manually trigger the interactions. If it' doesn't work, please experiment with a variety of setups as there's a lot of moving parts.

Burp User | Last updated: Jun 28, 2019 02:17PM UTC

Hi Paul, Thanks for the reply. I checked outgoing packets from colloborator server using wireshark and I see Server Hello message containing the SNI value during SSL handshake. But in my server application I abort any incoming SSL handshake with SNI value different from my domain name. I've tried manually sending requests using Repeater with the SNI value generated from burp colloborator client payloads and checked for poll colloborator interactions. Also tried setting the right Hostname resolution in Project options as you've mentioned. But could not reproduce the issue. I've changed DNS server in my server application to some invalid IP, so no dns lookups can occur. But still I am getting external service interaction in scan report. How can my server resolve a domain name when the DNS server is set to some random IP. Is this a false positive?

Rose, PortSwigger Agent | Last updated: Jul 02, 2019 12:32PM UTC

Hi Kiran The DNS interaction is occurring somewhere in your infrastructure. Given your debugging steps, it seems likely that this is something in front of your server application.

Burp User | Last updated: Oct 03, 2019 07:58AM UTC

Hi When sending request in Repeator target responses 403 code. I don't know what means this ?

Liam, PortSwigger Agent | Last updated: Oct 03, 2019 11:12AM UTC

HTTP 403 is a standard HTTP status code communicated to clients by an HTTP server to indicate that access to the requested (valid) URL by the client is Forbidden. Do you have access to the application?

csh | Last updated: Mar 25, 2020 03:42PM UTC

Figured i would share my findings thus far. First we had to set up a NS server under our control to really see whats happening. After hours of testing, it's looking like there may be some kind of SNI/HTTPS inspection and/or monitoring going on. Running external openssl client tests, off our internal network, did not show this behavior in our case. SNI/HTTPS monitoring is common in firewalls and you can find a lot of docs on it. There is a nice diagram in this (old) paper showing an example of the flow (Fig.4: Client SNI verification using DNS) https://hal.inria.fr/hal-01349710/file/SNI_HTTPS_Security_Monitoring.pdf Hope this helps :)

Liam, PortSwigger Agent | Last updated: Mar 26, 2020 11:28AM UTC

Thanks for the update!

csh | Last updated: Mar 26, 2020 03:53PM UTC

Passing thought: Consider mentioning possible firewall SSL/SNI inspection somewhere in the Issue background details? Might be helpful and time saving for anyone having to research the issue that not be familiar with the technique. Certainly would have saved us a lot hours. :)

Liam, PortSwigger Agent | Last updated: Mar 27, 2020 02:55PM UTC

Thanks for the input. I'll pass on your message to the research/scanner teams.

PortSwigger Agent | Last updated: Mar 30, 2020 08:36AM UTC

There's a huge number of things that could cause a DNS interaction so we can't plausibly enumerate them all, but I'll see if I can add some wording/methodology to isolate some of the less-obvious culprits.

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