GET /grizzly/get-header1
...
Date: Fri,25Dec199523:59:59 GMT
...which was accessed within the following code:
com.contrastsecurity.grizzly.header.HeaderStringHandler#service(), line 22
...and ended up being used as part of the path in the following file being opened:
/Fri,25Dec199523:59:59 GMT
What's the risk?
The application takes data from the user's request and uses it to access the file system. Because there is untrusted data being used as part of the file path, it may be possible for an attacker to read sensitive data or write, update, or delete arbitrary files on the container's file system. The ability to write arbitrary files to the file system is also called Unrestricted or Arbitrary File Uploads.
Recommendation
The application opens up a java.io.File or file I/O stream based on user input. Although it's not directly clear how that file is being used, this functionality could be an avenue for path traversal abuse.
Here's an example of a typical path traversal vulnerability:
String statement = request.getParameter("statement");
if(!statement.endsWith(".xml")) { // Validate (weakly) this file is an xml file
logger.error("Bad filename sent");
return;
}
// Read the specified file
File file = new File(STATEMENT_DIR, statement);
FileInputStream fis = new FileInputStream(file);
byte[] fileBytes = new byte[file.length()];
fis.read(fileBytes);
response.getOutputStream().write(fileBytes);
Often, there is no filename validation at all. Either way, an attacker could abuse this functionality to view the /etc/passwd file on a UNIX system by passing the following value for the "statement" parameter:
http://yoursite.com/app/pathTraversal?statement=../../../../../../../../etc/passwd%00.xml
The NULL byte (%00) is just another char to Java, so the malicious value passes the "endsWith()" check. However, when the value is passed to the operating system's native API, the NULL byte will represent an end-of-string character, and open the attacker's intended file. Note that Null byte injection in Java was fixed in Java 7 Update 45. So, make sure you are using at least this version of Java, in addition to validating the user's input to this File accessor code.
To prevent attacks like this, any of the following steps could help:
Use maps to filter out invalid values. Instead of accepting input like "file=string", accept "file=int". That "int" can be a key in a Map that points to an allowed file. If the map has no corresponding value for the key given, then throw an error.
Strongly validate the file value. Validate the file using a whitelist or regular expression:
Pattern p = Pattern.compile("^[A-Za-z0-9]+\.xml$");
String statement = request.getParameter("statement");
/ Validate the statement to prevent access to anything but XML files /
if( !p.matcher(statement).matches() ) {
response.sendError(404);
return;
}
// Read the file here as normal
Vulnerability ID: N1E8-H102-X4DE-XULF
Application Name: Pluto
Vulnerability Link: http://localhost:19080/Contrast/static/ng/index.html#/7c6cfec5-a187-4d5e-984a-d11d96d2ef63/applications/0f9338c6-352f-418b-9d89-696406640d91/vulns/N1E8-H102-X4DE-XULF
What Happened?
We tracked the following data from "date" Header:
GET /grizzly/get-header1 ... Date: Fri,25Dec199523:59:59 GMT
...which was accessed within the following code:
com.contrastsecurity.grizzly.header.HeaderStringHandler#service(), line 22
...and ended up being used as part of the path in the following file being opened:
/Fri,25Dec199523:59:59 GMT
What's the risk?
The application takes data from the user's request and uses it to access the file system. Because there is untrusted data being used as part of the file path, it may be possible for an attacker to read sensitive data or write, update, or delete arbitrary files on the container's file system. The ability to write arbitrary files to the file system is also called Unrestricted or Arbitrary File Uploads.
Recommendation
The application opens up a java.io.File or file I/O stream based on user input. Although it's not directly clear how that file is being used, this functionality could be an avenue for path traversal abuse. Here's an example of a typical path traversal vulnerability: String statement = request.getParameter("statement"); if(!statement.endsWith(".xml")) { // Validate (weakly) this file is an xml file logger.error("Bad filename sent"); return; } // Read the specified file File file = new File(STATEMENT_DIR, statement); FileInputStream fis = new FileInputStream(file); byte[] fileBytes = new byte[file.length()]; fis.read(fileBytes); response.getOutputStream().write(fileBytes);
Often, there is no filename validation at all. Either way, an attacker could abuse this functionality to view the /etc/passwd file on a UNIX system by passing the following value for the "statement" parameter: http://yoursite.com/app/pathTraversal?statement=../../../../../../../../etc/passwd%00.xml The NULL byte (%00) is just another char to Java, so the malicious value passes the "endsWith()" check. However, when the value is passed to the operating system's native API, the NULL byte will represent an end-of-string character, and open the attacker's intended file. Note that Null byte injection in Java was fixed in Java 7 Update 45. So, make sure you are using at least this version of Java, in addition to validating the user's input to this File accessor code. To prevent attacks like this, any of the following steps could help:
First Event
Last Event
HTTP Request
GET http://localhost:32841/grizzly/get-header1 HTTP/1.1 Date: Fri,25Dec199523:59:59 GMT Contrast-Mq-Name: queue-072-GrizzlyIT.it_tests_grizzly_header_sources_register_as_vulnerabilities-contrastsecurity-docker.jfrog.io/contrast/grizzly:rev7 Host: localhost:32841 Connection: Keep-Alive Accept-Encoding: gzip User-Agent: okhttp/3.9.1