Testing company A has conducted a series of penetration security tests directed at one IP address associated with a new investment web site built by company B.
The overall purpose of this activity was to evaluate the externally observable application and web server security configuration and thereby assist company Bs management in ascertaining the current level of conformance to network security policy.
Methodology
A profile of network security was accumulated through the use of specific and controlled security penetration and diagnostic methods. Specifically, the scope of the testing comprised of:
 | Phase 1 - Information retrieval |
| Phase 2 - Vulnerability testing of network services on specified components |
Phase 1 Information Retrieval
The first step of the analysis consisted of querying publicly available databases on the Internet for information regarding the specified company Bs system. To have a network presence on the Internet implies exposure since it is a public environment. This information may include names of employees, physical addresses, details regarding the internals network, IP-numbers and software or hardware used.
A profile or network map of the system listed above and other information was created of company B using widely available tools. This included identification by platform, operating system version and application,. This formed the basis of the selection of appropriate attack paths during phase 2.
Phase 2 Vulnerability Scan
The specified system address was programmatically scanned using a variety of commercial and publicly available network security assessment software. Such software is not used directly to compromise systems, but to identify vulnerabilities that are, or that may result in, a breach security policy. Typically this type of software seeks vulnerabilities that may be exploited to gain unauthorised high-level access to information systems and therefore must be updated daily with the latest list of possible vulnerabilities.
This section describes how phase 1 was performed
Public Information Queries were conducted against the whois databases, Arin, RIPE, ApNic, InterNic and other appropriate registries such as IP-indexes, domain search sites to discover domains and IP network ranges associated with the client. This was done without accessing any of company Bs systems.
Normal Known Traffic This step involves extracting information-using channels that will not differ from any normal Internet use, for example browsing company Bs available web sites, therefore should not create any alerts triggered by company Bs firewall or Intrusion Detection Software (IDS). Extracting information was achieved by connecting to know services such as HTTP, HTTPS and FTP, then downloading as much content as possible and searched the data collected for relevant information.
Host Enumeration This step evolves determining the IP address of potential targets on a network via the use of tools such as Icmpenum. Icmpenum uses not only ICMP Echo packets to probe networks, but also ICMP Timestamp and ICMP Information packets as well. Furthermore, it supports spoofing and promiscuous listening for reply packets. Icmpenum is used for enumerating networks who block ICMP Echo packets but have failed to block Timestamp or Information packet, or for upstream sniffing of trusted addresses.
Full Contact Enumeration Scanning was performed against the web site, which included TCP, UDP, stealth protool, RPC scanning as well as TCP-fingerprinting, fragmentation and reverse ident scanning. The scan also included banner grabbing and information gathering through services such as SNMP, finger, rusers, SMTP and NetBIOS.
The information gathered via the above methods is then used to identify the system types for vulnerability scanning during phase 2.
An e-Business site may be vulnerable to two main mechanisms of attack:
| Penetration unauthorised access to the system or its resources or to data held on the system |
| Denial of Service Where the system is flooded with traffic, preventing authorised users from normal work. This may be caused by a malicious attack, or be an indication of the vulnerability of the system to heavy loads or errors. |
A mixture of a commercial available automated scanning tool and specific exploitation techniques was used, such as techniques to exploit buffer overflows, race conditions, enhanced password cracking and denial of service attacks.
A checklist of possible vulnerabilities was then created. Below is an example of such a checklist derived from categories used by Security Focus
Checklist of Possible Vulnerabilities
Penetration
| Access Validation Faults |
 | a subject invokes an operation on an object outside its access domain |
| an error occurs as a result of reading or writing to/from a file or device outside a subject's access domain |
| an error results when an object accepts input from and unauthorised subject |
| an error results because the system failed to properly or completely authenticate a subject. |
| failure of user input checking results in component failure, incorrect operation and/or data leakage. |
| a user can bypass security checks e.g. by entering the URL of a web page nominally password protected |
| an intruder impersonates the identity of an authorised user (e.g. by adopting their network IP address) |
| Passive - an intruder obtains data from the system (e.g. passwords, security information, transaction details) by capturing network traffic. |
| Active - an intruder runs code on the system, enabling them to access data. (Trojan Horse) |
| A fault results from an interaction in a specific environment between functionally correct modules |
| A fault occurs only when a program is executed on a specific machine, under a particular configuration |
| A fault occurs because the operational environment is different from that for which the software was designed. |
| an unauthorised device can be inserted into the system allowing the intruder to obtain information and data. |
| A fault results because a system utility was installed with incorrect set-up parameters |
| A fault occurs by exploiting a system utility that was installed in the wrong place |
| A fault occurs because access permissions were incorrectly set on a utility such that it violated the security policy.(e.g. the utility allows a user to access parts of the system normally blocked to them) |
| the default configuration of a component places the component or system in an insecure state. (e.g. systems shipped with default passwords in place) |
| a fault occurs because a program failed to recognize syntactically incorrect input |
| a fault results when a module accepted extraneous input fields |
| a fault results when a module failed to handle missing input fields |
| a fault results because of a field-value correlation error. |
| an error manifests itself because the system failed to handle an exceptional condition generated by a functional module, device, or user input. |
| information relating to the configuration or build of a component is freely obtainable or obtainable through other errors. (e.g. error messages providing database structure) |
| a fault occurs when partially-modified data structures were observed by another process |
| a fault occurs because the code terminated with data only partially modified as part of some operation that should have been atomic. |
| a fault is exploited during a timing window between two operations. |
| it is possible to modify input data after validation of the data has taken place but prior to final submission. (e.g. in a two stage transition process where the validity of the data is checked after the first stage) |
| A fault results from inadequate or improper serialisation of operations. |
Denial of Service
| Data overload |
| The system is flooded with traffic, preventing authorised users from normal work. This may be caused by a malicious attack, or be an indication of the vulnerability of the system to heavy loads or errors. |
| Failure of a component to adequately check the length of received data (e.g. input data) prior to passing it to a small, fixed length buffer |
| Boundary Conditions |
| a process attempts to read or write beyond a valid address boundary |
| a system resource is exhausted |
| an error results from an overflow of a static-sized data structure (classic buffer overflow conditions). |
Completion of the Attack/Vulnerability Matrix (AVM)
Once the vulnerabilities have been identified, an Attack Vulnerability Matrix should be completed for both mechanisms of attack
Example: (This is a very basic example the final one should be more extensive)
Denial of Service AVM
Mechanisms |
Heavy traffic |
x |
|
X |
Malformed data |
|
x |
X |
|
Fragmented packets |
x |
x |
|
|
URL Flood |
x |
|
X |
|
Mail Flood |
x |
|
|
|
|
Data overload |
Buffer Overflow |
Boundary Conditions |
|
Vulnerabilities |
||||
Given the list of possible vulnerabilities from the Attack Vulnerability Matrix test cases were created to test for the presence of vulnerabilities in each of the components of the system. These test cases should cover all possible system configurations.
| Comment from Isabel Evans | Lots of
really useful information, needs to be transferred to the template agreed
at the last meeting.
Would be useful to have some test cases in the example. Useful to have the phased approach and the list of vulnerabilities - might be good to have (eventually :-) ) in the guidelines for the standard a generic list of vulnerabilities or a long example list and then in the example the specific vulnerabilities to be checked in this system. May be useful to set some acceptance criteria as part of the requirements for the example, perhaps based on ISO 9126 e.g to show the level of risk to be contained in the example system - as presumably the higher risk to the system, the greater effort spent on security testing and the higher the acceotance criteria are set. Example might be percentage of different types of vulnerability to be contained by the system security? Normal known traffic: Should the test cases be directed not only at confirming the firewall does check for access from the web site (which the example implies) but also at finding the places where the firewall does not check but should? For example a state transition test to show the ways that information moves from inside to outside the firewall and vice versa? Is there a place for using any review / inspection techniques? I am thinking here that e.g. in the UK the Data Protection Agency have rules about what is personal data and what may / may not be kept/kept public. So an inspection of the system rules against the DPA rules might show vulnerabilities/places of illegal access? Terminology - does some of the security terminology need to be in the glossary, or if not testing specific, explained in the example: Tools and techniques mentioned: are these freely available/shareware/owned? DO they need acknowledgement/sources in a table at the end? |
| Comment from Marco Giromini | Sorry
but I did not have enough time to make a detailed review.
Anyway I think it is good and I basically agree with it. |
| Comment from Margaret Edney | This
example needs some expansion. I accept this is a huge area to deal with.
The information retrieval section is quite informative and should help testers get an idea of how to start. The example starts off as a description of a penetration attack but the matrix only lists a few examples for DoS attacks. The penetration matrix is much harder! The vulnerability scan should help to populate the matrix. It is also important to check that any countermeasures for a penetration attack don't trigger a major DoS. There is nothing on any techniques used to derive the test cases (e.g. use of syntax testing to determine values that should be illegal and then creating packets with these values.) |