For our new blog series Blast Radius, security professionals, researchers and experts deep dive into different attacks and vulnerabilities, explore how they can impact the entire internet ecosystem, and examine what they mean for organizations of all sizes, across all industries. To talk about the emerging properties of self-registration services bundled with devices provided by major manufacturers and the implications of their insecure design, we are joined by Ken Pyle.
Ken Pyle is a partner of CYBIR, specializing in exploit development, penetration testing, reverse engineering, and enterprise risk management. As a highly rated and popular lecturer he’s presented groundbreaking research at major industry events such as DEFCON, ShmooCon, Secureworld, HTCIA International, and others.
He’s also discovered and published numerous critical software vulnerabilities in products from a wide range of companies that includes Cisco, Dell, Netgear, Sonicwall, HP, Datto, Kaseya, and ManageEngine, earning him multiple Hall of Fame acknowledgements for his work.
Ken has been publishing DNS work and vulnerability research privately for a number of years. He began showing some of his work in the web application, DNS and IPv4 space at different cybersecurity conferences, with a focus on fixing sets of problems that had already been deemed unfixable.
For our latest installment of Blast Radius, Ken will share a continuation of his work, and will disclose how the entire PKI, non-repudiation and encryption design of entire vendor ecosystems is flawed, and how you can use popular IoT devices and services to de-anonymize anonymity networks and map internal networks via poorly managed cloud security features. Additionally, he’ll reveal how he gained arbitrary control of firewall rules across millions of devices and multiple vendors.
The emergent properties of dynamic DNS scraping
At DEFCON 29, I presented a number of new attacks, reconnaissance types, exploits, and emergent properties of Self-Registration Services that come with devices provided by major manufacturers such as Datto.
In the lead up to DEFCON, I have been publishing quietly on the subject and attempting to pre-empt and alert companies to the exposures.
I have been a really big fan of SecurityTrails all the way back to DNSTrails. I find the engine and dataset to be simple to carve, highly accurate, and many emergent properties can be easily identified using the site and tools.
In this write-up, we’re going to discuss the emergent properties of passive, historical dynamic DNS registrations and how these can be easily exploited.
Mass mapping/arbitrary control of firewall rules
One of the many awesome features of SecurityTrails is the ability to quickly and easily search data in weird ways no one has thought of. For example, a search for RFC 1918 addresses via ST will turn up some pretty interesting results:
Searching for RFC 1918 addresses, specifically those which MSPs, IT folks, or even your home routers distribute, will allow you to very quickly start identifying internal networks and their firewall rules. You’ll notice I’ve highlighted a few interesting zones (remotewd.com, wd2go.com, duckdns.org, dattolical.net). We’ll get back to those.
In order for many of these devices to register or maintain a record on the manufacturer’s dynamic DNS regime, they must consistently beacon or “check-in” every few minutes. This allows the manufacturer (and you) to find the device easily, track it over network changes, and allow it to update and license itself. Since the records expire quickly, they can be considered live, passively gathered, and mapped.
Historical A records for 42vmmpfpf7.dattolocal.net - SecurityTrails
Here, you will see how the internal IP addresses and habits of the IT person are mapped. We track the internal IP registration (egress rules for multiple internal IPs), map the ingress rules (if web available), and I already have an understanding of what to start looking for (backups).
You can then also search the external IP address for any of these and understand the exact infrastructure of a given company.
What backup solution is New York Presbyterian Hospital likely to be running?
There is no cloud—just poorly managed, publicly accessible, shadow IT infrastructure.
The Datto devices are hardly unique in this regard; there are thousands of these devices pumping historical, accurate, internal network, firewall, patching and security control statuses out every day.
In the Datto example, the device self-registers quietly with the Datto DNS, PKI, and cloud infrastructure. As part of that, it exfiltrated data to Datto and provision services.
A quick read-through of their documentation will provide me, the attacker, with what amounts to a detailed map of rules, exactly how Datto tells customers to disable or wildcard firewall rules, and which zones to farm.
By running this simple query, you have mapped out the private firewall rules and networks of millions, if not billions, of devices.
This example gives you every Datto that registered 192.168.1.9 as its IP through their DNS:
Reverse IP lookup for 192.168.1.9 - SecurityTrails
This example does the same with Synology:
All domains that include synology - SecurityTrails
192.168.1.2 with Western Digital Network Storage devices:
Reverse IP lookup for 192.168.1.2 - SecurityTrails
This flapping DNS record tells me everything I need to know.
Why does this matter?
You have used their Fast Flux DNS network to map the internal IP addresses and firewall rules of millions of active devices:
SIRIS, ALTO, and NAS: BCDR networking and bandwidth requirements (datto.com)
SIRIS, ALTO and NAS: Datto appliances and firewalls
If you read that carefully, you’ll see that what you’ve really done is turned over arbitrary control of firewall rules across millions of devices. When you wildcard DNS in your firewall rules you’re going to have a bad time:
Datto is even nice enough to whitelist a lot of rules and functions for me, disabling many of the controls that would catch me doing what I’m about to show:
So, by following vendor product guidance, you have effectively:
- Exposed your backups and most crucial data to public internet devices
- Created and allowed attackable rules/PAT/NAT through the firewall in both directions
- Disabled most controls and exposed them to all IPs that can resolve to Datto domains through an arbitrary DNS server of the device’s custodian
- Allowed for arbitrary control of firewall rules through improper record registration and maintenance by unauthorized parties
Again, Datto is not alone in this problem; many of these appliances and devices work this way.
Vendors design for this very bad consideration:
About Policies by Domain Name (FQDN) (watchguard.com)
DNS Resolution of Wildcard FQDN Address Objects | SonicWall
I will not release a full, specific list of appliances and devices which provide wildcard firewall rule guidance and insecure zones. It is simply too dangerous.
But they exist.
Rapid exploitation at scale of vulnerable devices
These design and implementation decisions should be viewed as what they really are: exploitable, searchable fast flux DNS networks with live beaconing. They also allow you to quickly find vulnerable systems and maintain consistent tracking of patching, updating and exploitability. The GeoVision appliance network is an excellent example of this.
Mirai and how it could’ve been better - attacking at scale
Detailed analysis of Mirai and its impact as the largest DDoS attack in history is widely available.
Where Mirai was “sloppy” and poorly designed, we are going to quickly improve.
“Mirai spread by first entering a rapid scanning phase… where it asynchronously and ‘statelessly’ sent TCP SYN probes to pseudorandom IPv4 addresses, excluding those in a hard-coded IP blacklist, on Telnet TCP ports 23 and 2323…”
Not only is this very loud, it is very inefficient and allows for forensicators and IR people (like myself) to very easily identify attacks and threats due to sheer volume.
Mirai looked for default credentials and bad firewall rules (amongst other things) and did so rather clumsily. We will do this much more efficiently and elegantly.
As part of my DEFCON presentation and ongoing research, I have been privately disclosing to a number of vendors related flaws or exploitable conditions which enable these attacks to work. Some have responded quickly and admirably, some have been hostile, some have been highly dishonest.
That being said, I’m a firm believer in providing PoCs.
So I proved it and it wasn’t difficult.
Below, you will see the exploit I released at DEFCON 29 and responsibly disclosed to the vendor months ago:
The vendor, GeoVision, issued an ineffective or broken patch. The vulnerability was reported to them as an LFI/XSS/HHI/RCE/CSRF.
GeoVision Security Advisory… but that’s not what they are telling their customers:
Nor did they fix it:
Now, instead of trying default credentials and port scanning we can become much stealthier and generally nefarious:
How to access GV-IP camera through broadband modem (geovision.tw)
The exploit above is unpatched by the manufacturer. We know their internal/external IPs. We know they are active and beaconing through DDNS updates. We know the likely firewall rules. We know they can at least tunnel back out and likely have ports open inward.
Extending - Historical vulnerability data and OPSEC exposures
Watching records in DDNS zones, specifically changes and jitter, will greatly inform a skilled attacker. I can tell what patch statuses are, where likely vulnerable devices are, and I can stage Massive DDoS campaigns that are effectively unstoppable. I will stay with GeoVision to illustrate this.
Here, we have scraped the GVDIP.COM zone for active GeoVision devices. Not only have I identified vulnerable organizations and their security controls (DVR), I have created a very quick list of attackable IPv4 and IPv6 hosts through passive collection:
Assuming these devices are on privileged subnets/server subnets, I have just provided myself a pivot point into each one of those networks via the DVR system and my exploit without the need to even port scan: GV-Access_Installaion_Guide
Just send a single malicious crafted request via 80/443 to each FQDN individually or all at the same time and the rest is simple. You don’t need to randomly port scan, just use their DDNS records. If GeoVision attempts to turn off the DDNS service, everything breaks.
This is also common across many devices/appliances. DDNS cannot be turned off easily and a lot of things depend on it.
GeoVision (and others) are nice enough to publish notifications like this fairly periodically:
As you can see above, DIPMAP.COM is an old domain that is supposed to be terminated and devices on that network are likely to be highly exploitable.
But isn’t this supposed to be deactivated?
The record above (and many others) are continually updated, targetable, and the zone of insecure devices is absolutely not deactivated.
Commandeering this network and weaponizing it as a botnet is extremely simple, enabled by the manufacturer, and an example of the much larger problem.
De-obfuscating anonymity networks and proxies
Lastly, it is simple to perform OSINT and de-obfuscate anonymity networks or specific users (and their networks) using this method.
In addition to mapping the firewall rules, DHCP scope, features, and status of this device, we now have a unique FQDN/identifier. We also have a lot of UPNP attack data and opportunities.
When using a full stack proxy or anonymizer, the browser, application or a service on a given endpoint will attempt to resolve this record with the appropriate DNS server during a backup, click, or automated process. It will be tunneled through the proxy itself to perform the request.
While not absolutely authoritative, there is a very small likelihood that a user that does not own this device or know its identifier would ever request that record. If a user accidentally clicks or an automated agent is installed, this DNS request will be sent through the proxy and resolved, and the user de-anonymized.
This can also be used to track a user’s IP addresses across a long period and patch status, if the identifier is known. As an example, I’ll use WDTEST6.COM. This appears to be a Western Digital developer/test DDNS zone that is externally accessible:
Again, as noted before: if a user requests this record, it can be tracked or traced.
As the data and requests are tracked and logged (or should be) by the provider, this should be simple to obtain and begin tracking. An investigator or bad guy can now query this information or subpoena it directly.
Lastly, by searching via egress IP, we can again, map it to a PAT/NAT and track the DDNS name as it hops providers (WDTEST8).
An investigator (or bad guy) can now use this historical and real time information to do some really damaging stuff.
There are a lot more implications and emergent properties from these networks, zones, services and appliances that I have not touched on. By failing to police these zones or adequately monitor them, huge vulnerabilities have been created that are not easily fixed.
Anchoring PKI, firewall rules, and proper resolution to DDNS names allows an attacker an incredible attack surface.
Via RFC 1918 leakage, malicious hijacking or record registrations, or efficient exploitation, an attacker can pivot, perform recon, and attack via insecure devices easily, and can probe private and public IPv4 and IPv6 networks stealthily, control firewall rules, and operate nearly silently through multiple high-availability DDNS networks, efficiently mapping and collecting personal, infrastructure, and security metadata passively or actively.
Lack of monitoring and controls creates serious non-repudiation flaws in vital functions such as encryption and certificates. Providers fail to properly monitor the registration of malicious or compromised certificates via the provider and DDNS records on their network, and may not be able adequately attest to the integrity or non-repudiation of specific devices.
An excellent example of this issue can be found here, cached on SecurityTrails. This is a “spoofed” record which carries a properly registered SSL, and is pointing to an arbitrary server; security controls by Datto are based on this zone:
Historical A records for 4dh8g3k779.dattolocal.net - SecurityTrails
Not only does registering this record/certificate place serious doubt on PKI, I can now host arbitrary content on a controlled server using their DDNS zone. This also proves they are not sanitizing or policing these registrations. This was never flagged or stopped before I disclosed.