The web project was rushed and no security assessment was done. Can you read the /etc/passwd file?
๐ฏ Challenge Files & Infrastructure
Provided Files
1
Files:None
๐ Initial Analysis
First Steps
Initially, the website appears as follows:
Site Presentation
The first thing I did was inspect the page source, finding two suspicious js scripts: detailsCheck.js and xmlDetailsCheckPayload.js:
Page Source
Upon analyzing them, I found these two functions:
detailsCheck SourcexmlDetailsCheck Source
When the function checkDetails() is called, it appears that the payload(data) function is invoked, returning an XML, which is vulnerable to an XXE Injection since no sanitization is applied. This happens in the page’s forms when clicking the Details button:
Form
A POST request is made to /data, which will print the details associated with the input having name=ID and value=1 in XML, as shown here:
XML
Therefore, we can modify this value or exploit the /data route to send malicious XML to be executed in the page. Once the vulnerability is understood, we can move on to exploitation.
๐ฌ Vulnerability Analysis
Potential Vulnerabilities
XXE Injection (XML External Entity Injection)
๐ฏ Solution Path
Exploitation Steps
Initial setup
There are several ways to get to the flag, and I believe I used one of the simplest. Instead of directly using the /data route (which I did in the exploit), I manually modified the <input> field by exploiting the form already present in the HTML. Let’s see how.
Exploitation
The goal was to read /etc/passwd, and this can be done with a standard injection similar to:
1
2
3
4
5
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE data [<!ENTITY xxe SYSTEM "file://etc/passwd">]>
<data>ย <ID>&xxe;</ID></data>
This payload will replace &xxe with the file /etc/passwd, and if we can see the result, we will obviously be able to view the content of the file. We can think of xxe as a function that executes SYSTEM 'file://etc/passwd', thus fetching the contents of the /etc/passwd file. In the field <data><ID>&xxe;</ID></data>, itโs as if we are calling this function, inserting its output into that field. I use ID because in the form <input>, name=ID is the key extracted in the payload() function, which generates the XML that will then be inserted into the page.Even though we can directly modify the <input> field in the HTML for this type of injection, I used the form that does the POST to /data to set any name we want. I acted precisely this way, modifying the <input> tag as we can see, passing the value &xxe;:
Replace
I then rewrote the payload() function via the console, inserting the XML to perform the injection. Once the function was rewritten and I clicked the Details button on the first form, I triggered the injection and thus obtained the flag.
Flag capture
Manual Flag
๐ ๏ธ Exploitation Process
Approach
The exploit follows the steps described manually earlier, but instead of overwriting the function, it uses the /data route to send the XML payload containing the injection. Once the response is received, it extracts the flag with a regex and prints it.
