Web hackers vs. the auto industry
samcurry.net
samcurry.net
- Broken API authentication mechanisms, SSO that doesn't work properly. The frequency with which they could simply register accounts and then make themselves some sort of admin by sending ordinary HTTP requests, without ever once needing to confirm with anyone in person, is quite astounding.
- Everything being totally exposed on the internet: frontends, backends, all of it. Apparently IP firewalls are history.
- Stringly typed APIs and protocols in which adding escaped control characters in various places allows bypass of critical comparison logic.
- And a bit of SQL injection. Apparently only worth looking for on old web apps - progress?
It feels like the ad-hoc way user accounts were added to the web platform have led to a universe of different implementations and varying exploits. Still, it'd be good to know what their failure rate was. How many companies did they attack without finding any (serious) problem?
Yes, but very minimal and disappointing.
Sure, people got serious about this and today, SQL injection is hard to near-impossible to introduce using modern frameworks and practices. But we got there by learning the wrong lesson.
We've treated SQL injection as its own vulnerability class. We've taught a generation of developers to Not Write SQL Statements By Hand, to Use Prepared Statements or Use ORMs. Libraries and frameworks were changed accordingly. Sanitizing, which evolved to "Web Application Firewalls", was introduced to detect and block SQL injection attempts. We've solved this as a specific case, instead of learning the general principle: never work with structured operations on structured data in their string representation form.
"Stringly typed APIs" you mention are just another form of this, they're the same class of problems as SQL injection. So are XSS attacks. So are ${any other query language} injection attacks. So is your site breaking apart because of a stupid mistake or malformed user input that broke your templating engine. All of them are caused by gluing unstructured strings together and then deserializing the result.
Operations like "interpolate this value in this place of structure/query" aren't string-level operations, they're structure representation level operations (e.g. DOM node replacements). If you do them in their natural representation, injection vulnerabilities cease to exist.
This is something I bang on about a lot in the last few years. So many exploit classes go away entirely if you write an app using standard OOP desktop UI frameworks and tooling. Take a toolkit like Jetpack Compose, JavaFX, WPF and combine it with gRPC or, alternatively, log in directly to the database (as your own user). Now it becomes nigh on impossible to mount injection attacks.
In particular, if your ACL logic is expressed in the database itself (row level security, security-definer views, stored procedures etc), and every user of the system has a database user, then SQL injection goes away entirely by design because you're now designing on the assumption that the user can run arbitrary SQL anyway. If something goes wrong with the containment it's a flaw in the database or your declarative ACLs, and can be patched in one place (+if it's a db bug you can hold the vendor responsible if you license a commercial rdbms).
Now, this type of design can't solve all the problems that cropped up in their explorations, and it adds a few new ones - you have to be careful to configure your database correctly, obviously, and you might become more vulnerable to DoS attacks, although for web apps like dealer consoles DoS is probably not your primary concern. But you will at least have one place to declaratively assert what data everyone should be able to see, and authorization is enforced by centralized logic. Some of the problems found in these websites seem to be caused by devs losing track of what bits of code are meant to enforce security. There are auth tokens everywhere but nothing is being enforced properly. Two tier direct-to-db designs would fix that.
Still, the worst vulns here all seem to be related to creation of new accounts for semi-private systems and the onboarding process for how to assign roles to them. Most auth systems consider account creation and role assignment to be out of scope, which encourages/forces everyone to roll their own account system on top of the web. The results speak for themselves.
Still people insist on writing their code as text strings mumbling "something something but my vim".
As long as people think strings are some "universal format" this madness won't stop.
(The vim people at least insist. The IDE people just roll their eyes, not understanding what is being talked about and how code could look any different.)
And while you'll have to pry my Emacs from my cold, dead hands, the no #1 thing I wish for is the ability to keep the code in a database (or at least treat it as such, and not look at the raw text files) and expose it through various structured view, allowing editing at higher level of abstraction.
There are benefits to 2D textual representation, not the least of which is that both Emacs and vim let you work with it with efficiency and ergonomics unmatched by any other tool. But it should still be seen as representation, not the ground truth, and exploited to its full potential.
Some trivial examples of what I'm thinking about:
1) Render class content as an org-mode table like:
| name | type | access | initializer |
|--------------+---------------------+---------+-------------|
| GetWidget() | () -> Widget | public | |
| widget | Widget | private | {} |
| frobnicators | vector<Frobnicator> | private | {} |
| ... | | | |
With this, I can very quickly add, modify, or reorder fields, and the view should either immediately or on "commit" step ensure that I can't possibly get this wrong syntactically. Renames and other changes should, obviously, do appropriate "refactors".2) Imagine something like 1), but rendering the result of a query "every field of every class in the current module, that is of type Frobalizer<?>". I'd then be able to e.g. rename these fields in bulk using, say, one or two regex-replace calls, and then commit it to execute a mass renaming "refactor".
The benefits of staying with 2D text as a representation form is that vim and Emacs are really that good at navigating and editing it, much better than GUI-based equivalents could ever be. I think it also maps quite nicely to how people think - there's the abstract structure, which you inspect by viewing it in various representation, and when you want to change something, you think in terms of how you'd want the representation to look like after the change - e.g. "I want all those Y and Z to be X and Q instead".
But I've posted something similar to what is described here just the other day:
https://news.ycombinator.com/item?id=34232549
The thing we interact on the surface should stay "text like" of course.
But the tools used should work on the actual data structure (and this should be also what ends up it on disk).
Proper editors (and IDEs) do this partly anyway. Only that things get converted (loosely!) back and forth between the internal representation of the IDE and the text on disk. The compiler than again extracts the rich data form the text, over and over. Pure madness…
If just the LISP machine would have won… Things would likely look much better now. We would work with rich ASTs instead of text blobs I guess.
Surprised to see these even mentioned on HN. I've read R155 as part of my job and am responsible for implementing it.
I have no idea what exactly will be exposed to the manufacturer's backend, what can be manipulated and hacked on the front-end, and the possible safety repercussions involved with this.
Who's to say some government/corporate espionage results in a manufacturer getting their back-end hacked and having every online vehicle immediately get their brakes applied? Definitely some Black Mirror-esque stuff...
Not to mention the convenient ability to surveil any vehicle and their locations with a busted and easily crackable API - why does it take external hackers with a (thankfully good) sense of morals and ethics to bring these things to companies' attention?
It'll probably take something hitting national/international news before lawmakers or companies take this security seriously.
The automotive industry has simply been slow to adapt. Manufacturers were almost universally founded in an era when mechanical systems dominated and that's how they want to treat everything. There's been a painful and ongoing learning process for them to realize that software and computerized systems are fundamentally different from the mechanical systems they understand well.
On the inside, doing things securely takes a lot of deliberate and careful work. COTS stuff is rarely designed for high security systems. I've sat in more than one pen test where we found a wireless interface unintentionally added by some dev board that was selected for a completely different purpose. I've also seen cases where the security team/software teams were hired/onboarded after the vehicle design was essentially finalized with little consideration for their requirements.
And so have the legislators and regulators who should have been preventing the automotive industry from selling products where it increasingly seems plausible or even likely that a vulnerability will be found and exploited at scale by someone really trying to do harm and the consequences will be catastrophic.
The danger has been obvious to many who work in tech for a long time and has been publicly demonstrated often enough against enough different types of vehicles that the threat should be like a giant billboard that is repeated every 100m along every road in the world by now. Someone in power needs to realise that even the kind of intense scrutiny and safety culture that we see in for example aviation or some medical fields or nuclear power stations doesn't scratch the surface of what we need for an industry that sells around 100,000,000 new vehicles every year.
The auto industry is infamous for treating the human cost of its failures as a mere financial cost of doing business and operating accordingly. It simply can't be trusted to "adapt". It must be forced through unprecedented levels of oversight, regulation and sanctions for businesses, executives and investors who don't act responsibly.
That is a huge understatement, as they mostly (majorly?) employ electrical/mechanical engineers who end up writing code for the ECU's. Cloud services are mostly an afterthought in design. In my experience, regulation isn't the main problem.
I've personally sworn off any more responsible disclosures to companies not paying at least $1,000/hr(USD) in rewards or without clearly good intentions. I am not bending and very backwards to find it either. Any shenanigans is instant disclosure and shenanigans exposure.
I'm about to be homeless and know of exploits currently working at 20billion dollar companies. They can't even bother responding to emails...
There's a point where one has to focus on needs. Morality I want, food I need.
Yes, but jail food isn't all that it's cracked up to be and if you are able to get that kind of work done then your choice isn't $1000/hour for undisclosed vulnerabilities or starving, the viable alternative is just to get a job.
With those skills you are 10x as employable as most people that are currently jobless. At least.
I should mention that I don't intend to release or sell anything harmful. I just recently experienced this issue and I came out on the right side(?). I can see someone coming out the other side too, too easily. My intent rather is to stop working for free. I will notice it, note it, eliminate my personal exposure, and ignore it. I would say that puts me somewhere between white and black.
It's not easy (for me) to find employment. My last company was in automotive advertising(bankrupt) and I am aware of quite a few more problems than what you see in this disclosure. Though the listed brands are outside of my knowledge.
I imagine my odds of being an accident in which 25 years of crash safety advancements help are higher than being hacked.
(and for the inevitable flood of "But the A pillars are bigger" comments, if you're safety conscious you can still get cars with reasonably sized A pillars. A few years ago Honda specifically called out smaller, further recessed, A pillars for visibility in the Accord redesign)
The best way to avoid crashes is to drive less, which is what I'm also doing and why I expect this car to last the rest of my life (and probably well beyond, the way I'm maintaining it). It's my daily driver because that's what I would be driving if I were to drive on any given day but I'm actually quite surprised to find out that I spent more last year on insurance than on fuel.
Automatic emergency braking is probably great if all you do is highway traffic and stop-and-go but it really sucks that you can't disable it and that it isn't able to distinguish between safe and unsafe to a degree that it will turn a safe situation into an unsafe one all by itself. At that point in time a safety feature becomes a risk in itself. Possibly the statistics are still in favor of the solution but I'd rather take my chances.
We are monsters.
https://www.epa.gov/clean-air-act-overview/benefits-and-cost...
Like it or not, old cars spew highly toxic crap out their exhaust.
Back to the topic at hand, are you claiming that all of the safety improvements added to the cars over the past 20 years didn't make a massive positive impact on passenger safety during collisions? Arent't there agencies worldwide that issue safety ratings after performing variety of tests and studies (that are way more rigorous and quantitative than a one-off anecdote), and they show massive safety improvements over time for all cars in general? Or are you trying to claim that those agencies can't be trusted, and that their tests are not valid?
I am not trying to be combative about it. I am just genuinely trying to figure out what point you were trying to make with this anecdote, but all I have right now is pure guesses.
A good 10-20 year old car may have as good crash rating as many modern cars. top or average modern cars may be better than top or average 10 year old cars. Stats are interesting thing. But then there's the average driver assistance vs average UI vs average visibility vs average handling of these cars.
Bottom line, I don't feel less safe but I do feel differently safe, in my old Subaru and new Honda.
What percentage of crashes can be attributed to that? Let's make it simpler, how many crashes per year as a raw number happen due to those reasons you listed?
Because out of all things I would be worried about when it comes to car safety, this is the one that is least concerning to me. Especially since for most modern cars that have such a thing as "software updates" in the first place, they have the driving subsystem and infotainment subsystem entirely detached (yes, even on Teslas). Very easy to confirm yourself by force rebooting the infotainment center and seeing that the car still drives just fine.
In summary, the infotainment system and the drivetrain definitely speak to each other and unless a secure architecture comes along, I would not discount the possibility of unintended interactions due to bugs. In fact, most famous car hacks start from the infotainment system and make their way into the drivetrain.
2. I don't have those numbers, in fact point of my post I'd that I don't know how we get those numbers. When I'm a passenger I'm terrified how distracted people can be by poor UI. I wish we had more hard data. Some studies are slowly emerging.
Why do I compare an old "upper class car" with a modern "lowest tier"? Isn't this unfair? No, because that is usually the choice people have. If they can afford just the cheapest of new cars, there is likely a much better one that is not new available for the same price or a lot cheaper.
Case in point: I've restored a Daihatsu Trevis, a small Japanese budget car, and after working on it and bringing it back up to the standard required to pass a salvage title inspection (which is a higher standard than the original one where I live, you have to book an inspection for the vehicle that takes several hours and that will have cross frame measurements and all kinds of assessments to make sure that the vehicle is safe) I decided that this is not a car that is suitable for many kilometers of highway driving. A crash in that car that would be survivable in even the cheapest Golf or Skoda would be lethal in that little car. So I ended up passing it on to people that only drive in the city and got an elderly Golf instead.
And a Golf was definitely not the high end of safety at that time, but it was tons better than the much more modern Trevis.
That car was often a butt of many jokes as people thought its chassis was made off "recycled paper" (in fact it was one of the first composite chassis cars). It was called a plastic-soap-box, but it was so simple to repair one needed a push bike set of tools to fix anything (until once a suspension strut in a rear wheel failed). Then all it took to be able to get back home slowly was to wrap it with some steel wire... Fun little car. Unfortunately it was scrapped against my will when I was abroad (my parents weren't happy I drove it). Today many people consider it a classic and it has quite a following.
It's just pretty well established that in the last 25 years we've made huge strides is vehicle safety.
People routinely walk away from accidents where they would die in a 25 year old car because of those advancements.
The difference in survivability is not small: https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/...
If you extend the time range to 25 years I might agree, but let's say we start at year 2000. I fail to see those "huge strides in vehicle safety". Perhaps what you mean is that certain "upper tier" features made their way into basic equipment. That no doubt has positive impact on an average driver.
However, at least for me, any time I bought/rented an old car it was always a top spec version, so as mentioned. I don't see those huge strides.
I've gritted my teeth every time somebody on HN has referred to their computer as their "daily driver", but I will remain silent no more: You, sir, are the daily driver of your automobile, and NOT vice versa.
However, I'll allow that to connect any new auto you purchase to your computer, you might need to download new drivers.
I'd drive either of them to any spot in the world. I'd carry tools and spares, but I'd still drive them there.
There’s no way they would remove remote control functions in cars, regardless of the safety implications for the drivers.
I bet after we get the first terrorist act in history to reach millions of victims, they will. And then they will claim nobody could predict it.
Depends how you define reach.
I can't buy dynamite without a bunch of onerous license requirements thanks to a variety of 70s "activists". I can't buy a bunch of fertilizer without getting on a list because the FBI doesn't like when people make them crispy. I can't call overseas without the metadata being recorded in perpetuity by the NSA because some terrorists hijacked some planes. So a nation of 300+mil has already been "reached" by plenty of terrorists if you count putting up with not directly violent but inconvenient BS.
Why would anyone call overseas (i.e., using voice service with a "phone number") in this day and age anyway? Anyone with half a brain knows to use chat apps and their voice-calling (or video-calling) functions to talk to their friends overseas.
Why on earth would you do this? Your country's embassy is a local phone call, in whatever country you're in. Your embassy isn't in your home country, it's in the country you're now present in (geographically at least, but not legally, but the phone number is still a local number).
Also, this stuff can usually be handled online these days.
We're talking secure!
https://medium.com/@mpesce/the-great-hack-part-one-attack-70...
;-)
There are a lot of money to be made if you're good, so there's the incentive as well.
And Google's bounty program reward hackers who will find bugs in apps with over 100 million installs, or in google's open source apps. And they pay up to $30,000 per bug depending on impact.
Yep, I see this all the time in junior's code.
People doing such things should never got the job in the first place.
My year 2000 car with stick-shift and window cranks seems more valuable now, it even has mechanical accelerator/throttle, lol hack that.
(I worked on some parts of this research.)
It would be fun to buy a Prius Prime and play Quake on it with steering and horn as controls.
Not good, but seems to be the IT curse repeating again and again.