blog

iRedAdmin Multiple Vulnerabilities – CVE-2024-47227

Written by Simone Q | Sep 24, 2024 4:15:00 AM

TL;DR

CSA identified multiple vulnerabilities within iRedAdmin <= 2.5 which are tracked under CVE-2024-47227. iRedAdmin is an administrative panel to manage iRedMail Server (a single solution to install, configure and maintain a mail server).

The vendor released a fix to the reported vulnerabilities and version 2.6 is currently not vulnerable. The product iRedAdmin-Pro was never affected by these vulnerabilities.

Technical Details

Multiple instances of reflected Cross-Site Scripting (XSS) were identified in the iRedAdmin panel, which affected version 2.5 and below. Reflected Cross-Site Scripting (XSS) is a web security vulnerability where an attacker injects malicious scripts into a URL. The script is executed when a user clicks on this manipulated link. The script does not persist on the server and only runs in the immediate response. This can allow the attacker to perform actions, view, or modify information within the application as the user clicking on the tampered link.

The following pages and parameters were susceptible to reflected XSS:

A proof-of-concept XSS would look like the following:

Figure 1 - Response including the injected JS code

Additionally, a Host Header Injection was also observed affecting the redirect functionality of the application. The use of ‘self’ in the Python script, will give an implicit trust to the “Host” request header, making it build response based on its content. An example of this can be observed in the Redirect component of iRedAdmin:

Figure 2 - Host Header Injection

Demonstrating Impact – Admin Account Creation

The impact of reflected XSS attacks can be severe depending on the configuration of the webserver and cookie flags. If an attacker can control a script that is executed in the victim’s browser, then they can typically fully compromise that user. Amongst other things, the attacker can perform any action within the application that the user can perform, view any information that the user is able to view, modify any information that the user is able to modify, and initiate interactions with other application users. The attack could be targeted directly against a known user, or could be an indiscriminate attack against any users of the application. The need for an external delivery mechanism for the attack means that the impact of reflected XSS is generally less severe than stored XSS, where a self-contained attack can be delivered within the vulnerable application itself.

To demonstrate the impact of this XSS, SCCS will create a new administrative user in iRedAdmin. To do so, the following actions will be required:

  1. Fetch the ‘/iredadmin/create/admin’ page to get a valid ‘csrf_token’
  2. Issue a POST request to ‘/iredadmin/create/admin’ to create a new administrative user, attaching the value of a valid ‘csrf_token’

 

The body of the POST request should contain the following elements:

To automate both operations, we can use the following JavaScript code:

The above is however too long and containing unnecessary elements (comments, error handling and output controls). We can therefore create a minified version, which would look like the following:

Next, we can URL-encode the full payload directly in the vulnerable parameter (don’t forget to include “”><script>[payload]</script>”):

This is however looking too suspicious to be send to an iRedAdmin – In this case we can use a URL-shortener and create a smaller link:

Figure 3 - Payload in URL-shortener

The vulnerable URL can be then sent to an iRedAdmin user via email or via IM, for example as a Teams message:

Figure 4 - Bait Teams Message

Once an administrative user (already logged-in within iRedMail) clicks the link, a new POST request will be issued using his/her session cookie, to create a brand-new administrative user in the platform:

Figure 5 - New Admin User

Remediation

As of 2.6, iRedAdmin sanitises untrusted user input to prevent HTML and JavaScript code injection. This fix successfully mitigated the aforementioned XSS and Host Header Injection vulnerabilities.

Disclosure Timeline

05/07/2024: XSS instances identified and requested a technical contact to info@iredmail.org

06/07/2024: CVE Requested to MITRE for multiple XSSs – Assigned just in September

06/07/2024: Technical details sent to Zhang Huangbin, founder of iRedMail

16/07/2024: Version 2.6 released fixing the reported vulnerabilities

24/09/2024: This blogpost published