Denim Group, Ltd.

OWASP Podcast with Dan Cornell Live

By Dan Cornell

My recent appearance on the OWASP Podcast is now live.  I had a great time recording this - we talk about all sorts of OWASP stuff like Membership and ESAPI as well as application security topics like vulnerability management.

You can subscribe to the iTunes feed for the OWASP Podcast here: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012.

--Dan
dan _at_ denimgroup.com

New Denim Group Team Members

Radu I., Team Consultant
Radu brings 6 years in java development and 3 years of .NET development to Denim Group. In his role as team consultant he will specialize in application development. Before Denim Group, Radu worked as a senior application developer for Masai Technologies. Radu has a Bachelor of Science in Computer Science and Economics from Boston College.

Kushala K., Team Consultant
Kushala joins Denim Group as a team consultant with 5 years of experience in IT development and project management. Before Denim Group, Kushala worked as software developer and analyst for HEALTHMEDIA Inc. Kushala has a Bachelor of Science degree in Computer Engineering and a Master of Science degree in Administration from Central Michigan University. She is a member of the Austin Java Group, Ann Arbor Java Group, and Project Management Institute (PMI).

Brent P., Associate Consultant
Brent joins Denim Group as a consultant specializing in software development and quality assurance. Prior to Denim Group, Brent worked as a research intern at iMedia. He is a graduate of Trinity University with a Bachelor of Science degree in Computer Science and a minor in Business Administration and Management of Information Systems.

Web Application Security Panel at Austin ISSA Next Week

By Dan Cornell

I'll be moderating a panel on web application security at the Austin ISSA meeting next Wednesday May 21st from 11:30 to 1:00.  The panelists will be:

• Phil Agcaolli from Dell
• Gary Buonacorsi from Texas Office of the Attorney General
• Frosty Walker from the Texas Secretary of State

This will be a great opportunity to hear what these folks have been doing in their organizations to address web application security risks.

The meeting will be held at:

Microsoft Technology Center
Stonebridge Plaza, Building One
9606 N. Mopac Expressway, Suite 200
Austin, TX  78759
Phone (512) 795-5300
Map: http://tinyurl.com/dzp537

--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

Comments on "Mythbusting: Secure Code is Less Expensive to Develop"

By Dan Cornell

WhiteHat Security's Jeremiah Grossman just put up a blog post titled "Mythbusting: Secure Code is Less Expensive to Develop"  In it he looks at the costs required to fix the vulnerabilities in an "average" web application.

This is interesting analysis, but should probably be expanded to address more types of vulnerabilities and to look at how vulnerabilities cluster in applications.

If you get your fundamental coding idioms wrong, you're going to end up with a whole bunch of XSS or SQLi vulnerabilities. Fixing the first one might take a couple of hours (environment set up, tracking down the issue, testing the fix), but fixing vulnerability 1+N is pretty cheap because you just have to go to the next vulnerability and change the code. Rinse and repeat. It isn't fun work, but at least it is predictable to schedule. Project managers love this.

Business logic issues are a lot more variable to fix. It could be as simple as adding a permissions check before allowing data access or it could require you to change the application requirements and then those changes have to flow down through the development process. Project managers like these less because they could take a lot or a little. Uncertainty and variability are not the project manager's friends.

Architectural issues are the most variable and tend to start large and get enormous with regard to the level of effort required for the fix. I worked on one system where a single vulnerability (weakness in the way authentication worked) required a multi-year change control effort. Yikes! Needless to say, project managers (and line of business managers, executives, boards of directors...) like these the least.

I like the idea of economically modeling remediation efforts, and I think the model should be expanded to look at the mix of vulnerabilities found in applications as well as the mix of applications that organizations have.

I gave a talk about Vulnerability Management in an Application Security World at OWASP Minneapolis/St. Paul a while back that is up on Google Video. We talk about some of the economics surrounding fixing identified vulnerabilities in there a bit.

--Dan
dan _at_ denimgroup.com