S2-057 vulnerability in the original author's README: how to use automated tools find 5 RCE-vulnerability warning-the black bar safety net

!
2018 4 months, I to Apache Struts and the Struts security team reported a new remote code execution vulnerability–CVE-2018-11776（S2-057 in to do some configuration on a server running Struts, and can be accessed via the carefully constructed URL to trigger the vulnerability. This discovery is I the Apache Struts ongoing Safety study of part. In this article, I will describe my discovery of a vulnerability and how to exploit the previous vulnerability information to get the Struts internal working of the principle, create a package Struts-specific concept of the QL query. Run these queries will highlight the problematic code results. These works are hosted on GitHub, later we will also to this repository add more query statement and database to help the Struts and other projects of the security research.

Mapping the attack surface
Many security vulnerabilities are addressed from untrusted sources such as user input stream to a particular location of the sink of the data, and the data using an unsafe way-for example, the SQL query, deserialize, and some other interpreted languages, etc., QL can easily search for such vulnerabilities. You just need to describe the various source and sink, and then let the DataFlow library to accomplish these things. For a particular project, began to investigate such issues, a good method is to view the older version of the software known vulnerabilities. This can be in-depth understanding you want to find the source and sink points.
This vulnerability discovery process, I first see a RCE vulnerability S2-032（CVE-2016-3081）, S2-033（CVE-2016-3687 and S2-037（CVE-2016-4438-in. With Struts in many other RCE as RCE relates to the untrusted input is converted to OGNL expressions, allowing an attacker on the server to run arbitrary code. These three vulnerabilities are particularly interesting, not only do they let us on the Struts of the internal working mechanism have some understanding, and these three vulnerabilities actually is the same, also repair three back!
These three issues are the remote input through the variable methodName as a method of parameter passing caused OgnlUtil::getValue().
! [](/Article/UploadPic/2018-8/2018823153022696. png)
Here the proxy has ActionProxy type, it is an interface. Note that the definition of it, in addition to the method getMethod（）（in the above code is used to assign a value to the variable methodName addition, there are a variety of methods, such as getActionName（）and getNamespace（）。 These methods look like from the URL to return information, so I’ll just assume that all of these methods may return untrusted input. The rear of the article I will in depth research I for these the input from where the investigation.）
Now use QL to start on these untrusted source modeling:
! [](/Article/UploadPic/2018-8/2018823153023567. png)

Identify the OGNL sink point
Now that we have identified and described some of the non-trusted source, the next step is to sink the point of doing the same thing. As previously mentioned, many of Struts RCE relates to the remote input parsed for OGNL expressions. Struts has many function will eventually be their arguments as OGNL expressions; for we in this article the start of the three vulnerabilities, the use of a OgnlUtil :: getValue （）, but in the vulnerability S2-045（CVE-2017-5638, using TextParseUtil :: translateVariables（）。 We may be looking for execution of OGNL expressions commonly used function, I feel OgnlUtil :: compileAndExecute）and OgnlUtl :: compileAndExecuteMethod（）looks more games.
My description:
! [](/Article/UploadPic/2018-8/2018823153023415. png)

The first attempt
Now we have in QL are defined in the source and sink, we can stain the tracking query using these definitions. By defining DataFlow configured to use the DataFlow library:
! [](/Article/UploadPic/2018-8/2018823153023702. png)
Here is what I used before defined isActionProxySource and isOgnlSink it.
Note that I’m here to reload the isAdditionalFlowStep, so that it can allow me to contain the pollution data is propagated to the additional step. Such as allow me to the project-specific information into the flow configuration. For example, if I have by a network of communicating components, I may be in QL as described in those various network-side code is what allows the DataFlow library to track tainted data.
For this particular query, I added two additional process steps for the DataFlow library. First:
! [](/Article/UploadPic/2018-8/2018823153026173. png)
It includes tracking the standard Java library calls, string manipulation, etc. of the standard QL TaintTracking library steps. The second Add is an approximate value, allow me to by a field access track tainted data:
! [](/Article/UploadPic/2018-8/2018823153026186. png)
That is if the field is assigned a tainted value, then as long as the two expressions are the same type of method call, the field visit will also be regarded as pollution. See the following example:
! [](/Article/UploadPic/2018-8/2018823153026144. png)
Seen from above, the bar in this. field access may not always be contaminated. For example, if in the bar before not to call foo（）。 Therefore, we are not in the default DataFlow :: Configuration contained in this step, because you cannot guarantee that the data always in this manner the flow, however, for digging vulnerabilities, I think adding this very useful. In later posts I will share some of the similar to the other process steps, these steps for find the bug helpful, but for similar reasons, the default case is not included these steps.

The initial results and Refine the query
I’m on the latest version of the source code on the run a bit with QL, found that due to the S2-032, S2-033 S2-037 is still marked. These vulnerabilities obviously already been fixed, why still will be reported problem?

[1] [2] [3] next