Backup-ToSystem: abusando de los permisos de "Backup operators" y el servicio VDS

Buenas, ¿cómo andas cabeshas de mal? Mi nombre es Luis Vacas o CyberVaca como me conocen algunos… y en este post hablaremos sobre los permisos que se otorgan al grupo de “Backup Operators”


SeBackupPrivilege

➔ "Permite al usuario eludir los permisos de archivos y directorios para hacer una copia de seguridad del sistema. Tiene sentido que exista este privilegio para que se pueda realizar backups del sistema. El privilegio se selecciona sólo cuando la aplicación intenta acceder a través de la interfaz de la aplicación de copia de seguridad NTFS. De lo contrario, se aplican los permisos normales de archivos y directorios"

➔ Con este privilegio se puede hacer fácilmente una copia de seguridad del registro de Windows y utilizar herramientas de terceros para extraer los hashes locales de NTLM. Cómo por ejemplo secretsdump.py de impacket.

Hasta aquí todo correcto, pero un momento, si este privilegio permite leer todos los archivos del sistema, quizá podamos aprovecharnos de ello. Así que intentaremos cambiar las ACL de algún path en el que no deberíamos poder escribir, pero espera ¿Qué diablos es un ACL?

ACL

➔ Una lista de control de acceso (ACL), con respecto a un sistema, es una lista de permisos adjunta a un objeto. Una ACL especifica qué usuarios o procesos del sistema tienen acceso a los objetos, así como qué operaciones están permitidas en determinados objetos. Cada entrada de una ACL especifica un usuario o grupo y una operación. Por ejemplo, si un objeto de archivo tiene una ACL que contiene (Administrador: leer, escribir; Pepe: leer), esto le daría a Administrador permiso para leer y escribir el archivo y a Pepe sólo para leerlo.

Bueno, ya que tenemos claro los conceptos vamos a ver si podemos abusar de él.
Primero vamos a sacar las ACLs de un path en el que no deberíamos poder escribir, como por ejemplo “c:\windows\system32\drivers\etc\”.


Por lo que si nosotros intentamos crear un fichero con nuestro usuario hackplayers_backup, no nos lo debería permitir en ese path. Así que intentamos hacer un “echo hola > c:\windows\system32\drivers\etc


Efectivamente el sistema no nos lo permite. Pero lo que si podemos hacer es cambiar los permisos del path y hacernos propietarios de dicho path. Para ello usaremos un script que subimos hace algunos meses al github de hackplayers, Acl-FullControl. Que cargaremos en nuestra sesión de Evil-WinRM.


En el caso de que no estéis usando Evil-WinRM, bastaría con usar Import-module .\Acl-FullControl.ps1. No obstante, como Evil-WinRM es una aplicación de Hackplayers, pues la usamos. Ejecutamos Acl-FullControl para ver que datos se los solicita.


El script es bien sencillo, nos pide que le pasemos un dominio + usuario (“si no hay dominio es el hostname de la máquina”) y también nos pide el path al que le queremos cambiar los permisos, sencillote ¿no?, veamos si funciona.


Estupendo parece que ya nos hemos hecho con el control de la carpeta.

- ¿Con esto ya podemos escribir en la ruta?
- No cabesha, aún no es posible, ahora faltaría asignarnos permisos de lectura y escritura.

Bastaría con copiar las ACL de algún sitio donde podamos escribir y asignárselo a este path. Así que obtendremos las ACL de un path en el que podamos escribir y se lo estableceremos a “c:\windows\system32\drivers\etc”, en nuestro caso escogeremos un path donde cualquier usuario del sistema, puede escribir (“c:\programdata”).


Pues bastaría con establecer esta acl a la ruta objetivo. Nosotros usaremos los cmdlets de powershell que están vigentes en powershell desde la versión 3.0 de powershell. Para ello haremos un get-acl y lo empiparemos a set-acl y al path objetivo.


Y efectivamente ya podemos escribir en este path en el que no deberíamos tener permisos.


    • Bien, parece que esto mola. Pero… ¿podríamos escalar privilegios con esto?
    • Off course, my weapon. (Pues claro, mi arma)

Podríamos escribir un binario en alguna parte que sepamos que en un reinicio sería ejecutado. Pero no nos gusta esperar, así que os contaremos algo. El servicio de Microsoft Windows VDS.

VDS Service

➔ El Servicio de disco virtual es un servicio de Microsoft Windows que realiza operaciones de consulta y configuración a petición de los usuarios finales, scripts y aplicaciones. El servicio amplía las capacidades de almacenamiento existentes de los sistemas operativos de Windows Server. Y si estamos dentro del grupo de "backups operators", podemos pararlo y arrancarlo.

De tal manera que podríamos usar la técnica que acabamos de ver, para hacernos con el binario del servicio VDS que esta en “c:\windows\system32\vds.exe”.

    • ¿Cuál es nuestro plan?

    1. Guardar un backup de las ACLs de c:\windows\system32
    2. Hacernos con el control de c:\windows\system32
    3. Establecer una ACL de lectura y escritura
    4. Modificar el binario del servicio vds
    5. Arrancar el servicio vds con nuestro binario maligno
    6. Dejar el sistema como estaba antes del ataque.

Pero esto es un rollo hacerlo mano, ¿Somos hacker o somos fucking loosers? De modo que para realizar todo este ataque concatenando características de Windows hemos creado el script de powershell “Backup-ToSystem”. El módulo lo tenéis disponible aquí. (“https://raw.githubusercontent.com/Hackplayers/PsCabesha-tools/master/Privesc/Backup-ToSystem.ps1”)


Como veis el módulo, sólo nos solicita introducir el comando a ejecutar.

Ejecutaremos el modulo e intentaremos crear un usuario. Pero antes comprobaremos que efectivamente nosotros no tenemos los permisos suficientes como para crear usuarios en el sistema.


Ejecutamos el módulo pasandole de comando la creación de un usuario:

Backup-ToSystem -command "net user Luis.Vacas Hackplayers20 /add"


Efectivamente nuestro módulo está ejecutándose como system, por lo que podríamos ejecutar lo que quisiéramos como authority system. Ya para terminar lo que haremos es crear una Shell con nuestra herramienta de generación de Shells Reversas. Que tenéis en (“https://github.com/Hackplayers/ReverseShell”)


Nos copiamos todo el base64 y se lo pasamos a Backup-ToSystem como argumento y en otra Shell dejamos un netcat a la escucha.


De esta manera obtendríamos nuestra querida Shell de “nt authority\system”. De modo que ya sabéis si tenéis los privilegios de Backup, es un Game Over en toda regla. Espero que os haya gustado, al menos a mi me ha entretenido explicároslo. Un saludo.

Comentarios

  1. Que bueno!
    Me hubiese venido de perlas hace un par de dias xD
    Buen post!
    Gracias

    ResponderEliminar
  2. Pues para la proxima ya sabes!! Me alegro de que te gustara.

    ResponderEliminar
  3. Gran trabajo luis, como siempre...

    ResponderEliminar
  4. muy bueno y mejor explicado, muchas gracias!

    ResponderEliminar

Publicar un comentario