Fighting the Rogue Toaster Army: Why Secure Coding in Embedded Systems is Our Defensive Edge

There are plenty of pop culture references to rogue AI and
robots, and appliances turning on their human masters. It is the
stuff of science fiction, fun, and fantasy, but with IoT and
connected devices becoming more prevalent in our homes, we need
more discussion around cybersecurity and safety.

Software is all around us, and it’s very easy to forget just how
much we’re relying on lines of code to do all those clever things
that provide us so much innovation and convenience.

Much like web-based software, APIs, and mobile devices,
vulnerable code in embedded systems can be exploited if it is
uncovered by an attacker.

While it’s unlikely that an army of toasters is coming to
enslave the human race (although, the Tesla bot^[1]
is a bit concerning) as the result of a cyberattack, malicious
cyber events are still possible. Some of our cars, planes, and
medical devices also rely on intricate embedded systems code to
perform key tasks, and the prospect of these objects being
compromised is potentially life-threatening.

Much like every other type of software out there, developers are
among the first to get their hands on the code, right at the
beginning of the creation phase. And much like every other type of
software, this can be the breeding ground for insidious, common
vulnerabilities that could go undetected before the product goes
live.

Developers are not security experts, nor should any company
expect them to play that role, but they can be equipped with a far
stronger arsenal to tackle the kind of threats that are relevant to
them. Embedded systems – typically written in C and C++ – will be
in more frequent use as our tech needs continue to grow and change,
and specialized security training for the developers on the tools
in this environment is an essential defensive strategy against
cyberattacks.

Exploding air fryers, wayward vehicles… are we in real
danger?

While there are some standards and regulations around
secure development best practices to keep us safe, we need to make
far more precise, meaningful strides towards all types of software
security. It might seem far-fetched to think of a problem that can
be caused by someone hacking into an air fryer, but it has happened^[2]
in the form of a remote code execution attack (allowing the threat
actor to raise the temperature to dangerous levels), as has
vulnerabilities leading to vehicle takeovers.

Vehicles are especially complex, with multiple embedded systems
onboard, each taking care of micro functions; everything from
automatic wipers, to engine and braking capabilities. Intertwined
with an ever-increasing stack of communication technologies like
WI-Fi, Bluetooth, and GPS, the connected vehicle represents a
complex digital infrastructure that is exposed to multiple attack
vectors. And with 76.3 million connected vehicles expected to
hit roads globally by 2023^[3], that represents a
monolith of defensive foundations to lay for true safety.

MISRA^[4] is a key organization
that is in the good fight against embedded systems threats, having
developed guidelines to facilitate code safety, security,
portability and reliability in the context of embedded systems.
These guidelines are a north star in the standards that every
company must strive for in their embedded systems projects.

However, to create and execute code that adheres to this gold
standard takes embedded systems engineers who are confident – not
to mention security-aware – on the tools.

Why is embedded systems security upskilling so specific?

The C and C++ programming languages are geriatric by today’s
standards, yet remain widely used. They form the functioning core
of the embedded systems codebase, and Embedded C/C++ enjoys a
shiny, modern life as part of the connected device world.

Despite these languages having rather ancient roots – and
displaying similar vulnerability behaviors in terms of common
problems like injection flaws and buffer overflow – for developers
to truly have success at mitigating security bugs in embedded
systems, they must get hands-on with code that mimics the
environments they work in. Generic C training in general security
practices simply won’t be as potent and memorable as if extra time
and care is spent working in an Embedded C context.

With anywhere from a dozen to over one hundred embedded systems
in a modern vehicle, it’s imperative that developers are given
precision training on what to look for, and how to fix it, right in
the IDE.

Protecting embedded systems from the start is everyone’s
responsibility

The status quo in many organizations is that speed of
development trumps security, at least when it comes to developer
responsibility. They’re rarely assessed on their ability to produce
secure code, but rapid development of awesome features is the
marker of success. The demand for software is only going to
increase, but this is a culture that has set us up for a losing
battle against vulnerabilities, and the subsequent cyberattacks
they allow.

If developers are not trained, that’s not their fault, and it’s
a hole that someone in the AppSec team needs to help fill by
recommending the right accessible (not to mention assessable)
programs of upskilling for their entire development community.
Right at the beginning of a software development project, security
needs to be a top consideration, with everyone – especially
developers – given what they need to play their part.

Getting hands-on with embedded systems security problems

Buffer overflow, injection flaws, and business logic bugs are
all common pitfalls in embedded systems development. When buried
deep in a labyrinth of microcontrollers in a single vehicle or
device, it can spell disaster from a security perspective.

Buffer overflow is especially prevalent, and if you want to take
a deep dive into how it helped compromise that air fryer we talked
about before (allowing remote code execution), check out this report^[5]
on CVE-2020-28592.

Now, it’s time to get hands-on with a buffer overflow
vulnerability, in real embedded C/C++ code. Play this challenge to
see if you can locate, identify, and fix the poor coding patterns
that lead to this insidious bug:

How did you do? Visit www.securecodewarrior.com^[7] for precision, effective
training on embedded systems security.