 Hi folks, my name is Rikram Gadi and I originally had submitted a talk called Shining Alight on a black box. However, things changed and then after Ian and I changed our slides to B. So hopelessly broken 2.0, circumventing security controls and network accessible services. So like I said, my name is Rikram Gadi. I'm the one on the right here. I am a senior security analyst at ISE and I like to hack things like web apps, mobile apps, binaries and IoT devices, which is why I do a lot of work with the IoT Village. I like to read a lot and I'm always confused. Then we also have Ian Sinerman. Hi. Well, that would be me. I'm a security analyst at ISE as well. I may have been a low key colony as a child. I also like to hack things, web apps, IoT garbage, some hardware, tech obscura, that sort of stuff. I always like to try and learn new things. I always like to teach them as well, whether that works, maybe not. But I'm also always confused like Rik. I really like that one. I guess it's an easy one to like. It's very realistic. So yeah. So the things, here's the agenda. This talk is about our research project that we concluded in 2018. During our research project we hacked a bunch of embedded devices, 13 where we had 13 targets. We got a remotely exploitable shell in 12 of them. And these are the three best stories that I could fit in half an hour or that we could fit in half an hour. And the idea behind it was that we were trying to find remotely exploitable bugs in embedded devices. So which is kind of what you do when you play the SOHO policy broken CTF. And throughout the whole presentation, we're going to cover three devices, the Buffalo Terras station, the Drobo 5N2 and the Nekir R9000. These are all devices that we bought, I think, early last year. So I would say March-ish. And then we hacked in between then and we ended everything in about October, November. But as we'll find out throughout the presentation, just because we concluded testing does not mean that our job was over. With the Buffalo Terras station, we're going to be looking at how sometimes developers may be confused with how some functionality may work. We're going to be looking at a couple interesting HTTP headers. And then we're going to be talking about an interesting situation where responsible disclosure where we responsibly disclose these issues to this manufacturer. And then they didn't respond to us in some sub-having where they tweeted some information and then deleted it. And it's all very humorous yet concerning. Then we have the Drobo 5N2. We're going to be talking about how we reverse engineered the protocol, which is what the stock was originally about. And then after that, we're going to be talking about how we found the keys to get into the Drobo under the device's doormat. And then last, we have the R9000, which we'll be talking about an interesting authentication mechanism and how we were able to fake a call from inside of the house. And then after a tale of bug bounties and bug bounty companies that we ended up in. And then after that, we're going to have a conclusion where we talk about responsible disclosure, the stuff that we found, how we found it, and comparing our study from last year with our original study from 2013. So without further ado, I'll kick it off with the first one, the Buffalo Terras station. This is one of the devices that's actually in the CTF right now. And after you figure out how easy it is, you'll score some easy points. The Terras station with this very easy name is a Soho Enterprise business-grade NAS. And it runs between $2,000 to $4,000. It's made in Japan. And it has an administrative web application. And I'll pass it over now to Ian to explain everything else. Okay. So this web app has, it has this wonderful JSON API. So one thing that I really dislike about JSON, at least in the context of, I guess, everything, is application JSON. So application JSON really sucks when you're trying to do CSRF, assuming they're actually checking the content type, because you generally need to pre-flight your requests if you want to set this content type. But further, we see that there is an authentication cookie. So they're probably using cookies for some of this. But there's also an authentication value within the post body. Back to CSERF, that's probably not going to be something that we can do if that authentication token is there because we would have to know their authentication token in order to send a malicious post body. However, we decided to kind of change that. So first thing we did is, you know, find the source code for this, or at least the code for the web app. In this case, we found that they were all pre-compiled Python binaries, which kind of sucks. Like, it's Python, you should be able to read it nice and easy, but this is not super readable. However, you just use on CompileSix and then it's just ready to go in a matter of like one or two minutes. So that was nice. So now we have very nice readable data, and it's in Python, nice and easy to parse, even if you don't know what you're doing. And then we see some rather concerning stuff here. Like, skip off. Yes, please, I'd very much like to do that. How do I do this? What do you guys think skip off does? So somebody thinks it's a security mechanism. We'll talk later. But it's a, yeah, let's figure out where this is going now. So the next thing I did after seeing this was just see where else to skip off reference, like within this file. So I just do a search and then we find this chunk of code. I highlight the important parts. And it looks like if we just set our HTTP host, like our host header to local host, we skip authentication. You know, it's like, I can kind of see why someone would implement this. So let's talk about that. So let's say that we have an API that needs to talk to itself. We could, you know, implement some sort of authentication, like understanding with the authentication to grant yourself an off token for yourself and then use it with yourself. Or we could just say, hey, when I talk to myself, I know it's me, so we're good to go. So I'm pretty sure that's what they were trying to do. So, you know, if the host header is always a local host and a local request, and it's never a local host and a client request, then the host header being local host means it's a local request. You know, good to go, job done. Except there's a problem with this. And I think many of you have already realized this problem. And it's that the host header is client controlled. So that's not good. So the host header is usually local host and a local request. And it's rarely local host and a client request. So the host header being local host just means it's a request with a weird host header. So one of the reasons that I think this becomes an issue with a lot of people is that the host header is application layer while routing decisions are done at the network layer. So although in a lot of our large web applications, we can expect some routing decisions to be made based on the host header, this is a tiny little, tiny little NAS on your LAN. Like, you're not going through a load balancer to talk to your NAS. If you are, like, that's a hell of a NAS. So since there's no load balancer and since we're talking to it directly, what can we do? Well, let's find out. So we have a base request here. We have a junk seed and it responds with, hey, this is an invalid ID or invalid session ID. Okay, that makes sense. So what if we set our host header to local host? And we still have a junk seed and we still get an error but it's a slightly different error. It's still invalid but it's invalid params. And it's saying that, you know, the reboot function doesn't take any arguments but we did give it one. As far as I can tell, the only argument that we may have given it was the seed parameter. So what if we just delete it? Well, if we delete it, we get result null. And then the device makes some sad beeps and reboots because suddenly we're an admin. That's probably not good. So I just got a shell. And now I can get a root shell without authentication. Also probably not good. Yes, well, I guess if for those of you keeping track, the authentication is the host header kind of. So the fact that you could just send, say, your IP address is 127.001. And then I have to say this is all you need to know from here on out. We were able to access all the functionality in the NAS. Also the ability to make the device beep. And that was really interesting as well. So we brought this device to another CTF. I think no one's figured it out here so far. There's actually a request to make the device play music. And that's one of the most annoying things that we found out. So remotely we're able to play music in other people's houses. And on top of the fact that we're able to get a shell. I'm not sure which one's more concerning. Yeah. So I don't know. It seems like after all the shells that we got on these devices, getting a shell kind of got boring. So then it became, hey, we can play music. This is fun. This shell is boring. So yeah, how about that Tweet and Delete? So we decided to disclose. As normal, we disclosed all of the issues that we found to the manufacturer. Gave them at least a month or two to fix them before we're doing public disclosure. In this case, you know, we sent an email to their security contact on 06-22 and heard nothing. So we sent another on 0702 and heard nothing. So then we sent the volumes to the security contact on 07, like on the next day and we heard nothing. So we sent the CVEs on 08-22 and we heard nothing. So we announced our public release because it had been many months and we tried our best. And then two days later, we did our public release with a demo live stream showing off the exploits and how to do this. And then something happened the next day that none of us were anticipating. An official Buffalo Twitter account retweeted the link to our live stream. What did that link contain? That link contained a very nice URL to our live stream on YouTube about how to hack all Buffalo devices. What happened to that tweet in? Well, at some point, they must have realized that something was terribly wrong because they deleted it. However, we do have a screenshot, so that's nice. So we're not crazy. This actually did happen. Hopefully your folks in the back can see it and enjoy your life and so you definitely can see it in the back and hopefully you're enjoying it as much as we did. So what ended up happening with the device in the end? Did we get patches? Well, we'll find out. So clearly they realized that something was wrong. So at least someone at that company is aware that there's a lot of vulnerabilities that should be fixed. So clearly, as far as patchability goes, there are patches. There are no patches. It's been like a year I think? Yeah, and for a talk that I did at CypherCon, I did some more research and found that all Terrasations are vulnerable to the same exploit, including the ones with the brand new completely redone UI. How much were those devices again? The devices, I think some of them were up into 20k, something like that, like professional grade network attached storage for businesses. 20k for your own, I guess, C2C server in the end. Pretty much. But yeah, I guess in summary, the host setters client controlled. Unless you have something that's parsing it and making sure that it's not client controlled, maybe don't rely on it for authentication. And like, if you have a security address, please pay attention to it. We're trying to help you. And if you screw up, own up. Like clearly whoever had deleted that tweet knew that something was wrong, but they didn't own up to it or if they did, someone didn't listen to them and all of these devices are still vulnerable, including the one in the CTF. Like it's running the newest firmware and you can go over and get a shell in it if you like. Oh, you want to talk about Maryland Democratic Party real quick? You're way more enthusiastic about this issue than I am, so I'm going to let you take care of this one. Yeah. So after all of this, we found out that the Maryland Democratic Party had a Buffalo NAS on the internet with no password. And while we were doing all this research, another research company found it and contacted them and then like did a release about it. Apparently like every nation state and their grandmother was in this NAS pulling off all their data. But the Maryland Democratic Party did take care of it. They put a password on it. So it was still on the internet, but they put a password on it. And then we released this. So I guess I'm pretty sure every nation state and their grandmother can Google. So sorry, Maryland Democratic Party. We tried. Just to be clear on that one, we didn't hack them at all. That never happened. Let's make sure I don't want to hear about that later on from anybody. But it's kind of funny because we give a lot of these presentations where we tell people about like, hey, like you there are vulnerabilities that you're seeing are it's in the system. It's like you can have the like up-to-date firmware. You can have a good password. It's like if there are authentication bypasses, it's like false sense of security that you're leading yourself into is like I mean wrong. It's important to have good passwords and important to keep your stuff up to date. But if there's no update and people can just change the host header to local host and get in, you're just lying to yourself. Talking about lying to yourself is our next device, the Jovo 5N2. The Jovo 5N2 is a SOHO enterprise-grade NAS and it is between $400 or $500, way cheaper than a Buffalo, but just as vulnerable. This one's made in a great, I'd say a lot more vulnerable. This one's probably way more vulnerable. I'll tell you guys how many unauthenticated shells we got on this thing at the end of this. But this one's made in America. The one, the reason why we wanted to look, to research into this device was because it doesn't, you can manage it through a web app by default. Almost all these devices, there's like you hook it up, there's a web app, you connect to it. The Jovo only, the only way that you can connect to it by default is by installing this thing called a Jovo dashboard and people on Reddit were losing their minds over it because they thought it was really cool because it has all these pretty lights and the kids really like LEDs. And the other reason why is because it's like pretty robust and it's also like pretty fair price point I guess. I wanted to get it because it has this custom protocol that it uses to connect to the device with this like only macOS and Windows binary that you need to install. So we installed it and this is what the Jovo dashboard looks like. Just, I think this was the macOS version, you install it and then it gives you like other like information about the device like the serial number, it tells you the like how many drives you have installed, when was the last time you like set up RAID and all that and the life expectancy of all those drives. Not sure how it does that. And you can also install other apps and remotely access the device through other means as well. The first thing that we did is that I was really worried that the only way that we'd be able to assess this device is by doing a lot of hard core reverse engineering because like oh they probably have certificate pinning, they probably encrypt everything with TLS. Ha! It was just plain text. Everything and I know it's a little bit hard to see that but that's just we opened up Wireshark and started clicking on a bunch of stuff and we found out that everything was in plain text. I was like well cool but it's so it's like this customer proprietary API was just XML and what you had to do is that you sent the like that like drynet, TM stuff at the beginning, those dots are just hex characters, I put dots in so it's a little bit more easy on the eyes and then some XML data. Well we still need to reverse engineer the protocol here, we need to figure out like how it all works, what does the 61 here mean, what does that DRA number and how does this all work. So the first step that I said is like well cool, maybe I can just send this message with echo and then pipe it into netcat, connect to the device on port 5001. We saw that whenever we were interfacing with the device it was over port 5001 and that it was always listening on that port as soon as the device turned on. So maybe we can just send this and figure out if it just gives us a message back maybe there's no authentication. We sent it, we didn't get anything back it just froze. We needed to figure out why at that point so we need to do some more protocol reverse engineering and see where that goes. So I also found out while we were looking at it that if you kill the instance of your Jorbo dashboard it'll restart and when it restarts it'll have something listening on port 5000. It's like cool well I can probably just connect to the device on port 5000. If you connect to the device on port 5000 it spits out all this XML and that's really interesting notice there's no trickery there no authentication I'm not sending anything connected to the device on port 5000 and that's it. So I was like alright maybe it is that it needs to be connected to the device on port 5000 and also send a message. Well let's try that out if we send that and we echo this information pipe it into netcat maybe there's maybe there's no authentication. It's like well that's not working either maybe there's something else. So at this point we're going through the process of reverse engineering if you're gonna how is it that the whole like handshake part is happening between these things. So we kill the Jorbo dashboard and I think the other thing that was very important about this is that every time you kill it it just automatically restarts so we needed to set a script to automatically kill it every time until we were ready start water sugar then start back there from from nothing and we found out there is authentication when the Jorbo dashboard starts so the application that connects to your device it sends this message and this message is only it only happens once at the beginning kind of sounds like what happens when you log into an application right you log in what you send your username and password once it sets a session token it gives it back to you and then you have all that information and you can just keep on doing the do. So we needed to reverse engineer the front part here so you can see that the drawing ATM part is still the same there's a bunch of dots and a number there that number looks pretty long and it looks I would say it looks complex enough that I don't think I'd be able to brute force it so we started looking into what it is what it is that this number meant the first part the join a TM part was just those hex characters then we found out that after that it would say if it's coming from the server or if it's being sent to the server with the other bytes and then the rest of it was a size of the packet and now that we know all that information there's something else here that we still need to figure out what's that so the part that's like I guess kind of highlighted in red but definitely bolded that looks like something that's still complex enough that we can't just randomly guess who it belongs to but we found out that when we connect to the device on port 5000 it gives us back that number that that here folks is the serial number so it looks like the thing that you need to authenticate to the device is its serial number it's like oh this is complex enough serial numbers are pretty long but you can just do the following connect to the target on port 5000 extract the serial number from the xml that's returned to you send the login request on port 5001 send whatever command you want to port 5001 and then install whatever you want we found out that you can install pretty much anything you can install my sequel you can install apache you can install open ssh you can install other malware that you find out and you find anywhere but it pretty much allows you to do anything and then after we found out that drobo also provides this thing called drobo access it's a web application that they provide so that you can connect to the device through something that's not the drobo dashboard and we were so wondering I said well we don't really have a shell yet how are we going to do this the first application that we installed gave us cv 2018 14 6 9 9 and I think that's a little bit hard to see for everyone in the back so let's look at this a little bit more closely here's the device's IP address 192 168 1.26 it's on port 8080 that it listens on drobo access you send an enable user request and you set your username to your command injection payload that goes straight into a shell and that's the easiest shell I've ever gotten throughout my whole career and that's pretty much it there's no authentication or anything you send this individual request to any job access I guess job or job or with job or access and you automatically get a shell so let's talk about now the disclosure timeline we send everything's them on 0706 we're in an email so like hey we want to send you these vulnerabilities over how do you want to receive them do you want to see encrypt them or not do you want us to PGP sign it ha they didn't care we send them back again to security contact ha they didn't care we send them to the we send the CVs over anyways hopefully stirring something up for them to respond back to us we got nothing and then after I did a public release and a live demo of me exploiting this vulnerability I'm also going to be doing this in on other conferences I'm going to be a b-sides Puerto Rico in October I'm going to be doing the same thing again and the reason why is because they don't fix anything so send the DM to the gerbo CTO Ian what happened there how do we DM the gerbo CTO so for that handy-dandy protocol that they gave us I decided to write a little Python utility that makes it very easy to run your own commands and I accidentally got command injection just while writing a script so we kind of figured we should probably tell them about that because it's depressingly trivial so I I sent him a DM and or I sent the the CTO of the company that acquired robo a DM we'll get to that so then after that we recent all the vulnerabilities that we found to drobo and in it to CTO email or sent all the vulnerabilities that we found the job of the CTO's email we didn't hear back from him I'm pretty sure he doesn't like us besides the point Ian mentioned something interesting while we were sending all this stuff over something was happening in the background job was getting acquired while job was getting acquired we found a bunch of we found nine unauthenticated shells folks nine that's embarrassing to me not for me I found them but they're like this company store centric they were acquiring two companies job oh and next in throughout the whole process now I'm here in red which I hopefully I'm hoping all of you can see in august 21st 2018 they released this on the nexon website let's look at that timeline again we submitted everything on 0706 so that would be July yeah July he's shaking his head July and then after on august 22nd 22nd we send them all the CVs throughout that whole process they could have addressed these issues or just got them back to us they get I'll be honest they could have been just busy with their acquisition and not really in the mood to deal with nine unauthenticated shells sounds like their problem on mine but let's go to the summer the summary of this issue having a proprietary protocol is not making safe just because you're like you're prescribing to the idea behind like if it's mine and nobody else knows about it nobody can find any exploits that's not true there are many good reverse engineers out there they will figure it out it's a bad idea to authenticate with the thing that you're providing users they probably shouldn't be authenticating users with the serial name or the serial number I probably wouldn't be authenticating people with their name and pay attention to your support tickets we sent a couple support tickets in hope that they would address these issues never got addressed and then last up it's like if you end up screwing up like Ian said it's probably just to own up to it it's a if somebody submitted these things maybe it's time to address them there was also something in other some other thing that happened that was interesting throughout this whole process when I was sending them these emails I got or guess we got we got blacklisted our P.I. just got blacklisted now that makes no sense why would you blacklist somebody who sending you an email and I'm hacking a device that I have in my house those things on add up those are very separate things but that was whatever I could have also I give them the benefit of the doubt I actually give all these companies despite all the headaches the benefit of the doubt may have just been that we downloaded the firmware too many times may have just been that like we're a security company and it looked like fishy traffic it's all I think I I understand if those things happen I don't understand not addressing the issues that were reported so now I'm passing it over to Ian for the Nekir R9000 which is the last of last advice we're going to be looking at today and this one's really a doozy have fun Ian no idea so the R9000 holds a special place in my heart for good reasons and bad reasons we'll get to that so it's a flagship router by Nekir at the time that we did our research I think it was like the most expensive one they offered something like $350 to $500 it's aimed at like power users that sort of thing and as a rich feature set with all sorts of fun applications you can run on your router because you need to run applications on your router and it's administrate administered via a web app a mobile app and tell that if you cheat of course I cheat but it also has a bug bounty for vulnerability disclosure and only a bug bounty for vulnerability disclosure we'll get to get to how that kind of broke things in a minute so the web app you know it was kind of boring it's what we've seen a lot it's just basic authorization or like yeah basic authentication no clear by passes it's a form post but it has C serve protection it's very crappy C serve protection so if you want to break that probably can I highly recommend trying so I started poking at other things like the mobile API so it's a soap API which yeah you that it's not fun to work with those but it's it's different and as jwe based authentication which is it's okay but static analysis showed that it was a total minefield of command injection and command injection is one of my favorite things to do so that that instantly got me interested but sadly the API is terribly broken and unreliable and half of the end points just did not work at all so it kind of ended up being an uphill battle to do anything with this API but I still got off bypassing friends so we'll figure out how Eric have you ever like seen people using the exported for her much I've seen a lot of people use the exported for her I've never seen somebody use it properly so the exported for her it's a de facto standard it's so it's something that a lot of people have agreed on that it does it does x thing but it's not properly standardized but it's usually used by load balancers to convey a client's actual IP address to some sort of upstream service usually so it's also not as simple as a lot of people think it is so the exported for her is actually a list of IP addresses normally we only see it as a single IP address but it's designed so that when a load balancer or whatever that's working with this header receives a request it should prepend the IP address that it received that header from to the beginning of the list and also it doesn't have to be an IP address you can put whatever you like in this header and your load balancers probably just gonna stick an IP address on the front of it so a lot of people don't seem to realize this and it causes problems like what happens if they're just expecting an IP address and dumping that into a database and I put a little semicolon boy in there breaks things so how does this relate to our router well our soapy API interprets the exported for her why I honestly have no idea there is no reason that you should need the exported for her on your land again you're not talking to your router on your land for a load balancer that would be a hell of a router but static analysis also showed that the R9000 is probably the only neck your router or device that interprets exported for her I downloaded all the firmware that I could find unpacked it search through it and the R9000 was the only one with an instance of the exported for her that's also weird but what you know what can we do with it well here's a problem so htp requests are handled by CGI server and this is you htp deep that CGI server sends those requests down to a like a downstream process in this case net CGI is what handles all of our soap API requests so you htp d we'll take something in take your request turn all the headers into environment variables and then toss that down to a different process so net CGI uses the remote address environment variable to determine if a request is local and much like the buffalo it will whitelist itself so it can talk to itself without having to deal with authentication and normally the remote address environment variable is what you would want to use for this because it will be the actual IP address that that request came from in normal circumstances and even like if you try to change it like it's chances are you're not going to be able to mess with it however you htp d just replaces the remote address environment variable with the contents of the x4 to 4 header for some reason like I'm a complete re screw scrub I graph scrub and everything but even looking at the assembly I could tell that that's exactly what that did because it was like 10 lines of assembly and that was it so yes that's not good because if we can say that we're whatever IP address we want and it uses an IP address to determine if you should bypass on authentication why can't we bypass authentication well we can we just set we just set x4 to 4 colon 192 168.1.1 and suddenly we're an admin on the soap API and we can do whatever we like so thus cv e 2019 12 51 0 was born so I wasn't satisfied because you know off bypass isn't fun if you don't get a shell right so I got a shell cv e 2019 1 5 1 2 5 1 1 it's kind of big so I don't think we're going to focus on this shell because it's got a lot of fun challenges like it can only be 17 characters it has to be all capitalized all capitals it has to have a colon it has to have a single quote and then it's in my colon and you have comment out everything but if you want to talk about that talk to us later because we don't have time yeah before we get out before we get away from this one the interesting part was I even found the range header which is definitely an unexpected header so we're able to use the range header to say like alright well let's put the whole thing that we need in the header and then we'll reference that header in the xml body of that soap request and I guess we were just lucky that all those things happen to drive together yep when you're poking at CGI and you're trying to get weird command ejection payloads through the environment variables are very much your friend but I wasn't quite done yet because netgear has a very fun clause in their bug bounty if you can get remote unauthorized access to administer a netgear device via the internet not the LAN it will give you 15 grand I can buy a lot of ice cream with 15 grand so yeah I want that so I started looking into that so the soap API requires extra headers like for the soap requests and all that good stuff so XHR can set these but it's cross-origin so it'll have to pre-relate the requests and chances are the routers was going to slap that right out of the air so CSERF isn't going to happen so the device isn't exposed to any um it doesn't expose itself over the WAN at all so I was kind of out of luck at this point so I just kind of decided well guess I'll die I guess I'm not getting the 15k until two weeks later and I was taking a shower and my brain started just shouting dns rebinding and say two minutes later I figured out why the thing with dns rebinding is that it functions a lot like CSERF except it's seen as being the same origin so you can send whatever requests you like without having to deal with these pre-flighting um annoyances so yeah no more pre-flighting however it differs from CSERF and that we cannot send authentication in our case well dex-worded 4 is a de facto standard so can we just set that header and make ourself an admin well yes so that's what I did so it's not restricted so let's just build a payload so this is the workflow that I went with we have um the victim is anyone on the land they can be authenticated unauthenticated does not matter mobile devices does not matter they just wait for the dns ttl to wear out and then once it does I start issuing post requests via xhr with our auth bypass header to do the following we start to config change we enable qos we enable advance qs then we finish the config change and we pop a shell so we have to fire off five requests to enable a bunch of services and do configs and stuff but it actually only takes like 20 seconds to do all of that and then get a shell so just threw that into I think singularity and then it was off to the races uh so we started uh disclosure uh so we got 15k bounty didn't we rick yeah right although I appreciate the applause something we didn't get the bounty why was that Ian so you know how the our disclosure timelines have been pretty small up until now and we tab through the all this is half of our disclosure timeline we just put the important bits in here so let's go through some of the uh more important ones on 10.03 or 18 10.03 we submitted all our all of our vulnerabilities through bug crowd because that was the only disclosure avenue that we had uh so we got an award for cross-site scripting via the Xorted 4 header a completely different issue that was rather low severity so that was nice uh but we didn't hear anything else for two months uh until next year stated that they can't reproduce the command injection issue and they had in the meantime released new firmware uh and asked us to test again and record the uh proof concept so they could figure out what they were doing um so we did that you know we verified that yes I can still get root remotely um and I gave them a nice video so they marked the command injection exploit as triaged which was nice uh that was a little over two months after the initial release uh and then about a month after that they released the firmware um 1.0.4.26 uh they didn't tell us about that they just released it and then about a month after that or half a month or so I got a hunch that you know I think they fixed everything without telling us or giving us rewards so I checked and they had so we confronted them and they marked everything as unresolved and gave us degraded rewards like you know that command injection north bypass that lets you do admin and everything totally not critical totally um so whatever that's fine we just wanted to disclose the issues we're not actually going for the money although it would be nice so we asked for cvs because net gear is a or it was a um cv numbering authority so they should be giving us cvs for their products uh and they just didn't respond and then something like a month later we asked for cvs again and they said we're not doing cvs anymore okay then why are you with cna so we contact mitre to get cvs and they say we'll give you cvs once we know that net gear is not a cna two months later almost like what half a year over eight eight months since we started the disclosure timeline we got our cvs from mitre and surprise or unsurprisingly net gear was no longer on the list of cna's so that was fun anything to add rick well i got plenty to add so one of the things that i guess was really problematic about all this was that when we reported all these vulnerabilities through bug crowd to net gear all that time went by and they were just not fixing the issues they weren't admiring that we had sent them the issues over i can i blame both net gear and bug crowd for the situation because we had responsibly disclosed all these vulnerabilities through them and this was the first time ever i think both of us have ever seen bug crowd put a blocker not on the researcher but on the company for not addressing the issues that we had sent over net gear had also put us in a position that we thought that all right cool if we could have easily send them these issues separately and they could have been addressed and the dns for binding was just kind of a nice feature that we knew or i guess a nice way to chain all the things together to get unauthenticated command injection on this device would i guess 20 seconds of user interaction the thing about it is that we would i feel i can't help but feel that i ended up being lied to as a researcher especially from the fact that we meet we met all the requirements of their program and we didn't get what they were promised that they were going to give us that's beside the points i guess kind of water under the bridge at this point in the summary so in general like i highly recommend if you're doing anything with web applications use the x forwarded foreheader it is a very fun header to mess with you can get command injection sql injection a lot of sql injection you're tainting logs all sorts of good stuff like that and cmdi like yeah it'll it'll find a way if even if it's you know four seventeen characters and mangled to all hell you're still going to get command injection you just have to try hard enough so again environment variables are your friend dns rebinding is remarkably powerful this was the first time that i used it and it kind of blew my mind because suddenly all these attacks that require you know authentication tokens or um require bypassing um c-surf protection become extremely easy to do as long as you don't have to worry about authentication and like yeah if you have a bug bounty please communicate with us don't just leave us sitting there for two months five times um and if you stop providing service communicate you can like say hey we're not a cv uh cna anymore um and also like communicate in general it's nice um and for bug bounties we found out a few times now that bug bounty bug bounty programs like the companies don't have much of an incentive to treat researchers fairly they can just say no and you can't really do much there's no incentive for them to not not really do that aside from just people getting angry um and bug bounties probably shouldn't replace your security contacts we would not have gone through the bug bounty if we didn't have to but that was their only security contact that that was the only way that we had so that's just how it ended uh i guess anything to add rick no that's kind of it i know we're definitely over time so we're just going to run through these conclusions and answer some questions at the end for the quick conclusions these were the things that were different from when we conducted a research project in 2013 in 2013 most of the shells that we ended up getting were through c-surf we found out now i think it's more that our security research in general has gotten to a spot where it's more it's easier to get a hand of different ways to bypass checks especially authentication checks so in this case we didn't need to use c-surf for any of these we just use a lot of authentication bypasses one of the things that was nice now that we didn't see in 2013 is that in 2013 a lot of the devices had executable stacks we found uh i think two buffer workflows in in one of the asus routers that we hacked those did not have an executable stack so we had to do rob and a bunch of other like really fancy stuff to eventually get a shell that was not the case in 2013 where just pretty much it was the bottom of the barrel with regards security on software packages really out of date in 2013 they're really not that much anymore one of the bugs that we found a lot in that study was that smb was horribly out of date so you could do some link traversal that's really not the case anymore for a lot of these it's pretty it's much more up to date and i guess nicer from both the securities perspective because you get to try to find new interesting security vulnerabilities instead of these old ones and before we didn't see any publicly documented security contacts a lot of the times we were just emailing people that we found the LinkedIn now we we did see some manufacturers for example asus terramaster, Synology, QNAP a lot of these companies actually tried their best to ensure that the vulnerabilities that we were disclosing were getting addressed and publicly documented uh like disclosure outlets the two that i mentioned that i think were the ones that made me the happiest were QNAP and Synology yeah QNAP and Synology were very good about all the issues that were reported to them as soon as we reported them they responded within the a day or two and they addressed the issues and they had us checked to make sure that everything was good let's find that we'll stay the same devices are still remotely exploitable given the 125 cvs that we found i think that's pretty easy to understand um there's still plenty of c-surf not like i said in the previous slide before we were using that for the exploit chain for a lot of the stuff now we don't need to use it as much because we found a lot about a lot of authentication bypasses OS command injection is still a problem that's probably one of the vulnerabilities that we focused on this time around and security obscurity is still alive and well we looked at a lot of manufacturers that the way that they would do stuff it's like they would try to do their own type of encryption or their own type of like set or file host things so that it would become kind of problematic but it wasn't in the end and here's some of the stuff that stayed the same for or like it's like what changed but stayed the same in manufacturers some manufacturers actually really care i've been talking about Synology and QNAP a lot not because i know anybody there but it's because i was really happy with the disclosure process xiaomi too yeah oh yeah xiaomi was another one that was very good i i think that's how you say it right i don't know the xiaomi did a very good job of addressing the issues that we disclosed there they have an interesting bug money program they don't they they paid us in toys never had that happen before and um even as a child and a lot of the companies have bug money programs needless to say i'm not very happy with companies like necker who were partnering with bug card and they ended up in the situation where we feel cheated but a lot of other companies they'd actually pay out their bug bounties and i'm happy for that and some companies are really interested in working with researchers to get things addressed a lot of the stuff that we reported they were very much happy of understanding they wanted to know how did you guys find they what did you do do you think that we have more instances can you check also it's free work so why not but it's a really nice situation where they want care about the security and they're trying their best to improve it and that's kind of it folks these are me and ian's twitter me and ian's twitter and well we also love talking shop we're going to be at the village for the rest of the day until sunday we'll be here we'll leave eventually but the this was a very good experience and this was the results of our three of the best results from our research project the two other people that weren't able to present with us today that's josh mire and shah marani those guys found a lot of other vulnerabilities and it was great to work with them thanks for your time and i'll open the floor up to questions if any of you have anything to say or ask