Sign up to our newsletter
2016 is already being dubbed “The Year of Ransomware” and ransomware features prominently in my upcoming “Mid-Year Threat Review” webinar. In that webinar I will also be talking about the IoT (Internet of Things) and more specifically the IoIT (the Internet of Insecure Things); mainly because risks arising from the latter are on the rise. Don’t get me wrong, I’m not saying that the IoIT currently poses as big a threat as ransomware does. But part of my job is to look beyond the present – and I’m concerned that a future headline will read: “The Year of Jackware.”
I define jackware as malicious software that seeks to take control of a device, the primary purpose of which is not data processing or digital communications. A car would be such a device. A lot of cars today do perform a lot of data processing and communicating, but their primary purpose is to get you from A to B. So think of jackware as a specialized form of ransomware. With regular ransomware, such as Locky and CryptoLocker, the malicious code encrypts documents on your computer and demands a ransom to unlock them. The goal of jackware is to lock up a car or other device until you pay up.
Fortunately, and I stress this: jackware is, as far as I know, still theoretical. It is not yet “in the wild”.
Unfortunately, based on past form, I don’t have great faith in the world’s ability to stop jackware being developed and deployed. We have already seen that a car company can ship more than a million vehicles containing vulnerabilities that could have been abused for jackware. I’m referring to the Fiat Chrysler Jeep problem that was all over the news last year. Just as serious as those vulnerabilities, in my opinion, was the apparent lack of planning for vulnerability patching in the vehicle design process. In other words, it is one thing to ship a digital product in which ‘holes’ are later discovered – in fact, this is pretty much inevitable – but it is a different and more dangerous thing to ship digital products without a quick and secure means of patching those holes.
And while most “car hacking” research and discussion centers on technical issues within the vehicle, it is important to realize that a lot of digital devices and IoT technology relies on a support system that extends well beyond the device itself. We saw this last year with VTech, a player in the IoCT space (as in Internet of Children’s Things). Weak security on the company’s website seriously exposed personal data about children, reminding everyone just how many attack surfaces the IoT creates. We also saw this infrastructure issue earlier this year when some Fitbit accounts had problems (to be clear, the Fitbit devices themselves were not hacked, and Fitbit definitely seems to take privacy seriously).
So what has this got to do with cars? Consider the recent news of bugs in the online service web app for BMW’s ConnectedDrive. There are a lot of interesting IoT aspects to ConnectedDrive. For example, you can use it to regulate your home’s heating, lights, and alarm system “comfortably from inside your vehicle”. The possibility that the features and settings of an in-vehicle system could be remotely administered through a portal that could be hacked is unsettling to say the least. And the reports of insecure smart car design keep coming, like this Wi-Fi enabled Mitsubishi, and hacked radios used to steal BMWs, Audis, and Toyotas.
To stop jackware being developed and deployed a number of things need to happen, in two different spheres of human activity. The first sphere is the technical sphere, where the challenge of implementing security on a vehicular platform is considerable. Consider the processing power and bandwidth required for traditional security techniques, like filtering, encrypting, and authenticating. This adds overhead to systems, some of which need to operate with very low latency. Security techniques like air-gapping and redundancy could potentially add significantly to the cost of vehicles. And we know that controlling costs has always been critical to car manufacturers, down to the last dollar.
The second sphere where action is required to head off jackware is policy and politics. The outlook here is not good because so far the world has failed abysmally when it comes to cybercrime deterrence. There has been a collective international failure to head off the establishment of a thriving criminal infrastructure in cyberspace, one that now threatens every innovation in digital technology you can think of, from telemedicine to drones to big data to self-driving cars.
Consider where we are right now, mid-2016. Ransomware is running rampant. Hundreds of thousands of people have already paid millions of dollars to criminals to get back the use of their own files or devices. And all the signs are that ransomware will continue to grow in scale and scope. Early ransomware variants failed to encrypt shadow copies and connected backup drives, so some victims could recover fairly easily. Now we’re seeing ransomware that encrypts or deletes shadow copies and hunts down connected backup drives to encrypt them as well.
At first, criminals deploying ransomware relied on victims clicking links in emails, opening attachments, or visiting infected websites. Now we’re also seeing the bad guys using hacking techniques like SQL injection to get into a targeted organization’s network, then strategically spread the ransomware, all the way to the servers (many of which may not be running anti-malware). The war stories from victims keep rolling in but there’s been very little in the way of indictments or arrests. Given the technical challenges of securing increasingly connected, computer-enabled vehicles, and the apparent lack of progress in deterring cybercrime, the outlook for jackware is not good (or rather, it is good if you’re a bad guy thinking about the long term).
So, is it inevitable that ransomware will eventually spawn jackware? Well, it certainly seems like a logical progression. A few months ago I was talking to noted Canadian automotive journalist David Booth. He has written about car hacking in the past and when I described how ransomware was attacking laptops and servers he quickly arrived at this headline: Ransomware is the future of car theft. In my opinion, he may well be right.
Beyond enabling demands for payment to unlock cars, I think the point at which automotive malware becomes serious jackware – and seriously dangerous – is self-driving cars. Consider this scenario. You swipe your card on the windshield of the self-driving unit to unlock it (something I’ve been doing for years with the Car2Go units here in San Diego). You get in, select your destination, and you’re rolling. The doors auto lock, for safety, and you start reading your email. Then you look up and realize you are heading in the wrong direction, to a destination not of your choosing. A voice comes on the in-car audio and calmly informs you of how many Bitcoins it’s going to take to get you out of this mess.
Let’s be clear, I didn’t coin the term jackware to cause alarm. There are things that can be done to thwart this nightmare scenario. And I certainly didn’t write this article to give the bad guys ideas for new crimes. The reality is that they are quite capable of thinking up something like this for themselves. Remember, crimeware is a business that operates through a well-organized market-based system that uses untraceable digital currency, escrow services, and reputation systems, not to mention division of labor and modularity to leverage specialist skills. You could argue that the reason we are not seeing jackware yet is simply because the time is not right. After all, there’s no need to switch from plain old file encrypting ransomware as long as people keep paying up.
Right now, automotive jackware is still under “future projects” on the cybercrime whiteboards and prison napkins. Technically it’s still a stretch today, and tomorrow’s cars could be even better protected, particularly if FCA has learned from the Jeep hack; if VW has learned from the emissions test cheating scandal; if GM’s bug bounty program gets a chance to work; and if the infrastructure supporting connected cars is built securely.
Unfortunately, just as I was thinking “there are a lot of ‘ifs’ in that sentence” a haunting refrain came on the car radio, something about “when will they ever learn …”
The following four papers, all downloadable as PDF files, provide plenty of insight into many of the cybersecurity issues pertaining to vehicles:
Author Stephen Cobb, ESET