hackivista

Kitty

Este artículo será el primero de una serie dedicada a la vulnerabilidad conocida como DLL Hijacking. Haremos una breve introducción y veremos cómo llevar a cabo una primera fase de descubrimiento de posibles aplicaciones candidatas a ser vulnerables a DLL Hijacking.

Para entender bien en qué consiste esta vulnerabilidad tenemos que tener claro cuál es la funcionalidad de estos ficheros en nuestros sistemas Windows, de los cuales encontraremos muchos repartidos por nuestro sistema de ficheros.
El uso de DLL, Dynamic Link Library, es el método más utilizado por Windows y aplicaciones para compartir funciones, haciendo que las aplicaciones sean más modulares y permita reutilizar funciones comunes que ya están desarrolladas y que son exportadas por estas librerías

La idea es que cualquier ejecutable pueda cargar funciones de estas librerías, aprovechando el desarrollo ya realizado. Por ejemplo, hay funciones comunes que testean la disponibilidad de la red, la conexión a Internet o la presencia de una impresora.

Pero, ¿qué pasaría si la aplicación no encuentra una DLL que intenta cargar? ¿Podría un atacante suplantar esa DLL creando una personalizada con código malicioso? Aunque existen métodos para evitar esto, la respuesta más correcta sería que si.

Para poder descubrir si una aplicación es vulnerable a DLL Hijacking, tendríamos que poder monitorizar el proceso de la aplicación para ver qué ficheros son los que carga, o intenta cargar. Esta parte es la más importante del descubrimiento.

Vamos a utilizar la herramienta de Sysinternals para monitorizar procesos, Process Monitor, o Procmon. Con esta herramienta podremos ver todos los eventos que se generan en nuestro sistema, con información de procesos, claves de registro o archivos, entre otra información.

Son muchos los eventos que se muestran en Procmon, miles de eventos, lo que nos va a dificultar encontrar la información que nos pueda revelar si una aplicación es candidata a ser vulnerable a DLL Hijacking. Por esta razón necesitamos utilizar los filtros que Procmon dispone

Eventos cuyo Process Name sea el nombre del proceso de la aplicación que estamos testeando. Eventos cuyo Path finalicen en “dll” (estamos buscando referencias a archivos de tipo DLL). Eventos cuyo Result sean “NAME NOT FOUND“, lo que indicará que no se ha encontrado ese fichero DLL

Con estos tres filtros, obtendremos eventos de la aplicación de intentos fallidos de carga de DLL, al no encontrarse estos ficheros. En función del PATH donde haya intentado cargar la DLL, la complejidad de la explotación de esta vulnerabilidad variaría.

La razón es que nos resultará mucho más fácil suplantar una DLL si la aplicación la busca por ejemplo primero en el mismo directorio desde donde se ejecutó la aplicación que si lo busca en el directorio de Windows, al que quizás no tengamos permisos para escribir nuestra DLL.

En los sistemas Windows, este orden ya está preestablecido, y varía en función de si la clave de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode está activada o no.

Para que los filtros sean lo más efectivos posibles, deberíamos de pensar en cuáles son los criterios importantes para encontrar aplicaciones vulnerables. Los filtros que vamos a aplicar contendrán los siguientes criterios: - See more at: http://hacking-etico.com/2015/07/13/dll-hijacking-descubriendo-posibles-aplicaciones-vulnerables/#sthash.l3PQZzqq.dpuf

Una vez aclarada la importancia del orden de búsqueda de las DLL, veamos cómo quedarían los filtros en Procmon.

Y ahora, después de aplicar los filtros, veamos cómo quedarían los eventos filtrados.

En la imagen anterior, podemos comprobar que hay varios ficheros DLL que la aplicación no ha podido cargar, por lo tanto estas DLL son candidatas a ser usadas para explotar una posible vulnerabilidad de DLL Hijacking en esta aplicación

En el siguiente artículo veremos cómo preparar nuestra DLL personalizada para hacer una primera prueba de concepto de explotación de esta interesante vulnerabilidad.

Para poder descubrir si una aplicación es vulnerable a DLL Hijacking, tendríamos que poder monitorizar el proceso de la aplicación para ver qué ficheros son los que carga, o intenta cargar. Esta parte es la más importante del descubrimiento. - See more at: http://hacking-etico.com/2015/07/13/dll-hijacking-descubriendo-posibles-aplicaciones-vulnerables/#sthash.l3PQZzqq.dpuf

El uso de DLL, Dynamic Link Library, es el método más utilizado por Windows y aplicaciones para compartir funciones, haciendo que las aplicaciones sean más modulares y permita reutilizar funciones comunes que ya están desarrolladas y que son exportadas por estas librerías - See more at: http://hacking-etico.com/2015/07/13/dll-hijacking-descubriendo-posibles-aplicaciones-vulnerables/#sthash.l3PQZzqq.dpuf

En este post veremos que sólo 20 líneas de python son las necesarias para complementar el comportamiento de un sniffer y lograr que éste cumpla con nuestras necesidades. No obstante, el objetivo principal es proporcionar una introducción práctica a la librería scapy.

Este script resulta útil cuando en las auditorías wifi se requiere el conocimiento de los distintos AP de la organización que están a nuestro alcance. Un objetivo claro puede ser, por ejemplo, suplantar la identidad de los puntos de acceso para el envío de paquetes de desautenticación a las estaciones clientes.

Evidentemente esta tarea se puede realizar de forma manual, simplemente lanzado airodump-ng y anotando los bssid de interés, y cruzando los dedos para que no existan demasiados puntos de acceso. No obstante, contemplar las posibilidades del script resulta interesante, ya que son muy extensas. Por ejemplo, con pocas líneas es posible automatizar el envío de los paquetes de desautenticación y al final, todo se reducirá en un cd y un enter.

Para hacer uso del script, como siempre, debemos disponer de nuestra tarjeta en modo monitor:

- See more at: http://hacking-etico.com/2016/02/16/bss-id-finder/#sthash.gKKCKQNW.dpuf