White Paper: Practical Aspects Of Web Application Penetration Testing And Vulnerability Analysis

Practical Aspects of Web Application Penetration Testing and Vulnerability Analysis

Title:

Practical Aspects of Web Application Penetration testing and vulnerability analysis

Conference:

Testing BFSI Applications – a STeP-IN Theme Conference, September 19 – 20, 2008 @ The Leela Palace, Bangalore

Authors:

Nilesh Dasharathi (Test Analyst) Sadaf Kazi (Software Development Engineer-Quality Engineer)

Email Address:

[email protected] [email protected]

Address:

Aztecsoft Ltd. Rajiv Gandhi Infotech & Biotech Park, Plot no. 37, Phase 1, MIDC, Hinjewadi, Pune – INDIA 411057

1

www.aztecsoft.com

Page 1 of 17

2 ABSTRACT Introduction: The success of a web application penetration testing project is directly proportional to the quality of its execution cycle.

Executing a penetration testing project is very different from executing a

functional testing project given the fundamentally different goals and challenges of penetration testing and vulnerability analysis. It is therefore surprising that very little published work deals with the unique challenges of the practical aspects of penetration testing projects. Our experience with penetration testing for a number of web applications has helped us abstract out a set of Best Practices for penetration test execution for web applications, which we present.

Audience: This paper is intended for Engineers, Test Leads and Managers who undertake security testing projects.

Benefits: 

This paper throws light on the practical aspects of penetration testing and vulnerability analysis of web applications.



It will help focus efforts on overcoming the key challenges involved in penetration testing and vulnerability analysis of web applications.



Issues and Challenges: Relative indifference towards the importance of Web application penetration testing



Too much focus on tool based security assessment of web applications

www.aztecsoft.com

Page 2 of 17

Contents 1

ABSTRACT................................................................................................. 2

2

INTRODUCTION ............................................................................................

3

PENETRATION TESTING ............................................................................... 7

4

EXECUTION ASPECTS OF “WEB APPLICATION PENETRATION TESTING” ...................................... 8 4.1 4.2 4.3 4.4 4.5 4.5.1 4.6 4.7

4

Understanding the application including its business logic ........................................... 8 Threat Modeling .............................................................................................. 9 Planning attacks for well-known vulnerabilities...................................................... 10 Planning attacks for business logic testing ............................................................ 11 Test environment set up and execution ............................................................... 12 Test data creation: ..................................................................................... 12 Analysis of results .......................................................................................... 13 Suggesting mitigation strategies ........................................................................ 14

5

TOOL BASED PENETRATION TESTING ............................................................... 15

6

CONCLUSION........................................................................................... 16

7

REFERENCES ............................................................................................. 16

8

ACKNOWLEDGEMENT ..................................................................................... 16

9

AUTHOR PROFILE ......................................................................................... 17

www.aztecsoft.com

Page 3 of 17

3 INTRODUCTION Since the advent of the World Wide Web, many routine activities in the banking, finance and insurance sectors have been moved to web based applications. Internet banking, online dealing in stocks and shares, making important purchases and payments online has become a norm nowadays.

The Web touches almost all areas of human life and has become an integral part of it. Businesses have embraced the Web to conduct their core business functions. Web based applications are used for various critical transactions and they handle sensitive data like personal information and financial information. As a result web-based applications face threats like information disclosure and misuse of information. Recent attacks bear a testimony to this reality: 

The Secret Service arrested at least 6 people in an investigation that involved information theft at an Ohio court web site. At least one known identity theft case resulted in a $40,000 loss to the victim. Sensitive information was stolen by manipulating predictable identifier parameters. The stolen information belonged to at least 270 people and included the name, address, age and other information that could be used to obtain credit card numbers and to open bank accounts. Reported: 22 December 2007



Chinese hacker stole user information of 18 MILLION online shoppers at Auction.co.kr A Korean e-commerce site was hacked and a staggering number of record, 18 million, where stolen. The attack can be described as session hijacking. Reported: 12 February 2008



Symantec reported an active exploit of CSRF against residential ADSL routers in Mexico (WHID 2008-05). An e-mail with a malicious IMG tag was sent to victims. By accessing the image in the mail, the user initiated a router command to change the DNS entry of a leading Mexican bank, making any subsequent access by a user to the bank go through the attacker's server. Reported: 28 January 2008

The following industry statistics has been compiled by web application security consortium from data provided by four vendors - Whitehat Security, SPI Dynamics, Positive Technologies and Cenzic) from past web application security engagements using automated scanning technologies. The scans include a combination of raw scan results and results that have been manually validated to remove false positive results.

www.aztecsoft.com

Page 4 of 17

Web Application Security Attack Statistics

Total Sites Tested - 31,373

Threat Classification Brute Force Content Spoofing Cross Site Scripting Directory Indexing HTTP Response Splitting Information Leakage Insufficient Authentication Insufficient Authorization Insufficient Session Expiration OS Commanding Path Traversal Predictable Resource Location SQL Injection SSI Injection XPath Injection

No. of Vulnerabilities 66 663 100,059 292 4,487 20,518 84 23 46 143 426 651 19,607 950 14 148,029

Vulnerability. % 0.04% 0.45% 67.59% 0.20% 3.03% 13.86% 0.06% 0.02% 0.03% 0.10% 0.29% 0.44% 13.25% 0.64% 0.01% 100.00%

No. of Sites 66 218 26,531 168 3,062 4,924 1 4 1 44 374 173 8,277 298 6 44,147

% of Vulnerable. Sites 0.21% 0.69% 84.57% 0.54% 9.76% 15.70% 0.00% 0.01% 0.00% 0.14% 1.19% 0.55% 26.38% 0.95% 0.02%

Web application security is a subject of growing importance as the BFSI sector conducts their core business transactions using Web-enabled applications. Besides educating developers about best practices to avoid security holes, a variety of activities such as auditing, vulnerability assessment, penetration testing are undertaken by IT organizations to ensure their web-based assets are secure. Security testing can be clearly divided into two areas: Penetration Testing and Vulnerability analysis.

Penetration testing attempts to exploit any one of the vulnerabilities to gain unauthorized access. It is a Quality Control activity with a focus on threat modeling, planning and executing various attacks on the application under test and suggesting mitigation strategies. It is important to note that penetration testing does not provide a complete inventory of exposures, but it does identify those exposures exploited to gain access.

It is a method of evaluating the security of a computer system or network by simulating an attack by a malicious hacker. The process involves an active analysis of the system for any weaknesses, technical flaws or vulnerabilities. This analysis is carried out from the perspective of a potential attacker, and

www.aztecsoft.com

Page 5 of 17

can involve active exploitation of security vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution. There are two types of “penetration testing” services: Network Penetration Testing involves attempting to break into a system’s network or servers. Network penetration tests involve use of tools, a (usually somewhat proprietary) grab-bag of tricks and exploits, network scanning, social engineering, port scanning etc. Application Penetration Testing This does not generally involve servers or the network. Instead, the application penetration test team is given a piece of software to look at. The focus of Application Penetration Testing is to find out vulnerabilities in the application (J2EE, ASP.NET, PHP etc.) using automated tools along with manual analysis.

In Web application Penetration Testing, the team is usually given a set of accounts with varying levels of privilege on the application, and is tasked with finding OWASP-type vulnerabilities in the application

Vulnerability analysis is a process that defines, identifies, and classifies the security holes (vulnerabilities) in a computer, network, or communications infrastructure. In addition, vulnerability analysis can forecast the effectiveness of proposed countermeasures and evaluate their actual effectiveness after they are put into use. Considering the importance of Web application Penetration Testing in today’s world, we will discuss the nitty-gritty’s of Web application Penetration Testing, in detail.

www.aztecsoft.com

Page 6 of 17

4 PENETRATION TESTING Penetration testing is a specialized area of testing which requires detailed understanding of the product, its architecture, and the underlying technology/platform for it to be effective. It is a test to determine if an outside party can penetrate existing organizational defenses both from a technological and social perspective. Penetration testing simulates the actual hacker behavior to the extent possible. It demonstrates the practical risk associated with an identified vulnerability by exploiting the latter to gain entry.

Web application penetration testing refers to a set of services used to detect various security issues with web applications. Enterprises across the world are performing their business on the web, yet only a meager percentage of websites are regularly and professionally tested for vulnerabilities. This increases the chances of website attacks and eventually leads to compromise of applications. Web Application Penetration Testing services help identify: 

Vulnerabilities and risks in web applications



Known and unknown vulnerabilities to combat against the threat until your security vendor provide the appropriate solution.



Technical vulnerabilities: URL manipulation, SQL injection, cross site scripting, back-end authentication, password in memory, session hijacking, buffer overflow, web server configuration, credential management etc,



Business Risks: Day-to-Day threat analysis, unauthorized logins, Personal information modification, pricelist modification, unauthorized funds transfer, breach of customer trust etc.

www.aztecsoft.com

Page 7 of 17

5 EXECUTION ASPECTS OF “WEB APPLICATION PENETRATION TESTING” Carrying out a complete Web application penetration test is a comprehensive process and can be quite complex. Hence it is good to have a methodical approach, which ensures thorough testing of the web application. The execution phase of web application penetration testing consists of: - Understanding the application architecture and its business logic - Threat Modeling - Test data creation - Planning and executing attacks using automated tools / business logic testing - Analysis of results generated by automated tools - Suggesting mitigation strategies for exploited vulnerabilities

5.1 Understanding the application including its business logic Understanding the application architecture and its business logic is the first and critical step in the security testing life cycle of web applications. It is a common myth that all security flaws can be detected by merely running automated tools. Understanding of architecture, application functionality, interaction among various components of the application, data handled by the application, data flow, and the underlying technology is gained by browsing the application and thorough discussions with the system architects / developers of the application. Once a sufficient amount of understanding is developed, business critical assets and critical scenarios are identified. The assets and scenarios thus identified provide input during the threat modeling exercise. Automated tools attempt to discover the structure of the application in one of the following two ways: In Spidering mode the tool is given an initial starting URL of the application to be tested along with some information necessary to traverse through the application (e.g. credentials required for accessing the application). The second way is Manual recording mode where the security engineer browses through the application just as a typical user of the application would in the course of his normal interaction with the application. While this is going on, the tool captures and records information about pages visited as well as the data submitted.

Automated tools cannot understand how data flows in the application, nor can they identify critical data in the application. Automated tools treat all portions of the application the same way because of

www.aztecsoft.com

Page 8 of 17

this limitation. As a result, these tools cannot differentiate between critical and non-critical assets of the business application during the simulation of attacks.

In order to overcome the deficiencies of these automated tools, human intervention and intelligent analysis is required. So as to achieve this, assessing the security preparedness of the application is essential.

Hence, carrying out a security audit becomes important.

Auditing an application for

security involves interacting with the application designers and developers so as to discover the security mechanisms implemented within the application.

For Example, the response of the developers to an auditing question “Does any part of the application use dynamic SQL? If yes, how do you prevent SQL injection?” will determine whether SQL Injection is possible.

The Analysis phase consists of analyzing the business scenarios and data, and thereby figuring out the critical scenarios. This analysis is helpful in determining the application portions to be tested and vulnerabilities to be exploited. It also helps de-prioritize the testing of non-critical portions of the application.

For example: In an e-commerce application, critical business scenarios would be the login scenario, purchase scenario etc.

5.2 Threat Modeling Threat modeling is an engineering technique often used to identify threats and vulnerabilities, and rate them in the context of application scenarios. Threat Modeling helps in understanding the application better. Identification and rating of threats based on a solid understanding of the architecture and implementation of the application helps addressing threats with appropriate countermeasures in a logical order. One can begin with threats that present the greatest risk.

Threat modeling consists of three high-level steps: understanding the attacker’s view, characterizing the security of the system, and determining threats.

During the threat modeling exercise the

application is decomposed, interaction among various components is identified, and threats for various components of the application are identified.

There are many tools available for threat modeling, but they essentially help only with managing the process of threat modeling. They cannot identify threats for a given application on their own. The

www.aztecsoft.com

Page 9 of 17

Security Engineer needs to key in the threats into these tools. These tools are essentially helpful in storing the information about threats in a structured fashion. There are models like STRIDE and DREAD to categorize and rate the identified threats. These models are platform-and technology-neutral and can be used for threat modeling of most genres of applications. In this step a privilege matrix can be created which indicates which functions can be performed by which user and the access rights of each user. This would essentially help the security tester to come up with a list of threats (the functionality that a user does not have access to). The following table is an example of a privilege matrix, which can be created for an application:

Function Function 1 Function 2 Function 3 Function 4 Function 5 Function 6 NO YES

Normal user

Administrator

Super User

NO NO NO NO NO NO

YES YES NO NO YES YES

YES YES NO NO YES YES

Page not available or cannot be viewed Page available or can be viewed

For example: According to the above table, a normal user does not have access to the Function 4 whereas a Super User has access to it. Hence a potential threat would be that a normal user can access Function 4.

The Analysis phase consists of analyzing the identified threats and categorization and rating of the threats in the context of the application using models like STRIDE & DREAD. For example: In an e-commerce application, purchasing an item at 0 price or changing the price of an item to 0 can be potential threats.

5.3 Planning attacks for well-known vulnerabilities Though web application security is a recent concern, web applications have a number of well-known vulnerabilities like XSS, insecure session management. There are projects like Open Web Application Security Project (OWASP), which publish newer vulnerabilities for web applications every year.

Careful planning is required to define attacks to be used to exploit these well-known vulnerabilities. System architects and developers try to implement various mitigation strategies to prevent attackers

www.aztecsoft.com

Page 10 of 17

from exploiting these well-known vulnerabilities. Hence more creativity is required while planning the attacks. The threat model created during the earlier phase of the security-testing life cycle plays an important role in planning these attacks.

There are many open source and commercial tools available that can exploit these well-known vulnerabilities. It is imperative to define boundaries for usage of automated tools for attack simulation and manual attacks during the planning phase.

During the attack simulation the automated tool modifies the originally recorded requests and resubmits them using test data from its ‘dirty-tricks repertoire’ i.e. the injections database. Automated tools do these simulation attacks blindly without identifying the vulnerable fields or without understanding the underlying business logic. These attacks need to be supported by activities like threat modeling and test data creation to make them more effective.

For example, a securely designed application may respond to a simulated injection attack from a tool with a session logout. Since the tool has no way of detecting that it has been logged out, it continues to carry out its injections, unaware that the application is refusing to respond to these requests as these requests are from an expired session. As a result, the application is never really subjected to the number of attacks that the tool claims to have executed.

Another example where these tools prove to be inadequate and the human touch is required is the detection of the stored XSS vulnerability, which requires some understanding of how data flows through the application.

5.4 Planning attacks for business logic testing Testing business logic is often an ignored area during security testing of applications. Most of the security testing efforts are concentrated on testing the well-known vulnerabilities. There are various mechanisms and open source / commercial tools to test well-known vulnerabilities. But hardly any efforts have been put into developing similar mechanisms and tools for business logic testing.

The example below will explain the criticality of business logic testing during security testing efforts:

In an e-commerce application purchasing an item at 0 price or changing price of an item to 0 are potential threats. In a Leave Management application, being able to approve one’s own leaves, or

www.aztecsoft.com

Page 11 of 17

changing the leave balance are potential threats. Testing for such business scenarios using various techniques like escalation of privileges, session hijacking during the security testing efforts is essential.

The Analysis phase consists of understanding the business logic, how components interact with each other and the critical data which the application is handling. This information is utilized while planning the attacks. This improves the chances of exploiting critical vulnerabilities related to the business logic of the application.

5.5 Test environment set up and execution Test environment set-up often includes deploying the application and provisioning the application for testing. The test environment should be a replica of the production environment, not necessarily from hardware perspective but from application deployment and configuration perspective. The web servers, applications servers and database servers should be configured similar to the production environment.

Application provisioning is normally done using database scripts. There are standard checklists available for configuring the servers for security which can be tweaked to suit application specific requirements. Proper configuration of servers and application helps in reducing the chances of reporting of false positives by the automated tools.

5.5.1 Test data creation: Test data is a set of input values that are used during the execution of a test. Test data is also the expected results referenced for comparative purposes. Test data creation requires good understanding of the application functionality, various data elements involved in various transactions in the application.

There are two types of test data that need to be created: reference data and test data. Reference data is the seed data which is required to be populated in the application even before users start using the system. It is also called as application provisioning. Application provisioning is usually done through database scripts as it mainly involves populating the database with the required data. For example, in an e-commerce application, data related to the product, e.g. its pricing is reference data. Test data consists of input values required during the simulation of transactions of the application. For example, creating different users having different user roles (privileges) as defined in the privilege matrix above

www.aztecsoft.com

Page 12 of 17

Test data creation for security testing requires not just the understanding of the application architecture but also an understanding of the implementation of the application and how data is handled in the application.

There have been many attempts to automate the test data creation activity but they are not always successful. The reason being the context based nature of the activity. The test data needs to be generated for a specific program which needs understanding of the data structure at the back end. Of course, even though the automated techniques have this limitation, they are very helpful for creating standard data like user data (name, address, phone #) etc.

Automated penetration testing tools use a standard set of test data i.e. the injections database to execute attacks. This approach increases the chances of either declaring application as safe and not vulnerable or reporting false positives.

The Analysis phase consists of creating the test data required during the testing based on factors like understanding of the application functionality, the underlying technology, analysis of code implementation, and a threat model created for the application.

For Example: Analysis needs to be done on how SQLs are formed and how SQLs are used in the application before executing SQL injection attack. The SQLs to be used during the attack are created based on this analysis.

After the test environment is set up, the actual execution of tests / attacks is initiated. As decided during the planning phase, a mix of automated attacks and manual attacks is used to exploit identified vulnerabilities.

5.6 Analysis of results During attack simulation the automated tool modifies the originally recorded requests and resubmits them using test data from its ‘dirty-tricks repertoire’ i.e. the injections database.

This activity

generates a huge amount of result data. Careless planning of these attacks can result in reporting substantial amount of false positives. Careful analysis of the result data is essential to ensure that the results reported by these automated tools are correct and there are no false positives.

www.aztecsoft.com

Page 13 of 17

For example, false positives are often observed incase of SQL injection vulnerability. Typically, automated tools have a database of SQL constructs which they simply insert in every application request and the response is analyzed. These tools report the SQL injection vulnerability as being exploited incase there is no application error, unexpected input error etc.

This is an example of a false positive as we cannot solely rely on the vulnerabilities reported by tools. A sanity check and further analysis might indicate that the injection was not successful in the real sense i.e. no sensitive data was retrieved or deleted from database etc.

Another reason why analysis of results is important is the multiple occurrences of the same vulnerability. As discussed earlier, the automated tools simulate attacks blindly and they are not smart enough to analyze the results in real time. As a result these tools end up trying the same attack at all possible locations and report the findings. It is very important to analyze how many threats are actually exploited.

For example, while simulating XSS attack, these automated tools will try to inject scripts in all the fields. These tools will continue doing these injections even if they find that the application is vulnerable to XSS.

Penetration testing involves exploiting security threats using both a manual and an automated approach. This uncovers various threats that can be exploited to harm the users and the application. The analysis phase now involves figuring out the actual loopholes which cause the threats. This would help to identify the vulnerabilities and the impact of those vulnerabilities on the entire application.

For Example, If we are able to gain administrator account access by manipulating some parameters, then we have exploited a threat in which a normal user can perform the functions of the administrator. Now the analyst knows that the underlying vulnerability is Insecure Id’s and it’s his job to find out the impact of this vulnerability on the entire application.

This also helps in suggesting the appropriate

mitigation strategies.

5.7 Suggesting mitigation strategies Assessing web applications for security is not enough. Carrying out security testing and exploiting vulnerabilities is just half of the work; suggesting mitigation strategies for exploited vulnerabilities is also critical. Mitigation strategies help in preventing attackers from attacking the web application.

www.aztecsoft.com

Page 14 of 17

Some of the automated tools suggest mitigation strategies. These tools have repositories of mitigation strategies for common vulnerabilities just like they have a repository of injections for attacks. Based on the attacks exploited these tools pick up a mitigation strategy associated with it and include it in the final report. The problem with these mitigation strategies is that these mitigation strategies are vanilla and popular and attackers often know how to bypass those mitigation strategies.

The Analysis phase consists of suggesting mitigation strategies which are application specific on the basis of deep understanding of the application, underlying technology etc. This includes suggesting defense in depth kind of strategies i.e. strategies at different layers in the application which makes the software more secure. Hence, the mitigation strategies are not limited to the application but they also cover other components like web servers, application servers, database servers and so on.

6 TOOL BASED PENETRATION TESTING Security testing of web applications is fundamentally harder than testing for functional correctness. Tools are still evolving since web application security testing is of recent origin. The commonly held perception that penetration testing can be fully automated using one of these tools is incorrect.

Automated tools like Appscan and WebInspect scan the web application by crawling all user-visible pages and sending attack vectors for well-known vulnerabilities such as, cross-site scripting and SQL injection. Such penetration tests do not enumerate all possible vulnerabilities present in the application, for reasons discussed above, but are meant to gain unauthorized access. Vulnerability assessment, on the other hand, is performed by Test Analysts with the help of such scanning tools, and is expected to locate as many potential problems as possible.

With the web platform adding newer technologies all the time, like RIA (Web 2.0 rich Internet applications), the automated tools end up playing a catch-up game while a Test Analyst is able to plug such gaping holes in the tool-based approach. For Ajax in fact, very few of the present-day tools are able to catch even all of the standard vulnerabilities.

Highly integrated applications are also difficult to scan using automated scanners. For example, webmail has always been tricky for the tools. The scanner in some cases has to learn how to send mail to itself and then analyze them, and in some cases it has to realize that the XSS filtering system can be used against itself.

www.aztecsoft.com

Page 15 of 17

7 CONCLUSION This paper demonstrates how the execution aspect of Web application Penetration testing can be carried out in a well defined, organized and comprehensive manner. The aspects of web application penetration testing defined above helps in thorough testing of the web application and also make the life of the tester easy. By leveraging the ideas presented here, organizations can more effectively manage the results and expectations of their investments in security testing and significantly protect against attacks.

8 REFERENCES 

http://en.wikipedia.org/wiki/Penetration_test



http://www.webappsec.org/projects/whid/byid_id_2008-10.shtml



http://www.webappsec.org/projects/whid/byclass_class_outcome_value_monetary_loss.shtml



Drive-by Pharming in the Wild Blog Entry, Symantec, 22 January 2008



Hacker uses Social Security numbers from Ohio court site News Story, Ohio.com/AP, 22 December 2007



http://www.darknet.org.uk/2006/04/penetration-testing-vs-vulnerability-assessment



http://www.matasano.com/log/714/on-the-different-types-of-penetration-tests



http://en.wikipedia.org/wiki/Penetration_test



http://www.webappsec.org/projects/statistics

9 ACKNOWLEDGEMENT We would like to extend our gratitude to Nikhil Chinchwade and Amit Jadhav from our team for their invaluable support and effective feedback.

www.aztecsoft.com

Page 16 of 17

10 AUTHOR PROFILE Sadaf Kazi is presently working with Aztecsoft iTest as a Security Testing Engineer. She is responsible for R&D and Training, in the area of Web Application Security Testing. She has Bachelor’s degree in Information Technology from Pune University, India.

Nilesh Dasharathi is presently working as a Test Analyst at Aztecsoft iTest. In this role, he is responsible for R&D, Training, sales support and delivery in the area of Web Application Security Testing. Prior to joining iTest Practice group he worked in the area of Quality Assurance, Information Security, and Manual Testing in Aztecsoft. He has Master’s degree in Computer Management from Pune University, India and a Bachelor’s degree in Commerce. He is a Certified Information Systems Auditor (CISA). He has 5.5 years of experience in the software industry.

www.aztecsoft.com

Page 17 of 17