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.
This is the second use case of this vulnerability. If you missed the first one, click here.
This use case is a modified real-world example discovered at a client. After performing an active scan of the client, several instances of External DNS and HTTP Interaction began to appear. However, many of these instances were being called from unique IP addresses from wildly different networks – none of which came from the client. In addition, there appeared to be no impact within the tested application to import the HTTP content of the Burp Collaborator server or behave in any different way. The only thing that was in common was all parameters had the ‘Referer’ header be the source of the issue.
After performing reconnaisance on the received IPs (using Internet searches, whois requests, etc), it was possible to determine several of the networks belonging to these IPs. The one in the example above belongs to Cisco Ironport’s Division as we can tell by the following whois request:
$ whois 68.232.128.22 % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.arin.net inetnum: 68.0.0.0 - 68.255.255.255 organisation: ARIN status: ALLOCATED whois: whois.arin.net changed: 2001-06 source: IANA # whois.arin.net NetRange: 68.232.128.0 - 68.232.159.255 CIDR: 68.232.128.0/19 NetName: IRONPORT-DH NetHandle: NET-68-232-128-0-1 Parent: NET68 (NET-68-0-0-0-0) NetType: Direct Assignment OriginAS: AS16417, AS30238, AS25605, AS30214, AS30215 Organization: Cisco Systems Ironport Division (CISL-7) RegDate: 2009-02-26 Updated: 2018-08-15 Comment: THIS ADDRESS SPACE IS STATICALLY ASSIGNED Ref: https://rdap.arin.net/registry/ip/68.232.128.0 OrgName: Cisco Systems Ironport Division OrgId: CISL-7 Address: 170 West Tasman Drive City: San Jose StateProv: CA PostalCode: 95134 Country: US RegDate: 2010-11-09 Updated: 2018-08-15 Ref: https://rdap.arin.net/registry/entity/CISL-7 Cisco Ironport (similar to Trend Micro’s service in Part 1 ) is a service that provides analysis and protection frameworks either via email or IPS-like services. In this case, Cisco Ironport was reviewing the ‘Referer’ header of all incoming requests and determining if the origin was a legitimate source or should be categorized as a malicious site.
Other IP addresses that had reached out to the Collaborator server include various tracking and advertising services. These services view the ‘Referer’ header to determine what type of visitors are viewing the site and to either record that for analysis at a later time or to use the information to fine tune the advertisements that show on the website.
This collection of exposed IP addresses presents a rather unique way of fingerprinting previously unknown technologies that are potentially protecting the application or providing a different service that can be exploited. For example, when visiting the page directly, it may not be possible to determine that Cisco Ironport is protecting the page. However, with the above method (and a little bit of patience), we can determine as testers (and attackers) to tune our specific tests to avoid Cisco Ironport defenses or develop attacks to stay off their radar.
Here is a flowchart showing how this scenario’s fingerprinting process would work:
In an effort to reduce any exposure of third-party services within your environment, you will want to investigate how many of these services function. Some security appliances actively attempt to identify all unknown connections that flow through them via HTTP calls to unknown sites, while others only view the contents of the request and make their pass/block determination. If it is a matter of keeping the protection mechanisms of your web applications a secret, try to find a security appliance that is less chatty.