Why Injection still matters, XSS attacks

A cross-site scripting (XSS) vulnerability allows an attacker to execute malicious code within a user's browser without the user's consent. XSS does not target the application directly. Instead, XSS targets the users of a web application.

JetBrains’s YouTrack stored XSS

Stored XSS vulnerabilities are the most severe type within the family of XSS vulnerabilities. This is because the application stores the malicious code within its database. The code infects any page that displays the malicious data to the end user. Every user that requests the infected pages will cause the malicious code to execute every time on each user's machine. The attacker can compromise multiple accounts through this vulnerability.

In JetBrains’s YouTrack any user with the ability to create projects, can inject a malicious XSS payload in the project’s logo and use the logo’s URL to attack other users of the application. In the following Proof of concept, we aim to attack the application’s Administrator.

After creating a project in the application we edit their properties and add an image to the project’s logo. Capturing that request with an HTTP analyser we can see that the image is sent encoded in base64, we can modify the property “data:image/jpeg;base64” to “data:text/html;base64” and inject an XSS payload, shown in the following image:

The application successfully accepted the code and stored it in its database. After a user has requested a page containing this injected code (the path specified in the response as “iconUrl”), the user's web browser subsequently executes it.

We encoded the following JavaScript code for this proof of concept:

In the image above we can see that the payload is reading the browser’s local storage and obtaining the ‘__youtrack__’ json to get an identifier called ‘serviceId’. With the obtained ‘serviceId’ another item from the local storage is acquired, this item has the access token used to authenticate a user in the application. Once the authentication token is obtained, we send it to a server controlled by the attacker.

When the victim enters the URL obtained in the response (http://server:8080/hub/api/rest/projects/7a38c0da-0a02-4814-be64-6f55c11e1b20/icon?etag=MjctMjQ%3D) the JavaScript code will be executed:

The victim’s token will be acquired from the browser’s local storage and sent to a server controlled by the attacker. This is demonstrated in the screenshot below:

After the attacker attains the victim’s token (aiming to attack the application’s administrator) the following request can be done in order to create a permanent authentication token:

With that token we can use the administrator’s API to control the application.

JetBrains’s TeamCity reflected XSS

The second vulnerability is a reflected Cross site scripting. When Tesserent reported this issue, JetBrains’s Security department informed us that this was already fixed, but there is no public technical information about this vulnerability.

A reflected cross-site scripting vulnerability allows an attacker to execute malicious code within a user's browser without the user's consent. The user's browser executes the code when it receives a response to the malicious request, as the browser believes it originated from a trusted source.

Tesserent found the application TeamCity Professional 2021.1 is susceptible to a Reflected XSS attack and used the following payload as a proof of concept to exfiltrate data from the server.log file:

In this case this reflected XSS was really restricted, it was not possible to use JavaScript functions that have upper case letters in their name since when the reflection occurs, the payload was converted to lower case, any special character should be scaped with back slash symbol and then URL encoded.

With this payload and attacking an administrator, we aim to read the server’s log, encode it to base64 and send it to an attacker controlled google analytics page.

The following image shows the XSS request and the server’s response:

As a proof of concept, we set up the server’s Content Security Policy to allow connections to Google Analytics, this is a known technique since Google Analytics is widely used. After that we can bypass the content security policy enforced by the browser and exfiltrate the server.log file content that contains the super user authentication token, shown in the following image:

Base64 decoding the data, we get the following token:

With that token an attacker can authenticate as a super user and get full control of
the application.

In all the mentioned cross-site scripting cases, the first mitigative step is to write secure code from square one. The code should always validate and verify user inputs especially if the input is going to be inserted in the web page. The code should also limit user inputs to avoid or filter special characters or skip long inputs.
If successful, a cross site scripting attack can gravely impact websites and web applications, damage their reputation and relationships with customers.
Most of the time we think of client-side exploitation and that might be misleading, with attacking the end user, as we shown in these examples, we are attacking the client (administrators) in order to take full control of the application.

Note: both XSS vulnerabilities have been fixed in the latest releases from Jetbrain: https://www.jetbrains.com/privacy-security/issues-fixed/