Penetration tests are conducted in a way where a professional security expert tries to launch attacks on a computer system looking for security weaknesses which could be used by a real hacker to get access to features and data the user is not authorised to get access to.
Normally a penetration test 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 is capable of going outside what these users are authorised to do. However, an alternative strategy is white box testing in which case the hacker actually checks the configuration and the source code. The latter is commonly used for military or very high security installations.
The goals of a penetration test are:
- Determine feasibility of any attack vectors as a mean 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 which from time to time defines the most common attack vectors and what tests can be done to reduce the risk of these vulnerabilities. The 10 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 proper 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 un-trusted 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 web sites, 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. Without an access control check or other protection, attackers can manipulate these references to access unauthorised data. 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 properly 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, as well as 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 need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorisation. Test for:|
|8||Cross-site request forgery||A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests 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. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. 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||Un-validated 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:|
At Gislen Software we use various means to reduce the risk of hacking in the way software is developed. Some risks can be fully mitigated by certain filters or certain methodologies. By keeping all the software updated other risks can be mitigated. Major remaining risks are when third-party components are used and these are vulnerable. Commonly used well-known third-party components are often updated frequently but less common ones may not be.
Sometimes vulnerabilities may be indirect. I.e. the same web server or the same domain or company runs some other application which is insecure and while it is not possible to hack the application directly from outside, it may be possible to hack another application and get access to the network and the place where files are stored for the application in question. 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 tests
A number of times clients have asked us to verify applications before pen-tests are to be conducted. We have mainly done this by 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 in the code or server configuration for vulnerabilities. The [black-box] penetration tester does not have that advantage and neither has a real hacker and hence by having this advantage we can often reduce the risk to a level where the risk is very low. The penetration test is then only a verification that we have not missed anything.
However, since we often only have access to a test environment there is always a risk that the real server is vulnerable in regards to setup or configuration and unless we are given full access to the live server it may be hard to fully secure the live environment.
Some types of risks are not application based, other infrastructure such as firewall, operating system, web server etc. are also assessed during a PEN-test, hence if we are asked to harden an application for pen-test this may not be sufficient to ensure that a pen-test does not find any vulnerabilities since the infrastructure itself may be vulnerable. This may include risks of DDOS attacks.
Some risks can also be mitigated by adding an application firewall (in particular injections but a lot of the OWASP 10 risks can actually be mitigated
This document has outlined how penetration tests are normally conducted, what the main risks are, which tools can be used and how we at Gislen Software develop and helps clients to secure their software applications in a way which should prepare for successful penetration tests.
The OWASP 10 table above is a compilation of the information in the following pages with some additional comments by us:
- https://www.owasp.org/index.php/Top_10_2013-Top_10 and
What tools are used for penetration tests?
Tests are often conducted with help of certain security tools, Wikipedia lists a number of these.
In addition to white-box testing ahead of penetration tests, we have sometimes used tools such as:
- NMAP (free) which is used to find open ports (https://nmap.org/)
- Cain & Abel – The URL for the tool is presently linked as insecure and some virus scanners will block it as insecure, while the tool itself is useful.
- THC Hydra
- Acunetix (commercial) – Cost of using Acunetix is $810 for a year. (http://www.acunetix.com/)
- Pure Hacking
- Torrid Networks
How are penetration tests conducted?
There is plenty of material available on how a penetration test can be conducted:
- Automated penetration test: http://www.coresecurity.com/conducting-penetration-testing-0
- http://www.softwaretestinghelp.com/penetration-testing-guide/ (includes how social engineering aspects can also be covered)
Application Firewalls which can be used to mitigate the risks:
While applications can and should be hardened ahead of penetration tests it is also possible to use application firewalls to mitigate some of the risks. The OWASP site lists a number of 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 web site includes a configuration guide for application firewalls:
- AQTRONIX WebKnight (Open Source),
- Qbik WinGate (Commercial),
- 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)