: 8558: b508 855a: 6848

push {r3, lr} ldr r0, [r1, #4] 271

Native Exploitation and Analysis 855c: 8560: 8562:

f7ff ffe2 2000 bd08

bl 8524 movs r0, #0 pop {r3, pc}

Just a little tip In the preceding objdump output, the far-left column shows the offsets of the instructions; the column after that, delimited by the : character, holds the actual hex representation of the code; and the column after that shows the human-readable mnemonics for the associated assembler instructions.

Pay attention to the emboldened code in the previous objdump output. The instruction at the 8526 offset loads the contents of memory found 0x40 addresses away from the current value in the program counter (pc) register; this address holds a special value called the stack canary. It's commonly termed as a canary because of how actual canaries were used by miners to make sure mine shafts were safe to explore.

This value is placed on the stack between the local variables and the saved instruction and base pointer; this is done so that if an attacker or erroneous instructions were to corrupt the stack far enough to influence the values saved there, it would need to destroy or change the stack canary as well, meaning the program would be able to check if the value changed. This value is generated from a cryptographically secure—supposedly so—pseudorandom number generator, and it's stuck in the memory of the program during runtime to avoid reliably predicting this value. Moving on, we see that the instructions at offsets 852c-8530 stick the stack canary in the r3 and r4 registers. The following instruction at offset 8532 makes sure the stack canary is placed on the stack before the dangerous strcpy call at offset 8534. So far, all the code has accomplished was to place the value on the stack after the strcpy call—actually, closer to the printf function. From offset 8542 to offset 8544, the stack canary values are fetched from register r4 and the position it was placed on the stack, loaded into the r2 and r3 registers, and then compared at offset 8546. If they don't match, we see that the instruction at 854a will be executed, which will basically cause the program to abort and not exit normally. So, in summary, it grabs the stack canary from some offset in the file, places it in a register and another copy on the stack, and checks for any changes before exiting. One thing you may notice is that though this prevents the saved instruction pointer from being corrupted it does not protect the local variables at all! It is still possible to maliciously corrupt the other variables on the stack depending on their layout in memory—where they appear in relation to the canary and the other stack buffers. This could in some very special circumstances still be abused to maliciously influence the behavior of a process. 272

Chapter 8 So now how do we remove this annoying protection such that we can smash some stack properly and gain the ability to control the instruction pointer? Well, seeing that stack canaries are a compiler-based protection—meaning that it's something the executable compiler enforces—we should be able to modify the way NDK executables are compiled so that stack protection is not enforced. Though this may seldom be a practical situation for the binaries on the Android system, it is still something that may very well happen. We are removing this protection in order to simulate a stack-based overflow vulnerability. To remove the protection, you'll need to change some of the GCC compiler extensions that the NDK uses. To do this, you'll need to: 1. Navigate to the /toolchains/arm-linux-Androideabi-4.9/ directory and locate a file called setup.mk. Please note, your NDK may use a different version of arm-linux-androideabi. If the following steps don't work or have the desired effect, you should try removing the stack protection:

2. The next thing you may want to do is back up the setup.mk file. We're about to change the default compilation configuration for the NDK, so it's always good to back it up. You can create a makeshift back up by copying the script to another file named slightly differently. For instance, you can back up the setup.mk file by executing this command: cp setup.mk setup.mk.bk

273

Native Exploitation and Analysis 3. After backing it up, you should open the setup.mk file in your favorite text editor and remove the flags, specifically the one containing the -fstack-protector switch; see the following screenshots for more clarity:

After removing the specified flag, your setup.mk file should look something like this:

4. Once you've done that, you can use the ndk-build script to compile a fresh copy of your executable and then pass it to androideabi-objdump. Without stack protection, your code should look like this: 000084bc : 84bc: b51f push 84be: 1c01 adds 84c0: a801 add 84c2: f7ff ef8a blx 84c6: 4803 ldr ) 84c8: a901 add 84ca: 4478 add 84cc: f7ff ef8a blx 84d0: b005 add 84d2: bd00 pop 84d4: 0000154a andeq 000084d8

: 84d8: b508 84da: 6848 84dc: f7ff ffee 84e0: 2000 84e2: bd08

274

{r0, r1, r2, r3, r4, lr} r1, r0, #0 r0, sp, #4 83d8 r0, [pc, #12] ; (84d4 r1, sp, #4 r0, pc 83e4 sp, #20 {pc} r1, r0, sl, asr #10

push {r3, lr} ldr r0, [r1, #4] bl 84bc movs r0, #0 pop {r3, pc}

Chapter 8 Notice how there are none of the instructions that were in the previous version of the executable. This is because the -fstack-protector compiler flag that we removed tells GCC to autonomously look for any instance of any function that may potentially corrupt the function stack.

See also ff

The ARM and Thumb Instruction Set Quick Reference Card document by ARM infocenter at http://infocenter.arm.com/help/topic/com.arm.doc. qrc0001l/QRC0001_UAL.pdf

ff

The ARM Instruction Set document at http://simplemachines.it/doc/arm_ inst.pdf

ff

The ARM v7-M Architecture Reference Manual document by the department of Electrical Engineering and Computer Science, University of Michigan at http:// web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ ARMv7-M_ARM.pdf

ff

Exploiting Arm Linux Systems, An Introduction by Emanuele Acri at http://www. exploit-db.com/wp-content/themes/exploit/docs/16151.pdf

ff

The Procedure Standard for the ARM Architecture document at http:// infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_ aapcs.pdf

ff

The ARM Instruction Set document at http://bear.ces.cwru.edu/eecs_382/ ARM7-TDMI-manual-pt2.pdf

ff

The ARM Developer Suite Version 1.2 Assembler Guide document by ARM infocenter at http://infocenter.arm.com/help/topic/com.arm.doc.dui0068b/ DUI0068.pdf

ff

The DLMalloc Implementation library at the Android Platform Bionic GitHub page at https://github.com/android/platform_bionic/blob/master/libc/ upstream-dlmalloc/malloc.c

ff

The ok_magic call in the DLMalloc implementation at the Android Platform Bionic GitHub page at https://github.com/android/platform_bionic/blob/ master/libc/upstream-dlmalloc/malloc.c#L4715

ff

The Bionic source code at the Android Source code repository at https:// android.googlesource.com/platform/bionic/

ff

DLMalloc.c, Android Platform Bionic jb-mr0-release at the Android Official GitHub repository at https://android.googlesource.com/platform/ bionic/+/jb-mr0-release/libc/bionic/dlmalloc.c

275

Native Exploitation and Analysis

Exploitation of race condition vulnerabilities Race conditions have caused quite a few issues and privilege escalation attacks on the Android platform; many of them allowing malicious attackers to gain root privileges. Essentially, race conditions are caused by the lack of enforced mutual exclusion when a process on a multithreaded (a platform where more than one process is allowed to run concurrently) system that uses preemptive process scheduling. Preemptive scheduling allows a task scheduler to interrupt a thread or running process preemptively, meaning without first waiting for the task to be ready for interruption. This enables race conditions because often developers don't enable applications to operate in a way that accommodates arbitrary and unpredictable interrupts from the process scheduler; as a result, processes that rely on access to potentially shared resources like files, environment variables, or data structures in shared memory are always "racing" to get first and exclusive access to these resources. Attackers abuse this situation by gaining access to these resources first and corrupting them in a way that enables either damage to the processes operation or allows them to maliciously influence the process's behavior. A simple example would be a program that checks if a user authenticating themselves is in a given file listing the valid usernames; should this process not accommodate the preemptive scheduler, it may only access the file after a malicious user has corrupted it by adding his/her username to the list, allowing them to be authenticated. In this walkthrough, I will detail some basic race condition vulnerabilities and discuss other potential causes; I will also detail exploitation of a few of the most basic race condition vulnerabilities. The walkthrough ends with references and useful sources of information on past Android-based race condition vulnerabilities; most of them reported in the year of this writing. Exploitation of race condition vulnerabilities depends on a few factors, namely an attacker must at least be able to: ff

Gain access to the resources a vulnerable process is racing for access to: Just having a process that doesn't enforce mutual exclusion for its external resources but leaves the attacker with no method of access to these same resources wouldn't harbor much potential for exploitation. If this wasn't true, every single nonmutual exclusive access a process makes would be exploitable. This includes every time a process dereferences a pointer in memory without checking out a semaphore or spin lock, which could happen billions of times!

ff

Influence these resources maliciously: It wouldn't help much if a process doesn't exclusively access its resources in the context in which an attack cannot augment or maliciously modify the resources. For instance, if a process accesses shared memory or a file that an attacker only has read access to—unless of course this causes the vulnerable process to crash, given the semantic priority of the process; for example, an anti-virus program, IDS, or firewall.

276

Chapter 8 ff

Time of use / time of check window size (TOU/TOC): This is essentially the time difference, or more effectively the likelihood of scheduler interrupts, between the time an application checks for access to a resource and actually accesses the resource. The exploitability of a race condition depends heavily on this time difference because exploits will essentially race for access in this time frame in order to maliciously affect the resource.

Taking these conditions into account, let's look at some constructed examples of race condition vulnerabilities and how to exploit them on Android.

Getting ready Before we start exploiting race conditions, we need to prepare an example. Here's how you do that: 1. We're going to prepare to an embedded ARM Android platform—the Jelly Bean emulator in this example—that causes race condition vulnerability. The following code details the behavior of a vulnerable process: #include #include #include #define MAX_COMMANDSIZE 100 int main(int argc,char *argv[],char **envp){ char opt_buf[MAX_COMMANDSIZE]; char *args[2]; args[0] = opt_buf; args[1] = NULL; int opt_int; const char *command_filename = "/data/race-condition/commands. txt"; FILE *command_file; printf("option: "); opt_int = atoi(gets(opt_buf)); printf("[*] option %d selected...\n",opt_int); if (access(command_filename,R_OK|F_OK) == 0){ printf("[*] access okay...\n"); command_file = fopen(command_filename,"r"); for (;opt_int>0;opt_int--){ fscanf(command_file,"%s",opt_buf); } printf("[*] executing [%s]...\n",opt_buf); fclose(command_file); } else{ 277

Native Exploitation and Analysis printf("[x] access not granted...\n"); } int ret = execve(args[0],&args,(char **)NULL); if (ret != NULL){ perror("[x] execve"); } return 0; }

Compile this by following the same process as detailed in the Cross-compiling native executables recipe and deploy it to your Android device. Try deploying it to a partition or folder that's been mounted as executable and readable by any user on the Android system (to see how to do this, please refer to the Copying files off/into an AVD recipe in Chapter 1, Android Development Tools). Throughout this recipe, we use the partition mounted as /system, which was remounted with read and write permissions, as in other recipes. Please note this may cause the NDK to throw out a couple of warnings, but as long as everything compiles to an executable, you're good to go! 2. You'll also need to put the commands.txt file in the directory mentioned in the code, namely /data/race-condition/command.txt. This requires making a race condition folder in the /data path. A good example of how to do this can be found in the Inspecting network traffic recipe in Chapter 4, Exploiting Applications, since we needed to create a similar setup for TCPdump. 3. You will need to set the setuid permission for this executable on the Android device; you can do this by executing the following command after deploying it to the device: chmod 4711 /system/bin/race-condition

This command also makes sure any user on the system has execute permissions. Please be aware that you will need root permissions to perform this command. We are simulating the effect of a setuid binary and how it can cause arbitrary code execution. We have everything set up for exploitation; we can move onto detailing this exploitation now.

278

Chapter 8

How to do it... To exploit the vulnerable binary, you will need to do the following: 1. Run the ADB shell into the Android device; if you're using an emulator or a rooted device, you should be able to use su to assume another application's access rights. Try accessing some root-owned folders and files that don't have execute, read, or write permission set for your user. Here I've chosen user 10170 as an example, and you should see the Permission denied messages being thrown around when you try to access the /cache/ directory:

2. Let's exploit the race-condition binary. We do this by augmenting the commands. txt file with another command, namely /system/bin/sh, which will open a shell for us. You can do this by executing the following command: echo "/system/bin/sh" >> /data/race-condition/commands.txt

The /system/bin/sh command should now be the last entry in the commands.txt file, this means, if we hope to select it from the menu we need to choose option 5.

3. Execute race-condition on the Android device and supply 5 as an option. The vulnerable binary would then execute the sh command and give you root permissions.

279

Native Exploitation and Analysis 4. Test your root access by trying to change the directory to /cache. If you're running a Jelly Bean or later version of Android, you should not see any Permission denial messages, which means you've just escalated your privileges to root!

The preceding example is designed to detail the most basic concepts in race conditions, namely when an application accesses a file that any other process can augment and uses it to perform actions as the root user. There are more intricate and subtle situations that cause race conditions, one that's been commonly exploited are those involving symbolic links. These vulnerabilities stem from an application's inability to discern a file from a symbolic link, which allows attacks to augment files via a crafted symbolic link or when a file reads a symbolic or hard link but is incapable of determining the authenticity of the link target, which means the link can be redirected maliciously. For more modern examples of race condition vulnerabilities, check out the links in the See also section.

See also ff

The Vulnerability Summary for CVE-2013-1727 article at http://web.nvd.nist. gov/view/vuln/detail?vulnId=CVE-2013-1727&cid=8

ff

The Vulnerability Summary for CVE-2013-1731 article at http://web.nvd.nist. gov/view/vuln/detail?vulnId=CVE-2013-1731&cid=8

ff

The Sprite Software Android Race Condition article by Justin Case at http:// packetstormsecurity.com/files/122145/Sprite-Software-AndroidRace-Condition.html

ff

The Race Condition Exploits article by Prabhaker Mateti at http://cecs.wright. edu/~pmateti/InternetSecurity/Lectures/RaceConditions/index. html

280

Chapter 8

Stack memory corruption exploitation Stack memory exploitation may not be the most likely source of Android bugs and security vulnerabilities, though it is still possible for these kinds of memory corruption bugs to affect native Android executables even in the midst of protections such as ASLR, StackGuard, and SE Linux. In addition to this, most of the Android market share consists of devices that don't have as robust protection against stack and other memory-based exploitation, namely 2.3.3 Gingerbread devices. Another great reason—besides its direct relevance to security research—to include a discussion and walkthrough on stack-based exploitation is because it provides a great gateway into more advanced exploitation techniques. In this section we will detail how to exploit a common stack-based memory corruption flaw to take control of the flow of execution.

Getting ready Before we start, you'll need to prepare a vulnerable executable; here's how you do it: 1. Create a directory with the usual jni folder and the same naming convention as in the previous recipes. If you need a recap, see the Cross-compiling native executables recipe in this chapter. 2. Write this code into a .c file in the jni folder: #include #include void vulnerable(char *src){ char dest[10]; //declare a stack based buffer strcpy(dest,src); //always good not to do bounds checking printf("[%s]\n",dest); //print the result return; } int main(int argc, char **argv){ vulnerable(argv[1]); //call vulnerable function printf("you lose...\n"); return (0); }

This code is strikingly similar to the previous example. In fact you may even edit the previous example code, since it differs in only a few lines. 3. Compile the code using the ndk-build script as before. 4. Deploy the code to an Android device or emulator; for the following example, I used an emulated Android 4.2.2 device. Once you've got your code all set up, you can move on to pushing the binary onto your emulator or device—if you're up for the challenge. 281

Native Exploitation and Analysis

How to do it... To exploit the stack-based buffer overflow, you could do the following: 1. Launch the application on your emulator a couple of times, each time giving it a bigger input until it fails to exit the execution gracefully and your Android system reports a segmentation fault. Try to remember how many input characters you gave the application because you'll need to give it the same number to trigger the crash using gdbserver. Here's a screenshot of what a normal run of the executable looks like:

You should see the GDB output exited normally, indicating that the return code of the process was the same and nothing interrupted or forced it to stop.

282

Chapter 8 Once too much input is given to the application, it exits with a segmentation fault, which looks like this in GDB:

2. Launch the application in gdbserver, giving it an "unsafe" amount of input, namely an amount of input that will crash it. For our code that should be anything above 14 to 16 characters. In this example, I've entered around 16 characters to make sure I overwrite the correct portion of memory. 3. Run androideabi-gdb and connect to the remote process. If you need a recap on how to do this, see the Debugging the Android processes using the GDB server recipe in Chapter 6, Reverse Engineering Applications. 4. Set a couple of breakpoints using GDB. Set a breakpoint just before blx to strcpy and another after, as in the following screenshot:

283

Native Exploitation and Analysis You set breakpoints using the break command or b as a shorthand, and giving it either an offset for a line of code or a pointer to an address that holds an instruction; hence the * character before the memory value.

5. Once your breakpoints are set, re-run the application via gdbsever and reconnect to it using the Android GDB. Step through each breakpoint as explained later. All you need to do is type in continue in the GDB prompt, or c as shorthand. GDB will continue the execution of the program until a breakpoint is reached. The first breakpoint you reach should be the one before the strcpy call; we set a breakpoint here so that you could see how the stack changes before and after the strcpy call. It's crucial to understand this so you can work out how much data to give the application before you start overwriting the return addresses. This is shown in the following screenshot:

This is a snapshot of the stack for the vulnerable function before the call to strcpy; nothing much has happened yet except that some space has been prepared for the local variables. Once the first breakpoint is reached, you should inspect the stack by printing some of its memory contents. In the following example, this is shown by executing this x command in GDB: x/32xw $sp

284

Chapter 8 This command tells GDB to print 32 hexadecimal words from the memory address contained in the sp (Stack Pointer) register; here's what you should see:

You'll notice that a couple of values are highlighted; these values were passed to the stack by an instruction in the function prologue, which is the following instruction: push

{r0, r1, r2, r3, r4, lr}

The push instruction—as used in the previous command—makes sure the register values of the calling function are preserved. This instruction helps ensure that when the function executing returns control back to the function that called it, the stack is returned to its original state.

One of the values used in the push instruction is lr or link register. The link register usually holds the return address of the current function. Here, the lr register holds the value 0x000084f5. We are going to try to overwrite it with one of our own later; and in a few minutes, you should see how our input has changed this value, so try to remember it for the time being.

285

Native Exploitation and Analysis You want to do this because of an instruction further down in the vulnerable function, namely the following: pop

{pc}

This instruction moves the saved lr value straight into the program counter register; which causes execution to continue at the address saved in the lr register. If we can overwrite the saved lr value, we can effectively control where the execution is branched at the end for the vulnerable function. The next step covers how to calculate exactly and what to enter into the program in order to make sure you control the execution as mentioned. 6. Continue to the next breakpoint. Once GDB hits this breakpoint, strcpy should have written your input to the stack. Inspecting the stack at this point should yield the following output:

You should notice that the value 0x000084f5 changed to 0x00008400; they're quite similar because when strcpy wrote our input into the buffer, it partly overwrote the saved lr value with the NULL byte that follows our string; this is why the 0xf5 was replaced with 0x00. We now know that our 16 characters of input overwrites one byte of the saved return address. This means to completely overwrite the 2 bytes of return address, we need to add 2 bytes of input—accommodating the NULL byte—with the last 4 bytes being the new return address. Here's how it works: Before the strcpy call, the stack had this structure: Uninteresting stack contents

Input Buffer field

0xbee6fc75

0xbee6fb44

0xbee6fb50

Saved lr value

0x00000000

0x000084ed

0x00000

0x84

0xF5

After the strcpy call with the 16 bytes of input, the stack had the following structure: 286

Chapter 8 Uninteresting stack contents

Input Buffer field

Saved lr value

…0xbee6fc75

16 chars

0x00000

0x84

0x00

The bold 0x00 value is the NULL byte from our input; based on this we would want to input 16 chars plus 2 chars for the new return address, which would look like this: Uninteresting stack contents

Input Buffer field

Saved lr value

…0xbee6fc75

[16 chars]

0x00000

0x??

0x??

Here, the 0x?? characters indicate the extra input chars we give the strcpy call to overwrite the return address; again we see the 0x00 character after the extra input chars. 7. Relaunch the GDB server with the given input; try skipping over the printf "you lose" call and checking that it wasn't executed—this makes for an easy way to check if you've successfully redirected execution. Here's how you can grab an example address to redirect execution flow to. Disassemble the main section by executing the following command in the GDB shell: disass main

This will yield the following output: 0x000084ec <+0>:

push {r3,lr}

0x000084ee <+2>:

ldr r0,[r1, #4]

0x000084f0 <+4>:

bl 0x84d0

0x000084f4 <+8>:

ldr r0, [pc, #8]

0x000084f6 <+10>:

add r0,pc

0x000084f8 <+12>:

blx 0x83f8

0x000084fc <+16>:

movs r0,#0

0x000084f3 <+18>:

pop {r3,pc}

0x00008500 <+20>:

andeq r1,r0,r2,asr,r5

287

Native Exploitation and Analysis The blx instruction at 0x000084f8 is clearly the call to printf so, if we want to skip over it, we would need to grab the address of the instruction just following it, which is 0x000084fc. More specifically, we would give the following as input to our program: [16 padding chars] \xfc\x84

The bytes that specify the return address are given in reverse order because of the endianness of the architecture. 8. Relaunch the application using the GDB server, this time giving it the following input: echo –e "1234567890123456\xfc\x84"`

If all goes well, you should not see the application print the "you lose" message and just exit instead. There's a lot more you can do than just skip over a simple print instruction; in some circumstances, you can even take complete control of the process running a program with vulnerability like this. For more information on how to do this, see the link titled ReturnOriented Programming without Returns in the See also section. For good sources on general memory corruption attacks, see the Memory Corruption Attacks, The (almost) Complete History as well as the Smashing the Stack for fun and Profit links in the See also section.

See also ff

ff

A short Guide on ARM Exploitation at http://www.exploit-db.com/wpcontent/themes/exploit/docs/24493.pdf The Smashing the Stack for fun and Profit article by Aleph One at http://www. phrack.org/issues.html?issue=49&id=14#article

ff

The Memory Corruption Attacks, The (almost) Complete History guide, Thinkst Security 2010, by Haroon Meer, at http://thinkst.com/stuff/bh10/

BlackHat-USA-2010-Meer-History-of-Memory-Corruption-Attacks-wp. pdf

ff

The Return-Oriented Programming without Returns guide by Stephen Checkoway, Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, Hovav Shacham, and Marcel Winandy at http://cseweb.ucsd.edu/~hovav/dist/noret-ccs.pdf

ff

The Return-Oriented Programming without Returns on ARM guide by Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, and Marcel Winandy at http://www.

informatik.tu-darmstadt.de/fileadmin/user_upload/Group_TRUST/ PubsPDF/ROP-without-Returns-on-ARM.pdf

288

Chapter 8

Automated native Android fuzzing Fuzz testing is a great way to find exploitable bugs or bugs in system utilities. It allows auditors to gauge the effectiveness of file handlers and any other application against malformed and possibly malicious input, and helps determine whether there are any easily exploitable entry points on a system. It's also a great way to automate security testing. Android is no different from any other system and has a myriad of interesting fuzz targets. The attack surface of an Android device doesn't stop at the Java application layer; in fact, root exploits are sometimes based on a native executable or system utility that doesn't properly handle any given input or respond in a secure way to certain situations. Fuzzing is a great way to find these situations and possible root exploits on an Android device. What I'm going to cover here is how to port a fuzz test generator called Radamsa to the Android platform, and also install some utilities that will help you to script some robust fuzzing scripts that use Radamsa.

Getting ready Before we can start porting, you will need to grab a copy of the Radamsa fuzzer; here's how you do that: 1. Make sure you have either CURL or Wget installed on your Linux machines. Wget will work fine, but sticking to the recommendation on the Radamsa site, you can install the prerequisites by executing the following command from your Ubuntu machines: sudo apt-get install gcc curl

Running this command should produce an output similar to the following screenshot:

2. Once they've been downloaded, you can grab your copy of the Radamsa source code as follows: curl http://ouspg.googlecode.com/files/radamsa-0.3.tar.gz > radamsa-0.3.tar.gz

289

Native Exploitation and Analysis Running this command should produce an output similar to the following screenshot:

3. You should then extract the Radamsa source by executing this command: tar –zxvf radamsa-0.3.tar.gz

If you've executed this command correctly, your output should be similar to the following screenshot:

Your directory should look something like the following when you're done:

Everything is set up now; we can begin setting up the jni directory structure and compiling Radamsa for Android. 290

Chapter 8

How to do it... To cross-compile Radamsa for Android, you should do the following: 1. You should have a directory called radamsa-0.3 after unpacking the Radamsa source inside this directory; you should create a directory called jni, just as we've done in the Cross-compiling native executables recipe. 2. Make a copy of the Android.mk file you used for the buffer overflow recipe and stick it inside the jni directory; your directory should look similar to the following screenshot:

3. Copy the radamsa.c file, which contains the Radamsa source, into the jni directory as in the following screenshot:

291

Native Exploitation and Analysis 4. Grab a copy of the Android.mk file and stick it inside the jni folder. Copying your Android.mk file should be similar to the demonstration shown in the following screenshot:

5. Edit the Android.mk file you copied in the previous step so that it looks like the following:

6. Once you're done setting up the Android.mk file, you can execute the ndk-build command; you should get the following output:

This means the build has failed. GCC also shows you which lines of code cause the error. It is, in actual fact, one issue cascading through the rest of the code, namely typedef, which aliases an unsigned long into something called in_addr_t; in the next step, we will fix this issue to get Radamsa compiled successfully.

292

Chapter 8 7. Open the radamsa.c file in your favorite code editor—preferably one that displays line numbers. Scroll down to line number 3222; you should see the following code if you're using the vim text editor:

8. In line 3222 of the radamsa.c code, replace the in_addr_t type name to an unsigned long. The code should look something like this when you've changed it correctly:

9. You should also remove the typedef command in line 2686; before editing the line, it should look like the following:

After commenting it out, it should look something like the following:

10. After you're done editing the radamsa.c source so it pleases the NDK GCC compiler, you can run the ndk-build script. If you've done everything correctly, your output should look something like this:

293

Native Exploitation and Analysis 11. After successfully building the executable you can then push it to an Android emulator as follows—assuming you have one set up already, and you've remounted the system partition as writeable:

12. Once you've pushed the Radamsa executable, you can test it by executing this command on your Android emulator: radamsa –-help

This should generate the following output:

13. You can run Radamsa on some test input to make sure everything is working fine. As an example, see how Radamsa was run using the following command to make sure everything was sane and in working condition: echo "99 bottles of beer on the wall" | radamsa

Running this command should produce an output similar to the following screenshot:

294

Chapter 8 And that's it! Radamsa is up and running on Android. The next section talks about setting up a simple fuzzing script and pointing it at dexdump to try and generate some crashes and hopefully find some exploitable vulnerabilities. If you're going to be doing some fuzzing, you will eventually need to do some bash scripting to hone Radamsa at the right targets and autonomously report input data that causes interesting behavior. Unfortunately, Android platforms don't come packaged with all the utilities that make bash scripting powerful; they don't even come with a bash shell application, mostly because it's not needed. We could use the sh shell do to our scripting, but bash is a little more powerful and robust and generally most people are more accustomed to bash scripting. Because of this, the following section of this recipe explains how to get Busybox running on an Android platform.

Setting up Busybox To get Busybox utilities (a package of useful terminal applications) on Android, you need to do the following: 1. Grab a copy of the Android port from http://benno.id.au/Android/busybox; in the example, we used wget to do this:

2. What you need to do then is prepare a busybox directory on your Android emulator— assuming you have one already set up and ready to go. For this example, the busybox directory was made in the /data/ folder; since it's writable and executable, any folder on a partition mounted with write, read, and execute permissions should work well.

295

Native Exploitation and Analysis 3. Once you've made a dedicated directory for Busybox, you can push it to the emulator using this command: adb push [path to busybox] /data/busybox/.

You should be doing something similar to the following screenshot:

4. Once you've pushed a copy of the busybox binary to your emulator, you can install the binaries by executing the following command on your emulator: /data/busybox –-install

Here's an example from a Samsung Galaxy S3 smartphone:

After executing this command, your busybox folder should look something like the following:

296

Chapter 8

Fuzzing dexdump Now that you've got your test case generator up and running and the Busybox utilities installed, you can start generating some crashes! In this example, we will see how to set up a simple script to do some "dumb" fuzz testing against dexdump, a utility that dissects an Android DEX file and prints its contents: 1. Before we start, you will need a sample DEX file; you can either get one by writing a sample "hello world" type application using the Android SDK or just grabbing the Example.dex file created in the previous chapter's recipes. If you'd like to generate this file, see the Compiling from Java to DEX recipe in Chapter 6, Reverse Engineering Applications. 2. Create a directory to base your input test case generation files in. This is the folder on the Android emulator where your script will generate files. Test them and copy the interesting ones should they cause any crashes; the /data/ directory once again is a great place to do this, though it would be good to consider emulating an SD card and saving your data there. 3. Inside your fuzzing directory—the one created in the previous step—create a bash script that contains the following code: #!/bin/bash ROOT=$1 TARGET=dexdump ITER=$2 for ((c=0;1;c++)) do cat $ROOT | radamsa -m bf,br,sr -p bu > fuzz.dex $TARGET -d fuzz.dex 2>&1 > /dev/null RET_CODE=$? echo "[$c] {$RET_CODE} ($WINS)" test $RET_CODE -gt 127 && cp fuzz.dex windexdump_$ITER"_"$c.dex && WINS=`expr $WINS + 1` done

4. Run the script in bash by executing the following command on your emulator: /data/busybox/bash; /data/busybox/source [fuzz script name] [example.dex]

And now you're fuzzing!

297

Native Exploitation and Analysis

How it works... In the first part of the How to do it… section of this recipe, we covered cross-compiling a popular fuzz test generator called Radamsa. Most of what we did is already explained in the Cross-compiling native executables recipe. Things get interesting when the NDK build script fails to compile Radamsa because of a type definition; here's what it looked like: typedef unsigned long in_addr_t;

This causes the build script to fail because the GCC compiler used by the NDK build script— namely one that was built to support the ARM Application Binary Interface—failed to recognize the effect of the type definition. When the type defined by the mentioned statement is referenced, it causes GCC to halt and report that it basically doesn't know what in_ addr_t is. This issue was resolved by removing the need for typedef by replacing the mentioning of the in_addr_t alias with the full variable type of unsigned long and commenting out the typedef statement. Once this issue was resolved, Radamsa could compile successfully and be deployed to an Android device. Then we wrote a makeshift fuzzing script to the target dexdump. To make sure you guys understand exactly what you're doing in this recipe, it's important we detail what the bash script does. The first few instructions make sure we have some useful mnemonics to help us refer to the arguments passed to the script. These instructions—appearing after the #!/bin/bash instruction—simply assign values to some variable names. After assigning these values, the script steps into a for loop with a sentinel value—the value that limits the number of times the for loop iterates—which will cause the script to iterate forever unless explicitly stopped by the user or the operating system. Inside the for loop, we see the following line: cat $ROOT | radamsa -m bf,br,sr -p bu > fuzz.dex

All this does is grab the file pointed to by the ROOT variable and feeds it to Radamsa. Radamsa then applies some randomized transformations to the file. After making the requested random transformations to the DEX file, Radamsa redirects the output to a file called fuzz.dex, which is the "fuzzed" version of the sample DEX file.

298

Chapter 8 Then dexdump is invoked with the fuzzed DEX file as an argument; here's what it looks like: $TARGET -d fuzz.dex 2>&1 > /dev/null

And all output is redirected to /dev/null, since we probably won't be interested in it. This line of code also redirects all the output from STDIN (the standard output file) to the STDERR file (the standard error output file). This allows all the output generated by the program—any that would likely clutter the screen—to be redirected to /dev/null. The next instruction looks like this: RET_CODE=$?

This records the exit code of whatever the last command was; in this case, it was dexdump. The script does this because it will reveal information about how dexdump exited. If dexdump exited execution normally, the return code will be 0; should anything have happened that caused dexdump to exit or halt abnormally—say, like a fault due to corrupted input—the exit code will be nonzero. And even more interestingly, if the fault required the operating system to halt dexdump via the use of inter-process signaling, the return code will be greater than 127. These return codes are the ones we are interested in generating since they give us a strong indication that a relatively serious flaw was exposed due to the given dexdump input. Errors like segmentation faults, which usually happen when an invalid portion of memory is used in an incorrect manner, always generate return codes higher than 127. For more detail on how exit codes or rather exit statuses work, see the Work the Shell - Understanding Exit Codes link in the See also section. Moving on, the rest of the code looks like this: echo "[$c] {$RET_CODE} ($WINS)" test $RET_CODE -gt 127 && cp fuzz.dex win-dexdump_$ITER"_"$c.dex && WINS=`expr $WINS + 1

The first instruction of this portion of the code simply helps us keep track of which iteration the script is currently executing—by printing the $c value. It also prints out the return code of the previous run of dexdump and how many notable halts have occurred. After printing out the mentioned "status indicators", the script compares the value saved in the RET_CODE variable's value to 127; if this value is greater, it makes a copy of the sample input that caused this error and increments the WINS variable by 1 to reflect that another notable error was generated.

299

Native Exploitation and Analysis

See also ff

The Work the Shell – Understanding Exit Codes Linux journal at http://www. linuxjournal.com/article/10844

ff

The Radamsa Google Code at http://code.google.com/p/ouspg/wiki/

Radamsa ff ff

The Blab Google Code at http://code.google.com/p/ouspg/wiki/Blab The Options for Code Generation Conventions web page at http://gcc.gnu.org/ onlinedocs/gcc/Code-Gen-Options.html

ff

300

The Fuzzing with Radamsa and some thoughts about coverage file at http://www. cs.tut.fi/tapahtumat/testaus12/kalvot/Wieser_20120606radamsacoverage.pdf

9

Encryption and Developing Device Administration Policies In this chapter, we will cover the following recipes: ff

Using cryptography libraries

ff

Generating a symmetric encryption key

ff

Securing SharedPreferences data

ff

Password-based encryption

ff

Encrypting a database with SQLCipher

ff

Android KeyStore provider

ff

Setting up device administration policies

Introduction The primary focus of this chapter will be on how to make use of cryptography properly to store data securely on a device. We start with creating a consistent cryptography foundation by including our own encryption implementation libraries to give support to stronger encryption algorithms on older devices. One of the straightforward items to tackle is the generation of symmetric encryption keys; however, the default settings are not always more secure. We look at the specific parameters to ensure the strongest encryption and review a common antipattern and OS bug that limits the security of the generated keys.

Encryption and Developing Device Administration Policies Then, we look at several ways in which we can securely store encryption keys using third-party libraries or a system service called the Android KeyStore that was introduced in Android 4.3. Going further, we learn how to avoid storing the key on the device altogether using a key derivation function to generate a key from the user's password or pin code. We'll cover how to integrate SQLCipher efficiently to ensure that your applications' SQLite database is encrypted to dramatically increase the security of your app data. We will wrap up with a look at the Device Administration API that is designed for enterprises to enforce device policies and safeguards to further protect the device. We implement two factitious (yet sensible) enterprise policies to ensure that the device has enabled encrypted storage and meets lock screen timeout requirements.

Using cryptography libraries One of the great things about Android using Java as the core programming language is that it includes the Java Cryptographic Extensions (JCE). JCE is a well-established, tested set of security APIs. Android uses Bouncy Castle as the open source implementation of those APIs. However, the Bouncy Castle version varies between Android versions; and only the newer versions of Android get the latest fixes. That's not all in an effort to reduce the size of Bouncy Castle; Android customizes the Bouncy Castle libraries and removes some of the services and APIs. For example, if you intend on using Elliptic Curve Cryptography (ECC), you will see provider errors when running it on Android versions below 4.0. Also, although Bouncy Castle supports the AES-GCM scheme (which we'll cover in the next recipe), you cannot use this in Android without including it separately. To solve this, we can include an application-specific implementation of cryptographic libraries. This recipe will show you how to include the Spongy Castle library, which provides a higher level of security given that it is more up-to-date as compared to Android's Bouncy Castle implementation and supports more cryptographic options. You may be wondering "why use Spongy Castle and not just include the Bouncy Castle libraries". The reason is that Android already ships with an older version of the Bouncy Castle libraries, and so we need to rename the package of this library to avoid "classloader" conflicts. So, Spongy Castle is a repackaging of Bouncy Castle. In fact, the package name could be whatever you wanted as long as it differs from org.bouncycastle.

How to do it... Let's add Spongy Castle to our Android application. 1. Download the latest Spongy Castle binaries from https://github.com/rtyley/ spongycastle/#downloads. Review the MIT X11 License (same as Bouncy Castle) to ensure that this is compatible with how you intend to use it. 302

Chapter 9 2. Extract and copy the Spongy Castle .jar files in your application's /libs directory: ‰‰

sc-light-jdk15on: Core lightweight API

‰‰

scprov-jdk15on: JCE provider (requires sc-light-jdk15on)

3. Include the following static code block in your Android Application object: static { Security.insertProviderAt(new org.spongycastle.jce.provider. BouncyCastleProvider(), 1); }

How it works... We use the static code block to call Security.insertProviderAt(). It ensures that the Spongy Castle provider that we have bundled in our application's /libs folder is used in preference. By setting the position as 1, we ensure that it gets preference over the existing security providers. The beauty of using Spongy Castle with the JCE is that no modification to the existing encryption code is needed. Throughout this chapter, we show samples of an encryption code that works equally well with either Bouncy Castle or Spongy Castle.

There's more... As mentioned, the code is available for download from GitHub; however, it is possible to build your own version. Roberto Tyley, the owner of the Spongy Castle repository, has included the become-spongy.sh bash script that does the renaming of com.bouncycastle to com. spongycastle. Therefore, you can use it on your own freshly downloaded and up-to-date version of the Bouncy Castle library, and convert it to org.spongycastle or something equally cute and catchy. The become-spongy.sh bash script is available at https://gist.github.com/scottyab/8003892

See also ff

ff

The Generating a symmetric encryption key and Password-based encryption recipes demonstrate using the JCE APIs The Spongy Castle GitHub repository at http://rtyley.github.io/

spongycastle/#downloads

303

Encryption and Developing Device Administration Policies ff

The Bouncy Castle home page at http://www.bouncycastle.org/java.html

ff

The Using the Java Cryptographic Extensions OWASP community page at https:// www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions

Generating a symmetric encryption key A symmetric key describes a key that is used for both encryption and decryption. To create cryptographically secure encryption keys in general, we use securely generated pseudorandom numbers. This recipe demonstrates how to correctly initialize the SecureRandom class and how to use it to initialize an Advanced Encryption Standard (AES) encryption key. AES is the preferred encryption standard to DES, and typically used with key sizes 128 bit and 256 bit. There are no code differences whether you are using Bouncy Castle or Spongy Castle, as noted in the previous recipe.

How to do it... Let's create a secure encryption key. 1. Write the following function to generate a symmetric AES encryption key: public static SecretKey generateAESKey(int keysize) throws NoSuchAlgorithmException { final SecureRandom random = new SecureRandom(); final KeyGenerator generator = KeyGenerator. getInstance("AES"); generator.init(keysize, random); return generator.generateKey(); }

2. Create a random 32-byte initialization vector (IV) that matches the AES key size of 256 bit: private static IvParameterSpec iv; public static IvParameterSpec getIV() { if (iv == null) { byte[] ivByteArray = new byte[32]; // populate the array with random bytes new SecureRandom().nextBytes(ivByteArray); iv = new IvParameterSpec(ivByteArray); } return iv; } 304

Chapter 9 3. Write the following function to encrypt an arbitrary string: public static byte[] encrpyt(String plainText) throws GeneralSecurityException, IOException { final Cipher cipher = Cipher.getInstance("AES/CBC/ PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, getKey(), getIV()); return cipher.doFinal(plainText.getBytes("UTF-8")); }

public static SecretKey getKey() throws NoSuchAlgorithmException { if (key == null) { key = generateAESKey(256); } return key; }

4. For completeness, the preceding snippet shows how to decrypt. The only difference is that we call the Cipher.init() method using the Cipher.DECRYPT_MODE constant: public static String decrpyt(byte[] cipherText) throws GeneralSecurityException, IOException { final Cipher cipher = Cipher.getInstance("AES/CBC/ PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, getKey(),getIV()); return cipher.doFinal(cipherText).toString(); }

For this sample, we have just stored the key and IV as a static variable; this isn't advisable for actual use. A simple approach would be to persist the key in SharedPerferences with the Context.MODE_PRIVATE flag so that a consistent key is available between application sessions. The next recipe develops this idea further to use an encrypted version of SharedPerferences.

How it works… Creating a SecureRandom object is simply a case of instantiating the default constructor. There are other constructors available; however, the default constructor uses the strongest provider available. We pass an instance of SecureRandom to the KeyGenerator class with the keysize argument, and the KeyGenerator class handles the creation of the symmetric encryption key. 256 bit is often touted as "military grade", and for most systems it is considered cryptographically secure. 305

Encryption and Developing Device Administration Policies Here we introduce an initialization vector which, in simple terms, increases the strength of the encryption, and is essential when encrypting more than one message/item. This is because messages encrypted with the same key can be analyzed together to aid message extraction. A weak IV is part of the reason why Wired Equivalent Privacy (WEP) was broken. So, it is recommended to generate a new IV for each message, and store it along with the cipher text; for example, you could pre-append or concatenate the IV to the cipher text. For the actual encryption, we use an AES instance of the Cipher object that we initiate in ENCRYPT_MODE with the newly-generated SecretKey. We then call cipher.doFinal with the bytes of our plaintext input to return a byte array containing the encrypted bytes. When requesting the AES encryption mode with the Cipher object, a common oversight that is also present in Android documentation is to simply use AES. However, this defaults to the simplest and less-secure ECB mode, specifically AES/ECB/PKCS7Padding. Therefore, we should explicitly request the stronger CBC mode AES/CBC/PKCS5Padding, as shown in the sample code.

There's more... Here we look at how to use a strong encryption mode called AES-GCM, and a common antipattern that reduces the security of the generated keys.

Using AES-GCM for strong symmetric encryption We noted that simply defining AES does not default to the strongest mode. If we include the Spongy Castle libraries, we can use the much strong AES-GCM that includes authentication, and can detect if the cipher text has been tampered with. To use AES-GCM when defining the algorithm/transformation string, use AES/GCM/NoPadding as shown in the following code: final Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding", "SC");

Antipattern – setting the seed Since Android Version 4.2, the default PseudoRandom Number Generator (PRNG) provider of SecureRandom was changed to OpenSSL. This disables the ability, which existed previously, of Bouncy Castle provider to manually seed the SecureRandom object. This was a welcome change as an antipattern emerged where developers were setting the seed. byte[] myCustomSeed = new byte[] { (byte) 42 }; secureRandom.setSeed(myCustomSeed); int notRandom = secureRandom.nextInt();

In this code sample, we can see the seed being manually set to 42, the result being that the notRandom variable would always equal the same number. Although useful for unit tests, this defeats any enhanced security from using SecureRandom to generate a cryptographic key.

306

Chapter 9

Android's PRNG bug As mentioned previously, the default provider of PseudoRandom Number Generator (PRNG) is OpenSSL since Android 4.2. However, in August 2013, a critical bug was discovered with the generation of random numbers. This was highlighted by the compromise of several Android Bitcoin wallet apps. The issue concerned the seeding of the secure random number generator; instead of using complex and individual system fingerprints, it was initialized to null. The result was similar to that of the antipattern secure keys that were generated earlier from a predictable number. The effected Android versions were Jelly Bean 4.1, 4.2, and 4.3. A fix was noted in the Some SecureRandom Thoughts Android blog article and issued to Open Handset Alliance companies. However, it's recommended that you call this fix from your application's onCreate() method in case the fix has not been applied to the device your app is running on. For convenience, here's a gist provided by GitHub of the code from Google, which can be found at https://gist.github.com/ scottyab/6498556.

See also ff

The Securing SharedPreference data recipe, where we used a generated AES key to encrypt application SharedPreferences

ff

The An Empirical Study of Cryptographic Misuse in Android Applications guide at http://cs.ucsb.edu/~yanick/publications/2013_ccs_cryptolint.pdf

ff

The SecureRandom class in the Android Developer Reference guide at https:// developer.android.com/reference/java/security/SecureRandom.html

ff

The KeyGenerator class in the Android Developer Reference guide at https:// developer.android.com/reference/javax/crypto/KeyGenerator.html

ff

The Some SecureRandom Thoughts Android blog article at http://android-

developers.blogspot.co.uk/2013/08/some-securerandom-thoughts. html

ff

The Open Handset Alliance members at http://www.openhandsetalliance.

com/oha_members.html

307

Encryption and Developing Device Administration Policies

Securing SharedPreferences data Android provides a simple framework for app developers to persistently store key-value pairs of primitive datatypes. This recipe illustrates a practical use of a pseudorandomly generated secret key and demonstrates the use of Secure-Preferences. It is an open source library that wraps the default Android SharedPreferences to encrypt the key-value pairs for protecting them against attackers. Secure-Preferences is compatible with Android 2.1+, and is licensed with Apache 2.0; hence, it is suitable for commercial development. I should add that I'm the co-creator and maintainer of the Secure-Preferences library. A good alternative to Secure-Preferences is a library called Cwac-prefs that is backed by SQLCipher (covered in a later recipe).

Getting ready Let's add the Secure-Preferences library. 1. Download or clone Secure-Preferences from GitHub at https://github.com/ scottyab/secure-preferences. The Secure-Preferences repository contains an Android library project and a sample project. 2. Link the library to your Android project as you would normally do.

How to do it... Let's get started. 1. Simply initialize the SecurePreferences object with Android context: SharedPreferences prefs = SecurePreferences(context); Editor edit = prefs.edit(); edit.putString("pref_fav_book", "androidsecuritycookbook"); edit.apply();

2. The following are several helper methods that you could add to your application to retrieve an instance of the (secure) preferences object in your application object: private SharedPreferences mPrefs; public final SharedPreferences getSharedPrefs() { if (null == mPrefs) { mPrefs = new SecurePreferences(YourApplication.this); } return mPrefs; }

Here, YourApplication.this is a reference to your application object. 308

Chapter 9 3. Then ideally, in a base application component such as BaseActivity, BaseFragment, or BaseService, you can include the following to retrieve an instance of the (secure) preferences object: private SharedPreferences mPrefs; protected final SharedPreferences getSharedPrefs() { if (null == mPrefs) { mPrefs = YourApplication.getInstance().getSharedPrefs(); } return mPrefs; }

How it works... The Secure-Preferences library implements the SharedPreferences interface; therefore, no code changes are needed to interact with it in comparison to the default SharedPreferences. Standard SharedPreferences keys and values are stored in a simple XML file and Secure-Preferences uses the same storage mechanism; except that the keys and values are transparently encrypted using an AES symmetric key. The cipher text of keys and values are encoded with base64 encoding before writing to the file. If you examine the following SharedPreference XML file; it shows without and with the Secure-Preferences library. You'll see the file from the Secure-Preferences library is a collection of seemingly random entries that give no clue to their purpose. ff

A standard SharedPreferences XML file:

ff

A SharedPreferences XML file using Secure-Preferences library: 309

Encryption and Developing Device Administration Policies The first time SecurePreferences is instantiated, an AES encryption key is generated and stored. This key is used to encrypt/decrypt all future keys/values that are saved via the standard SharedPreferences interface. The shared preference file is created with Context.MODE_PRIVATE that enforces app sandbox security and ensures that only your app has access. However, in the case of rooted devices, sandbox security cannot be relied upon. More correctly, Secure-Preferences is obfuscating the preferences; therefore, this should not be considered as bulletproof security. Instead, view it as a quick win for incrementally making an Android app more secure. For instance, it will stop users on rooted devices easily modifying your app's SharedPreferences. Secure-Preferences could be further enhanced to generate the key based on the user input password using a technique called password-based encryption (PBE), which is covered in the next chapter.

See also ff

The SharedPreferences interface in the Android Developers Reference guide at https://developer.android.com/reference/android/content/ SharedPreferences.html

ff

Article on Secure-Preferences by Daniel Abraham at http://www.codeproject. com/Articles/549119/Encryption-Wrapper-for-AndroidSharedPreferences

ff

The Secure-Preferences library at https://github.com/scottyab/securepreferences

ff

The CWAC-prefs library (an alternative to Secure-Preferences) at https://github. com/commonsguy/cwac-prefs

Password-based encryption One of the larger issues with encryption is the management and secure storage of encryption keys. Until now and in the pervious recipes, we have settled for storing the key in SharedPreferences as recommended on the Google developer's blog; however, this is not ideal for rooted devices. On rooted devices, you cannot rely on the Android system security sandbox as the root user has access to all areas. By that we mean, unlike on a unrooted device, other apps can obtain elevated root privileges. The potential for an insecure app sandbox is an ideal case for password-based encryption (PBE). It offers the ability to create (or more correctly derive) the encryption key at runtime using a passcode/password that is usually supplied by the user. Another solution for key management is to use a system keychain; Android's version of this is called the Android KeyStore, which we will review in a later recipe. 310

Chapter 9

Getting ready PBE is part of the Java Cryptography Extension, and so is already included in Android SDK. In this recipe, we'll use an initialization vector (IV) and salt as part of the key derivation. We covered the IV in the previous recipe, and it helps create more randomness. So, even the same messages that are encrypted with the same key would produce different cipher texts. Salt is similar to an IV in that it is usually a random data that is added as part of the encryption process to enhance its cryptographic strength.

How to do it... Let's get started. 1. First, we define some helper methods to retrieve or create IV and salt. We will use them as part of the key derivation and encryption: private static IvParameterSpec iv; public static IvParameterSpec getIV() { if (iv == null) { iv = new IvParameterSpec(generateRandomByteArray(32)); } return iv; } private static byte[] salt; public static byte[] getSalt() { if (salt == null) { salt = generateRandomByteArray(32); } return salt; } public static byte[] generateRandomByteArray(int sizeInBytes) { byte[] randomNumberByteArray = new byte[sizeInBytes]; // populate the array with random bytes using non seeded secure random new SecureRandom().nextBytes(randomNumberByteArray); return randomNumberByteArray; }

311

Encryption and Developing Device Administration Policies 2. Generate the PBE key: public static SecretKey generatePBEKey(char[] password, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException { final int iterations = 10000; final int outputKeyLength = 256; SecretKeyFactory secretKeyFactory = SecretKeyFactory .getInstance("PBKDF2WithHmacSHA1"); KeySpec keySpec = new PBEKeySpec(password, salt, iterations, outputKeyLength); SecretKey secretKey = secretKeyFactory.generateSecret(keySpec); return secretKey; }

3. Write a sample method showing how to encrypt using a newly derived PBE key: public static byte[] encrpytWithPBE(String painText, String userPassword) throws GeneralSecurityException, IOException { SecretKey secretKey = generatePBEKey(userPassword.toCharArray(),getSalt()); final Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, secretKey, getIV()); return cipher.doFinal(painText.getBytes("UTF-8")); }

4. Write a sample method showing how to decrypt cipher text using a newly derived PBE key: public static String decrpytWithPBE(byte[] cipherText, String userPassword) throws GeneralSecurityException, IOException { SecretKey secretKey = generatePBEKey(userPassword.toCharArray(),getSalt()); final Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, secretKey, getIV()); return cipher.doFinal(cipherText).toString(); } 312

Chapter 9

How it works... In step 1, we define methods similar to the ones we have used in the previous recipes. Just to reiterate, it's essential for the salt and IV to be consistent to be able to decrypt encrypted data. For example, you could generate a salt per app and store it in SharedPreferences. Also, the size of the salt is typically the same as the key size, which in this example is 32 bytes / 256 bit. Typically, you would save the IV along with cipher text to be retrieved upon decryption. In step 2, we derive a 256 bit AES SecretKey using PBE with the user's password. PBKDF2 is a commonly used algorithm for deriving a key from a user password; the Android implementation of this algorithm is noted as PBKDF2WithHmacSHA1. As part of the PBEKeySpec, we define the number iterations used internally within SecretKeyFactory to generate the secret key. The larger the number of iterations, the longer the key derivation takes. To defend against Brute Force attacks, it is recommended that the time to derive the key should be more than 100ms; Android uses 10,000 iterations to generate the encryption key for encrypted backups. Steps 3 and 4 demonstrate using the secret key with the Cipher object to encrypt and decrypt; you'll notice that these are very similar to the methods noted in an earlier recipe. But of course, for decryption, the IV and salt are not randomly generated but re-used form the encryption step.

There's more… In Android 4.4, a subtle change was made to the SecretKeyFactory class when dealing with PBKDF2WithHmacSHA1 and Unicode passphrases. Previously, PBKDF2WithHmacSHA1 only looked at the lower eight bits of Java characters in passphrases; the change to the SecretKeyFactory class allowed the use of all the available bits in Unicode characters. To maintain backward compatibility, you can use this new key generation algorithm PBKDF2WithHmacSHA1And8bit. If you are using ASCII, this change will not affect you. Here's a code sample of how to maintain backward compatibility: SecretKeyFactory secretKeyFactory; if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1An d8bit"); } else { secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1"); }

313

Encryption and Developing Device Administration Policies

See also ff

The SecretKeyFactory class in the Android Developers Reference guide at https://developer.android.com/reference/javax/crypto/ SecretKeyFactory.html

ff

The PBEKeySpec class in the Android Developers Reference guide at https://

developer.android.com/reference/javax/crypto/spec/PBEKeySpec. html

ff

Java Cryptography Extension in the Java Cryptography Architecture (JCA) Reference guide at http://docs.oracle.com/javase/6/docs/technotes/guides/ security/crypto/CryptoSpec.html

ff

The Using Cryptography to Store Credentials Safely Android Developer's blog at http://android-developers.blogspot.co.uk/2013/02/usingcryptography-to-store-credentials.html

ff

Sample PBE project by Nikolay Elenkov at https://github.com/nelenkov/ android-pbe

ff

Changes to the SecretKeyFactory API in Android 4.4 at http://androiddevelopers.blogspot.co.uk/2013/12/changes-to-secretkeyfactoryapi-in.html

Encrypting a database with SQLCipher SQLCipher is one of the simplest ways to enable secure storage in an Android app, and it's compatible for devices running Android 2.1+. SQLCipher uses 256-bit AES in CBC mode to encrypt each database page; in addition, each page has its own random initialization vector to further increase security. SQLCipher is a separate implementation of the SQLite database, and rather than implementing its own encryption, it uses the widely used and tested OpenSSL libcrypto library. While this ensures greater security and wider compatibility, it does come with a relatively high .apk file footprint of roughly 7 MB. This additional weight is probably the only disadvantage of using SQLCipher. According to the SQLCipher website, in terms of read/write performance, there is a ~5 percent performance hit that is negligible unless your app is performing complex SQL joins (but it is worth noting that these aren't great in SQLite either). The good news for commercial development is that not only is SQLCipher for Android open source, it is also released under a BSD-style license.

314

Chapter 9

Getting ready To start with, we will download and set up your Android project with SQLCipher. 1. Download the latest binary packages via the link on the SQLCipher GitHub page, or follow this direct link https://s3.amazonaws.com/sqlcipher/SQLCipher+fo r+Android+v3.0.0.zip. 2. Unpack the ZIP file. 3. Copy the icudt46l.zip file from /assets to /assets of your application. 4. The /libs directory contains several JARs and folders containing native libraries. 5. Copy the *.jar files to you application's /libs directory. You may already be using Commons-codec and/or guava; if so, check if the version is compatible with SQLCipher. 6. Both the ARM and x86 implementations of the native code are included; however, you'll probably only need the ARM-based native libraries. So, copy the armeabi folder to /libs of your application.

How to do it... Let's create an encrypted SQLite database. 1. There are several ways to handle SQLite database, either by working directly with the SQLiteDatabase object or using SQLiteOpenHelper. But generally, if you are already using an SQLite database in your app, simply replace the import android. database.sqlite.* statement with import net.sqlcipher.database.*. 2. The simplest way to create an encrypted SQLCipher database is to call openOrCreateDatabase(…) with a password: private static final int DB_VERSION = 1; private static final String DB_NAME = "my_encrypted_data.db"; public void initDB(Context context, String password) { SQLiteDatabase.loadLibs(context); SQLiteDatabase database = SQLiteDatabase. openOrCreateDatabase(DB_NAME, password, null); database.execSQL("create table MyTable(a, b)"); }

315

Encryption and Developing Device Administration Policies 3. If you're using the SQLiteOpenHelper object, you would have extended it. In this example, we'll assume that your extension is called SQLCipherHelper. When you call getWritableDatabase, you'll notice that you are required to pass a string argument (the database passphrase) with SQLCipher's version of SQLiteOpenHelper: import net.sqlcipher.database.SQLiteOpenHelper; public class SQLCipherHelper extends SQLiteOpenHelper { private static final int DB_VERSION = 1; private static final String DB_NAME = "my_encrypted_data.db"; public SQLCipherHelper (Context context) { super(context, DB_NAME, null, DB_VERSION); SQLiteDatabase.loadLibs(context); } }

The SQLCipher native libraries need to be loaded before any database operation can be completed using the SQLiteDatabase.loadLibs(context) statement. Ideally this call should be located in the onCreate lifecycle method of either a content provider or your application's application object.

How it works… The sample code illustrates the two most common ways of working with SQLite database: directly with the SQLiteDatabase object or using SQLiteOpenHelper. The main point to note is the difference between using the net.sqlcipher.database API and the default SQLite API is the use of passphrase when we create or retrieve the SQLCipher database object. SQLCipher derives the encryption key using PBKDF2, as covered in the previous recipe. The default configuration generates a 256 bit AES key using 4,000 iterations at the time of writing this book. It's the job of the developer to decide how to generate the passphrase. You could generate using a PRNG on a per app basis or for greater randomness and so greater security input by the user. SQLCipher transparently encrypts and decrypts with the derived key. It also uses a message authentication code (MAC) to ensure both integrity and authenticity, ensuring that the data has not been accidently or maliciously tampered with.

316

Chapter 9

There's more... It's worth noting that because much of SQLCipher is written in native C/C++, it is compatible with other platforms such as Linux, Windows, iOS, and Mac OS.

IOCipher Think of IOCipher as SQLCipher's long lost cousin from the good people at the Guardian project. It offers the ability to mount an encrypted virtual filesystem that allows developers to transparently encrypt all files within their app's directory. As with SQLCipher, IOCipher relies on the developer to manage the password and supports Android 2.1+. One huge advantage of IOCipher is that it is a clone of the java.io API. This means that from an integration perspective, there are few code changes to the existing file management code. The difference is that the filesystem is first mounted with a password, and instead of using java.io.File, you use info.guardianproject.iocipher.File. Even though IOCipher uses parts of SQLCipher, it is less mature but worth investigating if you wish to protect the files rather than data within SQLite database.

See also ff

The SQLCipher downloads at http://sqlcipher.net/downloads/

ff

The SQLCipher for Android source code at https://github.com/sqlcipher/ android-database-sqlcipher

ff

The IOCipher: Virtual Encrypted Disks project at https://guardianproject. info/code/iocipher/

Android KeyStore provider In Android 4.3, a new facility was added to allow apps to save private encryption keys in a system KeyStore. Called Android KeyStore, it restricts access only to the app that created them, and it was secured using the device pin code. Specifically, the Android KeyStore is a certificate store, and so only public/private keys can be stored. Currently, arbitrary symmetric keys such as an AES key cannot be stored. In Android 4.4, the Elliptic Curve Digital Signature Algorithm (ECDSA) support was added to the Android KeyStore. This recipe discusses how to generate a new key, and save and fetch it from the Android KeyStore.

317

Encryption and Developing Device Administration Policies

Getting ready As this feature was only added in Android 4.3, ensure that the minimum SDK version in the Android manifest file is set to 18.

How to do it... Let's get started. 1. Create a handle on your app's KeyStore: public static final String ANDROID_KEYSTORE = "AndroidKeyStore"; public void loadKeyStore() { try { keyStore = KeyStore.getInstance(ANDROID_KEYSTORE); keyStore.load(null); } catch (Exception e) { // TODO: Handle this appropriately in your app e.printStackTrace(); } }

2. Generate and save the app's key pair: public void generateNewKeyPair(String alias, Context context) throws Exception { Calendar start = Calendar.getInstance(); Calendar end = Calendar.getInstance(); // expires 1 year from today end.add(1, Calendar.YEAR); KeyPairGeneratorSpec spec = new KeyPairGeneratorSpec. Builder(context) .setAlias(alias) .setSubject(new X500Principal("CN=" + alias)) .setSerialNumber(BigInteger.TEN) .setStartDate(start.getTime()) .setEndDate(end.getTime()) .build(); // use the Android keystore KeyPairGenerator gen = KeyPairGenerator.getInstance("RSA", ANDROID_KEYSTORE); gen.initialize(spec); 318

Chapter 9 // generates the keypair gen.generateKeyPair(); }

3. Retrieve the key with a given alias: public PrivateKey loadPrivteKey(String alias) throws Exception { if (keyStore.isKeyEntry(alias)) { Log.e(TAG, "Could not find key alias: " + alias); return null; } KeyStore.Entry entry = keyStore.getEntry(KEY_ALIAS, null); if (!(entry instanceof KeyStore.PrivateKeyEntry)) { Log.e(TAG, " alias: " + alias + " is not a PrivateKey"); return null; } return ((KeyStore.PrivateKeyEntry) entry).getPrivateKey(); }

How it works... The KeyStore class has been around since API level 1. To access the new Android KeyStore, you use a special constant "AndroidKeystore". According to the Google documentation, there is a strange issue with the KeyStore class that requires you to call the load(null) method even though you are not loading the KeyStore from an input stream; otherwise, you may experience a crash. When generating the key pair, we populate a KeyPairGeneratorSpec.Builder object with the required details—including the alias that we use to retrieve it later. In this example, we set an arbitrary validation period of 1 year from the current date and default the serial to TEN. Loading a key from the alias is as simple as loading keyStore.getEntry("alias", null); from here, we cast to the PrivateKey interface so that we can use it in our encryption/decryption.

There's more... The API for the KeyChain class was also updated in Android 4.3 to allow developers to determine whether the device supports hardware-backed certificate store or not. This basically means that the device supports a secure element for the certificate store. This is an exciting enhancement as it promises to keep the certificate store safe even on rooted devices. However, not all devices support this hardware feature. The LG Nexus 4, a popular device, uses ARM's TrustZone for hardware protection. 319

Encryption and Developing Device Administration Policies

See also ff

The KeyStore class in the Android Developer reference guide at https:// developer.android.com/reference/java/security/KeyStore.html

ff

The KeyStore API sample at https://developer.android.com/samples/ BasicAndroidKeyStore/index.html

ff

The Credential storage enhancements in Android 4.3 article by Nikolay Elenkov at http://nelenkov.blogspot.co.uk/2013/08/credential-storageenhancements-android-43.html

ff

ARM TrustZone at http://www.arm.com/products/processors/ technologies/trustzone/index.php

Setting up device administration policies First introduced in Android 2.2, the Device Admin policies grant abilities to apps to gain a greater level of device control. These features are primarily aimed at enterprise app developers given their controlling, restrictive, and potentially destructive nature, and offer an alternative to a third-party Mobile Device Management (MDM) solution. In general, this is not aimed at consumer apps unless a trust relationship already exists, for example, a bank and a banking app. This recipe will define two device policies designed to strengthen the device that could be part of an enterprise's mobile security policy: ff

Enforce device encryption (which also ensures that a device pin/password is set)

ff

Enforce maximum screen lock timeout

Although device encryption is no replacement for ensuring that the app data is encrypted properly, it does add to the overall device security. Reducing the maximum screen lock timeout helps protect the device if left unattended. There is no restriction on the number of apps enforcing device policies. If there is a conflict on policy, the system defaults to the most secure policy. For example, if there was a conflict on the password strength requirement's policy, the strongest policy would be applied to satisfy all policies.

Getting ready The Device Admin policies were added in Version 2.2; however, this feature and the specific restriction for device encryption were not added until Android 3.0. Therefore, for this recipe, ensure that you are building against a SDK above API 11.

320

Chapter 9

How to do it... Let's get started. 1. Define a device administration policy by creating a new .xml file called admin_ policy_encryption_and_lock_timeout.xml in the res/xml folder with the following content:

2. Create a class that extends the DeviceAdminReceiver class. This is the app entry point for system broadcasts relating to device administration: public class AppPolicyReceiver extends DeviceAdminReceiver { // Called when the app is about to be deactivated as a device administrator. @Override public void onDisabled(Context context, Intent intent) { // depending on your requirements, you may want to disable the // app or wipe stored data e.g clear prefs context.getSharedPreferences(context.getPackageName(), Context.MODE_PRIVATE).edit().clear().apply(); super.onDisabled(context, intent); } @Override public void onEnabled(Context context, Intent intent) { super.onEnabled(context, intent); // once enabled enforce AppPolicyController controller = new AppPolicyController(); controller.enforceTimeToLock(context); controller.shouldPromptToEnableDeviceEncrpytion(context); } @Override public CharSequence onDisableRequested(Context context, Intent intent) { 321

Encryption and Developing Device Administration Policies // issue warning to the user before disable e.g. app prefs // will be wiped return context.getText(R.string.device_admin_disable_policy); } }

3. Add receiver definition to your Android manifest file: <meta-data android:name="android.app.device_admin" android:resource="@xml/admin_policy_encryption_and_lock_ timeout" />

Defining the receiver allows AppPolicyReceiver to receive system broadcast intents to disable/request disabling of the admin settings. You should also notice that this is where we reference the policy XML file in the metadata via the filename admin_policy_encryption_and_lock_timeout. 4. A device policy controller handles communication with DevicePolicyManager with any additional application-specific logic. The first method that we defined is for other application components (such as an activity) to validate device admin status and to get intents that are specific to device admin: public class AppPolicyController { public boolean isDeviceAdminActive(Context context) { DevicePolicyManager devicePolicyManager = (DevicePolicyManager) context .getSystemService(Context.DEVICE_POLICY_SERVICE); ComponentName appPolicyReceiver = new ComponentName(context, AppPolicyReceiver.class); return devicePolicyManager.isAdminActive(appPolicyReceiver); } 322

Chapter 9 public Intent getEnableDeviceAdminIntent(Context context) { ComponentName appPolicyReceiver = new ComponentName(context, AppPolicyReceiver.class); Intent activateDeviceAdminIntent = new Intent( DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN); activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_DEVICE_ADMIN, appPolicyReceiver); // include optional explanation message activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_ADD_EXPLANATION, context.getString(R.string.device_admin_activation_ message)); return activateDeviceAdminIntent; } public Intent getEnableDeviceEncryptionIntent() { return new Intent(DevicePolicyManager.ACTION_START_ ENCRYPTION); }

5. In AppPolicyController, we now define the method that actually enforces the lock screen timeout. We've arbitrarily chosen a maximum lock time of 3 minutes, but this should align with an enterprise's security policy: private static final long MAX_TIME_TILL_LOCK = 3 * 60 * 1000; public void enforceTimeToLock(Context context) { DevicePolicyManager devicePolicyManager = (DevicePolicyManager) context .getSystemService(Context.DEVICE_POLICY_SERVICE); ComponentName appPolicyReceiver = new ComponentName(context, AppPolicyReceiver.class); devicePolicyManager.setMaximumTimeToLock(appPolicyReceiver, MAX_TIME_TILL_LOCK); }

323

Encryption and Developing Device Administration Policies 6. Encrypting the device may take some time depending on the device's hardware and external storage size. As part of enforcing the device encryption policy, we need a way to check whether the device is encrypted or encryption is in progress: public boolean shouldPromptToEnableDeviceEncryption(Context context) { DevicePolicyManager devicePolicyManager = (DevicePolicyManager) context .getSystemService(Context.DEVICE_POLICY_SERVICE); int currentStatus = devicePolicyManager. getStorageEncryptionStatus(); if (currentStatus == DevicePolicyManager.ENCRYPTION_STATUS_ INACTIVE) { return true; } return false; } }

7. We define an example activity to show how it's possible to integrate AppPolicyController to help direct the user to enable system settings and handle the responses: public class AppPolicyDemoActivity extends Activity { private private 12; private private

static final int ENABLE_DEVICE_ADMIN_REQUEST_CODE = 11; static final int ENABLE_DEVICE_ENCRYPT_REQUEST_CODE = AppPolicyController controller; TextView mStatusTextView;

@Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_app_policy); mStatusTextView = (TextView) findViewById(R. id.deviceAdminStatus); controller = new AppPolicyController(); if (!controller.isDeviceAdminActive(getApplicationContext())) { // Launch the activity to have the user enable our admin. startActivityForResult( controller

324

Chapter 9 .getEnableDeviceAdminIntent(getApplicationConte xt()), ENABLE_DEVICE_ADMIN_REQUEST_CODE); } else { mStatusTextView.setText("Device admin enabled, yay!"); // admin is already activated so ensure policies are set controller.enforceTimeToLock(getApplicationContext()); if (controller.shouldPromptToEnableDeviceEncrpytion(this)) { startActivityForResult( controller.getEnableDeviceEncrpytionIntent(), ENABLE_DEVICE_ENCRYPT_REQUEST_CODE); } } }

8. Here, we implement the onActivityResult(…) activity lifecycle method to handle the results from the system activities when enabling device administration and encryption: @Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); if (requestCode == ENABLE_DEVICE_ADMIN_REQUEST_CODE) { if (resultCode != RESULT_OK) { handleDevicePolicyNotActive(); } else { mStatusTextView.setText("Device admin enabled"); if (controller.shouldPromptToEnableDeviceEncrpytion(this)) { startActivityForResult( controller.getEnableDeviceEncryptionIntent(), ENABLE_DEVICE_ENCRYPT_REQUEST_CODE); } } } else if (requestCode == ENABLE_DEVICE_ENCRYPT_REQUEST_CODE && resultCode != RESULT_OK) { handleDevicePolicyNotActive(); } }

325

Encryption and Developing Device Administration Policies 9. Finally, we add a method to handle the process if users choose not to activate this app as a device administrator. In this sample, we simply post a message; however, it is likely that you would prevent the app from running as the device wouldn't compliment the enterprise security policy: private void handleDevicePolicyNotActive() { Toast.makeText(this, R.string.device_admin_policy_breach_ message, Toast.LENGTH_SHORT).show(); } }

How it works... AppPolicyDemoActivity shows an example of handling user interactions and callbacks in onActivityResult(…) from the system activities for enabling the device administration and device encryption. AppPolicyController encapsulates interactions with DevicePolicyManager and

contains the logic to apply the policies. You could locate this code in your activity or fragment, but it's a better practice to keep it separate.

Defining the policies is as simple as defining them in the element of the device admin file. This is referenced in the metadata element of the AppPolicyReceiver XML declaration in the Android manifest: <meta-data android:name="android.app.device_admin" android:resource="@xml/admin_policy_encryption_and_lock_timeout" />

Given the elevated privileges of being a device administrator, apps are not enabled as device administrators on installation as a security precaution. This is achieved post install by using a build-in system activity that is requested using an intent with a special action AppPolicyController.getEnableDeviceAdminIntent() as shown. This activity is started with startActivityForResult(). This returns a callback to onActivityResult(…) where the users choose to activate or cancel. Nonactivation of the device administration could count as being in breach of the enterprise security policy. Therefore, if the user doesn't activate it, it might be enough to simply prevent the user from using the app until it is activated. We use the DevicePolicyManager.isActive(…) method to check if the app is active as a device administrator. Typically, this check should be performed on the entry points to the application, such as the first activity.

326

Chapter 9 The job of AppPolicyReceiver is to listen for device administration system events. To receive these events, firstly you have to extend DeviceAdminReceiver and define Receiver in the Android manifest file. The OnEnabled() callback is where we enforce the lock screen timeout as it requires no additional user input. Enabling device encryption requires user confirmation; therefore, we initiate this from the activity. AppPolicyReceiver will also receive an onDisabled event if the user disables this

application as a device administrator. What to do when a user disables your app as device administrator will vary between apps, as mentioned earlier it depends on enterprise security policy. There is also an onDisableRequested callback method that allows us to display a specific message to the user, detailing the consequences of disabling the application. In this example, we wipe the SharedPreferences to ensure that data is not at risk while the device is noncompliant.

There's more... In addition to the policies used in this recipe, the device admin can enforce the following: ff

Password enabled

ff

Password complexity (more control over this was added in 3.0)

ff

Password history since 3.0

ff

Maximum failed password attempts before factory reset

ff

Wipe device (factory reset)

ff

Lock device

ff

Disable lock screen widgets (since 4.2)

ff

Disable camera (since 4.0)

Users cannot uninstall apps that are active device administrators. To uninstall, they must first deactivate the app as a device administrator, and then uninstall it. This allows you to perform any necessary functions in DeviceAdminReceiver.onDisabled(), for example, reporting an incident to a remote server. Android 4.4 saw the introduction of an optional device admin feature constant to be used in the tag in the app's manifest.xml file. This declares that the app requires device admin feature and ensures correct filtering on the Google Play store.

327

Encryption and Developing Device Administration Policies

Disabling device camera An interesting feature added in Android 4.0 was the ability to disable camera use. This can be useful for organizations looking to limit data leakage. The following code snippet shows the policy to enable an app to disable camera use:

See also ff

The Device Administration API in the Android Developers Reference guide at

https://developer.android.com/guide/topics/admin/device-admin. html ff

The Device Admin sample application at https://developer.android.com/ guide/topics/admin/device-admin.html#sample

ff

The Enhancing Security with Device Management Policies web page in the Android Developers training guide at https://developer.android.com/training/ enterprise/device-management-policy.html

ff

328

FEATURE_DEVICE_ADMIN in the Android Developers Reference guide at https://developer.android.com/reference/android/content/pm/ PackageManager.html#FEATURE_DEVICE_ADMIN

Index Symbols -a [action] 61 -alias tool 47 -c [category] 61 -d [data uri] 61 -ecn [extra key] [component name] 61 -e [extra key] [string value] 61 -efa [extra key] [float value, float value,...] 62 -ef [extra key] [float value] 61 -eia [extra key] [integer value, integer value,...] 61 -ei [extra key] [integer value] 61 -el [extra key] [long value] 61 .end method 224 -eu [extra key] [uri value] 61 -ez [extra key] [boolean value] 61 -f [flags] 61 .finduri module 143 -keyalg tool 47 -keysize tool 47 -keystore tool 47 .load() method 242 -n [component] 61 -t [mime type] 61 -t switch 27 tag 327 -validity tool 47 -v tool 47

A activities enumerating 95, 97 launching 106-108

activity manager interacting with, ADB used 59-62 used, for intent sniffing 129-134 ADB about 29, 59, 119 applications, installing onto AVD 31 used, for activity manager interaction 59-62 used, for application resource extracting 6369 using, to interact with AVD 29, 30 adb push command 127 Address Resolution Protocol (ARP) 161 ADT about 8 alternative installations 18-22 installing 8-11 Advanced Encryption Standard (AES) encryption key 304 AES-GCM 306 allowClearUserData attribute 56 Android enabling 24-26 Android application reverse engineering, need for 196, 197 signing 45-47 android:authorities attribute 59 Android Debug Bridge. See  ADB android:description attribute 54, 171 Android Development Tools. See  ADT android:enabled attribute 58 android:exported attribute 57, 166 android:icon attribute 54 android:isolatedProcess attribute 58 Android KeyStore 302. See  KeyStore

android:label attribute 54 Android logcat information, disclosing via 118-122 AndroidManifest.xml file inspecting 49- 52 working 52-59 android:name attribute 54, 57, 170 android:permission attribute 57 AndroidPinning 255 Android processes debugging, GDB server used 232 android:protectionLevel attribute 55, 170 android:readPermission attribute 59 Android Virtual Device (AVD) 35 Android Virtual Devices. See  AVDs android:writePermission attribute 59 Ant build system DexGuard, enabling for 190 ant release command 192 API hiding 189 API sources updating 16 APK file 45 apktool 49 app.broadcast.info module 104 application properties 116, 117 protecting, from another 117 sensitive information communication, protecting 118 user related data, examples 116 application attack surfaces determining 104-06 application certificate enumerator writing 112-114 application certificates inspecting 34-44 requirements 34 application components securing 166-168 ApplicationInfo class 184 application native libraries decompiling 231 Application Packages (APKs) 31 Application Programming Interfaces (APIs) 8

330

application resources extracting, via ADB 63-69 application signature tamper detection, responding to 181 verifying 48, 177-180 assumeNoeffects attribute 188 AVDs about 27 application, installing via ADB 31 creating 27, 28 external storage, emulating 28 files, copying off to 30 files, copying onto 30 interacting with, ADB used 29, 30 partition sizes 28 AVs memory card, emulating 28

B broadcast receivers attacking 139-141 enumerating 103, 104 browser_autopwn module 164 Busybox setting up 295 bytesToHex() method 255

C CACert 249 checkClientTrusted() method 254 checkServerTrusted method 246, 251 Cipher.init() method 305 ClassDefs section 213, 214 components securing, with custom properties 168-170 content provider paths protecting 171-173 content providers enumerating 98, 99 createClientConnectionManager method 242 cryptography libraries using 302, 303

CURL 289 custom properties used, for component securing 168, 169 CVE-2010-4804 URL 147 Cwac-prefs 308

D Dalvik bytecode about 219 interpreting 218 setting up 220-226 Dalvik Executable files. See  DEX files dangerous attribute 55 Data Access Object (DAO) 175 database encrypting, with SQLCipher 314-317 debuggable attribute 56 Denial of Service (DoS) 135 description attribute 56 device administration policies AppPolicyDemoActivity, working 326 device camera, disabling 328 setting up 320-326 DeviceAdminReceiver class 321 DevicePolicyManager.isActive(…) method 326 DEX decompiling, to Java 227-230 Java, compiling to 197-199 Dex2Jar tool 227 dexdump fuzzing 297, 299 dexdump utility 215 DEX file header 201-205, 206 DEX files decompiling 200-217 format 200 DEX files format about 200 ClassDefs section 212, 214 DEX file header 201-207 FieldIds section 211 MethodIds section 211, 212 ProtoIds section 210 StringIds section 207, 208 TypeIds section 209

DexGuard comparing, with ProGuard 192 enabling, for Ant build system 190 enabling, for Gradle build system 190, 193 official website 193 used, for advanced code obfuscation 189193 DexGuard Eclipse plugin installing 190 DexMethod 214 drozer about 72 GitHub repository 95 session, running 87 setting up 79-87 drozer module writing 108-110 drozer session running 87, 89 drozer (Windows installer) option 80

E Elliptic Curve Cryptography (ECC) 302 Elliptic Curve Digital Signature Algorithm (ECDSA) 317 emulator detecting 182, 183 enabled attribute 56 exclusive ORs (XORs) 203 execute method 111 eXtensible Markup Language (XML) 53

F fetchAndPrintPinHashs method 250 FieldIds section 211 file permissions base 8 259 Execute ability (x) 259 inspecting 258-268 Read ability (r) 259 Set Group ID ability (s) 259 Set User ID ability (s) 259 sticky bit 260 Write ability (w) 259 find -exec command 267 findX509TrustManager() method 245 331

frame 219 Fuzz testing 289

G gdb command 236 GDB server used, for Android processes debug 232-236 genkey tool 47 getAcceptedIssuers() methods 254 get_provider() function 99 Gradle build system DexGuard, enabling for 190 gradle releaseCompile command 192 GrantURI 144 grant URI mechanism 173

I installed packages APK Path 94 Application Label 94 Data Directory 94 enumerating 90-94 GID 94 Process Name 94 Shared Libraries 94 Shared User ID 94 UID 94 Uses Permissions 94 version 94 installer detecting 182, 183 inter-process communications (IPC) 167 Intrusion Detection System (IDS) 128 invoke-virtual method 226 IOCipher about 317 advantage 317

J Java compiling, to DEX 197-199 DEX, decompiling to 227-230 Java Cryptographic Extensions (JCE) 302 Java Development Kit. See  JDK java -jar command 220 332

Java JDK 45 JD-GUI tool 227, 228 JDK about 12 installing 12-15

K KeyStore 317-319 keytool command 240 kill command 62

L Linux 238 load(null) method 319 LocalTrustStoreMyHttpClient class 243 LocalTrustStoreTrustManager class 255

M Mac 238 man-in-the-middle. See  MITM attack Memory size dialog 77 Mercury 72 META-INF folder contents 41 MethodIds section 211, 212 MITM attack about 158, 250 on applications 158-160 on mobile phones 161-164 Mobile Device Management (MDM) 320

N Native Development Kit. See  NDK native executables cross-compiling 268-275 native exploitation techniques learning, need for 258 nc command 127 NDK about 22, 23 installing 23 Netcat 124 network traffic inspecting 123-128

prerequisites 124 network traffic, prerequisites Netcat 124 TCPdump for Android 124 Wireshark 124 normal attribute 55

O objdump tool 270 onCreate() method 307 onDisabled event 327 OnionKit library StrongTrustManager, using from 247, 248 OpenSSL 238 Openssl -showcerts command 239 Orbot 249 OrbotHelper class 249

P PackageManager class 184 password-based encryption (PBE) 310 permission group defining 170 pinning 249 Process ID (PID) 234 ProGuard comparing, with DexGuard 192 limitations 188, 189 output 188 used, for log message removal 184-188 proguard.config property 188 ProtoIds section 210 PseudoRandom Number Generator (PRNG) 306 PublicKeyExtractingTrustManager class 253 push command 127

R race condition vulnerabilities exploiting 276-278 exploiting, factors 276 exploiting, steps 279, 280 Radamsa about 289 Busybox, setting up 295, 296

cross-compiling, for Android 291-295 dexdump, fuzzing 297, 298 obtaining 289, 290 Radamsa fuzzer 289 read/write permissions 144 registers 219 ReTrace tool 188 reverse engineering 196

S Santoku about 72 installing 73-78 setting up 73-78 Secure Hashing Algorithm (SHA) 203 Secure-Preferences 308 Secure Sockets Layer. See  SSL self-signed SSL certificates antipattern 246 HttpsUrlConnection 243, 245 issues 238 using, in live environment 243 validating 238-243 sensitive information communication extra-device communication 118 inter-application communication 118 inter-component communication 118 services attacking 135-138 enumerating 100-102 signature attribute 55 signatureOrSystem attribute 55 signatures inspecting 34-44 SQLCipher used, for database encryption 314-317 SQL-injection attack defending against 174, 176 SQL-injection vulnerable content providers debuggable applications, exploiting 152-157 enumerating 150, 152 SSL 237 SSL pinning about 249, 250 enhancements 255 limitations 256 333

steps 250-255 stack canary 272 stack memory corruption exploiting 281-288 standard filesystem folders /acct 261 /cache 261 /charger 262 /config 262 /data 261 /default.prop 262 /dev 261 /etc 261 /init 262 /init[device_name].rc 262 /init.rc 262 /mnt 261 /proc 261 /root 261 /sbin 261 /sdcard 261 /storage 262 /sys 261 /system 261 /uevent[device_name].rc 262 /ueventd.rc 262 /vendor 261 sticky bit 260 string-encryption feature 189 String.equalsIgnoreCase() method 180 StringIds section 207, 208 StrongTrustManager class about 249 using, from OnionKit library 247 Substitute User (SU) 126 su substitute 233 symmetric encryption key about 304 AES-GCM, using 306 creating 304-306 SystemProperties.java class 184

334

T tamper protecting, by debug flag detection 181-184 protecting, by emulator detection 182, 183 protecting, by installer detection 181 Tor project 249 TrustManager.checkServerTrusted server(…) method 248 TrustManager class 253 truststore 241 typedef command 293 TypeIds section 209

U Uniform resource identifiers (URIs) 172 Unzip 45

V validateAppSignature() method 180 validateCertificatePin method 256 vulnerable content providers about 141 data, extracting from 144-147 data, inserting into 148, 149 enumerating 142, 144 vulnerable function 286

W Wget 289 Windows 239 WinZip 45 Wired Equivalent Privacy (WEP) 306 Wireshark 124

Thank you for buying

Android Security Cookbook About Packt Publishing

Packt, pronounced 'packed', published its first book "Mastering phpMyAdmin for Effective MySQL Management" in April 2004 and subsequently continued to specialize in publishing highly focused books on specific technologies and solutions. Our books and publications share the experiences of your fellow IT professionals in adapting and customizing today's systems, applications, and frameworks. Our solution based books give you the knowledge and power to customize the software and technologies you're using to get the job done. Packt books are more specific and less general than the IT books you have seen in the past. Our unique business model allows us to bring you more focused information, giving you more of what you need to know, and less of what you don't. Packt is a modern, yet unique publishing company, which focuses on producing quality, cuttingedge books for communities of developers, administrators, and newbies alike. For more information, please visit our website: www.packtpub.com.

About Packt Open Source

In 2010, Packt launched two new brands, Packt Open Source and Packt Enterprise, in order to continue its focus on specialization. This book is part of the Packt Open Source brand, home to books published on software built around Open Source licenses, and offering information to anybody from advanced developers to budding web designers. The Open Source brand also runs Packt's Open Source Royalty Scheme, by which Packt gives a royalty to each Open Source project about whose software a book is sold.

Writing for Packt

We welcome all inquiries from people who are interested in authoring. Book proposals should be sent to [email protected] If your book idea is still at an early stage and you would like to discuss it first before writing a formal book proposal, contact us; one of our commissioning editors will get in touch with you. We're not just looking for published authors; if you have strong technical skills but no writing experience, our experienced editors can help you develop a writing career, or simply get some additional reward for your expertise.

Mobile Security: How to Secure, Privatize, and Recover Your Devices ISBN: 978-1-84969-360-8

Paperback: 242 pages

Keep your data secure on the go 1. Learn how mobile devices are monitored and the impact of cloud computing 2. Understand the attacks hackers use and how to prevent them 3. Keep yourself and your loved ones safe online

VMware vCloud Security ISBN: 978-1-78217-096-9

Paperback: 106 pages

Make your datacenter secure and compliant at every level with VMware vCloud Networking and Security 1. Take away an in-depth knowledge of how to secure a private cloud running on vCloud Director 2. Enable the reader with the knowledge, skills, and abilities to achieve competence at building and running a secured private cloud 3. Focuses on giving you broader view of the security and compliance while still being manageable and flexible to scale

Please check www.PacktPub.com for information on our titles

Spring Security 3.x Cookbook ISBN: 978-1-78216-752-5

Paperback: 300 pages

Over 60 recipes to help you successfully safeguard your web applications with Spring Security 1. Learn about all the mandatory security measures for modern day applications using Spring Security 2. Investigate different approaches to application level authentication and authorization 3. Master how to mount security on applications used by developers and organizations

Android Application Security Essentials ISBN: 978-1-84951-560-3

Paperback: 218 pages

Write secure Android applications using the most up-to-date techniques and concepts 1. Understand Android security from kernel to the application layer 2. Protect components using permissions 3. Safeguard user and corporate data from prying eyes 3. Understand the security implications of mobile payments, NFC, and more

Please check www.PacktPub.com for information on our titles