This post is the second of a short series of posts that we have dubbed “Attack Surface Mapping the Wrong Way”, showing the wrong way that people/companies/vendors attempt to do attack surface mapping. Read the first in this series here. Next up is brute force and why it is the wrong way.
Brute force alone is flawed
When Jeremiah Grossman and I first started in information security, there really was no way to find a company’s assets other than going to their main homepage and surfing around, hoping to find assets that were linked. It was an extremely error-prone and entirely manual process. There were a few scripts that attempted to crawl the site looking for links, but that is about it.
Enter fierce.pl – a DNS enumeration tool that I wrote in the early 2000s. Fierce was designed to ask the primary DNS server of the company in question a few different things:
- Will you please hand over all the DNS records for the domain (E.g., example.com) in question (this is known as an AXFR query or a “zone transfer”)? If so, we are done.
- If not, will you please tell me if this weird long string (E.g., 1239hkjlah98h1th0h.example.com) resolves? If so, I know that you are using a wildcard, and I cannot trust the results you give me. So, if that string resolves with “123.123.123.123,” for instance, ignore any future results that reply with that IP address because they too are likely wildcard.
- Now, going down this dictionary list of probable subdomains, will you please tell me if any one of them resolves? This is what we call a “DNS brute force” enumeration technique.
- Going up and down the IP range for any IP addresses found in step 3, do a reverse DNS and see if any of those subdomains match the domain in question.
Fierce was extremely powerful for the time because it would use a series of questions and illicit a very rapid (by those day’s standards anyway) response, and it would do so in a way that did not make a lot of noise or cause any service disruptions. Most importantly, it could be done without asking the company in question anything.
That meant, as a penetration tester or an attacker, they could quickly enumerate the bulk of the primary subdomains in question for any given domain. That was a huge shift forward for external exploitation. Starting with an up-to-date asset list, the penetration tester or the attacker could begin running their exploit code against a much greater set of known hosts.
That solved a problem that I had at the time as a penetration tester, but it always felt very clunky, slow, and error-prone. I did not have much choice, though, because there were not a lot of options that were available to me with the limited resources I had at the time. It worked well enough to impress companies, but I knew it was not ideal in the back of my mind.
As advanced as it was at the time, Fierce and subsequent similar, somewhat more advanced knockoffs like sublist3r, subbrute, amass, nmap’s dns-brute library, and so on all had some significant flaws.
- Brute force is slow: For a domain with 100’s of thousands of DNS entries associated with it, Fierce would take just over 24 hours to run. That may not seem that slow, but if a company has dozens, hundreds, or thousands of domains, you could be waiting a very long time. The name of the game is often speed, so relying upon such incredibly slow code to run never made much sense. It was just the best we had at the time. There have been some improvements to tools since Fierce that take advantage of multi-threading, but it is still far too slow of a technique due to memory/bandwidth limitations.
- Brute force misses correlated domains: If you searched for ebay.com, it would not find rent.com. That may not seem like a big deal, but often the worst issues fall on other domains rather than the primary because no one is focusing their security efforts there. So, from an external attacker’s point of view, those other domains are often the juiciest targets. Once in, it is easy to pivot around.
- Brute force cannot go back in time: Brute force attacks are ad-hoc and only work the second you run them. But if you believe something happened in the past, there is no way to go backward and ask the question about historically what has happened with this domain or subdomain in question. That is especially important when talking about 0days where you want the data from yesterday to speed things up; you don’t want to wait around for hours or days to find out what’s going on today. The slightly lower resolution of data is totally acceptable in emergency situations when speed is the major issue at hand.
- Brute force does not stay up to date: From an asset management perspective, DNS brute force is only mildly useful because it must be run over and over to have any hope of staying up to date. That means running thousands or tens of thousands of queries against every domain in your inventory if you want to have any chance. Running a single Fierce scan will not set off alarm bells most of the time but running hundreds or thousands of them on an ongoing basis could theoretically get into the realm of inadvertent denial of service through server/memory congestion. Thankfully, DNS packets are small, and DNS lookups do not take up much memory, but in aggregate, it can add up, especially if parallelism is used.
- Brute force relies on wordlists: Wordlists like “dev” and “test” will find a lot of assets, sure, but it will not find obscure asset names like “qa-testing-albuquerque-90118-noc-3”. Likewise, English dictionary words will not find words in other languages. You can use some sorts of statistical representations of most common server names to get close, but you are always limited by the questions you know to ask. And the longer the list you make, the more likely you are to be noticed, and it can add an enormous amount of time.
Brute force can certainly be a part of an overall strategy of finding assets, without a doubt. But using it as the primary and only method of keeping an asset inventory up to date is incredibly error-prone – take it from me, the guy who wrote one of the very first DNS enumeration tools ever. I still like and use brute force, and Bit Discovery takes advantage of it, but only as a fallback for when other methods prove to give incomplete data. In an ideal situation, DNS enumeration should show you the same data as every other technique does. Still, there are a wide variety of reasons those datasets don’t perfectly overlap, which we’ll be discussing in future blog posts.
To re-iterate, DNS brute force should be a component, not the entirety of a good attack surface mapping technology. If you or your vendor are using it in a vacuum, you are quite likely missing an enormous amount of assets.
Want to talk about the right way to do attack surface management? We’ll show you. Get in touch with us here.
