Google Says NSO Pegasus Zero-Click 'Most Technically Sophisticated Exploit Ever Seen' (securityweek.com) 106
wiredmikey shares a report from SecurityWeek: Security researchers at Google's Project Zero have picked apart one of the most notorious in-the-wild iPhone exploits and found a never-before-seen hacking roadmap that included a PDF file pretending to be a GIF image with a custom-coded virtual CPU built out of boolean pixel operations. If that makes you scratch your head, that was exactly the reaction from Google's premier security research team after disassembling the so-called FORCEDENTRY iMessage zero-click exploit used to plant NSO Group's Pegasus surveillance tool on iPhones.
"We assess this to be one of the most technically sophisticated exploits we've ever seen," Google's Ian Beer and Samuel Grob wrote in a technical deep-dive into the remote code execution exploit that was captured during an in-the-wild attack on an activist in Saudi Arabia. In its breakdown, Project Zero said the exploit effectively created "a weapon against which there is no defense," noting that zero-click exploits work silently in the background and does not even require the target to click on a link or surf to a malicious website. "Short of not using a device, there is no way to prevent exploitation by a zero-click exploit," the research team said.
The researchers confirmed the initial entry point for Pegasus was Apple's proprietary iMessage that ships by default on iPhones, iPads and macOS devices. By targeting iMessage, the NSO Group hackers needed only a phone number of an AppleID username to take aim and fire eavesdropping implants. Because iMessage has native support for GIF images (especially those that loop endlessly), Project Zero's researchers found that this expanded the attack surface and ended up being abused in an exploit cocktail that targeted a security defect in Apple's CoreGraphics PDF parser. Within Apple's CoreGraphics PDF parser, the NSO exploit writers abused Apple's implementation of the open-source JBIG2, a domain specific image codec designed to compress images where pixels can only be black or white. Describing the exploit as "pretty terrifying," Google said the NSO Group hackers effectively booby-trapped a PDF file, masquerading as a GIF image, with an encoded virtual CPU to start and run the exploit. Apple patched the exploit in September and filed a lawsuit seeking to hold NSO Group accountable.
"We assess this to be one of the most technically sophisticated exploits we've ever seen," Google's Ian Beer and Samuel Grob wrote in a technical deep-dive into the remote code execution exploit that was captured during an in-the-wild attack on an activist in Saudi Arabia. In its breakdown, Project Zero said the exploit effectively created "a weapon against which there is no defense," noting that zero-click exploits work silently in the background and does not even require the target to click on a link or surf to a malicious website. "Short of not using a device, there is no way to prevent exploitation by a zero-click exploit," the research team said.
The researchers confirmed the initial entry point for Pegasus was Apple's proprietary iMessage that ships by default on iPhones, iPads and macOS devices. By targeting iMessage, the NSO Group hackers needed only a phone number of an AppleID username to take aim and fire eavesdropping implants. Because iMessage has native support for GIF images (especially those that loop endlessly), Project Zero's researchers found that this expanded the attack surface and ended up being abused in an exploit cocktail that targeted a security defect in Apple's CoreGraphics PDF parser. Within Apple's CoreGraphics PDF parser, the NSO exploit writers abused Apple's implementation of the open-source JBIG2, a domain specific image codec designed to compress images where pixels can only be black or white. Describing the exploit as "pretty terrifying," Google said the NSO Group hackers effectively booby-trapped a PDF file, masquerading as a GIF image, with an encoded virtual CPU to start and run the exploit. Apple patched the exploit in September and filed a lawsuit seeking to hold NSO Group accountable.
Scary Stuff (Score:1)
Is this state actor level or just real good bad guys?
Re: (Score:3, Informative)
Is this state actor level or just real good bad guys?
Yes.
Re:Scary Stuff (Score:4, Interesting)
Is this state actor level or just real good bad guys?
At this point it's hard to tell the difference. I'm not even sure it matters.
A "virtual CPU built from custom-coded boolean pixel operations"
Damn. That's some impressive shit. It's brilliant, really.
Re: Scary Stuff (Score:2)
Probably best to just avoid iPhones if you're a high profile target for a state actor:
Android CVEs for code execution, all time:
https://www.cvedetails.com/vul... [cvedetails.com]
Total: 674
(Note: Most of these vulnerabilities only apply to one or possibly a few models of Android phones.)
Chrome CVEs for code execution, all time:
https://www.cvedetails.com/vul... [cvedetails.com]
Total: 116
iOS CVEs for code execution, all time:
https://www.cvedetails.com/vul... [cvedetails.com]
Total: 1158
(Note: Applicable to ALL iOS devices)
Safari CVEs for code execution, all tim
Re: (Score:1)
So the actor sends a msg to an iMessage recipient - after figuring out a target iMessage address (phone number?).
That msg is the virtual machine as a PDF disguised as a GIF?
Then, the device invokes the virtual machine via (posting) that "GIF" thru the iMessage app, and eavesdropping starts w/o any other action?
Re: (Score:2)
Yet, something has to invoke it, right?
As per the article, just receiving it is enough to trigger it.
So yes, technically, something has to "invoke it", and in this case it's the OS that's "invoking" it just by being there to receive it. You don't have to do anything except have the phone (or other device) turned on and able to receive an email or a text.
Like I said, it's brilliantly evil.
Re:Scary Stuff (Score:4, Insightful)
State level pretending not to be. Look into the background of their founders, all former members of unit 8200 (Israeli signals intelligence).
Re: (Score:2, Informative)
In Israel, everyone is former military. So having that background doesn't imply anything.
Re: (Score:2)
Re: (Score:3)
I think its time that we made the buying, selling, trading or abusing of exploits a crime. This kind of spyware should be outright illegal (and no the argument that its being used to catch kiddie fiddlers, terrorists and other really nasty people doesn't justify it)
Re: Scary Stuff (Score:2)
I doubt anybody would do that for several reasons:
- Bug bounty programs, which basically work as a legal alternative to selling exploits on the dark web, would possibly go away, meaning white hat independent security researchers won't bother
- Black hat hackers typically already don't care what the law says anyways, and in many cases have no moral qualms about who they sell it to or what they use it for
- Government spy agencies really want these exploits, so unless legislators are willing to put an exclusion
Re: (Score:1)
You are mistaken, I think. They are weapons manufacturers/sellers. They don't hack phones directly. They sell (hacking) weapons to governments. (Not all, but the ones that the company and the government decides they can export weapons to.) The controversy is because some of those countries, like Saudi Arabia, should not have those weapons.
But they don't hack people's devices, so you can't prosecute them for that.
Re: (Score:2)
Exactly like gun manufacturers
Re: (Score:1)
Given how incompetent government IT is, probably not a state actor.
Re: (Score:1)
Really good good guys, for varying definitions of good.
Re: (Score:2)
It's N S O ! They'll be ex-military + civilian + permanent military contract.
Re: (Score:3)
a PDF file pretending to be a GIF image with a custom-coded virtual CPU built out of boolean pixel operations
PoC||GTFO!
to Summarize, a virtual machine was shipped (Score:2, Interesting)
Re:to Summarize, a virtual machine was shipped (Score:5, Informative)
Not APIs, but the compressed image parser itself. A flaw in the parser allowed it to execute code encoded as pixels in the image, and from there get a foothold to run native ARM code.
Re: (Score:1)
Re:to Summarize, a virtual machine was shipped (Score:5, Insightful)
Note that image parsing code should always be tested very well, because it's a fruitful source of exploits. The reason is because it's mathematically complex, and not always obvious when a buffer will be overflowed.
Re: (Score:2)
not always obvious when a buffer will be overflowed
Unless, like, you checked for a full buffer before you appended something to it. Yeah, no way to prevent that.
Re: (Score:2, Interesting)
You can do that, but usually you want image de-compressors to go quickly. No one is happy if you can see each pixel rendered across the screen as you do all your buffer checks.
This isn't an easy problem to solve in Rust, either, because of the complex math.
Re: to Summarize, a virtual machine was shipped (Score:2)
Rust uses fat pointers. What's so complex about bounds checking a fat pointer?
Re: (Score:2)
Doing it at runtime is easy, but slows things down. Doing it at compile time is hard.
Re: to Summarize, a virtual machine was shipped (Score:2)
You're talking one or maybe two operations, which is well well below the nanosecond time scale.
But if you already have a boundary established elsewhere in your code (which is the only way to do "bounds checking" at "compile time" in any language without introducing the same kind of bugs you're talking about preventing) then you can always just call an unchecked buffer read/write. Rust has those for exactly this purpose.
Re: (Score:2)
ok? Write some Rust image decompressors. Maybe you can convince people to use them, even if they're slow.
Re: (Score:2)
A bit late for that as many already exist, and they're anything but slow. No real notable video codecs I'm aware of though, but that's mainly because the open source community barely even has the patience to write just one good library for the only useful video codecs these days. To say modern video codecs are a LOT of work is an understatement, as it's a field of study unto its own that requires years of understanding. That, and video codecs are so demanding these days that a lot of the work is now done in
Re: (Score:2)
Yeah, I'm basically done fighting programming language holy wars (my chosen language never wins, anyway). Rust is fine.
My main point was that Rust won't automatically solve all your problems when writing an image decoder, because it's hard (ie, instead of a byte stream, you have a bit stream, etc).
Re:to Summarize, a virtual machine was shipped (Score:5, Interesting)
The flaw in question was a buffer overflow created by an integer overflow. If you read the code, it isn’t something that jumps out as incorrect code. The rest of the code doesn’t read past any buffers (except for using a variable with an incorrect value).
The library used is open source and I am willing to bet just about any other user of the same library is vulnerable to the same exploit as well.
This is just one part of the attack. NSO figured out how to hit this code using other unexpected behavior (other code being too smart and figuring out what type of image format it is based on the content - a .gif file triggered jbig code). Lots of little flaws plus one serious one.
Re: (Score:2)
Unless, like, you checked for a full buffer before you appended something to it. Yeah, no way to prevent that.
Obligatory "That's unpossible!"
Big vendors screwing with "standards" (Score:5, Informative)
> image parsing code should always be tested very well, because it's a fruitful source of exploits.
This is another reason I get pissed when big vendors force new image "standards" onto us having relatively minor advantages. Examples include webp and avif. It takes several years for image handling apps and utils to recognize the new format properly. Stoppit! If it's not "a lot" better, go home.
Webp format drove me crazy as MS had one codec and Google another. When I made the MS codec the default, a group of apps couldn't display it right. When I made the Google codec the default, a different group of apps couldn't display it right. I had to pick which group of apps to be broken to the format.
Re: (Score:2)
All I really need is Ogg Vorbis. For everything.
Re: (Score:1)
Ogg does images and videos also? So it's the Emacs of media file formats?
Re: (Score:2)
Not that I know of. I see no reason that should stop you.
Re:to Summarize, a virtual machine was shipped (Score:5, Interesting)
Apple has a history of not being great at it too. Just yesterday, a nice proof of concept exploit, encoding a png that shows "Hello world" on correct implementations, and shows "Hello Apple" on Apple devices:
PNG Parser Differential [vidbuchanan.co.uk]
Re: (Score:2)
That's really cool.
Re: (Score:2)
Re: (Score:3)
code encoded as pixels in the image
That doesn't seem quite right judging from the description in the detailed article.
But but but (Score:1)
Thank goodness Windows is totally immune and will never fall prey to this, right? Right?
Comment removed (Score:4, Funny)
Re: (Score:3)
The GP said nothing about phones. If Microsoft has code that reads the JBIG format based on Xpdf (open source), then they could have code vulnerable in a similar fashion. I wouldn’t be surprised if this library is included in many other places as well.
The details of the exploit might change as the rest is based on iOS details, but that is more a matter of effort in customizing the attack for an OS.
Re: (Score:2)
How many Windows phones do you suppose are even out there anymore?
You're absolutely right and there's no way, no way at all that this flaw could be present anywhere else in the tiny codespace of the entire world.
Re: (Score:1)
Re: (Score:2)
You're assuming a lot, with the usual and predictable result of being wrong.
Re: But but but (Score:2)
Re: (Score:2)
Explain
Sorry, I can explain it to you but I can't understand it for you.
Re: But but but (Score:2)
Re: (Score:2)
##Reply not found## ERRCODE 328452
Re: (Score:2)
Locked down (Score:5, Interesting)
In its breakdown, Project Zero said the exploit effectively created “a weapon against which there is no defense,” noting that zero-click exploits work silently in the background and does not even require the target to click on a link or surf to a malicious website. “Short of not using a device, there is no way to prevent exploitation by a zero-click exploit,” the research team said.
Note that if you could control the device, you could install firewalls, filters, and alternate messaging services. "There is no way to prevent" only because Apple doesn't allow you to prevent it.
Re: (Score:3, Insightful)
In its breakdown, Project Zero said the exploit effectively created “a weapon against which there is no defense,” noting that zero-click exploits work silently in the background and does not even require the target to click on a link or surf to a malicious website. “Short of not using a device, there is no way to prevent exploitation by a zero-click exploit,” the research team said.
Note that if you could control the device, you could install firewalls, filters, and alternate messaging services. "There is no way to prevent" only because Apple doesn't allow you to prevent it.
So you think that an alternate messaging service would write their own JBIG2 implementation? Reimplementing every library so they don't have to use the OS libraries? And without a single exploit in their implementation? You sure have a lot of confidence in others.
If you could control the device, more devices would be compromised by social engineering attacks (low cost, low technical knowledge required) by fooling the users into installing the "virus scanner", "firewall" or "security update" that the tech su
Re: (Score:1, Flamebait)
If you could control the device, more devices would be compromised by social engineering attacks (low cost, low technical knowledge required) by fooling the users into installing the "virus scanner", "firewall" or "security update" that the tech support recommends. The types of attacks that is described in this article are VERY hard to protect yourself from.
Interestingly, if Apple allowed virus protection on the phone (or even just a message scanner), then once the virus was discovered, it could easily be defended against by updating the signatures. Much more quickly than Apple's fix.
As for the social engineering attacks, they don't seem to be a problem on Mac, so I don't know why you are so worried about them.
I seriously doubt that you are one of them. If you were you wouldn't be posting crap on /.
There are some wicked-smart posters on Slashdot, it's not Reddit or Medium.
Re: (Score:2)
> There are some wicked-smart posters on Slashdot, it's not Reddit or Medium.
Occasionally, once you get past the trolls.
Re: (Score:2)
They've left for greener pastures, like stack exchange.
Re: (Score:1)
Because its worked so well on ... Windows?
And you do realize what a "message scanner" is, right? It's a piece of spyware. Any app that can go through messages arbitrarily has the ability to spy on the users by copying and forwarding on those messages elsewhere.
Re: (Score:2)
Unfortunately, there are also a lot of trolls just shitposting. It's hard to read through all the crap for an occasional gem.
I regularly get discouraged a leave for a while. I come back when I have time to waste.
Re: (Score:3)
In its breakdown, Project Zero said the exploit effectively created “a weapon against which there is no defense
Note that if you could control the device, you could install firewalls, filters, and alternate messaging services. "There is no way to prevent" only because Apple doesn't allow you to prevent it.
I can already install those on my iPhone, and have. For instance, Lockdown is a third-party firewall that you can run locally. Alternate messaging services are readily available and you aren’t required to log in with your Apple ID to use an iPhone. And most of my traffic goes through pi-hole additionally. But this library is widely used, this class of exploit is difficult to secure against, and arbitrary code execution will let you bypass most of these safeguards altogether if you’re dealing wit
Re: (Score:2)
But this library is widely used, this class of exploit is difficult to secure against, and arbitrary code execution will let you bypass most of these safeguards altogether if you’re dealing with a clever attacker (which we are here), so nothing you’re suggesting would actually stop it.
Of course it would, you're a moron. Filter out any JBIG2 images, and problem is solved.
Re: (Score:2)
If you think this class of exploit is limited to that library, I’m not the moron here.
Re: (Score:2)
It's not going to happen with GIF or PNG, that's for sure.
Re: (Score:2)
It's not going to happen with GIF or PNG, that's for sure.
JBIG2 is literally a GIF decoding library, so you’re for sure incorrect.
Re: (Score:2)
JBIG2 is a different image format. The problem here is that it allows a basic logic operations (which most other image formats don't have), which turned out to be Turing complete, so they could use the image itself as a kind of scripting language.
Re: (Score:2)
Also, what sort of magic “filter” are you envisioning? We’re talking about E2E communication. You can’t do any sort of meaningful packet inspection and filtering on that traffic. By the time it’s unencrypted, you’ve already missed the best window to do any form of filtering, since it’ll already be in-memory for the messaging app, at which point the exploit is already active.
Re: (Score:2)
Sensational much? (Score:3)
Short of not using a device, there is no way to prevent exploitation by a zero-click exploit
Or...use a device with non-broken software? This claim that no such device could exist seems preposterous.
Re: (Score:3)
Re: (Score:3)
Or...use a device with non-broken software? This claim that no such device could exist seems preposterous.
Sorry, but computer science isn't there yet; not even close. Smart phones have millions of lines of code. Humans, even with the best technological tools currently available, can't produce that much perfect code. Then there are bugs in the compilers, the CPUs and other hardware, including vulnerabilities like row hammer.
There are efforts to produce both software and hardware that has been proved to be correct using formal verification techniques. This is very limited, extremely expensive and the commerci
Re: (Score:2)
Re: (Score:2)
Your comment was explicitly in response to the observation that "short of not using a device, there is no way to prevent exploitation by a zero-click exploit". Other zero-click exploits are possible.
Re: (Score:1)
Re: (Score:3)
Technically all exploits on a touch-screen device are zero-click since you tap on the screen -- unless you have a mouse connected.
I thought I'd seen the limits of pedantry here on Slashdot. I was sadly mistaken.
Re: (Score:2)
Re: (Score:2)
I interpreted the sentence like this:
Meaning if you have a device that is vulnerable to a zero-click exploit, your only mitigation for that threat is not to use that device -- disconnect from network or power off. Of course you could use other devices, or take a risk and use the vulnerable device anyway.
Re: (Score:1)
Imagine if... (Score:2)
... you could use a non-native message app that can interface with iMessage.
It's not the message transmission that's broken, it's the software on the phone.
I remember the first (IIRC) Windows jpeg exploit (Score:4, Insightful)
All sorts of people said "don't worry, this is too hard to exploit practically". Then, within a week, everyone was scrambling.
So... progress?
Not that surprising (Score:4, Interesting)
Back when the US court system was figuring out electronic documents it always bothered me that they ended up going with PDF instead of TIFF which is intended to not have a way to easily be edited which is more suitable as an archive standard. Plus TIFF obviously makes it easy to add data tags that would make cataloging data much easier.
Re: (Score:2)
PostScript is indeed Turing-complete, but PDF only implements a subset of the PostScript operators and isn't, or isn't supposed to be, Turing-complete. (I'm assuming here, of course, that JavaScript is disabled... it's not really part of the PDF spec anyway.)
Re: (Score:3)
Actually, JavaScript is supported [adobe.com] in the PDF standard, mostly for forms.
There are actually quite a few PDF exploits. https://www.sentinelone.com/bl... [sentinelone.com]
Re: (Score:2)
Yes, but JavaScript isn't part of the PDF standard, and I would certainly hope PDF readers would disable it by default. If they don't, then yeah... you've lost.
Re: (Score:2)
I find that claim very surprising. It's a raster format: raster formats are typically very easy to edit. The optional zip compression in TIFF would be a slight complication, but PDF also has optional zip compression so that doesn't seem to be what you're referring to. Do you have any references which might enlighten me?
Re: (Score:2, Informative)
As noted, this generalisation doesn't hold. PostScript is indeed a programming language and PDF is closely related, but it doesn't have the loops and things that PostScript does; it's a page description language rather than a page-describing programming language. This is deliberate. Not because security, but for practical concerns: It can be hard to figure out where each page is described in free-form PostScript, making it hard to programmatically edit (say with a desktop publishing program). The structure
Re:Not that surprising (Score:5, Informative)
Hmm. I don't think that this a PDF related issue. Rather, it's an issue with one of the image formats that can be embedded within PDFs. You can have JBIG2 files outside of PDFs.
(In 2013, some copiers that stored images in JBIG format could alter the text of documents that weren't obvious to the observer [wikipedia.org])
If it had not done so, it would have been a useful archival standard-- high dpi files take up a lot of space, and standards like jpeg would introduce blurriness.
Engadget described JBIG2 [engadget.com] as
"old code from the 1990s used to process text in scanner images."
Which is only half true. Yes, the standard was released in December 1999, and yes, most JBIG2 files were scanned in at some point, but the niche the format purports to fill still exists.
Re: (Score:2)
This is getting a bit off topic...
JBIG actually seems like a pretty good compression format for its use-case (black and white documents). I didn't know about it until I read the article. The real problem is the encoders that allow too much variation in what they encode, leading to fun stuff like 6's being replaced by 8's. But this is really the encoder's fault, not the file format itself. You probably could get could compression ratios with a lossless encoder - and even better if the encoders just allowed a
"a weapon against which there is no defense," (Score:2)
Uh... okay? That's obviously bullshit ?
There are two cases and two cases only _that I know of_ under which this would be possible, both of which are a bigger problem than such "undefendable weapons" themselves:
1) cpu bug. Honest-to-goodness bad cpu design which allows bypassing of virtual memory protection features (reference: most of christopher domas' presentations)
2) an os that allows code to execute privileged instructions/ call system entry points (implied: when it shouldn't).
Am I missing something?
Re: (Score:2)
The main thing you seem to be missing is reading the links.
Re: (Score:2)
Good god, don’t read the links. It’s right there in the url - project zero! Yes, the purport to be analyzing flaws, but given their expertise why wouldn’t they also create exploits of their own. Google long ago gave up on Don’t Be Evil. ;)
(For those humor-impaired, yes this is a joke.)
Re: (Score:2)
You are missing that you don't own the OS. Apple can defend against this, but you can't.
This is not "code encoded as pixels" (Score:5, Informative)
"JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does," the researchers explained.
"Using over 70,000 segment commands defining logical bit operations, [NSO’s hackers] define a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent."
"The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It's pretty incredible, and at the same time, pretty terrifying,” the Google researchers added.
Re: (Score:1)
I don't get it. how can any image pixels however they are flipped, affect anything else on your computer? dont you just end up with at most an image that displays something other than intended?
Re: (Score:2)
Reminds me of the early days of game console development, as well as the demo scene on early PCs.
Big scary words (Score:1)
"A weapon against which there is no defense!"
Other than fixing the buggy implementation, making this just like any number of exploits.
booby-trapped a PDF file
Also called a trojan
Great NSO ad. (Score:2)
Quit wasting time (Score:3)
Sell me on this - more sophisticated than stuxnet? (Score:1)
iMessgae should reject all data from unknown # (Score:2)
I think iMessage should reject everything other than plain text in messages that do not verifiably come from come from numbers or addresses in the user's contact list. No images, pdfs, gifs or urls - plain text only.
That ought to reduce the attack surface somewhat.