- Email: [email protected]
Database security — an oxymoron?
c o l u m n
Ken Munro
Database security — an oxymoron? Ken Munro Penetration testing often reveals the same old security issues, particularly with regard to the configuration and maintenance of databases. Some of these recurrent security problems are generic and affect nearly every database we have tested. Others are associated only with a particular vendor or version.
n example of the latter is the Oracle database. Back in the dim and distant past of 2001, Oracle ran their ‘Unbreakable’ campaign; a bold move which attracted attention from the hacking community. However, we continually see the same issue: credentials. On installation the Oracle database server has a set of around 14 default passwords, and these are frequently left as default, instead of changing them for stronger passwords.
A
To gain access to the database, one needs to find a set of default credentials to an account with ‘create library’ permissions'. Account name DBSNMP, with default password of DBSNMP is used by the Oracle Intelligent Agent. Using this account, the attacker can log on as database administrator, giving them ownership of the database.
Infosecurity Today November/December 2006
Once one has control of the database, the password hashes can be dumped and cracked offline, as Oracle password encryption isn’t particularly strong by default. Databases in an organization usually use common administrator passwords. Hence, it only takes one default or weak password on one database in the organisation to potentially give access to all similar databases. We also find that we can enumerate the database using the Oracle TNS Listener service because there is rarely a password set, or it’s left in default. There is a simple solution: remove or rename default accounts and set strong passwords.
Microsoft’s SQL Server also has a fundamental configuration issue, again credentials-related. Like MySQL the root user or systems administrator (SA) often has no password set or it is set to ‘SA’ or ‘password’ even though there’s a clear prompt to set a password on installation. SQL Server is usually configured with the highest privilege running, so if there’s no SA password, or it’s easily guessed, then the ‘xp_cmdshell’ stored procedure is usually available. This allows one to execute database queries and DOS-like commands, which means one could access the underlying operating system and execute OS commands. There’s a similar problem on some Sybase systems, which can also provide the attacker with total ownership. In our experience implementations of MySQL tend to be more secure than SQL Server, although we occasionally find TCP port 3306 left open to the Internet. There is rarely a need for this service to be publicly available so close it. We also find old vulnerable versions running when an update is available. Keep yourself informed of versioning via manufacturer web sites and assess likely installation or configuration issues in user forums and groups. One not so common but deadly issue is that MySQL has an extremely powerful functionality called UDF Functions. This can allow you to write your own libraries which
MySQL can then load into memory. All well and good but SQL injection can be performed on a site running MySQL. Using UDF it’s possible to inject your library and take ownership of the server. Due to their small scale it’s not often that we specifically test file-based databases such as FoxPro or Access. But when we do, the perennial favourite is exploring NFS shares for files. Usually they are world readable and give up the contents of much of the database. Database password issues are sometimes a result of insecure coding practices – developers write applications that require, for example, a blank SA password. Third party applications that run over databases often require default credentials. Don’t accept this: require that your developers code secure methods of transacting with a database, and application vendors helpdesks usually have a workaround available to secure your DB. If we had to cite a common cause for these issues it would be that database administrators (DBAs) simply don’t have the time, skills or resources to dedicate to securing their databases. They have their work cut out just managing and maintaining the database. With availability the main driver, security is often sidelined.
•
Ken Munro is the managing director of Secure Test.
42
Ken Munro
Database security — an oxymoron? Ken Munro Penetration testing often reveals the same old security issues, particularly with regard to the configuration and maintenance of databases. Some of these recurrent security problems are generic and affect nearly every database we have tested. Others are associated only with a particular vendor or version.
n example of the latter is the Oracle database. Back in the dim and distant past of 2001, Oracle ran their ‘Unbreakable’ campaign; a bold move which attracted attention from the hacking community. However, we continually see the same issue: credentials. On installation the Oracle database server has a set of around 14 default passwords, and these are frequently left as default, instead of changing them for stronger passwords.
A
To gain access to the database, one needs to find a set of default credentials to an account with ‘create library’ permissions'. Account name DBSNMP, with default password of DBSNMP is used by the Oracle Intelligent Agent. Using this account, the attacker can log on as database administrator, giving them ownership of the database.
Infosecurity Today November/December 2006
Once one has control of the database, the password hashes can be dumped and cracked offline, as Oracle password encryption isn’t particularly strong by default. Databases in an organization usually use common administrator passwords. Hence, it only takes one default or weak password on one database in the organisation to potentially give access to all similar databases. We also find that we can enumerate the database using the Oracle TNS Listener service because there is rarely a password set, or it’s left in default. There is a simple solution: remove or rename default accounts and set strong passwords.
Microsoft’s SQL Server also has a fundamental configuration issue, again credentials-related. Like MySQL the root user or systems administrator (SA) often has no password set or it is set to ‘SA’ or ‘password’ even though there’s a clear prompt to set a password on installation. SQL Server is usually configured with the highest privilege running, so if there’s no SA password, or it’s easily guessed, then the ‘xp_cmdshell’ stored procedure is usually available. This allows one to execute database queries and DOS-like commands, which means one could access the underlying operating system and execute OS commands. There’s a similar problem on some Sybase systems, which can also provide the attacker with total ownership. In our experience implementations of MySQL tend to be more secure than SQL Server, although we occasionally find TCP port 3306 left open to the Internet. There is rarely a need for this service to be publicly available so close it. We also find old vulnerable versions running when an update is available. Keep yourself informed of versioning via manufacturer web sites and assess likely installation or configuration issues in user forums and groups. One not so common but deadly issue is that MySQL has an extremely powerful functionality called UDF Functions. This can allow you to write your own libraries which
MySQL can then load into memory. All well and good but SQL injection can be performed on a site running MySQL. Using UDF it’s possible to inject your library and take ownership of the server. Due to their small scale it’s not often that we specifically test file-based databases such as FoxPro or Access. But when we do, the perennial favourite is exploring NFS shares for files. Usually they are world readable and give up the contents of much of the database. Database password issues are sometimes a result of insecure coding practices – developers write applications that require, for example, a blank SA password. Third party applications that run over databases often require default credentials. Don’t accept this: require that your developers code secure methods of transacting with a database, and application vendors helpdesks usually have a workaround available to secure your DB. If we had to cite a common cause for these issues it would be that database administrators (DBAs) simply don’t have the time, skills or resources to dedicate to securing their databases. They have their work cut out just managing and maintaining the database. With availability the main driver, security is often sidelined.
•
Ken Munro is the managing director of Secure Test.
42