[EAS] ALERT: EAS Device passwords

[Martin Gibbs]

I think Rich is on to something.  A modern version of the old 
"authenticator" envelopes would be an encryption key fob:

http://en.wikipedia.org/wiki/Security_token

Way back, I participated in one of the FCC auctions and they sent a fob 
to every bidder.  It may be a bit "out of date" to use "snail mail" 
these days, but since the security key itself circumvents the internet 
completely,  I believe that it could maximize security.

Software updates in our EAS boxes to complement this, and our whole 
system would be a lot more secure, even with default passwords.  
Although I have updated my passwords, I work with a lot of stations 
where the very act of updating a Sage is technically way over their 
head, since you have to use ENDECSetD instead of the web interface just 
to change a password.

Martin Gibbs
KOLU-FM
Pasco, WA

On 2/12/2013 5:24 PM, Rich Parker wrote:
> Voice of reason - thanks for that Alex.
>
> It amazes me that we don't use keys - and that 'box to box' communications are not regulated by shared keys (i.e. I know who I monitor) - part of the 'traffic' of any alert should be some kind of shared key, set in advance. And they can be rotated - just like the 'pink envelopes'.
>
> I did the 'good boy-scout' thing and made sure the user and admin passwords were 'not factory' - but the reality is that even if we took the 'advice' sent around tonight, and changed passwords, and even did the 'extreme' measure of disconnecting from the 'net', the vulnerability from having a 'hacked' upstream box that you monitor triggering an alert that gets relayed can't be 'stopped' by any of those methods.
>
> I am assuming here that the 'jury is still out' on whether or not this was a 'modified' RWT, or something else.  I am inclined to think it was 'something else' based on the fact that there were reports of 'stations in Utah' (and other places) getting the bogus alert - and although it was anecdotal, someone reported that they 'were able to kill the alert' before it went out. That doesn't sound like the behavior of a received RWT (which 'should' be log only, right?).
>
> And as for 'inserting' NV audio into an RWT - those theoretically don't change once they are set-up, so it shouldn't be terribly difficult to decide on 'what an RWT is', and whether or not you use NV audio with it. Then its just a simple matter of a combination of a checksum and a key to allow changes to the NV audio.
>
> And it wouldn't require re-inventing the wheel - the FCC CDBS website has a currently 'legitimate' certificate - so, for instance, that site could be used to distribute keys and or pass-phrase info on a rotating basis - if that's the best plan going forward.
>
> I'm sure this isn't the 'end of this'.....
>
> -rp
>
> ----- Original Message -----
> From: "Alex Hartman" <goober at goobe.net>
>
> Using a shared-key system versus a user/pass system would be much more
> secure inherently. It's harder to get your hands on the keys than it
> would be to sniff a password or even a brute-force system.
>
> And "PC Based" means nothing. I'm willing to bet that all the current
> EAS systems with a network jack on them are running a BSD or Linux
> variant, be it x86 or ARM based. I've done several MitM attacks on my
> Sage box since installing it just to prove a point. It really doesn't
> take much to get into it if one tries.
>
> --
> Alex Hartman
>   
>
> __________________________________________________________
> The EAS Forum Discussion List is hosted by the BWWG (Broadcast Warning Working Group). http://eas.radiolists.net
> Please invite your friends to join our Forum! The sign up is at: http://lists.radiolists.net/mailman/listinfo/eas
> ___________________________________________________________
>