IG Learner Challenge #7

*SPOILERS* Highlight to read.
The hardest part of this challenge was figuring out and setting up Mercury. It's a cool little app that lets you execute commands as an app on the phone. Once it is set up (no easy task, at least for me) all you have to do is execute the command "run app.provider.query content://com.intrepidusgroup.learner.contentprovider/iglearnerdb" in the Mercury terminal. It queries the Learner's insecurely created database using info gleaned from the app itself (database name, content URI)

IG Learner Challenge #6

*SPOILERS* Highlight to read.

This challenge was not as much difficult as it was frustrating. From a quick glance at the code it was clear it used AES encryption with the key "intrepidlearner1", but for the life of me I couldn't generate the correct code with the correct combinations of base 64, binary, and luck. So, I wrote some code to do it for me. I will not show it here since I can't cover it in white, but here's the link (excuse the sloppy code, I made it quickly and it's based off the learner app). With that program the challenge was quick.

IG Learner Challenge #5

*SPOILERS* Highlight to read.
Number 5 was a more difficult version of four. Just like in four, in order to complete it, I had to forward phone traffic through my computer and read the secret key. I used burp to read the data on my computer and ProxyDroid to forward the phone data to my computer (IG has a great tutorial here). However, this challenge had a twist. The app used certificate pinning to link the certificate to the website. Since I could not mimic the certificate, I changed the app to pin my certificate instead of the IG one. After hours of frustration at the program not sending the key, I finally found that I had to pin the "trail" of certificates that led from my proxy to Intrepidusgroup.com, not just my proxy's certificate. 

IG Learner Challenge #4

*SPOILERS* Highlight to read.
This challenge was quite difficult. In order to complete it, I had to set up ProxyDroid, an app that forwards all traffic to a proxy, on my phone and have it forward traffic to Burp, a package sniffer I installed on my computer. This setup forwards all of my phone's internet traffic to my computer. However, since the Learner app will not send the key unless it has an SSL connection to the Intrepidus Group website, I also had to use burp to make an SSL certificate, then register it on my phone as a trusted CA Certificate. Finally, I sent the token, ProxyDroid redirected it to my computer, and I found the key in the parameter SecretTokenHeader.

IG Learner Challenge #3

*SPOILERS* Highlight to read.
I was fairly disappointed by this challenge. I decompiled it just like the other one and started looking through the code. I was (rather stupidly) confounded for a long time by looking at lesson3activity since I couldn't find where it checked the input against a key. I eventually realized that, in addition to lesson3activity there was lesson3handlerActivity, which prominently displayed at the top  "final String unlockkey = "crazyurihandler";". Lo and behold, I entered iglearner://www.intrepidusgroup.com/crazyurihandler and I am greeted with "UNLOCKED. Challenge is completed." It was sort of an undramatic conclusion to the lesson. I love the idea of the app and I am very grateful that Roman created it, but I feel as though it could have included the URI handler in some way that forces the user to learn about URIs to be able to complete the task. 

IG Learner Challenge #2

*SPOILERS* Highlight to read.
This challenge was more difficult than the last since you must look through the application's source to figure out what the passphrase is. My first step was pulling the learner application off of my phone so I could decompile it. I then used the dex2jar utility to convert it to a jar file and used the jd-gui utility to view the source. For whatever reason, the application was not obfuscated, meaning that all of the class and variable names were intact, making searching through it very easy. I looked in the lesson2activity class under com.intrepidusgroup.learner and figured out the code relating to the naming of the file. I will let you do the same, but once you figure out how the name is generated, it is simple to piece together the name of the application from the date and your phone number.

IG Learner Challenge #1

*SPOILERS* Highlight to read.
The first challenge was fairly simple if you know how to access the android logs -- or even exactly what they are. I, unfortunately, did not. I did some research on what the logs were and came up with the understanding that they were a global resource that applications could dump output into for debugging and logging purposes. While the latter part of that is self explanatory (I guessed as much but I wanted to be sure), the global part is important since that means there is one log to rule them all. I didn't have to search for the app's individual log, but instead could pull directly from the global log. I used ADB to get the log with the command "adb logcat > log_android.txt". This pulls the log from your phone and writes it in log_android.txt. The only issue with this method is that it is slow, taking hours to gather the full log. However, you don't need the full log, just a few recent additions to it, so you can cut it off after a few minutes of downloading. I then searched the log (in a standard text editor using ctrl-f) for the phrase "com.intrepidusgroup.learner" since that is the system name of the application. I found the process ID associated with the app (just the number next to "com.intrepidusgroup.learner") and searched for that instead since the full name doesn't always appear next to the log entries. I looked through the log finding all instances of the process ID until I found a fairly distinctive patch of log entries with one of them containing the code that let me proceed.
NOTE: the passphrase is procedurally generated, meaning it changes if you restart the app, so you must do all of this without killing the app.

Note from Max Sobell, Intrepidus Security Consultant: "The log can take "hours" to gather fully because it's always being appended to. I believe the Android OS keeps a rotating portion of the log. When you say "adb logcat" you're getting that portion, plus the things that are appended while the pipe stays open. So, if you run it for hours, you will get hours of logging. If you run it for 1 second, you will get 1 second + the stored logs."

This would suggest that you only need to run it for as long as it takes to press Lesson 1. Thanks Max!

IG challenges

For the past few days I have been working on completing challenges in an application that was given to me by my brother. The app is called "IG Learner" and it has a series of discrete challenges that teach the user about android security. On this blog I will post walkthroughs for the challenges so that you can solve them the same way I did. However, I encourage you to try them on your own first as they are very rewarding to complete without any help. I would also like to thank Roman Faynberg for creating the app, it is an awesome resource.

Controlling App Permissions

Last week I wrote a script that would control which permissions an app had access to. It did this by unpacking the app with APKTool, editing the AndroidManifest.XML file to remove the unwanted permissions, then repackaging the whole thing. This works because if the app doesn't request a permission in its manifest, the system will not give it that permission, effectively limiting the app. There are a few cases in which the app cannot run without a certain permission, but I was not able to determine when this would occur or prevent it.
I also had some fun learning about how to incorporate command line arguments into a script, and I made this script accept the name of the app to edit in the terminal so that users wouldn't have to edit the app's name for the script to recognize it.

Here is the script, by the way:

Getting Back Into the Swing of Things

For my first day back I am starting by looking at how Android sandboxes applications. The security section of Android's open source documentation (at https://source.android.com/tech/security/) does a fair job of documenting the basics. The most interesting portion of the description that I found explains that all of Android's applications run as separate users. This gives each one the flexibility to make system calls and utilize all of android's services while not being able to interact with one another. It is also deeply ingrained in the Linux kernel (which android is based off of) that users must not be able to affect one another, helping to ensure that if one application is exploited, the attacker will not be able to affect other programs unless he/she finds a vulnerability in the Linux kernel. Understanding that the system is set up this way also helps to explain why having root makes the whole system vulnerable. Because root has permissions to access all other users' files, any program with root access can read, write, and execute all other applications' files, breaching the sandbox and allowing an attacker to influence all programs on a phone.

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.