Hacker News Reader

Comment by spicyjpeg | Hacker News Reader

The article does not make it particularly clear, but the malware in question is delivered through official first-party OTA updates on cheap Chinese aftermarket head units that happen to run Android. It cannot self-propagate to any Android-based head unit, nor does it affect Android Auto which is a "dumb" screen mirroring protocol with the bulk of the software running on the connected phone rather than the head unit. This seems to be a very similar situation to that of cheap generic Android TV streaming boxes, which often come pre-infected from the factory with residential proxies and other malware as well; most of the infrastructure is likely shared.

View on HN

Why do they gloss right over how this was distributed? Barring details of any other kind of exploit we would have to assume the vendor's update server was compromised? If so why don't they just say so.

Cheap Android phones and tables often have built-in advertisement from manufacturer. One example of such software, it creates a window with Google Ads on top of browser window. The window is shown only when the browser is active to make it look like the ads is a part of the site. The ads appears only couple weeks after activation so that the user thinks it is a result of installation of some app and Youtube reviewers do not notice existence of malware. The adware consults a remote config which defines in what countries it should work. Another adware component automatically downloads and re-installs it if it is deleted.

I found all these details through examining the official firmware image and reverse engineering.

I don't remember if I reported Google Ads id to Google. It is interesting that Google doesn't notice and care about such use of their products.

> we would have to assume the vendor's update server was compromised

You say "compromised". I say "monetised".

:sigh:

To avoid charges of libel.

In America its not libel if it's true

I see nothing at a glance about the author (Dmitry Kalinin) being American, so I can't imagine that is relevant.

there is the problem. We don't know what country is in question. There are some countries where the truth is not a defense against libel. Thus, depending on where the author is from, or for that matter the publisher or other people who might happen to be in the chain, there could be a libel case if the truth was stated.

> There are some countries where the truth is not a defense against libel

Germany, for example. Utterly bizarre and baffling that a democracy protects its politicians this way. /s

It's important for people to be able to critize elected officials.

Indeed this is an odd disclosure and I am not familiar with past posts by them.

Moreover, no CVE is associated with this claimed vulnerability. It's not even stated which Android version or automotive head-unit variant version is affected.

https://en.wikipedia.org/wiki/Kaspersky_and_the_Russian_gove...

Oh, I see I'm getting downvoted by the Russian bots, quelle surprise.

This makes me think whether the whole chain is an intelligence side business — sell cheap electronics for profit and at the same time own them too.

> nor does it affect Android Auto which is a "dumb" screen mirroring protocol with the bulk of the software running on the connected phone rather than the head unit

Huh, how does that work anyway? And while we're at it, Apple CarPlay as well? Both can run wirelessly via Bluetooth, but BT is nowhere near capable enough to stream full bandwidth video?

Wireless AA and CarPlay use a hotspot your car emits that your phone connects to and transfers the image/inputs/audio that way

Got into a weird situation recently where my cheap android head unit was displaying Car Play from my phone, but (Google Maps) audio from my partner's.

Directions weren't coming from my phone's speaker or the car, but testing audio in the Maps app did (from the car).

Still not sure what combination of connections it had managed to get itself into!

Wireless CarPlay uses Bluetooth to exchange SSID and key info before switching over to WiFi for the duration of the session.

Wow that's cursed, never realized that's how it worked.

Cursed is exactly how I would describe it - because it works great until it doesn’t and it of course gives you zero clue why it won’t connect.

Anecdotally, I just got back from a holiday trip across Europe and crossed four international borders. At every single border crossing, my CarPlay session disconnected, and I had to toggle CarPlay off and back on in my phone settings to reconnect. Very strange, and I still have no idea what caused it.

It's a good idea actually, but it's also really complex to get right.

Early version of Android Auto could transfer over USB 2.0 instead of Bluetooth, which works, but it's not near as high bandwidth.

> Early version of Android Auto could transfer over USB 2.0 instead of Bluetooth, which works, but it's not near as high bandwidth.

This sentence doesn't make much sense - Auto (and CarPlay) still work in wired mode over USB 2.0 if the head unit supports it. They never worked over Bluetooth.

(And they use less than 15Mbps so USB 2.0s 480MBps are more than enough)

They use Bluetooth to configure WiFi. Most people call that Bluetooth, but technically you are correct.

They actually run over WiFi (WiFi direct IIRC) - Bluetooth is mostly just used as a setup handshake and to help the head unit decide which phone in the car should be the one connected.

The way I understand it, the connection is negotiated via BT, but then wifi is used for the fat data pipe to run the display.

I thought the latest Bluetooth protocols were basically designed to hand off to an ad-hoc Wi-Fi connection between the two devices after the initial handshake. (Might be an oversimplification of the real protocol)

They didn't run over BT. BT is used to initiate communication and share the password to a wifi-network. It then uses that Wi-Fi network for most communication, keeping the BT channel strictly for telephony.

It uses Bluetooth to stream audio, but everything else happens through a WiFi connection exposed by the car that the phone automatically pairs with after the Bluetooth handshake.

Not sure about CarPlay, but Android Auto connects via wifi to the head unit for the video feed.

Not sure about carplay, but Android Auto wireless uses wifi for the video stream.

My car requires wired connectivity (USB) for Android Auto.

For a decent amount of the older android / CarPlay usb implementations - you can also buy little WiFi / USB dongles that perfectly enable wireless CarPlay - I’ve used them now on a few vehicles and they have been perfect !

Interesting how there is possibly a new category of residential proxy malware “automotive proxy malware”

This is just another mobile device. It even has a SIM card.

It cannot self-propagate to any Android-based head unit

Remember that not that long ago viruses spread through floppy disks.

Today, people share USB sticks full of music from one car to another all the time. They also bring their music from their home car to a rental car and back.

I’ve never met anyone irl who used USB sticks full of music. I know the capability is there in most cars, just never seen it. It seems like Bluetooth capability and Spotify/Apple Music landed in mainstream cars too soon after “play MP3s from USB” was added, for that to catch on.

I did it for a few years, back when I had a new car with the capability but not a phone with a good mobile data plan.

It had the benefit of an information center with physical buttons too, so I could navigate around my library without touch screen madness or voice commands constantly failing to understand band and song names.

> I’ve never met anyone irl who used USB sticks full of music.

I've been doing it for years, since it's so much more convenient than the alternatives: plug the stick into my car and I have my whole music library there and it Just Works.

We haven't met yet.

We use an USB key full of audio books: Harry Potter saga and The Quest of Ewilan among others. The whole family is hooked.

The car UI is much more reliable (no phone to unlock by the copilot, no Bluetooth disconnect). The phone battery is spared for navigation purposes.

I have 256GB of FLAC in my car, and it's great.

My hand is raised. I like having 8GB of music on an old (USB2 is fine) flash drive in my car as a fallback. On longer trips I'll hookup the Android Auto, but if I don't need maps and it's a quick ride, shuffle & repeat all enabled on the USB source.

Sure beats the radio, which plays 2 songs and then 5 min of commercials/sweepers, and has the gall to run ads on the HD text transmission on FM designed for song information.

Most people just bring their phone between cars for music.

My phone is much clunkier to use for this than a USB stick. Plus my phone can't store my whole music library (because there's too much other stuff already on it), whereas a single USB stick does it easily with plenty of room to spare.

Phones can access the whole internet. A USB stick can't stream Spotify or connect to the cloud.

Which doesn't matter to me since the music I'm talking about is music I already have on the USB stick (because it's music I've collected over years and years of buying CDs, mostly before ways of streaming music over the Internet even existed), and I mostly want to listen to that. If I want something else, I can just use XM radio.

You'll be surprised, but some places where a car can go have no phone connectivity.

> It cannot self-propagate to any Android-based head unit

Article does not say that.

Headline really quite clearly implies it, though. I think the correction is apt.

Bottom line is that lots of HN commenters here, as is our wont, will see this as a platform bug with a hated rival and not a bad third party integration that introduced vulnerabilities.

Like, if it was a Linux-based edge system from some fly-by-night contractor, would you be OK with a headline like "Malware infects Debian based refrigerators"? What'd Debian do?

It’s no different than how the old Ford Sync or something else could have been compromised.

The two big things here in my mind are:

1. Android Automotive has gotten very popular since it provides so much and writing your own OS is very very hard and expensive as so many car makers found out

2. Aftermarket head units often use it (see #1) so it’s likely far easier to get out there than if you had to compromise Ford/VW/Volvo/whoever

This is not Android Auto though, which is an entirely different product suite designed to connect a OEM infotainment system to an Android device owned by the vehicle operator. That protocol is proprietary, Google-owned and managed, not part of AOSP, and not available to the integrator of the software in question.

The actually vulnerable system is a custom vehicle head unit that merely happens to be running a software stack based on AOSP. It's not even "Android" in a product marketing sense.

Again, it's like blaming Debian because some loon stuffed it in a wifi NAS or whatever and put a backdoor into their UI. It's insane.

Do you mean Android Automotive?

So? spicyjpeg is pointing out what is true, not just regurgitating TFA.

Reply on news.ycombinator.com