HEUR:Trojan.MSIL.Agent.gen malware suffers from an information disclosure vulnerability.

    Discovery / credits: Malvuln (John Page aka hyp3rlinx) (c) 2022Original source: https://malvuln.com/advisory/bc2ccf92bea475f828dcdcb1c8f6cc92.txtContact: malvuln13@gmail.comMedia: twitter.com/malvulnThreat: HEUR:Trojan.MSIL.Agent.genVulnerability: Information DisclosureDescription: the malware runs an HTTP service on port 19334. Attackers who can reach an infected host can make HTTP GET requests to download and or stat arbitrary files using forced browsing.Family: AgentType: PE64MD5: bc2ccf92bea475f828dcdcb1c8f6cc92Vuln ID: MVID-2022-0654Disclosure: 11/09/2022Exploit/PoC:C:\>curl "http://192.168.18.125:19334/c:/Windows/system.ini" -v  Trying 192.168.18.125:19334...  Connected to 192.168.18.125 (192.168.18.125) port 19334 (#0)  GET /c:/Windows/system.ini HTTP/1.1  Host: 192.168.18.125:19334  User-Agent: curl/7.83.1  Accept: */** Mark bundle as not supporting multiuse* HTTP 1.0, assume close after body  HTTP/1.0 200 OK  content-encoding: utf8  content-type: application/octet-stream  date: Tue, 08 Nov 2022 23:11:55 GMT  last-modified: Sat, 16 Jul 2016 07:45:35 GMT  content-disposition: attachment; filename*=UTF-8''system.ini; filename="system.ini"; for 16-bit app support[386Enh]woafont=dosapp.fonEGA80WOA.FON=EGA80WOA.FONEGA40WOA.FON=EGA40WOA.FONCGA80WOA.FON=CGA80WOA.FONCGA40WOA.FON=CGA40WOA.FON[drivers]wave=mmdrv.dlltimer=timer.drv[mci]* Closing connection 0Disclaimer: The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. Do not attempt to download Malware samples. The author of this website takes no responsibility for any kind of damages occurring from improper Malware handling or the downloading of ANY Malware mentioned on this website or elsewhere. All content Copyright (c) Malvuln.com (TM).

HEUR:Trojan.MSIL.Agent.gen MVID-2022-0654 Information Disclosure

The Windows kernel suffers from multiple memory corruption vulnerabilities when operating on very long registry paths.

Windows Kernel Long Registry Path Memory Corruption

### Impact
When following a redirect, Electron delays a check for redirecting to file:// URLs from other schemes. The contents of the file is not available to the renderer following the redirect, but if the redirect target is a SMB URL such as `file://some.website.com/`, then in some cases, Windows will connect to that server and attempt NTLM authentication, which can include sending hashed credentials.

### Patches
This issue has been fixed in all current stable versions of Electron. Specifically, these versions contain the fixes:

- 21.0.0-beta.1
- 20.0.1
- 19.0.11
- 18.3.7

We recommend all apps upgrade to the latest stable version of Electron.

### Workarounds
If upgrading isn't possible, this issue can be addressed without upgrading by preventing redirects to file:// URLs in the `WebContents.on('will-redirect')` event, for all WebContents:

```js
app.on('web-contents-created', (e, webContents) => {
  webContents.on('will-redirect', (e, url) => {
    if (/^file:/.test(url)) e.preventDefault()
  })
})
```

### For more information
If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).

### Credit
Thanks to user @coolcoolnoworries for reporting this issue.

**Impact**

When following a redirect, Electron delays a check for redirecting to file:// URLs from other schemes. The contents of the file is not available to the renderer following the redirect, but if the redirect target is a SMB URL such as file://some.website.com/, then in some cases, Windows will connect to that server and attempt NTLM authentication, which can include sending hashed credentials.

**Patches**

This issue has been fixed in all current stable versions of Electron. Specifically, these versions contain the fixes:

*   21.0.0-beta.1
*   20.0.1
*   19.0.11
*   18.3.7

We recommend all apps upgrade to the latest stable version of Electron.

**Workarounds**

If upgrading isn't possible, this issue can be addressed without upgrading by preventing redirects to file:// URLs in the WebContents.on('will-redirect') event, for all WebContents:

app.on('web-contents-created', (e, webContents) \=> {
  webContents.on('will-redirect', (e, url) \=> {
    if (/^file:/.test(url)) e.preventDefault()
  })
})

**For more information**

If you have any questions or comments about this advisory, email us at security@electronjs.org.

**Credit**

Thanks to user @coolcoolnoworries for reporting this issue.

**References**

*   GHSA-p2jh-44qj-pf2v
*   https://nvd.nist.gov/vuln/detail/CVE-2022-36077

GHSA-p2jh-44qj-pf2v: Exfiltration of hashed SMB credentials on Windows via file:// redirect

Plesk Obsidian allows a CSRF attack, e.g., via the /api/v2/cli/commands REST API to change an Admin password. NOTE: Obsidian is a specific version of the Plesk product: version numbers were used through version 12, and then the convention was changed so that versions are identified by names ("Obsidian"), not numbers.

Plesk Dashboard

**INTRO**

Plesk is a commercial web hosting and server data center automation software developed for Linux and Windows-based retail hosting service providers. It’s the main choice of web hosting providers these days being used by 86.7% of the websites that use a web panel for administration. This is 4.4% of all websites and there around 2M Plesk installations in the US alone. As expected there are many interesting features to attack as an administrator, however we couldn’t find anything really exploitable and also it isn’t that interesting to begin with, if you’re already an administrator, right? We tried to see if we can escalate our privileges from one of the limited roles, but these seem solid. In the end we discovered a cookieless CSRF, which is basically a design issue in this case, because it affects all the POST requests and we could abuse most of the APIs with it.

Generally speaking, it’s obvious that Plesk has been through quite a few pentests and overall has a good security posture. The last thing we wanted to focus our attention on was the REST API. We were wondering, has the REST API the same level of security as the other Plesk components? Also we need to mention that the source code Plesk is highly obfuscated with a custom PHP extension.

**Misconfigured CORS policy**

While reviewing the REST API, we quickly noticed that there was a completely open CORS policy:

Using a wildcard to allow everything

So, we thought, wow this is definitely a good sign and we were on the right track testing the REST API. This will basically allow us to send any request with any methods/headers from any origin and read the response back. Or so we thought.

**Cookieless CSRF #1 – add secret token**

The administrator can call the REST APIs from the browser and there’s no CSRF protection either (partially correct as you will see next). Let’s try to CSRF an Administrator then. But what API endpoint shall we target? After reviewing the REST API, we discovered that there is the /api/v2/auth/keys endpoint which we thought of abusing by adding a secret key to give us admin access.

API endpoint to add a secret key for Administrator

This key will allow us to authenticate and call any endpoints after that, no more CSRF needed 🙂 Perform CSRF once, add a backdoor token and get full access forever. Sweet, let’s try this.

CSRF first attempt failed

We have used Burp’s CSRF POC generator and it seems that the request fails due to “=” added at the end, the server can’t parse this JSON. This was no big issue, this old dog knows some old tricks and by reformatting our payload a bit we were able to generate a valid JSON.

Name field of the input will hold most of the JSON field

The input’s name is html encoded and basically decodes to the following. The input’s value field will hold ‘test”}’ so that when it’s concatenated with the name it will result in a valid JSON payload. Nothing new here.

Name field html decoded

Now we were able to create a valid CSRF payload and generate a secret key as you can see bellow. We also have a miconsfigured CORS policy, so we can steal it, right?

CSRF attack on the Administrator

Well, not really. What we’ve missed initially is that the Authorization header gets added automatically by the browser when using an html form to perform the CSRF attack using the POST method. However, when using the javascript XHR object to create the same request and get the token from the response, the Authorization header isn’t added anymore. Bummer, our CSRF fails in this case as we can’t read the key! But wait, there’s still some hope left. Maybe we can find some other REST endpoints where we can trigger a CSRF attack using HTML forms (POST based) that will be impactful enough to give an attacker what they need without reading the response. And we sure found quite a few of these endpoints that we’ve exploited with various degree of severity as you’ll see next.

**Cookieless CSRF #2 – add DB user**

We found a REST endpoint that allows us to add a db user which can connect from ANY remote host to ANY database.

Add DB user (CSRF-able)

Result looks like bellow:

DB user added

We thought of injecting an UDF for a quick RCE, however the mysql port is not accessible. Lesson learned, check the port first.

Mysql port filtered

**Cookieless CSRF #3 – add FTP user**

We managed to add a new FTP user with access to any existing domain we wanted.

Add FTP user (CSRF-able)

This actually worked, you can connect via FTP, inspect the client’s home dir and conduct further attacks from there.

FTP connect OK

**Cookieless CSRF #3 – add a malicious Plesk extension**

We didn’t know what Plesk extensions were initially, so we did some quick research, backdoored an existing one and added it via CSRF upload using the REST API

Plesk malicious extension added via CSRF in the REST API

The problem was that you still need to authenticate in Plesk to access the backdoored extension. Certainly there must be an easier way, right?

**Cookieless CSRF #4 – compromise the admin**

Plesk implements some custom commands internally (a “command” is an abrastraction layer if you will in the code which calls various cli tools to do the heavy lifting) in order to manage the server as you can see bellow. One of these, is the “admin” command that allows you to do multiple things, including changing the Administrator’s password.

Plesk custom commands callable via REST API

And that is exactly what we needed. We ended up compromising Plesk via its REST API (CSRF) and change the Admin’s password. Game over!

CSRF-ing the Administrator to change his password.

The documentation around this feature isn’t great so it took a while to figure out the above payload. All POST requests can be CSRF-ed , because the browser adds the Authorization header automatically when using html forms. We noticed that there is a common misconception that an application using the Authorization header is protected against CSRF. As long as you don’t have to read the response back using javascript everything just works.

**Timeline**

10/05/22 FORTBRIDGE reaches out to PLESK for vuln disclosure

11/05/22 Plesk confirms receipt and starts investigation

19/05/22 Plesk confirms the vulnerability and starts working on a fix, no ETA offered

03/06/22 Plesk fixes the issue, but requests _delaying_ the disclosure, FORTBRIDGE accepts

25/07/22 FORTBRIDGE requests update on the patching progress

27/07/22 Plesk requests _delaying_ the disclosure again, FORTBRIDGE accepts

03/08/22 Plesk estimates “no longer than 2 weeks” for disclosure

16/09/22 FORTBRIDGE requests update

16/09/22 Plesk requests _delaying_ the disclosure, FORTBRIDGE agrees to delay 2 months max

08/11/22 FORTBRIDGE releases blogpost with technical details of the Plesk Admin takeover issue

**References**

RCE & Privesc in cPanel/WHM

Mass account takeover in Yunmai smartscale by abusing the REST API

CSRF POCs sent to Plesk

**About Post Author**

CVE-2022-45130: Compromising Plesk via its REST API

Hole-y software alert, Batman: Cybercriminal faves Citrix Gateway and VMware Workspace ONE have authentication-bypass bugs that could offer up total access to attackers.

Critical authentication-bypass vulnerabilities in Citrix and VMware offerings are threatening devices running remote workspaces with complete takeover, the vendors warned this week.

Admins should prioritize patching, given the history of exploitation that both vendors have. Both disclosures prompted CISA alerts on Wednesday.

**Citrix Gateway: A Perfect Avenue for Infesting Orgs**

As for Citrix, a critical bug tracked as CVE-2022-27510 (with a CVSS vulnerability-severity score of 9.8 out of 10) allows unauthenticated access to Citrix Gateway when the appliance is used as an SSL VPN solution. In that configuration, it gives access to internal company applications from any device via the Internet, and it offers single sign-on across applications and devices. In other words, the flaw would give a successful attacker the means to easily gain initial access, then burrow deeper into an organization's cloud footprint and wreak havoc across the network.

Citrix also noted in the advisory that its Application Delivery Controller (ADC) product, which is used to provide admin visibility into applications across multiple cloud instances, is vulnerable to remote desktop takeover (CVE-2022-27513, CVSS 8.3), and brute force protection bypass (CVE-2022-27516, CVSS 5.3).

Tenable researcher Satnam Narang noted that Citrix Gateway and ADC, thanks to how many parts of an organization they provide entrée into, are always favorite targets for cybercriminals, so patching now is important.

"Citrix ADC and Gateways have been routinely targeted by a number of threat actors over the last few years through the exploitation of CVE-2019-19781, a critical path traversal vulnerability that was first disclosed in December 2019 and subsequently exploited beginning in January 2020 after exploit scripts for the flaw became publicly available," he wrote in a Wednesday blog.

"CVE-2019-19781 has been leveraged by state-sponsored threat actors with ties to China and Iran, as part of ransomware attacks against various entities including the healthcare sector, and was recently included as part of an updated list of the top vulnerabilities exploited by the People’s Republic of China state-sponsored actors from early October," Narang continued.

Users should update ASAP to Gateway versions 13.1-33.47, 13.0-88.12, and 12.1-65.21 to patch the latest issues.

**VMware Workspace ONE Assist: A Trio of Cybercrime Terror**

VMware meanwhile has reported three authentication-bypass bugs, all in its Workspace ONE Assist for Windows. The bugs (CVE-2022-31685, CVE-2022-31686, and CVE-2022-31687, all with CVSS 9.8) allow both local and remote attackers to gain administrative access privileges without the need to authenticate, giving them full run of targeted devices.

Workspace ONE Assist is a remote desktop product that's mainly used by tech support to troubleshoot and fix IT issues for employees from afar; as such, it operates with the highest levels of privilege, potentially giving remote attackers an ideal initial access target and pivot point to other corporate resources.

VMware also disclosed two additional vulnerabilities in Workspace ONE Assist. One is a cross-site scripting (XSS) flaw (CVE-2022-31688, CVSS 6.4), and the other (CVE-2022-31689, CVSS 4.2) allows a "malicious actor who obtains a valid session token to authenticate to the application using that token," according to the vendor's Tuesday advisory.

Like Citrix, VMware has a history of being targeted by cybercriminals. A critical vulnerability in Workspace ONE Access (used for delivering corporate applications to remote employees) tracked as CVE-2022-22954 disclosed in April was almost immediately followed by a proof-of-concept (PoC) exploit released on GitHub and tweeted out to the world. Unsurprisingly, researchers from multiple security firms started seeing probes and exploit attempts very soon thereafter — with the ultimate goal of infecting targets with various botnets or establishing a backdoor via Log4Shell.

Users should update to version 22.10 of Workspace ONE Assist to patch all of the most recently disclosed problems.

Patch ASAP: Critical Citrix, VMware Bugs Threaten Remote Workspaces With Takeover

Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability

CVE-2022-37966

Windows Kerberos Elevation of Privilege Vulnerability

CVE-2022-37967

Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability.

Windows Kerberos Elevation of Privilege Vulnerability.

Windows Scripting Languages Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-41118.

Tag

#windows