US Emergency Alert System private SSH key mistakenly distributed

http://arstechnica.com/security/2013/07/we-interrupt-this-program-to-warn-the-emergency-alert-system-is-hackable/

by croikle • 13 years ago

159 39 13 years ago

arstechnica.com

betterunix• 13 years ago

This is why smart cards should be used. You should not be able to accidentally distribute a private key like this.

raverbashing• 13 years ago

Yes

Private keys without a passphrase are probably even riskier than passwords

Private keys with a passphrase had better have a hard passphrase or they'll just be bruteforced offline

Locke1689• 13 years ago

Stations that use vulnerable gear should upgrade to version 2.0-2, which is available by sending an e-mail to _suport@digitalalertsystems.com.

Oh for fuck's sake. I hope Ars screwed up that email address. Sometimes I feel like regulatory capture has totally screwed our national defense.

I'm from Maryland. I know a lot of defense/NSA people. Some are fantastic. Others... let's just say not everybody is the best and brightest.

dfc• 13 years ago

"The best and the brightest" is such a strange phrase. Whenever I read it I always think of Halberstam and assume the author is using the phrase pejoratively.

jlgreco• 13 years ago

Yeah, I cannot help but hear that phrase sarcastically, sort of like "good enough for government work."

ColinWright• 13 years ago

    " Congratulations gentleman - you're everything we've
      come to expect from years of Government training."

    -- Zed, in "Men in Black"

http://www.youtube.com/watch?v=cflpNLjhi0s

jes5199• 13 years ago

There's a nice explanation of the context around Halberstam, on wikipedia for those of us who aren't familiar with the story: http://en.wikipedia.org/wiki/The_Best_and_the_Brightest

clarkm• 13 years ago

Yeah, it looks like Ars messed it up: http://digitalalertsystems.com/contact.htm

waster• 13 years ago

National zombie attack alert... it's only a matter of time.

akira2501• 13 years ago

EAS has so many weaknesses, I'd actually qualify this as the least worrisome. The way we deploy any computerized equipment that is a part of our air-chain includes firewalls and only allowing connections to the necessary servers for CAP type alerts.

Every EAS receiver is typically monitoring other stations in the area for EAS relay. We actually have a tuner tuned to another station in the market and if we hear an EAS alert go across the air on their station we simply relay it. Due to the FM capture effect, it's _very_ easy to attack this channel; especially because there's _zero_ authentication on these incoming "relay" messages.

Even worse, some types of messages are setup for "national relay." This system was tested recently to ensure that a message could be relayed like this from one end of the country to the other -- and yes, it can. So, if you construct the right type of message, you can have it broadcast over _every_ station in america.

jevinskie2• 13 years ago

I wrote a SAME FSK encoder in Java. It was very straightforward. If I had a transmitter, I could have strolled by the local TV or radio station and caused the entire state of Indiana to declare a hurricane emergency.

Relayed across radio stations, TV ticker, and your weather radio.

Here is a bit of the specification: https://en.wikipedia.org/wiki/Specific_Area_Message_Encoding...

contingencies• 13 years ago

What's the bet a whole bunch of people with false TV station emails just scored copies of the code?

johnchristopher2• 13 years ago

What code ? It's more likely they just were given a new public key for an updated private key or something along this line.

jlgaddis• 13 years ago

I have some four-letter domains that start with "w", should I try? =)

dave1010uk• 13 years ago

If you were building a system with legacy firmware (so, for examole you couldn't rotate keys in case of a breach), how would you mitigate against situations like this? Can anyone give a brief overview of how to architect a more secure system?

rdl• 13 years ago

When you build a public key into firmware which isn't easily updated, you need to put a lot of effort into securing the corresponding private key. The correct way to do this is to have a separate credential for your actual admin users who then use that to authenticate to an HSM or similar system which controls the actual widely-deployed keys. Humans should never be able to access the important private keys directly, and there should be a logging process which shows those keys have never been exported (and have technical and policy controls against being exported) without proper multi-party control (so, you back them up in k of n shares, and distribute those shares across corporate officers in multiple sites in the event you need to replace the HSM).

Shorter lived keys and more frequent updates, provided you also have a secure way of authenticating the updates (hard) is often preferred.

bdonlan• 13 years ago

You can put the private key on a few HSMs, and have the HSM enforce a security policy (eg - access must be authorized by a quorum of operators). Never allow the private key to leave the HSM, ever again, except when initializing a new HSM (in which case, it had better be encrypted by the new HSM's unique key before leaving the old one).

Then you go fix your legacy firmware.

cnvogel• 13 years ago

The "canonical" way of solving this is of course with a certificate hierarchy. You can configure your target system to allow authentication whenever your certificate is signed by the "golden" key, and by creating the certificates with expiration dates it's easy to restrict the time that a certificate (which maybe got stolen or was made public inadvertendly) can be used for login.

Adding auxiliary data (comparable to X509 certificate usage restrictions only for code-signing or signing for emails) would allow you to have a (central hardened) machine hand out certificates to your "semi trusted" administrators that only allow login from a specific IP-address, to a specific target-system, up to a certain date or even time. Putting this functionality in a script (to acquire the certificate and login to a system) such a wrapper could most likely be used as a drop-in replacement for the normal ssh-client.

If your restriction is to use only the default openssh already deployed to the target machines, one quick solution to hide the critical private key from the developer/admin/service machines would be to place it on a (hopefully somewhat hardened) machine running the ssh-agent, and access the agent by creative use of tunelling. In essence then the hardened machine would act as a kind of "smartcard" for all your admins.

glabifrons• 13 years ago

It's sad that it was abused to broadcast a prank (that might send phobics over the edge) rather than something to enlighten those who don't frequent sites like this one about the current situation with regard to SWIFT, the NSA, and the associated dangers of the situation. Most of the people either aren't aware of it at all, or are focused on Snowden (thanks to CNN, et al) and ignoring or are otherwise oblivious of the huge problem that he exposed. Far too many don't think for themselves and believe that it's actually a good thing, that it won't/can't be abused, and that it's entirely to fight terrorism. These same people believe that terrorism is an enormous threat (bigger than being killed by drunk drivers, smoking, and bathtub drowning). Sadly, I know plenty of people that fit into this category.

Fuxy• 13 years ago

Yay! The zombie apocalypse is upon us. How could they fk up so royally?

johnchristopher2• 13 years ago

FTA: Stations that use vulnerable gear should upgrade to version 2.0-2, which is available by sending an e-mail to suport@digitalalertsystems.com.

As a "broadcast-emitting-messages-company" admin: would I really upgrade a system, which functionalities include complete take-over of my broadcast equipment, that is vulnerable to someone mistaking the private and public ssh keys of his "taking-over-any-equipment" equipment ?

I'd rather un-subscribe from that "service" in the limit of legality until that point of failure is fixed.

magoon• 13 years ago

Your medical records are somehow safe? It's only a matter of time before the govt mandated exchanges go "oops" in a similar way

ceejayoz• 13 years ago

My understanding of the exchanges is they're just a way to buy health insurance. They're not storing your medical records in the exchanges.

lettergram• 13 years ago

Coming from a medical billing service which deals with this, yes they will keep your records as of 2014 I believe.

adolph• 13 years ago

Exchanges may also refer to Health Information Exchanges (HIE).

http://www.healthit.gov/providers-professionals/health-infor...

vertex-four• 13 years ago

And yet somehow, in general, national health services with highly integrated medical data storage systems across Europe don't seem to lose data as often as you'd think.

groby_b• 13 years ago

As opposed to private providers, who are oh-so-safe? For breaches of private providers so far, see http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachno...

A quick sum of all the incidents in there adds up to 22 million health care records lost so far. It's hard to imagine the government could do much worse.

In case you don't feel like importing the CSV file somewhere, https://docs.google.com/spreadsheet/ccc?key=0AkJeZCqH2PsHdDZ...

(Not modified except for column width and a final tally)

US Emergency Alert System private SSH key mistakenly distributed

Related Stories