Slashdot Mirror
Gaining a Remote Shell On Android
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."
Thomas has a pretty low-key way of presenting the shell access in the linked article - here's the Vimeo how-to video.
Hulk SMASH Celiac Disease
Why do these tinfoil hat types keep bringing up the _NSAShell functionality? Enough already!
Unintended root access is a vulnerability by definition.
Give me Classic Slashdot or give me death!
Until my phone's Android lets me run the Android Perl shell app on it without rooting, it's not "open", no matter what Google says. The source code might be open, at least "open readonly", and the binary might be "open execute" by hackers onto unauthorized hardware. But the OS instance is not open if it's not open to me as a user to invoke its API with an app that can do the job.
--
make install -not war
Woah, if you install an app, it can do stuff! Presentations (Defcon 18), numerous student thesis and a number of academic papers do nearly (or exactly) this. (agreed that apps w/o INTERNET permission probably shouldn't be able to leverage the browser, etc, but again, not new or newsworthy)
And if you don't have root, you can use one of the many remote root exploits to give yourself root access.
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
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 this shows inter-process communication.
http://developer.android.com/reference/android/content/Intent.html this shows how to launch the browser.
This is a question which doesn't seem to get asked much, probably because Google is an unmovable behemoth that's not really interested in the owners of devices, but only in advertisers. Nevertheless, it needs to be asked.
These cellphones and tablets belong to us, they don't belong to the device manufacturer, nor to the cellphone service operator, and even less to Google. They are ours. So why are we, the owners, forbidden direct root access to our own devices? It's like owning a Linux desktop without root, or owning a Windows machine and not being allowed Administrator access.
It's daft, and it's completely wrong.
Currently the crackers seem to have easier access to root than the device owners. Google, stop navel gazing and caring only about profit, and do something for users for a change. Add to standard Android a legitimate method for users to have access to root on their own devices, so that "rooting" becomes a thing of the past. It's not your right (nor anyone else's) to deny it.
Morgaine.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
"Secure Boot" is nothing new. They had that over ten years ago in their xbox game consoles. Its a simple chain of trust where the OS is loaded in a modular approach starting with the BIOS/UEFI handing off control to the next link only after cryptographically verifying their signatures. It has nothing to do with "locking" you out. Its a method to be reasonably sure that the OS is not compromised w/o hardware access (disabling secure boot is a bios option IIRC). If they wanted to lock you out from admin, they would simply not ship the OS with any way to allow you to create an admin account. Secure boot is irrelevant here.
Without resorting to paranoid delusions and conspiracies I don't see how Microsoft benefits if you don't have admin access. As it stands on windows you require admin access for dozens of important things like installing drivers, applications, system maintenance, debugging applications and many such tasks. Besides Windows would never change the existing user & process privilege model if they want to continue to be backwards compatible with previous versions. Hell they include a copy of the heap mnager from w95 just so broken programs continue to work. http://technet.microsoft.com/en-us/magazine/ff625273.aspx
Is this the iphone that was rooted by downloading a PDF?
You must be referring to the two exploits in the previous version of iOS that were quickly patched. Apparently Apple has trouble porting functionality to subsequent versions of iOS. Who says Apple can't learn anything from Google?
Amazing web page. A security page that requires javascript to display. If you look at the source, the entire readable content a dozen short paragraphs at the end, each written on one line, and being mere verbaige around the real content, which is a video hosted elsewhere.
Somehow I don't think I'll be taking any of this site's suggestions very seriously.
Infuriate left and right
Right, big deal, the app calls the browser to do something in the background while the screen is locked. However, you may be scared after reading the following PDF Systematic Detection of Capability Leaks in Stock Android Smartphones -- I was!
Jump to page 9 for the table.
Three HTC phones allow rouge apps (without the defined permissions) to record phone calls and send SMS! The SMS example is neat as they broadcast an intent with the phone number in it; then stock apps on the phones actually send the message. Also, the Samsung Epic 4G allows rouge apps to follow a similar method to wipe the phone to factory defaults! Most of the exploits are in the default packages that come with the bloated firmware from either the device maker or carrier. The Google Nexus phones were the safest as they had the fewest apps installed.
From the PDF:
"...by simply including a premium number in the intent, the built-in app will start sending SMS messages to this premium number!"
"For example, the explicit leak of CALL PHONE capability in Samsung Epic 4G involves passing a component a “technical assistance” phone number, which it calls after considerable processing. Similarly, all the tested HTC phones export the RECORD AUDIO permission, which allows any untrusted app to specify which file to write recorded audio to without asking for the RECORD AUDIO permission."
So you would have the firewall prevent your browser from connecting to pages that aren't in your whitelist? Because that's how the exploit works, by using the built in browser to contact a webpage and then execute local instructions.
I did some experiments a long while back... the most interesting one was releasing a VNC viewer to Version Tracker which during installation popped up a huge license message which highlighted in bold print "Do Not Install This App... It includes a trojan and by clicking continue below, it will also gain root access and add the text 'Ha Ha Ha' to the heading of every Word and text document on your file system". It did not actually do that, but it did actually call home and provide statistics regarding the number of times the installer was opened, whether the user just clicked through, whether there was any form of anti-virus on the computer I knew how to check for and then it would call home each time the VNC viewer was run afterwards. As a bonus feature, it also popped up a fake "look-alike" dialog to ask for the administrator password to install the program... it would then pretend like the user typed something wrong and then pop-up the real dialog. I didn't transmit the passwords... but I did collect stats of who actually typed their password.
Shockingly, because Mac users were so damn gung ho on how absolutely secure their OS was, there was an over 90% installation rate. 40% used the application more than once. It took 6 weeks for the app to be taken down... and people were still downloading it even though the comments screamed about how it was a virus.
Microsoft Windows 7 is EXTREMELY secure now because of several things...
1) People DON'T trust Windows apps like the used to... they're skeptical about viruses.
2) People run anti-virus software... which may be useless on zero-day bugs and often can be more harmful to the user experience than any virus they can block, but they run it.
3) Microsoft bought a gazillion anti-virus vendors and has produced one of the best anti-virus programs I've ever seen... they give it away for free... they respond QUICKLY to new viruses and by having access to all system internals, produce applications that can remove even the nastiest viruses from the system.
4) Microsoft now listens to their anti-virus group and makes changes to the OS to make it more secure from user blunder. Things like the ever annoying "Are you sure you want to run this app?" and also, in Windows 8, trying to deter the user from installing applications that are in their central online as harmful or incompatible.
Apple iOS is pretty damn secure because it's a bit harder for the vendor of a malicious app to get an app into the app store. If someone chose to add a virus/trojan/etc... to the app store, it's taken down very quickly if it's detected as such (unless we're talking about apple approved trojans) and the amount of information that has to be gathered on an app developer before they can publish an app makes it much harder to put things there without there being some recourse. Unlike the rest of the Apple Stores, it's not possible to purchase through PayPal. A developer has to use some identifying form of payment. Prepaid credit cards do however work... so if you get one of those and forge some info on it... you're good. Still... quite a big obstacle.
Mac OS X is still a rats nest of security hell as almost no one installs anti-virus software on it. The Anti-virus companies don't even take it seriously since the market for Mac sucks... most Mac anti-virus software really only checks to make sure you're not transmitting known Windows viruses through e-mail. People still trust it too much and the market for Mac is still probably heavily dominated by people who want to use FaceBook but can't find the 'Any Key'. They bought the Mac because the guy at the store said "You want a Mac because you don't ever have to worry about viruses" and they trusted the guy who was obviously a highly educated computer expert working for $10 an hour at a company who treats their employees like slaves and makes them wear a stupid blue shirt.
BlackBerry... haha I won't even begin to bash how useless their device security is. What'
If leaving out the rooting part... (what is app install from market + single click to root/unroot) the iptables is easy to use in Android
1. Install droidwall (or any other iptables firewall)
2. Start application and check/uncheck applications rights to have connection when in 2G/3G or WiFi mode.
I hope it would be as easy with Linux distributions....