Most cybersecurity professionals understand moral ambiguity. Just ask Marcus Hutchins, the “accidental hero” who stopped the WannaCry ransomware attack in its tracks.

Hutchins was working as a security researcher when he discovered a critical flaw in the malware — its kill switch. Not long after, he was indicted on federal charges related to his previous work as a malware developer on HackForums – a bustling collective of young hackers.

Thankfully, Hutchins was eventually cleared of all charges. But his story highlights the murky ethical landscape that many security researchers operate in.

On one hand, companies and individuals are better off when security researchers find and disclose vulnerabilities. On the other hand, some researchers find – or develop – exploits to sell on the dark web. For budding cybersecurity researchers, it’s not always clear where the line is.

After reading Hutchins’ story, I thought a lot about the nature of communities. Communities in the Internet age, specifically, and how they can lead us to the best things the Internet has to offer, or to the worst corners of others’ minds.

Take YouTube, for instance – its algorithm is designed to serve content that pushes users deeper into a specific topic, often toward morally questionable content. The same is true of TikTok, Facebook, and a slew of others. This subconscious manipulation is one of many reasons why it’s so difficult to find a like-minded community where you can collaborate and learn.

Hutchins didn’t need an algorithm to push him into the dark side. He found it while poking around a young hacking forum. Pretty soon, he would go from admiring malware to building his own, with increasingly dark results. Eventually, Hutchins built his own community, amassed followers on the order of tens of thousands, and attracted the attention of Kryptos Logic. And thus began his white-hat path toward neutering WannaCry.

“There’s [a] misconception that to be a security expert you must dabble in the dark side,” said Hutchins. “It’s not true. You can learn everything you need to know legally. Stick to the good side.”

I can only wonder how much more good Hutchins could have done had he found the “good side” long ago. Or, how much good current black-hat hackers could accomplish with encouragement from the right community.

The Modern Security Researcher’s Tribe

In the early days of hacking, only a handful of people could exploit vulnerabilities and gain unauthorized access to systems. These individuals were self-taught, like Hutchins, and their skills were not widely known or understood. As the Internet grew, more and more people became interested in hacking culture, sharing their knowledge and developing new techniques.

It’s a constantly evolving field.

Researchers used to be seen as “lone wolf” operators, working in isolation to scratch an intellectual itch. But the cybersecurity profession has undergone a dramatic transformation in recent years. Today’s security researcher is less likely to be a lone wolf and more likely to be part of a team, working together to uncover critical vulnerabilities and exploits (CVEs) and develop solutions. They are also more likely to use sophisticated tools and techniques to find vulnerabilities in systems. And thanks to the power of the Internet, they can reach a global audience with their findings.

This shift has been driven by the increasing complexity of attacks, which require greater levels of expertise to defend against. Security research is now an essential part of the modern IT landscape, and it is only going to become more important in the years to come.

One thing is certain, though: The work of security researchers has a profound impact on society. They are the ones who find the vulnerabilities that can be exploited to cause massive damage – like WannaCry. But the vulnerabilities they find could just as easily end up in the hands of bad actors who are intent on ripping off people and/or harming critical infrastructure.

The job is a delicate balancing act, one that requires a great deal of responsibility.

It’s important to remember that security researchers are not immune to the same biases and motivations that affect everyone else. They need support, and people to hold them accountable when they come across that ethically dubious line.

There’s no question that security research is a vital part of keeping our online world safe. But where do these researchers thrive? In what types of environments do they do their best work?

For many security researchers, it’s all about the community. It’s here where groups of like-minded individuals share information and ideas. And there are numerous online forums and newsletters where they can share ideas, debate techniques, and collaborate. In addition, there are conferences and in-person meetups to discuss the latest trends and challenges.  

By working together, they can pool their knowledge and resources, making it easier to identify and neutralize threats. In addition, the security research community provides a supportive environment for new researchers, helping them to develop the skills and knowledge that they need to be successful.

Today, the security research community is vast and diverse. It includes individuals from all walks of life, with varying levels of expertise. Some security researchers are full-time professionals, while others are hobbyists or students. But regardless of their background or experience, they all share one common goal: to find and report CVEs. That’s why we developed vsociety – for security researchers to share CVEs and gain communal support.

Of course, not all security researchers need or want to be part of a community. Some prefer to work independently, researching new vulnerabilities and developing innovative new solutions to exploits. For these researchers, the lack of community involvement can actually be a benefit, as it allows them to focus entirely on their work as they see fit. And, for that matter, not every community offers consistent, genuine support.

Take Twitter, where many security researchers gravitate due to a lack of good online communities. Twitter can be a great source of support, but it can also be a breeding ground for new threats. In recent years, we’ve seen several cases of hackers on Twitter developing and releasing malware that caused real-world damage.

Yes, social media intelligence can be a valuable asset for gathering insights on threats or contextualizing current research. But the information found on Twitter needs a thorough scrubbing for veracity and reliability.

Why? Because Twitter is rife with fake news and content disguised to harm organizations or people. The proliferation of misinformation requires security researchers on Twitter to always use keen judgment. But some activities on social media can fall in a gray area; meaning they may be illegal in certain jurisdictions but do not violate Twitter’s terms of service. If a security researcher runs with such information, they could be compromised..

Indeed, it’s more important than ever to find a cybersecurity community that nurtures “good faith” vulnerability hunting. After all, we’re on the verge of the new age in security research…

A New Catalyst for Good Emerges

Security researchers work tirelessly to find vulnerabilities in software and systems, and they report these bugs to the appropriate parties so they can be patched. Many of these researchers also participate in bug bounty programs, which offer rewards for finding and reporting security vulnerabilities. In other words, they get paid to hack systems and find weaknesses. Without security researchers, we would be living in a much less safe and secure world.

While bug bounties can be a great way to crowdsource security testing and build goodwill with the bug-hunting community, it can also be great for adding a misdemeanor (or worse) to your record. The good news is that the U.S. Justice Department recently directed prosecutors not to go after hackers under the Computer Fraud and Abuse Act (CFAA). But only if their reasons for hacking are ethical. Ethical reasons include bug hunting, disclosing CVEs responsibly, and above-board penetration testing.

This is huge news.

While some believe the new policy doesn’t go far enough to protect individual bug hunters, it does provide more freedom for security researchers to find and report CVEs without the fear of legal repercussions. Still, individual security researchers must mind the ethical gap. If they unwittingly cross a muddled line (made even more indecipherable by the policy’s bureaucratic speak), they could be met with legal consequences—making it all the more important for security researchers to learn how to apply caution and ethics in their bug hunting.

A Tribe Called Home

“In my career I’ve found few people are truly evil, most are just too far disconnected from the effects of their actions,” wrote Marcus Hutchins. “Until someone reconnects them.”

A good community – if it does its job well – can reconnect even the most ethically disconnected individuals. But it’s essential for everyone – from individuals to companies to government agencies – to do their part to improve cybersecurity. Whether it’s investing in better security tools or simply being more careful about what information is shared online, we all have a role to play. Our role is in building a community that security researchers may turn to for education, collaboration, and thought leadership.

As technology advances, so must the methods used to protect our data. Cybersecurity professionals are constantly working to stay ahead of hackers by developing new security measures and techniques. At the same time, security researchers are working just as hard to identify potential vulnerabilities in these systems so that they can be addressed before they can be exploited. As security professionals, we are constantly trying to stay ahead of the latest threats and vulnerabilities. We need to be able to quickly identify attacks, respond to them, and prevent them from happening again. To do this, we rely on security researchers who help us understand how attackers operate and what new techniques they are using. It is a never-ending race, but it is one that is essential to the safety of our digital world. And in today’s digital landscape, community plays a pivotal role in driving security researchers toward “good faith” vulnerability hunting.

There will be plenty more people like Marcus Hutchins. Some of whom discover the “dark side” and transition over to the “good side.” And others who discover the “dark side” and remain. With positive support from the right community, we can better steer the Marcus Hutchins’ of this world over to the good side of security research.

#security #community #ethics #hacking #hackers

There is common confusion about the difference between XSS (Cross-site scripting) and CSRF (Cross-site request forgery). 

In performing Cross-site scripting (XSS) attack, an attacker can execute a script within the browser of a victim user. While performing a Cross-site request forgery (CSRF) attack, an attacker can induce a victim user to perform actions they do not intend to.

These are the steps the attacker will perform to hijack the victim’s identity:

• Persuade a victim with social engineering techniques to click on the link sent in the mail, which will trigger a request to the targeted site. 
• After going to some website malicious request is triggered, the application will assume that it comes from a signed user. An attacker will perform a requested action without the user’s knowledge or consent.

Purpose of CSRF attack

Target is often to change server state and/or to gain access to sensitive data. When a CSRF attack is successful against the victim’s account, the attacker has the option to transfer funds, purchase a product, modify account settings, or any other action that the signed user could perform.

Example

As I mentioned, the attacker will try to persuade the targeted user to click on the link that will

send the request.

If the attackers were messing with DOM elements, they would use the href tag:

<a href="https://someUrlWithSomeParameters.com">Click for more details</a>

If the application has some filter restriction on navigation, and if the application is using POST requests attacker can try to use the form tag. They would create a form and, with JS, submit the POST request.

I found one simple example of adding a form on site Portswigger, and the code is below.

This example is the hidden HTML form that will, without user knowledge, create a post request. If the user was redirected to another site, this site could contain this hidden form to hijack the user identity.

Code in script tag will trigger submit of the form and send the request.

<html>

    <body>

        <form action="https://vulnerable-website.com/email/change" method="POST">

            <input type="hidden" name="email" value="pwned@evil-user.net" />

        </form>

        <script>

            document.forms[0].submit();

        </script>

    </body>

</html>

What are CSRF Tokens

CSRF tokens are used to protect from CSRF attacks. Tokens are unique and are created as a secret value generated by the server and sent to the client to be included in subsequent HTTP requests created by the client. 

How we prevent CSRF attacks using CSRF tokens

When the HTTP request is made, the server-side validates the request, including the expected token. If the token is missing or invalid, validation will not pass, and the request will be rejected.

So, when an attacker creates a request, it will not pass because the requests will not have all the required parameters. After all, the attacker can not guess the value of the CSRF token.

Tokens should be generated as session tokens should be. They should be unpredictable, PRNG (pseudo-random number generator) should be used, etc.

Where are CSRF tokens transmitted?

Synchronized token pattern

There is an approach to transmit the token in a hidden HTML form field. This approach is often called the Synchronized token pattern. This pattern presents the flow of setting a unique, valid token for each HTTP request and then checking that value when the HTTP request is subsequently sent. It is done by setting hidden fields.

Example

The token would then be added in post request on form submit. We can create a hidden input field with the value which is the value of the CSRF token, something like this:

<input type="hidden" name="token" value="valueOfCSRFToken" />

It is very important that the hidden field is loaded before any non-hidden fields in HTML, so the attacker cannot catch the field’s content.

The problem with using this approach is that hidden token needs to be implemented on all HTML forms in the application. Also, you would need to keep track of the valid tokens from the server side and check out each request if it is using a valid token. 

There is also a possibility to send CSRF tokens in a custom request header using a cookie-to-header token pattern.

Cookie-to-header token pattern

This is the second anti-CSRF technique. The cookie should be set once in the session. After JS reads the cookie’s content, a custom HTTP header should be set (X-CSRF-TOKEN or X-XSRF-TOKEN or XSRF-TOKEN) with that value from the content. Each request will send a header with the mentioned token (from custom HTTP header) and the cookie (from standard HTTP header), so the server can check if those two values match.

Now we can be confused if we don’t figure out the point of this approach. But no worries, it is not so clear without knowing its exact idea. The purpose of it is that only JavaScript, which runs on the same domain as the cookie domain, would have access. So, only JS with the same domain can set up the correct value of the cookie’s content to the custom HTTP header.

This approach would only work with JavaScript requests (XHR requests). So, requests that would be set up by HTML form would not set the header. 

Example (JavaScript):

The web application is using session, and it sets session cookies. You can check out the Session Management article for more information regarding the sessions.

In the HTTP response header, Set-Cookie will be visible if HTTP is used to send a cookie from the server to the client side.

Content would be token, maximum age, expiration date, and cookie attribute, and it would look something like this:

Set-Cookie: __Host-token=RANDOM; Expires=Mon, 01-Jan-2023 12:55:00 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure

It is essential to use cookie prefixes for a cookie with CSRF token value. This means that it can not be overwritten from another subdomain. The path should be “/.” And as you saw, it is marked as Secure, meaning it can not be sent over an unencrypted HTTP request. SameSite attribute helps the browser to decide if it should send cookies with cross-site requests. In this case, Lax is used; he is the default attribute. If you want to learn more regarding the SameSite attribute, check out this site.

When JavaScript (client side) reads a cookie, copy it to a custom HTTP header sent with each request. 

That would look something like this:

X-Csrf-Token: RANDOM

After, only validation of the token is left.

* The CSRF token cookie mustn’t have the httpOnly cookie flag! HttpOnly flag is used against XSS vulnerability because it makes the value of the cookie unavailable from JavaScript. So, you can conclude from the explanation that JavaScript will be prevented from reading X-Csrf-Token.

Double submit cookie pattern

There is the third pattern as the variation of the two mentioned patterns. This one puts the X-Csrf-Token value in a hidden form field but keeps the server-side logic simpler than the first pattern- The Synchronizer token pattern. This approach has some weaknesses, and you can check them on site.

Enabling CSRF in Angular

There is available Angular documentation for CSRF protection. 

First, you need to configure cookie/header names. To do that, you will need to import both HttpClientModule and HttpClientXsrfModule. In theory, it is easier to sync the names in the backend and frontend, but if you have different names on the server side, you can use the withOptions() method explained on this site.

  imports: [

      HttpClientModule,

      HttpClientXsrfModule.withOptions({

        cookieName: 'X-Csrf-Cookie',

        headerName: 'X-Csrf-Header',

      }),

    ]

In the mentioned documentation, you can find code that will help you test if your implementation is correct. 

Now we are left with intercepting requests and checking if the token in the cookie is the same value as it is in the HTTP request. In the code below, a custom interceptor class is created, which uses HttpXsrfTokenExtractor to get the token value so it can be compared.

@Injectable()

export class CustomHttpInterceptor implements HttpInterceptor {

    constructor(private spinnerService: SpinnerService, private toastrService: ToastrService,

        private httpXsrfTokenExtractor: HttpXsrfTokenExtractor) { }

    intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

        const cookieheaderToken = 'X-XSRF-TOKEN';

        let csrfToken = this.httpXsrfTokenExtractor.getToken();

        if (csrfToken !== null && !req.headers.has(cookieheaderToken)) {

            req = req.clone({ headers: req.headers.set(cookieheaderToken, csrfToken) });

        }

        this.spinnerService.show();

        return next.handle(req)

            .pipe(tap((event: HttpEvent<any>) => {

                if (event instanceof HttpResponse) {

                    this.spinnerService.hide();

                }

            }, (error) => {

                if (error.status == 400) {

                    this.toastrService.error("Warning", error.error.Error)

                } else if (error.status == 500) {

                    this.toastrService.error("System error occurred");

                }

                this.spinnerService.hide();

            }));

    }

}

Conclusion

 

I hope I succeeded with a simple explanation of this type of attack. If you want to further investigate the prevention or even how the attack is performed, there is plenty of literature on the Internet. I found a lot of GitHub repositories with app samples for this attack. I think it is very good to check them out, but if you want to clone them, make sure it does not contain malicious code!

OWASP is constantly upgrading its Prevention Cheat Sheet for the Cross-Site Request Forgery, so you should check that one also.

Good luck with your investigation!

In the end, secure code is the cheapest code!

Cover photo by Philipp Katzenberger

#CSRF #cookie_to_header_token_pattern #synchronized_token_pattern

Intro

Our goal here is to explain what SQL Injection means, how it works, and what types of SQLi exist. With so many applications talking on the internet, while also having some sort of database on the backend, SQL Injection is something you should always think of.

There’s too many production systems that are internet-facing, and if they have a database on their backend (which they usually do), you would probably want to mitigate this risk in any way possible.

 

What is SQL Injection?

SQLi, or short for SQL Injection is an attack on a database of a webapp. SQL Injection means that the malicious query gets executed – injected. This happens when we don’t validate properly, not sanitizing our user inputs, or not using stored procedures, for example. When we don’t do this, we allow the user input to be sent from their browser – or our webapp’s frontend – to the backend of the app, where the database lives, which then gets executed. The idea here is to have some sort of control, so that our app will evaluate the given input to see if it’s valid, before letting the query be executed. Ideally, if the input is not valid, it would just not let the user execute. If we don’t do this, we will be vulnerable to the SQL injection.

When this attack is successful, there’s a risk of stuff within the webapp database being deleted, altered, stolen, or used to further attack other areas of the application. SQL injection, even though its one of the oldest vulnerabilities, as you can infer, can be particularly devastating for us.

Let’s try and briefly illustrate how an SQL injection would look like, using one of the simplest types of SQL injection – in-band SQLi.

For example, imagine the query below should return personal data of the current user – call him user1, and display it:

SELECT * FROM users WHERE user_id LIKE ‘user1’

If we allow this query to be executed in our app, our attacker could simply say %’– which would in turn send the following query to our database:

SELECT * FROM users WHERE user_id LIKE ‘%’--’

Since in SQL the two dashes are used to comment out the rest of the line that follows, our app would actually execute the following query:

SELECT * FROM users WHERE user_id ‘%’

The percent sign in SQL is a wildcard, and the query above, when executed, would in turn display all the contents in the users table.

This is quite scary as you can see, and not at all complex to do. The example above is something that’s known as in-band SQLi.

Types of SQLi

There are three main categories of SQLi: in-band SQLi, blind SQLi, and out-of-band SQLi. Our example above used the in-band SQLi, but let’s try and explain these three types of SQLi a bit more.

In-band SQLi

This is the simplest of the three SQLi types; in-band means that our attacker, who is able to change the query to their liking, will get direct results of this changed query. Direct results implies they also get their results in the same way they performed the attack – if they did that with their browser, their browser would also display the results of the query.

Subcategories include error-based SQLi and union-based SQLi.

Blind SQLi

Contrary to the in-band SQLi, with blind SQLi we get no feedback, or very little response as to the success of the injected query. One of the most well known examples of the blind SQLi is the ‘ OR 1=1;– (which is also a subcategory of blind SQLi called Boolean SQLi). 1=1 is always a true statement, and when combined with the OR operator, this query will also be true, which can end up being enough for the logic of our web application that would in turn believe that it found a valid username/password combination, thus allowing access.

This can be used to bypass authentication – letting us through the login screen; login forms that are connected to the user database are often made in such a way that the application doesn’t really care what username/password is given to it, rather that the two are matched successfully in the respective table.

You can think of it as our application asking the database if there is such a combination of the username/password (not what the contents are) and the response from the database is either true or false. If true, we are granted access, and can login successfully.

Blind SQLi query could look something like this:

SELECT * FROM users WHERE username=’ ‘ and password=’ ‘ OR 1=1;

Two subcategories include: Boolean-based SQLi and time-based SQLi

Out-of-band SQLi

Not that commonly used, out-of-band SQLi needs specific features to be enabled on the database server, or in the web application’s logic, that would make an external network call based on the results of the given query.

The server would need to have commands that could trigger DNS or HTTP requests, otherwise we can’t do the out-of-band SQLi.

Further, there are two communication channels in out-of-band SQLi – one that is used to do the attack, and the other that would collect the results.

If, however, these conditions are met, what would happen is that the attacker could make a request to the website, with their payload, then the website/app would make an SQL query on their behalf, which gets passed to the database (the payload is passed too), and finally, the payload has a request inside it that forces the database to send back an HTTP request to the attacker’s machine – containing the results.

 

Preventing SQLi

Some of the best ways to prevent SQLi is to use, prepared statements (parametrized queries), input validation, and escaping user input.

Prepared statements (parameterized queries) – the only fully effective way to prevent all types of SQLi in web apps. (If your language doesn’t support parameterized queries but your database does, you can use stored procedures instead).

We must note that even though input validation and escaping user input can help you against SQLi, these methods are not completely bulletproof and the attacker might still find a way around them.

Conclusion

We hope that this short primer on SQLi has brought the topic closer to you. The main takeaway here (we feel) is the fact that avoiding this specific vulnerability should mostly depend on your developers, specifically, crafting the appropriate prepared statements/parameterized queries as this is the best approach – since it eliminates the vulnerability alltogether. Without it, your filters, blacklisting, or other controls, are just bigger obstacles, but not the full solution.

#SQLi #blind #in-band #out-of-band

In my last post, I talked about what makes the UK National Cyber Security Centre (NCSC) unique – and a valuable model of national cybersecurity for others to follow. I highlighted a recent report from the NCSC that explores their success with Active Cyber Defence (ACD): where they hunt down and face off against threats to make the cyber landscape safer for all. That report has too many interesting insights to contain in just one post – so I promised to write another. Here’s what I didn’t cover before that I think readers will want to be aware of.

Offense is the Best Defense

One of the signature services of the NCSC goes on the offensive to remove “bad stuff” hosted on the internet: extortion mail servers, fake eCommerce stores, phishing URLs, web shells, and quite a bit more. Kind of like internet cops, they patrol around for any criminal activities trying to ensnare the public and shut them down (hopefully) before anyone gets harmed.

Of course, cleansing the internet is an impossible and overwhelming undertaking for any team, but the impact of the NCSC is impressive nonetheless.

In total, it took down 2.7 million campaigns spread across 3.1 million bogus URLs in 2021. And while that may not sound like much on the grand scale of the internet, these takedowns are still significant. Consider, for example, phishing scams that used the UK government as a lure. These scams are very effective and potentially devastating. But thanks to the NCSC, there are 11,000 fewer active campaigns, and the median availability of attacks dropped by 30%. I call that progress.

The NCSC claims that in the 5 years it has been running the ACD program, the UK share of global phishing attacks has been cut in half, and the lifecycle of commodity attacks has shrunk significantly. Those results make a compelling argument in favor of offensive cybersecurity tactics, for one, and carrying out those tactics at the federal level, for another. As the NSCS says itself, “Our continued hope is that other nations, National CERTs, and other organizations employ similar services to amplify the effect of this work.”

Security Comes From Community

Something else that strikes me as unique about what the NCSC does is its emphasis on community involvement and proactive reporting. Users can provide suspicious emails or URLs for the NCSC to check out. Those tips, in turn, inform the comprehensive threat intelligence that the NCSC provides to organizations across the UK.

I think that’s a powerful model for others to follow: where threat intelligence comes from the bottom up (or perhaps the front-lines backward), and then guidance, support, and services are delivered from the top down. The security apparatus works similarly in other aspects of society – we report suspicious activities to the police or call out unusual activities in the airport – but it has yet to really expand into the realm of cybersecurity. Most would agree that needs to change, and the NCSC shows us why and how.

Whether at the federal level, the individual level, or anywhere in-between, cybersecurity benefits from community and suffers from isolation. The more that people report red flags and share intelligence, the faster we neutralize attacks. And the more that we approach cybersecurity as a shared priority and cooperative endeavor, the more we build an insurmountable advantage against hackers. I know this might sound sentimental. But I firmly believe that cybersecurity only works collectively. The NCSC seems to agree.

Granted, other federal cybersecurity agencies, including those in the US, have mechanisms for reporting possible threats and distributing threat intelligence. The UK isn’t alone in that regard. But through some combination of accessibility and outreach, the NCSC has gotten people onboard with cybersecurity in ways that should make other governments envious. As they say in their own report, active cyber defense is a “team sport.”

I couldn’t agree more.

#cybersecurity #UK #NCSC #CISA #InfoSec

Whoa, nelly! Eight vulnerabilities have been added to CISA’s Known Exploited Vulnerabilities Catalog. We have remote code execution, privilege escalation and the complete compromise of Confidentiality, Integrity and Availability of a system. Let’s dive into a few and see what smarter people than I have to say. Resources will be at the bottom and linked throughout the piece.

CVE-2022-32894 and CVE-2022-32893: CWE-787, Out-of-bounds Write.

Can’t flip on the TV to get your daily dose of social, cultural, and environmental decline without some talking head getting the newest Apple vulnerabilities in your existential dread. What gives? Well, 32894 allows an attacker to escalate privileges via a local application. This local application triggers an out-of-bounds write error allowing the execution of arbitrary code with kernel privileges. 32893 “is a boundary error in WebKit when processing HTML content.” If a user opens a malicious website created by a remote attacker, an out-of-bounds write is triggered which executes arbitrary code.

Apple users need to update Monterey.

CVE-2022-22536: CWE-444, HTTP Request/Response Smuggling or Memory Pipe Desynchronization per Tenable.

This one received a perfect CVSSv3 score of 10.0 and affects SAP NetWeaver Application Server ABAP, SAP NetWeaver Application Server Java, ABAP Platform, SAP Content Server and SAP Web Dispatcher. Per an Onapsis threat report that is available to download on their website, the vulnerability appears

…when an internal handler is able to generate a response, and the size of the request is bigger than that of the MPI Buffer. If a proxy is placed between the ICM and the clients, an attacker could leverage this to take over the application by exploiting the HTTP desynchronization between both components.

SAP users can access a patch via their account.

CVE-2022-2856: CWE-20 Improper Input Validation.

This one is fun since it fits the theme of a couple articles that a user has been posting recently and it’s another Google Zero Day! We don’t know much more than this tidbit found on Google’s blog: “insufficient validation of untrusted input in Intents.” Presumably we’ll know more once the update has had a chance to make it around.

Chrome users need to install the recent update.

Sources that were not linked above:

https://www.cybersecurity-help.cz/vdb/SB2022081718

https://onapsis.com/threat-report/icmad-sap-vulnerabilities (downloads the PDF)

#CISAnalysis #apple #google #rce #cisa #zeroday