Exploiting the Dolphin Browser for Android’s Backup & Restore Feature

try {
v1_2 = new ZipInputStream(((InputStream)v3));
}

try {
File v0_6 = new File(this.b.getApplicationInfo().dataDir);
while(true) {
ZipEntry v2_1 = v1_2.getNextEntry();
if(v2_1 == null) {
break;
}
BufferedOutputStream v2_2 = new BufferedOutputStream(new FileOutputStream(new File(v0_6 + File.separator + v2_1.getName())));
IOUtilities.copy(((InputStream)v1_2), ((OutputStream)v2_2));
v2_2.flush();
v2_2.close();
v1_2.closeEntry();
}
}

try {
label_129:
Log.e("BackupHelper", ((Throwable)v0));
throw new a(((Throwable)v0));
}
catch(Throwable v0_4) {
goto label_135;
}

<activity android_configChanges="keyboard|keyboardHidden|orientation|screenSize" android_name="mobi.mgeek.TunnyBrowser.BackupRestoreActivity" android_theme="@android:style/Theme.NoTitleBar"/>

Alright, now I was getting somewhere. After playing around with the Backup and Restore feature, I was able to extract the following information about its functionality.

• Basic browser settings can be saved and restored
• The default location for the backup file is always /storage/emulated/0
• The backup file has a custom file extension -> .dbk
• Setting a password on the backup is not required
• The backup’s name is [ year:month:day:time ]
• When you try and restore a backup, the browser will always access the most recently generated backup

The most important piece of information I was able to extract, was that the backup file was indeed the zip archive being processed in the vulnerable code, which results in the file write vulnerability!

Backup File Format

Encryption

After continuing to reverse engineer the backup file, I quickly figured out that the backups were being encrypted. However, this also had a flaw in its implementation. The browser encrypts the backup by handling two possible scenarios.

• Password set
• Password not set

If a password is set for the backup, first, that password is concatenated with a static key, then, the resulting string is hashed, and finally, the bytes from the hash are padded with 0x10 extra bytes and passed to the SecretKeySpec()constructor. If a password is not set, the entire process is exactly the same, except in the place of the password, another static key is used.

Header

The backup file also includes a custom header, which during the restoration process is used in order to verify that the file being restored is a legitimate backup created by the browser.

0D00010F 01000000 00010000 [sig]

The 0D00010F value can be considered the backup file’s magic identifier. The header also includes a signature directly after the value 00010000. The signature is generated through the same encryption implementation used for the backup file itself.

Finally we take the header’s contents and generate a CRC checksum, which is then appended to the file after the signature

0D00010F 01000000 00010000 [sig] [checksum]

When a backup file is restored, a CRC checksum is generated from the file’s header and then compared against the appended CRC checksum after the header’s signature. If these do not match, the restoration process is aborted.

Now we know how to generate a valid backup file.

Backup File Generation

• Create a new zip archive containing our desired contents
• Append the header to the zip archive -> 0D00010F 01000000 00010000 [sig]
• Append the header’s checksum
• Encrypt the archive

Exploitation

File Write Targets

Having an arbitrary file write primitive in the context of an Android application is only as good as the files the application includes in its package. I typically look for the following when I am trying to turn a file write into code execution:

• DEX
• JAR
• ELF

Luckily the Dolphin Browser includes a great target for our file write primitive.

/data/data/mobi.mgeek.TunnyBrowser/files # ls -la
...
-rwxr-xr-x u0_a195  u0_a195      9496 2017-12-12 14:26 watch_server

$ file watch_server
watch_server: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, stripped

We should have zero problems overwriting the watch_server with something we control in the backup file, but how and when is the watch_server executed by the browser?

watch_server

In order to figure out when the watch_server is executed, I simply searched through the browser for Runtime.getRuntime().exec() references. I found that the watch_server was getting executed every time the browser was launched! Talk about persistence and energy.

Proof of Concept

The biggest caveat to exploiting the Backup and Restore feature in the Dolphin Browser is the requirement for user interaction. The victim must restore a malicious backup that we’ve created and written to the sdcard. I wasn’t able to find a way to trigger the restoration process via IPC or through other means. The only upside to this fact, is the ability to potentially control which backup is selected.

• The backup’s name is [ year:month:day:time ]
• When you try and restore a backup, the browser will always access the most recently generated backup

After the restoration process is finished, the browser does a quick restart, which immediately executes our payload!

./build.sh
[+] Building ... [!]
[armeabi-v7a] Install        : payload => libs/armeabi-v7a/payload
[+] Creating tmp.zip and injecting payload [!]
[+] Launching backup file format generation [!]
[+] Generating cipher [!]
[+] key --> 95acde261f3e09d281498163958dd366
[+] Building backup  --> ./backup.dbk [!]
[+] Encrypting and saving backup [!]
[+] Cleaning up [!]
[+] Pushing backup.dbk to the device [!]
backup.dbk: 1 file pushed. 1.0 MB/s (13926 bytes in 0.014s)
[+] Waiting on restore process ... [!]
--------- beginning of system
--------- beginning of main
V/FlipperFlapper(14975): uid=10195(u0_a195) gid=10195(u0_a195) groups=1015(sdcard_rw),1028(sdcard_r),3003(inet),9997(everybody),50195(all_a195) context=u:r:untrusted_app:s0

https://github.com/VerSprite/research/tree/master/exploits/VS-2017-001