I spent a lot of time last year researching packet radio software for vulnerabilities. I found a remote code execution (RCE) vulnerability in WinAPRS that let me hack into a system over the air. The result is a reverse shell obtained over ham radio where the victim machine doesn't have to be connected to Ethernet at all, as long as they are running a WinAPRS station. Is it practical? Not really. But it was fun and I learned a lot. I always wondered if I could get RCE via ham radio through memory corruption and it feels good to have proved to myself that I can do it.
Another place to look is DSD/mbelib, although to exploit you would have to transmit on a frequency they were monitoring and any replies/confirmation would have to come from another path (Internet). Since a common use case for that software is monitoring public safety frequencies an exploit might actually be practical for law enforcement agencies.
I'm not familiar with DSD/mbelib but based on what I saw with a quick web search this sounds like a really interesting attack vector. I do want to perform some more research in this area, so thanks for the idea.
I can't find it now, but in the olden days of the Internet I read an article about how an up-and-coming band had "hacked" RDS to switch radios to play their song when it was played out on the local station.
The local station had a UHF link from the studio to the TX site that was audio only, a very common setup in the mid-90s, and the RDS flag on the transmitter was switched "in band" by sending a burst of tones over the audio feed, right at the start of the traffic jingle. Slap the traffic announce jingle cart in, hit the button, tune starts with just three quick DTMF digits. Uh-huh, you're seeing where this is going, right?
So if you put those three DTMF digits at the start of your single... :-D
Mbelib is of questionable legality as it implements a codec patented by DVSI. Indeed you might trigger some vulnerability at a hobbyist but a professional would never use it.
And public safety channels here are all encrypted so there's nothing to listen to, perhaps in the US that's not the case.
There's a long history of open source software implementing patented algorithms, especially in the video and audio codec space. Those open source implementations are definitely used by professionals, so I would recommend not being so assured about the scope of use of software that may contain patented algorithms.
The vocal data on public safety channels being reported as encrypted does not necessarily say that there could be no vulnerability there. There's lots of control data that may or may not be encrypted, and encryption does not prevent all kinds of attacks here.
But nobody sells radio sets based on mbelib except the Chinese budget brands (e.g. baofeng) which have circumvented DVSI's patent by setting up a local company that sells the patent because they say they own it (even though they have no right to do it, but DVSI can't sue them in China). But all the public safety ones I've seen are brands like motorola and hytera that buy the real DVSI codecs.
But I'm not saying there are no other vulnerabilities. I'm just saying that there will not be many people using mbelib to listen to public safety frequencies because there is nothing to listen to as it's encrypted.
Excellent work! As I learned more about digital modes and packet radio I had similar thoughts! This is a really cool writeup and I'm stoked someone looked into this.
What's the legality surround security research like this with ham radio? I was under the impression that the airwaves are highly regulated and those regulations could hamstring (forgive the pun) security research, but I also know next to nothing about it.
I'm not a lawyer, but I used my real callsign when doing anything over the air. I used known protocols, no encryption, nothing commercial, etc. This was all against my own lab systems. I don't think I crossed any legal lines here. It probably would have been even better to use some kind of dummy load to further reduce the range of my transmissions but I didn't have anything like that to use at the time. I just kept my power as low as I was able.
I couldn't find where anyone else had done this before with ham radio. That was another motivating factor. It was an interesting new (but, actually old) attack vector. I've always been interested in weird attack vectors like this. I've read some fun research in the past about infrared communications, magnetic strips, etc. Things that are all around us but we don't really think of as attack vectors.
>I've read some fun research in the past about infrared communications, magnetic strips, etc. Things that are all around us but we don't really think of as attack vectors.
Any particular source that you would recommend to start learning about these vectors?
The resources that come to mind are actually all videos of Defcon talks by the same person (Major Malfunction aka Adam Laurie). They are pretty old now, but still interesting.
Thanks! I actually took three OffSec courses last year. The first one I did was the OSWP (wifi) as a sort of warm up because it's the easiest course they offer and I knew I could knock that out pretty quick. Then I took the OSEP course which was a ton of content. Finally I took the OSED which was another ton of content and the most technical of those three. My work gave me 40 hours of in-office time to last year for training. I can't recall if I used that 40 hours for the OSEP or OSED, but I know I used it for one of those two. However, I still put in a ton of hours on my own time too. It's just a lot of content to go through. 40 hours isn't enough time for either of those courses in my opinion. Having no children (and an understanding spouse) made it easier for me to dedicate a lot of personal time on the training. I love OffSec's stuff though and recommend it to anyone who is into offensive security and wants practical training.
Yeah, I've thought about this a lot with the increased popularity of digital modes. Especially those small programs made by one or two people, just as you identified. I mean, I crashed a friend's radio simply by sending him an SMS over DMR (seems like a known issue/limitation with the radio firmware). Even well-established products are susceptible to attacks. No different from any other modern tech I guess :)
I'd like to spend some time digging into radio/tnc firmware for vulnerabilities but that's a bit over my head. I've managed to dump the firmware from my TNC but I haven't found a good way to get it disassembled yet. I've got a partial disassembly, but that's it. Unfortunately, I won't have more time to work on that for a few months.
I still don't understand why the amateur radio community has this disdain for open source. It feels like a majority of the popular amateur radio software tools out there are closed source freeware projects.
I'm not sure that it's disdain. I think it might just be more that it's a niche that matured in a different era, and the solutions are "good enough" to not warrant the recreation of these tools from scratch.
The amateur radio community isn't enormous, and the overlap between operator and developer doesn't always exist.
Because you are able to build and modify radios as a ham, many do and charge for said hardware. This just spilled over into software where people feel they should be paid for the work they’ve done just like the hardware folks. And since a lot of that started before OSS was popular it’s strangely stuck around.
That said some of the most popular ham software (like WSJT-X) are open source. I think the trend is starting to shift the other direction.
With CVEs for ham radio, clearly the next step is to add ATT&CK tactics and techniques. If you compromise a PC that's connected to a ham radio, you might be able to transmit maliciously, or interfere with the radio owner's ability to transmit or receive. But it turns out that ham radio isn't only about communicating with other ham radio people - it's also about using PKI to store details of who you communicated with: https://lotw.arrl.org/lotw-help/developer-pki/
Private key disclosure seems catastrophic because of their scorched-earth security policy https://lotw.arrl.org/lotw-help/certificatesecurity/ where the server admins plan to invalidate all signed data, even if the same data had been sitting on the central server for years before the compromise happened. Yet, the docs don't recommend a password for the private key except on "shared or public computers." The adversary just looks for -----BEGIN PRIVATE KEY----- in a text file in a keys directory (the filename is the call letters).
In other words, although executing cmd.exe is a wonderful accomplishment, there's also the possibility of 1. wait for the PC and radio to be idle, 2. tune the radio to a clear frequency, 3. open the victim's private key file, 4. transmit the private key with Morse code.
The station model doesn't matter. The version of Windows is important, though. WiFi and Ethernet are not involved at all here. The victim machine has a radio and KISS TNC hooked up to their PC running WinAPRS. The attacker crafts a malicious AX.25 packet and sends it from their own station. When the victim's radio receives the packet, WinAPRS attempts to parse it and the exploit is triggered. The attacker just has to be within range of the victim station to trigger the exploit.
I'm not sure if you are the same Cliff Stoll who wrote 'The Cuckoo's Egg', but if so I listened to the audio book in 2020 during the first part of the pandemic and I loved it. It was fascinating to see how a small billing discrepancy led you down such a rabbit hole. I also enjoyed the various solutions you came up with to crack the case using the technology of the time. I enjoy reading about the early days of the Internet. I have a sort of nostalgia for it, even though I didn't get on the net myself until around 1997. Your book hit a sweet spot for me with the combination of (now) retro technology and security. You might guess from this ham radio hacking post that I enjoy that kind of thing. If you are that Cliff Stoll, thanks for sharing your story!
Yes, user you replied to is the author The Cuckoo's Egg according to this comment by the same user, which includes an explanation of how the book came to be:
