 Hello. Today, we present to you our research on the DNS vulnerability class in the DNS service providers. My name is Shier and I lead the research team at Wizz, the cloud security company. With me in the room is Amir Lutvak, the CTO of Wizz. Thank you, Shier. It's really great to be here. Let's start with a bit of background about us. We are the Wizz research team. Wizz is a cloud security company. The team is composed of experienced security researchers, many of them with background from Microsoft cloud security group. Our goal is to do ground-breaking cloud research to find vulnerabilities, misconfigurations, risks in cloud environments that customers are not aware of and would impact anyone using the cloud. We started looking into DNS as a service. Why DNS as a service? First of all, DNS, as we all know, is the lifeblood of the Internet. It's probably one of the most important services that we have. Now, DNS as a service has huge impact. If you think about it, it holds your domain, it holds your internal routing. Now, what's cool about DNS as a service, unlike usual cloud services, is that also it controls not only cloud activities. When you use DNS as a service, it also impacts your own premise activities. Potentially, DNS as a service has huge impact on an organization. Now, on top of that, what is really great for researchers is the DNS protocol. It's one of the oldest protocols that we use. It's more than 20 years old. It's incredibly complex. There are so many different implementations of it, both from the DNS providers, but also I think about millions of DNS clients that we have out there, each of them implemented in a different way, creating a very, very interesting attack vector for researchers to explore. We started from looking into Route 53, which is the DNS service provided by AWS, and it's a highly popular across AWS customers. Route 53 is built on thousands of DNS servers that host DNS zones for all AWS customers. We mapped around 2,000 servers in the Route 53 platform. Whenever a customer is hosting a domain on the platform, they get four shared name servers to manage the desired domain. On the right side of the slide, you can see a simulation of one out of the four DNS servers Amazon provides each domain. The server stores the DNS zones for with IO, for example, and several other AWS customers. If the server is queried for one of the domains, under management, it will return the appropriate records for that domain. While studying the Route 53, we discovered that anyone can register any domain they want on the platform. There is no restriction on whether the domain is already hosted on the platform, and there is no ownership verification. The only limitation is that if the domain already exists in one of the name servers, it will not be possible to register it again on the same server. It makes a lot of sense, and it's indeed not possible, trust us, we tried. Basically, anyone can register any domain on any of the name servers as long as it does not already exist there. But is there anything dangerous here? For me, as a security researcher, it felt like we had too much control here. But almost any DNS service provider works this way. So is it really a security problem? This is an example that if you try to register with again on the server, it will be impossible because it's already there. So we started with a very, very simple and interesting research question. If we can register any domain, what domain can we possibly register that will give us interesting access to data? So we want to register a domain that is not already present on the name server, and that for some reason DNS clients will actually query for that. So we started into a quest to think what domains can we register that no one thought about, and we could actually somehow break the DNS. So we thought about it and came up with an idea. What would happen if we register one of the official AWS name servers on the platform? What would happen if we register one of the route 53 name servers under the same server? So we choose an arbitrary name server. In this case, it's the NS1611, as you see on the slide. And we try to register it on the platform enough times so that at least once it would fall under the management of the same name server. Let's do an illustration of that. So as you can see in the slide, we have an illustration of the NS1611 name server, which is an official route 53 name server. And you can see it already contains DNS zones for several of route 53 customers. What do you think would happen if we managed to register the name server domain name NS1611 under its own management? I totally don't know what would happen, but we must check it out. Definitely. So we tried it and it worked. As you can see on the slide, our new domain is now managed within a name server with the same domain name. We were really excited. We didn't know if it will have any impact, but we had a really good feeling about this one. So to test the effect of what we did, we decided to specify an IP record pointing to our server. So now, if a DNS client will connect to the NS1611 name server and ask it about itself, it is our IP address that will be returned. At this point, we're really curious to know if anyone is asking Amazon's server about itself and if anyone is trying to connect with us because of the manipulation we did. So we ran TCP dump on our server and hope to see something interesting. Surprisingly, we started receiving thousands of requests from thousands of different IPs. We realized we were onto something. The next step in the research was to analyze all these DNS queries and figure out why these queries are being sent to us. So wait, why are we getting any traffic? No one was supposed to ask the name server for their own domain. The name server actual domain is registered on other name servers. So why are we getting any traffic? And what's more weird was that it wasn't an actual regular traffic. It wasn't even DNS traffic. It was dynamic DNS traffic, which is a very specific protocol that you wouldn't even expect to see in this type of internet traffic. Now, we were getting a lot of data. I'm talking about IP addresses, computer names, domain names. So we started investigating. We started to look into the data. So basically, we saw we were getting millions of actual requests from endpoints. And when we started looking into it, we saw it's a lot of data. We are seeing internal IPs, external IPs, names of computers. We very quickly understood these are names of endpoints within many, many different organizations across the globe. And the scale was truly unbelievable. It's within a few hours of sniffing the traffic, we saw more than a million unique endpoints. And they would belong to based on the initial analysis we did, we saw more than 50,000 organizations, 15,000 organizations, all of them using AWS as a DNS service. Now, we said, okay, let's try to figure out what organizations are we seeing here? So it was quickly we understood that we are stepping into an unbelievable tap of worldwide organization and traffic. We saw Fortune 500 companies. We saw more than 130 government agencies in the traffic. So we knew we were probably onto something big, but the problem is that we had no clue what we were seeing and why. So what do we know so far? We registered a name server domain on the name server. We have no idea why, but for some reason, millions of endpoints started sending tons of dynamic queries to us. But again, why? Why are we seeing dynamic DNS before we are able to answer that simple mysterious question? We have no way to actually understand what we're seeing. So we decided we are going to step into the world of dynamic DNS. So what is exactly dynamic DNS? Dynamic DNS is an extension to the DNS protocol, which is specified in RFC 2136. It allows clients to dynamically update DNS records of a target DNS server. And it's commonly used to help devices find each other in internal Windows networks. Let's see how it works. So when my Windows computer joined the company's network and received a new IP address, as you see on the slide, it updates the local DNS server, which is called master server, when it's new IP address. Now, when Ami is trying to connect to my computer, he can query the local DNS server about share PC. And the master server will answer it with my current IP address. So far, sounds like a great feature. At the moment, it is still not clear to us why endpoints sends dynamic DNS updates to our server. These are requests that should never leave the internal network. Could it be that the endpoints sync of our server as their master server? I would even know how to find the master server. So it turns out Microsoft has its own algorithm for finding the master server. And it does not work exactly as specified in the RFC. Just before we go into the logic of the algorithm, let's do a brief refresh on DNS records for those who have not touched DNS recently. So in order to fully understand the algorithm, it is important to remember only three types of records. It will make it very quick. The first would be the A record. A record specify the IP address of which the domain points to. The second would be the DNS record, which specify the name server of the domain name. The third is the SOA record, which is short for start of authority. The SOA records contain administrative information about the domain, and its first parameter is the master server. This is the server in which clients will attempt to update during dynamic DNS updates. Usually, this server will be on one of the domain's name servers. And in Route 53, the different value of this field will be the first Amazon's name server from the name server's list. And now that we have already refreshed our memory, let's get into the algorithm. Now, this is the primary name server. So when a Windows endpoint wants to update the internal master server for its new IP address, it first needs to find it. The endpoint will send the SOA query for the internal DNS resolver on its own fully qualified domain name. The internal DNS resolver knows that the with IO DNS zone is managed internally. So with query, it will return the internal master server within the SOA response. Now, when the endpoints find the master server, it will update it as we saw in the previous illustration, and the update succeed. But what happens if the corporate DNS resolver is not set correctly and does not contain a DNS zone for the local domain? Or what would happen when the computer leaves the organization and start working with external DNS resolvers provided by home routers? In that case, when the computer query for the corporate domain, the DNS resolver will treat it as an external domain and will return the master server of the external domain just as it will do with any other domain. This is where the problem starts. So imagine an employee of Whiz decided to work from home, like most of us lately, and connected to their home Wi-Fi. The computer got an internal IP address from the home router, and now trying to find the local master server to update it. Because the external DNS resolver are not familiar with Whiz.io, it is going to resolve it just like any other domain. Because the domain is managed on Route 53, it will return the Whiz.io master server as specified in Route 53. The endpoint will then try to update the master server, which is an Amazon shared name server that manages thousands of customers. Obviously, Amazon servers does not support dynamic DNS, so the update request will fail. The thing is that the Microsoft's algorithm does not give up here. The algorithm believes it still has a chance to find the master server. So the next step would be to check if the Whiz.io's name servers have records for the master server. So the DNS client connects directly to the IP address of the name server and asks them what is the IP address of the master server. In our case, it is the same domain name as the name server. And here happens the interesting part. In fact, Windows DNS clients queers the name server for itself. And if you remember, we have registered this DNS zone, and here we can return any record we want. So we returned our IP address to the DNS client, and now the computer will update our server with DNS updates, which is the malicious actor server. And this is very crazy. So now we reached the point that we started understanding what's happening, right? Because what we know, we know the Windows endpoints. They use a custom algorithm to find the master DNS. The algorithm queries the name server for its own address. When you are in external and using Route 53, what happens that this means that you're actually querying the name server for its own domain? And that explains what happened. That's why we are able to register our malicious DNS server, and we're receiving this dynamic DNS traffic for millions of endpoints because all of the organizations using Route 53 when these devices are actually outside of the domain and outside of the company, they will actually use this algorithm, and we will be able to get traffic from those devices. So we understood what's going on. The next step was to figure out how much data are we actually getting, and what can you find from it? So when we started looking into the data, we quickly understood that we are actually building here what we call the nation state intelligence capability. Because think about it, we saw IPs from millions of endpoints from more than 15,000 organizations, but it's not just DNS requests. We are seeing external IPs, internal IPs, computer names. We are starting to map all of those organizations. Let's see what we can do with this scale of intelligence capabilities. We started from what we call IP-based intelligence. Imagine that you can map companies and a portion of companies around the world and map their global sites, map where their employees are at. We looked at one company, for example, and just see how amazing this is. This is one of the largest services companies in the world, and we got around 40k endpoints actively reporting from this company. Now, we are seeing a mapping of all of their global sites, all of their actual offices, the employee locations, right? So from just the external IPs, we can map, create a map of offices and home locations of employees across all of those companies. It's really amazing, and we can go even deeper, right? This is an example of a specific office where we detected 600 endpoints of that company. So imagine an intelligence capability that maps for you in one single tap into the DNS without any trace, actual structures of organizations across the world and all of their different offices and locations. But it doesn't stop there. Then we started thinking, okay, what interesting data can we pull from this if we're an intelligence agency now? So we started looking at companies that are in violation of the Office of Foreign Assets Control. We saw interesting things. For example, this mining company, it's an international mining company. And interestingly, we found six employees working from the Ivory Coast, which is definitely a place that is not allowed in that regulation at all, right? And we saw so many interesting examples like that. So we found a subsidiary of a large credit union with a branch in Iran. Again, 13 endpoints working from Iran based on our new and newly advised intelligence capability, right? So it's not only mapping all organizations, we can now start finding violations. We can ask questions across so many different agencies. You remember, we are actually seeing also government agencies. I wonder where are all of their offices, right? Now, it doesn't stop there. Because if you remember, external IPs is just a small portion of the data, right? We also have internal IPs. So what can you do with internal IPs? If I have internal IPs from different endpoints from the company, I can start building the map of the network, the internal logical network of the company. So for example, these are the segments. This is the employee segment. This is the ICD. Here's the operation network. Remember that we also see names of devices so we can start really understanding all of the segments. So building an intelligence map of the organization externally and internally across thousands of organizations. Now, we also had computer names and the computer names actually hold information about the endpoint, right? And many times you get employee names, you understand the actual role of the machine. You can see the specific, the build the machines is using, right? So we are actually getting quite a lot of information about those companies based on the IPs, the computer names. Here you see this is finance, and we see all of those machines are part of the specific segment. Okay, perfect. I'm starting to build my internal map of this company. That's perfect. Now, just so we understand the scope here. We looked at the specific DLS provider. Then we asked, wait, is this only this DLS provider? So we started looking at others. And we soon found there's many others also susceptible to the same vulnerabilities, right? This is not just about 53 vulnerability. This seems to be something that is shared across most of the DNS service providers. And if you think about it, we don't have to stop at the cloud providers. You have shared hosting. You have the main registrar hours. There's so many different service providers using, again, I think the shared concept here is that they provide DNS services for many, many different companies. And there's a chance that many, many of them are vulnerable to this attack of name server hijacking. So we started from AWS. We reported the vulnerability and was fixed really, really quickly by the AWS Route 53 team. Again, I think that within a week or two, it was fixed. And no one can now utilize this vulnerability in Route 53 because you're not allowed anymore to register those special domains in the name server. And we are in disclosure process with several additional cloud providers. And we believe there's many, many more to come. And it's part also of what we call the industry to start looking into and actually check across all of the DNS providers. So as Ami just said, AWS fixed the vulnerability very easily. They added all the names of their name servers to an ignore list, which is simple and very effective. Users trying to register one of the official AWS name servers on the Route 53 platform now receiving the follow error message, which says that the domain is invalid. And you can see it on the slide. When we report our discovery to Microsoft, they explained to us that this is a known misconfiguration that occur when the organization works with external DNS resolvers. And it's not considered as a vulnerability. So we would like to offer a solution for both platforms and organizations who would like to protect themselves from this kind of attacks. So first, we will start with the platforms. DNS providers want to ensure they are not vulnerable, should make sure it is impossible to register their own domains on the platform. DNS providers want to have even a better security, can also do ownership verification to ensure users only register their own domains. And in addition, it is very important to make sure that the platform user cannot register a reserved name as specified in the DNS RFC. The RFC is full of reserved domains that should not be allowed to register, and their gestation may lead to unexpected behavior. For an organization that want to make sure they're not vulnerable, we recommend making sure that the primary name server in their SOA record does not point to a different domain owned by the DNS provider. As you can see in the slide, and now you can see it, the different primary name server that a domain owner receives when they add their domains to the RATV3 is the first of the four name servers which manage the DNS zone. Changing it, changing the primary name server to an invalid sub-domain of the organization, or even the real primary master server will fix the issue, and attackers will not allow a potential attacker to register a domain on the platform. As you can see in the slide, and yeah, we are very close to the end. So just a few summaries and takeaways. First of all, what's really cool here is that we are able to get to nation state intelligence capabilities from a simple domain registration. Just a simple domain registration got us so much power, and we believe what we saw here is a new class of DNS vulnerabilities. This is just one idea of a domain. Think about how many different interesting domains you can try to register, and remember today you can basically register any domain that you want that will trigger unexpected results. No one thought, and we honestly did understand initially what would be the impact of registering the name server on itself. I'm sure there's many other magic domains that you can register, and it opens up so many interesting questions. Like all of this traffic was dynamic DNS. Why is it actually the dynamic DNS was built as a protocol like 20 years ago for on-premise networks? Why are we still seeing it outside in the internet? What are the implications of this protocol still being active on the internet and potentially endangering both the endpoints and the DNS servers? So there's so much here that we see as potential research areas for us and also for the community. And we believe the scope here is huge, because it's not a single service we founded across multiple DNS providers, and we are pretty sure that this one ability and many others will probably impact many, many, many of those DNS providers. Thank you very much. Thank you.