Earlier this year, I gave a talk at the RSA Conference about the privacy and security flaws in many of today’s connected cars. The response was nothing short of astounding. As it turns out, people get very nervous when you talk about finding and controlling their cars from a mobile phone.

While I didn’t initially set out to find vulnerabilities in modern cars, I couldn’t be happier that this project fell into my lap as global head of IBM X-Force Red.

Time Flies When You’re Breaking Toys

This past year since we founded X-Force Red has been a wild ride. I have seen the team come together and grow rapidly. We’ve made amazing hires, done great work in penetration testing and surpassed all expectations. Perhaps most importantly, we are poised to continue to do great things in the future. I could not be prouder to be part of X-Force Red’s development.

X-Force Red is a team made up of some of the world’s best security researchers — folks who grew up breaking their toys and figuring out ways to make computers misbehave. As soon as the team discovered my interest in connected cars, the light bulbs started going off. Soon, we were all working on breaking the biggest toys we could find: our cars.

If you’ve purchased a car made in the last decade, there’s a good chance that hundreds or thousands of electrical components are packed into your ride. Each of these components performs one specific task, but also communicates with many other devices doing the same.

If you stop to think about it, your car is essentially a computer on wheels. Some models have remote connectivity to apps on our phones, while others have satellite radio or infotainment packages. The newest cars are cruising around with Wi-Fi hotspots. The more convenience we pack into our cars, the more complex and vulnerable to attack these systems become. To put it all into perspective, the space shuttle ran on about 4 million lines of code. To run the average modern car, it takes about 100 million lines of code.

It’s safe to say that auto manufacturers aren’t looking to make cars less functional than their competitors, which means the attack surface of our vehicles is only going to expand. So how do we make sure we’re winning this technology race? By testing the components and then testing the complete system.

Sound too simple? At first, yes, but consider the way automotive production works. If we stringently test the hardware, applications, networks and even the human interactions of this year’s model, we’re going to have a pretty solid baseline for next year’s model. The auto industry knows that the most effective way to make cars is to keep what people like about this year’s edition and then make the next model even better. That’s just good business.

In the world of security testing, we’re also about good business. That’s precisely why we’ve made it convenient and transparent for our automotive clients (as well as all our clients) to programmatically test their products and solutions. For a vehicle, we have to test every component that could possibly introduce vulnerabilities into the complete system, and then test the ones that shouldn’t. This all happens before we test the complete system as a whole. Once we establish our baseline, the following year’s model becomes part of a programmatic test.

From a security testing perspective, we’re thorough. Cybercriminals only have to find one way into a system, but we have to find every way to protect that same system. If we’re looking at the same components year-over-year in a given car, with only incremental changes in infotainment, telemetry and various other systems, the programmatic testing process becomes much easier to manage.

Managing the security of multiple models and years of cars can become increasingly complex as new software updates and patches are rolled out — but it doesn’t have to be. Our automotive clients use the Red Portal to schedule security tests, view vulnerability assessments in real time and collaborate with X-Force Red on remediation before cybercriminals even know the updates exist.


X-Force Red Spreads the Hacker Love

At this point you may be saying to yourself, “It seems like this process would work for other industries beyond automotive.” And you’re right! Today we are pleased to launch a collaboration with the Watson IoT Platform to help ensure that Internet of Things (IoT) solutions get X-Force Red’s special brand of hacker love.

From the ideation phase to deployment and throughout the life cycle, X-Force Red can offer our expertise and, most importantly, assign a real human security expert to actively try to make the given product misbehave. We really love doing that, in case it wasn’t clear.

In the end, we want to help our clients move from only testing distinct targets to programmatic testing and solution testing. Since data is so often leveraged in a shared model where devices interoperate seamlessly, the industry can no longer think of technologies in isolation.

Want to hear more from Charles? Listen to this exclusive podcast

More from Software Vulnerabilities

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…