
Gone in six seconds? Exploiting car alarms - alphabetter
https://www.pentestpartners.com/security-blog/gone-in-six-seconds-exploiting-car-alarms/
======
nearengine
I had a Viper alarm with these features installed in my car back in 2012 and
immediately noticed that while their iOS app used SSL to talk to the API, it
never actually validated the certificate, and was trivial to set up a man-in-
the-middle proxy to grab a user's auth token and make requests as them.
According to their reply their devs weren't able to replicate it, which told
me all I needed to know about their ability to write secure software. It's
good to hear they responded quickly in this instance, but I'm not sure I'd
ever trust their devices again.

~~~
xorcist
> it never actually validated the certificate,

While I agree with everything above, it can be humbling to consider the huge
amount of people already in control of that car (at the car company, software
partner, hosting partner, phone maker) but extending that trust to the local
network amounts to an inexcusable security problem.

It is interesting that having legitimate control over a certificate makes this
a desired feature rather than a huge security problem. The real world may not
be all that black and white.

~~~
nearengine
Yeah, I agree. I probably won't own another system like this from any
manufacturer as long as I can avoid it. Luckily my car came out just before
all the OEMs started putting these cellular modems in them that are attached
directly to the CAN bus.

I don't think it was the bug itself that bothered me so much as their
response, I sent them an extremely clear email with the exact steps I took and
screenshots showing how other apps responded to my fake cert with
error/warning dialogs which was escalated directly to the engineering team and
they seemed to have no idea what I was describing or why it was an issue. I
assumed at that point the issues went a little deeper than what I had
uncovered, and it seems from this post I wasn't too far off the mark.

------
spydum
So, vulnerable web apps exploited to attack internet connected cars? you'd
think they'd learn from Nissan like two years ago?

[https://jalopnik.com/how-the-nissan-leaf-can-be-hacked-
via-w...](https://jalopnik.com/how-the-nissan-leaf-can-be-hacked-via-web-
browser-from-1761044716)

~~~
Pharmakon
This is one reason why Tesla’s OTA update system scares me. As bad as hacking
an alarm or some other secondary system is, imagine having your brakes hacked.

~~~
tehlike
I see the point, but alternative also scares me. A software that never gets
updated.

~~~
onion2k
It could be updated using a file you download to a USB drive and then plug in
to a port inside the car. That way it would require physical access to the
car, and the update file could be signed to only work in _your_ car
specifically.

The only reason to do OTA updates is convienence.

~~~
vbezhenar
Most people wouldn't bother.

~~~
onion2k
Anything safety critical should require a recall, and for everything else if
the user isn't bothered that tells you a lot about how important updates to
car software actually are.

~~~
kfriede
I'd love to see statistics on how many injuries/deaths occur from recalled
problems that users don't bother getting fixed.

I know I've had cars where certain defects (non-safety) were recalled, yet it
took 2-3 weeks lead to get an appointment with the dealership, and several
days in the shop once it was there (without a loaner vehicle). And I'm not
talking full engine rebuilds either, just simple fixes. Most of the time I
don't even bother anymore because it's such a hassle.

------
chx
This where -- literally -- the rubber hits the road and we need extreme
regulatory oversight over cybersecurity in cars. I don't like fearmongering
but can you imagine what would happen if a terrorist group got hold of an
exploit like this??

~~~
drdaeman
Does regulation actually improves _software_ security in practice?

I'm skeptical it does. I saw a few times how regulated software (certain
billing systems) were certified and that was a bad joke. Maybe you have
different experience, though.

If you want government bodies to spend taxpayers money on something, I'd
rather suggest spending it on funding security researchers actively attacking
systems and cooperating with manufacturers on fixing the discovered issues
(and you can legally mandate such cooperation). This might work, actually
improving end-user security. Although you'd have to somehow audit those
researchers are actually doing something...

~~~
speedplane
> Does regulation actually improves software security in practice?

Yes, it can. DO-178B is a widely used security standard in military equipment.
It's difficult and expensive to obtain, and caters to fighter jets, not cell
phones, but there is precedent for true technical security improvements
through government programs.

~~~
tialaramex
Hang on, is this DO-178B _different_ from the DO-178B now replaced by DO-178C
that is about _safety_ in aircraft systems? It isn't is it. So, you're talking
about _safety_ when the parent and article are specifically about _security_.

Because confusing safety and security is exactly the kind of awful goof that
we're talking about here. I'm sure these car alarms are _safe_ the problem is
they don't keep your car _secure_.

The security record of military procurements is... not good. Same for the
financial industry. Do a bad job, hope nobody finds out, if they do insist you
didn't do a bad job and hope nobody who understands the difference is
empowered to do anything about it.

Let's take something easy, communications. Your generic Android phone is
capable of doing secure voice communications over a distance subject only to
traffic analysis and other inevitabilities.

The British infantry have Bowman. At squad level it's unencrypted spread
spectrum voice radio. So, much worse than that Android phone. A sophisticated
bad guy (so, not some random bloke who decided to join ISIS last week, but
say, a Russian armoured division you've been deployed to counter) can
literally listen to everything you say, seamlessly, without giving away their
position. Brilliant.

Now regulation _can_ improve things by mandating something that people who
know what they're doing already recommend. But you're not going to get there
with things like DO-178B.

~~~
speedplane
> Hang on, is this DO-178B _different_ from the DO-178B now replaced by
> DO-178C that is about _safety_ in aircraft systems? It isn't is it. So,
> you're talking about _safety_ when the parent and article are specifically
> about _security_.

It's about both. The DO-178B/C standards require software to work as formally
specified, and require robust branch testing to ensure the code conforms to
the spec. This means different things for different applications, but in an
operating system, for example, it means that no process can affect any other
process if the two are deemed independent. This requires that the OS prevent
all covert channels, strictly limit memory, CPU performance, etc. For example,
a fork bomb wouldn't be able to affect other processes, and caches are wiped
on every context switch.

So yes, it is definitely relevant to security as well as safety (which in
military aerospace go hand-in-hand anyway).

------
jarym
So many ‘security’ companies making coding mistakes that there’s simply no
excuse for.

How are these companies remaining in business? Call yourself unhackable and
then don’t bother to even authenticate API requests... mind bogggles.

