OSSTMM 2.1 INTERNET TECHNOLOGY SECURITY TESTING
1. Logisitics and Controls
The purpose of this
module is to reduce false positives and false negatives by assuring proper adjustments are made to all testing
tools.
Expected Results
Testing bandwidth discrepancies
Packet loss for TCP
Packet loss for UDP
Packet loss for ICMP
Network routing problems
ISPs routing traffic and Transit Sellers
Tasks
Error Checking
1. Examine the route to the target network for packet loss using TCP
2. Examine the route to the target network for packet loss using UDP
3. Examine the route to the target network for packet loss using ICMP
4. Measure the rate of packet round-trip time using TCP
5. Measure TCP latency through TCP connections
6. Measure the rate of packet acceptance and response on the target network
7. Measure the amount of packet loss or connection denials at the target network
Routing
8. Examine the routing path to the targets from the attack system.
9. Examine the routing path for the target's ISPs.
10. Examine the routing path for the target ISPs primary Transit Sellers.
11. Examine the use of IPv6 to each live host in the network.
2. Network Surveying
A network survey serves often as an introduction to the systems to
be tested. It is best defined as a combination of data collection, information gathering, and policy control.
Although it is often advisable from a legal standpoint to define contractually exactly which systems to test if
you are a third-party auditor or even if you are the system administrator, you may not be able to start with concrete
system names or IP addresses. In this case you must survey and analyze. The point of this exercise is to find the
number of reachable systems to be tested without exceeding the legal limits of what you may test. Therefore the
network survey is just one way to begin a test; another way is to be given the IP range to test. In this module,
no intrusion is being performed directly on the systems except in places considered a quasi-public domain.
In legal terms, the quasi-public domain is a store that invites you in to make purchases. The store can control
your access and can deny certain individuals entry but for the most part is open to the general public (even if
it monitors them). This is the parallel to an e-business or web site.
Please bear in mind that the hosts discovered later may be inserted in the testing as a subset of the defined testing
and often only with permission or collaboration with the target organization's internal security team.
Expected Results
Domain Names
Server Names
IP Addresses
Network Map
ISP / ASP information
System and Service Owners
Possible test limitations
Tasks
Name server responses.
1. Examine Domain registry information for servers.
2. Find IP block owned.
3. Question the primary, secondary, and ISP name servers for hosts and sub domains.
4. Find IPv6 IP blocks in use though DNS queries.
Examine the outer wall of the network.
5. Use multiple traces to the gateway to define the outer network
layer and routers.
Examine tracks from the target organization.
6. Search web logs and intrusion logs for system trails from the
target network.
7. Search board and newsgroup postings for server trails back to the target network.
Information Leaks
8. Examine target web server source code and scripts for application
servers and internal links.
9. Examine e-mail headers, bounced mails, and read receipts for the server trails.
10. Search newsgroups for posted information from the target.
11. Search job databases and newspapers for IT positions within the organization relating to hardware and software.
12. Search P2P services for connections into the target network and data concerning the organization.
3. System Services Identification
Port scanning is the invasive probing of system ports on the transport
and network level. Included here is also the validation of system reception to tunneled, encapsulated, or routing
protocols. This module is to enumerate live or accessible Internet services as well as penetrating the firewall
to find additional live systems. The small sample of protocols here is for clarity of definition. Many protocols
are not listed here. Testing for different protocols will depend on the system type and services it offers. For
a more complete list of protocols, see the Test References section.
Each Internet enabled system has 65,536 TCP and UDP possible ports (incl. Port 0). However, it is not always necessary
to test every port for every system. This is left to the discretion of the test team. Port numbers that are important
for testing according to the service are listed with the task. Additional port numbers for scanning should be
taken from consensus intrusion database project sites such as www.dshield.org.
Once open ports have been identified, it is necessary to conduct an active examination of the application listening
behind the service. In certain cases more than one application exists behind a service where one application is
the listener and the others are considered components of the listening application. A good example of this is PERL
installed for use in a Web application. In that case the listening service is the HTTP daemon and the component
is PERL.
After service identification, the next step is to identify the system through the active probing of a system for
responses that can distinguish its operating system and version level.
Expected Results
Open, closed or filtered ports
IP addresses of live systems
Internal system network addressing
List of discovered tunneled and encapsulated protocols
List of discovered routing protocols supported
Active servicesService Types
Service Application Type and Patch Level
OS TypePatch Level
System Type
List of live systems
Internal system network addressing
Network Map
Tasks
Enumerate Systems
1. Collect broadcast responses from the network
2. Probe past the firewall with strategically set packet TTLs (Firewalking) for all IP addresses.
3. Use ICMP and reverse name lookups to determine the existence of all the machines in a network.
4. Use a TCP source port 80 and ACK on ports 3100-3150, 10001-10050, 33500-33550, and 50 random ports above 35000
for all hosts in the network.
5. Use TCP fragments in reverse order with FIN, NULL, and XMAS scans on ports 21, 22, 25, 80, and 443 for all hosts
in the network.
6. Use a TCP SYN on ports 21, 22, 25, 80, and 443 for all hosts in the network.
7. Use DNS connect attempts on all hosts in the network.
8. Use FTP and Proxies to bounce scans to the inside of the DMZ for ports 22, 81, 111, 132, 137, and 161 for all
hosts on the network.
Enumerating Ports
9. Use TCP SYN (Half-Open) scans to enumerate ports as being open,
closed, or filtered on the default TCP testing ports for all the hosts in the network.
10. Use TCP full connect scans to scan all ports up to 1024 on all hosts in the network.
11. Use TCP fragments in reverse order to enumerate ports and services for the subset of ports on the default Packet
Fragment testing ports in Appendix B for all hosts in the network.
12. Use UDP scans to enumerate ports as being open or closed on the default UDP testing ports if UDP is NOT being
filtered already. [Recommended: first test the packet filtering with a small subset of UDP ports.]
Verifying Various Protocol Response
13. Verify and examine the use of traffic and routing protocols.
14. Verify and examine the use of non-standard protocols.
15. Verify and examine the use of encrypted protocols.
16. Verify and examine the use of TCP and ICMP over IPv6.
Verifying Packet Level Response
17. Identify TCP sequence predictability.
18. Identify TCP ISN sequence numbers predictability.
19. Identify IPID Sequence Generation predictability.
20. Identify system up-time.
Identifying Services
21. Match each open port to a service and protocol.
22. Identify server uptime to latest patch releases.
23. Identify the application behind the service and the patch level using banners or fingerprinting.
24. Verify the application to the system and the version.
25. Locate and identify service remapping or system redirects.
26. Identify the components of the listening service.
27. Use UDP-based service and Trojan requests to all the systems in the network.
Identifying Systems
28. Examine system responses to determine operating system type
and patch level.
29. Examine application responses to determine operating system type and patch level.
30. Verify the TCP sequence number prediction for each live host on the network.
31. Search job postings for server and application information from the target.
32. Search tech bulletin boards and newsgroups for server and application information from the target.
33. Match information gathered to system responses for more accurate results.
4. Competitive Intelligence Review
CI Scouting is the scavenged information from an Internet presence
that can be analyzed as business intelligence. Different than the straight-out intellectual property theft found
in industrial espionage or hacking, CI tends to be non-invasive and much more subtle. It is a good example of how
the Internet presence extends far beyond the hosts in the DMZ. Using CI in a penetration test gives business value
to the components and can help in finding business justifications for implementing various services.
Expected Results
A measurement of the organization's network business justifications
Size and scope of the Internet presence
A measurement of the security policy to future network plans
Tasks
Business Intelligence
1. Map and measure the directory structure of the web servers
2. Map the measure the directory structure of the FTP servers
3. Examine the WHOIS database for business services relating to registered host names
4. Determine the IT cost of the Internet infrastructure based on OS, Applications, and Hardware.
5. Determine the cost of support infrastructure based on regional salary requirements for IT professionals, job
postings, number of personnel, published resumes, and responsibilities.
6. Measure the buzz (feedback) of the organization based on newsgroups, web boards, and industry feedback sites
7. Record the number of products being sold electronically (for download)
8. Record the number of products found in P2P sources, wares sites, available cracks up to specific versions, and
documentation both internal and third party about the products
9. Identify the business partners
10. Identify the customers from organizations to industry sectors
11. Verify the clarity and ease of use of the merchandise purchasing process
12. Verify the clarity and ease of use for merchandise return policy and process
13. Verify that all agreements made over the Internet from digital signature to pressing a button which signifies
acceptance of an end-user agreement can be repudiated immediately and for up to 7 days.
5. Privacy Review
The privacy review is the focal point of the legal and ethical storage, transmission, and control of data based
on employee and customer privacy. The use of this data is a concern to many private persons and legislation is
unveiling specific rules regarding privacy. Although some of these laws are local, all of them apply to the Internet
and therefore affect security testers internationally.
In these tests, it is required to understand the difference between personal and private information: Private
information is information which is generally only known to the persons themselves and the authority who collected
that data. This could be university transcripts, amount of money given to the church, names of ex-girlfriends
or ex-boyfriends, and perhaps an embarrassing childhood memory. Personal information is information that describes
a person or a person's lifestyle such as birth date, hair color, age, names of members in the family, the bank
they use, their pets' names, gender, sexual preferences, religion, or favorite color.
Additionally, personally identifiable information is information that a person's identity can be derived from whether
alone or in aggregate. This could be a person's name or government ID number.
Expected Results
List any disclosures
List compliance failures between public policy and actual practice
List systems involved in data gathering
List data gathering techniques
List data gathered
Tasks
Policy
1. Identify public privacy policy
2. Identify web-based forms
3. Identify database type and location for storing data
4. Identify data collected by the organization
5. Identify storage location of data
6. Identify cookie types
7. Identify cookie expiration times
8. Identify information stored in cookie
9. Verify cookie encryption methods
10. Identify the clarity of opt-out information
11. Identify the ease of use for opt-out
12. Identify beacon gifs (web bugs) in web services and e-mails
13. Identify server location of beacon gifs
14. Identify web bug data gathered and returned to server
False Light and Defamation
15. Identify fictionalized persons, organizations, institutions
with real persons.
16. Identify persons or organizations portrayed in a negative manner.
Appropriation
17. Identify persons, organizations, or materials which as themselves or of a likeness thereof which is used for
commercial reasons as in web sites or advertisements.
Disclosure of Private Facts
18. Identify information about employees persons, organizations,
or materials which contain private information.
6. Document Grinding
The module here is important in the verification of much of the tested
information and pertains to many levels of what is considered information security. The amount of time granted
to the researching and extraction of information is dependent upon the size of the organization, the scope of the
project, and the length of time planned for the testing. More time however, does not always mean more information
but it can eventually lead to key pieces of the security puzzle.
Expected Results
A profile of the organization
A profile of the employees
A profile of the organization's network
A profile of the organization's technologies
A profile of the organization's partners, alliances, and strategies
Tasks
1. Examine web databases and caches concerning the target organization
and key people.
2. Investigate key persons via personal homepages, published resumes, organizational affiliations, directory enquiries,
companies house data, and electoral register.
3. Compile e-mail addresses from within the organization and personal e-mail addresses from key people.
4. Search job databases for skill sets technology hires need to possess in the target organization.
5. Search newsgroups for references to and submissions from within the organization and key people.
6. Search documents for hidden codes or revision data.
7. Examine P2P networks for references to and submissions from within the organization and key people.
7. Vulnerability Research and Verification
The focus of this module is in the identification, understanding, and
verification of weaknesses, misconfigurations and vulnerabilities within a host or network.
Research involved in finding vulnerabilities is necessary up until the delivery of the report. This involves searching
online databases and mailing lists specific to the systems and network being tested. Do not confine yourself to
the web, consider using IRC, Newsgroups, and underground FTP sites.
Testing for vulnerabilities using automated tools is an efficient way to determine existing holes and system patch
level. Although many automated scanners are currently on the market and in the underground, it is important for
the tester to identify and incorporate the current underground scripts/exploits into this testing. However, manual
verification is necessary for eliminating false positives, expanding the hacking scope, and discovering the data
flow in and out of the network. Manual testing refers to a person or persons at the computer using creativity,
experience, and ingenuity to test the target network.
Expected Results
Type of application or service by vulnerability
Patch levels of systems and applications
List of possible denial of service vulnerabilities
List of areas secured by obscurity or visible access
List of actual vulnerabilities minus false positives
List of Internal or DMZ systems
List of mail, server, and other naming conventions
Network map
Tasks
1. Integrate the currently popular scanners, hacking tools, and exploits
into the tests.
2. Measure the target organization against the currently popular scanning tools.
3. Attempt to determine vulnerability by system and application type.
4. Attempt to match vulnerabilities to services.
5. Attempt to determine application type and service by vulnerability.
6. Perform redundant testing with at least 2 automated vulnerability scanners.
7. Identify all vulnerabilities according to applications.
8. Identify all vulnerabilities according to operating systems.
9. Identify all vulnerabilities from similar or like systems that may also affect the target systems.
10. Verify all vulnerabilities found during the exploit research phase for false positives and false negatives.
11. Verify all positives (be aware of your contract if you are attempting to intrude or might cause a denial of
service).
8. Internet Application Testing
An Internet application test employs different software testing techniques
to find "security bugs" in server/client applications of the system from the Internet. In this module,
we refer the server/client applications to those proprietarily developed by the system owners serving dedicate
business purposes and the applications can be developed with any programming languages and technologies. E.g. web
application for business transactions is a target in this module. "Black box" and/or "White box"
testing can be used in this module.
Expected Results
List of applications
List of application components
List of application vulnerabilities
List of application system trusts
Tasks
Re-Engineering
1. Decompose or deconstruct the binary codes, if accessible.
2. Determines the protocol specification of the server/client application.
3. Guess program logic from the error/debug messages in the application outputs and program behaviors/performance.
Authentication
4. Find possible brute force password guessing access points in the applications.
5. Find a valid login credentials with password grinding, if possible.
6. Bypass authentication system with spoofed tokens.
7. Bypass authentication system with replay authentication information.
8. Determine the application logic to maintain the authentication sessions - number of (consecutive) failure logins
allowed, login timeout, etc.
9. Determine the limitations of access control in the applications - access permissions, login session duration,
idle duration.
Session Management
10. Determine the session management information - number of concurrent
sessions, IP-based authentication, role-based authentication, identity-based authentication, cookie usage, session
ID in URL encoding string, session ID in hidden HTML field variables, etc.
11. Guess the session ID sequence and format
12. Determine the session ID is maintained with IP address information; check if the same session information can
be retried and reused in another machine.
13. Determine the session management limitations - bandwidth usages, file download/upload limitations, transaction
limitations, etc.
14. Gather excessive information with direct URL, direct instruction, action sequence jumping and/or pages skipping.
15. Gather sensitive information with Man-In-the-Middle attacks.
16. Inject excess/bogus information with Session-Hijacking techniques.
17. Replay gathered information to fool the applications.
Input Manipulation
18. Find the limitations of the defined variables and protocol
payload - data length, data type, construct format, etc.
19. Use exceptionally long character-strings to find buffer overflows vulnerability in the applications.
20. Concatenate commands in the input strings of the applications.
21. Inject SQL language in the input strings of database-tired web applications.
22. Examine "Cross-Site Scripting" in the web applications of the system.
23. Examine unauthorized directory/file access with path/directory traversal in the input strings of the applications.
24. Use specific URL-encoded strings and/or Unicode-encoded strings to bypass input validation mechanisms of the
applications.
25. Execute remote commands through "Server Side Include".
26. Manipulate the session/persistent cookies to fool or modify the logic in the server-side web applications.
27. Manipulate the (hidden) field variable in the HTML forms to fool or modify the logic in the server-side web
applications.
28. Manipulate the "Referrer", "Host", etc. HTTP Protocol variables to fool or modify the logic
in the server-side web applications.
29. Use illogical/illegal input to test the application error-handling routines and to find useful debug/error
messages from the applications.
Output Manipulation
30. Retrieve valuable information stored in the cookies
31. Retrieve valuable information from the client application cache.
32. Retrieve valuable information stored in the serialized objects.
33. Retrieve valuable information stored in the temporary files and objects.
Information Leakage
34. Find useful information in hidden field variables of the HTML
forms and comments in the HTML documents.
35. Examine the information contained in the application banners, usage instructions, welcome messages, farewell
messages, application help messages, debug/error messages, etc.
9. Routing
The Screening Router is a defense often found on a network that restricts
the flow of traffic between the enterprise network and the Internet. It operates on a security policy and uses
ACL's (Access Control Lists) to accept or deny packets. This module is designed to assure that only that which
should be expressly permitted be allowed into the network; all else should be denied. The screen may also be designed
to restrict the outflow of certain types of traffic as well. Routers are becoming more and more complex and some
may have features unknown to the tester and often the target organization. The tester's role is in part to determine
the role of the router in the DMZ.
Expected Results
Router type and features implemented
Information on the router as a service and a system
Outline of the network security policy by the ACL
List of the types of packets which may enter the network
Map of router responses to various traffic types
List of live systems found
Tasks
Router and feature identification
1. Verify the router type with information collected from intelligence gathering.
2. Verify if the router is providing network address translation (NAT)
3. Verify the penetrations from strategically determined packet TTL settings (Firewalking) completed in the Port
Scanning module.
Verifying router ACL configuration
4. Test the ACL against the written security policy or against
the "Deny All" rule.
5. Verify that the router is egress filtering local network traffic
6. Verify that the router is performing address spoof detection
7. Verify the penetrations from inverse scanning completed in the Port Scanning module.
8. Test the router outbound capabilities from the inside.
9. Measure the ability of the router to handle very small packet fragments
10. Measure the ability of the router to handle over-sized packets
11. Measure the ability of the router to handle overlapped fragments such as that used in the TEARDROP attack
10. Trusted Systems Testing
The purpose of testing system trusts is to affect the Internet presence
by posing as a trusted entity of the network. The testing scenario is often more theory than fact and does more
than blur the line between vulnerability testing and Firewall/ACL testing, it is the line.
Expected Results
Map of systems dependent upon other systems
Map of applications with dependencies to other systems
Types of vulnerabilities which affect the trusting systems and applications
Tasks
1. Verify possible relationships determined from intelligence gathering,
application testing, and services testing.
2. Test the relationships between various systems through spoofing or event triggering.
3. Verify which systems can be spoofed.
4. Verify which applications can be spoofed.
11. Access Control Testing
The firewall controls the flow of traffic between the enterprise network,
the DMZ, and the Internet. It operates on a security policy and uses ACL's (Access Control Lists). This module
is designed to assure that only that which should be expressly permitted be allowed into the network, all else
should be denied. Additionally, the tester is to understand the configuration of the firewall and the mapping
it provides through to the servers and services behind it.
Reviewing the server logs is needed to verify the tests performed on the Internet presence especially in cases
where results of the tests are not immediately visible to the tester. Many unknowns are left to the analyst who
has not reviewed the logs.
Expected Results
Information on the firewall as a service and a system
Information on the features implemented on the firewall
Outline of the network security policy by the ACL
List of the types of packets which may enter the network
List of the types of protocols with access inside the network
List of live systems found
List of packets which entered the network by port number
List of protocols which entered the network
List of unmonitored paths into the network
Tasks
Firewall and features identification
1. Verify the router type with information collected from intelligence
gathering.
2. Verify if the router is providing network address translation (NAT)
3. Verify the penetrations from strategically determined packet TTL settings (Firewalking) completed in the Port
Scanning module.
Verifying firewall ACL configuration
4. Test the ACL against the written security policy or against
the "Deny All" rule.
5. Verify that the firewall is egress filtering local network traffic
6. Verify that the firewall is performing address spoof detection
7. Verify the penetrations from inverse scanning completed in the Port Scanning module.
8. Test the firewall outbound capabilities from the inside.
9. Determine the success of various packet response fingerprinting methods through the firewall
10. Verify the viability of SYN stealth scanning through the firewall for enumeration
11. Measure the use of scanning with specific source ports through the firewall for enumeration
12. Measure the ability of the firewall to handle overlapped fragments such as that used in the TEARDROP attack
13. Measure the ability of the firewall to handle tiny fragmented packets
14. Test the firewall's ability to manage an ongoing series of SYN packets coming in (flooding).
15. Test the firewall's response to packets with the RST flag set.
16. Test the firewall's management of standard UDP packets.
17. Verify the firewall's ability to screen enumeration techniques using ACK packets.
18. Verify the firewall's ability to screen enumeration techniques using FIN packets.
19. Verify the firewall's ability to screen enumeration techniques using NULL packets.
20. Verify the firewall's ability to screen enumeration techniques measuring the packet window size (WIN).
21. Verify the firewall's ability to screen enumeration techniques using all flags set (XMAS).
22. Verify the firewall's ability to screen enumeration techniques using IPIDs.
23. Verify the firewall's ability to screen enumeration techniques using encapsulated protocols.
24. Measure the robustness of firewall and it's susceptibility to denial of service attacks with sustained TCP
connections.
25. Measure the robustness of firewall and it's susceptibility to denial of service attacks with temporal TCP connections.
26. Measure the robustness of firewall and it's susceptibility to denial of service attacks with streaming UDP.
27. Measure the firewall's response to all types of ICMP packets.
Reviewing firewall logs
28. Test the firewall logging process.
29. Verify TCP and UDP scanning to server logs.
30. Verify automated vulnerability scans.
31. Verify services' logging deficiencies.
12. Intrusion Detection System Testing
This test is focused on the performance and sensitivity of an IDS.
Much of this testing cannot be properly achieved without access to the IDS logs. Some of these tests are also subject
to attacker bandwidth, hop distance, and latency that will affect the outcome of these tests.
Reviewing the server logs is needed to verify the tests performed on the Internet presence especially in cases
where results of the tests are not immediately visible to the tester. Many unknowns are left to the analyst who
has not reviewed the logs and alerts.
Expected Results:
Type of IDS
Note of IDS performance under heavy load
Type of packets dropped or not scanned by the IDS
Type of protocols dropped or not scanned by the IDS
Note of reaction time and type of the IDS
Note of IDS sensitivity
Rule map of IDS
List of IDS false positives
List of IDS missed alarms
List of unmonitored paths into the network
Tasks
IDS and features identification
1. Verify the IDS type with information collected from intelligence
gathering.
2. Determine its sphere of protection or influence.
3. Test the IDS for alarm states.
4. Test the signature sensitivity settings over 1 minute, 5 minutes, 60 minutes, and 24 hours.
Testing IDS configuration
5. Test the IDS for configured reactions to multiple, varied attacks
(flood and swarm).
6. Test the IDS for configured reactions to obfuscated URLs and obfuscated exploit payloads.
7. Test the IDS for configured reactions to speed adjustments in packet sending.
8. Test the IDS for configured reactions to random speed adjustments during an attack.
9. Test the IDS for configured reactions to random protocol adjustments during an attack.
10. Test the IDS for configured reactions to random source adjustments during an attack.
11. Test the IDS for configured reactions to source port adjustments.
12. Test the IDS for the ability to handle fragmented packets.
13. Test the IDS for the ability to handle specific system method attacks.
14. Test the effect and reactions of the IDS against a single IP address versus various addresses.
Reviewing IDS logs and alerts
15. Match IDS alerts to vulnerability scans.
16. Match IDS alerts to password cracking.
17. Match IDS alerts to trusted system tests.
13. Containment Measures Testing
The containment measures dictate the handling of traversable, malicious
programs and egressions. The identification of the security mechanisms and the response policy need to be targeted.
It may be necessary to request first a new test mail account or desktop system that the administrator can monitor.
Expected Results
Define Anti-Trojan Capabilities
Define Anti-Virus Capabilities
Identify Desktop Containment Measures
Identify Desktop Containment Weaknesses
List containment resources
Tasks
1. Measure the minimum resources that need to be available to this subsystem
in order for it to perform its task.
2. Verify the resources available to this subsystem that it does not need to perform its tasks, and what resources
are shielded from use by this subsystem.
3. Verify the detection measures present for the detection of attempted access to the shielded resources.
4. Verify unneeded resources
5. Verify the features of the containment system.
6. Verify detection measures are present for detection of 'unusual' access to the 'needed' resources
7. Measure the response and process against the "sap 27" (see page 123 in the OSSTMM for the list).
8. Measure the configuration of the system.
14. Password Cracking
Password cracking is the process of validating password strength through
the use of automated password recovery tools that expose either the application of weak cryptographic algorithms,
incorrect implementation of cryptographic algorithms, or weak passwords due to human factors. This module should
not be confused with password recovery via sniffing clear text channels, which may be a more simple means of subverting
system security, but only due to unencrypted authentication mechanisms, not password weakness itself. [Note: This
module could include manual password guessing techniques, which exploits default username and password combinations
in applications or operating systems (e.g. Username: System Password: Test), or easy-to-guess passwords resulting
from user error (e.g. Username: joe Password: joe). This may be a means of obtaining access to a system initially,
perhaps even administrator or root access, but only due to educated guessing. Beyond manual password guessing with
simple or default combinations, brute forcing passwords for such applications as Telnet, using scripts or custom
programs, is almost not feasible due to prompt timeout values, even with multi-connection (i.e. simulated threading)
brute force applications.]
Once gaining administrator or root privileges on a computer system, password cracking may assist in obtaining access
to additional systems or applications (thanks to users with matching passwords on multiple systems) and is a valid
technique that can be used for system leverage throughout a security test. Thorough or corporate-wide password
cracking can also be performed as a simple after-action exercise and may highlight the need for stronger encryption
algorithms for key systems storing passwords, as well as highlight a need for enforcing the use of stronger user
passwords through stricter policy, automatic generation, or pluggable authentication modules (PAMs).
Expected Results
Password file cracked or uncracked
List of login IDs with user or system passwords
List of systems vulnerable to crack attacks
List of documents or files vulnerable to crack attacks
List of systems with user or system login IDs using the same passwords
Tasks
1. Obtain the password file from the system that stores usernames and passwords
2· For Unix systems, this will be either /etc/passwd or /etc/shadow
3· For Unix systems that happen to perform SMB authentication, you can find NT passwords in /etc/smbpasswd
4· For NT systems, this will be /winnt/repair/Sam._ (or other, more difficult to obtain variants)
5. Run an automated dictionary attack on the password file
6. Run a brute force attack on the password file as time and processing cycles allow
7. Use obtained passwords or their variations to access additional systems or applications
8. Run automated password crackers on encrypted files that are encountered (such as PDFs or Word documents) in
an attempt to gather more intelligence and highlight the need for stronger document or file system encryption.
9. Verify password aging.
15. Denial of Service Testing
Denial of Service (DoS) is a situation where a circumstance, either
intentionally or accidentally, prevents the system from functioning as intended. In certain cases, the system may
be functioning exactly as designed however it was never intended to handle the load, scope, or parameters being
imposed upon it.
It is very important that DoS testing receives additional support from the organization and is closely monitored.
Flood and Distributed (DDoS) attacks are specifically not tested and forbidden to be tested as per this manual.
Well resourced floods and DDoS attacks will ALWAYS cause certain problems and often not just to the target but
also to all routers and systems between the tester and the target.
Expected Results
List weak points in the Internet presence including single points of failure
Establish a baseline for normal use
List system behaviors to heavy use
List DoS vulnerable systems
Tasks
1. Verify that administrative accounts and system files and resources are
secured properly and all access is granted with "Least Privilege".
2. Check the exposure restrictions of systems to non-trusted networks
3. Verify that baselines are established for normal system activity
4. Verify what procedures are in place to respond to irregular activity.
5. Verify the response to SIMULATED negative information (propaganda) attacks.
6. Test heavy server and network loads.
16. Security Policy Review
The security policy noted here is the written human-readable policy document outlining the mitigated risks an organization
will handle with the use of specific types of technologies. This security policy may also be a human readable form
of the ACL's. There are two functions to be performed: first, the testing of the written against the actual state
of the Internet presence and other non internet related connections; and second, to assure that the policy exists
within the business justifications of the organization, local, federal and international legal statutes, with particular
respect to employer's and employee's rights and responsibilities and personal privacy ethics.
These tasks require that the testing and verification of vulnerabilities is completely done and that all other
technical reviews have been performed. Unless this is done you can't compare your results with the policy that
should be met by measures taken to protect the operating environment.
Tasks
1. Measure the security policy points against the actual state of the Internet
presence.
2. Approval from Management -- Look for any sign (e.g. signature) that reveals that the policy is approved by management.
Without this approval the policy is useless because staff is not required to meet the rules outlined within. From
a formal point of view you could stop investigating the policy if it is not approved by management. However, testing
should continue to determine how effective the security measures are on the actual state of the internet presence.
3. Assure that the documentation is stored appropriately- electronically or otherwise, that the policy has been
read and accepted by people before they are able to gain any access to the computer systems.
4. Identify incident handling procedures, to ensure that breaches are handled by the correct individual(s) and
that they are reported in an appropriate manner.
5. Inbound connections -- Check out any risks mentioned on behalf of the Internet inbound connections (internet->DMZ,
internet -> internal net) and measures which may be required to be implemented to reduce or eliminate those
risks. These risks could be allowed on incoming connections, typically SMTP, POP3,HTTP, HTTPS, FTP, VPNs and the
corresponding measures as authentication schemes, encryption and ACL. Specifically, rules that deny any stateful
access to the internal net are often not met by the implementation.
6. Outbound connections -- Outbound connections could be between internal net and DMZ, as well as between internal
net and the Internet. Look for any outbound rules that do not correspond to the implementation. Outbound connections
could be used to inject malicious code or reveal internal specifics.
7. Security measures -- Rules that require the implementation of security measures should be met. Those could be
the use of AVS, IDS, firewalls, DMZs, routers and their proper configuration/implementation according to the outlined
risks to be met.
8. Measure the security policy points against the actual state of non-Internet connections.
9. Modems -- There should be a rule indicating that the use of modems that are not specially secured is forbidden
or at least only allowed if the modems are disconnected when not in use, and configured to disallow dial- in.
Check whether a corresponding rule exists and whether the implementation follows the requirements.
10. Fax machines -- There should be a rule indicating that the use of fax machines which can allow access from
the outside to the memory of the machines is forbidden or at least only allowed if the machines are powered down
when not in use. Check whether a corresponding rule exists and whether the implementation follows the requirements.
11. PBX -- There should be a rule indicating that the remote administration of the PBX system is forbidden or at
least only allowed if the machines are powered down when not in use. Check whether a corresponding rule exists
and whether the implementation follows the requirements.
12. Measure the security policy against containment measures and social engineering tests based on the organization's
employees' misuse of the Internet according to business justification and best security practices.
TEAM ACCESS