External Service Interaction through DNS or HTTP is one way to identify out-of-band server interaction vulnerabilities (issues where the server will respond to something other than your testing computer).
This blog post will dive into the topic of out-of-band server interactions to fingerprint services that protect networks and web applications. This includes advertiser platforms, intrusion prevention systems (IPS), web application firewalls (WAF), and the like. If you need a primer on the base vulnerability, please check out the Portswigger documentation at the following links.
- https://portswigger.net/blog/introducing-burp-collaborator
- https://portswigger.net/kb/issues/00300200_external-service-interaction-dns
This is one interesting case I have identified:
ASUS Router and Trend Micro Integration
The first example occurred in my testing source network. While testing various web applications, I kept receiving External DNS Interaction issues in my Burp scanner results while testing various and seemingly unrelated web applications. Another peculiar thing that kept occurring was the timing of the interaction – it would often happen 15 minutes to 4 hours after the initial scan. However, I would have trouble replicating the issue as it was not showing up reliably after attempting to manually verify it.
When diving into what source IP was accessing the Burp Collaborator server, I got a random AWS IP address of 34.223.45.138 and no readily identifiable way to determine who it belonged to.
As it was a matter of scan efficacy (and to stop sorting through potential false positives), I tried to dive into the issue to discover what component was causing the issue. The only components that were similar to all of these External DNS Interaction issues was my computer, LAN, WAN link, and any potential internet facing services in use by my ISP such as DNS.
Here were the troubleshooting steps I went through before discovering the final issue (for which I’ll go into more detail):
- Did my computer have any AV software or other service to call out to the Burp Collaborator server? I tried from a couple different computers and OS’s (Mac, PC, Kali Linux) and the External DNS Interaction hits were happening. This leads me to think it was not a computer issue.
- Were there any LAN issues such as an DNS or automated services also inspecting my traffic? My testing network was pretty simple and does not have extra equipment on it, but I tried changing my DNS from the ISP provided DNS to other providers such as OpenDNS and Cloudflare. I still was experiencing the same issue.
- However, I got logged into my testing router and discovered the root cause…
I use an ASUS RT-AC3200 router for my testing network. While it may not the powerhouse of some other newer routers, it has a fairly comprehensive set of features and works alright for doing web application testing. One of built-in features, called AiProtection, performs a malicious site check and other basic intrusion prevention system functions.
AiProtection uses Trend Micro to power much of the data behind the functionality. When this feature is turned on, the router will send the data to Trend Micro to verify whether sites that traverse the router are malicious or not. If it encounters an unknown site, Trend Micro’s server will send a request to attempt to identify the web content and give it a risk rating (according to this support article at https://www.asus.com/support/FAQ/1008719).
In this case, my ASUS router was inspecting my traffic, sending the unknown Burp Collaborator URLs to Trend Micro, and triggering the Trend Micro servers to do a lookup of my Burp Collaborator URLs during my scan. Once I turned off the AiProtection feature, the unknown sources of DNS and HTTP requests stopped. Without this fingerprinting method, I would not have identified that my router was inspecting all of my outbound traffic.
Here’s a small flow chart showing how the fingerprinting process works:
On a side note, if you’re paranoid about features inspecting your outbound traffic, you may want to investigate your router and identify if these features are enabled.
Stay tuned for another example in an upcoming blog post! [EDIT – Part 2 is here]