Eli5: How are Zero-click exploits even possible?

341 views

Like if nobody “asks” a piece of software to execute how does it get downloaded to my phone or PC and then execute it self ? I can understand attacks e.g where you download a jpeg and then click to open it and the jpeg had some extra malicious code in it etc, but without anybody “authorizing” anything how does the kernel allow the code to be run by the cpu etc ?

**EDIT** I am talking about forced entry zero click software like the one pegasus created for iphones

In: 190

20 Answers

Anonymous 0 Comments

[removed]

Anonymous 0 Comments

They’re usually more rare exploits, sometimes as the result of situations where a trusted component has a flaw that causes it to execute data as code.

For example, in the case of a cellular modem flaw from earlier this year (CVE-2023-24033, CVE-2023-26496, CVE-2023-26497 and CVE-2023-26498), it was found that since the modem is always trusted, it could be possible to craft a exploit that forced a victim’s modem to run code on the system without any restrictions. This could allow a device to be compromised without the user even accepting a phone call.

Anonymous 0 Comments

This can only happen with a major flaw in the operating system and software running on the computer. And it’s not usually “just” a download of a nasty file that somehow runs itself. It would require a combination of a flaw in a web browser for example to both download and trigger the file to run. For example if you open a link to a Zoom meeting you will usually get a pop up that asks “do you want to use the Zoom application to open this link?” So on one hand, you have a layer of security there, on the other hand your web browser is able to send instructions to other applications, so you can imagine there is some potential for abuse if that browser doesn’t do this check properly and just passes off instructions to another program.

And you can imagine the OS itself could similarly have flaws though the details would be different. None of this can just run without your consent… if the system is working properly according to modern security standards. But sometimes systems don’t work properly according to modern security standards.

It would be quite rare to be struck by one of these vulnerabilities as these are the types of issues that get lots of attention and have security updates released to fix them ASAP.

On the other hand if you don’t keep both your OS and software up to date the chance for problems is higher…

Anonymous 0 Comments

Really depends.. windows is built to trust everything by default

1) there are built into os on purpose by us government (like wannacry)

2) they use other software updates etc.. your pc already downloads stuff all the time

3) code injection – pc reads text as part of code like acror reading *Romeo runs towards Juliet* out loud instead of acting it .. this was case of log4j

4) many more

Anonymous 0 Comments

There does need to be some attack vector, for a hypothetical jpeg attack, that might be just putting the image in a web page that you visit. When your browser tries to display that image, the image exploits a hypothetical vulnerability in the way that web browser displays images.

Anonymous 0 Comments

To add another example – your computer may be open to communicate with other computers on the network, for example for sharing files and printers. Normally this will only do what it is supposed to do – share files you chose to those who know the username & password, but if there is a bug (and there were many bugs in this component in Windows), it can be tricked into doing something completely different, including executing arbitrary code. No input from the user is necessary at all.

Normally your computer is not directly accessible from the internet, so this danger would come only from other computers on the same network. But in certain configurations it could come from the internet too.

Anonymous 0 Comments

A PDF file is probably easiest to understand here.

The specification for PDF says it can contain JavaScript code, to do stuff when you open the document.

Your email client on your phone probably opens PDF documents automatically, to save you a step from having to get an email and then open the PDF, that you’re going to do anyway.

So someone figures this out, and creates some malicious JavaScript that says ‘steal all the emails in this phone’. They then email it to you and as soon as you read the email, the ‘zero click’ happens without you having to have done anything.

Then a security person figures this method out and people implement fixes (like not running JavaScript automatically from emails) so it doesn’t happen again.

Anonymous 0 Comments

Zero click attack describes attacks on services that are usually listening without the user intervening.

Your PC might be continuously checking in the background for updates, for example – if you can somehow hijack that, the user doesn’t need to act in any way, their computer is just taken over.

Your phone has a host of things running, from obvious stuff like text messages to less obvious stuff like NFC comms that can be compromised without leaving a trace (a text message that the user needed to open or click on something within wouldn’t fall in this category).

Anonymous 0 Comments

Your browser and other systems (e.g., your OS’ networking stack) frequently have vulnerabilities (bugs defects in their logic) and they are constantly processing untrusted input from over the internet. Just visiting a website, the website sends your browser tons of data it needs to process to create the end result page you see. You’re asking about a specific type of exploit called RCE, or remote code execution.

There are many ways to get RCE, but a popular theme across many apps throughout time has always been memory bugs (type confusion, use-after-free, double-free, etc.) in software.

Imagine by visiting a website it could gain full control over your computer. How is this possible?

At its most basic, RCE is possible because computers intermingle (1) *control flow* data with (2) *data* data, and (2) is often within a user’s control or influence, even if only partially. Attackers can get very clever and insert data that programmers never intended and to subvert control flow by overwriting control flow data and thereby hijack control of the program.

Here’s an analogy. Suppose you were handed a piece of paper that read:

“`
Follow each step and then proceed to the next step, unless instructed otherwise:

1. Print “Hello, what is your name?” to the screen.
2. Listen for user input, and whatever they type, write everything down, starting at the beginning of the blank line below:
3. _____________ (space for 32 characters)
4. Take what you see on line 3, and print “Hello, <whatever is on line 3>!” to the screen.
5. Exit.
“`

You are the CPU, and you execute these instructions one by one, *precisely* as you find them.

Now what if a clever attacker gave you an input that overflowed the space available on line 3, and you, being a good follower of instructions, just kept on writing and writing, writing *over* the ink on lines 4 and 5, so that after you’re done transcribing their input to the paper, line 4 read “Delete all the files on this computer.” When you come to the next line, you will execute it as you find it.

This is grossly oversimplifying it, but the general, high level idea is it’s the intermingling of control flow data (which the CPU uses to determine what instructions to execute next) and and attacker controlled data *combined with* bugs like buffer overflows (where data overruns a buffer and overwrites other stuff nearby, like a return address on a stack, or a vtable pointer) that enable you to overwrite that control flow data.

Nowadays, the most common bugs in browsers are use-after-frees, which can be devastating if an attacker can spray the heap, eventually causing a used-after-freed vtable pointer to be followed to execute shellcode.

The most common practice is to try to mitigate bugs by making full control flow hijacking difficult to achieve through hardening techniques like:

– Stack cookies
– ASLR
– Non-executable stack / heap (more accurately, preventing a memory page from ever being both writable and executable at the same time)
– Control flow integrity
– Pointer authentication

Each of these makes bugs very hard to exploit. Even if you had a write-what-where primitive, you may not be able to subvert control flow. But attackers have gotten very clever and used all sorts of techniques to overcome each:

– Stack cookies can be overcome by memory disclosure bugs that leak stack contents
– ASLR can be overcome by memory disclosure bugs that leak addresses, as well as to an extent setting up NOP sleds and spraying the heap
– W^X pages can be bypassed by ROP (reusing pieces of code belonging to the program against it) or abusing processes where pages need to be writable and executable (such as JIT compiler processes like JavaScript)
– Pointer auth can be overcome with the use of signing gadgets in existing code (once again reusing code that already exists in the program to trick it into signing a pointer)

Anonymous 0 Comments

Lots of these attacks have been targeting the code that OSes use to read the details of things like JPEG images or video files. Decoding the contents of something like a JPEG can be very complex, especially when the code not only has to deal with correctly formatted images, but also end up with workarounds in it for reading images generated but other code that didn’t quite follow the standard exactly.

And complex code like this becomes relatively easy to attack, by passing deliberately badly formatted data to it. You find the right combination of bad data that causes the OS code to crash in such a way that it ends up running some of the data in your badly formatted image as code.

You then send this badly formatted image to someone via text/WhatsApp/email etc. When the messaging app wants to maybe show a notification, with the image of it, the OS reads the details of the image and the malicious code gets to run.

To combat this OSes (especially mobile ones) have been moving code like this into special walled off areas, so that that if someone manages to trigger a bug like this they can’t escape and run their code in a context that can cause damage.