Mi write-up noviembre "uno al mes"

He subido mi write-up del reto de noviembre de "uno al mes".

write-up: https://anonfile.com/k099fbd1ba/write_up_unaalmes_15-11-17.pdf
reto: http://unaaldia.hispasec.com/2017/11/quieres-jugar-un-juego-demuestra-tus.html

Enjoy!

Troyano bancario Trickbot - webinjects y bancos españoles.

Trickbot es un troyano bancario que se estima que lleva funcionando desde el 2016 y que afecta a una gran cantidad de bancos y de entre ellos a muchos españoles.

Se han escrito varios artículos sobre su funcionamiento, persistencia, tipos de inyecciones, etc. De modo que sólo quiero tratar el tema de los webinjects o inyecciones dimámicas (dinj).

Una vez Trickbot se ha instalado en el sistema y demás, inspecciona la lista de procesos en busca de los tres principales navegadores: firefox, chrome y iexplore. Si encuentra uno de ellos, reserva espacio de memoria dentro de cada uno de los procesos e inyecta una dll que es la encargada de realizar el hooking para inspeccionar y alterar el tráfico entre nuestro navegador y el servidor web del banco.

De entre la lista de bancos afectados, están los siguientes españoles:

caixaontinyent.es
cajamar.es
bancopopular.es
caja-ingenieros.es
caixabank.es
lacaixa.es
finconsum.es
cetelem.es
liberbankbancaprivada.es
openbank.es
bmn.es
cajasur.es
kutxabank.es
y más...

Voy a realizar una prueba con mi banco, ya que me preocupa especialmente porque es dónde tengo mi dinero.

Al conectar a cajamar.es con el navegador Internet Explorer versión 11, se puede apreciar que Trickbot ha instalado un hook en la función HttpSendRequestW dentro de la librería WININET.DLL realizando un salto incondicional JMP hacia la dirección 0x0A1EBFA0:

Hook instalado en la función HttpSendRequestW

Para que se pueda apreciar la diferencia entre la función hookeada y la que no lo está, hice la misma prueba pero sin Trickbot instalado.

Sin hook instalado

Una vez da el salto al hook, Trickbot realiza las comprobaciones para determinar si el sitio al que se ha conectado el usuario está entre la lista de las inyecciones dinámicas o "dinj". En ese caso, realiza una petición con el servidor malicioso y devuelve, entre otra información, la inyección a realizar en el sitio web:

Inicio de la inyección en cajamar.es

Función Javascript que roba credenciales de acceso a la banca electrónica de cajamar.es

Para que la inyección pueda realizarse sobre el sitio legítimo, Trickbot tiene que hookear la función InternetReadFile dentro de la librería WININET.DLL que es la encargada de leer la respuesta del servidor web bancario y alterarla para poder incluir la inyección correspondiente:

Hook instalado encargado de devolver a petición al navegador con la inyección

Una mitigación que se puede implementar desde el lado del servidor web del banco, es leer la cookie "tknz_referrer" para determinar si el usuario/cliente del banco está infectado y actuar en consecuencia.

TOR con Python y cambiar circuito programáticamente

En este artículo voy a mostrar cómo tunelizar todas las conexiones de nuestro script Python y además la posibilidad de cambiar de circuito para salir cada vez por una IP distinta.

Los ingredientes necesarios son Python y TOR, obviamente. Una vez tenemos nuestro sistema listo, debemos configurar TOR habilitando la directiva ControlPort para poder interactuar con el servicio por medio del puerto configurado:

/etc/tor/torrc

Para esta prueba de concepto, he deshabilitado la autenticación del puerto de control CookieAuthentication con el valor 0. Para sistemas en producción configurar este valor adecuadamente.

Reiniciamos nuestra instancia TOR y vamos al código:

Ejemplo de ejecución:

Para cambiar el circuito, básicamente se establece una conexión en texto plano al puerto 9051 sin autenticación y se envía el comando "SIGNAL NEWNYM". Establecemos un tiempo de espera de 10 segundos para dar tiempo a que se cambie el circuito. 

Wordlist para fuzzing web con Apache y Logrotate

Crear una wordlist para fuzzing web puede ser relativamente sencillo, efectivo y sin apenas esfuerzo aprovechando la tecnología y la "inteligencia" que nos brindan los diferentes actores que ponen a prueba nuestro servidor web Apache donde tenemos alojadas nuestras webs, honeypots, etc.

Los ingredientes necesarios son un servidor web Apache y Logrotate. Para el que no sepa que es Logrotate, como su nombre indica, nos permite realizar rotación de archivos evitando que crezcan y nos colapsen el espacio de disco duro. Para ello se vale de varias directivas y demás. Para nuestro propósito nos valdremos de la directiva "prerotate".

Abrimos el archivo "/etc/logrotate.d/apache2" y justo debajo de "prerotate", añadimos:

PATH_LOGS="/var/log/apache2/*.log"
PATH_WORDLIST="/home/cukz"
grep "HTTP/1.1\" 404" $PATH_LOGS | awk '{print $7 } ' | sort | uniq | sort >> $PATH_WORDLIST/wordlist.tmp && cat $PATH_WORDLIST/wordlist.tmp | sort | uniq > $PATH_WORDLIST/wordlist.txt

Modificar la variable "PATH_LOGS" y "PATH_WORDLIST" con los valores adecuados según nuestro sistema.

Quedaría algo así:

Logrotate se ejecutará diariamente gracias a cron y en la ruta "PATH_WORDLIST" tendremos un archivo ordenado con todas las peticiones 404 que se hayan realizado sobre nuestro servidor web.

Hay que tener en cuenta que no todas las peticiones nos valdrán para nuestro diccionario, nos tocará filtrarlo y eliminar lo que no nos interese.

Esta wordlist también nos puede valer para realizar un posterior análisis forense, estudiar tendencias de ataques, etc.