Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
Object Graph Notation Language (OGNL) is a popular, Java-based, expression language used in popular frameworks and applications, such as Apache Struts and Atlassian Confluence. Learn more about bypassing certain OGNL injection protection mechanisms including those used by Struts and Atlassian Confluence, as well as different approaches to analyzing this form of protection so you can harden similar systems.
Object Graph Notation Language (OGNL) is a popular, Java-based, expression language used in popular frameworks and applications, such as Apache Struts and Atlassian Confluence. In the past, OGNL injections led to some serious remote code execution (RCE) vulnerabilities, such as the Equifax breach, and over the years, protection mechanisms and mitigations against OGNL injections have been developed and improved to limit the impact of these vulnerabilities.
In this blog post, I will describe how I was able to bypass certain OGNL injection protection mechanisms, including the one used by Struts and the one used by Atlassian Confluence. The purpose of this blog post is to share different approaches used when analyzing this kind of protection so they can be used to harden similar systems.
No new OGNL injections are being reported as part of this research, and unless future OGNL injections are found on the affected frameworks/applications, or known double evaluations affect an existing Struts application, this research does not constitute any immediate risk for Apache Struts or Atlassian Confluence.
I have a past history of bugs found in Struts framework, including CVE-2016-3087, CVE-2016-4436, CVE-2017-5638, CVE-2018-1327, CVE-2020-17530 and even some double OGNL injections through both Velocity and FreeMarker tags that remain unfixed to this date. Therefore, I have become familiar with the OGNL sandbox and different escapes over the years and I am still interested in any OGNL-related vulnerabilities that may appear. That was the case with Atlassian Confluence, CVE-2021-26084 and CVE-2022-26134, where the former is an instance of the unresolved double evaluation via Velocity tags mentioned in my 2020 advisory.
My friend, Man Yue Mo, wrote a great article describing how the OGNL mitigations have been evolving over the years and there are few other posts that also describe in detail how these mitigations have been improving.
In 2020, disabling the sandbox became harder, so I decided to change the approach completely. I introduced new ways to get RCE by circumventing the sandbox, and using the application server’s Instance Manager to instantiate arbitrary objects that I could use to achieve RCE. This research was presented at our Black Hat 2020 talk, Scribbling outside of template security. We reported this issue to the Apache Struts team, and they fixed the issue by using a block list. However, in 2021, Chris McCown published a new bypass technique which leverages the OGNL’s AST maps and the Apache Commons Collections BeanMap class.
That was it–at that point I had enough of OGNL and stopped looking into it until two events happened in the same week:
Okay, OGNL, my old friend. Here we go again.
isSafeExpression protectionWhen the CVE-2022-26134 was released there was an initial understanding that the OGNL injection could not lead to direct RCE in the latest version 7.18.0 since the isSafeExpression method was not possible to bypass for that version
Harsh Jaiswal (@rootxharsh) and Rahul Maini (@iamnoooob) took a different approach and looked for a gadget chain in the allowed classes list that could allow them to create an admin account.
Soon after, @MCKSysAr found a nice and simple bypass:
Class property instead of class one.
MCKSysAr’s bypass was soon addressed by blocking the access to the Class and ClassLoader properties. I had some other ideas, so I decided to take a look at the isSafeExpression implementation.
The first interesting thing I learned was that this method was actually parsing the OGNL expression into its AST form in order to analyze what it does and decide whether it should be allowed to be executed or not. Bye-bye to regexp-based bypasses.
Then the main logic to inspect the parsed tree was the following:
containsUnsafeExpression() on each node of the tree.ASTStaticField, ASTCtor or ASTAssign then the expression is deemed to be unsafe. This will prevent payloads using the following vectors:
ASTStaticMethod check that the class the method belongs to is in an allow list containing:
net.sf.hibernate.proxy.HibernateProxyjava.lang.reflect.Proxynet.java.ao.EntityProxyAccessornet.java.ao.RawEntitynet.sf.cglib.proxy.Factoryjava.io.ObjectInputValidationnet.java.ao.Entitycom.atlassian.confluence.util.GeneralUtiljava.io.SerializableASTProperty checks block list containing (after the initial fix):
classClassclassLoaderClassLoaderunsafePackageNames block list (too long to list here).ASTMethod, check if we are calling getClass or getClassLoader.ASTVarRef, check if the variable name is in UNSAFE_VARIABLE_NAMES block list:
#application#parameters#request#session#_memberAccess#context#attrASTConst (eg: a string literal), call isSafeExpressionInternal which will check the string against a block list (for example, harmful class names) and, in addition, it will parse the string literal as an OGNL expression and apply the containsUnsafeExpression() recursive checks on it.This is a pretty comprehensive control since it parses the AST recursively and makes sure that any AST nodes considered harmful are either rejected or inspected further.
MCKSysAr bypass was based on two things: A) Class and ClassLoader properties were not accounted for when inspecting ASTProperty nodes; and B) ”java.lang.” + “Runtime” was parsed as an ASTAdd node with two ASTConst children. None of them matched any of the known harmful strings and when parsed as an OGNL expression, none of them were valid expressions so they were not parsed further. A) Was fixed quickly by disallowing access to Class and ClassLoader properties, but B) was not fixed since it was considered as a security in-depth control (it’s impossible to analyze all variants in which a malicious string could be written).
With that in mind I took a look at the list of the OGNL AST nodes to see if there was anything interesting that was not accounted for in the isSafeExpression() method.
ASTEvalThe first one that got my attention was ASTEval. It looked very interesting and it was not accounted for by the containsUnsafeExpression() method.
ASTEval are nodes in the form of (expr)(root) and they will parse the expr string into a new AST and evaluate it with root as its root node. This will allow us to provide an OGNL expression in the form of a string (ASTConst) and evaluate it! We know that ASTConst nodes are parsed as OGNL expressions and verified to not be harmful. However, we already saw that if we split the string literal in multiple parts, only the individual parts will be checked and not the result of the concatenation. For example, for the payload below #application will never get checked, only # and application which are deemed to be safe:
As you can see in the resulting tree, there are no hints of any ASTVarRef node and therefore access to #application is granted.
ASTEvalThere are multiple ways to craft a payload levering this vector. For example, we could get arbitrary RCE with echoed response:
ASTMap, ASTChain and ASTSequenceI was already familiar with ASTMaps from reading Mc0wn’s great article. In a nutshell, OGNL allows developers to instantiate any java.util.Map implementation by using the @<class_name>@{} syntax.
Using this technique, we were able to use a BeanMap (a map wrapping a Java bean and exposing its getters and setters as map entries) to bypass the getClass limitation by rewriting the payload as:
BeanMap map = @org.apache.commons.beanutils.BeanMap@{};
map.setBean(“”)
map.get(“class”).forName(”javax.script.ScriptEngineManager”).newInstance().getEngineByName(“js”).eval(payload)
BeanMap map = @org.apache.commons.beanutils.BeanMap@{};
map.setBean(“”)
map.get(“class”).forName(”javax.script.ScriptEngineManager”).newInstance().getEngineByName(“js”).eval(payload)
This payload avoids calling the BeanMap constructor explicitly and, therefore, gets rid of the ASTCtor limitation. In addition, it allows us to call Object.getClass() implicitly by accessing the class item. However, we still have another problem: we need to be able to assign the map to a variable (map) so we can call the setBean() method on it and later call the get() method on the same map. Since ASTAssign was blocked, assignments were not an option. Fortunately, looking through the list of AST nodes, two more nodes got my attention: ASTChain and ASTSequence.
ASTChain allows us to pass the result of one evaluation as the root node of the next evaluation. For example: (one).(two) will evaluate one and use its result as the root for the evaluation of two.ASTSequence allows us to run several evaluations on the same root object in sequence. For example: one, two will evaluate one and then two using the same root node.The idea was to bypass ASTAssign constraint by combining ASTChain and ASTSequence together
We can set the map returned by the ASTMap expression as the root for a sequence of expressions so all of them will have the map as its root object:
In our case, expression1 is the call to setBean() and expression2 is the call to get().
Taking that into account and splitting literal strings into multiple parts to bypass the block list we got the following payload:
The final AST tree bypassing all isSafeExpression checks is:
There was a final problem to solve. The OGNL injection sink was translateVariable() which resolves OGNL expressions wrapped in ${expressions} delimiters. Therefore, our payload was not allowed to contain any curly brackets. Fortunately, for us, OGNL will replace unicode escapes for us so we were able to use the final payload:
I submitted these bypasses to Atlassian through its bug bounty program and, even though I was not reporting any new OGNL injections but a bypass of its sandbox, they were kind enough to award me with a $3,600 bounty!
As mentioned before, a friend found what he thought was a Server-Side Template Injection (SSTI) (%{7*7} => 49) but it turned out to be an OGNL injection. Since this happened as part of a bug bounty program, I didn’t have access to the source code. I can’t be sure if the developers were passing untrusted data to an OGNL sink (for example, [ActionSupport.getText()](https://struts.apache.org/maven/struts2-core/apidocs/com/opensymphony/xwork2/ActionSupport.html#getText-java.lang.String-)), or if it was some of the unfixed double evaluations issues (still working at the time of writing). Anyhow, the application seemed to be using the latest Struts version and known payloads were not working. I decided to take a deeper look.
When I listed what objects were available I was surprised to find that many of the usual objects in the Struts OGNL context, such as the value stack, were not there, and some others I haven’t seen before were available. One of such objects was #request[‘.freemarker.TemplateModel’]. This object turned out to be an instance of org.apache.struts2.views.freemarker.ScopesHashModel containing a variety of new objects. One of them (stored under the ognl key) gave me access to an org.apache.struts2.views.jsp.ui.OgnlTool instance. Looking at the code for this class I quickly spotted that it was calling Ognl.getValue(). This class is not part of Struts, but the OGNL library and, therefore, the Struts sandbox (member access policy) was not enabled! In order to exploit it I used the following payload:
That was enough to get the issue accepted as a remote code execution in the bounty program. However, despite having achieved RCE, there were a few unsolved questions:
.freemarker.TemplateModel object available?Attackers are limited to the objects they are able to access. Normally, OGNL injections take place before the action invocation completes and the action’s Result is rendered.
https://struts.apache.org/core-developers/attachments/Struts2-Architecture.png
When grepping the Struts’s source code for .freemarker.TemplateModel, I found out that there are plenty of new objects added to the request scope when preparing the action’s Result in order to share them with the view layer (JSP, FreeMarker or Velocity) and .freemarker.TemplateModel was one of them. However, those objects are only added after the ActionInvocation has been invoked. This implies that if I find .freemarker.TemplateModel on the request scope, my injection was evaluated after the action invocation finished building the action’s Result object and, therefore, my injection probably did not take place as part of the Struts code but as a double evaluation in the FreeMarker template.
These new objects will offer new ways to get remote code execution, but only if you are lucky to get your injection evaluated after the action’s Result has been built. Or not? 🤔
It turned out that the ongoing ActionInvocation object can be accessed through the OGNL context and, therefore, we can use it to force the building of the Result object in advance. Calling the Results doExecute() method will trigger the population of the so-called template model. For example, for Freemarker, ActionInvocation.createResult() will create a FreemarkerResult instance. Calling its doExecute() method will, in turn, call its [createModel()](https://github.com/apache/struts/blob/266d2d4ed526edbb8e8035df94e94a1007d7c360/core/src/main/java/org/apache/struts2/views/freemarker/FreemarkerResult.java#L273) method that will populate the template model.
Executing the above payload will populate the request context with new objects. However, that requires us to know the result code and the template’s path. Fortunately, we can also invoke the ActionInvocation.invoke() method that will take care of everything for us!
The line above will result in the template model being populated and stored in the request, and context scopes regardless of where your injection takes place.
After the invocation, the request scope and value stack will be populated with additional objects. These objects vary depending on the view layer used. What follows is a list of the most interesting ones (skipping most of them which do not lead to RCE):
For Freemarker:
.freemarker.Request (freemarker.ext.servlet.HttpRequestHashModel).freemarker.TemplateModel (org.apache.struts2.views.freemarker.ScopesHashModel)
__FreeMarkerServlet.Application__ (freemarker.ext.servlet.ServletContextHashModel)JspTaglibs (freemarker.ext.jsp.TaglibFactory).freemarker.RequestParameters (freemarker.ext.servlet.HttpRequestParametersHashModel).freemarker.Request (freemarker.ext.servlet.HttpRequestHashModel).freemarker.Application (freemarker.ext.servlet.ServletContextHashModel).freemarker.JspTaglibs (freemarker.ext.jsp.TaglibFactory)ognl (org.apache.struts2.views.jsp.ui.OgnlTool)stack (com.opensymphony.xwork2.ognl.OgnlValueStack)struts (org.apache.struts2.util.StrutsUtil)For JSPs:
com.opensymphony.xwork2.dispatcher.PageContext (PageContextImpl)For Velocity:
.KEY_velocity.struts2.context -> (StrutsVelocityContext)
ognl (org.apache.struts2.views.jsp.ui.OgnlTool)struts (org.apache.struts2.views.velocity.result.VelocityStrutsUtils)And now let’s have some fun with these new objects! In the following section I will explain how I was able to leverage some of these objects to get remote code execution.
There may be different ways to get an instance of a FreeMarker’s ObjectWrapper, even if the application is not using FreeMarker as its view layer because Struts uses it internally for rendering JSP tags. A few of them are listed below:
freemarker.ext.jsp.TaglibFactory.getObjectWrapper(). Even though Struts’ sandbox forbids access to freemarker.ext.jsp package, we can still access it using a BeanMap:freemarker.ext.servlet.HttpRequestHashModel.getObjectWrapper():freemarker.core.Configurable.getObjectWrapper(). We need to use the BeanMap trick to access it since freemarker.core is also blocklisted:Now for the fun part, what can we do with an ObjectWrapper? There are three interesting methods we can leverage to get RCE:
newInstance(class, args)
This method will allow us to instantiate an arbitrary type. Arguments must be wrapped, but the return value is not. For example, we can trigger a JNDI injection lookup:
Or, if Spring libs are available, we can get RCE by supplying a malicious XML config for FileSystemXmlApplicationContext constructor:
**getStaticModels()**
This method allows us to get static fields from arbitrary types. The return object is wrapped in a FreeMarker’s TemplateModel so we need to unwrap it. An example payload levering Text4Shell:
**wrapAsAPI()**
This method allows us to wrap any object with a freemarker.ext.beans.BeanModel giving us indirect access to its getters and setters methods. Struts’ sandbox will not have visibility on these calls and therefore they can be used to call any blocklisted method.
BeanModel.get('field_name') returns a TemplateModel wrapping the object.BeanModel.get('method_name') returns either a SimpleMethodModel or OverloadedMethodsModel wrapping the method.We can, therefore, call any blocklisted method with:
This call will return an instance of TemplateMethodModelEx. Its [exec()](https://freemarker.apache.org/docs/api/freemarker/template/TemplateMethodModelEx.html#exec-java.util.List-) method is defined in the freemarker.template namespace and, therefore, trying to invoke this method will get blocked by the Struts sandbox. However, TemplateMethodModelEx is an interface and what we will really get is an instance of either freemarker.ext.beans.SimpleMethodModel or freemarker.ext.beans.OverloadedMethodsModel. Since the exec() methods on both of them are defined on the freemarker.ext.beans namespace, which is not blocklisted, their invocation will succeed. As we saw before, arguments need to be wrapped. As an example we can call the File.createTempFile(“PREFIX”, “SUFFIX”) using the following payload:
We can achieve the same by calling the getAPI() on any freemarker.template.TemplateModelWithAPISupport instance. Many of the FreeMarker exposed objects inherit from this interface and will allow us to wrap them with a BeanModel. For example, to list all the keys in the Struts Value Stack we can use:
Note that com.opensymphony.xwork2.util.OgnlContext.keySet() would be blocked since it belongs to the com.opensymphony.xwork2.util namespace, but in this case, Struts’ sandbox will only see calls to TemplateHashModel.get() and TemplateModelWithAPISupport.getAPI() which are both allowed.
The last payload will give us a complete list of all available objects in the Value Stack, many of which could be used for further attacks. Lets see a more interesting example by reading an arbitrary file using BeanModels:
Or listing the contents of a directory:
The org.apache.struts2.views.jsp.ui.OgnlTool class was calling Ognl.getValue() with no OgnlContext and even though the Ognl library will take care of creating a default one, it will not include all the additional security checks added by the Struts framework and is easily bypassable:
package org.apache.struts2.views.jsp.ui;
import ognl.Ognl;
import ognl.OgnlException;
import com.opensymphony.xwork2.inject.Inject;
public class OgnlTool {
private OgnlUtil ognlUtil;
public OgnlTool() { }
@Inject
public void setOgnlUtil(OgnlUtil ognlUtil) {
this.ognlUtil = ognlUtil;
}
public Object findValue(String expr, Object context) {
try {
return Ognl.getValue(ognlUtil.compile(expr), context);
} catch (OgnlException e) {
return null;
}
}
}
package org.apache.struts2.views.jsp.ui;
import ognl.Ognl;
import ognl.OgnlException;
import com.opensymphony.xwork2.inject.Inject;
public class OgnlTool {
private OgnlUtil ognlUtil;
public OgnlTool() { }
@Inject
public void setOgnlUtil(OgnlUtil ognlUtil) {
this.ognlUtil = ognlUtil;
}
public Object findValue(String expr, Object context) {
try {
return Ognl.getValue(ognlUtil.compile(expr), context);
} catch (OgnlException e) {
return null;
}
}
}
We can get an instance of OgnlTool from both FreeMarker and Velocity post-invocation contexts:
Or
For FreeMarker’s case, it will come up wrapped with a Template model but we can just unwrap it and use it to get RCE:
Or, even simpler:
OgnlTool was inadvertently fixed when Struts 6.0.0 was released by upgrading to OGNL 3.2.2 which always requires a MemberAccess. But the latest Struts 2 version (2.5.30) is still vulnerable to this payload.
Another object that can be accessed in the post-invocation context is an instance of org.apache.struts2.util.StrutsUtil. There are plenty of interesting methods in here:
public String include(Object aName) can be used to read arbitrary resources
<struts_utils>.include("/WEB-INF/web.xml")public Object bean(Object aName) can be used to instantiate arbitrary types:
<struts_utils>.bean("javax.script.ScriptEngineManager")public List makeSelectList(String selectedList, String list, String listKey, String listValue)
listKey and listValue are evaluated with OgnlTool and therefore in an unsandboxed context<struts_utils>.makeSelectList("#this","{'foo'}","(new freemarker.template.utility.Execute()).exec({'touch /tmp/bbbb'})","")On applications using Velocity as its view layer, this object will be an instance of VelocityStrutsUtil which extends StrutsUtils and provides an additional vector:
public String evaluate(String expression) will allow us to evaluate a string containing a velocity template:The last vector that I wanted to share is one that I found a few years ago and that I was not able to exploit–although I was pretty sure that there had to be a way. New post-invocation discovered objects finally made this possible!
If you have inspected the Struts Servlet context (#application) in the past you probably saw an item with key org.apache.jasper.runtime.JspApplicationContextImpl which returned an instance of org.apache.jasper.runtime.JspApplicationContextImpl. This class contains a method called getExpressionFactory() that returns an Expression Factory that will expose a createValueExpression() method. This looks like a perfect place to create an EL expression and evaluate it. The problem was that [createValueExpression](https://docs.oracle.com/javaee/7/api/javax/el/ExpressionFactory.html#createValueExpression-javax.el.ELContext-java.lang.String-java.lang.Class-) requires an instance of ELContext and we had none.
Fortunately, our post-invocation technique brought a new object into play. When using JSPs as the view layer, #request['com.opensymphony.xwork2.dispatcher.PageContext'] will return an uninitialized org.apache.jasper.runtime.PageContextImpl instance that we can use to create an ELContext and evaluate arbitrary EL expressions:
The avid readers may be wondering why Struts stores the PageContext in the request. Well, turns out, it does not, but we can access it through chained contexts.
When accessing #attr (AttributeMap), we can indirectly look into multiple scopes such as the Page, Request, Session and Application (Servlet). But there is more, org.apache.struts2.dispatcher.StrutsRequestWrapper.getAttribute() will look for the attribute in the ServletRequest, if it can’t find it there, it will search the value stack! So, we can effectively access the value stack through the #request or #attr variables.
In this case, the PageContext was not stored in the request scope, but in the Value stack, and we are able to access it through chained context searches.
We can even run arbitrary OGNL expressions as long as they don’t contain any hashes (#), for example, #request["@java.util.HashMap@class"] will return the HashMap class.
You may already be familiar with McOwn’s technique. He realized that it was possible to use OGNL Map notation to instantiate an org.apache.commons.collections.BeanMap by using the #@org.apache.commons.collections.BeanMap@{ } syntax, and then it was possible to wrap any Java object on this map and access any getters and setters as map properties. His payload was based on the org.apache.tomcat.InstanceManager payload we introduced at Black Hat 2020 and looked like:
The payload was basically disabling the OGNL sandbox and then accessing otherwise blocked classes such as InstanceManager. There is a simpler way to abuse BeanMaps that do not require to disable the sandbox and that is using reflection:
This payload also works in Struts 6 if the BeanClass is available in the classpath (either from Apache Commons Collections or Apache Commons BeanUtils), but you need to specify the FQN (Fully Qualified Name) name for Runtime: @java.lang.Runtime@class.
These bypasses were first reported to the Struts and OGNL security teams on June 9, 2022.
On October 7, 2022, the security team replied to us and stated that improving the block lists was not a sustainable solution, and, therefore, they decided to stop doing it. They highlighted that a Java Security Manager can be configured to protect every OGNL evaluation from these attacks and we highly recommend doing so if you are running a Struts application. However, bear in mind that the Security Manager is deprecated and will soon get removed from the JDK.
At this point, you will have probably realized that sandboxing an expression language, such as OGNL, is a really difficult task, and may require maintaining a list of blocked classes and OGNL features even though that is not an optimal approach. In this blog post, we have reviewed a few ways in which these sandboxes can be bypassed. Although they are specific to OGNL, hopefully you have learned to explore sandbox controls–and one or two new tricks–that may apply to other sandboxes. In total, we were able to raise $5,600, which we donated to UNHCR to help provide refuge for Ukrainians seeking protection from the war.