BOOK THIS SPACE FOR AD
ARTICLE ADAfter uncovering the GraphQL playground and exploring the introspection query as we discussed previously, I got curious to witness these calls in real-time. I wanted to understand their usage context, and importantly, uncover any hidden queries or mutations that weren’t listed in the introspection.
To do this, I needed to intercept the app-server communication. This usually involves a MITM setup, but there’s a catch: intercepting doesn’t mean you can read the traffic; it must be decrypted first. Luckily, I have a rooted Android phone for such experiments. Here’s the plan:
Install the Fintech application from Google Play into the rooted phoneInstall the Burp Suite SSL certificate.Set up my laptop as a Wi-Fi proxyConfigure Burp Suite to intercept the data.This method hinged on one critical factor: the absence of certificate pinning in the app. Certificate pinning is a security measure where an app is hardwired to trust only specific SSL certificates, making it tough to decrypt its communication. If the app had used certificate pinning, I would have had to decompile it, swap out the certificate, and recompile it — a process I was keen to avoid.
Adding a custom SSL certificate to an Android phone
Why Root Access Matters: Android systems, for security reasons, limit the addition of new trust certificates. However, with root access, you can override these restrictions. Rooting allows you to tweak system files and settings, crucial for installing a custom certificate.
First, grab the certificate you need. For the Burp Suite’s certificate, simply visit http://127.0.0.1:8080, and download the CA certificate. The cacert.der file is what you need, in binary format.
Android verifies the certificate’s hash against its file name. So, calculate the hash and rename the file accordingly:
# Calculate the certificate's hash on your local machine using the .der fileCERT_HASH=$(openssl x509 -inform DER -subject_hash_old -in cacert.der | head -1)
echo "Certificate hash: $CERT_HASH"
# Rename the .der certificate with the calculated hash and .0 extension
mv cacert.der ${CERT_HASH}.0
I ended up with the file 9a5ba575.0, and it’s likely you will end up with the same result. This particular certificate is set to expire in 2032.
Next, push this file to the rooted Android using ADB (Android Debug Bridge), and place it in the system’s trusted credentials. This involves remounting the system partition with read/write permissions, moving the certificate, and setting the correct permissions:
# Push the renamed certificate to the Android deviceadb push 9a5ba575.0 /sdcard/
# Move the certificate to the system's trusted credentials
adb shell
su
mount -o rw,remount /system
cp /sdcard/9a5ba575.0 /system/etc/security/cacerts/
chmod 644 /system/etc/security/cacerts/9a5ba575.0
reboot
After rebooting the phone, if all goes well, you’ll be ready to decrypt the traffic in Burp Suite using your proxy setup.
Enjoying the results
Thankfully, everything went smoothly. I could observe every backend request made by the Fintech app, pause them, inspect, and even modify them. Even better, I could see the actual responses using my account details!
For now, I’m not reporting any vulnerabilities. I’ve noted in my report to recommend certificate pinning to enhance security, but I’ll hold off on sharing this until my research is complete. 😎
Stay tuned for more findings in the next chapter!