2600
<html>
<head> <meta http-equiv=“Content-Type” content=“text/html; charset=windows-1252”> <meta name=“GENERATOR” content=“Microsoft FrontPage? 4.0”> <meta name=“ProgId?” content=“FrontPage?.Editor.Document”> <title></title> <!--************************Overall Style************************-->
<STYLE type=text/css> A:link { FONT-WEIGHT: normal; COLOR: #000000; TEXT-DECORATION: none } A:visited { COLOR: #000000; TEXT-DECORATION: none } A:active { COLOR: #0000000; TEXT-DECORATION: none } A:hover { CURSOR: crosshair; COLOR: #000000; TEXT-DECORATION: underline overline
}
</STYLE> <style> BODY{ scrollbar-face-color: “#ffffff”; scrollbar-shadow-color: “#ffffff”; scrollbar-highlight-color: “#000000”; scrollbar-3dlight-color: “#ffffff”; scrollbar-darkshadow-color: “#000000”; scrollbar-track-color: “#ffffff”; scrollbar-arrow-color: “#000000”; background-repeat: no-repeat;
) </style>
</head>
<body>
<p>2600 INTERNATIONAL</p>
</body>
</html>
Penetration testing guide Introduction Penetration testing is an often confused term. Through this guide Corsaire, a world leader in information security, provides a broad overview of what it means, why you would want it, and how to get the most out of the process.
What is a penetration test? Why conduct penetration testing? What can be tested? What should be tested? What do you get for the money? What to do to ensure the project is a success What is a penetration test? Much of the confusion surrounding penetration testing stems from the fact it is a relatively recent and rapidly evolving field. Additionally, many organisations will have their own internal terminology (one man’s penetration test is another’s vulnerability audit or technical risk assessment).
At its simplest, a penetration-test (actually, we prefer the term security assessment) is the process of actively evaluating your information security measures. Note the emphasis on ‘active’ assessment; the information systems will be tested to find any security issues, as opposed to a solely theoretical or paper-based audit.
The results of the assessment will then be documented in a report, which should be presented at a debriefing session, where questions can be answered and corrective strategies can be freely discussed.
Why conduct a penetration test? From a business perspective, penetration testing helps safeguard your organisation against failure, through:
Preventing financial loss through fraud (hackers, extortionists and disgruntled employees) or through lost revenue due to unreliable business systems and processes. Proving due diligence and compliance to your industry regulators, customers and shareholders. Non-compliance can result in your organisation losing business, receiving heavy fines, gathering bad PR or ultimately failing. At a personal level it can also mean the loss of your job, prosecution and sometimes even imprisonment. Protecting your brand by avoiding loss of consumer confidence and business reputation. From an operational perspective, penetration testing helps shape information security strategy through:
Identifying vulnerabilities and quantifying their impact and likelihood so that they can be managed proactively; budget can be allocated and corrective measures implemented. What can be tested? All parts of the way that your organisation captures, stores and processes information can be assessed; the systems that the information is stored in, the transmission channels that transport it, and the processes and personnel that manage it. Examples of areas that are commonly tested are:
Off-the-shelf products (operating systems, applications, databases, networking equipment etc.) Bespoke development (dynamic web sites, in-house applications etc.) Telephony (war-dialling, remote access etc.) Wireless (WIFI, Bluetooth, IR, GSM, RFID etc.) Personnel (screening process, social engineering etc.) Physical (access controls, dumpster diving etc.) What should be tested? Ideally, your organisation should have already conducted a risk assessment, so will be aware of the main threats (such as communications failure, e-commerce failure, loss of confidential information etc.), and can now use a security assessment to identify any vulnerabilities that are related to these threats. If you haven’t conducted a risk assessment, then it is common to start with the areas of greatest exposure, such as the public facing systems; web sites, email gateways, remote access platforms etc.
Sometimes the ‘what’ of the process may be dictated by the standards that your organisation is required to comply with. For example, a credit-card handling standard (like PCI) may require that all the components that store or process card-holder data are assessed.
What do you get for the money? While a great deal of technical effort is applied during the testing and analysis, the real value of a penetration test is in the report and debriefing that you receive at the end. If they are not clear and easy to understand, then the whole exercise is of little worth.
Ideally the report and debriefing should be broken into sections that are specifically targeted at their intended audience. Executives need the business risks and possible solutions clearly described in layman’s terms, managers need a broad overview of the situation without getting lost in detail, and technical personnel need a list of vulnerabilities to address, with recommended solutions.
What to do to ensure the project is a success Defining the scope
The scope should be clearly defined, not only in the context of the components to be (or not to be) assessed and the constraints under which testing should be conducted, but also the business and technical objectives. For example penetration testing may be focussed purely on a single application on a single server, or may be more far reaching; including all hosts attached to a particular network.
Choosing a security partner
Another critical step to ensure that your project is a success is in choosing which supplier to use.
As an absolute fundamental when choosing a security partner, first eliminate the supplier who provided the systems that will be tested. To use them will create a conflict of interest (will they really tell you that they deployed the systems insecurely, or quietly ignore some issues).
Detailed below are some questions that you might want to ask your potential security partner:
Is security assessment their core business? How long have they been providing security assessment services? Do they offer a range of services that can be tailored to your specific needs? Are they vendor independent (do they have NDAs with vendors that prevent them passing information to you)? Do they perform their own research, or are they dependent on out-of-date information that is placed in the public domain by others? What are their consultant’s credentials? How experienced are the proposed testing team (how long have they been testing, and what is their background and age)? Do they hold professional certifications, such as PCI, CISSP, CISA, and CHECK? Are they recognised contributors within the security industry (white papers, advisories, public speakers etc)? Are the CVs available for the team that will be working on your project? How would the supplier approach the project? Do they have a standardised methodology that meets and exceeds the common ones, such as OSSTMM, CHECK and OWASP? Can you get access to a sample report to assess the output (is it something you could give to your executives; do they communicate the business issues in a non-technical manner)? What is their policy on confidentiality? Do they outsource or use contractors? Are references available from satisfied customers in the same industry sector? Is there a legal agreement that will protect you from negligence on behalf of the supplier? Does the supplier maintain sufficient insurance cover to protect your organisation? Standards compliance There are a number of good standards and guidelines in relation to information security in general, for penetration tests in particular, and for the storage of certain types of data. Any provider chosen should at least have a working knowledge of these standards and would ideally be exceeding their recommendations.
Notable organisations and standards include:
PCI The Payment Card Industry (PCI) Data Security Requirements were established in December 2004, and apply to all Members, merchants, and service providers that store, process or transmit cardholder data. As well as a requirement to comply with this standard, there is a requirement to independently prove verification.
ISACA ISACA was established in 1967 and has become a pace-setting global organization for information governance, control, security and audit professionals. Its IS Auditing and IS Control standards are followed by practitioners worldwide and its research pinpoints professional issues challenging its constituents. CISA, the Certified Information Systems Auditor is ISACA’s cornerstone certification. Since 1978, the CISA exam has measured excellence in the area of IS auditing, control and security and has grown to be globally recognized and adopted worldwide as a symbol of achievement.
CHECK The CESG IT Health Check scheme was instigated to ensure that sensitive government networks and those constituting the GSI (Government Secure Intranet) and CNI (Critical National Infrastructure) were secured and tested to a consistent high level. The methodology aims to identify known vulnerabilities in IT systems and networks which may compromise the confidentiality, integrity or availability of information held on that IT system. In the absence of other standards, CHECK has become the de-facto standard for penetration testing in the UK. This is mainly on account of its rigorous certification process. Whilst good it only concentrates on infrastructure testing and not application. However, open source methodologies such as the following are providing viable and comprehensive alternatives, without UK Government association. It must also be noted that CHECK consultants are only required when the assessment is for HMG or related parties, and meets the requirements above. If you want a CHECK test you will need to surrender your penetration testing results to CESG.
OSSTMM The aim of The Open Source Security Testing Methodology Manual (OSSTMM) is to set forth a standard for Internet security testing. It is intended to form a comprehensive baseline for testing that, if followed, ensures a thorough and comprehensive penetration test has been undertaken. This should enable a client to be certain of the level of technical assessment independently of other organisation concerns, such as the corporate profile of the penetration-testing provider.
OWASP The Open Web Application Security Project (OWASP) is an Open Source community project developing software tools and knowledge based documentation that helps people secure web applications and web services. It is an open source reference point for system architects, developers, vendors, consumers and security professionals involved in designing, developing, deploying and testing the security of web applications and Web Services.
The key areas of relevance are the forthcoming Guide to Testing Security of Web Applications and Web Services and the testing tools under the development projects. The Guide to Building Secure Web Applications not only covers design principals, but also is a useful document for setting out criteria by which to assess vendors and test systems.
Glossary Listed below is detailed glossary of penetration testing terminology. Inclusion here does not imply any form of endorsement on the behalf of Corsaire; the link is supplied for your convenience only.
http://www.ee.oulu.fi/research/ouspg/sage/glossary About Corsaire Corsaire is a market leader in information security consultancy and vulnerability research. Privately founded in 1997, we provide a range of consulting and assessment services to help organisations measure their security posture and build a thorough compliant security program to support their business strategy. We operate on an international basis with a presence across Europe and the Asia-Pacific rim. Our clients include some of the world’s best known blue-chip multinationals, many of whom are listed on the FTSE, DAX and Fortune 500 stock indices although we also have a selection of UK government authorities and agencies and mid-range organisations. Most of our clients have been drawn the e-banking, finance, telecommunications, insurance, legal, IT and retail sectors. They are all mature buyers, operate at the highest end of security and understand the differences between the ranges of suppliers in the current market place.
Legal Notice Rules and Regulations The following rules and regulations apply to all visitors to or users of this website. By accessing this website, user acknowledges acceptance of these terms and conditions. Corsaire Limited (“Corsaire”) reserves the right to change these rules and regulations from time to time at its sole discretion. In the case of any violation of these rules and regulations, Corsaire reserves the right to seek all remedies available by law and in equity for such violations. These rules and regulations apply to all visits to the Corsaire website, both now and in the future.
Limited License Corsaire hereby authorizes you to copy materials published by Corsaire on this website solely for non-commercial use within your organisation. No other use of the information is authorised. In consideration of this authorisation, you agree that any copy of these materials which you make shall retain all copyright and other proprietary notices in the same form and manner as on the original. Except as specified above, nothing contained herein shall be construed as conferring by implication or otherwise any license or right under any patent, trademark or copyright of Corsaire or any third party.
ALL CONTENTS ON THIS SITE ARE PROTECTED BY COPYRIGHT. EXCEPT AS SPECIFICALLY PERMITTED HEREIN, NO PORTION OF THE INFORMATION ON THIS WEBSITE MAY BE REPRODUCED IN ANY FORM, OR BY ANY MEANS, WITHOUT PRIOR WRITTEN PERMISSION FROM CORSAIRE. VISITORS OR USERS ARE NOT PERMITTED TO MODIFY, DISTRIBUTE, PUBLISH, TRANSMIT OR CREATE DERIVATIVE WORKS OF ANY MATERIAL FOUND ON THIS SITE FOR ANY PUBLIC OR COMMERCIAL PURPOSES.
Trademarks The trademarks, logos and service marks (“Marks”) displayed on this website are the property of Corsaire or other third parties. Users are not permitted to use these Marks without the prior written consent of Corsaire or such third party which may own the Mark.
General Disclaimer Although Corsaire has attempted to provide accurate information on the website, Corsaire assumes no responsibility for the accuracy of the information. Corsaire may change the programs or products mentioned at any time without notice. Mention of non-Corsaire products or services is for information purposes only and constitutes neither an endorsement nor a recommendation.
ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED “AS IS” WITH ALL FAULTS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. CORSAIRE AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
CORSAIRE AND ITS SUPPLIERS SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR REVENUES, COSTS OF REPLACEMENT GOODS, LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS SITE OR ANY CORSAIRE PRODUCT, DAMAGES RESULTING FROM USE OF OR RELIANCE ON THE INFORMATION PRESENT, EVEN IF CORSAIRE OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Disclosure; Forward-Looking Statements Some of the information on this website may contain projections or other forward-looking statements regarding future events or the future financial performance of the Company. We wish to caution you that these statements are only predictions and that actual events or results may differ materially.
Transmission of Personal Data/User Communications Except as required by law, Corsaire will maintain the confidentiality of all personal information transmitted to Corsaire by the user.
Cookies A cookie is a small data file that certain websites write to your hard drive when you visit them. A cookie file can contain information such as a user ID that the site uses to track the pages you’ve visited, but the only personal information a cookie can contain is information you supply yourself. A cookie can’t read data off your hard disk or read cookie files created by other sites. No part of the Corsaire website requires the use of cookies.
Links to Third Party Sites This website may contain links to third party sites. Access to any other Internet site linked to this website is at the user’s own risk and Corsaire is not responsible for the accuracy or reliability of any information, data, opinions, advice or statements made on these sites. Corsaire provides these links merely as a convenience and the inclusion of such links does not imply an endorsement.
This is the html version of the file http://research.corsaire.com/whitepapers/040405-application-level-dos-attacks.pdf. G o o g l e automatically generates html versions of documents as we crawl the web. To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:8QCjObgl9awJ:research.corsaire.com/whitepapers/040405-application-level-dos-attacks.pdf+Corsaire+resource&hl=en&ct=clnk&cd=2&gl=us
Google is neither affiliated with the authors of this page nor responsible for its content. These search terms have been highlighted: corsaire resource
Page 1 The natural choice for information security solutionsA Corsaire White Paper:Application Denial of Service (DoS?)AttacksAuthor? Stephen de Vries Document Reference 03-03-04 Application Level DoS? Attacks v0.4.docDocument Revision V1.0 ReleasedDate? 1 April 2004© Copyright 2000 - 2004, Corsaire Limited. All Rights Reserved
Page 2 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 2 of 11Table of Contents TABLE OF CONTENTS……………………………………………………………………………………………….21.INTRODUCTION………………………………………………………………………………………………….31.1Denial of Service Attacks ………………………………………………………………………………..32.APPLICATION DOS OVERVIEW…………………………………………………………………………..42.1Root Causes……………………………………………………………………………………………………42.2Application DoS? Attack Vectors ………………………………………………………………………53.APPLICATION DOS ATTACKS…………………………………………………………………………….63.1Attack Classes………………………………………………………………………………………………..63.2User Based Attacks…………………………………………………………………………………………63.3Transaction Resources……………………………………………………………………………………83.4Attacking the Database……………………………………………………………………………………83.5Session ID Exhaustion…………………………………………………………………………………….84.CONCLUSIONS…………………………………………………………………………………………………10ACKNOWLEDGEMENT …………………………………………………………………………………………….11About The Lead Author ……………………………………………………………………………………………11About Corsaire…………………………………………………………………………………………………………11
Page 3 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 3 of 111. Introduction In order to achieve business goals, organisations frequently have to develop bespoke application solutions or customise commercial off-the-shelf (COTS) packages. These rangefrom complex back-office database applications, CRMs and asset management systems to customer-facing fat and thin applications. Corporate web-applications offer anything from a simple brochure request to a full e-business implementation. Availability of these services is important for customers and users of the site, with any disruption directly affecting revenues, negatively impacting confidence in the company or even damaging the brand. Denial of Services (DoS?) attacks aimed at disrupting network services range from simple bandwidth exhaustion attacks and those targeted at flaws in commercial software to complex distributed attacks exploiting specific COTS software flaws. These types of attack are not new and have been used to devastating effect to prevent normal operation of the victim sites. Historically, these attacks by hacktivists and extortionists alike have targeted companies asdiverse as eBay and Microsoft, the RIAA and SCO, and a plethora of online gambling companies. Attackers have not, as yet, exploited the full range of vulnerabilities present in many onlineservices – particularly attacks aimed at the application and data processing layer. With the rise of increasingly targeted and motivated attacks and attackers, these application level DoS? attacks will inevitably be exploited for nefarious gains.1.1 Denial of Service Attacks Conceptually, DoS? attacks are intended to prevent legitimate users, customers or clients of a site from successfully accessing it. Traditional DoS? attacks have been aimed at consuming resources or disrupting services at the network or operating system level. Typical examples are server-based attacks such as SYN floods and bandwidth exhaustionattacks that attempt to saturate the victim’s Internet connection with spurious traffic.
Page 4 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 4 of 112. Application DoS? Overview Application DoS? attacks exploit flaws in the bespoke application design and implementation toprevent legitimate access to the victim’s services. They represent a subset of potential attacks on such applications, as they are aimed specifically at disrupting operation rather than subverting the application controls. Attacks based on exploiting these flaws can offer the attacker a number of advantages over traditional DoS? attacks: •The attacks will typically not be detectable or preventable by existing security monitoring solutions1– Since the attacks do not consume an unreasonable amount of bandwidth and could, in many cases, be indistinguishable from normal traffic. •Application attacks are more efficient – The attacker may not need as much resource at their disposal to successfully complete the attack. Application level attacks targetbottlenecks and resources limitations within the application and do not require manycompromised “zombie” systems or a large amount of bandwidth. Furthermore, they can be targeted at the weakest link in an environment – for example if a web-farm of ahundred servers relies on a single back-office host to authenticate users, an applicationattack may be able to directly target it. •Application attacks are harder to trace – Application level attacks normally use HTTP orHTTPS as their transport. Proxy servers can therefore be used to obfuscate the trueorigin of the attacker; and many are available for an attacker to redirect his malicious traffic. Many of these proxy servers do not keep logs of connection attempts and could therefore successfully hide the true origin of the attacking host. 2.1 Root Causes Application security flaws exist due to flawed design and implementation, often as a result ofincorrect assumptions made during the development process. 2.1.1 Reasonable Use Expectations Applications are designed and built based on expected use criteria. Capacity planning and load-testing are typically based on these criteria of expected and maximum use. As with network DoS? attacks, this narrow view of how the application may be used exposes it todisruption when those expectations are exceeded. 2.1.2 Application Environment BottlenecksApplications? are becoming increasingly complex and often reside in distributed environments. The traditional approach to providing adequate capacity has been to focus resources on theclient-facing tier, e.g. having a large web-farm. Often, back-office functionality such as authentication and database access have far less resource allocated. Whilst the front-end may therefore be able to cope with far more than the expected or possible demand, there may be hidden bottlenecks elsewhere within the environment that, while not accessible to an attacker via the network, can be targeted through the application itself. 2.1.3 Implementation FlawsMost? existing DoS? attacks have been designed to crash COTS applications or services. Thissame class of application attack is equally, if not more, likely to work on bespoke applications. An attacker may be able to crash application or middleware components using buffer overflow 1E.g. intrusion detection (IDS) and intrusion prevention systems (IPS)
Page 5 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 5 of 11style attacks, for example. This could be due to a poorly implemented software module such as an ISAPI filter failing when sent excessive input data. 2.1.4 Poor data validation Another common mistake is to implicitly trust input from the client side and user. In many cases, the application acts as a structured portal through which users interact with back-endservices and databases. If these functions do not sufficiently validate client-input, it may bepossible to disrupt those back-end services through attacks such as Database (SQL) or Script(XSS) insertion. 2.2 Application DoS? Attack Vectors 2.2.1 Automated Data Submission Web application architects and designers frequently assume that the user of the application is aperson and not an automated script. This assumption often leads to vulnerabilities that can beexploited by attackers who craft automated tools to attack the application. A simple example would be a dictionary attack on the authentication process. If a username is known, an attacker may automate the login process using passwords from a dictionary of common words until a match is found. There are many tools available to perform dictionary attacks on various protocols. Similarly, variations on this theme can be used to attack specific weaknesses in the application’s design, for example by overwhelming application functions, invoking race conditions or systematically attacking multiple entities. 2.2.2 Data Manipulation Any data sent from the client-side may be manipulated by an attacker, from obvious form elements that are completed by the user to hidden fields, cookies and bespoke data channels.Commonly, manipulation of this data before sending it to the server results in errors or unusual application behaviour – even as a result of simple modification such as sending letters instead of numbers. These back-end errors may in turn lead to exploitable vulnerabilities.
Page 6 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 6 of 113. Application DoS? Attacks 3.1 Attack Classes 3.1.1 Resource abuse and starvation The simplest way to attack an application is to exceed expected use beyond the capacity of theenvironment. This is conceptually very similar to a Network DoS? attack in that it preventslegitimate users from accessing the application while it is forced to deal with many false requests. 3.1.2 ExploitationMore? sophisticated attacks are based on an analysis of the application and its functionality, and identification of susceptible components. This may involve overflows on application buffers to crash the components on the servers themselves, or destruction of back-end data through SQLinsertion for example. 3.2 User Based Attacks In any application that makes use of user based authentication (e.g. a username and some formof password), the authentication system may be vulnerable to DoS? attack. 3.2.1 Login Process DoS? It may be possible to overwhelm the login process by continually sending login-requests that require the presentation tier to access the authentication mechanism, rendering it unavailable or unreasonably slow to respond. 3.2.2 Username Enumeration When a user enters an incorrect username and/or password, the application should respond with a generic error message stating that the information entered was incorrect. If theapplication explicitly states which component of the username/password pair was incorrect thenan attacker can automate the process of trying common usernames from a dictionary file in anattempt to enumerate the users of the application. Whilst applications may handle authentication failure messages correctly, many still allow attackers to enumerate users through the forgotten password feature. Typically, this feature requires the user to enter some form of identification before re-establishing access to anaccount. Many forgotten password features require only the username to be entered before responding with a message as to its validity. If the application behaves in this manner, as with login messages it is a trivial exercise to automatically deduce valid usernames. With a list of valid usernames an attacker can attempt to mount automated attacks against theauthentication mechanism. 3.2.3 Account Lockout In order to mitigate dictionary attacks, many applications implement an account lockout procedure to freeze a user’s access should they make too many failed login attempts. The lockout facility is designed to deny access to users performing illegal operations, or who are suspected of malicious intent. Since this mechanism is designed to deny access to the application, if it is not properly implemented it may be abused by attackers to deny access to legitimate users. A number of strategies may be employed by the lockout facility: 1. Lock the account and require manual intervention to re-enable it – Any form ofpermanent lockout should be carefully evaluated to ensure that the process used to
Page 7 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 7 of 11unlock the accounts doesn’t require too much resource. Care should be taken whenchoosing lockout mechanisms that require manual intervention since they may bedifficult to action should a large number of users be locked out simultaneously. 2. Lock out the IP address of the user temporarily or permanently – Locking out users based on their IP address could create unforeseen problems as many use shared proxy servers2or are in NAT environments. Locking out the proxy server’s IP address could inadvertently deny service to many legitimate users. 3. Lock the account out for a certain period of time only – This is often the best choice of lockout mechanism for as it prevents attackers from performing dictionary or brute forceattacks, but still prevents them from locking out legitimate users. It also requires theleast resource and interaction from the provider. Attackers can abuse the first two lockout mechanisms using the same technique: 1. Enumerate usernames through another vulnerability in the application 2. Attempt to authenticate to the site using valid usernames and incorrect passwords 3. Systematically lock-out the accounts after the specified number of failed attempts At this point legitimate users will not be able to use the site, and will have to follow the account unlocking procedure. Depending on the business requirements of the application and the account un-locking procedures, automated account locking of a large portion of the application’s user base canhave an immediate damaging impact on the availability of online services. 3.2.4 Creating multiple false users Some applications have the requirement of allowing users to sign-up, register or join theapplication by a fully automated method. This typically involves the user choosing a usernameand password and entering their required details. If there is no manual interaction required in this process, and if the application does not provide a mechanism to ensure that it is a person entering the data, then it may be susceptible to automated attack. An attacker could use files containing lists of usernames, passwords, telephone numbers, addresses and even fictional credit card numbers. These lists could be created by manipulatingthe data from common dictionaries. Once in hand, the attacker could create a program that submits the registration forms repeatedly; adding a large number of spurious users to theapplication. This could in itself be a form of attack, since any statistical analysis of the user data will belargely skewed to the side of fiction. Besides the threat to business process posed by the existence of a large amount of fictional data, there is also the risk that the attacker can usethese user accounts to perform transactions through the application. With a pool of thousands of fictional users at their disposal, an attacker could develop starvation attacks that would haveall the users purchase goods at exactly the same time, for example. Checks should be built in to susceptible portions of the application to ensure that a person, and not an automated script, is submitting the data. One technique used particularly in high traffic sites is for the application to generate a random sequence of characters, displaying them as images that are slightly distorted and then requires the user to enter them3. This will foil most automation attempts as image recognition software has difficulty recognising these characters. Another technique is to send an email to the user that requires them to click on a link to activatetheir account. While this may deter casual attackers, those with more determination can setupa system that receives and process those emails automatically. 2E.g. AOL, cable and DSL users. 3For more information on this approach see the CAPTCH project at http://www.captcha.net.
Page 8 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 8 of 113.3 Transaction Resources Each transaction performed by the application requires resources such as processing time andstorage space. By triggering an excessive number of transactions, the attack may be able to prevent normal operation of the application. Some transactions may even incur a financial cost, such as when requesting third party services that are billed per transaction. Sending SMS messages or implementing automatic call back facilities also incur costs for each transaction. If an attacker has created thousands offictional users, then it may be possible, through the use of an automated script to perform thousands of transactions that could incur a substantial cost. 3.4 Attacking the Database Many web applications use databases extensively to store static data, which is accessed and modified infrequently, and dynamic data which is used to manage the user sessions. Eachdatabase operation incurs an overhead in storage space and processor cycles with static limits to both these resources. Simple application functions such as searches, performing user authentication or submitting registration forms often require the database to access data and toconsume resources. An attacker needs access to a large amount of bandwidth should he wish to attempt to flood thevictims internet connection. Considerably less resource may be required if the attack is instead directed at a few carefully selected database queries. Complex database queries that can beperformed without authentication are the most at risk, since they consume a larger amount ofresource and can be accessed by anyone. Search functions that allow users to enter queries innatural language are a good example of a complex query. These require a comparatively largeamount processing time for each query, especially if they allow the use of wildcard characters. Should thousands complex queries repeatedly be submitted, the strain on the application mayaffect other more critical components, and could even prevent legitimate users from performingtransactions.3.5 Session ID Exhaustion The HTTP protocol is stateless; meaning that each request to a web server is unique andunconnected to any preceding requests. A requirement of modern web applications is that ausers multiple requests to be associated with each other across a “session”, requiring uniqueHTTP requests be tracked and connected. A session typically begins when a user logs in to the application and ends when they logout. This session management is usually implementedthrough a unique, random identifier, called a Session ID, created at the start of the session.The client transmits this ID with all subsequent HTTP requests so that the server can identify the user. The session IDs and corresponding session information is usually maintained in a database orat the application level. Each session ID that is generated therefore requires resource in terms of processing time and storage space. Attackers may use this to keep requesting session ID’sin an attempt to exhaust the available resources and thereby deny access to legitimate users. The attacker’s ability to request that the application generate a new session ID is largely controlled by the chosen session management strategy. As far as the generation of session IDs are concerned, applications can be broken down into three broad categories: •The application generates a session ID when the user visits a specific page, without authenticating. This is the most vulnerable class of application, as the attacker can request many session IDs easily, and quickly. •The application generates a session ID only after the user authenticates and allows multiple sessions for the same user. This requires the attacker has a valid user accounton the application before session ID request’s can be sent, but since the application allows multiple sessions for a single user it is still relatively easy to generate manysession IDs in a short space of time.
Page 9 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 9 of 11•The application generates a session ID after authentication and only allows one sessionper user. This is a more secure approach, since the attacker will have to use multiple user accounts to cause the application to track multiple session IDs. For someapplications where user accounts are granted through a manual or manually-assistedprocess, it will be almost impossible for an attacker to create the required number of user accounts. But, where applications are vulnerable to automated registration scripts (section 2.2.1), it is only moderately more difficult for an attacker to sign-up thousands of fictitious users and have them all log in and request session IDs at the same time. The generation of session IDs and the resources used to manage sessions can often beoverwhelmed if an attacker has the ability to generate a large number of session IDs.
Page 10 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 10 of 114. Conclusions Vulnerabilities in web applications can allow attackers to exhaust available resources and thereby deny access to legitimate users. Companies that rely on web applications to provide critical business functions are therefore at risk from attackers wishing to disrupt these functions by exploiting application level vulnerabilities. Application based DoS? attacks require considerably less resource in terms of processing powerand bandwidth on the part of the attacker, and therefore present a higher risk to business as thenumber of possible threat-agents is much greater. The possibility of a denial of service attack should be considered when designing, implementing and providing applications, and appropriate strategies and mitigation techniques put in placewithin the application.
Page 11 Corsaire White Paper: Application DoS? Attack © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 11 of 11Acknowledgement This White Paper was written by Stephen de Vries and Glyn Geoghegan, Principal Consultants at Corsaire Limited. About The Lead Author Stephen de Vries is a Principal Consultant in Corsaire’s Security Assessment team. He has workedin IT Security since 1998, and has been programming since 1997. He has spent the last four years focused on Ethical Hacking, Security Assessment and Audit at Corsaire, KPMG and Internet Security Systems. He was a contributing author and trainer on the ISS Ethical Hacking course and TechnicalLeader? for the Automated Perimeter Scanning project co-coordinating a team of six developers inthree countries. Stephen’s past roles have included that of a Security Consultant at a leading City of London Financial institution and also Security Engineer at SMC Electronic Commerce. At both positions he was involved in corporate security at many levels and was responsible for consulting on thepaper security policies and procedures, conducting vulnerability assessments, designing, deploying and managing the security infrastructure of the organisation. About Corsaire Corsaire are experts at securing information systems. Through our commitment to excellence we help organisations protect their information assets, whilst communicating more effectively.Whether they are interacting with customers, employees, business partners or shareholders,our sound advice can help our clients reduce corporate risk and achieve tangible value fromtheir investments. Privately founded in 1997 and with offices in the UK and Australia, Corsaire are known for our personable service delivery and an ability to combine both technical and commercial aspects into a single business solution. With over eight years experience in providing information security solutions to the UK Government’s National Security Agencies, Governmentdepartments and major private and non-profit sectors, we are considered a leading specialist inthe delivery of information security planning, assessment, implementation and management. Corsaire take a holistic view to information security. We view both business and security objectives as inseparable and work in partnership with our clients to achieve a cost-effectivebalance between the two. Through our consultative, vendor-neutral methods we ensure that whatever solution is recommended, an organisation will never be overexposed, nor carry theburden of unnecessary technical measures. Corsaire have one of the most respected and experienced teams of principal consultants available in the industry and have consistently brought fresh ideas and innovation to theinformation security arena. We take pride in being a knowledge-based organisation, but wedon’t just stop there. Through a culture of knowledge-share, we are also committed to improving our client’s internal understanding of security principles. It is this approach to knowledge that differentiates us from most other information security consultancies. As a mark of this, we are known globally through our active contribution to the security research community, publishing papers and advisories on a regular basis. These we share freely with our clients, providing them with immediate access to the most up-to-date information risk management advice available, allowing them to minimize their exposure and gain an instant competitive advantage. Whilst it is imperative for us to offer a high level of security to our clients, we believe that it is of equal bearing to provide a high level of service. At Corsaire our clients are not only protectedbut valued too. We work hard at building strong relationships that are founded on thecornerstones of respect and trust. With 80% of our customer base deriving from referrals we are certain that our clients value the quality, flexibility and integrity that partnering with Corsaire brings.For more information contact us at info@corsaire.com or visit www.corsaire.com
This is the html version of the file http://research.corsaire.com/whitepapers/040211-surviving-ddos-attacks.pdf. G o o g l e automatically generates html versions of documents as we crawl the web. To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:DhZ8rs6Eh-oJ:research.corsaire.com/whitepapers/040211-surviving-ddos-attacks.pdf+Corsaire+resource&hl=en&ct=clnk&cd=3&gl=us
Google is neither affiliated with the authors of this page nor responsible for its content. These search terms have been highlighted: corsaire resource
Page 1 The natural choice for information security solutionsA Corsaire White Paper:Surviving Distributed Denial ofService (DDoS?) AttacksAuthor? Stephen de Vries Document Reference Surviving DDOS Attacks.doc Document Revision V1.0 ReleasedDate? 11 February 2004 © Copyright 2000 - 2004, Corsaire Limited. All Rights Reserved
Page 2 A Corsaire White Paper: Surviving DDoS? Attacks © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 2 of 8 Table of Contents TABLE OF CONTENTS……………………………………………………………………………………………….2INTRODUCTION…………………………………………………………………………………………………………31.ATTACK TYPES………………………………………………………………………………………………….32.MITIGATION STRATEGIES ………………………………………………………………………………….32.1Management strategies …………………………………………………………………………………..32.2Technical strategies………………………………………………………………………………………..43.CONCLUSION …………………………………………………………………………………………………….6ACKNOWLEDGEMENT ………………………………………………………………………………………………7About The Author………………………………………………………………………………………………………7About Corsaire…………………………………………………………………………………………………………..7
Page 3 A Corsaire White Paper: Surviving DDoS? Attacks © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 3 of 8 Introduction Distributed denial of service (DDoS?) attacks aim to disrupt the service of information systems byoverwhelming the processing capacity of systems or by flooding the network bandwidth of thetargeted business. Recently, these attacks have been used to deny service to commercial web sites that rely on aconstant Internet presence for their business. The attacks differ from traditional DDoS? attacks in the targeted nature and shear number of attacking hosts. Even hardened Internet companies such as the SCO group and Microsoft are not immune to attack, and historically high-profile e-tailers such as eBay have had their services disrupted. The threat from the latest attacks has become greater due to the political and financial agendas of those instigating them, particularly the involvement of international organised crime in protection extortion attempts. There is no simple solution to mitigate the risk of these attacks, but there are strategies that canhelp minimize the impact of a large-scale attack. 1. Attack types Recent reports from the NHTCU have warned of DDoS? attacks that use SYN flooding andSMTP flooding to saturate the bandwidth of targeted sites. Although, these are by no means the only attack vectors, they will be the main focus of this paper as they pose the greatest threat to the availability of business sites. SYN flood attacks exploit a feature of the TCP connection by making seemingly legitimateconnection requests, and then discarding the responses. This results in the attacked serverresponding to requests and waiting for connections to complete that never do. The server wastes resources on maintaining these non-existent connections and the bandwidth suffers as a result of the high volume of traffic generated by the initial request and server response. It is believed that SMTP attacks simply send a high volume of e-mails to the targeted server thereby overwhelming both the server and the available bandwidth. Both types of attack effectively deny service to legitimate users by reducing the performance of the site to make it unusable, or causing it to fail altogether. 2. Mitigation strategies 2.1 Management strategies 2.1.1 Planning for attack Without proper planning and forethought, a sustained DDoS? attack can find your organisationwithout the necessary resources or procedures to deal with the attack. It is essential that theresponse procedures are clear and that enough resource, both people and technology, areavailable to effectively handle the attack. 2.1.2 Defining critical services In order to better protect your online business, it is important to identify the most critical part of your online presence. In many cases, organisations use the same connection to the Internet for various purposes such as outbound web traffic, incoming web traffic, SMTP e-mail and DNStraffic. When this connection comes under attack, there should be a clearly identified priority of
Page 4 A Corsaire White Paper: Surviving DDoS? Attacks © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 4 of 8 services that are essential to the business. Once this is decided, further technical mitigation strategies become easier to implement. 2.1.3 Communicating with the ISP In many cases when a sustained high bandwidth attack reaches your servers it will not be possible to contain the attack at your border gateway as the offending packets have already consumed the finite bandwidth available on the connection to the ISP. In this case, having agood relationship and clear communication channels with your ISP are essential in containingthe attack. High bandwidth attacks will have an impact on the ISP’s network and they have a vested interest in assisting you. In addition, since they are closer to the source of the attack they are in a better position to filter the offending traffic. The ISP may already have procedures in place for dealing with this kind of attack.Understanding these procedures and your responsibilities can greatly reduce the time taken to contain an attack. If not already negotiated, such protection mechanisms could form part of thestandard SLAs. 2.1.4 Resources The resources needed to deal with an attack should already be in place when an attack occurs. More bandwidth, additional load balanced servers and support staff should be ready to be deployed in the live environment when the need arises. 2.1.5 Response procedures Clearly defined and understood incident response procedures should be in place both at your organisation and at your ISP. The ISP may be able to provide guidance on how best to respond to DDoS? attacks and what procedures need to be followed by your organisation’s technical staff so that a timely defence is ensured. The escalation procedures, including contact details at the ISP should be documented and if DDoS? protection is part of the SLAs, the response timesshould be specified. The technical team should understand their responsibility in detecting and responding to anattack, and if the need arises, how to escalate the response to the ISP. When the DDoS? attack originates from many compromised hosts, it is likely that your organisation is not the only victim and it may be necessary to contact the National High Tech Crime Unit (www.nhtcu.org). Remediation and investigation efforts can be expedited by contacting the NHTCU prior to anattack to establish a clear communication and escalation procedure.2.1.6 Insurance Where the availability of online services is a critical function to the business, it may be possible to procure insurance to protect against the loss of business as a result of a successful attack. 2.2 Technical strategies 2.2.1 Detecting attacks Certain types of DDoS? attacks are easy to detect as they make use of unusual protocols or attempt to send specific non-standard packets to the targeted systems. Attacks that mimic the behaviour of legitimate users by making repeated requests to the website or by sending a largevolume of e-mails can be much harder to detect. Having an understanding of normal user behaviour and traffic can help in identifying anomalous traffic. Some network based Intrusion Detection Systems (IDS) and network monitoring tools
Page 5 A Corsaire White Paper: Surviving DDoS? Attacks © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 5 of 8 can be used to identify anomalous behaviour on the network and configured to send alerts tothe appropriate personnel. In some cases attacks may be indistinguishable (at the protocol level) from legitimate traffic and it is important that detection mechanisms are able to detect these attacks by analysing the volume of connections per host and not simply relying on attack signatures. The network monitoring tools currently used within your network should be investigated todetermine whether they support detecting anomalous traffic patterns. Secondary monitoring procedures should also be in place to detect attacks that are not identified by the primarydetection tool. These could be bespoke scripts that check the availability of the web site periodically, or a service provided by the ISP or other partner. It is important that the detection mechanism chosen can identify and log details of the attack, such as the source IP address, the protocol used and the payload. 2.2.2 Filtering at the border gatewayUnnecessary traffic destined for your network should be filtered at the border gateway as a matter of course. Protection mechanisms that prevent SYN Flood attacks from reaching servers should also be considered. Popular commercial and open source firewall products now offerthis feature and can provide a limited degree of protection against low bandwidth attacks. However, if the attacks succeed in saturating the available bandwidth between your organisation and the ISP then the protection offered by these devices is negated, in this case it will be necessary to contact your ISP to assist in managing the attack. Furthermore, SYN protecting in firewalls is often a processor intensive function, especially whenunder a DDoS? attack. It is important to ensure the device has sufficient processor and memory capacity to function effectively under heavy load. For these reasons, SYN defences should be provided by devices as far upstream as possible –ideally on the ISP side of the connection. 2.2.3 Filtering at the ISP Since the ISP has more available bandwidth and is closer to the source of the attack, they are ina better position to perform filtering of the malicious traffic. This filtering can usually be done based on two criteria: a) The source and destination IP addresses of the traffic b) The type of traffic In order for the ISP to use the source and destination IP addresses to filter traffic, they will needto know the sources of the attack. The sources should be identified by the detectionmechanism and communicated to the ISP. Where distinct IP addresses are known, the ISP may be able to filter these individually, but there may be occasions where the offending traffic isidentified as originating at another network (or even an entire country). Many DoS? attacks used spoofed packets that do not reveal the true source address of the attacking host. In these cases, the ISP will have to communicate with upstream providers to block traffic from the offending networks. An agreement with the ISP will have to be reached on whether it is feasible to deny traffic from an entire network node, as opposed to individual IP addresses as this may deny access to legitimate users on that network. ISPs can also perform traffic shaping based on the type of traffic. This allows them to permit certain types of traffic while denying others. Where the services critical to the business have been identified, the ISP can give priority to these services while denying or delaying others.
Page 6 A Corsaire White Paper: Surviving DDoS? Attacks © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 6 of 8 2.2.4 SegmentationOnce? critical services are identified, it is possible to segregate these services from other lesscritical services. If the organisations web site is critical to the business, then hosting at a high bandwidth provider should be considered. Other less critical Internet services such as email orFTP could be hosted locally. When designing network defences, it is important to identifybottlenecks in the architecture that could be exploited by attackers. Where possible secondary DNS and email servers should be hosted at different ISPs and at different physical locations. 3. Conclusion DDoS? attacks present a very real threat to online business, even more so when the availability of the service is an essential business function. Traditional firewalls and sensible security at the border gateway can provide some degree of protection against low bandwidth attacks. But more and more attacks are using flooding techniques to saturate the bandwidth of online companies, thereby denying legitimate users access to their services. It is difficult to defend against these attacks at the border gateway, but by careful planning and by communicating withyour ISP, it is possible to provide some level of protection from loss of business.
Page 7 A Corsaire White Paper: Surviving DDoS? Attacks © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 7 of 8 Acknowledgement This White Paper was written by Stephen de Vries, Principal Consultant, Corsaire Limited. About The Author Stephen de Vries is a Principal Consultant in Corsaire’s Security Assessment team. He has workedin IT Security since 1998, and has been programming since 1997. He has spent the last four years focused on Ethical Hacking, Security Assessment and Audit at Corsaire, KPMG and Internet Security Systems. He was a contributing author and trainer on the ISS Ethical Hacking course and TechnicalLeader? for the Automated Perimeter Scanning project co-coordinating a team of six developers inthree countries. Stephen’s past roles have included that of a Security Consultant at a leading City of London Financial institution and also Security Engineer at SMC Electronic Commerce. At both positions he was involved in corporate security at many levels and was responsible for consulting on thepaper security policies and procedures, conducting vulnerability assessments, designing, deploying and managing the security infrastructure of the organisation. About Corsaire Corsaire are experts at securing information systems. Through our commitment to excellence we help organisations protect their information assets, whilst communicating more effectively.Whether they are interacting with customers, employees, business partners or shareholders,our sound advice can help our clients reduce corporate risk and achieve tangible value fromtheir investments. Privately founded in 1997 and with offices in the UK and Australia, Corsaire are known for our personable service delivery and an ability to combine both technical and commercial aspects into a single business solution. With over eight years experience in providing information security solutions to the UK Government’s National Security Agencies, Governmentdepartments and major private and non-profit sectors, we are considered a leading specialist inthe delivery of information security planning, assessment, implementation and management. Corsaire take a holistic view to information security. We view both business and security objectives as inseparable and work in partnership with our clients to achieve a cost-effectivebalance between the two. Through our consultative, vendor-neutral methods we ensure that whatever solution is recommended, an organisation will never be overexposed, nor carry theburden of unnecessary technical measures. Corsaire have one of the most respected and experienced teams of principal consultants available in the industry and have consistently brought fresh ideas and innovation to theinformation security arena. We take pride in being a knowledge-based organisation, but wedon’t just stop there. Through a culture of knowledge-share, we are also committed to improving our client’s internal understanding of security principles. It is this approach to knowledge that differentiates us from most other information security consultancies. As a mark of this, we are known globally through our active contribution to the security research community, publishing papers and advisories on a regular basis. These we share freely with our clients, providing them with immediate access to the most up-to-date information risk management advice available, allowing them to minimize their exposure and gain an instant competitive advantage. Whilst it is imperative for us to offer a high level of security to our clients, we believe that it is of equal bearing to provide a high level of service. At Corsaire our clients are not only protected
Page 8 A Corsaire White Paper: Surviving DDoS? Attacks © Copyright 2000-2004, Corsaire Limited. All Rights Reserved Page 8 of 8 but valued too. We work hard at building strong relationships that are founded on thecornerstones of respect and trust. With 80% of our customer base deriving from referrals we are certain that our clients value the quality, flexibility and integrity that partnering with Corsaire brings.For more information contact us at info@corsaire.com or visit our website at www.corsaire.com