CTF — Exploiting Corellium’s GlitchChat iOS Application
Introduction
NOTE: The following may contain some spoilers for the challenge! This blog will not publish answers but some of the content may provide hints.
I recently completed an iOS mobile application capture the flag challenge created by Corellium and I wanted to briefly share my analysis and thoughts on it.
The target is a messenger app named GlitchChat, suffering from multiple vulnerabilities including memory corruption, which will be the focus of this blog.
For more information you can sign up to view the webinar for free and read the accompanying blog. The blog contains a link to download the app:
Webinar: Watch Now: Experimenting with Messaging App Vulnerabilities (corellium.com)
Blog: Corellium GlitchChat
Corellium is a great resource for anyone trying to get into mobile penetration testing. I also highly recommend HackTricks mobile pentesting section.
Prerequisites
The challenge is intended to be completed using Corellium’s iOS hardware virtualization platform, however it is not necessary.
You will need the following:
- Jailbroken iPhone ≥ 7
- Python ≥ 3.9
- PC or MacBook (MacBook preferred)
- USB connector
I used the following tools to test, discover and exploit the application:
- Binary Ninja (disassembler and debugger)
- Frida
- Objection
- 010 Hex Editor
- iProxy
How to jailbreak an iPhone and load apps is out of scope for this blog. Further setup for the app and explanation of the scenario is explained in the Corellium blog.
Analysis
The target is a simple messenger app that communicates using the MQTT protocol. Once a server is running, a connection can be made to that server by specifying a username as well as the IP address and port on the main page.
Interaction with the chat server can be scripted with python. The image below shows an example python script using an MQTT library to send the message “Hello!” to the recipient and the captured network traffic for that message.
When a user sends an image, a similar message structure is used, however the message field must be a base64 encoded PNG file.
The app replies with a message validating the storage location of the image on the device and the memory address of the function used to process that image. The address is in decimal format.
You will note that the memory address follows the text “AI result”. This is because the app is intended to detect AI-generated images based on the header information. Using a custom implementation of the libpng library, the app includes several functions that handle the processing of these images to label them as generated by tools like DALL-E, Midjourney, Stable Diffusion, etc.
There is one function named _png_aixx_ctf that seems like a function of interest; however, there are no cross-references to it, meaning nothing calls or interacts with that function directly. This will be the target of our exploit.
Exploitation
Based on initial analysis and the track record of capture the flags, one can assume that this app may suffer from a memory corruption bug that can be exploited to call the _png_aixx_ctf function using a ROP (Return-Oriented Programming) chain.
Since libpng contains custom code, we can focus our analysis there and perform controlled tests against those functions to determine where the flaw exists.
You will find that the instruction pointer can be hijacked and replaced with an arbitrary pointer of our choosing. In this case, we will replace it with the pointer to _png_aixx_ctf which prints a message that the “flag” has been captured. Since ASLR (Address Space Layout Randomization) is enabled, you will need to use the memory address leak found in the returned message to calculate the address of _png_aixx_ctf.
If an aixx header is crafted and properly parsed by the app, a warning message will pop up in the recipient's chat alerting them that the image is AI-generated.
Since the _png_aixx_ctf function prints the success message to stderr, we will need a way to validate that the function is called. Setting a breakpoint on the function using a debugger is one way to do this, but we can also use Frida to hook the fprintf function and read the contents of the second argument.
In the Frida script below, I check the second argument of fprintf to see if it contains the string “flag!” and print a message to the console stating that the flag was found.
// Frida script with a function to hook the fprintf function, print the arguments and the return value
function hook_fprintf() {
console.log("Hooking fprintf");
var module = Module.load("libSystem.B.dylib");
if (module == null) {
console.log("Module not found");
return;
}
var fprintf = module.getExportByName("fprintf");
if (fprintf == null) {
console.log("Symbol not found");
return;
}
Interceptor.attach(fprintf, {
onEnter: function(args) {
// Check if the string "flag!" is in the first argument
var str = Memory.readCString(args[1]);
if (str.indexOf("flag!") != -1) {
console.log("You have found the flag!");
}
},
onLeave: function(retval) {
//console.log("Return value: " + retval);
}
});
}
hook_fprintf();
While my analysis ends here, you could take this further and create a full ROP chain to call arbitrary functions and do your bidding.
Final Thoughts
There were a couple other interesting vulnerabilities to exploit in the application leading to data exfiltration, but I found the memory corruption vulnerability to be the most fascinating due to the fact that it can be classified as a zero-click exploit, meaning it involves no user interaction.
GlitchChat does a good job of demonstrating the nature of messenger app vulnerabilities and facilitating the approach to exploiting memory corruption bugs against a mobile device. Creating custom implementations of common libraries lack scrutiny from the broader community and runs the risk of introducing vulnerabilities which lead to catastrophic results.
