Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android may soon restrict on-device ADB

kitsumed.github.io

Post reply on HN
Print view View original

111–120 of 536 posts

Re: Android may soon restrict on-device ADB

#111

Post by londons_explore »

xg15 wrote: post #75
pigggg wrote: post #40

Earlier quoted context omitted.

Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?

Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying... But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?

Yes, but users are told to allow it if they want to get free coins etc.

Re: Android may soon restrict on-device ADB

#112

Post by microtonal »

izacus wrote: post #73
roer wrote: post #61

Earlier quoted context omitted.

The original issue is proposing letting the user assign the debug service to a specific interface, one of which would presumably be loopback. This article is about the proposal from a developer that it should only ever be assigned to wlan0, which would break a lot of apps. Letting applications bypass permissions with this feature is the exact usecase they don't want to lose. If anything, I don't see them being agains…

It would break exactly 0 apps because none of the apps should be using this API to access your private data and phone call audio.

So why do Google Play Services, etc. have full privileged access to a phone, including private data and phone call audio, but the user doesn't?

It is tech feudalism - you don't own anything anymore, you just get to live on the digital land of a bunch of ~trillion dollar companies.

At least, that is the goal.

IMO either everyone gets access at the user's discretion or Google has to sandbox their own GMS services as well.

Re: Android may soon restrict on-device ADB

#114

Post by xg15 »

londons_explore wrote: post #111
xg15 wrote: post #75

Earlier quoted context omitted.

Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying... But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?

Yes, but users are told to allow it if they want to get free coins etc.

Told by whom though? If it's through proxyware, then there are three parties who mostly don't know each other:

- the app embedding the proxyware SDK for money

- the proxy operators

- the attackers/botnets using the proxy to access ADB.

The botnet has no access to the app, so it can't show any messages.

The app can show messages, but probably has no connection to the botnet. (I hope)

The proxy operators could show a message by abusing the SDK even more, but that would mean they actively colluded with the botnet. Is that likely? Then they could just give the botnet direct access to the app, no need to do the whole proxy thing.

Re: Android may soon restrict on-device ADB

#115

Post by dns_snek »

vrighter wrote: post #88
izacus wrote: post #67

Earlier quoted context omitted.

"An app can bypass OS security system with certain setting enabled" absolutely fits into CVEs. There's no "depends: on it. I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.

a lot of cves are of the type "if you leave the keys in the door, then anyone can unlock it and get in! We must destroy all doors, they are insecure!" This is one of them

This is not one of them. This is "the lock accepts any key" type of CVE.

> In adbd_tls_verify_cert of auth.cpp, there is a possible bypass of wireless ADB mutual authentication due to a logic error in the code. This could lead to remote (proximal/adjacent) code execution as the shell user with no additional execution privileges needed.

Patch: https://android.googlesource.com/platform/packages/modules/a...

Docs:

> EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported.

The original code cast the integer return value to boolean, and -1 and -2 cast to "true", therefore authentication would succeed if the key types were different or the operation wasn't supported.

Re: Android may soon restrict on-device ADB

#116

Post by TeMPOraL »

londons_explore wrote: post #111
xg15 wrote: post #75

Earlier quoted context omitted.

Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying... But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?

Yes, but users are told to allow it if they want to get free coins etc.

You can't fully protect people from the risk of taking bad advice from malicious strangers.

Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".

Re: Android may soon restrict on-device ADB

#117

Post by xg15 »

TeMPOraL wrote: post #116
londons_explore wrote: post #111

Earlier quoted context omitted.

Yes, but users are told to allow it if they want to get free coins etc.

You can't fully protect people from the risk of taking bad advice from malicious strangers. Not the least because most of our industry relies on it to make money. Marketing and advertising themselves are institutionalized forms of "do this thing that's actually harmful to you to get free coins / be safe / get laid".

> Not the least because most of our industry relies on it to make money.

I mean, this seems more like one of the root causes for a lot of bad things in the industry me...

Re: Android may soon restrict on-device ADB

#118

Post by londons_explore »

xg15 wrote: post #114
londons_explore wrote: post #111

Earlier quoted context omitted.

Yes, but users are told to allow it if they want to get free coins etc.

Told by whom though? If it's through proxyware, then there are three parties who mostly don't know each other: - the app embedding the proxyware SDK for money - the proxy operators - the attackers/botnets using the proxy to access ADB. The botnet has no access to the app, so it can't show any messages. The app can show messages, but probably has no connection to the botnet. (I hope) The proxy operators could show a m…

It isn't being done behind-the-back of proxy operators.

It's one more revenue stream to be able to remote control real android phones to pass device attestation checks etc.

It's marketed to users with phrases like "earn money from your phone whilst you sleep".

Re: Android may soon restrict on-device ADB

#119

Post by crote »

pigggg wrote: post #40
microtonal wrote: post #30

I am generally in favor of security improvements, but I do not really see much of a benefit here. This attack vector requires both that the user enabled developer settings and that they have remote adb enabled. So, this does not seem to be a realistic attack vector for 99.9% of the users and most of the other 0.1% probably know what they are doing. The other proposed change (to restrict access to certain interfaces o…

Isn't this because of the kimwolf (and now 6+ other botnets) that are taking advantage of people running residential proxyware unknowingly on the device which permits outbound connections to 127.0.0.1 on tcp/5555 to auth in and exec wgets or drops a loader that grabs the ddos malware APKs and install it?

It seems to require the user to:

1. Enable Developer Mode by going to an obscure settings page and tapping the build number seven times

2. Enable USB ADB debugging in the Developer Options

3. Establish an actual USB ADB session

4. Enable TCP/IP ADB debugging in the Developer Options

5. Unknowingly download a malware app from the official Play Store

6. Blindly click "Yes" on the permission prompt.

In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. And it only works if the Play Store is useless at preventing malware in the first place - but I thought their excellent app scanning was the entire reasoning behind all-but-banning 3rd-party app stores and sideloading???

It is "for safety" in the same sense that governments banning all encryption is to "protect the children" or to "prevent terrorism": flawed justification invented to distract from the real reason they want it.

Re: Android may soon restrict on-device ADB

#120

Post by microtonal »

izacus wrote: post #44
microtonal wrote: post #35

Earlier quoted context omitted.

Many alternative AOSP-based systems work fine today and do not have the new Android Developer Verifier (wow, already rolled out to 500M+ devices [1], though still dormant). To be honest, it is quite scary that Google is able to remotely roll out an app like that to all GMS Android phones. Of course, we all knew that, but it highlights again that Google can remotely take away functionality that you had before, brick y…

Wait till you hear that your OEM can remotely rollout full OS updates with full access to all your data and drivers... carrying Google software and most of it Google code.

Snarks do not lead to productive discussions. You also know that there is has always been an implicit social contract between users and vendors. The vendor rolls out updates as part of the service attached to the device (typically included in the purchase price) and that the vendor does not abuse the update mechanism to make things worse for the user.

If vendors use updates to restrict functionality that the user had before, puts existing features behind paywalls, etc. people are rightfully outraged, because it breaks the social contract.

It's just that the repeated offenses have made us insensitive. Imagine Debian rolling out some mechanism that only allows you to install software outside their repos with a 24 hour delay. It would destroy Debian.

Post reply on HN