Living Forever In The Internet Of E-Waste by Darren Martyn

all right hello everyone um so firstly uh obviously opinions expressed don't represent my employer or Cisco um Cisco may be a little upset about a few things but so I'm Darren I'm a full-time caretaker and a fantastic company called cybermax um all the material from this talk will be on the full spectrum.dev website just after the talk or actually maybe slightly before um scheduled posting and all that um but yeah so um I had a there's a question I've had for a while it's like what makes the best the absolute the best exploit and it's like you want it to be remote you want no authentication requirements you want privileged code execution so like Rooter admin um and ideally you want to get stuff like persistence for free and it's even better if the bug is unpatchable right well Cisco dropped one of these lovely absolute Chad tier s tier bugs in our lap with uh well it's got a CBS sub 10. I actually don't know how CVSs Works um but when I take the tiki boxes it came out to a 10. um so Cisco announced that there's this bug in some of their end of life um ATA devices uh the spa series that permits a remote unauthenticated user to just remotely [ __ ] override the firmware and like gain persistent code execution forever and they're like yeah the products aren't alive we're not fixing this and I was like that sounds great so but like there's no there's no patch to diff so let's go you know this talks about the process of like reverse engineering it and writing an exploit for the thing and like making all the nice things happen and I want to you know I was like okay cool we've got like an exploit that gives like living forever inside people's networks where their only mitigation is to unplug the device and Chuck it in the bin which annoys me a bit um this was the advisory it was um they're like oh blah blah um on the fence Gator remote attacker could execute arbitrary code which I think is the understatement of the year because what they actually mean is they can overwrite the firmware of the device and just like become the device you know you're God now and they were like oh it's a missing authentication check in the firmware update process and I was like right okay cool that tells me a little bit and the Cisco were like oh this has not been exploded in the wild don't worry it's fine um please upgrade to our device which is going to be end of life next year um so you know buy more [ __ ] to deal with the old [ __ ] and then presumably next year they'll have a new little box that like you have to buy to replace the box that just went out of support um so I love these end Life Products things um because they're great like you know it's like oh there's no fix and I went and looked on the internet there is about six and a half thousand these exposed publicly to the internet these are more common inside networks like you'll find some networks that have done testing on you'll find like dozens of these one on every desk but sometimes some idiot like lets one through the firewall and out exposed um so if the 6000 exposed the internet I estimate there's probably like 20 times more like deployed everywhere probably a hundred times more these are quite popular devices um so to come up with a plan uh like what was I gonna do when I read this advisory and I was like I want to do something with this and I was like so to find the firmware I'm gonna have to reverse engineer the firmware I'm gonna have to find the mug we're gonna have to build some kind of back door for the thing uh we're gonna have to build a firmer image with the back door to put on the device and then I'm going to make the whole Rube Goldberg machine of [ __ ] work so that I get code execution and then you can't get rid of me off the device you know I'll be able to live forever on the device because I can do nasty things like patch out the firmware update function so you can't just update to a known good um so you know it's permafucked [Music] so finding the firmware this this was weird so the one of the problems that Cisco is Cisco are really really crap at like letting you download firmware for stuff but for some reason this device is firmware I was able to actually pull from their website um at the time that I was writing this so it might be there like next week because Cisco tends to delete crap off their website that they don't support anymore and a lot of their stuff is behind a login wall so if you do have a Cisco login and you can download firmware for stuff just start downloading and upload archive.org um I'm telling you but please do like please start archiving this stuff because they do tend to delete it which makes vulnerability research on it really hard um so unpacking the firmware it was less hard than I thought so bin walk kind of did an okay job that I did have a screenshot for this but it was completely [ __ ] unreadable um it's just a like a wall of text but like bin walk with the dash M and dash e arguments was able to extract some of it then I'd use um like Sasquatch to unpack the swash fs file um I was hoping to use a tool called backhand for that but it didn't support the like custom squash FS they used at the time um unblock actually worked better than bin walk for this but you know so the firmer structure it turns out was documented by a nice person called Big Nerd 95 a few years ago by the pleasure of meeting them a few years ago to conference um they're an absolute genius they were hoping to get open wrt onto a related device so they had uh they'd like you know done a bunch of reverse engineering work on it documenting like the weird firmware structure in the header which saved me a shitload of time because I was sitting there going oh god um so they'd done reverse engineering the spa232d which is a related device that looks almost [ __ ] identical um I found that the their work also applied to the 112 and one two two um which were the one more two is one of the advisory is for and they all used kind of similar samish Sami firmware so they released two called Paint image editor which allows you to write patches for the firmware like you can unpack it and repack it with stuff which saved me a shitload of time so the firmware structure is um it's got like a header and then you've got module headers and then you've got module data and the only important bit really is the header bit the rest just like you can kind of Cobble together by like cutting files together so the firmware header bit has this firmer magic string at the start which becomes a little bit interesting in a bit and the only real check it has is an md5 sum of the header and the module headers so there's no like code signing there's no like Integrity checking beyond the md5 being used to like make sure the data isn't corrupted um so the obvious thing was go buy some buy some stuff so I just went to flea Bay and 50 Quid later um a device landed and then another 50 Quid another device land you know you know how it goes you end up with a bunch of garbage um my original plan was to start taking part advice to find if there's like a UR header or something um which I kind of started doing and then kind of forgot because I ended up just writing the [ __ ] exploit and owning the thing before I could finish like doing all the documentation that but you can see this is the like some of you may be familiar with this this kind of this device this contraption it's what it's for is it sits on your desk and you plug a shitty old plain old telephone into it and it turns it into a VoIP capable desk phone and is this the one one two um just like what's inside it um there is kind of a like over on that side over on the far side of it there is kind of four pins that I think might be uart but I haven't actually checked yet um because I got distracted um and then you've like you know you have a couple of ports like on the one more two You've Won ethernet port your power your phone one phone two and there's an empty slot on the board which I'll actually just go back to there's like an empty space where you could put another um ethernet in which is interesting because on the 232d you have two ethernet ports so like they're you know reusing the same same everything same bill of materials the 232d is kind of interesting because it also does dact for like the cordless handsets so it's got like a bunch of radio gubbins inside um that I haven't gotten around playing with yet um so like there's possibly Radio phone there's a thing that looks like you are there's you know there's a so the what the 232d and the one two two have two ethernet ports because it not only acts as a phone to sip VoIP converter but it also acts as a router so you plug your workstation into one end and the other end goes into like the one port on your cable modem or whatever or you know see it it sits in the middle between a user's workstation and the internet which gets quite interesting in a little bit so what happened next was like I had the firm room packs and I had some devices but and I had an idea that there would you know that there's this vulnerability that exists and I knew that it was going to be the web server so after like just kind of staring at it for a while I knew it was going to be something in the HPD binary so we started looking at that and originally it was going to post a load of decompiler screenshots but nobody could [ __ ] read them so um yeah so the process of reverse engineering this was pretty much the same as anyone who's you know [ __ ] around the binary reverse engineering knows it's like you look for some stuff you like search for Strings you do your cross reference thingy at the decompile button you stare at it you go this tells me absolutely nothing you curl up a little ball in the corner and cry for a while then you go back and you hit the decompile button again and you know you go around in circles and eventually you see the thing you're looking for um so what we actually learned from staring at the web server binary was a bunch of stuff so it has this authenticity authentication checking function which doesn't actually get called all the time for all the endpoints so all the CGI endpoints are like in a like a a big you know big load of code and only some of them actually call the auth check so and it's a auth check you know um and the upgrade function interestingly the one that's like slash upgrade.cgi doesn't actually ever call the authentication check it does call to see if it's if the request coming from the WAN port or the Lan Port but that call doesn't actually do anything because it's not actually checking the auth so I figured at this point it was like we could just try to see what happens when we do the firmware upgrade so gotta burp didn't upgrade with the legitimate firmware file and started looking at all the parameters in the post request and I was like so we've got session ID in the get session ID and the refer and the session ID post parameter a bunch of other [ __ ] that doesn't really matter and then there's the firmware file as like a file and I was like will the stupidest [ __ ] thing work well it turns out if you just delete all those authorization headers and parameters it just [ __ ] lets it go through anyways like it doesn't matter so you you end up um you know it just it just works so that was exciting so to back door the firmer image what we do is we to carve out the squash FS thing from the firmware blob and then unpack the squash FS file add a arm V4 like telnet D or like tiny shell or your backdoor choice in just add a call to it from a net script add you know whatever tools you want on the box at the same time like if you want TCP Dom if you want a debug or whatever just put them in and then re-pack the squash FS file back up which there are tools for because Cisco had to release the source for their modified version of squash FS because the GPL and stuff so you can actually get like the correct Packer to recompress it directly from like Cisco upload to [ __ ] Source Forge or something um and then you use a modified version to pay an image editor to rebuild the firmware image sticking the you know gluing the headers back on like concatenating the thing I've written a lengthy blog post about this because it doesn't really translate well into slides um like showing all the steps [Music] so the question is does it work um zero to python script that does uploads and arbitrary firmware blob to the device uh without all and it's got this there's this Awkward Moment where when you run the script the device has to reboot and you wait like two minutes going [ __ ] [ __ ] [ __ ] have I ripped it have I bricked it have I just made like you know and yes it does work you you get a root shell of the device that persists across reboots and it even persists across hitting the factory reset pin on the back um and also the thing I noticed was it doesn't break the configuration of the device the device config is stored in nvram and when you reflash the device it pulls the config back out of the nvram so like you won't cause an interruption of service Beyond like two minutes where the device just rebooting and re-flashing itself well I was like okay so if x112 which what Cisco said Cisco were like this only really affects the 112 and I was like Cisco [ __ ] lie oh look it works on the 122 as well one they didn't didn't admit it was affected and oh look also the 232 is affected it's like come on guys you know it's not hard Cisco surely know where they've put their shitty software in like all their products they surely know where like they it shouldn't be up to somebody like me to go like buy a bunch of their crap and like take it apart to like figure out which ones are affected or not it's something they should be capable of doing in-house but apparently no so I stopped off to three because I live in a house with another person and they get really pissy if I started having Stacks and stacks and stacks of Cisco garbage filling up the whole house you know three or four was bad enough but like beyond that you know it might have caused problems but a thing I noticed with Cisco they they reuse code all over the shop and I got a hold of firmware for the wrp 500 and the spa eight thousand um and they kind of look really similar I haven't put enough time in yet they use slightly different things like Wonder Muses jff S2 for the file system says squash FS but all the all the crap in it looks the same um you know different but the same but when I was reversing the upgrade function I noticed this so in the upgrade function it's got this like check for the the magic at the start of the firmware image and the magic varies across devices because some of them helpfully have they've all got this weird like upper lowercase firmware like firmware or whatever but some of them like we now know that the SRP 520 by 40 uh the whatever the [ __ ] a vs510w is they all use the same upgrade binary which means they're vulnerable I just have to you know go get one and like get firmer images for them to prove it but like these are just the ones they admit to like the these are just ones that like the you can tell are affected by like looking in the in the code of one that like it's readers and others but there's a whole bunch there's an Untold number of other devices which use this hate and firmware thing use the same patent firmware updater which is garbage and doesn't check for authentication so you know it could affect like dozens or hundreds of devices um so I also I went and checked the s p 520 is end of life and the support and more than likely vulnerable but I can't really be bothered buying one yet the 540 yep [ __ ] it just throw that in the bin as well and next we get up so like you know the next part is about payload selection so spawning a telnet shell of the device is nice and all but it's kind of useless in like real world you know hacking so the criteria had was the connection needs to be encrypted because you know if you're using this live you don't want to expose your customers blah blah blah it needs to be either so like then there's the question of like how you want your thing to connect back to you or do you want to connect to it um and that depends on network position network topology and then there's the features you want generally I want like a fully functional shell so if I hit Ctrl C I don't lose my shell on the box because that's embarrassing but I also like stuff like file transfer and socks proxies because if this device is a network Edge you can pivot in and start [ __ ] with active director and stuff um but the other the big one is can you cross compiler for arm and that's where I lost several weekends and many nights and the other limitations are these devices are like the CPU is trash they've got [ __ ] all Ram they've got bugger All Storage it has to be statically linked for arm and because they have so little storage you can't like use tools written in go or rust because the binaries are so big that you don't have flash space for them so that has to be stuff written in C and then this is your connectivity constraints so if the device at the network Edge you can use stuff like a bind shell or Port knocking um and that's kind of Ideal otherwise you need something that beacons out um and that's more common is that you know it's going to be device behind that where you don't have a direct thing to it um so I made this terrible diagram which shows like the connectivity of with the 112. so with the 112 your shell will live somewhere there where you're adjacent to user workstations whereas with the one two two and two three do you will actually be Upstream of users workstations which becomes quite interesting because if your network adjacent you're not the [ __ ] in the middle you're on the side so you're not going to be Upstream so like you're going to do spoofing and stuff to do like pocket sniffing whereas if you're in the Upstream position with say if you're the on the one two two or the two two three two D you are in between user workstations and the internet so you can just sit there and sniff traffic and you can probably also sniff like the phone calls and stuff um so after considerable pain I managed to cross compile Tzu TCP dump for the [ __ ] thing get it working so I could do Upstream sniffing and I did have a demo for this but it didn't work properly so I'm gonna post it next week but what you can do is you can write a script that lives on the device that will sniff traffic upload it to your C2 on a loop so you you basically have a wiretap um which I think is pretty [ __ ] cool um like your wires hopping their phones and their workstations at the same time forever um so when it came down to like the back door thing ended up using crash by um what I call stealth and it offers all the features you want it's written in C it compiles really small it's really nice it's super awesome the problem is that it relies on opensl and if anybody here has ever tried cross compile stuff use opensl they will know the pain and suffering ended up getting that working so you end up with a persistent connect back shell that gives you the ability to do socks proxying and pivoting Etc I also end up putting together a simple Beacon and sea with curl um this was a terrible idea but um I actually got gbt to write a bunch of the code I actually need to publish that next week because it's on a machine at home um all simple Beacon for the Cisco Spa does is it it can either run commands it can like launch crash with a config file or it can like dump the NV RAM and upload it because the nvram stuff is kind of interesting it was somebody from see you tell that I talked on Twitter a while back mentioned that the Sip credentials like the device stores zip credentials for like whatever outbound zip thing it uses and there's the possibility if I can figure it away because I know where the zip credentials live they're j