False Negatives in Attack Surface Mapping
June 10, 2021
Post by Robert Hansen
On occasion, there will be an asset that slips through the cracks, and there is a wide variety of reasons for it. Not all assets are made equal, so while an asset may be missed, the ones that are missed are often the least important in terms of risk, but it is also never a good idea to miss any asset if you can help it. Let us walk through some of the reasons an asset can go unnoticed.
- The asset does not belong to you. Sometimes people will find an asset critical to them that they firmly believe to belong to them. Still, for whatever reason, the attack surface map believes it belongs to another company. A straightforward example of this would be something like yourcompany.salesforce.com – do you own it or does SalesForce? Technically they own it, and you rent it, so this is a strange grey area that can be solved on a one-off basis through manually adding said singular hostname. Still, there is no perfect programmatic solution to that issue for all variants of this issue.
- The asset is internal. Suppose the asset is entirely internal or has no public route (RFC1918, for example); it may not be found because there is nothing linking to it. In that case, there are no DNS entries that are publicly available (in the case of split-horizon DNS,) or even if it is a public DNS entry, it may not be found due to not having any observable footprint. Sometimes people will use local /etc/hosts or C:/ WINDOWS/system32/Drivers/etc/hosts files, and no one will see the entries within those files except for whoever has them on their local systems.
- The asset has no DNS. In a DNS-centric world, if your asset has no DNS entry, and you do not know the IP address in question to have it monitored, it is entirely possible that no Attack Surface Mapping tool will find it.
- The asset does not use SSL/TLS. One way Attack Surface Mapping tools find assets is by using certificate transparency. If your asset does not use SSL/TLS, it will not leak that information to be collected later and is less likely to be found.
- Your DNS server is broken. The likelihood of this occurring is low, but occasionally DNS servers are just broken. In what way they are broken is not always clear. I have seen sites that absolutely blow up on long strings. I have seen others that do not respond after a few requests. If your DNS server is broken, it will stand to reason that assets may get missed. Quite often, failover pairs of DNS servers will have different zone files. If I only query one of them because the failover is rarely, if ever used, I will not see the entries on the failover.
- You just bought a company. Occasionally a paper-only transaction occurs between two business entities. While there may be a public announcement about it in the trade rags, there may be absolutely no technical changes that have taken place at all. In that case, it may be challenging to know that the assets belong to your company. This can be even more difficult if it is a stock agreement only where your company owns a large share of stock. Still, no other mechanical levers into the company exist that would give away that information to correlate the two entities.
- Your DNS entry is not RFC compliant. There is over a 1% error rate in DNS entries, which is to say about 1% of all DNS entries are invalid. That is partially due to collection issues, partially due to how flaky DNS is, but also, yes, some DNS is just wrong. Many characters are not RFC compliant. Yet, the system will pass the characters along, and the resolver must decide to drop it. A simple example would be this_is_invalid.com vs. this-is-valid.com.
- Your domain uses whois privacy. Suppose the domain is intentionally protecting its association with your other domains. In that case, it may not be found, and the assets that are associated with the domain will also not be found.
- You use round-robin DNS. Round-robin DNS means that with each request, I may get one or more different IP addresses. Just by bad luck, it can take forever to get the same result twice, and therefore, a single asset may be missed while others for the same DNS entry will be found many times. It is the luck of the draw with round-robin DNS. I can flip a coin a million times and always get heads, and I can query your DNS a million times and always not get the one IP address in question.
- The DNS goes up and down frequently. When infrastructure is ephemeral, it may be missed purely because the systems are not fast enough to manage something that only lives momentarily. This can be mitigated to some extent by using agents via the API. Still, the customer must manage it because there is no way to track that kind of behavior externally at any cadence that would not ultimately lead to cease and desist letters due to how much traffic it would require to monitor.
- It is a very new asset. If the asset just appeared, it may take some time for the system to identify its location. This can be mitigated by manually adding the asset in question via the API or via an agent.
- Your asset is hidden amongst wildcards. This can sometimes happen where all *.test.yourcompany.com DNS entries point to a singular wildcard, but you also have a testing.test.yourcompany.com subdomain, for example. In this case, a wildcard test would confirm the presence of a wildcard and would not attempt a brute force in that case, or if it did, it would need to selectively remove the IP in question associated with the wildcard. If that IP is the same, you are basically out of luck because there is no way to identify the wildcard at that point.
- There is no traffic to the site. Un-indexed websites or assets that have no users on them will not be spotted using external passive DNS sources. The more traffic to a site, the more likely it is to be spotted by some 3rd party that does passive DNS telemetry.
- It is not an asset with a dictionary name. If the asset is 180r0818.scotland04-rack41.yourcompany.com, the chances of brute forcing that name are approaching zero. Typical brute forcing uses dictionary words or very common hostnames, and if it is uncommon, the fallback of brute force will have little to no chance of finding it in situations where it is a long/unique string.
- DNS is hacked. Not the least of which is that DNS is a very flakey protocol overall, given that it is stateless and unencrypted. It is ripe for interception, modification and as my friend Dan Kaminsky once found – it can also be very vulnerable. Some users may be getting one result and others a different result.
I have attempted to iterate most of the issues, but there are certainly more. Hopefully, this gives you a good idea of how assets can go unfound in an Attack Surface Map. Let us know if you think I have missed anything!