BTS #70 - How Cheap KVMs Could Be Your Network's Weak Link
In this episode, we explore the security vulnerabilities of low-cost IP-based KVMs, including firmware flaws, default credentials, and insecure update mechanisms. Two Eclypsium researchers, Paul and Rey, discovered the vulnerabilities and shared the details and behind-the-scenes details! We also discuss real-world testing, vendor responses, and best practices for securing remote management devices in enterprise environments.
Transcript
Paul Asadoorian (01:02.327): Welcome to Below the Surface. This is episode number 70 being recorded on March 19th, 2026. I’m your host, Paul Asadoorian, joined by Mr. Chase Schneider. Chase, welcome.
Chase Snyder (01:15.726): What’s up, all?
Paul Asadoorian (01:17.527): Another regular to the show, Mr. Vlad Babkin is here with us. Vlad, welcome. He’s waving. There’s a lot of background noise where Vlad is right now, so he’s gonna do the muting, unmuting thing. And our special guest for this episode, first time on Below the Surface, Reynaldo Garcia, who we’ll refer to as Rey for the rest of the episode. Rey, welcome to the show.
Vlad Babkin (01:25.859): Yeah, hello.
Reynaldo (01:41.146): Thank you.
Paul Asadoorian (01:42.967): So before we dig into it, and then I’ll give you a little more background on Rey and the project that we worked on, but Below the Surface listeners can learn more about Eclypsium by visiting eclypsium.com/go. There you’ll find the ultimate guide to supply chain security. In an on-demand webinar I presented called “Unraveling Digital Supply Chain Threats and Risk,” a paper on the relationship between ransomware and the supply chain, and a customer case study with DigitalOcean. If you’re interested in seeing our product in action, you can do that by going to eclypsium.com/go. Alrighty. Rey, welcome to the show, my friend. Rey is one of our coworkers here at Eclypsium. Rey, why don’t you give us a little bit about your background and how you came to work here at Eclypsium.
Reynaldo (02:31.29): Yeah, so I started about a year ago with a project for DEF CON and that was doing research on a smart vape detector for schools and that went really well. I got in contact with, you know, Mickey, who has also been on the show, and yeah it’s been just a smooth ride from here.
Paul Asadoorian (03:06.26): Yeah, you were featured in Wired.com. I want to say Wired Magazine. I don’t think they produce a print magazine anymore. But there was a Wired article about your research into the vape detection devices.
Reynaldo (03:15.62): Yeah, really cool stuff.
Paul Asadoorian (03:21.344): That’s how we found Rey then, right? And then, so Mickey was kind of the brainchild behind this. Mickey was like, well, we need another project for Rey to work on. So he was kind of like, why don’t we look at these IP-based KVMs? Was there more to it than that? Or he was just like, hey, we should look at these devices. Like they’re inexpensive, they’re everywhere now, right?
Reynaldo (03:34.095): Yeah. Right. Yeah. I think a lot of Mickey. Yeah, it was a lot of, you know, thinking behind that. But also they were just really, you know, everywhere. So you couldn’t really avoid them. I mean, if you wanted to remotely control like your computer, you know, like you got a KVM. So. Yeah.
Paul Asadoorian (04:10.997): Yeah, and there’s a lot more that came on the market, Sipeed, GL.iNet, and JetKVM, some of the more popular ones, right? PiKVM is out there. Some people ask if we tested that one. We didn’t test PiKVM. That’s been out there for a while, but those are a little more expensive, right? We’re talking about largely sub-$100 devices that serve as KVMs that work across the network. So was the first one you tested, was that GL.iNet?
Reynaldo (04:38.552): Yes, that was GL.iNet, the comet, I believe.
Paul Asadoorian (04:43.349): Yeah, Comet R1, right, I think is the model that we tested. So a lot of people were kind of confused too because the term KVM is overloaded, right? It’s not the Kernel Virtual Machine in Linux, that’s different. And also many people I talked with, even some journalists were like, wait, I thought a KVM was like that physical thing you had in front of a, you know, connected a monitor, mouse and keyboard to it, and then there was cables that went to physical computers and you could switch between them. Like that’s a KVM, these are IP based, right? And they all work pretty similarly, right? You get a web browser. And do they all use mostly like WebRTC in a web browser and you access the KVM and interfaces with HDMI and USB on the device? They all work on the computer, I should say.
Reynaldo (05:34.808): Yeah. Yeah, it’s pretty simple. Like WebRTC is like really common.
Paul Asadoorian (05:42.369): Gotcha. So let’s start with GL.iNet. Walk us through your process when you first got the device, Rey, and started looking at the firmware.
Reynaldo (05:57.668): Yeah, so this was my first project after DEF CON. It was a lot of… How do I explain this? Trying new things, you know, like learning how to do it exactly. But GL.iNet, one of the first things I noticed was that it was vulnerable to brute force attacks. You could just send whatever, however many requests you want to the login page. That was really surprising. I’d expect there’s a sort of standard I expect with these devices and it didn’t meet that. I’m just kind of surprised.
Paul Asadoorian (06:49.386): Yeah, I agree Rey. I was explaining it earlier this week that I expected a higher level of security because essentially an attacker is like they’re physically sitting in front of the system, is the level of access they provide. Was GL.iNet, did that have a username and a password or just a password on it?
Reynaldo (07:09.913): It was a, I think it was a username and a password. I’m not entirely sure. But…
Paul Asadoorian (07:20.022): Yeah, because I know with JetKVM it was just a password. There was no username component.
Reynaldo (07:20.824): Right, That is sometimes common in the KVMs. I saw one of the other ones I saw research was just a password. And sometimes they offer like a username, but underneath there’s no like accounts or anything. So there’s no reason for a username field.
Paul Asadoorian (07:36.149): Interesting. I gotcha. I gotcha. And so did you start with, so yeah, this is a good question. Like, how did you start? Did you start by setting it up and just hitting the web interface? Did you start by pulling apart the firmware? Or did you start with interfacing with the hardware? Because I think you did all three, especially in the GL.iNet platform.
Reynaldo (08:07.521): Yeah, so it was a lot of… I remember first we discovered the UART vulnerability and how it just drops you into a shell. That was really surprising. Usually… yeah.
Paul Asadoorian (08:21.172): Into a root shell. Sometimes it’ll drop into the shell, but you don’t have root level access. But this was a root level shell just by interfacing with, I’m assuming, a USB serial to the UART port on the physical board, right?
Reynaldo (08:34.519): No, yeah. It is really surprising.
Paul Asadoorian (08:41.162): Did you use that access to discover any more vulnerabilities or that was pretty much just like a finding?
Reynaldo (08:48.887): It was a finding, most KVMs, IP-based KVMs offer shell-like capabilities. Like most of the ones we researched had a built-in shell.
Paul Asadoorian (09:03.614): I got, yeah, you can SSH or Telnet. Usually it’s SSH, right?
Reynaldo (09:05.059): Right, but sometimes they offer like a web shell. And that’s really interesting. So the UART finding was more, yeah, just a finding.
Paul Asadoorian (09:21.28): Gotcha, gotcha. And then you looked at the firmware, right, and using a lot of our tried and true methods, I should say, for pulling apart firmware. We want to go into great detail, but yeah, we do that a lot here at Eclypsium, right? Pull apart firmware, unpack it. None of these were encrypted though, right? I don’t think we came across any firmware encryption on these, right?
Reynaldo (09:44.035): No. No, nothing like that.
Paul Asadoorian (09:49.067): Well, it’s interesting. I almost want to go back because we did discover, you and I both on two different platforms, that there was no cryptographic firmware signing, which means anyone could tamper with the firmware and put it on the device. That was true of GL.iNet and JetKVM. I don’t think we tested the Sipeed or Anjeet devices to see if they signed their firmware.
Reynaldo (10:18.989): No, I don’t think we did. Sipeed, I think, had a custom thing where it called home and then got updates from there.
Paul Asadoorian (10:32.34): Yeah, JetKVM was similar. I spent a lot of time with the JetKVM determining how it updated firmware. At a high level, it hits an API endpoint. If there’s a firmware update, it spits back a response, says, hey, there’s a firmware update. The SHA-256 hash of that update is this, and you can download that update from this URL. And that URL was a different host name. So was like API.jetkvm.com was the first request that it made that would spit back, hey, get your update from update.jetkvm.com. And the only thing that was like protecting it just to make sure it wasn’t corrupt in transit, was that SHA-256 hash.
Paul Asadoorian (11:11.897): What was interesting about that process that I didn’t put in the blog post actually was there was a point in time like last fall where when I was analyzing that firmware update process, I noticed that the API response said, hey, get your firmware here. And it was HTTP://update.jetkvm.com. And I was like, well, I can be an attacker in the middle. And since there’s no firmware validation, I can send any kind of firmware I want to it. And also, since I think Sipeed and the NanoKVM and the JetKVM, they’re all open source, their firmware is completely open source. So I’m like, I could build my own firmware with my own back doors in it, do a machine in the middle attack, and send the JetKVM new firmware. And I tested that and I was like, that works.
Paul Asadoorian (12:04.995): I didn’t actually backdoor the firmware. I actually had code where I was gonna backdoor the firmware. And I was talking with Mickey, he’s like, let’s write it up. So I started to write it up. I went back and started to test it while I was writing up the vulnerability disclosure for the vulnerability of not using SSL to retrieve the firmware. And then when I tested it, I saw that the URL changed and it was protected with SSL. So like while I was getting ready for disclosure, they fixed the vulnerability before we could report it, which is good, right? I just want to point that out. It was frustrating as a researcher, but when researchers are frustrated, it usually means someone did the right thing. And JetKVM did.
Paul Asadoorian (13:02.169): So then, I don’t know that you have seen my scripts that I created. So then I started using scripts and writing new scripts to be able to machine in the middle, right? So I’ve got the KVMs on one network, goes to a Linux device. I control DHCP, I control DNS, all the traffic flows through that Linux device. And I started building out tools. Well, I used off the shelf tools, if you will, open source tools that already exist to test SSL. So I had man in the middle proxy. I had like a list of other SSL tools. I had a tool called DeLorean on there that can spoof NTP to change the time on the device to then try and execute an SSL attack that requires that you control the time on the device. And so I tested probably half a dozen or more different SSL based attacks to try and be able to insert my own firmware in the update process and all of those failed. So SSL is configured correctly on the JetKVM device.
Paul Asadoorian (13:52.729): And what I ended up with was this vibe coded project that represents a set of scripts on Linux that can turn a Linux device into what I call a man in the middle beast. So it has all the capabilities of all those tools, including full packet capture. And so we released those open source. We’re actually working on getting them in Eclypsium’s official GitHub. But I was like, hey, here’s the tools I use to test this firmware in hopes that others would test that firmware in the same way as well. So it’s kind of a useful… Again, it’s not a new tool. Some people put that on, they’re like, hey, they released a new tool. I’m like, no, we didn’t release a new tool. It’s really just a set of scripts that helps you automate existing tools. I really didn’t write any new tools. It was just sort of like glue to stitch them all together to make it easier to set up. That was all. Chase, do you have questions at this point? We’re going to give our listeners a little of the behind the scenes.
Chase Snyder (15:14.476): Yeah, buddy. I just also posted this to try and get some people to interact with us in the live stream as well. But yeah, I don’t know. Something that came up when we were internally talking about this was what the enterprise attack surface is with regard to these sort of cheap KVMs. Historically, KVMs have been present in enterprise infrastructure, but they were kind of big hulking, expensive enterprise targeting devices. These are, you know, $30, $100, whatever cheapo gadgets. You would think and hope that most enterprises would not be using these for their sort of enterprise purposes, but I don’t know. What do you think the likelihood that this is creating risk for businesses?
Reynaldo (16:10.723): I think it’s very much like… I don’t think every enterprise environment is going to have these KVMs, but I can definitely see it happening in a very chaotic, low budget team. They’re very easy just to deploy and boom, you have access. I think that’s the main enticement when it comes to these. Just how easy they are to deploy.
Chase Snyder (16:42.944): Yeah. Emergency situation. They’re like, man, we need that. Totally.
Paul Asadoorian (16:48.308): Yeah, I can speak to that too. Again, Rey found most of the vulnerabilities, by the way. Seven of the nine, I give Rey total credit for those 100%. I ended up testing the JetKVM platform and Rey tested the other three platforms. And so from a JetKVM perspective, super easy to deploy, right? You unbox the, I have the little device right here. Like here it is on my desk. You unbox it and it’s just like a bunch of cable. So you plug it into the ethernet, you plug it into the HDMI, you plug it in via USB. It tells you on the display of the JetKVM what IP address it has and so you hit that IP address in the browser and you’re off to the races. Now by default—and I think the other platforms work similarly, Rey—in that there’s no authentication by default. Like it’s just open to the internet.
Paul Asadoorian (17:48.311): And I described that to people. It’s kind of like if you had a monitor, mouse, and keyboard connected to a computer on a busy street in Manhattan, and you just left that outside the window for anyone to interact with your computer. That’s like the equivalent, right? So I’m assuming where the other platforms were similar, authentication wasn’t enabled by default.
Reynaldo (17:59.011): Right. Yeah. Is that authentication like a web-based password? Or like you just hit the…
Paul Asadoorian (18:17.182): Yeah, usually when you hit the web server on the KVM, does it prompt you for a password or does it prompt you to set a default one when you connect to it? I don’t remember.
Reynaldo (18:27.747): I think most of them either had a default password or I think one had a password prompt change like a change your password prompt but most of them just had a default password.
Paul Asadoorian (18:43.316): Gotcha, gotcha. And so, Chase back to your question, we find in the enterprise, you know, we’d have to look. You know, we didn’t scan everyone’s enterprise network to look for these specific devices. We’re kind of leaving that as an exercise to the reader. I think, you know, the situation where these will end up is if you’re deploying servers or computers that don’t have remote management capabilities equivalent to this. So on the server side, that would be a BMC, which we’ve talked about on the show. Vlad is intimately familiar with BMC, has several CVEs to his credit for BMCs, right? But if your computer or server doesn’t have that, you can add one of these on to it. Now there’s enterprise class IP based KVMs, which we have not tested yet. Hopefully we get to that maybe someday. No promises though.
Paul Asadoorian (19:34.082): But then the consumer market, I mean, they’re the same. I’m not sure what the features are difference between the enterprise IPKVMs and the consumer ones, but the consumer ones are cheap and easy to deploy. So I could see someone go, well, we had to put this computer in a data center on a manufacturing floor, somewhere in the hospital or healthcare facility, and we need remote access to it. So for 30 to $100, we can add this little device to it and we’re off to the races. But as we discovered, you’ve got to do a lot of due diligence to lock that down.
Chase Snyder (20:17.804): Yeah. It’s like remote access tools in general are an obvious target and a huge target. And so many countless of the cyber attacks that are in the news, the initial access vector was a remote access tool and this kind of thing. Like there’s this constant push and pull of needing remote access, but then anything that has remote access becoming ultimately a target and an appealing, you know, thing to try to crack into from an attacker perspective. It seems like an unsolvable, just a permanent sort of issue to have to deal with. If you are going to want remote access, and you always, always are, you are always going to have to anticipate that whatever mechanism you use to enable remote access is going to be targeted. And so for there to be this like cheap, easy to deploy type of device out there that opens the door, unlocks the network in that way. I don’t know. It’s like death by a thousand cuts. Every little thing like this. Every device type is going to be subject to this sort of commodification and like cheap, easy version with tons of vulnerabilities coming out. It seems like a very difficult asymmetrical problem for security people to have to deal with.
Vlad Babkin (21:48.348): It gets even better. It gets even better. Like, if you expose your remote access tool directly to the internet, you should evaluate your life choices. If you’re a vendor of hardware and you don’t do digital signatures in 2026, you should also evaluate your life choices.
Paul Asadoorian (22:06.004): Yeah, I agree. I think that’s one of the reasons we chose this platform, right, is in publishing this research, and I think we accomplished our goal of helping raise awareness that when you produce devices, especially ones that provide the equivalent of physical access to a machine, that you have to use what we would deem as best practices, right? So, and I’ve talked about this on shows in the past, right? Like firmware encryption, cryptographic firmware, signature validation, strong authentication. I would love to see MFA. Rey, I don’t think any of the devices we tested, do they offer MFA, multi-factor authentication, for the login?
Reynaldo (22:47.947): I think GL.iNet offered that. That’s it.
Paul Asadoorian (22:53.086): Okay. Yeah. So I’d like to see that become more of a standard, right? Because you really have to protect these devices that are on your network. Now, exposing them to the internet is like Vlad saying, it’s just silly. But I don’t want the, whether it’s exposed to the internet or not to determine how well you secure your devices because as you know, especially Chase and I have talked about, right? How threat actors are compromising networks today. They get on the inside of your network. So we don’t want the 90s style security like, I’ve got a firewall and I have a hard and crunchy outside and a soft and chewy center, right? That’s something we’ve been saying in security for over 30 years. And it’s still that mindset persists. People are like, well, this isn’t a problem because I would never expose it to the internet. I’m like, well, what happens if an attacker gets into your network any number of ways?
Paul Asadoorian (23:48.311): And then you’ve just got this thing hanging on the network with no security. Now they have physical access. Now they can persist, right? Something we haven’t touched on yet is an attacker persisting on one of these devices, you’re not going to catch them on your Windows computer or whatever that it’s connected to. They’re going to persist on this device. They’re going to get into your UEFI or BIOS is one avenue it opens up. Booting from removable media. Did you test any like booting from removable media on these, Rey?
Reynaldo (24:19.169): No, we didn’t get that far.
Paul Asadoorian (24:21.181): I know the features there and so in that case, the attacker provides the disk image and can boot the remote computer off of a disk image that’s provided by the attacker. How awesome is that for an attacker? So these need a higher level of security in my mind.
Reynaldo (24:40.951): Yeah, for sure.
Paul Asadoorian (24:44.297): What else Chase, you and I really haven’t caught up on this research in a little while.
Chase Snyder (24:50.806): Yeah, I was having fun reading the comments on like this. This got written up in a couple of publications like Ars Technica wrote about it. And always fun to see research get covered. Great job, Rey and Paul. Writing, know, doing some research that people are obviously interested in. Ron Gula did a whole podcast episode about it too. And there were some good comment action. I kind of want to pull that up and just talk about what people were talking about. What people were shouting out in the comments.
Paul Asadoorian (25:23.817): Yeah, it got a few comments from the Ars Technica article. So I actually briefed Dan Goodin in preparation so he could write the article. He always asks great questions, by the way. Dan does great work. And Ars Technica is a popular site and they open it up to comments. Now, like we’ve all seen the internet before, right? We know how comments can go sometimes. But I thought the comments were mostly positive, Chase, in the Ars Technica article.
Chase Snyder (25:56.012): Yeah, a hundred percent. I think the overall tone of it. Yeah. They say, don’t read the comments. I always read the comments. I’ll be upfront about that. You can’t hurt me in any way that matters online, but, yeah, a lot of people have sort of brought up what we already have mentioned that when the fundamental architecture and sort of whatever you want to call it, the fence in depth or securing your internals is not there, then having something like this in your environment is bad, but it’s just an indicator of sort of more, more rot or lack of attention to the internal security in the environment that is, yeah, deserves more focus than it gets. And yeah, I don’t know. A few people said, like, yeah, okay. Remote access tool exposed to the internet, foregone conclusion. Obviously this is bad, but you know, keeps happening. So we’ll keep talking about it, right?
Paul Asadoorian (27:01.46): Yeah, and I want to go back to the Saipede NanoKVM. Rey, for our audience, can you describe that vulnerability? Because I think out of all of them, this is kind of a somewhat unique class of vulnerability that you discovered on this platform.
Reynaldo (27:17.101): Yeah, so it was really interesting. The endpoint to change the Wi-Fi. On some models, on the model I had bought, it was ethernet only, but you can buy a Wi-Fi model. And on these, you can hit the endpoint without authentication. So you can change the Wi-Fi information to whatever. And this also, you could spam that and it would result in a denial of service attack, which was also interesting.
Paul Asadoorian (28:04.767): So an open API endpoint on the wifi enabled models.
Reynaldo (28:09.367): Yeah. And it was really funny because it’s open source. So I looked at the responsible code snippet that was like written wrong. Someone had misspelled “secure” in the config for that endpoint.
Paul Asadoorian (28:35.753): That’s really funny.
Reynaldo (28:36.933): And it had been there for like the past however many, I think like 10 updates or like the last 10 versions of the firmware, which is really interesting.
Paul Asadoorian (28:51.603): Yeah, so when Rey tells us they literally they can’t spell secure, that’s literally what we’re saying. Oops.
Paul Asadoorian (29:01.075): In terms of vendor response though, Sipeed did release fixes for that particular vulnerability pretty quickly. JetKVM probably had the best response. I don’t know if you were following along. So we filed a case with US-CERT to help track these nine vulnerabilities to help keep communication open and healthy with all four different vendors so that the burden upon ourselves of communicating with all four vendors was not solely on us. US-CERT was helping in reaching out to the vendors as well because we really do want the vendors to have time to fix it. We give vendors 90 days to address problems. These particular vendors had more than 90 days actually to address all nine of these vulnerabilities in the respective platforms. JetKVM’s co-founder actually jumped on the VINCE case and was like, I see these and I’m going to fix them.
Paul Asadoorian (30:17.804): A little while later, he’s like, yep, these are all fixed. So JetKVM fixed the… They’re the only one to publish a fix of the four vendors to cryptographically sign firmware on their devices. And I just, want to give them so much credit for that because I think that’s awesome. And I hope it starts a trend that continues where other vendors follow suit with that. And they also fixed the what we call insufficient rate limiting that we talked about that was also present in JetKVM as well. Also, since JetKVM and NanoKVM are open source, if you’re using something like Claude Code, you can pull down the source code and use Claude to help you do analysis, to help you build tools, to test, to… You could create add-ons, you can create features.
Paul Asadoorian (31:00.246): Fixes pull requests for these projects and using Claude to do that is really nice. In fact, before, I mean, they fixed the insufficient rate limiting again very quickly, I had behind the scenes, I had vibe coded a password brute force guest tool tuned specifically for JetKVM. And it didn’t take me long to create that, because I was like, Claude, this is what I want to create. And Claude didn’t give me much pushback either, because I set the context. I’m like, I’m a researcher. I found this vulnerability. I need a tool to validate their fix. And Claude’s like, yeah, yeah, yeah. Since you’re doing it for that reason, totally fine. I’ll create a brute force password guessing tool. And since it had the source code for JetKVM, it knew exactly how the authentication logic and structure worked, albeit it was a very slow brute force tool.
Paul Asadoorian (31:58.519): But it was one nonetheless, which obviously we didn’t release because JetKVM addressed the issue. I don’t know that we would have ever released it, but we certainly wanted it to be able to test and validate the fixes from the vendors. Which is also pretty good usage of Claude too. Sometimes I would spot check if one of these vendors said, hey, we released a fix for this. Here’s the pull request. I’d say, Claude, what does this pull request address? And it will go, oh, it addresses a vulnerability in this. And Claude’s really good at reading code and spitting back what it does. So I used that as an aid to determine whether or not a fix was published and valid for it. So it saved me some time of reading the code and doing the analysis myself. Also, we can test the firmware and run attacks against them and make sure that they don’t work.
Paul Asadoorian (32:47.389): What about yourself Rey, you use any tools or tips or tricks that you used in your analysis to discover the vulnerabilities?
Reynaldo (32:55.916): I did do some of that, yeah, for analyzing some of the vulnerabilities. Most of it was written in, like, plaintext. It wasn’t compiled or anything. So it was really easy to analyze. But for actually confirming stuff, I used a lot of Claude, you know, to like write scripts, and I would just, you pop out like a script to do this or… And brute forcing was one of the interesting ones, calculating how fast it could do a password or how many requests per second you can send to it.
Paul Asadoorian (33:39.316): Yeah, in JetKVM’s case it was pretty slow. But I think both NanoKVM and JetKVM, I analyzed both in terms of just figuring out what they used for like a backend server. And they’re pretty similar. Like they both use Go and they both use React. Different, slightly different frameworks and libraries between them, but very similar web and Go based languages implementing the Web and Management Interfaces on both. Which was different from the Anjeet. Tell us a little bit about that one, Rey, because, well, as it stands today, Anjeet has not published any fixes. We heard back, we got one email from Anjeet, both ourselves and US-CERT reached out to them, and I wanna make this clarification that we give vendors ample time to fix their vulnerabilities.
Paul Asadoorian (34:41.621): But we also have some, at least I have requirements and powers that be here at Eclypsium, we’re on board with that too. And I was like, look, if a vendor comes back to us and says, oh no, no, no, we’re gonna fix this. I still can’t put in the public disclosure that there’s a planned fix. In order for me to state that there’s a planned fix, I need a plan. You have to tell me a timeframe and a version that this is going to be fixed. And then I’m more than happy to update. I don’t even have to put, maybe I’ll put that stuff in there, but then I can put there’s a planned fix, right? But you got to give me a date. Like we’re targeting, I don’t know, April something 2026, and it’s going to be included. I don’t even need a full version number in version 2.x of our firmware is where this is planned. If you commit that to us, then I’ll say, okay, there’s a planned fix. But what some of the vendors try to do in this case is just say no, no, we’re gonna address that eventually. And I’m like, well, In what version? And they’re like, well, we’ll address it eventually. And I’m like, well, no, then there’s really no plan. That’s just a promise. It could be an empty promise, right? So that’s how I managed it.
Reynaldo (35:55.225): Yeah. Yeah, Anjeet was really weird. There was no official security inbox they had or email. Yep.
Paul Asadoorian (36:08.595): Yeah, was just their support email was the only one we could find. The only one US-CERT could find as well.
Reynaldo (36:15.288): And that was really, uh, I don’t know. Usually there’s at least some sort of, you know, vulnerability disclosure program with these. Anjeet was really like, it was just a generic brand like on Amazon. It still interesting. It still had, you know, a few reviews. I think 20 something like that. But the communication was interesting because we, if I remember correctly, I initially contacted them with the disclosure and then followed up with another email after they haven’t responded. And then they responded with, “I don’t know what you want us to do,” which was really interesting to get back.
Paul Asadoorian (37:08.521): Yeah. Yeah, I had never seen it before either. They were kind of confused. They were like, but we don’t, we don’t know what this is and how to respond to it. And Rey was like, well, you need to fix the vulnerabilities. And they were like, okay, we’ll work on that. And then, you know, months went by and we tried reaching out, CERT tried reaching out and never responded. So, I mean, I don’t know if they have fixed it since publication. How does the firmware update work on Anjeet? Because myself and also some of the journalists could not find the website for Anjeet. It just doesn’t, it goes nowhere.
Vlad Babkin (37:51.088): But to be honest, it’s not just under the name for remote control solutions. Just about every solution that I know for IPKVM, BMC, et cetera, et cetera, most of them have a surprising lack of security. No security programs, no firmware security. If you look at how they operate, hey, they’re just hidden bus users which have hard-coded credentials. What are we doing?
Paul Asadoorian (38:20.982): Anjeet’s firmware update though, Rey, is on the device only, right?
Reynaldo (38:27.98): Yeah, you had to upload it to the web panel and that was that. But I never found any firmware updates or anything like a page for that.
Paul Asadoorian (38:37.786): Okay. So you do have to go find it, but there is no place to find a firmware update. It’s… It’s weird. That’s weird.
Reynaldo (38:42.87): Yeah, no place. Yeah, it is really weird. And they had weird firmware naming styles too. It was like a super long, I don’t know, it just stood out. It was just super weird overall.
Paul Asadoorian (38:59.86): And it was Lua under the covers, right? Was there a web interface?
Reynaldo (39:03.712): Yes.
Paul Asadoorian (39:07.887): Different from some of the other platforms for sure.
Chase Snyder (39:12.204): When you said that it had 20 Amazon reviews, my immediate thought was Amazon reviews are fake. But then I was like, but who buys 20 fake Amazon reviews? And so now I’m like, maybe those are real. And I kind of want to go read them, but it seems like. Yeah.
Reynaldo (39:26.838): The Amazon reviews are actually pretty funny. I don’t know if we can go over them, but I think it’s rated at near four stars. But no, they’re really funny. I think I remember reading one that was like, this thing is broken. Never buying from this brand. And it’s a… Yeah.
Paul Asadoorian (39:58.89): Well, and it’s interesting too, because this was branded as an Anjeet, but also there was a YeeSo brand. And I was listening to a podcast with Cory Doctorow, whose book title is actually “Enshittification” and talks about social media, but also talks about Amazon and marketplaces. And in a recent interview he did, said something how Chinese manufacturers will like spin up products and they need like a brand to go sell it on Amazon and they’ll like literally just pick random English letters, which many of us have seen, right? We buy stuff on electronics on Amazon quite a bit. And they’ll just pick random English letters and that’s the brand and they’ll sell it under that brand. And I forget exactly like why that, what the advantage of that was or why they were doing that. But when he said that I was like, that makes total sense because that’s what I’ve observed too, they’re just like random names, random letters.
Paul Asadoorian (41:04.115): But also concerning that we can’t find the firmware. Like if one did exist, where would we find the firmware update for this device?
Chase Snyder (41:12.52): Right. Let’s just don’t buy them. I guess at that point, you know, you can’t update to a secure version.
Paul Asadoorian (41:19.699): Yeah, I wouldn’t recommend this device because we can’t figure out if there even was a firmware update available, how we would get it because the email was like something at anjeet.com but if you go to anjeet.com, the website just spins forever. I didn’t investigate much beyond that.
Chase Snyder (41:42.476): Yeah, I mean, regardless of whether this brand you would recommend or not, it feels like this whole category of devices is going to create a lot of work in order to be able to use it at all. I’m still looking at the comments on the Ars Technica story, which I didn’t realize Ars Technica tells you how long somebody has been a subscriber. And there’s some people, there’s someone on here that has been a 21 year subscriber to Ars Technica, a fifth of a century. But there’s some discussion about, it’s like, okay, yeah, don’t connect, don’t expose this kind of thing to the internet, but if you want to use it, how would you use it? And the answers are all some variety of like, okay, one of them is run it through a VPN concentrator and then a bastion and then the KVM. And I mean, we’ve discussed at length recently and always how VPNs are also just not secure are riddled with vulnerabilities and they increased your risk more than they reduce it. And organizations with on-prem VPNs are more likely to have a ransomware attack than with a cloud VPN or no VPN at all, according to cyber insurers. But if you guys were, what is the right way to do it? You know what I mean? If you want to use a KVM or what’s the right way at all to have the amount of remote access that you need, but have it be… There’s no zero risk way, but have it be at a risk level that most organizations would tolerate.
Paul Asadoorian (43:16.125): I would, off the top of my head, because I haven’t really fully designed out the defensive structure, but I would put a VPN endpoint in the network, and then behind that VPN endpoint, I would put all the KVM access. So it’s a separate VLAN, separate network. In order to access that network, I have to create a VPN, you know, WireGuard, Tailscale, or even if you want to use an enterprise VPN, although we caution that based on previous shows and research talking about enterprise VPNs from the big players having a ton of vulnerabilities. And that’s how I would recommend that you do it. However, when you’re adding more technology, bastion host VPNs, now you’re increasing your attack surface because all these technologies could be attacked.
Paul Asadoorian (44:18.168): One of the things we started thinking about was, because I think some of these models support Tailscale natively, because they run Linux, so conceivably you could put, I think it was, JetKVM and NanoKVM support Tailscale, Rey, is that correct? Yeah, but the problem with that is, let’s say you do configure Tailscale on there, which is conceivably the right thing to do, but an attacker can get in the middle of a firmware update and backdoor the device. Now if the attacker gains access to that device, now they have access to your VPN network, to your Tailscale network. And there could be other things on there as well. So careful planning.
Chase Snyder (44:56.278): Yeah. Which shout out, Tailscale, great products, but you know, not a panacea.
Paul Asadoorian (45:02.932): I mean, it’s almost as if you have to maintain a separate network with separate security controls just for your KVMs and your BMCs, right? Because anything you have connectivity to in that environment could open up a potential door for an attacker. Vlad, would you agree on the BMC front too? It’s similar segmentation issue.
Vlad Babkin (45:36.836): Yeah. Yeah, the BMC is pretty much the same. So like if you manage to jump into BMC from host or the other way, suddenly you have access to the whole BMC network and it’s the same exact problem. And like to be honest, what I would do for VPN solution for more or less secure access is not on Tailscale, just do a OpenVPN host, just configure it well. So yeah, it runs into quite the same issues. Like if somebody jumps on the BMC, they have access to all other BMCs because it’s a normal VPN that you access it from. If you don’t get access to everything else in the Tailscale, you can just segment your network properly and done. So that’s not a very hard problem. And second part is that you can actually limit communications between devices. Like what should happen is that VPN can communicate to the BMC and backwards, but BMCs can communicate between one another. And same exact thing applies to IPKVM because essentially they solve the same exact problem.
Paul Asadoorian (46:40.201): Right, which is harder in a, you know, an enterprise network, can do segmentation so hosts can’t talk to each other if you’ve got an enterprise grade switch. But you put that in a lot of environments where these lower cost IP KVMs are deployed in a home lab or in different parts of the network. Maybe you don’t have that capability. So now you’re opening yourself up to jumping between KVMs, IP KVMs. So yeah, that’s really interesting. That’s why I was calling for, need to be able to harden these devices and make them resilient. In terms of discovering these on the network, I think network scanning, you could pick up on these. Probably for the consumer ones, we probably don’t have great signatures to detect consumer-based devices, but those would be easy to develop and deploy and discover on your network, potentially. One thing I didn’t look into that didn’t occur to me until like pretty much until we’re ready to publish this research was is there something on the the host that you a Windows host let’s say has an IP KVM connected to it via USB is there a signature like it could you run something on the Windows host to say hey connected via USB there’s a an IP KVM connected to this device. I didn’t look at it, I if or anyone else looked at that, I didn’t.
Reynaldo (48:08.332): Hmm. I mean, I think that would be in the field like USB fingerprinting. Cause I mean, that would pop up as a human interface device and that would be, I’m not entirely sure of the, how you would fingerprint that, but I’m sure there’s a way.
Vlad Babkin (48:34.905): Yeah, USBs have like vendor ID, device ID. Like, they work, I believe similar to PCI IDs, but for USB. So like same exact idea, but another bus. And in this case, there is a database, probably with vendors. Like while you will not catch every device like this, hey, this vendor just produces IPKVM solutions and you have a device with this vendor. Ergo, you probably have an IPKVM connected to your computer.
Paul Asadoorian (49:08.373): So that’s one way. I think my advice is that enterprises should be diligent about discovering IoT devices and especially these IPKVMs on the network and potentially via the host because they’re just, I don’t know, they’re not locked down. I mean, it’s getting better, obviously, after, you know, we weren’t the first ones, obviously, to publish research in these areas. Did you look at the history at all? I don’t know if anyone looked into some of the history about evaluations of these devices, and people have pointed out some security issues that, lot of them got addressed and fixed over time, but there was a bunch of YouTube video, I don’t know if you saw any of that, Rey.
Reynaldo (49:54.231): I think I saw the article on Tom’s Hardware a few months back, I believe, something like that.
Paul Asadoorian (50:02.975): Yeah, we put in the media questions. We referenced some people’s YouTube videos and stuff where they were in it. And when I watched some of those videos, they were like, well, this doesn’t, it has a default password. Make sure you change it. So like people were in the community were aware and pushing for better security on these devices.
Reynaldo (50:26.346): You know, it’s, it’s, I’m thinking back to your, you know, what you said with the Claude Code, how you kind of, you could patch it yourself or at least, you know, add add-ons. I think that’s another cool part about it being open source. You know, we didn’t look at PiKVM, but PiKVM is also open source. And we have, I haven’t really seen anything security wise wrong with PiKVM. It’s not mentioned in a lot of articles. I’ve been seeing a lot of GL.iNet, you know, Anjeet KVMs obviously, but with PiKVM, you know, a lot of them are open source, but being able to see what code it’s running and kind of, you know, verify that is, you know, it goes a long way for sure.
Paul Asadoorian (51:15.613): Yeah, I agree. I agree. It’s much harder when there isn’t source code available to find. Again, it goes back to finding vulnerabilities and then developing tools when you have the source code is great, right? Because you can tune it for that platform because you have insight as to behind the scenes of what it’s doing. We didn’t test PiKVM. They’ve been around for a lot longer and they are more expensive, which I think in my opinion, kind of gave birth to these lower cost devices. I don’t pretend to remember what a PiKVM costs, but it’s more than $100. You can also do it yourself. It looked like a lot of work though. Before we launched this research, I was looking in these devices because my friend started using a JetKVM. He was like on their original Kickstarter. I figured out they raised a few million dollars on Kickstarter. So he got one of the earlier devices.
Paul Asadoorian (52:11.911): He was like, this thing is great. And I was like, but can’t you just do that with a Raspberry Pi? Like, isn’t there a PiKVM? And I was like, then I was reading about PiKVM and I’m like, yes, you can buy the enterprise version of it or the commercial version of it, or you can do it yourself. And I was like, well, I’m a DIY Linux guy. Like, I can go create a KVM out of a Raspberry Pi. And then I was like, wow, that looks like a lot of work because I’m a lazy hacker. I’m like, that looks like a lot of work. So maybe that was part of the reason why I was like, let’s evaluate the security of the ones that are easier to deploy and cheaper. Maybe not cheaper than doing it yourself, but yeah. I personally, I like JetKVM based on their response, based on the community.
Paul Asadoorian (52:54.571): The amount of time I spent looking for vulnerabilities and hit dead ends in their web interface, tested a ton of different, not just the SSL, but I tested a ton of different web application vulnerabilities. There is a previously published, I believe RunZero, HD Moore and team were pointed out in their article they released last year that there was an open API endpoint on the JetKVM. And I was trying to leverage that because that particular endpoint, I forget what the URL is, would display log entries. And if you could generate HTML, let’s say, and inject it into the log, you could then, without authentication, hit this API endpoint, and it would render conceivably what you could generate unauthenticated by hitting the device in that page. However, that page content type is text, not HTML. Then I was like, are there ways to get around that?
Paul Asadoorian (54:09.437): And there are certain circumstances where you can, but that wasn’t the case with JetKVM. At least that’s what I found. Now, another researcher wants to prove me wrong. I would love that. That would be great. But I hit a dead end and I was like, wow, I was so close. I thought I had some kind of injection-based attack, but it turned out to be a dead end. So given that, I like the JetKVM. Yeah, if you want to take a look, you’re more than welcome. More than welcome.
Vlad Babkin (54:29.135): Send me, send me, send me, send me.
Paul Asadoorian (54:36.149): But given that I like the JetKVM, I think they’ve done a stand-up job compared to devices at similar price points.
Reynaldo (54:47.787): Definitely, I was actually asked yesterday by a friend what kind of KVM they should get because after the article… But I think I recommended the JetKVM or the PiKVM both, you know, based on the security response. It’s, you know, out of all the KVMs if I had to pick, JetKVM for sure. They’re willing to fix, the reported vulnerabilities quickly.
Paul Asadoorian (55:19.965): Yeah. And I believe they have addressed all those vulnerabilities in the past too. Like I said, a lot of the YouTube reviewers, they fixed some of that stuff. So they’re constantly improving. Well, and it was evidenced by in our testing, they addressed the vulnerability before we could even report it. So they’re certainly paying attention to security, which is a lot of times like all you can really ask, right? Like nobody writes perfectly secure code the first time when it ships. The best you can do is have a good response and improve security over time. What else Chase?
Chase Snyder (55:58.926): Yeah, man, this is, I don’t know, I’m still skimming through the comments and you mentioned PiKVM and it looks like those are like 150 bucks or 250 to 350 for a pre-built unit. So yeah, pretty different price range. And it seems like as the AI tools, the accessibility of building both software and hardware and of like pumping out a tool like this get more and more accessible, you’re going to have more and more people and companies that have kind of the response that you said Anjeet had, which is that they’re just not paying attention to security at all. They’re not participating in the broader culture of including security in their products. We’re thinking about it as they develop. I think a lot of people are just going to. Yeah. The way that vibe coding apps are happening, it’s going to come to hardware devices too, where it’s just going to be so easy to create a product like this and sell some amount of it online. And, people who aren’t careful about it are going to get, going to get popped because of using it. So it sort of changes the, not, not changes, but just continues to reinforce the importance of diligence in your security, your procurement for any sort of product that you’re connecting into your network, whether consumer at home or enterprise. It’s free, you’re the product, right? If it’s cheap, there’s probably something missing that you actually really need.
Paul Asadoorian (57:49.673): Yeah, and security is probably one of those things. And I worry about shadow IT, right? Someone can just go on Amazon, find the Anjeet and deploy it in the network.
Reynaldo (58:03.573): Yeah, and for a lot of those KVMs that were cheaply made, there’s a lot, for sure. Like, Anjeet, if you go to their store page, they have like 15 different list dates for almost identical KVMs, and they’re all kind of… I mean, we haven’t tested them, I imagine they’re not up to the standards that we’d probably like them to be.
Paul Asadoorian (58:36.725): Yeah, because I find a lot of the low cost devices that come out of China, there’s a lot of reasons for that. I think it goes back to batteries as well. Like why you can go on AliExpress and buy batteries really cheap. Why you can go on AliExpress and buy electronics really cheap is, you know, there’s like the second, third shift in the manufacturing plant because they have all the specifications to build devices. So they’ll do a run that’s for a larger manufacturer that has to pass a lot of quality assurance testing and go through all the rigors. And then they’re like, well, the fab’s already set up to build these things. Why don’t we later on just do some runs, not apply a lot of the quality checks to it, cut a bunch of corners, produce it cheaply, sell it direct from China. And that’s how you were able to go on these sites like Temu and AliExpress and the like and buy stuff cheaply. But be careful because when I talk to folks in our community in security, that’s what they’re telling me happens. So right to your point, you look at Anjeet and they’ve got a bunch of SKUs of a bunch of things. That was probably like a nicer model with more quality surrounding it that they did for some contract. But then they’re like, we’ll just do like a few more thousand runs of these and fill a warehouse and sell them direct on Amazon, but they don’t get the quality. They’re not gonna do support as well. They’re not gonna make, in Anjeet’s case, they’re not gonna make firmware available, right? We’re just gonna, firmware works, like ship it. If there’s issues like whatever, the person only paid, you know, 30 to 50 dollars for something that, you know, there’s equivalents that are much more expensive. So, that’s my guess, I don’t know. I have no, I don’t have evidence to back that up, but.
Chase Snyder (01:00:23.862): Yeah, the supply chain is under us all.
Vlad Babkin (01:00:23.885): Yeah, absolute dumbest thing is that at some point we will have to regulate certain industries. Like, IPKVM right now, because of what happens with AI, it will become more more easy to do some kind of solution there, either software or hardware. And a lot more people will do it. And this means a lot more people who don’t even understand what they’re doing will be doing this. So like, hey, I can sell this. And suddenly we will have like absolutely impossible problem of people delivering hardware like this who don’t understand a single thing about security or maybe even development. At some point we will need to create some regulations which will introduce like hefty fines for like missing basic cybersecurity stuff. Otherwise people just have a terrifying perspective of like just about 99.9% of them just not being secure at all.
Chase Snyder (01:01:22.72): I think the EU Cyber Resilience Act is a step in that direction. It has requirements around providing SBOM and even firmware bill of materials, hardware bill of materials, and disclosing vulnerabilities. And it has actual dates of enforcement associated with it. And it has real consequences. You know, it has some teeth, which a lot of the cybersecurity stuff that gets framed as cybersecurity regulations or like, guidelines or whatever just doesn’t have any sort of actual teeth to it. So organizations just don’t do it until they’re going to get audited. And even when they get audited, the downsides of not having done it at that point, you know, it’s just not a, not, it’s not more painful than doing the thing. They’d rather take the audit and fail than actually do the work. Cause that, cause it’s more painful. But the Cyber Resilience Act, I think it’s going to have a similar impact that GDPR had, where organizations that do any business in the EU, it’s going to have pretty wide ranging sort of ripple effects across industries because you’re just not going to be able to, you’re going to experience actual consequences or you’re going to have to stop doing business. It’s going to cut off sort of lanes of doing business for you that go through the EU because of those consequences around letting insecure stuff slip through your own supply chain. Which I think will be painful, but also good.
Paul Asadoorian (01:03:05.106): Yeah, well, thank you all for coming on the show today. Rey, thank you for joining us. Thanks for your awesome work on this project. I certainly look forward to continuing to work with you and see what we come up with next, right? So thanks everyone for listening and watching this edition of the Below the Surface. We’ll see you next time.
