In this part, Georgia Weidman breaks insecure data storing down to the code level, explaining code samples behind sensitive information access.
Something interesting about Android is that if you want to exploit the Android, really, just google online: “How do you send someone’s IMEI to yourself via text message?” And there are code examples that will show you exactly how to do that. It’s not exploitation, you asked for the permissions – this isn’t evil. It’s hilarious, really. The stuff you can find on the Internet, even if you don’t know how to code in Java, will show you how to do this. And then, it stores it to the SD card in a file called IMEI string filename. That’s not a very good filename, because that pretty much says exactly what’s in there.And then, BadSendFile, knowing that it’s called IMEI, reads from the SD card, which is a default permission because it’s not considered scary, and then reads what’s in that file and sends it via SMS – since it has that permission, it can do so (see image). So it sends an SMS, and as a former baseband programmer who wrote kernel codes to send SMS, being able to do it in 3 lines here is really awesome. But wait. We relied on one little caveat here: we knew what the filename was. How did we know that? How did we know what they were storing there and what it was called? It’s actually quite simple, using open source tools, to basically get the source code out of an Android app. There’s talks on reversing Android apps that do a lot better job than this, but it is for the basics to get the source code out and review it. You can do it just with these 3 tools here: you unzip the APK and you use a free tool that is on Google code called dex2jar that will reverse it back to source code from the compiled Java code; and then open it up in the tool called jd-gui which will show you the source code. These slides are online at my slideshare.net/GeorgiaWeidman, and there’s a link to the white paper that describes all this. It takes a malware sample and shows all this, reversing the malware and looking at what it’s doing. So, if you’re interested in malware reversing, this would be a good place to start with this paper.
For instance, this is Facebook, I said that I have read the source code for Facebook – this is how (see upper part of the image). Very big app there, it does a lot of things. And then, this is DroidDream (bottom part); you don’t see this very well, but there’s some nonsense here, so the caveat here is this isn’t 100% perfect; sometimes it gets it wrong, there are more sophisticated ways of reversing Android; but just to get the basics you can do this in, like, a minute and a half and get basically the entire source code. If you can’t see, it basically says ‘rage against the cage’ up there, which generally gives me an idea of exactly what this is doing; and then it wants to go to /system/bin/sh and run that.Even though this is not 100% correct, just looking at this, like, a minute and a half after I download it I can generally get the idea it wants to use the ‘rage against the cage’ exploit and then run it.
And then we get something wrong: it says: while (true) if (i<0), while (true) again and then return, and then do some other stuff, but of course after we’ve returned, we won’t ever do any other stuff. So I sat there and thought: "What is this? This is really weird code; I’ve never seen anything like this before." And then my Mom walks by and she’s like: "Wow, your decompiler sucks!" And this solves my problem of what this means: my decompiler was not completely 100% correct. But it did give me the gist of it, and I’ve never come into a time where it wouldn’t give me filenames and such. So this will definitely get you what you need for this sort of attack. [caption id="attachment_11161" align="alignleft" width="200"]Secure data storing tips[/caption] Mitigation for storing things incorrectly – just store things correctly. You have a really good model here: you can store things securely because you only have your user ID and no one else can see it but you.
So don’t store things on the SD card, that’s VFAT, we don’t like that. Don’t store them in the source code, because that’s what we saw: we might get those strings back again. And don’t store them world readable. If you want to share them with others, you can share user ID or you can store them in the SQLite database and share it. But don’t share them these ways, this is bad.