Secret Codes, Again

My final project for the internship! I re-wrote a script that I wrote earlier which searched for secret codes. This new script will do the same thing, but much faster. Secret codes are unique to each application, and they are listed in the app's AndroidManifest.XML file. A secret code can be typed in to an android phone's dialer to open a secret menu for an app. These menus usually just give access to some tools developers can test, but they can also be security risks if a menu is left enabled that should not be (like this). In my previous script, I had pulled off every single app in its entirety, decompiling each with APKTool for its manifest. This new script however pushes busybox to the phone and uses it to extract ONLY the AndroidManifext.XML file from each app. The issue with this approach is that if the AndroidManifest.XML file is simply unzipped, it is not readable by most programs since it is actually in a binary XML format that android uses. This was not the case before since APKTool decompiled it and made it into regular XML (the issue with this approach being that it is mind-numbingly slow). To deal with this, I found a program called aapt that google made which will output the contents of the manifest, but only if it is in a .APK archive (the standard app format). Thus, in order to read the manifest, my script zips the manifest back up as a placeholder app named test.apk and then uses aapt to output the contents of the manifest in the placeholder app. It is then a simple task of searching through the output of aapt for android_secret_code tags and printing their corresponding codes. Here is the script:
By doing all of this roundabout work, my script avoids downloading hundreds of apps from a phone which is time consuming, and it also avoids parsing through an entire app for just the manifest, which is also time consuming. The really cool part is that my brother said that because it is so fast, we are going to fix it up a bit and put it in the security testing suite that his company uses!

Conway's Game of Life

Yesterday and today I worked on my most difficult programming project yet: making a version of Conway's game of life in java. After I scrapped the UI I made Tuesday, I created a completely new program that simply prints out a grid of Xs and Os to represent the living squares and the dead squares respectively. The program operates by making an object for each square and then stepping through one round at a time, each square figuring out what it will do next and then all changing at once. Here's the primary class:

Here's Citizen, the object:

It's not pretty or efficient, but it works and I made it :).

Java UI

Today in my java practice I tried to make a user interface for the game of life using checkboxes and swing, a java UI tool. I succeed in making the interface, but at the same time I made the underlying code so complicated that I couldn't understand it enough to edit it and make the actual game. I guess I should hold off on the tools that automatically generate code until I have a more solid understanding myself. One of the most infuriating things however was how the code was generated. Large chunks were simply not editable! I couldn't, for example, initialize all of the checkbox objects in one array because the whole class that created them was uneditable. I am sure there are good reasons that the code could not be changed, but I could not for the life of me find them out. Tomorrow I will tackle the issue again and make the UI last, if at all, and focus on the actual programming of the game.

Java!

The past few days I have been working on learning java. When I tried to make an android app, I found my knowledge severely lacking, so I have been reading through a java book and learning the basics of the language. Right now I am in the middle of trying to make a game of life simulator in java, but that project is going to take some time so I decided to write this blog post to keep people updated with what I am doing.

So far in java, I have learned about classes, objects, methods, instance variables, and other general topics. This has given me enough experience to make a simple class that mimics a bike and a class to test it:

finding secret codes

I made a script yesterday that will search for secret codes on an android phone. It does this by downloading all of the APKs from the phone, decompiling them using apktool, and searching through their manifests for any lines containing SECRET_CODE or secret_code. Here it is:

Exploring Permissions

I decided to take a closer look at android permissions and create a script that could search through the device and find issues with its permission settings. To do this, I am using MonkeyRunner, a tool made by Google and packaged inside the Android SDK. It allows scripting languages (in my case python) to communicate with android devices. I then installed Busybox on my phone to more easily find files and execute commands (for those of you who don't know, Busybox is a package of stripped down versions of many useful UNIX utilities). The script is at the bottom of this post for those interested, but I will walk through it step by step up here. The first three lines are just overhead that points to the python directory (I don't actually think this is necessary in this context), imports the MonkeyRunner libraries, and establishes a connection to the phone. The next lines are really the meat of the code. Each print statement simply tells the user exactly what is being displayed or displays it. The lines beginning in variables are statements that use MonkeyRunner to query the phone via ADB, which in turn uses BusyBox to execute a command.

Android Security Exploits Pt.2

http://www.xda-developers.com/android/nfc-secure-beta-makes-standard-lock-screen-security-a-relic-of-the-past/
This app looks very interesting as it provides another layer of security that can only be unlocked with an NFC tag. I do however have some questions: could somebody copy the NFC key and use their version to unlock the phone? The application claims to be 100% secure, but that seems very unlikely. What did they use to secure their application? If an attacker gained root couldn't they simply look at the device over ADB? Does the app protect against this? It seems like a good idea, but their claims seem slightly over the top.

http://www.xda-developers.com/android/dangerous-exynos-4-security-hole-demoed-and-plugged-by-chainfire/
The XDA Forums member alephzain created an application that can plug the hole found on devices using certain Exynos processors. The application changes the permissions on the vulnerable device, but in doing so also breaks the camera. The fix is a trade off, but it seems to be the only one that works currently. I am surprised that with such a large hole Samsung (the creator of the Exynos line of chips) has not taken steps to fix the issue.

Android Security Exploits

I am compiling a very random list of exploits that catch my attention when browsing XDA Forums and similar sites. Most/all of these are old and already patched, but they are still interesting.

http://forum.xda-developers.com/showthread.php?t=1987032&nocache=1
This thread is not directly about security, but when I read it I became concerned. If the random number generator is being toyed with, it might not be as random as the standard function. This wouldn't have a huge effect on standard usage, but if a secure key is generated, the random numbers used to generate it wouldn't be as random (I believe adding in the randomness is called salting), which means the cryptography would be significantly weaker. In real life, this shouldn't cause any effect since to discover this vulnerability a hacker would have to be making a direct attack on the phone's encryption, which is very unlikely, but it is still a slight concern.

http://www.xda-developers.com/android/x-ray-for-android-lets-you-scan-your-device-for-security-vulnerabilities/
This app is very interesting in that it does not fix any vulnerabilities, but simply alerts the user if their phone is vulnerable to one. It seems like a very interesting idea, but I don't know if it has a database of version numbers that is checks the host's against, or if it actually scans for vulnerabilities to see if certain flaws are present.

http://www.xda-developers.com/android/droidsheep-undresses-network-security-and-shows-how-its-done/
Droid Sheep is old news, but I find it very interesting and a lesson on using HTTPS whenever possible. By simply listening to other's wifi traffic, droid sheep can steal session IDs, allowing it to log on to sites that other users have logged on to as those other users.

http://www.xda-developers.com/android/secure-your-android-device-with-secdroid/
SecDroid seems like a neat app that protects you from intrusion by simply disabling services that can leave your phone vulnerable such as SSH, Telnet, and ADBD (Android Debugging Bridge Daemon). The issue with these services is that they are very rarely used by most users, but can be exploited if not properly configured. By simply disabling them by default this app adds another layer of security to most devices.

frame src="tel:*2767*3855%23"
An interesting vulnerability that affected many android devices (primarily TouchWiz UI phones, but possibly others, it is unclear) reset and wiped a phone if it visited a webpage that contained the code above. That line of code opened up the phone's dialer and entered in the code that carriers use to remotely reset a phone. The exploit primarily causes annoyance and the potential for the loss of sensitive information, but it cannot (as far as I know) steal or otherwise compromise a user's information.

http://www.xda-developers.com/android/no-odin-root-exploit-found-for-exynos-4412-and-4210/
This exploit is actually very relevant as it affects current devices and (to my knowledge) has not been patched yet. A device in the kernel is R+W with all users, and it gives access to all of the device's physical memory. This would allow any app to give itself root permissions, a clear vulnerability. This exploit affects all devices with either a Exynos 4210 or 4412 processor.

Aha!

With the help of my amazing dad, step dad, and brother, I finally found the issue. First of all, scripts cannot utilize setuid in Ubuntu. Thus, when I made a script with setuid to try and bypass using setuid directly with bash, I was doomed to failure. Additionally, when bash detects that it is being run with setuid privileges, it automatically drops its privileges, which explains the different prompt that was displayed with setuid. Finally, to test this, I made a program, not a script, that simply creates a file in the root folder, gave it setuid permissions and made it belong to root. I ran it and it worked, proving that there is no issue with setuid on my computer. I also found a great article at Vidar's Blog that explains more about setuid and how it works with bash and scripts. Now, on to more android related material!

Messing around with Ubuntu #2

Oops, I made an error on the last post. I did not in fact get root, since I started up bash with the sudo command I was running it as root, not as sam. Attempting to switch back to user "sam" while in bash as root does not work as even as root, I get "Cannot execute /bin/bash: Permission denied". I am confounded and I have no idea why this does not work. It is an issue I will have to pick up again later.

Messing around on Ubuntu

While I was working on Rage Against the Cage, I had to take a more in depth look at how SETUID and SETGID worked. As a proof of concept, I tried to give all users root privileges in bash using SETGID. I changed bash's permissions using "sudo chmod 6644 /bin/bash" and restarted the terminal, but I only got a $ with no username or machine name, suggesting that I was not even running bash but some other default shell. I figured out that by running that command, I had removed the execute permissions for others. I added it back in using "sudo chmod o+x /bin/bash" and restarted the terminal again, receiving the prompt "bash-4.2$". running the "id" command, I found out that I was still uid 1000, not root. I guessed that the issue was that I belong to the group "sam" while bash belongs to the group "root", which makes it so that I cannot run bash with root privileges as I am an other. My next step was to change bash to belong to the group "sam" using "chgrp sam /bin/bash" and restarting the terminal. The terminal again started up with only the $ as the prompt, which meant that I was not running bash but the other default shell. Using "ls -l" revealed that bash had permissions -rw-r-Sr-x and belonged to group sam, the same as my user, and lo and behold, when I ran "sudo /bin/bash", it came up with a root prompt. My only remaining question is why the terminal no longer starts up with bash, forcing me to use "sudo /bin/bash" to get it working.

Over my head

I learned about the inner workings of the Rage Against the Cage exploit. It abuses a flaw in the way ADB is executed, taking advantage of the fact that the process that spawns it doesn't actually check to see if it actually dropped the shell's permissions to those of a user. RAtC takes advantage of this by forking ADB into so many processes that RLIMIT_NPROC (the value that places a limit on how many processes a user can initiate) is reached. It then kills ADB and restarts it. It is created as root and then attempts to drop down to user's permissions but fails because there are too many threads already and continues to run as root, resulting in the attacker gaining root access to the system. I attempted to do the same process inside Ubuntu Linux with an intentionally vulnerable program, but found that I need more coding experience before I can effectively tackle such a difficult project.

Introduction

Here I will be cataloging my experiences as I go in depth exploring the security of Android. With the help of my brother, Max Sobell, I will research the vulnerabilities of Android and learn about the operating system. I will also be teaching myself more python throughout the process and becoming more adept at programming in general. Today, Monday 1/7/2012, I will explore the rageinthecage exploit and attempt to use it to gain root access to a virtual machine via a program I create in C that doesn't check the return value of suid/sgid. I will post my results by 6:00, and it is likely that I will need to continue tomorrow.