Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Years ago we used to regularly have worms that’d infect millions of computers without any clicks at all.

The truth is that “Zero-Click” hacks are becoming increasingly rare.

But of course everything is new for journos unfamiliar with the field.



Yes, Chrome pretty much single-handedly changed that, timed well with Vista. For about a decade we got a reprieve because:

1. Memory safety mitigations became much more common (Vista)

2. Browsers adopted sandboxing (thanks IE/Chrome)

3. Unsandboxed browser-reachable software like Flash and Java was moved into a sandbox and behind "Click to Play" before eventually being removed entirely.

4. Auto-updates became the norm for browsers.

And that genuinely bought us about a decade. The reason things are changing is because attackers have caught back up. Browser exploitation is back. Sandboxing is amazing and drove up the cost, but it is not enough - given enough vulnerabilities any sandbox falls.

So it's not that security is getting worse, it's that security got better really really quickly, we basically faffed around for a decade more or less making small, incremental wins, and attackers figured out techniques for getting around our barriers.

If we want another big win, it's obvious. Sandboxing and memory safety have to be paired together. Anything else will be an expensive waste of time.


And now you never know when your useful browser extension is going to auto update into malware!


If a browser extension requests new permissions it will be disabled upon its update.


Not all malware requires new permissions.


> And that genuinely bought us about a decade. The reason things are changing is because attackers have caught back up. Browser exploitation is back. Sandboxing is amazing and drove up the cost, but it is not enough - given enough vulnerabilities any sandbox falls.

It’s still a completely different world. We’ve come a long way from back when Paunch was printing money with Blackhole.


I mean, for how long? Like I said, we had a long period of time without ITW exploits for browsers. That has ended. I'm sure costs are higher today than they were before, but I'm not convinced that the economic incentives won't ultimately lead to another blackhole.


I think it's different for good now. Detection is better, response is better. The exploits used in blackhole would be patched really quickly, and detected really quickly.

I think it would be detected quickly because the most likely payload dropped would be ransomware. which makes it immediately obvious to users they got owned. I don't think it would take longer than a day to discover a zero day exists in $BROWSER once a group starts a campaign using it.

All software distributors that expose attack surface to a large consumer base have all had plenty of time to learn how to deal with a major security hole that needs to be patched asap. Once a researcher tweets about a 0day in $BROWSER, there'll be an incomplete patch 1 day later. 4 days later the final patch is out. Auto updates ensure every user has the patch the moment they go online.

But I do think we can still see a CCG using a browser exploit to infect people, but I don't think we'd see exploits packaged and sold inside exploit kits.


There are definitely significant economic changes - the turnaround time for discovery, patch, rollout is way tighter.

I suppose that could make a generalized kit much harder to sell. Once it's sold once you basically have to assume it'll be burned soon.

Time will tell.


Only way we’re going to see another exploit pack like blackhole is if it’s targeting Android devices which aren’t receiving security updates.


Or there's more vertical integration in exploit packs ie: they pair it with some sort of post exploitation payload that's better at hiding. Or something else we haven't thought of.


I was about to say the same thing in response to people claiming security is getting worse. Zero-Click is just another name for a worm. I guess mayyybe you could consider Zero-Click as more like a class of worm whose entry into the system is visible (you can see that you got the strange message or image).

And you're definitely right that they are far more rare. Worms used to be nasty is now fast and easily they spread. Security has come a long way since then.

That said, we could go further on security. But is selling people on using more secure software and hardware. Even something as simple as bounds checking has a cost. Look at the reception of the Windows 11 change to have Virtualization Based Security turned on by default. People are upset about it because it takes away performance for security that they claim they don't need on their home computer.

And then there's resistance from developers. For some reason people get really upset about mechanisms designed to improve security without increasing runtime overhead when they make compile time take longer. If your application is used by any significant number of people, surely the amount of runtime you're saving dwarfs the amount of extra time to compile.


Wormable bugs are a subset of zero-click bugs. Worms are very rare, and always have been, even during "the Summer of Worms".


Even a browser driveby attack is wormable if you use various social media for spreading.

Few vaguely reliable RCE bugs aren’t wormable. Even ones requiring significant user interaction are wormable, office macros are wormable.

Workable bugs are far more common than actual worms.


I was about to ask whether I'm missing something here. "Zero Click" just means no user interaction is required right?So from my Perspektive this is just another way of saying Remote Code Execution?

There really isn't something new here other than a fancy name - or I am not seeing the point.


A non zero click remote code execution would be for example the attacker sends the victim a message, with a link or attachment, that if the victim interacts with it, the attacked gets to run code they wrote in the victims device.

A zero click remote code execution, would be for example where the attacker send a message, and their phone just processing the message on it's own is enough for the attacker to execute code on the victims device.

A non zero click vulnerability can be mitigated by being cautious. A zero click vulnerability cannot.


> A non zero click vulnerability can be mitigated by being cautious. A zero click vulnerability cannot.

No amount of caution will save you when the exploit is injected into a major website.

Why bother with such meaningless distinction? Does your browser never hit any http:// resources?


An exploit that achieves remote code execution just by a browser performing an HTTP request (for example a malicious ad) would be considered a zero-click exploit.


But then most exploits that involve sending links would also be zero-click, just not deployed in that manner.

I think this just goes to show how silly this new terminology is.


The terms are all stupid and were made up 40 years ago. Trying to tease out nuance is pointless.

You get owned without clicking hence zero click. Is it different from RCE? A subset? Doesn't matter. Title could have said RCE.


Some RCE can require user interaction.


That’s correct.


'Zero-Click' is just a new buzzword, it probably got popular due to Pegasus and NSO.


Both attacks and defenses have gotten a lot better. Meanwhile, the consequences of hacks keep going up every year. You didn't have viruses disrupting shipping or gas pipelines before, because they didn't depend as much on computers.


You have to be a special kind of naive to not have such infrastructure behind airgap.


There are a number of organizations out there who think they are airgapped. And then some employee in the basement decides he needs to run a test while he's on the road, or monitor the water treatment plant from home because he's been exposed to COVID and can't come in, so he gets his buddy to install an LTE hotspot and boom! Now the company's not airgapped any more.

It's a special kind of naive to assume that airgapping is a technological problem rather than a human behavior problem.


> You have to be a special kind of naive to not have such infrastructure behind airgap.

Most of it is not behind air gap. And unless things get a lot worse it wont be.

Proper air gaping is hard, expensive and pain in the ass, on the ongoing basis.

That's why almost none does it. Not even most military systems are air gaped.


You cannot assume "airgap" for any reason--that will eventually fail.

Systems need to work assuming that they are bathed in a hostile environment at all times.


Yup.

And yet in most organizations, airgapping is an alien concept. Even for machine tools that could kill someone.

Security vs convenience...


Airgapping didn't stop Stuxnet.


Exactly, 10 years ago tens of millions users were using outdated Flash and Internet Explorer. Literally everyone could infect them using pretty old exploits. There were no autoupdates.


Yep, good luck finding an useful exploit pack on crime forums now. The days of blackhole & co are long past, those people hacked far more people than those discussed in this article ever will.


To me there's a difference between RCE and Zero click.

RCE occurs on a system with a listening daemon/service (e.g. web, SQL, DNS SSH).

Zero-click describes an issue on a client system where usually a user would have to click something to trigger it, but doesn't as parsing/processing happens before the user actually sees anything (e.g. via an SMS on a phone).


There is no meaningful distinction between the two.

> Zero-click describes an issue on a client system where usually a user would have to click something to trigger it, but doesn't as parsing/processing happens before the user actually sees anything (e.g. via an SMS on a phone).

Historically these have been referred to as RCE.

FWIW You are essentially describing a service listening on the network. It’s silly to try to make an artificial distinction based on some irrelevant L4 differences.


That's a view of the world for sure :) Personally I don't think it's irrelevant. From a threat modelling perspective, exposed services are expected to be attacked.

Client services with zero interaction, have traditionally been regarded as safer, usually for client side attacks we'd expect a trigger from user action (e.g. a link being clicked, a PDF file being opened).

Just because you don't find something to be useful as a distinction in your line of work doesn't necessarily mean that it's not useful to anyone ...


Client services like these are also expected to be attacked.

iMessage isn’t meaningfully different from Apache, instead of listening on a TCP number it listens on your Apple user id.


This is really flyfucking of the worst kind: the kind that doesn't serve any useful purpose.

From any useful perspective, RCE and zero-click exploits are the same thing. The latter is just a fancy name for the moron journalists like the one who wrote this article to bandy about to lure in some readers.


RCE is routinely used to describe clientside bugs; you're mixing orthogonal concepts here.


errr what? Im struggling to figure out what you might mean here. Are you talking about floppy disk shared worms?



Also, don't forget https://en.wikipedia.org/wiki/Nimda ... all of these were a horror show to deal with on networks of the era..


My favourite: https://en.wikipedia.org/wiki/SQL_Slammer - 376 bytes of malware, spread via spraying UDP packets at random IP addresses, infected basically every vulnerable system on the entire internet within 10 minutes.




A sibling has already linked it, but extra context: Robert Tappen Morris (aka ‘rtm’) is a legend, his dad is a Bell Labs legend, and along with Trevor he’s kind of the “silent partner” in the Viaweb -> YC -> $$$$$ miracle.

Guy’s a boss.


I think they talk about worms that spread by infecting other devices in the local network using RCEs in net-services like rdp/smb/..

That or maybe drive-by downloads / java/activeX code execution, which have become more rare





Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: