A few weeks ago, we analyzed the top five cyber security vulnerabilities in terms of potential for catastrophic damage.

Data breaches like the one affecting the Federal Office of Personnel Management (OPM) and the numerous cyber-attacks targeting US infrastructure and government offices raise the discussion of the potential catastrophic damage caused by the exploitation of cyber security vulnerabilities.

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

Let’s examine in detail the top five cyber security vulnerabilities that we have identified to provide a few suggestions to mitigate the risk for a cyber-attack.

Injection vulnerabilities

Injection vulnerabilities occur every time an application sends untrusted data to an interpreter. The casuistry of injection flaws is wide, but most popular injection vulnerabilities affect SQL, LDAP, XPath, XML parsers and program arguments.

The adoption of best coding practices and design patterns could allow developers to design robust solutions and easily discover such flaws by reviewing the code. Unfortunately, once vulnerable applications are deployed, it is hard to discover injection flaws while testing them.

Attackers used to exploit injection flaws to steal data and compromise the target system, in some cases gaining the full control of its resources. It is easy to understand the potential impact for the exploitation of an Injection flaws.

As explained by the OSWAP organization, the prevention of injection flaws has to be addressed in the coding phase. The organization suggests keeping untrusted data separate from commands and queries.

It is suggested that the adoption of safe API, which provides a parameterized interface and carefully validated input data. In case a parameterized API is not available, coders should carefully escape special characters using the specific escape syntax for that interpreter.

In some cases, developers could adopt “white list” input validation, but despite that, it is a good practice to implement. It doesn’t provide a complete defense against injection attacks because many applications require special characters during input.

SQL Injection vulnerabilities are the most common flaws exploited in injection attacks. The attackers operate by providing input data to a web application that is then used in SQL queries. The data in the majority of cases comes from an untrusted input such as a web form, but it is a good practice to consider not trusted data and also data provided by the database. A common error made by developers is to trust data from their own database. However, there are several ways to poison these data and trigger a SQL injection vulnerability by using data in input extracted from the database.

For the validation process, it is important to assume that not all data is created explicitly in the PHP source code of the current request should be considered untrusted.

Some languages such as the PHP implement extension that could be used to escape all data that have to be passed to a SQL query.

Always referring the SLQ injection mitigation, parameterized queries, also known as prepared Statements, could help developers to avoid the construction of bogus SQL queries.

Another good approach consists to enforce the “Least Privilege Principle” ensuring that users are given only those privileges that are absolutely necessary to carry out their tasks.

Users should never access the database from a web application as root or administrator to avoid the ability to gain complete control of the database and exploit other SQL injection attacks for other illicit activities.

Buffer Overflows

A buffer overflow vulnerability condition exists when an application attempts to put more data in a buffer than it can hold. Hackers exploit buffer overflow vulnerabilities to overwrite the content of adjacent memory blocks causing data corruption, crash the program, or the execution of an arbitrary malicious code. This kind of attack is difficult to exploit because requests the knowledge of memory management of the targeted software, the buffers it uses, and the way to access them to overwrite their content and run the attack.

In a classic attack scenario, the attacker sends data to an application that store it in an undersized stack buffer, causing the overwriting of information on the call stack, including the function’s return pointer. In this way, the attacker is able to run its own malicious code once a legitimate function is completed and the control is transferred to the exploit code contained in the attacker’s data.

There are numerous techniques to prevent buffer overflow attacks, most popular ones are:

• Bounds Checking, which consist of detecting whether avariable is within some bounds before it is used. There are a number of controls that is possible to perform on the variable, for example, a variable that is being used as an array index is within the bounds of the array (index checking).

The main problems related to bound checking is the overhead introduced by the controls, to improve code performance developers usually do not perform the checks at any usage.

• Using of Safe Libraries that help preventing buffer overflows by replacing the legitimate vulnerable function to implement bounds-checked replacements to standard memory and string functions.

• Running Static Code Analysis that is an essential part of the code review. The choice of proper Static Code Analysis tools is crucial to run automatic tests searching for buffer overflow bugs.

• Using the Executable space protection, a practice that consists in the marking of memory areas where application cannot store executable code. Every time a user or a program attempts to execute machine code in these regions will trigger an exception, in this way it is possible to mitigate buffer overflow making impossible to overwrite the content of these areas.

• Using canary values. For compile time protection, some compilers calculate the key hash of return pointer when the RP is being pushed onto the stack. This keyed hash value is known as the canary. Then the canary and RP is pushed onto the stack and when the function needs to return, system checks whether the RP and canary has the same value. If they do not, program never return from function not allowing the execution of malicious code and causing the program end gracefully.

• Implementing the Address space layout randomization (ASLR), a technique that randomly arranges the address space positions of principal data areas used by a process. The techniques randomly arrange the address space of executables and the positions of the stack, heap and libraries.

• Implementing Stack-smashing Protection (SSP), a compiler feature that helps detecting stack buffer overrun by aborting if specific value, also dubbed stack canary, on the stack is modified. Be aware, SSP simply detects stack buffer overruns, but not prevent them.

Sensitive Data Exposure

Sensitive data exposure occurs every time a threat actor gains access to the user sensitive data.

Data could be stolen in numerous ways, by hacking data storage, by intercepting data between a server and the browser with a Man-In-The-Middle attack.

The principal causes for data exposure are the lack of encryption for sensitive data or the poorly configured encryption processes. The adoption of weak key generation, the lack of proper key management, and the usage of weak algorithms are very common errors in almost every industries and applications.

The adoption of encryption mechanisms could help in preventing sensitive data exposure, but they must be properly implemented to avoid open the door to hackers.

The first suggestion is to avoid storing information if nor strictly necessary.

The OWASP suggests a minimum set of practices when dealing with sensitive data, first of all, it is important to assess potential threats and evaluate related risk of exposure. Make sure you encrypt all sensitive data at rest and in transit in way to avoid cyber threats compromise sensitive information.

Be sure to adopt strong standard algorithms and strong keys, most important is to put in place an efficient key management process (i.e. key generation and key protection). When dealing with web applications disable autocomplete on forms used for data entry and disable page caching, both scenarios usually expose sensitive data (i.e. passwords, credit card data, addresses and social security numbers) to attackers.

Another element to consider carefully is the disposal of sensitive data; information disclosure has become a major risk to organizations dealing with sensitive data due to the increasing penetration of technology in storage systems and the use of disposable media.

Every media must be properly destructed, in the following table are reported the suggested removal methods for each media type.

Figure 1 - Media and Data Destruction methods (Health & Social Care Information Center)

Broken Authentication and Session Management

The exploitation of a broken Authentication and Session Management flaw occurs when an attacker uses leaks or flaws in the authentication or session management procedures (e.g. Exposed accounts, passwords, session IDs) to impersonate other users.

Despite Authentication and Session Management, flaws are hard to mitigate due to the large number of authentication schemes implemented by organizations.

There are several options to bypass authentication mechanisms, including “Brute-forcing” the targeted account, using a SQL Injection attack, retrieving a session identifier from an URL, relying on the session timeout, reusing an already used session token or compromising a user’s browser.

The primary recommendation provided by the OWASP project to the organizations is to make available to developers a single set of strong authentication and session management controls and carefully consider XSS flaws implementing all necessary countermeasures to fix them.

XSS is an element of major concern because it is one of the most common methods to steal session id to impersonate other users.

An XSS attack allows a hacker to insert or execute code on the client side in order to implement a wide range of attacks such as the theft of confidential data, and the access and modification of data on the server side.

One of the principal techniques to prevent XSS attacks is the contextual output encoding/escaping. There are a number of escaping schemes that could be implemented to mitigate XSS attacks, the methods depend where the untrusted string needs to be inserted in the HTML document.

If applications allow users HTML input it is necessary to run it through an HTML sanitization component that parse the code verifying that it does not contain XSS exploits.

Among the most recent XSS mitigation technologies there are Content Security Policy, JavaScript sandbox tools, auto-escaping templates.

Security Misconfiguration

Security Misconfiguration is one of most insidious vulnerabilities that could affect basically every technology, including web services, client applications, electronic equipment, Internet of Things devices, and encryption mechanisms. Applications and systems that have been misconfigured result open to cyber-attacks. Unfortunately, in the majority of cases an attacker can easily searches for this kind of vulnerabilities by using automated scanners.

Below some typical example of security misconfiguration flaws and the way to mitigate them.

• Running outdated software – Every software and firmware component must be updated with the last version available ensuring that all known flaws have been patched.

• Applications and products running in production in debug mode or that still include debugging modules – Debugging mode must be disabled because it could represents an open port for attackers that could exploit it to have full access to a system or to an application. Revealing too much debugging information is one of the most common misconfiguration error that allow attackers to collect extra information to decide the specific type of attack to run against the system.

When dealing with software components it is easy to find debugging component left in the code that could be exploited by hackers to access functions of the host system. The problem is quite similar for hardware components, an example are JTAG circuit, normally used for debugging and simulation purposes, which is left in the component could be accessed by hackers to run numerous malicious activities.

• Running unnecessary services on the system. Every service represents potentially an open door for attackers. It is essential to assess all running services evaluating which one are necessary for the operations and disabling unnecessary ones by reducing the surface of attack.

• Improper Policy or Role configuration – The adoption of groups or roles to access settings or records that were not intended for them is one of the primary cause of successfully attacks. It is essential to define simple business roles and polices that could be easily deployed within an organization. For every resource in the organization must be clearly defined its role and the task assigned.

• Not changing factory settings. – This is another common error that could be easily exploited by attackers. It is quite easy to find online any kind of information regarding a specific software or devices, including default settings (i.e. passwords, Telnet credentials, open port, etc.) In order to protect the system it is necessary to change any default setting making hard for an attacker to hack the targeted system. Never use default accounts.

• Incorrect exception management. Not properly handling exceptions could disclose system information to the attackers, including stack traces. To secure systems it is important to manage system exceptions correctly. An attacker can force an exception condition to gather information on the target system. Avoid handling errors by catching non-specific exceptions because it is important to predict all possible causes of an exception and ensure that an attacker cannot exploit the resulting application state. It is essential to catch only those exceptions that it is possible handle.

References

http://phpsecurity.readthedocs.org/en/latest/Injection-Attacks.html#code-injection-also-remote-file-inclusion

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_Top_10_for_2013

http://securityaffairs.co/wordpress/24094/cyber-crime/ponemon-sql-injection-attacks.html

http://securityaffairs.co/wordpress/28615/hacking/bash-bug-critical-risk.html

https://www.owasp.org/index.php/Buffer_overflow_attack

https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management

http://securityaffairs.co/wordpress/28151/hacking/cert-test-android-apps.html

http://systems.hscic.gov.uk/infogov/security/infrasec/gpg/dadosd.pdf

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration