Mini Web Penetration Testing Framework

Intro

This page is dedicated in helping you define a mini web penetration testing framework and provide you with the essential knowledge and essential tools you need to provide an advanced web application penetration testing engagement. I am going to include only the toolkit needed to do what you are supposed to do, no exotic tools, nothing not needed. I am sure you are going to find it very useful and interesting.

Phase 1 : Planning 

First identify the type of the test you are going to perform/deliver, and by saying the type of the test I mean know what you are planning to deliver to the client. Model all your actions and explain them to the costumer. Security Testing is not hacking is a product, that you are trying to sell to your costumers and at the same time help them gain the best out of it. Usually costumers do not know what they want. So what are the types of security testing? The types of testing are 3:
  1. Web Penetration Testing (Includes Proof of Concept,not good for production systems).
  2. Vulnerability Assessment (Does not include Proof of Concept, does cover important issues).
  3. Code audit (It is passive and it has to do with code static analysis and web application development standards). 
The difference between a vulnerability assessment and a web penetration test is that in penetration testing you provide your client with proof of concept, meaning actually penetrating the company web applications and extracting costumers valuable data. While vulnerability assessment is only assessing your costumers security and not actually penetrating the costumers Web application, you make assumptions about how a vulnerability could affect the costumers Web Applications and you help your client make more of  a qualitative technical risk assessment. Why proof of concept is important? Because it helps your client understand the real risks and quantify them. Nowadays modern penetration testing methodologies move towards PoC oriented penetration methods. Security audits is a passive methodology that helps identify risks based probably on some industry standard such as PCI DSS e.t.c, I assume that this is very simple to understand.

Understand exactly what type of test you are planning to do

You should be able to sell your penetration testing services by using specific scoping rules. The penetration test scoping rules should be of two types:
  1. Code review  Penetration Test
  2. Black Box Penetration Test
Code review Penetration Testing is harder to scope but is also more realistic and maybe more expensive, usually clients that do not understand real world risks and do not want that type of test. Black Box Penetration Testing is more easy to scope and usually cheaper.

Further specifying the type of the test you are selling

Specify even more what you are going to web pentest, I will define  the technical types of penetration test that exist:
  1. Client Side Attack Tests (e.g. XSS tests)
  2. Web Application Tests (e.g. SQL injection tests)
  3. Cryptogrphic Alogorithm Test (e.g. testing SSL using sslscan)
  4. Web Application Platform
  5. Web Application Server
  6. All the above
Note: I believe that the following types of tests are self explanatory and need no further explanation.

Hardening your pentest machine
Make sure that your testing equipment is as it is supposed to be. A good penetration testing laptop should be:
  1. Clean of viruses and Trojan horses
  2. Using encrypted hard disk 
  3. Using two factor authentication for login (e.g use fingerprint and password)
  4. Harden 
  5. Run only necessary services (reduce the attack service)
  6. Having tools for encrypted communication (e.g. use PGP)
  7. Having the latest patches.
Note:Between penetration test you should wipe out all information and delete data from previous tests.

Phase 2 : Scoping

When you have planned your web pentest and you have standardized it as a product then you can engage the client and start scoping the project. Now when scoping you have to:
  1. Agree on the type of the test (Vulnerability Assessment or penetration test,Code Review or Black Box)
  2. Agree on the sub category of the test (Web Application or  Web Application Platform)
  3. Agree on the amount of the the man days that are going to be used.
  4. Agree on the team members from your company that are going to participate in the test.
  5. Agree on the team members that are going to participate from the other company
  6. Interview the costumer employees that need to be interviewed to do the scoping
  7. Identify the part of the Web Application to be tested
  8. Identify team leaders from each team
  9. Get contact information from the costumer team leader
  10. Get contact information from the costumer team system administrator
  11. Get contact information from the costumer team network administrator
  12. Get contact information from the costumer team lead developer
  13. Get contact information from the costumer team firewall administrator
  14. Get contact information from the costumer team web application firewall administrator
  15. Agree on start and  end date
  16. Agree on start and end times
  17. Document the agreements and have everyone sign off
None technical information needed before the test

In order to perform a successful web penetration test you have to have the following questions answered:
  1. Has the Web Application been tested before?
  2. What is the exact goal of penetration test?
  3. How valuable is the Web Application to the company?
  4. What is the reason for penetesting it?
  5. Contact details of the web server administrator
  6. Contact details of the web application administrator
  7. Contact details of the firewall administrator (if needed)
  8. Contact details of the web application firewall administrator (if needed)
Technical information needed before the test

The following information is very important to know:
  1. Is the Web Application in production? 
  2. Has the Web Application been tested before?
  3. Does the web application contain credit cards or other sensetive data? If yes what type?
  4. Is the web application going to be tested for DoS attack? If yes have you done a stress test?
  5. Access of two user accounts per type of user (meanning with the same privilages)
Phase 2 : Assessing Stages

Web Application penetration test is not like network penetration tests, it is more complex and at the same time more simple.So these are the stages of pentesting a web application:

1. Map Web Application

1.a Explore all visible content (e.g. all linked content)

By saying all visible content I mean all content that has links inside the targeted website using a web crawler. A web crawler (also known as a web spider, web robot, or—especially in the FOAF community—web scutter) is a program or automated script which browses the World Wide Web in a methodical, automated manner. To do that you have to use the administrator account so as to take all possible information and then repeate the process for each type of user you have access to.

Suggested programs:

a. Burp Spider: Burp Spider enables you to obtain a detailed understanding of how a web application works, avoiding the time-consuming and unreliable task of manually following links, submitting forms and scouring HTML source code.


b. WebScarab Spider:WebScarab is a Web Application Review tool. It sprang from the designs of the people inhabiting the WebAppSec list run from SourceForge, for a powerful, free, open tool for reviewing web applications for security vulnerabilities.


1.b Explore all none visible content

By saying none linked content I mean all all default, dynamic and none linked content. How? Simple using the most privileged account to login and then using a crawler and of course Wikto Back End and other search engines (dirbuster will also do the job). The best way to do it though would be to use burp intruder with a dirbuster and a fuzzdb list combined list.

Suggested programs/methods:

a. Wikto back-end: The Back-End miner section in Wikto is used to find interesting files and
directories on a web server. It is using the default database from Nitko to be updated.

b. About the Wayback Machine:Helps you browse through over 150 billion web pages archived from 1996 to a few months ago. To start surfing the Wayback, type in the web address of a site or page where you would like to start, and press enter. Then select from the archived dates available. The resulting pages point to other archived pages at as close a date as possible. Keyword searching is not currently supported.

c. About fuzzdb: Fuzzdb aggregates known attack patterns, predictable resource names, server response messages, and other resources like web shells into the most comprehensive Open Source database of malicious and malformed input test cases.

About Burp Intruder: Burp Intruder is a tool for automating customized attacks against web applications, to identify and exploit all kinds of security vulnerabilities. Burp Intruder is exceptionally powerful and configurable, and its potential is limited only by your skill and imagination in using it. You can use Intruder to:

b. Google:The keywords filetype, inurl, site, relevant and other keywords can be used to extract cached and none cached information about the targeted website.

2. Identify functionality and technologies used

2.a Identify core functionality:

a. Login/Logout functions.

By saying login/logout functions I mean that you have is to identify how the login/logout mechanism is working. More specificaly I mean looking for:
  1. Allowing password aging
    • As passwords age, the probability that they are compromised grows.
  2. Authentication Bypass via Assumed-Immutable Data
    • Important data that are used for authentication decisions is sent to the client side and subject to user modification
  3. Empty String Password
  4. Failure to drop privileges when reasonable
    • Some legacy systems flat privilage assigment
    • This might introduce privilage escalation attacks or vertical privilage escalation attacks
  5. Hard-Coded Password:
    • Using hardcoded default passwords in configuration files e.g. in Web.config
    • Using hardcoded passwords in cookies will introduce vulnerabilities
  6. Not allowing password aging:
    • Passwords shoud be changed by the user relativly often 
  7. Misused authentication:
    • If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.
  8. Reflection attack in an auth protocol:
    • The primary result of reflection attacks is successful authentication with a target machine - as an impersonated use.
  9. Unsafe Mobile Code:
    • Third party cross domain referenced code should be avoided
    • Third party unchecked code should be reviewed
  10. Using password systems:
    • The failure of a password authentication mechanism will almost always result in attackers being authorized as valid users.
  11. Using referer field for authentication or authorization
    • The  referer fields can:
      • Be spoofed e.g using http header injection
      • Introduce vulneabilities to open redirects
  12. Using single-factor authentication:
    • Single factor authentication is easier to bypass than two factor authentication 
  13. Proper session termination
    • The session expires after a reasonable period of inactivity
    • The session terminates after user login logouts
    • Session termination functionality is implemented only on the server side
c. User registration mechanism.

By saying  password registration mechanism  functions I mean that you have is to identify how the   password registration mechanism is working. More specificaly I mean looking for:
  1. Properly validating user web application form for input data validation
  2. Transfering personal information above secured communication channel
  3. Applying proper access control of registration form (it should not be accessible unless needed)
  4. Password  registration mechanism is should not be used directly by other password management functions
  5. Password  registration mechanism should establish for a certain time frame entity origin authentiation (e.g. avoiding MIM attacks)
  6. Apply proper password complexity
d. Password recovery mechanism. 

By saying  password recovery mechanism  functions I mean that you have is to identify how the password recovery mechanism is working. More specificaly I mean looking for:
  1. Proper old password expiration
  2. Not giving away current username information
  3. Generate random urls when senting password recovery e-mails and expire temporery passwords
  4. Apply proper password complexity
e. Major Web Application functionality.

2.b Identify platforms

By saying identify platforms I mean that you have is to identify how the password recovery mechanism is working. More specificaly I mean looking for:
  1. Software version
  2. Software name
  3. Software programming lamguage
  4. Programming language used
  5. Web Server used
Programs suggested:

HttpPrint: HttPrint is a web server fingerprinting tool. It relies on web server characteristics
to accurately identify web servers, despite the fact that they may have been obfuscated by changing the server banner strings, or by plug-ins such as mod_security or server mask.


Phase 3: Exploitation

Web Application exploitation should take into considiration if it is a production system, the goals of the Web Application penetration test and the amount of time to dedicated to exploit. But first you would have to identify the exposed components of the web application that need to be poked (get PoCed).

1. Define Web Application Attack Surface

Associate core functionality and web application content with known vulnerabilities, e.g. file uploading with path traversal.

2. Test Client Side Functionality

2.a Make sure that no security mechanisms exist in the client side (e.g.the client might be exposed to client side cookie manipulation, client side session management, client side input validation).

2.b Test data transmission (e.g. make sure secure flag and httpOnly flag are enabled).

2.c Verify no critical variables are passed through hidden fields, if any, and make sure the application is not vulnerable to repudiation attacks (e.g. replay old client request to bypass access control mechanisms).

2.d Verify that no comments exits in the content returned back to the client that reveal the internals of the web application (e.g. Javascript and Html comments).

2.e Test thick client components (e.g. decompile Java Applets returned back from the web
application).
Programs suggested:

Firebug: Integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.


Note: This is a small descriptionof the client side testing.

3. Test Authentication Mechanisms

3.a Go through the whole authentication mechanism (e.g. locate login mechanism, password recovery mechanism, registration process etc.)

3.b Test password and username security policies (e.g. validate and try to bypass the default password complexity and then make sure that the each user name is unique and is associated with only one password). It means identifying how the user data are represented in the database.

3.c Test lock out mechanisms (e.g. Does the web application have a lockout mechanism and how effective is?)

3.d Run a brute force attack and a dictionary attack against the web application, then log the errors returned from the web application and make sure there is no information disclosure issue.

3.d Try to perform user enumeration using the responses from the server (e.g. try login using many different valid usernames with invalid password and analyze the error messages).

3.e Test for auto generated credentials predictability (e.g. if usernames and passwords are generated from the web application, generate a large amount for usernames and passwords to see how predictable are).

3.f Test for unsafe credential transmission (e.g. There is no SSL enforcement, secure and httpOnly flags are not set and hidden fields are used to pass user credentials or critical variables). Verify that no user credentials are passed to the cookie (e.g. so as to be used for XSS attacks), the referrer header (e.g. session fixation attacks) when third party links are allowed inside the web application or the url query string (e.g. web server logs and and internet browsers will save user credentials into the history).

4. Test Session Management Mechanism

Understand what a session is composed from(e.g. Variables in hidden fields, cookies, URL identifiers e.t.c). Understand meaning of session and try to reproduce valid sessions using various user credentials. Test session generation and session termination. Test for session fixation (e.g. try to produce valid sessions, try to replay a request using an old session or replay a request using a from the targeted web application a session ( captured before a successful login) trying to retrieve authenticated pages, after the user has logged in. Try to perform CSRF.

Programs suggested:

Stompy: Stompy is a free tool to perform a fairly detailed black-box assessment of WWW session identifier generation algorithms. Session IDs are commonly used to track authenticated users, and as such, whenever they’re predictable or simply vulnerable to brute-force attacks, we do have a problem.


More specifically look for:
  1. Testing for Session Management Schema (OWASP-SM-001)
  2. Testing for Cookies attributes (OWASP-SM-002)
  3. Testing for Session Fixation (OWASP-SM-003)
  4. Testing for Exposed Session Variables (OWASP-SM-004)
5. Account Access Control

Look for broken links after mapping all type user content (e.g. access variables with high user account privileges simply by guessing  URL ID’s). More specifically look for:
  1. Testing for bypassing authorization schema (OWASP-AZ-002)
  2. Testing for Privilege Escalation (OWASP-AZ-003)
  3. Business Logic Testing (OWASP-BL-001)
  4. Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)
6. Test Input Based Vulnerabilities

The input vulnerabilities YOU need to test for are:
  1. Testing for Reflected Cross Site Scripting (OWASP-DV-001)
  2. Testing for Stored Cross Site Scripting (OWASP-DV-002)
  3. Testing for DOM based Cross Site Scripting (OWASP-DV-003)
  4. Testing for Cross Site Flashing (OWASP-DV-004)
  5. Testing for SQL Injection (OWASP-DV-005)
  6. Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)
  7. Testing for path traversal (OWASP-AZ-001)
6.1a Identifying SQL Injection

In order to identify for SQL injections you should use a generic of mini character sequence that applies to all types of data bases a good one is the one that follows:
'

'--


)(




'#




#

';

');

'); --

--

''''' ---



/*something*/

''''''''''''




'"




"'








'
 



Note: Mitigation happens with proper filtering and character escaping.







Bypassing Web Application Filters.








 


6.2 Identifying XSS




 


All echoed web application vulnerables are potential XSS issues, input to test XSS is all Html and Javascript mini character sequence:


 


<







>







<>







><







<--







-->







<!--







--!>







<script>







</script> 







6.2b Filter XSS bypassing 







You bypass filters by encoding and mutating javascripts code. 











6.2a Identifying XXE















You can do that using this set of characters:











'



''



"



""



<



>



]]>



]]>>



<!--/-->



/-->



-->



<!--



<!



<![CDATA[ / ]]>















7. Test for Web Server Vulnerabilities 











Common vulnerability scanners such as Nessus, Rapid 7, metasploit and OpenVas should also be used to identify web application, platform and system vulnerabilities. I always do also a port scanning. Check Http header injection, server banner advertisement, enabled Http methods and supported protocols that run over Http (e.g. WebDev). Also check Web Server default content and configuration.











Nikto: Is an Open Source (GPL)web server scanner which performs comprehensive tests against web servers for multiple items, including over 3500 potentially dangerousfiles/CGIs, versions on over 900 servers, and version specific problems on over 250 servers.




















Phase 4 : Deliverables











We talked about all the different penetration testing phases and got a got grasp about penetrating properly the client infrastructure, now what is left is to do the reporting. The reporting is very important, because it shows all the work you have done and also show that you succeeded to do a proper technical risk analysis. So what does reporting means? 







Report Structure 







The report structure takes into consideration the whole results and makes it understandable from all type of personnel






    

  • Statement of Confidentiality
    • 

      

    • Declares that both parties have signed a confidentiality agreement
      • 

    

  • Executive Summary
    • 

      

    • Introductory document that has a short description of what you did.
      • 

    • Findings and Analysis with no details
      • 

    

  • Action Plan
    • 

      

    • Categorization of the vulnerabilities based on their impact and time to be fixed.
      • 

    

  • Steps to Mitigate or Manage Risk
    • 

      

    • Next step for a retest
      • 

    • Further actions on increasing or reducing the scope
      • 

    

  • Management Overview
    • 

      

    • Goals and Objectives for the pentest
      • 

    • Project Team composition and names
      • 

    • Project Dates
      • 

    

  • Analytical Process
    • 

      

    • Insight on the penetration test process used
      • 

    

  • Costume or public vulnerability categorization (e.g. OWASP) 
    • 

      

    • Generic risk categorization based on type of vulnerability and impact
      • 

    

  • Detailed Findings
    • 

      

    • Short technical description on what was found
      • 

    

  • Overview
    • 

      

    • Short technical explanation of the findings
      • 

    • Statistical analysis of the vulnerabilities based on occurrence
      • 

    • Statistical analysis of the vulnerabilities based on  their impact
      • 

    • Statistical analysis of the vulnerabilities based on their type (optional)
      • 

    • Statistical analysis of the OS's identified (optional)
      • 

    • Statistical analysis of the  services identified (optional)
      • 

    

  • Areas of Analysis Table Ratings
    • 

      

    • Identified sections that were tested form the client infrastructure
      • 

    

  • Key Vulnerabilities Table Ratings
    • 

      

    • Analysis of the vulnerability based on the:
      • 

        

      • Business impact
        • 

      • Remediation Action
        • 

      • Difficulty to exploit 
        • 

      

    

  • Tools Used
    • 

      

    • Detailed list of the tools used
      • 

    

  • Appendices
    • 

      

    • Detailed analysis of the vulnerabilities
      • 

    • Vulnerability Screen shots 
      • 

    




Other documents









You should also keep an inventory excel on how to identified and how you exploited the vulnerability.













Reference:






    

  1. http://owasp.com/index.php/Category:Vulnerability
    2. 


























































        

      









Subscribe to:
Posts (Atom)