Denim Group, Ltd. Blog

ThreadFix 1.1 Release Candidate Now Available

By Dan Cornell

We've been hard at work on ThreadFix since the 1.0 release in October and we're just about ready to push out an updated 1.1 release. This week we've made a 1.1 release candidate available for folks to take a look at and review. You can get it from the ThreadFix downloads site.

What's new in 1.1? Lots of stuff including:

• Support for NTObjectives NTO Spider scans (#162)
• Support for Microsoft Team Foundation Server (TFS) bug trackers (#117)
• Adding user comments for vulnerabilities (#55)
• Editing of manually-entered vulnerabilities (#160)
• "Filter by CWE" for vunerabilities(#163)
• Updated security model to allow for fine-grained user permissions (#56) (this has been a huge priority for the larger enterprises deploying ThreadFix)
• Updated Snort rule generation (#113)
• Updated license from MPL 1.1 to MPL 2.0 (#181)
• Various updates and bug fixes and enhancements (#159, #168, #176, #196)

You can see the full list of features and defects addressed during the 1.1 development cycle in the issue tracker. We've posted information on the ThreadFix wiki about how to upgrade your ThreadFix 1.0.1 install to 1.1 and would love to hear any feedback from people going through that process. So take a look and please post any thoughts or bugs either on the ThreadFix issue tracker or join the ThreadFix Google Group and let us know there.

Contact us for help managing your software security program with ThreadFix.

--Dan

dan _at_ denimgroup.com

@danielcornell

Java User Group San Antonio meeting 6:00 Sep 3, 2009 at New Horizons

http://groups.google.com/group/satjug/web/jug-poster.pdf

The inaugural meeting of the Java Users Group of San Antonio will be Wednesday September 3rd, 2009 at New Horizons at 6:00pm. The presentation will be "Programming in Scala"

Posted via email from denimgroup's posterous

Denim Group Launches ThreadStrong

By Dan Cornell

This has been in the works for quite a while, but the actual public release came out today - Denim Group has released our new application security e-Learning program called ThreadStrong.

We have a brief video online here:

ThreadStrong is a great way for organizations to provide a base-level of application security knowledge for developers and other personnel involved in the software development process.  A number of organizations have also used it to address aspects of compliance requirements such as PCI.

The available courses include:

• Introduction to Application Security Concepts (1 hour, for Developers, QA, Managers and Security Professionals)
• Application Security for Java (4 hours, for Developers)
• Application Security for .NET (4 hours, for Developers
• Threat Modeling (1 hour, for Security Professionals and Developers)

Give us a call or drop us an email if you'd like a demo.

--Dan
dan _at_ denimgroup.com

Command Injection In Java on Windows: 100% Proven that it is 100% Possible (in Certain Cases)

By Dan Cornell

So Alex Smolen's blog post about command injection in Java and .NET has had me writing some little test cases over the past couple of days (Java command injection, .NET command injection).  When I ran some tests in Java on OS X it looked like simple approaches to command injection weren't effective.  Fantastic!

But wait a minute.  WebGoat has a command injection lesson.  And it is written in Java.  What gives?

So I went and dug through the WebGoat 5.2 code and found that they're playing a little bit of dirty pool - they look through the attack payloads passed in and run some checks and do some other stuff.  Oh, and they make calls to cmd.exe which can chain further calls.  So you actually can inject commands in Java on Windows if you're calling the right original executable.  Not good!

So I updated the previous test code to check for the operating system and run different commands on UNIX versus Windows.  And after some tweaking of the intended.bat and exploit.bat batch files I got new results that did allow me to run multiple commands via a single call to System.getRuntime().exec().  Yikes!  Batch files and commands using cmd.exe can be command injected.

I've uploaded updated test code here:

http://www.dancornell.com/files/JavaCommandInjection_v1_1.zip

So:

• Command injection in Java on OS X: seemingly hard and merits further testing, but be careful if you are making calls to shells like /bin/sh
• Command injection in Java on Windows: not hard if you are running a command that can load other commands - like cmd.exe or batch files (which run via cmd.exe)

The reason I got into Java in the first place was "write once, run anywhere"  That might never have worked as well as Sun had promised, but it was a great goal and Java does it much better than C/C++.  Seeing the results of this testing makes for a great lesson: "Do the right thing - even if you think you don't have to."  Also known as: "Defense in depth."

As is often the case, "Doing the right thing" in this case means:

• Positively validate inputs - type, length, composition, business rules
• Properly encode outputs when they get sent to interpreters

Successful testing finds bugs, but cannot prove a lack of bugs.  In this case the test code demonstrates that you can cause command injection by including "&" and perhaps "&&" characters in your commands if the original executable supports chaining other calls.

The test system is running Windows XP SP2 and the Java environment is Java SE Runtime Environment (build 1.6.0_11-b03) Java HotSpot(TM) VM (build 11.0-b-16, mixed mode, sharing)

Next up: more testing.

--Dan
dan _at_ denimgroup.com

Command Injection in .NET: 82% Proven that is 98% Impossible

By Dan Cornell

So I decided to also slap together a .NET version of the Java command injection testing thing I posted yesterday in response to Alex Smolen's blog post on .NET and Java command injection.  It is up online here:

http://www.dancornell.com/files/DotNetCommandInjection.zip

.NET looks to be similarly resistant to command injection.

Also, "Jordan" posted a comment to the previous post:

One quick way to verify Java isn't vulnerable is to see which native functions it's using. On Linux, use strace -f java [...]/Main on your test app and look for exec or system. Yup, we see execve -- safe calls.

I suppose you could do it that way.  If you wanted the easy way to find out what was actually going on.  But then you wouldn't get to write any crudimentary Java code - and what fun would that be?  That's actually a great idea.

Does that mean that you don't need to validate input that is being sent to command interpreters on Java and .NET?  No.  Failing to do this can still give attackers control over command line arguments and filenames.  Plus there may be other ways to break out of this that my 60 lines of Java or C# test code and 15 test cases didn't find.  (What a surprise that would be!)  Sleep a little better at night.  But not too well.

--Dan
dan _at_ denimgroup.com

Command Injection In Java: 80% Proven that it is 100% Impossible (Sometimes)

By Dan Cornell

IF YOU ARE USING JAVA ON WINDOWS PLEASE SEE THIS FOLLOW UP POST ON COMMAND INJECTION IN JAVA ON WINDOWS.  HECK, SEE THE FOLLOW UP POST REGARDLESS.

I was reading Alex Smolen's blog the other day and ran across the post "Command Injection Impossible in Java and .NET?"  Interesting stuff!  In an effort to avoid doing work I should actually be doing, I decided to look into it a bit more.

So I put together a tiny little program to try a bunch of different permutations to try and test this out.  This is by no means an exhaustive fuzzing but I did run a number of command lines through Java that should have resulted in multiple commands being executed (cut and paste them from the Java System.out output).  I zipped up the code and binaries and uploaded it here:

http://www.dancornell.com/files/JavaCommandInjection_v1_1.zip

If you go into the bin/ directory and run "java denimgroup.fuzzer.commandline.Main" it will try to run a bunch of commands.  I have two scripts in the directory: intended and exploit.  "intended" appends its command line arguments to intended_shell_results.txt and "exploit" appends its command line arguments to exploit_shell_results.txt.  On Mac OS X 10.5.6 with Eclipse 3.4.0 using JDK 1.5.0 it runs the following commands through "Runtime.getRuntime().exec(command);"

./intended ; ./exploit
./intended : ./exploit
./intended | ./exploit
./intended && ./exploit
./intended & ./exploit
./intended ! ./exploit
./intended >> ./exploit
./intended << ./exploit
./intended > ./exploit
./intended < ./exploit
./intended :: ./exploit
./intended ;; ./exploit
./intended ;: ./exploit
./intended :; ./exploit
./intended || ./exploit

Assuming that "exploit" was executed, you would expect to see something in the "exploit_shell_results.txt"  For example, if you manually run "./intended ; ./exploit" from the shell (as Java tried and failed to do via exec()) it will put some info in the file.  But - wait - there's nothing there when Java tries to run it!  Perhaps Alex and the OWASP site are right (!).

Clearly this merits further study.  My list of payloads is, by no means, exhaustive.  But this is certainly interesting.  To the degree that the standard Java libraries seem to prevent at least the most boneheaded attempts at command injection - bravo!  There is a long way to go before declaring victory, but this is at least encouraging.  I'd want to spend a lot of compute cycles trying to fiddle with combinations of Unicode characters on different OSes and different JDKs, but these days I am kind of busy.  The code is available under an Apache 2.0 license so anyone can feel free to make this happen.

And hey - maybe I'll fire up VS.NET 2008 and make a C# version.  Otherwise I might accidentally do some real work.

--Dan
dan _at_ denimgroup.com

Houston TechFest Slide Deck Online

By Dan Cornell

The slide deck from my talk at Houston TechFest is now online: Static Analysis Techniques for Testing Application Security.  Also see my previous post about the trip there.

--Dan
dan _at_ denimgroup.com

The Road to Houston TechFest

By Dan Cornell

I was up in Houston last weekend for the rescheduled Houston TechFest.  The hurricane delayed this from the original date, but the event was still packed.

I flew into Houston for the day to give my talk on Static Analysis Techniques for Testing Application Security.  Unfortunately, when I was headed to my early-morning flight, I noticed that the airport had been overrun by birds:

Yikes!  I didn't know who my pilot was, but I wasn't convinced he would be able to successfully land a 737 in the San Antonio River.  After all, the Hudson is a little wider than the Riverwalk...

Fortunately I made it to Houston all right and checked in with the TechFest folks.  The event was at the University of Houston so I went to the bottom of the student center where the event was being held to try and get some work done before my talk.  I soon found myself trapped between a bunch of martial arts students:

And some folks playing "Magic - The Gathering" :

No offense to the "Magic - The Gathering" crowd, but I had to cast my lot with the martial arts folks.  Cards representing elven chain mail and whatnot are no match for a crowd of folks ready to break actual bricks with their hands.

Fortunately everyone got to remain friends and I made it to my talk unscathed.

There was a great group there and we had some great questions such as:

• Does the fact that most .NET static analysis tools rely on decompiling MISL make .NET, as a language, less secure than Java? (Both Java bytecodes and .NET MSIL are pretty easy to decompile, so there aren't a ton of differences there.  .NET static analysis tools usually use MSIL binaries because .NET code exists in a variety of languages and it is easier to write one parser/decompiler for MSIL that will work for all .NET languages wheras Java bytecode is almost always compiled from Java source code, thus making Java source or Java bytecode reasonably equally attractive choices for tool builders.)
• Are there any subsets of PMD rules that are best for running security checks? (There are security-specific PMD checks, but they are mainly related to API misuse.  I don't know of any collection that includes the explicit security rules along with rules from other categories that often have security implications.)

One thing I talked about Saturday that was relatively new was the OWASP Open Review Project (ORPRO) which provides advanced static analysis capabilities for open source projects.

Overall it was a great session and I will be posting the slide deck shortly.

--Dan
dan _at_ denimgroup.com

OWASP EU Summit in Portugal: Tuesday

By Dan Cornell

[Running a little behind, as usual.  Over the course of today I'll be putting up a series of posts to finish out my OWASP EU Summit notes.]

First of all, my favorite part of Tuesday was that I won a t-shirt at the Sensepost training class on offensive web application hacking.  H4x0r skillz!

 

In addition to that, Tuesday was a really productive day.  I had the opportunity to attend a number of sessions where folks presented their Summer of Code projects and OWASP projects in general:

• Jason Li - JSP Testing Tool - This tools tests JSP tag libraries to determine which attributes are properly escaped when they are written out to the HTML stream.  It does this by generating a large number of JSP/HTML examples with various payloads placed into the tags' attributes.  When the page renders, unescaped payloads change colors of parts of the DOM so you can see which attributes are "dangerous"  This is a very cool approach and it would be interesting to see how it applied to ASP.NET web controls as well.
• Paolo Perego - Orizon - Orizon is a framework for code analysis that can apply various rules to look for security defects.  It currently supports Java and there are plans to make it support .NET.  Source code files are broken down into a number of XML representations and then those XML representations are run through a rules engine to identify potential security issues.
• Alex Smolen - ESAPI.NET - This is the .NET version of the ESAPI.  Currently it is basically a word-for-word port of the Java ESAPI into C#, but the plan is to update the .NET version to accomodate existing security capabilities of the .NET platform such as the Membership API and the AntiXSS library.

I also had an opportunity to attend a number of working groups:

• Tools Working Group
• ESAPI Working Group

The energy and enthusiasm at this event was incredible.  As you'll see from the following posts we covered a lot of ground during the week and a lot got accomplished.

--Dan
dan _at_ denimgroup.com

OWASP EU Summit in Portugal: Monday

By Dan Cornell

This week I'm in Portugal at the OWASP EU Summit '08.

Just after I arrived on Monday I had the opportunity to talk about AJAX security and sprajax to a group of students at the 1 day OWASP event at the University of Algarve.  The slide deck was a shortened version of the one from when I presented at OWASP Montgomery.  I always enjoy speaking to University students because you have to work hard to frame the material in the appropriate context.  For example - how do you explain SQL injection to someone who has never written a database application?  How to explain PCI compliance to someone who has never worked inside an enterprise that takes credit cards?

I finally got some sleep Monday night after a day and a half of flights, airport wait time, presentations to University students and the conference kickoff.  This is shaping up to be a great event.  More to come.

--Dan
dan _at_ denimgroup.com