Twitter
Tuesday
Dec162014

Hooking Non-Public Methods With the NDK - Using Mobile Substrate For Android Part 2

One day, you decide to put on the security ninja gloves, open your laptop, plug your android phone and take apart your dear Android application using Part 1 of our tutorial on Android Hooking using Mobile Substrate; and you realize there is something wrong – something is not working. Then you come to the realization that your hook can’t access non-public methods. This post will discuss an option for hooking non-public methods by utilizing Mobile Substrate from NDK code.

Getting Started

The application we will be using in this demonstration is a demo application called SuperMath and can be downloaded here. This application will perform various mathematical operations within private functions and display the results to the user. The focus of this post will be hooking into private functions of a class, accessing and modifying the function parameters, and viewing and modifying the function’s return values.

Note: This guide assumes you have a rooted device, have already installed Mobile Substrate onto the device, and have already downloaded the Mobile Substrate API.

In case you haven’t done so yet, you can download the Mobile Substrate APK here: https://play.google.com/store/apps/details?id=com.saurik.substrate

You can also read the following documentation on how to download the Mobile Substrate APIs here: http://www.cydiasubstrate.com/id/73e45fe5-4525-4de7-ac14-6016652cc1b8/

Preparing NDK/JNI Support

After following steps “Setting Up the IDE” and “Adding Permissions to AndroidManifest.xml” from Part 1 of our tutorial, we need to make sure that we have installed and enabled NDK support for the ADT plugin and that the environment variables are set properly. To ensure that we have NDK support available, we will navigate to the ‘About Eclipse’ menu item, click the ‘Installation Details’ button and check for ‘Android Native Development Tools’ under ‘Installed Software’. If an entry for ‘Android Native Development Tools’ is missing then we are missing NDK support and NDK support can be installed from the ADT Plugin Update Site. 

Once the plugin has been installed successfully, ensure that SDK and NDK paths have been properly set in Eclipse Properties. This can be done as follows:

  • Navigate to the ‘Preferences’ menu item, select ‘Android’ preferences, and set SDK path
  • Navigate to the ‘Preferences’ menu item, expand ‘Android’ preferences, select ‘NDK’ preferences, and set NDK path

Adding NDK/JNI Support

Next, we will need to add support for NDK/JNI to our project. This will allow us to use NDK functions to interact with the Android system and applications. In order to add NDK/JNI support, Right Click on project, navigate to the ‘Android Tools’ context menu, and click ‘Add Native Support…’. Once you click the menu item, Eclipse will show you a dialog box and will ask you for the name of your library. You can specify whatever name that pleases you. However, it is a good practice to append suffix ‘.cy’ to help one identify it is a Cydia extension.

 

 

 

 

Once you click Finish, the ADT plugin will process the provided information and generate a new directory ‘jni’ under the project directory and create following two new files –

  •  <libName>.cpp: This file will contain the code for the Substrate hook
  • Android.mk: This is a Makefile file which contains make commands used to build our hook

 

 

Including Substrate Libraries

Next, we need to include the Substrate libraries. The easiest way to do this is to navigate to the ‘/sdk/extras/saurikit/cydia_substrate/’ directory and copy ‘substrate.h’ and navigate to the ‘/sdk/extras/saurikit/cydia_substrate/lib/<ARCH>/’ directory and copy ‘libsubstrate-dvm.so’ file into the jni folder of the project.

 

 

Finding Target Functions

The ‘SuperMath.apk’ contains a private method to perform multiplication (This can be identified by decompiling the application using a utility like Dex2Jar) :

private String mul(int a, int b){
  return "" + (a * b);
}

 

If we recall, the steps outlined in previous tutorial will not allow us to hook into non-public members of a class.  By creating our hooks using NDK code we will be able to overcome this limitation.

Coding a Substrate NDK Hook

We will start by including appropriate header files in the ’.cpp’ file, and calling the ‘MSConfig’ Substrate macro.

#include "substrate.h"
#include <android/log.h>

#define TAG "NDK_HOOK"

/*
 * Decide where we would like to hook
 */
MSConfig(MSFilterExecutable, "/system/bin/app_process") 

 

The first import statement imports substrate headers into the current program to provide us all Substrate functionality. The second import statement imports Android logging headers into the current program to provide us logging features, which will be used later in the program to log information to LogCat.

MSConfig is a Substrate macro that allows developers to configure and ask the Substrate runtime to allow our extension to hook into the application or the library of our choice. MSConfig takes two string constant arguments: the name of a configuration option and a string value.

Macro Signature: MSConfig(configOption, configOptionValueAsString)

Configuration Option

Description

MSFilterExecutable

This tells the Substrate runtime that we would like to hook into an application. If this configuration option is specified as the first argument to the MSConfig macro, the second argument is a string value containing the fully qualified path to the process that we are trying to hook. Usually this argument is set to “/system/bin/app_process” as this process points to zygote but can be other processes as well.  For more information on why we wish to hook zygote, refer to the blogpost by David Ehringer on The Dalvik Virtual Machine Architecture. For this blogpost, we will hook into zygote.


MSFilterLibrary

This tells the Substrate runtime that we would like to hook into a library. If this configuration option is specified as the first argument to the MSConfig macro, the second argument is a string value containing the library that we are trying to hook. If we are trying to hook __android_log, the value of this argument will be “liblog.so”.

 

Then we will call the MSInitialize macro in order for us to write the function definition used to initialize the hook. This is the primary entry point into the application and where we begin to write our hooks.

/*
 * Substrate entry point
 */
MSInitialize
{
  // Let the user know that the extension has been
  // extension has been registered
  __android_log_print(ANDROID_LOG_ERROR, TAG,
      "Substrate initialized.");

// Hook into specified class and call OnClazzLoad // method when hooked MSJavaHookClassLoad(NULL, "me/rahilparikh/SuperMath/ShowMathOps", &OnClazzLoad); }

 

A call is made to the MSJavaHookClassLoad function, which is used to hook into the class specified by the second argument to the function.  A callback function is passed as the third argument which will be called once the ‘ShowMathOps’ object is loaded.

Method Signature: MSJavaHookClassLoad( jniPtr, classNameAsString, referenceToCallbackMethod)

The class name passed to MSJavaHookClassLoad follows the JNI naming convention. So, me.rahilparikh.SuperMath.ShowMathOps is written as me/rahilparikh/SuperMath/ShowMathOps. The OnClazzLoad callback function will now need to be defined as follows:

/*
 * This method should be used to perform various operations
 *  within the class
 */
static void OnClazzLoad(JNIEnv *jniPtr, jclass clazz,
    void *data) {

  // Let user know that the class has been hooked
  __android_log_print(ANDROID_LOG_ERROR, TAG,
      "Hooked into the application.");

  // Search for method
  jmethodID methodMul = jniPtr->GetMethodID(clazz, "mul",
      "(II)Ljava/lang/String;");
  if (methodMul != NULL) {
    // Let user know that we have found the method
    __android_log_print(ANDROID_LOG_ERROR, TAG,
        "mul called.");
    // Hook into method
    MSJavaHookMethod(jniPtr, clazz, methodMul,
        &newMulMethod, &oldMulMethod);
  }
}

 

The onClazzLoad callback function is invoked once the specified object is loaded by the Android device. The first parameter to this function is a JNI Pointer, which will provide us access to various JNI methods. The second parameter to this function is an instance of jclass, which will provide us access to the members of the class.

In onClazzLoad, we call the GetMethodId method to get a reference to the method that we are trying to hook into. Refer to JNI and JNI Types and Data Structures documents to for more information on how to use GetMethodId and other JNI methods. On the next line, we check if an instance of the returned methodId is null or not. If the instance is not null, a Java method that matches our signature was found and we will use MSJavaHookMethod to hook into our desired method.

The MSJavaHookMethod function is used to replace the implementation of the function at runtime. The third parameter contains the reference to the ‘methodId’ that was previously returned by the GetMethodID function. The fourth parameter contains the reference to the new implementation of the ‘mul’ method that will need to be defined within our Substrate code. The fifth parameter will contain a callback reference to the original ‘mul’ method. We will still need to the define a prototype for the function passed as the fifth parameter. Substrate will handle setting the appropriate values once the ‘mul’ method is hooked.

The following walks through how to create the function prototype to the ‘oldMulMethod’ and a definition for the new ‘newMulMethod’ method to include the code we want to execute within the hook.

/*
 * Original method template
 */
static jstring (*oldMulMethod)(JNIEnv *jni, jobject _this, ...);

/*
 * Modified method
 */
static jstring newMulMethod(JNIEnv *jni, jobject _this,
    jint param1, jint param2) {

  // Let user know that the method has been hooked
  __android_log_print(ANDROID_LOG_ERROR, TAG,
      "Hooked into mul.");

  // Print all original parameters
  __android_log_print(ANDROID_LOG_ERROR, TAG, "Param1 : %d",
      param1);
  __android_log_print(ANDROID_LOG_ERROR, TAG, "Param2 : %d",
      param2);

  // Call original method
  jstring originalRetVal = (*oldMulMethod)(jni, _this, param1,
      param2);
  __android_log_print(ANDROID_LOG_ERROR, TAG,
      "Original Answer : %s",
      jni->GetStringUTFChars(originalRetVal, 0));

  // Modify return value of original method
  char *modifiedRetValC = (char*) malloc(3);
  strcpy(modifiedRetValC, "10");
  __android_log_print(ANDROID_LOG_ERROR, TAG,
      "Modified Answer : %s", modifiedRetValC);
  jstring modifiedRetValS = jni->NewStringUTF(
      modifiedRetValC);

  // Be a nice kid, return what you've got
  free(modifiedRetValC);

  // Return modified return value
  return modifiedRetValS;
}

 

The hook will simply log the values of the parameters that were passed by the application to the ‘mul’ method. This allows us to gain visbility into the values being passed at runtime without requiring a debugger. We then call the ‘oldMulMethod’ function which causes the original ‘mul’ method that was defined by the hooked application to be invoked. We could have modified the values for the param1 and param2 variables if we would have liked, but in this scenario we simply pass them to the original method. The return value of the original mul function is then logged as well. Lastly, we then decide to modify the expected return value of the ‘mul’ funtion so that the value of “10” will always be returned.

Configuring Android.mk

Once the hook has been created we need to update the Android.mk Makefile to help the Android build system understand what we are trying to achieve and how it should compile our application. The Android system creates a Android.mk make file with the following as default content –

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := SuperMathHook.cy
LOCAL_SRC_FILES := SuperMathHook.cy.cpp

include $(BUILD_SHARED_LIBRARY)

This would have allowed us to compile a simple ‘Hello World’ application but we will need to make some modifications to account for the Substrate library dependencies. The resulting Makefile should look similar to the following:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE:= substrate-dvm
LOCAL_SRC_FILES := libsubstrate-dvm.so
include $(PREBUILT_SHARED_LIBRARY)

include $(CLEAR_VARS)

LOCAL_MODULE    := SuperMathHook.cy
LOCAL_SRC_FILES := SuperMathHook.cy.cpp
LOCAL_LDLIBS := -llog
LOCAL_LDLIBS += -L$(LOCAL_PATH) -lsubstrate-dvm

include $(BUILD_SHARED_LIBRARY)

 

For more information on how to configure the Android.mk file, refer to the NDK Programmer’s Guide, which is shipped with the NDK SDK.

Running our Substrate Hook

With the skeleton of the Substrate hook in place, running this code should allow us to hook into the desired class and method. The created Substrate hook can then be run using the instructions found in Part I - Using Mobile Substrate With Android Applications  After the screen flashes, we can run the SuperMath application and monitor the output of Logcat for the tag “NDKHook”. 

Conclusion

JNI does not suffer from the access restrictions that are imposed by Java to access various fields, methods and other members of an application. Therefore, writing hooks using the NDK Substrate APIs can give us low-level access to the application code and allows us to make changes to the existing code at runtime.

One should also remember that some of the method signatures provided here are simplified, minimal and essential for writing a hook. There are instances where these methods can take more arguments but are not specified here as they have been omitted to improve the understanding of the hook writing process and/or they are not required in most cases.

All of the code discussed within this blog post can be found on our Github page here.

 

References/Further Reading

Ehringer, D. (2010, March). The Dalvik Virtual Machine Architecture. Retrieved October 2014, from http://davidehringer.com/software/android/The_Dalvik_Virtual_Machine.pdf

Java Programming Tutorial – Java Native Interface (JNI) . (2014, February). Retrieved October 2014, from https://www3.ntu.edu.sg/home/ehchua/programming/java/JavaNativeInterface.html

JNI Functions. (n.d.). (Oracle Corp.) Retrieved Oct 2014, from Java SE Documentation: http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html

JNI Types and Data Structures. (n.d.). (Oracle Corp.) Retrieved October 2014, from Java SE Documentation: http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html

Kumar, A. (2012, October). Understanding Android: Zygote and DalvikVM. Retrieved October 2014, from StackOverflow: http://stackoverflow.com/a/12703292

NDK Programmer’s Guide. (n.d.). Retrieved October 2014, from Android.mk: /ndk/docs/Programmers_Guide/html/md_3__key__topics__building__chapter_1-section_8__android_8mk.html

 

Friday
Oct032014

A Java Web App's Attack Surface to Shellshock

Amongst the chaos of trying to patch and the whirlwind of information on the Shellshock vulnerability, several of our clients raised the question - what level of exposure, if any, do our enterprise Java web applications have to Shellshock?

In case you’ve been living under a shell, here are a few links to get up to speed on CVE-2014-6271, dubbed Shellshock. Various web-based software products were proven to be vulnerable. Custom web apps running on Apache using mod_cgi or mod_cgid where CGI scripts are either written in Bash, or spawning subshells are also easy targets (if a vulnerable version of Bash is still installed). Web apps written in PHP, Python, or Java could be vulnerable if they make calls to functions such as popen() or system(), as these are backed by calls to /bin/sh -c. Since it is common for systems to create symbolic links from /bin/sh to /bin/bash it could still lead to these applications being susceptible to the Shellshock vulnerability.  

Despite Java apps being implicated as potentially vulnerable, our gut reaction was the exposure for a typical Java web app would likely not be critical or systemic, but rather on a case by case basis. Further, we always advise our clients that any Java web app spawning external processes be closely audited and better more secure alternatives be considered irrespective of this Bash vulnerability. With that said, we still wanted to do a little bit of research to back this up and this blog post shares some of these results. On to the details …

Two main conditions must be met to exploit the Shellshock vulnerability :

  1. The system runs a vulnerable version of Bash shell
  2. An attacker injects a persistent or volatile malicious environment variable into directly or indirectly invoked Bash shell

Applications running Apache ‘mod_cgi’ are remotely vulnerable to Shellshock due to HTTP request headers (e.g. User-Agent header) being set as environment variables. During the request processing Apache receives an HTTP request header and sets the values as environment variables that are visible within the script handler provided by mod_cgi. The combination of user controllable environment variables through HTTP data and the behavior of command executions spawning shells creates a high potential for exploitable Shellshock scenarios within CGI applications to be a likely scenario.

However, Java web application containers like Apache Tomcat, handle the request parameters and headers without using the environment variables as a pipeline. To verify the previous statement GDS performed a set of tests on Apache Tomcat (v8.0.12,7.0.55) and JBoss Application Server (v7.4). The tests included using a python script that injects a Shellshock payload into HTTP request headers and query parameters on a selected endpoint. A simple JSP page was built to iterate through the environment variables to confirm that the request headers did not lead to an environment variable being tainted with user input. As expected, this was confirmed and significantly reduces the potential for Shellshock to be exploited in a Java web app via the typical HTTP header payloads

POC.JSP:

… snip …

Enumeration<String> HeaderName = request.getHeaderNames(); %>

<H1> Headers</h1>

<% 

 String headerName , headerValue  ;

while(HeaderName.hasMoreElements()){

  headerName  = HeaderName.nextElement();

  headerValue = request.getHeader(headerName);

  // Save Header

  headerMap.put(headerName, headerValue);

 %><H1> Env Variables </h1><%

for(Map.Entry<String,String>  entry : System.getenv().entrySet()){ %>

  <%=entry.getKey()%> <%=entry.getValue()%><br>

<%

for(Map.Entry<String,String> headerEntry : headerMap.entrySet()){

  if(entry.getValue().contains(headerEntry.getValue())){

  finding.put(entry.getKey(), headerEntry.getKey() +":"+ headerEntry.getValue());

}}}

// Register Logs

for(Map.Entry<String,String> entry : finding.entrySet()){

  writer.append(entry.getKey()+":"+"{"+entry.getValue()+"}");

}

…snip …  

Tester.py :

…snip …

def start:

request_headers =  {}

for header_key in INPUT.HEADERS:

for reuqest_method in INPUT.METHODS:

  request_headers = copy.copy(INPUT.HEADERS)

  request_headers[header_key] = INPUT.HEADERS[header_key]+INPUT.PAYLOAD

  self.__client.request( request_method,"/ POCs_Headers.jsp",headers=request_headers )

  self.__logfile.write(self.__client.getresponse().read())

… snip …

Java’s ‘Runtime.exec’ method seemed like the most obvious place to start as a high-risk function that could work as a stepping stone for exploitable scenarios of Shellshock. ‘Runtime.exec’ uses the ProcessBuilder class to execute the command passed to it. The following outlines the function execution flow for executing the submitted command.

Runtime.exec function flow :

- > Runtime.exec(String command)

- > Runtime.exec(String command, String envp, File dir)

- > ProcessBuilder.start(String[] cmdArray, Map<String,String> env, String dir, …)

- > UnixProcess( final byte[] prog, …. )

- > forkAndExec( … )

Unlike command execution APIs found on PHP or Perl where a shell will be invoked regardless of the string passed in, Java’s Runtime.exec does not work in this manner. Runtime exec will perform an exec of the submitted string value and therefore a Shellshock vulnerability could only occur if Bash is invoked by the running process by calling ‘/bin/bash’, symbolic links to ‘/bin/bash’ or any executable that may invoke Bash at some point. 

In the event that an environment variable within the application server process is user controllable it would cause the application invoking the following code to be vulnerable to the Shellshock vulnerability (as discussed above, this is not the case for the application servers we looked at):

Runtime.getRuntime().exec( "/bin/bash" ) ;

Runtime.getRuntime().exec( "/script.sh" ) ; # Where script.sh uses !#/bin/bash 

Another exploitable scenario but also very unlikely would be if a malicious environment variable is passed as the second parameter within the ‘Runtime.exec’ method.

Runtime.getRuntime().exec(

  new String[]{"/bin/bash"},

  new String[]{"P=() { :;}; echo 'vulnerable' > message"}

);

Runtime.getRuntime().exec(

  new String[]{"/script.sh"},

  new String[]{"P=() { :;}; echo 'vulnerable' > message"}

);

What follows is a sample code snippet that if present in a web app would be remotely exploitable via Shellshock:

… snip …

Enumeration<String> HeaderName = request.getHeaderNames();

String headerName , headerValue ;

while(HeaderName.hasMoreElements())

{

 if ( headerName.nextElement().equals(“HOST”)){

 headerValue = request.getHeader(headerName);

 Runtime.getRuntime().exec(

  new String[]{“/bin/bash”,”-c”,”/bin/process_host”}, new String[] {headerValue});

 }

} 

Although not impossible, it’s unlikely that a developer would pass the environment variable intentionally via a HTTP header.

In conclusion, while there are certain scenarios where a Java web app could be vulnerable to Shellshock, these are likely to be one off edge cases. This is primarily due to application servers not setting environment variables with HTTP request data and also the fact that Runtime.exec does not invoke a shell unless explicitly set by a developer or indireclty used by any invoked script. Organizations should ensure that Bash is patched to the latest version and not vulnerable to Shellshock. Additionally, identify if any of the following methods or functions are called using a shell (e.g. /bin/bash/, /bin/sh, shell scripts) and ensure user input is not passed in as any parameters unless it undergoes stringent input validation. 

  • Runtime.exec
  • ProcessBuilder.start

  • UnixProcess

  • forkAndExec

It is also recommended to pass in a empty String array as the environment to these functions in order to prevent the possibility of the application server’s environment being tainted with user input. By passing an empty array as the environment it will provide an extra layer of protection in the event the application server’s environment variables can be compromised

Tuesday
Sep232014

Auditing Scala for Insecure Code with FindBugs

Here at GDS we have noticed an increase in the use of the Scala programming language by our clients. We have been looking for good tools to perform static analysis of Scala to facilitate our code audits. Although there are static analysis tools for Scala, they are not capable of identifying security issues with their out of the box rule-sets. In this blog post we cover how FindBugs can be leveraged to scan Scala for the purposes of identifying insecure code patterns.

Why FindBugs?
FindBugs is an open source static analysis tool that detects bugs in Java applications. Unlike static analysis tools PMD or Jlint, FindBugs operates on bytecode rather than source code. Because Scala classes compile to Java bytecode, this means we can run FindBugs against them! Additionally, FindBugs exposes a plugin interface making it possible to write custom bug detectors to find vulnerabilities in Scala applications. It is possible to run FindBugs without custom detectors against a Scala code base, however there will certainly be false positives and false negatives since the bug detectors are tuned against javac compiler generated bytecode. To start finding security flaws we need to write Scala specific detectors. Finally, because FindBugs is a well-known open source project already common to developer toolchains, the learning curve for extending is potentially reduced and existing development workflows do not need to be altered. It is also worth mentioning that FindBugs is integrated into the enterprise security static analysis tool Fortify SCA, and so the approach we suggest here could be a low cost alternative for these organizations. 

Implementing Your First Security Detector
We will implement a very small ‘Hello World’ detector which does nothing more than to flag every time a dangerous MongoDB function is executed. We will be writing a rule targeting Casbah, the official MongoDB driver for Scala. The Casbah library has an ‘eval’ method which can lead to the execution of arbitrary Javascript code if unvalidated user input is passed in. We will walk through how to write a rule to identify potential insecure usage of the Casbah ‘eval’ method within Scala applications.

For an introductory tutorial on how to write custom detector for FindBugs have a look at https://code.google.com/p/findbugs/wiki/DetectorPluginTutorial. For the rest of this blog post it will be assumed that you know the basics shown in the above link.

  • Since we are operating on bytecode we will extend the BytecodeScanningDetector
  • We will override the visit method, since it is called every time new code is executed.
  • When we find the ‘eval’ method we will log a bug using the standard FindBugs logging interface.

We start with extending the BytecodeScanningDetector so Findbugs knows what code we are interested in.

public class HelloworldRule extends BytecodeScanningDetector {

Next, we declare the function we are looking for. Invokevirtual means that a new function is being invoked.
private final String VULNERABLE_METHOD = "com.mongodb.casbah.MongoDB.eval";
private final String FUNCTION_DECLARATION = "invokevirtual";
BugReporter bugReporter;

We also need to define a constructor which will take in a ‘bugreporter’ object which is used to report back found bugs to FindBugs.
public HelloworldRule(BugReporter bugReporter) {
 this.bugReporter = bugReporter;
}

Next we chose to implement the visit function. The documentation around this method is a bit shorthanded but the returned object “represents a chunk of Java byte code contained in a method” according to the Javadocs. Using this method allows us to analyze a function line by line.
public void visit(Code someObj) {
 ByteSequence stream = new ByteSequence(someObj.getCode());
 while (stream.available() > 0) {
   String line = Utility.codeToString(stream, someObj.getConstantPool(), true);

 We use two helper functions to identify the function call. getCommand will give us the current instruction being executed. In this example we are mainly interested in the invokevirtual instruction mentioned above. 
String command = getCommand(line);

We also use getFunction to parse out a function signature. It might look like the following:
com.mongodb.casbah.MongoClient$.apply (Ljava/lang/String;I)Lcom/mongodb/casbah/MongoClient
The signature will always start with the full package name followed by the function name. For this example, this is all we need. For more involved rules, the function arguments could also be analyzed.
String function = getFunction(line);
 if(command.equals(FUNCTION_DECLARATION) &&   
   function.startsWith(VULNERABLE_METHOD)) {

If the function matches what we are looking for we will log a bug. We state that it’s a normal priority bug and we pass in an identifier which we will define below.
    BugInstance instance = new BugInstance("MONGO_INJECTION",
      NORMAL_PRIORITY).addClassAndMethod(this).addSourceLine(this);
    bugReporter.reportBug(instance);
  }
}

protected String getCommand(String line) {
 String[] parts = line.split("\\t");
 return (parts.length > 0) ? parts[0] : "";
}

protected String getFunction(String line) {
 String[] parts = line.split("\\t");
 return (parts.length > 1) ? parts[1] : "";
}

We also need to reference our new rule so FindBugs knows where to find it. Create a new folder in the project directory and name it “etc”. Create a new file called findbugs.xml in this folder. In here we can reference the rule by adding the following text:

<FindbugsPlugin>
  <Detector class="com.package.HelloworldRule" speed="fast" />
</FindbugsPlugin>

Lastly we need to give a short description of our plugin. Create a new file called messages.xml in that same folder. Put the following content in there:

<MessageCollection>
  <Detector class="com.package.HelloworldRule">
    <Details>
      <p> A Simple Mongo Injection Detection Rule</p>
    </Details>
  </Detector>
</MessageCollection>

The plugin is now ready to go, let’s give it a test!

Running FindBugs is pretty simple, all you need to do is to download the Jar and specify the source to run against. Adding new plugins is simple as well. You can either supply the plugin jar as a command line argument or you can add it to the default plugins folder for FindBugs. For this example we’ll add it on the command line:

java -jar /path-to-findbugs/findbugs.jar -textui -pluginList /path-to-your-new-jar.jar -home . -auxclasspath /path-to-scala-installation/:casbah-alldep.jar /path-to-class-files/

It is important to specify the auxclasspath option since this is how we will specify the classpath to the Scala installation. If the auxclasspath is not set, running Findbugs on Scala code will result in various errors. Additionally we add the Casbah jar to the path since it is a dependency to our sample application. Any other dependencies to the application being scanned should be added to the auxclasspath option when running FindBugs. The sample output below shows how FindBugs will report usage of the Casbah eval function within a Scala application.

M S GDS: A Simple Mongo Injection Detection Rule.       At CasbahExample.scala:[line 18]

This is just a short introduction on how to leverage FindBugs to analyze Scala code. Hopefully this code can be used as a foundation to write more involved and more complex rules. Popular web frameworks such as Play and Vert.x run in Scala and FindBugs can certainly be used to evaluate them.

The code referenced in this blog post can be found on our GitHub page: https://github.com/GDSSecurity/Scala-Findbugs-Sample  

Thursday
Aug142014

Analysis of Mobile Application Wrapping Wrap Up

We would like to say thanks to everyone who came to our talk on Mobile Application Wrapping. We received a good amount of positive reactions and we are working hard on completing the whitepaper to accompany the presentation.

The slides for the talk have been added to our Github Repository and is available for download:

Download Slides Here

Thursday
Jul312014

Black Hat USA 2014 

GDS will be speaking at Black Hat USA 2014 on the research we have done on “Application Wrapping” within Mobile Application Management (MAM) BYOD commercial solutions and some of the short comings we have encountered. The complete abstract for the talk can be found here: 

Keep a lookout on our Twitter and Blog for details on downloading the slides and the white paper shortly after the conference. Our research will provide very useful knowledge for the “buyers, builders and breakers” in the BYOD world.

Buyers - Organizations looking to purchase a MAM solution or determine the effectiveness of their current solution will find that we will cover the major threat scenarios in BYOD deployments, common short coming and additionally equip the business with the right questions to ask to the vendors.

Builders - The vendors that are creating the MAM solutions will be able to utilize our research to verify their solutions are not suffering from critical design and implementation flaws. The talk and corresponding whitepaper will provide organization with a solid base line of security checks to validate their solution against.

Breakers - Security assessors can learn throught the walkthroughs of the vulnerabilities discovered. The MAM solution security checklist will be provided so that security firms are equipped with a strong baseline for determining the security posture of a MAM solution. 

The talk will be on August 7th, 5pm at South Seas GH.  We hope to see you there!