SoylentNews is people
SoylentNews
Starting shortly before midnight Friday, emergency sirens all over the Dallas, Texas started blaring even though there was no emergency:
Rocky Vaz, director of Dallas' Office of Emergency Management, said that all 156 of the city's sirens were activated more than a dozen times.
Officials don't know who was responsible for the hacking, but Vaz said "with a good deal of confidence that this was someone outside our system" and in the Dallas area.
Deactivating the emergency alert system was the only way to stop the sirens:
The system remained shut down Saturday while crews safeguarded it from another hack. The city said the system should be restored Sunday or Monday — in time for thunderstorms that are expected to begin rolling through the area early next week.
[...] Dallas officials said they have begun working with the Federal Emergency Management Agency to add an alert system that would send messages to all cellphones in the area when there is an emergency.
(Score: 4, Insightful) by Runaway1956 on Monday April 10 2017, @01:42AM (25 children)
The authority's focus will, naturally, be on apprehending and punishing the guilty party.
It will never cross their minds that the system is broken by design. If the things are hooked up and accessible from the internet, the design is all wrong.
Cue the apologists pointing out that authorities should be able to access the system at a moment's notice from anywhere in the world. Like - it's not possible to actually have someone on duty somewhere in the city to flip a switch at the appropriate time.
(Score: 1) by tftp on Monday April 10 2017, @02:21AM (2 children)
It's probably not a question of the switch, but a question of the 150+ pairs of wires (dedicated pairs!) that one needs to drag across the whole city to those sirens. That would be quite expensive, point to point! Likely the sirens are connected to the Internet (at the nearest cell tower, for example) via a very simple gateway (SCADA?) that has minimum security. One can also understand why - the device should be as reliable as possible, and you do not want to deal with updating certificates and fixing whitelists of IP addresses of control stations. Probably they have some sort of password authentication that is weak, or have too many ports open that are vulnerable. Does the city government employ rocket scientists to design these boxes?
(Score: 3, Interesting) by Geezer on Monday April 10 2017, @12:37PM
Back in the 1950's/1960's, the civil defense sirens were activated by a dedicated phone line and a simple relay. The ring tone voltage latched one relay, hangup let an old dashpot timer break the latch. Simple and effective, at least till the first warhead lands.
Anyone remember CONELRAD (AM 640 and 1240)? Jeez I miss the cold war.
(Score: 1) by toddestan on Wednesday April 12 2017, @12:38AM
You think so? My guess is that in most municipalities, the sirens date back decades and probably use a fairly simple mechanism to turn them on/off that predates the whole idea of the internet.
I'd say it's reliable, but then again I've never understood why they feel the need to test the system every week.
(Score: 0) by Anonymous Coward on Monday April 10 2017, @02:40AM
Just blame it on the Rrrrrussians.
(Score: 4, Interesting) by hopp on Monday April 10 2017, @02:44AM (19 children)
Not accessible from the internet.
Control is via RF with simple FSK coding which is unauthenticated and vulnerable to a replay attack.
(Score: 3, Insightful) by Runaway1956 on Monday April 10 2017, @02:58AM (1 child)
That's as bad, or worse, than the internet. Holeeeee SHITE!!
(Score: 1) by WillR on Monday April 10 2017, @06:12PM
(Score: 2) by kaszz on Monday April 10 2017, @03:17AM (16 children)
Seems just like the about 90% of smart TVs vulnerable to remote hacking via rogue TV signals [soylentnews.org]. Pro prediction, security by obscurity will be less workable as time goes on.
My guess.. the Emergency Alert System (EAS) has no concept of authentication at the Primary Entry Points (PEP) nor lower down the distribution chain.
Diagnose: Huh? Dohh!
(Score: 2) by SomeGuy on Monday April 10 2017, @03:55AM (13 children)
But it goes both ways - this simple system is exploitable, but a more complex system would be more prone to failure when the shit is hitting the fan.
Seems like it is time to re-analyze the current emergency system tech, but like so many "upgrades" they may choose to pull specs out of their ass and wind up with a system involving TCP/IP, The Cloud, XML, HTML 5, SQL, Blue LEDs, Java mixed with .NET, Object Orientation, and whatever buzzword are in this months management brochures, all to be provided by Rube Goldberg Corp. Right, and can be activated by Donald Trump posting from Twitter.
(Score: 0) by Anonymous Coward on Monday April 10 2017, @04:53AM (1 child)
I agree with SomeGuy. Don't know who he is, or what he is saying, but I agree with him. Redundancy. Reliability. Things almost no software-based system has. When lives are at stake, better to use a stake and lot of fire, because God will not suffer a witch to live!!
(Score: 2) by Runaway1956 on Monday April 10 2017, @06:55AM
Fortunately, we do have redundancy. The EAS is the "foolproof" fallback system for radios and internet. Many people in tornado alley have alerts sent to their computers (phone, whatever) in case of a tornado watch/warning. During tornado season, most people keep a radio turned on. Some people even have dedicated weather warning radios. Pretty much everyone has a telephone, so that Mom can call to warn them of an impending tornado.
We do have redundancy, but there are still some who probably won't get the warning unless that EAS sounds. Whether they got the warning or not, that damned siren howling down the street adds a sense of urgency - or panic.
(Score: 3, Informative) by DannyB on Monday April 10 2017, @04:57PM (9 children)
In ancient times, back in a different millennium, before the web, before AOL even, there were these things called telephone lines. They went to every building. And through a contract, you could get your local telco to provide a "dry pair" from point A to point B. (Dry pair means two wires that are connected from A to B with no telco equipment whatsoever in between.)
Set up a pair of modems on that dry pair.
Now I get it about the mishmash of technologies you mentioned. But micro controllers using simple private key authentication (not certificates) is quite doable. Encrypt the message. That encryption key is encrypted with the private key of the central control and the public key of the remote siren. To avoid replay attacks, include a serial number, or the next word on a one time pad. A contractor could build this with off the shelf hardware and some custom code. There is no complexities of SSL / TLS and certificates and certificate chains. Just two simple encryption algorithms on fixed size message blocks. If the message gets through you know it came from central control because it was encrypted with their private key, and only the remote siren could decrypt it because it was encrypted with their public key. (Rather, the AES-256 key was encrypted.) So anyone listening to the messages to trigger the sirens only has encrypted content and can't replicate a genuine message. Further, replay attacks are prevented.
Emergency siren systems should be tested regularly on some regular schedule like always noon of the first Monday of the month. It should be possible to have positive feedback to the central control that the siren head is rotating and that the siren noisemaker is rotating. Nothing more than an electric eye with a hole punched somewhere to detect rotation, and compute rotational speed.
If you want more reliability, then have a backup to the modems on a dry pair. Also be able to signal a one way message to sirens (no feedback) via the same encrypted command with one time pad over the local FM radio station. Or over a licensed business band frequency or the fire and emergency frequencies.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by kaszz on Monday April 10 2017, @11:40PM (8 children)
My thought too. The big question is why isn't it already implemented?
(Score: 2) by DannyB on Tuesday April 11 2017, @02:49PM (7 children)
Two immediate possibilities come to mind:
1. It would cost money. ("What? We don't need no steenkin' encryption!")
2. Ignorance. ("Encryption? What's that? Why would we need it? Nobody could ever send the specific unencrypted radio signal to set off the sirens.")
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by kaszz on Tuesday April 11 2017, @03:12PM (6 children)
The cost is that of an 8-bit CPU and the developer cost can be distributed across a nation and decades. A no brainer really.
(Score: 2) by DannyB on Tuesday April 11 2017, @04:31PM (5 children)
No brainer for both you and I. But see my two points about cost and ignorance. :-)
What!?!? The cost of an 8-bit CPU! On every siren!
In 2030, if you want to blink an LED, it will take terabytes of code, including an Arduino emulator in interpreted python on Linux in another emulator. It will be the only option on the market for blinking an LED. But hey, it will be in a SOT-23 package, draw nanoamps, and the blinker part will cost five cents.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by kaszz on Tuesday April 11 2017, @06:14PM
Selling water to a idiocracy is a hard matter, I know ;)
There's even a documentary made on the subject from 2006 :p
(Score: 2) by jasassin on Tuesday April 11 2017, @08:23PM (3 children)
I got a breadboard the resistors and chips. Never got the led to blink, but I blew out about 10 of them before I got the resistance right. Janrok said he would help, but I can't find my bag of parts... :(
Anyone here make an led blink? If so props to you!
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 3, Informative) by DannyB on Tuesday April 11 2017, @08:38PM
You can probably google for calculating the resistor value for an LED.
You will need to know:
* The current for the LED
* The voltage across the LED
* The source voltage
In a nutshell, the resistor will have the voltage of "source voltage" minus "voltage across LED". Then Ohms law with the current to get resistor size. Also consider the voltage across resistor and the current through it to know what wattage of resistor to use.
If you need the LED to blink, there are a number of ways.
1. Raspberry Pi
2. Arduino
3. 555
4. LM 3909
(I'm a software guy and don't know about hardware, so don't ask. I don't know which end of a soldering iron to pick up.)
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Informative) by DannyB on Wednesday April 12 2017, @02:30PM
Oh, and I did get an LED to blink.
Then I used a bunch of MAX 7219 chips to get many LEDs to blink. :-)
I (ab)used the SPI pins on a Raspberry Pi to talk to the first MAX 7219 in a chain of 7219's, driving that first 7219 slightly out of spec. (The Pi's logic level one voltage is slightly below the minimum stated logic one voltage of Maxim's data sheet for the chip.) But it works great.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Informative) by DannyB on Thursday April 13 2017, @01:44PM
Here are pictures of what I described with the MAX 7219's. The hardware is three 7219's chained. The first 7219 controls an 8 digit 7-seg plus decimal point display. (eg, 8x8 LEDs). The next two modules on the chain each are simple 8x8 matrix of LEDs.
I wrote software in Java on the Pi which creates a "message queue" for each display. Multiple threads can add messages to the queue for a certain display module. If any queues have outgoing messages ready, then a "train" of commands for the three modules is formed, even if some modules get a NOP command. Then the three messages are clocked out the SPI pins to the three modules.
The first picture here [postimg.cc] shows that the 7-segment display has:
* a millisecond counter
* a rapidly rotating spinner in the leftmost 7-segment digit, in it's upper half (segments A, B, G and F)
And you can see two 8x8 matrix modules, each with a snake that runs around on that display. One of the snakes is faster and longer. The other snake is slower and shorter. Just to make it clear that they are independent processes. So that's four processes total:
1. millisecond counter
2. spinner on 7-seg left digit
3. snake 1
4. snake 2
Each of these processes adds messages to outgoing queues of commands for a particular display module. Then my home grown library forms the message trains to clock out at about 8 MHz.
The entire animation happens very fast.
Next is this [postimg.cc] picture where I have a "virtual matrix" abstraction that can create an apparent 8x16 matrix out of two 8x8 matricies. That virtual 8x16 display has a single longer snake that can run around the entire 8x16 area.
I have videos of this and it is amazingly fast. But they are not posted anywhere.
I think that will qualify as getting the LED to blink.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by kaszz on Monday April 10 2017, @11:44PM
It can be made complex enough to solve the problem but not more.
(Score: 2, Interesting) by anubi on Monday April 10 2017, @07:19AM (1 child)
My take is that the anonymity of sneaking off and pulling it has similar thrill to us kids once per blue moon pulling the "in case of fire" switch in the school.
Yeh, it got pulled a couple of times for fun. Great fire drill, as it wasn't announced and no-one was prepared for it.
But, it worked, and everyone found out what it did and what it sounded like.
It did not happen too often, and the perps ( or anyone else for that matter ) did not want to repeat the performance, as they knew those things were now being watched.
Yeh, maybe change the codes.
I am afraid if I was putting something like that in, I would use simple codes for the same reason: robustness. Get it too complicated and it might not work when I needed it to.
An FSK modem tied onto the 67KHz SCA subcarrier of the local FM radio station sounds like a winner to me. But I might use nonstandard frequencies.
( I had seen that done before in the early days... I came across stock market information on a SCA subcarrier - using nonstandard FSK frequencies at a nonstandard baud rate. Found the frequencies by lissajous patterns on an oscilloscope. Built a '565 PLL decoder, then deduced the baud rate by looking at the output of that. The PLL output was raw ascii. All I had to do was square it up and send it into the UART. Then play around with the baud rate and center between the two endpoints where the framing errors hit the roof. )
I am kinda partial to the SCA approach as its kinda hard to outyell the main carrier of the radio station and set ALL the alarms off. Not only that, the range of the alerts are the range of the radio station itself. And pick a radio station you are prepared to support as part of the civil defense system.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 1) by anubi on Wednesday April 12 2017, @12:12PM
Late post. For posterity.
The more I think about this, I would use FSK coded manchester on the SCA subcarrier. Easy to decode. Embedded clock. 50% duty cycle. Makes the analog design much more stable.
Send continuous codes down: Sync. Address. Data. Confirmation .
That way, I can put lots of stuff addressed onto one carrier. Slow speed, but just how fast do I need to turn stuff like alarm sirens on and off anyhow?
Other things, like signage boards, could also get info from this.
Each device would have its own address it looks for. Probably 16 bits of it. When it sees it, it looks for its data. Probably 64 bits of it. Then it looks for its confirmation. Probably 128 bits of it. The carrier would fully loaded with live and dummy addresses. So someone would have to be right over the target and stay there to engage it, because the radio station stream is constantly telling it to turn off. And they have a big transmitter. And FM receivers, by their very design, lock onto the strongest carrier.
Now, this is not prank-proof. If one does succeed in pranking the system, at least they have to be close enough to overcome the radio station carrier.
If a kid does succeed in pranking it... hmmm. I might offer the kid a job working for the city - cuz he sure demonstrated an understanding of all sorts of electronics to do it.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by DannyB on Monday April 10 2017, @04:34PM
Several problems
Their focus will be to find a scapegoat. Probably a low level employee. It will get headlines. The Mayor can claim he solved the problem and will get a photo op shaking the president's tiny hands.
Design problems can be fixed. First, do not run telnet on the standard port. Run it on a non standard port so nobody will ever find it. Secondly, it should require a password between four and eight characters, uppercase only.
Here lies the biggest problem of all. Worldwide access is clearly necessary by your argument alone. Here is how that will go. City hires someone to be on duty to flip a switch. That person is unreasonable and expects that they should make enough money to eat and live in a cardboard box. So their job is outsourced to Elbonia. Thus the switch to be flipped is remote and internet access is required.
End result:
After punishing a scapegoat, an expensive contractor will be selected to create the solution described above with a remote switch in Elbonia, internet access to the sirens using the improved security measures described above.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.