No-permission Android App Gives Remote Shell(viaforensics.com)
viaforensics.com
No-permission Android App Gives Remote Shell
http://viaforensics.com/security/nopermission-android-app-remote-shell.html
3 comments
So there's a way to establish two-way communication with an Android device, without enabling any permissions. But it's a very obvious system (works by launching intents, just like every other Android function), so it's hardly something that would work in any kind of stealth mode. Interesting hack, but not really as serious a vulnerability as the name might suggest.
So you demonstrate a confused deputy attack on Android? This is hardly news.
Not very interesting if you don't tell me how it's done...
The've since added a link http://www.defcon.org/images/defcon-18/dc-18-presentations/L... to a presentation describing many of the basic ideas, for how apps can do things that they haven't been granted explicit permission to do.
The basic problem is that the permissions model is very leaky; there are lots of ways to work around it, by sending intents to other apps that have more permissions, by relying on certain OS services to call you in a more privileged way, by providing custom notifications that display on top of everything, and so on.
For instance, even if you don't request internet permissions, you can still open a URL, with whatever data you want to send encoded in the URL; and you can even do this in sneaky ways that the user can't detect if you're careful (only doing so when the screen is off, for instance, and redirecting to Google so they don't see anything odd when you turn the screen back on). And you can register a URL handler, that the page can redirect to, to communicate back to your app.
The basic problem is that the permissions model is very leaky; there are lots of ways to work around it, by sending intents to other apps that have more permissions, by relying on certain OS services to call you in a more privileged way, by providing custom notifications that display on top of everything, and so on.
For instance, even if you don't request internet permissions, you can still open a URL, with whatever data you want to send encoded in the URL; and you can even do this in sneaky ways that the user can't detect if you're careful (only doing so when the screen is off, for instance, and redirecting to Google so they don't see anything odd when you turn the screen back on). And you can register a URL handler, that the page can redirect to, to communicate back to your app.
According to the linked presentation the app sends data by opening URLs in the web browser (which is obvious to the user unless the device is locked). It receives data by having the browser open URLs using a custom URL scheme (which can apparently be registered without any permissions).
What was that python reverse program and if that's running then the device is in debug mode (since it's an emulator maybe it's always in debug mode?). So I'm left wondering what does this prove?
The python program was simply the server the attacker sets up. It could be run on any machine connected to the Internet and then accessed by the shell program from the user's device. The emulator and server were run on the same machine to make it easier to record the screencast, but the method works just the same on a real device and a remote server. There is nothing really difficult about how it is done, it is explained in the linked presentation, it is just a nice demo of it.
I guess I need to go back and review the whole presentation, I stopped about half way through. Thanks.
I'm currently building an app that only uses the permission for internet access, but it's also using basic functionalities of the OS for managing specific types of public files that might be on the SDCard or not depending on the device, in my case it's pictures through the Media ContentProvider.
I'm guessing the exploit in the article is pushing this method to the next level.
I'm guessing the exploit in the article is pushing this method to the next level.