XML External Entity Vulnerability To SSH Shell | TryHackMe

Introduction

In this walkthrough, we covered XXE or XML external entity vulnerability and how to find it in a web application. This video used the lab material from TryHackMe XXE room.

An XML External Entity (XXE) attack is a vulnerability that abuses features of XML parsers/data. It often allows an attacker to interact with any backend or external systems that the application itself can access and can allow the attacker to read the file on that system. They can also cause Denial of Service (DoS) attack or could use XXE to perform Server-Side Request Forgery (SSRF) inducing the web application to make requests to other applications. XXE may even enable port scanning and lead to remote code execution.

There are two types of XXE attacks: in-band and out-of-band (OOB-XXE).
1) An in-band XXE attack is the one in which the attacker can receive an immediate response to the XXE payload.

2) out-of-band XXE attacks (also called blind XXE), there is no immediate response from the web application and attacker has to reflect the output of their XXE payload to some other file or their own server.

Skills Learned

• XML
• XXE

Getting Started with XML and DTDs

Before jumping into the exploitation, I took some time to brush up on my XML knowledge. I learned that XML, which stands for Extensible Markup Language, is a case-sensitive language used to store and transport data. While not always required, an XML document often starts with a prolog that defines the XML version and encoding.

A key concept in understanding XXE is the Document Type Definition (DTD). A DTD file, which has a .dtd extension, is used to define the structure and legal elements of an XML document. It’s like a rulebook that the XML document has to follow. Within a DTD, you can define new elements, specify the root element, and, most importantly for our purposes, define new entities. It’s this ability to define custom entities that opens the door for XXE attacks.

From Theory to Practice: The Exploit

With the theory out of the way, it was time to get my hands dirty. I deployed the machine on TryHackMe and was greeted with a simple web application that had an input box. This was my playground.

My first step was to test a basic XXE payload. I crafted an XML document that defined an entity named “name” with the value “feast”. When I submitted this payload, the application responded with “falcon feast”, which confirmed that it was processing my XML and I could inject my own entities.

Now for the real fun. I modified my payload to read the /etc/passwd file from the server. This is a classic first step in reconnaissance, as it lists all the users on the system. The payload looked something like this:

XML

<?xml version="1.0"?>
<!DOCTYPE root [<!ENTITY read SYSTEM "file:///etc/passwd"> ]>
<root>&read;</root>

Success! The application displayed the contents of the /etc/passwd file, and I could see a user named “falcon“.

With a username in hand, my next target was the user’s SSH private key. These are usually stored in the /home/user/.ssh/id_rsa file. I updated my payload to point to this file, and just like that, the private key was displayed on my screen.

Gaining Access and Post-Exploitation

Now that I had the private key, I was ready to log in. I copied the key and saved it to a file on my own machine. It’s crucial to set the correct permissions for the private key file, or SSH will reject it. After that, I used the key to SSH into the machine as the falcon user. I was in!

Once inside, I did a quick check of my privileges to see what I could do. While this particular challenge didn’t require it, the next logical step would be to look for ways to escalate my privileges to root.

Technical Commands Used

Here are the technical commands I used on the terminal during this process:

• nano id_rsa
  • I used this command to open the nano text editor and create a new file named id_rsa. I then pasted the SSH private key I had obtained into this file.
• chmod 600 id_rsa
  • This is a critical command that changes the permissions of the id_rsa file to 600. This means that only the owner of the file can read and write to it, which is a security requirement for SSH keys.
• ssh -i id_rsa falcon@<IP_ADDRESS>
  • This command initiates an SSH connection to the target machine. The -i flag specifies the identity file (our private key) to use for authentication, and falcon@<IP_ADDRESS> specifies the username and the IP address of the server.
• id
  • A simple command to display the current user’s ID and group information. I ran this to confirm I was logged in as falcon.
• sudo -l
  • This command lists the commands that the current user is allowed to run with sudo (superuser) privileges. It’s a great way to start looking for privilege escalation vectors.

Room Answers

Video Walk-Through