Yuzi download

En la pasada Defcon 23 se liberó una aplicación denominada NetRipper. Esta aplicación es una herramienta de post-explotación que permite interceptar el tráfico de red y, por ejemplo, es capaz de capturar tanto el tráfico en plano y el cifrado. En otras palabras, podremos hookear los navegadores de la máquina y robar las credenciales de Gmail, Facebook, Twitter u Outlook, ya que estamos en un nivel inferior, antes de que el HSTS haga su juego. También podremos extraer cookies de sesión, por lo que si la víctima tiene algún servicio al que se conecta con cookie persistente se podría sustraer.

Metasploit: Cómo hookear con NetRipper los navegadores para robar las contraseñas

La herramienta tiene una versión para Windows con un binario o .EXE, una versión para PowerShell y otra versión en forma de módulo de Metasploit. A mí me llamó la atención tanto el script de PowerShell, ya que se podría utilizar con el Powershell Empire y utilizarlo como script de post-explotación y la versión de Metasploit, ya que junto a una sesión de Meterpreter podríamos hacer grandes cosas. Para este artículo decidí orientarlo hacia el caso de Metasploit.

Instalación de NetRipper en Metasploit

Tal y como se puede leer en el Github de la herramienta, su instalación es básica, simplemente descargar los ficheros, por ejemplo, con un git clone. Después, hay que seguir los pasos que se detallan a continuación:

Figura 2: Instalación de NetRipper en Metasploit

Cómo se puede ver el proceso de instalación o de adición al framework es sencillo. Antes de continuar con el artículo vamos a pararnos a visualizar la siguiente imagen sobre dónde NetRipper se inyecta y cómo funciona.

Figura 3: Esquema de hooking de NetRipper

Se puede consultar más detalles sobre la charla de la Defcon y sobre el funcionamiento de la herramienta en la dirección URL de las diapositivas de Ionut Popescu, autor de la investigación y de la herramienta.

PoC: Hookeando navegadores y obteniendo contraseñas de Gmail o Facebook

La prueba de concepto la comenzamos en el estado en el que el auditor o el atacante ya tienen la sesión de Meterpreter conseguida. Sin perder la sesión ejecutamos el comando background y, posteriormente, cargamos el módulo de netripper con la instrucción use post/windows/gather/netripper. Tal y como se puede ver en la imagen, el módulo ofrece diferentes opciones, a través de sus atributos.

Figura 4: Opciones de NetRipper

Hay varios atributos que tenemos que configurar. El primero, y el requerido sí o sí, es el identificador de sesión. Tenemos que indicar por cual sesión queremos ejecutar el módulo de post-explotación. En esta prueba de concepto utilizaremos la sesión número 1 conseguida previamente para ejecutar el código.

Por otro lado, hay que configurar el atributo PROCESSNAMES, indicando cual es el nombre del proceso al que NetRipper debe hacer el hook. Para este ejemplo, utilizaremos iexplore.exe, para ello ejecutamos set PROCESSNAMES iexplore.exe. Podríamos separar por comas e intentar hacer hooking a más procesos que nos interesasen.

Una vez configurado se puede ejecutar el comando run y el módulo será ejecutado a través de la sesión de Meterpreter. El módulo listará los procesos y se quedará con los procesos que encajen con los valores indicados en el atributo PROCESSNAMES, tal y como se puede ver en la imagen.

Figura 5: Hooking en Internet Explorer

En este instante vemos que tenemos 2 procesos de Internet Explorer hookeados. En la siguiente ruta de la máquina comprometida se comenzará a escribir ficheros de texto con las peticiones HTTP que el navegador envía, justo antes de que se cifren.

Figura 6: Ficheros con peticiones HTTP realizadas

Si echamos un ojo, por ejemplo al fichero que comienza con el PID_iexplore.exe_EncryptMessage.txt podemos ver las peticiones en texto plano. La máquina víctima es un Windows 8.1, se puede ver en la petición a través del User-Agent. La petición POST queda al descubierto con NetRipper y obtenemos el usuario y contraseña.

Figura 7: Fichero con petición HTTP que almacena usuario y contraseña de Google

Es cierto que un KeyLogger podría darnos un resultado similar, y Metasploit también tiene esta posibilidad. Lo que no lograríamos sería la limpieza y todos los datos que obtenemos con NetRipper, ya que como se mencionó anteriormente, quizá solo podamos robar una cookie y eso ya es mucho. Si la víctima visita Facebook y hace login o simplemente tiene una sesión abierta, le podríamos robar la cookie de sesión.

Figura 8: Credenciales de Facebook en sesión HTTP

En la siguiente anterior vemos cómo robar la contraseña de Facebook, lo único que tenemos que hacer es visualizar el fichero indicado anteriormente. Como nota aclaratoria, con Meterpreter podremos descargar los ficheros de texto con esta información que NetRipper genera en la máquina comprometida. El comando que debemos utilizar es download [ruta origen] [ruta destino].

Una PoC de NetRipper para robar cuentas de Facebook en vídeo

En el siguiente vídeo tienes un ejemplo de cómo un Windows 8.1 es vulnerado con Metasploit a través de una versión vulnerable de Easy File Sharing FTP. Una vez que el equipo con Windows 8.1 es controlado con Meterpreter, se utiliza el módulo de post-explotación de NetRipper para hookear Internet Explorer y robar las credenciales de un inicio de sesión en Facebook.

NetRipper es una potente herramienta integrada con el framework de Metasploit, lo cual hace que un proceso complejo o que pueda llevarnos más tiempo en una auditoría podemos realizarlo rápidamente. Interesante herramienta que debemos llevar en la mochila en una auditoría interna.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”

Una de las partes que se revisa en detalle cuando se hace un pentesting a una compañía es el servidor DNS. Los registros que allí se encuentran pueden dar mucha información. Desde conocer la infraestructura del Active Directory - buscando los registros que genera este servicio - o la infraestructura de la red - buscando los registros PTR, SRV, WPAD o el Primary Name Server -, hasta llegar a conocer información sobre la versión del DNS, el software sobre el que está construido el servicio, dónde navegan sus usuarios, el software de los clientes - inluidos los antivirus -,  etcétera. Y entre otras, las opciones de seguridad en los servicios de correo electrónico.

Es en este último servicio de correo electrónico, donde más información se puede obtener sobre la seguridad del mismo. Desde información de la infraestructura con los servicios MX y SPF, hasta las políticas antispoofing y antispam con la información de las políticas en las configuraciones DKIM, SPF o SenderID o DMARC (y en el futuro con los registros de SMTP STS). Todos ellos permiten saber a un atacante si va a poder realizar con facilidad o dificultad un ataque de Spear Phishing a la organización.

A todos ellos, hay que añadir un par de registros DNS que pueden ayudar a un atacante a reconcoer que la empresa está utilizando Microsoft Office365 o Windows Live Mail. Los registros son de tipo TXT y son necesarios para validar el dominio de la organización.

Esta validación es obligada por Microsoft cuando contratas un dominio nuevo personalizado para Office365, para evitar que nadie suplante el dominio y basta con hacer una búsqueda de registros TXT en el dominio objetivo para ver si están allí. Son los que comienzan por "MS=XXXXXXXX"

Esta es la forma en la que Microsoft valida el dominio. En el caso de que sea un dominio del antiguo Windows Live Mail, el registro tiene un aspecto como "v=msv1 t=XXXXXXXXX", pero también indica la existencia del backend de Microsoft. 

Para detectar Gmail, basta con mirar el DNS y fijarse en dos registros TXT. El primero el de "Google-Site-Verification", que indica que se ha validado el dominio con Google - pero no es concluyente porque se puede validar el domino sin tene el correo en Gmail - y el registro SPF, donde debe aparecer incluido el valor _spf.google.com como uno de los enviadores de correo autorizados, ya que ese registro de Google es el que incluye las direcciones IP utilizadas por Gmail para enviar los mensajes de e-mail.

Por supuesto, que estén los registros DNS ahí puede no significar nada si el administrador del servidor DNS los dejó allí olvidados después de validar los dominios o configurar el servicio, pero es un indicio más que útil en la mayoría de los casos. ¿Conoces algún otro registro DNS de validación que obligue a crear algún sistema en los DNS de las organizaciones?

Conocer que una organización tiene como plataforma Office365 o Gmail es útil para aquellos ataques de Spear Apps que se quieran realizar contra una organización, como ya os contamos en la serie de artículos de SAPPO: Spear Apps to stealth OAuths Tokens. Es necesario, ya que dependiendo de cuál sea el ID Provider, la app maliciosa y la API que habrá que utilizar será distinta y, con solo mirar estos registros se puede saber qué utiliza la organización.

Saludos Malignos!

Hace tiempo que publiqué el artículo que explicaba que cuando usas Google Authenticator, si no haces ningún intento de resolver el valor del TOTP, Google no te deja ningún rastro. Esto es una mala idea de seguridad porque entonces nunca serías consciente de que alguien te ha robado la contraseña y está solo a un paso - robarte el segundo factor con alguno de los trucos que contaba ayer - de quitarte tu cuenta. Hoy quise revisar cómo gestiona Microsoft esta situación en Hotmail, a.k.a Windows Live Mail, a.k.a. Outlook.com, para ver si lo hacía bien o lo hacía mal. Y lo hace mejor que Google.

Si has visto el título, ya te podrás imaginar que en este caso, el log de tu cuenta de Microsoft sí que refleja correctamente la situación que yo que describo. Para comprobarlo, tenemos que ir a la página de Actividad Reciente de tu cuenta, donde que da información de todos los accesos que se hacen a ella y veremos el último acceso correcto a la cuenta - he borrado toda la información anterior, así que solo me muestra el último acceso -.

Ahora vamos a abrir otra sesión desde otro navegador en Modo Incógnito y ponemos correctamente la contraseña, pero nos quedamos en la parte donde se nos solita la verificación del segundo factor de autenticación - que en este caso es un OTP vía SMS o vía e-mail asociado -. Y no respondemos nunca a esta pregunta porque somos un atacante y aún no hemos resuelto el problema de robar el 2nd Factor Authentication.

Si refrescamos el listado al que podemos acceder vía Actividad Reciente en nuestra cuenta de Microsoft, veremos que ahora aparece una entrada con el identificador de "Security Challenge", lo que refleja justo esta situación.

Si nos vamos a la ayuda de Microsoft veremos que el log al que podemos acceder es de lo más florido y refleja cualquier situación de seguridad que haya tenido que ver con nuestra cuenta. Desde el acceso correcto o el Security Challenge hasta cualquier cambio que suceda en alguna de las propiedades de seguridad de la cuenta. La lista completa la tienes haciendo clic en la imagen.

En definitiva, que me gusta más este log que el que tiene Google, aunque por desgracia la mayoría de los usuarios no revisan estos detalles de su cuenta periódicamente. Aquí os dejé unas acciones extras para saber si te estaban espiando tu cuenta de Hotmail/Live/Outlook o Gmail ahora mismo.

Saludos Malignos!