Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

External service interaction (DNS & HTTP) Not Replicable on Personal Server

Duarte | Last updated: Jan 11, 2019 03:02PM UTC

Hello, While reviewing a web application for a client, Burp audits identified both External Service Interaction (DNS) and External Service Interaction (HTTP) in multiple links and parameters. Going after this because it was interesting, I tried to replicate using the Burp Collaborator client (generating payloads, replacing them on the requests identified and polling the collaborator server) and successfully replicated the behavior. However, when I switched Collaborator's payload with a personal server's URL and while observing the log of all the incoming requests, no DNS nor HTTP request showed up. I haven't found any documentation in this regard, so I'll be really glad if you can help me as my client is asking me for a justification of this behavior and for me it doesn't make much sense. Thank you for your help.

PortSwigger Agent | Last updated: Jan 11, 2019 03:02PM UTC

Thanks for letting us know about this. It sounds like your personal server is not accessible from the target application. Perhaps you are using a self-signed SSL certificate, and the application requires a valid certificate? Please try your personal server's URL from your web browser and check the log. Try running tcpdump, then retry the issue on the application - you may see a failed SSL handshake. I wouldn't expect to see DNS requests on your personal server, you need to have your domain set up to redelegate for that to happen.

Burp User | Last updated: Jan 11, 2019 03:42PM UTC

Thanks for your quick reply. My personal server has a Let's Encrypt certificate. Just an update on my status, I don't have access to the application. I am testing from an outsider perspective. Just let me know what more you think it can be causing this different behavior. Thank you again for your time.

PortSwigger Agent | Last updated: Jan 11, 2019 03:43PM UTC

Please do try using tcpdump to see if there's any traffic. If you'd like us to investigate further, please send screenshots of the request/response and Collaborator interactions to support@portswigger.net

Burp User | Last updated: Jan 15, 2019 05:06PM UTC

Hello again, I tried your suggestion (using tcpdump in my server and try again in the application) but I am not receiving any communication from my client's application. Do you have any more information about this behavior (from other cases maybe) that you can share? Thanks again for your help.

PortSwigger Agent | Last updated: Jan 16, 2019 09:31AM UTC

Hi Duarte, Thanks for trying that. I can't remember any other user having encountered this. Collaborator isn't particularly different to any other web server, and the long interaction IDs make false alerts unlikely. I suspect that something is wrong with the web server you have set up, or the payload you have used. You didn't send screenshots of the Collaborator interactions, but I suspect there's evidence within them that the connections are genuine.

Burp User | Last updated: Jan 16, 2019 10:03AM UTC

Hi Paul, I didn't send screenshots because I don't have my client's authorization to share. Regarding the personal server I can access it through my usual web browser and it registes the accesses in the logs. So the only thing that might be happening is my payload being wrong. However, I chose a request which worked thourgh collaborator and replaced the <target>.burpcollaborator.net string by my server's URL. Thank you again for your quick replys and your attention.

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