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.
POST http://api.vungle.com/api/v1/requestAd
← 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": "http://cds.g8j8b9g6.hwcdn.net/bundles/526956a8584cbfa904000010-4.zip"
...
}
Shortly thereafter, we see this zip being downloaded:
GET http://cds.g8j8b9g6.hwcdn.net/bundles/526956a8584cbfa904000010-4.zip
← 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 http://cds.g8j8b9g6.hwcdn.net/bundles/51508704e2903eb17f000006-2.zip > tmp.zip
Now, let's look at the files in the zip we downloaded through our proxy:
$ unzip -l tmp.zip
Archive: tmp.zip
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.
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.
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 evil.zip
Archive: evil.zip
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 evil.zip
Archive: evil.zip
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
some/random/path/bin
There exists a flag to allow GNU unzip to extract files outside of the active extraction folder tree head.
➜ ~ unzip -: evil.zip
Archive: evil.zip
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.
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 https://gist.github.com/Fuzion24/6535f8b9dc2a51745173. If you have other technical questions, post a message at https://www.stackoverflow.com/questions 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.