BBS Botnet – The Packet Radio Cybersecurity Crisis in Ham Radio

Ham radio operators are generally technically inclined people. It takes a special person to take an interest in the electronic aspect of amateur radio stations. Combine this with the computer knowledge and passion it takes to develop the applications that often go along with the hobby, you wouldn’t think something as novel as cyber security would be an issue. But combine the confidence of a skilled technician with the popular use of often archaic software/hardware, and you have the cybersecurity crisis in Amateur Radio.

The Inherent Vulnerabilities of Ham Radio Operators

In the security industry, we often say humans are the weakest link. Radio amateurs are especially vulnerable due to our inherent trust in others. The hobby itself encourages comradery between it’s members. Between clubs, competitions, and other events, there’s a trust we build between each other. The license alone generally keeps people in check. The problem is when we assume others will behave the same way online. Armed with technical proficiency, amateurs often host their own applications on servers and personal computers. The spirit to share information and provide service to others encourages us to expose these services to the world. Combine that with the fact that the average ARRL member is 68 years old, and the cyber threat has changed dramatically over the past 20 years, and you can see where some problems begin. Old dogs CAN learn new tricks, don’t get me wrong. But the younger generation who have grown up with the cyber menace must contribute as well, we must all be informed, and willing to accept when things should be better.

It’s important to show evidence of such arguments. As a security researcher, I recognize there is a blurred line about what NEEDS to be talked about, and what SHOULD be. I will tiptoe this line in an effort to bring awareness, without tipping off attackers as best I can. At some point however, we must drag the ugly into light so we can see the hard truth. It’s the only way to bring to light the Cybersecurity Crisis in Ham Radio

The Online BBS Node- A Web of Weakness

I’ve been working on a “Packet Radio Series” on my YouTube channel. The goal is consolidating lots of information about packet radio in a modern way, with best security practices in mind. I understood BBS software like BPQ32 or JNOS were from a much earlier age of the internet (even before). The software is still being maintained, but the culture never changed. After discovering an unauthenticated buffer overflow in one of these applications, I submitted a private vulnerability disclosure. The vulnerability was promptly patched. After finding several nodes online exposed to the wild web, I acknowledged that this is worth talking about. I’m picking on BPQ32 mainly here, because that’s the one I’ve dug into. One can see an example of the numerous online exposed nodes with something as simple as using a google dork “intitle:”BPQ32 Web”“

Use of Insecure Protocols

Telnet (the service in question) shouldn’t be used in 2024 over any wire whatsoever. Telnet used in this fashion contributes to CWE-319.(Cleartext Transmission of Sensitive Information). Yes, your SYSOP password is indeed sensitive. Telnet has a cousin in the same boat, HTTP. With BBS software, these services come packaged together as management solutions. The point being, don’t use either for administration if you’re not okay with everyone between you and your node also being a SYSOP. Had everyone followed these best practices, the buffer overflow wouldn’t be an issue, and neither would the next part.

Volunteering the Keys

Being conscientious sanitarians as they are, hams often post the configuration for these nodes online for other use. Hams often post these files for troubleshooting as well. These files very often contain login credentials, and open ports contributing to CWE-538 (Improper Removal of Sensitive Information Before Storage or Transfer). This was especially blatant when doing research on Packet Radio Nodes. The worst offenders came about from a true ignorance in the ways of the internet combined with a innate trust in their fellow hams. If you google something such as “bpq32 ANON,pass” you will come across a frightening amount of amateurs who have volunteered ports, hosts/IPs and authentication for public display to the most dangerous cyber landscape in existence(the internet). Unless you intend for every single person in the world access to your node (and every single one connected to it) we now have CWE-306 .But the rabbit hole gets deeper.

You may be thinking you’re in the clear, but we aren’t done yet. The points above are in fact a side effect of the culture. The next two parts are oversights in configuration due to a lack of clear documentation. What was not important enough to disclose then, is now extremely relevant.

Unintended Access

So you’ve done your homework, used best practices, and are now ready to expose your node externally to form Node <-> Node connections with others over the internet. BPQ32 Documentation and online research will all suggest you add a Map statement to a new AXIP / BPQAXIP port, and forward port UDP 10093. The problem arises because just about every single example configuration online includes the “AUTOADDMAP” option. This includes the example configuration for AXIP on the official BPQ32’s docs. Here, we’re introduced to CWE-1188(Initialization of a Resource with an Insecure Default). If you do a combination of forwarding this port, along with using the default AUTOADDMAP option, you now give anyone in the world access to your node, and it’s applications. There is no longer a map statement needed from you to give any weirdo on the internet access to your radio equipment. How would they find your IP? Assuming you didn’t post it above, remember the entire internet can be scanned for all exposed nodes via its default port in about 5 minutes. A friendly remember that security by obscurity in isolation is not security at all.

Linking to Danger

Assuming you’ve done everything right up until now, good job. The only threat you have left is your fellow hams. The nature of these BBS nodes means everyone is connected together for the most part. By default, once on a node, a user can issue the “Connect” command to move adjacently. This is enabled with the “NODE=1” command that is shipped with the “SIMPLE” or default configuration option. You can see how this may be a problem due to the above major disregard or lack of knowing of proper security measures. The point of all of this is, in any given packet radio network, all it takes is a single internet facing node with a port forwarded, using default configuration options to put every single node and radio in that network in danger of being abused. After doing all of the right things, in the end our friends become our biggest vulnerability. But that’s still not all.

If you are unfortunate enough to have one of these problematic nodes on your packet network (statistics say you probably do), and your node has internet access with telnet enabled, now you can get into real trouble.

How a Packet Radio Network becomes a Botnet

Now if you’ve enabled telnet with basically ANY default configuration file, example, config, or installation guide found on the internet, you probably missed a pretty important option, SECURETELNET=1. You will see this mentioned on the official telnet config docs on the BPQ32 Website, but it still isn’t included in it’s given example. A few examples of this missing in pages intended to guide users can be found on popular sites like packet-radio.net, https://wiki.oarc.uk/, and https://www.wh6fqe.com/bpq32-config. So what does this option do? If you have a telnet port (as most example configs do and suggest), and this option isn’t present (which it’s not unless you intentionally added it, which you probably didn’t), anyone can use your node to send outbound connections to virtually any internet server due to the nature of telnet. To a malicious actor, this makes your node a bot, useful for brute forcing logins, and attacking other servers.

You can see an example of this here, where I was able to connect to a Node over HF, and use it’s TELNET port to connect back out to another node via telnet. But this could have been just as easily used to attack any other server. I’ve blanked out the users NODE info to protect them:

Conclusion

Upon visiting one of the “Groups.IO” pages for one of these BBS applications I saw my final nail. A user had issues with windows restarting, killing one of their node modems. The thread was full of helpful people rushing in with various windows update blocking fixes. Someone even mentioned running Windows 7, which hasn’t gotten a security update in 4 years. This implies all of these users were getting update notifications (internet connected PCs), were running BBS software on them, and were still denying themselves security updates at all costs. Under this thread was a user needlessly posting their public BBS telnet, and HTTP connection information, along with a config file with login credentials included. SECURETELNET was not enabled, advertising themselves as a free BOT for any keen attacker. I realized I would never want to interface my node with any of these users, and that made me sad.

In a packet radio network, you can screen a single users willing to form a Node to Node link. But you can’t screen them all. Until we change the default configurations that we share with others to implement best security practices, and discourage bad practice, our amateur radio allies are as good as adversaries in the current security climate. By abiding by the basics we can clean a lot of this mess up.

Takeaways

• Use SSH port forwarding/tunneling for administration access if nothing else is available in place of telnet/http over the web.
• The entire world wide web does not need your configured ports and credentials. Take them out of your config files before uploading them online.
• Review official documentation before exposing services online. This would prevent vulnerabilities that come with AUTOADDMAP, and a lack of SECURETELNET.
• Keep your applications up to date, as well as your operating system.
• Review your log files for any strange connections.
• In any given internal network like that such as packet radio, do not expect everyone to be following best practices. One user could be sharing their node online with free anonymous access, meaning they are sharing yours too.

Sources

https://www.arrl.org/files/file/QST/This%20Month%20in%20QST/May2019/May%20Editorial.pdf
https://csrc.nist.gov/glossary/term/cyber_threat
https://learningnetwork.cisco.com/s/blogs/a0D3i000002SKPuEAO/why-telnet-is-bad
https://cwe.mitre.org/data/definitions/212.html
https://cwe.mitre.org/data/definitions/862.html
https://thechief.io/c/editorial/how-to-scan-the-internet-in-5-minutes
https://cwe.mitre.org/data/definitions/1188.html

Please leave this field empty

Consider Subscribing!

Signup for our once a month newsletter!

Email Address *

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.