STOP! IDENTIFY YOURSELF! A call to all third-party vendors
The Source Defense security platform is deployed on multiple websites, preventing Formjacking attacks in real-time and gathering data that is used by our teams to identify risky trends. Recently, we came across a dangerous shortcut used by some third-party vendors that created an unnecessary security risk that has continued to grow daily. In fact, we found that it was already used to compromise at least 17,000 websites!
In this article, I will explain the details of the shortcut, why it created such a security risk, and how it can be prevented with a few easy steps and at a minimal cost.
But first, let’s start at the beginning.
What is Formjacking?
Formjacking (AKA Magecart attacks) is when cybercriminals inject malicious JavaScript code to hack a website and take over the functionality of the site’s form page and collect sensitive user information. These JavaScript skimmers are designed to steal PCI and PII information from forms that can be captured on the checkout pages of websites.
These skimmers are most commonly introduced to the user’s web session via external JavaScript services such as marketing, analytics, optimizations, and other external tools used by websites to enhance the user experience and increase user interaction and website monetization.
This (not so new) attack vector created a new challenge for security teams as it was not covered by any of the existing countermeasures used today, simply because this attack happens on each user’s browser with no attempt to breach the websites’ web server.
Since all conventional security countermeasures are focused on protecting the websites’ servers, this became one of the most popular vectors on sites. A second reason for the growing popularity of Formjacking by hacker groups is the fact that once you managed to infect one external service providers with a JavaScript skimmer, you effectively infected all of their customers and their users.
This means that one successful hack can compromise hundreds or even thousands of websites.
Fighting Formjacking
As Formjacking gained popularity, security companies started taking it more seriously, and today there is more than one way to tackle this problem, the three most commonly used approaches are –
- Content Security Policies (CSP) – is the name of an HTTP response header that modern browsers use to enhance the security of the document (or web page). The Content-Security-Policy header allows you to control the origin of resources such as – JavaScript, CSS, or pretty much anything that is on the browser, using a whitelist methodology
- JavaScript Proxying – is a method that can be utilized in the browser that allows an overwrite of some of the JS prototypes; for example, you can overwrite the input.get.value prototype and decide if you want to allow it or not based on the actual value in the field
- Real-time JavaScript Sandboxing – is a method that isolates external resources from the page in virtual pages, reflecting in real-time elements that are necessary for the proper function of the service and redacting anything that could be considered PII or PCI
Know your partners (and enemies)
No matter which approach you decided to go with or how you chose to implement it, the one thing they rely on is the need to identify script vendors and operations on the page.
As is probably evident by the names and descriptions of the mitigation options, they are all (to an extent) policy-based. From setting a policy that whitelists origins of resources on the page to controlling actions in the most granular level possible, knowing who did what is critical; In fact, it is the only way to avoid breaking the page by preventing a legitimate action.
In a web session, the best (and probably only) way to identify a service is by the domain it loads from, which is why almost any vendor will have one or more recognizable domains they use to load resources.
Take Google, for example; any Google service will load in one of two methods –
- A domain holding the service name (Like Google Analytics, or Google Tag Manager)
- A general Google domain used for resources called Google API’s (like Google Maps)
Technically this is easy enough to do; Google has bought these domains and mapped them to the CDN services they use, a process that takes minutes, you don’t need to be Google to do it, and not surprising it is used by most vendors today.
Now, consider CSP. If you use any of these Google services, you will need to whitelist these domains to load scripts, load CSS, create iframes, and more. If you fail to whitelist one of these domains, you risk anything from breaking the specific service, to breaking the page (depending on the service); This is true in any policy-based platform.
Back to the beginning
Now that we know more about FormJacking and how we fight it today, let’s go back to our original storyline. While reviewing the logs and new scripts identified on a major commerce website, we found a service that uses a general hosting service to pull their resource to the page.
In this case, the service was S3 by Amazon; this means this service forgoes the process of creating an identifiable subdomain mapped to a hosting service. It also means that if the website wants to allow this service to operate, they will need to create a policy that includes anything loading from Amazon’s S3.
To understand the significance of this, we need to also take into consideration that Hackers would much rather use S3 buckets and other commercially trusted CDNs when possible to avoid having their origins blacklisted by security services, just last year a FormJacking JavaScript skimmer was found on multiple S3 buckets and was proven to infect over 17K websites.
Our immediate response was to recommend the website will block this service while contacting the service provider to remedy this oversight. Still, we were also curious how common this might be and decided to do some research into how common this shortcut is. Analyzing data taken from just over 1K commerce, finance HMO websites, and spanning over 500 third-party service providers. We were happy to find that the majority of service providers will stay true to the industry standard and create a recognizable name for their resources. Only 22 service providers did not follow this best practice and loaded their resources directly from CDN or hosting providers such as Cloudflare, Amazon S3, and others.
A surprising discovery was that contrary to an internal theory, these service providers were not startups just starting out, but for the most part, vendors that have been in business for years and for some reason have not adopted this practice.
What should you do?
If you are a third-party vendor, make sure all of your resources are loaded from your own domains and not global CDN and hosting buckets.
If you are a website owner, never whitelist a general CDN or hosting service in your policies, the risk is too high, demand from both your vendors and your internal development teams to work only with registered domains.
To get a free risk assessment of your website, fill a request here
The post STOP! IDENTIFY YOURSELF! A call to all third-party vendors appeared first on Source Defence.
*** This is a Security Bloggers Network syndicated blog from Blog – Source Defence authored by Avital Grushcovski. Read the original post at: https://sourcedefense.com/resources/blog/call-to-all-third-party-vendors/
