phone hacking situation is crazy

Sometimes in your career as a person who makes internet videos about vulnerabilities in software, you find those vulnerabilities where you just look at them and you're like, "Wow, they they really did that." And this one is is no exception. CVE 2026 2329 critical unauthenticated stack buffer overflow and Grandstream GXP Voes. Guys, we are literally hacking like the 1990s in this video and it is truly spectacular. They're called Grandstream Phones. I guess it's like a you know, it looks like a Cisco kind of knockoff thing. at the 1990s style woo woo spinny thing. When you look at a phone like this, you're like, "Oh, surely all phones are the same. Surely the security of my iPhone 69 is the same as a Grandstream, what is this, a 1628?" But that is not the case, guys. The bug in this video is so egregious. And the lack of mitigations are so egregious that I adhore you you watch to the end of the video. It is truly spectacular. Okay, so the bug in this video, a remote attacker can leverage a CVE to achieve unauthenticated remote cut execution with root privileges on the device. The device has been patched now. They have a firmer version 10781. It is in the webbased API service and is accessible in a default configuration. All models of this phone share the same common firmware image. Therefore, all of these phones are vulnerable to this, scoring it a 9.3 critical CVSs. Guys, this kind of bug and unauthenticated Stack Buffer overflow is literally hacking from the '9s. And we're going to see later in the video how the lack of mitigations make it even more like the '9s. Like, it should be illegal for companies to get away with bugs like this. And if they have them in their software, there should be a way for you to find them or something. So, let's go into the actual nature of the vulnerability and kind of figure out what's going on here. So, first of all, I do want to highlight that they integrated this into a metas-flight module, which is really impressive. But you'll see here using a interpreter shell. They deploy interpreter to a phone. That's actually [ __ ] incredible. But by doing this, uh, they're able to get UID on the device, they land as root. So, can we just can we just acknowledge for a second stackbased buffer overflow unauthenticated lead rce and when you land on the device, you land as root. You can see here they prove it by they do shell getting you UID0 G0 in group zero. It just absolutely bonkers exploit and even worse they they have a way here where they can extract SIP accounts. So SIP is session initialization protocol. It's a protocol that like VoIP devices use to initiate an RTP conversation to do telephone calls, right? So the idea here is you're sitting in your home office or like your your real office, I guess. You have a bunch of these in your office and they all talk through some IPBX, right? a public branch exchange for that office and you use that to have telephone calls. You dial 1 2 3 and that goes to George in finance's office. But if someone in your office is a malicious hacker and they want to just spy on all your phone calls, they want to talk about the lack of software development skills while you're still not compiling with Stack Canaries, ASLR, or any modern mitigations using a real compiler. But that being on the side, you know, a hacker could uh intercept these calls, which is pretty crazy. One of the easiest ways to stop hackers from getting into your network is knowing not only where your attack surfaces are, but vulnerabilities in those attack surfaces. And that's why today's video is sponsored by Intruder. Intruder is a vulnerability management platform that allows lean engineering teams and lean security teams to stay ahead of threats by unifying attack surface discovery and cloud security. Intruder is constantly scanning for vulnerabilities and looks for over a thousand attack surface issues that other platforms miss. What's cool is that Intruder is constantly on and constantly looking at your cloud infrastructure looking for issues and sending you emails when it finds them. What I like about Intruder is that it's it's calling me out right here uh because I've actually used my AWS root access key to manage the Level Academy, which is a thing I probably shouldn't be doing, right? So, it was really easy to integrate Intruder into my AWS account. All I had to do was make a new IM role in AWS and give it the config that intruder gave me. And then once I did this, it literally went into the cloud and was able to discover all of the components of Lowle Academy and Stack Smash and give me issues with them. It also discovered that I have an unsupported EngineX version that I wasn't aware of that I have to go into and update now because that that version is no longer supported. It's pretty cool. And it took me almost zero work. Now, despite this high threat, I still got an A+ in cyber hygiene from Intruder. Thanks, Intruder. You guys know the deal. The best way to help the channel out is to go interact with the sponsors. Give them a shot. You can actually try Intruder for free for 14 days at this link below. Go plug in your AWS account and see what issues they find in your cloud deployments. Intruder, thanks again for sponsoring the video. Back to the video now. The technical analysis is where it gets really hairy, guys. Like the the reason this bug exists is literally a stir copy basically. So, let's go into it. So, TCP port 80 again, this is a vulnerability in the phone's web server. You can exploit it using curl and it is in the API point CGI bin API values get. When I saw this, I was like, "Oh, like surely they're going to use some very complex JSON format. Maybe it's like a custom protocol that they had to figure out some decryption key, some RC4 going on where they use that between the client and the host to encrypt the commands." And no, literally it's just JSON. And so you'll see here is we have a function that is doing some kind of parsing. They use the Grandstream common utils to get the request out of the data that comes in from that function header. And then they're going to take the request length is equal to the sterlin of the buffer. Now, what you're probably seeing is we do have a single check for request length being greater than zero. But what we're not seeing is a check for if it's less than some value anywhere else. We are literally not checking to make sure that it's too big to go anywhere. So basically what this code goes through and does is it looks for a colon to denote the end of a of a value or the end of a key and then it's going to stir copy that into a buffer that is too small for it is literally a like baby's second I guess instead of a baby's first a baby's second buffer overflow right we we are literally hacking in the 1990s so the request parameter is iterated over character by character if the next character is not a colon the next character is appended to a small 64-bit buffer on the stack If the next character is a colon, the end of the request parameter is reached. When appending other character to the small 64-bit buffer, no length check is performed to ensure that no more than 63 characters are ever written to this buffer. Guys, I don't know how we get to a place in software where code can exist where we're just like, oh, arbitrary user input. Let's not check for any length ver verification. Let's not do anything to see if it's the right size. And again, another it it it just it drives me crazy cuz every time I see an embedded device, I know I see this article about these these Grandstream phones and it's like you just know that something's going to go wrong with them. You look at them. You look at a device like this and and on the internet or you could buy it for like $48 or whatever and you're like, h something's going to go wrong here. I can't tell you why I know that, but I just kind of have an an inkling of a suspicion. And then you take it apart and then they're like, "Oh yeah, let's stir copy to the stack." What? That's [ __ ] crazy, dude. Okay. Uh, Rapid 7 did all this this uh research. And what you'll see here, guys, is just like all you have to do is put request equals ah in the device. You don't even have to put the colon because it's actually copying the key from before the colon. And then you get full register control, guys. You get control of all of the nonvolleted registers. So R through R11. And then you get control of PC. Now what you will notice is that instead of being 41, 41 is ASKI A by the way. Uh you get 4 Z. That's because the ARM architecture is going to cut off that bit and try to execute in thumb mode if that one bit is set. But regardless, it is indicative that they have control of the program counter and then can send it anywhere. Now they go into what mitigations does this have? Right? So in a world where you're doing binary exploitation, you want to know what mitigations are in place. Okay, you control the program counter, but what else is going on? Well, so first of all, there was no stack canary that stopped you from exploiting this. Literally, if you just enable a flag in the compiler, it'll put a secret value below or above the stack pointer before the program counter. So, if you overflow it, it'll kill the program. That's not enabled. The binary is not position independent. So, if you want to return somewhere, you know where other parts of the program are. There are literally no mitigations in place. And I think they mentioned that ASLR was also not set up. Yeah. Well, yeah. So, it's not PIIE. So, they can't randomize this address, right? So, because of this, we are able to do return oriented programming. Kind of the go-to hacker skill if you have control of the stack, but you can't run on the stack because you have NX enabled, NX was enabled, so you can't jump to like shell code, for example, right? But still, other than that, not a lot going on here from a mitigation standpoint. So, kind of bonkers. And in doing that, what they found is this really cool technique where basically by placing the colons in certain places, they're able to get effectively a null terminator and they're able to arbitrarily write whatever they want on the stack using that to set up their chain and then using that to finally return the system, giving them this magical little bada bing bada boom, you get UID in your route using interpreter on a phone. Right? Honestly guys, the point of this video is to kind of highlight stackbased buffer overflow due to effectively a stir copy is still well and good. A and B, it's really important to just understand that everything is code. All embedded devices in your house, your fridge, the camera I'm recording this on probably like all of the OT software that run the electrical grid, the power, the power grid, I said that twice. Electrical and power, same thing. Uh the water grid are all just code that is written by the lowest bidder. No offense to anybody. That's just like a gross generalization, I guess. But it's just it's just how it ends up being, man. So, you have these weird issues where if a hacker got into a network that had grand streams, weird shit's going to go on. You know what I'm saying? So, oh, and the one question I'm sure you're asking, the one the question that you are dying to know the answer to, would Rust have fix this? Would the world's best anastster programming language fix this problem? Absolutely. There like literally this kind of bug we're talking about where we have arbitrary data written to a buffer that is too small. You would not be able to do this if you use mo like the the proper tooling in rust. And then two, the minute you go outside of the buffer, you're going to turn this into a DOSs. So while you may not necessarily hack the phone, you may doss the phone, which is like a different problem obviously depending on like your threat scenario, right? But yes, literally Rust is the uh the perfect solution to a problem like this. That being said, obviously Grandstream has other libraries they're running their code on. They different parts of the platform they have to adhere to. It looks like they're running a very old version of ARM and Linux. site thing. Let me pull it up real quick. There we go. A very old version of ARM, ARM v5. So like you have to be able to make sure that like your runtime environment can deal with Rust if you compile it a certain way. So like there are, you know, obviously edge cases to that statement, but generally speaking, yes, Rust is uh is good for this. So make sure you you try that out as well. Okay. So if you're in this scenario, if you have a grand stream phone at your office, what do you do? Well, step one, work with it. Get that thing updated to one, what is it? 10781. Or maybe I don't know. I'm not a doctor, but maybe you don't. Maybe you don't use this brand anymore. I don't know. I I can't say that. I think for like legal reasons or something, but like I think generally if if they're uh if they're shipping this uh you know who else who else knows what they're shipping? I don't know. Please, if you are a developer watching this video, please check your buffer lengths. Please don't trust user data. Please validate that it matches the constraints of the world that you're putting it into. And please compile with all modern mitigations. This has been a low-level TV video. Thank you for watching. We'll see you next time. Goodbye.

Go try Intruder today for 14 days, free at https://go.lowlevel.tv/intruder https://www.rapid7.com/blog/post/ve-phone-listening-cold-war-vulnerability-modern-voip/ https://www.rapid7.com/blog/post/ve-cve-2026-2329-critical-unauthenticated-stack-buffer-overflow-in-grandstream-gxp1600-voip-phones-fixed/ 🏫 MY COURSES Sign-up for my FREE 3-Day C Course: https://lowlevel.academy 🧙‍♂️ HACK YOUR CAREER Wanna learn to hack? Join my new CTF platform: https://stacksmash.io ⌨️ KEYBOARD Like what you hear? Grab a Q5 at https://go.lowlevel.tv/keyboard 🔥COME HANG OUT Check out my other stuff: https://lowlevel.tv