Skip to content

Instantly share code, notes, and snippets.

Last active Aug 6, 2018
What would you like to do?

Vungle Arbitrary Write Vulnerability

The Vungle advertisement library is distributed as a .jar that developers can include into their application. When a developer utilizes this SDK, their application becomes vulnerable to a remote arbitrary file write vulnerability. The following is a brief synopsis of the vulnerability:

We can set up a man-in-the-middle attack against the phone to proxy the device network traffic and see what traffic is being sent by the application.

        ← 200 application/json 967B 947.36kB/s

In the JSON response, we can see the server tell the app where to download additional zip resources that contain the video advertisements displayed throughout the application.

    "postBundle": ""

Shortly thereafter, we see this zip being downloaded:

       ← 200 application/zip 292.45kB 1.97MB/s

This ZIP file is downloaded in plaintext and there are no further mitigations to prevent tampering with the file. The Android ZIP APIs do not prevent directory traversals by default, allowing for file injections with a directory traversal on-the-fly into the ZIP. This allows us to gain an arbitrary write in the context of the app. With this, we can easily write a script for a proxy that will inject our payload on-the-fly into the zip. Let's test this out by downloading the payload using our zip injecting proxy:

$ curl -x http://localhost:9999 >

Now, let's look at the files in the zip we downloaded through our proxy:

$ unzip -l
  Length     Date   Time    Name
 --------    ----   ----    ----
    28036  12-27-13 09:06   app_icon.jpg
     3807  12-27-13 09:06   app_store.gif
    28250  12-27-13 09:06   download_arrow_minimal.png
    21153  12-27-13 09:06   exit_button_down_minimal.png
    20159  12-27-13 09:06   exit_button_minimal.png
     3426  12-27-13 09:06   index.html
    69878  12-27-13 09:06   landscape.jpg
    63430  12-27-13 09:06   portrait.jpg
     1182  12-27-13 09:06   postroll-script.js
    11599  12-27-13 09:06   postroll-style.css
    21834  12-27-13 09:06   replay_button_down_minimal.png
    20521  12-27-13 09:06   replay_button_minimal.png
    20564  12-27-13 09:06   star_empty.png
    19843  12-27-13 09:06   star_full.png
    20225  12-27-13 09:06   star_half.png
     5433  12-27-13 09:06   vungle_logo.png
        4  01-01-80 00:00   ../../../../../../../../../../../../../../../../../../../../../../data/data/com.outfit7.mytalkingtomfree/code_cache/secondary-dexes/i_wrote_files_here_which_is_bad
 --------                   -------
   359344                   17 files

Notice here that the zip was injected with a directory traversal that writes inside of the app directory. During the attack, we can see that our files were written in the application’s data directory. This directory is only writable by the application that owns it:

root@hammerhead:/data/data/com.outfit7.mytalkingtomfree/code_cache/secondary-dexes # ls -l | grep i_wrote
-rw------- u0_a188  u0_a188         5 2014-10-17 17:55 i_wrote_files_here_which_is_bad

Our dummy payload was successfully extracted by Vungle. Now, we need to turn this file write into something more useful.

Mitigations and Closing Thoughts

Plaintext traffic

All traffic between clients and servers should encrypted and authenticated. TLS (Transport Layer Security, previously SSL) should be used for all communications between the client and the server including for file downloads such as ZIP files. Attacks like this can be mitigated best by employing TLS.

Validation of Zip files

The default behavior of Android's Zip library is dangerous. In order for the zip to write files outside of the target extraction directory, an additional flag should be provided. Let's consider how the GNU unzip handles a zip file with a directory traversal:

Here is an example of a zip file that includes a relative directory traversal:

➜  ~  unzip -l
  Length      Date    Time    Name
---------  ---------- -----   ----
     1025  2014-11-10 14:55   ../../../../../../../../some/random/path/bin
---------                     -------
     1025                     1 file

When we try to extract this zip file with GNU unzip, it strips off any dangerous components and extracts inside of the current working directory:

➜  ~  unzip
warning:  skipped "../" path component(s) in ../../../../../../../../some/random/path/bin
 extracting: some/random/path/bin
➜  ~  ls -l some/random/path/bin
-rw-r--r-- 1 fuzion24 fuzion24 1025 Nov 10 14:55 some/random/path/bin
➜  ~  ls some/random/path/bin

There exists a flag to allow GNU unzip to extract files outside of the active extraction folder tree head.

➜  ~  unzip -:
 extracting: ../../../../../../../../some/random/path/bin

From man unzip we can learn more about this flag:

       -:     [all but Acorn, VM/CMS, MVS, Tandem] allows to extract archive  members
              into  locations outside of the current `` extraction root folder''. For
              security reasons, unzip normally removes ``parent dir'' path components
              (``../'')  from  the names of extracted file.  This safety feature (new
              for version 5.50) prevents unzip from  accidentally  writing  files  to
              ``sensitive''  areas  outside  the  active extraction folder tree head.
              The -: option lets unzip switch back to its previous, more liberal  be‐
              haviour,  to  allow  exact  extraction  of  (older)  archives that used
              ``../'' components to create multiple directory trees at the  level  of
              the  current  extraction  folder.   This option does not enable writing
              explicitly to the root directory (``/'').  To achieve this, it is  nec‐
              essary  to set the extraction target folder to root (e.g. -d / ).  How‐
              ever, when the -: option is specified, it is still possible to  implic‐
              itly write to the root directory by specifying enough ``../'' path com‐
              ponents within the zip archive.  Use this option with extreme caution.
Copy link

please my friend give me a soltuion
google play sent me this text
We remind you that your application uses a version of the Vungle ad library that has a security vulnerability.

Please install Vungle 3.3.0 or later for your application as soon as possible. As of November 11, 2015, we will no longer accept application updates or new apps containing versions of Vungle prior to version 3.3.0 on Google Play.

To check which version of Vungle you have, you can run a grep search on "VungleDroid /". You can download the latest version of Vungle from the Vungle website. For help with updating, check out this Vungle Support page.

To ensure that the update has been completed, post the updated version of the application to the Developer Console and run a test after five hours. If the update was not done correctly, a warning will be displayed.

This vulnerability can allow hackers to launch a "man-in-the-middle" attack against the user's devices via proxy network traffic and injecting a load extracted by the Vungle application. To learn more about the vulnerability, go to If you have other technical questions, post a message at using the tags "android-security" and "Vungle".

Although these specific issues do not necessarily affect all applications that use Vungle, we recommend that you keep yourself informed about security patches. Applications that have vulnerabilities that could compromise user security may be considered unsafe products that violate Program Policies (for developers) or Section 4.4 of the Distribution Agreement (for developers).

Applications must also comply with the Distribution Agreement (for developers) and Program Policies (for developers). If you believe we've sent you this warning in error, you can contact our support team through the Google Play Developer Help Center.

Relates to version 3 of the APK file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment