Web Vulnerabilities of 2020

Feb - 16

Web Vulnerabilities of 2020


Before we get started talking about those vulnerabilities we'd like to take a step back and talk about why we need this webinar. Our goal is to keep you aware of the risk involved in running a digital service in 2020.

TrueFire at the beginning of this year five months' worth of credit card data was stolen and then we move on to Wawa which was later in January. 30 million payment cards were stolen. Virgin Media was 900,000 UK-based customers' information that was compromised. Marriott International also had the personal information of 5.2 million hotel guests. As we go through you can see in early spring we had EasyJet email and travel details of nine million customers compromised. And finally, we have the blue leaks which were US police and FBI information. It was a leak of 269 gigabytes

Data Breach Damages Customer Trust Reputation Legal Fines

As you can see here Equifax had to pay almost 600 million in fines and also lost its customer trust as a result of the 2017 data breach. Capital One and British Airways were also fined millions of dollars as a result of their 2019-2018 data breaches. So we can�t stress enough that it is very important to address your cyber-security risk when your company stores or processes personal and or sensitive information.

What are vulnerabilities

So what are vulnerabilities? Vulnerabilities or system weaknesses that represent a business risk to your organization. An unpatched vulnerability may lead to a data breach. In the case of Equifax, it was a publicly reported but unpatched Apache Struts vulnerability that led to that system compromise. Vulnerabilities may relate to a software product that your organization uses but does not necessarily maintain. Recently while conducting a penetration test for one of our clients White Hack Labs discovered a vulnerability in a well-known accounting vendor software and it would have had a negative impact on their business as a whole. Please keep an eye out we'll be publishing those findings later this month.

Web Vulnerabilities of 2020

The agenda for this webinar that Pasha is going to cover is going to be five recent vulnerabilities that are relevant in 2020. We'll start with HTTP request smuggling, serverless vulnerabilities, remote code execution in Apache Spark, remote code execution in CMS, and hidden property attack and node.js ecosystem.

HTTP Request Smuggling

HTTP request smuggling has been around since 2005, but there are new variations of exploits that exploit the same vulnerability that is coming out. For example in 2019 a security researcher was able to successfully exploit HTTP request smuggling on paypal.com he reported to PayPal and PayPal and patched it immediately. However, to demonstrate that he could exploit it he could successfully get another user's credentials on the paypal.com website. And the only condition is that the neighboring user had to use paypal.com at the same time as he did.

Jason: So does this mean in that example that if I was a neighboring user an attacker could access my data and what exactly would be compromised?

Pasha: It would be possible to get your PayPal credentials, access your PayPal account, initiate financial transactions, and get your account activity. So anything within the scope of what a PayPal account allows you to do

There are a few conditions that are needed for this vulnerability to be exploitable:

  1. The website infrastructure should contain a front end and a back end and usually, it's a proxy and a web server.
  2. The proxy and the webserver should understand the content length of the request differently based on two headers (a) content length and (b) content type.

The opportunity for this vulnerability arises out of different web services and proxies not adhering to the same RFC standards. So when the front end thinks that the request is a little bit longer and the back end thinks that the request is a little bit shorter it's an opportunity for an attacker to smuggle some text into the neighboring user's request.

As you can see on the image here to the bottom right that orange piece of text has been smuggled into the request to the neighboring user. In the same way, an attacker can get some text out of the neighboring user's request and that's how he can get credentials to paypal.com.

Serverless vulnerabilities

Serverless technology is generally more secure because it limits the scope of what an attacker can do once he is able to successfully execute his code in your application. While doing a penetration test for a client of ours we discovered that authorization was missing. We were able to register a customer account on our client�s platform and start accessing the resources of other users. It was a confidentiality impact on their business and this vulnerability could be classified under broken access control. As you see S5 is on the list to the right. There are other types of vulnerabilities serverless applications are vulnerable to, like an injection.

If you are using AWS for your serverless app, you might be using AWS Lambda functions. But the code of these Lambda functions still needs to be checked because if they're written improperly, for example, if they can contain eval statements, an attacker could smuggle some JavaScript code in its request and that code could be executed by that eval statement.

Now to continue in the exploit chain, if your serverless application also has security misconfiguration and your Lambda function role has access to the S3 bucket and, for example, the S3 bucket stores configuration for your Kubernetes cluster that also stores the base64-encoded credentials to that Kubernetes cluster. An attacker, by using those two exploits, injection and security misconfiguration could first execute its code using a Lambda function and then have your Lambda function access that S3 bucket using AWS API and extract those credentials. As you can see, the vulnerability by itself may not represent a big risk but a combination of them can lead to serious consequences.

Remote Code Execution in Apache Spark

Moving on to the next type of vulnerability. That type can be only executed in traditional environments, not serverless. Remote Code Execution Apache Spark. Remote code execution in general is what results in a data breach. It's when an attacker can execute its code on your server. It can then use that to overtake your server, escalate privileges, and even move laterally in the network. That's exactly what happened with Equifax. They initially compromised [Equifax�s] unimportant customer service portal through an Apache Struts vulnerability and then they were able to move laterally onto a core application that contained all the social security numbers.

So, it's very important to be aware of any RCEs or Remote Code Execution vulnerabilities that are coming up and track them and patch them in time. in Equifax's case, they weren't able to patch the vulnerability in time after it's been public for some time and that's what caused the data breach. Moving on to Apache Spark, it's a little bit different than Apache Struts. Apache Spark 2.4.5 or older allows attackers to bypass authentication by sending a specifically crafted remote procedure call (RPC) and, eventually, once they bypass authentication, they can launch application resources into the cluster, and they can execute code on the host. That again leads to other consequences that I mentioned before.

Remote Code Execution in CMS Platforms

Moving on to the next type of vulnerability. It's a code execution in content management systems (CMS) and one big difference from the previous one we talked about is that this vulnerability has a condition. An attacker should be in control of your CMS templates. Without control of your CMS templates, they won't be able to exploit this vulnerability at all. It puts a lesser risk on this one compared to the previous one. Most of the java-based and .net-based content management systems are affected. Here you can see a couple of examples on the right. In an image, to the center, you can see an example of remote code execution through the template. This piece of ASP code that is actually executable in a template will launch a calculator app on a Windows server that hosts this content management system. In this example, it's a SharePoint.

So if attackers can smuggle their code into your template, they can get different applications started on your Windows computer host. Example at the top you can see an attacker could output the contents of web.config file and that config file contains multiple keys like a verification key. If they get their hands on verification keys they can then move on to a remote code execution exploit.

Jason: Interesting, can this allow one of our customers' databases to be compromised?

Pasha: Yeah, so once attackers got control of the host and can execute their code on the host, there is a very high chance they could get their hands on the data. Depending on what the application does they could also do what the application does.

For example, if your application processes health information and attackers could change the health records of patients that could affect the lives of those patients because doctors would read that information differently and make different decisions about how to treat the patient.

If your application processes financial transactions and attackers would have the same scope of control which they could send funds to a different destination.

Jason: would this give them access to one of our customer servers?

Pasha: Yeah, that's what remote code execution practically is. It's executing their code or getting access to the server.

Hidden Properties Attack on Node.js Ecosystem

That type of attack can allow attackers to manipulate your application logic, get confidential data, bypass security checks, and even launch denial of service attacks (DoS). It relates to how node.js processes your requests. When node.js processes any input from the outside as part of the request it converts it into a JavaScript object with properties. It gives attackers the ability to form that JavaScript object. And if the application uses this object, and doesn't destroy it immediately, but continues using it through the application logic, it's possible for an attacker to change how the application functions. It also applies to prototype properties that are in __proto property of the JavaScript object.

So, if I'm sending JSON and I have __proto as part of the parameters, it will be converted to a JavaScript property; a prototype object. So an attacker has pretty huge leverage on the structure of the subject, and again if your application relies on this object [application�s] logic could be changed and an attacker could either bypass security checks or get some confidential data out of it. To prevent this, it's important to review your node.js code to make sure your application doesn't rely on those properties.