Finding XXE vulnerabilities in applications via code analysis
Welcome back to AppSec Simplified! Last time, we talked about the fascinating XXEs vulnerabilities and how they can affect your application. If you are not already familiar with XXEs, please read that post first!
This time, let’s hunt for XXEs for real! We will be analyzing the source code of an example application that is vulnerable to XXEs: the OWASP WebGoat. You can download the application here if you want to follow along with this exercise.
We’ll be using ShiftLeft’s NG-SAST scanner to hunt for XXEs. You can register for a free account here. After you register, you will be taken to a dashboard.
From there, go to “Add App” on the top right, and click on “use our CLI”. Follow the instructions to set up the command-line tool on your machine. We can now start analyzing any application for vulnerabilities!
Analyzing the app
Once you finish setting up the tool, execute this command in your terminal to analyze WebGoat. PATH_TO_WEBGOAT_JAR_FILE is the location of the WebGoat JAR file on your machine.
sl analyze --app WebGoat --java PATH_TO_WEBGOAT_JAR_FILE
Within a few minutes, you will see the results of the WebGoat scan uploaded to your dashboard.
Let’s dive into the findings! Click on the WebGoat project, and you should see findings sorted by vulnerability type on the bottom left. Click on the XXE label. This takes you to all the XXEs we found in WebGoat.
Let’s dive into one of these XXEs and try to exploit it! Click on one of the XXEs found. Here, I will be looking at “HTTP data to XML via commentStr in SimpleXXE.createNewComment”.
The NG-SAST tool tracks how data flows through applications to find patterns that indicate vulnerabilities. This window shows you where the vulnerability is located and how it happened, starting from the code that allowed the vulnerability to happen, to where the vulnerability actually happens. In code analysis speak, these locations are called the “source” and the “sink” of that vulnerability.
You can see that the attacker’s entry point is on line 66 in a file called SimpleXXE.java in a method named createNewComment. Then, the attacker’s malicious input gets passed into line 87 of Comments.java in a method named parseXml. Let’s take a look at these locations and investigate!
Diving into the source code
Open SimpleXXE.java here. You should see the method createNewCommentat line 66. What is this method doing?
From the method name, we can guess that this method is used to create a new comment on a webpage.
In line 13 of this code snippet, you can see that the code is taking user input (commentStr in the request body) and passing it into the method comments.parseXML().
In addition to the commentStr, parseXml accepts another parameter called secure. If the request session has the attribute applySecurity set, secure will be true. Otherwise, secure will be false. And from this snippet on line 113 of SimpleXXE.java, we see that applySecurity is only set when the path “/xxe/applysecurity” is used.
Let’s head over to Comments.java to see what parseXml is doing!
If the secure parameter is set to true, the XML parser properties ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA will be set to an empty string. These settings protect the parser from XXE attacks. But if secure is false, the XML parser will parse the input string directly without protection. This means that attackers can launch an XXE attack as long as the session attribute applySecurity is “null”!
Exploiting the XXE
Now that we understand where the vulnerability is, and how we can trigger it, let’s run the server and launch an XXE attack. You can launch the WebGoat server by running this command in your terminal.
java -jar PATH_TO_WEBGOAT_JAR_FILE
Access WebGoat by going to localhost:8080/WebGoat. Navigate to http://localhost:8080/WebGoat/start.mvc#lesson/XXE.lesson/3 to the page vulnerable to XXE. You should see a comment field. This is where createNewComment is getting its input string from.
When you submit a comment on this page, your browser will send a POST request to like this one to WebGoat.
Let’s intercept this request and insert our XXE payload! We will modify the XML file in the request to include a malicious DTD. The malicious DTD will point to the root of the local file system. Finally, we dereference the external entity in the body of the XML document.
You should now see the contents of the root directory of your local server displayed as a comment. Using this endpoint, you can read any file that the user who started WebGoat has access to. Try it out yourself! See which files you can read on your server, and imagine: these are the files an attacker can get access to if they find an XXE in your applications.
Hope you had fun with this tutorial! I sure had fun writing it. Static analysis is the most efficient way of uncovering most vulnerabilities in your applications. If you’re interested in learning more about ShiftLeft’s static analysis tool NG-SAST, visit us here.
Thanks for reading! What is the most challenging part of developing secure software for you? I’d love to know. Feel free to connect on Twitter @vickieli7.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Vickie Li. Read the original post at: https://blog.shiftleft.io/detecting-and-exploiting-xxes-appsec-simplified-8f9392aac908?source=rss----86a4f941c7da---4