Surging CMS attacks keep SQL injections on the radar during the next normal

Every year, millions of websites across the world fall victim to malware attacks that are designed to gain access to the site’s backend without the administrator’s knowledge in order to steal sensitive data or cause damage, usually for financial gain. This year, cyberattacks have been on the rise during the pandemic, leaving businesses to wonder whether or not things will settle down whenever the COVID-19 situation begins to wane, or if this is the next normal for the indefinite future.

Attacks targeting popular content management system (CMS) platforms like WordPress, Joomla, Drupal, and noneCMS have risen in 2020. In fact, according to the 2020 Global Threat Intelligence Report from Dimension Data, these CMS platforms alone were the target of approximately 20% of all observed attacks globally. SQL injection vulnerability in Joomla was found to be the most commonly exploited by attackers.

In this article, we’ll take a look at security vulnerabilities in the context of CMS platforms and the implications of SQL injection attacks on your website.

How CMS vulnerabilities have evolved over the years

CMS vulnerabilities affect your website’s security as well as the content management system you use. Some of the common reasons for CMS vulnerabilities include privilege escalation exploits, social engineering attacks, and cross-site scripting.

  • Privilege escalation exploits involve making use of security flaws, known bugs, or a lack of configuration oversight in an application or an operating system to gain full access to resources.
  • Social engineering attacks on CMSs include a wide variety of malicious activities that are used to bypass technical measures implemented to protect the process of content management.
  • Cross-site scripting (XSS) utilizes security flaws in client-side execution environments as well as vulnerabilities in the backend, such as the lack of verification of content and parameters to disclose sensitive data, allowing attackers to take over the system.

Most security flaws linked to CMS platforms aren’t limited to web content management but present in server environments, web technologies, and protocols.

Cross-site scripting

Cross-site scripting targets the client environment and makes use of the server side’s low parameter and content sanitization. As a result, the attacker can inject malicious code and arbitrary commands into the pages users view.

This security flaw differs from code execution vulnerabilities, since the injected code is run on the client-server and not on the server-side. This delays the technical impact of the threat. However, when executed effectively, it can result in serious data and privacy violations such as the manipulation of databases and stored variables, including the manipulation of the actual content served.

This type of web application security vulnerability commonly targets popular CMS platforms, as they rely heavily on the internet in their technical architecture. Alternatively, this threat can be easily neutralized by disabling the client-side execution environment.

Open-source CMSs such as WordPress and Drupal, which rely heavily on the client-side environment, are more prone to client-side attacks as compared to traditional corporate-based frameworks that exhibit server-side remote vulnerabilities. The growth of third-party CMS plugins has also contributed to cross-site scripting becoming a top security vulnerability for CMS platforms.

Arbitrary remote code execution

Sending malicious commands to a web application can result in disclosure of users’ private data, and the attacker can gain access to a user’s computer. This method of injecting code within the same local execution infrastructure is relatively easy when compared to remote injection, which requires more specialized tools and skills.

Here, the remote hacker only needs a security flaw that offers a small window to send commands to the remote execution environment, enabling the malicious code to run without any evaluation.

As a result, attackers can create a remote entrance to reach the target environment, and oftentimes the administrator has no knowledge of the system being compromised.

Most of the time, attackers make use of remote code execution security flaws that are on the web surface or within different narrow-use and specific ports and protocols. When a CMS is attacked, the remote code execution flaw often results from a connected platform such as the .NET environment, PHP scripting language, or file-sharing service or database that has remote code execution vulnerabilities.

Instead of targeting the remote infrastructure, sometimes threat actors change their tactics by initiating remote code execution attacks within the client environment. For example, a malicious email may have an attachment containing a specially crafted infected file. The file containing the malicious code is executed on the client’s infrastructure. It can, for example, enable the attacker to install programs or create new accounts with full user rights.

In both types of attacks, the malicious code can be the same. However, the method of delivery is different. This is why it’s vital for CMS admins to secure their platforms and not allow attackers to gain entry to the end-users’ systems. As of 2017, arbitrary remote code execution has emerged as a top CMS security vulnerability. Several security flaws have been detected in Magento’s CMS, including arbitrary code execution.

SQL injection and the CMS

These days, most CMS platforms have an underlying SQL database backend. These backend databases implement application-specific authentication instead of user-level credentials. As a result, when malicious code is introduced to a web layer in the form of an SQL injection, a breach in data security affects the entire database.

As with other code injection threats, an SQL injection is able to send arbitrary SQL code straight to the database layer. In most cases, a lack of parameter sanitization is responsible for this type of security vulnerability, as it allows the threat actor to send direct database commands and modify the database directly.

SQL injections have been around for a long time now still, they remain one of the most common CMS security flaws. With time, users have discovered new injection points. Performing parameter value sanitization for input value processing is a common way to stop SQL injection attacks.

Some of the most popular CMS platforms that are known to have SQL injection vulnerabilities include WordPress, Joomla and Drupal. According to Sucuri’s 2019 Website Threat Research Report, over 2 million SQL injection attack attempts were blocked by the Sucuri Firewall, accounting for 1.55% of all blocked attack attempts.

Consequences of SQL injections on CMS platforms

The whole point of a CMS platform is to connect with a database that stores content, including both structured information as well as data relating to registered users with different roles.

According to Sonicwall, there has been a considerable rise in web app attacks executed via SQL injection. Web app attacks, which are commonly executed via SQL injection, are down from last year but have been trending dangerously upward since February, with 2.1 million attacks rising steadily to 4.9 million attacks in June.

surging CMS attacks

In an SQL injection attack, the attacker sends SQL input into an entry field for execution or to gain access to a web application without the owner’s permission or knowledge. This allows the malicious user to view, insert, modify, or delete data stored in the web application’s database tables. Most attackers use SQL injections to exploit known security vulnerabilities in plugins and applications like PHP.

Here’s an example of how an SQL injection works. Suppose a web application with text input asks the user to enter their user id for identification:

SELECT * FROM Users WHERE UserId = " + txtUserId

The input entered by the user “202 or 1=1” where 202 is the wrong user id. This changes the server code as follows:

SELECT * FROM Users WHERE UserId = 202 or 1=1

Since the condition 1=1 always holds true, every entry in the Users table of the database is returned by this statement. Now, if your code was written to select the first row in SQL, this could potentially compromise data stored in multiple database tables.

Let’s take a look at some of the consequences of SQL injection attacks in CMS platforms:

  • No need for authentication for a successful login: The threat actor isn’t asked for identification before logging into your site, giving open access to the site’s resources.
  • Setting up redirects: This involves the attacker placing malicious redirecting links on your site pages, which direct your site’s visitors to websites where they get scammed or their system gets infected with malware.
  • Spamming: Attackers use spamming techniques to monetize fraudulent products on your site. They may infect your applications by allowing them to directly communicate with your site’s users.
  • DDoS attacks: Attackers use DDoS attacks to disrupt your website services temporarily or indefinitely, resulting in serious financial damages.

There are various ways you can prevent injection attacks. The most common measures include:

  • Deploying web application security: A web application firewall (WAF) is a must-have security solution for any live website or application today. A WAF prevents malicious traffic and processes from interacting with your CMS platform.
  • Use input validation: Most popular CMS platforms already check the data being submitted through fields and forms. But in case you will be doing customizations that involve adding fields, make sure you have scripts that screens all data sent by users.
  • Secure access to your database. It’s best to create a unique SQL user with a strong password for each of your CMS installations. Avoid providing root level access by limiting the privileges of the user. WordPress, for example, can work with just SELECT, INSERT, UPDATE, CREATE, DELETE, DROP, and ALTER privileges.
  • Keep everything updated. CMS platform and plugin developers also maintain their code bases for security. Many of their releases are meant to address bugs and vulnerabilities. If your CMS platform notifies you of an update, check if these include bug and security fixes. Update accordingly.

Conclusion

Millions of websites fall victim to malware attacks each year and result in huge financial losses. However, website owners can successfully prevent or minimize the impact of such attacks by proactively fixing vulnerabilities (such as SQL injection vulnerabilities) in their CMS.

There are several measures you can take to prevent SQL injection attacks but they should be implemented as part of a cohesive strategy. By deploying the right security tools and continuously testing your website and fixing any apparent flaws, you can stay ahead of attackers who try to exploit CMS vulnerabilities.

Most global brands fail to implement security controls to prevent data leakage and theft

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 security controls

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.

There’s a troubling lack of security controls required to prevent data theft and loss through client-side attacks like Magecart, formjacking, cross-site scripting, and credit card skimming. These attacks exploit vulnerable JavaScript integrations running on 99% of the world’s top websites, Tala Security reveals.

The report indicates that security effectiveness against JavaScript vulnerabilities is declining, despite high-profile attacks and repeated industry warnings over the past 18 months, including the largest GDPR fine to date.

Without controls, every piece of code running on websites – from every vendor included in the site owner’s website supply chain – can modify, steal or leak information via client-side attacks enabled by JavaScript.

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.

JavaScript risk has increased in 2020

The average website includes content from 32 third-party JavaScript vendors, up slightly from 2019. JavaScript powers richness but also the framework of what renders on customer browsers, including images, style sheets, fonts, media and content from 1st party source- the site owner.

Content delivered by third-party JavaScript integrations

58% of the content that displays on customer browsers is delivered by third-party JavaScript integrations identified above.

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

While other client-side attacks such as Magecart capture most of the headlines, no attack is more widespread than Cross-Site Scripting (XSS). This study found that 97% of websites are using dangerous JavaScript functions that could serve as injection points to initiate a DOM XSS attack.

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.

Drupal fixes three vulnerabilities, including one RCE

Drupal’s security team has fixed three vulnerabilities in the popular content management system’s core, one of which (CVE-2020-13663) could be exploited to achieve remote code execution.

CVE-2020-13663

Drupal is a free and open-source web content management system (CMS), and over a million sites run on various versions of it.

The most recent stable version is 9.x, released earlier this month.

About the most recently fixed vulnerabilities

Three security holes have been plugged with the latest versions of Drupal core (9.0.1):

CVE-2020-13664 is the most critical one, but can be only triggered under certain circumstances.

“An attacker could trick an administrator into visiting a malicious site that could result in creating a carefully named directory on the file system. With this directory in place, an attacker could attempt to brute force a remote code execution vulnerability,” Drupal’s security team explained, and added that Windows servers are most likely to be affected.

CVE-2020-13665 is an access bypass flaw that can be exploited only on sites that have the read_only set to FALSE under jsonapi.settings configuration. (By default, JSON:API works in a read-only mode.)

Both of these flaws affect Drupal versions 8.8.x, 8.9.x and 9.0.x. The third one – CVE-2020-13663 – also affects Drupal 7.x, the most widely used Drupal version (both according to Drupal and W3Techs).

CVE-2020-13663 is a document object model-based cross-site scripting (DOM XSS) vulnerability that was unearthed by Checkmarx researcher Dor Tumarkin.

“This type of XSS attack is achievable if a web application enters data to the DOM without being appropriately sanitized. In this case, an attacker can manipulate their input data to include XSS content on the web page, for example, malicious JavaScript code, which in-turn would be consumed by Drupal Core itself,” the company explained.

“An attacker abusing this vulnerability can take over the administrator role of a Drupal-based website and get full control that allows changing of content, creating malicious links, stealing sensitive or financial data, or whatever else comes to mind.”

What to do?

Admins of Drupal-based sites are advised to upgrade to Drupal v7.72, 8.8.8, 8.9.1 or 9.0.1.

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Drupal v7.x is still maintained and receives security updates, but it will reach end-of-life in November of 2021, so admins that use it are urged to start planning the upgrade to a newer version, preferably 9.x.

How secure are open source libraries?

Seven in 10 applications have a security flaw in an open source library, highlighting how use of open source can introduce flaws, increase risk, and add to security debt, a Veracode research reveals.

secure open source libraries

Nearly all modern applications, including those sold commercially, are built using some open source components. A single flaw in one library can cascade to all applications that leverage that code.

According to Chris Eng, Chief Research Officer at Veracode, “Open source software has a surprising variety of flaws. An application’s attack surface is not limited to its own code and the code of explicitly included libraries, because those libraries have their own dependencies.

“In reality, developers are introducing much more code, but if they are aware and apply fixes appropriately, they can reduce risk exposure.”

Open source libraries are ubiquitous and pose risks

  • The most commonly included libraries are present in over 75% of applications for each language.
  • Most flawed libraries end up in code indirectly: 47% of those flawed libraries in applications are transitive – in other words, not pulled in directly by developers, but are being pulled in by upstream libraries. Library-introduced flaws in most applications can be fixed with only a minor version update; major library upgrades are not usually required.
  • Not all libraries have Common Vulnerabilities and Exposures (CVEs) – this means developers can’t rely only on CVEs to understand library flaws. For example, more than 61% of flawed libraries in JavaScript contain vulnerabilities without corresponding CVEs.

secure open source libraries

Language makes a difference

  • Some language ecosystems tend to pull in many more transitive dependencies than others. In more than 80% of JavaScript, Ruby, and PHP applications, the majority of libraries are transitive dependencies.
  • Language selection makes a difference both in terms of the size of the ecosystem and in the prevalence of flaws in those ecosystems. Including any given PHP library has a greater than 50% chance of bringing a security flaw along with it.
  • Among the OWASP Top Ten flaws, weaknesses around access control are the most common, representing over 25% of all flaws. Cross-Site Scripting is the most common vulnerability category found in open source libraries – found in 30% of libraries – followed by insecure deserialization (23.5%) and broken access control (20.3%).

Nearly a million WordPress sites targeted in extensive attacks

A threat actor is actively trying to insert a backdoor into and compromise WordPress-based sites to redirect visitors to malvertising.

wordpress extensive attacks

“While our records show that this threat actor may have sent out a smaller volume of attacks in the past, it’s only in the past few days that they’ve truly ramped up, to the point where more than 20 million attacks were attempted against more than half a million individual sites on May 3, 2020,” Wordfence analysts discovered.

“Over the course of the past month in total, we’ve detected over 24,000 distinct IP addresses sending requests matching these attacks to over 900,000 sites.”

About the attacks

The group has an obvious predilection for older cross-site scripting (XSS) and options update vulnerabilities in less popular WordPress plugins and themes such as Easy2Map, Blog Designer, WP GDPR Compliance, Total Donations, and the Newspaper theme.

Most of these vulnerabilities have been patched months and years ago and are known to have been targeted in the past. Some of the targeted plugins have also been removed from online plugin repositories, including WordPress’ official one.

The analysts believe that the same actor is behing most of these attacks as the payload they are attempting to inject – a malicious JavaScript – is the same.

“If the victim is not logged in, and is not on the login page, it redirects them to a malvertising URL. If the victim is logged into the site, the script attempts to inject a malicious PHP backdoor into the current theme’s header file, in addition to another malicious JavaScript,” they shared.

They expect the threat actor to take advantage of similar vulnerabilities in other plugins and themes.

What to do?

“The vast majority of these attacks are targeted at vulnerabilities that were patched months or years ago, and in plugins that don’t have a large number of users. While we did not see any attacks that would be effective against the latest versions of any currently available plugins, running a Web Application Firewall can also help protect your site against any vulnerabilities that might have not yet been patched,” Wordfence analysts noted.

K2 Cyber Security’s Timothy Chiu says that perimeter security tools like WAFs require a lot of tuning to make them effective at protecting applications and companies don’t typically have the security resources required to do an adequate job.

For organizations that have that problem and for individuals who only run a site or two the easiest thing to do to minimize their attack surface is to keep plugins and themes up to date and to delete plugins that they don’t need anymore and those that have been removed from the WordPress plugin repository.

Wordfence has provided indicators of compromise site administrators can use to check whether they’ve been hit.

Client-side web security

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.

client-side web security

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.

client-side web security

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-src directive 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-src directive 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-src directive 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-src directive in CSP blocks font downloads from any unwanted or potentially malicious sites.

Subresource integrity

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.

SRI is implemented through cryptographic hash functions which finger-print JavaScript being offered by third parties. Browsers can then fetch a resource, check the cryptographic hash value – which include the location of the resource, and then make a policy decision about whether to accept the resource. This capability is supported in all important browsers, and significantly reduces the risk of malware from third party actors.

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.

client-side web security

Figure 2. Commercial client-side security lifecycle

Information model

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.

COVID-19 affects web traffic and attack trends

There have been significant changes in web attack and traffic trends as a result of COVID-19, according to Imperva.

web attack traffic trends

The monthly report also revealed that the Cyber Threat Index remains at a ‘high’ level and the financial services sector has been suffering the most from cross-scripting site (XSS) attacks, and a continued increase in attacks from cloud services.

Amid COVID-19, web traffic and attack trends were affected

During the month of March, changes in traffic and attack trends were tracked across multiple industries and countries as the coronavirus pandemic escalated.

The March findings indicated that the food and beverage industry experienced more website attacks globally (+6%), especially in Germany (+125%). There were more attacks on the financial industry both globally (+3%) and in specific countries like Italy (+44%), UK (+21%), and Spain (+18%).

CTI remains at a ‘high’ level

In March, a balancing effect took place as some industries (news and retail) saw increases in both traffic and attacks, while others (travel and sports) saw less traffic and attacks. Due to this variation between industries, the global index remains consistent and, while the score didn’t increase, the risks remain high.

Financial services suffer the most from XSS attacks

Cross-site-scripting attacks, a type of malicious script injection, were the most dominant attack vector (32%) for sites in the financial services sector. This may be because taking over web sessions in financial sites is extremely profitable for hackers, or because of the high regulation on these sites and the frequent risk assessment and penetration tests being conducted.

Network DDoS peaked at 279 GBPS

Aimed at a domain name registrar and web hosting company in the U.S., Imperva registered a network DDoS attack that peaked at 279 GBPS which is 37% higher than the average network DDoS attack in the last three months.

web attack traffic trends

Attacks from cloud services increased

As attacks from anonymization platforms declined, attacks from cloud services increased. Imperva observed a 23% decline in attacks from anonymity frameworks like TOR, VPNs, and masking proxies. This can be explained by the simultaneous 10% growth in attacks coming from different cloud services, which provide a partial anonymity.

U.S. govt and law sector attacks compared to those in France

Attacks against the government and law sector in the U.S. declined, compared to an increase in France. France’s first local election round was accompanied by a 12% increase in attacks on law and government websites, while the U.S. experienced a 5% decline in attacks during the month of March.

A client-side perspective on web security

Threats to web security are explained in this first of a three-part article series, and client-side security is shown to address a commonly missed class of cyber attack exemplified by Magecart. Traditional solutions to web security are outlined, including a new approach to web security based on client-side standards such as content security policy and subresource integrity. These emerging approaches are explained in the context of a representative client-side security platform.

threats web security

Introduction

Perhaps the most salient aspect of cybersecurity as a professional discipline is its continuous cycle of change. That is, as cyber attacks emerge that challenge the confidentiality, integrity, or availability of some on-line resource, corresponding protection solutions are invented to reduce the risk. Once these solutions become integrated into the underlying fabric of the resource of interest, new cyber-attacks emerge, and new solutions are invented – and the cycle continues.

In some cases, new protective cyber solutions have the side-benefit anticipating new forms of malicious attacks – and in cases where this works, security risks are often avoided in a wide range of different scenarios. Two-factor authentication, for example, was created in response to password guessing, but is now an important component in the design of new Internet of Things (IoT) machine-to-machine application protocols to reduce risk.

Nowhere is this process of introducing and mitigating cyber risk more obvious than in web security – also referred to as web application security. With valuable assets being provisioned and managed increasingly through web-based interfaces, the value of web-based exploits continues to rise. One consequence of this rise is that despite the many technologies available to protect web resources, the gap between offense and defense is growing.

A main premise in this technical series is that this web security gap stems from the fact that most application execution occurs on the modern browser. The web security community has long recognized the need to deploy functional controls to safeguard the server-side vulnerability of web servers delivering content and capability to client browsers. Too little attention, however, has been placed on this client-side vulnerability, which is attractive to attackers and largely ignored by today’s security infrastructure.

The three parts that follow in our series are intended to help address this oversight. In Part 1, we offer an introduction to the most common cyber attacks that target websites today. Part 2 then provides an overview of the web security solutions that are deployed in most production environments today. Finally, Part 3 offers an introduction to how a representative client-side security solution can help rectify the client-side weaknesses exploited by bad actors today.

Common attacks to websites

Commensurate with Tim Berners-Lee’s idea in the mid-1990’s to layer hypertext protocols and markup languages onto the Internet protocol (IP) came the emergence of offensive means to attack the infrastructure, systems, and applications that make up the now-called web. And thus was born the discipline of web security, which can be defined as the set of protective measures required to manage the security risk of web-based computing.

As one would expect, the taxonomy of web security issues quickly grew in several directions, but early focus was on avoiding denial of service attacks, protecting hosting infrastructure, and ensuring free flow of web content to users. Such focus on availability corresponded to the observation that if a website was down or not working properly, then eCommerce transactions would not occur – which had obvious revenue implications.

In addition to these infrastructure concerns, however, came a growing observation that application-level security issues might have severe consequences – often to the privacy of customers visiting a website. Thus was born the so-called web applications threat, which quickly evolved from a small concern to a massive security challenge. Even today, finding sites with exploitable vulnerabilities in their web applications is an easy task.

Several standard attack strategies have emerged in recent years that have been difficult to eradicate. These nagging problems prey on the complexity of many web application designs, and on the relative inexperience and ignorance of many web software administrators. Below, we describe these strategies – four in total – that continue to drive risk into eCommerce infrastructure and to cause challenges for many enterprise security teams:

Cross-Site Scripting (XSS)

The most common application-level web security attack is called cross-site scripting or just XSS. A cross-site attack involves a technique known as injection – where the attacker finds a way to get scripts running on a target website. The ultimate goal is for that targeted web application to send the attacker’s code to some unknowing user’s browser. The XSS attack works best when a website accepts, processes, and uses input without much checking.

The end goal is that the attacker has managed to inject code into someone’s browser. That user will expect any downloaded scripts to be fine, since they came as dynamic content from the visited, and presumably trusted website. Their browser will then execute this code, often JavaScript, thus exposing sensitive information such as session tokens or cookies to the original attacker. The XSS code can also redirect a user to some infected website.

threats web security

Figure 1. XSS Attack Schema

Organizations such as Open Web Application Security Project (OWASP) suggest various defenses against XSS attacks. Their suggestions, many of which continue to be ignored by practitioners, involve common-sense coding and web administrative procedures that improve the processing of data from users. Most involve better validation of input data on the server side, which is a welcome security control and should be present in any web ecosystem.

Content and Ad injection

The challenge of dealing with content and ad injection attacks, also known as malvertising, has increased substantially in recent years. This should come as no surprise given the rise of the on-line advertising ecosystem as a force in modern business. Some estimates have the size of on-line advertising now reaching aggregate levels as high as $100B. Hackers and criminals understand this trend – and take advantage of exploitable weaknesses.

The way malvertising works follows a similar pattern to XSS attacks: Malicious actors find ways to inject their code onto websites through legitimate advertising networks. The goal, again similar to XSS, is to target visitors to the site, usually with the intent to redirect their browsers to some targeted website that has been planted with malware and that forms the basis for whatever attack is desired, such as credential theft.

Many observers have referenced the injection process as involving something called a drive-by download. This term references a user viewing an advertisement using a browser with an exploitable vulnerability (which is sadly a common scenario). While the user interacts with the ad, a redirection process is initiated whereby the malicious software finds its way to the unsuspecting visitor to the site.

threats web security

Figure 2. Drive-By Download via Malvertising

The traditional solution to this problem involves placing a control such as a web application firewall (WAF) in-line with the access. The WAF would be programmed to use signature or behavioral analysis to stop malicious code execution from untrusted sources. As with XSS security, this server-side protection is commonly found in advertising ecosystems as a primary control. Such emphasis can address malvertising, but might not work for all forms of attacks.

Magecart

The hacking group Magecart emerged several years ago, terrorizing websites with an attack known as card skimming. Normally, hacking groups tend to come and go quickly, but Magecart hit a nerve with their targeted breaches of enterprise websites and web applications. Wide ranges of different organizations saw their sites formjacked, and security solutions were not immediately evident to most victims.

The man-in-the-middle attack from Magecart is quite simple to explain: It begins with malicious code added to the JavaScript served to clients from a website. The malicious code then watches for and collects sensitive data such as credit card information from legitimate users visiting the site with their browser. The data is exfiltrated to a malicious drop site and is unloaded in the usual illegal manner. It’s that simple.

threats web security

Figure 3. Magecart Card Skimming

The nagging issue, however, is that common server-side security tools don’t account for this man-in-the-browser (MITB) attack because it occurs on the client side. Web application firewalls (WAFs), for example, don’t see the JavaScript activity and have no means for scanning libraries for code insertions. And when this attack is served from third or fourth-party hosted sites, the cascading result is something called piggy-backing.

Contributing author: Aanand Krishnan, CEO, Tala Security.

WordPress and Apache Struts weaponized vulnerabilities on the rise

Vulnerabilities in leading web and application frameworks, if exploited, can have devastating effects like the Equifax breach which affected 147 million people, according to RiskSense.

weaponized vulnerabilities

Among the report’s key findings, total framework vulnerabilities in 2019 went down but the weaponization rate went up, WordPress and Apache Struts had the most weaponized vulnerabilities, and input validation surpassed cross-site scripting (XSS) as the most weaponized weakness in the frameworks examined.

“Even if best application development practices are used, framework vulnerabilities can expose organizations to security breaches. Meanwhile, upgrading frameworks can be risky because changes can affect the behavior, appearance, or inherent security of applications,” said Srinivas Mukkamala, CEO of RiskSense.

“As a result, framework vulnerabilities represent one of the most important, yet poorly understood and often neglected elements of an organization’s attack surface.”

Most weaponized vulnerabilities

These two frameworks alone accounted for 57% of the weaponized vulnerabilities, those for which exploit code exists to take advantage of the weakness, in the past 10 years.

WordPress faced a wide variety of issues, but XSS was the most common problem, while input validation was the biggest risk for the Apache Struts framework. Their respective underlying languages, PHP for WordPress and Java for Struts, were also the most weaponized languages in the study.

2019 vulnerabilities are down, but weaponization is up

While the overall number of framework vulnerabilities was down in 2019 compared to previous years, the weaponization rate jumped to 8.6% which is more than double the National Vulnerability Database (NVD) average of 3.9% for the same period. This uptick was primarily due to increased weaponization in Ruby on Rails, WordPress and Java.

Input validation replaces XSS as top weakness

While XSS issues were the most common vulnerability over the 10-year study period, it dropped to 5th when analyzed over the last 5 years. This is a sign that frameworks are making progress in this important area.

Meanwhile, input validation has emerged as the top security risk for frameworks, accounting for 24% of all weaponized vulnerabilities over the past 5 years mostly affecting Apache Struts, WordPress, and Drupal.

Injection weaknesses are highly weaponized

Vulnerabilities tied to SQL injection, code injections, and various command injections remained fairly rare, but had some of the highest weaponization rates, often over 50%. In fact, the top 3 weaknesses by weaponization rate were command injection (60% weaponized), OS command injection (50% weaponized), and code injection (39% weaponized). This often makes them some of the most sought after weaknesses by attackers.

Shedding light on hidden threats

An organization’s web-facing applications represent fundamental digital assets that are essential to serving internal and external users. Their exposure to the outside world also means they are susceptible to constant attack.

Most credential abuse attacks against the financial sector targeted APIs

From May 2019 and continuing on until the end of the year, there was a dramatic shift by criminals who started targeting APIs, in an effort to bypass security controls. According to data from Akamai, up to 75% of all credential abuse attacks against the financial services industry targeted APIs directly.

credential abuse attacks

According to the report’s findings, from December 2017 through November 2019, 85,422,079,109 credential abuse attacks were observed. Nearly 20 percent, or 16,557,875,875, were against hostnames that were clearly identified as API endpoints. Of these, 473,518,955 attacked organizations in the financial services industry.

A mix of API targeting, and other methodologies

But not all attacks were exclusively API focused. On August 7, 2019, the single largest credential stuffing attack against a financial services firm was recorded, consisting of 55,141,782 malicious login attempts.

This attack was a mix of API targeting, and other methodologies. On August 25, in a separate incident, the criminals targeted APIs directly, in a run that consisted of more than 19 million credential abuse attacks.

“Criminals are getting more creative and hyper-focused on how they go about obtaining access to the things they need to conduct their crimes,” said Steve Ragan, Akamai security researcher and principal author of the State of the Internet / Security report.

“Criminals targeting the financial services industry pay close attention to the defenses used by these organizations, and adjust their attack patterns accordingly.”

Criminals exposing data through different methods

Indicative of this fluid attack dynamic, the report shows that criminals continue to seek to expose data through a number of methods, in order to gain a stronger foothold on the server and ultimately achieve success in their attempts.

SQL Injection (SQLi) accounted for more than 72% of all attacks when looking at all verticals during the 24-month period observed by the report. That rate is halved to 36% when looking at financial services attacks alone. The top attack type against the financial services sector was Local File Inclusion (LFI), with 47% of observed traffic.

LFI attacks exploit various scripts running on servers, and as a consequence, these types of attacks can be used to force sensitive information disclosure. LFI attacks can also be leveraged for client-side command execution (such as a vulnerable JavaScript file), which could lead to Cross-Site Scripting (XSS) and DoS attacks.

XSS was the third-most common type of attack against financial services, with a recorded 50.7 million attacks, or 7.7% of the observed attack traffic.

Criminals still leveraging DDoS attacks

The report also shows that criminals continue to leverage DDoS attacks as a core component of their attack arsenal, particularly as it relates to targeting financial services organizations.

Observations from November 2017 until October 2019, show the financial services industry ranking third in attack volume, with gaming and high tech being the most common targets. However, more than forty percent of the unique DDoS targets were in the financial services industry, which makes this sector the top target when considering unique victims.

Security teams need to constantly consider policies, procedures, workflows, and business needs – all while fighting off attackers that are often well organized and well-funded,” Ragan concluded. “Our data shows that financial services organizations are constantly improving by adopting fluid security postures, forcing criminals to change their tactics.”