Skip to main content

File Upload

File uploading represents a significant risk to applications. It is the first step in many attacks, as it allows the attacker to introduce malicious code into the system. Once this is accomplished, the attacker only needs to find a way to execute the code. The use of file uploading facilitates this first step for the attacker.

The consequences of unrestricted file uploads can be diverse and include complete system takeover, file system or database overload, forwarding attacks to background systems, client-side attacks or simply defacement. These consequences depend on how the application handles the uploaded file and, especially, where it stores it.

There are two kinds of problems associated with file uploading. The first refers to the file metadata, such as the path and file name. This data is provided by the transport, such as multi-part HTTP encoding. If not properly validated, they can trick the application into overwriting a critical file or storing the file in the wrong location.

The second type of problem is related to the size or content of the file. The problems associated here depend entirely on how the application uses the file. It is essential to analyze the entire file handling process in the application and carefully consider which processes and interpreters are involved to protect against this type of attack.

Application Platform Attacks​

  1. Upload .gif file to resize: exploits the image library vulnerability.
  2. Load .jsp file in the web tree: the JSP code is executed as the web user.
  3. **Uploading huge files: causes a denial of service due to lack of disk space.
  4. Upload file using a malicious path or name: overwrites a critical file on the system.
  5. Upload file containing personal data: exposes sensitive information to other users.
  6. Upload file containing "tags ": tags are executed as part of the inclusion in a web page.
  7. Upload .rar file to be scanned by antivirus: a command is executed on a server with vulnerable antivirus software.

Attacks on Other Systems​

  1. Upload .exe file to the web tree: victims download the Trojan executable.
  2. Upload virus-infected file: victims' machines are infected when downloading the file.
  3. Load .html file containing script: victims experience Cross-site Scripting (XSS).
  4. Load .jpg file containing a Flash object: the victim experiences cross-site content hijacking.
  5. Upload .rar file to be scanned by antivirus: a command is executed on a server with vulnerable antivirus software.

The example provided shows different security levels (low, medium and high) and how vulnerabilities at each level can be exploited by uploading malicious files. In each case, various techniques, such as the use of OWASP ZAP, file concatenation and magic number manipulation, are used to bypass file upload restrictions and execute malicious code on the target system.

Low​

In this security level, when entering the corresponding section, we find an input that allows us to upload files. We take advantage of this functionality to perform a malicious file upload test.

Normal use input

We created a shell containing a simple message, designed to demonstrate the ability to load and execute malicious files on the system, but which could be programmed according to our needs.

<!DOCTYPE html>
<html>
<head>
    <title>Shell DVWA</title>
</head>
<body>
    <h1>Shell low</h1>
</body>
</html>

We try to upload the file and see that it loads correctly.

Upload correct low Subida Correcta

After uploading the file, we verify that the upload is successful. Subsequently, we access the path where the file has been loaded and confirm that the shell execution is successful. This process demonstrates a serious vulnerability in the file upload system, as it allows the execution of malicious code.

Execution Shell low Shell nivel bajo

In summary, at this low security level, we were able to load a malicious shell and successfully execute it, which highlights the importance of implementing stronger security measures in the file upload system.

Medium​

At this intermediate security level, when trying to upload the same malicious shell, we notice that we cannot complete the file upload.

Error upload file medium

Examining the application code, we find that a content-type check of the file is performed to ensure that it is a JPEG or PNG image, and that its size is less than 100,000 bytes.

// Is it an image?
    if( ( $uploaded_type == "image/jpeg" || $uploaded_type == "image/png" ) &&
        ( $uploaded_size < 100000 ) ) {

We decided to use OWASP ZAP to modify the content-type of our file and thus circumvent the restriction imposed by the application.

Upload medium

In OWASP ZAP, we identify that the content-type is application/octet-stream. We modify this value and replace it with one of the allowed content-types, such as image/jpeg or image/png.

Modify code OWASP ZAP

Once this setting has been made in OWASP ZAP, we proceed with the file upload and observe that it completes successfully. Now we just need to go to its path and verify that the execution of the malicious shell also runs smoothly, which indicates a significant vulnerability in the file upload system.

Upload medium attack Upload correct

execution shell medium Shell media

In summary, at this intermediate security level, we were able to circumvent the content-type restriction using OWASP ZAP and successfully upload the malicious shell, thus demonstrating a major vulnerability in the file upload system.

High​

At this higher security level, by repeating the process performed in the previous levels, we again find it impossible to upload the malicious shell.

Error upload high

When analyzing the application code, we observe that a file extension check is performed and the getimagesize function is used to obtain the size of an image. This indicates that the system requires the upload of a file that is considered an "image".

if( ( strtolower( $uploaded_ext ) == "jpg" || strtolower( $uploaded_ext ) == "jpeg" || 
strtolower( $uploaded_ext ) == "png" ) && ( $uploaded_size < 100000 ) && getimagesize( $uploaded_tmp ) ) {

Therefore, we have to upload an "image" yes or yes. Given the restrictions imposed by the application, we are forced to look for alternatives to load the malicious shell. We have two options available:

  1. Use the 'cat' command to concatenate two files (an image and a shell).
  2. Use 'magic numbers' (lista) to trick the system.

cat​

For the 'cat' command option, we proceed to create a one pixel image with the image editor of our choice or we can use any available image. Then, we concatenate this image with the malicious shell using the following command:

cat shellimagebase.png shell.php > shellfinal.png

This command generates a new image containing the combination of the original image and the malicious shell, which we are going to upload to the system.

Upload correct cat high

After uploading the generated image, we verify that the upload is done correctly, which allows us to access it through the corresponding path. When we open the image, we can observe its visual content without any problems.

show image upload

However, if we want to execute the malicious code contained in the shell, it is necessary to combine this attack with File Inclusion. To do this, we go to the File Inclusion section and load the file. As a result, the image is not rendered, but the shellcode is successfully executed, highlighting the effectiveness of this type of attack.

Execution Shell File Inclusion High Shell high with cat File Inclusion

Magic Number​

For the 'magic numbers' option, we add the hexadecimal code corresponding to the PNG files at the beginning of our shell file. First, we open the shell with a hex editor.

Editors hexadecimal code Shell

Copiamos el 'magic number' para los archivos PNG:

89 50 4E 47 0D 0A 1A 0A

Introducimos el 'magic number' al comienzo del archivo de nuestra shell, de modo que el archivo se identifique como un archivo PNG.

Insert code in png Shell

Thus, the file will look like this, with the beginning of the file identified as PNG.

Editor hexadecimal code Shell

After modifying the shell file, we proceed to upload it to the system. Once the file is loaded correctly, we verify its operation by accessing the corresponding path.

Upload correc magic number high Correct upload

In this case, the image is not visually loaded into the system, as only the image header is present to fool the system.

Shell upload not show Shell subida pero no visible

However, if we perform the file inclusion using File Inclusion, the shell loads and works correctly, which highlights the effectiveness of this type of attack in combination with additional techniques.

execute Shell File Inclusion high Shell cargada mediante File Inclusion