invited participants to exploit a CWE-73: External Control of File Name or Path vulnerability

and read a file containing the challenge flag.

We are delighted to announce the winners of Dojo Challenge #35 below.

Want to create your own monthly Dojo challenge? Send us a message on X (Twitter)!

 feeds to be notified of upcoming challenges.

Read on to find out how one of the winners managed to solve the challenge.

We asked you to produce a qualified report explaining the logic allowing exploitation, as set out by the challenge. 

To ensure contestants actually solved the challenge themselves rather than copy-pasting the answer from elsewhere.

To determine contestants' ability to properly describe a vulnerability and its vectors within a professionally redacted report. This gives us invaluable hints on your unique talent as a bug hunter.

We want to thank everyone who participated and reported to the Dojo challenge. Many other high quality reports were submitted alongside those of the three winners. 😉

Below is the best write-up overall. Thanks again for all your submissions and thanks for playing!

An Arbitrary Local File Overwrite occurs when an attacker can overwrite specific local files on a target system with arbitrary content. This vulnerability typically arises due to insecure handling of file paths or poor validation in web applications, software, or systems.

This attack may lead to the disclosure of confidential data via local file inclusion, denial of service or remote code execution and other system impacts.

We are presented with a web application allowing us to send messages on a chat. We can give it a JSON file with the message content and recipient as input.

When analyzing source code, it's important to start with the entry point. In our case, this means retrieving user input. This user input first passes through the Web Application Firewall, which URL-encodes it. User input has been replaced in the following code by the 

 is first decoded using the decodeURIComponent() function. This acts as the inverse function of the URL encoding performed by the Web Application Firewall.

 If the user input is non-empty, it is parsed as JSON using 

. If the input format is not a valid JSON, then an error log is generated.

 At the last line, the “to” and “msg” arguments of this JSON are retrieved and used into the 

 class constructor. The initialization of the variable 

 was used as a hint to identify the JSON format, i.e. 

Code analysis - Part 2: Message class & its usage

The previous piece of code is followed by:

This is the only call to a method of the 

 class in the whole provided code. This method 

 should therefore be analyzed in details.

 which corresponds to the message recipient

 which corresponds to the content of the message

 which corresponds to the where the message is stored 

(in reality, in this code: the message is never really sent, it is simply stored in a file)

 method, which consists of two lines whose purpose is:

 argument, using a timestamp followed by the user input 

The line of code of interest here is the first one, let's see in details:

 argument, corresponding to the location where the file will be saved on the filesystem, takes as its value the return value of the 

 function is defined like this in NodeJs:

. Which means that a file is displayed in a format 

In its documentation, we can see that only the last part of the path is retained. Which means that adding a directory separators "

" would allow us to modify the return value of the function and retain only the part to the right of the separator.

In practice it means that if we send a value in the format "

This vulnerability allows us to write to a file in the target "file-write folder". Also, thanks to the second line of code, we can fill this file with any content we like.

If the newly created file was publicly accessible with execution rights, then we could have had a Remote Code Execution.

Code analysis - Part 3: Render of index.ejs

It renders and executes the EJS template present in the 

 argument of the message object created previously.

The code allows to write to file in the local folder with control over its name in 

Putting it together, we create a payload to overwrite the index.ejs file with any content:

 file has been replaced by our test content.

EJS is a templating language that lets us generate HTML markup with plain JavaScript. It has an 

 function that allows us to include any file in the file system if it has an extension (i.e. allowing Local File Inclusion). By default, the 

 extension is used, but it can be replaced by any other extension.
In order to retrieve the content of the flag.txt file, we use the following JSON payload :

Retrieving the flag : FLAG{W1th_Cr34t1vity_C0m3s_RCE!!}

Files such as /etc/passwd have no extension and are not recoverable via this type of payload.

Some sensitive files could be recoverable but are not available in this challenge. Example files: 

 with environment variable present at the root of the project (either in the write folder or one of its parent folder)

Arbitrary Local File Overwrite vulnerabilities pose significant security risks to systems. By exploiting these vulnerabilities, attackers can gain access to sensitive files on the server, execute remote code, or retrieve confidential data.
This can lead to privacy breaches, data integrity violations, or even complete compromise of the system. Vulnerable applications often include web services and other applications that handle user input data without properly controlling it, exposing these systems to significant risks of exploitation by malicious actors.

To protect against this vulnerability, we recommend following these measures:

Rigorously validate and filter the user input before processing it. Ideally, compare the user input with a whitelist of permitted values. If that isn't possible, verify that the input contains only permitted content, such as alphanumeric characters only. In our case it would prevent the directory separator "

After validating the supplied input, append the input to the base directory and use a platform filesystem API to canonicalize the path. Verify that the canonicalized path starts with the expected base directory and that the file respects the expected standards. In our case it would be a verification that the timestamp is present and that file is what we expect it to be (filetype/extension is correct, content is text only...)

 Educate developers and security teams on best practices for securing user inputs in web services.

By implementing these measures, you can effectively reduce the risks of such vulnerabilities in your applications and systems.

https://nodejs.org/api/path.html#pathbasenamepath-suffix

https://cwe.mitre.org/data/definitions/22.html

Dojo challenge #35 winners!

invited participants to exploit a XML external entity (XXE) injection (CWE-611) vulnerability

We are delighted to announce the winners of Dojo Challenge #34 below.

Want to create your own monthly Dojo challenge? Send us a message on Twitter!

A XXE (XML External Entity) vulnerability occurs when an application allows an attacker to include insecure external entities in an XML document.

This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

Vulnerable applications may include web services, applications that use XML documents for data processing, or any workflow that improperly controls XML data.

We are presented with a web application giving us a prompt in order to give our input to an AI generating images. We can either directly give it a theme or input a base64 string of an XML file.

When we analyze the source code, we notice the 

 function, which we're going to focus on:

One line catches instantly our attention:

parser.setFeature(xml.sax.handler.feature_external_ges, True)

Indeed, this line of Python code is used to configure the XML parser to allow the processing of external general entities (external general entities are entities declared outside the DTD (Document Type Definition) of an XML document).

: is a method used to enable or disable certain features of the XML parser.

: is a predefined constant in the xml.sax.handler module that specifies the feature to allow external general entities.

This confirms that an XXE attack is possible on the web application if we manage to craft a malicious XML file.

if (dataBytes[:2] != b'\xff\xfe' and dataBytes[:2] != b'\xfe\xff'):

 checks for the presence of Byte Order Mark (BOM) signatures for UTF-16 little-endian (

). Here's the purpose of this verification:

 BOM signatures are used to indicate the encoding of a text file, especially for UTF-16. 

 signifies that the text is encoded in UTF-16 little-endian, while 

 signifies that the text is encoded in UTF-16 big-endian.

 By checking these signatures, the code ensures that the data it processes is not encoded in UTF-16. If the data were UTF-16 encoded, it would require special handling to be correctly decoded. The absence of these signatures allows the code to proceed under the assumption that the data is encoded in another format (likely UTF-8 or another encoding without a BOM).

 If the data were UTF-16 encoded but processed as another encoding, it could lead to processing errors or unexpected behaviors. By checking for and excluding UTF-16 encoded data, the code reduces the risk of such errors.

However, it appears that the code lacks explicit handling for data that contains a UTF-16 BOM. It would be prudent to add an else block to handle this situation if necessary, for instance, by returning an error or correctly decoding the UTF-16 data.

if any(x in dataBytes.lower() for x in [b'file://', b'tmp', b'flag.txt', b'system', b'public', b'entity']):

 checks for the presence of certain substrings within the decoded data. Here's the purpose of this verification:

Detection of Potentially Dangerous Content:

 This condition searches for specific keywords and substrings that could indicate dangerous or sensitive content. For example:  

 could be used to attempt file access or directory traversal.

 might refer to sensitive files or directories.

 could be related to critical system paths or publicly accessible areas.

b'entity' is relevant in the context of XML parsing and could be related to XML External Entity (XXE) attacks.

 By detecting these potentially dangerous substrings, the code can prevent the processing of malicious data that could lead to security vulnerabilities. For instance, an XXE attack might involve using external entities to access sensitive files, and this condition helps block such attempts.

 This check acts as an early warning system for malicious input, allowing the function to return 'BLOCKED' immediately if any of these keywords are found. This prevents further processing of potentially harmful data, reducing the risk of security breaches.

Overall, this condition helps enhance the security of the application by detecting and blocking potentially harmful content before it can be processed and cause damage.

The parser allows parsing of general entities.

A UTF16 little-endian of big-endian bypass the blacklist protection

In order to exploit the vulnerability, we then can take a classic XXE payload :

And use any program to encode it as UTF16 little-endian (or big), then encode it to base64 and feed it to application.

 binaries, on our XML file containing our payload:

Copy paste the result to the prompt of the application and verify the exploitation:

 file, we use the following XML payload :

In order to automate the task I wrote a script that automate the task, here is a demonstration :

XXE (XML External Entity) vulnerabilities pose significant security risks to systems. By exploiting these vulnerabilities, attackers can gain access to sensitive files on the server, execute remote code, or retrieve confidential data.
This can lead to privacy breaches, data integrity violations, or even complete compromise of the system. Vulnerable applications often include web services and other applications that handle XML data without properly controlling it, exposing these systems to significant risks of exploitation by malicious actors.

To protect against XXE (XML External Entity) vulnerabilities, we recommend following these measures:

 Configure XML processors to disable support for insecure external entities.

 Utilize secure XML libraries that implement protections against XXE attacks.

 Rigorously validate and filter all incoming XML data to eliminate unauthorized external entities and potentially malicious data.

 Ensure all XML libraries used are up-to-date with the latest security patches to mitigate risks.

 Educate developers and security teams on best practices for securing XML applications and web services.

By implementing these measures, you can effectively reduce the risks of XXE vulnerabilities in your applications and systems.

 - XML External Entity (XXE) Processing : https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing

 - Vulnerabilities affecting of the SAX parser : https://docs.python.org/3/library/xml.html#xml-vulnerabilities

Dojo challenge #34 winners!

invited participants to exploit a path traversal (CWE-22) vulnerability

We are delighted to announce the winners of Dojo Challenge #33 below.

 occurs when an application uses external data (e.g., user input) to identify a file or directory located under a restricted root directory, but does not properly control the elements entered by users, resulting in the interpretation of the resolution of a path name to a location external to the restricted root directory.

In other words, exploiting this vulnerability allows an attacker to read files 

 the current directory. This could lead to sensitive files being read.

Firstly, an application whose source code was accessible was identified. The purpose of this application was to enable users to display files within an HTML page via a form in which the file name was entered.

The first step in exploiting this application was to analyze the 

The following lines provide an initial source of important information. The application's current directory is set to 

. This means that the files included in the application should be in this directory:

The section of code following the first 5 lines configures a Jinja2 environment for template rendering, using the 

 directory as the template source, with an initial template named 

. This means that it is probably via this file that the contents of the other included files will be displayed:

The next part of the code indicates a function named 

. This function returns a variable of type 

, and takes as parameter a variable with name 

, corresponding to the file name specified by the user:

This function acts as an initial check on the data sent by the user:

 converts all uppercase letters within the variable f to lowercase. For example, "ExampLe" will become "example".

Thereafter, various checks are made via conditions:

if f.startswith("/") or f.startswith("file:///")

 variable begins with "/" or "file:///". If so, the function returns 

elif (“127” in f) or (“localhost” in f)

 is a second check to detect whether the 

 variable contains the strings “127” or “localhost”. This blocks the possibility of including files using a local address such as 127.0.0.1. If either of these two patterns is detected, the function also returns 

Finally, if all conditions are not met, i.e. if the 

 variable does not begin with “/” or “file:///” and does not contain “127” or “localhost”, then the function returns 

The following code then forms the core of the application, enabling the reading of local files specified by the user:

The first line of this block of code instantiates a variable named 

3 nested conditions instructions are then implemented:

 is strictly positive. If this condition is not met, the default file displayed is 

 directory, as indicated by the following lines in the code block :

The welcome.txt file is therefore located in 

.

If the condition is met, a filter set up by the 

 loop detects the presence of the string “../” in the 

 variable. As long as this string is present, all occurrences of “../” in 

 will be replaced by an empty string. This reduces the risk of including files. For example, “../../../secret.txt” would become “secret.txt”.

Then, the second condition uses the previously analyzed function, 

 variable as argument. This condition is used to validate that this variable respects all the prerequisites previously mentioned in the analysis of this function. If all conditions are met, the function returns 

. If this is the case, the application will try to parse the name of the 

 variable using a regular expression.

If this second nested condition is not met, the 

. This value will then be displayed within the application.

The third and final nested condition provides additional control over the 

 variable, via a regular expréssion. The regular expression in question is: 

 variable by detecting the presence of alphabetic characters at the beginning of the value (whether upper or lower case). It then checks for the presence of “://”.

If the regular expression is satisfied, the application will attempt to read the file. On the other hand, if the regular expression is not satisfied, the file read will be “files/**filename”. If the application is unable to read the file, the error message displayed will be “File not found”.

Finally, the last part of the code is as follows:

This code adds a condition to check whether the string “

Finally, the last line of code displays the contents of the read file, or various error messages if all conditions are not met.

To exploit the application, the aim here is to attempt to read a file external to the authorized directory path.

To do this, the first check to be satisfied is the absence of “/” or “file:///” at the beginning of the input. As this condition is too permissive, the use of the 

 wrapper is authorized. This will enable us to read a file.

Secondly, the application checks for the presence of “127” and “localhost”. Fortunately for us, it's possible to bypass these protective measures by using a 

 representation of the 127.1 address (equivalent to localhost): 

Here, there's no need to use “../”. Any file can then be read. Here, a secret is present in 

 tries to be included: a blacklist is set up and replaces the string "flag" with "_AV_", which doesn't satisfy the last condition of the code:

To bypass this protection, character encoding can be used. This would result in a final load of :

It is now possible to include and read any file.

Here, the file /tmp/secrets/flag.txt will be displayed via the following payload:

The secret is FLAG{Y0u_C4n_Acc33ss_F1l3s_Th1s_w4y?!}.

When analyzing the code, we noticed that the template used was "index.tpl" located in "/tmp/app/templates/".

Here, if we try to include this file, the code will be displayed:

It's possible to notice that a file is included via the 

 placeholder. This is how the contents of the file are displayed.

An attacker with the ability to exploit this vulnerability could perform the following actions:

: if a web application is vulnerable to file inclusion or path traversal, the attacker could gain access to sensitive files such as configuration files, database files or password files. This could enable the attacker to compromise the security of the application or server.

: if a web application handles personal or sensitive data, a file inclusion or path traversal vulnerability could enable the attacker to access this data and use it for malicious purposes, such as identity theft or fraud.

Finally, in the worst case scenario, it would be possible to include remote files containing malicious code, which would be executed by the application, leading to its compromise.

To remedy this vulnerability, various control measures could be implemented:

: it is necessary to configure sufficient rights on files so that the application cannot access them. This can be done through read, write and execute rights.

: instead of authorizing access to all files on the system, it is preferable to define a whitelist of authorized files, and only authorize access to these files.

: it is recommended to implement more controls on user input. This could involve detecting the presence of wrappers, if this is not necessary. Last but not least, character encoding controls should also be tightened.

Of course, these controls will have to be analyzed beforehand to avoid impacting the application's operation.

https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion

https://portswigger.net/web-security/file-path-traversal

Dojo challenge #33 winners!

Class Pollution (Python's Prototype Pollution) vulnerability

and capture the flag stored in the flag.txt file of the vulnerable application.

We are delighted to announce the winners of Dojo Challenge #32 below.

 occurs when an attacker manipulates special attributes and methods associated with Python classes to modify their behavior or even their state at runtime. This vulnerability typically affects mutable objects, such as dictionaries, lists, or custom classes. In this case, the discovered vulnerability was found in the 

 function, which on the one hand allows users to modify the server's security settings, but on the other hand allows a remote attacker to execute arbitrary code on the web server by providing malicious input as a new security configuration.

During the security tests, an administration panel was discovered. A phase of exploration took place, so as to understand its functionalities.
The panel corresponds to an endpoint accessible to administrators, allowing them to modify a server's configuration based on an input string converted to JSON format.

To begin, we will review, block by block, the available code excerpt, shedding light on the backend logic:

At the very beginning, after receiving the request containing the new configuration, the server defines 2 variables:

: which contains the name of the configuration file on the server,

 as a parameter. According to the provided indications, calling this script would update the server's configuration from a JSON configuration file.

Dojo

Dojo challenge #35 winners!

Dojo challenge #34 winners!

Dojo challenge #33 winners!

Dojo challenge #32 winners!

Dojo challenge #31 winners!

Dojo challenge #30 winners!

Dojo challenge #32 winners!

Unveiling Dojo v2: Our new CTF and realistic challenge-building framework

Festive Dojo challenge #29: SantaLock winners revealed!

DOJO Challenge #28 Winners!

Unveiling Dojo v2: Our new CTF and realistic challenge-building framework

DOJO Challenge #27 Winners!

DOJO Challenge #26 Winners!

DOJO Challenge #25 Winners!

DOJO Challenge #27 Winners!

Products

Researchers

Resources

Company

Follow us