BRIEF // 00
Coruna is a nation state exploit kit founded in the wild and researched by GTIG and iVerify. The exploit kit target iOS version 13.0 up to version 17.2.1 and some OSx versions.
All the exploits are 1-click delivered through phishing sites impersonating crypto stuff, AI stuff, gambling stuff... This is an example of a phishing site source code delivering the first stage
You can clearly see a one liner of obfuscated javascript tag inside the HTML source code of the web page
When an operation is exposed by Google or whoever the first thing you should do is take down all C2/payloads host domains to not leave free access to the public, in this case chinese peoples ?forgot? to do that giving the public the chance to get their hands on it too. So the idea working with some friends was to scrape all of the still active domains and try to "recreate" the exploit kit (or just a full chain) for educational purpose.
RESEARCHING // 01
First evidence of public release of the payloads was from matteyeux on his Github, all of those payloads were hosted on b27.icu, we started looking at other domains known to deliver the first loader of the Coruna chain (see here)
The whole web infrastructure for my understanding was divided into those components:
- Domains delivering modules and exploits to the loaders: Called by the phishing sites
- Domains delivering loaders: Phishing sites
- Post exploitation domains delivering C2 connections: Generated with a DGA and always use as TLD ".xyz"
Those are the active phishing domains (used during research) that delivers the payloads:
Working domains hosting malicious iframes:
Loaders and exploits were interchanged between sites with little to no difference in their logic and implementation, here we can see the page source code for lmt0ken loading remotehealthcheck malicious analytics.html
We tried generating ~4000 domains using a DGA algorithm that implements the seed "lazarus" and has a max length of 15 characters (as described by Google TIG) but none of them worked
Each js payload was hosted in a single hardcoded domain using a hex string as a name (eg: http://b27.icu/166411bd...js)
BREAKDOWN 1-CLICK EXPLOIT CHAIN // 02
This is a simplified breakdown on Coruna exploit chain, from initial compromise to OS memory access, i hope this can make the level of engineering required behind Coruna and in general all the modern browser exploits
From here things will get tough so i need to say this: im NOT by any means an expert in iOS/browser exploitation, i usually do Windows/Linux and less complicated binary exploitation, do not rely 100% on what i will say and do your own research, thanks (:
INITIAL LOADER AND DEVICE FINGERPRINTING
Every code was part of a larger chain, the whole operation was very modularized (basically a framework), each modules and additional utilities were delivered by the loaders.
Let's view the analytics.html deobfuscated code to better understand all the functionalities of one loader
The loader first check the version of WebKit executing the payload, it does that by parsing WebKit version number and comparing it to some hardcoded values
If the webkit version is < 13000 the module abort the execution, else if the version is > 16000 further setups are executed (runtime.zo())
C2 communications works through HTTP using XMLHttpRequest, it's used to fetch further modules and execute them using stealth DOM injection.
The loader use a particular way to resolve URLs, it calculate the sha256 of the remote resource that need to be fetched and uses only the first 40 hex chars for the filename
Stealth DOM injection happens by creating a new div with opacity: 0.0 and executing the JS module by creating a new script element
WEBKIT RCE
Coruna uses 3 different RCE exploits in the webkit renderer, based on my understanding none of them were actually exploiting 0days but rather known ndays never exploited in the wild (still crazy)
- 1) NaN Boxing type confusion: On legacy devices running iOS 11-13 | CVE 2021-30952
- 2) JIT Type Confusion: iOS 15.2-15.5 | CVE 2023-48503
- 3) Heap corruption + SVG R/W: iOS 16-17 | CVE 2024-23222
Because im not an expert on browser exploitation and 3 CVEs are a lot to go through in the next paragraphs ill just analyze and rewrite the RCE + R/W primitive of the heap corruption, i will link to a repository with all of the exploits cited above (obfuscated and not), you are welcome to do the same with all of them
Doing a quick brief on JS engines vulnerabilities the majority of them arise because of the natural difference between JavaScript, a dynamically typed language, and c++, language used to write the engine that is a statically typed language.
Often on the other hand, type confusions are well known problems within the JIT compilation on the JS engine, this is because JIT is based on assumptions in order to generate machine code and be faster. JavaScript variable are dynamic, a variable x can be a double in one line and an Object on the next, to make execution faster JIT will assume that x will stay a double, if the variable changes during runtime and the developer doesnt guard deoptimization the CPU will interprets the memory bits of a doubles as an object
MEMORY R/W PRIMITIVE UPGRADE
Lets first start with a fundamental distinction in exploit development: A vulnerability is the root cause, a primitive is what the bug allows you to do (often limited).
Upgrading the primitive is critical, you need to have some kind of "privileged" and reliable primitive, preferable an arbitrary R/W, Coruna in all 3 exploits found a way to upgrade the initial vulnerability and gain this primitive, later we will see an example and how it create a "stable channel" for writing and reading
In the realm of browser/JS engine exploitation the 2 most powerful primitives are addrof and fakeobj.
addrof:
func addrof( obj ) { return address; }
Used to defeat ASLR this primitive leak memory addresses from JS objects
fakeobj:
func fakeobj( addr ) { return object; }
Used to create JS objects at specific memory addresses
JIT CAGE EXECUTION AND PAC
After establishing R/W primitive its time to achieve Arbitrary Code Execution, generally its obtained through hijacking already existing pointers/callbacks in order to invoke an attacker controlled function pointers with a PAC valid signature. This phase has big constraints, one of those being PAC.
Doing a brief overview on Pointer Authentication, PAC is a mechanism by which certain pointers are signed, when pointers get signed, a cryptographic hash of its value and other values is stored in unused bits of that pointer
PAC is a mitigation against ROP and JOP attacks, general ways to bypass this mitigation are by leaking a valid signature key or signing your own pointer
You can read more about PAC here
Coruna start its PAC bypass by searching for ARM64 PAC Trampoline gadgets, it does that by looking for 17 specific instructions. JSC includes a PAC trampoline for its own internal use (signing JIT code pointers), the exploit locate those pointers using pattern matching
A64 architecture has specific instructions for Pointer Authentication, for effective PAC bypass its important to control them.
Looking at the whole and in-depth PAC bypass mechanism is a lot of work and i still want to cover a lot of things, however at the end i will link my github repository with all the deobfuscated files im possessing right now, if you are interested you can have a look at it by yourself
This is an high level overview of what should be happening:
- 1. Finds the signing gadgets - JSC PAC trampoline for own usage
- 2. Reuses the signing infrastructure - Calling pacia1716 with controlled inputs for generating PAC signatures
- 3. Signs WASM table entries - The variant 1 use the WASM function table, it expects only PAC-signed entries, the exploit signs the function pointers with correct discriminator (0x24ad) before patching them into the table
To execute code from within the JIT cage Coruna abuse Intl.Segmenter, a JavaScript API for unicode text segmentation. This API allow developers to split strings into units according to some unicode standards or language-specific rules, return an iterable object via the segment() method
Intl.Segmenter( locale, { granularity: 'something' } )
When called using "sentence" as granularity and used on a long string, under the hood JSC JIT compiles the ICU break iterator's (icu::BreakIterator) internal loop. The exploit corrupt the iterator's internal data structures to redirect the JIT compiled code path to an arbitrary native function. This works because the iterators internal pointers and vtable entries are stored in the heap accessible via the R/W primitive
This is the setup, whats happening is:
- 1. Create a segmenter
- 2. Build a long string - (300 "a" joined with white spaces), forces JIT compilation in native code
- 3. Warm up - .segment(longstring) triggers the JIT compilation
- 4. A buffer is allocated to hold a copy of the original JIT code
Now start the actual call phase (pointer hijack), this is the core logic of the exploit that will run every time we want to call a function.
First we need to get a new iterator using Symbol.iterator method and parse the internal pointers from it
We are using the previous R/W primitive in order to read those pointers, what we are interest in is the code address
You can see strange sequence of characters like: FVmvHQ or wKny90, those are the memory offset (specific to JSC version) where function pointers resides
We now copy and modify the internal ICU data structure
Critical step is to set the flag to RWX on the newly allocated buffer, this bypass Write XOR Execute mitigation
We have now one buffer for the Trampoline code and one buffer for the cloned ICU internal pointers
linking the 2 buffer together we now swap pointers and point the internal codeBufferPtr from the iterator to the cloned and RWX buffer
Patching the iterators internal pointer codeBufferPtr to point to cloned buffer with our modified ICU pointer. Now the engine thinks our buffer is the legitimate code buffer
We copy legitimate JIT instruction inside the Trampoline buffer allocated before, then we patch the Call instruction to target the native function we want to execute.
To finish we trigger the JIT execution by calling iter.next on the modified iterator object
We are now executing native c++ functions, but note that we are still inside the renderer's memory space
As a summary: Normally the JIT space its executable but not writable, this exploit create a trusted RWX that JIT will execute, you can write shellcode in this space as if it was legitimate JS code. we can call this a "call anything" primitive
I hope this graph can help, if you find this difficult its because it is
After JIT cage escape that im not going to cover here Coruna will exploit a kernel vulnerability (CVE 2023-41974) for gaining LPE and install an in-memory implant inside the root daemon powerd
All i have described above is just the tip of the iceberg about browser exploitation, its a huge world and i encourage you to look further. ret2systems its an extraordinary resource
HEAP CORRUPTION VULNERABILITY - HEAP GROOMING // 03
I took a deeper look at one of the WebKit vulnerability and how Coruna updates the initial relative to a complete arbitrary R/W
The vulnerability is a Type Confusion, whats crazy about this is how it get triggered through Heap Grooming voodoo magic
Heap grooming is a technique where an attacker deliberately shapes the memory allocator's state so that 2 unrelated objects end up at overlapping heap addresses. Unlike heap spraying grooming is more precise and surgical, its a combination of frees and allocations in order to control with a greater probability where the next allocation lands
The exploit abuse Intl.NumberFormat("en-US") and OfflineAudioContext.decodeAudioData() javascript objects
Looking at Intl.NumberFormat("en-US") internals, when this object its created JSC allocate an ICU UNumberFormat structure containing a float-formatting buffer, this buffer resides on the heap and it contains intermediate results when a number is converted from local-formatted to string (see Intl.NumberFormat doc)
When OfflineAudioContext.decodeAudioData() is called it allocates a temporary buffer for decoded stuff
If the heap is groomed correctly the buffer allocated by OfflineAudioContext.decodeAudioData() can land on an Intl.NumberFormat("en-US") float buffer
The grooming sprays 3 tiers of Intl.NumberFormat("en-US")
- formatterPool - 7000 objects, are the primary ones and where we will be looking for overlapping
- flankingFormatters - 3x primary (21000 objects), are used to fill the gaps around primary formatters and create precise holes around them
- tempFormatters - 2x primary (14000 objects), used for additional heap density, they force the allocator to compact the memory early
So at the beginning we have ~21 MB of heap space used just for float buffers. You can already understand the concept of grooming, each allocation has its own scope
Now the core grooming logic begin, first we release all the 14000 tempFormatters allocated before, creating holes inside the heap
Continuing we do cycles of applying heap pressure and exception spray
240 allocations of 4 MB ArrayBuffer each for a total of 960 MB, why are we doing that? => The act of allocating those chunks force JSC garbage collector to compact the heap pushing smaller allocation (NumberFormat internal buffers) closer together
This is the exception spraying logic
The locale "dowocjfjq[" (CANARY_LOCALE) is syntactically invalid because it contains a "[". The ICUs locale parser reject this allocation but not before allocating internal temporaries to parse the locale. This allocation -> immediate freed cycle has 2 effects:
- Free-list churning: ICUs internal allocator fragment free list, breaking up contiguous blocks into smaller pieces that match the size of a formatter's float buffer (~512 bytes)
- Garbage Collector triggering: The repeated exception path may trigger GC to compacts the "young generation" and moves surviving objects (primary formatters) into tighter arrangements
Everything is still being done with the objective of compacting more and more the primary formatters around the holes we created freeing the temporary formatters
The next phase require to call format() method on primary formatters
The format(n) is a method that converts a number into a locale-specific string, calling format 3 times with 3 different values forces:
- 1. format(1): Forces allocation of ~512 byte ICU float buffer
- 2. format(2): Ensure buffer is fully initialized
- 3. format(3): After this call the live formatting state will produce deterministic output
After the warm up each primary buffer owns distinct ~512 byte heap allocation containing its ICU float buffer. These buffer are now interspersed with the holes left by the released temporary formatters, exactly where DecodeAudioData will try to allocate
Now another cycle of release - Heap pressure - exception spray is done, this time we are releasing the flankingFormatters (creating 21000 new holes)
The exploit run this cycle twice in order to refine the heap layout, the first round creates holes and compact them, then the warm-up materializes buffers into those compacted regions, then the second round creates new holes right next to the now-materialized buffers
Now its time to trigger the corruption/overlap by using the OfflineAudioContext.decodeAudioData() method to allocate ArrayBuffer chunks that land in the holes next to primary formatters
OfflineAudioContext.decodeAudioData() takes as arguments an ArrayBuffer containing a full audio data and return an AudioBuffer containing decoded PCM audio data
We are performing 20 rounds where each round performs 3 decodes:
- 1. Allocates a medium size PCM buffer
- 2. Another allocation of the same size as 1, two consecutive allocation of same size tend to land adjacent in the heap
- 3. Null-Write decode, an intentional malformed WAV, the decoder start processing it, allocate a buffer, write the initial decoded sample into it and then encounters the malformed data and throws. By the time of the throw the decoded PCM have been already written in the heap
The carriers buffer are retained inside the heap so they occupy space permanently and reduce the effective free region forcing the subsequent allocation closer to formatter buffers. The null-write buffers are the actual overlap triggers, they fail during decoding but the partial write has already occurred
To finish we want to detect the overlapping
What is format(1.02)? => On an uncorrupted en-US formatter, format(1.02) returns 4 chars string "1.02", this is a deterministic output with a fixed len. If the formatter internal float buffer has been overwritten by an overlapping ArrayBuffer the ICU formatting engine reads garbage data from the corrupted buffer, this buffer is interpreted as a different value with a length other than 4
If the overlapping is triggered the format(1.02) will leak an address from the heap, result contains bytes from the overlapping ArrayBuffer, we just parse the string to extract the memory address
Due to apple being apple i had many problems testing the exploit live while debugging with lldb, at the end i have opted to just use extensive debugging messages. I have spun up a local web server delivering the heap grooming phase of the exploit and navigated to that using an iPhone XR with iOS 16, this is the result
A graph to better visualize each phase of the grooming
UPGRADING TO ARBITRARY MEMORY R/W PRIMITIVE // 04
This is the second stage for the exploit, its job is to transform the limited heap corruption achieved during heap grooming into a reliable mechanism for reading and writing arbitrary memory
This stage of the exploit produces 2 primitives:
- AudioPrimitive - format(NaN) for reading and decodeAudioData for writing
- SvgPrimitive - orderX.baseVal
We will only look at the AudioPrimitive, its enough to understand how the exploit achieve relative - arbitrary R/W
AUDIOPRIMITIVE - READING MEMORY
Remember that now the formatter's internal float buffer overlaps with an AudioBuffers decode PCM buffer, when Intl.NumberFormat.format(NaN) is called ICU serializes the internal float buffer as a string. Because the buffer is overlapped the resulting string returned contains raw heap memory content
This is the code for reading 32 bits value
Calling format(NaN) is expensive, to avoid redundancy the exploit cache the result inside _readBuffer
AUDIOPRIMITIVE - WRITING MEMORY
A general rule in exploit development is that the majority of the times you will achieve arbitrary something is by overwriting already existing pointers
As we said before OfflineAudioContext.decodeAudioData() allocate an internal buffer for the decoded PCM output, these allocations go through the same allocator (bmalloc) as Intl.NumberFormat internal buffers. By carefully constructing the input buffer is possible to control the PCM values that get written to the overlapped memory region
This is how writing works:
1. Construct a TargetedWriteStrategy WAV buffer with encoded the target address and value
This is building a WAV buffer from a strategy object, TargetedWriteStrategy define strategy objects, these objects are used to compute the sequence of PCM sample "jumps" that will position the decoder's output cursor at the target address and deposit the desired value
When decodeAudioData processes the resulting WAV, the audio decoder interprets the sample descriptors as PCM jumps, each jump is simply a 16-bit offset that advances a cursor through the output buffer, we can position the cursor by carefully selecting the jumps sequence (this is the strategy)
2. Submit to decodeAudioData()
At this point we basically have a very limited R/W primitive, we can read memory using the format(NaN) and write to memory by crafting special buffers whose decoded PCM output writes a specific value at a specific address through decodeAudioData
Writes are unreliable, unlike reads (which are deterministic once we know the memory address of the overlap), writes depend on where the allocation place the decoder's output buffer. The best thing would be to target a specific address
To read/write at arbitrary addresses we modify the overlapped formatter's internal structure fields (using the write primitive) to "slide" the window
At leakedAddress + INTERNAL_SIZE_OFFSET (968) there are several internals structure:
- Capacity (INTERNAL_SIZE_OFFSET + 8) - How many bytes the formatter think the buffer holds
- Length (INTERNAL_SIZE_OFFSET + 12) - Data length
- Data Pointer (INTERNAL_SIZE_OFFSET + 24) - its the base address that format(NaN) reads from
We will write the target address inside the data pointer at offset +24
As you see the target address is written 32 bit at a time
We can call format(NaN) to read from the new address
Now decodeAudioData will writes to the new address written inside Data Pointer
In this way we are setting a specific and arbitrary address in which apply the already present R/W primitive
CONCLUSION // 05
The entire Coruna exploit kit is much bigger than what i have discussed in this post, you can find all the deobfuscated payloads i used here
Useful links: