75% of executives believe their organization scans all web applications for security vulnerabilities, while nearly 50% of security staff say they don’t, a Netsparker survey reveals.
Web application security efforts are insufficient
Even more concerning, over 60% of DevOps respondents indicate that new security vulnerabilities are being found faster than they can be fixed, indicating that web application security efforts are insufficient.
However, only just over 40% of executives are aware of this situation, and thus most companies are unlikely to be making the required investments to remedy the situation.
Despite this, respondents ranked web application security highest among areas they believe their company should focus. Over 66% of respondents named web application security as a priority – more than any other aspect of IT security, ahead of network security, endpoint security, and patch management.
- While just 20% of developers believe that development teams are resistant to incorporating security, close to half of security professionals say they encounter developer resistance.
- Just under 40% of developers indicated that critical security issues get automatically escalated, showing that organizations still have a long way to go to fully integrate security into the software development process.
- Just under 35% of developers report friction caused by security false positives, compared to over 54% of security staff. This suggests that security teams bear the bulk of extra work caused by false alarms.
Disconnect between theory and practice
The survey shows a worrying disconnect between the theory and practice of web application security. While most organizations appreciate the importance of web security, many still don’t scan all their applications and an even greater number struggle to deal with vulnerabilities in a timely manner.
This research shows that perceptions and expectations of web application security vary widely depending on the role. This misalignment between perception and reality creates dangerous threats to the security of organizations and their customer’s data as well.
In a recently released report by the UK National Cyber Security Centre (NCSC), whose findings have been backed by Canada’s Communications Security Establishment (CSE) and the US NSA and CISA (Cybersecurity and Infrastructure Security Agency), the agency has warned about active cyber attacks targeting biomedical organizations that are involved in the development of a COVID-19 vaccine.
On Friday, BitSight researchers shared the results of a study that looked for detectable security issues at a number of companies who play a big role in the global search for a vaccine, and found compromised systems, open ports, vulnerabilities and web application security issues.
Biomedical orgs under attack
The report details recent tactics, techniques and procedures (TTPs) used by APT29 (aka “Cozy Bear”), which the NCSC and the CSE believe to be “almost certainly part of the Russian intelligence services.”
The agencies believe that the group is after information and intellectual property relating to the development and testing of COVID-19 vaccines.
“In recent attacks (…), the group conducted basic vulnerability scanning against specific external IP addresses owned by the organisations. The group then deployed public exploits against the vulnerable services identified,” the report states.
Among the flaws exploited by the group are CVE-2019-19781 (affecting Citrix’s Application Delivery Controller (ADC) and Gateway), CVE-2019-11510 and CVE-2018-13379 (affecting Pulse Secure VPN endpoints and Fortigate SSL VPN installations, respectively) and CVE-2019-9670 (affecting the Synacor Zimbra Collaboration Suite).
The group also uses spear-phishing to obtain authentication credentials to internet-accessible login pages for target organizations.
After achieving persistence through additional tooling or legitimate credentials, APT 29 uses custom malware (WellMess and WellMail) to execute arbitrary shell commands, upload and download files, and run commands or scripts with the results being sent to a hardcoded Command and Control server. They also use some malware (SoreFang) that has been previously used by other hacking groups.
The report did not identify the targeted organizations nor did it say whether the attacks were successful and whether any information and IP has been stolen.
Biomedical orgs open to cyber attacks
As many security researchers pointed out, Russian cyber espionage groups aren’t the only ones probing these targets, so these organizations should ramp up their security efforts.
BitSight researchers have recently searched for security issues that attackers might exploit. They’ve looked at 17 companies of varying size that are involved in the search for a COVID-19 vaccine, and found:
- 25 compromised or potentially compromised machines (systems running malware/bots, potentially unwanted applications, spam-sending machines and computers behaving in abnormal ways) in the past year
- A variety of open ports (i.e., exposed insecure services that should be never exposed outside of a company’s firewall): Telnet, Microsoft RDP, printers, SMB, exposed databases, VNC, etc., which can become access points into a company’s network
- Vulnerabilities. “14 of the 17 companies have vulnerabilities and six of them have very serious vulnerabilities (CVSS score > 9). 10 companies have more than 10 different active vulnerabilities.”
- 30 web application security issues (e.g., insecure authentication via HTTP, insecure redirects from HTTPS to HTTP, etc.) that could be exploited by attackers to eavesdrop on and capture sensitive data, such as credentials, corporate email, and customer data.
“These findings are not abnormal when compared to other groups of large companies (e.g. the Fortune 1000), but given the heightened threat environment, they do provide cause for concern,” the researchers pointed out.
“It only takes a misconfigured piece of software, an inadvertently exposed port, or an insecure remote office network for a hacker to gain entry to systems that store scientific research, intellectual property, and the personal data of subjects involved in clinical trials.”
There are growing concerns around the number of businesses vulnerable to cyberattacks due to hackers’ ability to bypass their Web Application Firewall (WAF), Neustar reveals.
Cyberattacks bypass the WAF
49% of security professionals reported more than a quarter of attempts to sidestep their WAF protocols had been successful in the last 12 months. In addition, as many as four in ten respondents disclosed that 50% or more of attacks had managed to get around their application layer firewall.
These findings come at a pivotal time, as organizations continue to adapt their security strategies to cope with the increase in malicious web activity associated with COVID-19.
29% of respondents admitted they had found it difficult to alter their WAF policies to guard against new web application attacks, while just 15% said they had found the process very easy.
No fully integrated WAF
Despite many having already been on the receiving end of a successful web-application attack, 39% of respondents declared they do not have a WAF that is fully integrated into other security functions; a technique that is critical in developing a holistic defense against a variety of attack types. Three in ten also claimed that half of network requests have been labelled as false positives by their WAF in the last year.
“As members of the public, we have witnessed the steady and significant growth of volumetric DDoS attacks, fake domains, malicious malware and harmful misinformation. However, while these may be the security concerns capturing headlines, those within the community have also seen the unsettling rise in application-layer attacks,” said Rodney Joffe, Senior VP and Fellow at Neustar.
“Often unleashing destruction before they are even recognized, these attacks are equally as damaging, targeting specific vulnerabilities to cause a multitude of complications for those on the receiving end.”
“Due to their ‘under-the-radar’ nature, application-layer attacks are difficult to detect and therefore require a security posture that is always-on in order to be identified and mitigated. Only by providing protection across the entire network can organizations respond to the type of threats we are seeing today.
“For full-protection that doesn’t hinder business performance or add unnecessary complexities, organizations should opt for a cloud-based WAF, underpinned by curated, actionable threat data.
“Not only is this approach guaranteed to safeguard against the most common web threats, it also delivers visibility into application traffic, no matter where the applications themselves are hosted,” added Joffe.
DDoS attacks and system compromise ranked as the greatest concerns
There has also been a steep 12-point increase on the International Cyber Benchmarks Index year-on-year. Calculated based on the changing level of threat and impact of cyberattacks, the Index has maintained an upward trend since May 2017.
During March – April 2020, DDoS attacks and system compromise were ranked as the greatest concerns for security professionals (both 21%), followed by ransomware (17%) and intellectual property (16%). To date, 68% of enterprises surveyed indicated that they had been on the receiving end of a DDoS attack at any given time, up 3% on previous reports.
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.
As non-essential businesses have been forced to shut their doors around the world, many companies that previously relied heavily on the brick-and-mortar side of the business are now leaning more on revenue from their digital platforms. By 2023, according to research performed by Statista, applications may generate nearly $935 billion in revenue. With increased reliance on these applications and increasing customer traffic, security will play a critical role.
Although the use of applications has steadily increased, the difference in the ways that web and mobile applications are protected is not widely understood. Additionally, many companies that have been using security tools for their web application may feel that moving these security tools to mobile may be difficult, but it isn’t.
Let’s delve deeper into the similarities and differences in mobile and web apps, and what protection for each of those platforms looks like.
When it comes to mobile applications, the customer that is using a service has an operating system that stores data. Because sessions and identities are usually saved, the app knows who the user is when it’s opened. The user’s data is saved on that particular device. If the application that the user uses is hacked, the cybercriminal can also access the personal information and sessions that the application uses to remember and authenticate the user.
Unlike mobile applications, web applications don’t have long-term memory (although they do perform some caching). This means that they do not save a large amount of data in the same way that mobile applications do. If a web application is hacked, the cybercriminal has gained a foothold, but not instant access to user data. The foothold can later be leveraged to access back-end databases or other sensitive places within the company’s network. This can lead to a potential breach.
Application security for both types of apps
Both types of applications can be protected through the right type of application security testing. Mobile application security testing (MAST) and web application security testing tools are easily accessible nowadays. According to research performed by WhiteHat Security, organizations that perform scans during the application’s production have a lower chance of being breached. Additionally, organizations that include security in DevOps are able to lower the risk of a breach, reduce costs and have better time to market.
Security testing for web applications
Web application security testing focuses mainly on the relationship between the request and response. Because the size and complexity of websites has increased over time, the need for web app security testing tools that contextualize the risk carried by the vast amounts of data collected as they try to spot anomalies and identify vulnerabilities has increased as well.
There are two types of tools that can achieve this: dynamic application security testing (DAST) and static application security testing (SAST).
DAST scans apps on an ongoing basis once they have been deployed, and SAST scans applications at the pre-production level. Combining both DAST and SAST is a great way to strengthen the application’s security not only through the DevOps lifecycle, but also into production when the app is live and in use.
All about MAST
MAST looks at the coordination between the request and its response, and also how they are handled within the operating system. The best MAST approach uses both dynamic and static automated scanning in addition to manual mobile application-layer penetration testing. This offers coverage throughout the entire DevOps lifecycle. It also tackles compliance requirements, reduces risk and produces safer mobile apps that stay secure against potential attacks.
Adding a mobile app to a company’s product line-up should not be nerve-wrecking, even in these stressful times. By adding application security testing when implementing these applications, companies can save themselves and their customers from major data breaches and give the business time to appreciate the benefits of having an application – rather than fretting over risks.
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.
Cyber attackers are increasingly leveraging web shell malware to get persistent access to compromised networks, the US National Security Agency and the Australian Signals Directorate warn.
What are web shells?
Web shells are malicious scripts that are uploaded to target systems (usually web servers) to enable attackers to control it remotely. In affect, they create a backdoor into the target system.
The threat is not limited to internet-facing web servers, though, and can be deployed on non-internet facing internal content management systems or network device management interfaces.
Preventing web shell installation
Attackers usually manage to deploy web shells by exploiting web application vulnerabilities, weak server security configuration, or by uploading to otherwise compromised systems.
Among the web application vulnerabilities that are commonly exploited to install web shell malware are:
“This list is not intended to be exhaustive, but it provides insight on some frequently exploited cases,” the agencies noted, and advised organizations to regularly patch/update web apps and limit their permissions.
“In particular, web applications should not have permission to write directly to a web accessible directory or modify web accessible code. Attackers are unable to upload a web shell to a vulnerable application if the web server blocks access to the web accessible directory,” they pointed out.
If the latter step is not possible, they advised orgs to implement file integrity monitoring to block file changes to web accessible directories or alert when changes occur.
Finally, they should add defense layers such as Intrusion Prevention Systems (IPS) and Web Application Firewalls (WAF), and improve network segregation and harden web servers.
Detecting installed web shells
“Web shells are difficult to detect as they are easily modified by attackers and often employ encryption, encoding, and obfuscation,” the agencies explained. That’s what makes them so useful to attackers and so dangerous to defenders.
There are several methods that can be used to detect their presence, such as:
- Comparing a verified benign version of the web app against the production version (and analyzing the discrepancies)
- Monitoring web traffic for anomalies
- Detection based on signatures (can work for detecting popular web shells that have been minimally modified)
- Monitoring for unexpected network flows
- Using Endpoint Detection and Response (EDR) and logging tools such as Microsoft Sysmon or Auditd (on Linux systems) to spot system call or process lineage abnormalities
The NSA has set up a GitHub repository with tools and signatures that can help defenders implement these techniques.
Finally, the agencies warn, organizations that find a web shell on one or more of their systems should investigate how far the attacker penetrated within the network.
As should be evident to anyone in the cyber security industry, the wide range of available web security solutions from commercial vendors will necessarily have varying degrees of effectiveness against different threats.
A premise of this article is that client-side security has been under-represented in these solutions – and to see this, it helps to briefly examine the specifics of the well-known web security solutions in use today, and their respective emphases.
Web Application Firewalls (WAFs)
The design of web application firewalls (WAFs) addressed the fact that the target of most malicious activity is not always the infrastructure surrounding a web hosting environment, but rather the application itself. By manipulating or exploiting security weaknesses in the critical applications of a business, bad actors could gain access to the most valuable assets.
WAFs are built to track the specifics of an application protocol versus the most foundational focus of an IDS/IPS. A WAF has the great advantage of being able to line up closely with the back-and-forth between user and application so that weird commands or other unusual behavior can be identified easily. Doing this properly is easier said than done, but a WAF positioned on the server side of an application architecture can be helpful.
Figure 1. WAF architecture
One challenge to WAF operation is the complexity of dealing with the incessant pace of change for applications in a modern DevOps environment. Another challenge, however, is a WAF’s inability to detect and mitigate client-side security exploits. Like an IDS/IPS, when exploit code finds its way to the user’s browser, mitigation of subsequent attack behavior is no longer in the purview of the server-side controls.
Secure Sockets Layer (SSL)
The use of Secure Sockets Layer (SSL) is an important contribution to secure eCommerce because it provides strong protection for the provision of user credential information – and, in particular, credit card numbers over the Internet. Virtually all eCommerce purchases today require some form of credit card exchange, and SSL has been invaluable in reducing the risk of this data being inappropriately observed in transit.
The infrastructure supporting SSL is surprisingly complex, and has required cooperation between various different organizations including the eCommerce vendor, the hosting provider, the browser companies, and security entities known as Certification Authorities (CAs.) Nevertheless, the SSL infrastructure for modern on-line transactional business is strong, and has benefited companies such as Amazon.com in a profound manner.
Figure 2. SSL architecture
While SSL has been a great success, its focus has been on the confidentiality of credentials, and not on the prevention of malicious attacks – especially on the client-side. Sadly, too much user training has incorrectly advised users that if they see evidence of SSL in action, that the “security issues” are covered. This might be true for avoidance of credit card sniffing attack in transit, but it is definitely not true for most web attacks, including client-side exploits.
Intrusion Detection Systems (IDS)
The most traditional means for protecting endpoints and infrastructure from security attacks involves insertion of an intrusion detection system (IDS) or intrusion prevention system (IPS) in-line with access to these components. The earliest IDS/IPS systems were built to detect attacks based on signatures of known methods, but more recent systems have been designed to include some more behavioral attributes.
Nevertheless, all IDS/IPS platforms inspect live session traffic to determine whether a given activity should be prevented from starting or terminated while on-going. This man-in-the-middle (MITM) approach its respective benefits and drawbacks, but it is common – especially since such functionality is regularly integrated into a next-generation firewall or gateway. The resulting architectural set-up for most enterprise looks as follows:
Figure 3. IDS/IPS architecture for web security
One challenge with any inspection-based solution is that encrypted communications traverse the MITM security with impunity. Another is that normal downloads to the client are not easily differentiated from malicious ones. Once a bad script finds its way past the IDS/IPS onto a client browser, the malware can run without the gateway security having any idea it is occurring. This does not remove the need for MITM security, but it does highlight a major weakness.
The provision of security for client-side attacks requires a new type of focus, one not found in many commercial solutions. It requires that security protections either pre-install on the client, or travel to the client in a dynamic manner based on the transaction being protected – usually a user with a browser visiting a website. The traditional deployment of client-side security for enterprise users has involved the following types of solutions:
Traditional anti-malware – The use of signatures as the basis for detecting malware continues to be a mainstay of modern enterprise security – and this extends to web application security. Many CISO-led teams rely on their anti-malware vendor to help reduce the risk of malware that might have been downloaded from a website. As one might expect, even with behavioral enhancements, this remains a weak control.
Virtual containers – The use of virtualized client computing environments, sometimes referred to generally as virtual containers, supports the idea that if malware finds its way to the endpoint, then it cannot reach real assets. This approach requires deployment of endpoint virtualized software, which often requires some work to minimize impact to application performance or use.
Web isolation – This technique involves a MITM gateway being positioned between the client and the website. Such processing can be software-only, or for higher assurance, implemented in hardware. The use of MITM gateways is shown here as a client-side protection because it extends the virtualization concept to the gateway.
Off-line detonation – The use of virtualized, off-line detonation is a useful means for detecting downloadable malware, and is commonly found in protection schemes for email attachments. It is also implemented frequently as part of a MITM gateway, and like isolation, complements the use of controls more specifically designed to protect the browsing session from website-born malware.
That such an assortment of methods exists is both good news and bad news for enterprise security managers: On the one hand, it is good news because these are all sensible controls, each with successful vendors supporting a range of enterprise customers. But it is also bad news in the sense that none address the problem of flexible, policy-based security policy enforcement for applications executing on the client browser.
In the next article, we’ll describe several standard application-specific controls that have emerged to address the risk of attacks such as Magecart, card skimming, and other web application and eCommerce-born exploits. The technology will be explained in the context of a typical client-side security platform, which implements content security policies, subresource integrity, and other security safeguards that should be of interest to the security team.
Contributing author: Aanand Krishnan, CEO, Tala 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.
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.
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.
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.
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.
Figure 3. Magecart Card Skimming
Contributing author: Aanand Krishnan, CEO, Tala Security.
In this podcast recorded at RSA Conference 2020, Jason A. Hollander, CEO, and Paul B. Storm, President at Cymatic, talk about how their platform builds a defensible barrier around the user, so web-based threats can be stopped at the source.
Here’s a transcript of the podcast for your convenience.
Welcome to the Help Net Security podcast. In this edition, I’m joined with the guys from Cymatic. Can you please introduce yourselves?
My name is Paul Storm. Good morning or good afternoon, wherever you are. And my name is Jason Hollander and we’re both the co-founders of Cymatic.
Can you tell me what is Cymatic’s approach to web security and what differentiates you in the marketplace?
Paul: Sure. I guess I could take it Paul. We built a web application defense platform that’s able to identify, basically calculate risk, and also really understand users from inside of the web application. Think of it as almost like a client-side WAF.
Jason: When you think about web application defense, it includes a lot of different silos of technology. And one of the things that we want to do is build a technology that brings the silos together. That way they can leverage each other to make smarter decisions. And we’re able to bring that as close to the user as possible.
If you think about web application threats and breaches, you want to catch it left of boom. A lot of the technology today is either at boom or right of boom because it’s in the network. We push it straight out to the user. It’s invisible. We surround the browser or the mobile device, and therefore we’re able to eliminate a lot of the threats, to see the threats that a lot of technology cannot, because they create silos.
In browser automation detection
Your website mentions next generation pre-endpoint protection. Can you tell our listeners exactly how does it work?
Paul: I’ll preface this by saying we are a young startup and messaging is something we’re still working on. For the world of startups out there, it’s an iterative process.
We open up a socket from that browser session, back to our Cymatic cloud. Then everything’s streamed on a real-time socket. One of our micro services will pick up on the feed or speed and only grab the elements that it needs to provide visibility, control or identify risk.
Jason: One of the things we did, Paul mentioned it, it’s got this real-time socket connection back to our cloud, which does all the AI and ML part of our product. A lot of technology is stateless. Once they do their job, they fall off. We’re stateful, we see it the moment someone lands on a web application, to the moment that they end their session – we’ve got complete visibility and complete control over that.
If we take a look at the current cybersecurity trends in the industry, we see account takeover attacks have been rising steadily in the last year. So, how does your company help organizations with this type of attacks?
Paul: When we first created this, ATO was the first thing that we were trying to attack, probably the wrong choice of words, but to stop. We are basically looking at users based upon user behaviors. When you do that and you’re looking at not just a single vector, it’s really able to identify not just ATO risks, which is a definite problem, but all the other issues that come with an externally facing property. It’s a lot more holistic than just going after ATO. We’re identifying bots, IP risk session based threats. It’s not just looking at specifically ATO.
Jason: I’d say with ATO, a lot of technology just looks at “I want to stop ATO by blocking automation”. You have a lot of bot mitigation products that do that. You could stop ATO by having a multifactor. There’s a lot of ways to try to prevent it. But again, our approach is taking these silos, that are blind, to really understanding if that bot is a real risk and combining that with the verification of the user, combining that with identification of their interactions to other users, environmental things, credential hygiene that the user might have.
Let’s try to be preemptive to stopping attacks. If you think about an ATO, typically it’s from a credential breach. But what if those credentials have been breached but they haven’t been exposed publicly yet? Now how do you determine that? How do you determine if someone has poor credential hygiene?
The credentials might not have been breached, a company might not have been breached, but they are a risk to the organization because they possibly share credentials with other people. Or maybe they leverage those credentials, their corporate credentials, which should be a lot more secure and controlled, on social networks. Our technology, because of where we sit and the visibility we have, we’re able to triangulate that. And that provides better visibility and an indication of possible breach to an organization, than a lot of the technologies that, again, are after boom.
Compliance-driven reports and analytics
Your platform provides compliance, written reports and analytics. Can you tell us more about it?
Paul: All these bits of information are being streamlined. We could either visualize that through our own dashboards or you can basically tie it into a SIEM or SOC. With all of this data, we’re able to look at things from an actual compliance side of things, especially on devices that aren’t managed.
And once they recognize that, then Cymatic can start remediating that on the fly. So, we do a lot of auto remediation. We don’t have a lot of roles because once you start flipping switches, turning knobs, and you don’t really understand how the product is making decisions, it actually increases your risk. We try to take all that decision making out of the organization, put it into the product, let the product remediate. And then over time you see these gaps start settling and going away.
Also, out of that is these reports that provide organizations insight to their probability of being breached. Cause today, if you ask CISOs or anyone in security: “Do you really understand the probability that your organization could be breached?” Typical answer is no, they just don’t, with the current toolset. At Cymatic, we can print out this report and they can say: “Okay, I feel not that they’re not going to get breached, but I feel a lot more confident in our ability to defend against any attack that we might have.”
To find out more information, please visit our website at cymatic.io and you can always contact us. There’s information on there too. If you want to learn more about Cymatic or see a demo and how it can help your organization.