Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

WhatsApp is a common messaging application used across the world. Because everyone stores data on their phones, compromising the content of a phone is massively impactful. This particular discusses a round-about-way to compromise WhatsApp.

In Android, Content Providers are an IPC mechanism to share resources with other applications. For instance, this is can WhatsApp load a picture from Google Drive. Modern Android devices have Content Providers for SMS, MMS and many other pieces of information.

The sdcard is a special Content Provider that is accessible by any application at any time. It is used by ALL applications and considered an insecure place to put data. The content:// URI is a way to access the content provider data via a URL. This is supported within the chrome browser even!

The Same Origin Policy (SOP) dictates that content that JavaScript can access. If the protocol, domain or port is different, then it is consider a With local files, SOP is more restrictive; each path is considered its own origin.

On Android for Chrome, this protection is NOT implemented though. So, data loaded from one page can be used to access any data under /sdcard/Android. With devices NOT running scoped storage per app, this is a serious vulnerability.

Although this is a Chrome vulnerability, it has direct impact on WhatsApp; just click a link in WhatsApp! WhatsApp stores TLS session information within the /sdcard directory. By using the Chrome vulnerability, an attacker can steal the Pre Shared Key (PSK) for TLS 1.3 and steal the Master Secret on TLS 1.2. By stealing these secrets, WhatsApp can be MitM'ed even when the application believes it is being done securely.

This scoping issue is NOT just possible to exploit from Chrome via the content URI. Another application could have done this in order to snoop on the E2E traffic. With a MitM position (assumed throughout this article) and the TLS secrets leaked, the next step is to get code execution.

When a user gets a photo filter or doodle emoji on WhatsApp, the content is delivered through a zip file with a specific name. When the zip file is being extracted, it does not sanitize the name for directory traversal bugs. So, if this process can be hijacked, we have an arbitrary file write vulnerability.

The WhatsApp client stores its DSO (dynamic shared objects) libraries within the data directory. So, simply overwriting one of these libraries (such as SoLoader) is sufficient. With control over a library, this is game over.

An additional vulnerability was found though. WhatsApp uses end-to-end encryption (E2E) by using the Noise protocol. Being able to steal the Noise protocol keys would allow for the complete compromise of the communication via a MitM.

When WhatsApp encounters an OutOfMemoryError within the first few days of a release, the entire application heap is sent to a WhatsApp server for debugging. Guess what is in this heap!? Noise keys!

By purposely inducing a MemoryError by sending a VERY large response to a request, this data is sent over the network... leaking the keys!

The WhatsApp issues appear to be unexploitable because the data is normally controlled by the server. However, the MitM breaks this assumption it makes the directory traversal possible.

Additionally, the addition of the defense-in-depth measure of isolated sdcard directories make this vulnerability much less impactful. So, good job Android!