Tarbomb Denial of Service via Path Traversal

As software applications are built and developed over the years, engineering teams continuously shift perspective on what features to prioritize or de-prioritize. A feature developed five years ago may have no significance today. However, features deemed low priority may still be kept operational for legacy, compatibility, or business requirement reasons.

Praetorian discovered such a legacy feature in a recent web application assessment. Despite lacking documentation or formal support, this feature continued to provide functionality to the end user. Within this ancient code base, Praetorian engineers discovered a hidden path traversal vulnerability that allowed an attacker to upload a maliciously compressed file to induce a denial of service in the application.

Identifying Path Traversal

The assessment focused on a web application that enabled users to organize and manage CI/CD operations for software development pipelines.

Within the application, Praetorian discovered an API endpoint that received a URL path from a user and used this path to download a file for processing. However, the application did not sanitize or validate the path parameter to prevent users from injecting path traversal characters such as ../.

The application did not validate against path traversal characters.

Normally, the application only processed files located within a specific directory. This vulnerability meant that the application could be induced to process any file stored on the website. To achieve further impact, the next step for an attacker would be to upload a malicious file for the application to process.

The only problem? The application did not have a file upload feature. At least, not a documented one.

Arbitrary File Upload

The official API documentation for the application did not list any endpoints which would allow users to upload files. Undeterred, Praetorian scoured the code base for legacy features and were rewarded with an undocumented feature that allowed users to upload files related to unit testing.

First, Praetorian created a new unit test.

Praetorian created a unit test and received an identifier.

Once a unit test was created, the application enabled users to upload “unit test artifacts” to track metrics and performance. This was a two-part process. First, the application required users to submit the filenames of any artifacts to be uploaded. Then, after receiving a Google storage link, users could upload actual file contents.

Praetorian submitted the filename of “test.zst” as a unit test artifact. The application returned a link to upload the contents of the “test.zst” file.

Praetorian submitted a JSON payload indicating intent to upload a “unit test artifact” named “test.zst”.

After uploading a sample file, Praetorian tested the path traversal vulnerability. The application returned “200 OK”, indicating that it successfully processed the sample file.

The application processed the path traversal payload successfully.

At this point, Praetorian could upload arbitrary files masquerading as unit test artifacts to the application. Combined with the path traversal vulnerability discussed earlier, Praetorian could induce the application to process the arbitrary file.

Now, we look deeper into how the application processed those files.

Malicious Decompression

Armed with the power of arbitrary file upload, Praetorian initially searched for a remote code execution vulnerability. Unfortunately, the application only performed minimal processing on the uploaded file; hopes for a critical exploit were quickly dashed. The only processing that the application performed was the decompression of compressed files.

While not particularly exciting, denial-of-service attacks from malformed files are a foundational part of file upload testing (see OWASP’s list of File Upload Threats). For example, an attacker could upload files that exceed the application’s expected size limits to consume system resources.

A neat trick for creating a tarbomb or zipbomb is to create a file containing all zeroes. This file will achieve a very favorable compression ratio, allowing an attacker to upload a relatively small file which will balloon to a massive size when decompressed. The following bash command will create a 10-gigabyte file containing all zeroes:

head -c 10G /dev/zero > payload.txt

Using this command, Praetorian created a 10 GB zero-file and compressed it to only 321 KB. We repeated Step 2 to upload this file as a unit test artifact and executed the path traversal payload once more. The application took 27 seconds to process the tarbomb.

Praetorian uploaded the maliciously compressed file to the server, incurring 27 seconds of processing.

As a baseline, Praetorian uploaded a compressed file of only a few bytes. The application took only 3 seconds to process this file, indicating an ~10x increase in processing time for the malicious file.

The server processed the baseline file in 3 seconds.

Praetorian concluded testing after demonstrating the proof-of-concept exploit. In reality, an attacker could create a much larger tarbomb file to consume additional system resources, degrading performance for legitimate users and disrupting system operations.

Conclusion

Successful execution of this exploit relied upon chaining together several security vulnerabilities in the application:

  • Lack of path traversal validation in filename processing
  • Undocumented legacy feature that enabled arbitrary file upload
  • Insufficient file validation before processing

This exploit highlights the importance of input validation as a security best practice. Applications should treat all user-supplied input as potentially malicious, and perform rigorous validation to check for any malicious aberrations.

This assessment also reveals how legacy features may introduce significant security risks in modern applications. By identifying an undocumented upload feature, Praetorian bridged the gap between two other vulnerabilities that would have been largely benign on their own. This demonstrates the importance of proper feature lifecycle management; forgotten or partially disabled features may enable unintended attack paths in otherwise secure applications.

icon-praetorian-

See Praetorian in Action

Request a 30-day free trial of our Managed Continuous Threat Exposure Management solution.

About the Authors

Catch the Latest

Catch our latest exploits, news, articles, and events.

Ready to Discuss Your Next Continuous Threat Exposure Management Initiative?

Praetorian’s Offense Security Experts are Ready to Answer Your Questions