8 - Limited File Uploads

# Intro - While file upload forms with weak filters can be exploited to upload arbitrary files, some upload forms have secure filters that may not be exploitable with the techniques we discussed - However, even if we are dealing with a limited (i.e., non-arbitrary) file upload form, which only allows us to upload specific file types, we may still be able to perform some attacks on the web application. - Certain file types, like `SVG`, `HTML`, `XML`, and even some image and document files, may allow us to introduce new vulnerabilities to the web application by uploading malicious versions of these files - This is why fuzzing allowed file extensions is an important exercise for any file upload attack # XSS - Many file types may allow us to introduce a `stored XSS` vuln to the web app by uploading maliciously crafted versions of them - The most basic example is when a web app allows us to upload `HTML` files - Even though HTML files won't allow us to execute code (e.g., PHP), it would still be possible to implement JavaScript code within them to carry an XSS or CSRF attack on whoever visits the uploaded HTML page - Another example of XSS attacks is web app that display an image's metadata after its upload - For such web apps, we can include an XSS payload in one of the Metadata parameters that accept raw text, like the `Comment` or `Artist` parameters - Below is an example where a stored XSS vuln is added to a comment parameter of an image ```bash exiftool -Comment=' "><img src=1 onerror=alert(window.origin)>' HTB.jpg exiftool HTB.jpg #shows full metadata for image ``` - XSS attacks can also be carried with `SVG` images, along with several other attacks - SVG images are XML-based, and they describe 2D vector graphics, which the browser renders into an image - As such , we can modify their XML data to include an XSS payload like below ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1" height="1"> <rect x="1" y="1" width="1" height="1" fill="green" stroke="black" /> <script type="text/javascript">alert(window.origin);</script> </svg> ``` - Once we upload the image to the web app, the XSS payload will be triggered whenever the image is displayed. # XXE - Similar attacks can be carried to lead to XXE exploitation - With SVG images, we can also include malicious XML data to leak the source code of the web application, and other internal documents within the server - The following example can be used for an SVG image that leaks the content of (`/etc/passwd`) ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <svg>&xxe;</svg> ``` - Once the above SVG image is uploaded and viewed, the XML document would get processed, and we should get the info of (`/etc/passwd`) printed on the page or shown in the page source - While reading systems files like `/etc/passwd` can be very useful for server enumeration, it can have an even more significant benefit for web penetration testing, as it allows us to read the web application's source files - For File Upload exploitation, it may allow us to `locate the upload directory, identify allowed extensions, or find the file naming scheme`, which may become handy for further exploitation - To use XXE to read source code in PHP web applications, we can use the following payload in our SVG image: ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg [ <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]> <svg>&xxe;</svg> ``` - Once the SVG image is displayed, we should get the base64 encoded content of `index.php`, which we can decode to read the source code # Denial of Service - Many file upload vulns may lead to a DOS attack on the webserver - For example, we can use the previous XXE payloads to achieve DoS attacks, as discussed in the [Web Attacks](https://academy.hackthebox.com/module/details/134) module - We can utilize a `Decompression Bomb` with file types that use data compression, like `ZIP` archives - Another possible DoS attack is a `Pixel Flood` attack with some image files that utilize image compression, like `JPG` or `PNG` # Exercise - `ping` test ![[images/Pasted image 20251224150220.png]] - `nmap` scan ![[images/Pasted image 20251224150308.png]] - visit page ![[images/Pasted image 20251224150242.png]] - only `.svg` images are allowed ![[images/Pasted image 20251224150257.png]] ## XSS with an SVG image - Download random `.svg` image ![[images/Pasted image 20251224150825.png]] - Edit the xml code to include the below script as a test ```javascript <script type="text/javascript">alert(window.origin);</script> ``` ![[images/Pasted image 20251224150945.png]] - Upload the modified `htb.svg` file - Success - we are getting the alert dialog box ![[images/Pasted image 20251224151057.png]] ![[images/Pasted image 20251224151224.png]] ## Create new svg file to leak flag - Create new file `flag.svg` as shown below ![[images/Pasted image 20251224152133.png]] - Try to upload - blank image as expected ![[images/Pasted image 20251224152230.png]] - check source code - we have the flag ![[images/Pasted image 20251224152305.png]] ## Create new svg file to leak source code for `upload.php` - Create a new file `upload.svg` as shown below ![[images/Pasted image 20251224152446.png]] - Try to upload ![[images/Pasted image 20251224152631.png]] - the source code has a `base64` string that we need to decode ![[images/Pasted image 20251224152623.png]] - Decode `base64` string ```bash echo "<base64_string>" | base64 -d > upload.php ``` - We have the source code for `upload.php` ![[images/Pasted image 20251224152757.png]]