Remote Code Execution with Spring OAuth Extension (CVE-2018-1260)
Recently, a new Remote Code Execution vulnerability in Spring OAuth extension was published by Pivotal.
The OAuth Protocol
OAuth is a protocol that supports authorization processes by enabling users to share their data and resources stored on one site with another site. For example, when you use the sign in with Facebook feature available in many modern websites, you utilize the OAuth protocol to allow the 3rd party application to access resources from your Facebook account. This is achieved by authenticating against Facebook’s authorization server and obtaining a token that will be used by the 3rd party application to access the resource servers of Facebook. The supplied token will be validated and if approved the resource servers will send the requested resource.
The Vulnerability
There are some conditions that must be met for the application that uses the Spring Framework OAuth extension to be vulnerable:
- It must act in the role of an authorization server.
- It must not configure any scopes. OAuth scopes provide a way for the authorization server to limit the amount of access that is granted to an access token. For example, scopes can be defined to limit the 3rd party application to read only for certain resources. Because the malicious payload will be sent to the application in the scope parameter if the application will encounter a scope name that doesn’t match the configured ones it will throw an exception and terminate the authorization process.
- It must use the Whitelabel OAuth approval page. Whitelabel pages in the Spring framework are pages that are present only for demonstration and should be replaced by the application developers. Another example of a Whitelabel page in the Spring framework is the default 404 page, that should be customized by the developer.
Figure 1: Spring OAuth Whitelabel approval page
The vulnerable code resides in the WhitelabelApprovalEndpoint class which handles the requests sent to the /oauth/authorize endpoint. It holds the template HTML code that will be rendered by the application and shown to the user when he approves the authorization. The template html is saved as a string in a private variable of the class.
Figure 2: Spring’s default OAuth approval HTML template.
The HTML template contains a few placeholders that will be replaced with the request values once the page is rendered by the application (e.g. %csrf% and %scopes% placeholders). The function that is responsible for replacing those placeholders is the createTemplate function.
Figure 3: createTemplate function used by the WhitelabelApprovalEndpoint class to replace the placeholders with the session values
The first if statement in the createTemplate function checks if the model object or the request object containing a key or attribute named “scopes”. if it finds such key in the model object or attribute in the request object it will call the createScopes function, which is responsible for building a <ul> (unordered list) HTML element which will hold the scopes available in the model object or the request object. it is important to note that if the model object contains the key “scopes” the value that will be shown to the user in the Spring’s OAuth Whitelabel page will be taken from it and not from the user’s request thus making the application not vulnerable (Condition number 2 mentioned above for the application to be vulnerable).
Figure 4: “createScopes” function used to create a <ul> HTML element containing the provided scopes.
After replacing the values in the Whitelabel HTML template, Spring returns a “ModelAndView” class instance and instantiates a SpelView class instance which stands for Spring Expression Language View and passes the parsed HTML template string to the constructor of the SpelView class.
Figure 5: ModelAndView class instance returned by Spring framework and SpelView is used as the View instance.
The SpelView class implements the View Java interface which declares the render method and requires the class that implements it to give its own implementation to it.
Another important point to note about the SpelView class is that it holds an instance of the PlaceHolderResolver interface which requires the class that implements it to implement the resolvePlaceholder method.
Figure 6: SpelView class declaration and constructor implementation.
During it’s render process the SpelView class attempts to extract values that are located inside “${}” template expressions and evaluate them by parsing them as Spring Expression Language (SpEL) expression instance.
Figure 7: SpelView render method implementation.
Now let’s recap, if the Spring application is being used as the OAuth Authorization Server, and the application didn’t define any OAuth scopes, the user can supply a Spring Expression Language Expression inside a “${}” expression template, that will be stored in the scope parameter and will be parsed by the SpelView class. As we saw in previous vulnerabilities in the Spring framework, evaluation of a user-controlled Spring Expressions by using the “StandardEvaluationContext” class may lead to arbitrary code execution.
Figure 8: Malicious user-controlled input parsed as a Spring Expression by the application.
Figure 9: The result of parsing the user provided Spring Expression.
Mitigating the vulnerability with BIG-IP ASM
BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Also, operating system command execution signatures will detect the attempt to execute operating system commands as the payload for the exploit.
Figure 10: Exploit blocked with attack signature 200003437
Figure 11: Exploit blocked with attack signature 200003073
