Vulnerabilities

Databases—vulnerabilities, costs of data breaches and countermeasures

This post introduces principal database vulnerabilities, providing an overview of the possible effects for their exploitation. For each database vulnerability, the principal cyber threats are exposed and a few suggestions are proposed for their mitigation. In the second part of the article interesting statistics related to the incidents/data breaches in private sectors and related costs are explored.

Database vulnerabilities

According to the latest security reports released by principal security firms, hackers consider database vulnerabilities as principal flaws to exploit in order to bypass defense of targets. The Imperva security firm recently issued a very interesting report that explains which are the principal database vulnerabilities for enterprises and how hackers exploit them. I strongly suggest reading the report, which provides a detailed description and techniques for its mitigation for each threat.

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

I personally created a list of the "Top Ten Database Security Threats" based on the security threat reports proposed by principal security companies, including Imperva, from 2010 to 2013.

1. Excessive privilege abuse
2. Legitimate privilege abuse
3. Privilege elevation
4. Exploitation of vulnerable, misconfigured databases
5. SQL injection
6. Malware
7. Denial of service
8. Database communication protocol vulnerabilities
9. Unauthorized copies of sensitive data
10. Backup data exposures

Probably many IT technicians still ignore many of them and the success of so many attacks against enterprises and organizations is the demonstration that a database flaw doesn't mean only "SQL Injection"!

The adoption of a multi-layered database security defense strategy is strongly suggested; the adoption of best practices and the implementation of internal controls could sensibly reduce the risk for data exposure caused by various attack vectors. The matrix below identifies solutions for each of the top 10 database threats proposed by Imperva in its last study:

Figure 1 Matrix Threat - Solution (Imperva)

Privilege abuse

The first three points in the above list are related to the abuse of database privilege settings. In both cases, "legitimate privilege" and "excessive privilege," the principal source of the problem is represented by the grant of unnecessary access privileges to the users or applications with consequent increase of the attack surface. In the third case, the threat is represented by privilege elevation operated by hackers.

The mitigation for this category of database vulnerabilities is the elimination of any excessive rights; of course, this requires an additional effort for administrators who have to identify excessive rights analyzing for each user the real business needs. This task could be executed manually, but is considered time-consuming; that's why large enterprises have deployed specific solutions for analytical process.

The access rights could be managed at various levels: Security experts consider an optimal choice is to control query-level access discriminating SQL operations (SELECT, UPDATE, etc.) and data for each entity that access to the system.

"Query-level access control is useful not only for detecting excessive privilege abuse by malicious employees, but also for preventing most of the other top ten threats described herein. Most database software implementations integrate some level of query-level access control (triggers, row level security, etc), but the manual nature of these "built-in" features make them impractical for all but the most limited deployments. The process of manually defining a query-level access control policy for all users across database rows, columns and operations is simply too time consuming."

Another element to consider is the exploit of legitimate privileges that could be abused by ill-intentioned users for obtaining access to corporate database: It is possible, for example, that malware on the machine could catch the database credentials to retrieve information stored in the archive.

A possible solution to legitimate privilege abuse is the deployment of the context of database access controls enforcing policy for client applications, time of day, and location. In this way, it is possible to discriminate the use for legitimate database access privileges.

Hackers typically follow alternative ways trying to exploit target software vulnerabilities to escalate access privileges to those of an administrator. Attackers could exploit vulnerabilities in stored procedures, built-in functions, and even SQL statements to increase their access privileges. To prevent this type of attack, businesses use a combination of intrusion prevention systems (IPS) and query-level access control.

Misconfigured databases and leak of input validation

Attackers could benefit from unpatched databases or archives not properly configured that still have default accounts and configuration parameters. The first step for a penetration testing is the analysis of those flaws. An efficient patch management process, especially for large enterprises, could reduce the time of exposure for the release of new database patches; vulnerability assessment activities could also support the mitigation of those cyber threats.

The SQL injection

The SQL injection is probably the most popular vector of attack for databases. In a typical attack, the hackers inject unauthorized database statements into a vulnerable SQL data channel, such as stored procedures and web application input parameters. These injected statements are specifically crafted to be executed on the database side for malicious purposes.

The successfully execution of a SQL injection attack can give to the attackers unrestricted access to an entire database. If these injected statements are executed by the database, critical data stores can be viewed, copied, and altered.

"Preventing SQL Injection—Three techniques can be combined to effectively combat SQL injection: intrusion prevention (IPS), query-level access control (see excessive privilege abuse), and event correlation. IPS can identify vulnerable stored procedures or SQL injection strings. However, IPS alone is not reliable, since SQL injection strings are prone to false positives. Security managers who rely on IPS alone would be bombarded with 'possible' SQL injection alerts. However, by correlating a SQL injection signature with another violation, such as a query-level access control violation, a real attack can be identified with extreme accuracy. It's unlikely that a SQL injection signature and another violation would appear in the same request during normal business operation."

Malicious attackers successfully use SQL injection on legitimate web sites using various techniques: They often adopt a search engine's index to find vulnerable websites by using one of the numerous DIY SQL injecting tools available on the black market.

The availability of the DIY Google Dorks based hacking tool allows ill-intentioned people to acquire precious information on remotely exploitable websites, data that could be collected to compromise them; for example, deploying a malicious exploit kit or exploiting known vulnerabilities. The tool relies on Google Dorks for a target evaluation. In particular, the DIY Google Dorks based hacking tool has built-in features that can be used to evaluate the possibility of performing a SQL injection attack or to discover all the targets that aren't protected by a CAPTCHA challenge mechanism.

Cybercriminals could also rely on botnets actively crawling inside a search engine's index, looking for websites vulnerable to SQL injection attacks. One of the most popular massive SQL injection attack affected over a million web sites during in October 2011, an offensive directly connected to the Lizamoon mass SQL injection attacks.

Example

Let's use a very simple query as example:

[sql]

SELECT fields FROM myTable

WHERE field = '$EMAIL';

where $EMAIL' is an email address provided by the user via a web form. If an ill-intentioned user provides the following input:

dummy’ OR ‘1’=’1

[/sql]

in the email field, and it is not validated, the resulting SQL will be

[sql]

SELECT fields FROM myTable

WHERE field = 'dummy’ OR ‘1’=’1';

[/sql]

Due the presence of the '1'='1' condition, which is always TRUE, the query returns every item in the myTable.

Denial of Service (DOS) and database communications protocol vulnerabilities

Exactly like any other service, a database can suffer a denial of service attack; there are various ways to flood DBMS with requests that may impede the database from providing data to intended users. DOS may be achieved by exploiting database platform vulnerabilities to crash a server, flooding the system with requests, or using specifically designed malware. Protection from these cyber threats needs a multiple level defense system that has the capability to recognize the sources of attack and apply the needed countermeasures. It's fundamental to put in place defensive measures at network, application, and database level.

Principal classes of DoS attack are:

• Abuse of functions
• Complex queries
• Bugs and defects in the database
• Application usage

Another critical element for database security is represented by a communications protocol that could be exploited by attackers to obtain unauthorized access to the data. The principal database vendors are aware of cyber threats related to the communication protocols; the majority of recent security fixes released by IBM and Oracle are related to protocol vulnerability.

The SQL Slammer2 worm represents a perfect example of malicious code designed to exploit a flaw in Microsoft service. The countermeasure most efficient against database communication protocol attacks is protocol validation designed to parse traffic and block malicious ones in case anomalous patterns are detected.

Data exposure

Data exposure could be caused by various factors. For example, it is possible that data backup devices are stolen or unauthorized copies of sensitive data are accessed by unauthorized entities.

The principal cause of data exposure is the absence of a secure mechanism for protecting database copies. In many cases, companies that were victims of incidents did not have an inventory of all their databases and related backups. Each database is a mine of information and could contain sensitive data that need the control of accesses. Outdated database instances represent one of the principal weaknesses for organizations; numerous security audits revealed the absence of proper management of media containing old copy of the databases.

A company must identify all databases within internal infrastructures and the data contained; for each archive it has to define privileges of access and maintain track of every activity during its lifecycle, from its creation to the dispose of the media support used for the storage.

Data classification is a must, identifying the sensitive information within the archives. It is also strongly suggested to discover combinations of data that could expose confidential information, despite the fact that the same data could appear innocuous, if combined they could reveal sensitive data. An accurate inventory of databases including location of sensitive data and access controls should be set in compliance with corporate data access policies.

To prevent backup data exposure it is also necessary to encrypt the backup.

Malware and databases

Another serious menace for the database is represented by the most classic cyber threat, malware. The malware authors could in fact design malicious code to automate the exploitation of one of the above points; the principal purposes of those malicious agents are information stealing and sabotage. The damage to an enterprise database could have serious repercussion on business for private companies. One of most popular agents that targeted victims' databases is W32.Disttrack malware, also known as Shamoon, which is able to wipe out data from infected PC hard disks.

In November 2012, Symantec published a security alert on a new malware dubbed W32.Narilam that was designed to damage corporate databases. Exactly like Shamoon, this malware hit a specific the geographic area, the Middle East.

Figure 2 - Narilam diffusion (Symantec)

The W32.Narilam worm attempts to spread by copying itself to all drives and certain shared folders on the victim's PC. There weren't instances that included a module to steal information from the victims.

The worm was designed to attack SQL archives; it was able to search for database instances having one of the following names:

• alim
• maliran
• shahd

Once the database instance was found, the malware was able to access database objects to manipulate them; it was also able to delete the entire archive. The malware was designed to find objects with specific names belonging to the Arabic and Persian languages (e.g., hesabjari than means "current account" in Arabic/Persian).

Narilam was written in the Delphi programming language and has a behavior similar to other malicious agents, but what is considered "unusual" by security researchers is its capability to update a Microsoft SQL database if it is accessible by OLEDB. The investigation revealed that the malicious code was designed to target mainly corporations, the percentage of business users hit is of 97.1%, while non-business users are at 2.9%.

The Symantec report stated:

"Unless appropriate backups are in place, the affected database will be difficult to restore. The affected organization will likely suffer significant disruption and even financial loss while restoring the database. As the malware is aimed at sabotaging the affected database and does not make a copy of the original database first, those affected by this threat will have a long road to recovery ahead of them."

A few days after its discovery, the Iranian national CERT, also known as "Maher," announced that "Narilam" was an already known malware detected for the first time in 2010 and that it didn't represent a serious cyber threat like other agents that hit the Iranian region. The simple nature of the malware looks more like an attempt to harm the software company reputation among their customers.

The Cost of a data breach in private sector

Now we have listed the principal vulnerabilities related to a database. Unfortunately, the cost related to a data breach is still very high and its analysis it is necessary to highlight the importance of adopting proper countermeasures to mitigate the risk of incidents/cyber attacks.

In May 2013, the Ponemon Institute published its annual analysis on the cost related to accidental data exposure. The paper, titled "2013 Cost of Data Breach Study: United Kingdom," is benchmark research sponsored by Symantec and independently conducted by the institute.

The study is focused on the cost of data breach incidents for companies located in the UK. It examines the costs incurred by 38 UK companies in 12 industry sectors after these businesses experienced the loss or theft of protected personal data and then had to notify breach victims and/or regulators as required by law

Let's start with some alarming data: The average per capita cost of an incident increased from £79 to £86 and the cost of data breach continues to rise for the sixth consecutive year

Figure 3 - The average per capita cost of data breach over six years (Ponemon Institute)

The organizational cost grew from £1.75 million to £2.04 million. Negligence is considered the main cause of data breaches (accounting for 37% of incidents), confirming the need to establish a strong commitment for the diffusion of security culture within corporates.

Figure 4- The average total organizational cost of data breach over six years (Ponemon Institute)

The study revealed that malicious attacks also increased, from 31% to 34%, and related data breaches are generally considered most costly. The per capita cost of a data breach caused by malicious or criminal attacks was £102.

Figure 5 - Per capita cost for three root causes of data breach (Ponemon Institute)

Cost of data breaches due to system or business process failures was £79 and the loss for data breaches caused by the employee or contractor negligence was £76 per compromised record.

Lost business costs (including the abnormal turnover of customer, increased customer acquisition activities, reputation losses, and diminished goodwill) rose from £779 thousand in 2011 to £921 thousand in 2012.

Lost business cost has nearly doubled over the last six years, also ex-poste response and detection costs (e.g., activities that attempt to address victims', regulators', and plaintiff counsels' concerns about the breach incident, legal and consulting fees that attempt to reduce business risk and liability) increased from approximately £451 thousand in 2011 to £508 thousand in 2012..

Conclusions

The data presented by the Ponemon Institute demonstrate how insidious and expensive are cyber threats that target vulnerabilities in databases. Despite the high level of awareness of the principal menaces, the number of incidents has increased in recent years and with the cost suffered by victims of incidents or data breaches has also increased. To reduce the impact of these events, an organization needs to prepare a formal incident response plan, the adoption of proper procedures could, in fact, reduce the total cost of a data breach. Organizations have to define and adopt a strong security policy sustained by a strong commitment of high management and the policy must include corporate database security. The hiring of outside consultants could also contribute to the improving both for processes of security policy definition and for the definition/implementation of data breach response.

Security of databases is a critical element for the cyber security policy of any companies, but the data related to the incidents seems to suggest to us that organizations still don't perceive it!

Sources

http://www.imperva.com/docs/WP_TopTen_Database_Threats.pdf

http://docs.media.bitpipe.com/io_10x/io_102267/item_692230/2013%20Report%20UK%20CODB%20FINAL%2041.pdf

http://securityaffairs.co/wordpress/10564/malware/w32-narilam-the-malware-that-hit-databases-in-middle-east.html

http://securityaffairs.co/wordpress/8153/malware/shamoon-malware-cyber-espionage-tool-cyber-weapon-or.html

http://securityaffairs.co/wordpress/14196/cyber-crime/hacking-new-diy-google-dorks-based-hacking-tool.html#!

http://www.symantec.com/security_response/writeup.jsp?docid=2012-111516-3751-99

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

http://ddanchev.blogspot.it/2008/10/massive-sql-injection-attacks-chinese.html

http://docs.media.bitpipe.com/io_10x/io_102267/item_692230/2013%20Report%20UK%20CODB%20FINAL%2041.pdf

https://securosis.com/blog/database-denial-of-service-the-attacks

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

http://www.idgconnect.com/download/12059/emerging-cyber-threats-report-2013?flag=true&source=connect