The $50 Ham: Checking Out the Local Repeater Scene

So far in this series, we’ve covered the absolute basics of getting on the air as a radio amateur – getting licensed, and getting a transceiver. Both have been very low-cost exercises, at least in terms of wallet impact. Passing the test is only a matter of spending the time to study and perhaps shelling out a nominal fee, and a handy-talkie transceiver for the 2-meter and 70-centimeter ham bands can be had for well under $50. If you’re playing along at home, you haven’t really invested much yet.

The total won’t go up much this week, if at all. This time we’re going to talk about what to actually do with your new privileges. The first step for most Technician-class amateur radio operators is checking out the local repeaters, most of which are set up exactly for the bands that Techs have access to. We’ll cover what exactly repeaters are, what they’re used for, and how to go about keying up for the first time to talk to your fellow hams.

Continue reading “The $50 Ham: Checking Out the Local Repeater Scene”

A Network Attached Radiation Monitor

It started as a joke, as sometimes these things do. [Marek Więcek] thought building a personal radiation detector would not only give him something to work on, but it would be like having a gadget out of the Fallout games. He would check the data from time to time and have a bit of a laugh. But then things got real. When he started seeing rumors on social media that a nearby nuclear reactor had suffered some kind of radiation leak, his “joke” radiation detector suddenly became serious business.

With the realization that having his own source of detailed environmental data might not be such a bad idea after all, [Marek] has developed a more refined version of his original detector (Google Translate). This small device includes a Geiger counter as well as sensors for more mundane data points such as temperature and barometric pressure. Since it’s intended to be a stationary monitoring device, he even designed it to be directly plugged into an Ethernet network so that it can be polled over TCP/IP.

[Marek] based the design around a Soviet-era STS-5 Geiger tube, and outfitted his board with the high voltage electronics to provide it with the required 400 volts. Temperature, barometric pressure, and humidity are read with the popular Bosch BME280 sensor. If there’s no Ethernet network available, data from the sensors can be stored on either the built-in SPI flash chip or a standard USB flash drive.

The monitor is powered by a PIC32MX270F256B microcontroller with an Ethernet interface provided by the ENC28J60 chip. In practice, [Marek] has a central Raspberry Pi that’s polling the monitors over the network and collecting their data and putting it into a web-based dashboard. He’s happy with this setup, but mentions he has plans to add an LCD display to the board so the values can be read directly off of the device. He also says that a future version might add WiFi for easier deployment in remote areas.

Over the years we’ve seen a fair number of radiation monitors, from solar-powered WiFi-connected units to the incredible work [Radu Motisan] has done building his global network of radiation detectors. It seems hackers would rather not take somebody else’s word for it when it comes to the dangers of radiation.

This Tiny Router Could be the Next Big Thing

It seems like only yesterday that the Linksys WRT54G and the various open source firmware replacements for it were the pinnacle of home router hacking. But like everything else, routers have gotten smaller and faster over the last few years. The software we run on them has also gotten more advanced, and at this point we’ve got routers that you could use as a light duty Linux desktop in a pinch.

But even with no shortage of pocket-sized Linux devices in our lives, the GL-USB150 “Microrouter” that [Mason Taylor] recently brought to our attention is hard to ignore. Inside this USB flash drive sized router is a 400 MHz Qualcomm QCA9331 SoC, 64 MB of RAM, and a healthy 16 MB of storage; all for around $20 USD. Oh, and did we mention it comes with OpenWRT pre-installed? Just plug it in, and you’ve got a tiny WiFi enabled Linux computer ready to do your bidding.

On his blog [Mason] gives a quick rundown on how to get started with the GL-USB150, and details some of the experiments he’s been doing with it as part of his security research, such as using the device as a remote source for Wireshark running on his desktop. He explains that the diminutive router works just fine when plugged into a USB battery bank, offering a very discreet way to deploy a small Linux box wherever you may need it. But when plugged into a computer, things get really interesting.

If you plug the GL-USB150 into a computer, it shows up to the operating system as a USB Ethernet adapter and can be used as the primary Internet connection. All of the traffic from the computer will then be routed through the device to whatever link to the Internet its been configured to use. Depending on how you look at it, this could be extremely useful or extremely dangerous.

For one, it means that something that looks all the world like a normal USB flash drive could be covertly plugged into a computer and become a “wiretap” through which all of the network traffic is routed. That’s the bad news. On the flip side, it also means you could configure the GL-USB150 as a secure endpoint that lets you quickly and easily funnel all the computer’s traffic through a VPN or Tor without any additional setup.

We’ve seen all manner of hacks and projects that made use of small Linux-compatible routers such as the TP-Link TL-MR3020, but we expect the GL-USB150 and devices like it will be the ones to beat going forward. Let’s just hope one of them doesn’t show up uninvited in your network closet.

BSD Breathes New Life Into Obsolete Equipment

An old laptop or desktop computer that’s seen better days might still have a little bit of use left in it for a dedicated task. Grabbing a lightweight flavor of Linux and running a web server, firewall, or Super Nintendo emulator might get a few more years out of it. You can also get pretty creative repurposing obsolete single purpose  machines, as [Kristjan] did with some old Cisco server equipment.

The computer in question isn’t something commonly found, either. It’s an intrusion detection system meant to mount in a server rack and protect the server itself from malicious activity. While [Kristjan] mentions that Cisco equipment seems to be the definition of planned obsolescence, we think that this Intel Celeron machine with an IDE hard drive may have gone around the bend quite some time ago. Regardless, it’s modern enough to put back to work in some other capacity.

To that end, a general purpose operating system was installed, and rather than use Linux he reached for BSD to get the system up and running. There’s one other catch, though, besides some cooling issues. Since the machine was meant to be used in a server, there’s no ACPI which means no software shutdown capability. Despite all the quirks, you can still use it to re-implement a network security system if you wanted to bring it full-circle.

Memcached Servers Abused For DDoS Attacks

Cloudflare announced recently that they are seeing an increase in amplification attacks using memcached servers, and that this exploit has the potential to be a big problem because memcached is capable of amplifying an attack significantly. This takes DDoS attacks to a new level, but the good news is that the problem is confined to a few thousand misconfigured servers, and the solution is to put the servers behind a tighter firewall and to disable UDP. What’s interesting is how the fundamental workings of the Internet are exploited to create and direct a massive amount of traffic.

We start with a botnet. This is when a bunch of Internet-connected devices are compromised and controlled by a malicious user. This could be a set of specific brand of web camera or printer or computer with unsecured firmware. Once the device is compromised, the malicious user can control the botnet and have it execute code. This code could mine cryptocurrency, upload sensitive data, or create a lot of web traffic directed at a particular server, flooding it with requests and creating a distributed denial of service (DDoS) attack that takes down the server. Since the server can’t distinguish regular traffic from malicious traffic, it can’t filter it out and becomes unresponsive.

This DDoS attack is limited to the size of the botnet’s bandwidth, though. If all the web cameras in the botnet are pounding a server as fast as they can, the botnet has reached its max. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn’t then oh well. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address.

So if the web camera sends a request to Server A and the response is sent to Server B, then Server A is unintentionally attacking Server B. If the request is the same size as the response, then there’s no benefit to this attack. If the request is smaller than the response, and Server A sends Server B a bunch of unrequested data for every request from the camera, then you have a successful amplification attack. In the case of memcached, traffic can be amplified by more than 50,000 times, meaning that a small botnet can have a huge effect.

Memcached is a memory caching system whose primary use is to help large websites by caching data that would otherwise be stored in a database or API, so it really shouldn’t be publicly accessible anyway.  And the solution is to turn off public-facing memcached over UDP, but the larger solution is to think about what things you are making available to the Internet, and how they can be used maliciously.

Router Rebooter Eliminates Hassles

Some low-end or older routers might get you a decent WiFi network in your house or apartment, but often these cheaply made devices are plagued with subtle software problems that cause the router itself to become unresponsive after a few days of operating. One solution is to just power cycle the router by hand whenever the Internet disappears, but a better solution is to build something that does that for you.

[Charlie] had this problem as the de facto IT person in his family, and didn’t want to keep getting bothered for such a simple problem. His solution involves a relay, an ESP8266, and a Wemos D1 mini. The device connects to the Internet through the router and occasionally sends out pings to another address. If it can’t ping the address successfully after a certain time period, the device power cycles the router by activating the relay.

Since this isn’t the newest idea out there, there are many ways to solve this problem if you are constantly annoyed by router issues, whether from your own router or from friends and family who treat you as their personal IT department. One solution doesn’t involve any extra hardware at all as long as you have a computer near your router/modem already, and others solve this problem when it happens to the modem rather than the router.

Continue reading “Router Rebooter Eliminates Hassles”

34C3: Roll Your Own Network Driver In Four Simple Steps

Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.

Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.

Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps”