serializethoughts

Recovering dProtect’s Obfuscated Strings Using Katalina in an Android App

2024-07-03T10:32:22+00:00

TL;DR: In an Android app, strings obfuscated using dProtect can be recovered by Dalvik code emulation using Katalina.

Time To Read: 5 min

Katalina

Katalina is a Dalvik bytecode emulation tool. Katalina implements a sandbox in Python and executes one dalvik instructions at a time for emulation. As highlighted by the author, such approach is useful in dealing with obfuscated code, especially in recovering obfuscated strings.

String obfuscation is a highly effective technique used by both, malwares and genuine applications to slow down reverse engineering attempts. For instance, lack of visible strings can deter many automated static analysis tools and slows down manual attempts, forcing the attacker to perform dynamic analysis. The app authors can further implement various anti-dynamic analysis techniques to prolong the time to reverse engineer the app.

To put Katalina to test, I created an obfuscated application using dProtect. dProtect is an open source obfuscation tool for Android. It is an extension of Proguard and offers code obfuscation for Java and Kotlin, along with symbol obfuscation feature from Proguard.

dProtect String Obfuscation

DetectMagiskHide is used. Following dProtect configuration is used to enable string obfuscation, along with other techniques:

-keep,allowobfuscation class com.** { *; }

-obfuscations *
-obfuscate-strings      class com.darvin.security.** { *; }
-obfuscate-arithmetic   class com.darvin.security.** { *; }
-obfuscate-constants    class com.darvin.security.** { *; }
-obfuscate-control-flow class com.darvin.security.** { *; }

-repackageclasses
-allowaccessmodification
-flattenpackagehierarchy
-useuniqueclassmembernames

Post obfuscation, the code is transformed to following:

public class AppZygotePreload implements ZygotePreload {
    private static int a;
    private static long[] b;
 
    static {
        b = r0;
        long[] jArr = {1959339100, 1532247175, 496329810, 84648423, 1290985939, 139648832, 1345075629};
        a = ((int) jArr[6]) ^ 618995181;
    }
 
    public static String a(String str) {
        long[] jArr;
        StringBuilder sb = new StringBuilder();
        int i = ((int) b[1]) ^ 1532247175;
        while (i < str.length()) {
            char charAt = str.charAt(i);
            long[] jArr2 = b;
            int i2 = (((int) jArr2[2]) ^ 496366473) + charAt + (((int) jArr2[3]) ^ 84648422);
            int i3 = ~charAt;
            sb.append((char) ((i % (((int) jArr2[4]) ^ 1290935852)) ^ ((i2 + ((~(((int) jArr2[2]) ^ 496366473)) | i3)) - (((((int) jArr2[2]) ^ 496366473) + charAt) - (((charAt + (((int) jArr2[2]) ^ 496366473)) + (((int) jArr2[3]) ^ 84648422)) + ((~(((int) jArr2[2]) ^ 496366473)) | i3))))));
            do {
                jArr = b;
                int i4 = (((int) jArr[3]) ^ 84648422) + i + (((int) jArr[3]) ^ 84648422);
                int i5 = ~i;
                i = i + (((int) jArr[3]) ^ 84648422) + (((int) jArr[3]) ^ 84648422) + ((~(((int) jArr[3]) ^ 84648422)) | i5) + (((((int) jArr[3]) ^ 84648422) + i) - (i4 + ((~(((int) jArr[3]) ^ 84648422)) | i5)));
            } while ((a + (((int) jArr[3]) ^ 84648422)) % (((int) jArr[5]) ^ 139648834) == 0);
        }
        return sb.toString();
    }
 
    @Override // android.app.ZygotePreload
    public void doPreload(ApplicationInfo applicationInfo) {
        if (applicationInfo == null || Build.VERSION.SDK_INT < (((int) b[0]) ^ 1959339073)) {
            return;
        }
        System.loadLibrary(a("鞵鞻鞭鞱鞩鞻韰鞰鞺鞰"));
    }
}

Call to System.loadLibrary() expects a string input and dProtect has obfuscated the original string passed to this function. The original string is recovered during the runtime by calling a("鞵鞻鞭鞱鞩鞻韰鞰鞺鞰").

If we closely analyze the function a, the code is self-contained in the class, which means all the dependencies and logic required to execute this function is present in the same class. There is no dependency on any other class. Such scenarious are perfect to handle using emulation.

On using Katalina, the original string native-lib can be easily recovered:

python3 Katalina/main.py -v classes.dex -x 'Lcom/darvin/security/AppZygotePreload;->a(Ljava/lang/String;)Ljava/lang/String;' '鞵鞻鞭鞱鞩鞻韰鞰鞺鞰'     
 
// --- output ----
...
INFO     String created: Lcom/darvin/security/AppZygotePreload;.a(LL) -> native-lib
INFO     String created: native-lib
...

Patching Katalina

The existing implementation of Katalina does not handle all array use-cases properly (and mentioned in the Readme). dProtect’s code is using aget-wide and aput-wide instructions, and to handle them it required patching Katalina. The patched code is available here.

Poking around with FRIDA’s Java enumerateClassLoaders

2021-05-07T08:17:22+00:00

TL;DR: In Android, if classes are loaded by using non-default classloader, FRIDA will not be able to hook it. By using enumerateClassLoaders() API one can get the other classloaders used by the program and use them to hook Java classes.

Time To Read: 5 min

Java Classloaders

In Java, a Classloader is a part of Java Runtime Environment that dynamically loads Java classes into the Java Virtual Machine. By doing so, the Java run time does not need to know about files and file systems as this is delegated to the classloader. This concept is very much applicable with Dalvik bytecode for Android as well.

Often malwares and obfuscation tools change the default behaviour of class loading in Android. By default all the classes to be loaded are present in the classes.dex file and are loaded using the default dalvik.system.PathClassLoader classloader. But Android offers other classloaders too, like dalvik.system.InMemoryDexClassLoader, using which one can load a dex (containing Java classes) file from the memory.

FRIDA

FRIDA will throw error while trying to hook a class not loaded using the default classloader. To this problem, FIRDA provides a easy solution via Java.enumerateClassLoaders() API. You can iterate over the classloaders and use them by using Java.ClassFactory.get(loader) API. Once the new loader is set, the .use() API can be used to get the desired class and hook it.

Java.enumerateClassLoaders({
        onMatch: function(loader){
            Java.classFactory.loader = loader;
            var TestClass;

            // Hook the class if found, else try next classloader.
            try{
                TestClass = Java.use("com.example.TestClass");
                TestClass.testMethod.implementation = function(){
                    console.log("[+] Inside test method");
                }
            }catch(error){
                if(error.message.includes("ClassNotFoundException")){
                    console.log("\n You are trying to load encrypted class, trying next loader");
                }
            }
        },
        onComplete: function(){

        }
    });

Solving iOS UnCrackable 1 Crackme Without Using an iOS Device

2019-10-28T08:17:22+00:00

TL;DR: iOS UnCrackable Level 1 crackme application can be solved without using an iOS device using Angr’s dynamic execution engine.

Time To Read: 5 min

OWASP MSTG UnCrackable Level 1 Crackme App is an iOS crackme application. The goal of the crackme is to find a secret string hidden somewhere inside the application. There are multiple ways to solve the crackme using Frida, or a debugger, or even by manually reversing the native code. In this post I will solve the challenge using Angr’s dynamic execution engine. With the current approach, by using static analysis assisted with dynamic execution, the crackme can be solved without needing an iOS device.

To perform static analysis, multiple tools are available - Ghidra, R2 or IDA Pro. The application code is not obfuscated and can be easily followed in any of these tools. I am using Ghidra in this post.

The application gives a message “Verification Failed” when a wrong input is provided to it.

On searching the binary for this string, it is found in buttonClick function. The message is displayed after a comparison operation using isEqualToString. The comparison is being performed between the input string and the value of a label marked as hidden.

To find the secret string, we need to find the value of this label. Further, on analysing the function viewDidLoad, the value of the label is being set using the return value of the function at offset 0x1000080d4.

Shifting our attention to function at 0x1000080d4, there are multiple sub-function calls, and return values from each of these sub-functions is stored at an index of an array at address 0x10000dbf0. This array is the hidden string we are looking for! Each of the above sub-functions are not too complicated, but nevertheless require some manual effort to reverse them and obtain the eventual hidden string.

The function at 0x1000080d4 or any of its sub-functions are self contained, i.e, there are no library calls or system calls; we can easily run this code in any emulator like Unicorn or its likes. Angr is a reverse engineering framework with multiple features and one of them being to dynamically execute code. For using dynamic execution feature of Angr, we need to identify and pass the points in the program from where we want to emulate the code and the addresses where the eventual secret string generated. In this case, the function at 0x1000080d4 is the function we want to emulate and the return value is the information we are interested in. The return value is a pointer to the hidden string.

The eventual Angr script looks as following:

import angr
import claripy

def solve():

    # Load the binary by creating angr project.
    project = angr.Project('uncrackable.arm64')

    # Pass the address of the function to the callable
    func = project.factory.callable(0x1000080d4)

    # Get the return value of the function
    ptr_secret_string = claripy.backends.concrete.convert(func()).value
    print("Address of the pointer to the secret string: " + hex(ptr_secret_string))

    # Extract the value from the pointer to the secret string
    secret_string = func.result_state.mem[ptr_secret_string].string.concrete
    print(f"Secret String: {secret_string}")

solve()

Angr Project is the basic building block, and must needed to access any functionality of Angr. Using callable API we inform the Angr engine to execute the code from the offset 0x1000080d4, and the return value post concrete execution (dynamic execution is also called concrete execution) is captured in ptr_secret_string. The value stored in the pointer is accessed using result_state.

This solution is also contributed to the OWASP MSTG and with some more details on reverse engineering part.

RageAgainstTheCage - Revisting Android adb setuid Exhaustion Attack

2019-10-28T08:17:22+00:00

TL;DR: adb setuid exhaustion attack (aka RageAgainstTheCage) was present in Android 1.6 to 2.2. During adb initialisation, while dropping its privileges there is no check for setuid syscall’s return value. This can be exploited by causing a race condition by creating RLIMIT_NPROC processes and killing adb, on adb restart setuid syscall might fail and can lead to adb continue running with root privileges.

Time To Read: 5 min

In 2010 Sebastian Krahmer discovered a vulnerability in the implementation of adb for Android 1.6 to 2.2 versions. The vulnerability is - adb fails to check setuid return code and this can be caused to fail by a shell user already having RLIMIT_NPROC processes. The vulnerability in itself is very simple, unlike many other vulnerabilities which require various memory gymnastics to exploit. Apart from the simplicity, the vulnerability gives us a good insight into some of the Linux kernel working and also a good lesson for the developers.

RLIMIT_NPROC

To understand the working of this exploit, we need to understand how resource allocation works in Linux. Linux uses getrlimit() and setrlimit() system calls to get and set resource limits for a process. Some of the process resources are: virtual memory size, CPU time a process can consume etc, a list is available at getrlimit man page. In this case we are interested in RLIMIT_NPROC resource. This resources was introduced to protect against a fork bomb. As per the man page:

This is a limit on the number of extant process (or, more precisely on Linux, threads) for the real user ID of the calling process. So long as the current number of processes belonging to this process’s real user ID is greater than or equal to this limit, fork(2) fails with the error EAGAIN.

Vulnerability

When Android Debug Bridge (adb) is started, there are multiple tasks need to be performed before adb is available to the user. To accomplish these tasks, adb is launched with root privileges and once all the initialisation is complete, it drops its privileges. Linux system call setuid is used to lower the privileges. The main cause of the vulnerability is, in Android 1.6 to 2.2, adb does not check the return value of this setuid syscall while lowering its privileges.

// setuid call in adb 

setgid(AID_SHELL);
setuid(AID_SHELL);

When setuid is called, the kernel checks if the number of processes for that non-root user set by administrator is not crossed (i.e RLIMIT_NPROC). If this non-root user already has RLIMIT_NPROC processes running, then setuid call will fail.

If we can somehow reach this RLIMIT_NPROC processes and then make adb restart, the kernel will prevent the adb to lower its privileges. Since, adb does not check the setuid return value, it will continue to execute with root privileges. To accomplish this, we can launch multiple dummy processes and reach RLIMIT_NPROC process limit for the user. Then kill adb, which will cause adbd to restart adb. While relaunching adb, it causes a race condition between adb and the processes we launched to spawn the last RLIMIT_NPROC process. If our dummy process is launched, setuid for adb will fail, and in this case it will continue running with root privileges.

Multiple dummy processes can be launched using the following code:

if (fork() == 0) {
    fork();
    for (;;)
        sleep(0x743C);
}

Fix

One obvious fix for this vulnerability is to check the return value of setuid. But it seems non-checking of setuid return value is a common mistake with grave consequences. In the past, sendmail capabilities bug was caused by the same programming malpractice. The common occurrence of this programming pattern has lead to discussion within Linux Kernel community to fix it in the Kernel itself, discussed in this excellent LWN article.

References

https://thesnkchrmr.wordpress.com/2011/03/24/rageagainstthecage/
https://lwn.net/Articles/451985/

Differentiate an ELF executable from a shared library

2019-06-29T08:17:22+00:00

Time To Read: 5 min

TL;DR: A position independent ELF executable is compiled as a shared library to achieve position independent code. The OS is able to differentiate between the two by checking for PT_INTERP segment, which is present in executable and not in a shared library.

All modern operating systems support Address Space Layout Randomization, ASLR, as part of defense in depth approach, to make it harder for an attacker to reliably jump to a memory location while exploiting a vulnerability, like bufferoverflows. To effectively use ASLR, the code should be compiled as position independent, i.e code can be loaded at any address in the memory. Shared libraries are always compiled as position independent, while in the past (before ASLR) an ELF executable was always loaded at a fixed address.

For an executable to utilize ASLR, OS should be able to load executable at any address in the memory. Such executable is often referred as PIE (position independent executable). To make an executable PIE, the solution lies in reusing the existing implementation of how a shared library is compiled. In a nutshell, it turns out to be quite simple to create a PIE: a PIE is simply an executable shared library. This can be verified by checking the ELF filetype using readelf command. Both shared library and PIE are: DYN (Shared object file).

Since both files have same ELF filetype, it raises the question how to determine if a given ELF binary is a shared library or an executable. The answer unsurprisingly lies in the fact how the OS differentiates between the two. As it is evident from above, ELF filetype cannot be used anymore to differentiate between the two, the OS need to look for some other hints.

A quick read through on how an ELF file is loaded by the kernel and executed gives us the hint. If you are interested in learning the gory details, the article is highly recommended, while for the others, the hint is in “The code now loops over the program header entries, checking for an interpreter (PT_INTERP) …”. As it turns out PT_INTERP is an ELF segment which contains the path name of the interpreter used to execute a file. And this PT_INTERP segment is the answer to our problem. An ELF executable file has this segment while a shared library will not. This can be verified using readelf as shown in the screenshots below.

To sumamrize, an ELF executable is made to be position independent by compiling it like a shared library, and to make this shared library executable you just need to give it a PT_INTERP segment and appropriate startup code.

Some other information I discovered and might be interesting for further experimentation is, an ELF executable and shared library are so closely similar that with some hacking you can make an executable work as a shared library. This is discussed by Romain Thomas on how to achieve this using LIEF. Also, Ian Lance in Piece of PIE discusses about how similar ELF position independent executable and shared library are.

Bypassing Android FLAG_SECURE using FRIDA

2018-10-07T08:17:22+00:00

Since Android 5 via MediaProjection API, Android allows screen capturing and screen sharing using third party applications. I won’t be going in detail of how this API work and what are its various security implications. This article by Nightwatch Cybersecurity summarizes it very succinctly.

The important point to keep in mind is, to protect sensitive applications from screen capturing and sharing is to set FLAG_SECURE flag for that respective screen.

Recently I came across an Android application using this very FLAG_SECURE flag to prevent from screen capturing or sharing. I wrote a simple FRIDA script to bypass this check and it is very straightforward. The script I used is below:

There is an XPosed module as well which performs exactly same thing.

Frida, Magisk and SELinux

2018-07-23T08:17:22+00:00

While using Frida 12.x with Magisk v16.3+, I came across the problem that Frida is not able to spawn applications on Android. In logcat one can see the SELinux error:

avc: denied { sigchld } for scontext=u:r:zygote:s0 tcontext=u:r:magisk:s0 tclass=process permissive=0

I am not sure from the problem has started, is it Magisk, which does perform some tinkering with SELinux or is it new version of Frida. I have not open a bug with either projects yet, as I am not sure.

But for those stuck with this problem, the solution is to use magiskpolicy, which is installed along with magisk. Just go to the terminal and add this policy:

magiskpolicy --live "allow zygote magisk process *"
magiskpolicy --live "allow system_server magisk process *"
magiskpolicy --live "allow radio magisk process *"

In case someone knows the root cause I would be more than happy to know.

UPDATE:

It seems others also have come across problems related to SELinux and FRIDA, like https://github.com/frida/frida-core/issues/123. The recommended solution is to set SELinux to Permissive mode. In case you don’t want to do that, as some applications do check for SELinux status and do not work if set to Permissive mode, then use the commands above, as a workaround.

Bypassing anti-debugger check in iOS Applications

2018-01-23T08:17:22+00:00

Expected Reading Time: 5 Mins

While pentesting mobile applications, very often you will come across applications implementing myriads of anti-reversing techniques. Specially while performing dynamic analysis, it is imperative to disable these checks. To make the bypassing these checks more daunting, some applications heavily obfuscate the binaries. In this post, we will look into bypassing one of the anti-debugging technique for iOS applications and using IDAPython script to automate patching of the binary. The idea presented in this post is really simple, and many readers might have been already using it, for others here is another idea to add to your armory.

Ptrace

iOS under the hood runs a XNU kernel. The XNU kernel do implement ptrace() system call, but it is not potent enough when compared to Unix and Linux implementations. On the other hand, XNU kernel exposes another interface via Mach IPC to perform debugging. In this post we won’t be comparing between the two mechanisms, in fact we will only talk about one feature of ptrace syscall, PT_DENY_ATTACH. It is a fairly well known among the iOS application hackers, and among the most frequently encountered anti-debugging technique in iOS applications.

Before getting into the details of bypassing the check, lets first try to understand briefly what exactly does PT_DENY_ATTACH do. Although, there is ample literature available on the Internet discussing PT_DENY_ATTACH in various depths, but The Mac Hacker’s Handbook defines it most succinctly.

PT_DENY_ATTACH This request is the other operation used by the traced process; it allows a process that is not currently being traced to deny future traces by its parent. All other arguments are ignored. If the process is currently being traced, it will exit with the exit status of ENOTSUP; otherwise, it sets a flag that denies future traces. An attempt by the parent to trace a process which has set this flag will result in the segmentation violation in the parent.

To rephrase it, using ptrace with PT_DENY_ATTACH, it ensures that no other debugger can attach to the calling process; even if an attempt is made to attach a debugger, the process exits.

It is important to know that ptrace() is not part of public API on iOS. As per the AppStore publishing policy. Because of this, developers don’t call ptrace() directly in the code, instead its called via obtaining ptrace() function pointer using dlsym. Programmatically it looks like:

#import %3Csys/types.h>
#import typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
void anti_debug() {
ptrace_ptr_t ptrace_ptr = (ptrace_ptr_t)dlsym(RTLD_SELF, "ptrace"); ptrace_ptr(31, 0, 0, 0); // PTRACE_DENY_ATTACH = 31
}

The dis-assembly of the binary implementing this approach looks like following:

To break down whats happening in the binary, at 0x19086 dlsym() is called with “ptrace” as the 2nd argument (register R1, offset 0x19084) to the function. The return value, in register R0 is moved to register R6 at offset 0x1908A. Eventually at offset 0x19098, the pointer value in register R6 is called using BLX R6 instruction. In this case, to disable ptrace() call, all we need to do is to replace the instruction BLX R6 (0xB0 0x47 in Little Endian) with NOP (0x00 0xBF in Little Endian) instruction. Armconverter.com is a handy tool for conversion between bytecode and instruction mnemonics. The code after patching looks like following:

This can be done manually easily if there is only one or a few calls to ptrace, but this turns tedious once such calls are made multiple times across the binary.

IDAPython Script

IDAPython script can be leveraged to perform this task automatically. I wrote one such script to automate the task for the binary dis-assembly shown above.

The script is quite self explanatory, but if something is not clear, feel free to drop a comment below for further clarification.

To conclude, there are many other anti-debugging approaches available for iOS, the one discussed here is the most commonly found in the iOS applications. Using such techniques to slow down the attackers is fine, but solely depending on such techniques for the security of an application is not at all advisable. Such techniques can be part of the defense in depth approach, but should not be the only defense.

Keep hacking :)

Working of LD_PRELOAD for Android Applications and its anti-RE Technique

2017-04-01T08:17:22+00:00

Have you ever checked the parent process of an Android application launched using “wrap” system property set with LD_PRELOAD value? It’s not Zygote!!!

Expected Reading Time: 10 mins

There are multiple tools and methodology available for reverse engineering an Android application. In this post, I am not exploring various RE techniques available, instead look into how one such technique works in case of Android applications. LD_PRELOAD is a functionality of dynamic linker present across all Linux distributions, giving precedence to library passed to be searched first for symbols. It is not a RE technique per se, but I have used it often for such purposes and hence I classify it as a RE technique which one should know.

Many Linux users will be aware of how LD_PRELOAD works in case of native binaries. For the starters, there are many good blogs available and I will leave it as an assignment. As a side note, knowledge of how dynamic linkers work is always handy for reverse engineering assignments.

In case of a simple native binary compiled to run on Android, LD_PRELOAD works as for other Linux systems. Things get interesting once you intend to use LD_PRELOAD for an Android application. If you simply set the LD_PRELOAD env variable and then try to launch the application, it will not work. Rather you need to perform some Android trickery to make it work for an application. For example, we want to load libpreload.so using LD_PRELOAD for application with package name com.foo.bar. We need to perform following steps:

Push the library to the device. adb push libpreload.so /data/local/tmp/libpreload.so
Set system property: setprop wrap.com.foo.bar LD_PRELOAD=/data/local/tmp/libpreload.so

Note, in last step the property name is “wrap” prefixed to the application’s package name.

Now if you launch the application, the library libpreload.so will be searched first by the dynamic linker for symbols. (In recent Android versions, one need to disable SELinux to make this work, as libpreload.so does not have SELinux context assigned, because of which the library is not loaded and whole process exits on such an error.) The above work around is neither a hidden feature nor a newly added feature. Many of us might have used it several times in the past.

After knowing how to make it work practically, lets try to understand what is actually happening internally, and why we need to perform these extra steps. Some might have already guessed, it is because of Zygote process creation model used in Android. As covered previously on this blog as well, an Android application is launched by forking a Zygote process. Argument being, in order to save time while launching an application, Android coldstarts a process during OS startup, from which applications can be forked when required. This process is initialized with all necessary libraries required to run an Android application, and remains in sleep state. When a request to launch an application is received, this Zygote process is simply forked and used there on.

Since, Zygote process is initialized well before launching the application, setting LD_PRELOAD env variable before launching an application will cause no change in symbol search order for linker. Thus, to enable LD_PRELOAD functionality, Android needs a work around.

Lets revisit how an application launch request is passed to Zygote. When user makes a request to launch an application, a request is sent to /dev/socket/zygote. On receiving request, Zygote forks itself and launches the application in the child process. As per this mechanism all the application’s, as expected, will have Zygote as the parent process. But in case of LD_PRELOAD scenario, a slight different code path is taken.

Code listening at /dev/socket/zygote runs in a loop, referred as ‘select loop’ in code. On receiving request, runOnce() in ZygoteConnection is called. In this function, many checks and operations are performed, one such check is to check if “wrap” system property set for the given application’s package name.

boolean runOnce() throws ZygoteInit.MethodAndArgsCaller {
...
applyUidSecurityPolicy(parsedArgs, peer, peerSecurityContext);
applyRlimitSecurityPolicy(parsedArgs, peer, peerSecurityContext);
applyInvokeWithSecurityPolicy(parsedArgs, peer, peerSecurityContext);
applyseInfoSecurityPolicy(parsedArgs, peer, peerSecurityContext);
checkTime(startTime, "zygoteConnection.runOnce: apply security policies");
applyDebuggerSystemProperty(parsedArgs);
applyInvokeWithSystemProperty(parsedArgs);
checkTime(startTime, "zygoteConnection.runOnce: apply security policies");
...
}

If it is set, it extracts the value of the property. It is important that, a system property name cannot be more than 31 chars, and if package name is more than 31 chars, it need to be truncated to 31 chars.

After extracting the value, execApplication() in WrapperInit is called. In this function, a command string is constructed with required parameters, to launch application via /system/bin/app_process (Zygote) directly. The shell arguments, LD_PRELOAD in this case, is appended in this command string. This command is executed using /system/bin/sh. Thus, making /system/bin/sh as the parent process to the finally launched application.

public static void execApplication(String invokeWith, String niceName,
int targetSdkVersion, FileDescriptor pipeFd, String[] args) {

StringBuilder command = new StringBuilder(invokeWith);
command.append(" /system/bin/app_process /system/bin --application");
if (niceName != null) {
command.append(" '--nice-name=").append(niceName).append("'");
}
command.append(" com.android.internal.os.WrapperInit ");
command.append(pipeFd != null ? pipeFd.getInt$() : 0);
command.append(' ');
command.append(targetSdkVersion);
Zygote.appendQuotedShellArgs(command, args);
Zygote.execShell(command.toString());
}

This very fact, that parent process for such an application is not Zygote, can be used as an anti-RE technique. If application’s parent is not Zygote, then application can change its behavior or exit, preventing application analysis.

Keep hacking :)

Intercepting HTTPS Traffic of Android Nougat Applications

2016-09-10T08:17:22+00:00

TL;DR To intercept network traffic for Android 7.0 targeted applications, introduce a res/xml/network_security_config.xml file.

Expected Reading Time: 5 mins

In this post I am exploring the new security feature of Android 7.0, which by default makes applications to not to trust “user” installed CA certificates (non-admin), and how to bypass this new security feature. I started with the feeling that it might not be easy to find a way past these checks, but it panned out to be quite straightforward and much less technical than expected.

Android 7.0 (Nougat) has introduced many new security features to harden the OS. The changes ranges from low level stuff like using more of Linux Seccomp, having File based encryption, to making mediaserver more secure by compartmentalization and compiler level checks for integer overflows. Among all these changes, Android 7.0 also changed the default trust level of installed CA certificates for the applications.

In Android Nougat, the default trusted CA certificates by the applications has changed. In the earlier versions of Android, by default the application apart from trusting the “system” installed CA certificates, it also used to trust the “user” added CA certificates as well. For example, while using some MITM proxy like mitmproxy, burp etc, you can simply install the proxy’s certificate on Android device/emulator and then you can intercept and observe the network traffic in clear text. But from Android 7.0 onwards, the default behaviour has been altered and the “user” installed certificates won’t be trusted anymore by the applications. Thus, intercepting application’s traffic using a proxy will not be possible out of the box.

So how to observe the network traffic for the applications targeting Android 7.0? Apparently, Google has not provided any simple switch in settings menu, which can be toggled and apps start trusting user installed CA certs. So it means we need to get our hands dirty.

So with a task in hand, I picked up an open source Android application and compiled with target SDK Level 24 (for Android 7.0). I prepared a release build and installed on a device running Android 7.0. I used mitmproxy for the job to intercept network traffic. And to no surprises, the application was not able to connect and reported no internet connectivity.

As the adage goes, RTFD, lo and behold, the hint is there in the same blog post. For ease of setting network security configuration, Android provides a network security configuration file, while lets you to “customize network security settings in a safe, declarative configuration file without modifying app code”. So that is all needed. We need to decompile the application using apktool and introduce a network_security_config.xml (shown below) file at res/xml folder of the application. Recompile the application with apktool again, sign it using jarsigner and we are good to go.

<network-security-config>  
      <base-config>  
            <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
 </network-security-config>

Once this file is created, also update the AndroidManifest.xml file to reflect the above changes.

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
                    ... >
        ...
    </application>
</manifest>

For the better understanding, I highly recommend to read the original blog and the security config documentation.

In the end it turned out to be quite trivial than expected, but nevertheless requires few extra steps now to intercept an applications traffic. This technique might be not be needed immediately, as most applications will still be targeting at least Android 4.4 for now, for which the user added CA certificate are still trusted.

Bypassing SSL Pinning in Android Applications

2016-08-18T08:17:22+00:00

It is a common practice for Android and iOS applications’ developers to implement SSL Pinning in order to make reverse engineering of the apps difficult. As per OWASP, SSL Pinning can be defined as the process of associating a host (in this case the app), with their expected X509 certificate or public key. Applications communicating over HTTPS and using SSL Pinning makes it non-trivial to perform Man-In-The-Middle attack and grab the network traffic in clear text using the proxy tools. For further reading about SSL Pinning, I would recommend OWASP article to get started with.

In this post, I will be looking into the steps involved in bypassing SSL Pinning checks for an Android application and show how we can patch the application binaries in order to intercept the traffic. For this post I am using Facebook Messenger (FBM) application as an example.

SSL Pinning In Android

SSL Pinning in case of Android can be performed either in the Java layer, using the Android API, or in the native C/C++ layer. Lets look into each of the cases one at a time:

Java Layer

To implement SSL Pinning, Android API exposes multiple functions to do so. Android developer website provides a good overview about the topic. In order to bypass the SSL Pinning in Java layer one can use existing tools or can patch the APK file manually.

Xposed Framework: If the device is rooted, one can install Xposed Framework and use one of the multiple modules available to disable SSL Pinning. One such module is SSL Unpinning. Using the module is straight forward and I would leave the details of usage to the readers to figure out.
Manual Patching: Xposed Framework requires the device to be rooted. In such a case we cannot use the tools discussed above to bypass the SSL checks. In such a situation we can patch the APK file manually. Patching the file manually requires some extra effort, but given the abundance of exiting tools, this can be done with ease. The steps involved are following:

Decompile the application using Apktool or any other similar tool. Apktool gives Smali code for the application.
Patch the relevant functions in the Smali code.
Compile the application back using apktool, sign it using jarsign and run zipalign over it.
Installed the patched APK generated above.

The above approach is discussed in detail in this blog post. Hence, I will refrain from duplicating the information and recommend you to read it there.

Native Layer

Now enters a bit more challenging part. If the above approaches fail, you can fairly be confident that the SSL Pinning checks are being performed in the native layer. FBM is doing exactly same. To make things a bit obscure, the FBM application do have SSL Pinning logic in Java layer as well, but patching it does not work.

To get started, simply run APKTool and get the decompiled/unzipped version of the APK. If you look in the lib folder, there are 6 native libraries.

After exploring these libraries using IDA Pro, to my surprise, none was having network related code. Which entailed more research is required to find the relevant code. If you look into these existing native libraries, you will find there is logic for xz decoding and logic for loading more native libraries. Also, if you go on and install the application and after the first usage, you will find that the /data/data/com.facebook.orca directory have a folder lib-xzs, which contains another 30+ libraries.

So now the work is cut out clearly, we have to look into these libraries to find the network code. After evaluating each library using IDAPro, the code for SSL Pinning was found in libliger-native.so. There are many functions corresponding to SSL Pinning and network in this library. On seeing the various functions, proxygen::SSLVerification::verifyWithMetrics() seems to be an easy target to fix. The function performs a comparison of the certificate received against the desired certificate embedded/pinned in the application and returns true or false. The pseudocode is shown below:

Dynamic Patching: Dynamic library can be patched by performing dynamic injection and patching the function during the runtime. ADBI and FRIDA are the two frameworks that provide such functionality. After some fiddling around with the above mentioned tools, in both the cases FBM was crashing whenever an injection is made. Whether it was a security defense mechanism or instability of the process post injection, I left this unexplored for the time being. A note to the readers, to use these framework you need a rooted device.
Native Library Patching: Given the dynamic injection is causing frequent crashes, patching the binary manually and reloading it again seems to be the only other option to go with. I used IDAPro to patch the binary. At the offset 0x0006732E patch code from 0xB948 (CBNZ R0, loc_6744) to 0xB9B8 (CBNZ R0, loc_6760). Where the block at loc_6760 is responsible for setting the return value, variable ‘result’, to always true. To get more understanding how the ARMv7 instructions represented at the bit level, read this answer. After patching, replace the libliger-native.so file in /data/data/com.facebook.orca/lib-xzs with the new one, restart the application and now you can intercept the traffic.

Before patching library looks like following:

After patching:

Recently, there was another blog post discussing patching of Android application (Pokemon Go app) to bypass SSL Pinning and I would recommend to read that one as well. The approach taken in that post is slightly different, as each application has different implementation.

Keep hacking :)

Linux Thread is a Standard Process

2016-07-16T08:17:22+00:00

As per Wikipedia, a computing thread is defined as “the smallest sequence of programmed instructions that can be managed independently by a scheduler”. And further goes on to say, the implementation of threads and processes differs between operating systems, but in most cases a thread is a component of a process. A process can have multiple threads within a shared memory address space of the process. In this article, I won’t be going into the nitty-gritty of threads. There are many good resources available on the Internet discussing various details of threads. Rather I would like to focus on an important aspect of threads specifically in Linux kernel.

While discussing Linux internals with a senior developer, he mentioned that in case of Linux kernel, there is no difference between a process and a thread. Intrigued by the fact, I started looking into kernel’s source, aided by the excellent book on Linux kernel, Linux Kernel Development, by Robert Love.

Coming on to the topic, in Linux, there is no separate data structure defining a thread. A thread and a process have the same data structure. Also, a thread is created exactly in the same way as a normal process is created, i.e by calling fork or vfork() (which eventually calls clone() system call). Although, in case of a thread, while making clone() system call some extra flags are passed. These extra flags specify the resources which are to be shared. A typical call looks like:

clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0);

So the address space, filesystem resources, file descriptors, and signal handlers are shared.

For the readers who want to delve more into the internal working, struct task_struct contains information about a process, defined in <linux/sched.h>. The field unsigned int flags stores all the flag related information. These flags, help specify the behaviour of the new process and detail what resources the parent and child will share. List of other clone flags can also be found in linux/sched.h.

For completeness, in case of Microsoft Windows, kernel have explicit support for kernels and also referred as lighweight process. For Windows, a thread is an abstraction which provides a lighter, quicker execution than the heavy process. The pros and cons of the two approaches requires more deep understanding of the two, and will be a much bigger post than this one.

Security Implications of Zygote Process Creation Model in Android

2016-05-25T08:17:22+00:00

In the previous post I discussed about the Zygote process creation model in Android OS and importance of having different process creation model than a linux process in a mobile device. Before getting into the technical specifics, it is advisable to freshen the concept pertaining to Linux process creation and ASLR.

In Zygote process creation model, a process template is created on the system startup, having the Dalvik VM (DVM) instance initialized and also other essential libraries loaded. When an application launch request is received, this template process is forked and application is loaded into it, saving significant time by avoiding loading of libraries and in instantiating DVM on every launch. Also, Linux COW (copy-on-write) helps in reducing global memory usage. But this trade-off have a major security implication.

Zygote process creation model causes two types of memory layout sharing on Android, which undermine the effectiveness of ASLR. Firstly, the code of an application is always loaded at the exact same memory location across different runs even when ASLR is present; and secondly, all running apps inherit the commonly used libraries from the Zygote process (including the libc library) and thus share the same virtual memory mappings of these libraries. If an attacker is able to get the memory mapping information for one process, he can easily predict for the target process (as both share same mappings for Zygote loaded libraries). Thus developing ROP attacks becomes very easy, in spite of having ASLR. For more details, read this excellent article by Copperhead team.

After understanding the pros and cons of the approach, it must raise the curiosity that how can it be fixed without breaking the existing applications. To start with, one approach is to switch to Linux style process creation model, i.e, fork and exec, rather than creating a template and keep forking it subsequently. This approach fixes the security issue, but raises the very issue for which Zygote model was created. We will revisit this approach again at the end and re-evaluate its applicability in light of new performance enhancements measures introduced in Android.

Another approach to fix the security issue with Zygote process creation model was proposed by Lee et. al. in this paper. They name their approach as Morula process creation model. Why it is called Morula is left as an exercise for the readers.

Morula Process Creation Model:

In this approach, a template process performs the common and time-consuming initialisation tasks beforehand. The whole process is divided into 2 steps:

Preparation Phase: initiated by the Activity Manager. A preparation request is made to the Zygote process, when the system is idle or lightly occupied. The Zygote process forks a child, which immediately call a exec() to establish a new memory image with a fresh randomized layout. Then, the new process constructs DVM instance and loads all shared libraries and common Android classes, which would tremendously prolong the app launch time if not done in advance. Now the Morula process is fully created, waiting for the request to start an app. Multiple Morula process can be created in order to accommodate a flurry of requests to start several apps. If these newly created process is not used immediately, the process enters the sleep mode and awakened only when needed.
Transition Phase: When the Activity Manager requests an app launch, the request is routed through Zygote process first, where a decision is made regarding if the app should be started in a Morula process or in a fork of the Zygote process. Having this option allows the Morula model to be backward compatible with the Zygote model, in order to carry out an optimization strategy. Depending on the configuration, using either of the process the application is launched.

From Android 4.4.4 onward, Google was previewing a new runtime environment instead of Dalvik, called ART. From Android 5.0 it was fully deployed and considered to be faster than previous Dalvik VM. Factoring in the advances made by ART, Copperhead experimented with fork and exec approach in their Copperhead OS. As per their findings, “The Morula proof of concept code has some issues like file descriptor leaks and needs to be ported to Lollipop. It’s much less important now that ART has drastically improved start-up time without the zygote.” To conclude, with ART, fork and exec approach is not as slow as compared with Dalvik runtime. For security paranoid users, a small performance glitch should not be a big barrier.

It is highly recommended to read both, the Morula paper and blog by Copperhead to understand the nitty-gritty of the topic. And for the hackers out their, patch for implementing Morula is available here.

Android Zygote

2016-04-15T08:17:22+00:00

In this post I will discuss about a very interesting piece of Android Operating System. If you have worked with Android, you might have run the ps command and might have observed that all applications have same parent PID (PPID). Android takes an unconventional approach to spawn processes, which ensure application startup is snappy. The process from which all the Android applications are derived is called Zygote. So in the screenshot below, all the applications have PPID of 1914, which is the PID of Zygote. In the rest of the post, I will talk about what is the need of Zygote, how does it come into existence and some discussion about Zygote in general.

Need of Zygote?

In a typical Linux process, when a process is started - by forking parent process, it goes through various setup steps, including loading of libraries and resources. The details are out of scope for this post. This process setup consumes time and on our beefy desktops, it is hardly noticeable. But in case of Android, not all devices are high spec and this process setup is noticeable to end user. As a workaround to normalize the process startup times on various devices, Android coldstarts a process during OS startup, from which applications can be forked when required. This process is called Zygote.

Zygote Startup

After the Android device is turned on, and following all booting up steps, then init system starts, and run /init.rc file to setup various environment variables, mount points, start native daemons etc. There are many resources available on the internet discussing about Android bootup process and init system as well, and thus bypassed in this post. While executing init.rc, that Zygote is started. There is no binary directly corresponding to Zygote, instead it is started by a binarycalled app_process. Corresponding line in init.rc can be found here.

    service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server

app_process firstly starts Android Runtime, which in turn starts Dalvik VM of the system, and finally Dalvik VM invokes Zygote’s main().

Zygote initilization can be simplified into following steps:

Register Zygote socket (listens for connections on /dev/socket/zygote) for requests to start new apps
preload all java classes
preload resources
start system server (not covered in this post)
open socket
listen to connections

Zygote Socket

As mentioned above, zygote opens up a socket, /dev/socket/zygote, and listens on it for requests to start new applicationss. On receiving a request, it simply forks itself and launches the new requested application. So now the new application have Dalvik VM already loaded, including other necessary libraries and resources, and can start with execution straight away.

One feature of Linux is important to understand over here, Copy-on-Write (COW) policy for forks. Forking in Linux involves creating a new process, which is an exact copy of the parent process. With COW, Linux doesn’t actually copy anything. On the contrary, it just maps the pages of the new process over to those of the parent process and makes copies only when the new process writes to a page. Thus, saving significant amount of memory and setup time as well. To add, in case of Android, these pages are never written, as the libraries are mostly immutable and hardly changed over the process lifetime.

If you want to learn more details, with corresponding code, this is an excellent resource.

In upcoming post I will discuss about the security implications of having Zygote model and various existing alternative workarounds.

TLS Sequence Numbers

2016-02-09T08:17:22+00:00

When talking about SSL/TLS most of the discussion centers around the ciphersuites, the types of messages or other complex cryptographical aspects. But there are many subtle things embedded in the protocol, which are often skipped or not discussed generally. One such thing is sequence numbers. Like in TCP, a sequence number for messages is also maintained in SSL/TLS protocol and one gets to know only is he/she delve into the RFCs.

In case of SSL/TLS, sequence number is a simple count of messages sent and received. This is maintained implicitly i.e, not sent in the messages explicitly. The protocol requires to maintain a separate sequence number counter for read and write sessions respectively.

A touch of history, sequence numbers were not used in the SSLv1, and were introduced in SSLv2 only. Thus making SSLv1 prone to replay attacks (against which sequence numbers protect).

The question arises, if sequence number for a connection is maintained, and given that it is not explicitly transmitted, then how it is useful? To answer, sequence numbers are used in the MAC. To prevent message replay or modification attacks, the MAC is computed using the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings. When either side calculate the MAC for a given message, if sequence number does not correspond to the current message, then message authentication will fail, and the receiver will demand the sender to re-send the message.

From RFC 6101 states following about how sequence number should be calculated and also what data type should be used. Note that by using int64, chances of overflow are minimized.

Each party maintains separate sequence numbers for transmitted and received messages for each connection. When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero.  Sequence numbers are of type uint64 and may not exceed 2^64-1.

To summarize, the sequence number provides protection against attempts to delete or reorder messages.

References:

https://tools.ietf.org/html/rfc6101#page-14
https://security.stackexchange.com/questions/55667/tls-sequence-number#
SSL and TLS Theory and practice by Rolf Oppliger

iOS Solid State NAND Storage

2015-11-21T08:17:22+00:00

There is not much literature available on how does NAND storage of Apple’s iDevices is like. While reading “Hacking and Securing iOS Applications” by Jonathan Zdziarski, I came across how does the NAND storage looks like until iOS 5. As a note on caution, it is very possible that this structure has been changed in the subsequent iOS versions.

Knowing the structure of storage is an important step in order to understand how encryption works in iOS. The text below is verbatim from the book. The NAND is divided into six separate slices:

BOOT: Block zero is referred to as the BOOT block of the NAND, and contains a copy of Apple’s low level boot loader.
PLOG: Block 1 is referred to as effaceable storage, and is designed as a storage locker for encryption keys and other data that needs to be quickly wiped or updated. The PLOG is where three very important keys are stored, which you’ll learn about in this chapter: the BAGI, Dkey, and EMF! keys. This is also where a security epoch is stored, which caused iOS 4 firmware to seemingly brick devices if the owner attempted a downgrade of the firmware.
NVM: Blocks 2–7 are used to store the NVRAM parameters set for the device.
FIRM: Blocks 8–15 store the device’s firmware, including iBoot (Apple’s second stage boot loader), the device tree, and logos.
FSYS: Blocks 16–4084 (and higher, depending on the capacity of the device) are used for the filesystem itself. This is the filesystem portion of NAND, where the operating system and data are stored. The filesystem for both partitions is stored here.
RSRV: The last 15 blocks of the NAND are reserved.

If there is any recent material on this topic, please let me know by commenting below.

Keep Hacking :D

Detecting Microsoft HTTP.sys Vulnerability

2015-11-12T08:17:22+00:00

On April 14th, 2015 patch Tuesday, Microsoft released a patch for a remote code execution vulnerability in HTTP.sys module of Windows. The vulnerability affected all versions of windows, ranging from Windows 7 to Windows servers. Microsoft’s bulletin MS15-034 talked about the vulnerability only in brief and left the details to be revealed only by reverse engg the patch. It was a race against time for people to patch their servers and for attackers to reverse engineer the patch to zero-down on the exact vulnerability. The vulnerability was assigned CVE-2015-1635. In this blog we will see what is HTTP.sys is and how to detect the vulnerability. Understandably the fix was to apply Microsoft’s patch.

What is HTTP.sys?

HTTP.sys is a kernel-module which is a HTTP listener. Prior to HTTP.sys, windows used Windows Socket API (Winsock), a user-mode component, to receive HTTP requests. Having HTTP listener in kernel have following advantages [1]:

Kernel-mode caching: Requests for cached responses are served without switching to user mode.
Kernel-mode request queuing: Requests cause less overhead in context switching because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.

For more details on working and advantages of HTTP.sys, visit [2].

Vulnerability

The vulnerability exists in the parsing of the Range Header [3] of the HTTP request sent to the server. By sending Range header’s value as bytes=0-18446744073709551615, triggers a buffer overflow and this can be used as a test to detect HTTP.sys vulnerability on a server.

Following curl command can be used for testing:

$ curl -v www.example.com -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

If response is “HTTP Error 400. The request has an invalid header name.”, then the server is patched, any other response apart from this indicate the server is still vulnerable.

Sending following request will cause Blue Screen of Death (BSoD) and thus causing Denial-of-Service.

$ curl -v www.example.com/iis-85.png -H "Host: irrelevant" -H "Range: bytes=20-18446744073709551615"

As per comments on Hacker News [4], the vulnerability affects only those server on which “Output Cache” or “Enable Kernal Caching” is checked.

There is ready to use tool available on Github for testing your server for HTTP.sys vulnerability.

This attack is similar to Range-attack on Apache servers, causing Denial of service [5].

Keep Hacking :).

References:

https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a2a45c42-38bc-464c-a097-d7a202092a54.mspx?mfr=true
http://www.codeproject.com/Articles/437733/Demystify-http-sys-with-HttpSysManager
https://tools.ietf.org/html/rfc7233#section-3.1
https://news.ycombinator.com/item?id=9380889
http://seclists.org/fulldisclosure/2011/Aug/175
https://security.stackexchange.com/questions/86201/does-http-sys-vulnerability-affect-windows-not-running-any-webservers
https://isc.sans.edu/forums/diary/MS15034+HTTPsys+IIS+DoS+And+Possible+Remote+Code+Execution+PATCH+NOW/19583/
https://www.reddit.com/r/netsec/comments/32n3m2/cve20151635_rce_in_windows_httpsys/
https://stackoverflow.com/questions/22598350/how-exactly-does-http-sys-work

How Cuckoo Filters Can Improve Existing Approximate Matching Techniques

2015-11-01T08:17:22+00:00

If you have used VirusTotal, in additional information tab you will find a field for ssdeep. It is intriguing what this field represents among hashing functions SHA1, SHA256 and MD5. ssdeep is a approximate matching algorithm (AMA). NIST define approximate matching algorithms as:

"Approximate matching is a technique for identifying similarities between or among digital objects, such as files, storage media, or network streams, which do not match exactly".

In simple words, given two files, having certain degree of similarity, for example, two word files with second file being copy of first except a paragraph. Traditional hash functions can only tell about the exact similarity, but cannot provide degree or a confidence score out of 100 of how similar the files are.

AMA are used extensively in forensics investigation as they provide easy way to compare a hard disk against whitelisted or blacklisted corpus of files. Over past few years many AMA have been proposed. ssdeep was the first, followed by sdhash and mrsh-v2. In between, some other algorithms were also proposed, but they suffered with one shortcoming or other. All of the above algorithms use Bloom filters as their basic building block. In short, Bloom filter is a probabilistic data structure for performing set membership query efficiently. In this post I will not go into details of internal working of AMA nor of Bloom filter, but talk about an alternative of Bloom filter, namely Cuckoo filter. Cuckoo filter is modification of Cuckoo hashing approach to construct a data structure suitable for set membership determination. Cuckoo filter excel over Bloom filter on following parameters:

Cuckoo filter has better lookup performance
Cuckoo filter has better space efficiency than Bloom filter, when false positive rate desired is < 3%.
Unlike Bloom filter, Cuckoo filter supports deleting stored items dynamically.

In one of my recent works, I have used Cuckoo filter instead of Bloom filter in mrsh-v2 and was able to achieve significant performance gain. The final results can be summarized as:

In simple runtime performance, there is a gain of 37%.
Size of final fingerprints generated is halved.
Memory usage is 8th of approach with Bloom filter.

This work was presented at ICDF2C-2015, which took place on 6th October in Seoul, South Korea, titled How Cuckoo Filter Can Improve Existing Approximate Matching Techniques (pdf). The work was adjudged with best paper award by the committee.

In next coming posts I will try to cover what are approximate matching algorithms in detail and probably also look into each of these algorithms.

Keep hacking!!

How to Detect a Drupal Installation

2014-11-18T08:17:22+00:00

On 15th October Drupal project disclosed a severely critical vulnerability SA-CORE-2014-005 in Drupal core. Durpal is one of the most commonly used Content Management System (CMS), apart from Wordpress and Joomla. CMS helps in organizing and storing files of a website.

The vulnerability affects Drupal version 7.x, before 7.32, and some deployments of 6.x. An SQL injection vulnerability is present in Drupal’s abstraction API layer and an unauthenticated user can easily exploit it. More details about the vulnerability are available at PSA-2014-003.

Lets look into some signatures which can be used to detect a Drupal installation:

CHANGELOG.txt: A default Drupal installation will have a CHANGELOG.txt file present in the root folder of the website. The presence of this file helps in couple of ways, firstly, it affirms presence of Drupal CMS and secondly helps in extracting the version of the Drupal running on the website. One can check Drupal’s website to check how does this work.
HTTP Expire header: A default Drupal installation have value of ‘Sun, 19 Nov 1978 05:00:00 GMT’ for expires header. It is fairly a good signature as not many servers will keep exactly this value.

X-Generator HTTP Header: A default installation also sends a ‘X-Generator’ header in the HTTP response with value ‘Drupal 7 (http://drupal.org)’ .
Looking for Drupal modules: In case above mentioned methods are disabled by the server admin (which is very likely), one can scan for Drupal specific plugins. An exhaustive list is available here.

Determining Version

Above methods, apart from CHANGELOG.txt, can only give us only a yes/no. But if one need to go a bit further and wants to determine the version of Drupal running??

To solve this problem, one can use the fact that Drupal is an open source tool. Clone the Drupal code and look for the file which is most changed across various versions. One would prefer to look for javascript or css files, as these will be easy to fetch and unlikely to be changed by the website developer. In my short research I found using modules/color/color.js is a nice place to start with. Generate a SHA-1 hash of color.js across various versions of Drupal, then fetch this file from the website and hash and check against an already generated hash table to determine the version, or at least a range. You can practice this technique here.

Will update this post in case I find some more signatures. If you know one and would like to share, please leave it in the comments below.

Keep hacking !! :D

What is POODLE and How to Detect It

2014-10-19T08:17:22+00:00

SSL was again center attention recently. After series of vulnerabilities, Heartbleed and OpenSSL CCS to a count a few, another vulnerability rocked one of the most important communication protocol of the internet. POODLE - Padding Oracle On Downgraded Legacy Encryption, affects SSLv3 (RFC6101) protocol and assigned CVE-2014-3566. SSL 3.0 is an old protocol, proposed by Netscape in 1996 and now have been succeeded by new protocols, TLS 1.0, TLS 1.1 and TLS 1.2. SSL 3.0 is obsolete now and only supported because many legacy systems still use it. For example, some old embedded devices still use it and it is not very straightforward to update such devices. But after surfacing of POODLE attack, it is highly recommended to disable SSL 3.0 for any form of communication. After the demise of IE 6, all the modern browsers support TLS 1.0 and thus it is safe and logical to deprecate this old protocol.

POODLE hogged the most of the limelight, but in the OpenSSL advisory there were some more bugs reported, which should also be taken care by the administrators and the users. In total there are 4 bugs disclosed, other than poodle, rest 3 relates to implementation issues in OpenSSL. It is highly recommended to update your OpenSSL library version if you are using it.

POODLE

SSL is a very big and complex protocol. I tried to cover the basics of SSL/TLS protocol in the previous posts. Most of the complexities lies in the initial handshake phase, where various protocol parameters like protocol version, ciphersuite, compression etc are negotiated. POODLE attack is concerned with the next phase of the SSL protocol, the bulk encryption phase, where the communication end points have already established the SSL connection and ready to exchange application’s data, e.g HTTP request and responses. POODLE is the latest in a long line of similar attacks against known weaknesses in SSL’s use of Cipher block chaining (CBC) mode for block ciphers used in encryption. It is important to note that POODLE is more of a design issue than an implementation bug, unlike previous bugs like Heartbleed and OpenSSL CCS vulnerability. Some excellent explanation about the working and explanation of the attacks is available at following places:

The security advisory by the authors of the attack, Bodo Moller, Thai Duong and Krzysztof Kotowicz.
Thomas Pornin explaining very succinctly at security stackexchange.
A detailed explanation of the vulnerability and its history .
This and this contains information about configuration changes in various servers and browsers to be taken care of in order to protect against POODLE.

The Workaround

There are couple of workarounds suggested by experts. One recommended by most is to outright totally disable SSLv3. As argued, it is a very old protocol and now most modern devices support its successor, thus it makes sense to do so. But if this is not an option, then using TLS_FALLBACK_SCSV proposal by Google’s Adam Langley is another option.

SCSV stands for “signaling cipher suite value”, and its essentially a hack which allows TLS clients to indicate to servers that they support some extensions to TLS, while ensuring that servers that don’t understand the extension will simply ignore. SCSV works by appending a special, bogus value to the list of ciphersuites that the client advertises support for. The working of this proposal is a IETF draft and not standardised yet, but many implementation are supporting it now.

The working of SCSV is very simple, but tend to confuse in the first shot. In case of an attack via downgrading the SSL version, TLS_FALLBACK_SCSV indicates that the client is knowingly repeating a SSL/TLS connection attempt over a lower protocol version than its supports, as the last one failed for some reason. When the server sees this TLS_FALLBACK_SCSV in ciphersuite list, it compares the highest protocol version it supports to the version indicated in the Client Hello. If the client’s version is lower, then the server responds with a new Alert defined by the RFC called ‘inappropriate_fallback’ (code 86). The logic being that the server knows the client supports something better so the connection should have negotiated that. The ‘inappropriate_fallback’ Alert is a “fatal” error and the connection attempt should be aborted. In practice, this protects from all forced downgrades attack completely. Unfortunately, this is not the silver bullet to the problem. In case the client-server negotiate SSLv3 protocol then this attack can be carried out. To further read about TLS_FALLBACK_SCSV, you can visit here and RFC draft.

How To Detect

The detection is also straightforward. Send the TLS_FALLBACK_SCSV {0x56,0x00} in the list of supported ciphersuites in the Client Hello, if the server responds with an alert message inappropriate_fallback, then the server is not vulnerable to downgrade attack. Additionally, it is best if the server does not support SSLv3 outright.

Keep hacking!! :D