February 25, 20190 mins read
Welcome to the first edition of a new exploit series we’re calling “Snyking In”! We’ll be looking at various security vulnerabilities, demonstrating how they can be exploited, as well as the potential risk they pose to your data and systems. Our examples will always involve real-world libraries that contain the vulnerability type in at least one of their released versions.
Oh, and don’t worry, we won’t leave you high and dry! We will also show you how to find and fix vulnerabilities in your application. Without further ado, here’s our first exploit video followed by more information about the directory traversal vulnerability.
A directory traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (
../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on the file system, including application source code, configuration, and other critical system files.
Directory traversal vulnerabilities can be generally divided into two types:
Information disclosure: allows the attacker to gain information about the folder structure or read the contents of sensitive files located on the system.
Writing arbitrary files: allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip Slip.
Directory traversal in st
st module serves static files on web pages and contains a vulnerability of this type. In our example, we serve files from the public route.
If an attacker requests the following URL from our server, it will in turn leak the sensitive information stored on that machine. Note
%2e is the URL encoded version of
This type of directory traversal is an information disclosure vulnerability, meaning that the attacker can read the contents of sensitive files. The damage is limited to the information that the attacker has access to on the system.
The st exploit
In the video above, the hack is performed from a terminal window, as the browser would normalize the input. The first attempted exploit uses the dot-dot-slash notation to traverse out of the public directory:
st library, however, is pretty security conscious. It protects against the dot-dot-slash style of directory traversal. However, by URL encoding the dot as we mentioned previously, the following command successfully exploits the vulnerability:
The output shows we now have access to the
package-lock.json file, among others. This gives us visibility to the other modules and associated versions used by the application. We can also look deeper into the file system for more sensitive information, as we do in the video—exposing the
1<!doctype html>Index of<!doctype html> 2../ 3exploits/ 2018-11-22T11:36:32.894Z - 4goof/ 2018-06-19T12:09:39.211Z - 5node_modules/ 2019-02-21T11:51:45.792Z - 6public/ 2018-06-19T12:09:03.003Z - 7routes/ 2018-06-19T12:09:03.003Z - 8views/ 2018-06-19T12:09:03.004Z - 9app.js 2018-06-19T12:09:02.997Z 2152 10app.json 2018-06-19T12:09:02.997Z 267 11db.js 2018-06-19T12:09:02.997Z 1157 12GoofApp.zip 2018-09-11T07:21:58.433Z 14138285 13package-lock.json 2019-02-21T11:51:46.183Z 186799 14package.json 2018-11-06T18:59:57.850Z 1207 15README.md 2018-06-19T12:09:02.996Z 1815 16utils.js 2018-06-19T12:09:03.003Z 641
To test your application for vulnerabilities in third-party libraries, such as
st, try Snyk for free and get instant results.