Good analysis on the Android security ecosystem

I recently blogged about Google and Samsung starting to offer regular security patches for their Android devices.

Over on ars technica, Ron Amadeo has an interesting article describing why the current Android ecosystem is not conducive to the quick and widespread distribution of security fixes and why this needs to change, urgently.

At this point in time it seems that in order to be halfway secure, one has to basically root the phone and run well-tested and well supported distribution like CyanogenMod. While I – and presumably most, if not all, readers of this blog – certainly have the technical know how and abilities to root a phone, that’s a poor approach to security because most people either will not or cannot root their phones.

Why I’m suspicious of car insurance dongles

Some security researchers from UCSD showed a proof of concept exploit via one of the dongles that appears to be also used by car insurance companies to monitor your driving “to give you discounts for good driving”. I’m not really a fully paid up subscriber of the tin foil hat brigade but stuff like this makes me glad that I’m still opting for the old-fashioned way of paying for car insurance. Of course the fact that over half our fleet is too old to be OBD-II compliant may have some bearing on that as well…

Not knowing much about CAN bus, my assumption is that in order to get access to certain pieces of data, the dongle will have to put commands on the bus and read the responses. That part is blindingly obvious. Good security practices however would suggest that such a dongle would have a built-in mechanism that restricts the commands it can issue to the set of commands it actually needs to issue to fulfill its function rather than just allowing commands through unfiltered, especially if said dongle is connected to the outside world. I mean, with the ability to issue arbitrary commands to a pile of steel weighing a couple of tons and potentially moving at 70-80 miles per hour, what could possibly go wrong?

On the other hand, instead of having to invent one of those EMP devices as “showcased” in Fast & Furious to stop a street racer, all law enforcement has to do is to send the car an appropriate (or rather, inappropriate) text message.

If anybody needs me, I’m over on Hemmings.com looking for a Ford model A. Try texting that one to stop.

avast!’s virus scanner uses a self-issued trusted root certificate

tl;dr – avast’s web shield functionality appears to insert itself into SSL connections using a self signed trusted root certificate and a simple kind of man-in-the middle “attack” on SSL. I would recommend you turn off web shield’s https scanning or choose another virus scanner.

I read about this on a blog post that was linked from Hacker News where someone claimed that Avast’s virus scanner for Mac OS inserts itself into SSL-encrypted connections using a self-signed certificate. A quick check on a Windows machine in my household confirmed that this was also true for Windows:

Google Maps showing the Avast! certificate
Google Maps showing the Avast! certificate

I case you’re not that familiar with what the connection information is supposed to show you, you can be pretty sure that Google doesn’t have their identity verified by avast!.

As I was preparing the images for the blog post, I noticed the same behaviour on Outlook.com. Have a look at the “Issued by:” entry for the certificate information and also the encryption information in the URL box:

outlook-avast

Now compare the identity information for the “clean” connection with avast! web shield disabled to the information that was showing up in my first example showing Google Maps. This is what a real certificate is supposed to look like:

outlook-clean-1

outlook-clean-2

 

Did you notice the inscription “Microsoft Corporation [US]” next to the padlock symbol that indicates you’re on an encrypted connection? That shows Microsoft is using an EV (Extended Validation) certificate for this particular site. EV certificates are backed by a much more thorough identity verification process, not to mention that they’re considerably more expensive than a normal certificate. EV certificates are intended to give the user additional confirmation that you’re indeed talking to who you think you’re talking to and not Joe’s Phishing & Hijacking service. With avast!’s inserted security certificate, you lose this additional protection. Oh, and for additional comedy value – avast! themselves use an EV certificate on their own website. Which is commendable, only that you don’t necessarily see it if you use the software you downloaded from that website.

Now, is this a big security crisis and we all need to break out our tinfoil hats? I seriously doubt that. In fact, I believe avast! is acting in good faith with their web shield – after all, if you want to protect your users from malware downloaded over an encrypted connection to a dodgy site, the only way to do this in real-time is basically to insert yourself into the connection in the first place.

However, I personally am a bit concerned that Avast! installs a Trusted Root certificate into the Windows certificate store:

avast-certmgr

Call it “echos of SuperFish” (see Lenovo’s security advisory here, Google for the tons of spilled electrons on the Internet), but that makes me uncomfortable, especially if the machine you find it on a machine that you use for online banking.

For my part, I’ve turned the web shield https scanning functionality off for now and will probably spend some more time on this sunny afternoon researching alternative virus scanners.