Smart cities are not quite as bright as their administrators might think, as a just-released study has found many critical flaws in a variety of devices commonly used by municipalities. The main takeaway: vendors did not take even basic security steps to protect these critical products.
The study, released by IBM’s X-Force Red Team today at Black Hat 2018, looked at four common devices and found 17 vulnerabilities, nine of which were considered critical in nature, said Daniel Crowley, research baron at IBM X-Force Red. These included ICS components, devices used in conjunction with connected cars, and other products that control various types of sensors.
The genesis of the project was the human error that caused Hawaiian residents to believe their islands were under missile attack in January 2018. With that in mind, IBM decided to look at systems to see if its researchers could find flaws that would allow them to launch “super villain” level attacks.
“We looked to discover the tech being used and picked a few devices and tried to hack them,” said Crowley, referring to how the study began. “We found the vulnerabilities pretty quick and that was disturbing.”
IBM looked at Meshlium by Libelium, i.LON 100/i.LON SmartServer and i.LON 600 by Echelon, and V2I (Vehicle-to-Infrastructure) Hub v2.5.1 and the V2I Hub v3.0, both by Battelle.
Security flaws included a device that was found exposed on the internet, another whose open-source software came with an easy-to-find hard-coded username and password that were just small variations on the company name, and another that contained shell flaws, potentially giving an attacker root privileges.
To show a physical manifestation of one potential attack, Crowley’s team built a demonstration based on one of the devices it studied, a Meshlium IoT gateway. These are normally used to monitor devices like radiation sensors and then report any problems. Since exposing a Black Hat audience to radiation would not be a good idea, Crowley’s team connected the Meshlium product to a water sensor and simulated it controlling a dam sluiceway that controls a river’s water level.
Due to the shell flaws in the Meshlium product, Crowley was able to hack the device and input a false reading, resulting in too much water getting released downstream and flooding a fake road.
Crowley said the good news is that the vendors, once told of the flaws, were in all cases quick to issue patches. But the study showed it is obvious the manufacturers are not putting enough thought and emphasis on security, assigning it a lower priority.
“They are not baking in security. In the case of all the devices we looked at, basic security processes needed to be in place,” Crowley said, adding that even running a basic static code analysis would have taken care of the majority of the vulnerabilities.
One reason he gave for this situation is companies’ desire to be first to market with their products, which makes them willing to shortchange the security aspect of the design.
IBM also did not let the smart cities who use their products off the hook. Crowley said the people in charge of purchasing systems must do their own due diligence on the products and then make sure the default login credentials are changed and strengthened.
Here is a list of all the issues uncovered by the IBM team:
Meshlium by Libelium – Wireless sensor networks
(4) CRITICAL — Pre-Authentication Shell Injection Flaw in Meshlium (four distinct instances)
i.LON 100/i.LON SmartServer and i.LON 600 by Echelon
CRITICAL — i.LON 100 default configuration allows authentication bypass – CVE-2018-10627
CRITICAL — i.LON 100 and i.LON 600 authentication bypass flaw – CVE-2018-8859
HIGH — i.LON 100 and i.LON 600 default credentials
MEDIUM — i.LON 100 and i.LON 600 unencrypted communications – CVE-2018-8855
LOW — i.LON 100 and i.LON 600 plaintext passwords – CVE-2018-8851
V2I (Vehicle-to-Infrastructure) Hub v2.5.1 by Battelle
CRITICAL — Hard-Coded Administrative Account – CVE-2018-1000625
HIGH — Sensitive Functionality Available Without Authentication – CVE-2018-1000624
HIGH — SQL Injection – CVE-2018-1000630
HIGH — Default API Key – CVE-2018-1000626
HIGH — API Key File Web Accessible – CVE-2018-1000627
HIGH — API Auth Bypass – CVE-2018-1000628
MEDIUM — Reflected XSS – CVE-2018-1000629
V2I Hub v3.0 by Battelle
CRITICAL — SQL Injection – CVE-2018-1000631