Android vulnerability allows attackers to modify apps | Hacker News Reader

Android vulnerability allows attackers to modify apps

guardsquare.com

115 pointsWinandVM65 comments

Out of all the Android vulnerabilities so far, and out of all the devices that are not running an up-to-date versions of Android, what's your theory as to why we have yet to discover a large Android botnet?

Ironically this is the one thing that the Android ecosystem fragmentation has going for it. My guess is that no one can be bothered to make reliable exploits that have all the correct offsets and addresses for who knows how many different kernels and firmwares and such.

You'd think the Broadcom wifi bug would be an extremely lucrative worm target, but in reality it takes a great deal of effort to make a reliable exploit targeting a single version of a single device.

Until there's a more basic bug that doesn't involve kernel addresses and exact memory layouts etc it's far more profitable for bad actors to deliver their malware via malicious .APK files that users will happily install.

A few reasons (imho):

* No one has really tried.

* Google will remove malicious apps from devices via Play Store if they spread too wide.

* A phone botnet would be pretty lame for ddos, which is what botnets seem to be all about these days. Their connections are unreliable, and utilizing the botnet for more than a few hours would kill it's batteries.

Phone exploits seem to be more about harvesting personal data[1], ransomware[2], and/or adware[3].

1. http://www.zdnet.com/article/this-bank-data-stealing-android...

2. http://www.zdnet.com/article/this-nasty-new-android-ransomwa...

3. http://www.bbc.com/news/technology-31129797

What are some other things botnets could be used for?

Stealing CPU cycles for mining, password cracking, captcha solving, etc?

Don't forget spam!

what's the one thing phones have tons of that desktops don't?

sensors. lots and lots of them, and many of them don't require an explicit permission to access.

if you pay the developers of a few nigh-ubiquitous mobile app dev libraries to let you phone home sensor data while their apps are on, you can probably get some really interesting novel information, and you might be able to find somebody willing to buy a dataset constructed from sensors on 50% of all smartphones.

Ad fraud. Mobile video gives high CPMs.

Many phones are connected to reliable WiFi for a significant percentage of the day.

Using a phone for ddosing when it's charging and connected to wifi could be feasible, though, given a large enough infection rate.

True, but a better use of the phone would be to exploit the consumer router hosting the wifi and/or other IoT on the subnet and ddos with that.

It's an interesting idea. Considering phones connect to multiple wifi networks (work, home, market, coffee shop) having a set of exploits to further infect vulnerable APs would be an interesting idea.

Every day I pass by a couple dozen open wifi networks.

For all of the publicity about vulnerabilities, I don't remember any that are really that useful for compromising large numbers of devices. Many, including this one, require something like installing a random app from the web, which most users likely have disabled. Some require being physically close to the device. Some, like Stagefright, are easily blocked at the carrier level.

I can't remember any that were like some of the Windows vulnerabilities of the bad old days, of fully owning the device just from it being on the network. The OS is a lot more locked down too, no install of non-store apps by default, and heavy restrictions on app permissions.

Probably also helps that since they're phones, anything doing the usual botnet activities would result in rapid battery death and the user getting their phone fixed or replaced.

Stagefright is one,so is the broadcom SoC exploits project zero published

Because Android is more secure then you've been led to believe. Google does a decent job of continually hardening the OS and ecosystem and of detecting and counteracting the spread of malware.

But most people don't get access to that work, because their phones don't get updated.

No, most people get access to this work, despite their phones not getting updated. They get this via access to the Google Play Store.

If an Android device has access to the store, Google can check and remove malware from the device. Incidentally, these checks are how Google has a pretty comprehensive view of active vulnerabilities and in devices as well as active exploits being used.

The result is if a user does not enable unknown sources and only installs apps from the Play Store (the default and by far the most common configuration) they have a vanishingly small chance of being infected by malware.

Google has done a ton on work extracting chunks of the OS and moving it into OTA updatable components. Google has also done tons of work on making the core OS easier for OEMs to update.

They've done some work on some parts. There are still large chunks of the OS that can't do that. And the core OS was never that difficult to update, it's more that the OEMs had no incentive, and still have no incentive, to do so.

It has nothing to do with the OS being easier to update, rather Google not wanting to force OEMs to do so.

Expect the same rate of updates with Treble certified devices.

Although the Android ecosystem is probably the biggest OS deployment on devices right now, Google has done a pretty impressive job maintaining its overall safety. The primary mechanism they use is what they call GMS (Google Mobile Services), built on top of AOSP.

GMS includes the Google Play Store, which they reported this year had 2B monthly active users. The most notable AOSP derivatives that do not run GMS are Amazon's Fire OS and whatever Chinese companies are doing. Whenever you see somebody trying to implement "Android without Google", they are (misguidedly) replacing GMS.

Anyway, GMS on the device auto-updates and works with cloud services to detect and act on malware the user may have installed. This year Google branded this "Google Play Protect". Because GMS doesn't require firmware, kernel, or platform updates to work, Google is able to police the ecosystem effectively.

Also, because all apps are signed by the developer and Google controls the Play Store, its also able to work with developer community to mitigate libraries / sdks that are harmful. The overall end result is harmful apps are only on 0.05% of devices that only install apps from the Play Store (the most common scenario, and the default).

All those problems and I sit here with my Moto and the last patch from February...

Good my guarantee runs out soon so I can switch to something I can patch myself.

I'm in a similar situation, I got a One Plus Onyx since I heard so much about how One Plus supports and updates their products and I haven't had an update in over a year.

It's probably time to install LineageOS...

On the other hand OP3 and OP3T have pretty impressive (for me) track record and are now on 8.0 with September security (I think). And out of the box 3T had 6.X something. OP is not a perfect company, not even close, but ok I suppose overall.

Don't they also have all kinds of backdoors setup on those phones?

There was a report they log when you open apps, close apps, change state, etc. But as far as I know no backdoors have been found that are specific to OnePlus (and not bugs in Android)

Just one, and it takes physical access with USB debugging enabled. Still would never use their OxygenOS over LineageOS.

Yes and no.

a) they were collecting excessive telemetry for a long time, after this was exposed they claimed it was config error or something and patched it and additionally allow to disable telemetry in settings fully or partially I think. Though no malicious intent was ever proved it was not a good thing.

b) people found app with soft root like capabilities. Eventually it was discovered that it was a debug Qualcomm app left intentionally (and present in phones of other brands) and soft root possible only if attacked has physical access phone must have ADB installed (never used it so I have no additional details).

I think there was no other incidents in 2017. Overall it was not good but compared to what can be extracted from Google (and that stuff can't be disabled and present in every Android phone) or other apps that many users install (FB, messengers etc.) it is just drop in the ocean. Not a secure phone but neither are any other mass market phones including Apple (who had degraded their security to a simple pincode - https://blog.elcomsoft.com/2017/11/ios-11-horror-story-the-r... ).

Why not getting an iPhone and let Apple patch it for you? It's just a phone, not your child, you don't have to take care of it...

I don't like the closed culture and the prices they put up for their hardware are far beyond justified in my opinion.

Also, didn't they also had trouble recently?

From the top of my head:

- Calculator bullshit.

- Wifi not really disabled.

- UX hell in iphone X.

Only from the last 2-3 months.

Calculator bullshit is due to the animation of the button, and it will only show if you're really fast trying to calculate things. There are better third party calculator apps that don't have that problem and contain more features.

The wifi part, I did notice it. But, I think it's by design. When you're connected to wifi, click the wifi button on control center just disconnects your current wifi session. I've actually kinda grown to use that feature. I don't like hooking to xfinity hotspots much, so I click that away. When I get back home, phone automatically hooks back up to my wifi.

UX hell in iphone X... don't get iphone X. Or any OLED screens with burn-in issues.

If you go into settings and turn Wifi off it is completely off. Turning it off from control centre is a useful alternative where it disconnects, but leaves it available for geolocation and airdrop - it's really rather useful.

This sounds terrible. Why not having it op-in? I'd expect that I'll need to go to settings and add it to the functionality of the control center button.

I suspect because Apple found out that people were primarily using the Control Centre switch for 'This WiFi network sucks get me off it' reasons, rather than 'Disable all Wifi circuitry reasons', so optimised functionality for the use that users were using it for.

> I sit here with my Moto and the last patch from February...

> I don't like the closed culture

What good is an "open" culture if you can't patch things yourself anyway?

You should have read on ;)

I'll put LineageOS on it as soon as the guarantee runs out.

Edit: I'm not sure myself why @guarantee. Maybe something else breaks...but actually it's just a habit I guess.

(sorry for the answer here but I can't answer directly to your comment. Too deep down...)

Why do wait so long?

(Serious question. What use is the guarantee if your device is hacked? Will they pay indemnity if that happens during guarantee?)

Google Pixel is (mostly) open, receives timely updates, and you can also flash images yourself if you'd like. You don't have to get an iPhone.

Some Moto's allow you to unlock the bootloader through their official page.

My X 2015 had significant performance issues and Bluetooth would randomly stop working. They didn't upgrade from Marshmallow 6.0.0 to Nougat (7.0.0, not even 7.1) until last month.

I bought an iPhone X. I love Android but most manufacturers don't seem to care about the product after you've purchased it.

Consider getting a Pixel. Guaranteed timely security updates for 3 years, and you can flash your own images if you'd like.

I ended up buying used HP Elite x3 (Win10 Mobile) because of that. Even though MS dropped feature updates for Win10 Mobile, they promised security updates until 2020 if I'm not mistaken.

HP will update their phones into 2019. But yeah, the direct-from-Microsoft security updates basically make an Elite x3 a no-brainer for someone who wants a secure phone at this point. Apps are limited, but apps are usually a risk anyways, the ones you actually need are all there.

I'm slightly bummed by the lack of YouTube (hello again, Google), and Lyft.

FWIW, I consider being shoved away from Google products a bonus of the Windows Mobile platform at this juncture. ;) It encouraged me to finish transitioning away from their services.

YouTube is "good enough" in the browser, but I prefer to not watch videos on a phone anyways, and usually save them for later.

€ 799.00, more than a month salary for many people that I know.

Multiple month salaries in many 2nd and 3rd tier countries around the world.

Security as a privilege only for the rich people is not a solution.

You're right. The Nexus phones that Google used to sell were relatively affordable and secure (like the Nexus 5X). Too bad that's no longer an option.

>and you can flash your own images if you'd like

Just an FYI for anyone interested in getting it. You can do this only if you buy directly from Google, not from Verizon. Only Google's version has an unlockable bootloader. Google sold out pretty hard to Verizon in order to get some sales. One of the nice things about the Nexus line (at least all the later ones) was that you get a good no-bullshit phone no matter where you buy it from. Now, with Pixel, you get the shitty one if you buy from Verizon. The major downside to this is the used market. No way to reliably buy a good phone on ebay etc. The model numbers are the same. Some respite is swappa, which lists them accurately.

> The major downside to this is the used market.

Yeah Google I believe unintentionally really messed up the used market for people that want to flash. You can tell the difference by installing an app or going under developer options from what I have gathered https://android.stackexchange.com/questions/163706#181321

And after 3 years?

(I'm using a Nexus 4)

You did not specify the exact model. Have you checked whether there is a LineageOs Rom for your device?

https://download.lineageos.org/

There is. When I wrote the post above I thought I might wait until the guarantee did run out but I'm preparing the switch right now :)

This seems noteworthy:

> Any scenario still requires the user to install the malicious update from a source outside the Google Play store.

Agreed. Also this "The ... vulnerability affects ... Android 5.0 and newer... Applications that have been signed with APK signature scheme v2 and that are running on devices supporting the latest signature scheme (Android 7.0 and newer) are protected against the vulnerability."

From a user's standpoint, the impression I'm getting is this:

"A user might download a malicious update to an existing application from someplace other than Google Play, and Android will incorrectly tell the user that the application is valid."

Is this correct? Then they should say so in this article, perhaps in the introduction. As a user I can look at the details later if I'm interested, but for now I need to know what (not) to do to stay safe.

Again, beating the drum that security news needs to improve its messaging.

I believe your understanding is correct. And if you have security patch level of 2017-12-01 or newer, you are safe from this vulnerability.

I agree that the article needs a TLDR at the top.

https://source.android.com/security/bulletin/2017-12-01

"And if you have security patch level of 2017-12-01 or newer, you are safe from this vulnerability."

So, not most people.

> The JAR signature scheme only takes into account the zip entries. It ignores any extra bytes when computing or verifying the application's signature.

Why? is there a use-case for this?

Because that's how `jarsigner` (the Java application) signs. The code signature was fixed in Android 7.0.

Does it mean the vuln only affects devices running < 7.0?

The vuln affects all APKs on 5.0 <= Android < 7.0, and APKs not signed with APK Signature Scheme v2 on Android 7.0 and newer.

Jarsigner is designed to be used by Java.

And both Jarsigner, and the Java command used to actually run the code on Oracle Java and OpenJDK use the same code – so they both only see the zip entries.

This issue only exists because Android reused a signing process designed for an entirely different execution environment.

Apk are usually signed using v1 an v2 signatures for backwards compatibility. Ripping out v2 signature would keep v1 signature valid. I hope Android 7 doesn't allow signing scheme downgrades if previously installed version was signed with v2 signature.

UPD Documentation states it does.

Ripping out v2 signatures makes the APK invalid on Android 7.0 and newer. This is because the v1 signature contains a special header X-Android-APK-Signed in its META-INF/*.SF files. When Android 7.0 or newer encounters this header without having encountered a valid v2 signature, it rejects the APK.

Installing a v1-only signed update to an APK which is v2 signed is permitted. However, the update has to be the same versionCode or higher to be accepted, meaning it can't be a downgrade in terms of versionCode. Thus, as long as you don't produce updates/upgrades which are v1-only signed, you should be protected against this vulnerability on Android 7.0 and newer.

Reply on news.ycombinator.com