Mautic Version <=3.2.2

ADVISORY SUMMARY

The Mautic application is affected by stored XSS vulnerabilities. Upon exploitation, these issues allow an authenticated attacker to store malicious JavaScript payloads that would execute against other Mautic users. Specifically, an attacker with the permissions to manage companies or Social Monitoring, an application feature, could attack other users, including administrators. For example, by loading an externally crafted JavaScript file, an attacker could eventually perform actions as the target user. These actions include changing the user passwords, altering user or email addresses, or adding a new administrator to the system.

Impact

An authenticated attacker with the permissions to manage companies or Social Monitoring could target and perform actions on the behalf of other users, including administrators.

Risk Level

Medium

Affected Vendor

Product Vendor

Product Name

Affected Version

Mautic Mautic <= 3.2.2

 

Product Description

Mautic is an open source marketing automation tool. The project’s official website is https://www.mautic.org/. The latest version of the application is 3.2.4 released on January 14, 2021.


Vulnerabilities List

One vulnerability was identified within the Mautic application:

CROSS-SITE SCRIPTING (XSS)

Solution

Update to version 3.2.4

VULNERABILITIES

CROSS-SITE SCRIPTING (XSS)

The Mautic application is affected by stored XSS vulnerabilities. These issues allow an authenticated attacker to store malicious JavaScript payloads that would execute against other Mautic users. Specifically, an attacker with the permissions to manage companies or Social Monitoring could attack other users, including administrators. For instance, by loading an externally crafted JavaScript file, an attacker could eventually perform actions on behalf of the target user, including changing the user’s password or email address or adding a new administrator to the system.

CVE ID

Security Risk

Impact

Access Vector

CVE-2020-35128,
CVE-2020-35129

Medium Escalation of privileges Remote


Stored XSS in Company Name Field

A stored XSS vulnerability was found in the Company Name field. To demonstrate this issue, a proof-of-concept (PoC) payload was injected into that field:

 

Company Name with JavaScript payload


Figure 1
-
Company Name with JavaScript payload

As shown in the following POST request, the XSS payload was used in the company[companyname] parameter:

POST /mautic/s/companies/edit/1?mauticUserLastActive=4764&mauticLastNotificationId= HTTP/1.1
Host: localhost
…omitted for brevity…
company%5Bscore%5D=0&company%5Bowner%5D=&>company%5Bcompanyname%5D=%3Cimg+src%3Dx+onerror%3Dconfirm('XSS')%3E&company%5Bcompanyemail%5D=&company%5Bcompanyaddress1%5D=&company%5Bcompanyaddress2%5D=&company%5Bcompanycity%5D=&company%5Bcompanystate%5D=&company%5Bcompanyzipcode%5D=&company%5Bcompanycountry%5D=&company%5Bcompanyphone%5D=&company%5Bcompanywebsite%5D=&company%5Bcompanynumber_of_employees%5D=&company%5Bcompanyfax%5D=&company%5Bcompanyannual_revenue%5D=&company%5Bcompanyindustry%5D=&company%5Bcompanydescription%5D=&company%5B_token%5D=kAayMpWGSe_npJC64UDzpgtMHDeFLGx4CAptt1mDzH8&company%5Bbuttons%5D%5Bsave%5D=



Figure 2
- Affected parameter in POST request


As soon as the change was saved, the XSS triggered:

 

Triggered XSS after creating or editing company


Figure 3
Triggered XSS after creating or editing company

Additionally, this XSS triggered on several locations. For example, the default Dashboard had a Recent Activity widget that retrieved all recent activities. As a result, when the company with a malicious JavaScript code was added, it appeared on the Dashboard:


Triggered XSS on Dashboard page

Figure 4 - Triggered XSS on Dashboard page

The company with the XSS payload could also be selected when adding a new contact:

Selecting malicious company while creating or editing a contact


Figure 5
- Selecting malicious company while creating or editing a contact


When the contact was added or viewed, the XSS triggered:

Triggered XSS while viewing a contact


Figure 6
- Triggered XSS while viewing a contact


The default Mautic installation featured a single user role that had full administrative access; however, it was possible to create less-privileged user roles. If a less-privileged user role had access only to create companies, that user could inject an XSS payload to perform actions on behalf of those users.

Stored XSS in Social Monitoring Title or Name

A stored XSS issue was also discovered within the Social Monitoring section. Specifically, an attacker could enter a malicious JavaScript payload in the Name or Title of the Social Monitor feature, as shown below:

Social Monitor Name allowing XSS payloads


Figure 7
- Social Monitor Name allowing XSS payloads

 

The following HTTP POST request was used to store the XSS payload:

POST /mautic/s/monitoring/edit/1?mauticUserLastActive=180&mauticLastNotificationId= HTTP/1.1
Host: localhost
…omitted for brevity…
monitoring%5Btitle%5D=AAA%3Cimg+src%3Dx+onerror%3Dconfirm(1)%3E&monitoring%5BnetworkType%5D=twitter_handle&monitoring%5Bproperties%5D%5Bhandle%5D=bishopfox&monitoring%5Bproperties%5D%5Bchecknames%5D=0&monitoring%5Bdescription%5D=Test&monitoring%5BisPublished%5D=1&monitoring%5BpublishUp%5D=&monitoring%5BpublishDown%5D=&monitoring%5Bcategory%5D=&monitoring%5B_token%5D=4eSQ1YrFcdj3xdVfIcXiDQBkKnpSZa8dLZ1az8_YVWU&monitoring%5Bbuttons%5D%5Bsave%5D=



Figure 8
- POST request with XSS payload in the
monitoring[title] parameter

The XSS payload was evaluated as soon as the modified Social Monitor was viewed:

 

Triggered XSS after opening Social Monitor


Figure 9
- Triggered XSS after opening Social Monitor

As with the previous XSS instance affecting company names, even if a user role had access only to Social Monitoring, that user could eventually attack other Mautic users, including administrators, by injecting malicious payloads. For instance, an attacker could load an externally drafted JavaScript file that would allow them to eventually perform actions on the target user’s behalf, including changing the user’s password or email address or changing the attacker’s user role from a low-privileged user to an administrator account.

CREDITS

Dardan Prebreza, Senior Security Consultant, Bishop Fox (dprebreza@bishopfox.com)

 

TIMELINE

  • Initial Discovery: 09/23/2020
  • Contact with vendor: 09/23/2020
  • Vendor acknowledged vulnerabilities: 09/23/2020
  • Attempted to contact vendor regarding remediation: 11/27/2020
  • Final attempt to contact vendor regarding remediation: 12/30/2020
  • Vendor released patch version 3.2.4: 01/14/2021
  • Vulnerabilities publicly disclosed: 01/15/2021