Fatal assumptions in any supposedly-secure design:
o) You can trust packets on the Internet
o) You can trust source IP addresses
o) All packets from a given session are from the same peer
o) Nobody can decode this!
o) Certified means it’s secure
o) If the protocol is undocumented, it can’t be deciphered
o) Encryption makes any connection a secure connection
o) Letting the central HQ disable encryption won’t cause insecure deployments o) Alarm systems engineers can design secure Internet protocols
…and it turns out certain alarm systems manufacturers are really big fans of these assumptions. Dutch researcher Wilco Baan Hofman goes through a number of them, pointing out how burglars can wreak all kinds of havoc.
The “Fire Sale” in the presentation is a reference to Die Hard 4, “computer hacker Casper evacuated all personal in several government buildings, including the FBI HQ, with fake anthrax alarms. … the cyber-terrorists are launching what hackers call a Fire Sale, a three-step systematic attack that shuts down transportation, financial and utility systems.” (http://diehard.wikia.com/wiki/Live_Free_or_Die_Hard)
Worst (or best) of all, these attacks have nothing to do with the sensors. That means an attacker can interfere with the alarms without interacting with the rest of the security infrastructure.
“The next talk was “Orchestrating a Fire Sale: Brining Dutch Alarm Systems to Their Knees” by Wilco Baan Hofman. Like in most countries, buildings in Holland are protected by alarm systems. Wilco performed some researches on the protocols used to exchange events between the alarm systems and their central management. His primary goal was to have more visibility: after all why alarms communicate only with their management centres? He found interesting vulnerabilities. They are many protocols used by alarm systems. Some are analog (ANSI SIA, ANSI X/SIA, Ademco ContactID) while others are “over IP” (SIA-HS, Vebon SecIP, Chiron etc). Some are proprietary and others are standards based on countries. But all of manufacturers have the same problem: They make fatal assumptions and mistakes are made! Here are the assumptions:
You cannot trust packets on the Internet,
Same for source IP addresses.
All packets from a session are from the same peer
Nobody can decode this!
If my product is certified, it is secure
If nobody knows the protocol, nobody can decipher the message If my peer speaks the same protocol, it must be a valid peer Encryption is enough to make a connection secure
Giving an alarm receiving centre the option to disable encryption will not lead to insecure deployments Alarm system electronics engineers can design secure Internet protocols
Assumptions from alarm systems manufacturers
Before explaining the found vulnerabilities, Wilco gave some basics information about alarm systems. They are ATE (alarm devices), ARC (central management), PROM (buildings), etc. The first protocol reviewed by Wilco was SIA-HS. This is a protocol developed by Alphatronics and marked in the documentation as “impossible” to decipher. Really? A pattern with multiple repeating characters cannot be a valid crypto. Indeed, the data was just XOR’d… Big fail! Once the protocol dissected, Wilco wrote his own implementation of SIA-HS with nice features like pluggable handlers: logging to database, JSBONBOT IRC Event notification… (the free implementation is available here). Being able to decode the protocol used between the components of an alarm system may have huge security implications:
Send false alarms (while remaining anonymous!)
DoS the alarm centre ops
DoS the Police response
Do you remember Die Hard 4? We are very close to this scenario! The next protocol dissected by Wilco was Vebon SecIP. It uses RSA 1024 bits and AES communication. Looks secure. No! There is a lack of identify verification, insecure cryptographic padding and no forward secrecy. What about the responses from the affected manufacturers? Between Augustus 2013 and January 2013 , Wilco received no feedback at all. Then Alphatronics asked to remove the publication already made. Vebon & ENAI responded better and Chiron offered a properly configured ARC to aid testing. But it will not solve the problem: ALL the already implemented systems are vulnerable (all the firmwares must be upgraded) and customers using insecure protocols must be isolated to mitigate attacks. Like the previous talk, this prove that security must be properly implemented!”