Geo-Distributed Bug Bounty Hunting
GeoDNS is a technology that allows entities to deliver content to users from servers closest to the requesting user geographically.
GeoDNS is one of the first technologies that a bug bounty hunter may unwittingly encounter when attempting to conduct a bug bounty campaign. Utilizing a geo-distributed cluster of machines enables bug bounty hunters to gain a better understanding of their target attack surface and enables them to map it more accurately.
By running simultaneous and duplicate scans from multiple geolocations, attackers can see if a target organization is routing traffic to different servers across the globe based on a requester geolocation.
Furthermore, by repeating these scans on a regular basis and diffing the results, attackers can more accurately map a target as new services come online.
Bug bounty campaigns are truly a function of time equals money. The more time you spend looking at a bug bounty campaign, the more you need to earn in order to make the time spent worth it.
This means that the more that can be automated and the greater your ability to discover and intelligently parse an attack surface, then the better your chances of finding qualifying bugs while also reducing your time spent. Even with a solid methodology though, there is a major transparent issue that most bug bounty hunters will face at some point, which is a GeoDNS configuration.
Attempting to map the attack surface of a GeoDNS configured target without shifting the attacker's location either by proxy, VPN, or some other means, will result in a failure to identify all assets owned by the target organization.
What is GeoDNS?
GeoDNS for the purpose of this article can be summarized as routing a request to the geographically nearest server to the requester that can respond with the requested information.
This is not a recent technology and is supported by most major cloud-based platform providers today.
For example, Azure Traffic Manager offers a routing service called "Geographic" which does exactly what is stated above. This geographic service (see Figure 1 below) can route a request to different endpoints based on the sources' geographic location.
GeoDNS was developed as a patch for Berkeley Internet Name Domain (BIND) DNS.
Developed by Berkeley in the 1980s, and originally funded by a DARPA grant. BIND is software designed to interact with the Domain Name System (DNS).
It is important to note that geographic DNS handling was never intended to be a security measure. The purpose behind it has been and still is to speed up the experience for the end user, offer redundancy when regions go down, offer a compliance solution for data regulatory requirements, and provide localization of content for end users.
Bypassing GeoDNS
Geographic DNS handling is not terribly complex to bypass.
As already stated, it was never meant to be a security mechanism. It is merely something that bug bounty hunters need to contend with.
There are multiple ways to bypass GeoDNS. Attackers can use a proxy server, a VPN, or, as I am going to outline here, a cluster of geo-distributed machines.
Without taking the time to bypass GeoDNS, bug bounty hunters are potentially missing outdated and vulnerable servers that are in scope but outside of the attacker's region. Even if a VPN or proxy is used, it is difficult to iterate between regions to rerun extensive and time-consuming scans repeatedly.
Making the Case for a Geo Cluster Attack Platform
As previously stated, bypassing geographic DNS is trivial, but to do it consistently, quickly, and automated is an order of magnitude more complex.
This is because of the existing options; there is no straightforward way to pivot around the world. It requires VPNs in the geographic region you are targeting as well as the ability to pivot between them consistently. It also requires that you run the same commands against your targets in the same order so that you can juxtapose the regional results.
Proxies can also be configured to do this but once again, this requires proxies in the region that you are targeting. If you are using public proxies, they are notoriously unreliable, not to mention the other issues that could go along with running attacks through machines you do not control.
This brings me to the heart of this article, which is maintaining a global cluster of machines through which you can proxy commands in an automated and repeatable fashion.
Bug bounties are once again a function of time equals money.
Also, since bug bounties are legally authorized by the target entity, the focus can truly be on the target and mapping the attack surface. There is no real requirement to use technology like proxy chains to make it difficult to track attacks back to you.
The only primary concern attackers should really have in their bug bounty campaigns is not launching them from a home network and remaining in scope. This is because content delivery network tools like Akamai and Cloudflare will ban the source IP address if they detect malicious payloads being launched against their customers.
Getting your home IP address flagged by one of them means you will have a challenging time using the Internet for day-to-day things. This is where the power of using a VPN or proxy server is key.
The above diagram shows the proposed cluster setup.
The director can be in any region and each of the nodes would exist in a different geographic region. When the attacker issues a command to the cluster director, that command is then issued to each of the regional agents, who then resolves the DNS record and then individually runs the command.
Once this system is in place, some interesting capabilities are then unlocked.
For example, the ability to schedule reoccurring recon scans and then automatically diffing the results of the scans to see if the attack surface has changed since last scanned. This is an important thing to consider because targets of the bug bounty campaign do not exist in a vacuum.
They are often actively being developed - which means new services, test environments, or development environments may inadvertently become visible to the public Internet. If this happens and you have only run a single recon scan, then you will miss the evolution of the attack surface. This is but one of many additional capabilities we unlock by having a global attack cluster in place.
Development Going Forward
For the better part of 2022 and into 2023, I have been working on a platform that mirrors the above cluster diagram.
It is both web and mobile capable. It allows for scheduling repeated scans and attacks, as well as for automatic diffing of results with alerts when things change.
This is only a small subset of the features I plan to bring to market with this new tool. For now, most of the feature list is private as well as the repository.
Summary
Bug bounties really boil down to how fast you can find bugs so that you can get paid before the other attackers find them.
The best way to do this is by conducting methodical and comprehensive recon against targets. As companies continue to scale, they will ever increasingly use geographic DNS to improve the experience for their customers.
The only way to accurately map the attack surface of these companies is by bypassing their geographic DNS systems. Though other mechanisms do exist to do this, it is laborious and often time consuming to do this with existing solutions.
This article has demonstrated that by creating a globally distributed cluster of attacking machines, bug bounty hunters can not only get a comprehensive view of a target's attack surface, but also do it in a quick, repeatable, and methodical way.