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 2012

2 The Problem of Web Application Abuse When Web applications are the core of your business, protecting them from abuse is crucial. 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 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 2012, 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 application was being abused and data stolen without administrators knowing. Without a way 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 silent introspection. The attacker gathers as much information as possible, and starts identifying potentially vulnerable areas of the application. He does this discretely 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 user. At this point, the attacker will stop interacting with the target server directly. They will spend 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 ced, the real work can start. Copyright 2012, 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. 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. 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 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 2012, Mykonos Software, Inc. Page 4

5 Phase 3 Implementation The third phase is Implementation 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» 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. 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. This tactic poses serious challenges for the administrator, because even if the attack is often use a pre-fabricated command and control kit that allows them to quickly raise and command a bot army. Copyright 2012, Mykonos Software, Inc. Page 5

6 Phase 5 - Maintenance 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 process over again, focusing on the parts of the application that are essential for the bots 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. implementation phase. But sophisticated attackers evade content Another available approach is to implement whitelist rules that tightly constrain all application The silent introspection behavior is largely invisible to intrusion detection systems, and gets lost in the background noise of normal user behavior. 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. 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. anomalies, bursts at abnormal hours from unusual geographic sources, and unexplained business losses. By this time, the attack is already entrenched. Administrators are forced 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 sition of not only being attacked, but being forced to pay for it, too. Copyright 2012, 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 Early Detection from Incident Triggers Unlike signature-based solutions, which wait until an attack is attempted, the Mykonos The Mykonos Security Appliance enables administrators to detect abuse activity without a chance of false positives. detection points. Many of these detection points are code-level honeypots fake parameters, pear 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» The Mykonos Security Appliance enables administrators to detect abuse activity without a chance of false positives» ng 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 introspect and map Copyright 2012, 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 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 Abuse Response The Mykonos Security Appliance also enables administrators to implement and manage warnings to attackers in the application interface, block them from downloading application Abuse Profiles that response policies can be applied consistently across applications and organizations. Copyright 2012, 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. 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. ABOUT MYKONOS S O F T W A R E Mykonos, a Juniper Networks company, is the smartest way to protect Websites and Web applications against hackers, fraud and theft. Using deception-based techniques, its Web intrusion prevention system detects, tracks, profiles and prevents attackers in real-time with no false positives. HEADQUARTERS 1350 Bayshore Highway, Suite 215 Burlingame, CA USA Phone: Toll free: WINGS Copyright 2012, Mykonos Software, Inc. All rights reserved Mykonos-EN