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

and read a file containing the challenge flag.

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!

 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!

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://cwe.mitre.org/data/definitions/22.html

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.

Thus, we immediately identify what appears to be a variable of interest, 

, mastery of which would allow the execution of arbitrary code on the server, potentially resulting in remote code execution (RCE). However, these 2 variables are hardcoded and seem initially unmodifiable, unless it was possible to modify them through the input configuration file in some way.

The next block of code then defines a class and a function:

 is defined, corresponding to an implementation of a key-value dictionary. This class will likely instantiate objects containing security configurations.

 allows, on the other hand, to merge 2 dictionaries (or security configurations): the 

 configuration overwriting the values of 

In the next block of code, a default security configuration containing a few arguments is defined and instantiated. Then, the file 

, containing the result page, is read by the program.

Now comes the part where our input comes into play

. Subsequently, from what we understand of the code, the user-provided security configuration, which has been URL-encoded, is:

 to retrieve the original input string (because of the initial URL-encoding by the Web Application Firewall), using the 

 function. This method takes as input a string containing JSON and transforms it into a Python dictionary.

⚠️ If this conversion to JSON fails, the program terminates. Therefore, it is essential to ensure that, regardless of the payload used, the conversion works.

Once the user-provided security configuration is transformed into a dictionary, it is merged into the default security configuration with a call to 

merge_config(user_config, security_config)

⚠️ This results in an object of type 

) to convert it into a dictionary in the next code block.

 file is opened for writing, and the values contained in the new security configuration resulting from the merge are inserted into it using the 

json.dump(vars(security_config), config, indent=4)

 method. This method serializes a Python object into a file, effectively replacing the content of the JSON file on the server.

Next, the HTML page to be displayed to the user, containing the values of the server's new security configuration, is prepared, and the server's configuration update is performed by executing the previously defined 

To start, I will perform some tests with simple values to observe the nominal behavior of the server.

Thus, I will first attempt to add keys with arbitrary names to the default configuration, which will work. Then, I will try to replace an already existing value in the default configuration, such as the value associated with the firewall_enabled key, which was initially set to true:

 → Overrides the original value with the boolean 

 → Overrides the original value with the string 

. Thus, no strict type validation seems to have been implemented ;

 → Predictable validation error at attribution when merging with the default security configuration:

I will also note that the values of the configuration file are reset before each request, which does not allow reusing a payload across multiple requests.

After thorough research, I will find the existence of a vulnerability in Python applications called 

, a kind of equivalent to Prototype Pollution in JavaScript.

Thus, this vulnerability would stem from the very use of an object merging method such as the one defined in the body of 

Indeed, in Python, it is possible to access certain special attributes of objects in order to obtain 

 (meaning information unrelated to the business use of the objects).

According to this blog article (https://blog.abdulrah33m.com/prototype-pollution-in-python/), it is hence possible to "pollute" a class by using some of these attributes:

: allows direct access to an object's class,

: in case of inheritance, allows access to the parent class of level 

: allows access to the dictionary of the class method 

, containing its global variables, including all imported modules.

From this point, the attack path initially envisioned becomes feasible: if one could modify the 

 variable directly, then one would be able to execute arbitrary code remotely on the server.

To do this, I will go through the only class method defined for the 

 class, which also is the destination of the string taken as input and then converted into an object: I named 

Thus, the payload will be crafted as follows:

In the server's response, I will obtain the output of this command:

We now have a working remote code execution on the server.

It will then be left for me to attempt to display the contents of the file 

Sending this payload will allow us to obtain the final result, the flag 

FLAG{J4v4ScRipT??No_Pyth0N_cl4Ss_p0lluTi0n!!}

As shown in the PoC, the vulnerability allows a remote attacker to execute arbitrary commands on the server. Depending on the level of privileges required to be able to send the payload to the vulnerable endpoint, an (authenticated or not) attacker could then use this access to tamper with data, access sensitive information on the server, attempt to proceed with its exfiltration, and even try to elevate his privileges to continue the exploitation.

Remediating the issue mainly depends on business requirements. However, some mitigating steps for class pollution in this specific case are:

 Strict input validation mechanisms should be enforced so as to make sure that only expected and valid input is accepted. The Python library 

 can notably be used to validate JSON data against a given set of expected properties and types.

 The attributes that can be accessed or modified dynamically based on user input should be restricted, by implementing whitelists of allowed attributes in order to prevent access to sensitive or class-wide properties.

 The process should be executed within a sandboxed environment with restricted privileges, using Python's built-in sandboxing mechanisms or a third-party sandboxing solution so as to isolate potentially harmful operations. Although this is not a remediation of the vulnerability itself, it would limit the impact of any further remote code execution.

Dojo

Dojo challenge #34 winners!

Dojo challenge #33 winners!

Dojo challenge #32 winners!

Dojo challenge #31 winners!

Dojo challenge #30 winners!

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

Dojo challenge #31 winners!

Festive Dojo challenge #29: SantaLock winners revealed!

DOJO Challenge #28 Winners!

DOJO Challenge #27 Winners!

Festive Dojo challenge #29: SantaLock winners revealed!

DOJO Challenge #26 Winners!

DOJO Challenge #25 Winners!

DOJO Challenge #24 Winners!

DOJO Challenge #26 Winners!

Produits

Chercheurs

Ressources

A propos

Suivez-nous