Tags:
Entry #9 on the new CWE/SANS Top 25 is about OS Command Injection [1]. It's officially called Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection'), but I prefer to keep the title short when describing it.
In a previous post [2] we had just gained access to the application by using a default user id and password. Turns out we really couldn't do much with the application level account that we had because it didn't give us full access to confidential customer information. So, we continued to look around and saw that the application was deployed on Tomcat. Of course, we were able to log in to the Tomcat Manager application using the same default user id and password that we had used before. Now, the great thing about Tomcat Manager is the ability to upload arbitrary WAR files.
Of course, we quickly uploaded a web app that called netcat via Runtime.getRuntime().exec() to shovel a reverse shell back to our attacking machine so that we could execute arbitrary OS commands on the server itself. Technically, this isn't "Improper Sanitization of Special Elements used in an OS Command" as we just uploaded a whole app instead of bypassing an unsanitized field used to construct on OS command, but the result was the same.
As a side note, it was interesting to see Ryan Barnett's post [3] where people are still trying to brute force Tomcat Manager credentials so that they too can upload malicious web apps. His October 2009 post came about three years after we uploaded our malicious web app and points out that we need to do a better job defending our applications.
In the next post I'll talk about what we did with our command line access.
- http://cwe.mitre.org/top25/#CWE-78
- https://blogs.sans.org/appsecstreetfighter/2010/02/23/top-25-series-rank-19-missing-authentication-for-critical-function/
- http://tacticalwebappsec.blogspot.com/2009/10/wasc-honeypots-apache-tomcat-admin.html