 Okay, so critical vulnerabilities in network equipment. We'll be talking about the past, the present, and what I think is gonna be the future. So Raynall already introduced me. So basically, you know, this presentation, it was a bit long, so I'll just skip these parts. What you need to know from this is that basically I'm a hacker and I focus on embedded devices in enterprise software and especially network equipment. So I've hacked all kinds of network equipment. And also before we move on, me with my colleague, Radik Domanski, we have a YouTube channel where we talk about our exploits that we use in the pontoon competition where we participate regularly. And that's it for the intro, so let's get started. What are we gonna talk about today? We're gonna talk about network equipment. So these are routers, firewalls, WAF, web application firewalls, VPN switches, and everything for home and enterprise. So as you can see on the screen, we got small routers like the ones you have at home, and you got like the big enterprise stuff. So we're gonna be talking about all of this. Or are we, actually? In fact, we're gonna be talking mostly about routers. So before you turn off your screen, let me just explain what's happening here. So routers and almost every kind of network equipment, the ones we spoke in the previous slide, are very similar. They have similar technologies, they have similar protections, and they have similar vulnerabilities. And this doesn't matter if we're talking about home or enterprise devices, a router, a WAF, or VPN applies. Okay, and then you say, okay, fine, but in that case, why are there so many more published vulnerabilities in routers than enterprise network equipment? The thing is for a hacker like me and you, it's very easy to go into a shop and buy $100 router, right? But if you're not a company and you don't have $50,000, or if you cannot go through the sales of these big companies that sell enterprise routers, enterprise equipment, firewalls, you're not gonna buy an enterprise class device, right? And this is why hackers like me and you cannot get our hands on this equipment. So this equipment is not well tested, especially compared to routers. And my goal during this presentation is to show you that I think enterprise network equipment is exactly the same as routers in terms of vulnerabilities, difficulty to hack all of this. And with that said, let's talk about critical vulnerabilities, mostly in routers, but also apply to the others. So before we start, some important definitions. So most network devices have two or more physically and logically separated domains. Let's take the example of the router, which is easy for everyone to understand. In a router, we usually have two domains. We have the wide area network, the one, this connects to the internet, do or to a wider outside network. And we have the LAN, the local area network. This is an internal trusted network, right? As you can see from this picture, these interfaces are physically separated, not only logically, but physically. And they have different trust boundaries. Obviously the LAN is gonna be more trusted than the one, right? So what you need to have in mind is that most network devices, whether enterprise or home, have this kind of separation in different networks. Sometimes the enterprise ones can have many more than two, can have 10, 20. In terms of impact, one side or external vulnerabilities are usually internet exploitable on consumer-grade routers. Although some internet service providers offer protections against this, we'll talk about these later. The same for other kind of enterprise network equipment, you know, whatever is the one, the outside network they're exposed, they can usually be exploited from that side. Whereas the LAN vulnerabilities are only usually exploitable locally, but locally, so to speak, right? So when you're talking about routers in particular, let's take again the example of home router, easy for everyone to understand. You have your LAN network where you connect your phone, you connect your laptop, you connect all of this, right? And the thing is you're thinking about your home and you think, okay, a LAN side vulnerability is not very critical. Okay, but what about if you're in a coffee shop? What about if you're in a corporate LAN with an enterprise device? Then we're talking about a big internal network. And so there, a LAN vulnerability is way more critical. Another thing to have in mind, some ISP distribute routers to their customers. So when you buy internet service, you get a router. So a vulnerability that is found in this ISP router means millions of customers, all the customers of this ISP which have the same device are affected. And as we know, during these pandemic days, I don't think there's no doubt that router vulnerabilities have become much more important. Moving on, let's start by talking about the past. And by the past, I mean before 2016. So in, let's start with CV 2012 5958 to 5965. This is a bunch of vulnerabilities in a portable SDK for UPNP devices. These are basically multiple vulnerabilities that result in pre-authentication, remote code execution. They were discovered by Rapid 700 in 2012. So the result is 23 million systems were exposed on internet and most of them routers. And the root cause is a software development kit reuse. And this we'll see is a recurring problem. So what does this mean? This means that there was a platform that was built with a software development kit. This software development kit introduced a vulnerability in every router base that was developed with it. And here we can see the vulnerabilities, like two of these, as I said, there are plenty of them. And if you can read code, you can clearly see this is a very basic vulnerability. It's a string and copy. This is a heap overflow. So basically it gets the data received with UUID. So this is a universal plugin plays a network protocol. You send a request with a UUID. This UID gets copied into the heap and then you take control of the device. So all of these were one exploitable. And in 2013, when this was found out, there were no binary protections on routers. There was no NX, there was no ASLR. And these days we still find plenty of similar vulnerabilities in some very low grade ISP routers because usually in some cases the ISPs distribute very cheap routers. And this was a devastating bug because like I said, there's 23 million effective internet devices. And then you just need to write your exploit ones and you run everywhere. There's no binary protections, memory layout. So you write the exploit ones and then you can own all 23 million devices. Not exactly that, but close. Now let's talk about an older but very interesting vulnerability called Ms. Fortin Cookie, CV 2014 9222. So this is a vulnerability in embedded HTTP server. It's called AllegroSoft Rompager. Again, this was exposed to the one. This embedded HTTP server is not used to run the router software but to manage the TR069 protocol which you use by the ISP to manage your router. So as you can see because it was used by the ISP was exposed to the outside, right? The vulnerability was fixed in 2005 but it was not propagated to the SDK users because again, this embedded HTTP server was part of the software development kit. So if you develop a router platform and use a software development kit, it embeds the HTTP server, bam, you're vulnerable. And it's a very interesting one. Unfortunately, you can't go into much into details here just what's on the next slide but it's an arbitrary memory rights through a cookie. And here you have the link to the YouTube talk. I highly recommend you see it. I think pardon me if I'm wrong but I believe it was Checkpoint who had this research which I think are one of the sponsors of Norsak. So here's a slide from their presentation and as you can see, arbitrary memory rights relative to a fixed anchor. What this means is that you see this cookie here there's this 10, 73, 73, 883. This is the memory address where you write and this value that the cookies set, oh my God, one, three, three, seven hacks is the value set at two. So you send an HTTP request to this cookie and you write this thing to this memory address. I mean, it couldn't be nicer as a vulnerability. Couldn't be more impressive. Again, 12 million systems were exposed at a time this was discovered, mostly routers and the root cause is the same as the previous vulnerability. Software development kits reuse of a vulnerable one. A recurring problem still happens to this day. Okay, moving on. Why are these SDK vulnerabilities so common in network equipment? So for this you have to understand how network equipment is done. So a lot of network equipment, not just routers but mostly low-end stuff, you know, like low-end routers, low-end cameras, low-end IoT devices are not produced by the company that sells them. So when you buy a net gear camera, for example, for surveillance, this camera was not produced by net gear. It was produced by usually a Chinese, Taiwanese, East Asian third party that then produces a base platform which uses one of these SDKs which it's produced by another company and then creates the base platform. And basically net gear dealing, whoever you're buying from just slaps a different shell on it. So it looks different, a different plastic mold. Slaps a different logo and a sell it to you for different prices. But underneath, it runs the same software, it runs the same things just with different logos. And as you can imagine, because this is used for cheap devices, these third parties are very cheap. So they hire employees on the cheap. So obviously employees who are paid cheaply, they're not motivated. They might be very junior, they will produce very cheap code. This cheap code will have lots of vulnerabilities. And again, these companies because they have such a high churn, they might disappear after two, three, five years. And of course, there's no support updates or fixes because the way these agreements are made between companies, net gear and dealing, they don't even get the code of the camera they're buying sometimes. They just get a support contract when the company goes bust and then that's it. So obviously as you can imagine, this results in lots of vulnerabilities. So things these days are starting to change. Instead of using third parties, these big companies like dealing and net gear for the mid-grade and high-grade routers, they're starting to produce them in-house. But is it really that different in terms of final effects? We shall see. So in the past as a summary, we got one vulnerabilities everywhere, all of these devices, no protection. Okay, and remember, I was mostly focusing on routers showing router vulnerabilities, right? And then you ask, okay, what about other types of network equipment? It cannot be that bad, right? Wrong. So here we have a vulnerability which published by Orange Psy. If you don't know who he is, I recommend you see him, very good guy, finds all kinds of vulnerabilities. And Meixang that found a vulnerability in a Palo Alto SSL VPN Terminator. So this is a high-grade enterprise device used to connect at an enterprise level. And what they found will shock you, is a format string vulnerability. If you're not aware of that, it's a very, very 90-style vulnerability, super easy to exploit that is almost impossible to find in the wild, so to speak, these days. And the way you exploit it, it could not be simpler. Here you can see here in the bottom, you just sent a post request to the SSL manager, and then in SF profile name, here this is the format string that will be used to exploit. This is trivial, and we're talking about, I'm not gonna lie, I have no idea how much this device costs, but I guarantee you it costs over 10K, possibly 30 to 50K, maybe even more, who knows. But this is like a top-notch enterprise device. So as you can see, clear example of what I just explained applies to everything. Okay, with that said, let's talk about the present. And by present, I mean from 2016 to 2020X, what this X means, somewhere in the next couple of years, let's say 23, 24, around that, you know. So things are definitely improving these days. We got NX, no execute, which is pretty common, and ASLR, but mostly on 32 bits. If you don't know what this is, NX basically is a protection, binary protection, that means you cannot execute code on the stack. So if you take control with a buffer overflow, you have to do some extra tricks to be able to execute your code. ASLR means that, again, when you have a buffer overflow and exploit it, it's very hard to find where your code is, but in this case, most ASLR is 32 bits, and all of these protections are relatively easy to bypass. However, they do add something, right? They increase the difficulty. Then finally, manufacturers start to understand they cannot leave the one doors open, the entrusted network doors open. This doesn't make any sense. So many routers are now locked down on the one side. And ISP have also improved, they offer better protection for their customers. Some ISP have what's called carry grade NAT, which is basically like a network address translation, like the one we have in your home that allows devices on the internal network to communicate with the outside. They have that for the ISP. But to simplify, it means that you on the internet cannot connect directly to an ISP customer. So as you can imagine, this offers some protection if you have a vulnerability on your external device, but your ISP doesn't let anyone from the outside connect to you. So now let's talk about a vulnerability I discovered in 2016, is CV 20166563. And interesting about this one, I just wanted to give it as an example because it's multi-architecture and affects a lot of different devices from the same manufacturer. So this affects D-Link over 10 router models. I'm not exactly sure how many, but I remember it was 10 or more. This is exploitable only from the LAN side, so also the quote-unquote trusted side, right? And it's a multi-architecture where you have these 10 devices, they have different CPU architectures. Some are MIPS, some are ARM. MIPS has only NX stack protection. ARM has NX and ASLR 32 bits. And this is a classic old school stack buffer overflow. We do an NX bypass using Rope and you do an ASLR bypass on ARM. So here is a very brief example of how it is. This is a bit simplified, but as you can see, you've got this parse input function. It takes input. This input is an XML that comes from the HTTP server. So you send an XML request HTTP server. Then there's a stack variable, which is 2048 in size. Then this input gets converted into an XML document and then it calculates the starts and the end of what's in between this action tag, XML tag, and basically uses string copy to copy into the stack var with the length it calculated. So basically this is how not to use string and copy because you are using the input, the length of the input instead of using the length of the variable. So typically when you have this kind of string and copy where the copy is size limited, if you do it right and you put the size of the destination variable, it can really go wrong. So this is a massive blunder. Anyway, as you can see is a relatively simple vulnerability or quite simple, I'd say. But here's the thing. I spoke about 30-bit ASLR. So as I explained before, the ASLR is basically a memory randomization technique which means that when you take control of when you execute your buffer overflow, then you need to execute your code, right? But you don't know where this code is because the location changes in memory every time the program runs. But when you're talking about 32-bit Linux, this is actually very predictable. So here on the right-hand side, you see an example that I run on a 32-bit machine and you can see every time it runs, the stack location only varies by the three middle bytes. That's it, everything else is static. So three bytes are supposedly 24-bit of entropy. In practice, due to some limitations, we end up only with 12 bits of entropy. This is 4,096 possibilities where our memory location can be. Okay, but here's the thing. If you send the buffer overflow and you crash the server because you didn't hit the right address, then you cannot exploit it again, right? But some servers, especially HTTP servers on embedded devices, network equipment, they use fork. So fork, so when you send a HTTP request, the server cannot just stop and process your request, right? What if other requests come at the same time? So what it does is it forks, it creates a new process to handle this request and then keep the main process keeps waiting for others. Every time you fork, if you crash a fork process, you're not gonna crash the whole process. What this means in practice, we can try and guess the memory address up to these 4,096 times and eventually we will hit the right address because there's very few possibilities. We're talking about on average 2048 requests. So this is a computer making these requests, we're talking about five seconds, right? It's trivial to break this. Anyway, this was an example of a vulnerability in the manufacturer SDK, as I explained. Now let's talk about another one. Let's talk about logical vulnerabilities. Another example, another vulnerability I found in 2018, actually two of them, one CV 2018 5999 authentication bypass and the other 6,000 Enviram variable configuration overwrite. So this is similar to the previous, the vulnerability is completely different than the previous one I explained. However, the effect is similar. It affects all mid and high end Asus routers. So you start to see a pattern here. Like the link, all these routers share the same platform. So whereas before we had manufacturers who use third parties that use an SDK. So when one router is vulnerable from one manufacturer, all the routers from all the manufacturers are vulnerable. Now the problem is slightly different. Now we have the same manufacturer. When you want devices vulnerable, all the devices from that manufacturer are vulnerable. So we'll touch more on that later, but for now, just bear in mind, sometimes you don't really need memory corruption to take over a device. So we need to speed up a bit, but anyway, here's a very simple example. Your authentication bypass is really simple. You send a request, and typically the request is, if your authentication fails, it sends you to the login page. But the way they wrote the code is super weird. If authentication fails and you send a post request, it still takes care of your post request and handles it before sending you to the login page. So this is how we bypass authentication. We cause authentication to fail, but then send a post and then we're in. And then the other vulnerability is a configuration variable override. It's a bit convoluted, but basically if you send to this VPN upload a post request, remember we bypass with post before, we can set any kind of configuration variable on the router. And using this, we can change the administrator password. So the attack sequence is very simple. We send an HD post to the VPN upload CGI URL. We bypass authentication. We override the router's administrative password. We send a configuration packet, and then we execute code in the login via SSH, et cetera. So a good example of a logical vulnerability chain. What about one side vulnerability is these days? Yes, we have firewall bypasses. And here you have a vulnerability we used to win Pwn2Own Tokyo 2020 November, which is a bypass of the firewall IPv6 handling. So I can't talk much about this now because I promised my colleague we wouldn't. We will release a YouTube video on it. But just bear in mind that this is relatively, what's relatively common is getting more rare, but even though the one side is more locked down, there are still ways to go through if you think like a hacker, I guess. So again, what these vulnerabilities have in common, there's no more multi-vendor SDK, there's no more multi-vendor vulnerabilities like in the past, but now vendors have a common platform for their devices. You own one device from a vendor, you own all devices from the vendor. So in terms of numbers, it's quite similar. It's just a different cross-section, I guess. So in the present, to summarize, we've got land vulnerabilities everywhere. And again, it cannot be that easy network equipment, right? Wrong, it is. Look at these very recent, March 10th, March 18th, vulnerabilities in F5 big IP appliances, another big manufacturer of enterprise equipment, trivial vulnerabilities, look at this. This is, okay, I think you should look at this offline, but anyway, it's basically a very simple exploit, the simplest you can imagine on this side. In here, we have an even simpler command injection. It's a joke of vulnerability, honestly. You wouldn't expect this on thousands of thousands of dollars enterprise device. And in here, we have more on Cisco devices, Dreitech core enterprise routers. So yeah, basically you can see the pattern here, right? So let's talk about the future. What do we have for the future? So land vulnerabilities will become much harder to find an exploit. Once we have more 64-bit processors, we'll have 64-bit ASLR. The 64-bit ASLRs, they're not that stupid trick I showed earlier. You need an extra information leak, an extra vulnerability. So again, we up the skill level. So we start to have stock cookies, railroad, binary relocations, pointer signing, all of these are being implemented in high-end network devices, and they will soon start to cascade down to mid-end and low-end devices. But even so, you have to understand that manufacturers, they want to provide more features, you know? So a lot of these manufacturers, let's be honest, they're terribly incompetent, but a lot of them, they're not, they're just, you know, but they have to achieve a balance between usability and security. As security professionals, we all know that if you get more security, you sacrifice usability. There's no way to get both at the same time. You've got to achieve a balance. So that's why we have, there's going to be a trade-off, and this is going to introduce vulnerabilities. Because of this, but because there's going to be more high-end, more high-end binary protections, I predict the high-increasing logical vulnerabilities. So it'll be more like the one I showed before in the ASLR router, no memory corruption, bypasses, et cetera. Another thing to have in mind is that manufacturers are starting to feel the pressure from government bodies, especially in the U.S. So they're starting to have to do proper pentas, fuzzing, and spend some of their money to hiring good researchers, which they don't really like, to be honest. So what about one vulnerability is? Will this become impossible to exploit? Well, I think the common firewall bypasses like the one I alluded to, that we did in Tokyo, are going to be dead soon, because they're quite easy to patch. And manufacturers are starting to completely lock down the one side, the external side. I also predict that ISP attacks will become more common. So an ISP internet service provider has a huge hidden tech surface, a huge infrastructure. It includes a lot of specialized network equipment that has never been touched by hackers because let's say you got three grades of network equipment. You got the consumer grade that we discussed here. You got the enterprise grade that we also discussed here. And then you got the ISP carrier grade. So if a consumer grade router costs $100, an enterprise router costs $20,000, $50,000, ISP one can cost half a million. So we're talking about the highest end of devices. And these devices, again, they have not been touched by hackers. And as we've seen in the previous slides, just because they're more expensive, doesn't mean that they are less vulnerable. In fact, I'd argue they are more vulnerable because hackers like you and me cannot touch them. So I suspect they are frail and full of juicy vulnerabilities just waiting to be owned. So next steps, what can we do as attackers? We can go down the layers a notch. So we can start attacking the IP stack, internet protocol, attacking Ethernet stack, attacking Wi-Fi parsers, Bluetooth, all of this. We're gonna have to start thinking about remote kernel exploits. And another thing we have to start focusing on vendor specific functionality. So, you know, vendors, they do a lot of customization. You know, they get Linux or they put it on their network devices and then they build the kernel modules. So they add kernel modules. They introduce proprietary network protocols to accelerate these protocols. They put these protocols in the kernel. So this increases a lot of the attack surface. And you see a lot of this in high-end devices, you know? And here's an example. So we can see an example of what I just said. So Wi-Fi compromised, another using AirDrop on iPhones, which is Wi-Fi too. We got a Bluetooth vulnerability. So I suspect these are the next juicy ones that we're gonna see. But again, these require a high level, a high grade of attacker. So let's finish with a comparison. On one side, we got consumer routers. On the other side, we got enterprise network equipment. What we got on consumer routers, we got shared SDK or platform. One device is vulnerable. All devices from the same vendor are vulnerable. Is this true in network equipment? Yes, it is. Palo Alto, Cisco, Barracuda. They have devices which share many, one platform shared by many devices. So we got implicit trust and less protection on the LAN siding routers. Do we have this on enterprise? Yes, we do. We got LAN networks. You got management networks, which have less protections than the one. Which by the way, you don't need. You can apply almost the same protections. On consumer routers, we got inadequate binary protections. We can SLR, no sandboxes, we have seen services running as root, et cetera. And yes, we do have this in the presence of equipment, sometimes worse than consumer grade routers. Consumer routers, we have recently reported 90 size vulnerabilities, like the Stack Overflow I described. We have that on network equipment. Yes, we do. Remember the orange side format string bug. Routers, we can get very cheaply and easy, available for everyone to buy enterprise equipment. Nope, we cannot. So I think pretty clear here, and I hope I was able to convince you that there's a clear pattern here. And there's a lot of these vulnerabilities just waiting to get popped, if you have the money and or the connections to get these devices. And of course, because we cannot not only think as attackers, if you work for an ISP or something like that, just have a think about this. Have a think about what devices, those black boxes that costs dozens or hundreds of thousands of dollars in your network do. That's pretty much it.