Guest Post By Brad Bussie of Trace3
Brad Bussie is an award winning sixteen-year veteran of the information security industry. He is an author, security strategist, and industry thought leader. He holds an undergraduate degree in information systems security and an MBA in technology management. Brad possesses premier certifications from multiple vendors, including the CISSP from ISC2. He has a deep background architecting solutions for identity/access management, vulnerability management, governance, risk, and compliance. Brad has spoken at industry events around the globe and has helped commercial, federal, intelligence, and DoD leaders solve complex security problems.
Internet facing applications are more vulnerable than ever. Organizations have spent countless resources securing the perimeter, strengthening web servers, and establishing vulnerability management programs. Why then do application vulnerabilities continue to be the gateway attackers use to compromise? When the applications are scanned internally the code shows clean and all the latest patches are applied. However, the applications are still vulnerable to something many organizations often overlook – third party vendor scripts. It is important to differentiate server side vulnerabilities vs. client side vulnerabilities. Server side vulnerabilities are generally defended against by traditional security controls like securing the server and the application platform. Client side vulnerabilities, on the other hand, are where attackers are spending time in the unsecure and unmanaged white space between browsers and third parties. Terms like Magecart, Formjacking, and Clickjacking litter unknown recesses of the internet. Third party risk is real and attackers are ahead of the game and leveraging relatively unknown techniques to cause the next wave of data breaches. The good news is that there are several things that organizations can do to detect and protect against the next wave of third party compromise.
What attacks are we looking at?
There are two primary attacks of interest when analyzing third party risk to websites; Formjacking (which has made headlines with the hacker group known as Magecart), and Clickjacking.
Formjacking – primarily targets banking and ecommerce because of the plethora of customer personal information exchanged with the sites. Think of Formjacking like a virtual adaptation of card skimming. A website infected with Formjacking captures data in real time and sends it off to attackers from the client side.
Magecart – finds its roots in supply chain attacks. Magecart represents a malicious hacker group that targets online shopping carts to steal customer information, typically credit card or personally identifiable information. These are spread through widely used third-parties and rely on their popularity to get to as many websites and users as possible.
Clickjacking – is insidious in the way that it tricks users into clicking on something that they are unable to see. Think of a website button as a layer on the page. Clickjacking infected sites layer on top of seemingly safe buttons and inject malicious code that can perform a wide range of attacks without the user realizing, in some cases simply creating a registration form on top of the website itself, simulating the site’s own form.
Traditional security methods are unable to defend against these types of attacks because they are browser based. A Web Application Firewall (WAF) is great for protecting against attacks designed specifically against servers and the application itself. The challenge with Formjacking and Clickjacking is that they occur on the client and are virtually invisible to the server side protection. Sure, Content Security Policy (CSP) offers a level of protection but often require more information then administrators have and tend to drift after initial configuration due to the dynamic nature of trusted sources. While you can use CSP to whitelist controlled resources such as your own website. So many attacks come from trusted sources and third parties it makes CSP a non efficient use case for protection. Many vendors are relying on 4th parties such as CDN’s and other providers. In the latest Magecart attack, the use of domains that are generally whitelisted by CSP, such as CDN’s, Amazon S3, and Haruko.
How to protect your website and customers’ data?
In discussing 3rd party vulnerabilities, how does an organization go about protecting against such attacks? Server-Side Protection is critical to an overall cybersecurity program, but an often overlooked ingredient is Client-Side Protection. Whitelisting and Blacklisting is no longer enough. There are several best practices to consider with Client-Side Protection.
- Remove DOM access as it is often the root cause of browser based attacks
- Understand what scripts are running and detect ones that are malicious
- Look for changes in client side libraries
A platform like the one offered by SourceDefense is purpose built to protect against Client-Side attacks and bolster third party plugins against malicious parties. SourceDefense sets themselves apart from traditional security approaches by implementing real time sandbox isolation and reflection technology to provide unique client-side security solutions focused on preventing malicious attacks originating from third party vendors, plugins, and applications. With its unique focus on Supply-chain security, SourceDefense leverages machine learning and industry best practices to dynamically control access and permissions to all third party plugins operating on your websites.
What to expect in 2020:
We are in the midst of a true Digital Transformation. The year 2020 will be the precursor to new ways of defending against attacks. Data Privacy will continue to be debated and other states will follow what California is doing with the California Consumer Privacy Act (CCPA). We will, however, see an increase in:
- Attack sophistication – every day it gets harder to prevent Client-Side attacks with a dedicated solution. Many companies out there claim to do this as a feature of what their core product does when in fact, this is something that should be standalone in alignment with your security stack
- Attack automation – we will see more compromises and more risk before the year is done
- Awareness / organizational accountability – more companies like Macy’s will find themselves exposed and violating Payment Card Industry (PCI) compliance and General Data Protection Regulation (GDPR)
Imagine you are signing up for health insurance next year or applying to purchase a vehicle. There are dozens or potentially hundreds of companies leveraged on the website you are applying through. The companies may be providing analytics, widgets, plugins, or live feeds. They proudly bear the insignia of protection via a leading WAF. The important question you have to ask yourself is: with so many 3rd parties on the website – do you really feel comfortable putting in your credit card information?
What can you do next?
- Work with your web team to learn about your client-side security measures
- Be cognizant of the news – are you a competitor or similar company as Ticketmaster or British Airways…because they had major breaches and you want to make sure you are aware of these breaches for your own protection
- Know your weaknesses – download your website vulnerability report
- Stay ahead of the curve! Don’t wait until an attack has crippled your brand and bottom line – identify and address risks early, deploy IT resources efficiently, and protect environments and data prudently.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.
