The second type of privilege elevation technique perpetrators employ is the SQL injection through stored procedures attack. Stored procedures are written in a manner that uses their parameters to construct SQL statements which are then executed with the privilege of the procedure owner. As a consequence, a perpetrator that is only allowed to execute a stored procedure can actually execute any SQL statement with administrative privileges (assuming that in most scenarios, the owner of the stored procedure is an administrative user, exposing some reduced functionality to less privileged users).
A third type of privilege elevation attacks take advantage of SQL parsing vulnerabilities such as the one reported by Oracle in 2007 (see http://www.red-database-security.com/advisory/oracle_view_vulnerability.html). This vulnerability allows an attacker to create a special database view that provides unauthorized INSERT, UPDATE or DELETE capabilities on database tables. All these privilege elevation techniques can be employed using basic database client tools such as the tools provided with the Microsoft Office suite or with the default database client installation.
A newer and lesser known, yet incredibly clever attack technique exploits the vulnerabilities inherent in the implementation of database network communication protocols. These proprietary protocols are used for client-server communication and include a host of security vulnerabilities an attacker could exploit to gain control over the server. To do this, a perpetrator can use a simple text editor, though some require a standard Telnet client, and others require more sophisticated network control tools. There are no internal mechanisms within a database server to proactively protect against this type of attack.
5. Covering the Tracks
The smart thief knows how to strike and leave undetected. This also applies to database criminals, who have several ways to cover their tracks. In many instances, the perpetrator doesn't even have to worry, since internal audit mechanisms are rarely activated due to performance and disk space concerns. In many of the attack methods discussed, the thief's actions would not trigger an alert. Servers with audit trail functionality activated are typically set to track unusual conditions that are the result of unsuccessful executions. However, most of the techniques previously discussed do not invoke these conditions but rather yield successful execution of the SQL statements.
Let's assume though that we do have a properly configured audit mechanism on our database server. The first step a perpetrator would take upon completion of a successful privilege elevation attack would be to turn off logging. In most deployments, a criminal with administrative privileges can also tamper with the existing audit trail, erasing any trace of the attack steps that preceded the privilege elevation.