Penetration testing (often called a pen test) is conducted by a professional security expert who tries to launch attacks on a computer system. The expert seeks security weaknesses that a real hacker could exploit to access features and data that are inaccessible to the user.
Typically, penetration testing is done as a black box attack, where the security expert is not given access to the code or details of the server. Often, s/he is given a few user credentials to check if s/he can go beyond what these users are authorised to do. However, an alternative strategy is white box penetration testing, in which the hacker checks the configuration and the source code. The latter is commonly used for military or very high-security installations.
The goals of any penetration testing are:
- Determine the feasibility of any attack vectors as a means of getting unauthorised or enhanced access to features or data
- Identify high-risk vulnerabilities from a combination of lower-risk vulnerabilities exploited in a particular sequence
- Identify vulnerabilities that may be difficult or impossible to detect with automated network or application vulnerability scanning software.
- Assess the magnitude of potential business and operational impacts of successful attacks.
- Test the ability of network defenders to detect and respond to attacks
- Provide evidence to support increased investments in security personnel and technology
Attack vectors / OWASP 10
OWASP is a non-profit security organisation that periodically identifies the most common attack vectors and outlines penetration testing methods to mitigate these vulnerabilities. The ten most common attack vectors are called OWASP-10, and the last list was defined in 2013
| No | Vulnerability | Description/Tests to be conducted |
| 1 | Injection | Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without authorisation. Test for:
|
| 2 | Broken authentication and session management | Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens or to exploit other implementation flaws to assume other users’ identities. Test for:
|
| 3 | Cross-site scripting | XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface websites, or redirect the user to malicious sites. Test for:
|
| 4 | Insecure direct object reference | A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Attorneys can manipulate these references to access unauthorised data without an access control check or other protection. Test for:
|
| 5 | Wrong security configuration | Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. Test for:
|
| 6 | Sensitive data exposure | Many web applications do not adequately protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection, such as encryption at rest or in transit, and special precautions when exchanged with the browser. Test for:
|
| 7 | Missing function-level access control | Most web applications verify function-level access rights before making that functionality visible in the UI. However, applications must perform the same access control checks on the server when each function is accessed. Attackers can forge requests to access functionality without proper authorisation if requests are not verified. Test for:
|
| 8 | Cross-site request forgery | A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request to a vulnerable web application, including the victim’s session cookie and any other automatically included authentication information. This allows the attacker to force the victim’s browser to generate requests that the vulnerable application thinks are legitimate requests from the victim. Test for:
|
| 9 | Using components with known vulnerabilities | Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. Such an attack can facilitate severe data loss or server takeover if a vulnerable component is exploited. Applications using components with known vulnerabilities may undermine application defences and enable a range of possible attacks and impacts. (Heartbleed and Shellshock are examples). Test for:
|
| 10 | Unvalidated redirects and forwards | Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites or use forwards to access unauthorised pages. Test for:
|
Our strategy
At Gislen Software, we employ various measures to mitigate the risk of hacking in software development. Certain filters or specific methodologies can entirely reduce some risks. By keeping all the software updated, other risks can be mitigated. The significant remaining risks arise from the use of vulnerable third-party components. Commonly used, well-known third-party components are often updated frequently, but less common ones may not be.
Indirect vulnerabilities
Sometimes, vulnerabilities may be indirect. I.e., the same web server, domain, or company runs some other insecure application. Although it is impossible to hack the application directly from outside, it may be possible to hack another application and access the network where the application’s files are stored. One example of this is a hacker story of a person who managed to hack Facebook (he did this to get a bounty from Facebook, so this is legal, ethical hacking) –
Verifying and hardening applications ahead of penetration testing
Clients have often asked us to verify applications before penetration testing. We have mainly done this using white box verification against the list above. The advantage of preparing for a [black-box] pen test with a white-box test is that the white-box tester has an advantage by being able to check the code or server configuration for vulnerabilities. The [black-box] penetration tester does not have that advantage, and neither does a real hacker; hence, by having this advantage, we can often reduce the risk to a level where the risk is shallow. The penetration test only verifies that we have not missed anything.
However, since we often only have access to a test environment, there is always a risk that the actual server is vulnerable to setup or configuration. Unless we are given full access to the live server, it may be hard to secure the live environment fully.
Some types of risks are not application-based. Other infrastructure, such as firewalls, operating systems, web servers, etc., is also assessed during penetration testing. Hence, if we are asked to harden an application for a pen test, this may not be sufficient to ensure that penetration testing does not find any vulnerabilities ,since the infrastructure itself may be vulnerable. This may include risks of DDOS attacks.
Application firewalls
Adding an application firewall (particularly injections) can also mitigate some risks, but many OWASP 10 risks can also be mitigated.
Conclusion
This document outlines the typical process of penetration testing, identifies key risks, and explains the tools available. Additionally, it explains how Gislen Software develops and assists clients in securing their software applications, thereby preparing them for successful penetration testing.
References
The OWASP 10 table above is a compilation of the information on the following pages with some additional comments by us:
What tools are used for penetration testing?
Tests are often conducted with the help of specific security tools; Wikipedia lists several of these.
In addition to white-box testing ahead of penetration testing, we have sometimes used tools such as:
- NMAP (free), which is used to find open ports
- Nessus
- Metasploit
- Wireshark
- OpenSSL
- Cain & Abel—The URL for the tool is currently linked as insecure, and some virus scanners will block it as insecure. However, the tool itself is helpful.
- THC Hydra
- w3af
Commercial tools/services:
- Acunetix (commercial) – The cost of using Acunetix is $810 for a year.
- Pure Hacking
- Torrid Networks
- SecPoint
- Veracode
How is penetration testing conducted?
There is plenty of material available on how a penetration test can be conducted:
- Conducting Penetration test organisation
- Automated Penetration test
- Penetration testing guide
- Penetration Testing Guidance
- 5 tips for a successful penetration testing program
Application Firewalls, which can be used to mitigate the risks:
While applications can and should be hardened before penetration testing, application firewalls can also be used to mitigate some of the risks. The OWASP site lists several such application firewalls.
There is a long list of application firewalls or appliances. Here are some found in Wikipedia
Below is a list of various application firewalls and appliances running as plugins, boxes and load balancers or even in the cloud (as proxy servers)
OWASP website includes a configuration guide for application firewalls:
- AQTRONIX WebKnight (Open Source),
- Qbik WinGate (Commercial),
- Navilin
- Untangle (Commercial)
- Check Point (Commercial)
- Smoothwall (Open Source)
- Barracuda Networks Web Application Firewall/Load Balancer ADC (Commercial)
- A10 Networks Web Application Firewall (Commercial)
- Citrix Netscaler (Commercial)
- F5 ASM, Fortinet FortiWeb (Commercial)
- WatchGuard (Commercial)
- Imperva (Commercial)
- KEMP Technologies (Commercial)
- Penta Security (Commercial)
- Cloudbric (Commercial, but charges only based on traffic and only above 4GB / month)
- PIOLINK (Commercial)
- ProxyServerModSecurity package (Plugin for PFSense Open source firewall/ Linux-based)
Do you need help developing secure software or preparing for a pen test?
Do you need help with security testing, preparing for penetration testing, or developing secure software? Don’t hesitate to contact us at Gislen Software. We have experts with the necessary skills and experience. Whether you face technical challenges or need strategic guidance, we are here to help you reach your goals. Contact us today to discuss how we can support your needs!