Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

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

Duarte Gonçalves 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.


Paul Johnston Jan 11, 2019 03:15PM UTC Support Center agent

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.


Duarte Gonçalves 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.

Paul Johnston Jan 11, 2019 03:45PM UTC Support Center agent

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


Duarte Gonçalves 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.

Paul Johnston Jan 16, 2019 09:36AM UTC Support Center agent

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.


Duarte Gonçalves 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.

Post Your public answer

Your name
Your email address
Answer