 So thank you for coming for my talk on travel routers. This is something that I just found very exciting to work on. So my name is Michael Sasongin. I'm director of research and data at Cinec and Cinec is a company that leverages the crowds to find vulnerabilities in our clients. So if you like discovering vulnerabilities, if you like hacking, this is something that you might want to try out because it's sort of a way to do real world vulnerability discovery and fight, get paid to do it. So in the process of doing that, we also work on a lot of IOT devices and I had a problem. I found myself to be a digital nomad for a while and I was sort of moving around from an Airbnb to a cafe and I had to connect all my devices like laptops, phones, my wife's laptop and her phones as well and it's just, it became really annoying to do that. So I was trying to find something that would solve this problem for me. So this was the motivation for discovering a whole lot of sections of devices that I did not know existed before this called the travel routers. In fact, I have one right here. This is about the size of this device. There are essentially, there are tons of them out there. I picked this Hutu travelmate because it is very reasonably priced. There are a whole bunch of reviews out there and people say that it is actually good for you. It provides some security. It's very convenient to use, et cetera, et cetera, et cetera and I figured, okay, I'll try it out. So I bought one. It was really useful because I was able to have all my devices connected to it using Wi-Fi and then I would just connect it to the cafe network, cafe Wi-Fi and it would sort of just bridge the two together. It's small, good for travel, has a battery pack, never catches fire and it sort of gives you a little layer of protection. I felt a little bit of a warm and cozy because I was connecting to my own network using network address translation. So I thought, hmm, this is interesting. I like to hack things. Does it actually make me secure or worse, does it make me less secure? And so I started doing some analysis. First thing I did, of course, network scan, see what services are available. I wasn't surprised to find that HTTP port 80 was open and so this is for the admin interface. However, when I actually looked at the admin interface, I found that it had two services responding to me. One was light HTTPD, which is very popular and I was very familiar with that, but the other one was called VS HTTPD. It's a little bit confused for a while. Clearly there is some sort of proxy going on in the background, but what is this service? So I went out to Shodan because that's what you would do when you are curious about something. And I searched for it. I found a few devices, not many of them are out there. I would expect that a lot of them are actually hidden behind private networks, so you wouldn't be able to see them. But there are still a few of them that kind of come up once in a while. Primarily in the area of Asia, so Japan, China, I didn't find any North Korea, but there were some Taiwan devices. So I knew they were out there somewhere and there was some importance to them. Then I kind of turned on the device itself and I decided to start reverse engineering it. First I downloaded the firmware from the Hutu main page. And that was easy. You just click download. It turned out to be a raw archive which you can just extract. And what you get back is a shell script. And at the bottom of the shell script there is a file system attached. It was GZ compressed but you know, that's trivial. Once I mounted it, I found that it was an XT2 file system and it had more stuff in there. And primarily there was something called the root FS. I figured okay, that's interesting. It's a little Indian squash file system. And that's kind of consistent with what you would expect with a flash based device. So I mounted that. I looked at the configuration and I found that it had this IOS service in reference from the elite HTTP config files. And I thought that this is what was the VS HTTP implementation of. So I didn't know what else to do. I kind of went around some more. I found a shadow file. I saw the hash. I quickly threw it and John the Ripper I felt really elite with that one because it took a couple of days to crack it. But I didn't know what else to do with it because I didn't really have a new place to use this password. Going online I found that there was some research done on other devices from Hutu such as the original, the Titan and the Nano. They're all kind of similar in a way. However I had the elite and it didn't have tellness anywhere on the device. I thought, hmm, what are the chances that the vendor would actually make custom firmware for each and every one of them? It's probably all the same and they just disable Telnet on my device to make it a little more secure. And sure enough when I did a search on the firmware I found that it had open Telnet that I say it's script that would actually enable Telnet on the device. But I still didn't have any way to run it until I realized that I could just fake an update of the firmware and I can tell it to execute this file and enable Telnet for me. But when I tried that, even though there were no signatures and no real validation done on this firmware, for some reason it did not execute. And I didn't really know what else to do. I just kind of continued on reverse engineering. Throwing the iOS service into IDA I eventually found this function called checkFirmware2 which apparently does a checksum validation on the firmware that you upload. And of course there was no signature or nothing like that and I said, okay, well I can just generate my own checksum. So I did that. I just pulled it up there and the firmware was, the device was very happy to accept it. And it just executed open Telnet data stage for me. It said there was an error in updating the device because I didn't exit one so it automatically means that there was a problem. However, doing this action enabled Telnet and I was able to receive a show. I was able to execute commands and essentially do dynamic analysis, download the debugger attached to any services, et cetera. So this was very happy news for me. In the course of reverse engineering I also found that the developers that they were writing in C++ because most of the internal state was in the structures that looked awfully like objects. There would be buffers inside, there was internal state and it would usually be followed by function pointers right at the bottom of the structure itself. Usually there would be initialization, they would assign function pointers to the actual structure and when those functions are used every time it would pass in the pointer to the structure itself. So it is very much like this pointer in C++. So that was kind of cool. In and of itself it's not really a problem. However, it just feels very hairy situation when you have lots of buffers and function pointers on dynamic allocation next to each other. So immediately I thought okay, what kind of memory protections does it provide? I found that it had partial virtual spatial randomization. So the binary itself and the heap were at static locations. However, the libraries and the stack were randomized so they moved around. But there was nothing else, there were no stack canaries, there were no heap protections and of course control flow integrity would be way too advanced for this device. Alright, so then I started looking for vulnerabilities, start fuzzing. I kind of honed in on the f name parameter of the get request because I saw that f name was actually responding to me verbatim, whatever I put in there it would come back inside of an XML file. So I thought I wonder what happens there. After about two seconds I found that there was a buffer of a flow and what was happening is that the developer was copying the value of the parameter into a buffer on the stack using sprint f which is of course an unbounded copy essentially. And they, you know, it just quickly overflowed and I was able to control the return address on the stack. So I did that and I was really excited and I thought man I have this vulnerability so quickly I can just exploit and get execution on it because I can control the program counter. However, what I found is that even though I can control the program counter I couldn't point it anywhere useful. I tried pointing it to the main binary and the heap because they were static and I could predict those addresses. But I had to, but those things were allocated on a low memory so I had to insert a null somehow into the string. Fortunately I couldn't do it literally and I couldn't use sprint f's own ending null, terminator null for this address. That's because of this format string that I was using. Then I tried to use red tulip C attacks, you know, see if I can point it to some gadget or directly to the stack because everything was essentially executable. Those things move around so I would have to have some sort of information leak attack in order to actually execute it. But I decided to move on. I started fuzzing other fields. For example, the cookie field immediately overflowed for me as well. This one was a little bit more complex. This was a heap overflow. What was happening is that the developer allocated one of those object structures which was called CGI tab. Inside there was a buffer of 1024 bytes. Now in order to fill the buffer they would take the value from the cookie and just use stir copy which was obviously unbound and put it in there. Immediately I thought okay, well if it's 1024 buffer I will just send 1036 bytes and overwrite one of the function pointers of the structure. So I did that and about 100 or so instructions later this function would be used. And I was able to overflow and control the program counter by changing the function pointer of the structure. And immediately when it would jump to that location I could have the control there. Now I was really excited about this because there were a lot less restrictions. It was a stir copy and there was no format to deal with. So what I did is I actually pointed it back into the heap because that's where the value of the post-messages body was being stored. And post-message body is pretty much designed for any sort of data. So I could insert pretty much any value and I didn't have to encode my shell code and I just was able to gain execution that way. All right. So now I can actually show you a demo of this. I thought well if I'm an attacker and I have this exploit what is it that I can do? So this demo shows pretty much everything that we've talked up to this point. I was able to attach with a debugger, I was able to get Telnet in there and then I attached with the debugging client with GDB. So then I started looking for some coffee and went to this website. I thought okay everything is working, the device is fine. I throw the exploit and now we kind of just let the program run. We can see it's working just fine. And then we see sort of the damage that the exploit has done to the device. So when I refresh the same website we can see that I'm able to inject JavaScript and essentially demonstrate I'm in the middle attack. And the way it was done is basically execute an IP table's rules that allows me to redirect HTTP traffic to somewhere else, to some proxy that I've created. I mean you might say well I mean so what? Of course it's HTTP. It's vulnerable. It's all in clear text. It doesn't everybody just use SSL now. Unfortunately not. I mean according to Google's transparency report there are still tons and tons of very popular websites such as cnn.com and vbc.co.uk that still use HTTP for a lot of portions of their website. And really I just need one that will allow me to inject JavaScript in there in order to install keyloggers or launch browser attacks that way. So there are multiple ways to actually exploit the router and to trigger these vulnerabilities. First is you can go through the access RF. Let's say if an attacker visits a web forum and there is some sort of request that has an F name parameter in there. Now even though I wasn't able to exploit it for this demo it doesn't mean that the device doesn't have any other attacks. And so if it was susceptible to other overflows through the unauthenticated get requests we could potentially do it without even being close to the device itself. The other option is from the external Wi-Fi. Like I said this is a traveler router. It connects to all kinds of networks with questionable cyber hygiene in there. And so there could be already vulnerable to exploitation from there. And then of course from inside the Wi-Fi itself what if you connect an Android device that has malware that specifically targets the infrastructure. For example there was one called Switcher which would look for routers to attack from the Android device. All right so pretty much getting to the end of this point so this was a lot of fun. I mean these vulnerabilities were reported to the vendor and they were recorded in the CVE database. You know the stack overflow was very easy to fix. Just specifically use SN print F which is bounded. Or in more general terms you can use stack canaries which wouldn't prevent the vulnerability itself but at least it would terminate the attack vector and you wouldn't be able to take advantage of it. The heap overflow is a little bit harder to deal with. It basically just use a bounded string copy. Or you can also in more general terms you can try to encode your function pointers such as something that Windows does. But unfortunately as you can see here the NSA has a pattern on that so we don't get to use it. All right so why would somebody actually try to attack travel routers or any sort of infrastructure? I mean there are a lot of use cases for this. First one is attribution application. You know if I'm an attacker and I want to hide my exploits you know I may want to blame someone else for it so I can exploit the infrastructure and then use that as a jumping point for my attacks. Of course stealing user information, you know authentication tokens, user names, passwords, pretty much anything that is unencrypted I can start collecting from this device. And then also I can manipulate the user information. You know you can use so in a demonstration where I was able to inject JavaScript so that means I can inject exploits, I can manipulate what they see, etc, etc. And of course the last one is getting a foothold into other networks. It's a travel device so it's going to be touching a lot of different networks. If I want to propagate as fast as possible I may try to use this device to launch attacks into you know Airbnb's, hotels, enterprises or what have you. So I reported this to the vendor they were quite happy to receive it. They said hey, thanks for finding these vulnerabilities. However our entire product team is off on Spring Festival. I said to myself this is kind of cool. I want to be part of that. It sounds like fun. Then it turns out this was actually the Chinese New Year. I didn't know this and so this was like a really cool cultural thing to learn. And of course as soon as the Chinese New Year was over everyone got back and they promptly responded by sending me a patched version personally but not into anyone else. And about a couple of weeks later after I noticed that it wasn't published on the website I said hey can you guys like make this public so that people are not exploited by anyone. So they did. They just said that their release cycle was a little bit slower than it is to send me an email. So that was cool. They were super nice about it. So what did we learn from this process? I mean you know the saying don't roll your own crypto. Well I think there should be a saying that says don't roll your own custom CGI web server. Because those things are notoriously complex. There's a lot of work to be done and there's a lot of parsing happening in there. And so really either get a lot of people, get a lot of advice or use something that has been tested by the community. You know when there's due response I had a pretty good experience in this case. If you can use something like OpenWRT just because like I said it's been tested and used by other people. I mean to me exploiting routers is a lot of fun. I didn't know MIPS before this and so it was kind of cool to learn all this process. And to be honest I was really surprised that people still use Turcopies and Sprint Ops just like they did in 1999. All right. So if you enjoyed this and you just want to chat about this I mean thank you for coming. It's been a real pleasure to be here and if you have more questions please ask ahead. And if you want to catch me in the hallways or online you can find me there as well. I love to talk about this stuff. I will also put about four different articles on my blog describing all the processes I've gone through and more information about reverse engineering at debugtrap.com. So thank you for your attention.