Why IoT Security Will Be a Nightmare for Everyone

Posted by George Yunaev on 2015-05-08 14:00:00

The Internet of Things (IoT) seems to be about innovation, about developing new cool, exciting “things” that nobody has done before – developing them fast, bringing them to the market with high speed. And people developing these things do understand the importance of security. Even for a small thing such as a wireless-controlled lamp, a user wouldn't want any neighbor kid to control it. However, as the 2014 Blackhat/Defcon showed[1], a number of those devices have rather inadequate security and could be easily broken into. So why exactly does this happen?

internet_of_things_resize

This was also addressed at Defcon by several speakers, usually following a presentation about ‘hacking yet another “thing”’. The overall consensus was that the security issues seem to be typical for companies with the following characteristics:

  • Type of company: a product is developed by a company that’s in the startup/incubator phase, and focuses on rapid development, innovation and new cool features. At this point, they have little time to consider security implications. “If we spend too much time and lose the market, it won't matter how secure this thing is.”
  • Staffing: most of those “things” are developed by small teams or companies with very limited staff. Such teams are not likely to include a dedicated security engineer, and they're more likely to rely on fallacious “security practices” such as “security through obscurity”.
  • Budget: making a product secure requires a certain amount of money and time. Sadly, for a product that is late on schedule and already over the budget, security seems to be one of the first things to be cut off.
  • Ignorance: companies that have no prior experience and are just entering this market may treat security as a nuisance, and assume that they don't have to treat security seriously because their product will not be a target for hackers. “We're just building a wireless-controlled lamp, not a fusion reactor. No hacker will waste their effort to learn how to turn the lamp blue”. 

These approaches resulted in situations in which a number of “things” already developed were found later on to have critical security issues, in most cases no security at all.In many cases, the security issues are very basic indeed. For example, the OWASP Internet of Things Top Ten Project[2] list of top security issues found in 2014 included items such as weak passwords, or cleartext communication protocol which allowed for credentials to be sniffed easily.

Another problem is that once the security issue is discovered and the vulnerability is made public, the company often has no means to react to it. For cheaper devices, the vulnerability is not even likely to be patched - a “connected” light bulb is unlikely to have a remote firmware update mechanism; if it has security issues, it is unlikely that the update mechanism is secure either. And even notifying consumers about the vulnerability is a problem, as people who purchase a $30 connected light bulb are not likely to register it with the manufacturer. This means the vulnerable device will likely stay there for a while, and its vulnerability will not be fixed.Even worse, there are no security solutions for the security-conscious user to implement. For example, invaluable security advice such as “password-protecting your wireless network, and changing the WiFi router default usernames and passwords[3]” – is hardly related to a “connected home”, and will not help protect against any vulnerabilities found in the devices themselves.

Case in point: the BMW Security Flaw

Recently, several “connected” BMW cars were found vulnerable.The vulnerability allowed the researchers to send remote unlock commands to the car by imitating the BMW servers. In this case, not one company characteristic matches the typical Defcon profile described above:

  • Type of company: BMW is not some startup/incubator company. It is a well-established company which has been known to produce high quality products with high ratings, including safety ones.
  • Staffing and budgets: BMW certainly has no issues with hiring and retaining qualified staff, including software security specialists.
  • Ignorance: BMW products are expensive high-end cars, not $30 lightbulbs or even $200 home thermostats. They understand that a car breach would be considered security-sensitive by virtually anyone, and would become major news, attracting lots of attention, including attention from government agencies.

Nevertheless, they allowed for a major vulnerability in cars, similar to vulnerabilities discovered in $30 light bulbs.And there is more. The vulnerability was discovered during the privacy research, triggered by the German Automobile Club's interest in finding out what information the car sends back to the manufacturer[4]. This was achieved by a single skilled and experienced person, with moderate effort and accessible equipment; it wasn't a Stuxnet-like multi-government effort. The result of his lookout was six vulnerabilities found, three critical – and this guy was NOT even looking for vulnerabilities! He did not do any penetration testing, and he did not look at what other commands this unit accepts. One cannot help but wonder what would the result of real vulnerability assessment be?

Next, the research also revealed that BMW indeed used encryption in the module. Both encryption and authentication are used in the code which receives an SMS to power on and boot up the control module[5]. But it was not used in the piece of code which processed the configuration update or handled the door unlocks. Which means, there was only limited, if any, code review and security testing as even the basic testing would find out that the data is being sent unencrypted, and is not authenticated by any means.

And finally, the mitigation mechanism also raises questions – BMW delivers the firmware update to the cars, but will those updates be properly authenticated? Or will they go through the same unencrypted and unauthenticated connection? Well, they use SSL now. Hopefully they did not forget to disable SSLv2/v3 support...

Lessons learned 

The Internet of Things is today's ‘Wild West’ – every manufacturer implements security as they wish. But can we rely on them doing it right?And what would we, ordinary users, do if we learned about their security issues? You can uninstall or patch a vulnerable software on a PC. You can also install the anti-virus product; despite what some people may tell you[6], modern security products such as Bitdefender contain much more than a “signature-based antivirus” and can protect against a wide range of threats. 

 

 

Subscrine to OEM Hub


[1]“Just last month multiple presentations at the Black Hat and Defcon security conferences highlighted weaknesses in various IoT devices.” http://venturebeat.com/2014/08/23/the-internet-of-things-will-be-vulnerable-for-years-and-no-one-is-incentivized-to-fix-it/

[2] https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project#tab=OWASP_Internet_of_Things_Top_10_for_2014

[3] See https://community.norton.com/en/blogs/norton-protection-blog/connected-home-just-how-safe-convenience 

[4]“Cars with built-in modems are sending data to their manufacturers – German motorist's club ADAC wanted to know what exactly gets sent” http://www.heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive-2540957.html

[5]Even this code is not implemented securely, because it uses a single encryption key for all cars as well as no challenge-response mechanism, allowing the replay attack to be used at all cars without even knowing the key.

[6]“traditional, signature-based antivirus cannot cope with modern threats” or something like that

George Yunaev

George Yunaev is a Senior Software Engineer at Bitdefender. He joined the company's OEM Technology Licensing Unit in 2008, after working at Kaspersky Lab for seven years. Aside from developing SDKs for various OEM solutions, George is also providing partners and prospects with useful insights into emerging threats and potential pitfalls of technology licensing. His extensive software engineering experience of 19 years also covers reverse-engineering and malware analysis. He is based in Silicon Valley, California, and enjoys traveling and active sports such as skydiving and wakeboarding.

Topics: Technology, Internet of Things