Sirius XM flaw unlocks so-called smart cars thanks to code flaw Sirius XM's Connected Vehicle Services has fixed an authorization flaw that would have allowed an attacker to remotely unlock doors and start engines on connected cars knowing only the vehicle identification number (VIN). Yuga Labs' Sam Curry detailed the exploit in a series of tweets, and confirmed that the patch issued by …
Sirius does telematics - traffic reports, roadside assistance, movie tickets, gas prices, and tons of marketing buzzword features that requires a subscription. Some of it is via the satellite link, some by cellular.
It's hard to imagine that at least 12 major companies worked on these protocols and there was still zero security. That's a pretty pig pool of engineering stupidity.
for a short time I worked at a car company, being located in the development offices they had exactly 0 staff with any clue or idea about any of this stuff, no one was tasked to even look at it, this comes as no surprise.
when I tried to raise a know security issue, I got bounced around, little understanding or comprehension of the dangers of interlinked remotely accessable systems
"It's hard to imagine that at least 12 major companies worked on these protocols"
That's because they didn't work on them. Those companies each put out a bid for a product that would do what they want, and Sirius XM's product was the one chosen.
Car companies don't build much in house, at least fo electronics. Instead, they plug in something made by one of the big tier I manufacturers (Bosch, Continental, Wabco, ZF, etc.). In many cases, the automotive company may have their own software running on the module, but they don't know squat about the underlying software or hardware.
Source: $dayjob is close to the industry.
Really? I have no difficulty imagining it.
And from Curry's tweet that was quoted in the article, it sounds like these are straight off the OWASP Top 10: A01:2021 Broken Access Control (includes direct object access, which is the "we put in a VIN" issue, and exposure of sensitive information to an unauthorized attacker, which is the "even without the JWT" part); and A04:2021 Insecure Design (includes incorrect privilege assignment, trust boundary violations, and general "your security is not so good").
So this software has a web-service interface which was not designed properly and was not hardened against the OWASP Top 10, which is the very first thing a web UI or API should be checked against. It's a failure to follow even the most basic of best practices for web security.
But the same is true of most of the web UIs and APIs I look at. Vendors simply aren't interested in doing this work correctly. The market isn't fixing that, so regulators will have to.
"The researchers determined that the telematics platforms used the car's VIN, which is located on most cars' windshield, to authorize commands"
Yet another example of "coding" as opposed to software engineering. The latter takes into account the purpose and operational context of the code so it fulfils the required purpose robustly. The former just releases stuff that seems to "work" in the dev environment. The fundamental difference is the presence or absence of forethought and interest in the end purpose.
Agreed.
Yes, a bona fide software engineer would be the correct choice - due to the threat to the population posed by the motor vehicle industry. But any decent programmer would not propose/accept such a moronic concept as using a single field (VIN), which is available to "anyone", to be used in this way.
Hey, though, it's not the first time we've seen manufacturers that are leading in their discipline assume they can handle ICT functionality. And, ofc, it won't be the last. One that always springs to mind is Yale locks going NFC. That improved your products how, exactly?
Any software should start with some requirements. In this case, one of those would be "only the legitimate owner can unlock the vehicle." Then there's some software engineering to implement the requirements, then a coder can write the code. And then, crucially, it's subjected to a barrage of tests to ensure it meets its requirements. For anything security-related, that should include penetration testing. So there's a whole bunch of fails here, but the lack of proper testing seems the most egregious. This software is protecting a valuable asset, and ought to have been treated accordingly. Or am I being naïve?
Unfortunately the requirements (for almost all software) have changed to "Do the minimum necessary to get paid".
Competent software engineers cost much more than an Indian sweatshop programmer so the beancounters use the cheap labor and do not care about adverse outcomes.
Icon for what should happen to all managers who choose low cost ahead of safety ====>
And of course threes scenarios where how API / functionality will be is mandated from "above" (e.g. by product design with some IT knowledge but zero security clue) and arguments against are dismissed as "negativity" or similar... So an insecure system is developed with devs knowing full well there's going to be security trouble in the future.
The provisioning is the problem. If the manufacturer creates a key infrastructure to connect cars with authentication details, it's now a database that has to be maintained. Plus the customer care cost of fixing inability to start or service when the database is wrong.
little more complicated than that.
most computer software engineers from school, college/university are NOT taught security in a meaningful way.
They teach by book, in specific ways to build crap, not how to think around a problem logically.
Hackers on the other hand, are driven to understand the low level concepts and how systems can be subverted. and are really good at reverse engineering from minimal clues.
(cough, I only ever did this for amusement and stopped before it became illegal, thats my story, and I'm sticking to it, incase gov are watching!!)
"most computer software engineers from school, college/university are NOT taught security in a meaningful way"
In which case they're not actually engineers at that point in their careers. Designating someone "engineer" doesn't make them one -- they have to be able to perform to a standard that justifies the label. Graduating in any discipline is the start, not the culmination, of the required learning process. Contrary to popular opinion, even a PhD doesn't make one omniscient -- it's just an initial training in conducting a research project. What's needed thereafter is a lot of experience in delivering successfully.
Competent software engineers cost much more than an Indian sweatshop programmer so the beancounters use the cheap labor and do not care about adverse outcomes.
Unfortunately, it's not just 'cheap' outsourced labor that is the problem. Even 'Engineers' pulling big salaries and so called Project Managers are causing these problems. I am surprised at how many professional developers struggle with basic concepts. But we're Agile, so everything is rosy.
Personally, I don't fear a SkyNet type (or I Robot) human subjugation. I'm not convinced the human race is capable of developing AI that can extend itself beyond humans. AI isn't smarter, just faster. I'm more worried about the self-drive (or self anything) sloppy coding turning anything with a computer into Maximum Overdrive because someone heard of the 80/20 rule, and QA and security became part of the 20.
I suppose we should just be happy that Teslas crash into emergency vehicles, not school buses. See, I can be a glass half full kind of guy.
"We take the security of our customers' accounts seriously..."
As a Sirius XM radio customer, I had to call them around 8 years ago to transfer my service to a new car. I was completely flabergasted when the agent asked me, like it was nothing: "Are you still happy wirh [censored] for your password?" I am not kidding: not only were they saving their customers passwords in plaintext, but customer service agents could go and read them all they want! I immediately expressed my outrage to the agent, who became very defensive and argued that only authorized personel were allowed to access the passwords; yeah, right, and all agents on Earth are always honest, and no risk at all for the data to get stolen...
I don't know if they changed their way of storing passwords, but no suprises to me here if they conceived a system that is so eay to hack.
I notice a number of Japanese companies on that list.
Back in the eighties we were looking at how easy cars were to steal (for research purposes) and at the time certain brands were notoriously easy to TDA. Ford and Vauxhall were particularly well known for their lack of resistance to theft. We found some Austin Rover vehicles were a cake walk too. We found Saabs were probably the most secure of the European brands. And then we got to the Japanese cars.
Japanese cars were at the time generally a cut above most European brands for both their ingenuity and their build quality so we were expecting their theft resistance to be top of the pile. We were disappointed. Several were very easy to get into without breaking anything - not unusual, this was the eighties after all. But lots of them were very easy to start and drive away.
Speaking to an expert on things Japanese revealed that theft was is not really part of the Japanese psyche. Since they found it hard to understand why somebody would steal a car they didn't really have the thought processes to make a car secure. After all you need to be able to think of the methods somebody might use to steal a car in order to thief proof a car.
Maybe little has changed in that respect so they just trusted the vendor.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
