Sirius XM Software Vulnerability

This is new:

Newly revealed research shows that a number of major car brands, including Honda, Nissan, Infiniti, and Acura, were affected by a previously undisclosed security bug that would have allowed a savvy hacker to hijack vehicles and steal user data. According to researchers, the bug was in the car’s Sirius XM telematics infrastructure and would have allowed a hacker to remotely locate a vehicle, unlock and start it, flash the lights, honk the horn, pop the trunk, and access sensitive customer info like the owner’s name, phone number, address, and vehicle details.

Cars are just computers with four wheels and an engine. It’s no surprise that the software is vulnerable, and that everything is connected.

Tags: cars, hacking, vulnerabilities

Posted on December 1, 2022 at 10:10 AM • 19 Comments

Comments

TimH • December 1, 2022 10:40 AM

The scary bit:

Sam Curry
@samwcyo
·
Nov 29
Replying to
@spikeroche
With the account takeover, you could access everything on the user’s SiriusXM account where you could enroll/unenroll from the service, but if I remember correctly the API calls for telematic services would work regardless of whether there was an active subscription.

Josh Joyce • December 1, 2022 11:35 AM

There was a podcast episode called “The Roman Mars Mazda Virus” (that’s the transcript link; here’s the MP3) about how the “99% Invisible” podcast could crash the in-car entertainment system in a way that was difficult to fix. It was a format string bug, of course, because of the percent sign; there was a “Mazda feed” of the podcast for a while, consisting of the same episodes with the percent sign removed.

Mazda later had a very similar bug caused by radio broadcasts. FM radio now has some way of embedding metadata, including station logos, and a station transmitted an image whose filename had no extension. Because of that, the car was permanently locked to that station, with no volume control (though a commenter said muting still worked), till the radio unit was patched or replaced (Mazda wanted $1500, but later relented and waived the fee as a “goodwill” gesture).

The persistency of these crashes were caused by the entertainment system storing data about what people were listening to, and reloading this data on the next boot. There’s usually no easy way to wipe this private data; those who consider it a privacy invasion had better just use the analog line input.

I don’t recall anyone checking for remote exploitability of these bugs. But given the level of incompetence they demonstrate, I’d be shocked if Mazda’s systems were secure.

Cars are just computers with four wheels and an engine.

They’re actually a network of several computers, which adds to the fun.

Neither the Twitter nor Gizmodo links will work without Javascript enabled; the latter one has no text whatsover. Here’s a working Twitter link. An alternate Gizmodo link would be appreciated.

Clive Robinson • December 1, 2022 12:30 PM

@ Bruce,

“Cars are just computers with four wheels and an engine.”

Computers as most people understand them in general have “no physical agency” beyond push paper out of a printer and opening a drive door.

A car is upwards of 1500lb of metal with upwards of a 100kW power generation system capable of hurling it at 100mph for hours at a time.

Few people have yet realised that their car is a “leathal weapon” run by hundreds of thousands of lines of code a sizable fraction of which can alow the car to be “taken over” by somebody who could be half way around the planet.

The worst offenders at the “wrong view” in the technical commubity who should know better are general application “software developers” deluding themselves about their capabilities.

Every day more and more “Devices with physical agency” are having code loaded that is vulnerable to outside influence in hundreds if bot thousands of ways.

At some point people are going to be hurt, maimed and killed by these “Devices with physical agency” just because some one can do so. Because someone else who realy should have known beyyer, instead thought “dancing hansters” would be “cool”.

Denton Scratch • December 1, 2022 12:47 PM

According to researchers, the bug was in the car’s Sirius XM telematics infrastructure

Presumably there’s absolutely no relation with the Sirius Cybernetics Corporation, and the directors need not fear being the first “up against the wall” come the revolution.

Umm – why does a car’s “telematics infrastructure” need to be able to honk the horn, flash the lights, fiddle with the locks, and pop the trunk? That seems like automation for the sake of automation (being generous), or sinister control freakery (being cynical).

I regret the passing of the days when a reasonably-competent mechanic could diagnose most car problems, and replace most parts. My first car was a Morris Minor; you could reach in and touch everything in the engine compartment, without grazing your knuckles on neighbouring components. Most of these components were user-replaceable, and many of them were user-serviceable.

Marmot • December 1, 2022 1:40 PM

This is why consumers should be able to physically disable telematics on their vehicles. Right now it’s a ‘trust the manufacturer to disable when asked’ approach.

I’m still trying to find the radio on my new Toyota, but they’ve made it exceedingly difficult to access and find.

Tesla of course, is the anthesis of this approach (and why I’ll never drive one).

Uthor • December 1, 2022 1:48 PM

Um, does this affect cars that have Sirus, but it isn’t used by the driver? Asking for a friend. Me.

Ted • December 1, 2022 3:12 PM

Hi @Uthor

Um, does this affect cars that have Sirus, but it isn’t used by the driver?

I see TimH may have found the answer to that question. According to Sam Curry, one of the researchers:

…I remember correctly the API calls for telematic services would work regardless of whether there was an active subscription.

Sam’s got a nice Twitter thread describing the hack. Sirius reported (in the Gizmodo article) that the vuln has been patched.

https://twitter.com/samwcyo/status/1597792097175674880

bender • December 1, 2022 3:30 PM

@Marmot,

Tesla of course, is the anthesis of this approach (and why I’ll never drive one).

You don’t even need hackers to hijack your Tesla… I had borrowed an older Model S, and Tesla decided to remotely brick it until a firmware update was installed. The car was quite a few years old at that point, I have no idea what made them think that this update was so important that it mustn’t drive for another second without it.

Since the update required WiFi access, with no reachable WiFi nearby… It took over an hour with their phone support to get going again, very convenient indeed.

(As I later figured out, the reason the car wouldn’t connect to any WiFi was that it only supported 802.11b – a standard already several years obsolete when the car was released…)

Richard Rostrom • December 1, 2022 4:49 PM

Denton Scratch • December 1, 2022 12:47 PM:

Umm – why does a car’s “telematics infrastructure” need to
be able to honk the horn, flash the lights, fiddle with the
locks, and pop the trunk?

It doesn’t. The bug in the telematics code enables access to the car’s other systems, which can “honk the horn, flash the lights, fiddle with the locks, and pop the trunk…” etc.

Clive Robinson • December 1, 2022 4:56 PM

@ Denton Scratch,

“Umm – why does a car’s “telematics infrastructure” need to be able to honk the horn, flash the lights, fiddle with the locks, and pop the trunk?”

Those things are all “car park assistance”.

1) The flash of the lights and honk of the horn to find your car amoung hundreds in a big car park.

2) Opening the doors and trunk essential for the soccer mum with 2.4 children a family dog and a couple of armfulls pf groceries in those “easy tear” paper sacks.

They are all “built in features” of “key fob” entry systems. Including the infamous “butt kiss special” where if you have the fob in your rear trouser pocket of your skinny jeans you just rub your “derriere upon the handle” for instant access, thus it comes for nothing…

But (1) is also there for your “safety” if you were to accidently come off the road into a ditch out of sight then OnStar or whoever will “assist” rescuers. Along with (2) a feature that is also good for repomen…

Remember these days like your “mobile phone” and other “smart devices” and Farmers their Tractors you realy don’t own your car these days…

Matt A • December 1, 2022 6:52 PM

This is a pretty astonishing vulnerability. Just supply a VIN in the request and you can extract the car owner’s name, address, phone, etc and also car location, unlock/start, etc etc. I mean there are bugs and there is…. unbelievably poor testing.

Clive Robinson • December 1, 2022 7:15 PM

@ Richard Rostrom,

You beat me by minutes…

@ Bruce, ALL,

The perils of buses and harnesses.

Anyone who has worked with mechanical, electrical, electronic or other powered systems with parts will be famillia with the idea of a “test point”.

It enables parts of the system to be tested not just during manufacture and calibration, but also when fault finding and repair.

As systems became more complex testpoints became consolidated in various ways as each one cost a few cents on the design.

Likewise as systems became made of distributed semi-autonomous sub systems they had to be connected back to a control point. Running individual comms cables whilst making things at a low level simple, adds bulk, weight and freaky amounts to production costs. So “serial busses” were put in back in the 1980’s then cheaper I2C from Philips ment for just PCB’s got extended as did the similar SPI from rivals Motorola (that is now mainly seen on Memory Cards). Then the deficiences of such systems resulted in “hardened” comms bus systems like CANbus. However the need to shift ever larger quantities of data has resulted in other buses through to modern 100Mbit and even 10Gbit Ethernet networking in larger vehicles (think aircraft).

Unfortunately few software developers even those of embedded systems understand the important differences between speed and latency especially in shared bus systems[3]

The result is that the “fundementally insecure by design” “test bus” ended up as the base of the general Comms Bus[2].

Unfortunately the reduce cost mania went further and this means everything including “passanger toys” such as BlueTooth and WiFi for mobile phones and entertainment systems all end up on these “fundementally insecure by design” comms systems where other security issues arise [3].

So they can not be made secure, and these issues will keep reoccurring with the monotony of a metronome.

[1] There is a veritable smorgasbord os standards for CAN bus for you to choose from over and above the basic ones for the physical layers.

The basic CAN standard can be found in the ISO 11898 series, but you need a lot more than those.

As not everything is CAN bus there are other “serial protocols” that people tried to unify under “Keyword Protocol 2000” with ISO 14230 defining several parts for “diagnostics on a serial line” which is bus independent so not specific to CAN. So… Keyword 2000 is brought onto CAN bus by an intermediate syandard ISO 15765 which essentially defines “diagnostics” on a CAN bus and is thus the lowest part of the “test harness” and from memory “security” is not something considered.

[2] The story of why all these Comms
Systems have all ended up as “fundementally insecure by design” is something that happens so often we ought not still be making it, but we are. The reason is fundementally in two part,

1, Initial resource limitations.
2, Stack based thinking.

Back when these serial busses were thought up even 8bit CPU’s were a bit modern in “control systems” thus they were inordinately expensive. Even General Instrument’s 4bit PIC chips were expensive so the costs had to be justified by savings in other areas. Hence the “kitchen sink” mentallity of “chuck it all in there”. Back half a century ago security was “super scary” and was just thought of by most as “encryption” that back then was “mind boggling” resource hungry. And at the microcontroller level still is well into this century (complexity = CPU cycles = High energy usage = poor battery performance). So as “test” occures long before “integration” and “individualisation” where unique crypto keys are loaded, test necessitates unencrypted communications on the bus for low level functionality. Unfortunately under the “stack model” thinking security gets “pushed way up the stack” thus is not a requirment “on the wire” just at some high level protocol, which is the wrong place for it to be.

[3] There is a fundemental failing in most non proffessional security thinking that security is “data security” that is, if the message is encrypted by some high level protocol then the system must be secure, when infact it’s not as the “CIS triade” indicates. Few engineers actually understand,

1, Traffic Analysis.
2, Segregation under fault.
3, Reverse control channel insecurity.

We are starting to talk about parts of traffic analysis when we mumble about meta-data issues or very very occassionally meta-meta-data (though very few understand it). They realy should be “meat and vegetables” level thinking for any engineer involved with security, and that should be all of us these days.

One of the many other ways security can be obtained is by issolation or segregation. If implemented properly, and it almost never is, it can give a high margin of security. However using a common bus and segregating by time can never ever by considered secure because of faults, actual or induced, that can “block the channel” or “flip bits” on the wire.

The next problem most do not realise is due to “left to right thinking”. The assumption is everything flows left to right due to the way we draw systems in diagrams. As many software developers ignore every day, whilst data might indead go left to right, “errors and exceptions” go right to left. Many people make the mistake of thinking that “adding a data diode” gives “segregation” it does not. Due to the need for “flow control” in all “reliable” shared communications, timing information can flow back through the data diode and quite a long way backwards through a system. This reverse direction timing is a fully available “communications channel” in it’s own right and cares not a jot about your very high priced “data diode”. This issue was known about publicly in publications and journals back in the 1950’s if not earlier, long before the idea of “data diodes” was thought up as a poor substitute for security. In fact the more general blocking or “jamming” asspects in broadcast systems was known about back in “The Great War” or as we now call it “WWI”. Also spoofing and false message injection and the use of “noise in the channel” to make “recognition hard” as told by the old,

“Send three and four pence I’m going to a dance.”

Being heard rather than the said,

“Send reinforcements I’m going to advance.”

And still causing notable comment,

https://www.wsj.com/articles/BL-TEB-2613

Jon • December 1, 2022 8:12 PM

@ Clive Robinson

These guys are not dumb. I can see only one reason why these things happen: It’s cheaper that way.

All those who pointed out security problems got shuffled aside. The reason why all these things still happen, despite being well-known as both threats and readily-available mitigation?

It’s not cheap.

Thus they shall continue, until the penalties for making insecure things reflect upon not those who built them – but upon those who budgeted for (or not) them.

Thank you, J.

K.S. • December 2, 2022 10:36 AM

I don’t think we need to assume malice (it is cheaper) when incompetence (our devs have no experience in information security) can explain this. Personally, I think NHTSA could get involved in this – if there is a plausible way such issue could result in a crash, for example by distracting a derive by unexpectedly blasting loud music while driving.

JonKnowsNothing • December 2, 2022 11:02 AM

@K.S., All

re: malice (it is cheaper) vs incompetence (devs have no experience)

It is malice as you have defined it because:

Who Hires The Devs?
Who Pays The Devs?
Who Decides The Design Team?
Who Approves the Market Goal?
Who Funds the Project?
Who Gets The Venture Capital?

The Whos Do.

When the Whos pitch a project to Venture Capital, it’s not about the security, it’s all about The Money. Money and Market Share. It’s built in, ready baked.

Sure, there are goofs and gaffs that happen (= vs ==) but design faults come from Up Top and no Dev can alter that path. That path is the one approved and funded. No other path can be taken.

Jon • December 2, 2022 3:12 PM

It’s malice when someone deliberately profits.

It’s malice.

JonMightActuallyKnowSomethingAfterAll 😉 J.

Wes Plouff • December 2, 2022 5:46 PM

“Cars are just computers with four wheels and an engine. It’s no surprise that the software is vulnerable, and that everything is connected.”

Nope. A car is a distributed embedded system controlling myriad electromechanical components, including an engine.

Most cars build in the last 20 years use 20 to 50 microcontrollers, more in luxury models. Some of them have hard real-time requirements (engine, transmission, traction control), while most don’t even need to run an operating system.

It’s often a mistake to look at embedded systems through a desktop computing or IT lens. Many things about the embedded world are quite different.

Also nope. Having read Sam Curry’s original report of the Sirius telematics exploit, though, I think Bruce and most commenters are pointing fingers in the wrong direction. The basis of the exploit was weak authentication at the company’s telematics server, not anything in vehicle firmware.

Wes Plouff

Josh Joyce • December 3, 2022 3:37 PM

@ Wes Plouff,

Most cars build in the last 20 years use 20 to 50 microcontrollers, more in luxury models. Some of them have hard real-time requirements (engine, transmission, traction control), while most don’t even need to run an operating system.

The manufacturers have, for a while now, been looking to get away from having all these separate microcontrollers. The infamous “COVID chip shortage” has probably accelerated this. They’re looking at mixed-criticality operating systems, real-time hypervisors, and the like, to run as much as possible on one or a few computers. There’s promising research on ways to do this safely and securely; but, again, the history of in-car computers might not fill us with confidence in the ability of the manufacturers to do it successfully. Remember that a car faces much less regulatory burden than, say, a Boeing 737.

An internal combustion engine, by the way, is not necessarily hard-real-time (don’t believe everything you read on Wikipedia). Slightly missing the fuel-injection deadline degrades fuel-efficiency and increases pollution, but as long as the system doesn’t miss by too much or too often, it can avoid damage and meet legal requirements. (If it does happen too often, the monitoring software may turn on the “check engine” light; or, if really bad, might activate “limp home mode” or shut down altogether.)

Clive Robinson • December 4, 2022 5:23 AM

@ Josh Joyce, Wes Plouff, ALL,

Re : Embeded RT OS requirments in cars.

“An internal combustion engine, by the way, is not necessarily hard-real-time (don’t believe everything you read on Wikipedia).”

Or “soft-real-time” either, a simple “polled loop” often suffices.

Most engines in consumer cars are not “agile” and don’t have to be.

That is at 10 revolutions per second at the “idle” end and 100/S at the top end, with a response time of maybe 0.25-1.5 seconds what an engine does on the next revolution is only fractionaly different to the current revolution.

Which means a totally different design methodology to the break systems or in car entertainment systems is fine.

In fact you would be much more likely to need a real-time response from the dash-board controller needing a full display update ever 10mS or so (as many humans do not like visual flicker in their peripheral vision at even 20mS, getting “eye fatigue” and “migraines” after quite a short time).

Sirius XM Software Vulnerability

Comments

Leave a comment Cancel reply