LuaRadio Gives Insight Into SDR

December 24, 2019 by Al Williams 3 Comments

In theory, you shouldn’t need any help to develop a software-defined radio (SDR) application. But in real life you really don’t want to roll your own code every time to read the IQ samples, perform various transformations on them, and then drive audio output. At worst, you’ll use some libraries (perhaps GNU Radio) but usually, you’ll use some higher-level construct such as GNU Radio Companion (GRC). GRC is a bit heavyweight, though, so if you’ve found it daunting before, you might check out some of the material on the LuaRadio website.

We’ve looked at LuaRadio several years ago, but it has undergone a lot of changes since then and has some excellent documentation. Like Lua itself, LuaRadio emphasizes fast scripting. It supports quite a few pieces of common hardware and nearly anything that feeds data through a soundcard.

Continue reading “LuaRadio Gives Insight Into SDR” →

This Week In Security: VPNs, Patch Tuesday, And Plundervault

December 13, 2019 by Jonathan Bennett 11 Comments

An issue in Unix virtual private networks was disclosed recently, where an attacker could potentially hijack a TCP stream, even though that stream is inside the VPN. This attack affects OpenVPN, Wireguard, and even IPSec VPNs. How was this possible? Unix systems support all manner of different network scenarios, and oftentimes a misconfiguration can lead to problems. Here, packets sent to the VPNs IP address are processed and responded to, even though they are coming in over a different interface.

The attack initially sounds implausible, as an attacker has to know the Virtual IP address of the VPN client, the remote IP address of an active TCP connection, and the sequence and ACK numbers of that connection. That’s a lot of information, but an attacker can figure it out one piece at a time, making it a plausible attack. Continue reading “This Week In Security: VPNs, Patch Tuesday, And Plundervault” →

RPi4: Now Overclocked, Net-Booted, And Power-Sipping

October 30, 2019 by Jenny List 58 Comments

It has now been a few months since the launch of the Raspberry Pi 4, and it would only be fair to describe the launch as “rocky”. While significantly faster than the Pi 3 on paper, its propensity for overheating would end up throttling down the CPU clock even with the plethora of aftermarket heatsinks and fans. The Raspberry Pi folks have been working on solutions to these teething troubles, and they have now released a bunch of updates in the form of a new bootloader, that lets the Pi 4 live up to its promise. (UPDATE: Here’s the download page and release notes)

The real meat of the update comes in an implementation of a low power mode for the USB hub. It turns out that the main source of heat on the SoC wasn’t the CPU, but the USB. Fixing the USB power consumption means that you can run the processor cool at stock speeds, and it can even be overclocked now.

There is also a new tool for updating the Pi bootloader, rpi-eeprom, that allows automatic updates for Pi 4 owners. The big change is that booting the Pi 4 over the network or an attached USB device is now a possibility, which is a must if you’re installing the Pi permanently. There are some fixes that caused problems with certain HATs, in which the Pi 4’s 3.3 V line was cycled during a reboot.

With a device as complex as a Raspberry Pi it comes as no surprise that it might ship with a few teething troubles. We’ve already covered some surrounding the USB-C power, for example. And the overheating. Where the Pi people consistently deliver though is in terms of support, both official and from the community, and we’re very pleased to see them come through in this case too.

This Word Clock Has Dirty Alphanumeric Mouth

September 29, 2019 by Tom Nardi 7 Comments

Clocks which use words to tell the time in place of numbers are an increasingly popular hacker project, but we have to admit that before seeing this gorgeous clock from [Mitch Feig], we didn’t realize how badly we wanted to see one that could curse like a sailor.

But don’t worry, the WordClock-1 knows more than just the bad words. Rather than using an array of illuminated letters as we’ve seen in previous clocks, this one uses six alphanumeric LED displays. So not only can it display the time expressed with words and numbers, but it can show pretty much any other text you might have in mind.

[Mitch] is partial to having his clock toss a swear word on the display every few seconds, but perhaps you’d rather have it show some Klingon vocabulary to help you brush up. The lack of extended characters does limit its language capabilities somewhat, but it still manages to include Spanish, Italian, French, and Croatian libraries.

The ESP32 powered clock comes as a kit, and [Mitch] has provided some very thorough documentation that should make assembling it fairly straightforward as long as you don’t mind tackling a few SMD components. Additional word databases are stored on an SD card, and you can easily add your own or edit the existing ones with nothing more exotic than a text editor. The clock itself is configured via a web interface, and includes features like RGB LED effects and support for pulling the time down from an external GPS receiver.

Of course, if you’re content with what we can apparently now refer to as “old style” word clocks, we’ve seen plenty of projects which should serve as inspiration for anyone looking to roll their own textual timepiece.

Continue reading “This Word Clock Has Dirty Alphanumeric Mouth” →

This Week In Security: Black Hat, DEF CON, And Patch Tuesday

August 16, 2019 by Jonathan Bennett 11 Comments

Blackhat and DEF CON both just wrapped, and Patch Tuesday was this week. We have a bunch of stories to cover today.

First some light-hearted shenanigans. Obviously inspired by Little Bobby Tables, Droogie applied for the vanity plate “NULL”. A year went by without any problems, but soon enough it was time to renew his registration. The online registration form refused to acknowledge “NULL” as a valid license plate. The hilarity didn’t really start until he got a parking ticket, and received a bill for $12,000. It seems that the California parking ticket collection system can’t properly differentiate between “NULL” and a null value, and so every ticket without a license plate is now unintentionally linked to his plate.

In the comments on the Ars Technica article, it was suggested that “NULL” simply be added to the list of disallowed vanity plates. A savvy reader pointed out that the system that tracks disallowed plates would probably similarly choke on a “NULL” value.

Hacking an F-15

In a surprising move, Air Force officials brought samples of the Trusted Aircraft Information Download Station (TADS) from an F-15 to DEF CON. Researchers were apparently able to compromise those devices in a myriad of ways. This is a radical departure from the security-through-obscurity approach that has characterized the U.S. military for years.

Next year’s DEF CON involvement promises to be even better as the Air Force plans to bring researchers out to an actual aircraft, inviting them to compromise it in every way imaginable.

Patch Tuesday

Microsoft’s monthly dump of Windows security fixes landed this week, and it was a doozy. First up are a pair of remotely exploitable Remote Desktop vulnerabilities, CVE-2019-1222 and CVE-2019-1226. It’s been theorized that these bugs were found as part of an RDP code review launched in response to the BlueKeep vulnerability from earlier this year. The important difference here is that these bugs affect multiple versions of Windows, up to and including Windows 10.

What the CTF

Remember Tavis Ormandy and his Notepad attack? We finally have the rest of the story! Go read the whole thing, it’s a great tale of finding something strange, and then pulling it apart looking for vulnerabilities.

Microsoft Windows has a module, MSCTF, that is part of the Text Services Framework. What does the CTF acronym even stand for? That’s not clear. It seems that CTF is responsible for handling keyboard layouts, and translating keystrokes based on what keyboard type is selected. What is also clear is that every time an application builds a window, that application also connects to a CTF process. CTF has been a part of Microsoft’s code base since at least 2001, with relatively few code changes since then.

CTF doesn’t do any validation, so an attacker can connect to the CTF service and claim to be any process. Tavis discovered he could effectively attempt to call arbitrary function pointers of any program talking to the same CTF service. Due to some additional security measures built into modern Windows, the path to an actual compromise is rather convoluted, but by the end of the day, any CFT client can be compromised, including notepad.

The most interesting CFT client Tavis found was the login screen. The exploit he demos as part of the write-up is to lock the computer, and then compromise the login in order to spawn a process with system privileges.

The presence of this unknown service running on every Windows machine is just another reminder that operating systems should be open source.

Biostar 2

Biostar 2 is a centralized biometric access control system in use by thousands of organizations and many countries around the globe. A pair of Israeli security researchers discovered that the central database that controls the entire system was unencrypted and unsecured. 23 Gigabytes of security data was available, including over a million fingerprints. This data was stored in the clear, rather than properly hashed, so passwords and fingerprints were directly leaked as a result. This data seems to have been made available through an Elasticsearch instance that was directly exposed to the internet, and was found through port scanning.

If you have any exposure to Biostar 2 systems, you need to assume your data has been compromised. While passwords can be changed, fingerprints are forever. As biometric authentication becomes more widespread, this is an unexplored side effect.

An SDR Transceiver The Old-School Way

June 29, 2019 by Jenny List 4 Comments

Software-defined radios or SDRs have provided a step-change in the way we use radio. From your FM broadcast receiver which very likely now has single-application SDR technology embedded in a chip through to the all-singing-all-dancing general purpose SDR you’d find on an experimenter’s bench, control over signal processing has moved from the analogue domain into the digital. The possibilities are limitless, and some of the old ways of building a radio now seem antiquated.

[Pete Juliano N6QW] is an expert radio home-brewer of very long standing, and he’s proved there’s plenty of scope for old-fashioned radio homebrewing in an SDR with his RADIG project. It’s an SDR transceiver for HF which does all the work of quadrature splitting and mixing with homebrewed modules rather than the more usual technique of hiding it in an SDR chip. It’s a very long read in a diary format from the bottom up, and what’s remarkable is that he’s gone from idea to working SDR over the space of about three weeks.

So what goes into a homebrew SDR? Both RF preamplifier, filters, and PA are conventional as you might expect, switched between transmit and receive with relays. A common transmit and receive signal path is split into two and fed to a pair of ADE-1 mixers where they are mixed with quadrature local oscillator signals to produce I and Q that is fed to (or from in the case of transmit) a StarTech sound card. The local oscillator is an Si5351 synthesiser chip in the form of an SDR-Kits USB-driven module, and the 90 degree phased quadrature signals are generated with a set of 74AC74 flip-flops as a divider.

Running the show is a Raspberry Pi running Quisk, and though he mentions using a Teensy to control the Si5351 at the start of his diary it seems from the pictures of the final radio that the Pi has taken on that work. It’s clear that this is very much an experimental radio as it stands with wired-together modules on a wooden board, so we look forward to whatever refinements will come. This has the feel of a design that could eventually be built by many other radio amateurs, so it’s fascinating to be in at the start.

If I and Q leave you gasping when it comes to SDR technology, maybe we can help.

Thanks [Bill Meara N2CQR] for the tip!

Impersonate The President With Consumer-Grade SDR

June 26, 2019 by Tom Nardi 43 Comments

In April of 2018, the Federal Emergency Management Agency sent out the very first “Presidential Alert”, a new class of emergency notification that could be pushed out in addition to the weather and missing child messages that most users were already familiar with. But while those other messages are localized in nature, Presidential Alerts are intended as a way for the Government to reach essentially every mobile phone in the country. But what if the next Presidential Alert that pops up on your phone was actually sent from somebody with a Software Defined Radio?

According to research recently released by a team from the University of Colorado Boulder, it’s not as far-fetched a scenario as you might think. In fact, given what they found about how the Commercial Mobile Alert Service (CMAS) works, there might not be a whole lot we can even do to prevent it. The system was designed to push out these messages in the most expedient and reliable way possible, which meant that niceties like authentication had to take a backseat.

The thirteen page report, which was presented at MobiSys 2019 in Seoul, details their findings on CMAS as well as their successful efforts to send spoofed Presidential Alerts to phones of various makes and models. The team used a BladeRF 2.0 and USRP B210 to perform their mock attacks, and even a commercially available LTE femtocell with modified software. Everything was performed within a Faraday cage to prevent fake messages from reaching the outside world.

So how does the attack work? To make a long story short, the team found that phones will accept CMAS messages even if they are not currently authenticated with a cell tower. So the first phase of the attack is to spoof a cell tower that provides a stronger signal than the real ones in the area; not very difficult in an enclosed space. When the phone sees the stronger “tower” it will attempt, but ultimately fail, to authenticate with it. After a few retries, it will give up and switch to a valid tower.

This negotiation takes around 45 seconds to complete, which gives the attacker a window of opportunity to send the fake alerts. The team says one CMAS message can be sent every 160 milliseconds, so there’s plenty of time to flood the victim’s phone with hundreds of unblockable phony messages.

The attack is possible because the system was intentionally designed to maximize the likelihood that users would receive the message. Rather than risk users missing a Presidential Alert because their phones were negotiating between different towers at the time, the decision was made to just push them through regardless. The paper concludes that one of the best ways to mitigate this attack would be to implement some kind of digital signature check in the phone’s operating system before the message gets displayed to the user. The phone might not be able to refuse the message itself, but it can at least ascertain it’s authentic before showing it to the user.

All of the team’s findings have been passed on to the appropriate Government agencies and manufacturers, but it will likely be some time before we find out what (if any) changes come from this research. Considering the cost of equipment that can spoof cell networks has dropped like a rock over the last few years, we’re hoping all the players can agree on a software fix before we start drowning in Presidential Spam.