Web Vulnerabilities of 2020

Feb - 16

Web Vulnerabilities of 2020

Before we get started talking about those vulnerabilities um 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. fire i was uh beginning of this year it was five months worth of credit card data that was stolen um and then we moved on to wawa that was later in january 30 million payment card stolen we moved through to virgin media it was 900 000 uk based customers information that was compromised marriott international also had personal information of 5.2 million hotel guests as we go through you can see in spring uh early spring we had um easyjet email and travel details of nine million customers compromised and finally we have the blue leaks which was the us police and fbi information uh was a leak of 269 gigabytes as you can see here equifax had to pay almost 600 million in fines and also lost their customer trust as a result of the 2017 data breach capital one and british airways were also finding the millions of dollars as a result of their 2019-2018 data breaches so we can stress enough that it is very important to address your cyber security risk when your company stores or processes personal and or sensitive information all right so what are vulnerabilities vulnerabilities or system weaknesses that represent 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 struck vulnerability that led to that system of 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 and please keep an eye out we’ll be publishing those findings later this month okay so 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 or content management system and hidden property attack and node.js ecosystem http request smuggling has been around since 2005 but there are new variations of exploits that exploit the same vulnerability that are coming out for example in 2019 a security researcher was able to successfully exploit uh http request smuggling on paypal.com he reported to paypal and paypal and passed it immediately however to demonstrate that he could exploit it he could successfully get another user’s credentials on paypal.com website

and the only condition is that that neighboring user had to use the paypal.com uh at the same time as he did

so does this mean that um in that example that if i were a neighboring user an attacker could access my data and uh what exactly would be compromised

it would be possible to get your paypal credentials access your paypal account and initiate financial transactions and get your account activity so anything within the scope of what paypal account allows you to do

moving there are a few conditions that i needed for this vulnerability to be exploitable number one the website infrastructure should contain a front end and a back end and usually it’s a proxy and a web server number two the proxy and the web server should understand the content length of the request differently based on two headers content length and 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 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 request and that’s how he can get credentials to paypal.com

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 have discovered it was for a serverless application we have discovered that authorization was missing

we were able to register a customer account on our clients platform and start accessing resources of other users it was a confidentiality impact to their business and this vulnerability could be classified under broken access control as you see s5 on the list to the right there are other types of vulnerabilities serverless applications are vulnerable too like injection

if you are using aws for your serverless app you might be using aws lambda functions but the code of this lambda function still need 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 his request and that code could be executed by that evil statement now to continue in the exploit chain if if your serverless application also has security misconfiguration and your lambda function role has access to s3 bucket and for example the ss3 bracket stores configuration for your kubernetes cluster that also stores the base64 encoded credentials to that kubernetes cluster and attacker by do by using those two exploits injection and security masking configuration he could first execute his code using a lambda function and then have your lambda function access that s3 bucket using aws api and extract those credentials so as you see vulnerability by itself may not represent a big risk but a combination of them can lead to serious consequences moving on to the next type of vulnerability and 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 his code on your server he 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 their unimportant customer service portal through an apache spark 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 rc or remote code execution vulnerabilities that are coming up and track them and patch them in time in equifax 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

so moving on to apache spark uh it’s uh it’s a little bit different than apache struts uh apache spark 2.4.5 or older allows an attacker to buy path authentication uh by sending a specifically crafted remote procedure call

and eventually once he bypasses authentication he can launch application resources into the cluster and he can execute code on the host that again leads to other consequences that i mentioned before moving on to the next type of vulnerability it’s a code execution in content management systems and one big difference from the previous one we talked about is that this vulnerability has a condition uh an attacker should be in control of your cms templates without control of your cms templates he won’t be able to exploit this vulnerability at all so it’s it’s it puts lesser risk on this one compared to the previous one um and most of the content mesh java based and net based content management systems are affected

here you can see a couple of examples on the right in the 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 sharepoint in this in this example it’s a sharepoint

so if an attacker can smuggle his code into your template he can get different applications started on your computer only on a windows computer host one example to the top uh you can see an attacker could output the contents of web.config file

and that config file contains uh multiple keys like a verification key if you get his hands on verification he he can then move on into a remote code execution exploit it’s interesting um can this allow one of our customers databases to be compromised yeah so once an attacker got control of the host and able to execute his code on the host there is a very high chance he could get his hands on the data um depending on what application does he could also do what the application does for example so if your application processes health information and an attacker could change the health records of patients that could affect the life of those patients because doctors would read that information differently and make different decisions of how to treat the patient if your application processes financial transactions and an attacker would have the same scope of control which he could send fonts to a different destination

right and would this give them access to one of our customer servers

yeah that’s what remote code execution is practically is it’s it’s gaining executing his code or getting access to the server 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

and it relates to how node.js processes your requests when node.js processes any input from from the outside as part of the request it converts it into a javascript object with properties so it allows an attacker to an ability to form that javascript object and if application uses this this object doesn’t destroy it immediately but continues using it along the application logic it’s possible for an attacker to change how the application functions it also applies to prototype properties that are in underscore underscore proto property of the javascript object so if i’m sending json and i have underscore underscore proto as part of the parameters it will be converted to a javascript property a prototype object so an attacker has a pretty huge leverage on object on the structure of the subject and again if your application relies on this object it will be it its logic could be changed and an attacker could either bypass security checks or get some confidential the 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.

Leave a Reply

Your email address will not be published. Required fields are marked *