23DataVulnerabilities

Data Vulnerabilities

Outline

Concepts
What causes vulnerability ?
The famous SQL Injection attack
Trojan
Elimination of vulnerabilities
Hardening MySQL environment

A risk is the potential of gaining or losing something of value.

For example, in some database systems it is possible to re-use a password already used to logon to an operating system. In such a case, we gain a smaller number of passwords to remember, however, we risk, both access to an operating system and to a database system when a password is broken.

In the other example, we reduce time spent on verification of logical consistency constraints. In such a case, we gain on performance, because a database system does not need to spend more time on verification of data consistency.

On the other hand, the risks of database corruption are higher.

A threat is a communicated intent to inflict harm or loss on another person.

In a typical case a hacker communicates the intentions to break into the system.

A concept of vulnerability, refers to the inability of a system to withstand the effects of a hostile environment.

The human element of a database management system is one the biggest vulnerabilities of the system.

An attack vector is a path or means by which a hacker can gain access to a computer or network server in order to deliver a payload or malicious outcome.Attack vectors enable hackers to exploit system vulnerabilities, including the human element.

Concepts

Risk
- A risk is the potential of gaining or losing something of value
Threat
- A threat is a communicated intent to inflict harm or loss on another person
Vulnerability
- A vulnerability refers to the inability of a system or a unit to withstand the effects of a hostile environment
Attack vector
- An attack vector is a path or means by which a hacker can gain access to a computer or network server in order to deliver a payload or malicious outcome
- An attack vectors enable hackers to exploit system vulnerabilities, including the human element

Data Vulnerabilities

One of the main sources of vulnerabilities are software defects. Software defects are accidentally or intentionally built into the code, during the software development process. Software defect include design flaws and coding mistakes. Usually about 35% of successful attacks exploit software defects.

Design flaws involve design decisions, that create an inherently insecure system.

Coding errors include both ordinary software bugs as well as features, that were put in not by design but through oversight.

Usually, as a result of developers not thinking of all potential consequences of the design and implementation decisions.

Typical coding errors include: buffer overflows, race conditions, back doors into systems and even nonrandom random-number generators.

What causes vulnerability ?

Software defects
- Software defects are accidentally or intentionally built into the code during the software development process and include design flaws and coding mistakes (35% of successful attacks exploit these types of errors)
- Design flaws involve a design decision, that creates an inherently insecure system
- Coding errors include both ordinary software bugs as well as features that were put in not by design but through oversight and as a result of developers not thinking of all the potential consequences
- Coding errors include buffer overflows, race conditions, back doors into the system, and even nonrandom random-number generators

Another important source of vulnerabilities are configuration errors. Configuration errors account for approximately 65% of all vulnerabilities. Configuration errors include set up of unnecessary and dangerous services, when a system is configured, such that it brings up the services, and allows for the connections that are not required. It is usually caused by installation of a system with a default configuration, rather than with the precisely defined configuration, that eliminates all features, that are not required. It is always easier to use default configuration, because vendors prefer to offer an all-enabling starting configuration.

A classical example was one of the well known database systems, where a default password to a database administration account was predefined as 'manager'.

Usually, database administrators forgot to change the password after the installation of database system.

MySQL with user: root, available without a password is yet another nice example of a situation, that may result with a configuration error.

What causes vulnerability ?

Configuration errors
- Configuration errors account for 65% of vulnerabilities
- Configuration errors include set up of unnecessary and dangerous services when a system is configured, such that it brings up services and allows for connections that are not required
- It is usually caused by installation of a system with a default configuration, rather than with a precisely defined configuration, that eliminates all features, that are not required (it is easier to use default configuration because vendors prefer to offer an all-enabling starting configuration)

What causes vulnerability ?

Access administration errors
- When access control includes configuration errors, entire security model fall apart
- Because most complex systems have elaborate access control schemas based on the concepts of groups, roles, permissions, delegation, etc it is easy to get the errors in access control configuration
- It is very hard to detect the cases, that exploit such errors, because it cannot be detected by the intrusion detection or other monitoring systems due to the incorrect assumptions, that outside access looks correct

Data Vulnerabilities

Outline

Concepts
What causes vulnerability ?
The famous SQL Injection attack
Trojan
Elimination of vulnerabilities
Hardening MySQL environment

SQL injection is a technique, that exploits the applications using relational databases as their back end. The technique uses the fact, that an application has an available connection to a database and that the application composes SQL statements and send them to a database server, to extract data or to perform certain functions.

SQL injection uses a fact, that many of these applications compose SQL statements, by doing string concatenation of the fixed part of SQL statements, along with user supplied data, that forms WHERE clause or additional subqueries.

The technique is based on intentionally malformed user supplied data, that transform SQL statement from an innocent form into a malicious call, that causes unauthorised access, deletion of data, or even theft of information.

In all cases SQL injection as a technique, is based on using bugs and vulnerabilities in an application.

The famous SQL Injection attack

SQL injection is a technique, that exploits the applications using relational databases as their back end
The technique uses the fact, that applications have an available connection to a database and that the application composes SQL statements and sends them to a database server to extract data or to perform certain functions
SQL injection uses a fact, that many of these applications compose such SQL statements by doing string concatenation of the fixed part of SQL statements along with the user supplied data, that forms WHERE clause or additional subqueries
The technique is based on intentionally malformed user-supplied data, that transform SQL statements from an innocent form into a malicious call, that causes unauthorized access, deletion of data, or even theft of information
In all cases SQL injection as a technique, that is based on using bugs and vulnerabilities in an application

The famous SQL Injection attack

For example, assume that we would like to implement an interface, that can be used to login a user to a system

USER ID:  __________________________
PASSWORD: __________________________
          +---------+    +---------+
          | Logon   |    | Enroll  |
          +---------+    +---------+

The application receives USER ID and PASSWORD and it authenticates by checking USER ID and PASSWORD in USER table
Additionally, the application does not validate what a user typed into these two fields and SQL statement is created by string concatenation

The present slide contains a piece of code, that implements the authentication. The SQL string variable concatenates: SELECT statement, with the string constants taken from the text fields: and PASSWORD, of the interface. Then the SQL statement included in a variable SQL string, is sent to a database server for processing. The results of processing are saved in a variable: results.

If the results of processing are empty, then it means, that a relational table: USER, does not contain user name and password provided by a user through the interface. Then, a variable: user Has Been Authenticated, is set to false. Otherwise, if a query returns a nonempty result, then a variable: user Has Been Authenticated, is set to: true.

Hence, to pass through the authentication, we have to enter into the fields: and PASSWORD, the values, such that SELECT statement returns a nonempty result. As long as the result is nonempty, it really does not matter what SELECT statement returns from its processing on USER table.

So assume, that a malicious user intentionally types in a malicious code like the one displayed in the second paragraph of the present slide. An idea is to provide the values in the and PASSWORD fields, such that after the concatenation with the SELECT statement, a condition in the WHERE clause always evaluates to: TRUE. In such a case, SQL String variable obtains the values listed at the bottom of the present slide.

Note, that it is always true, that empty string: ' ' is always equal to an empty string: ' ' If such term is used in a disjunction on both side of a conjunction in the WHERE clause, then disjunction is always true and in the consequence a conjunction is also always true. At the end, it does not really matter what a user name and password are. SELECT statement always returns all rows from a relational table USER.

The famous SQL Injection attack

The following piece of code implements the authentication


sqlString = "SELECT USERID FROM USER WHERE USERID = ' " &userID& " ' AND PWD = ' " 
            &pwd& " ' ";
result = GetQuery Result(sqlString);
if (result = "") then
	userHasBeenAuthenticated = False
else
	userHasBeenAutheticated = True
end if;

What happens when a user intentionally types in a malicious code like

In such a case sqlString variable obtains the following value


SELECT USERID FROM USER WHERE USERID = '' OR '' = '' AND PWD = '' OR '' = ''

The famous SQL Injection attack

In such a case sqlString variable obtains the following value


SELECT USERID FROM USER WHERE USERID = '' OR ''= '' AND PWD = '' OR ''=''

Interpretation of WHERE condition returns TRUE because empty string is equal to empty string (' ' = ' ') and evaluation of disjunctions USERID = ' ' OR ' '= ' ' , and PWD = ' ' OR ' ' = ' ' returns TRUE and finally evaluation of conjunction USERID = ' ' OR ' ' = ' ' and PWD = ' ' OR ' ' = ' ' returns TRUE
Hence result is not empty and a variable userHasBeenAutheticated is set to True

Data Vulnerabilities

Outline

Concepts
What causes vulnerability ?
The famous SQL Injection attack
Trojan
Elimination of vulnerabilities
Hardening MySQL environment

A Trojan is an unauthorized program contained within a legitimate program. A legitimate program is modified by placement of unauthorized code within it. A legitimate program seems to do one thing but it actually does several other operations without your knowledge or agreement

The word “Trojan” comes from the myth about the City of Troy in which the Greeks gave their enemy a “gift” – huge wooden horse as a gift during a war. The Greek soldiers were hidden inside the horse. The soldiers stormed out of the horse during the night and they conquered the City of Troy

Trojans (or Trojan horses) are one of the main forms of attack that have gained “fame” on the desktop computers together with worms, viruses, and other malicious software

So, the more general conclusion is: "be careful about the gifts from the enemies".

Trojan

A Trojan is an unauthorized program contained within a legitimate program
A legitimate program is modified by placement of unauthorized code with it
A legitimate program seems to do one thing but it actually does several other operations without your knowledge or agreement
The word “Trojan” comes from the myth about the City of Troy in which the Greeks gave their enemy a “gift” – huge wooden horse as a gift during a war
The Greek soldiers were hidden inside the horse
The soldiers stormed out of the horse during the night and they conquered the City of Troy
Trojans (or Trojan horses) are one of the main forms of attack that have gained “fame” on the desktop computers together with worms, viruses, and other malicious software

Trojan

A Database Trojan is an attack that consists of two phases: the injection of the malicious code and the calling of the malicious code
It is difficult to track a Database Trojan because of separation in two phases, it is difficult to associate two apparently not related events
A Database Trojan after it is inserted into the system may stay in the system for a long time (“sleeper”) until it is activated

There are four categories of Trojan attacks:

The first is an attack, that both injects a Trojan and calls it.

The second is an attack, that uses an oblivious user or process, to inject a Trojan and then calls it, to extract the information or perform an action within a database.

The third is an attack, that injects a Trojan and then uses an oblivious user or process, to call a Trojan.

The fourth is an attack, that uses an oblivious user or process, to inject a Trojan and also uses an oblivious user or process, to call a Trojan.

An example of using an oblivious user, is a scenario when a junior developer gets some procedural code, for example a trigger or a stored procedure, from someone he/she does not know and then the developer uses this code, without fully understanding what the code is doing.

Trojan

There are four categories of Trojan attacks:
- An attack that both injects a Trojan and calls it
- An attack that uses an oblivious user or process to inject a Trojan and then calls it to extract the information or perform an action within a database
- An attack that injects a Trojan and then uses an oblivious user or process to call a Trojan
- An attack that uses an oblivious user or process to inject a Trojan and also uses an oblivious user or process to call a Trojan
An example of using an oblivious user is a scenario when a junior developer gest some procedural code, for example, trigger or stored procedure from someone he/she does not know and then uses this code without fully understanding what it is doing.

Data Vulnerabilities

Outline

Concepts
What causes vulnerability ?
The famous SQL Injection attack
Trojan
Elimination of vulnerabilities
Hardening MySQL environment

As we mentioned before, stored procedures and database triggers provide a "perfect environment" for the attacks on the security of database systems. It is one of the reasons why elimination of vulnerabilities, includes tracking of stored procedures and database triggers.

The first principle is to create a baseline for a set of stored procedures. It means, that a collection of stored procedures, is fixed and we monitor all divergences from a baseline.

The next principle is to log information and then to analyse the logs.

Next, we can implement a real-time alert. Such solution is able to detect in real-time a situation, where unauthorised user attempts to access sensitive data. If a real-time alert is implemented with the database triggers, then we have to make sure, that such implementation is completely safe.

The next principle, is to implement base-line capable firewall and do not pass the request, to access data in a situation where credibility of a user is doubtful.

The ultimate solution, is to manually control the creation of and changes to stored procedures and database triggers.

The other principle include: watching for changes to run as privileges. It means that we have to control the privilege to process a piece of code stored in a data dictionary.

The next principle, requires closely monitoring of developer activities in the production environments. It is related to monitor creation of traces and event monitors.

We also should be aware of S Q L attachments in e-mails, because such attachments can be automatically processed by the email clients.

Elimination of vulnerabilities

Track processing of stored procedures
- Create baseline for a set of stored procedure
- Monitor all divergences from a baseline
- Log information and analyse the logs
- Implement a real-time alert
- Implement base-line capable firewall
Control creation of and changes to procedures and triggers
Watch for changes to run-as privileges
Closely monitor developer activity on production environments
Monitor creation of traces and event monitors
Be aware of SQL attachments in e-mails

Data Vulnerabilities

Outline

Concepts
What causes vulnerability ?
The famous SQL Injection attack
Trojan
Elimination of vulnerabilities
Hardening MySQL environment

To harden MySQL environment, we have to first physically secure access to a server on which MySQL lives.

Next, it is recommended to use the following values of the system variables.

A variable: local_infile, should be set to: OFF, in order to disable: LOAD DATA LOCAL statement.

A variable: skip-show database, should be set to: OFF, to ensure, that: show databases statement, only lists databases for which the user has some kind of privilege.

A variable: secure_auth, should be set to: OFF, to disallow authentication for the accounts, that have a password from the earlier versions.

A variable: skip_name_resolve, should be set to: ON, in order, not to resolve the host names when checking client connections and use only IP addresses.

The privileges: PROCESS, FILE or SUPER should not be granted to non administrative users.

We should not run MySQL server on the same host as Web server, in order to force remote connections.

We must ensure, that a password for a user: root, is strong enough.

Hardening MySQL environment

Physically secure server on which MySQL lives
Use the following values of system variables
- local_infile = 'OFF' to disable LOCAL in LOADDATA statements
- skip_show_database= 'OFF' to ensure that show databases command only lists databases for which the user has some kind of privilege; in a more restrictive approach use skip-show-databases option
- secure_auth= 'ON' to disallow authentication for accounts that have password from earlier versions
- skip-name-resolve='ON' Do not resolve host names when checking client connections and use only IP addresses
Do not grant PROCESS, FILE, or SUPER privileges to non-administrative users
Do not run MySQL server on the same host as Web server in order to force remote connections
Ensure strong password for a user root

Hardening MySQL environment

Disallow the default full control of the database to local users and disallow the default permissions for remote users to connect to a database
Do not use MySQL prior to version 4.1
Limit privileges to the load_file function
Disallow developers to access production database servers
Enable auditing

References

C. Coronel, S. Morris, A. Basta, M. Zgola, Data Management and Security, Chapters 10 and 11, Cengage Compose eBook, 2018, eBook: Data Management and Security, 1st Edition
R. Ben Natan, Implementing database security and auditing: a guide for DBA's, information security administrators and auditors, Elsevier Digital Press, 2009 (Available online through UOW Library)