
US Emergency Alert System private SSH key mistakenly distributed - croikle
http://arstechnica.com/security/2013/07/we-interrupt-this-program-to-warn-the-emergency-alert-system-is-hackable/
======
Locke1689
>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
"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
Yeah, I cannot help but hear that phrase sarcastically, sort of like "good
enough for government work."

~~~
D9u
_Outstanding_

    
    
        Euphemism for "standing around outside - a lot"

~~~
RyanMcGreal
Like the joke about the farmer who won an award for being outstanding in his
field.

------
dave1010uk
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
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.

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

~~~
raverbashing
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

------
magoon
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
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
Coming from a medical billing service which deals with this, yes they will
keep your records as of 2014 I believe.

------
johnchristopher
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.

------
glabifrons
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.

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

~~~
akira2501
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.

~~~
jevinskie
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...](https://en.wikipedia.org/wiki/Specific_Area_Message_Encoding#Header_Format)

~~~
StavrosK
Clearly, there should be laws mandating that everyone who knows Java, has
visited that Wikipedia page, or walks outside radio stations be surveilled at
all times, to ensure people's safety.

~~~
VLM
"be surveilled at all times" We already are, everybody.

Its worse than that, unfortunately. About a decade before SAME started showing
up on public for profit broadcasters, they had it on NOAA weather radio (you
know, 162.4 MHz and several other channels in that area). So this has been
around since the late 80s or so.

Well my bright idea was to latch on to the then popular craze in electronics
magazines of make a project using a (then new) PIC, convince a magazine to run
the article, sell my pre-programmed PICs to people, and retire to a private
island (LOL... but I probably could have made my programmer pay for itself, at
least). So I had a PC/AT class machine with a soundblaster 16 generating SAME
codes using, if I recall, a BASIC program. The plan was a simple zero crossing
detector and what amounts to a software "bit banged" UART and some UI code to
drive a LCD module. Back when the PIC16 family was "new" this ended up not
fitting, or at least my UI would have been ridiculously crude with little
translation and filtering features so I dropped the whole thing. I could fit a
really good UI in there or the decoder but not both and I didn't think a
multi-chip solution fit the "standards" of the time. Now a days this would be
a one chip PIC probably on an arduino shield with real analog input instead of
zero crossing detector and all that, and enough space for a monster UI
probably. The "target market" at the time was ham radio equipped storm chaser
type guys who wanted a SAME radio for "them" rather than for fixed locations.
Very travel and location oriented. Now a days of course they just use a
smartphone and an app like proweatheralert or just the weather.gov webpage. I
don't know if there's a startup lesson buried in here other than its possible
to come up with an idea that greatly exceeds the technological limits of the
day, not just at the super high end like big data, but also at the super low
end.

Anyway the point is you'd have to ban virtually any post 1980's era stuff,
including at least some pre-PC era home computers. A PC XT with an original
soundblaster should be sufficient to encode SAME tones, its not like I was
stressing out my old spare 286 while encoding test tones for my PIC based
decoder.

The general development plan of a SAME encoder is about the same as a morse
code sender. If you can figure out one, you can figure out the other. So you
make a tone generating function. (and for SAME you need two tones, no big
deal). Then you send the proper length of each aka a 1 bit transmitter. Then a
function to send a whole byte at a time (big endian or little endian?) aka a 8
bit/1 byte transmitter. Then a function that eats a string and calls the byte
sender for each byte of the string and optimistically stops when it hits the
end of the variable length string. Then a function that eats some vaguely
"human compatible" API and squirts out a line of SAME which is fed to the
function above. And a zillion subroutines/function calls later, you get an
audio SAME message. Making something that sends morse code is developed about
the same way.

Its noob-compatible. No need for recursion, scalability is irrelevant, etc. As
I recall the ancient PIC16 series didn't do recursion very well at the
assembly language level.

~~~
StavrosK
Well, that was an interesting comment, and I read all of it, even though I
only understood precious few words.

~~~
VLM
It was a detailed technical ramble about how I made a SAME encoder using 80s
era hardware and software because I was poor in the early/mid 90s because I
was trying to "startup" a little hardware project to sell a mobile car SAME
decoder optimized for storm chaser people (and more likely electronics fiends
in general). The whole market segment has pretty much been replaced in the
2010's by smartphones and 3G networks so I'm not exactly worried about giving
away my idea.

Turns out the encoder was really easy to make using 1980s era stuff, but the
tech required to pull off the decoder product greatly exceeded the
technological/economic limitations of the time, so that's why the project
failed. Oh well.

The point was a raid to eliminate fancy Java and GUIs and modern computers
won't stop forbidden SAME encoders from being written, they'd actually have to
raid and confiscate museum pieces.

It would be like trying to forbid DES-56 by getting rid of everything DES-56
capable. That's a lot more than year 2012 quad core pentiums, that includes my
25 year old HP-48 calculator...

Another interesting note is that I'm sure the security theater guys would like
to calm people by claiming it takes millions of dollars and dozens of people
and years of effort and top of the line modern high tech stuff to make a SAME
encoder, but I did it alone as a poor yet smart kid using junkpile stuff
decades ago in a ridiculously short amount of time. The only reason this
doesn't get hacked on a regular basis, is despite the paranoid delusion that
they're all out to get us, they actually are not, because they would have
gotten us a zillion times over already, if "they" actually wanted to, which
they obviously do not desire to do. Some lower forms of humanity profit off
convincing people to be hostile toward each other, nothing new there.

~~~
jevinskie
Thank you very much for your stories! I agree, it is quite easy. A transmitter
for the VHF FM band that EAS uses is fairly simple to construct. I was really,
really surprised at the lack of authentication combined with relaying
_mandated by law_. I'm glad I'm not the only one who was concerned!

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

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

------
Fuxy
Yay! The zombie apocalypse is upon us. How could they f __k up so royally?

