researcher accidentally finds 0-day affecting his entire internet service provider

the amount of trust that we put into devices we use every day is absolutely insane in this video we're going to talk about a crazy story where a security researcher found a way that he could not only hack into his own modem but literally any modem that anybody used in his entire isp's network also if you're new here hi my name is the love learning I make videos about software security and cyber security so if you're new here or just want to hang out with me hit that sub button two years ago something very strange happened to me while I was working for my home network this guy was doing pen testing right and he had this blind xxc which is he's allowed to inject arbitrary XML and then use that to run command execution and for it to happen he had to have a different endpoint that he could point and download HTTP files from so we went up on AWS and spun Up This Server here and once the web server was running I sent a curl request from my home computer to make sure that it could receive external HTTP requests so he he sent this request to the server and then just a few seconds later I saw the following log so you know this is him tracing out the the logs of that server and you can see that this is his get request this is his curl request to that server perfect this meant that I was able to receive Network traffic on the box everything seemed good to go but right as I switched back to exploiting the vulnerability something very unexpected appeared in my log file so you see his initial request here and then there's a second request coming from a different IP address that was not his he runs his initial request you see his request hit the box and then the exact same request hits the box from a different IP address that is not his very suspicious all right an unknown IP address had replayed the exact same HTTP request just 10 seconds later wow that's seriously weird I thought somewhere between my home network and AWS someone had intercepted and replayed by HTTP traffic the traffic should not be accessible there is no intermediary between these two systems who should have seen this my intermediate thought was that my computer had been hacked and that the hacker was actively monitoring my traffic he has his box he has AWS he's thinking that there's somebody in a box in the middle that can go in and see all of his stuff now to check if this Behavior occurred on a different device I pulled out my iPhone so originally he was on his computer at his house homie pulls out his iPhone and he typed in the URL to Safari and he sent the request and peaked at his log file so again this is his request uh and then this is the same IP address doing the same replay attack so it's not just his computer that could be hacked it's also his iPhone the same unknown IP address had intercepted and replayed both HTTP requests from my computer and my iPhone somehow somebody was intercepting and replaying the web traffic from likely every single device on my home network so then from a security standpoint what does that mean either literally every device in your house is compromised by the same pie of malware or someone in the middle is snooping on your traffic or a device in the middle is compromised it's a bit of a foreshadow you'll see later in the video so panicked I spun up a new AWS box running engine X to make sure that the original instance had not been compromised somehow so now he's thinking like okay was it that the server I was on that got hacked so we made a new box made engine X so not python just a regular engine X server did the same thing from his iPhone and saw the exact same log so someone is sniffing on his data coming out of his house has nothing to do with that AWS instance it's literally just if it's coming out of my house someone is replaying it so something crazy is going on here through what could only be my ISP my modem foreshadowing or AWS being compromised someone was intercepting and replaying my HTTP traffic immediately after I sent it to eliminate the Absurd idea that AWS had been compromised I spun up a box on gcp instead another cloud provider and observed the same unknown IP address replaying my HTTP requests so it wasn't AWS the only real option left was that my modem had been hacked but who was the attacker I quered the owner of the IP address and found that it belonged to digital ocean strange it definitely didn't belong to my ISP to kick off an investigation I sent the IP address to some friends who worked for threat intelligence companies they sent me a link to the virus total listing for the IP address which detailed all of the domains which resolved the IP address over the years and this was odd the IP address just one year prior was being used to host fishing infrastructure that targeted a South American cyber security company assuming that they had been in control of this IP address for 3 years it would mean that they had had used it for at least two different fishing campaigns and is what appeared to be a CNC server for router malware so again this guy is thinking that his modem has been compromised and this IP address which resolves to is Glam or whatever is being used to C2 that malware so okay something weird is going on here handing over the evidence the modem that I've been using was the Cox panoramic Wi-Fi Gateway after learning that it was likely compromised I went to the local door to show them my device and ask for a new one the one issue with this request was that in order for me to receive a new modem I had hand over the old one sadly it wasn't actually my property I was only renting it from the ISP so classic ISP move where they put a device in your house your device gets hacked and when you want to look at it they're like sorry that's not actually your device we need to to get it back um I explained to the employee how I wanted to keep it and reverse engineer the device their eyes shot up a little bit they were much less enthusiastic about giving it back to me this is like they he went to a Cox store and literally there a guy making like $18 an hour and this and Sam Curry is like I literally have uncovered a malware campaign that's targeting your ISP modem like you have to let me keep this and the guy is like running his checklist and it's like uh it says I'm not allowed to let you do that and so that's just like what happens um there's no way I can keep it question mark I asked no we need to take your old one and give you a new one the ISP representative said again Steve he's at the end of his 8 hour shift he's an hour and a half in and there's no budging as much as I wanted to take it apart dump the firmware and see if there's any trace of what ever potentially compromised it I had already passed the device off to the employee I took my new device and left the store disappointed that I wasn't able to do anything more with it after setting up my new modem the previous Behavior completely stopped my traffic was no longer being replayed there was no other IP in the logs everything seemed fixed so guy is getting his internet traffic replayed thinks it's the modem gives the modem to Cox Cox gives him a new modem traffic stops so without a doubt there was a piece of malware living in his Cox ISP modem if I say Cox again I think I'm going to get demonetized Cox three years later so this is like in one of those movies where you you you see people they have some event happen to them and they they they know they they have to go through some traumatic life event and three years later they figure it out this is literally what happened so this guy is doing this research on his home device getting hacked getting his his Coxs hacked and then 3 years later he figures out a way to get through it three years later in early 2024 almost 3 years later I was on vacation with some friends who also worked in cyber security we were having a conversation over dinner when I explained the story to them curious to learn more they asked me for all the details and thought it'd be fun to run their own investigation the first thing that caught their attention having worked on more malware analysis a lot more than I had was the format of the two mail server domains so it's you know it's this and they're saying that basically every uh every single domain that was registered by the discovered IP address use the same naming convention so you have word six numbers and a top level domain due to the mass number of domains and algorithmic structure of the registered addresses this appeared to be a domain generation algorithm used by Mau operators to rotate the resolving address for the CNC server for the purpose of obfuscation so basically they're trying to make sure that you can't get you don't you don't have a good pattern of life on the DNS record for that IP address there's a good chance the IP address replaying my traffic was a CNC server and the two domains where I thought there were mail servers were actually algorithmically generated pointers to the CNC server something disappointing was that all of these domains were historical the last one scene was registered in March 17 2023 none of the hosts resolved anything anymore and we couldn't seem to identify anything similar being anything similar being registered to the same IP Address given that my new modem was the same model that had been compromised I was curious if the attacker had found a way back in from a quick Google search I discovered that there was no public vulnerabilities of the model of the modem that I had the other option was seemed more and more likely that they had exploited something outside of a generic router exploit I was super curious to investigate this and try to brainstorm ways my device could have been compromised so this is where the article gets absolutely insane so things start to get pretty crazy here because the this is where the tr69 protocol and the idea of an ISP being able to remotely control your device comes into play but effectively if you've ever had an ISP like work with your house they can remotely control the device that they give you when they set up your internet so if you have like a Verizon router right you plug an ethernet cable into that Verizon router and the ISP can completely remotely control it right something about that smells Incorrect and if it's not implemented correctly bad things can happen and are those end points TLS encrypted last loyal Raven let me tell you the answer is no and you're about to find out uh why in this chat targeting rest apis using the tr69 nice protocol after getting back home a close friend had asked if I had been able to help him move furniture into his new house what this also meant was helping him transfer over his Cox modem after connecting his device to the fiber line I went ahead and called the ISP support and asked they'd be able to push out an update to allow the device to work in a new location the agent confirmed that they could remotely update the device settings including changing the Wi-Fi password and viewing the connected devices now again this is where things get weird man like it makes sense that your ISP can help fix your device can update the firmware but the question is like how are they doing that and what is preventing one person from doing that and not the rest of the world right how why is the ISP special now the ability of support agents to control devices really interested me especially since they could update pretty much anything on the device this extensive access is facilitated by a protocol known as tr69 implemented in 04 which allowed isbs to manage devices within their own network via Port 7547 this protocol had already been the subject of a few great tfon talks and wasn't externally exposed so I wasn't super interested in bug hunting that protocol itself so typically these isps are able to have different planes of management where even though the port is open you can't hit it from the outside only the ISP can so in theory that's not a great attack service which is why Sam didn't go after it the theory craft a little bit if I were a hacker who wanted to compromise my modem I'd likely Target whatever infrastructure powered the support tools that the agents were using there were probably some internal website for device management that support agents used backed by an API that could execute arbitrary commands and change view administrative settings on customer devices foreshadowing if I could find some way to access this functionality it might shed light on how I might have been originally hacked and Patch out at least one method for somebody to compromise my modem the first thing that I decided to do was look at the Cox Business portal this app had a ton of interesting functionality to remotely manage devices set firewall rules and monitor Network traffic now you see there's a basic login portal here and again this isn't internal to his house this is just a regular page you can log into and again like basically behind this wall of off if implemented incorrectly could be a way to touch every modem that exists on Cox's Network without actually having a Cox business account myself I opened the login page for the portal and grabbed a copy of main. this that powered the core functionality of the app after beautifying it I parsed out all the routes and scrolled through them so this guy traditional hacker stuff you're doing web web exploitation you have all these JavaScript files that are coded to reach out and touch certain endpoints okay so let's see what those endpoints do and you see we have here API voicemail transcribe message user roles verify contact validate and the Assumption guys is that these are going to be authenticated right these are these are uh API endpoints that are going to behind some kind of off token that you as a regular user don't have there were over a 100 different API calls that all had the same base path of API cbma since this route seemed to power most device related functionality I thought it was worth investigating if the API cbma endpoint happened to be a reverse proxy to another host I tested this by sending the following requests HTTP requests that does not start with apmi cbma returns a 301 so that's a redirect HTTP requests that does start with API cbma returns 500 so from sending the above requests we learn that API cbma endpoint is an explicit route that is likely a reverse proxy to another host due to the differing Behavior between the HTTP responses basically this is a blind test where he has a hypothesis and he tests it by running two commands and between the two commands he gets result a and result B and by doing that he's able to prove that the back end is just a reverse proxy and when it can't connect you get a server error so since the API itself had all the interesting device management functionality it made sense to focus on everything behind the API cbma route and see if there was any lwh hanging fruit like exposed actuators API documentation or any directory tral vulnerabilities that would allow us to escalate permission so right now he's trying to see what can I what can I touch I went ahead and proxy the registration request for the coxm portal which is underneath the API cpma request so basically he is going to validate an email address uh request to this this endpoint right he's basically testing can I proxy arbitrary requests through API cbma to run these functions right so he's running the validate email V1 on email test example.com and it says okay message success so the HTTP request contained a bunch of different authorization headers including what looked to be a generic use API key that was shared between users client ID and the CB session Keys looked very custom and indicated there were multiple roles and permissions using the application the HTTP response look like a generic spring response and we can likely quickly confirm that the backend API was running Spring by simply changing the post to get and observing the response so again basic hacker stuff he has a hypothesis you change one variable does that return response you expect and by changing the get to a post he gets another 500 error which means that he now knows it is a spring related error a spring is a a server type that is very common to host these AP these rest end points now since we could confirm that the reverse proxy was running spring I decided to look for actuators and exposed API docs I went ah went ahead and tried the uh actuator route and again these are all just spring internals so now that he knows the type of framework that is being used here he can follow the patterns that that framework typically uses and get some kind of information out of it right so he's trying to enumerate all the actuators trying to enumerate all the documentation and eventually he does hit a Swagger UI index with HTML So eventually what happens here he's able to enumerate these API end points and he sees literally by doing this he's able to see all 700 different API calls the Swagger routes had loaded I use the same trick to load all the Swagger docks on all the other API endpoints and in total there were 700 different API calls with each AP Pi having the following number of calls and these are literally every endpoint that is exposed on the Cox Business Network yeah so this is this is where the article takes a wild turn so here it's looking like oh the API Dev forgot to turn off swagger like Swagger went to prod so now you can see all the end points oh boohoo but surely the authentication is good I mean surely you need to have an access key that only an admin can have to get into this thing right accidentally discovering an authorization bypass on the Cox's backend API after the Intruder scan of all the API endpoints completed I scrolled through to see if any had any interesting responses the following profile search endpoint had an interesting HTTP response which appeared to be a blank Json object from what looked like to be an empty search so he searched for profile search he did not provide any data and because there was no data he got a response back that said success zero hits so looking at the JavaScript it seemed that we needed to add an argument to the URI for a profile to search for he added that ur ur U and searched test in the URI and got the following response message authorization error invalid user token invalid user token but I had just been able to hit this endpoint I removed the word test from the URI resent the request and another authorization error for some reason the original endpoint without parameters was now returning an authorization error even though I just hit it when running Intruder I did a sanity check and confirmed that nothing had changed between my requested Intruder and the repeater request I replayed the request one more time but surprisingly this time it gave me the original 200 okay and the Json response from Intruder what was going on it seemed to be intermittently giving me authorization errors and then saying the request have been successful so what it sounds like is internal in this system there are multiple servers and it's doing like round robin load balancing and every once in a while he is hitting a server where the authorization is just not correctly set up like it is just a naked server that anyone can go in and and touch the endpoints without a user token now this may be because there's some weird caching issue going on where maybe someone somewhere else made a successful request and then there's like a knat translation in the Middle where like it sees that authorization session coming from the right server but either way this person is able to run these queries by typing in uh by by doing a profile search and they you know they redacted all this but to test it I could if to test if I could reproduce this with an actual search query I wrote down Cox in the URI and replayed the request two or three more times so I got the following response and he got success he got 10,000 hits and he G gave him a search list and even crazier these looked like profiles of Cox Business customers not really expecting results I replaced the word Cox with FBI to see if it was polling actual customer data and you're you're seeing there's FBI redacted FBI redacted FBI redacted the above response contained the physical addresses of several FBI field offices who were Cox's business customers the administrative customer search API was working not good so he not only found an API he thought oh I don't have off on this API surely it's just a test API where there's not real data behind it and so as kind of a joke he puts FBI into the search and he got legit like FBI sites in the request uh so we had confirmed there was an off bypass for the API endpoints by simply replaying the HTTP request multiple times and there were over 78 API requests that we could hit it was time to see what the real impact was and this is where the article kind of like boils to the top and you can just smell the the hacker Grease the hacker Essence not the hacker grease Sam's a great guy I looked back at the results of the Intruder scan not know or now knowing that I could bypass authorization by simply replaying a request in order to figure out if this vulnerability could have been used to hack my modem I needed to know if this API had access to the residential Network at an Access Control level Cox offered both residential and business services under the hood I was guessing the underlying API had access to both I went ahead and pulled out the simplest looking request that took in a MAC address parameter to test if I could access my own modem via the API and I I just think this article is crazy because it goes from zero to 100 so fast dude it goes from uh I can query if a profile exists in the Cox database to uh I'm going to see if I can change settings on my modem via the MAC address like what this was a get request to retrieve a modem IP address that required a MAC address parameter I logged into Cox retrieve my own Mac address and then hit the HTP request over and over again until it returned 200 okay so it returned this right and so what is this this request is account equipment V1 equipment he puts in his account number and it returns a list of all the Cox's equipment that is on premises at this guy's house it worked my connected equipment was returned in the HTTP response so like by using his Mac address and Uno he was able to query if he had oh a Cox Business TV uh a telephony device a Cisco router a Cisco phone a Nokia on a fiber Network transmitter like yeah dude it it's crazy accessing and updating any Cox Business customer account to test if this could reabuse the access and modifi business customer accounts I found an API request which could query customers via email I sent the following HTTP request and saw the following response so we put API this whole thing trying to query what the user data is and he put admin cox.net and he got legitimate data he redacted a lot of it being a good a good responsible hacker um but yeah this guy like was able to use the endpoint and he literally queried admin cox.net and other similar post uh account update requests worked so he was able to read and write business accounts another similar post account update uh worked and we already read this so at this point I demonstrated it was possible to one search a customer and retrieve their business account pii using only their name two retrieve the Mac addresses of connected Hardware on their account and then three run commands against that Mac address via the API so you can completely not only enumerate your network but run commands via Mac address it's not rce yet someone just said in chat retrieve crypto private keys so if this were done properly this would be okay if there were a a a keying scheme where the company had a private key the other end had a public key you signed the request with the with the private key and then you decrypt it you verify the digital signature and you say okay it came from the ISP overriding anyone's device settings via leaked cryptographic secret and looking through the Swagger docs it seemed that every Hardware modification request for example update device password required a parameter called encrypted value if I could find a way to generate this value then I could demonstrate right access to modems that would lead to remote code execution now again in terms of basic cryptographic Primitives if you know how cryptography works works if you are trying to authenticate that a response came from your ISP you would use a signing scheme a signing scheme uses asymmetric cryptography things like RSA elliptic curve under the hood to exchange a signature that you then verify with the public key assert would be enough yeah exactly they could use assert they could they could do they could do something like this okay so to know if I could even generate this encrypt value parameter I had to dig through the original JavaScript to figure out exactly how it was being signed and again he's using the word signed here and I think as you're getting from my inflection of my voice it's not going to be a signing scheme after tracing the encrypted value parameter back to the JavaScript I landed on these two functions yep in JavaScript both of these functions took in variables which existed at runtime so the easiest way to actually call these functions would it be to find somewhere that it was called using the actual API and after searching for a little while I realized that the four-digit pin I set was a registering my account was encrypting using the same function now that I had a breakpoint set I was in the correct context for the function I could simply paste the function into my console and run whatever I wanted so again this is the issue with doing critical functions on the front end because the code is not closed Source you could have done this on the modem you could have done this somewhere else where there is a hardware root of trust the hardware root of trust stores the key and then the kernel retrieves the encrypted data from the hardware root of trust there are so many ways you could have done this differently but they are using a a symmetric key scheme on the front end to to access the API okay let's keep reading to validate that it worked I copied the encrypted value of the PIN code that was set to the post request and passed it to the decrypt function so he decrypts this he takes the value that was sent by the to the API he decrypts it and out pops 8042 which is his pin perfectly it works as expected the only issue now is getting the encrypted value of a device so where where is that device encrypted value I asked around for a while until I found uh until I found a friend who owned an MSP a few states away he used Cox's business the game of the log into the account and I saw what appeared to be an encrypted value parameter in one of the HTTP responses after authenticating into their account so this guy logged in I copied the value and pass it into the function once again and out poops this long string of data and something in here is a little suspicious this looks like a MAC address okay let's see what's going on well that's annoying it looked like the encrypted parameter had the MAC address but also an account ID and a few extra parameters So within this encrypted value that his friend got from the the API request it had the account number the device name the device ID something unknown a label and a MAC address if there was some validation with check the MAC address attached to the account ID it would make exploiting this somewhat complicated I investigated further on a leap of faith I tried signing and again the issue here is he's using the word signing there is no signing happening here it is decryption I'm not on Sam I'm just saying like you could do this semi- correctly if you had a proper signing scheme but they're using AAS uh I tried assigning encrypted value string with a junk data for everything so he he's basically not caring about any of this data except for the MAC address which is the MAC address of a device he wants to attack uh to see if it actually validated that the account ID matched the MAC address if this request worked it meant that I could use encrypted value parameter in the API that didn't have a matching account ID I sent the request and I saw the exact same response as aboved this confirmed that we didn't need any extra parameters we could just query any hardware device just by knowing the MAC address we now essentially had a full kill chain I formed the following HTTP request to change the SSID of one of my own devices so here he's changing the SSID of his device via this this endpoint to the name Curry okay he got a success message and sure as after five minutes later my network rebooted and the SSID name of my device had been changed to Curry I could read and write anyone's device via this exploit absolutely wild this demonstrated that the API cost update device configuration worked this meant that an attacker could have access this API to overwrite configuration settings access the router and execute commands on this device at this point we had a similar set of permissions as the ISP tech support and could have used this account to exploit the millions of devices that were accessible to the apis so the total impact is that the series of vulnerabilities demonstrated in a way which fully a fully external attacker with no prerequisites could have executed commands and modified the settings of millions of modems accessed any business customer pii and gained essentially the same permissions as an ISP support team remotely from your house and So eventually they did take this they reported all it by a responsible disclosure and he didn't published this article until Cox went through and fixed it Cox actually did a very good job and they uh they I think they fixed the the issue in a matter of like a month or two which is really really solid but it's just truly insane so after reporting the vulnerability to Cox they investigated if this if the specific vendor had ever been maliciously exploited in the past and they found no history of abuse um they had also informed me that they had no affiliation with the digital IP address or the digital ocean IP addresses meaning that the device had definitely been hacked and ju and just not using the method disclosing this blog post anyway thanks for reading more than happy to listen to any theories comments or whatever about what happened here feel free feel free to reach out at samw Curry gmail.com I think what probably happened is that someone else figured out this vulnerability in the API they use this API to do some kind of command injection vulnerability every device that that can be touched by this endpoint has to process that data or that there could be a command injection vulnerability in any of these fields that he now can touch via these endpoints like there may not be necessarily a run arbitrary code endpoint on this API that device has endpoints that only that API could hit if that API could touch any of the code in there and there's a simple system command injection in that that code then I mean you're you're basically just opening up the attack surface for other bugs that could exist and I think that probably is what happened now why they're replaying the HTTP requests like in the order of like 10 seconds or 5 Seconds that I don't know that's really weird um but yeah man it's super weird anyway go show uh Sam some love and then hit that like button and that sub button and then go watch this video this video this video about how um what was my last video then go check this video out about Microsoft recall it's pretty crazy we'll see you guys in the next one take care bye bye

Channel: Low Level Learning

Views: 627,251

Keywords: router, hacker, security, vulnerability, 0day, modem, hacking, computers

Id: TFolQUeWoog

Length: 29min 1sec (1741 seconds)

Published: Tue Jun 11 2024