Gaining a Remote Shell On Android 124
SharkLaser writes "The security of Android devices has come under scrutiny in recent months. Android Market has been plagued with a number of trojaned apps, and researchers have identified various root exploits and permission leaks that can be exploited, for example, to send premium rate SMSs. Now researcher Thomas Cannon of ViaForensics is demonstrating a method for setting up remote shell on an Android device without using any exploits or vulnerabilities. The security hole is not new, and it has been pointed out for a number of years, but Google has yet to fix it. The method works on various versions of Android, up to and including the newest Ice Cream Sandwich."
Direct link to Vimeo How-To (Score:5, Informative)
No vulnerabilities? (Score:5, Informative)
Unintended root access is a vulnerability by definition.
Re:No vulnerabilities? (Score:5, Informative)
This doesn't give root, it just allows you to run a command within the context of the installed app. The app launches the web browser to pass data to and from a middleware server. So if the app itself doesn't have any specific access (including network access) it can still transfer data through launching a browser session.
It's more of a conscious decision by the android team. If you allow an application to launch an URL, then of course it can transfer data through the http session. However not allowing apps to launch a simple URL link would be very limiting, so they chose not to do that. I'm not sure there's a fix really, as this is a classic security / convenience problem.
Re:TFA is blank (Score:5, Informative)
No-permission Android App Gives Remote Shell
I have been working at viaForensics as the Director of R&D for about 5 months now, and in that time I’ve been involved in some exciting research projects. I haven’t had the opportunity to blog on our company site yet so I thought I’d take a little time out and record a video to demonstrate an Android issue that is of interest to many of our clients.
When talking with people and reading posts on the web I’ve often heard people say that the Android permission system protects their device such that apps without certain permissions are therefore safe to install. The permissions system on Android is a fantastic idea and generally well implemented, it gives apps just enough permissions or capabilities to perform the required functions without exposing capabilities that could be used in a dangerous way. It is a step up in protection when compared with a typical desktop system but this increased protection can give rise to a false sense of security.
Putting aside the issue of users ignoring the permissions when installing apps, can we rely solely on permissions to decide if an app is safe? There are multiple controls in Android and its ecosystem that protect a user and their device, but one should not automatically assume that installing an app, even if it requires no permissions, is safe.
To demonstrate this we’ve built an app which requires no permissions and yet is able to give an attacker a remote shell and allow them to execute commands on the device remotely from anywhere in the world. The functionality we are exploiting to do this is not new, it has been quietly pointed out for a number of years, and was explained in depth at Defcon 18 [1]. It is not a zero-day exploit or a root exploit. We are using Android the way it was designed to work, but in a clever way in order to establish a 2-way communication channel. This has been tested on Android versions ranging from 1.5 up to 4.0 Ice Cream Sandwich, and it works in a similar way on all platforms.
Please see the video below with accompanying audio for further explanation.
Link to video: Android No-permissions Reverse Shell
I should also mention here a recent paper by Michael Grace, Yajin Zhou, Zhi Wang, and Xuxian Jiang from NCSU who have developed a tool to detect capability leaks in Android devices. Using their tool they found a number of capability leaks, such as being able to send an SMS, in various Android applications usually added by OEMs. Malicious applications can call the vulnerable apps and exploit the lack of protection around permission/capability use and therefore do not need to request permissions themselves. In a similar way we’ve exploited the Android Web Browser, although we are not exploiting a vulnerability due to bad coding, but rather using the functionality it legitimately offers to other applications.
In this demonstration Android’s power and flexibility were perhaps also its downfall. Other smartphone platforms may not offer the controls we are bypassing at all, and the multi-tasking capabilities in Android allowed us to run the attack almost transparently to the user. This power combined with the open nature of Android also facilitates the customisation of the system to meet bespoke security requirements. This is something we have even been involved in ourselves by implementing a proof of concept Loadable Kernel Module to pro-actively monitor and defend a client’s intellectual property as it passed through their devices. It is no surprise that we have seen adoption of Android research projects in the military and government as it can be enhanced and adapted for specific security requirements, perhaps like no other mobile platform before it.
I hope this demo was of interest and that it generates some discussion around the best ways to select and use apps which offer the least risk to your device and data.
Update 20-Dec-2011: As mentioned these issues are not new and have been discussed before
Re:No vulnerabilities? (Score:5, Informative)
it is not root access (Score:5, Informative)
What happening here is that the app he installed opens the web browser to when you lock the screen. The app is then, in here in lies the secret sauce, is able to get the commands from the the browser is receiving. The browser part is simple, it can poll looking for input. How the app gets that input is interesting part. I don't know how its doing that. It may have created a callback from the browser to there app. Android has excellent inter process communication tools, but I don't know how he is doing this from an app he doesn't control. I've only thought about it for 5 minutes though. With this app and another app you control, this exploit would be trivial (one with internet access and another with sdcard access for example). I think any app can execute process with would give it access to the shell. That doesn't mean it has root access, but Android will let you view much of the file system without root. You cannot get to private app data storage, but you can see the sdcard and other basic parts of the file system like /framework or /etc.
http://developer.android.com/reference/android/os/Parcel.html [android.com] this shows inter-process communication.
http://developer.android.com/reference/android/content/Intent.html [android.com] this shows how to launch the browser.
Re:No vulnerabilities? (Score:4, Informative)
This doesn't give root, it just allows you to run a command within the context of the installed app.
How many times do we need to revisit the MS Word VBScript virus problem before we learn from it?
Here are some obligatory automatic security fails (on any platform) that guarantee your wonderfully architected system will be oft and immediately bypassed:
1. Asking the user to decide. Users don't read dialog boxes and just click/tap to make them go away. They will often happily answer YES to the "Install unsigned ActiveX control" dialog so they can see the dancing monkey or play some game. How often do you think they will pay attention to what rights an app wants and make a reasoned decision about whether that is a good idea or not? (Hint: almost never)
2. Asking the developers to oh-so-politely make sure they use best-practices and don't have any exploits or holes. They can and will not only willfully ignore your security best-practices but in fact will go out of their way to hijack the system because *their* app is special and like totally has a really good reason for it man! (See apps that hijack the right-click menu/sys tray/startup group/install 15 services/drivers that all auto-start/etc on Windows and the awful state of many drivers).
3. Assuming that an app should be able to do what the user can do - Granted this is not a problem with a sandbox system but still... Apps can't be trusted. Even when there is no ill intent there can still be unintended exploits (or just bad designs like running in the background constantly draining the battery when not necessary - part of the reason iOS still doesn't let apps run continuously unless they have an explicit reason like audio playback).
4. Assuming the user has the time or a f**k to give. In most cases the computer, phone, etc is just an appliance and they don't know or care about automatic updates, patches, security, etc. They just want the damn thing to work and stop annoying them. After all... most dangerous things have warnings and/or safety features and don't require you to check the manufacturer's website on a daily/weekly basis to see what new way to kill yourself has popped up. It can be impossible to keep up with even for technically-minded people who happen to have busy lives.
Re:Why does Android forbid root to the owner? (Score:2, Informative)
It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.
Uh, 'Secure Boot', dude. With Windows 8 you will only have whatever control Microsoft allow you over the Windows computer you thought you owned... if they disable admin access in Windows 9, you won't be able to patch the loader to re-enable it because it will refuse to run.
Re:it is not root access (Score:5, Informative)
The magic is getting the browser to return its data back to the app without privileges. That turns out to not be hard either. I found an example and posted it below. With this, you have a functional two way link from app without privileges to webserver and back. I'm not impressed and I don't consider this an "exploit". If you want a system that allows apps to communicate with each other, which we all do, then you have to be careful of what you install on your phone. This is better than a PC which almost always has full root access. This is just voyeur access...
http://www.android10.org/index.php/forums/49-other-coding-problemsarticles/1575-example-communication-between-an-activity-and-the-browser-callback [android10.org]
Re:No vulnerabilities? (Score:4, Informative)
Even in that case the shell is ridiculously restricted on Android. You can't even run sqlite command from the app.