Strust Remote code execution vulnerability in relation to published cve-2013-2251 vulnerability

(* This vulnerability affects version: Struts 2.0.0–struts 2.3.15)
(* The blog is just a record of my work and learning problems encountered, for reference only!) ）
(* If there may be an error in the description, please give more advice!) ）

Yesterday in the current responsibility for my ongoing maintenance of the project, the system was conquered by others, uploaded a. txt file, others can directly access the project under the TXT file, you can obtain the contents of the TXT file.

First, I present the project I am currently maintaining, using the strust2.1+hibernate3.0 architecture pattern, also known as the JAVAWEB+SSH framework, but for simplicity, there is no spring framework added. Also does not use the present SPRINGMVC mode!
As for the database, the use of MySQL, because of the lightweight MySQL, by the domestic user's preferences! Server, using Tomcat, there is nothing good to introduce!

Next, I'll show you how the project I'm responsible for is being conquered!

First, open the Strust Vulnerability monitoring tool: Place my current project URL in the Action box:

As follows:

In general, the use of the SSH framework is controlled by the action defined by the Strust.xml file, which is then performed, verified, and, if validated, jumps to success.jsp and, if not verified, is rolled back to login.jsp.

Of course, through this detection tool can see, I am responsible for the project, there is strust2 Remote Code execution vulnerability, number s-016!

Here I upload a test file, ending with a. txt file suffix. Then click Upload:

After the ToolTip is successfully uploaded, the Test.txt file in the directory can be displayed to this

At that time encountered this problem, suddenly head is big, some time ago, I and others discussed PHP by uploading a file vulnerability, upload a truncated. JPG format Trojan, get an example of server permissions.

Later, I went online to check the information, the original loophole, has already been published in July 2013, the specific situation of the loophole is as follows:

Bugtraq ID:61189CVE id:cve- --2251Cncve id:cncve-20132251Vulnerability release Time: -- -- -Vulnerability Update Time: -- -- -Vulnerability cause input validation error hazard level High Impact system Apache Struts2.0. 0-2.3. theNon-affected systems compromise remote attackers exploiting vulnerabilities to execute arbitrary code in the application context. CVSSV2: An attacker must access the Struts app to attack the required conditions. Vulnerability information The Apache Struts Framework is an open source project based on the Java Servlets,javabeans, and JavaServer Pages (JSP) Web application framework. Apache Struts2Defaultactionmapper in handling short path redirection parameter prefixes"Action:"/"Redirect:"/"Redirectaction:"A command execution vulnerability exists due to the"Action:"/"Redirect:"/"Redirectaction:"After theURLInformation is handled using OGNL expressions, where a remote attacker can exploit the vulnerability to submit a specialURLCan be used to execute arbitrary Java code. Test method1, simple expressionhttp://host/struts2-blank/example/x.action?action:% -{3*4}http://host/struts2-showcase/employee/save.action?redirect:% -{3*4}2, the command executeshttp://host/struts2-blank/example/x.action?action:% -{(New+java.lang.processbuilder (New+java.lang.string[]{' command ',' goes ',' here '}). Start ()}http://host/struts2-showcase/employee/save.action?redirect:% -{(New+java.lang.processbuilder (New+java.lang.string[]{' command ',' goes ',' here '}). Start ()}http://host/struts2-showcase/employee/save.action?redirectaction:% -{(New+java.lang.processbuilder (New+java.lang.string[]{' command ',' goes ',' here '}). Start ()} Security Recommendation Vendor Solution Apache Struts2.3. the. 1This vulnerability has been fixed and it is recommended that users download updates:http://struts.apache.org/vulnerability Provider Takeshi Terada ofMitsui Bussan Secure Directions, Inc. vulnerability Message linkhttp://struts.apache.org/release/2.3. x/docs/s2-016.Htmlhttp://struts.apache.org/release/2.3. x/docs/version-notes-23151.Htmlhttp://packetstormsecurity.com/Files/122442/apache-struts-2-open-redirection-command-execution.html Article Source:http://www.venustech.com.cn/

Of course, the solution is also very simple, either patching, or upgrading the version of Strust, of course, the two methods bring a lot of work, not so easy to do, and in my current technology, it is difficult to quickly solve the problem!

Later, I found that the vulnerability was through access to the uploaded file, the suffix is. txt, format, if I do not let him access this file, is not able to solve the problem, as long as the interception through the Strust interceptor is good. (Of course, the interceptor is also added to the project, but the interceptor only intercepts. jsp format files, and no other format files are intercepted!) ）

When you have this idea, the next thing is solved, the project interceptor, optimization is good!

First, paste the Web. XML code that I did not optimize:

<?xml version= "1.0" encoding= "UTF-8"?><web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns= "Http://java.sun.com/xml/ns/javaee" xsi:schemalocation="Http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_ 0.xsd " id=" webapp_id " version=" 3.0 ">  <display-name>Webjourmanage</display-name>  <welcome-file-list>    <welcome-file>Login.html</welcome-file>    <welcome-file>Login.htm</welcome-file>    <welcome-file>login.jsp</welcome-file>  </welcome-file-list>  <filter>    <filter-name>Struts2</filter-name>    <filter-class>Org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>  </filter>  <filter-mapping>    <filter-name>Struts2</filter-name>    <url-pattern>/*</url-pattern>  </filter-mapping>  <filter>    <filter-name>Loginauth</filter-name>    <filter-class>Loginfilter</filter-class>  </filter>  <filter-mapping>    <filter-name>Loginauth</filter-name>    <url-pattern>*.jsp</url-pattern>  </filter-mapping>  <listener>    <listener-class>Org.springframework.web.context.ContextLoaderListener</listener-class>  </listener>  <context-param>    <param-name>Contextconfiglocation</param-name>    <param-value>Classpath:applicationContext.xml</param-value>  </context-param></Web-app>

As you can see, in this piece of code, I've only intercepted. jsp files, and no other files have been intercepted for verification:

  <filter>    <filter-name>Loginauth</filter-name>    <filter-class>Loginfilter</filter-class>  </filter>  <filter-mapping>    <filter-name>Loginauth</filter-name>    <url-pattern>*.jsp</url-pattern>  </filter-mapping>

As for the Loginfilter.class, this is what I wrote:

 PackageFilter;ImportJavax.servlet.Filter;ImportJava.io.IOException;ImportJavax.servlet.FilterChain;ImportJavax.servlet.FilterConfig;ImportJavax.servlet.ServletException;ImportJavax.servlet.ServletRequest;ImportJavax.servlet.ServletResponse;ImportJavax.servlet.http.HttpServletRequest;ImportJavax.servlet.http.HttpServletResponse;ImportJavax.servlet.http.HttpSession; Public  class loginfilter implements Filter{          Public void Init(Filterconfig filterconfig)throwsservletexception {//TODO auto-generated method stub} Public void DoFilter(ServletRequest request, servletresponse response, Filterchain chain)throwsIOException, servletexception {httpservletrequest servletrequest = (httpservletrequest) request;                          HttpServletResponse servletresponse = (httpservletresponse) response;                          HttpSession session = Servletrequest.getsession ();                          String path = Servletrequest.getrequesturi (); String empId = (string) Session.getattribute ("username");if(Path.indexof ("/login.jsp") >-1) {Chain.dofilter (ServletRequest, servletresponse);return; }if(EmpId = =NULL||"". Equals (EmpId)) {Servletresponse.sendredirect ("/login.jsp"); }Else{Chain.dofilter (request, response); }                     }@Override                       Public void Destroy() {//TODO auto-generated method stub}}

This file will go back to the session of the username, that is, the login user name, if the user name does not exist, is to jump to login.jsp, if present. (This function is to verify that the user is logged on.) ）

The next step is in Web. XML, which will

  <filter>    <filter-name>Loginauth</filter-name>    <filter-class>Loginfilter</filter-class>  </filter>  <filter-mapping>    <filter-name>Loginauth</filter-name>    <url-pattern>*.jsp</url-pattern>  </filter-mapping>

This code is changed to

  <filter>    <filter-name>Loginauth</filter-name>    <filter-class>Loginfilter</filter-class>  </filter>  <filter-mapping>    <filter-name>Loginauth</filter-name>    <url-pattern>*</url-pattern>  </filter-mapping>

which

<url-pattern>*</url-pattern>

This piece, is to verify all the files! However, after this writing, there is still a problem, that is, when you log in to complete, will jump to login.action. The login.action is also intercepted and then jumps to login.jsp!

Later, I looked at the next Loginfilter.class code and found this piece.

     if(path.indexOf("/login.jsp") > -1) {         chain.doFilter(servletRequest, servletResponse);        return;     }

When the page is login.jsp, it executes: Chain.dofilter (ServletRequest, servletresponse);

As long as the login.action is added to the judgment statement here, you can avoid this problem, the code is as follows:

     if(path.indexOf("/login.jsp") > -1||path.indexOf("/login.action") > -1) {         chain.doFilter(servletRequest, servletResponse);        return;     }

In this way, the problem ends, but the flaw is still, the file can still be uploaded, but if not logged in, in the access to the uploaded file, will be found to jump directly to the login.jsp.

Summary: Although this is not a good way to solve this problem, but using the access address redirected to the login.jsp, in a very simple way, to avoid the server power-up problem!

Strust Remote code execution vulnerability in relation to published cve-2013-2251 vulnerability