Penetration Tests and Data Security

penetration testsPenetration Tests

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:

  1. Determine feasibility of any attack vectors as a mean of getting unauthorised or enhanced access to features or data
  2. Identify high-risk vulnerabilities from a combination of lower-risk vulnerabilities exploited in a particular sequence
  3. Identify vulnerabilities that may be difficult or impossible to detect with automated network or application vulnerability scanning software
  4. Assess the magnitude of potential business and operational impacts of successful attacks
  5. Test the ability of network defenders to detect and respond to attacks
  6. 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 un-trusted 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:
  • SQL Injection,
  • LDAP Injection,
  • ORM Injection,
  • XML Injection,
  • SSI Injection,
  • XPath Injection,
  • IMAP/SMTP Injection,
  • Code Injection,
  • Command Injection and
  • Buffer Overflow
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:
  • Role Definitions,
  • User Registration Process,
  • Account Provisioning Process,
  • Account Enumeration and Guessable User Account,
  • Weak or unenforced username policy,
  • Credentials Transported over an Encrypted Channel, Testing for default credentials,
  • Weak lock out mechanism,
  • bypassing authentication schema,
  • remember password functionality,
  • Browser cache weakness,
  • Weak password policy,
  • Weak security question/answer,
  • weak password change or reset functionalities,
  • Weaker authentication in alternative channel,
  • bypassing authorisation schema,
  • Privilege Escalation,
  • Bypassing Session Management Schema,
  • Cookies attributes,
  • Session Fixation,
  • Exposed Session Variables,
  • Cross Site Request Forgery (CSRF),
  • logout functionality,
  • Session Timeout,
  • Session puzzling
  • unreasonable high number of transaction for a user profile
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:
  • Reflected Cross Site Scripting
  • Stored Cross Site Scripting
  • DOM based Cross Site Scripting
  • JavaScript Execution
  • HTML Injection
  • Cross Site Flashing
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:
  • Directory traversal/file include
  • Insecure Direct Object References
  • Local File Inclusion Testing for Remote File Inclusion
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:
  • Fingerprint Web Server
  • Fingerprint Web Application Framework
  • Fingerprint Web Application
  • Network/Infrastructure Configuration
  • Application Platform Configuration
  • File Extensions Handling for Sensitive Information
  • Review Old, Backup and Un-referenced Files for Sensitive Information
  • Enumerate Infrastructure and Application Admin Interfaces
  • HTTP Methods
  • RIA cross domain policy
  • Analysis of Error Codes
  • Analysis of Stack Traces
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:
  • Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection
  • Padding Oracle (N/A for Microsoft environment)
  • Sensitive information sent via unencrypted channels Test HTTP Strict Transport Security
  • Credentials Transported over an Encrypted Channel
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:
  • Directory traversal/file include
  • bypassing authorisation schema
  • bypassing authentication schema
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:
  • Testing for Cross Site Request Forgery (CSRF)
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:
  • Enumerate Applications on Web server
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:
  • Client Side URL Redirect

Our strategy

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.

Indirect vulnerabilities

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.

Application firewalls

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

Conclusion

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.

References

The OWASP 10 table above is a compilation of the information in the following pages with some additional comments by us:

What tools are used for penetration tests?

Test 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:

Commercial tools/services:

How are penetration tests conducted?

There is plenty of material available on how a penetration test can be conducted:

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),
  • 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)

Leave a Reply