The following is “Mobile Hacking with Android”, as it appeared on page 15 of “2600″ issue 28:2. This article starts off by taking a look at the origins of Android, and a basic rundown on the internal structure of the OS. It then moves on to some choice software selections, and finally, details a real-world man in the middle attack using a rooted Android smartphone.
It’s worth noting that, as some time has passed between this being article written and today, a number of excellent security related tools have been released for Android. As predicted in this article, the rapid adoption rate of Android coupled with the release of the Android NDK has brought us ports of some of the best security tools from the Linux world. Keep an eye out for a future feature on the state of the art Android security tools here on “The Powerbase.”
If you have been following the mobile industry for the last year or so, you have already heard about Android. Google’s mobile Linux operating system has taken the industry by storm, and analysts predict that by the end of 2011 it will have overtaken Apple’s iOS as the number two mobile operating system in the world. Some even say that by 2015, it should overtake Nokia’s Symbian OS as the number one mobile OS.
The continued success of Android is of particular importance to hackers, as it is more proof that a large scale open source project can not only compete with proprietary software, but excel beyond it if properly supported. Perhaps more importantly, the open nature of Android allows it’s more technically inclined users to peer into the workings of their mobile devices and modify them however they wish. Finally, the dream of an open mobile device that started with the OpenMoko FreeRunner is very close to realization for the mass market.
Of course, we know that every story has two sides. With increased hardware performance, storage capacity, and software capability, mobile devices have become increasingly tantalizing targets for attackers and criminals over the last few years. But with flexible operating systems like Android under the hood, mobile devices are now becoming practical attack platforms; allowing an attacker to scan for and engage targets from the palm of his hand.
This article will take a look at a few Android applications of interest to both the hacker and the criminal alike, and detail a proof of concept attack using nothing more than a rooted Android mobile phone and publicly available software. The information herein is provided entirely for educational purposes so that the reader may have a better understanding of the capabilities and realistic applications of this technology. It in no way condones or suggests attempting to use these techniques in a malicious manner.
What is Android?
To get a better understanding of what Android is capable of, we should first get a good handle on what it actually is.
In 2005, Google acquired a little known company called “Android, Inc”, which had been developing software for mobile phones. Soon after, Google began filing various patents with a focus on mobile phone technology. This prompted the media to begin speculating that Google was planning on releasing a “G-Phone” to go head-to-head with Apple’s immensely popular (and largely unchallenged) iPhone.
But in 2007, rather than announcing a single phone they intended to bring to market, Google brought together a group of some of the most important companies in the mobile industry and created the Open Handset Alliance (OHA), a consortium designed to develop open standards for mobile devices. The OHA revealed that their first product would be an open source mobile OS, called Android, designed to run on the full gambit of mobile devices (phones, tablets, netbooks, etc), rather than an OS tied to a specific piece of hardware (like Apple’s iOS). In October of 2008, the HTC Dream (more commonly referred to as the G1) was released and became the first official Android device.
Android is made up of several software layers which are intended to make the OS more modular and easier to develop for. Android is based on the 2.6.x Linux kernel which handles hardware interaction, GNU-like userspace utilities for low-level system management, and various open source libraries such as OpenGL, SQLite, and FreeType.
While this technically makes Android a Linux OS, Android applications (or “apps” as they are usually referred to as) are not native Linux binaries. Rather, Google has developed a Java virtual machine called Dalvik and a large framework of libraries which developers can use without ever touching the underlaying Linux system. This means that developing for Android requires no previous knowledge of Linux programming, and allows the developer to work within a well documented and defined environment, regardless of what device their code will eventually run on.
The idea that a developer should be able to write one application and be able to deploy it on essentially every piece of hardware Android itself supports is a core element of the OHA. In theory, this should be a boon for developers, but in practice it introduces a number of problems, one of which being that Android applications are never truly optimized for a specific device, and are always limited by the capabilities of the Dalvik VM. Updates to Dalvik and the introduction of the Native Development Kit (NDK), which allows developers to bundle in native C code with their Java applications, are beginning to alleviate the issue, but hardware intensive applications like 3D games are still noticeably absent from Android’s software library.
While not a viable option for large-scale Android development, it is also possible to write (or adapt) Linux C code for use with Android. In theory, this means you could take existing Linux tools and applications and cross-compile them for the ARM architecture most Android devices are running on. In practice however, there are a number of limitations imposed by the abridged nature of Android’s Linux implementation that make things more difficult. Most notably, Android doesn’t include libc, but rather uses it’s own library known as Bionic. All native Linux code must be compiled against Bionic, but as Bionic is not 100% compatible with libc, there is no guarantee code will work as expected (or at all). In addition, Android doesn’t use an X server, so graphical Linux applications are out of the question.
As with all Unix-like operating systems, Android has a very strict set of permissions; which in this case extend from the core Linux components all the way up to the Dalvik VM. Since anyone can write an Android application and publish it in the Android Marketplace, it is extremely important for the system to monitor and limit the capabilities of everything the user installs. Every application must list it’s capabilities in regards to the Dalvik VM for the user upon installation, and Linux’s standard per-user filesystem permissions prevent even rogue applications from accessing the underlaying OS and doing system-wide damage.
While that is fine for the average user, those of us who want more control over our systems can start to feel a little caged in. Just like in a full Linux OS, if you want to get complete access to the system you need to elevate your user level to root. Gaining root privileges is not technically supported by Android, and doing so usually requires making use of some exploit or glitch in that particular device’s build of Android. Accordingly, the process of “rooting” an Android device differs greatly depending on the hardware and what version of Android it’s running, which makes it considerably out of the scope of this particular article. I can say that, as far as I am aware, all Android devices currently on the market can be rooted, with varying degrees of difficulty or Linux knowledge required. A simple Google search of your device name along with the term “rooting” should get you started.