While we frequently discuss SQL injection and command injection, OGNL injection receives a lot less attention.
What is OGNL?
OGNL stands for “Object Graph Navigation Language,” which is written through Java and is used in the Apache Struts2 framework for web applications. Struts2 was originally created to build “enterprise ready web applications” and was known for being able to handle multiple moving parts of a web application through a single framework.
Apache did this by making a model, view, and controller (MVC) architecture that handles OGNL expressions and other java code. Typically, OGNL expressions handle user input data–just as with other injection attacks, if user input is not sanitized injection can occur.
You may think that Struts2 was updated or changed so that this risk would be mitigated, but it has not been. Even the Apache Struts Security webpage provides ways to manually lock down the framework but also begins the page with “The Apache Struts 2 doesn’t provide any security mechanism – it is just a pure web framework.”
When there is an OGNL injection vulnerability present, there are a few things an attacker can do. OGNL expressions can change system variables as well as execute commands as the user running the web application, thus resulting in remote code execution.
How to Perform OGNL Injection
A website for learning areas in cyber security such as PenTesting, Blue/Red/Purple Teaming called TryHackMe.com has a room we can use to stand up a web application vulnerable to OGNL injection. The room is called “Atlassian, CVE-2022-26134.”
We begin by identifying services running on the machine using nmap.
In this case, the available ports are 22, 8090, and 8091. We know that 8090 is hosting a web service because of the fingerprinting nmap performed for us. When we navigate to the webpage, this is where we land.
Right away we can see what is running and its version number, Atlassian Confluence 7.3.5. After some research on the service, we can find a few vulnerabilities, specifically CVE-2022-26134.
Now that we know a vulnerability, we can check online for exploit code someone may have written. Places such as Exploit-DB and GitHub tend to work well. In this case we found an exploit for CVE-2022-26134 through GitHub.
In this exploit’s description it says it will first check to see if the web application is vulnerable by using a POC payload. If it is vulnerable, it will execute a RCE payload to give us a reverse shell on the vulnerable machine.
When the exploit code is run it injects OGNL expressions into the URL of the web application—though note that before any exploits were performed that there were already OGNL expressions in the URL, which could be another identifier of a possible OGNLi vulnerability.
After using the “cat” command we can dig deeper into what the exploit code is doing.
In this portion of the exploit code, we can see a python definition being made called PoC with the parameters of a string needing to be input and a Boolean to be output. In this set of code, we can see the OGNL payload being generated to check if the web application is vulnerable. The payload is then injected to the end of the URL of the landing page; if the response returns the desired information, then it is proof that OGNLi is possible on the web application.
Here is where the “poc” python definition is run. If the desired information is returned it will output that the application is vulnerable and will start to generate the RCE payload. If not, then the application is not vulnerable and the exploit stops.
This is where the “exp” python definition is created and is also where the OGNL RCE payload is generated.
If the application is vulnerable, then run the exploit code. When the exploit code is run it sits and listens for either “q” to terminate the shell or for other console commands being sent to the vulnerable machine.
How to Mitigate OGNL Injection Attacks
There are a few methods of mitigating the risk of an OGNL injection attack.
There are web application firewalls (WAPs) that can detect for OGNLi, through methods such as looking through the web applications’ logs.
Another way is to sanitize user input so that OGNL expressions inputted are not executed.
Finally, if you are planning on standing up a web application, try to avoid using applications with known security flaws such as OGNLi or avoid the Java Struts2 framework entirely.
For more options on how to secure your web application using Apache Struts2, see the Apache security page. Another good resource for further reading is a list
For additional information on OGNL injection, please see the following, a list of CVEs involving OGNL injection dating back approximately fifteen years: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=OGNL.
This post was written by Noah Godfrey.
