Happy 2014 to you all (and some Gradle and SecuRT to go)

Happy new year to whomever is reading this. May it bring you security and happiness.

Today I pushed my first version onto git after playing with Gradle as my new building environment. The reason that I moved is that I like to have an environment to develop in which is flexible (like ant), but also has build in dependency management (like Maven) all into one (unlike ant combined Ivy). The fact that Maven is not really flexible to the extend that you can’t do stuff like the following:

// after first compilation, build the basic bootstrap classes
task compileJava.doLast {
    javaexec {
        classpath sourceSets.main.runtimeClasspath
        main = generator
        args = [
            "-d",
            sourceSets.main.output.classesDir,
            "-p"
        ].toList()
    } 
} 

There are still some issues with Gradle that can be done more neatly or nicely, but for now it compiles, builds and tests the classes that I want. (if you can send me improvement, please do).

Currently I’m working in getting java.sql.Statement checked. As this is an interface you can’t just alter it, but that has to be done in runtime. I have to find a way in finding the correct class and altering that. I know it can be done through a JavaAgent, but for now I don’t want to add more ‘JVM Arguments’ to the command line. I like to keep it ‘simple’ for the intended end user.

So far, look at github and tell me what you think.,

Next Steps

I’m not the most regular poster, but Dinis Cruz encouraged me to use it more for mental notes to myself (can’t find the exact blog posting, but will give the link when I remember it). So that’s what I’m going to do from now on.

At the moment I’m ‘automating’ my Evil bit system. I’ve created an XML file which will be used to generate the altered classes. It’s easier to use the following contrust:

<securt>
    <sources>
        <!--source class="java.lang.StringBuilder" method="toString"/ -->
        <source class="java.io.BufferedReader" method="readLine" arguments="boolean" />
        <source class="java.io.RandomAccessFile">
            <method name="readUTF"/>
            <method name="readLine"/>
        </source>
    </sources>
    <sinks>
        <sink class="java.io.PrintStream" method="print" arguments="java.lang.String" vulnerable="1"/>
        <sink class="java.io.DataOutput">
            <method name="write" arguments="int" vulnerable="1"/>
        </sink>
    </sinks>
</securt>

I’ve also decided to use a static class for the tainting and testing, this will allow for simple adjustments in the future, but as I have to use the altered String class it did give me some challenges in defining the whole build process.

    private static void createTaintUtil(String destPath) throws NotFoundException, CannotCompileException, IOException {

        ClassPool cp = ClassPool.getDefault();

        // Just a shortcut to copy the Superclass to the new destination
        CtClass atu = cp.get("org.owasp.securt.AbstractTaintUtil");
        atu.writeFile(destPath);

        CtClass cc = cp.makeClass("org.owasp.securt.TaintUtil", atu);

        cc.addMethod(CtNewMethod.make("public static void setTaint(String tainted, boolean taint) {if(tainted != null){tainted.setTaint(taint);}}", cc));
        cc.addMethod(CtNewMethod.make("public static void checkTaint(String tainted) {if(tainted.isTainted())markTaint();}", cc));

        cc.writeFile(destPath);
    }

So what are my next steps? My ideas for going forward are as follows:
– taint the java.sql.Statement Interface (or at least have the implementation of the interface tainted from the bootclasspath)
– have a PoC for tainting J2EE classes
– perhaps have more fine grained tests of taints like Gravizapa (don’t know yet if I should pursue that or not)

That’s it for now. Happy holidays and a merry new year to whomever reads this 😉

Migration to an easier environment

In my previous post I mentioned that I got the Evil bit set. But I had to do that the long way round, as in, I actually changed the code in the OpenJDK of the following classes:

  • java.lang.String
  • java.lang.AbstractStringBuilder
  • java.lang.StringBuilder
  • java.io.BufferedReader
  • java.io.PrintStream

My PoC worked, but for every change I build into it, I had to wait for about 20 to 25 minutes on the compilation step. Which, of-course, for me is unacceptable but it did show that my initial feeling around the tainted String was correct. So now I made a newer version in which I use Javassist to build the modified classes based on the used JDK.

        ClassPool cp = ClassPool.getDefault();
        CtClass cc = cp.get("java.lang.String");

        // add the new tainted field
        CtField f = new CtField(CtClass.booleanType, "tainted", cc);
        f.setModifiers(Modifier.PRIVATE);
        cc.addField(f);

        // generate getters and setters for the new field
        cc.addMethod(CtNewMethod.getter("isTainted", f));
        cc.addMethod(CtNewMethod.setter("setTaint", f));
        cc.writeFile(destPath);

This removes the dependency to my build version, but allows anybody to create their own SecureRT.jar file (ok, modified classes for now) and test their applications on the potential use of tainted strings.

A new approach

Thanks to Arshan Dabirsiaghi who made a comment in http://blog.diniscruz.com/2013/09/java-tainted-strings.html I got a new approach to investigate. He mentioned JRebel and their process which reminded me of the Javaagent – which I had completely forgotten. JRebel uses the Instrumentation possibility to rewrite classes to be updateable, so I’m going to use the same technique to add tracking information into Strings.

I already have created an simple test case of input validation and output encoding:

package org.owasp.securert;

import java.io.*;

public class Basetest {
    public static void main(String[] args) {
        System.out.print("Enter your name: ");
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String userName = null;
        try {
            userName = br.readLine();
        } catch (IOException ioe) {
            System.out.println("IO error trying to read your name!");
            System.exit(1);
        }

        System.out.println("Thanks for the name, " + userName);
    }
}

I agree, it’s not a highly sophisticated test case, but it has security vulnerabilities. If you send the following string

'\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08test                           ' 
it will print Thanks test
instead of Thanks for the name, test that you would expect.

Now I’m going to see how ‘easy’ it will be to track the taint using both approaches, Bootclassloader and Javaagent.

Up the ante

My goal with the String meta-data is actually very simple. It should be designed in such a way that all developers/testers that are using the JVM can use it. Sort of copied from the ZAP policy “It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing as well as being a useful addition to an experienced pen testers toolbox.”

The end result should be easy to use and non intrusive to existing code. For this reason I’ve started to focus on the option of customisation. If I manage to adapt the Core classes of Java in such a way that I can do taint tracing, I can create a version in which security tests can be run simultaneously to unit and integration tests.

By allowing that the security testing is executed during unit and/or integration tests that would mean that ‘ordinary’ developers can perform these tests without those pesky security testers. And by changing the base classes themselves, it would mean that the test would be non intrusive to the actual code created by the developers in the first place.

The changed base classes should not be used in production systems, but if I manage with this, perhaps those production systems would be a bit more secure.

It starts with an idea

The AppSec conference in Hamburg just stopped and I’m already busy again. But this time it’s not only with the CTF that I host for OWASP, but also with a new – at least I hope it’s new – idea.
And that is to improve the security position of Java. The idea is to add meta-data (like a taint flag) to the String class and by doing so manage to get source-sink tracing possible. I’m not doing this alone, but together with Dinis Cruz we’re looking into this possibility. Not to make a production alteration, but as an additional scenario during testing.
As John Willander already said, the String class is way too open for abuse. Let’s find an easier way to check this and by doing so improve the code quality.

There is nothing wrong with being ambitious.