IoT security. A retrospective

How an innocuous research project into low-cost, low-functionality smart kids tech led us to remote compromise of millions of different, high-cost, high-functionality devices across hundreds of vendors, vehicles and homes.

With pressure to get smart products to market in ever shorter time, vendors are turning to IoT platforms, turnkey solutions and white-labelling of products and modules. Investors are looking for a minimum viable product – something that just works – anything on top of that is extra cost and delays time to market. IoT is about being first to market; all other concerns are secondary.

But, with the introduction of these platforms come associated systemic security flaws. Break once, run everywhere: Vulnerabilities in code you have never even seen can impact your system. Another mobile app using the same backend can now access your customer data. A legacy API used by a totally unrelated 3^rd party could allow access to your devices. An unrelated company claiming they are ‘unhackable’ could draw attention to the very same platform your smart device uses.

The consequences are significant:

<Could be used in TL;DR>

• Compromise of LoJack / Tracker and numerous other ‘certified’ vehicle tracking devices, leading to the ability to remotely inject CAN messages to millions of vehicles over various APIs
• To remotely access vehicle telematics platform messages, tracking, unlocking, stealing and killing the engines of millions of vehicles.
• To trigger millions of tracking devices (kids trackers, vehicle trackers, asset trackers and even covert spouse trackers) to make premium rate calls, generating a potential $1Bn fraud in a matter of minutes
• Remote access to smart medtech exposed through a smart hot tub (seriously!)
• A smart door lock that led to compromise of over a million high-end houses alarms, CCTV, a/v and lighting systems
• These are all real attacks. We will demonstrate these live against our own devices, or pre-recorded in the case of vehicle compromise

Review the perceived state of IoT security today, based on 5 years of research in the field.  It’s mostly a train wreck, but with beacons of excellence out there. We’ll share some common themes we noticed around organisations that dealt with disclosure well.

Regulatory progress & guidance frameworks. We’ve given assistance to NIST and ENISA towards improving IoT security, what can we learn from regulators and how can we work successfully with them?

Recap of our smart aftermarket car alarm research. We will expand on this and show new research in to the security of aftermarket vehicle immobilisers and trackers. Numerous high-end vehicle trackers including LoJack/Tracker trackers were vulnerable to the same attack. BMW also approve a 3rd party tracking device from ‘Trackstar’, fitted by BMW technicians in BMW dealerships. Trackstar is also vulnerable to compromise, exposing the security of the vehicle.

The above trackers are accredited to the highest security standard by the UK’s ‘Thatcham’ vehicle security research centre, bringing in to question the quality of said accreditations and the ability of the aftermarket auto industry to deliver improved vehicle security.

We thought this was the end of our project, but then started looking at the connection of car alarms and vehicle trackers to the CAN. We discovered multiple examples where we could remotely, through a vulnerable API, inject traffic directly on to the vehicle CAN.

Investigate the root cause of car alarm & tracker vulnerabilities: introduce concept of an IoT back end platform provider such as CalAmp, the cause of several of the tracker security issues. Explain why the ‘outsourced platform’ approach is supposed to solve IoT security, not make it worse!

We’ve showed compromise of other totally unrelated devices managed on the same platform

Examples of security failings by many of the large platform providers:

• a hot tub leading to Digi, leading us to medtech compromise
• car alarm -> Calamp -> Lojack
• thermostat -> Tuya -> kids tracker watches
• telematics -> Teltonika -> GPS vehicle trackers
• smart toy -> ThroughTek -> smart home

Examples of IoT device control aggregators leading to compromise of ~1M otherwise-secure smart homes

What goes wrong when IoT is being developed? It’s too easy to call ‘lazy app developers’ – the problems are much more complex and nuanced than this. We’ll look at a detailed example of the Gator kids smart watch from Caref Watch Co, showing how the security process went wrong, the complex ODM/importer/distributor/brand owner relationship and how various parties failed to act at different times

Discuss solutions: how OWASP ASVS & a SDLC can be built in to outsourced development contracts, giving legal recourse to the smart product brand owner

Equip attendees and viewers with the tools to assess whether their platform providers are secure. How does one know, what does one ask, how can we work smart with procurement?

Discussion of product and third-party liability. A claim involving compromise of any one platform provider could easily exceed insurance cover & could pose a systemic threat to the insurance market

Carmageddon: what’s the worst that could happen? Are the potential attacks real, or just unhelpful speculation? A pragmatic final view to close

Lessons

Insight into how IoT products are designed and the pressures developers are under

The advantages and disadvantages of IoT platforms

How to minimise risk to your business when implementing IoT platforms

Why IoT security is nearly always not about the device

Why do some IoT vendors still do things so badly?

<Needs more>

Our breadth of experience across so many different systems allows us a really deep insight into IoT security.

Solving these issues is not just a matter for researchers and regulators; we need the market to be alert to weak IoT platform security, asking probing questions to influence and direct suppliers security behaviour.