The continuing wave of attacks by cybercriminal groups known under the umbrella term Magecart perfectly illustrates just how unprepared many e-commerce operations are from a security point of view. It all really boils down to timing. If the e-commerce world was able to detect such Magecart attacks in a matter of seconds (rather than weeks or months), then we could see an end to Magecart stealing all of the cybercrime headlines.
What steps can organizations take then to mitigate against this method of cyber attack? Let’s delve deeper.
Assess your degree of client-side visibility
To avoid the hindsight is 20/20 syndrome, a key first step is understanding how aware you are of what your users are actually getting when they visit your e-commerce platform. You may think that every user will get an identical, safe-to-use version of your website when, in fact, some users may be interacting with compromised web pages and hijacked forms.
It might surprise you to learn that neither business owners or security teams seem to have a definite answer here.
For far too long now, there has been a spotlight on server-side security. Consequently, just about everything that happens on the client-side (for example the browser and the environment where Magecart attacks thrive) is generally overlooked. Based on the information we have gleaned from previous Magecart attacks, it is obvious that there is no sure-fire way of preventing these types of attacks completely. However, a good place to start is to shift our focus and prioritize what is happening on the client-side.
The average Magecart attack remains undetected for 22 days and it only took 15 days for attackers to steal 380,000 credit cards during the British Airways breach. That’s 18 credit cards per minute. This is how you should look at this threat: each minute that goes by while there’s an undetected skimmer on your website means a growing critical business problem.
Third parties are your weakest link
Various Magecart groups use different strategies to breach e-commerce websites. However, most go after the weakest security link: they avoid breaching your servers and prefer delivering malicious code to your website through third parties.
Nearly all websites use one or more third-party solutions: a live chat widget, an analytics tool, or an accessibility service. By doing so, companies end up having almost no control over the security of this externally sourced code. When attackers breach one of these third parties and inject malicious code, this code very easily bypasses firewalls and browser security mechanisms because the attack originates from a source that is trusted by default – in this case, a legitimate third-party supplier.
It’s crucial that you make sure that your business is scrutinizing third-party code and also its supplier’s level of security. Sadly, though, this is not something companies prioritize, as they are concentrated on product development.
And while many businesses are only just now learning about Magecart web skimmers, these skimmers are far from being the first iteration. Over time, skimmers have evolved to include obfuscation techniques to conceal their malicious code and even go as far as using defense mechanisms to avoid being detected by bots, rendering many detection options useless.
Taking decisive action to detect and control Magecart web skimmers
An ever-evolving security mindset is needed here. Businesses should find ways to quickly detect these injected skimmers and swiftly block Magecart attacks. This is preferable to solutions that prevent malicious (unpreventable) code injections.
Whilst third-party management and validation play a good part, they alone are not enough. The key is to look for malicious behavior.
We know that a skimmer always displays at least one sign of malicious activity. For example, a known script like a live chat has no business interacting with a payment form (formjacking). If that happens, it’s an indicator that something may be wrong. Also, if we start seeing a new script appearing in some user sessions, that is also something that warrants further analysis. Sure, it could be harmless – but it could also be a skimmer. Similarly, a network request to a previously unknown domain may be an indication that attackers are trying to exfiltrate data to their drop servers.
It is precisely here where most businesses are deficient. Not only do companies lack client-side visibility, but they also lack proper detection and control capabilities. Taking decisive action against web skimming means being able to detect and control any malicious activity on the client-side in real-time. To this extent, consider a web page monitoring solution, as it brings real-time visibility of malicious code and provides a more effective Magecart mitigation approach.
The global pandemic has seen the web take center stage. Banking, retail and other industries have seen large spikes in web traffic, and this trend is expected to become permanent.
Global brands fail to implement security controls
As attackers ramp up efforts to exploit this crisis, a slew of high-profile attacks on global brands and record-breaking fines for GDPR breaches have had little impact on client-side security and data protection deployments.
In many cases, this data leakage is taking place via whitelisted, legitimate applications, without the website owner’s knowledge. What this report indicates is that data risk is everywhere and effective controls are rarely applied.
Key findings highlight the scale of vulnerability and that the majority of global brands fail to deploy adequate security controls to guard against client-side attacks.
This website supply chain leverages client-side connections that operate outside the span of effective control in 98% of sampled websites. The client-side is a primary attack vector for website attacks today.
Websites expose data to an average of 17 domains
Despite increasing numbers of high-profile breaches, forms, found on 92% of websites expose data to an average of 17 domains. This is PII, credentials, card transactions, and medical records.
While most users would reasonably expect this data to be accessible to the website owner’s servers and perhaps a payment clearing house, the analysis shows that this data is exposed to nearly 10X more domains than intended.
Nearly one-third of websites studied expose data to more than 20 domains. This provides some insight into how and why attacks like Magecart, formjacking and card skimming continue largely unabated.
No attack is more widespread than XSS
Standards-based security controls exist that can prevent these attacks. They are infrequently applied.
Unfortunately, despite high-profile risks and the availability of controls, there has been no significant increase in the adoption of security capable of preventing client-side attacks:
- Over 99% of websites are at risk from trusted, whitelisted domains like Google Analytics. These can be leveraged to exfiltrate data, underscoring the need for continuous PII leakage monitoring and prevention. This has significant implications for data privacy, and by extension, GDPR and CCPA.
- 30% of the websites analyzed had implemented security policies – an encouraging 10% increase over 2019. However…
- Only 1.1% of websites were found to have effective security in place – an 11% decline from 2019. It indicates that while deployment volume went up, effectiveness declined more steeply. The attackers have the upper hand largely because we are not playing effective defense.
Your payment card information got stolen but you don’t know how, when and where? Maybe you shopped on one of the 570 webshops compromised by the Keeper Magecart group (aka Magecart Group 8) since April 1, 2017.
Magecart Group 8’s modus operandi and targets
The list of the online shops hit by the criminals has been released by researchers from Gemini Advisory, who managed to compile it after gaining access to the group’s dedicated attack server that hosts both the malicious payload and the exfiltrated data stolen from victim sites.
“Analysis revealed that the Keeper group includes an interconnected network of 64 attacker domains used to deliver malicious JS payloads and 73 exfiltration domains used to receive stolen payment cards data from victim domains.
Their research also revealed that:
- Over 85% of the victim sites operated on the Magento CMS, 5% WordPress, and 4% Sophify
- The group tried to disguise its malicious attacker domains as legitimate services (e.g., the attacker domain closetlondon[.]org attempted to imitate closetlondon.com) and tried to imitate popular website plugins and payment gateways
- The majority of victim e-commerce sites was hosted in the U.S., followed by the U.K., the Netherlands, France, India, etc.
“The 570 victim e-commerce sites were made up of small to medium-sized merchants and were scattered across 55 different countries,” the researchers shared.
“Victims with the top Alexa Global Ranking received anywhere from 500,000 to over one million visitors each month and were responsible for selling electronics, clothing, jewelry, custom promotional products, and liquor.”
The attackers likely targeted small and medium-sized retailers because they are less likely to have a dedicated IT security team, to implement CMS and plugin patches promptly, and to have security measures in place and attack detection capabilities.
The profitability of Magecart attacks
The researchers estimated that the group may have generated over $7 million USD from selling compromised payment cards between 2017 and today.
“With revenue likely exceeding $7 million and increased cybercriminal interest in CNP [Card Not Present] data during the COVID-19 quarantine measures across the world, this group’s market niche appears to be secure and profitable,” they noted, and said that they expect the group to continue launching increasingly sophisticated attacks against online merchants across the world.
For the end users – i.e., the online shoppers – it’s all the same and, unfortunately, there is little they can do to protect themselves against the threat of getting their payment card info skimmed.
Magento 1 reaches EOL: Merchants urged to upgrade or risk breaches, falling out of PCI DSS compliance
When Adobe released security updates for Magento last week, it warned that the Magento 1.x branch is reaching end-of-life (EOL) and support (EOS) on June 30, 2020, and that those were the final security patches available for Magento Commerce 1.14 and Magento Open Source 1.
Unfortunately, there are still too many (over 100,000) active Magento 1.x installations. The company is urging their owners and admins to migrate to Magento 2.x or risk being hit once another critical and easily exploited vulnerability is unearthed and its existence made public.
Magento is a very popular open-source e-commerce platform that powers many online shops, a fact that hasn’t gone unnoticed by cyber criminals.
Nearly four years ago (and possibly even earlier), cyber crooks started concentrating on breaching Magento-based shops and injecting them with scripts that quietly grabbed users’ personal and payment card data information and sent it to a server they controlled.
Since then, the tactic has been used and continues to be used by many cyber criminal groups, which have been classified by security companies as “Magecart” attackers. As they are quick to exploit newfound vulnerabilities in the Magento core and third-party extensions, hardly a day passes without news about another online shop having been compromised.
If you decide to stick with Magento 1
“If you have a store that continues to run on Magento 1 after June 30, please be aware that from that date forward you have increased responsibility for maintaining your site’s security and PCI DSS compliance,” Adobe warned.
Merchants that continue to use an unsupported Magento 1 version will have to implement compensating controls to re-certify PCI DSS compliance, such as signing up for and implementing third-party fixes and updates, continuously scanning their installations for malware, vulnerabilities and unauthorized accounts, using a web application firewall, and so on.
“General security vulnerabilities tend to increase the longer software is unsupported as hackers continue to use new technologies and techniques for exploitation. This raises the risk of attacks and security breaches over time and increases the possibility of exposing personally-identifiable customer data,” Adobe explained.
Companies risk their reputation, the trust of their customers, fines and may even lose their credit card processing ability if they fail to protect user information.
Another thing: the end of support for Magento 1 also means that some extensions merchants use will not be available anymore.
“We encourage Magento 1 merchants to download the Magento 1 extensions they plan to keep, since Magento 1 extensions will not be available in the Magento Marketplace after July 7, 2020, and will be removed from the Magento repository after August 6, 2020,” Adobe noted last week.
Magento 2 or something else?
PayPal, Visa and other payment processing companies and payment platforms have also been urging merchants to make the switch to Magento 2.
Even though Magento 2 was released five years ago and even though the migration from Magento 1 to Magento 2 can be performed by using an official Data Migration Tool the number of Magento 2 installations is still lagging (it’s currently around 37,500 installations).
As “painful” and costly as it maybe, this EOL will hopefully push many of them to finally make the switch – or make the switch to an alternative platform.
“2020 has been a tumultuous year for retailers. Merchants should not have to worry about security issues or upgrading their ecommerce platform while they are in the middle of adapting to drastically changed consumer behaviors and expectations. Amidst the list of business-critical priorities a merchant needs to focus on, worrying about what’s happening with a Magento migration or installation should not be included,” noted Jimmy Duvall, Chief Product Officer at BigCommerce.
Magecart attackers have compromised web shops belonging to large retail chains Claire’s and Intersport and equipped them with payment card skimmers.
The compromise of Claire’s online store and that of its sister brand Icing has been flagged by Sansec researchers.
The skimmer was served from a domain made to look like it might belong to the company (claires-assets.com), and it was added to the two online stores between April 25th and 30th.
“The malware was added to the (otherwise legitimate) app.min.js file. This file is hosted on the store servers, so there is no “Supply Chain Attack” involved, and attackers have actually gained write access to the store code,” the researchers pointed out.
“The skimmer attaches to the submit button of the checkout form. Upon clicking, the full ‘Demandware Checkout Form’ is grabbed, serialized and base64 encoded. A temporary image is added to the DOM with the __preloader identifier. The image is located on the server as controlled by the attacker. Because all of the customer submitted data is appended to the image address, the attacker now has received the full payload. Immediately, the image element is removed.”
How the attackers managed to compromise the web shops is still unknown, but they started planning the attack a month before actually executing it. In fact, they registered the malicious domain a day after Claire’s announced that they will be temporarily close all of their brick and mortar stores due to COVID-19.
ESET researchers have pointed out the compromise of Intersport’s web store and said that the company fixed the issue within several hours of ESET letting them know.
Sansec researchers say that an initial hack happened on Apr 30th and then another one on May 14th:
Intersport stores got hacked on Apr 30th, cleaned on May 3rd, then hacked again on May 14th. pic.twitter.com/RabcjPzzWd
— Sansec (@sansecio) June 15, 2020
Only the localized Intersport web shops serving customers from the Balkans region have been compromised.
It is still unknown how long the skimmers went unnoticed.
None of the compromised web shops sport a prominent notification about the breach and payment card info theft. Claire’s notified the payment card networks and law enforcement, and let’s hope they will contact affected customers directly once they determine the extent of the compromise and theft.
Companies should have protections in place to notice this and other types of breaches soon after they happen, but unfortunately many don’t.
If you’re paying for your purchases with payment cards – whether online or in physical stores – you should regularly check your account statements for unauthorized charges and report them quickly.
Applications are a gateway to valuable data, so it’s no wonder they are one of attackers’ preferred targets.
And since modern applications aren’t a monolithic whole but consist of many separate components “glued together” over networks, attackers have at their disposal many “doors” through which they can attempt access to the data.
Easy targets will remain popular
Some of these doors are more popular than others. According to the latest Application Protection Report by F5 Networks, attackers love to:
“PHP is a widespread and powerful server-side language that’s been used in 80% of sites on the web since 2013. It underpins several of the largest web applications in the world, including WordPress and Facebook,” F5 analysts explained the attraction.
2. Engage in injection attacks and formjacking (the latter especially when targeting the retail sector).
In 2019, formjacking payment cards was resposible for 87% of web breaches and 17% of known breaches in total (up from 71% and 12% in 2018). In 2019, the retail sector was the most significant formjacking target. 81% percent of retail breaches were from formjacking attacks, while nearly all other sectors tended to be breached most often through the access tier.
“The lesson is clear: for any organization that accepts payment card via the web, their shopping cart is a target for cyber-criminals,” the analysts pointed out.
3. Getting access to accounts (and especially email accounts) via phishing, brute forcing, credential stuffing or using stolen credentials.
“Access tier attacks are any that seek to circumvent the legitimate processes of authentication and authorization that we use to control who gets to use an application, and how they can use it. The result of this kind of attack is a malicious actor gaining entry to a system while impersonating a legitimate user. They then use the legitimate user’s authorization to accomplish a malicious goal— usually data exfiltration,” the analysts explained.
Attackers use a number of tactics to keep these attacks unnoticed, but organizations also have a lot of defensive options at their disposal to prevent them.
4. Go after unmonitored, vulnerable, poorly secured or misconfigured APIs.
“In the days of monolithic apps, whatever core business logic generated value needed to be supported by a user interface, storage, and other meta-functions. Now it is sufficient to develop a single specialized service, and use APIs to either outsource other functions to bring an app to market, offer the service to other app owners, or both,” the analysts explained.
Their widespread used makes them a big target, and a combination of factors make them rich targets:
- They are often configured with overly broad permissions
- Lack of visibility and monitoring.
There are solutions to these problems
Attackers go where the data is, and that’s why organizations in each sector/industry should develop risk-based security programs and tailor controls and architecture to reflect the threats they actually face, the analysts advise.
To counter access attacks, organizations should implement multi-factor authentication where fitting and possible, but should also consider:
- Checking passwords against a dictionary of default, stolen, and well-known passwords
- Making sure the system can detect and prevent brute force attacks by, for example, using CAPTHA, slowing down sessions, setting up alarms, etc.
- Creating simple methods for users to report suspected phishing
- Encrypting or eliminating confidential data from the organization’s email caches
- Enabling logging (to be able to discover what the attackers did when they gained access).
Spotting and foiling injection and formjacking attacks can be done with securing servers, patching injection vulnerabilities,employing change control, using web application firewalls (WAFs), through testing and watching of all third-party components on sites with forms accepting critical information, and so on.
But organizations should be aware that the injection landscape is constantly changing, and they have to follow the trends and adapt.
Finally, organizations can mitigate the risk of API attacks by:
- Making (and maintaining) an inventory of their APIs
- Deploying authentication for them and storing credentials securely
- Limiting their permissions
- Monitoring them (by logging connections and reviewing them)
- Encrypting the API connections
- Testing APIs
- Implementing API security tools.
The client-side landscape has been overrun by third-party script attacks executed by malicious attackers utilizing formjacking or other methods made famous by the Magecart attack group.
Many companies assume their current security stack ensures protection for these seemingly basic attacks, but in reality, they open a can of worms and you may not even know you’ve been attacked. Take a read below to see some of the common misconceptions regarding client-side protection, these dedicated threats and if your business is in fact safe.
Myth #1 – I don’t need to worry about client-side security unless I have a virtual shopping cart/eCommerce
While formjacking is heavily concentrated in online retail, there is a significant weakness in other pertinent verticals as only a few lines of code can interrupt any organization that collects personal information on a website.
Myth #2 – I have a firewall, WAF and a secure connection so I’m safe from these attacks
Firewall, WAF, secure connection and many other solutions are focused on securing internal servers and the communication between the browser and these internal servers. Formjacking and Magecart attacks are executed on the user’s browser and in many cases, load from a remote server. This client-side connection operates completely outside of the security capabilities an organization deploys to secure the server side of the browser session.
Myth #3 – RASP or DASP catches formjacking and Magecart-type attacks
Dynamic Application Security Testing (DAST) is usually active on a pre-production environment and does not cover live sites. The few who run DAST on a live site will simulate a few user profiles but cannot possibly scale this solution to monitor and detect all web sessions.
As third parties change their behavior from user to user, DAST is largely ineffective in detecting attacks on large production networks and completely ineffective at preventing these types of attacks. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.
RASP is Runtime Application Self-Protection; it exists only on the Java virtual machine and .NET Common Language Runtime. Since it will not run on the actual live site, third parties are outside of its detection scope. Again, RASP is not intended as a prevention solution. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.
Myth #4 – CSP and other page headers will stop Magecart attacks
CSP is often being suggested as the solution for Magecart attacks. Although it can be part of the solution, by now we know that a lot of the Magecart attacks are being done from trusted domains. Take for example the 24/7 chat hack that captured payment card information from huge enterprises websites such as Delta Airlines, Sears, Kmart, and BestBuy. This tool was trusted by those firms and needs to be whitelisted by the CSP in order to work.
Other headers such as HSTS are sometimes also mentioned as a possible solution but all of us understand that by now attackers are sophisticated enough to use SSL (https) when loading their payload to avoid this header as well.
Myth #5 – Magecart hackers need to use a “drop server” to capture the data
In most of the known Magecart attacks, the payload is being delivered by a trusted domain (for example a third party vendor) and the data it collects is being sent to the hacker server, also called “drop server”. In some of the attacks we are seeing the hackers are using domain names that look legit to avoid detection, for example, the drop server in the British Airways attack was under the domain “baways.com”.
But the more sophisticated hackers will avoid using a drop server altogether and create an account in one the third parties the website use in order to capture the information in an undetectable way.
Using Google Analytics to capture user credentials
Myth #6 – You can detect all Magecart attacks from the outside without implementing code to your website
Using a tool to scan the website from the outside in order to capture those attacks is a VERY low barrier that can be overcome by simply using one of the most common methods almost all third-party vendors use. By nature, third party code is dynamic and can adjust to run only for specific users – for example, when you go to a website, you will see an advertisement that is related to your browsing history, and some else will see completely different advertisements according to his history.
Hackers are using those same methods to avoid detection so the hack payload will be applied to real users and not shown to an outside scanner, sometimes limiting the hack to be sent only to a small percentage of the site visitors to avoid detection by humans. In order to detect Magecart, you need real-time all the time protection.
Myth #7 – If I am being attacked right now my team would definitely be aware of it
As proven by the Magecart attack that affected over 800 websites for 3 years, many dedicated attacks are very hard to detect. If you Google “undetected Magecart attacks” the search will return a number of recent threats that top Fortune 100 companies unfortunately experienced. While security teams are trained in responding to DDoS and bot attacks, these vectors are new and evolving establishing additional operational costs in dedicated man hours and more than likely a third-party solution alternative.
Myth #8 – Third-party risks are the top concern your company should be worried about
While third-party risks present the largest issues at hand, you can’t diminish fourth- and fifth- party risks that come as extensions of third parties.
Even the most security-driven websites, who audit and test the vulnerabilities of the third-party scripts they interact with (which is in itself rare and difficult to follow through), still remain exposed through the fourth- and fifth- party scripts these suppliers interact with. This makes the process of fully protecting websites and their users from attack scripts much more challenging.
Cyber crooks deploying web credit card skimmers on compromised Magento websites have a new trick up their sleeve: favicons that “turn” malicious when victims visit a checkout page.
Favicons and card skimmers
Favicons is a file containing one or more small icons associated with a website and are usually displayed in the browser’s address bar, on the tab in which a website has been opened, and in the bookmarks.
“The goal [with online credit card skimmers is] to deceive online shoppers while staying under the radar from website administrators and security scanners,” Malwarebytes researcher Jérôme Segura explained.
In this latest approach, the crooks registered a new website purporting to offer thousands of images, icons and favicons for download (myicons[.]net) and made it an exact copy of the legitimate iconarchive.com site by loading it as an iframe.
Several e-commerce sites were loading a Magento favicon from this domain, Segura noted, but at first glance, the favicon image was clean.
The script would override the PayPal checkout option with its own drop down menu for MasterCard, Visa, Discover and American Express. The entered information would be exfiltrated to a remote server controlled by the crooks.
The new trick is part of ongoing attacks
“Given the decoy icons domain registration date, this particular scheme is about a week old but is part of a larger number of ongoing skimming attacks,” the researcher noted.
In fact, the IP of the server on which the malicious icon was hosted was flagged as part of an attack infrastructure nearly a month ago by Sucuri researchers, who tied it to a gang “known for using quite a few interesting tricks in their skimmers.”
It’s difficult for consumers to spot this type of attack and endpoint security solutions may or may not detect it. It’s on site owners to keep their websites secure and to quickly spot malicious changes.
To address attacks such as XSS, Magecart and other card skimming exploits found in modern eCommerce environments, the use of client-side web security methods is beginning to emerge as a particularly useful practice.
Obviously, enterprise teams should integrate client-side protections with desired server-side countermeasures to ensure a full risk management profile (e.g., the client-side is a poor selection point to stop denial of service).
Several standards-based client-side security approaches have begun to mature that are worth examining from the perspective of website security and protection of browser sessions from malicious exploits. The best client-side security platforms automate implementation of these standards-based controls with emphasis on simplicity of administration. A typical, representative platform is used to demonstrate necessary client-side security controls.
Content security policy
To understand client-side security platforms, it helps to first explore the specifics of a standard approach known as a content security policy (CSP). This is a standard that is designed to address several types of web breaches such as cross-site scripting, click-jacking and form-jacking (all described earlier in this article series). CSP is also designed to reduce the risk of client-side malware injected from an infected advertising ecosystem.
CSPs are implemented as standard directives involving HTTP headers or page tags that specify which domains, subdomains, and resources a browser can load from a website. CSP use is consistent with the browsers any user would likely use including Chrome, Firefox, Safari, and Edge. The goal is that if malicious code is resident on a site, then visitors to that site would be prevented by the CSP from being directed to the hacker’s domain.
Figure 1. Content security policy
The example shown above in Figure 1 is taken directly from the original W3 recommendation. The CSP code can be interpreted as follows: Each source expression represents the location where content of the type specified is allowed to be pulled. To illustrate this whitelist security operation, consider that the
self keyword-source designation, in the example above, represents the set of URIs in the origin as the protected website.
Companies like Google have rolled out CSP successfully and are using it to stop attacks against their web applications daily. However, CSP is deployed only lightly in most web application environments. The challenge with CSP implementation has been its complex administration. Tala Security researchers have found, for example, that roughly two percent of website operators in the top Alexa 1000 websites deploy the standard to prevent client-side attacks. Assisting with this administrative challenge is a primary motivation for client-side platforms.
Client-side security protection results from using CSP can websites can be quite impressive. Here are some observed statistics from the Tala Security research team based on their experiences with client-side security support:
- Images – The average website in the Alexa 1000 loads images from roughly sixteen different external domains. The
img-srcdirective in CSP blocks images from any unwanted or potentially malicious sites.
- Stylesheets – The average website in the Alexa 1000 loads stylesheets from roughly two different external domains. The
style-srcdirective in CSP blocks stylesheet loads from any unwanted or potentially malicious sites.
- Fonts – The average website in the Alexa 1000 loads images from roughly one-and-a-half different external domains. The
font-srcdirective in CSP blocks font downloads from any unwanted or potentially malicious sites.
- Media – The average website in the Alexa 1000 loads images from different external domains. The
media-srcdirective in CSP blocks font downloads from any unwanted or potentially malicious sites.
An additional applicable cyber security standard from the World Wide Web Consortium (W3C) is known as subresource integrity (SRI). This standard is designed to validate resources being served up by any third party on a visited website. Such third parties include content distribution networks (CDNs), where it has not been uncommon to find malicious code being offered up to unsuspecting websites.
Client-side security platform
Client-side security platforms will make use of both CSP and SRI to provide effective client-side protections. The goal of these platform is to provide policy-based mitigation of fine-grained behavior for third-party sources where content is being served. Client-side platforms can then watch for any data collection suggestive of the attacks used by Magecart (and similar groups).
The client browser mitigation should be implemented based on artificial intelligence-based classification and learning. The software should install quickly and easily. Commercial platforms should support implementation for many target environments including Apache Nginx, IIS, NodeJS, and others. Performance and latency impacts should also be essentially non-existent and non-affecting of the user experience. Specific capabilities included in a commercial platform should include:
- Indicator evaluation – The selected platform should be designed to evaluate many different indicators of a web page’s architecture to analyze code, content, connections, and data exchange.
- Behavioral and risk modeling – The platform should include support for analysis to inform a behavioral and risk modeling task designed to highlight normal behavior and expose vulnerabilities.
- Operational improvement – Insights gained from the platform evaluation and modeling should be made available to help prevent client-side attacks such as XSS, Magecart, and the like.
The operation of world-class client side security platforms should include an on-going interaction between four different activities: Build, Monitor, Block, and Respond. The connection flow between these different lifecycle phases is depicted below.
Figure 2. Commercial client-side security lifecycle
Client-side security platforms should implement some type of information model that can be used to analyze the different behaviors on pages from the customer’s website to be protected. The security objective for such extraction should be to explicitly identify any sources of code and content on these web pages, as well as to find any data exchange support options that could involve sensitive data.
The resultant behavioral information model will thus provide a functional baseline on which to perform the necessary client-side risk management. The goal obviously should be to determine in real-time whether the site is vulnerable to attacks, third-party insertion, or other advanced breaches. As one would expect, performance of such behavioral modeling and protection in real-time complements any existing server-side security tools.
Contributing author: Aanand Krishnan, CEO, Tala Security.
Mac threats growing faster than their Windows counterparts for the first time ever, with nearly twice as many Mac threats detected per endpoint as Windows threats, according to Malwarebytes.
In addition, cybercriminals continue to focus on business targets with a diversification of threat types and attack strategies in 2019.
Emotet and TrickBot were back in 2019
In addition, a wave of new hack tools and registry key disablers made a splashy debut, reflecting greater sophistication used by today’s business-focused attackers.
Threat actors are becoming more creative
Adware was particularly problematic for consumers and businesses on Windows, Mac and Android devices, deploying aggressive techniques for serving up advertisements, hijacking browsers, redirecting web traffic and proving extremely difficult to uninstall.
“A rise in pre-installed malware, adware and multi-vector attacks signals that threat actors are becoming more creative and increasingly persistent with their campaigns,” said Marcin Kleczynski, CEO of Malwarebytes.
“It is imperative that, as an industry, we continue to raise the bar in defending against these sophisticated attacks, actively protecting both users and businesses by flagging and blocking all programs that may violate their privacy, infect their devices, or even turn the infrastructure they depend on against them.”
Mac threats are growing, other threats in the spotlight
Mac threats significantly ramp up – An average of 11 threats per Mac endpoint were detected in 2019—nearly double the average of 5.8 threats per endpoint on Windows. Overall Mac threats increased by more than 400 percent, year-over-year.
Business detections continued to rise – In 2019, global business threats rose 13 percent to about 9.6 million detections.
HackTools triumph – With consumer detections of HackTools up 42 percent, this is a threat to watch in 2020, bolstered by families such as MimiKatz, which also targeted businesses.
Dynamic duo does damage – TrickBot and Emotet once again reigned globally, targeting businesses heavily in the last year. Emotet was second-most detected threat against businesses in 2019.
Meanwhile, TrickBot saw enormous growth, with business detections on-the-rise by 52 percent, year-over-year.
Ransomware is rampant – Ransomware targeted cities, schools and healthcare organizations with increased vigor in 2019. Newer ransomware families saw the highest growth, with Ryuk business detections up by 543 percent, year-over-year, and Sodinokibi increasing by 820 percent since its introduction in May 2019.
Beware of adware – Adware increased 13 percent, year-over-year, for consumers and 463 percent for businesses. Seven of the 10 top consumer threat families were adware variants, as well as five of the top 10 business threat families.
Pre-installed malware became pervasive – Top-rated mobile threat in 2019 was a team of pre-installed potentially unwanted program (PUP) variants that combined for 321,103 detections.
These auto installers ship with Android devices and are used to update the phone’s firmware—but they also take and sell personal information.
Just keep skimming – Credit card skimmers, or Magecart, were one of the most prevalent web threats in 2019. Magecart activity will continue in 2020 with more e-commerce platforms targeted.
Key targets shift – The services sector leapfrogged over education and retail, snagging the top spot for industries impacted by threats in 2019. Notably this includes managed service providers (MSPs), which are being leveraged to take advantage of their network of clients.
The post Macy’s online store compromised in Magecart-style attack appeared first on Help Net Security.