Tuesday, October 25, 2011

Why penetration testing information should be destroyed?

Penetration testing is a sensitive testing mechanism against organizational assets. Penetration testing focuses on the current infrastructure of an organization network and its weaknesses. This test is able of identified most sensitive information security weaknesses of organizations’ network infrastructure. This sensitive information is very critical to organizations and protecting this from unwanted hands is utmost priority. When a penetration testing assignment is underway, it is important to reveal most of the business critical operations, information, critical assets, resource persons, etc to penetration testing team. On the other hand, during their penetration testing process, penetration-testing team can learn many hidden vulnerabilities, security weaknesses, and business process weaknesses and many more. These hidden weaknesses can create catastrophe event to organization without any notification, if goes to intruders or malicious users hands. Although the criticality of this information is very high, organization cannot do penetration testing with their internal teams. This is due to lack of experience, exposure, qualifications, equipments, knowledge of internal teams or lack of personal resource availability within the organization. Hence, organizations have to go for external resources by taking a slight risk. However, many of these risks can be covered via appropriate legal bindings, and selecting reputed, qualified, and professional team of penetration testers. Organizations must draft appropriate legal terms and bindings and get third parties abide by them to protect the organization that they may face in case of breach of confidentiality. In the normal practice and depending on the sensitivity of the information client organizations and third party penetration testing team can agree to destroy the information gathered during the penetration testing process. Furthermore, it should be noted, that client organization must specifically mention the information that they wanted the service provider (penetration testing team) to destroy and the period of time that the penetration testing team can retain confidential data before destroying. On the other hand, it should be clearly define the process to destroy, and confirmation of destroy, etc.

In case, if the external penetration testing team does not destroy the information, it is an unprofessional behavior of that origination or the team, and they might face legal charges or imprisonment depending on the case. Penetration testing team can be victims of, negligence of duties, breach of confidence, reputational damages, and legal actions. Since, the criticality of the information it is advised to destroy the collected information. For instance, if an attacker infiltrate penetration testing team member’s laptop where critical data is stored, attacker can extract very valuable first hand information from without much difficulty. This information can be used against the client organization to blackmail, threaten, attack, steal more information, and selling extracted information to third parties (hackers, competitors), etc.

It is imperative to select very reputed and professional team of penetration testers for your penetration testing projects. Below given are few ways to gauge the penetration testing vendor.

· Check whether the penetration testing is their core competencies. Some organizations provide this as a value added service and not master in the area.

· Check for the real world implementation and experience, rather than paper qualifications of testing team

· Evaluate vendors trustworthiness and competence

· Consider the cost versus frequency of penetration testing needed to conduct

· Find real penetration tester who are expert in the field and have practical experience in real environment, this is difficult to find but it will be worth the test

· Ask for references from vendor and verify their status

· Perform a thorough background check to identify the real nature of the vendor

Session fixation

Web applications use a mechanism called session management to maintain user’s web experience more smooth and easy. Web servers’ use unique identifier called Session ID to identify users separately. Each user is been granted with a unique session ID upon request to open a connection with a web service. Commonly session IDs are maintain by use of session IDs in a URL, session IDs in a hidden form field or store in cookies. These IDs are given a time to expire in some cases. Many of the cookies are not only identifiers but also act as an authenticator. This enable the interest to attackers, if they can grab the cookies and establish the session, they can take act as a legitimate user. This helps them to carry out unauthorized activities. This method is called session hijacking, where attacker takeover some legal users session and act as a legitimate user. Hence, it is necessary to provide web session security. Web session security is trying to prevent mainly three types of web attacks; those are interception, prediction and brute forcing. Session fixation attack is a three-step process

1. Session setup - The attacker sets up a "trap-session" for the target web site to extract the session's ID or select an arbitrary session ID for the attack. In some cases, the established trap session value must be maintained (kept alive) with repeated web site contact.

2. Session fixation - The attacker introduces the trap session value into the user's browser and fixes the user's session ID.

3. Session entrance - The attacker waits until the user logs into the target web site to fix the session ID value and take over the session by the attacker.

Below listed few ways in which the session fixation can be mitigated.

1. User built in session frameworks - most of the application framework comes in a session management scheme. These generate session IDs and manage them pretty well. These mechanisms are well tested by security professionals and fixed most of the vulnerabilities. Hence, these are much better than the homegrown session managements, due to above reasons.

2. Store session data on severs - any program language provide a way to store session data in objects. These session objects can be stored in servers to prevent attacks.

3. Be aware of the data in the session objects. - Programmers need to be aware of where and what data they store in session objects. These can be DBs, file systems, or RAM. There can be many standards violation (for instance, PCI-DSS, ISO 27001). You can consider encrypting data that is being stored in session objects.

4. Short session timeout sessions - session timeout interval is generally configured in servers. If the time that the session be active without activities can be reduce, where it can reduce the time that left for attackers to steal, copy, of hijack the session IDs.

5. User session ID with enough entropy and length - most built-in session ID frameworks use random session IDs that are difficult to predict due to the long length.

6. Invalidate session on the server - although users and applications clear cookies at their log out from sites, it does not necessarily kill the session on the server. Malicious attackers use session ID replay to gain access to that particular session. This can be avoided with implementation of Session.Abandon() (ASP,.Net), or session.invalidate (J2EE), which kill sessions on the server when users log out.

7. Regenerate session when privileges changes - when the privileges of user changes, sessions should be change. For instance, when a user log in his privileges changes and when users changes from http to https and vice versa.

8. Set flags on cookies such as secure and HTTPOnly - when the secure flag is set cookies will only sent via SSL/TLS (HTTPS connections). When HTTPOnly flag is set, it prevent client side scripting which access cookies and its values. This helps prevent cross-site scripting and stealing session token stored in cookies. Path and domain attribute also can set appropriately.

9. Never to reuse session IDs - session IDs should not be used as cryptographic keys or create unique file names with it. These are only random identifiers assigned by application servers only for a particular session.

Usage of valid SSL certificates - certificated used by application should be valid SSL/TLS certificates. When users are being get used to accept invalid certification, they do not know which is secure and which is not. Attackers can send malicious certificates, which can use this vulnerability. This can raise MITM attacks as well, thus accept only SSL/TLS certificates.

Different password cracking techniques

Password cracking technique

Description

Social engineering attack

(guessing and shoulder surfing)

This is a technique used to manipulate human into perform an action or divulge some confidential information without using any technical actions to breaking to systems. This technique can be utilized to attack systems without any technically sophisticated attacks. Two most interesting techniques are, shoulder surfing and guessing. For instance, you can pretend as a technical staff from the ISP and enter a office premises to meet the network administrator, and ask him to login to systems and see whether everything works perfectly. When network administrator types his password attacker can silently observe his password by standing behind the administrator and looking over his shoulder. Next option is to guess the password by profiling the organization and the user. Most users use a password relevant to them. Hence, if you know the person very well , chances are high to guess what he will use as a password.

Dictionary Attack

This is a subset of brute forcing attacks. Dictionary attacks try to use combination of words instead of all possible password combination of digits. Dictionary attacks use common usernames and passwords to crack passwords. This technique use dictionary words to guess passwords.

Brute Force Attacks

This method tries all possible combination of letters, numbers and characters until they find the correct combination. Comparatively this process takes long time depending on the length of the password, complexity, and the computer speed.

Hybrid Attack

This method of password cracking tries to add numbers or symbols to previous found passwords. Some cases users’ simply add new numbers or words to the end of old password and these passwords can be cracked easily.

Monday, October 10, 2011

Web Application Penetration Testing

Nowadays everything we see and find is computerized and interconnected, and it is hard to find anything that is not computerized or cannot be computerized. Due this factor, many businesses have improved their efficiency, productivity, save lot of energy (human and machinery), introduce more innovative products and services as well as made services available at fingertips of customers. For instance, web enabled service of banks like internet banking, which enabled customers to stay at home and make all the transactions such as paying utility bills, making other financial transactions, transferring money, checking accounts details etc with comfort and ease. This became possible due to secure web applications used by banks. However, not to forget everything comes with a risk and side effects. In Web applications that we use can have numerous unidentified and hidden vulnerabilities, security loopholes, improper codes, errors and inconsistencies. These could open up disasters to organizations and users if not identified before hand and managed effectively. Hence, organizations need to test these web applications with proven web application testing methodology to correct these vulnerabilities. There are many methodologies existing and organizations can use what is most suitable for the web applications that they require to test. This article will illustrate how to perform web application penetration testing effectively with proven methodology.

Penetration testing is a process of proactive and authorized evaluation of organizational information for security weaknesses. During the process, it analyzes for design weaknesses, technical flaws and vulnerabilities. At the end of the security measures evaluation process, it delivers comprehensive report to executives, management and technical expert’s review. Penetration testing could satisfy the goals of organizations such as test and validate the efficiency of implemented security protections and controls, to enable internal and external vulnerability perspective to organizations, and provide productive information for auditing teams for regulatory compliances, etc.

Web Application penetration test is a part of penetration testing, which only focuses on penetrating web applications and identifying vulnerabilities and weaknesses. Thereafter, reporting that to management and technical experts via reports. This includes the assessment of the web applications and the impact to the organization and often with a proposal for risk mitigation or technical solution.

As of any software and product, Web Applications also need security test to verify that it can handle what they are promising. Web applications have taken serious measures in implementing security within the web applications. On the other hand, it provides required level of security and not susceptible to any identified security vulnerabilities, weaknesses or improper input, modifications, etc. For instance, consider an internet-banking site. It stores personal sensitive information of users such as sensitive financial information and transaction details. If an attacker is able to access this information due to vulnerability in the web application; attacker can perform any transaction, modification, or insert hidden code, etc to the web applications. Hence, could harvest all the customer information and financial details as well as manipulate any information. This would be devastating news for the banking institute as well as their customers. Hence, it is critical to validate the security posture of web applications with web application penetration testing ,to be sure the level of security of the organization.

Since, there are many vulnerabilities in web applications, web applications penetration testers and developers need to concentrate on these items during their testing and application development. It is much better if application developers are well aware and educated to develop secure web applications rather than fixing vulnerabilities later when implemented. Below given list include few of the common web application vulnerabilities.

· Cross-Site Scripting (XSS)

· Cross-Site Request Forgery (CSRF)

· OSAP injection

· SMTP command injection

· Blind SQL/XPath injection

· Code executioin

· CRLF injection / HTTP response splitting

· SQL injection

· Cookie manipulation

· Script source code disclosure

Web Application penetration testing is a complex task and requires very well organized steps to identify and evaluate security measures. Methodology allows this complex process to streamline and have a standardized way to perform each task. OWASP (Open Web Application Security Project) Testing Guide is a proven and recognized Web Application penetration methodology, as well as OSSTMM (Open Source Security Testing Methodology Manual).Below illustrates how to perform Web Application penetration testing and its steps. This is a lengthy process however; it is noted here with brief description.

i. Fingerprint web application environment - this is the basic step to start with, you need to identify web application environment such as used scripting language, web server software, version, operating system, etc.

ii. Investigate the output form HEAD and OPTION HTTP request - these two options usually contain with web server software version, scripting environment and operating system in use.

iii. Investigate format and wording of 404 and other errors - some application environment such as ColdFusion maintain custom error pages that consist of software versions of the scripting language in use.

iv. Test for recognized file types, extensions and directories - different web servers respond differently for unknown extensions than known. Request will monitor for any unusual output or error codes.

v. Examine the source of available pages - immediately accessible pages of front end application’s source code will give very useful details

vi. Manipulate inputs to elicit scripting errors

vii. Test the inner working of web application - scripting languages like Javascript and client-side code can provide information of inner working of web applications

viii. Test database connectivity - access rights should be limited to minimum rights required and limited to required time duration.

ix. Test application code - check for misuse of super user accounts, login ID and passwords, exception /error handling and backdoors left by developers.

x. Test GET and POST in web application - check how these GET and POST are used in web applications.

xi. Test for parameter tampering attacks on the website - try to manipulate URL strings to retrieve sensitive information.

xii. Test URL manipulation - modify URL to see whether you can access unauthorized areas.

xiii. Test Cross-Site Scripting - use tools like, Paros proxy, Fiddler, and Burp proxy to test for these vulnerabilities.

xiv. Test for hidden fields - inspect source code to see if there is any hidden information stored. Try to modify source code and save, then execute and see whether the changes are accepted.

xv. Test for cookies attacks - stealing user cookies will enable attackers to access an account without any authentication.

xvi. Test for buffer overflows - send large amount of data to the buffer, where the buffer will crash and will result in unexpected behavior.

xvii. Test for bad data - enter data in to application by entering between will store in the database, later will result in inaccurate reports.

xviii. Test for client-side scripting - capture a URL after valid login and enter that URL in to a new browser. Check whether you can login without authentication.

xix. Test for known vulnerabilities - use Bugtraq to monitor these vulnerabilities

xx. Test for race condition - application use multiple threads to achieve simultaneous processing, check for this condition.

xxi. Test user protection via browser settings - browser settings provide protection from harmful contents, check whether this is supported.

xxii. Test for command execution vulnerabilities - web applications not properly sanitize the user input data before using it within the application. Application could execute the operating system commands using this.

xxiii. Check for SQL injection attacks - when directly input SQL statements by user are not properly sanitized attacker can steal data from your database, modify and delete.

xxiv. Check for Blind SQL injection attacks - this is identical to SQL injection except it gets a generic page specified by the developer.

xxv. Test for session fixation attacks - this is where attacker tries to use previously used session ID to log again.

xxvi. Check for session hijacking attacks - attacker tries to locate active session and track it, disconnect the host and hijack the session and resume the session after hijacking and use to his will.

xxvii. Check for XPath injection attacks - technique use to exploit website that construct XPath queries from the user supplied input.

xxviii. Test for server side include injection attacks - this exploit web application’s failure to sanitize user supplied data before they are inserted to server side interpreted HTML file

xxix. Check for logic flaws - this is a failure of performing conditional branching or apply security in web applications.

xxx. Check for binary attacks - static buffers may be vulnerable to binary attacks such as format string bugs and butter overflows.

xxxi. Check for XML structural - try to overload the XML parser by sending large amount or malformed XML messages to server.

xxxii. Test for XML content level - use Webscarab tool to test Web Service Definition Language, modify parameter’s data based on WSDL’s definition and check whether you can use web services with escalated privileges.

xxxiii. Test for WS HTTP GET parameter/RESET attacks - check for maximum and minimum length, validate payload, validate the parameter’s names and existence

xxxiv. Test for suspicious SOAP attachments - search wed service definition language that accepts attachments.

xxxv. Test for WS replay - user tools such as WebScarab to capture HTTP traffic and try to perform replay attack.

Every vulnerability found during the web application penetration testing process should be properly documented with valid evidences. Do not try to fix or modify the vulnerability to enhance security of the web application at this moment. This is not a duty of a penetration tester. Penetration tester could inform the relevant authorities if there is an immediate threat, otherwise these findings should be included in to the final reports of the client organization. Make sure the identified vulnerabilities exist with evidence. Furthermore, have proof of concepts to show this could enable greater danger if exploited by an attacker. Penetration tester should not exploit the vulnerabilities and cause any harm to web application of relevant systems. However, if the organization requested and agreed to exploit any vulnerability found during the process, you may proceed. Penetration tester could recommend possible security control measures that organizations could take in order to mitigate the risk exposed due to the vulnerabilities.

This paper discussed briefly how and what areas of a web application needs to be checked for vulnerabilities. In addition, what sort of vulnerabilities that we can find in general. This does not cover comprehensive web application testing in detail or discuss tools in depth. However, few tools that can be used are listed and where the details of these tools can be referred is noted.

Why should we take great care when creating passwords?


This is a very simple and interesting cartoon that I came across while I was searching some information.I think this is very well depict the importance of setting a secure password. This is simple, humorous, educational and delivering the message with attraction.

It is almost one year

It is sad to note that I have not updated my blog for almost a year. It is terrible. Why can't I post something in my blog?
Let's start it again, this time I am going to make it through. No excuses. Let me start with my previous post about the bird. This bird's name is "Cuckoo", or else we commonly known as "Koha".