 Hello DefCon, my name is Ken Pyle of Cyber and this is what I call my Blue Monday series which is a series of new attack types, techniques, vulnerabilities, and web application exploits that I've been working on for quite some time and really this presentation is going to focus on mapping exploiting vulnerable devices and appliances at scale via self-registration services. So again my name is Ken Pyle, I'm a partner and exploit developer at Cyber where I do a lot of reverse engineering, offensive security stuff, a lot of refinement and development of new attacks, exploits, techniques, and pen testing, that sort of stuff. I'm also a graduate professor of cybersecurity at Chestnut Hill College, Chestnut Hill College is particularly notable as we are the college that produced the ENIAC programmers way back in the day, so a very awesome, interesting little facet of the program. So at Cyber what we do is we are a manager as this provider, data-secured privacy compliance breach response, digital forensics, e-discovery, data recovery. So we're a full spectrum security forensics and IR shop and obviously my primary focus is offensive security tactics, exploit development, reverse engineering, refined methods of exploitation and attack. So I am also a professor of cybersecurity at Chestnut Hill College where I teach a lot of the techniques, new ideas and whatnot that you're going to be learning today so we have a number of different programs, master and undergraduate and we cover the full gamut of education and training at an educational level. So what I'm going to talk about today is really what I like to think of is what I think of as real threat monitoring, real threat monitoring which is attacking common or shared vulnerabilities, supply chain, software, hitting things basically due to bad design, poor decisions and a lot of just accrued and accumulated vulnerabilities and issues that come from a lot of places over a long period of time. So what we're going to talk about today again is appliances, IOT stuff which are designed for ease of use and access. A sample of the devices we're going to talk about today have a couple of very interesting features, mainly a find me feature which whenever you're in a network or a segment where a device such as one of the ones we're going to talk about is, you can go in and use their service or their website to find them. You also have appliance deployments and scaled use. So we're going to abuse these things to identify map networks, identify vulnerable and exploit vulnerable devices and basically turn a lot of stuff into botnets and large scale attacks. The reason for is very simple. These are architected for mass deployments where the fully qualified domain name, the DNS regime, is unknown, unreliable or totally independent. What that means is these devices and appliances are designed where they're aiming for the lowest common denominator and the designer really can't tell you or provide any assurance that the environment they're going into, if it even exists at all, is reliable. So this creates a number of weird sort of lags as I use for this right here. Splashback properties as I like to call them because it's a lot of poor design where people aren't talking or just jamming things in and it ends up causing some very serious fundamental problems that we don't really see until you get out into the field. And some of this is due to IPv4 address exhaustion. We have created all kinds of workarounds over the last couple of decades for IPv4 address exhaustion, convenience and a number of other things that have created these fundamental flaws such as, like I like to say, splashback flaws in everything else. And one of the core issues for that, one of the reasons is, again, we have this constant fight between DNS, IPv4 and humans. And it causes all of these problems. And what I've seen, I've been doing this a very, very long time, application and IoT developers rarely ever see what I say below layer seven on the OSI model. They see the network stack and IPv4, IPv6, whatever the transport mechanism is as the exit ramp for them and they don't really need to consider what goes on. It's a network stack, it's a call, we just drop it there and it goes off. And then engineers, conversely, rarely ever see above layer three or four. They say, hey, it's the IP address, it's up, I can ping it, ICMP works, I can pass traffic, TCP, UDP, what have you. And they don't think about what happens above that. And there's this gap this all sits in that I love to live in because it makes it really easy and not a lot of people bridge those gaps. It's one of the places I live. I understand both sides of this. I've been doing exploit development for a long time. I'm a pretty damn good engineer. And this is what I see and I'm doing this stuff all the time with my team and my company in the field and this is just a recurring problem. Which creates a cloud and appliance vendor problem because they rarely ever consider metadata leakage, advanced tactics or hybrid attacks ever. And I have plenty of proof of this and maybe I'll come back to DEF CON next year and show you all the emails and conversations, what I have had over the years even related to this where you find out that a lot of vendors aren't doing the things they're supposed to do. And even worse than all of this is no one ever cooperates. Everybody white labels. And this is how supply chain attacks happen. This is how MSPs get popped at scale. How big attacks happen, like SolarWinds and Kaseya, because all of these things happen. And again, it comes down to for what we're talking about here, IoT vendors and integrators. And it allows for scaled attacks and supply chain exploitation. Vendors collect metadata to market and enhance the reliability and usability of their devices. They refuse to coordinate or consider any of the implications of kill chains or the aggregation of vulnerabilities. And again, I'll show receipts some day on all of this where I have either spoken with or engaged with some of these vendors and they go, well, it's not my product and it's only really affecting this little part. I don't care. Or they are quite simply not aware of or don't consider because you're either talking to an application developer or a security person who doesn't understand all of this. Even worse, vendors control the ecosystem of patching, installation, integration, and knowledge. They are the gatekeepers of their own vulnerabilities. And this creates a huge conflict of interest because how many companies are going to openly come out and say, we didn't think about this and didn't design it with this, especially when it's an issue or a problem that at now or in the time isn't scored or considered very high on the vulnerability scoring matrix. And they're relied on to know better how many of these devices and appliances and whatnot are designed to take the thinking out of the hands of the end person. They're frequently bought so that somebody doesn't have to think about a lot of these things. And again, at the end of the day, vendors want to make money from everybody, especially in COVID. They want to get vertical. They want to sell at every level. MSPs, individual users, large corporations, what have you. And they try to be everything to everyone. Like here's the Meraki website. Meraki does Wi-Fi, switching, SD, WAN, security, wireless WAN, Meraki Insight portal, smart cameras, mobile device management. These things are just absurd to me that you want to try to do all these things. And even on top of that, I mean, here's something I pulled out we're going to talk about later. How to host a WordPress website on your Synology NAS, which is one of the worst things I have ever seen in my life. Who would want to put WordPress on anything? It's not designed to support it. I hack WordPress all the time. It's actually remarkably easy. And people are going out of their way to put this on vital infrastructure. It's crazy. And all of this creates what I like to call the Dennis system of IoT and self-registration. The thing to remember, and I'm going to show you individual vulnerabilities or whatnot, but here's the crazy part about everything I'm going to show you. Nearly every one of these devices or appliances with this service model or design concept might suffer from a common set of very easily exploitable conditions. Because, again, DNS regime is unreliable. The FQDN and host headers of any new individual host are never really known by the developer, and they have to make it work with everything. So it creates a couple of very interesting exploitable conditions. One, almost every one of these things suffer from a 302 abuse or redirection flaw where you can just simply feed it the right input craft that only can send somebody wherever you want. This also creates a number of cross-site request forgery abuses. Because, again, if you're depending on certain information, submit it from the browser as part of authentication, and you are openly disabling or dismantling these protections, which they do because of these things, you can come up with a bunch of CSRF abuses that are abusable via DNS. This, in turn, creates a lot of cross-site scripting abuses because you can combine these two up here, most of the time the 302 abuse and host header injection, to inject arbitrary HTML content or trigger cross-site scripting. Because they accept almost all kinds of client input on their side and integrate it unsafely and build content relatively based off of that, which creates, again, what's in right here, both server and client-side exploitation of privileged users working en masse on appliances and devices designed to take the thinking, the bad part, the convenience part, out of their job. And again, it creates the Dennis system. The Dennis system of IoT, and I like to consider IoT, I say, it's instead of thinking marketing because they don't want you to think at all. And in fact, they're marketing and designing around that because here's your Dennis system. You can't trust anyone's infrastructure so they implement dynamic DNS services. You can't trust anyone to be compliant so they implement encryption and external PKI services like certificate stuff. You can't trust anyone to install software, particularly not your client. So they either don't allow any software installs or they do and they don't allow any external oversight of that or they publish an ecosystem. You can't trust user knowledge because a lot of these users or integrators are buying this to not have to worry about having that knowledge. Security is difficult, it's hard to do. So we're gonna want to nurture that dependence, nurture it via MSPs and white boxing. We'll sell you this device, you can put whatever name or whatever skin you want on it and you're stuck in our system until we migrate you off or you decide you want to switch which isn't very often. And lastly, you can't trust your clients employees to know what they're doing. And again, they're marketing based off the fact that these people, integrators, engineers, small IT companies, medium IT companies, corporate security, what have you can't possibly know all of this. So it integrates silently. You can't trust them to do anything. So we're just gonna slipstream right in very easily and do these things. And on the right hand side, it's a very good example of this. This is the initialization page for a data device. I purchased off eBay. And again, what's interesting is you have to check the box to allow third party installation of drivers and software but you can't actually trigger any of this in the device without allowing it in some cases. And again, if you look at the functions here, I use device for migration, things like that where they're basically making this a cattle shoot of exploitability and vulnerabilities. Even beyond that, I'm gonna only spend a couple seconds on this but one of the crazy things in why supply chain attacks are so big and they're going to get bigger and bigger and bigger and I'm gonna give you right here a technique for doing this. Remember this, all of these devices and appliances obey the same laws, everything else does. Anything that exists on this device is a file or content that was put on through a firmware update or OS install. They're almost always running Linux. They're built for efficiency to be cheap and for storage considerations. So if something resides in a firmware update or on storage, it is either essential to it because they wanna reduce cost on storage or they forgot it existed and it's in there by accident and that tends to give you some pretty good information. And again, think of it this way. Firmware updates, no matter where you're getting them from are usually just flash file system updates or drive information rewrite of whatever's over there. And the cool part is you can carve these things like any other file system. In fact, I do it all the time. It's one of the best techniques I have for finding vulnerabilities. It's how I found a lot of these in here. Obviously, I like to use BinWalk because BinWalk rules not only because of the IoT though which sponsored but they're just fantastic at doing this stuff especially when you do the extraction and what they call the Matrioshka which is going through and water falling through recursively extracting all these things out of these updates. So if you look right here, this is an update I pulled which is literally a file system that gets pulled out of this image. And from here, you can pull out static credentials not expiring credentials. Static passwords or program credentials and passwords which are MD5 and crackable, stuff like that. And again, even kind of the byproduct of this and I guess I only spend a couple seconds on this is that you can start carving these firmware for supply chain attacks. What you're seeing right here is internal development system and network metadata that I carved out of a firmware update that tells me the internal development environment and networks of the company that produce this. This is a very specific product that does this sort of embedded system build in our firmware update. This is the GitHub environment and I had to remove all this and redact it so that nobody actually sees what this is but this is the GitHub environment and details of one of these developers and one of these manufacturers. It's crazy. And again, where we really want to get into is carving firmware for scaled attacks. These two things right here are a private certificate, private key that I carved out of a firmware update and this is a static password used for encryption that I pulled out of a different device and you can pull all of this out very easily without even owning the device and testing it. So, what I'm gonna start with is here some dynamic DNS domains. There are a number and I picked out a couple of these for a reason and I'll get to it later but these are dynamic DNS domains that are maintained by each one of these individual providers as an independent self-registration regime that allows you to conveniently access things. Now, you can start farming these zones for a significant amount of information because of a couple of things. The providers are rarely restricting record registrations. There's very little policing of these zones that is actually done. Many of these things enroll by default and the name is algorithmically generated which means it's predictable, which means it's farmable, abusable, I can find it or even worse, they are user defined which opens up a huge area of attack for me. The zones are third party hosted. You'll see that this is data local.net. This is one of the interesting ones and not only that, it registers inside this domain or a couple of the other ones but it also registers inside the default DNS zone of wherever they are, so it ends up registering two DNS zones. What's really interesting is via passive DNS collection, all of this information is gonna live forever which means it's never going away. It's a map for me and a sort of codex of things to look at and there's significant metadata leakage. I can't stress this enough. Think about it this way, by passive farming of this DNS zone, I can tell you about how many or estimate how many of these devices are out there active local at any given time. Like there's probably about 140,000 DATOs that have been sold and activated over the year. Let's talk about these exploitable storage ecosystems. It's a good place to start. I'm gonna use DATO and Synology as my primary example. Now the first one you're gonna see here on the right hand side is this find me function and it's a very simple enumeration. It's designed so that somebody can go inside of a network and say I'm an MSP integrator engineer who's just an IT company going around or maybe you're just somebody who doesn't know what the IP address is. You type in find.synology.com or find.datocom.com or what have you and it's simple enumeration. You go in there, it runs some things, all of them do it a little bit differently and it will tell you exactly where any or all of your storage and backup devices are in this network. In fact, it's part of the setup routine and in fact marketed towards. They want you to do this. It registers with a dynamic DNS service and that's part of the setup. And these again, are either user-definable names and controlled input or algorithmically generated. This creates a number of very interesting scenarios. You have third-party applications and administrators who are typically using this and again, this is what they're designing for. And if you consider all this, this is the keys to the kingdom. If I am a ransomware threat, if I'm an advanced persistent threat actor, if I am somebody who knows what they are doing, this is the first thing I wanna look for because this is the keys to the kingdom. People are putting backups on these things. They're keeping their NAS, this is a NAS, it's keeping all of their data on it. This is what I wanna know about. This is my end goal and this is where I wanna be when I start acting in a real bad way. And even beyond all of this, the thing that's the worst part about these devices is that the data custodian typically, and if there's typically more than one, gets to execute a lot of user discretion. They get to say or do things or assign rights, discretionary access control, all that kind of stuff, which opens up offset failures. And again, I could go into just this part forever, but I'm not going to. Just think about that for a second. What gets even crazier is that most of these zones, it's nearly universal, do not scrub RFC 1918 private addresses. This is almost universal. So by farming these dynamic DNS zones, I can start mining huge amounts of private network information. That's really what I'm concentrating on today. The data is exultrated and updated to the provider and is available unauthenticated via direct DNS request. Have you ever been asked for a password when you do a DNS request? Because I certainly haven't. And this is a great example of it. This is a DATO device. This is an algorithmically generated name from DATO that I found out on the internet through researching. And look at what this record tells me. This company, whoever they are, are running a DATO. The time to live on the record is 120 seconds. The A record points to 192.168.10.10, which is a private address. This is the private IP address of this DATO device wherever it may be. The problem is here. This is being hosted through their zone. And I queried it through 4.2.2.2, which is everybody's favorite DNS server, right? Or 8.8.8. You can go out and test this exact record for yourself. I queried this, again, on July 15th, 2021, just to date to this, just so you could see that this really exists this way and has for a very long time. And you ask yourself, why does any of this matter? Because whether this company knows it or not, the internal IP address scheme of this target network is available externally. I have effectively mapped something behind their firewall, which may or may not even have a direct rule out to the internet to allow me to see it, which creates a couple of things. One, if it does, I have just mapped a NAT and PAT address translation through the firewall. If this thing has a direct NAT or PAT through, I have figured out, if I can reach on 8044325, you name it, that's a firewall rule I've just figured out. Plus, I know the internal IP address. That's a key piece of information. If there isn't, I just determined the egress IP address for this network. Because if they're registering and they're NAT or PAT-ed and it's something external, I can tell you where all the traffic leaves. And again, this allows me to determine firewall rules. This also allows me in mass to find vulnerable software appliances and organizations really easily. And what do I mean? If you look over here, this is a Meraki zone, dynamicm.com. And if you look over here, I am following a templated install from somebody over and over and over again. A VPN template, VPN template, VPN template, all the way down. If these are being deployed, and this is indeed a templated install, what I've managed to do is find and track someone cookie-cuttering these things out. Not only that, again, I have many of these. You look for template in this zone and you're going to see people repeatedly doing this. You find a common supply chain. If they're putting a static credential, which is a common thing MSBs do, to be able to administer NMAS or by default, if that doesn't get changed, I just found them easily. So why does this matter from an advanced standpoint? Because now I can create hyper-accurate maps of internal networks down to layer one and beyond. For example, this is one I found. I have the exact device. I have the layer two address, the model, the fact that it runs wireless, and it's external IP address. I can overlay these things and tell you exactly what layer one looks like, at least partially, from just this one entry. On top of that, you can hijack code execution and redirect clients. Why? Because of three, two redirects, dynamic DNS registrations, a whole amount of other things. You can also create extremely effective social engineering campaigns outside of any sort of technical exploit. I know if they're using Meraki or Datto or whatever else, if this is a external IT company that's servicing, I can call them directly. I can call the people directly. Hey, I'm calling from Meraki or Datto. We had a problem. Or I'm calling from your IT company, which registered this. All of this is out there. Again, this also has passive DNS collection, which allows me to stealth, ninja style, historically view detailed internal vulnerability information forever. I can figure out what internal controls are, what to target when it's there, even on shielded private networks. Think about this as a double NAT or PAT problem. I'll show you this, but think about it this way. If your device doesn't have a direct route, or direct PAT NAT, whatever, to the internet, but it's buried three levels deep in your core, I can read your core IP addresses from these registrations that are getting sent out whether you know it or not, which is exactly what I'm after. I wanna know where I'm gonna end up, if you will, when I land. When I exploit this device, I know where I'm gonna be so I can pivot or what to avoid if they have Meraki security products in there. I know where they are and I know not to hit them. In fact, I don't even really need to do port scanning to find this stuff, right? So let's start with Datto. Datto devices, they're backups, they do disaster recovery, there's appliances, infrastructure. And they focus on MSP and partnership relationships where they wanna say fire and forget. The self-registers, you don't have to worry about this. It's a backup device, it's a disaster recovery device. It takes all the thinking out. You have Datto dynamic DNS zones. It automatically signs up for a certificate. It white labels the software. In fact, their agent is, from my research, a rebranded storage craft agent. It also works on this hybrid and hosted model where you can put it in any, roll it any way you want. You want a hybrid, you want an online, you want it, whatever. These things also like massive amounts of metadata. To an absurd degree, I could do hours on just this device and ecosystem alone and why it's so poorly designed. And worst of all, they're vulnerable. There is continued persistent issues and exploitable flaws and design considerations that they don't really seem to wanna fix or address. In fact, I've had public work and CVEs registered critically against these things since 2015. Now, let's look at their DNS records for a couple of things and the way they design this. Their DNS records, like I've read most of them others, have very short time to lives, which ends up functioning as a beginning or a canary. It tells me is the device on, is it active? If I'm trying to DOS or take this device out, disable their backups, watching this externally tells me if I'm successful or not. Again, this does active external registrations, which give me the I egress IP address and firewall rules, particularly important if I'm reverse tunneling. If I pop this device or something in that network, I wanna know that I can get back out of this and bring it back to me. And again, these things run Linux, they're very simple to pop. And again, they have backup agents and software and these things are pivot points. There are other things, other software that gets installed as part of this ecosystem that's exploitable. It's pivot points, plus we know it's talking to other devices. It allows me to identify things or even better, I can flat out disable the ransomware controls to make sure you can't back up and you have to pay my ransom. Now, let's go hunting for these things using that some of the techniques I've given you. So we have TKI registrations, we can directly form the DNS zones, we can do passive collection via security trails and show it on. And if we're inside a large network, we can just use the fighter service. This is an SSL certificate that these devices automatically register for. And I've actually taken this entry out because I don't want you knowing what it is. It's a private piece of information. But this isn't a certificate signed up for by the data device that you can go find through any method of doing this. And again, here's the private IP address of here, of this device. I can map these two things together. I know this thing has SSL, I know that's the host name and I know that's the internal IP address. It's a very useful thing to have. But let's start thinking like a real bad guy thinks. Let's do some real threat modeling. And this is one of the most interesting entries I found. This is ostensibly a data inside a public Department of Defense network. And think about this, the only reason you're dropping a data in your network is to do DR or backup or what have you. This thing is beaconing home regularly. It provides status updates at regular intervals. That's what this is. It is active because once this TTL expires and it's not updating, it's taking it right back out. This thing houses, again, potentially use of backups and data. If this is a DoD network, really was a DoD network information center computer, this is probably holding some data I wanna get my hands on or hit. There are firewall rules allowing for it to tunnel back because it is beaconing actively. It's registering itself. There are other things in here that are happening that tells me this thing can reach tunnel back or there are firewall rules allowing it to reach something on the internet. Again, I can reach a lot of things about it and worse, it's very attackable. Why? Couple ways. I'm gonna use this different entry to show you this and again, I'm not gonna give you exact exploit information through tunneling through right through. I'm gonna show you how this all goes together. I'm gonna give you the pieces put to puzzle together. So over here is Shodan and over here is a dig entry for this more farmed out of the data zone. And you can do this either way. You can either look for data devices in the data zone or you can just go out to Shodan. What's great is this is reflected. It works either way. I have the external IP address, the external DNS name, the certificate and by the way, it can absolutely get through the firewall to this thing. And this is the IP address, 727522930. By determining this entry and comparing these two things together, what I have effectively done is figured out that there is a NAT PAT rule for that IP address for this and oh, by the way, this is their BDR appliance. From just this information, I have put together a huge amount of attack data and mapped things out just from that. Again, .30 has a firewall rule for 443, 80, who else knows going into 192.168.25.10. 25.10 is actively beaconing outwards and sending stuff back through the firewall, which means I have determined both ingress firewall rules and egress firewall rules. That's all I need. Plus I know this company, whoever they are is running a Datto, bunch of other things that you can figure out from this. Now, here is another one to look at. And this is again, using security trails and look at what we figured out here. One, I can figure out DHCP scope features by just watching how long the duration is for or how long leases are held for. I can tell you that this thing was on either Pat, whatever, internally, went to an external IP address and then went right back in again. What's even crazier about that is I can actually map out IT developer, whatever, habits out of this. And what do I mean? This 10, the 10.network and the 192.network for here. And again, this goes back three years. Whoever is administering this likes to apparently put backup devices at 161 or uses that for configuration. I found this entry by looking for 1.10 because I know it's an IP address that IT people or engineers like to put important things on. So I looked for 1.10 and came up with one of these records. Oh my gosh, they also like to use .9 and 1.61. I've picked up a habit of these people, but not only that, I have picked up firewall rules and a bunch of other things. I have now been able, I can now predict where things are on their internal network or where I want to go hunting. Again, if I want to avoid something or disable something or go after something, I already know in this network we're a pretty good idea of where things are gonna be. And again, I'm tracking their behavior and uses. Western Digital has the same problem. In this, you can use to map DHCP scopes, remotewd.com and westerndigitaltogo.com. This one is hopping someone's internal DHCP scope 24, so this is going through their entire DHCP scope and telling me what's the extent of the DHCP scope, what the properties of it are, how often this thing is getting rebooted, but not only that, again, egress firewall rules of this person's network and that they're running Western Digital device. All very useful to me. So let's look at Synology. Synology has a very similar design and but when you do it, they suggest an opt-out. And again, they have a third party application support in the ecosystem and I always say users install the dumbest things. They really do. Their DNS zone allows for a lot of user discretion and parameter injection. And I'll show you that second for, and this is where you can start taking it. Cannot connect to Synology.me when at home. I know why that happens. You probably know why that happens, but this person doesn't know why that happens, which allows you to abuse this very, very, very, very, very easily. And I said a lot of varies for a reason. This is the entry. This is the workaround. And you have people in these user environments or these communities giving out the worst possible things that other people are going out and telling them what to do. So they're disabling security controls for me on a device I wanna take a look at. And there's zones Synology.me and DiskStation.me, I believe a couple other ones. Give me all this. I can search for interesting keywords. I can search for user metadata or I can find vulnerable software and instances of user discretion. What do I mean? Go search this zone for what I did, Firewall. And see how many people have named their Synology or given me some sort of interesting information about their network, either directly or indirectly through these DNS zones. What kind of Firewall is probably there? Which one's the Firewall server? All of these, whose Firewall is that? All of these things are out there and you can find them. And again, you can find from the hosting provider. Even worse, think about this from a blackmail or a ransoming standpoint. Look for things like pornplex. Why? Because people have Plex devices. They like to use Synologies for them. And you can get this information and you can find every pornplex on earth that's running on Synology. Think of that if I can get your IP address or you're laking other information out of it or it's been registered in a different name. You're now giving me who you are, where this thing is and if you have some compromising or interesting information on here you've given somebody how to do this. For example, here's another one. Look for backups. What do people name backups? RSA backups. SI Hodges Backup Server. We'll talk that one in a second. All of these things, Tom's backup server. WP might be WordPress. Lazy backup server. All these other things you go, oh my God. You can map these things out and they're telling you everything you need to know. And think about this from a user metadata standpoint. One, I can tell you there's about 675,000 registrations inside that zone. And look at some of these pieces of information. Barrett Nass, Harold Bogner, which is, I believe, a company territorial, that's probably a Italian speaker. You have all these things out here and you go, oh my Lord, they're giving me everything. You can use this in fact to de-opfiscate anonymity networks like Tor and other things. Why? If they're algorithmically generated they have an agent or some sort of software on there and they're using a full stack proxy that's going out and beaconing this or what have you. It is highly doubtful that anybody else on earth is going to be looking for these specific FQDNs, especially if you catch them coming across Tor or what have you, or an anonymity network. Even worse, you can track via this passive collection where this IP address is, all the metadata about it, and that this thing is hopping a dynamic cable provider network for their backups. Think about this if I wanted to DOS these people. They're giving me a path to find their IP address forever. It's like a giant beacon for me forever to track them across. And again, if you're using this for, if you accidentally click on this link or fat finger this, you have an agent on an anonymity network, you're telling somebody who you are, because nobody else would want to do this. You can also map controls for this. This is a way to map IDRAX as well. Getting that later, I exploited them in a totally different way. But again, these are things we're registering inside zones, outside, and again, these provide some more information. And you can map people's entire networks out of these sorts of registrations. Again, this is a switch, a wired Meraki switch that also happens to have the same IP address, egress IP address, as this support portal. Here's Wards, Livermore's Laboratories IDRAC device. It tells you exactly what are on these things, what they're running. Look at these things. I can map all of these to these zones. You can even find vulnerable instances of software and applications from this, because again, people install the dumbest things. Somebody installed WordPress on a Synology NAS. Not only that, I get to map out everything from it. It's externally available. It's in another country. I have everything I need to attack this thing. And you can find them through their dynamic DNS registrations. Meraki does a similar thing. They have dynamic DNS registrations because they're cloud managed infrastructure. These things are designed to allow you to always be online, always updating, and manage your infrastructure from anywhere on Earth. And look at some of these zones and some of these names. People are telling me, MX84.1, Boston, Glenwood Springs, you're telling me exactly what I wanna know, exactly where it is, and exactly what the device is. And that's a problem. So I wanted to use this for a little bit different, and I decided to start exploiting and mapping developer habits and networks. And you can map the Meraki zone for registrations. You can map the entire infrastructure regime of internal networks. However, one little entry, and you kind of already saw it, was very interesting to me when I was going through here, this one, BXBRAC66. And Aaron's search of this tells you that this results back to Cisco. Yes, that's Cisco systems. You can further illuminate, rumorate, and passively farm this zone, and you'll find a lot of registrations that they have in Meraki here. Think like a bad guy thinks for a second. These devices are externally available. They allow for a micro-targeting of devs in future releases. I can track teams, devices, and habits. And think about this, this is a regression test for MX67. If you're changing something soon, or I wanna test it before it's, or something changes on the new one from the old one, it means it's a problem that I can exploit, and we have no idea when it's gonna be fixed. In fact, you can map these registrations and overlay update schedules, and start seeing where they're working on things actively and how long it usually takes. This is how you crack the supply chain. Look, BXB regression has moved several times. Remember that devs and engineers tend to forget the layers that do not apply to them. They don't really care. Now, I don't condone doxing. I'm not gonna dox anybody here. That's not why I'm doing this. The reason I'm showing this is to make a point. None of this will ever be erased, hence exposing some of this is not inherently evil. I'm telling you how to do this, somebody else is gonna find it. We need to fix this problem now. We need to start cleaning up on IO5 and fix this. And the first thing to do that is start thinking like a real bad guy thinks, and how you can abuse this. This information is obfuscated here, but it is persistent. By going back through this zone of Rack 66, and going through other IP registrations and dynamic DNS registrations, what blacked out here happens to also be the names of people and what they're working on. BXB 200, MX250, what have you, MX68, what have you. Taking just one of those names out and overlaying the Aaron record and a LinkedIn search of one of these names, you turn up that this person is in Midway, Massachusetts, and they happen to be the engineering technical leader of Cisco, Maraki here. I can target them specifically. I can go after it. I can look at all that stuff. And it's very scary. Now, moving on, let's talk about GeoVision security systems. This is where it gets really scary. They have dynamic DNS zones, gvdip and dipmap.com. The developer is known, both by me and many a couple other people, to delay or improperly patch their software. They don't do it right. They never do, for whatever reason I do not know. Which opens up a mirai type botnet opportunity. Not only that, the target groups of this have very poor Opssec. The target market has poor Opssec and the distributors have poor Opssec. Think about what this is. It's a IP network camera, DVR, access control, license plate recognition, facial analytics, you name it. Now, look at this. And this is what really appalled me. They published this changeover notice for their dynamic DNS service that says all the things that are on this old zone that's getting retired on October 31st, 2020 are old things that don't get updated and they're vulnerable and you shouldn't use it. But we've got a new one, you can find all these things on, you should update your stuff. Now what's crazy is, this is dipmap.com, the zone that's supposed to be disabled. The problem with all of this is, it's not disabled. GeoVision DVRs suffer from several vulnerabilities I have disclosed to the vendor personally. If you'll cure June 16th, cross-site scripting HTML injection, local file include XML injection code execution vectors. I told them about this, very specifically. In fact, here's some of the exploit right here. They don't seem to have an interest in fixing this. In fact, thank you for your reply. We provided, they said, hey, we have provided, we created this update for you. And we did, and I updated it. We'll see what happens in a second. Please help us scan and confirm, which I did. As for your question about whether or not we plan on registering or telling anybody about this, we'll do this after we, my, myself, confirmed it was patched, which is not the way it should happen, right? It's not, but keep this in mind for a second. I tested it here and said, hey, my God, this thing isn't working. You gotta fix this. And again, here's what I'm asking. Their reply back to this was, and again, I said, this isn't fixed. Here is the way you exploit it. This is an LFI on a Windows-based host for this thing, you can go out there and you can pop all these things. Their reply to that was, we discussed with engineering and then we scanned with Nessus and it doesn't seem that Nessus seems or any problem with this, with version 5.33, which is what the version I tested here. They have attached the Nessus report and sent it to me and said, well, thanks a lot for everything, but here's the problem. If they don't report it, don't register it and whatever else. It's never gonna show up in Nessus, right? So what have they done? They don't seem terribly interested in it. They seem to be backing away from this problem and trying to talk over my head and talk over my team's head. That doesn't work that way. The way Nessus definitions get put in there is obviously through CVs, registrations, whatever, which they obviously have not done. Think about that for a second. Now, again, dipmap.com, if you look at that old entry, is supposed to be disabled as of October 31st, 2021. It's not. In fact, this is a company called 24 Hour Toe, Cobb Parkway, wherever that is, and this is the login page for their device. Even worse, the first time this DNS name was seen is well past their expiration date, but not only that, it's still active as of 719. This thing is exploitable. It is simply exploitable and this company does not have a very good history of patching and you've already just seen that. Absurd. Now, think about some advanced applications of all these things. What happens if you overlay multiple DNS zones in public open source intelligence sources? You can track vendor preferences, poor Opssec, and then the poor internal deployments. You can pivot through multiple networks via botnes and DNS zones abuses. Again, if you farm their entire zone and it's all public IP addresses and you can get to them, because again, this is a DVR or a wireless access point or whatever, and there's a common vulnerability through all of them, I can just immediately take everything over. You can use some of these internal IP addresses for some really crazy stuff I'm not gonna show here, but obfuscation, misdirectioning, signaling, exfiltration of data in ways I haven't even shown yet, but think about all the things you can use that for. For example, these things are operating essentially as fast flux DNS networks with very little control, but not only that, all of these zones are designed for a very specific purpose to allow you to get into them, plus these vendors go out and make sure that these things can get through firewalls, they're white listed, all these other things, and you can turn these into very big scaled attacks. And again, remember, 302 redirection host header injection to client-side code execution. I have turned every 302 host header redirection and reflection to potentially a client-side code execution vector. That's another paper at another time you guys can go look at, it's already publicly posted, and it works on multiple things, which turns everything device, especially in this scenario, into my own personal exploit factory, either reverse engineering or executing developer attacks. For example, you may be asking yourself why I picked out all of these specific devices in dynamic DNS zones, and I'll tell you very straight out for one specific reason. I have zero-day critical exploits against every one of these that allows me to take over their networks or their devices, I will. Again, going back to, I can't connect to Synology for my own network, and you go out on this Reddit and you find out these people have made all these changes to it to make it very exploitable, such as hosting a WordPress website on their Synology. Another thing on the Synology is, you can reliably unauthenticated enumerate all of the installed plugins via brute force attack, just web server content enumeration anonymously. You can go out and figure out exactly which plugins are out there and vulnerable if you know which ones to look for. And again, I go back to 302 redirects and what have you. The API of these devices allows you to determine exactly what the HTTP status codes for anything are, and you can increment and watch these, for example, if you were successful in bouncing a 302 redirect off of them. Think about that. Datto's have even more issues. And again, this is a symptom of a larger disease, if you will. But the local agent, again, is a rebranded storage craft agent that uses in all testing we had, an old cherry pie instance that's vulnerable. It gives you a whole lot of metadata, but not only that, you can abuse this for LFI enumeration and a whole lot of other things. Plus, this thing has some local privilege escalation problems as well. And this is a SSL server, web server running cherry pie 322 on a port that not many people know about. You can use this and a couple of other things, again, this applies across of other things, is start crawling things like alien vaults, OTX, open thread exchange, or other submission things where you can go through and look at entire conversations between devices on private networks, if you look for the things that are vulnerable and really start pivoting and mapping out networks or picking up credentials. I picked up credentials doing this on against another device. And the last thing I wanna hit on is turning these things into giant DDOS cannons or abusing them. And look at this right here. This time to live is 120 seconds. What is the implication of owning these zones or being able to abuse these zones with these devices? Again, these are fast flux DNS networks. You can abuse them. They don't do a whole lot of RFC scrubbing. You can use them for malware attacks, command and control what have you. You can abuse the TTLs and lack of controls to conduct, target, and abuse their DNS zones. And I'm gonna show you here in a second. Remember, these are user-defined DNS networks that operate under a trusted provider that somebody is probably whitelisted or won't think is a big problem. The question you have to ask yourself is, what is stopping you or me from creating a record that is false, nearly indetectable, abusable on their network, and that they can't change? And the reason they can't change it is the entire ecosystem works off of these dynamic DNS names. If they turn this off, their stuff breaks. An unfixable problem. This is an injected, valid, spoofed, if you will, because I didn't really spoof it. It really exists this way. DNS record on the DATO network. I just bought a DATO off of eBay that had never been registered. I set this up on my network and all I did was give it the IP address of 1.1.1.1 on my internal network, which happens to be a Cloudflare IP address. Why Cloudflare? I don't wanna point this to a live IP address. I needed to create a flag and maybe Cloudflare can take. Looking externally, and again, I created this on my network and this thing registered even before all of that outside. Now, this thing has checked in, and I can force this check in, but look at what I've done. I've spoofed this record. This is not really 1.1.1. It's 1.1.1.1 in the sense that it's the IP address of that. But now I've created a third-party DNS record on a fast-flux network that isn't scrubbed that I can use to aim at things now or exfiltrate data or perform any sort of crazy attacks using this. If I wanted to DDOS this thing and I wanted to point my botnet, maybe I took over a different network and I pointed at this address that I've spoofed and it's very hard to fight me off. There's all sorts of crazy abuses you can use for this. Think about this from a social engineering standpoint. If I can go out and change somebody's data device DNS record and they're using this to get to it, I can put them anywhere I want. And it's true. It's how it works. This is that easy. This is how abusable these are. So we've got all these different types of exploits and ways to attack these things because we have a way to map, abuse, inject, find, pivot through, large-scale provider appliance networks. Now, the question is this, how do we keep from getting redenised, if you will? How do we keep from having all this happen again? Because what we're effectively doing for me when I look at this is exactly that. I am playing exploit poker and everybody else at the table is showing me their hand. And all I gotta do is figure out if I get a better hand than they do. How do you stop it? The first thing I will say is stop using insecure self-registration services and practices and appliances. They're terrible. I, it's a bad design idea. I'm sure they're gonna come back and say there's reasons they do it or whatever. It's a bad idea and we've kind of absolutely closed the book on that. We need to bridge the gap between developers and engineers on IoT. Again, devs stop at layer seven, engineers stop at layer three and we don't really understand what the other side does and how it affects us. And this turns into, again, third-party independent oversight of vendors' appliances and ecosystems. I don't know exactly how to do it right, but what I'm gonna say is this. I don't trust them. And you shouldn't. And I'm not saying it personally. I'm saying I don't trust anybody. I'm a security person. But it's clear at this point that the people who are supposed to know better aren't thinking about these things or their motivations may not be to make the best decisions in the interest of their clients. I don't know, I'm just speculating, but it makes you think about it and makes you say, we need people who have no dog in this fight to look at these design decisions and arbitrate it in a better way. Better than what we have now. We absolutely need to migrate away from faulty legacy systems and fixes like IPv4, DNS, and a whole lot of other stuff because we just keep building on faulty foundations and bad information. We need to commit to moving off of HTTP technologies as a transport and API access model. HTTP is a library static hyperlinking transport that we have used for all kinds of crazy stuff that shouldn't be used for. It's why we have all these problems. And lastly, we need to manage IoT the right way. And we need to stop depending on computers, machines and definitions that tell us what's going on. We need better human analysis, period. We need to train people, developers, whatever else, whoever it is to understand the context of information, the exploitability of things, to understand why things work the way they do. We gotta stop taking and eliminating complexity and work out of this job. It's a very aggressive field that's growing quickly and we're trying to give people guardrails and it's causing these huge problems and we gotta stop. So I wanna thank you all for watching this and I'll give you a couple of hyperlinks to check out. Our Insights blog for cyber where I publish a lot of this stuff and a lot of my new research is right there. Feel free to check it out. In fact, after the conference when this gets posted, I'm gonna post some more additional analysis DNS zones and what have you. How to turn 302 redirects into code execution using Java is something I've worked on for a while and there's a link to it and it shows you how to exploit other types of IoT devices. And lastly, my college THC has a cybersecurity conference every year where we bring experts in to contribute, talk, what have you. If you're interested in joining us or contributing to the conference, there is a link for it, you can absolutely do so. So again, I wanna thank everybody for your time. Thank you for watching and I hope this was very informative to you. Thank you very much.