[EAS] EAS Zombie Attack

Wed Feb 13 22:08:39 CST 2013

John,
I appreciate the feedback, but respectfully suggest that you aren't 
living in the world many of us are living in.  We have a small universe 
of EAS decoder boxes to chose from and while you can make comments like 
"you have described a worthless device that can only be taken outside 
and bashed into pieces. ", that isn't very helpful to us. We don't have 
the budget to "bash into pieces" every poorly designed product that for 
one reason or another we got stuck with.  In my experience, broadcast 
equipment that complies with "best security practices" known to the IT 
community for decades is all too rare.  Drives me nuts, but that is what 
we have.

As for "most operating systems..."... again, not particularly relevant 
in our universe.  These boxes weren't built on Windows or OS X.  They 
were built on Linux or BSD (at least those I've worked with).  And the 
typical engineer doesn't have that much familiarity with those operating 
systems.  And it may not matter if they do if the vendor doesn't allow 
them access to the OS, but only to the web interface.

To give you an example of how silly it can get... one manufacturer of an 
early CAP 'converter boxes' actually sold a box that wouldn't work 
without accurate time, but provided NO means for the end user to set the 
time!  The box supported NTP, but the NTP functionality only worked if 
the box was already within 16 minutes of the correct time!  Of course, 
it ran on BSD and IF the end user had been allowed access to the OS, the 
date/time could have been set.  But the manufacturer considers that 
proprietary information!  Words can not adequately express what I think 
of that product (now off the market).

And you are seriously telling me it is unrealistic to expect a user to 
tolerate a one hour lockout if they miss the password five times in a 
row... but that they WILL tolerate a 100 character password?  Not in my 
universe.  To my way of thinking, any form of lockout (even 5 minutes 
after failing TEN attempts in a row) will make dictionary attacks 
essentially worthless, even with more modest password lengths like 10 or 
12 characters.  And I didn't suggest sending emails about EVERY failed 
login... only enough failed logins to result in a lockout.  Just how 
many emails do you think that is going to result in?  Our banks and 
corporate computers lock us out... why should we expect less from our 
EAS box?

And note that I didn't suggest "requiring" complex passwords... just 
"supporting them".  A user shouldn't have to worry about the hassle of 
dealing with a system that isn't flexible about what it will tolerate 
for choice of characters.  If the user wants to use J&*LFeje as their 
password, fine.  Personally, I'm far more interested in encouraging pass 
phrases than complex 8 character passwords.  Passwords you can remember 
or more secure than ones you can't that are on the sticky note on the 
side of your monitor!  If my math is correct, a complex 8 character 
password gets you somewhere in the neighborhood of 7 x 10E14 
combinations. A lower case alpha only password that is 10 characters 
long gets you around 1.4 x10E14 and an 11 character gets you to 3.7 x 
10E15.

I'll agree with you on the point about how often you change passwords, 
but that is a point of some controversy and obviously a significant part 
of the IT industry disagrees with us.

I don't have a clue what prompted your comments about IP addresses.  As 
for port numbers... again you are in a different universe than most of 
us here.  Our vendor didn't negotiate anything about port numbers with 
our IT department.  The port numbers used are industry standard 
assignments for HTTP (80), HTTPS (443), etc, etc.  It is the fact that 
they ARE industry standard that makes it easier for hackers.  And harder 
to accommodate the port forwarding limitations of the typical routers 
used by small broadcast stations (think Netgear or Linksys).

Dave

On 2/13/2013 7:25 PM, John Willkie wrote:
> I don't make EAS systems, but I do make remotely accessed PSIP generators.  While the above list is well-intentioned, it mostly amounts to "security theater" and not security, or what all vendors should already be doing.  Of course, inside the machine, passwords need to be kept not only "hashed" but "salted" so that "rainbow tables" can't be used to easily and quickly reverse-engineer passwords from hashes.
>   
> All password systems should start with a default password.  However, most operating systems (even Windoze) permit an administrator to set a password to "must change password at first login."  If this isn't a security feature, the vendor is being foolish and the customer will pay the bill.
>   
> As for password complexity, please, this is a joke from the 1980s and more security theater.  Nor is there any reason to EVER routinely change passwords.  Change passwords when someone leaves.  But, use passwords that are at least 100 characters long.  Speaking of complexity, imagine how many combinations of values a script kiddie needs to go through to try 52^99 combinations?
>   
> As for "lock out" not in this life buddy, you are telling vendors to make it difficult or impossible to log on to a system when you've forgotten the password.  How about sending an email message on each failed login attempt?  How quickly would you change the settings if you got such emails?
>   
> IP numbers can't easily be changed within a device; this is a function of the router/switch and DHCP.  Putting the ability within a device is a non-starter.  As for being able to change port numbers, this is a can of worms, since the vendor most likely previously worked out with the corporate IT department what ports are permitted.  This is a router/switch/firewall issue and not a device issue.  Permitting users to willy-nilly change port numbers is no substitute for having a good firewall.
>   
> As for "providing any means to disable protocols not in use." If you have a system that by default enables protocols to communicate with the Internet (or even an Intranet) or exposes ports to either by default, you have described a worthless device that can only be taken outside and bashed into pieces.  If a system runs under a computer operating system, the build should only contain the services and features necessary to run the vendor's applications through their entire life-cycle and no other.  No user should be exposed to any option that could compromise secirity; that's just asking for the ability to create a customer-service nightmare.
>   
> John Willkie
> EtherGuide Systems
>
> __________________________________________________________
> 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
> ___________________________________________________________
>