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

Open Source Point of Sale v3.3.7 was discovered to contain an arbitrary file upload vulnerability via the Update Branding Settings page.

**Description**

\# An Issue is discoverd in Open Source Point of Sale v3.3.7.

#We found a vulnerability file upload, when we upload malicious file at Update Branding Settings page.

**Payload Attack**

https://github.com/bypazs/GrimTheRipper

**Proof of Concept**

First, we login to the target application with admin privileges.

Then we click at the Pelanggan icon as show in the picture.

We select “Buat Barang Baru” menu.

At Favicon, click “Seleccionar Imagen” for select a file.

Browse the file where we prepared the payload XSS Then click “Baru” for saving a file.

After uploading the file The file will appear in a new row in the table.

We found the XSS!

**Author**

Grim The Ripper Team by SOSECURE Thailand

CVE-2022-34578: Open Source Point of Sale v3.3.7— File Upload Cross-Site Scripting

Possible cross-site scripting vulnerability in libxml after commit 960f0e2.

*   _From_: Patrick Toomey <patrick toomey github com>
*   _To_: "xml gnome org" <xml gnome org>
*   _Subject_: \[xml\] Incorrect server side include parsing can lead to XSS and other similar issues
*   _Date_: Fri, 12 Jan 2018 17:01:21 +0000

While triaging a reported cross site scripting bug we were analyzing the behavior of our HTML sanitization code and noticed that it was parsing an input in an unexpected way.  The sanitization library itself eventually wraps Nokogiri, which is a relatively thin wrapper around libxml2. We reached out to Kurt Seifriend and Daniel Veillard to let them know about the observed behavior.  There was discussion about whether the observed behavior was was expected or not and eventually it was suggested that we move the discussion to the libxml2 mailing list (the folks on that thread reserved CVE-2016-3709 in case it is decided that this is an issue).  

\->  libxml2 git:(bc5a5d65) ✗ cat test/HTML/ssiquote.html

<html><body><p><a href="">

\->  libxml2 git:(bc5a5d65) ✗ make testHTML

\->  libxml2 git:(bc5a5d65) ✗ ./testHTML test/HTML/ssiquote.html

<html><body><p><a href="">

Notice that the output results in a script tag added to the resulting parsed output.  Here is a small bit of Java/Xerces code to compare:

import java.io.IOException;

import java.io.StringReader;

import java.io.StringWriter;

import javax.xml.parsers.\*;

import javax.xml.transform.OutputKeys;

import javax.xml.transform.Transformer;

import javax.xml.transform.TransformerException;

import javax.xml.transform.TransformerFactory;

import javax.xml.transform.dom.DOMSource;

import javax.xml.transform.stream.StreamResult;

import org.w3c.dom.Document;

import org.w3c.dom.NamedNodeMap;

import org.w3c.dom.Node;

import org.w3c.dom.NodeList;

import org.xml.sax.InputSource;

import org.xml.sax.SAXException;

public class XmlTester {

public static void main(String\[\] args) throws ParserConfigurationException, SAXException, IOException, TransformerException {

String text = "<html><body><p><a href="">

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

DocumentBuilder builder = factory.newDocumentBuilder();

// text contains the XML content

Document doc = builder.parse(new InputSource(new StringReader(text)));

System.out.println(getStringFromDocument(doc));

}

public static String getStringFromDocument(Document doc) throws TransformerException {

DOMSource domSource = new DOMSource(doc);

StringWriter writer = new StringWriter();

StreamResult result = new StreamResult(writer);

TransformerFactory tf = TransformerFactory.newInstance();

Transformer transformer = tf.newTransformer();

transformer.transform(domSource, result);

return writer.toString();

}

}

This Java code, with the same input, results in the following output:

<html>

<body>

<p>

<a href="">

</p>

</body>

</html>

The attribute contents are quoted/escaped such that  they don’t break out of the attribute once it is parsed. This libxml2 behavior doesn’t apply to all attributes. If we change the href to a class attribute there is no issue. This likely makes sense since the above mentioned commit specifically references not URI escaping. 

\->  libxml2 git:(bc5a5d65) ✗ cat test/HTML/ssiquote.html

<html><body><p><a class='&lt;!--"&gt;&lt;script&gt;alert(1)&lt;/script&gt;-->'>test1</a></p></body></html>

\->  libxml2 git:(bc5a5d65) ✗ make testHTML

\->  libxml2 git:(bc5a5d65) ✗ ./testHTML test/HTML/ssiquote.html

<html><body><p><a class=''>test1</a></p></body></html>

So, I guess the question is, what do people think? I believe the argument from Daniel was roughly that this would be expected behavior for server side includes. However, this functionality seems to be in conflict with the Xerces behavior and it also leads to a trivial way to cause new/unexpected nodes to be introduced into the tree simply by parsing the document. 

*   **Follow-Ups**:
    *   **Re: \[xml\] Incorrect server side include parsing can lead to XSS and other similar issues**
        *   _From:_ Patrick Toomey

\[Date Prev\]\[Date Next\]   \[Thread Prev\]\[Thread Next\]   \[Thread Index\] \[Date Index\] \[Author Index\]

CVE-2016-3709: [xml] Incorrect server side include parsing can lead to XSS and other si

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

CVE-2016-4426: Version History — Zulip 2.1.7 documentation

In kippo-graph before version 1.5.1, there is a cross-site scripting vulnerability in xss_clean() in class/KippoInput.class.php.

@@ -444,7 +444,7 @@ public function printWgetCommands() echo '<td>' . $counter . '</td>'; echo '<td>' . $row\['timestamp'\] . '</td>'; echo '<td>' . xss\_clean($row\['input'\]) . '</td>'; $file\_link = explode(" ", trim($row\['file'\]))\[0\]; $file\_link = explode(" ", trim(xss\_clean($row\['file'\])))\[0\]; // If the link has no "http://" in front, then add it if (substr(strtolower($file\_link), 0, 4) !== 'http') { $file\_link = 'http://' . $file\_link;

CVE-2016-2138: Block XSS in wget commands (file links) · ikoniaris/kippo-graph@e6587ec

Authenticated (author or higher user role) Stored Cross-Site Scripting (XSS) vulnerability in GS Plugins GS Testimonial Slider plugin <= 1.9.1 at WordPress.

 Verified

 Not fixed

**4.8**

CVSS 3.1 score Medium severity

Monitoring Coming soon

Software

GS Testimonial Slider

Vulnerable versions

<= 1.9.1

PSID 

4b2c77540de2

Classification 

Cross Site Scripting (XSS)

OWASP Top 10 

A7: Cross-Site Scripting (XSS)

Required privilege 

Requires author or higher role user authentication.

Publicly disclosed

2022-07-27

**Details**

Authenticated Stored Cross-Site Scripting (XSS) vulnerability discovered by Tien Nguyen Anh (Patchstack Alliance) in WordPress GS Testimonial Slider plugin (versions <= 1.9.1).

**Solution**

No patched version is available.

**References**

CVE-2022-35882: WordPress GS Testimonial Slider plugin <= 1.9.1 - Authenticated Stored Cross-Site Scripting (XSS) vulnerability - Patchstack

An issue has been discovered in GitLab affecting all versions starting from 15.0 before 15.0.1. Missing validation of input used in quick actions allowed an attacker to exploit XSS by injecting HTML in contact details.

CVE-2022-1948

Loan Management System version 1.0 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Loan Management System - Stored XSS on several parameters# Date: 28/07/2022# Exploit Author: saitamang# Vendor Homepage: sourcecodester# Software Link: https://www.sourcecodester.com/sites/default/files/download/razormist/LMS.zip# Version: 1.0# Tested on: Centos 7 apache2 + MySQLThere are several functions and parameter affected as below:addUser.php- firstname- lastnamesave_ltype.php- ltype_name- ltype_descsave_borrower.php- firstname- middlename- lastname- addressThe payload use to inject is "/><svg/onload=alert(document.cookie)>

Loan Management System 1.0 Cross Site Scripting

Red Hat Product Security has been developing RapiDAST, a tool that can be used for security testing of products and services. DAST stands for dynamic application (or analysis) security testing. In this article, we introduce the tool and ideas that can help you with applying DAST into your software development life cycle.

Red Hat Product Security has been developing RapiDAST, a tool that can be used for security testing of products and services. It is also helpful for developers or quality engineers (QEs) to test the security of products during the software development life cycle (SDLC).

As the name suggests, RapiDAST is focused on performing rapid (automated) dynamic application security testing (DAST). While there are many security practices we can consider comprehensively for improving security posture of development environments — threat modeling, software composition analysis (SCA), static application security testing (SAST), fuzzing, penetration testing, etc. — this article focuses on DAST.

**What is dynamic application security testing?**

DAST stands for dynamic application (or analysis) security testing, and is a blackbox testing methodology used to uncover potential security flaws by performing automated security scanning against a running target.

This is opposed to SAST, which scans source code to identify security issues. Since DAST actually tests the running target, it produces fewer false-positives than SAST. DAST can also identify runtime and environment-related issues such as misconfiguration, which is almost impossible to detect in source code.   

While DAST can broadly refer to any security testing that can be used against any runtime targets, and while it does not necessarily have to target web technologies, most DAST tools are focused on web scanning. This is because of the prevalence of web applications and services that include APIs over the last few decades. Mobile backend services can also be a target of DAST, as they are generally implemented as web services.

DAST generally comes into play in the testing phase when it comes to SDLC. Since DAST requires a running target, DAST is used after the application’s code has been built and deployed to a test environment or to a staging or integration environment. Collaboration between developers and QEs is useful for DAST, and is cost-effective.

**Application programming interface (API) security**

Many modern web services are being developed as microservices. A microservices architecture is one in which multiple services are implemented separately and communicate with each other. Generally, such microservice architectures heavily rely on APIs for this communication. As more services are implemented with APIs, securing APIs is becoming increasingly important as well.

**Three phases of automated DAST scanning**

**1\. Identify endpoints**

In order to improve the security of something, the first step is to identify what actually needs to be secured. API scanning starts with identifying endpoints, called attack surfaces, where attackers input malicious data — such as URLs and parameters — in an attempt to compromise the web application. It should be noted that any data in the web requests can be freely modified by attackers. 

To automatically identify web endpoints, most DAST tools employ crawling or a spider feature. API endpoints can be difficult to identify with crawling, however API scanning can be done effectively by taking advantage of OpenAPI. See the OpenAPI-based scanning section below for more details.

**2\. Send requests**

Once the endpoints have been identified, DAST tools start sending lots of requests that simulate real attacks. To reach the protected contents, the tools can use established sessions that are normally implemented with cookies or tokens, or even guide users to login to the target.

APIs generally rely on tokens for authentication, whereas most traditional web applications typically use cookies. In some cases, both authentication techniques are used for the same website. It is not uncommon to see the frontend application use a cookie and the backend API use a token at the same time. 

**3\. Analyze results**

The previous phase results in a lot of responses and results. Analyzing them, with configured scanning rules, can detect security vulnerabilities such as SQL injection and cross-site scripting (XSS), in addition to many other weaknesses such as misconfiguration issues. 

**What is RapiDAST?**

RapiDAST (Rapid DAST) is an open source project to develop a DAST tool that Red Hat Product Security has been working on, hosted on GitHub. RapiDAST is evolving, but at this stage it is focusing on scanning APIs as effectively and conveniently as possible through automation. The project is currently making use of OWASP ZAP — a popular open source web security testing tool — as its core engine.

**OpenAPI-based scanning**

As mentioned above, OpenAPI can be used to identify API endpoints. The OpenAPI Specification — formerly known as Swagger specification — is quite popular in terms of describing RESTful API interfaces. The specification is in a standardized format that is not only human readable, but also can be easily used by machines or tooling for automation. 

OpenAPI enumerates all the API endpoints, methods and parameters including useful information such as whether a parameter is sent in a URL path, in a query string, or in request body, and whether a parameter type is string or integer. Such a collection of information can be written into a file called OpenAPI definition.

_Example of OpenAPI definition_

If there is an OpenAPI definition available (which many API development projects have), RapiDAST will take advantage of it to automatically get to know all of the API’s endpoints and parameters. RapiDAST can then proceed with scanning and generating scanning reports.

**Continuous security scanning with RapiDAST**

"Secure development" is a hot topic these days, especially with the U.S. President’s Executive Order for Cybersecurity issued in 2021, and Red Hat Product Security has been working hard to provide a SDLC framework that drives greater software security. As part of this, DAST is being used in many Red Hat products’ SDLCs. 

Using RapiDAST enables the developers and QEs to identify security issues at an earlier phase of the SDLC, and it is currently being used successfully within Red Hat. For example, RapiDAST is used to continuously scan many Red Hat managed services running on console.redhat.com or api.openshift.com.

_Services running on console.redhat.com_

Using RapiDAST, with a simple script run based on a YAML configuration file, users can get scanning results.

Here is an example of a RapiDAST scan. 

$ scan-example-with-podman.sh testscan                
Deleting previously generated scripts                                              
Loading the script to ZAP                                                          
Templating script Rule\_Gen\_05eec230-5ba0-4bf5-b1d0-43268b8542d2                    
Loading script Rule\_Gen\_05eec230-5ba0-4bf5-b1d0-43268b8542d2 in ZAP from /tmp/Rule\_Gen\_05eec230-5ba0-4bf5-b1d0-43268b8542d25k5s0yj7.js                                 
Enabling script Rule\_Gen\_05eec230-5ba0-4bf5-b1d0-43268b8542d2 in ZAP               
Script Rule\_Gen\_05eec230-5ba0-4bf5-b1d0-43268b8542d2 successfully loaded and enabled                                                                                   
Creating session in: /zap/results/testrun/sessions/20211210-041924/session1          
Excluded URLs: ^(?:(?!http://192.168.109.202:9000).\*).$                               
Include URL in context: http://192.168.109.202:9000/api/.\*                            
Exclude URL from context:                                                          
Importing API: /zap/config/oas/openapi.json                                        
\>> Target Url: http://192.168.109.202:9000                                            
Start Active scan. Scan ID equals 0                                                
Scan Policies: \['API-minimal-example'\]                                             
Active Scan progress: 0%                                                           
Active Scan completed                                                                                                                                                  
Waiting for Passive Scan to complete                                                                                                                                   
Passive Scan completed                                                             
XML report saved in: /zap/results/testrun/demo1-report-20211210-041924.xml

The logs give you an overview of how it works:

1.  Load custom scanning rules (RapiDAST can be extensible)
    
2.  Import OpenAPI
    
3.  Perform scanning against a target with a scanning policy
    
4.  Save a scanning report
    

RapiDAST can generate reports in XML, HTML and JSON, thanks to OWASP ZAP’s report feature.

**RapiDAST operator running on Kubernetes or Red Hat OpenShift**

RapiDAST has recently evolved to be running as an operator on Kubernetes or Red Hat OpenShift. This can add more scalability and stability for your "shift left" projects. Also, Red Hat Product Security is actively participating in the Operate First community, with the goal of delivering greater security to open source projects that are running on the community clusters.

_rapidast-operator running on Operate First cluster_

**Security and cross-team collaboration**

Taking care of security is no longer a blocker that delays development. Nowadays, many experts emphasize the importance of "shift left" or DevSecOps, and success relies on cross-team collaboration. Both security engineers and development teams (including developers and QEs) have to work together to apply RapiDAST into SDLC.

Here’s an example of what cross-team collaboration workflow might look like:

*   Developers develop a project with OpenAPI
    
*   QE teams help with scanning on running target environments
    
*   CI/CD teams may provide infrastructure for continuous scanning
    
*   Security engineers analyze and manage in case of security issue
    

This sort of collective, collaborative effort to shift security left makes it significantly more likely that security issues will be identified much earlier in the software development life cycle, saving both time and effort on all sides.

**Conclusion**

In this article, we introduced the RapiDAST tool and ideas for cross-team collaboration that can help you with applying DAST into your software development life cycle. While we focused on API security so far, RapiDAST is going to have more useful features soon. We are already on the journey!

**Learn more**

*   RapiDAST project on GitHub
    
*   Red Hat Security Blog
    
*   Red Hat Product Security Center
    
*   Red Hat Product Security Overview

Automated dynamic application security testing with RapiDAST and cross-team collaboration

An issue was discovered in Veritas NetBackup 8.1.x through 8.1.2, 8.2, 8.3.x through 8.3.0.2, 9.x through 9.0.0.1, and 9.1.x through 9.1.0.1 (and related NetBackup products). An attacker with authenticated access to a NetBackup Client could remotely trigger a stack-based buffer overflow on the NetBackup Primary server, resulting in a denial of service.

**Revision History**

*   1.0: July 18: Initial Release

**Summary**

Veritas has addressed multiple security vulnerabilities impacting Veritas NetBackup, NetBackup Appliance, Flex Appliance, and Flex Scale. If you are at an earlier release of NetBackup, you will need to first upgrade to a version where a HotFix is available and then apply the appropriate HotFix. Table 2 of this advisory lists the high-level description. Click the Description hyperlink in Table 2 for more detail on each vulnerability.

**Affected products/versions:**

*   NetBackup 8.1.x, 8.2, 8.3.x, 9.0.x, 9.1.x
*   NetBackup Appliance/NetBackup Virtual Appliance 3.1.x, 3.2, 3.2 MRs, 3.3.0.1, 3.3.0.x MRs, 4.0, 4.0.0.1 MRs, 4.1, 4.1.0.1 MRs
*   NetBackup 8.1.x, 8.2, 8.3.x, 9.0.x, 9.1.x Containers on Flex Appliance 1.3.x, 2.0, 2.0.x, 2.1
*   Flex Scale 1.3.1, 2.1

**HotFixes are available for the following NetBackup versions:**

*   NetBackup 8.1.2, 8.2, 8.3.0.1, 8.3.0.2, 9.0.0.1, 9.1.0.1

**Remedial Actions:**

*   Review Table 1 below to identify your current NetBackup Enterprise software version and follow the remediation steps to apply the HotFix, or upgrade to a version where a fix is available.
*   To fix ALL issues listed below we recommend applying the HotFix to Primary servers as well as all Media servers. This HotFix may be safely applied to all NetBackup Media servers.
*   Flex Appliance customers, please apply the NetBackup HotFix corresponding to the NetBackup Container version on Flex appliances.
*   Flex Scale Appliance customers, please contact Veritas Technical Support and reference Knowledge Article ID 100053006 to obtain a fix.

_Table 1. Affected Version and Remedial Steps_

NetBackup Version

NetBackup Appliance NetBackup Virtual Appliance

Remediation Steps

8.1.2

3.1.2

Apply VTS22-004 - Hotfix for Security Advisory impacting NetBackup 8.1.2 and Appliance 3.1.2 Master and Media Server

8.2

3.2, 3.2 MR1/MR2/MR3

Apply VTS22-004 - Hotfix for Security Advisory impacting NetBackup 8.2 and Appliance 3.2 Master and Media Server

8.3.0.1

3.3.0.1 MR1/MR2

Apply VTS22-004 - Hotfix for Security Advisory impacting NetBackup 8.3.0.1 and Appliance 3.3.0.1 Primary and Media Servers

8.3.0.2

3.3.0.2 MR1/MR2

Apply VTS22-004 - Hotfix for Security Advisory impacting NetBackup 8.3.0.2 and Appliance 3.3.0.2 Primary and Media Servers

9.0.0.1

4.0.0.1 MR1/MR2/MR3

Apply VTS22-004 - Hotfix for Security Advisory impacting NetBackup 9.0.0.1 and Appliance 4.0.0.1 Primary and Media Server

9.1.0.1

4.1.0.1 MR1/MR2

Apply VTS22-004 - Hotfix for Security Advisory impacting NetBackup 9.1.0.1 and Appliance 4.1.0.1 Primary and Media Server

Pre-8.1.2  

Pre-3.1.2

Upgrade to a newer version and apply NetBackup Hotfix if applicable

8.3

 

Upgrade to a newer version and apply NetBackup Hotfix if applicable

8.3.0.1

3.3.0.1, 3.3.0.1 MR1/MR2/MR3

Upgrade to a newer version and apply NetBackup Hotfix if applicable

9.0

4.0

Upgrade to a newer version and apply NetBackup Hotfix if applicable

9.1

4.1

Upgrade to a newer version and apply NetBackup Hotfix if applicable

10.0

5.0

Not Impacted

_Table 2. Security Issues and Affected Products_

Issue #

Description

Severity

Affected products

Apply HotFix to:

C1

Authenticated Conditional Remote Command Execution

Critical

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

C2

Arbitrary File Write

Critical

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

H1

Authenticated Remote Command Execution

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

H2

Authenticated Remote Command Execution

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

H3

Remote Command Execution

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

H4

Arbitrary File Write

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

H5  

Arbitrary File Write

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

H6

Remote Command Execution

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers, Media Servers

H7

Local Privilege Escalation

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers, Media Servers

H8

Denial of Service

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

H9

Arbitrary File Read

High

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

M1

Arbitrary File Read

Medium

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

M2

Arbitrary File Read

Medium

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

M3

Denial of Service

Medium

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

M4

Arbitrary File Read

Medium

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

M5

Arbitrarily Create Directories

Medium

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

M6

Information Leakage

Medium

NetBackup, NetBackup Appliance, Flex Appliance, Flex Scale

Primary Servers

**Critical Issues**

_Issue #C1_

*   Authenticated conditional remote command execution.
*   CVE ID: To Be Assigned
*   Severity: Critical
*   CVSS v3.1 Base Score: 9.9 ( AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
*   An attacker with authenticated access to a NetBackup Client could remotely execute arbitrary commands on a NetBackup Primary server given specific notify conditions.

_Issue #C2_

*   Arbitrary file write.
*   CVE ID: To Be Assigned
*   Severity: Critical
*   CVSS v3.1 Base Score: 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H)
*   An attacker with authenticated access to a NetBackup Client could remotely write arbitrary files to arbitrary locations from any Client to any other Client via a Primary server.
*   Note: For this to occur it would require VxSS to be enabled on both the NetBackup Primary server as well as the attacker-controlled NetBackup client.

**High Issues**

_Issue #H1_

*   Remote command execution.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
*   An attacker with authenticated access to a NetBackup Client could remotely execute arbitrary commands on a NetBackup Primary server.

_Issue #H2_

*   Remote command execution.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
*   An attacker with authenticated access to a NetBackup Client could remotely execute arbitrary commands on a NetBackup Primary server.

_Issue #H3_

*   Remote command execution.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H)
*   An attacker with unauthenticated access could remotely execute arbitrary commands on a NetBackup Primary server.

_Issue #H4_

*   Arbitrary file write.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 8.5 (/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H)
*   An attacker with authenticated access to a NetBackup Client could arbitrarily write files to a NetBackup Primary server.

_Issue #H5_

*   Arbitrary file write.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H)
*   An attacker with authenticated access to a NetBackup Client could arbitrarily write content to a partially controlled path on a NetBackup Primary server.

_Issue #H6_

*   Remote command execution.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 8.0 (AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H)
*   An attacker with authenticated access to a NetBackup OpsCenter server, NetBackup Primary server or NetBackup Media server could remotely execute arbitrary commands on a NetBackup Primary server or NetBackup Media server.

_Issue #H7_

*   Local privilege escalation.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
*   An attacker with unprivileged local access to a Windows NetBackup Primary server could potentially escalate their privileges.

_Issue #H8_

*   Denial of service.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H)
*   An attacker with authenticated access to a NetBackup Client could remotely trigger a denial of service attack against a NetBackup Primary server.

_Issue #H9_

*   Arbitrary file read.
*   CVE ID: To Be Assigned
*   Severity: High
*   CVSS v3.1 Base Score: 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L)
*   An attacker with authenticated access to a NetBackup Client could remotely trigger an arbitrary file read, Server-Side Request Forgery (SSRF), a denial of service, and potentially other impacts.

**Medium Issues**

_Issue #M1_

*   Arbitrary file read.
*   CVE ID: To Be Assigned
*   Severity: Medium
*   CVSS v3.1 Base Score: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
*   Under certain conditions, an attacker with authenticated access to a NetBackup Client could remotely read files on a NetBackup Primary server.

_Issue #M2_

*   Arbitrary file read.
*   CVE ID: To Be Assigned
*   Severity: Medium
*   CVSS v3.1 Base Score: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
*   Under certain conditions, an attacker with authenticated access to a NetBackup Client could remotely read files on a NetBackup Primary server.

_Issue #M3_

*   Denial of service.
*   CVE ID: To Be Assigned
*   Severity: Medium
*   CVSS v3.1 Base Score: 6.3 (AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H)
*   An attacker with authenticated access to a NetBackup Client could remotely trigger a stack-based buffer overflow on the NetBackup Primary server, resulting in a denial of service.

_Issue #M4_

*   Arbitrary file read.
*   CVE ID: To Be Assigned
*   Severity: Medium
*   CVSS v3.1 Base Score: 6.3 (AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:H)
*   An attacker with authenticated access to a NetBackup Client could arbitrarily read files from a NetBackup Primary server.

_Issue #M5_

*   Arbitrarily create directories.
*   CVE ID: To Be Assigned
*   Severity: Medium
*   CVSS v3.1 Base Score: 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N)
*   An attacker with authenticated access to a NetBackup Client could arbitrarily create directories on a NetBackup Primary server.

_Issue #M6_

*   Information leakage.
*   CVE ID: To Be Assigned
*   Severity: Medium
*   CVSS v3.1 Base Score: 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N)
*   An attacker with access to a NetBackup Client could remotely gather information about any host known to a NetBackup Primary server.

**Note**

You may also use the NetBackup HotFix and EEB Release Auditor on SORT to check if a previous Emergency Engineering Binary (EEB) or HotFix was delivered in a released product version. This information is also available in the NetBackup Emergency Engineering Binary Guide for that version. If you do not see information related to a HotFix or an EEB you expected, please contact Veritas Technical Support.

**Questions**

For questions or problems regarding these vulnerabilities please contact Veritas Technical Support (https://www.veritas.com/support).

**Acknowledgements**

Veritas would like to thank the following Airbus Security Team members for notifying us about most of these issues: Mouad Abouhali, Benoit Camredon, Nicholas Devillers, Anais Gantet, and Jean-Romain Garnier.

**Disclaimer**

THE SECURITY ADVISORY IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. VERITAS TECHNOLOGIES LLC SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE.

Veritas Technologies LLC  
2625 Augustine Drive  
Santa Clara, CA 95054

Tag

#xss