Using WhatsApp for OSINT
Discover how WhatsApp can be leveraged to expose information about other users silently. A passive OSINT trick hiding in plain sight.
For this trick you need to intercept mobile network traffic and bypass SSL pinning, which is part of the pentesting basics you learn in our Free Android Application Security course.
Jun 22
Discovery of 'the bug'
While monitoring the network traffic of WhatsApp after installing it on a (virtual) device, it turned out that the first phone number registration steps return interesting information. If you are not familiar with intercepting network traffic on Android, you can follow the Free Android Application Security training, especially the section '3 Android Penetration Testing Basics', since we will not explain all details in this post.
To summarize the bug: It is possible to retrieve details like phone model by only entering a phone number in the WhatsApp registration flow.
If you stop after the first step, the owner of the phone number will not be notified, so it could be used for silent enumeration. This information (for example: "Samsung Galaxy A32") can be useful already for bad actors who want to target someone and try to 'get in their phone', or use the information in phishing attacks.
Meta did not classify this as a security issue and partly mitigated this already. Since it used to work on Android and iOS (numbers linked to it) a few months ago, but recently it does not work for iOS devices anymore. We suspect that this might be related to recent spyware attacks targeting iOS, but this is just speculation.
Below are the steps to reproduce this issue.
To summarize the bug: It is possible to retrieve details like phone model by only entering a phone number in the WhatsApp registration flow.
If you stop after the first step, the owner of the phone number will not be notified, so it could be used for silent enumeration. This information (for example: "Samsung Galaxy A32") can be useful already for bad actors who want to target someone and try to 'get in their phone', or use the information in phishing attacks.
Meta did not classify this as a security issue and partly mitigated this already. Since it used to work on Android and iOS (numbers linked to it) a few months ago, but recently it does not work for iOS devices anymore. We suspect that this might be related to recent spyware attacks targeting iOS, but this is just speculation.
Below are the steps to reproduce this issue.
Prerequisites
To follow along with this post you need:
- Android Device or Emulator with root access
- Any version of Whatsapp installed on the device
- Frida server installed on the device and frida client installed on the host machine
- Burp Suite to intercept network traffic
Analyzing mobile network traffic
One of the first things you will learn if you are exploring Mobile Application Security is how to intercept network traffic, to monitor API usage between the app and backend services, and tamper with those HTTP requests to find possible security issues.
As a penetration tester this must sound familiar if you are testing web applications or API's. The only difference between web / API testing and Mobile Apps is that there are often additional security measures implemented like SSL pinning or even additional encryption of the HTTP requests and response to make it a little bit more difficult to read the responses or tamper with the requests.
In case of this WhatsApp API the HTTP request body is encrypted and the HTTP response is not encrypted. As shown in below API request to the host v.whatsapp.net.
As a penetration tester this must sound familiar if you are testing web applications or API's. The only difference between web / API testing and Mobile Apps is that there are often additional security measures implemented like SSL pinning or even additional encryption of the HTTP requests and response to make it a little bit more difficult to read the responses or tamper with the requests.
In case of this WhatsApp API the HTTP request body is encrypted and the HTTP response is not encrypted. As shown in below API request to the host v.whatsapp.net.


Assuming we cannot crack the encryption in the HTTP request body (value of the ENC property), this already indicates that the bug is related to the information exposed in the response. Let's explain the issue and also go over the steps needed.
Steps to reproduce
- Start an Android device or emulator (after creation via Android Studio) with a proxy configured. For example:

2. Install WhatsApp on the device
we used WhatsApp version 2.25.18.77 from APK Mirror, but the bug is related to a backend API, so probably any version will do.
we used WhatsApp version 2.25.18.77 from APK Mirror, but the bug is related to a backend API, so probably any version will do.
3. Configure the device with Burp Suite certificate to intercept network traffic
In this case we use Burp Suite Community Edition and installed the Burp root certificate on the Android (14+) emulated device. Follow the instructions in the course or https://httptoolkit.com/blog/android-14-install-system-ca-certificate/#how-to-install-system-ca-certificates-in-android-14 for this.
After configuring the certificate on the device, you will stil get errors related to the WhatsApp API
[8] The client failed to negotiate a TLS connection to v.whatsapp.net:443: Received fatal alert: certificate_unknown
Visible in the event log at the left bottom in Burp Suite:

This is related to SSL pinning: "SSL pinning is a technique that helps to prevent MITM attacks by hardcoding the SSL/TLS certificate’s public key into the app or device. This means that when the app or device communicates with the server, it will compare the server’s SSL/TLS certificate’s public key with the one that is hardcoded into the app or device."
Luckily SSL pinning can be bypassed by modifying the app during runtime (and overriding common used Java classes for this) using the tool frida, which is the next step.
Luckily SSL pinning can be bypassed by modifying the app during runtime (and overriding common used Java classes for this) using the tool frida, which is the next step.
4. Configure frida to start the app with instrumentation to bypass SSL pinning
To bypass SSL pinning we need frida. On your host machine you can install frida client via python
This will install the latest version. Make sure to download the same version of frida-server to push to the Android device for example frida-server-17.2.4-android-arm64.xz:

Extract the binary from the archive and configure it on the device via adb:
Now we can run fida with the 'frida-mutiple-unpinning' script, thanks to akabe1!
Run the script from Frida CodeShare via:
Run the script from Frida CodeShare via:
-f, means spawn (start) the app (with package name: com.whatsapp) and immediately attaches the script.

The error related to the domain v.whatsapp.net should be gone, and should be visible in the HTTP History with readable responses:

5. Trigger 'the issue'
On the second screen, after pressing 'OK' and 'Agree and continue', you can link a phone number. Fill in your own phone number for example and click on Next'
On the second screen, after pressing 'OK' and 'Agree and continue', you can link a phone number. Fill in your own phone number for example and click on Next'

Click on Next to get the following confirmation:

if you press 'Yes' the owner will get a notification with a confirmation code:

This is what you should avoid, if you want to be stealth..
If you click 'Edit' you will go back to the previous screen and the user will not be notified. The interesting thing is that if you check the network traffic, after entering the phone number and before confirming the number, there is already a request:
POST /v2/exist
Host: v.whatsapp.net
Body: ENC=[encrypted string]
Response body:
JSON with user details, and if lucky (Android?) details like:
"wa_old_device_name": "Samsung Galaxy A32" or "OnePlus OnePlus Nord2 5G" or "Google Pixel 8a" etc.
If you click 'Edit' you will go back to the previous screen and the user will not be notified. The interesting thing is that if you check the network traffic, after entering the phone number and before confirming the number, there is already a request:
POST /v2/exist
Host: v.whatsapp.net
Body: ENC=[encrypted string]
Response body:
JSON with user details, and if lucky (Android?) details like:
"wa_old_device_name": "Samsung Galaxy A32" or "OnePlus OnePlus Nord2 5G" or "Google Pixel 8a" etc.

The request body is not useful, so easy enumeration via the API is not possible:

Interesting it that this used to worked in almost all cases (if the phone number is linked to whatsapp), and this seems to be changed recently.
Earlier wa_old_device_name for an iOS linked phone number:
Earlier wa_old_device_name for an iOS linked phone number:

Recently:


Conclusion
All though we did not discover a serious security flaw in WhatsApp, it is still interesting to monitor the network traffic and look for (sensitive) information. If it was easier to enumerate and always returning the same output, it could have been interesting to enumerate all phone numbers (per country) and collect statistics about which phones are most popular for example.
Want to learn more
Join our free AppSec Courses for Android and iOS and proof your skills by doing the exams and become a Certified Android Penetration Tester (CAPT) or Certified iOS Penetration tester (CIPT).
Or if you want to dive deeper to cover the whole stack:
- Android Userland Fuzzing & Exploitation, with 72 hours hands-on exam to become a Certified Android Exploit Developer.
- Android Kernel Fuzzing & Exploitation, with free hands-on tryout lab
Or if you want to dive deeper to cover the whole stack:
- Android Userland Fuzzing & Exploitation, with 72 hours hands-on exam to become a Certified Android Exploit Developer.
- Android Kernel Fuzzing & Exploitation, with free hands-on tryout lab

Copyright © 2024
Company
Registration:
89905814
VAT:
NL004770321B63
89905814
VAT:
NL004770321B63