Understanding and Responding to the Five Phases of Web Application Abuse

Transcription

1 Understanding and Responding to the Five Phases of Web Application Abuse Al Huizenga Director of Product Management Kyle Adams Chief Architect Mykonos Software Mykonos Software Copyright 2010

2 The Problem of Web Application Abuse 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 non-compliance, to fraud, to competitive loss. For example: 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 PCI DSS Data scraping. For-hire hacking teams establish automated, non-sanctioned calls to business data to power a competitive site or service (e.g. retail pricing, travel bookings) Traditional approaches to stopping Web attacks that rely on signature based intrusion detection and anti-virus are increasingly ineffective. These problems are getting more severe as attackers become more organized and sophisticated. Traditional approaches to stopping Web attacks that rely on signaturebased intrusion detection and anti-virus are increasingly ineffective. This is the result of the combination of two factors. First, Web applications are exposed to the public, and easily introspected by the outside world. Attackers can take the time they need to understand how they are coded and which defensive measures are in place, allowing them to avoid being profiled by varying their attacks quickly. Second, the criminal community responsible for Web attacks has evolved into a market of its own, complete with highly productized command and control suites for creating and managing bots armies of 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-it-yourself attack kits. The market for these kits is extremely competitive, with 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 whitepaper describes how sophisticated attackers successfully abuse Web applications, and illustrates how the Mykonos Security Appliance can help. Copyright 2010, Mykonos Software, Inc. Page 2

3 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. 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 re-launch 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 effectiveness. Administrators need to understand these phases before they can identify and respond to abuse effectively. The reality is that for a long period the application was being abused and data stolen without administrators knowing. Phase 1 Silent Introspection The first phase is silent introspection. The attacker gathers as much information as possible, and starts identifying potentially vulnerable areas of the application. He does this 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 of a legitimate user. At this point, the attacker 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 the next phase, things get a little louder. For this reason, the attacker 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, anti-virus, and virtual machines. Once the attacker is confident that their traffic can no longer be traced, the real work can start. Copyright 2010, Mykonos Software, Inc. Page 3

4 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. He sends the boundary case values to the application to provoke an unintended response from the server. For example, he 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 he is aware of. When finished, he has a list of all the parameters that are correctly validated by the server, and more importantly the parameters that are vulnerable they produce calculation errors, fatal errors, or are blindly injected into the response without encoding or cleansing. The attacker tailors the boundary cases so that they do not match any known attack signatures, so this activity is almost always imperceptible to server administrators. The attacker still has to remain anonymous, because many applications keep track of errors, and record the addresses of the clients responsible for generating them. Because of this, administrators could discover the activity later by inspecting logs with a security tool. However, this is typically long after the attacker has moved on to the next phase. When effective attack vectors are blocked by signatures, the attacker just needs to tweak his input to avoid matching. If the attacker was 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 a SQL error when submitting a value of my username in a login form, then there is probably a 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 if he is detected, because from the perspective of the server he is connecting from somewhere else. His 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 his IP address is ever completely blocked, he can just go through a new proxy. 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 his input to avoid matching. The signature matching tool only provides another level of generic input validation that can easily be evaded. Copyright 2010, Mykonos Software, Inc. Page 4

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 starts. 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. If the attack vector generates revenue for the attacker, the next step is to automate the attack. 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. Because the attacker must still cover his tracks in order to execute the automated attack, he will generally code the attack into a remotely controlled bot. A bot allows the attacker to distribute the automation logic across a large number of geographically dispersed computers. He 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 pre-fabricated command and control kit that allows them to quickly raise and command a bot army. Copyright 2010, Mykonos Software, Inc. Page 5

6 Phase 5 - Maintenance The final phase is maintenance. Finally the attack is complete. He has extracted as much data as his experience and skill allows. He will go off and work on other projects until his 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, he may repeat the entire process over again, focusing on the parts of the application that are essential for the bots proper functioning. He will find a work around 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 introspection 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 constrain all application inputs and weed out attacks, similar to how network firewalls lock down all undesired communications across a port. But Web applications are complicated. It s hard to spend the time and resources getting those rules right, especially when the development team has moved on to other projects, and there s no one to help understand how the application works. The silent introspection behavior is largely invisible to intrusion detection systems, and gets lost in the background noise of normal user behavior. The best approach over the long run is to fix the application code itself implementing more considered input validation and encoding, or changing application logic to disrupt automated attacks, for example. But patching application code takes time, and takes the development team away from the current deliverables. Moreover, the application code is often unavailable the project was outsourced, or the application is off-the-shelf from a vendor. Administrators typically find out about the attack from the symptoms and aftermath 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. The IT team spends 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, too. Copyright 2010, Mykonos Software, Inc. Page 6

7 A New Approach to Defense The key to responding effectively to Web attacks is early detection and response identifying abuse during the silent introspection phase, and applying policies that prevent criminals from establishing an attack vector. This is the approach of the Mykonos Security Appliance, an abuse detection and response solution for legacy Web applications. The Mykonos Security Appliance is a high-performance, highly available Web proxy server that applies abuse detection and response policies to HTML/HTTP streams. Policies consist of three primary components: incident triggers, abuse profiles, and abuse responses. Early Detection from Incident Triggers Unlike signature-based solutions, which wait until an attack is attempted, the Mykonos Security Appliance 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 introspection of the application, the Mykonos Security Appliance alerts administrators in real time. Because these objects aren t part of the application code base, they are never called during normal operations. This approach has a number of benefits: The Mykonos Security Appliance enables administrators to detect abuse activity without a chance of false positives The Mykonos Security Appliance flushes out abusive users, exposing attacks that were previously indiscernible, and highlighting new and unknown attack vectors against the application The Mykonos Security Appliance slows abusive users down by creating a layer of deception and obfuscation around the application, making it extremely difficult to introspect and map The Mykonos Security Appliance enables administrators to detect abuse activity without a chance of false positives. Copyright 2010, Mykonos Software, Inc. Page 7

8 The Anatomy of an Attack ~ Identify the Attack Earlier Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Silent Introspection Attack Vector Establishment Implementation Automation Maintenance Abuse Detection Abuse Profiles through Intelligence Gathering Abuse Responses Web Application Firewall (PCI) Duration of the Attack Figure 1: Shows the Five Phases of an Attack and highlights where the Mykonos Security Appliance identifies the attacker earlier than traditional Web Application Firewall (WAF) security techniques. Abuse Response The Mykonos Security Appliance 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 ISPs from where the attack traffic originates. Abuse Profiles The Mykonos Security Appliance 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 share profile information so that response policies can be applied consistently across applications and organizations. Copyright 2010, Mykonos Software, Inc. Page 8

9 Conclusion If you can t see it, you can t defend against it. Current approaches to combating Web application abuse don t provide enough visibility into the early stages of an attack. As a result, 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, the Mykonos Security Appliance pre-empts attacks before they can occur. 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. A B O U T M Y K O N O S S O F T W A R E Mykonos Software is solving the problem of Web application security for both new development and existing applications. Mykonos has the Mykonos Framework to give developers complete security coverage and updates at the code layer, and the Mykonos Appliance which sits in front of existing Web applications to provide early abuse detection and response. HEADQUARTERS 1350 Bayshore Highway, Suite 215 Burlingame, CA USA Phone: Toll free: WINGS Copyright 2010, Mykonos Software, Inc. All rights reserved.