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?

▲

crote 4 hours ago | parent | next [-]

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.

▲

ryandrake 17 minutes ago | parent | next [-]

I think expert users on HN seriously downplay the ability and willingness of "regular users" to do very stupid things on their devices. If grandma wants that app that gives her a beautiful horse as a lock screen image, she will follow every one of those six steps that the malware HorseLockScreen app developer presents to her. She will tap a button that has a skull and crossbones icon, that says "tapping this will drain your bank account and kill your dog" if she thinks it will let her do whatever she's trying to do on her device. Have you guys never done IT tech support for your elderly parents' computers?

I'm not saying it's right to respond by simply locking everything down, but let's not downplay the blast radius of basically every attack that involves telling the user to do things.

▲

2 hours ago | parent | prev | next [-]

[deleted]

▲

II2II 3 hours ago | parent | prev [-]

> In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it.

Have you ever worked with someone who barely knows how to use a mobile phone? They will hand their phone over to someone they barely even know to do something they don't understand. They will follow instructions from a stranger over the phone, without understanding what the phone is warning them about.

I have worked with such a person. They did have someone walk them through a dubious process. Thankfully they realized what was going on before the process was complete, but who knows how much damage was done by the initial steps.

There are legitimate security reasons here. Whether there are reasons beyond that is an open question.

▲

freedomben an hour ago | parent | next [-]

Following this logic, shouldn't we just ban smart phones for everyone then? If we need to dumb down all technology to the absolute lowest level, we should probably ban computers or at least require an official government-controlled license to get access to one. Is this a world you want to live in? Me neither.

▲

realusername an hour ago | parent | prev | next [-]

You are right, better locking them out of the Play Store, there's too much risk using it.

We could also imagine a 24h delay to get Play Store access

▲

oblio 19 minutes ago | parent | prev | next [-]

Those people will be conned in a million other ways.

▲

g-b-r 3 hours ago | parent | prev [-]

Can we freaking sell them dumbphones, then, and stop destroying portable computers for everyone else with that excuse?

Which incidentally is often just a pretense for other motives?

If computers have suddenly become so dangerous for normal people, and they want smartphones nonetheless, add to them a dumb-mode encouraged at the initial setup, and requiring some third party assistance to turn it off once enabled..! (and forbid apps to change their behavior if it's not enabled)

▲

mlrtime 2 hours ago | parent [-]

"Can we freaking sell them dumbphones"

Nothing is stopping the guy at Walmart or Tmobile from selling them dumbphones, or are you implying they are forced to?

	▲	RunSet an hour ago \| parent [-]
		Try letting the blame trickle down from the pyramid's apex instead of blaming the footman. Here is the first iPhone ad: https://www.youtube.com/watch?v=6Bvfs4ai5XU The ad depicts it as a mere phone instead of a potentially hostile Turing machine. There is equivalent messaging in the android ecosystem but its advertising is not so ubiquitous.

▲

franga2000 3 hours ago | parent | prev | next [-]

You haven't been able to connect to an android device on port 5555 for yeeears. Every time you enable adb/IP it generates a new random port, or you need to use the QR/PIN pairing thing. On top of needing to enable developer options, adb/IP, confirm the fingerprint.

▲

pigggg 3 hours ago | parent [-]

Millions of Superboxes and various digital picture frames say different.

https://synthient.com/blog/a-broken-system-fueling-botnets

▲

microtonal 2 hours ago | parent | next [-]

Kimwolf exploits vulnerable Android Debug Bridge (ADB) services. Many low-cost TV boxes come "pre-infected" with proxy SDKs; Kimwolf then scans these residential proxy networks and exploits the devices within minutes as it propagates.

https://www.cloudflare.com/learning/ddos/glossary/aisuru-kim...

This is like saying that SSH is insecure because some device vendors install SSH, permitting root login with a default password of 'root'.

	▲	BiteCode_dev an hour ago \| parent [-]
		Yeah let's block port 80, too many people expose unprotected api.

▲

franga2000 an hour ago | parent | prev [-]

Well yes, but those won't get Google's new updates either. Open ADB on 5555 was a problem we solved almost a decade ago and these devices are still vulnerable. Even further restricting ADB in the latest version won't do anything to prevent that.

▲

xg15 5 hours ago | parent | prev [-]

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?

▲

londons_explore 4 hours ago | parent [-]

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

▲

TeMPOraL 4 hours ago | parent | next [-]

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".

	▲	xg15 4 hours ago \| parent [-]
		> 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...

▲

xg15 4 hours ago | parent | prev [-]

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.

▲

londons_explore 4 hours ago | parent [-]

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".

▲

xg15 4 hours ago | parent [-]

Ok, that makes more sense. Hooray for stuff getting even worse...

▲

TeMPOraL 3 hours ago | parent [-]

Remote attestation itself being a questionable idea at best, so it's bad things creating a market for even worse workarounds.

	▲	xg15 3 hours ago \| parent [-]
		No objection there. Also telling that advertising and locking down devices are driven by the same companies...