# Exploit for all Android Custom Recoveries with /data/Media



## Indirect (Sep 7, 2011)

Well, while I really hate to do this write up right now regarding one of my favorite recoveries. I feel as though it is needed to continue the development in security in the Android community.

Exploit: File permissions error ( General filesystem fault) on Android custom recoveries.

Software(s) affected: TWRP 2.*, CWM (possibly. Need more testing) {Only on /data/media devices [that we know of] }

This exploit is very simple but I would also class it as critical as it can compromise all userdata and binaries in the system. I have talked with Teamwin and they will implement a fix when they can. Not sure on the status of CWM as koush didn't respond before the write up.

Exploit information / disclosure:
When we look at the backups in TWRP / CWM, we normally just see our data. Well, unfortunately there is also a read / write permission ready for any user / app to come along and analyze, modify, and even use our backups as a method to exploit and gain system privileges on our device. This can easily be attacked but not quite so easily patched. The only real way myself or the developers of TWRP can think of how to fix it is using encrypted backups. With this in the works as of now the software is still vulnerable and a piece of malware could come along and hijack your backup / propagate itself in a worm like function to your roms. 
Now, is this an absolute terrible vulnerability? No. It's completely conditional but still enough to be considered a security flaw. This is why I like SDcards. It has to be written to through API calls (as far as I'm aware). With this exploit, I can just write to /data/media like it's nothing from any app as the system doesn't see the recovery folder as media_rw. It sees it as: drwxrwxrwx root root TWRP

What everyone that knows that linux permissions are and how they work can see 2 things. 1) That's a system owned directory.
2) I have read, write, execute permissions IN that system owned directory. 
This can lead to the result of "Hey, I can learn where their backups are and just add a payload to the system and let it be owned by root which can cause some fun things when the user restores the system (replace something as simple as su or chmod) or even replace su to no longer call to Superuser.apk and then have another payload run as root directly. 

While this all seems scary, it's not the end of the world. This exploit can be patched once someone pushes the necessary code to TWRP as well as an update gets released for it. 

All in all, a simple vulnerability with root folder permissions becomes a very scary exploit that can lead to destroying a system, local privilege escalation, and even to malware propagating. 

PoC:
#!/bin/sh
cd /data/media/TWRP/BACKUPS/{Redacted}/Stock/
mkdir extracted; cd extracted
tar xf system.ext4.win; cd ..
dd if=/data/media/payload.bin of=/data/media/TWRP/BACKUPS/{Redacted}/Stock/extracted/xbin/payload; chmod 755 /data/media/TWRP/BACKUPS/{Redacted}/Stock/extracted/xbin/payload
tar -cvwf ./extracted/ system.ext4.win
md5sum system.ext4.win > system.ext4.win.md5

Shout outs:
remicks - He's a jerkface but I owe him quite a bit (and it's his birthday today)
couga - For managing to help me disclose this to the devs while I was in class
Dees_troy - For listening to the disclosure and discussing it with me.

Twitter - @xIndirect
XDA Profile - Indirect
RootzWiki Profile - Indirect


----------



## yarly (Jun 22, 2011)

I think it's great that you're trying to bring more mainstream attention to the fact that external storage has always allowed reading without explicit permissions. Most users "throw caution into the wind" when it comes to what they install and what they do on their phones, so maybe someone will read this and think a bit more.

I do have a few comments though just in regards to your post.



> When we look at the backups in TWRP / CWM, we normally just see our data. Well, unfortunately there is also a read / write permission ready for any user / app to come along and analyze, modify, and even use our backups as a method to exploit and gain system privileges on our device.


I wouldn't exactly call it an exploit so much as lazy/naive development, since it's always been known that you can read anything external storage in Android without explicit permissions and developers should know better than store anything sensitive in cleartext on the external storage (though many do not, including some financial institutions and such). That was true until an droid 4.1 added that permission, but it's still off by default unless you enable it under development options. Enabling it though would probably screw up some apps that are more legacy though (until disabling once again).

Any backup app, not just ROM backups would be potentially vulnerable as well. That would include things like titanium backup for apps or even Google's built in backup system into Android if the encryption option is not enabled (the one used via adb recently added).



> This is why I like SDcards. It has to be written to through API calls (as far as I'm aware).


Nope, doesn't have to be as far as I know if you execute a script. Pretty sure you can write to sdcard in a command line shell script without permissions (one that is not using su). Just have to create a process in the app and execute the script. I will verify later though. Most users would probably not even notice or care if it required write permissions though explicitly for external storage, especially if the app they are using looks like it needs them (which could be nearly any app, since external storage is used for a billion things).



> All in all, a simple vulnerability with root folder permissions becomes a very scary exploit that can lead to destroying a system


I know the above didn't require root to inject the "payload," and if a user restores that backup, they're screwed. However, when one runs their phone as root, it's already making the device inherently less secure since users are tend to blindly give root permissions to apps without considering what they might do. This is just one vector of attack, but theres many others, given how most ROM developers are not thinking about how secure their ROM is in the first place. If I were a malware writer, I would just start looking for crummy code hacks in third party ROMs out there if I were wanting to go spear fishing against root users.

It's also rather shocking how users will blindly flash just about anything put up by anyone (themes or mods that one flashes in recovery) without verifying where it comes from.


----------



## Indirect (Sep 7, 2011)

This is through /data/media. While they're merged as a filesystem, I can still write to /data/media without a user needing sdcard mounted. Its hard to explain.

Sent from my Nexus S 4G using RootzWiki


----------



## yarly (Jun 22, 2011)

Indirect said:


> This is through /data/media. While they're merged as a filesystem, I can still write to /data/media without a user needing sdcard mounted. Its hard to explain.
> 
> Sent from my Nexus S 4G using RootzWiki


I know what you mean, I have a GNexus, but maybe we're having a miscommunication. I have not had an sdcard phone since Android 2.3 (still have one, but have not used it in months and still uses 2.3), but from what I recall, your sdcard is always mounted when it's inserted into the sdcard slot and Android is totally booted up.

Going on my assumption above, a rogue app would be able to do something like

// save exploit.sh somewhere

```
<br />
#!/bin/sh<br />
cd /mnt/sdcard/TWRP/BACKUPS/{Redacted}/Stock/<br />
mkdir extracted; cd extracted<br />
tar xf system.ext4.win; cd ..<br />
dd if=/mnt/sdcard/payload.bin of=/data/media/TWRP/BACKUPS/{Redacted}/Stock/extracted/xbin/payload; chmod 755 /mnt/sdcard/TWRP/BACKUPS/{Redacted}/Stock/extracted/xbin/payload<br />
tar -cvwf ./extracted/ system.ext4.win<br />
md5sum system.ext4.win > system.ext4.win.md5
```
// then in Java:


```
<br />
ProcessBuilder pb = new ProcessBuilder("exploit.sh");<br />
pb.directory(new File("/path/to/exploit"));<br />
pb.start();
```
EDIT: My previous statement about your code not needing root permissions is incorrect, it does or it cannot access /data/media. Denying root perms would stop it (if using /data/media).


----------



## Indirect (Sep 7, 2011)

When run by the sdcard you have permissions that look like this: [email protected]:/ # ls -l /sdcard/ | grep TWRP | awk '{ print $1, $2, $3, $6 }'
ls -l /sdcard/ | grep TWRP | awk '{ print $1, $2, $3, $6 }'
drwxrwxr-x root sdcard_rw TWRP
[background=rgb(251, 248, 244)]While in /data/media it is this:[/background]
[email protected]:/ # ls -l /data/media | grep TWRP | awk '{ print $1, $2, $3, $6 }'
awk '{ print $1, $2, $3, $6 }' <
drwxrwxrwx root root TWRP

The major problem is that the files are viewable and changeable while owned by root but theoretically could be abused by rogueware.

The sdcard_rw is the file / group for the sdcard and media_rw should be there in /data/media


----------



## yarly (Jun 22, 2011)

I guess I need to show you code to show you what I mean. Pretend the following is some random malware app a user installs. Even if your sdcard was not mounted, all one has to do is mount it if you have root, so it's sort of moot whether it is or isn't when it's in the phone sdcard slot. I didn't add that command to the below, but easy enough to do so.

Stick this in a blank android app project (no additional permissions required, but you may want to have it keep the device awake), change the ID and current backup dir accordingly and compile + run it:

http://pastie.org/pr...k6xwkigps4ntf4q

It'll do the same thing your little script does above, only it doesn't matter if you point it to /data/media or /sdcard

Note that it'll take a while to tar and untar and may say it's not responding, though it's still running fine.


----------



## Indirect (Sep 7, 2011)

Oh alright, that's a lot easier to get! Sorry on my inability to understand, been sick for 3 weeks.







anyway, I might make a PoC worm to attack backups just to show how insecure it is. This should get them to handle sd's differently.









Sent from my Nexus S 4G using RootzWiki


----------



## JBirdVegas (Jun 11, 2011)

not sure how encrypting backups would help as the key would still be available somewhere (TWRP/CWR are open source and the key's location and decryption process would be documented and understood by the community) ... its not like you can pull the key from the web when you're in recovery.

don't get me wrong encryption of backups is a GREAT idea.


----------



## yarly (Jun 22, 2011)

JBirdVegas said:


> not sure how encrypting backups would help as the key would still be available somewhere (TWRP/CWR are open source and the key's location and decryption process would be documented and understood by the community) ... its not like you can pull the key from the web when you're in recovery.
> 
> don't get me wrong encryption of backups is a GREAT idea.


The easiest way is use a method that provide a strong form of hashing for the password (like sha-512 + some unique salt, perhaps based off the android id and some other things).

1) User enters password 
2) Password is hashed
3) User comes back later to unencrypt data
4) User reenters password and it's hashed in the same way as it was before
5) hashes are compared for equality

Truecrypt does something like what I mentioned for hashing:

http://www.truecrypt.org/docs/?s=keyfiles-technical-details
http://www.truecrypt.org/docs/?s=header-key-derivation

The other way is through public key encryption (like RSA)

http://en.wikipedia.org/wiki/Public-key_cryptography


----------



## Indirect (Sep 7, 2011)

And J, just because something is known doesn't make it crackable; look at some of the algorithms out know.

Sent from my Nexus S 4G using Xparent ICS Blue Tapatalk 2


----------



## JBirdVegas (Jun 11, 2011)

I was thinking encryption without user interaction but I follow now.


----------

