Exploiting the way data is stored on SD cards in order to access it is what Georgia Weidman elaborates on here, explaining the corresponding demo in detail.So far we have talked about evil Android guy with horns, evil application that wants to hurt you, and it’s malicious. When you download it, it’s going to exploit you in some way. But now we’re going to switch gears and talk about this green little guy – normal Android, not scary at all. Android is awesome. I pick on Android a lot in this talk, but Android is my favorite platform by far. I often say I want to throw the iPhone across the room, and as a developer I do, it’s hard to develop for the iPhone. It’s easy to develop for Android; they make it very simple for programmers to do lots of cool functionality.
So, a lot of people are developing for Android. And with that comes the caveat, because Android’s got some new things in it. If you’re a secure developer, you’ve thought a lot about how to stop buffer overflows, SQL injections, things you’re used to. Now you’ve got content providers, and activities, and services, and intents. You’re not used to these, these are new. These are things that might have some security caveats we’re just not used to as secure developers, as a security community, that are just open and we’re not sure how to deal with it yet, which is a lot of what you run into – people who just don’t know, because it’s the new stuff.So, first off the simple stuff, the stuff that we should be thinking about – Android Storage.
Android apps are cool because every application has its own user ID; this is a Linux model and it’s read-only by default. The only person who can see your data is you because you’re the only one with this unique user ID. Other applications on the phone cannot see it.
The problem comes in when you want to share it, of course. A good place to store things is the SD card; we store all our pictures, and our music, and other things there; and when people switch phones they can still have that with them.
There is a problem with the SD card though. It’s VFAT. If anyone is familiar with VFAT, it’s read-only…no, it’s not read-only, not anymore. It’s world readable, so anyone can see anything you put there, any app. And if you still store it on the internal storage and you want to share it with someone else, naturally the idea goes to: “Let’s just make it world readable, no one will know the filename, who cares?” Not so much.
So, naturally, seeing this stuff I thought: “How hard would it actually be to steal data from another application?” So I wrote one. We’ve got more up-to-date Android platform, and iPhone. And we’re going to look at 2 applications; we’re going to look at one that stores data in an insecure manner, and we’re going to look at another application that steals that data.
You may not be aware of this, but after you install applications, you can still see all the permissions they ask for if you go to settings. You think that you just see it upon install and you say: ‘Yes’, and that’s it, and you’re stuck with it, but you can actually see it all.
I’m going to look at an app called BadFileSave, which no one would ever install of course. They want to modify and delete USB storage contents, so they can write to the SD card, and they want to read the phone state and identity, so they want that IMEI number. You might be able to see where this is going: they want to read it and they want to write it somewhere as world readable all the time. That sounds like a recipe for disaster.
Then I have another application BadSendFile. It does not ask for access to the IMEI number, so it should in no way ever be able to access it, and certainly not be able to send it to another phone, but it asks for the ability to send SMS messages. So, again, you might see where this is going. This should not be able to access the IMEI, but it does have the ability to send SMS. So, I wonder what’s going to happen when I call it.
Let’s see what happens. I call BadSendFile, it says: “Hello Android, I am an evil app;” it can have any app it wants here or no GUI at all, it could be just a service in the background, and I see that my IMEI has been sent to the iPhone. So, data it should not have had access to, it was able to access. Rather straightforward example here.So, basically our green guy is our good application. It stored its sensitive data on the SD card; this need not be the IMEI, this could be usernames and passwords, encryption keys, anything else that we might want to keep others from seeing not just on the SD card storing as world readable, inside of the actual Android storage it would work the same way. As long as you have the filename, you can then access it. SD card is world readable, so since we stored it there, we’re able to see it. Here comes the bad guy with the evil horns. He discovers how the data is stored, finds out that it’s stored on the SD card; anybody can read the SD card, we don’t have to ask for permission. We saw in the demo that it only asks for SMS, it didn’t ask for information, it asked permission to read SD card, whereas the other one asked for write to SD card, anyone can by default read from the SD card. So anyone can see your pictures from last night in the app on your phone, just saying…Maybe you want that app that deletes them, who knows.
And then it sends it to the attacker via SMS, which it asked for that permission, so it has that ability to do so, not doing anything evil there. It has the ability to read anything from the SD card, it has the ability to send SMS, so technically this didn’t actually exploit you.