PenTest OPEN eBook

(1)

(2)

(3)

A

s a result of fruitful collaboration between Dr. Wright and PenTest Magazine, eForensics Magazine and Hakin9 Magazine, we are proud to present this publication which is a comprehensive compendium of knowledge on four general subjects:

• Network Audit • Unix Testing

• Auditing Cisco - Routers & Switches • Pentesting

Dr. Craig Wright, multi-talented man, reaching heights both academically and professionally is the author of this publication. Dr. Craig Wright runs a number of training courses, academic lectures. He is also a contributor of various substantive articles for papers and magazines.

Dr Craig Wright is a lecturer and researcher at Charles Sturt University (IT Security, Digital Forensics) and Executive Vice – President (strategy) of CSCSS (Centre for Strategic Cyberspace+ Security Science) with a focus on collaborating government bodies in securing cyber systems. With over 20 years of IT-related experience, he is a sought-after public speaker both locally and internationally, training Australian and international government departments in Cyber Warfare and Cyber Defence, while also presenting his latest research findings at academic conferences.

In addition to his security engagements, Craig continues to contribute with IT security related articles and books. Dr Wright holds the following industry certifications: GSE CISSP, CISA, CISM, CCE, GCFA, GLEG, GREM and GSPA. He has numerous degrees in various fields including a Master’s degree in Statistics, and a Master’s Degree in Law specializing in International Commercial Law. Craig is working on his second doctorate, a PhD on the Quantification of Information Systems Risk and plans to work on new PhD in second half of the year in are of Juridical Studies.

On the 250 pages of the magazine you will find a cross knowledge of Network Audit, Auditing Cisco Routers and Switches, Unix Testing and penetration testing study guide. This knowledge will serve as a comprehensive material for independent work and study at home, as well as a source of information and innovative solutions.

I wish you, Dear Readers, an interesting reading! Sincerely,

(7)

Chapter 3: GPEN Study Guide

Pen-testing Foundations Pen-testing process Legal Issues Reconnaissance Intro to Linux

Scanning Goals and Techniques Network Tracing, Scanning, and Nmap Vulnerability Scanning

Enumerating Users Netcat and Hping Exploitation

Command Shell vs. Terminal Access Remote command execution

Password Attacks Wireless Fundamentals Web Application Overview

(8)

Outcome Statement

In this section I will demonstrate an understanding of the fundamental conceptsassociated with pen-testing. Core Topics:

• Terminology

• Purpose of Pen Testing • Types of Tests and Limitations • Methodologies

Terminology

Before delving into the world of penetration testing, it is important to make sure that everyone is “speaking the same language”. To that end we are going to start by identifying and defining some key terms that will be frequently used in this study guide:

Threat: A threat is an actor or agent that may want to or actually can cause harm to the target organization. Threats include organized crime, spyware companies, and disgruntled internal employees who start attacking their employer. Vulnerability: A vulnerability is some flaw in our environment that an attacker could use to cause damage. Vulnerabilities could exist in numerous arenas in our environments, including our architectural design, business processes, deployed software, and system configurations.

Risk: Risk is where threat and vulnerability overlap. That is, we have a risk when our systems have a vulnerability that a given threat can attack.

Exploit: An exploit is the vehicle by which the attacker uses a vulnerability to cause damage to the target system. The exploit could be a package of code which generates packets that overflow a buffer in software running on the target. Alternatively, the exploit could be a social engineering scheme whereby the bad guy talks a user into revealing sensitive information, such as a password, over the phone.

Ethical Hacking: Ethical Hacking is the process of using computer attack techniques to find security flaws with the permission of the target owner and the goal of improving the target’s security.

Penetration Testing: Penetration testing is a more narrowly focused phrase than ethical hacking, dealing with process of finding flaws in a target environment with the goal of penetrating systems, taking control of them.

Vulnerability Assessments: Vulnerability assessments are focused on finding vulnerabilities in a system or network, often without regard to actually exploiting them and getting in.

The Purpose of Pen-Testing

The purpose of pen-testing is simple: to find security flaws before the bad guys do. After applying their security policies, procedures, and technology, organizations can use thorough penetration tests to see how effective their security really is in light of an actual attack, albeit by friendly attackers. An added benefit of ethical hacking and penetration testing is that, because they show real vulnerabilities and indicate what a malicious attacker might be capable of achieving, they can get management’s attention. Decision makers, when presented with the carefully formulated results of a test in business terms, are more likely to provide resources and attention to improve the security stance of an organization.

A major goal of penetration testing and ethical hacking is discovering flaws so that they can be remediated (by applying patches, reconfiguring systems, altering the architecture, changing processes, etc.). However, it is important to note that in most tests, not all of the discovered vulnerabilities are actually addressed. A common recommendation is that all high-risk vulnerabilities be addressed in a timely fashion, but the truth is that some vulnerabilities linger long after a test is complete, even high-risk issues. Remember, information security is all about managing risk, not eliminating it. Types of Tests and Limitations

(9)

• Network services test: This involves finding target systems on the network, looking for openings in their underlying operating systems and available network services, and then exploiting them remotely. This is generally the most common type of test.

• Client-side test: This kind of test is designed to find vulnerabilities in and exploit client-side software, such as browsers, media players, or document editing programs.

• Web application test: These tests look for security vulnerabilities in the web-based applications deployed on the target environment.

• Remote dial-up war dial: These tests look for modems in a target environment, and often involve password guessing to login to systems connected to discovered modems.

• Wireless security test: These tests involve exploring a target’s physical environment to find unauthorized wireless access points or authorized wireless access points with security weaknesses.

• Social engineering test: This type of test involves attempting to dupe a user into revealing sensitive information such as a password.

Although penetration testing and ethical hacking are useful practices, they do have some limitations. First off, testing projects by their very nature have a limited scope. Most organizations don’t (and can’t) test everything, due to resource constraints. We test those elements of our infrastructure that are deemed most vital. But, a real-world attacker may find flaws in other areas that simply weren’t part of our testing project’s scope. Furthermore, penetration testers and ethical hackers often have constrained access to the target environment that models where some, but not all, of the bad guys sit. Also, because of the risk of crashing a target system during a test, some particular attack vectors will likely be off the table for a professional penetration tester or ethical hacker. Finally, most professional penetration testing is limited by the current known exploits available publicly. Most professional penetration testers and ethical hackers do not write their own exploits, but instead rely on exploits written by others. Even for those testers who do write exploits, there often isn’t enough time to create a custom exploit for a newly discovered flaw in a given target environment.

Methodologies

Several organizations have released high-quality, free penetration testing and ethical hacking methodology documents. It’s a good idea to review each of these free documents, as they provide useful insights into testing from various different perspectives. Four of the best free documents on testing methodologies include:

• Open Source Security Testing Methodology Manual (available at www.isecom.org/osstmm)

• NIST Special Publication 800-115: Technical Guide to Information Security Testing and Assessment (available at csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf)

• Open Web Application Security Project (OWASP) Testing Guide (available at www.owasp.org) • Penetration Testing Framework (available at www.vulnerabilityassessment.co.uk

)

Key Questions

1.

What is the difference between a risk, vulnerability, and a threat?

2. What is the difference between a penetration test and a vulnerability assessment? 3. What is the primary purpose of a penetration test?

4. What type of penetration test involves trying to find flaws in web browsers or media players and exploiting them? 5. What are some of the major limitations of penetration testing?

(10)

Section 1: Pen-testing process

Outcome Statement

In this section I will demonstrate an understanding of the pen-testing processand the importance of reporting. Core Topics:

• Permission and Liability • Rules of Engagement • Scoping

• Reporting

The overall penetration testing process involves three phases: preparation, testing, and conclusion. Preparation

During the preparation phase, the parties participating in the test may sign a non-disclosure agreement, especially if the test is conducted by a third-party organization. Then, the testers and the target personnel discuss the most significant concerns of the target organization. We also agree on rules of engagement that describe how the testing will occur. Testing

The testing phase is exactly what it sounds like; this is where the testing takes place. There are distinct sub-phases in the testing process that will be covered later in the material.

Conclusion

The conclusion phase, while often overlooked, is extremely critical. This is where you summarize your findings in a report and provide them to the client. It’s important to ensure that the data is not only available to the client but usable by them so they can develop a plan to fix any issues you identified during the pen-test.

Permission and Liability

Before doing anything else you need to get official, written permission to conduct the test, even if it is against targets in your own organization. This permission should notify the personnel associated with the target systems that there is some danger of their systems being crashed or impaired by the testing. One of the best ways to do this is via the use of a permission memo (aka a “Get Out of Jail Free Card”). A sample memo can be found at http://www.counterhack. net/permission_memo.html. Have your legal team review, tweak, and approve this language. Then, print it on corporate letterhead and have a chief information officer or similar level of management sign off on it.

While the permission memo is acceptable for employees testing their employers, it is not, by itself, suitable as a vehicle for a penetration testing company to test their customers’ environments. It can act as a starting point for that more comprehensive document. But such third-party penetration testing agreement for client networks must also include a limitation of liability agreement and a contract. These items should be drawn up by a lawyer associated with either the penetration testing company or the client. Most penetration testing companies include a limitation of liability agreement that caps the liability for any problems associated with the project at the price of the project itself. To help address this issue further, most penetration testing companies also carry liability and errors and omissions insurance in addition to getting the limitation of liability agreement. Again, this is generally only necessary for third party companies and is generally not necessary for in-house penetration testing.

Rules of Engagement

Rules of Engagement, a set of practices that must be defined before a penetration test or ethical hacking project can begin. Both the people responsible for the target environment and the testing team must agree on these rules. Without proper Rules of Engagement agreed upon in advance, a penetration test or ethical hacking project could go seriously awry, resulting in devastating consequences for the target organization and the testers.

The Get Out of Jail Free Card, limitation of liability agreement, and insurance help protect the testers legally. But, these documents must be shored up with a carefully decided rules of engagement memo that is documented in advance. Some testers define the rules of engagement with a client before they devise a detailed scope of the test. That way, the

(11)

target organization can have in mind the way the test will be conducted to help make decisions about what is in and out of scope. Others reverse the flow, defining the scope before agreeing to rules of engagement, so that they know what they will test and can then craft the rules of engagement around the given test targets. Either approach is acceptable – defining the rules of engagement first followed by scoping, or scoping the project first and then defining rules of engagement. The important point is that both issues be covered in advance.

Scoping

The scoping process determines what should be tested and what should not be tested. In addition to determining individual target systems and networks, this scoping process will also look at some types of testing that may or may not be in scope.

To start out a scoping conversation, ask members of the target organization about their biggest security concerns. Determining the primary concerns up front can help narrow the focus of a test. Discuss threats, risks, and already-known vulnerabilities with the target organization’s representatives. It is vital to focus this conversation to determine exactly what needs to be tested. The last thing a tester wants is a blurry scope that could lead to scope creep. With scope creep, a misunderstanding of what should be tested leads the target organization to add more systems, target networks, target types, and types of testing to the test as it progresses, a dangerous and costly proposition for a tester.

One of the most important elements to include in the project scope is a succinct statement of what is to be tested. Spell out explicitly those domain names, network address ranges, individual hosts, and particular applications that are included in the test.

Also, if there are particularly sensitive elements of the organization that should not be tested, explicitly spell out that list of off-limits machines. If any third-party owned or managed systems are included in the scope, make sure to get written permission from these parties before the test begins. The target organization is responsible for getting this permission, and the testers are responsible for making sure the target organization does this.

Beyond what should be tested, the scope should specify the level of testing that should occur. Will the test merely be a network scan for targets and vulnerabilities or should the testers go further and actually penetrate the target systems, getting access the targets if possible? If penetration is allowed, should it focus on listening network services, or will client-side software exploitation be allowed as well? Will the test include any application-level or client-client-side web component testing? What about physical attacks, social engineering or denial of service attacks? Your Rules of Engagement should specify each element on this list that is included in the scope.

Reporting

Testers should always create a final report describing their work and findings. If the testers work for a third-party penetration testing or ethical hacking company, the report is really the only evidence they leave behind of the project they performed. A report is concrete proof that your organization is exercising its due diligence in conducting vulnerability scans on a regular basis. If there are major security problems in the future (such as a major breach), and your organization is investigated by the government or shareholders, the vulnerability scanning reports will be helpful in showing your attempts to measure your security stance in the past.

Penetration testing, vulnerability assessment, or ethical hacking reports will generally include these elements:

Executive Summary: This brief up-front matter is meant for executives who may not read the full report, providing them the most important conclusions from the work. Probably the most important part of the report

Introduction: This component describes the project at a high level, answering the who, where, when, and why aspects of the project.

Methodology: This part of the report describes the “what” of the project – what did the team do? It covers the process of the penetration test or ethical hacking engagement.

Findings: This section presents the actual findings, listed one by one, in the target environment with detailed technical descriptions. The findings are sorted so that the most significant risk issues are discussed first.

(12)

Key Questions

1. What are the three phases of the penetration testing process?

2. Why is it important to ensure you get official permission in writing before conducting a penetration test? 3. Why might a permission memo not be sufficient for a third party testing company? What else may be needed? 4. What are rules of engagement as they apply to penetration testing? Why are they important?

5. What are some key differences between the rules of engagement and the scope of a penetration test?

6. What is the purpose of having a scope of a penetration test? What are some consequences of not having one? 7. What is probably the most important part of a penetration testing report?

8. What are the key sections of a penetration testing report? 9. Why is having a thorough report important?

Section 2: Legal Issues

Outcome Statement

In this section I will demonstrate an understanding of the legal issues thatsurround pen-testing. Core Topics: • US Laws • Canadian Laws • UK Laws • German Laws • Australian Laws • Japanese Laws • Singapore Laws

Many countries have instituted laws for dealing with crimes committed using a computer, so-called “cybercrime” laws. Not all countries have such laws, and indeed, attackers sometimes move to countries or operate through countries without such laws or where cybercrime laws are not enforced. As penetration testers and ethical hackers, we want to make sure we carefully adhere to the laws of the countries in which we operate. Your Permission Memo (the “Get Out of Jail Free Card”) is a very helpful thing in assuring that you have permission of the target organization that owns the systems you will test. Still, beyond that memo, we still need to have a feel for various countries’ laws so that we can make sure we follow them. It is important to note that the tester not only has to follow the laws where he or she is located, but also the laws in the country where the target machines are located.

US Laws

Some of the most important US cybercrime laws include:

• Title 18, Section 1030: This is the major law in the US under which most cybercrime cases are prosecuted. Originally known as the Computer Fraud and Abuse Act, this law protects federal interest computer systems from being attacked.

(13)

• The Cyber Security Enhancement Act of 2002: This law was designed to modernize cybercrime legislation in the United States, particularly issues associated with terrorism. This law allows for fines or imprisonment for any term of years or for life, or both.

• Title 18, Section 1362 addresses malicious injury or destruction of communications equipment, such as radio, telegraph, and telephone or cable equipment operated or controlled by the United States or associated with US military or civil defense. Penalties include fines and imprisonment for up to 10 years.

• Title 18, Section 2510 and its subsequent sections govern interception of electronic

• Communication, prohibiting interception of such information without explicit permission. The law includes exemptions for people who operate the network itself, so long as their actions are associated with protecting the network and keeping it running

• Title 18, Section 2701: This law protects stored electronic information and prohibits access to stored communications with penalties of fines and imprisonment ranging between one year and ten years. Exceptions are granted for the service provider, as well as the legitimate, intended recipient of the information.

Canadian Laws

Two laws dominate Canadian law from a cybercrime perspective:

CC184 is called Interception of Communications, and deals with unauthorized monitoring of private communications. It prohibits the unauthorized interception of such communications regardless of the form. The law carves out a series of exceptions. If the originator or the recipient authorizes the monitoring, it does not violate the law. Penalties for violating this law include up to five years imprisonment.

The second major law is CC 342: Unauthorized Use of Computer. This law criminalizes the use of computers for fraudulent activities, including:

• Obtaining computer service without authorization • Intercepting any function of a computer system

• Using a computer system with intent to commit an offence defined in other laws • Using, possessing, or trafficking in passwords used to commit an offense • Penalties for violating this section range up to ten years of imprisonment. UK Laws

In the United Kingdom, the dominant cybercrime law is the “Computer Misuse Act of 1990.” This law specifically says that, “A person is guilty of an offence if:

• He causes a computer to perform any function with intent to secure access to any program or data held in any computer • The access he intends to secure is unauthorized; and

• He knows at the time when he causes the computer to perform the function that that is the case.” These specific conditions apply regardless of the particular program or data the perpetrator accesses. German Laws

German cybercrime laws are contained in the penal code, specifically in Sections 202 and 303. Section 202a is associated with Data Espionage, and states:

“Whoever, without authorization, obtains data for himself or another, which was not intended for him and was specially protected against unauthorized access, shall be punished with imprisonment for not more than three years or a fine.” Section 202c, passed in 2007, is very controversial, sometimes referred to as the German “Anti-Hacking” Law by its detractors. It defines as a criminal offense the creation of and distribution of tools used for compromising computers.

(14)

Many people have interpreted this law to mean that security researchers cannot create or distribute scanning tools, sniffers, and exploitation software in Germany.

Section 303a specifically prohibits the unlawful deletion or suppression of data, as well as acts that render it unusable or altered, thus covering both integrity attacks and denial of service attacks. Violations of this law are punishable with up to two years imprisonment or a fine.

Section 303b covers the consequences that are associated with interfering with data processing equipment that has substantial significance to other people from a business perspective. Destruction or damage to such systems is prohibited, with violations punishable with up to five years imprisonment or a fine.

Australian Laws

A dominant law regarding cybercrime in Australia is the Cybercrime Act 2001. This law prohibits unauthorized access to or modification of data, computer systems, and electronic communications, and reserves its harshest penalties for impairment of any of these items. To be guilty of an offence, someone would have to cause unauthorized access to, modification of, or impairment to restricted data, with intent and knowledge that their actions are unauthorized. Furthermore, to classify as an offence, the data associated with the case must be either stored on Commonwealth computers, held on behalf of the Commonwealth, or associated with a telecommunications service. In other words, the law protects government computers and data, as well as systems accessed via public communications networks. Japanese Laws

Japan’s cybercrime laws center on Law Number 128 of 1999. This law prohibits acts of unauthorized access to computer systems. Specifically, it includes Article 3, which deals with unauthorized access to computers identified in the following categories:

• Entering another person’s access code into a computer via telecommunications lines

• Entering information other than an access code that evades access control mechanisms, again via telecommunications lines

• Entering information that evades other restrictions on computers via telecommunications lines

Penalties, defined in Article 8, include fines ranging up to 300,000 to 500,000 Yen, and imprisonment of up to one year. Singapore Laws

The primary cybercrime law in Singapore is known as Chapter 50a, Computer Misuse Act. This Singapore law specifically cites the UK Computer Misuse Act and the Canadian Criminal Law Amendment Act 1985 as references, showing its influences. This law carves out a series of offenses that are closely aligned with various information security models describing the aspects of secure systems, including access control, integrity, confidentiality, availability, and authentication.

Key Questions

1.

Why is it important to be familiar with the cybercrime laws of any country you or your company is in or that the network traffic passes through when conducting a penetration test?

2. What are some of the major US cybercrime laws? Which one is considered the major one? 3. What are some of the major Canadian cybercrime laws?

4. What are some of the major UK cybercrime laws? 5. What are some of the major German cybercrime laws? 6. What are some of the major Australian cybercrime laws?

7. What is the major cybercrime law for Japan and what does it specify? 8. What is the major cybercrime law for Singapore and what does it specify?

(15)

Section 3: Reconnaissance

Outcome Statement

In this section I will demonstrate an understanding of the basic concepts of reconnaissance and how to obtain basic information during this phase.

Core Topics: • Inventory • Whois • Web Reconnaissance • Metadata • DNS • Search Engines

Introduction

After the test has been thoroughly scoped and any required agreements are signed, the test begins with the reconnaissance phase. In this phase, the tester gathers information about the target organization from various public sources. The tester needs to become very familiar with the target’s people and culture, learning the specific business terminology used by people in the target organization. This recon phase is extremely important in conducting thorough penetration tests. Don’t dismiss it because it doesn’t get deep into technology. The information gathered during the reconnaissance phase will be helpful throughout all of the other testing phases, and will be instrumental in the development of the final report.

Inventory

Throughout the test it is vital that you record your results in an organized fashion. Disorganized penetration testers and ethical hackers are often far less successful. The last thing you want to do is to miss out on a vital vulnerability in a target organization because it was lost in disorganized clutter. One of the most helpful tools for recording results is an inventory of all discovered targets and their associated details. A convenient way to store this inventory is by using a spreadsheet. Each discovered target system gets one line in the inventory, with the details populated as they are discovered throughout the remainder of the test. The inventory includes numerous fields, such as the Target’s IP address, name, operating system type, etc. Some of the most important fields to include are How Discovered known vulnerabilities, and the accounts and passwords that are determined. Note that you might not populate every field for every discovered target. Instead of leaving the field blank, it is a good idea to enter “Not Found” or “Not Applicable”, to at least show that the given field was not overlooked.

Whois

To determine more detailed information about a given target domain, we can look it up using various Whois databases distributed around the world. When a domain is registered, the registrar gathers a significant amount of information about the Internet gateway and people associated with the domain.

Most registrars put this information in publicly accessible whois databases. Many of these databases, which are organized in a hierarchical fashion, have a web-based front-end so that they can be accessed via a browser. Alternatively, the whois command built into some operating systems can be used to formulate a whois query.

There are several websites devoted to getting whois information, each providing a portal that will query various whois servers on the Internet. Some of the most popular include:

• www.samspade.org • www.geektools.com • www.whois.net

(16)

Web Reconnaissance

As a start of the recon phase, the tester can use a search engine such as Google to learn more about the target organization. In particular, it is important to conduct searches on the target organization’s name to gather the following information, which should be recorded in the tester’s results:

• Major businesses: What is the industry or industries associated with the target? Financial services? Government

agency? Manufacturing?

• Major products or services: What does the target organization produce? What are the brand names of its

products or services?

• Corporate officers and other VIPs: Who is most important in the target organization? Who are its leaders? Who

is associated with its technical infrastructure?

• Physical locations: Where are the major facilities of the target organization?

• Recent press releases: What has the target enterprise told the public lately about itself? What do they consider

important from an image and marketing perspective?

Most organizations have job requisition information available on the Internet, as they look to hire new staff. These job requests often contain detailed information about the technical environment of the enterprise. In addition to search the target site itself you should look for open jobs on various job-hunting sites, like Yahoo’s Hotjobs.com and Monster.com. Both of these sites let you search based on categories of jobs.

Other helpful areas to search are social networking sites. People put a significant amount of information about themselves on these sites, often including where they work. That employer information is exactly what we are looking for. By searching within the social networking site for people who work for the target enterprise, we can then focus in on their background and skill set.

Metadata

As organizations create documents, the software that they use to create these documents embeds an enormous amount of information in the document files. A good deal of metadata is also included in the file. Much of this metadata is associated with formatting and display of the other data in the file. Besides this formatting metadata, a lot of file creation and editing tools include additional metadata entries that can be very useful for penetration testers during our reconnaissance phase, such as:

• User names: Penetration testers often need user names for exploitation and password-guessing attacks

• File system paths: Knowing the full path of the original file when it was created can reveal useful tidbits about the

target organization

• E-mail addresses: This data can be useful if the penetration test scope includes spear phishing tests

• Client-side software in use: Given that client-side exploitation is such a common attack vector, it can be helpful

to penetration testers to know which client-side programs are in use

Almost every document type has some form of metadata, but some are richer in metadata than others. The following types of documents, generated and used by most enterprises, are of particular interest to penetration testers:

• pdf files: These files are associated with Acrobat Reader and a variety of other pdf creation and editing tools. • doc/docx, xls/xlsx, and ppt/pptx files: These files are associated with Microsoft Office suite, but are also used

by several other related tools.

• jpg and jpeg: These image files often contain a significant amount of metadata, including data about the camera

used to take a picture, the file system of the machine where the image was edited, and details about the image-editing software.

(17)

• html and htm: These file types contain web pages, and may at first seem uninteresting. However, their comments

and hidden form elements could contain metadata that is very useful to a penetration tester. Additionally, scripts embedded in the HTML may reveal sensitive information or undocumented features of a web application.

DNS

The last elements of the whois record include the Domain Name System (DNS) Servers associated with the target organization, listed in the order of primary, secondary, and tertiary (if it exists) DNS servers. Name servers are focused on resolving domain names into IP addresses, but that isn’t their sole function. They also indicate which machines are mail servers for a given domain, among other useful information. DNS servers house a variety of different records, including (but not limited to):

• NS: Name server record, which indicates the name servers associated with a given domain. • A: Address record, which maps a domain name into an IP address.

• MX: Mail Exchange record, which identifies the mail servers for the given domain.

• CNAME: Canonical Name record, which indicates aliases and alternative names for a given host.

• SOA: Start of Authority record, which indicates that a server is authoritative for that DNS zone (set of records). • PTR: Pointer for inverse lookups records. Also called a reverse record, indicating an IP address to domain name

mapping.

Tools such as nslookup (available in both Windows and *nix) and dig can be used to query DNS servers to retrieve some or all types of available DNS records. There are also websites such as www.dnsstuff.com that can be used to perform DNS lookups.

Search Engines

Another step is to use publicly accessible search engines to look for signs of vulnerabilities on systems. Google, Yahoo, and Microsoft’s Live Search all contain a great deal of information that could indicate the presence of vulnerabilities in systems associated with the target environment. By sending the appropriate queries to the search engines themselves, we may be able to identify vulnerable systems without actually sending any packets to those systems directly. Google has some of the most advanced search queries, including:

• site: The “site:” directive allows an attacker to search for pages on just a single site or domain, narrowing down and focusing the search. For example typing “site:Hakin9.com” will return all the web pages associated with the Hakin9.com domain

• link: The “link:” directive shows sites that link to a given web site. During recon, this directive can be used to find business partners, suppliers, and customers.

• inurl: The “inurl:” directive lets us search for specific terms to be included in the URL of a given site. This can be helpful in finding well-known vulnerable scripts on web servers. For example, searching for inurl:viewtopic.php will find sites with URLs that contain “viewtopic.php” in them.

• ext: or filetype: Both of these directives allow you to search for specific file types. You can use this to identify all files of a given type within a domain by combining it with the site: directive. If you wanted to find all Microsoft Word files on the HAKIN9 website for example you could look for site:Hakin9.com filetype:doc.

There are many, many other things you can find using search engines such as Google. Things like system configurations, passwords, and confidential information can easily be found using the right directive and search strings. A list of useful Google searches to find vulnerabilities can be found at the Google Hacking Database (Johnny.ihackstuff.com)

Key Questions

1. What are some key things to keep track of about a given target system when conducting a penetration test? 2. When conducting web reconnaissance what are some things to take note of?

(18)

3. What sorts of key information can be found in file metadata?

4. What are some common types of files that can provide useful information in their metadata?

5. What is the purpose of querying a target network’s DNS server? What sort of information can you get from it? 6. What might you be able to find when using search engines to query publicly available information? How are

advanced operators such as inurl: and ext: helpful in allowing you to get more relevant search results?

Exercises

1. Using the tool of your choice perform whois queries on several well-known websites as well as smaller ones (local businesses, for example). What sort of information are you able to get.

2. Go to the website of a company of your choice and explore it. See what information you are able to obtain that could be useful to you if you were conducting a penetration test. Also check with national job sites to see if you can learn anything about that company there.

3. Use a DNS lookup tool such as nslookup or the dnsstuff website to query a DNS server and see what information you can obtain. What did you get that could be useful when conducting a penetration test?

4. Use a search engine such as Google to map out a company’s website. Use directives such as inurl: and ext: to gather information about particular types of applications, files, or client apps in use by the company. Use the link: directive to see what information you can gather about the company from other websites.

Section 4: Intro to Linux

Outcome Statement

In this section I will have a fundamental understanding of the Linux operating systems.

The default command terminal or shell (command line) in most Linux distros is BASH (Bourne Again SHell). In Bash, remember that it is simple to correct an error in typing a command using “CTRL-u”. Performing this action will abandon the entire line resulting in the removal of any input from the buffer (and hence evidence such as the BASH history file). Unlike Windows, Linux operating systems are case-sensitive. In Linux it matters what the case you use.

Linux allows commands to be put into “sleep”, killed, sent into the background, and many more options. Some of these are discussed in table 1. This includes a list of keys that can be used in a shell and are listed with their effect.

In addition, there are a number of other simple techniques for controlling execution in a Linux terminal shell. These include sending output to the foreground (fg), background (bg or &), redirecting it (> or >>) or piping it to another command (|).

Key Sequence Result

CTRL-j Line feed. “CTRL-J reset CTRL-J” can act as a reset command on some systems.

CTRL-u Remove the current line from the command buffer (and do not log it).

CTRL-s Stop (and restart) a process. This sequence may suspend a command (i.e. pause it). CTRL-s stops the system from sending any further data to the screen until a CTRL-q is pressed.

CTRL-s CTRL-s and CTRL-q control the flow of output to the terminal. CTRL-q resumes a terminal following the CTRL-s key.

CTRL-z Use CTRL-Z to stop a job. The command “bg” (background) can be used to put the program into the background (type “bg” on the command line).

(19)

CTRL-c Interrupt a program. This is used to “break” a program execution. This signal allows the program to clean up before exiting.

CTRL-d This is an end-of-input response. Some commands (such as mail) require this. Use with caution as this may log you out of some shells.

CTRL-\ Kills a program (without cleaning up).

CTRL-L Clears the screen. This is the same as the command “clear”. CTRL-C Abandon the current command line and return to the prompt.

TAB TAB is used to auto-complete the names of directories and files. Hit Tab for the shell to expand a name of a file such that the system expands it to a unique name that matches what you’ve typed so far. If there are multiple items that match what you’ve typed (i.e., there is nothing unique yet), you can hit Tab again to show the names of all files or directories in your current working directory that match what you’ve typed so far.

CTRL-R This is a history search on recent commands

HOME / END Use the “HOME” key to go to the start of a command line and the “END” key to jump to the end.

Table 1 BASH shortcuts

Shell History

Bash, like many other shells, remembers your shell history, letting you access it by hitting the up and down arrows to access and edit recent commands, which you can re-run by simply hitting enter.

Once you’ve chosen a previous command, you can hit the left and right arrow keys to position your cursor to edit the command.

Also, bash supports tab auto-complete for the names of directories and files. When accessing something in the file system, just hit Tab for the shell to expand it to a unique name that matches what you’ve typed so far. If there are multiple items that match what you’ve typed (i.e., there is nothing unique yet), you can hit Tab again to show the names of all files or directories in your current working directory that match what you’ve typed so far. That is, Tab expands to a unique value, and Tab-Tab shows all items that match what you’ve typed so far if nothing is unique.

Basic UNIX commands

Many of these are not on all UNIX or Linux systems. When connecting to a system for the first time, it is always a good idea to verify the operating system version. Next, use a command such as “which” to validate the existence and path of commands that you intend to use.

Where a command is not in your path, the “which” command will not return any information on the command you are

checking. This does not mean that the command is not installed on the system; it is just that you do not have it in your path. Offline investigation into the system defaults (there are many good information sources on the Internet) for the particular operating system version is the first step in finding what should be on the system.

Remember that Linux systems are often customised by the system administrator, so expect far more variation in path and commands than you will expect to find on a Windows based system. To this end, search tools, file listing tools and text editors will become extremely important in conducting an initial reconnaissance of the system.

Before anyone can master the finer arts of bypassing controls and running shell exploits, it is essential that the basics are not just understood, but are mastered. There are a number of key areas and commands that are fundamental to Linux. A failure to master the basics can be the difference in achieving success or being that person found running ‘dir’ on a Solaris host when ‘ls’ was desired. Some of the most fundamental command areas are detailed below:

(20)

• Account management (useradd, passwd, su, sudo, login, who, whoami, export);

• File management (cd, pwd, ls, mount, mkdir, chmod, chgrp, cp, mv, del, find, locate, mcedit, cat, more/less, pg); • Network management (nc, ifconfig, ifdown/ifup, ping, netstat, route, tcpdump, cat /dev/ip, cat /dev/tcp, ssh, ftp, tftp); • Executing programs (PATH, which, ‘./’, ps, jobs, at, cron);

• File editing (vi, emacs, mail);

• Compression and Compilation (tar, gzip, gunzip, rpm, configure, make);

• Scripting and more (perl, C, shell scripts, sed/awk, grep, man, info, shutdown, kill, bg, etc).

In conducting a reconnaissance of a *NIX system, it is good practice to ensure that you have the version of the system. It is also important to record the time/date that it is set to.

The Essential Commands

The following list provides a quick introduction to the essential commands that you will need to navigate the Linux system.

Lists the files in a directory

The ‘ls’ command is used to list the files in a directory. This is similar to the Microsoft ‘dir’ command, but far more powerful. As all hardware, memory, etc. are treated as a file in Linux, any device can be accessed as a file – if you know where it is and have the correct permissions.

The ‘ls’ command can be pointed at a single file, group of files, the current directory or a specific directory elsewhere in the directory tree.

ls –l

This is a command to list file entries using the ‘long format’. This information is valuable. It includes the file permissions, the size of the file, the file owner and group and it displays the time when the file was last modified. The last modified time is important to note as a change may quickly alert a vigilant system administrator to a change.

ls -a

This command option will list all files – even the hidden ones. In Linux, a file is “hidden” similar to a Windows hidden file attribute through having a name that starts with a “.”

ls -r

The “r” flag instructs the ‘ls’ command to display its output in reverse order.

ls –t

The “t” flag instructs the ‘ls’ command to display its output in order of the file timestamp. This allows you to quickly find all files that have been changed in a selected period.

Used together, these options can help you find all of the files in a directory that have been changed within the time that you have been logged into a host. For example, the command combination, ‘ls –altr | pg’ will output all of the files in the current directory in the order of timestamps starting with the most recently altered or added files and working to the oldest. Further, by piping the ‘pg’ (page) command to ‘ls’ you can see the output a single screen (page) at a time (rather than having this scroll past you faster than you can read it).

File Commands

(21)

more <filename> – less <filename> -

The ‘more’ command displays a file one page at a time. It is similar to the ‘pg’ and ‘less’ commands, with the added benefit that it is available on practically any Linux system.

The ‘pg’ and ‘less’ commands may be more powerful, but they are not universally available. Hitting the space bar will scroll to the next page and hitting ‘q’ will quit the command. The option ‘/pattern’ is available on most Linux systems and provides the ability to search for a defined pattern within the file.

emacs <filename> - vi <filename>

Both ‘emacs’ and ‘vi’ are text editors. Many people have a clear preference for one or the other of these editors, with ‘emacs’ being far more powerful than ‘vi’. Both of these commands are used to create or edit a file. It is essential to become adept in the use of either command. As ‘vi’ is available on nearly every Linux* system ever built – even most firewalls, it is essential to understand how to use it.

Although ‘emacs’ is more powerful in the options it provides, it is commonly removed from many secured systems (such as IDS, gateways and Firewalls). With knowledge of both of these commands you are unlikely to be caught out without access to a text editor when you need one.

mv <filename-1> <filename-2>

The ‘mv’ command simply moves a file. This command either renames the file to use a different name in the same directory (that is it does not create a copy) or moves it into a different directory.

cp <filename-1> <filename-2>

The ‘cp’ (copy) command copies a file. It is similar to what the ‘mv’ command does with the difference being that the original file will remain unchanged (other than the file access timestamp which will be updated).

rm <filename>

The ‘rm’ command removes or deletes a file. This command is similar in effect to the Windows ‘del’ command. The ‘-i’ option to the command asks for confirmation. That is, ‘rm –i’ will require you to confirm that you actually wish to delete the file before it actually removes it.

Many system administrators will alter their ‘.cshrc’ file so that the default behaviour of the ‘rm’ command is to ask for confirmation. This can be problematic if you are creating scripts based on the users profile.

diff <filename-1> <filename-2>

The ‘diff’ command compares two files and displays the differences. This is used to find changes to a file.

wc <filename>

The ‘wc’ (word count) command displays the number of lines, words, and characters in a file.

chmod options <filename>

This command will be covered in far greater detail later in the paper. The ‘chmod’ command is used to change the permissions on a Linux file. These permissions include the ability to read, write, and execute a file.

Without the correct permissions, you will not be able to view a file, modify it or execute it. date

The “date” command is used to either display (to STDOUT) or set the system date and time. Entering the command “date” by itself will list the date and time of the system it is run on. An example of the output of the “date” command is listed below:

(22)

Thu Dec 18 15:14:21 AEST 2008

The command, “date -s “12/22/2008 17:23:59”” would be used in order to set the system’s date and time to that displayed within the command.

The date command tells you a great deal about a system. From this one command, you can gain an understanding as to the level of care that is applied to the host, its location and other information. If the clock skew (the distance from the real time) is large, then the system is likely to receive less than adequate care.

In addition, if the clock is inaccurate, it will be simpler to hide an attack in the system logs. The date command will also return the time zone that is configured on the system. You will not always know where a host is located, and this information can aid you in determining where the system resides.

It is generally necessary to have access to a privileged account (root) in order to be able to set the system date and time. This will be covered in more detail later in the paper.

uname

The “uname” command gives a wealth of information to anybody who does not have knowledge of a system. This command is similar to the “ver” command supplied with Microsoft Windows systems (and DOS). This single command provides intelligence as to the following:

• The Operating System (O/S) running on the host,

• The O/S kernel name and version (which can offer information as to patching practices associated with the host, • The hosts processor type (e.g. i386, i686, sparc, mips) and the hardware platform (e.g. Sun-Fire-280R), and • The O/S or kernel release level.

The following example of this command displays the wealth of information returned from this command. $uname -a

=> Linux linux-09l5 2.6.25.16-0.1-pae #1 SMP 2008-08-21 00:34:25 +0200 i686 i686 i386 GNU/Linux

In some Linux variants (this includes AT&T UNIX System V Release 3.0 – such as Solaris), the “setname” command is available and can be used to modify the values that are returned from the “uname” command. As such, it is not possible to trust all of the information that these initial reconnaissance commands return. It is a good start.

which

The command, ‘which’ is used to find the location (path) of a program file if it exists in the user’s path. If the command being sought is not in the user path but is on the system, which will not return anything.

The ‘which’ command prints the full path of the executable (if found) to stdout. This is done by searching through the directories listed in the environment variable PATH belonging to the user. This process updates the access times of the files and directories searched.

Directory Commands

Directories are used to group files together in a hierarchical structure.

mkdir <directory_name>

This command creates a new directory

cd <directory_name>

The ‘cd’ command is used to change your location into a different directory. This allows you to display the file information in the directory with the ‘ls’ command. When a user logs into a Linux system, they will begin in their ‘home directory’.

(23)

Returning to one’s home directory is as simple as entering the ‘cd’ command without any other argument or options. The command ‘cd ..’ moves your one level higher in the directory hierarchy towards the root or ‘/’ directory.

pwd

Displays the current directory that you are in.

ff

The ‘ff’ command is used to find files on a Linux host. The ‘ff –p’ command has the benefit of not needing full name of the command being searched for. This command is similar to the command ‘find’ which is discussed in detail later.

grep <string_to_search> <filename>

The ‘grep’ command extracts, displays or simply finds strings within a file. The command performs searches based on regular expressions. There are a number of updated ‘grep’ programs including egrep and fgrep.

Finding out about other users on the system

These commands are used to find out about other users on a Linux host. When testing the security of a system covertly (such as when engaged in a penetration test) it is best to stop running commands when the system administrator is watching.

w

The ‘w’ command displays any user logged into the host and their activity. This is used to determine if a user is ‘idle’ or if they are actively monitoring the system.

who

The ‘who’ command is used to find which users are logged into the host as well as to display their source address and how they are accessing the host. The command will display if a user is logged into a local tty (more on this later) or is connecting over a remote network connection.

finger <user_name>

The ‘finger’ command is rarely used these days (but does come up from time to time on legacy and poorly configured systems). The command provides copious amounts of data about the user who is being “fingered”. This information includes the last time that user read their mail and any log in details.

last -1 <user_name>

The ‘last’ command can be used to display the “last” user to have logged on and off the host and their location (remote or local tty). The command will display a log of all recorded logins and log-offs if no options are used.

When the <user_name> option is provided, the command will display all of the user’s log-ins to the system. This is used when profiling a system administrator to discover the usual times that person will be logged into and monitoring a system.

whoami

This command displays the username that is currently logged into the shell or terminal session.

passwd <user_name>

The ‘passwd’ command is used to change your password (not options) or that of another user (if you have permissions to do so).

(24)

kill PID

This command “kills” any processes with the PID (process ID) given as an option. The ‘ps’ command (detailed later) is used to find the PID of a process.

This command can be used to stop a monitoring or other security process when testing a system. The ‘root’ user can stop any process, but other users on a host can only stop their own (or their groups) processes by default.

du <filename>

The ‘du’ command displays the disk usage (that is the space used on the drive) associated with the files and directories listed in the <filename> command option.

df

The ‘df’ command is used to disaplay the amount of free and used disk space on the system. This command displays this information for each mounted volume of the host.

Authentication and Validation

There are a variety of ways in which a user can authenticate in UNIX. The two primary differences involve authentication to the operating system against authentication to an application. In the case of an application such as a window manager (e.g. X-Window), authentication to the application is in fact authenticating to the operating system itself. Additionally, authentication may be divided into both local and networked authentication. In either case, the same applications may provide access to either the local or remote system. For instance, X-Window may be used both as a local window manager and as a means of accessing a remote UNIX system. Additionally, network access tools such as SSH provide the capability of connecting to a remote host but may also connect to the local machine by connecting to either its advertised IP address or the local host (127.0.0.1) address.

The UNIX authentication scheme is based on the /etc/passwd file. PAM (pluggable authentication modules) has extended this functionality and allowed for the integration of many other authentication schemes. Pam was first proposed by Sun Microsystems in 1995 and was integrated into Red Hat Linux the following year. Subsequently, PAM has become the mainstay authentication schema for Linux and many UNIX varieties. PAM has been standardized as a component of the X/Open UNIX standardization process.

This resulted in the X/Open Single Sign-on (XSSO) standard. From the assessor’s perspective, PAM However, necessitates a recovery mechanism that needs to be integrated into the operating system in case a difficulty develops in the linker or shared libraries. The assessor also needs to come to an understanding of the complete authentication and authorization methodology deployed on the system. PAM allows for single sign-on across multiple servers. Additionally, there are a large number of plug-ins to PAM that vary in their strength. It is important to assess the overall level of security provided by these and remember that the system is only as secure as the weakest link.

The fallback authentication method for any UNIX system lies with the /etc/passwd (password) file. In modern UNIX systems this will be coupled with a shadow file. The password file contains information about the user, the user ID (UID), the group ID (GID), a descriptor which is generally taken by the name, the user’s home directory and the users default shell.

root:x:0:0:root:/root:/bin/csh

bin:x:1:1:bin:/bin:/bin/sh

daemon:x:2:2:daemon:/sbin:/bin/noshell

adm:x:3:4:adm:/var/adm:/bin/noshell

lp:x:8:6:lp:/var/spool/lpd:/bin/noshell

cwright:x:500:50:wheel:/usr/home/csw:/bin/sync

User Password UID GID Name Home Directory

Shell

(25)

The user ID and group ID give the system the information needed to match access requirements. The home directory in the password file is the default directory that a user will be sent to in the case of an interactive login. The shell directive sets the initial shell assigned to the user on login. In many cases a user will be able to change directories or initiate an alternative shell, but this at least sets the initial environment. It is important to remember that the password file is generally world readable. In order to correlate user IDs to user names when looking at directory listings and process listings, the system requires that the password file the access to all (at least in read only mode) by all authenticated users.

The password field of the /etc/passwd file has a historical origin. Before the password and shadow files were split, hashes were stored in this file. To maintain compatibility, the same format has been used. In modern systems where the password and shadow files are split, an “x” is used to represent that the system has stored the password hashes in an alternative file. If there is a blank space instead of the “x” this represents that the account has no password.

The default shell may be a standard interactive shell, a custom script or application designed to limit the functionality of the user or even a false shell designed to restrict the use and stop interactive logins. False shells are generally used in the case of service accounts. This allows the account to login (such as in the case of “lp” for print services) and complete the task it is assigned. Additionally, users may be configured to run an application. A custom script could be configured to start the application allowing the user limited access to the system and to then log the user off the system when they exit the application. It is important for the assessor to check that breakpoints cannot be set allowing an interactive shell. Further, in the case of the application access, it is also important to check that the application does not allow the user to spawn an interactive shell if this is not desired. Either of these flaws may be exploited to gain deeper access to a system. As was mentioned above, the majority of modern Linux systems deploy a shadow file. This file is associated with the password file but unlike the password file should not be accessible (even to read) by the majority of users on the system. The format of this file is:

User Password_Hash Last_Changed Password Policy

This allows the system to match the user and other information in the shadow file to the password file. The password is in actuality a password hash. The reason that this should be protected comes to the reason that the file first came into existence. In the early versions of UNIX there were no shadow files. Being that the password file was world readable, a common attack was to copy the password file and use a dictionary to “crack” the password hashes. By splitting the password and shadow file, the password hash is not available to all users and thus it makes it more difficult for a user to attack the system. The password hash function always creates the same number of characters (this may vary from system to system based on the algorithm deployed, such as MD5, DES etc.).

Linux systems are characteristically configured to allow zero days between changes and 99,999 days between changes. In effect this means that the password policies are ineffective. The fields that exist in the shadow file are detailed below: • The username,

• The password Hash,

• The Number of days since 01 Jan 1970 that password was last changed, • The Number of days that must pass before password can be changed, • The Number of days after which password must be changed,

• The Number of days before expiration that the user is warned, • The Number of days after expiration that the account is disabled,

• The Number of days since 01 Jan 1970 that the account has been disabled.

Being that the hash function will always create a password hash of the same length, it is possible to restrict logins by changing the password hash variable in the shadow file. For instance, changing the password hash field to something like “No_login” will create a disabled account. As this string is less than the length of the password hash, no password hash could ever be created matching that string. So in this instance we have created an account that is not disabled but will not allow interactive logins.

PenTest OPEN eBook

Contents

A

Chapter 3: GPEN Study Guide

Outcome Statement

)

Key Questions

1.

Section 1: Pen-testing process

Outcome Statement

Key Questions

Section 2: Legal Issues

Outcome Statement

Key Questions

1.

Section 3: Reconnaissance

Outcome Statement

Introduction

Inventory

Whois

Web Reconnaissance

Metadata

DNS

Key Questions

Exercises

Section 4: Intro to Linux

Outcome Statement

Shell History

Basic UNIX commands

The Essential Commands

File Commands

Finding out about other users on the system

Authentication and Validation

root:x:0:0:root:/root:/bin/csh

bin:x:1:1:bin:/bin:/bin/sh

daemon:x:2:2:daemon:/sbin:/bin/noshell

adm:x:3:4:adm:/var/adm:/bin/noshell

lp:x:8:6:lp:/var/spool/lpd:/bin/noshell

cwright:x:500:50:wheel:/usr/home/csw:/bin/sync

Shell