Impersonate The President With Consumer-Grade SDR

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.

You’ll Really Want An “Undo” Button When You Accidentally Send A Ballistic Missile Warning

Hawaiians started their weekend with quite a fright, waking up Saturday morning to a ballistic missile alert that turned out to be a false alarm. In between the public anger, profuse apologies from officials, and geopolitical commentary, it might be hard to find some information for the more technical-minded. For this audience, The Atlantic has compiled a brief history of infrastructure behind emergency alerts.

As a system intended to announce life-critical information when seconds count, all information on the system is prepared ahead of time for immediate delivery. As a large hodgepodge linking together multiple government IT systems, there’s no surprise it is unwieldy to use. These two aspects collided Saturday morning: there was no prepared “Sorry, false alarm” retraction message so one had to be built from scratch using specialized equipment, uploaded across systems, and broadcast 38 minutes after the initial false alarm. In the context of government bureaucracy, that was really fast and must have required hacking through red tape behind the scenes.

However, a single person’s mistake causing such chaos and requiring that much time to correct is unacceptable. This episode has already prompted a lot of questions whose answers will hopefully improve the alert system for everyone’s benefit. At the very least, a retraction is now part of the list of prepared messages. But we’ve also attracted attention of malicious hackers to this system with obvious problems in design, in implementation, and also has access to emergency broadcast channels. The system needs to be fixed before any more chaotic false alarms – either accidental or malicious – erode its credibility.

We’ve covered both the cold-war era CONELRAD and the more recent Emergency Broadcast System. We’ve also seen Dallas’ tornado siren warning system hacked. They weren’t the first, they won’t be the last.

(Image: Test launch of an unarmed Minuteman III ICBM via US Air Force.)

Radio Apocalypse: The Emergency Broadcast System

Some sounds are capable of evoking instant terror. It might be the shriek of a mountain lion, or a sudden clap of thunder. Whatever your trigger sound, it instantly stimulates something deep in the lizard brain that says: get ready, danger is at hand.

For my part, you can’t get much scarier than the instantly recognizable two-tone alert signal (audio link warning) from the Emergency Broadcast System (EBS). For anyone who grew up watching TV in the 60s and 70s in the US, it was something you heard on at least a weekly basis, with that awful tone followed by a grave announcement that “the broadcasters of your area, in voluntary cooperation with the FCC and other authorities, have developed this system to keep you informed in the event of an emergency.” It was a constant reminder that white-hot death could rain from the sky at any moment, and the idea that the last thing you may ever hear was that tone was sickening.

While I no longer have a five-year-old’s response to that sound, it’s still a powerful reminder of a scary time. And the fact that it’s still in use today, at least partially, seems like a good reason to look at the EBS in a little more depth, and find out the story behind the soundtrack of the end of the world.

Continue reading “Radio Apocalypse: The Emergency Broadcast System”

Better Tornado Warnings With Polygons And Pi

Everyone pays close attention to the weather, but for those who live where tornadoes are prevalent, watching the sky can be a matter of life and death. When the difference between making it to a shelter or getting caught in the open can be a matter of seconds, it might make sense to build an internet enabled Raspberry Pi weather alert system.

We know what you’re thinking – why not just buy an off-the-shelf weather alert radio with Specific Area Message Encoding (SAME) reporting, or just rely on a smartphone app? As [Jim Scarborough] explains, living in the heart of Tornado Alley and having had a brush with tragedy as a kid teaches you not to be complacent with severe weather. He found a problem with the SAME system: lack of locational granularity below the county level, leading to a tendency to over-warn during tornado season. [Jim]’s build seeks to improve SAME by integrating National Weather Service polygon warnings, which define an area likely to see a severe weather event as a collection of geographic vertices rather than a political unit. He’s using a Raspberry Pi NOAA weather radio receiver with SAME decoding, and while details are sparse and the project is ongoing, the idea seems to be to use the Pi to scrape the NWS site for polygon data once a county-level warning is issued.

It’s an interesting idea, and one we’ll be keeping an eye on as [Jim] continues his build. In the meantime, you can brush up on weather radio and SAME encoding with this Arduino SAME decoder.

[via r/weather]