Yuzi download

En los últimos meses hemos hablado bastante sobre debilidades en la memoria RAM y la información que podemos encontrar en ella. Echando la vista atrás podemos encontrar “Cómo sacar la contraseña de Gmail de la memoria del proceso de Firefox utilizando Metasploit”, “Cómo proteger tu password cuando está en memoria RAM” o “Cómo volcar credenciales del proceso KeePass con Meterpreter”. Esta serie de artículos nos dio para poner de relevancia que la memoria RAM es un entorno muy volátil, pero a la par bastante inseguro por naturaleza y con información sensible, por lo que hay que proteger cualquier volcado que se haga de ella como si fueran datos de una aplicación. La fase de post-explotación, a día de hoy, tiene un punto marcado a fuego dónde debemos verificar que no podemos extraer identidades digitales de la memoria RAM.

Figura 1: Mimikittenz. Dumpea passwords de la RAM "like a boss"

Hace no más de una semana se ha liberado una herramienta llamada Mimikittez, la cual es un script de Powershell para pentesters, que se encarga de leer diferentes procesos, que podemos definir, y lanzar expresiones regulares en busca de leaks con contraseñas y usuarios. El script es potente, ya que podríamos utilizarlo a través de una sesión de Metasploit con el payload de Powershell, y poder aprovecharnos en remoto de esta característica. No hay que olvidar a Netripper que también nos permite, a través de Powershell, hookear procesos e interceptar, antes de que sea cifrado, el contenido de la comunicación.

Mimikittenz es una herramienta de post-explotación dónde se utiliza la función ReadProcessMemory() para extraer las credenciales en texto plano de varios procesos. La herramienta también puede extraer otro tipo de información definida como jugosa de otros procesos. Además, la herramienta no está atada a ser ejecutada con privilegios de administrador, se puede utilizar desde un contexto de usuario, siempre y cuando los procesos sean del usuario en cuestión.

Figura 2: Mimikittenz en GitHub

Mimikittenz presenta una estructura interesante y extensible gracias a dos funciones: AddRegex e InspectManyProcs. La primera permite que, con un poco de maña, manipulemos el script con el objetivo de añadir expresiones regulares con las que comparar información en el análisis del proceso. Viendo el código encontramos esta función:

De forma sencilla podemos añadir expresiones regulares para realizar las búsquedas en los procesos. Si observamos el código de Powershell que presenta el script encontramos lo siguiente:

[mimikittenz.MemProcInspector]::InspectManyProcs("iexplore","chrome","firefox")

Es realmente sencillo añadir procesos que deben ser inspeccionados en busca de las expresiones regulares que configuremos.

Echando un ojo a la ejecución de Mimikittenz vemos como se mostraría la información tras una ejecución del script en la máquina. Mimikittenz va abriendo los diferentes procesos indicados anteriormente y leyendo de ellos el contenido en memoria RAM. En ese momento se van pasando las diferentes expresiones regulares en busca de coincidencias. En el caso de encontrar una coincidencia se almacena el valor para ser, posteriormente, mostrado.

Figura 3: Patrones coincidentes

Es una herramienta de post-explotación bastante interesante y que automatiza el proceso de mirar dentro de la memoria en busca de leaks de información sensible por parte de las aplicaciones. Para el caso del gestor KeePass se podría realizar una serie de expresiones regulares con la intención de obtener la información sensible de la memoria.

A modo de ejemplo, se añade una nueva expresión regular en el script de Mimikittenz. Como se puede ver es muy sencillo de añadir. La expresión regular funcionaría para el sitio web de “El Otro Lado”, pero también para otros muchos dónde se encontrara un parámetro denominado password seguido del signo “=” y con diversos caracteres después. En la siguiente imagen se puede ver cómo queda el código.

Figura 4: Añadir regexp

Actualmente, ya comenté que lleva apenas diez días en Github, la herramienta permite extraer credenciales de memoria RAM de diferentes servicios. La herramienta los agrupa por categorías, las cuales enumero a continuación:

• Webmail: Encontramos expresiones regulares para extraer credenciales de Gmail, Office 365 u Outlook Web.
• Accounting: Xero y MYOB.
• Acceso remoto: Tenemos disponibles expresiones regulares para Juniper SSL-VPN, Citrix NetScaler o Remote Desktop Web Access 2012.
• Desarrollo y seguimiento: Expresiones regulares para Jira, Github, Bugzilla, Zendesk o Cpanel.
• Miscelánea: Aquí nos encontramos con expresiones regulares para Malwr, VirusTotal, AnubisLabs, Dropbox, Microsoft Onedrive, AWS Web Services, Slack, Twitter o Facebook.

En el caso de la expresión regular añadida para "El Otro Lado" podemos ver como en la siguiente captura del navegador nos la encontramos. Otra variación sencilla de la herramienta es que permita leer capturas ya realizadas y sacar el máximo provecho al análisis forense de la memoria RAM, por lo que es una posibilidad muy interesante.

Figura 5: Búsqueda de contraseñas del volcado de memoria.

El potencial del script es alto, y lo que más me ha gustado es que es muy personalizable y de forma muy sencilla. Herramienta necesaria para nuestra mochila en la fase de post-explotación de sistemas Windows por dónde vayamos accediendo en la auditoria. Veremos a muchos pentesters llevando a Mimikittenz en su mochila alineada con nuestro Meterpreter para sacar el máximo provecho al “lateral movement”.

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

Esta semana hemos tenido un nuevo caso de vulnerabilidad mediática. HTTPoxy fue detectada por primera vez hace 15 años, por lo que no podemos decir que sea nueva, pero sí que es hoy cuando parece que se ha tomado realmente en serio. El problema es profundo, ya que se encuentra en librerías de código que son utilizadas para realizar peticiones HTTP dentro de una aplicación web. En el caso de que se viera afectada la aplicación por esta vulnerabilidad HTTPoxy todas las conexiones que realice podrían ser espiadas y modificadas.

Figura 1: Cómo explotar httpoxy en una aplicación PHP vulnerable

HTTPoxy ha retomado el escenario a través de aplicaciones basadas en CGI, escritas en PHP - como en el caso del famoso bug CVE-2012-1823 que tantos problemas generó, Python o Go. Han habilitado un Github dónde podemos encontrar diferentes pruebas de concepto, las cuales utilizan docker para montarlas, por lo que simplifica el escenario y aplicaciones a instalar.

Figura 2: GitHub con las PoC de HTTPoxy

La vulnerabilidad reside en cómo se procesan las cabeceras Proxy. En el año 2001, el fallo fue identificado en curl, en el año 2012 en Ruby y en el año 2013 en Nginx. Esta vez les ha tocado el turno a los lenguajes PHP, Python y Go. La vulnerabilidad tiene un CVSS, en base score, de 8,1. Para mayor detalle se puede encontrar más información en los siguientes CVE:

• CVE-2016-5385, correspondiente a PHP.
• CVE-2016-5386, correspondiente a Go.
• CVE-2016-5387, correspondiente a Apache HTTP Server.
• CVE-2016-1000110, correspondiente a Python.

¿Cómo funciona?

Cuando un atacante quiere explotar la vulnerabilidad necesita forzar que las aplicaciones web del servidor se crean que el header que obtienen con valor Proxy es la nueva dirección del servidor al que se tienen que conectar para enviar todas las conexiones HTTP. En otras palabras, es un abuso de la cabecera Proxy. Todo esto es provocado por un conflicto de nombres. En otras palabras, si nosotros como clientes malintencionados del servidor enviamos una cabecera “Proxy”, puede suceder que algunas implementaciones CGI creen una variable de entorno HTTP_PROXY, lo cual provoca que se anule la variable real que tiene el mismo nombre. Por esta razón decimos que la vulnerabilidad, realmente, es un conflicto de nombres que genera una sobreescritura del valor original - que podría ser null -.

Figura 3: Esquema de explotación de bug de HTTPoxy

Entonces, si sobrescribimos la variable de entorno HTTP_PROXY por una dirección bajo nuestro control podremos colocarnos en medio de la comunicación del servidor y cualquier punto con el que se comunique. Es decir, estamos realizando un Man in the Middle remoto. ¿Qué podemos hacer? En al PoC viene una pequeña demostración del robo de un Secret de una API, es decir, se muestra como se modifica el Proxy del servidor web en remoto y se consigue redirigir las peticiones que hace el servidor contra una API y capturamos el “secreto”.


Figura 4: BlackHat 2012 "Owning Bad Guys {and mafia} using JavaScript Botnets"
Aunque hemos hecho solo la captura del secreto los ataques de man in the middle vía Proxy permiten hacer de todo, como ya hicimos en la época de Informática64 con el trabajo de "Owning Bad Guys {and mafia} using JavaScript Botnets" en donde aprovechamos un servidor Proxy para infectar máquinas y crear una JavaScript Botnet o en el caso de Evil FOCA, donde se hacen ataques basados en las variables de Web Proxy Auto Discovery para hacer ataques de SSLStrip. Si estás en medio, puedes hacer todo lo que quieras.

Nuestra PoC de HTTPoxy para automatizar Faast

Mi compañero Ioseba Palop y yo montamos un entorno para probar esto y, posteriormente, añadir un plugin en nuestro sistema de pentesting persistente Faast para detectar esta vulnerabilidad. Como se dijo anteriormente utilizaremos docker para tener los contenedores de lo necesario. Para instalar docker solo tenemos que ejecutar:

apt-get install docker docker.io

Una vez lo tengamos instalado, debemos construir el dock. Para ello descargamos el código de la PoC de HTTPoxy desde Github. Una vez tengamos descargado el código ejecutamos docker build -t fpm-guzzle-proxy, tal y como se puede ver en la imagen.

Figura 5: Build de docker con la PoC de HTTPoxy

Después se descarga y crea el dock debemos ejecutarlo. Para ello utilizamos la instrucción:

docker run -d -p 80:80 –name fpm-test-instance fpm-guzzle-proxy

La sentencia -p 80:80 nos indica el puerto externo de docker y con qué puerto interno se mapea, en ambos casos es el puerto 80. El resultado tras la ejecución se puede ver en la siguiente imagen.

Figura 6: Ejecución de la PoC sobre Docker

Ya tenemos el entorno vulnerable montado, por lo que vamos utilizar la herramienta curl para generar una petición al servidor web y aplicación montada. La instrucción es:

curl -H ‘Proxy: [ip]:[puerto]’ [ip del servidor]

Es muy sencillo de entender lo que estamos haciendo. Nosotros somos el cliente y le estamos diciendo al servidor web que el Proxy es el que nos interese. Si la aplicación web es vulnerable ocurrirá lo comentado anteriormente, se sobrescribe la variable de entorno y cuando el servidor web realice peticiones la enviará al Proxy, es decir, a nosotros en este caso.

Figura 7: Ejecución con curl de la sobrescritura de la cabecera Proxy

Para poder entender que todo esto está funcionando, hemos habilitado un netcat en el puerto 12345, que coincide con la dirección y puerto dónde le dijimos al servidor vulnerable que estaría su Proxy. Como se puede ver en la imagen nos llega una petición POST dirigida a Facebook y que envía algo “secreto”.

Figura 8: Captura del secret en el servidor Proxy malicioso

Hemos modificado el código del cliente PHP que utiliza el servidor vulnerable, ya que como podéis ver en la imagen en los datos que se envían por POST aparece el parámetro ‘secret’. Para realmente ver los datos del POST, debemos cambiar el parámetro ‘secret’ por ‘body’, y posteriormente construir el dock y ejecutarlo de nuevo. Es un pequeño bug que tiene la prueba de concepto.

Figura 9: Modificación del código PHP de la PoC

La mitigación es obligada si eres vulnerable a HTTPoxy. Para llevar a cabo la mitigación se debe bloquear el uso de la cabecera Proxy cuanto antes. Como se ha visto es realmente sencillo caer en esta vulnerabilidad y el impacto y potencial de ésta es muy alto afectando a dos dimensiones de la seguridad como son la confidencialidad y la integridad de la información.

Autores: Ioseba Palop & Pablo González