AN ORTHUS RESEARCH WHITE PAPER. Published July Orthus Limited

Transcription

1 AN ORTHUS RESEARCH WHITE PAPER Published July 2008 Orthus Limited

2 CONTENTS Introduction... 3 Setting the Scene An Analysis over 5 years... 4 Penetration Testing Defined... 7 No Carrier: War dialling... 7 Peering over the wall: The Outside / In Approach... 8 Black box / White box... 9 Vulnerability Scanning Application Assessment Tools I Robot: The push for automation Security Convergence Assess, Analyse, Remediate, Repeat Down in the Depths: Beyond the Binary Designing Security In Summary July

3 Introduction As network technologies and application features advance at an ever increasing rate so the associated security weaknesses and the test approaches to identify those weaknesses have evolved as well. This paper looks at how penetration testing has developed since its appearance in the seventies and the current tools available to assist security professionals in measuring the effectiveness of deployed security controls. The paper also includes an analysis of 100 baseline security testing engagements delivered since the beginning of Tests for the study were selected on the basis that both the network and application layers were included in the scope. All tests included a complex web application and were delivered across a range of industry sectors including banking, insurance, finance, retail, manufacturing, transport, utilities, health and education. Overall just under 2,000 individual vulnerabilities identified were analysed and the results show a significant shift towards weaknesses associated with the application layer. Whilst network security is improving the clear message from the analysis is that organisations should focus more resources on designing security in to the software development lifecycle. July

4 Setting the Scene An Analysis over 5 years As background for this paper an analysis of the results of 100 baseline security tests was undertaken with security issues identified categorised by layer (network or application) and type. Key findings of the analysis showed: 100% of tests identified at least one security vulnerability at the network level. 97% of tests identified at least one vulnerability at the application level. Network layer weaknesses have come down from an average of 14 per test in 2004 to an average of 6 in tests delivered during 2008 (a reduction of 57%). Conversely application layer weaknesses have increased from 8 per test in 2004 to 12 per test in 2008 (a 50% increase). The breakdown of network and application weaknesses in 2004 and 2008 is shown below. The increase in application related vulnerabilities is clear The analysis highlights an improvement in the way organisations are hardening and configuring network devices and servers prior to use in production environments. Five years ago simple security hardening such as removing unneeded services and limiting open ports was not being carried out. Today it is clear that the need for strong build standards is not only recognised but that they are actually being implemented. Some vulnerabilities are inevitably still present. More than half of these are attributable to weak operational security processes, in particular inadequate patch management programs. July

5 Findings relating to security of the application layer in contrast show an alarming increase. Application layer weaknesses are more prevalent than ever: The only category showing an improvement is web server misconfigurations. All others are up: SQL injection and other SQL weaknesses increased 25%. Cross-site scripting increased by 23%. Input validation issues increased 15%. SSL related issues went up by 7%. Authentication related issues (including username and password enumeration) increased by 9%. Information leakage (in error messages) increased 5%. Whilst overall security of the network layer is being practically addressed, organisations are not paying sufficient attention to the application layer. This is of particular concern as over 90% of all attacks are application layer based with the objective of extracting marketable information from associated backend databases. The percentage breakdown of weaknesses by category has not changed much in the past 5 years. The number of instances has increased across the board. The top areas of focus for companies deploying Internet / Web based applications should be SQL weaknesses (including SQL injection), cross-site scripting (including cross-site forgery) and input validation issues. The ability to subvert authentication mechanisms by forceful browsing directly to pages that should otherwise have only been accessible via a login page should also be investigated. July

6 The percentage breakdown of issues by category in 2004 and 2008 is shown below: The analysis shows that organisations need to apply the same level of due diligence to the application layer as they do at the network and operating system level, moving what s been learnt at the network layer up the stack. The remainder of this paper examines the technologies available to assist companies in achieving the level of protection required. July

7 Penetration Testing Defined The term penetration testing refers to the evaluation of the levels of security associated with a computer network or system by the simulation of an attack. Penetration testing is based around the assumption that by attempting to compromise the security of a system or network, more can be learnt about its susceptibility to attack, and specific weaknesses identified and mitigated against. No Carrier: War dialling The modern digital networked computer was born on university campuses. Early telephone systems made use of analogue switched networks and were regularly audited both externally (from attackers armed with blue boxes and whistles) and internally by dedicated security personnel. The modern network was a product of academia. In those nascent networking days academics were largely unconcerned with security - networks were largely a mechanism to openly and rapidly share information. Universities also formed the backbone of the Internet, and were the original ISPs, as well as being among the first to implement as a communication medium. Early governmental and military networks in contrast were formed of closed systems. Although the concept of penetration testing was first posited by the Rand Corporation (amongst others) and the US Department of Defense as early as the seventies and eighties, it did not become popular until the emergence of war dialling (which was largely a result of the switch from analogue to digital). War dialling was one of the first modern strains of formal penetration testing and was used to identify unprotected and publicly available modems which would allow unauthorised access to networks. War dialling was an accepted mechanism to assess the security posture of networked technologies until the early nineteen nineties and is still widely used - by security professionals and attackers alike - to assess the security of X.25 networks and other resources. The early nineteen nineties saw the emergence of penetration testing as a formal security activity. In 1988 Robert Morris Junior unleashed a self propagating worm, which had the possibly unforeseen consequence of crashing large parts of the emerging Internet. This coupled with seminal research papers including An Evening with Berferd (1991, Bill Cheswick) and Improving the Security of Your Site by Breaking Into It (1993, Dan Farmer & Wietse Venema) raised awareness of the potential activities of external attackers as well as testing methodologies that may be used by organisations looking to emulate them. July

8 A major driving force behind the evolution of penetration testing was not only management - who were growing increasingly concerned with the risks - but also IT security practitioners themselves. Since the early nineteen seventies both the Rand Corporation and the US Department of Defense had conducted research concerned with the security of networked IT environments (hence the publication of the many coloured books). The earliest security assessment / penetration testing applications available to security professionals all had to be independently developed and it was not until 1989 with the emergence of COPS, and later in 1995 with Farmer and Venema s SATAN, that automated scanning using externally developed tools took hold - much to the relief and distress of both testers and administrators alike. Peering over the wall: The Outside / In Approach Early penetration tests involved IT security engineers acquiring or developing basic attack tools, and attempting to exploit the target system or network. Repeatability and reliability were extremely limited due to an absence of methodologies and a reliance on human invention. As both processes and assessment mechanisms (including tools) matured and repeatable testing procedures developed, so an accepted methodology began to emerge. Testing activities associated with this external approach were designed to emulate external attackers who had no previous knowledge about the target network infrastructure. Many of the earliest available penetration testing tools sought to automate common attack activities (such as war dialling or port scans). If an organisation faced the possibility of external attack, it was reasonable to emulate the techniques employed by attackers, and in doing so, secure systems prior to external compromise. The approach was not without its limitations. Firstly, unlike attackers, organisations were limited in the time they could spend testing. Secondly the scope of testing often excluded commonly applied attack vectors (such as social engineering). Reliance on the Outside / In approach to the penetration testing process provides a valuable assessment of externally facing assets. However, the identification of vulnerabilities associated with usually a much higher number of internal assets is not included. Testers typically use a tool set that operates from a position of zero knowledge which offers little insight into the internal assets and networks themselves beyond the gateway. Inevitably vulnerabilities go undiscovered, and remediation advice is slight (e.g. disable service X, introduce a firewall rule to restrict access to Y). Although the superficial recommendations generated by this approach are still of value they do little to improve the overall security of the network and associated applications. July

9 Black box / White box Basic security testing approaches are often referred to as black box or white box assessments. Historically these terms related to software security assessments specifically aimed at the reverse engineering of compiled code bases. However these terms can also be applied to penetration testing of additional resources (networks, systems and applications). A black box test is similar to earlier historical precedents of current external assessments in as much as the tester begins with no knowledge of the target system, or code base, except for the location of the target itself. In a white box test full details about the system and / or code base are provided to the tester - who can then assess target resources from the perspective of a knowledgeable insider - and depending upon scope may even be in a position to draw upon access to internal resources, materials and personnel. The primary argument in favour of the black box test approach is that the tester has to assess the security of a particular target from the same starting point as an external attacker and approaches it from an external perspective. White box testing by comparison allows the tester to quickly begin to assess the security of a resource without first having to enumerate details about its functionality or levels of connectivity. External attackers often spend weeks or months attempting to access a particular target depending on the motivation and reward. Commercial penetration tests are nearly always, because of cost, compressed in time. The white box approach has the advantage that time is not spent enumerating and gathering information about the target. Most of this information particularly if external Internet facing systems are being tested can be obtained relatively easily. All the black box approach does is slow the tester down and reduce the time spent on the more important attack phase of a given test. If internal systems are within scope then a white box approach improves the value of a test to an even greater extent. White box testing can rapidly discover implementations that differ from internal design specifications. The best approach is a combined approach neither in isolation provides the basis for comprehensive risk management. A black box test of external systems followed by a white box approach internally is recommended. During the initial black box test perimeter security can be properly tested including the extent of logging as well as the effectiveness and accuracy of IDSs along with operational security procedures and response. July

10 Regardless of the approach taken a penetration test will only provide a snapshot of security at one point in time. New vulnerabilities are being published continuously - at a rate 139 per week throughout 2007 (Source: CERT/CC). Networks, particularly within the enterprise, are also highly dynamic with hosts, services and users (and their behaviours) changing frequently. Penetration testing can and should be supplemented with additional regular automated vulnerability assessment activities to increase assessment frequency and drive among other things formal patch management programs. Vulnerability Scanning As penetration testing processes evolved and matured there was an increased demand for a lower cost less resource intensive approach, and one focused towards the discovery of security vulnerabilities (without the actual exploitation associated with the later stages inherent within any penetration test). This demand was met with the development of vulnerability scanning applications. Vulnerability scanning tools have a history that dates back to the late eighties with the emergence of COPS (Computer Oracle and Password System) - an application that sought to quickly and easily discover security weaknesses within UNIX based systems. In 1995, the same authors developed SATAN (Security Administrator Tool for Analysing Networks), one of the first publicly available network based vulnerability scanners. As comparatively recently as 1998, the Nessus project was founded to provide an open source and comprehensive vulnerability scanner for a wide array of operating environments, platforms and applications. The process of vulnerability scanning was historically (and still is) to audit a networked environment and detail an inventory of all systems, services and devices discovered. Based upon the results of this initial discovery phase, vulnerability scanners (as the name suggests) then seek to analyse discovered resources for conditions that may be indicative of security vulnerabilities. Vulnerability scanning applications seek to discover resources that may contain exploitable states, but do not exploit any discovered vulnerabilities. Vulnerability scanning has a number of benefits. It can be less invasive than manual testing and depending on system configurations can also prove substantially faster. By its nature scanning is repeatable and both the discovery and vulnerability analysis phases can be automated (computers are designed to make numerous HTTP GET requests rapidly). Vulnerability scanning delivers rapid assessment of networked environments for a range of common security issues and therein lies the limitation. Not all attack results are predictable and many require an attacker or tester to manually July

11 manipulate data. Scanners may be able to rapidly assess an environment for common and predictable vulnerabilities but it is the extraordinary and unexpected that often leads to a successful attack. Furthermore checks in a vulnerability scanner only exist because of published security research. The most sophisticated attackers do not disclose techniques and newly discovered vulnerabilities immediately if at all. In terms of accurately quantifying security risks and providing a measurable degree of security assurance vulnerability scanning must be combined with frequent penetration testing. In isolation it is still valuable in ensuring that systems are protected against known predictable vulnerabilities those that can be exploited with an increasing number of automated readily-downloadable attack tools. Less sophisticated attackers rely on these tools which are now produced or updated within days, rather than weeks or months, of the disclosure of a new vulnerability. Current leading vulnerability assessment solutions include the ability to prioritise weaknesses based on the criticality of the asset (most still treat a vulnerability found on a desktop in customer services as having the same risk as the same vulnerability identified on a critical application or database server). Application Assessment Tools In recent years a new strain of automated testing software has emerged to complement network and host based assessment tools. These tools have been developed to perform automated scans of application environments, most notably Internet or Web based applications. Application scanning activity occurs in two ways. One class of scanning application connects to a pre-defined target application and performs a range of vulnerability tests against each application input field, cookie, session token etc. The second type of testing observes the normal operation and expected inputs and outputs of an Internet based application. Once these operations have been learnt common attack vectors are initiated in an attempt to disrupt normal operations - including SQL injection, cross site scripting, buffer overflows, authentication bypass, session impersonation etc. The second type of test tools rely on a database of known threats and coverage is not currently comprehensive. Even if application fuzzing is employed the assessment tools often only launch a small number of probes and attacks against different data inputs. The tools are also mostly binary in nature at present - a specific string constructed to elicit a particular response either succeeds or fails. Not only is this classification of success somewhat simplistic (e.g. a 500 error may well be recorded by the tool but on investigation may not include any detail useful to an attacker), but often a fail state is anything but. Such tools are known to produce a high number of July

12 false positives and it is therefore essential that the result set is confirmed by manual testing. Like other automated tools they are no match for human ingenuity, inventiveness, curiosity and cunning. Human judgement and interpretation of results by experienced testers is essential in order to thoroughly assess the security of Internet based applications. If an Internet based application fails every single test that is run against it it is a fair assumption that the security of that application is at best weak. However, even if an application passes the levels of audit provided by automated tools the security of the application should not be considered strong without manual testing to confirm or deny the results. Automated application testing tools should be used carefully. Within a Secure Software Development Lifecycle these tools are useful in initial assessments of code prior to release. Input validation issues or forceful browsing weaknesses can be highlighted back to development so that they can be fixed early, saving significant costs, prior to a more detailed code review or manual application penetration test. I Robot: The push for automation The earliest penetration testing processes were largely ad hoc in nature and manually intensive. These early processes have rapidly matured driven by the need to automate penetration testing activities. The demand for automated testing has come from CIOs looking for increased predictability and repeatability in testing practice (and results), as well as the ever present continuous drive to reduce costs. The net result has been a noticeable change in the composition of available testing tools and the range of testing performed against target assets, and also in the report generation process. Automated testing applications deliver some value - but only when used against very standardised network components, operating systems and to some extent commercial off the shelf applications. Even then the product base currently available is not as effective as marketing literature suggests. Automated assessment tools do not generate attack vectors that are sufficiently complex or original to bypass the security of an enterprise, providing a false level of assurance. For example, an automated testing tool may test for standard buffer overflows but fail to extend these tests beyond known parameters and particular environmental factors. The shortcomings of the technology become particularly apparent when using tools to assess the security of software applications. July

13 The one size fits all approach cannot be adequately tuned to assess the idiosyncrasies of custom code. Automated testing tools alone do not yet accurately reveal the true security posture of the organisation being reviewed. Current automated assessment software is valuable in that it can and should be used to cost-effectively increase the frequency of certain testing elements (such as basic network discovery and vulnerability assessment tasks) against homogeneous assets. It should not be seen as a replacement for in-depth manual testing. Using application assessment products to test minor point-releases of Web applications may be appropriate but certainly major releases should be reviewed using an application security specialist. A number of development projects are currently in progress to develop these automated tools further and it is expected that the resulting products based on new technologies - will be of increased value to both organisations and security professionals alike. Security Convergence As security testing tools have evolved so too has their convergence with other IT security technologies. By integrating security assessment applications and processes with technologies such as firewalls, IDSs and Security Information Management (SIM) solutions - real financial and assurance benefits can be potentially realised. Integration with trouble ticketing and help desk systems to drive and measure remediation activity is becoming more widely available from vendors. The results of security testing activities should be used to proactively improve security. As security tests discover new vulnerabilities and attack vectors, the results should be shared rapidly with firewall and IDS teams in order to mitigate the risks in a timely and effective manner. If vulnerability assessment tools detect security weaknesses that are known to exist within the environment but cannot be fixed for a period of time perhaps due to application impact IDS policies should be tuned on-the-fly to prioritise these attacks or to even drop traffic if the level of accuracy of attack detection is very high. The security Utopia of a single unified console and management reporting across whole enterprise estates is still some way off but more open and simplified APIs, standardised reporting and naming, common vulnerability databases and data export formats is bringing the horizon nearer. July

14 Assess, Analyse, Remediate, Repeat In 2001 continuous testing tools and recurring services emerged. Technology realised vastly increased scanning speeds enabling organisations to launch a testing application (or suite of tools) against targets on a regular, or in some cases on a continuous basis, depending on the criticality of the infrastructure. Once an initial baseline has been established changes to the target environment can be rapidly reported. If an organisation can make the investment in dedicated hardware and overcome practical challenges - such as incorporating the approach within strict change control frameworks and accommodate the bandwidth utilisation associated with sometimes highly parallel scanning - significant benefits can be gained in some areas. Given the number of new vulnerabilities reported on a weekly basis frequently recurring scans can close the window of exposure providing there is resource to review the output regularly and to carry out remedial actions. At the very least changes to the infrastructure such as the addition of unauthorised systems can be highlighted and prioritised, or the potential impact of a new widespread worm rapidly assessed. The approach in itself has value but does not dramatically improve security standalone. The tools cannot conduct deep assessments of the security of applications or database environments and therefore fail to provide any tangible levels of assurance of not only one of the major routes in to an organisation, but of the information jewels themselves. Down in the Depths: Beyond the Binary In recent years a trend that has been developing in both legitimate security research and targeted malicious attacks is a concentration on exploits directed at firmware and processors. To accomplish such attacks, a detailed knowledge of processor architectures and protection mechanisms within a microprocessor s RAM are required as well as security hooks, and load drivers that can be potentially circumvented. An examination of specific chip sets for security vulnerabilities has been a natural development from earlier code audit activities. Although code audit services (such as decompilation and exploit analysis) are now common service offerings, the deep security audit and penetration testing of firmware and associated chip sets is not commonly available. Many organisations implicitly trust the internal underlying hardware elements of information assets, with the false assumption that attackers lack either the skill to intrude at this level. As recent legitimate security research has reinforced (with the introduction of rootkit- July

15 like technologies at BIOS level, and exploits occurring with rapidity at firmware level) the challenges facing organisations are little understood. Traditional approaches to penetration testing are not sufficient to either test or exploit vulnerabilities at chip level. A thorough in depth understanding of code level issues, as well as complex hardware interactions, is required. The penetration testing of firmware and chip sets remains very much the preserve of the highly organised (highly funded) criminal seeking to bypass encryption algorithms or chip security models, or the cutting edge (government) security researcher. As the findings of these groups become increasingly available, it is doubtless that general concern across all types of organisations will grow. If these concerns are to be addressed it is essential that advances such as the Trusted Platform Model and other secure boot processes receive support. Additionally the need for manual penetration testing attack methodologies, blended with automated processes, will remain critically important. Designing Security In Companies should look to implement two strategic programs in order to ensure high levels of security assurance are achieved. Firstly, a comprehensive testing program is needed to ensure vulnerability assessments are conducted as frequently as possible, combined with manual indepth penetration testing. Acting on the findings and recommendations from both is paramount if value is to be realised from the investment. The pinnacle of testing currently is the Data Leakage Audit that looks at exactly how trusted users access, process, store and transmit sensitive information. More and more organisations are beginning to consider this form of testing seriously. July

16 Secondly, a comprehensive Secure Software Development Lifecycle should be designed and rolled out both internally and to third party outsourced development partners. A strong Secure SDLC should comprise: an initial detailed threat and risk assessment and architecture design review. regular application reviews throughout development using automated test tools to identify basic coding weaknesses. a formal independent manual code review once development is complete, with issues fully addressed prior to release into production. a final threat and risk review ahead of go live. automated tests of point releases and minor updates. additional code reviews of major releases (issues addressed in one release have a habit of re-appearing in subsequent releases). The Secure SDLC should be underpinned by published Secure Coding Guidelines and on-going training for internal and external development teams. Designing security in to the lifecycle ensures that weaknesses are identified early - at a time when they are significantly cheaper to fix. July

17 Summary Organisations need to move rapidly up the stack to address weaknesses at the application layer with the same level of intensity as network level vulnerabilities have been addressed in recent years. Penetration testing practice needs to evolve further in two almost opposite directions - to provide greater value (through increased automation) to software development teams, and to address emerging threats (such as hardware based vulnerabilities at chip level). Any tools used should be selected based on their ability to identify the business risks associated with the infrastructure being tested, with emphasis placed on tools that can be rapidly configured and extended by the test team to improve the accuracy and completeness of detection of application level weaknesses. The need for manual penetration testing attack methodologies, blended with automated processes, will remain critically important as will the need to conduct both internal and external tests. The strategic use of penetration testing within both a security test program and Secure Software Development Lifecycle should ensure that the upward trend in the number of application weaknesses identified is reversed. Perhaps then the focus can move on to layer 8 and the trusted user. About the Authors Orthus are a leading provider of innovative and independent information security services and solutions. For more information on our security lifecycle services including penetration testing and secure software development lifecycle design - please visit call , or info@orthus.com July