UNDERSTANDING AND RESPONDING TO THE FIVE PHASES OF WEB APPLICATION ABUSE

Transcription

1 White Paper UNDERSTANDING AND RESPONDING TO THE FIVE PHASES OF WEB APPLICATION ABUSE WebApp Secure Provides Real-Time Abuse Detection and Response to Preempt Attacks Before They Can Occur Copyright 2013, Juniper Networks, Inc. 1

2 Table of Contents Executive Summary...3 Introduction...3 Anatomy of Web Application Abuse...3 Phase 1 Silent Reconnaissance... 4 Phase 2 Attack Vector Establishment... 4 Phase 3 Implementation... 5 Phase 4 Automation... 5 Phase 5 Maintenance... 5 Responding to Abuse... 5 A New Approach to Defense... 6 Early Detection from Incident Triggers... 6 Abuse Response...7 Abuse Profiles...7 Conclusion...7 About Juniper Networks Copyright 2013, Juniper Networks, Inc.

3 Executive Summary Web application abuse is very common and often missed by administrators. Web applications can often give attackers unfettered access to critical data that needs to be protected. The sophistication of attackers is growing and the severity of attacks is becoming more damaging. At the same time, traditional approaches to stopping Web attacks that rely on signature-based detection methodologies are increasingly ineffective. If you can t see it, you can t defend against it, and current approaches to combating Web application abuse don t provide enough visibility into the early stages of an attack. To protect their organizations, administrators need to clearly understand the nature of today s advanced attacks, which are typically launched in covert phases, so that they can disrupt and prevent them. The Juniper Networks WebApp Secure technology is an innovative approach that applies abuse detection and response policies to HTML/HTTP streams. This high-performance technology enables administrators to detect abuse activity with no false positives, flushing out abusive users, exposing attacks that were previously indiscernible, and highlighting new and unknown attack vectors against the application. WebApp Secure also slows abusive users down by creating a layer of deception and obfuscation around the application, making it extremely difficult to introspect and map. Introduction When Web applications are the core of your business, protecting them from abuse is crucial. High profile Web applications can provide front-door access to critical data. Sophisticated and organized attackers with deep technology skills are increasingly successful at accessing that data, and the results can be disastrous, from noncompliance, to fraud, to competitive loss. Here are some examples: Bank account fraud: Attackers devise and execute phishing scams to highjack customer accounts and perform fraudulent electronic payments. E-commerce fraud: Attackers make fraudulent purchases, or steal credit card information. This results in a loss of brand credibility, and threatens compliance status with Payment Card Industry Data Security Standard (PCI DSS). Data scraping: Hacking teams for hire establish automated, non-sanctioned calls to business data to power a competitive site or service (e.g., retail pricing, travel bookings). These problems are getting more severe as attackers become better organized and more sophisticated. Traditional approaches to stopping Web attacks that rely on signature-based intrusion Signature-Based detection similar to antivirus are increasingly ineffective. This is the result Protection Not Enough of the combination of two factors. First, Web applications are exposed to the public, and easily introspected by the outside world. Attackers can take Traditional approaches to the time they need to understand how they are coded and which defensive stop Web attacks that rely measures are in place, allowing them to avoid being profiled by varying their solely on signature-based attacks quickly. Second, the criminal community responsible for Web attacks intrusion detection similar to has evolved into a market of its own, complete with highly productized antivirus are only effective command and control suites for creating and managing bots armies of against known attacks and compromised computers on the Internet that are used to distribute, transform, and obfuscate the attack. These suites are sold online as ready-to-go, do-ityourself attack kits. The market for these kits is extremely competitive, with are inneffective against unknown attacks. market demand driving new features and innovations all the time. To realize how advanced targeted threats can be disrupted and prevented, you need to clearly understand the nature of those threats. This white paper describes how sophisticated attackers successfully abuse Web applications, and illustrates how WebApp Secure can help. Anatomy of Web Application Abuse Misunderstandings about the nature of a Web application attack often lead administrators to believe that they are not at risk. An application-related data breach is typically viewed as a one-time event, a piece of shocking news about someone else s misfortunes that appears briefly in the technology press and fades away. The reality is that for a long period the application was being abused and data stolen without administrators knowing about it. Without a way to flush out and highlight user sessions that are engaged in low-level abuse, administrators can only wait until the damage is done. At that point, their only real option is to make defensive changes to the application code and relaunch as quickly as possible. The truth is that application abuse is very common it s just hard to see. When advanced attackers approach an application, they are very aware of their footprint. They execute the attack in phases that balance visibility with Copyright 2013, Juniper Networks, Inc. 3

4 Administrators Unaware of Abuse The reality is that for a long period of time, applications can be abused and data stolen without administrators even knowing it. of a legitimate user. effectiveness. Administrators need to understand these phases before they can identify and respond to abuse effectively. Phase 1 Silent Reconnaissance The first phase is silent reconnaissance. The attacker gathers as much information as possible, and starts identifying potentially vulnerable areas of the application. This is done discretely by using tools such as Web debugging proxies to monitor the traffic between the browser and the Web server. The attacker can then traverse the site, much like a normal user, while collecting valuable information about how the application works. This activity goes undetected, because as far as the server is concerned, it represents the traffic At this point, attackers will stop interacting with the target server directly. They will spend significant time reviewing the data collected by the debugging proxy and extracting useful facts about the environment. This may include the type of hardware and software in the network architecture, programming languages, libraries, source code, and comments. This information will help with the later phases of the attack. Phase 2 Attack Vector Establishment The second phase is attack vector establishment. This phase begins once the attacker has gained an understanding of the application design, and the breadth of its attack surface. Until now, the interaction with the server has been fairly benign and undetectable, but in this phase, things get a little louder. For this reason, attackers will often start using an anonymous proxy to interact with the server. They may also employ other protective measures such as browser privacy controls, firewalls, antivirus, and virtual machines. Once attackers are confident that their traffic can no longer be traced, the real work can begin. With notes in hand, and a debugging proxy up and running, the attacker starts to seek out dynamic pages, especially those which accept form or query input. The attacker will then determine what the various input parameters are, and attempt to derive boundary cases for them. The idea is to send boundary case values to the application to provoke an unintended response from the server. For example, the attacker might change the value of a query parameter from txt to xml in an attempt to get the server to send some informative XML data. The attacker repeats this activity on all dynamic pages that can be detected. When finished, the attacker has a list of all the parameters that are correctly validated by the server, and more importantly, the parameters that are vulnerable, e.g., produce calculation errors, cause fatal errors, or are blindly injected into Attackers Outsmart the response without encoding or cleansing. The attacker tailors the boundary Defenses cases so that they do not match any known attack signatures, making this activity almost always imperceptible to server administrators. The attacker still When effective attack vectors has to remain anonymous, because many applications keep track of errors, and are blocked by signatures, the record the addresses of the clients responsible for generating them. Because attacker just needs to tweak of this, administrators could discover the activity later by inspecting logs with a the input to avoid matching. security tool. However, this is typically long after the attacker has moved on to the next phase. In cases where the attacker has been able to obtain a large number of potentially vulnerable inputs, the next step is to start testing each one to see if an attack vector is possible. For example, if the attacker received an SQL error when submitting a value of myusername in a login form, there is probably an SQL injection vulnerability. The attacker will start supplying more structured SQL syntax into the input in an effort to shape the resulting error. At this point, attack signature detection software (for example, a Web application firewall) would likely detect the threat. However, the attacker really doesn t care about being detected because from the perspective of the server, the attack connection is coming from somewhere else. The goal is not to prevent detection, or even to prevent being blocked, but rather to find out what does not get detected or blocked. If the attacker s IP address is ever completely blocked, a new proxy can be used. Because of the variability of syntax in any given environment, it is nearly impossible to anticipate all possible attack vectors and their permutations. The attack signature library can never be comprehensive enough. When effective attack vectors are blocked by signatures, the attacker just needs to tweak the input to avoid matching. The signature matching tool only provides another level of generic input validation that can easily be evaded. 4 Copyright 2013, Juniper Networks, Inc.

5 Phase 3 Implementation The third phase is implementation. This phase begins once the attacker has identified the vulnerabilities and their associated attack vectors. This is where the real damage begins. The scope of damage depends on the types of vulnerabilities that are exploited. For example: The attacker starts to mine the database for sensitive information, delete existing information, or insert new fraudulent information. The attacker seeds the application with malicious code by way of XSS vulnerabilities and reflected parameters. The attacker designs complex phishing scams that use the vulnerabilities to give the scam credibility. The possibilities are only constrained by the potential vectors and how they can be chained together to deliver more powerful payloads. Most of the damage has been done at this point. Phase 4 Automation The fourth phase is automation. Attacks such as input parameter abuse are often single request vectors. This means that the damage happens within a single HTTP request. Sometimes, however, the execution of an attack vector provides incremental benefits each time it is performed. Generally, if the attack vector generates revenue for the attacker, the next step is to automate the attack. This enables the attacker to repeat the attack vector over and over again, multiplying the overall monetary gain. Attackers Automate Successful Attacks If the attack vector generates revenue for the attacker, the next step is to automate the attack. Because the attackers must still remain undetected in order to execute the automated attack, they will generally code the attack into a remotely controlled bot. A bot allows attackers to distribute the automation logic across a large number of geographically dispersed computers. They can then disseminate the bot and reap the benefits without incurring any risk of detection. This tactic poses serious challenges for the administrator, because even if the attack is identified, an IP-based block will no longer be sufficient. To accomplish this, attackers will often use a prefabricated command and control kit that allows them to quickly raise and command a bot army. Phase 5 Maintenance The final phase is maintenance. Finally the attack is complete. The attacker has extracted as much data as experience and skill allows, and will go off to work on other projects until the automated bots start to fail. This will signal that some fundamental vulnerability in the attack vector has been patched or modified. If the attacker cares enough, the entire process can start all over again, focusing on the parts of the application that are essential for the bot s proper functioning. The attacker will find a workaround for the new patch, create an entirely new attack vector, or move to a different target altogether. Responding to Abuse IT administrators are challenged to respond to Web application abuse, primarily because they can t detect when it happens. The silent reconnaissance behavior is largely invisible to intrusion detection systems, and gets lost in the background noise of normal user behavior. Administrators can deploy signature-based firewalls to block the actual attacks in the implementation phase. But sophisticated attackers evade content firewalls easily by tailoring their approach to avoid known attack patterns. This is made easier by the fact that the firewall filters are rarely applied restrictively, due to concerns about false positives. Another available approach is to implement whitelist rules that tightly Attacks Can Be Hard to constrain all application inputs and weed out attacks, similar to the way Detect network firewalls lock down all undesired communications across a port. But Web applications are complicated. It s hard to spend the time and resources The silent reconnaissance getting those rules right, especially when the development team has behavior is largely invisible moved on to other projects, and there s no one to help understand how the to intrusion detection application works. systems, and gets lost in the The best approach over the long run is to fix the application code itself by background noise of normal implementing more considered input validation and encoding, or changing user behavior. application logic to disrupt automated attacks. But patching application code takes time, and it takes the development team away from the current deliverables. Moreover, the application code is often unavailable because the project was outsourced, or the application is off-the-shelf from a third-party vendor. Copyright 2013, Juniper Networks, Inc. 5

6 Administrators typically find out about the attack from the symptoms and their aftermath, which come in the form of traffic anomalies, bursts at abnormal hours from unusual geographic sources, and unexplained business losses. By this time, the attack is already entrenched. Administrators are forced to spend weeks of sleepless nights stamping out the fire blocking IP addresses and killing accounts only to have it continue to flame up. Members of the IT team spend their time and resources blindly, trying to combat the attack as best they can. But the business is already damaged. Worse, there are often additional infrastructure and transaction costs incurred by the automated attack traffic. Companies find themselves in the position of not only being attacked, but being forced to pay for it as well. A New Approach to Defense The key to responding effectively to Web attacks is early detection and WebApp Secure response identifying abuse during the silent reconnaissance phase, and applying policies that prevent criminals from establishing an attack vector. As an abuse detection and This is the approach taken by WebApp Secure, an abuse detection and response solution for legacy response solution for legacy Web applications. Web applications, WebApp The WebApp Secure (MWS1000 Appliance) is a high-performance, highly Secure enables administrators available Web proxy server that applies abuse detection and response policies to detect abuse activity and to HTML/HTTP streams. Policies consist of three primary components: defend against it without a incident triggers, abuse profiles, and abuse responses. chance of false positives. Early Detection from Incident Triggers Unlike signature-based solutions that wait until an attack is attempted, WebApp Secure increments Web application code at serve time with specific abuse detection points. Many of these detection points are code-level honeypots fake parameters, fake functions, fake inputs, and fake configuration files that appear to end users and attackers as part of the application itself. When attackers touch these detection points as part of their silent reconnaissance of the application, WebApp Secure alerts administrators in real time. Because these objects aren t part of the application code base, they are never called during normal operations. Using WebApp Secure provides a number of benefits: Enables administrators to detect abuse activity without a chance of false positives. Flushes out abusive users, exposing attacks that were previously indiscernible, and highlighting new and unknown attack vectors against the application. Slows abusive users down by creating a layer of deception and obfuscation around the application, making it extremely difficult to introspect and map. The Anaomy of an Attack Identify the Attack Earlier Phase 1 Silent reconnaissance Phase 2 Attack Vendor Phase 3 Implementation Phase 4 Automation Phase 5 Maintenance Establishment Abuse Detection WebApp Secure Abuse Profiles through Intelligence Gathering Abuse Responses Web Application Firewall (PCI) Duration of Attack The Five Phases of an Attack, highlighting where WebApp Secure identifies the attacker earlier than traditional Web Application Firewall (WAF) security techniques. 6 Copyright 2013, Juniper Networks, Inc.

7 Abuse Response WebApp Secure also enables administrators to implement and manage policy-based, user-specific responses to abuse. For example, administrators can send warnings to attackers in the application interface, block them from downloading application code, or alert the Internet service providers (ISPs) from which the attack traffic originates. Abuse Profiles WebApp Secure creates a profile for known abusive users, and tracks all incidents for those profiles over time, rolling them up into an ongoing threat estimate. It uses unique profile re-identification technology to track abusive users after they leave and return, even if they are routing their traffic through anonymous proxy servers. Administrators can create responses for specific profiles, or for profiles with common characteristics (a specific geography and/or threat level, for example). Administrators can also share profile information so that response policies can be applied consistently across applications and organizations. Conclusion Current approaches to combating Web application abuse don t provide enough visibility into the early stages of an attack, and if you can t see it, you can t defend against it. Too often, administrators are forced to deal with attacks that are already underway, or well entrenched. This takes significant time and resources, and fails to prevent damage to the business. By providing early, real-time abuse detection and response, WebApp Secure preempts attacks before they can occur. And, it enables administrators to implement code-level security policies for a Web application that greatly reduce the chances of a successful Web attack against your business. About Juniper Networks Juniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics of networking. The company serves customers and partners worldwide. Additional information can be found at Corporate and Sales Headquarters Juniper Networks, Inc North Mathilda Avenue Sunnyvale, CA USA Phone: 888.JUNIPER ( ) or Fax: APAC and EMEA Headquarters Juniper Networks International B.V. Boeing Avenue PZ Schiphol-Rijk Amsterdam, The Netherlands Phone: Fax: To purchase Juniper Networks solutions, please contact your Juniper Networks representative at or authorized reseller. Copyright 2013 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos and QFabric are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice EN Nov 2013 Printed on recycled paper Copyright 2013, Juniper Networks, Inc. 7