Report 23

Information Systems Audit Report – Database Security

Audit Conclusion and Key Findings

Audit conclusion

The seven sampled agencies have not adequately protected information from attackers to prevent unauthorised access and data loss. Sensitive and confidential information is at risk and agencies may not know if or the extent to which data is compromised.

We identified 115 findings with failures in all seven key areas. Most concerning was a lack of some basic controls over passwords, patching and setting of user privileges. Our findings also revealed copies of sensitive information across systems and poorly configured databases. We rated these types of weaknesses as extreme or high given how easily an attacker can exploit them to gain the level of access needed to view or modify data.

Key findings

We have structured our findings in line with the seven key areas we tested.

The first four areas; attack surface, account security, system hardening and version/patching represent the greatest risk to databases and the information they contain. It is concerning then, that these four areas make up 64 per cent (73) of the total findings, with 47 per cent (54 of the total 115 findings) rated extreme or high.

Table 1 - Findings by severity

Each agency had at least three findings that we rated as extreme or high. Figure 1 shows the number and severity of the findings per agency database.

Figure 1 - Findings per severity

Attack surface

The greater the attack surface of a system the more likely it is to be compromised. This part of the health check gauges the attack surface by checking what applications and services are installed and accessible.

We found that agencies have increased the risk of unauthorised access and loss of information by increasing the number of opportunities for exploitation. This type of weakness made up 25 (22 per cent) of the total findings of which 18 were rated as extreme or high risk.

Figure 2 - Attack surface findings by severity

We found several agencies did not separate their production, test and development environments. These environments replicated information from production (live) databases across all environments. This increases the attack surface by making the data more freely available to a wider pool of staff and contractors without the same level of security afforded to the production database.

Settings in the database that are disabled by default when installed were enabled without reason. For example, we found settings enabled to allow the execution of operating system commands that permit the extraction of information from the database or to run unsolicited programs. These functions can allow an attacker or a well-crafted piece of malware to perform unauthorised activity leading to the compromise of the server and the data it contains. Alternatively they may be able to use the compromised server as a stage to perform other unauthorised activity across the entire network.

The ‘PUBLIC’ role in a database gives all users its assigned privileges. We found many databases that have allocated Read/Write privileges to PUBLIC, thereby providing all users with highly privileged access and creating information security risks. We also found instances where this account was allocated access to network folders, which creates additional vulnerabilities and introduces data integrity risks.

We found database links accessible by PUBLIC in a small number of databases. This allows access from one database to other connected databases so anyone with access to one may access the other. This includes the execution of programs to compromise information held in the databases within the local network or from other external networks and the Internet.

Databases contained unused schemas and automatic procedures, which can lead to a full compromise of the server. Schemas are the ‘blue print’ for how information is structured in a database, thereby increasing the exposure of information to attackers. These types of weaknesses also increase the likelihood of security vulnerabilities in the databases further increasing the risk of information being exploited.

We found a number of database servers that have multiple unrelated application databases. This increases the connections and activity on the database server and the likelihood of unauthorised access or cyber threats in general. It is better practice for each production database, if critical to the operations of the agency, to have its own dedicated server when the information it contains is sensitive.

There were no firewalls segregating databases and servers from the rest of the network or other agency networks. Users that access the network can compromise services running on the database or the server itself. This increases the risk of someone attempting to gain unauthorised access to the database or its server due to the increased number of people that have access to the server or use the same network.

Account security

Account security examines if database user accounts have default or easy to guess passwords. Exploiting weak passwords are one of the first actions an attacker will try in order to gain system access. Strong account security is therefore one of the most important steps to take to secure a database server.

The security of database users and system accounts could be improved across all systems we audited. We found a large number of accounts with high level privileges to data and system settings that had weak password controls. Account security made up 22 (19 per cent) of the findings of which 12 were rated as extreme or high risk and 10 as low.

Figure 3 - Account security by severity

We found many instances of database administrator accounts where the default usernames and passwords were still in use. These default user settings are widely known and often the first accounts someone would try to exploit. We also identified accounts with exceptionally easy to guess passwords. Examples include passwords that were the same as the username, passwords that were the same name as the application and passwords such as ‘test’, ‘password1’, ‘sqladmin’.

There were also many three-character passwords; in particular, one Database Administrator Account (DBA) had a password of ‘DBA’. There were several instances where the ‘SYS’ password was too easy to guess. The ‘SYS’ account carries DBA privileges and cannot be locked out. This provides an attacker with unlimited attempts to brute force the password. We also found instances where weak passwords had never changed or had been the same for 6-12 years. The risk of a password being compromised through brute force attacks, disclosed by trusted users or extracted from hacked systems increases with its age. Periodic password changes mitigate these risks.

We examined various properties in databases and found that password aging had not been enforced across many of them. We found several agencies had not changed administrator account passwords anywhere from three to over 10 years. In one database, we found 17 highly privileged accounts that had never had their passwords changed.

We also identified a large number of inactive user accounts, which had weak passwords or not had their passwords changed. While many accounts we identified on Oracle Databases were ‘locked’, flaws in the configuration of the database may allow attackers to unlock them. An attacker that has access to an existing account can exploit these flaws to unlock other accounts. These additional accounts might have higher levels of access than the attacker’s account, or allow the attacker to go undetected by occupying an unused account.

Several agencies were not logging accounts to determine activity within their database, meaning that they were not aware of when and what is accessed and if there was unauthorised activity occurring. Further detail is included under the Auditing and Monitoring section of this report.

Figure 4 - Sensitive information lost after password easily guessed

System hardening

Locking down privileges and ensuring secure configurations are in place make systems more resilient to attackers and cyber threats.

We found default configurations and permissions at 10 out of 13 systems audited indicating that the databases were not properly hardened. Inadequate system hardening made up 17 (15 per cent) of the findings of which 15 were rated as extreme or high risk and two as medium.

Figure 5 - System hardening findings by severity

Excessive privileges were granted to the PUBLIC role across most systems. This could allow an attacker to compromise the entire database. On these systems it is possible to execute procedures to allow anyone to grant themselves arbitrary java privileges with the ability to load and execute programs. This can lead to a full compromise of a database server.

We found several examples where the PUBLIC role had privileges on various database tables owned by highly privileged accounts such as ‘SYSTEM’ and ‘SYS’. If PUBLIC has high privileges on a table, it means that queries can be run to extract information from those database tables and even allow the creation of unauthorised accounts and permissions.

Database administrator accounts

Databases generally come with pre-configured administrator accounts and passwords that are listed in product documentation and widely available on the Internet. Because attackers will normally try the default user names and passwords, it is important to change these on installation.

In discussions with database administrators at the seven agencies, we found it common for their accounts to be used for general user activity and not solely for administrative tasks. This means that agencies cannot attribute actions to specific individuals or hold them accountable.

It is important to use database administrator accounts exclusively for administrative tasks with standard database accounts. Ensuring database administrators have unique and identifiable accounts will assist in auditing activities of databases. This is particularly helpful during investigations relating to an attempted, or successful intrusion. Furthermore, database administrator accounts should not be shared across different databases as this can increase the likelihood of a successful attack on multiple databases.

Version/patching

Attackers take advantage of security vulnerabilities to gain access to systems and escalate their privileges. As new vulnerabilities are discovered, it is important to keep software up to date by upgrading outdated software to the latest versions and regularly installing vendor supplied security patches.

Only four of the 13 systems reviewed were completely patched. The other nine were missing vendor patches, some dating back to 2010. Patching made up nine (8 per cent) of our findings with all of them rated either extreme or high risk.

Figure 6 - Version-patching findings by severity

We found one database that was never patched. This server was susceptible to numerous critical security vulnerabilities that an attacker with just a low access privilege could exploit to gain full control over the server.

We found several systems running a version of Oracle that ceased mainstream support in 2012. There are numerous known vulnerabilities in this version including many critical security flaws.

In one agency, all of its 150 databases stored large amounts of sensitive information without mainstream support from their respective vendor. Over half of these systems were so old the vendor gave no support at all. This significantly increases the risks to information stored in these databases.

We found two SQL servers that were over two years behind on patches and one three years behind. All three servers should have received numerous patches.

Many of the security vulnerabilities in the nine systems that were not fully patched have been well known in the industry since 2010. The Australian Signals Directorate (ASD) has identified patching of systems as one of the top four measures agencies can take to protect their information.

Figure 7 - The Australian Signals Directorate

Data protection

Sensitive, confidential or secret data requires a secure database server. Databases can be further protected with the use of encryption, virtual private database and or data redaction.

None of the 13 systems were encrypting sensitive data stored within their databases or on backups stored on tapes and off site. We also found inadequate protection of production data found in development and test environments.

Data protection findings made up 13 of the 115 findings (11 per cent) with four rated as high and nine as medium.

Figure 8 - Data protection findings by severity

Auditing and monitoring

Database auditing enables an administrator or security manager to detect in a timely manner the possible security breach of a database and to audit access made to the data. It means that the administrator can answer questions like, ‘has data been accessed by an unauthorised person, has data been changed, who changed it and when’.

Database object auditing was not active on any of the 13 databases we reviewed. While some actions such as failed logins were recorded in some cases, auditing was not active on sensitive data stored within the databases.

Auditing and monitoring weaknesses made up 27 (23 per cent) of our findings of which 26 were rated as low risk. However, these risk should not be underestimated because without adequate security monitoring, agencies will not know if, or to what extent, their information is compromised.

Figure 9 - Auditing and monitoring findings by severity

Backdoors/misconfiguration

Once an attacker has broken into a database, they may leave a backdoor in the system to allow access at a later date. These backdoors can take many forms and often look like misconfigurations. This section reviewed aspects that may be a backdoor but if not are more than likely an undesirable misconfiguration.

There are a number of ways to ‘backdoor’ a database server. Occasionally a misconfiguration can look like a backdoor and usually is the result of a mistake.

We only found instances at two agencies where misconfigurations existed. These had the PUBLIC role assigned membership to ‘other’ roles. Any privileges granted to these ‘other’ roles are therefore effectively granted to everyone on the database server via the PUBLIC role.

Both instances were not default settings of a database and therefore were deliberate actions. The reasons and real impact of these misconfigurations are not known so are considered to be high risk. We recommended to both agencies that they investigate these instances and correct as appropriate.

Figure 10 - Backdoors-misconfiguration findings by severity

 

 

 

 

 

 

 

 

Page last updated: November 5, 2015

Back to Top