Abstract: “If You Can’t Open It, You Don’t Own It”:
For the past 30 years, we have dealt with penetrations into secure systems almost exclusively from the software layer: applications and operating systems. With the advent of side channel attacks like Spectre, Meltdown and Foreshadow, hardware designs are now battlefields.
For C++ and Modern C++ engineers who run close to the hardware, whether they work in the embedded world or not, the implicit trust between our code and the hardware is absolute. In this talk, we’ll look at how hardware has become the newest targets for the next generation of attackers and how that affects Modern C++ systems design. Then we’ll see how hardware exploit strategies drive software exploit strategies in Modern C++.
We begin with a discussion of the concept of Roots of Trust and how each successive layer forms the Root of Trust for the layer above. But what are Roots of Trust and how can a failure at one level be used to create vulnerabilities in each successive layer? For Modern C++ systems, over reliance on the implicit trust of the layers below can spell disaster. But how does one layer protect itself against the broken trust of another?
Next, we’ll see that side channel attacks are really a class of attacks that involve involuntary information disclosure. Spectre, Meltdown and Foreshadow are just one facet of those types of attacks. We’ll look at how hardware side channel attacks that are run against hardware timing, current draw and memory all provide attackers invaluable information on the design and performance of a system. Then we’ll see how these same types of attacks can be run against Modern C++ systems by profiling a running system.
We’ll then discuss how having physical access to the hardware creates opportunities for attackers to design attacks that succeed at a distance. Physical penetrations range from probing data buses and pins to looking for emitted photons to tearing apart ICs. The exploitation of the hardware becomes the Achilles heal of the higher software layers because of their dependence in the hardware. But it also tells us something about the strategy for reverse engineering Modern C++ systems both in their behavior and their design. Understanding the strategies for reverse engineering software and source code shows us how to change our software designs and architectures to harden the target.
Finally, we’ll discuss how hardware supply chains create opportunities for nation states to build in back doors for controlling systems at a distance. We’ll see how Quality Assurance programs designed to catch tampering can be defeated by the careful selection of techniques and by simply playing the odds. We’ll see how the strategies for testing are evolving to confront this new reality. And we’ll look at how securing the supply chains of the future points us toward securing the supply chains in Modern C++, namely open source libraries.
Along the way, we’ll see:
how C++ designers can defend against the failure of Root of Trust that’s been in place for decades,
how software and hardware designs are changing to address these new threats,
how the compromises of the hardware supply chains mirror the compromises of the open source software industry, and
how the lessons learned in hardware exploitation affect the design of Modern C++ systems.
For C++ developers, understanding how the hardware layer can be compromised presents new challenges and has profound implications on the design and implementation of Modern C++ software systems.
Abstract: “Threat Hunting”:
C++ is a notoriously difficult language to master and Modern C++ is not far behind it. The language itself is powerful and flexible but does little to protect us from using it incorrectly and the closer a vulnerability is to an attack surface, the more easily it can be exploited. But how do you know where your attack surfaces are?
Threat Modeling is the foundation of everything else we do when securing our code. It tells us where the attack surfaces are, what possible attack vectors there are, where we aren’t verifying who we’re communicating with, where we’re holding data and more importantly where we’re holding data we don’t use. Threat modeling forces us to analyze our designs & code by focusing our thinking to that of an attacker. Without it we have little to go on when looking for areas of vulnerability.
In this talk, we’ll begin by looking at Intrusion Kill Chains, a simple but effective way to describe the process that attackers use to penetrate systems. We’ll look at one of the most famous and successful attacks in cyber history through the lens of a kill chain.
Using this knowledge we’ll then do a hands-on Threat Modeling exercise against an everyday system designed in Modern C++ using the STRIDE approach (and discuss others as we go). We’ll look at:
how Spoofing can be used to gain unauthorized access to data within our system,
how Tampering is used to affect system behavior and how to protect against it,
how Repudiation is used to ensure that all systems behavior is verified,
how Information leaks give an attacker vital information on how to attack our systems,
how to defend against Denial of service attacks, and
how privilege Escalation attacks give attackers access to more than just our systems.
We’ll also discuss how we have come to live in a Zero Trust world and how that affects systems design. We’ll see how Threat modeling allow us to:
expose attack surfaces,
uncover architectural flaws early,
identify attack vectors,
balance risks and usability, and
document mitigation strategies.
Modern C++ is a powerful, flexible language, but it’s not safe for those who have not truly mastered it. And as systems complexity increases, those knowledge gaps leave openings for attackers. Threat Modeling is the first step in sealing those gaps.