DEF CON SG1 - CSIT Village - Jun Rong And Javier Koh - Cve 2025 52692 Rogue Request Roots Router

All right, welcome back. Next up, we've got a powerful reminder that sometimes one small flaw is all it takes. This next talk, CVE-2025-52692, Rogue Requests Root Router, is as much a heart twister as it is a tongue twister. Lam Jun Rong and Javier Chua break down a zero-day vulnerability in a widely used router, where simple string comparison bug led to full authentication bypass and root access with just a simple HTTP request. Simple flaw, massive impact. Let's welcome Jun Rong and Javier. >> [cheering] [applause] >> Okay. Yeah, thanks for the intro. You didn't have to read that whole title. I didn't expect you to read it. Okay, but thanks anyway. Thanks for the welcome, everyone. So, today we'll be going through like a really simple vulnerability. I think everyone here can understand it. And hopefully you can have some interesting takeaways about how to hack your router. So, first I'll give a quick introduction about us, and then I'll introduce our friend here, which is the router we're going to hack today. And I'll go through a bit about the methodology or how we actually found this vulnerability and how you can find these kind of vulnerabilities as well. This will include a bit about firmware extraction and just some general tips about how to look at the attack surface and basically reverse engineer the router. Then we're going to some details about the vulnerability itself and how we exploited it. And of course, we will do a live demo that will surely go according to plan. And finally, I'll just close off with a quick summary and conclusion. So, I'm Jun Rong, and together with me here today is Javier. And we conducted this research as part of CSIT's cybersecurity research and malware analysis team. And apart from IoT research, uh CSIT does a whole bunch of other research into lots of other domains. And we are very um glad to have uh Dr. Joseph Teo supervising our work. Okay. So, enough about us. Um the router today is the Linksys E9450, specifically the Singapore variant. And it's a Wi-Fi 6 router that's been designed for use in homes and offices. Uh first released in October 2020, it was actually distributed by Singtel in 2021. And it's certified as a CSACL S level one device, which is actually the lowest level. So, that's uh as much security as you can expect. So, a lot of people ask me how to find bugs in IoT devices. There's basically two main steps. First, you need to obtain the firmware. And then, you analyze the firmware to find the bugs. But, in the first step, you may already encounter lots of problems. So, for many vendors, their firmware is actually encrypted. And there are two ways to get around this. Firstly, you can search for some older firmware um that is probably unencrypted. But, if that doesn't work, you may have to find a way to decrypt the firmware. So, um this can be done to uh either analyzing old firmware to find out the encryption algorithms, or you may actually have to do some uh hardware debugging to figure out what's going on there. But, once you've got the firmware, the next step is to analyze it. So, we use two main approaches, which is uh static analysis and dynamic analysis. So, the main static analysis tools we use will be decompilers like IDA Pro. Um but, for some projects where there are too many binaries, or you just want to get like a quick view of what's going on, uh tools like uh S Trace and GDB are actually very valuable to actually see what sys calls are being performed by the firmware. And once you've got our firmware extracted, I'd like to use this thing called the Swiss cheese model to basically map out how we're going to search for vulnerabilities. So, you can think of software as layers of Swiss cheese. So, no software is perfect and each layer has lots of holes in it just like Swiss cheese. And a vulnerability occurs when there's some way where all these holes happen to line up and the attacker can pass through all of these gaps to get to a dangerous function in the software. So, we can focus on understanding and analyzing each of these individual layers which can range from authentication all the way down to sanitization of inputs filtering of inputs. And once you have identified all the gaps here, we can then string them together and determine if we can find a vulnerability in this process. Yeah, so when we actually looking at IoT firmware, I like to use a slightly modified model which I call the meet-in-the-middle model. So, we split the software into two halves which I call the source side and the sink side. So, for the source side, we're trying to look at how the attacker who has network access can actually get into the software and how to what extent they can get into the software. So, this involves reverse engineering the firmware to figure out how we authenticate users and also figure out where the routing tables are. On the other hand, for the sink side, we're actually looking at where the dangerous functions are and then we try and extract them up towards the network side. So, ideally these two approaches would be able to meet somewhere in the middle and then we can combine them and that will be our variability. Okay. So, enough about the theory. Um let's see how it actually went for this particular router. So, this is a Linksys router and luckily for us the firmware extraction was really simple. We literally just grabbed the firmware from Linksys website and it was just unencrypted. So, it's very easy to extract using uh binwalk and we found that it was actually uh packed as a UBIFS image which has plenty of free tools available to extract. And in no time we actually had the whole file system out. So, the next step was to map out the attack surface. And the most obvious is the web interface, of course. So, this is what happens when you type the router's IP into a browser and it handles all the administrative functions of the router. So, for this particular router, the web interface is password protected and not exposed to internet by default. Uh we looked at the other services on the router, uh for example, the configuration management and also Wi-Fi management services. Uh but we found that they were using non-standard binary protocols. So, we decided to focus on the web interface first because it uses plain HTTP and it's just much simpler to interact with. So, um we were actually able to identify um the web server binary pretty quickly and we found it in this place in in the {slash}bin{slash}httpd. So, we took this binary out of the router and loaded it into IDA Pro. Uh but unfortunately for us, we found that most of the functions were didn't actually have any symbols. So, they were all random names like this. Um luckily, when we looked into the functions itself, we found that there were actually a lot of debugging calls and in fact, it happens that the second argument of each debug call is actually just the name of the function. So we were able to craft the IDA Python script to basically look through all of the call sites for this particular logging function uh and then just extract all of them and rename the functions accordingly. So in our experience when you're dealing with IoT firmware um there's actually a lot of debug information that you can pull out of uh the program itself. So before we actually didn't have names for a lot of functions, but after running our script we were able to identify the function names for quite a few of the key functions. Okay. So now that we actually have a binary that has some sensible function names, we can actually get started on finding the vulnerability. So the first thing that we looked at when we opened the router firmware is to actually look at their routing mechanism. So this is not the Wi-Fi routing mechanism, but actually just the HTTP routing mechanism. And we found that it's actually represented as an array of this struct called MIME handler. And you can see the definition of the struct over here. Um but there's only three fields that you need to care about, which is the pattern field, the action field and the do off field. So the pattern field is quite self-explanatory. Um it's just a string that basically indicates which routes uh which HTTP paths will actually match the handler. So for example, we have this pattern called uh star star.tgz. So the star star basically means match anything and so this route will just match anything that ends with tgz. For example, /files/backup.tgz. So once um the path actually matches this string pattern, we look at the auth check field. So, if this field is zero, it means it's a unauthenticated request, and we can just proceed to execute the handler. However, if this field is actually set, it means that it's a authenticated request, and we need to do the authentication check first. So, um when we looked at this MIME handler array, we actually found something that's quite interesting. Uh we found that two roots actually have the same handler function, uh which is do_command_cgi. Uh and the more interesting thing is that one of these roots actually require authentication, but the other doesn't, which is uh pretty suspicious to me. So, the first the first route here is um /login, and no authentication is required, which kind of makes sense, right? Because as um for the login route, you don't even have credentials yet. So, you would need uh the route to be unauthenticated to access it. But, the more interesting route here is the /api route, uh which actually requires uh authentication, but somehow these two routes actually map to the same request handler. So, our question here is how does this request handler actually figure out which uh route the request actually came from. So, if it doesn't do this properly, there's a potential that it could actually mix up the authenticated and unauthenticated requests because they both fall into the same request handler. So, let's have a look at how it discriminates between authenticated and unauthenticated requests. So, basically, the key code here is the call to string string. And if you know a bit about C programming, string string is a function that checks if the second string is contained within the first string. So, for example, the the first argument here is the request path, and the second argument is the string {slash} API {slash} object. So, what's going on here is the function is checking whether the second string {slash} API {slash} object is within the requested path. So, if the requested path actually contains {slash} API {slash} object, then the request will be treated as a authenticated request, and then we would then proceed to execute the handlers for this authenticated request. But, you can kind of see the problem here is that string string checks if the path contains this substring anywhere in the path. It doesn't check whether it's at the start. So, what we can actually do is construct this path called {slash} login {slash} API {slash} object. And let's have a look at how this path is actually handled. So, first, we note that it starts with {slash} login, so we're going to go first to the login request handler because it starts with {slash} login. Um that's okay. Uh but now because it starts with {slash} login, we are going to bypass the authentication check, and then go directly to do command CGI. But now, once we are here, do command CGI checks that our path contains {slash} API {slash} object, and then it's going to route us through to the API handlers, which would originally not require authentication to access. So, now we are able to access the API handlers without even providing any authentication. So, hopefully you're able to get that. Okay, good. So, now the critical question is what goes on in handle web command. Again, we see our good friend string string over here. But now it's being used to compare against the patterns from this table called the web command table. And when we happen to look at this web command table, we see this very interesting pattern called EN telnet. And as you can imagine, this EN telnet pattern actually corresponds to the handler which enables telnet for the router. And in this particular deployment of telnet, uh there's basically no authentication that's been configured for telnet. So, once telnet is enabled, any attacker can just basically run telnet and get access into the router. So, because the string string is used in this case, uh we are actually able to construct this path again. We just tag EN telnet onto the back of it. The string string basically um returns true, and we are able to then access this EN telnet route, and therefore enable the telnet server without any authentication required at all. Once the telnet server is enabled, we can simply run telnet, and then um gain command execution to the router as the root user. Simple as that. So, our POC Python script is very simple. It's just four lines. Like, you you don't even need a Python script, but um we had to submit a Python script anyway, so here it is. Yeah, so the actually later in our demo, we're just going to run two lines, which is the curl and then the telnet, and then we'll show you how with just these two commands we're able to get access into the router. So, now I'll be handing over to Javier, who will be exploiting um the router that we have over here right now. And hopefully the demo will go according to plan. Okay, so here we have the Linksys E9450 SG router. And we are connected to the Linksys uh router wirelessly here. And the router web interface is on 192.168.79.1. So now I'm going to uh use curl to send a request. And then we are going to use {slash} login, which should be the unauthenticated route. And uh {slash} API {slash} object to access the API handlers. And lastly, at uh EN telnet, we should enable the telnet server. Uh if we actually run the telnet command now, uh should be can see the telnet now is not activated. But after we run this uh curl command, the telnet now should work. So with just uh one curl command, we are able to get root access to the router. And if we bring out the password file, we are actually logged in as the Linksys uh Linksys admin user in this case. So yeah, it's very simple. It's only one curl command. Okay. >> Yep. Thanks David for the demo. As you can see our exploit is so simple that it can even work at Def Con. Okay. So, to summarize um the vulnerability we found is basically an authentication bypass um due to a logic error and uh because of repeated um instances of string string use, we are actually able to gain access root access to the router um with just a simple HTTP request and a Telnet command. So, there are some requirements uh preconditions for this attack to work. So, most importantly, the attacker must have access to the administrative web interface, uh which is not exposed to the internet, fortunately. Um but if you happen to be in someone's house and they're using this router and they're connected to that Wi-Fi, you can probably get root access onto it. So, the key thing about this attack is that no credentials are required at all. You just need to be connected to the Wi-Fi. And um we verified it to affect this particular version of firmware, uh which happens to be the only version of firmware released because the this router is actually not not supported anymore and the vendor actually um didn't even bother to patch it. So, um there's a lot of these routers out there that are still vulnerable today and there's no way for the owners to even fix this at all. So, um the vulnerability has been assigned a CVE last year and the CVSS score is rated as 8.8. So, um we mentioned that this is actually the Singapore variant of this router and Linksys actually made two other variants, which is the APAC variants and the US variants. So, based on our static analysis of the firmware from these two variants, we are able to identify that the US variant is vulnerable to the same attack except with a slightly different exploit path. However, when we analyze the firmware for the APAC variant, we found that it's not vulnerable to this attack because the code base is completely different. Yeah. So, the moral story is use the APAC version if you really want to use this. So, in conclusion, this a pretty serious pre-authentication RCE vulnerability. And if you happen to use this router, our advice is to please exercise caution in terms of access to this router and basically don't let any random guy, especially if they happen to be here today, access your router. And most importantly, don't expose it to the internet because there's going to be people scanning for this. So, in general, you should definitely update your router firmware to the latest version. And the good news for everyone here is that Singtel no longer actively distribute this router. And we haven't found Actually, I'll just end it there. So, yeah. That's it for me today. I'll be taking any questions if you have any. >> [applause] >> Uh yes. >> Does Singtel replace the faulty devices for free? >> Uh okay, so the question was does Singtel replace the faulty devices for free? So, the the answer is as far as I know, the answer is no. In fact, there was a guy called LinkedIn that actually messaged me and asked how he should patch his router. And and unfortunately, the only answer I had for him was to get a new one. Because there is literally no way for you to patch this unless you develop your own firmware for it. >> Um have you tried uh uh performing any exploits on modems? Because usually the ISPs allow you to change your router, but you cannot change your modem. >> Okay, yeah, that's a good question. So, um unfortunately, during my time at CSIT, we didn't have um a lot of um our scope was kind of limited to just uh routers. But of course, I think modems are uh another huge attack surface that we should definitely consider in the future. >> The modems are the ones you cannot change. Whereas the routers you can buy a kind of top-of-the-line, you know, more secure. So, I feel like that would be an interesting next step. >> Absolutely. I think um uh we could definitely consider looking at modems. Yeah, that should definitely be a a target. >> Uh was wondering uh how many modems I mean, how many uh routers uh have you tested before you hit this payload? >> Okay, I think I can share, right? Yeah, okay. So, uh this is the second router that we tested. And actually, we found this vulnerability like pretty early into our testing. Um within a 1 week, I believe. Yeah, that we got this router and started looking, uh we found these vulnerabilities. Yeah, so this is the second router we tested. Yeah. Any Any more questions? Uh the slides? Uh >> The slides. >> Okay. >> Do we share the I don't know, should we? Okay, yeah. So, the slides will be shared after the event. Uh but, if you are really interested in knowing the details, we actually have a blog post about this on the CSIT tech blog. Yeah, so basically all the details are there except for the um a few pictures. Yeah, pretty pretty much everything is there. So, yeah, you don't have to wait for the slides to come out. The details are all out there. Okay. If there's no questions, I think uh that will be it from me today. Thank you. >> Thank you both for the excellent breakdown and crazy demo. >> [applause]