Penetration Testing Methodology

1.1. External and Internal Infrastructure Testing Overview

This assessment is carried out by conducting an infrastructure penetration test to evaluate the security of a computer system or network against current security best practices by simulating an attack from a malicious user or an attacker. This could be performed from the perspective of an Internet-based external attacker or a rogue employee or attacker who has successfully gained physical access to the company network.

An attacker can learn multiple ways about your network structure, components, and access controls. Using combinations of the following (and many more) methods, an experienced attacker can gain quick and intimate knowledge of your infrastructure.

1.1.1. Web banner grabbing:

Using an HTTP HEAD request, gathering information about a server, such as a vendor or version information and internal IP addresses, is possible. This information is useful for an attacker as it enables them to build a picture of the network structure.

1.1.2. DNS server querying:

A DNS query can be used to gain useful information for an attack. Using a tool such as NSLookup or Dig, a DNS server can be queried so that it will disclose details such as zone transfers (a listing of all the registered names in the network, required so that multiple servers have the same user data) and version (useful for an attacker working out the correct exploit for the server).

1.1.3. Vulnerability assessment:

Using a tool such as Nmap, an attacker can enumerate all ports associated with an IP address or range of addresses. This automated process brings back false positives (results that say something exists when it doesn’t.) The attacker can sift the results, assess what is fact and make educated guesses about how to build an attack plan. This is valuable because each port (usually) has a particular service associated with it. If a port associated with a vulnerable service is identified, an attacker can perform a focused attack based on exploits for that service.

1.1.4. Methodology Overview:

An infrastructure test is the nucleus of a penetration test. Five main activities (information gathering, port/service scanning, host discovery and identification, vulnerability testing and extended manual testing) explicitly show where security holes lie. Razorthorn Security infrastructure testing is conducted using the OSSTMM methodology. A scoping exercise must be performed to confirm the targets in scope to complete any penetration test.

A Razorthorn Security technical consultant would perform scans remotely over the Internet or visit the customer site and run both automated and manual scans. The consultants will gather information about the infrastructure from these scans, such as open ports and services, to understand the potential vulnerabilities.

Following this, the consultant will continue to fully map the network in scope, providing a more detailed understanding of how the network is designed and highlighting further vulnerabilities not discovered during the initial scans.

The final stage of an infrastructure penetration test will see the consultant attempt to exploit the vulnerabilities previously identified during the scanning phase. All results found by toolsets use, whether false positive or not, will be manually explored to their fullest extent. Any services that require authentication are checked manually for default usernames and password combinations. Brute force attempts are only attempted if account lockouts do not occur.

Connections will be made to all open TCP services to check how these services react and for banner information such as host types and version numbers. Version numbers of target services are checked against recent exploits that are unlikely to be addressed in vulnerability scanners.

Exploits are downloaded, compiled and executed where appropriate (after receiving the client’s permission) to confirm the level of risk. We will make every effort to ensure the client is provided with a complete representation of their external and Internal facing networks and associated risks. Any issues identified will have the appropriate recommended actions to be taken.

It should be noted that whilst Razorthorn Security does not run exploits or tools that are designed to cause a Denial of Service (DoS) condition, the very nature of penetration testing means that unusual traffic will be sent across corporate networks, which can, on occasion, affect network performance and availability. In the event of severe service degradation, Razorthorn Security provides a direct line of communication with the consultant performing the test so that it can be paused/stopped instantly.

1.1.5. Tools:

Below is an overview of the tools used at Razorthorn Security that are leveraged in conjunction with manual enumeration techniques to conduct both internal and external penetration testing and malicious user testing. It should be noted that this list is non-exhaustive and is provided as an illustration of the toolsets used by Razorthorn Security consultants. Only Razorthorn Security approved, well known and trusted tools are permitted for test use. All tools are tested in commercial and custom virtual labs against a wide range of vulnerable virtual machines that address common operating systems, applications and protocols faced in testing environments. Tools are thoroughly tested and only approved for use if they function as required and expected.

1.2. Web Application Testing Overview

Many web applications are now key drivers for business and if not properly secured, can lead to loss of sensitive information, brand defacement, denial of service and loss of revenue.  It is recommended that all web applications are tested at least once a year and after significant code changes. If security is built into the application at the development stage, applications are likely to be delivered more securely.

Inferior testing can rely on automated scanners, and their results can contain a high number of false positives and negatives.  Many web applications are now highly complex transactional sites, and an automated scanner cannot find many potential vulnerabilities. It is imperative that highly skilled manual testing is also conducted during a web application test. 

1.2.1. What is web application testing?

Most companies conduct at least a portion of their business online. This can range from a simple website to complex user driven applications holding large amounts of dynamic data and interacting with many external systems. Businesses and customers can be at risk if these applications are successfully attacked. This includes, but is not limited to:

• Loss of sensitive data such as user databases containing email addresses, passwords, addresses and so on.
• Brand damage, either through apparent defacement or more subtle attacks such as delivering malware to user’s machines through your site.
• Denial-of-service, preventing access to the site.
• Accessing other internal servers and networks after compromising an Internet-facing applications

Ultimately, these can all lead to loss of revenue and loss of reputation. Today, even relatively insignificant breaches are generating significant press coverage.

To thoroughly test modern web applications, it is essential that highly skilled and experienced web application security consultants are used. Purely automated scanning cannot provide good coverage of complex, user-driven applications and is prone to showing a large number of false positive and negative findings. Skilled manual testing ensures excellent coverage, drawing on the consultant’s experience to uncover deeply hidden issues.

1.2.2. Overview:

Razorthorn Security’s in depth application security test will provide you with the necessary assurance that your applications and supporting infrastructure have suitable security measures in place to help protect against the latest threats. All testing is conducted in line with current industry best practices and, in the case of application testing specifically, the guidance provided by OWASP (see https://www.owasp.org for more information).

Using years of experience, knowledge, and proven methodologies, Razorthorn Security will identify security issues within the applications. This includes (but will not be limited to) the following commonly found vulnerabilities:

• SQL Injection
• Cross-Site Scripting (XSS)
• Broken Authentication and Session Management
• Insecure Direct Object References
• Cross-Site Request Forgery (CSRF)
• Security Misconfiguration
• Insecure Cryptographic Storage
• Failure to Restrict URL Access
• Insufficient Transport Layer Protection
• Un-validated Redirects and Forwards

This list covers 90% of vulnerabilities discovered during a typical web application test. For more in-depth coverage, OWASP publishes a web application testing guide.

However, reliance solely on a source such as OWASP will lead to missed vulnerabilities. As a result, we combine our experience, techniques and tools to produce a hybrid testing methodology.

A summary of critical web application testing areas is stated below. This is a quick overview and only covers some aspects of testing that will be carried out.

1.2.3. Unvalidated Input:

A large proportion of serious vulnerabilities are the result of blindly trusting user input. For example, allowing a user to enter JavaScript into their biography (cross-site scripting), permitting SQL statements to be entered into search queries (SQL injection), or failing to verify that your site redirects to a genuine page once logged in (open redirects).

Even where validation, sanitising or filtering is in place, there are often tricks and techniques to circumvent the protection.

1.2.4. Cross-Site Request Forgery:

A CSRF attack tricks a logged on victim’s browser into sending a forged HTTP request to a vulnerable web application, including the victim’s session cookie and any other automatically included authentication information. The vulnerable application thinks these are legitimate requests from the victim.

For example, a crafted link could be sent to support staff, and when clicked, will attempt to change the attacker’s account from a normal user to an administrative user.

1.2.5. Broken Access Control:

Access control restrictions determine which actions authenticated users are allowed to perform in a web application. When not adequately enforced, an attacker can exploit these flaws to access other user’s accounts, view sensitive files, or use unauthorised functionality.

A prominent example of this is when an application has admin functionality that is only protected by the URL being obscure and hidden, e.g. www.mywebapp.com/admin1234/

Insecure direct object references (IDOR) are a more subtle but typical example. An attacker notes that their user account is visible using the URL http://www.mywebapp.com/users/3823/. By changing the numeric user ID at the end of the URL, they then find they can access other accounts.

1.2.6. Broken Authentication and Session Management:

A session token is an ideally long and random string sent with each request to uniquely identify and authenticate that user. It is provided after the user successfully authenticates using their username and password.

When session tokens are not adequately protected, attackers can exploit vulnerabilities, allowing them to hijack another user’s session. For example, if the session token is purely time-based, an attacker can obtain a valid session token and guess others until an exciting account is obtained.

1.2.7. Cross-Site Scripting (XSS) Flaws:

Modern browsers and web applications rely heavily on client-side scripting to deliver rich, responsive experiences. Most often, these scripts are written in JavaScript. An attacker can exploit various flaws in web applications to run their own JavaScript in a user’s browser.

Several attacks can be carried out once this has happened. The attacker could redirect the user to their site, hosting a convincing copy of the real login page and allowing them to harvest credentials. They could take the user’s session token, send it to their server, and then re-use it to hijack the user’s session. Or they could deliver malware onto your customer’s machines.

1.2.8. Buffer Overflows:

The programs that drive web applications are sometimes vulnerable to buffer overflows. Whilst the program is writing data into a buffer, it fails to check that the data will fit. The data is then written to an adjacent area of memory. An attacker can sometimes carefully craft input to overwrite specific memory locations and execute code on the server.

These flaws are prevalent in custom protocols, such as those used by embedded systems. Thankfully, modern development practices and operating systems protections have made buffer overflows increasingly uncommon.

1.2.9. Injection Flaws:

Web applications sometimes pass user input through to other processes or services. An obvious example is the search functionality on a website, where the keywords may be passed into a SQL query to return results. Alternatively, the site may perform DNS lookups using the command line tool “NSLookup” with the domain name appended to the end.

An attacker can inject commands into these other systems if user input needs to be adequately sanitised.

SQL injection is when an attacker can send SQL of their own through to the database server. Often, this allows them to access the entire web application database with the same level of privilege as the web application itself. Sometimes, an attacker can take control of the server if the database is incorrectly configured.

Code injection allows an attacker to carry out commands in the operating system, such as delete files, add users, and download and upload files. Often, this can lead to the attacker gaining total control of the web application server.

1.2.10. Insecure Storage:

Storing information, such as passwords and files, can be achieved using some form of cryptography. Integrating crypto into a web application can be complex, so there are often deficiencies in its execution. Information is only protected when the cryptographic function is coded correctly and integrated appropriately.

A prominent example of this is the plaintext storage of passwords. If your database is compromised, the attacker can quickly view all the passwords. Password reuse is expected even if you have forced your users to change their passwords in response to a breach, and the same credentials are likely to work on other sites.

1.2.11. Improper Error Handling:

In some instances, error conditions occur during normal operations and are not handled properly. If an attacker can identify the errors the web application does not operate correctly, they can systematically force them, revealing system information.

1.2.12. Denial of Service:

An attacker can survey an application to determine what processes use the most resources. With this knowledge, it is possible to consume web application resources to a point where other legitimate users can no longer access or use the application. In extreme cases, the application can be knocked over and cease functioning completely.

1.2.13. Web service/API testing Methodology:

Service-orientated applications are commonly used to enable business or end-user peers to interoperate for whichever purpose by exchanging data. These are usually provided for high-volume and low-interactivity transactions (can be automated or do not require a user interface). Clients to these services are often modules on server applications that connect to the serving endpoint to carry out their tasks.

Web services are specific cases of service-orientated applications that run on top of the HTTP protocol, similar to a web application.

In addition, various technologies such as JSON, REST, XML, SOAP, WSDL and UDDI handle tasks such as message formatting, data encoding and exporting the web service’s interface.

Techniques commonly employed in web applications are often applied to web services, such as authentication, session persistence and encryption via SSL/TLS tunnels.

From an attacker’s point of view, a web service is an interesting object because it can be a self-documented interface running on top of a well-known protocol that handles customer and business data.

Explaining a web service can ultimately allow an attacker to extract database data, including authentication credentials, tamper with stored data, compromise the web server (or the database server), or attack its clients. In parallel, all typical network-based attacks can be carried out against web services, including data theft and tampering via man-in-the-middle attacks.

Testing a web service requires thoroughly analysing exposed methods with the generic OWASP methodology in mind. The same base methodology is used to test web applications.

For web services, however, particular attention is given to JSON and XML structure error conditions, input validation faults (possibly leading to SQL injection), session handling issues, handling of encoding variations, susceptibility to replay attacks, access controls and information disclosure. The authentication layer is tested to establish its effectiveness and the risk and consequences of credential theft. The likelihood of data interception and tampering is directly related to implementing the service’s encryption layer.

It should also be noted that authentication layers implemented using the OAuth protocol are complex and could consume significant testing time.

Testing web services is, for the most part, a manual process whereby the tester is required to make sense of the web service’s functionality and attempt to disrupt the flow of information or provoke situations that the application fails to handle correctly, possibly leading to exploitation.

1.3. Mobile Application Testing Overview

Razorthorn Security in-depth mobile application security test will provide the necessary assurance that your applications have suitable security measures in place to help protect against the latest threats. All testing is conducted in line with current industry best practice and, in the case of mobile application testing specifically, the guidance provided by OWASP.

Using years of experience and knowledge, as well as proven methodologies, Razorthorn Security will focus on (but will not be limited to) the following;

• Assessment of the client/server communication between the app and server endpoint(s).
• The security posture of the exposed server endpoint(s).
• Mobile app best practices (mobile OWASP top ten).
• Static analysis of the native application .ipa and/or .apk files for iOS and Android respectively (testing for hardcoded passwords/APIs etc in the filesystem etc).
• Assessment of the application from a forensic perspective (i.e. whether anything security sensitive is stored on the device, and what the associated implications of recovery from a lost/stolen device are).