SEMINAR REPORT ON PENETRATION TESTING & INTRODUCTION TO BACKTRACK

SUBMITTED AS A PART OF COURSE CURRICULUM FOR DEGREE OF BACHELOR OF TECHNOLOGY

IN

INFORMATION TECHNOLOGY

SUBMITTED TO:ER. DIVYA & ER. DIKSHA LECT. DEPT. OF INFORMATION TECH. DATE-21ST FEB. 2011

SUBMITTED BY:AMRIT RAJ RANJAN ROLL NO.:-2208606 B.TECH.-6TH SEM.

DEPARTMENT OF INFORMATION TECHNOLOGY SWAMI DEVI DAYAL INSTITUTE OF ENGINEERING & TECHNOLOGY DIST-PANCHKULA(BARWALA) HARYANA-134118

PREFACE
Most people think of hacker as computer vandals. But, call a real hacker a criminal and believe me, he would do more than lose his temper. Hackers are not computer criminals .why do most people think of hackers as criminals??The media is responsible for this erroneous assumption. Real hackers like to call people who break into system cracker. In fact, people who code and release viruses are not necessarily hacker, they are virii coders. This report is for new and experienced hacker (professional hacker) both who are really interested in giving security to softwares,wi-fi,and networks .While this report assume that readers ultimate goal is to develop good concept of system security and ethical hacking. I am thankful to Kurukshetra University which constituted this seminar program as a part of B.Tech syllabus, and gives me a chance to improve my knowledge in some extra field other than books. I express my gratitude to Dr. B. Pattnaik, Director Principal S.D.D.I.E. I also thank Er. Chandra Prabha, H.O.D Information Technology S.D.D.I.E.T & Er.Divya, Lect. Information Technology S.D.D.I.E.T for all the support and encouragement they give me about the seminar. I express my sincere thanks to Dr. Vashnavi Priyanka, M.D Cefin Technology for her advice and guidance for the improvement of my skill in IT Security. Also, I would like to place on records my appreciation and thanks to all the members of my family, faculty & my dear friends who have been associated with this training in one or the other form. AMRIT RAJ RANJAN B.Tech-3rd yr. Information Technology

ACKNOWLEDGEMENT

It is with greatest pleasure and pride that we present this report before you. At this moment of triumph, it would be unfair to neglect all those who helped me in the successful completion of this project. First of all, I would like to place ourselves at the feet of God Almighty for his everlasting love and for the blessings & courage that he gave me, which made it possible to me to see through the turbulence and to set me in the right path. I would also like to thanks Dr.VASHNAVI PRIYANKA for all the help and guidance that she provided to us. I would take this opportunity to thank my friends who were always a source of encouragement.

CONTENTS

1. INTRODUCTION TO PENETRATION TESTING

1.1

1.2
1.3

Black box vs. White box Rationale Stages of a Pen-Test Information Gathering Information Gathering Vulnerability Scanner

2. RISKS 3. METHODOLOGIES 4. STANDARDS AND CERTIFICATION 5. WEB APPLICATION PENETRATION TESTING 6. SOFTWARE PENETRATION TESTING 6.1 Penetration Testing Today

7. INTRODUCTION TO BACKTRACK 7.1 Histroy 7.2 Tools 7.3 Releases 8. BIBLOGRAPHY

1. INTRODUCTION TO PENETRATION TESTING

A penetration test, occasionally pentest, is a method of evaluating the security of a computer system or network by simulating an attack from a malicious source, known as a Black Hat Hacker, or Cracker. The process involves an active analysis of the system for

any potential vulnerabilities that could result from poor or improper system configuration, both known and unknown hardware or software flaws, or operational weaknesses in process or technical countermeasures. This analysis is carried out from the position of a potential attacker and 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. The intent of a penetration test is to determine the feasibility of an attack and the amount of business impact of a successful exploit, if discovered. It is a component of a full security audit. For example, the Payment Card Industry Data Security Standard (PCI DSS), and security and auditing standard, requires both annual and ongoing penetration testing (after system changes).

6.1Black box vs. White box

Penetration tests can be conducted in several ways. The most common difference is the amount of knowledge of the implementation details of the system being tested that are available to the testers. Black box testing assumes no prior knowledge of the infrastructure to be tested. The testers must first determine the location and extent of the systems before commencing their analysis. At the other end of the spectrum, white box testing provides the testers with complete knowledge of the infrastructure to be tested, often including network diagrams, source code, and IP addressing information. There are also several variations in between, often known as grey box tests. Penetration tests can also be described as "full disclosure" (white box), "partial disclosure" (grey box), or "blind" (black box) tests based on the amount of information provided to the testing party. The relative merits of these approaches are debated. Black box testing simulates an attack from someone who is unfamiliar with the system. White box testing simulates what might happen during an "inside job" or after a "leak" of sensitive information, where the attacker has access to source code, network layouts, and possibly even some passwords. The services offered by penetration testing firms span a similar range, from a simple scan of an organization's IP address space for open ports and identification banners to a full audit of source code for an application.

1.2 Rationale
A penetration test should be carried out on any computer system that is to be deployed in a hostile environment, in particular any Internet facing site, before it is deployed. This provides a level of practical assurance that any malicious user will not be able to penetrate the system.

Black box penetration testing is useful in the cases where the tester assumes the role of an outside hacker and tries to intrude into the system without adequate knowledge of it.

1.2 Stages of a Pen-Test

Gathering Information Analyzing the Infra-Structure Analyzing the Machines Fingerprinting Port / Vulnerability-Scanning Attacking the System / Proof of Concept Analyzing Applications Functional / Structural Analysis Attacking Authentication and Authorization Attacking Data and Back-End Communication Attacking Clients

1.2.1 Information Gathering

In this phase you try to compile as much publicly available information as possible Internic IANA / RIPE Whois Google / Usenet Private homepages of employees Email Addresses Telephone numbers

1.2.2 Information Gathering

Google Search-Syntax allintitle:Index of /etc site:gov site:mil site:ztarget.com filetype:doc filetype:pdf filetype:xls intitle:, inurl:, allinurl: allinurl:mssql, allinurl:gw inurl:".aspx?ReturnUrl=" "+www.ernw.+de" related:www.ernw.de login site:www.microsoft.com [cached]

1.2.3 Vulnerability Scanner

System / Host Scanner Nessus (www.nessus.org) Retina (www.eeye.com) ISS Security Scanner (www.iss.net) Microsoft MBSA (www.microsoft.com) Database Scanner MetaCoreTex (www.metacoretex.com) AppSecInc AppDetective (www.appsecinc.com) ISS Database Scanner (www.iss.net) Web Server Scanner Nikto (www.cirt.net)

2. Risks
Penetration testing can be an invaluable technique to any organization's information security program. Basic white box penetration testing is often done as a fully automated inexpensive process. However, black box penetration testing is a labor-intensive activity and requires expertise to minimize the risk to targeted systems. At a minimum, it may slow the organization's networks response time due to network scanning and vulnerability scanning. Furthermore, the possibility exists that systems may be damaged in the course of penetration testing and may be rendered inoperable, even though the organization benefits in knowing that the system could have been rendered inoperable by an intruder. Although this risk is mitigated by the use of experienced penetration testers, it can never be fully eliminated.

3. Methodologies
The Open Source Security Testing Methodology Manual is a peer-reviewed methodology for performing security tests and metrics. The OSSTMM test cases are divided into five channels which collectively test: information and data controls, personnel security awareness levels, fraud and social engineering control levels, computer and telecommunications networks, wireless devices, mobile devices, physical security access controls, security processes, and physical locations such as buildings, perimeters, and military bases The OSSTMM focuses on the technical details of exactly which items need to be tested, what to do before, during, and after a security test, and how to measure the results. OSSTMM is also known for its Rules of Engagement which define for both the tester and the client how the test needs to properly run starting from denying false advertising from testers to how the client can expect to receive the report. New tests for international best practices, laws, regulations, and ethical concerns are regularly added and updated. The National Institute of Standards and Technology (NIST) discusses penetration testing in SP800-115. NIST's methodology is less comprehensive than the OSSTMM; however, it is

more likely to be accepted by regulatory agencies. For this reason, NIST refers to the OSSTMM. The Information Systems Security Assessment Framework (ISSAF) is a peer reviewed structured framework from the Open Information Systems Security Group that categorizes information system security assessment into various domains and details specific evaluation or testing criteria for each of these domains. It aims to provide field inputs on security assessment that reflect real life scenarios. The ISSAF should primarily be used to fulfill an organization's security assessment requirements and may additionally be used as a reference for meeting other information security needs. It includes the crucial facet of security processes and, their assessment and hardening to get a complete picture of the vulnerabilities that might exist. The ISSAF, however, is still in its infancy.

4. Standards and certification

The process of carrying out a penetration test can reveal sensitive information about an organization. It is for this reason that most security firms are at pains to show that they do not employ ex-black hat hackers and that all employees adhere to a strict ethical code. There are several professional and government certifications that indicate the firm's trustworthiness and conformance to industry best practice. The Council of Registered Ethical Security Testers (CREST) is a non-profit association created to provide recognised standards and professionalism for the penetration testing industry. For organisations, CREST provides a provable validation of security testing methodologies and practices, aiding with client engagement and procurement processes and proving that the member company is able to provide testing services to the CREST standard. Three certifications are currently offered: the CREST Registered Tester and two CREST Certified Tester qualifications, one for infrastructure and one for application testing. The Information Assurance Certification Review Board (IACRB) manages a penetration testing certification known as the Certified Penetration Tester (CPT). The CPT requires that the exam candidate pass a traditional multiple choice exam, as well as pass a practical exam that requires the candidate to perform a penetration test against live servers. SANS provides a wide range of computer security training arena leading to a number of SANS qualifications. In 1999, SANS founded GIAC, the Global Information Assurance Certification, which according to SANS has been undertaken by over 20,000 members to date.[5] Two of the GIAC certifications are penetration testing specific: the GIAC Certified Penetration Tester (GPEN) certification; and the GIAC Web Application Penetration Tester (GWAPT) certification. Offensive Security offers an Ethical Hacking certification (Offensive Security Certified Professional) - a training spin off of the BackTrack Penetration Testing distribution. The OSCP is a real-life penetration testing certification, requiring holders to successfully attack and penetrate various live machines in a safe lab environment. Upon completion of the

course students become eligible to take a certification challenge, which has to be completed within twenty-four hours. Documentation must include procedures used and proof of successful penetration including special marker files. Government-backed testing also exists in the US with standards such as the NSA Infrastructure Evaluation Methodology (IEM). For web applications, the Open Web Application Security Project (OWASP) provides a framework of recommendations that can be used as a benchmark. The Tiger Scheme offers two certifications: Qualified Tester (QST) and Senior Security Tester (SST). The SST is technically equivalent to CHECK Team Leader and QST is technically equivalent to the CHECK Team Member certification. Tiger Scheme certifies the individual, not the company. The International Council of E-Commerce consultants certifies individuals in various ebusiness and information security skills. These include the Certified Ethical Hacker course, Computer Hacking Forensics Investigator program, Licensed Penetration Tester program and various other programs, which are widely available worldwide.

5. Web application penetration testing

Web application penetration testing refers to a set of services used to detect various security issues with web applications and identify vulnerabilities and risks, including:

Known vulnerabilities in COTS applications Technical vulnerabilities: URL manipulation, SQL injection, cross-site scripting, back-end authentication, password in memory, session hijacking, buffer overflow, web server configuration, credential management, Clickjacking, etc, Business logic errors: Day-to-Day threat analysis, unauthorized logins, personal information modification, pricelist modification, unauthorized funds transfer, breach of customer trust etc.

OWASP, the Open Web Application Security Project, an open source web application security documentation project, has produced documents such as the OWASP Guide and the widely adopted OWASP Top 10 awareness document. The Firefox browser is a popular web application penetration testing tool, with many plugins specifically designed for web application penetration testing. Damn vulnerable web app otherwise known as DVWA is an open source web application which has been made to be vulnerable so that security professionals and students can learn more about web application security.

Foundstone's Hacme Bank simulates a banking application. It helps developers and auditors practice web application attacks, including input validation flaws such as SQL injection and Cross Site Scripting (XSS).

5.1 Testing for SQL Injection

Try if you can inject SQL code in forms If the programmer simply concatenates user input with SQL statements a database compromise is most likely possible Try to generate errors Insert a ' character Does the application behave different ? Is maybe even a database error returned ? You can execute nasty statements through SQL Injection Union Drop... XP_CMDSHELL

6. Software Penetration Testing

Quality assurance and testing organizations are tasked with the broad objective of assuring that a software application fulfills its functional business requirements. Such testing most often involves running a series of dynamic functional tests to ensure proper implementation of the applications features. However, because security is not a feature or even a set of features, security testing doesnt directly fit into this paradigm. Security testing poses a unique problem. Most software security defects and vulnerabilities arent related to security functionalityrather, they spring from an attackers unexpected but intentional misuses of the application. If we characterize functional testing as testing for positives verifying that a feature properly performs a specific taskthen security testing is in some sense testing for negatives. The security tester must probe directly and deeply into security risks (possibly driven by abuse cases and architectural risks) to determine how the system behaves under attack. One critical exception to this rule occurs when the tester must verify that security functionality works as specifiedthat the application not only doesnt do what its not supposed to do, but that it does do what its supposed to do (with regard to security features). In any case, testing for a negative poses a much greater challenge than verifying a positive. Quality assurance people can usually create a set of plausible positive tests that yield a high degree of confidence a software component will perform functionally as desired. However, its unreasonable to verify that a negative doesnt exist by merely enumerating actions with the intention to produce a fault, reporting if and under which circumstances the fault occurs. If negative tests dont uncover any faults, weve only proven that no faults occur under particular test conditions; by no means have we proven that no faults exist. When applied to security testing, where the

lack of a security vulnerability is the negative were interested in, this means that passing a software penetration test provides very little assurance that an application is immune to attack. One of the main problems with todays most common approaches to penetration testing is misunderstanding this subtle point.

6.1 Penetration testing today

Penetration testing is the most frequently and commonly applied of all software security best practices, in part because its an attractive late lifecycle activity. Once an application is finished, its owners subject it to penetration testing as part of the final acceptance regimen. These days, security consultants typically perform assessments like this in a time boxed manner (expending only a small and predefined allotment of time and resources to the effort) as a final security checklist item at the end of the life cycle. One major limitation of this approach is that it almost always represents a too little, too late attempt to tackle security at the end of the development cycle. As weve seen, software security is an emergent property of the system, and attaining it involves applying a series of best practices throughout the software development life cycle (SDLC; see Figure)

Organizations that fail to integrate security throughout the development process often find that their software suffers from systemic faults both at the design level and in the implementation (in other words, the system has both security flaws and security bugs). A late lifecycle penetration testing paradigm uncovers problems too late, at a point when both time and budget severely constrain the options for remedy. In fact, more often than not, fixing things at this stage is prohibitively expensive. An ad hoc software penetration tests success depends on many factors, few of which lend themselves to metrics and standardization. The most obvious variables are tester skill, knowledge, and experience. Currently, software security assessments dont follow a standard process of any sort and therefore arent particularly amenable to a consistent application of knowledge (think checklists and boilerplate techniques). The upshot is that only skilled and experienced testers can successfully perform penetration testing.

The use of security requirements, abuse cases, security risk knowledge, and attack patterns in application de sign, analysis, and testing is rare in current practice. As a result, security findings cant be repeated across different teams and vary widely depending on the tester. Furthermore, any test regimen can be structured in such a way as to influence the findings. If test parameters are determined by individuals motivated not to find any security issues (consciously or not), its likely that the penetration testing will result in a self-congratulatory exercise in futility.

7. Introduction To BackTrack
BackTrack is a GNU/Linux distribution distributed as a Live DVD aimed at digital forensics use and penetration testing.

7.1 History
The BackTrack distribution originated from the merger of two formerly competing distributions which focused on penetration testing:

WHAX: a Slax based Linux distribution developed by Mati Aharoni, an Israeli security consultant. Auditor Security Collection: a Live CD based on Knoppix developed by Max Moser which included over 300 tools organized in a user-friendly hierarchy.

The overlap with Auditor and WHAX in purpose and tools collection partly led to the merger.

7.2 Tools

BackTrack provides users with easy access to a comprehensive and large collection of security-related tools ranging from port scanners to password crackers. Support for Live CD and Live USB functionality allows users to boot BackTrack directly from portable media without requiring installation, though permanent installation to hard disk is also an option. BackTrack includes many well known security tools including:

Metasploit integration RFMON Injection capable wireless drivers Kismet Nmap Ettercap Wireshark (formerly known as Ethereal) BeEF (Browser Exploitation Framework) Hydra Quypt (Terminal Emulator) (which is private software by Crimson Hacking group, which has leaked to the Mainstream) (Blackhat) A large collection of exploits as well as more commonplace software such as browsers.

BackTrack arranges tools into 11 categories:

Information Gathering Network Mapping Vulnerability Identification Web Application Analysis Radio Network Analysis (802.11, Bluetooth, RFID) Penetration (Exploit & Social Engineering Toolkit) Privilege Escalation Maintaining Access Digital Forensics Reverse Engineering Voice Over IP

7.3 Releases
Date February 5, 2006 May 26, 2006 March 6, 2007 June 19, 2008 January 9, 2010 May 8, 2010 November 22, 2010 Release BackTrack v.1.0 Beta The BackTrack project released its first non-beta version (1.0). BackTrack 2 final released. BackTrack 3 final released. BackTrack 4 final release. (Now based on Debian) BackTrack 4 R1 release BackTrack 4 R2 release

As soon as newer versions of BackTrack are released, older versions lose their support and service from the BackTrack development team.

8. BIBLOGRAPHY www.google.com

 www.wikipedia.com www.offensive-security.com