Logjam: la puerta que dejó abierta el gobierno de Clinton hoy tiene que cerrarse (downgrade en Diffie-Hellman)

en la foto Diffie y Hellman, las dos crypto-leyendas
No corren buenos tiempos para las comunicaciones "seguras" en Internet, a las últimas vulnerabilidades conocidas BEAST, CRIME, Lucky Thirteen, BREACH, POODLE, Heartbleed y FREAK se le añade una nueva bautizada como Logjam que permite a un atacante en el medio de una comunicación cifrada (MiTM) hacer un downgrade de TLS hasta 512 bits, permitiendo leer o modificar cualquier dato en tiempo real.

Digamos que se trata de un ataque reminiscente de FREAK, pero el problema está en un fallo en el protocolo TLS en vez de en un fallo de implementación y ataca al intercambio de claves con Diffie-Hellman en lugar de al intercambio de claves con RSA. 


Afecta a cualquier servidor que soporte DHE_EXPORT y a todos los navegadores web modernos. Y, nada más y nada menos, el 8.4% del top un millón de dominios son en principio vulnerables.

Lo curioso es que esta vulnerabilidad viene de la conocida como cripto-guerra de la era Clinton en los 90, en la que se impusieron restricciones a la hora de exportar cifrados fuertes a naciones que EE.UU. consideraba hostiles, para que el FBI y otras agencias pudieran descifrar la información en caso necesario. Como resultado, muchos navegadores y servidores siguen llevando una rutina para utilizar un protocolo débil y fácil de romper. Es decir tenemos un bug vigente desde hace 20 años y del que se dice que ha sido utilizado en muchas ocasiones para romper el cifrado de algunas VPNs.

Podéis ver el paper académico de un grupo de investigadores de varias universidades y empresas (coordinados por Google) o visitar Weakdh.org para más detalle. También tenéis una herramienta en esta última web para comprobar si vuestro servidor es vulnerable y arreglarlo si es necesario:
https://weakdh.org/sysadmin.html.

Ya se están parcheando o se van a publicar pronto actualizaciones para Chrome, Firefox y otros navegadores. El problema es el que suele haber con estos ataques de "downgrade": parchear te hará incompatible con quién o qué no haya parcheado, por lo que muchos sitios web vulnerables dejarán de ser accesibles.

Fuentes:
- Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice (paper)
- The Logjam Attack 

- Crypto Wars
- Massive Clinton-era Internet bug shows pitfalls of Obama's 'backdoor' proposal
- The Logjam (and Another) Vulnerability against Diffie-Hellman Key Exchange
- 'Logjam' browser vulnerability fix will block thousands of websites
- Anatomy of a LOGJAM - another TLS vulnerability, and what to do about it
- Today's terrifying Web security vulnerability, courtesy of the 1990s crypto wars
- There’s a new problem with SSL called “Logjam”, here’s what you need to know
- 'Logjam' crypto bug could be how the NSA cracked VPNs

Hackeando Starbucks para conseguir café gratis ilimitado

Egor Homakov, desarrollador y hacker ruso, saltó a la "fama" en 2012 al hacerse admin en GitHub explotando una vulnerabilidad en Ruby on Rails (el framework utilizado por GitHub) que, pese a reportarla con anterioridad, no había sido solucionada. Ahora, Egor anda por San Francisco y nos trae otra bonita historia acerca de cómo encontró una manera de generar una cantidad ilimitada de dinero en tarjetas regalo de Starbucks. ¡Café gratis para siempre!... o hasta que te pillen... :-S


starbucks.com tiene cuentas de usuario, donde se pueden agregar tarjetas de regalo, comprobar saldos e incluso transferir dinero entre estas tarjetas de regalo. Hay un interesante tipo de vulnerabilidades llamada "condición de carrera", que es un error muy común en los sitios web con saldos, vales u otros recursos limitados (sobre todo dinero).

Egor compró tres tarjetas de 5$ cada una. Para transferir dinero de la Tarjeta1 a la Tarjeta2 se realizan dos simples peticiones POST: la primera /step1?amount=1&from=wallet1&to=wallet2 guarda los valores en la sesión y la segunda petición POST/step2?confirm es la que realmente transfiere el dinero y limpia la sesión.

Esto hace que la explotación sea más difícil porque la sesión se destruye inmediatamente después de la petición de confirmación y, si volvemos transferir dinero otra vez, fallará. Pero esta "protección" todavía es fácil de pasar por alto: sólo tenemos que utilizar la misma cuenta en dos navegadores diferentes (con diferentes cookies de sesión).

El pseudo código para la explotación sería:

# prepara los detalles de la tranferencia de dinero en ambas sesiones
curl starbucks/step1 -H «Cookie: session=session1» --data «amount=1&from=wallet1&to=wallet2»
curl starbucks/step1 -H «Cookie: session=session2» --data «amount=1&from=wallet1&to=wallet2»
# envía $1 simultanemamente desde wallet1 a wallet2 usando ambas sesiones
curl starbucks/step2?confirm -H «Cookie: session=session1» & curl starbucks/step2?confirm -H «Cookie: session=session2» &

BOF en NetUSB o como un pequeño componente de software vulnerable puede afectar a millones de dispositivos en el mundo

NetUSB es una tecnología propietaria desarrollada por la empresa taiwanesa KCodes para proveer la funcionalidad "USB sobre IP". A grandes rasgos cualquier dispositivo USB como una impresora, un disco portátil, etc. conectado a un sistema Linux embebido como un router, un punto de acceso o una caja dedicada, estará disponible en red mediante un driver de kernel Linux que ejecuta un servidor en el puerto TCP 20005. Luego el cliente instalará un software (disponible para Windows y OS X), conectará al servidor y será como si el dispositivo USB estuviera conectado en local.

Para la conexión cliente-servidor es necesario pasar primero una autenticación que se realiza mediante claves AES estáticas en ambos extremos. Durante el inicio de la conexión el cliente envía el nombre de equipo y puede especificar la longitud de dicho nombre. Si se especifica con más de 64 caracteres se producirá un desbordamiento de buffer en el stack del kernel del servidor que podría permitir la ejecución de código en el sistema afectado.

int computername_len;
char computername_buf[64];
// connection initiation, handshake
len = ks_recv(sock, &computername_len, 4, 0);
// ...
len = ks_recv(sock, computername_buf, computername_len, 0); // boom!
Ya hay un script para la prueba de concepto "netusb_bof.py" que causa un DoS/reinicio del dispositivo:

./netusb_bof.py 192.168.1.1 20005 500

Este script todavía no ha sido publicado ni se publicará hasta que todos o la mayoría de vendedores parcheen la vulnerabilidad. El gran problema es que este driver de Kernel se encuentra activado por defecto en miles de dispositivos: TP-Link, Netgear, D-Link, TrendNet, Zyxel, ...


Fuentes:
- KCodes NetUSB: How a Small Taiwanese Software Company Can Impact the Security of Millions of Devices Worldwide 
- SEC Consult Vulnerability Lab Security Advisory 20150519-0   
- NetUSB Driver Flaw Exposes Millions of Routers to Hacking

Encuentran versiones de Putty troyanizadas que roban las credenciales de sus víctimas

El equipo de respuesta de seguridad de Symantec ha encontrado una versión troyanizada del popular cliente SSH PuTTY que roba credenciales a los usuarios. 

La versión maliciosa fue vista por primera vez por Symantec en Internet a finales de 2013, si buen su distribución fue mínima. Por lo tanto, la distribución actual de la versión troyanizada de PuTTY no es generalizada y no es específica de una región o de una industria, según los investigadores. 

El PE de la versión analizada tiene el hash md5 b5c88d5af37afd13f89957150f9311ca, ha sido compilado con otra versión de Microsoft Visual C++ (se nota en el interfaz de usuario) y tiene este "about":


Cuando un usuario realiza una búsqueda de PuTTY en el motor de búsqueda, se proporcionan múltiples resultados. Si la víctima sin saberlo, selecciona la página web comprometida en lugar de la página de descarga oficial de PuTTY, el sitio web comprometido redirige a la víctima varias veces, y luego conecta a la víctima a una dirección IP en los Emiratos Árabes Unidos para proporcionar una versión maliciosa de PuTTY.

Normalmente PuTTY SSH utiliza el siguiente formato de URL estándar para la conexión:

ssh://[USER NAME]:[PASSWORD]@[HOST NAME]:[PORT NUMBER]

 

Si la versión maliciosa de PuTTY conecta correctamente con un host, copia la URL de conexión SSH, codifica la dirección URL con Base64 y en https, y envía un ping que contiene esa cadena al servidor web del atacante. Así, con estas credenciales, un atacante podrá hacer fácilmente una conexión con el servidor.



Moraleja: ¡Chequea siempre tus fuentes y preferiblemente descarga en sitios oficiales!

Fuentes:

- Check your sources! Trojanized open source SSH software used to steal information
- Trojanized, info-stealing PuTTY version lurking online
- Trojanized PuTTY Software

- Trojanized SSH Client PuTTY Steals Credentials 

Las APIs más utilizadas por malware

En Binary Networks vemos un curioso experimento en el que analizaron una gran cantidad de muestras de malware para ver las APIs más utilizadas.
En total reunieron 5TB de espacio con 549.035 ejecutables, todos únicos y confirmados por VirusTotal. Luego mediante un script multihilo en Python extrajeron todos los imports y contaron las veces en las que cada muestra llamaba a una API.

De este análisis obtuvieron resultados muy interesantes. En total hubo 21.043 muestras sin importaciones mientras que 527.992 por lo menos importaron una API. Es decir, sólo el 3,8% de las muestras no tenía ninguna importación. Eso significa que menos del 5% de los archivos se empaquetaron bien sin importaciones estáticamente incluyendo sus dlls, o estaban usando sus propios métodos para la búsqueda e importación de APIs fuera de la tabla de importación del propio PE.

Del resto, de los que si hacían importaciones, hubo un total de 120.126 API importadas de forma exclusiva, un número mucho más grande de lo imaginado. 


Las 10 APIs más utilizadas, con un gran escalón respecto al resto, son las siguientes:

#1  GetProcAddress           394546
#2  LoadLibraryA               344607
#3  GetModuleHandleA       305054
#4  ExitProcess                 301073
#5  VirtualAlloc                 244900
#6  WriteFile                    223855
#7  GetModuleFileNameA   221006
#8  CloseHandle               220358
#9  RegCloseKey              213748
#10 VirtualFree                211790

Para ver algunas otras conclusiones interesantes y obtener el PDF detallado con los resultados visita: https://www.bnxnet.com/top-maliciously-used-apis/.

Parchea VENOM sin reiniciar QEMU

Seguro que ya os habéis enterado... Los investigadores de CrowdStrike han descubierto una nueva vulnerabilidad que han bautizado como VENOM (Virtualized Environment Neglected Operations Manipulation) que permite a un atacante acceder al datastore (disco físico) de una máquina virtual. Concretamente la vulnerabilidad con CVE-2015-3456 se trata de un desbordamiento de buffer que afecta a la emulación del viejo Floppy Disk Controller (FDC) que implementan los hipervisores KVM/QEMU y Xen.

Imaginar lo que significa: tenemos contratado a un proveedor un servidor virtual en la "nube" que comparte la misma máquina física con otros servidores de otros clientes. Todos los datos de esa máquina física podrían ser robados... Urge entonces parchear lo antes posible, pero ¿es posible implementar un parche sin reiniciar los procesos qemu que ya están ejecutándose?

Exploit para elevar fácilmente privilegios en Windows 7 (CVE-2015-1701)

Uno de los exploits analizados en la Operación RussianDoll (APT) se aprovechaba de la vulnerabilidad CVE-2015-1701 para escalar privilegios en Windows Vista/7 y poder ejecutar código en modo kernel. 
A grandes rasgos consigue una devolución de llamada (callback) en modo usuario obteniendo las estructuras del EPROCESS del proceso System y del proceso actual, para luego copiar datos desde el token del proceso System al actual. 
Al finalizar, el payload continúa la ejecución en modo de usuario con los privilegios del proceso del sistema.

Microsoft parcheó esta vulnerabilidad ayer (MS15-0517) y poco después el investigador ruso 'hfiref0x' (habitual de kernelmode.info) publicó en GitHub el código fuente y compilado (créditos a
R136a1). Es decir, si no has han actualizado tu owned Windows 7 piensa que ahora cualquier elevación de privilegios post-explotación es trivial. It's like magic!


Descarga ejecutable:
Taihou64.exe(6.0 KB)
Taihou32.exe(5.5 KB)


Código fuente:
Master.zip 

GitHub: https://github.com/hfiref0x/CVE-2015-1701

Los vectores de ataque más críticos en sistemas SAP

SAP está presente en más de 250.000 clientes en todo el mundo, incluyendo el 98 por ciento de las 100 marcas más valoradas. A pesar de que alberga la información más valiosa y sensible de una organización, los sistemas SAP no están protegidos de las amenazas informáticas mediante los enfoques tradicionales de seguridad.

Sobre la base de las evaluaciones de cientos de implementaciones de SAP, el estudio de Onapsis Research Labs descubrió que más del 95 por ciento de los sistemas SAP fueron expuestos a vulnerabilidades que podrían conducir a compromiso total de los datos y procesos de negocio de una compañía.

La mayoría de las compañías también están expuestas a las ventanas de parcheo prolongadas con un promedio de 18 meses o más. Sólo en 2014, fueron liberados por SAP 391 parches de seguridad, con un promedio de más de 30 por mes. Casi el 50 por ciento de ellos fueron clasificados como de "alta prioridad" por SAP.

"La gran sorpresa es que la ciberseguridad SAP tiene fisuras en la mayoría de las empresas debido a una brecha de responsabilidad entre el equipo de operaciones de SAP y el equipo de seguridad de TI", dijo Mariano Núñez, director general de Onapsis.

Detectando tráfico de conexiones HTTP inversas de Meterpreter (Snort)

Una de las mejores opciones post-explotación que tiene un atacante es dejar un Meterpreter que se comunique con el servidor C&C a través de una conexión HTTP inversa. Pero, ¿cómo podemos detectarlo?, ¿cómo podemos ver si existen PCs en nuestra LAN infectados que estén utilizando este payload?

En el blog de Didier Stevens se da respuesta a esta casuística. Para ello analizaba el tráfico de un cliente Meterpreter en modo http inverso, observando que hace peticiones HTTP regulares al servidor de Metasploit para comprobar si tiene comandos listos para ser ejecutados. Así se ve este tipo de tráfico:




Revisando además el código fuente del protocolo HTTP inverso de Metasploit, la solicitud HTTP POST del cliente siempre tiene un payload RECV de 4 bytes con una URI con el siguiente patrón: 4 o 5 caracteres alfanuméricos, un guión bajo y 16 caracteres alfanuméricos. Los 16 caracteres alfanuméricos se eligen al azar, y los 4 o 5 caracteres alfanuméricos son una especie de checksum.

Y para detectarlo con Snort, Didier nos facilita la siguiente regla:

# Snort rules by Didier Stevens (http://DidierStevens.com)
# 2015/05/01 - 2015/05/10
# Thanks to Nathan Fowler for helping out with performance optimization
# I start numbering my rules at SID 1618000
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Metasploit Meterpreter"; flow:to_server,established; content:"RECV"; http_client_body; depth:4; fast_pattern; isdataat:!0,relative; urilen:23<>24,norm; content:"POST"; pcre:"/^\/[a-z0-9]{4,5}_[a-z0-9]{16}\/$/Ui"; classtype:trojan-activity; reference:url,blog.didierstevens.com/2015/05/11/detecting-network-traffic-from-metasploits-meterpreter-reverse-http-module/; sid:1618008; rev:1;)

rdp2tcp: túnel TCP sobre RDP

Es muy frecuente hacer un pentest de un entorno Windows mediante una máquina Linux, yo diría casi lo normal. Y fácilmente podemos encontrarnos con una DMZ o un segmento de red en la que sólo esté permitido el acceso al puerto 3389/TCP de un servidor, por lo que pivotar a través de esa máquina puede ser crucial para la intrusión.

rdp2tcp es una herramienta del francés Nicolas Collignon que nos permite precisamente hacer un túnel TCP sobre RDP (remote desktop protocol), aprovechando sus canales virtuales para multiplexar la redirección de puertos a través de una sesión existente. El código tiene dos partes: el cliente rdesktop en el lado del atacante y el servidor en el lado de la víctima (terminal server):



Una vez que el servidor y el cliente están ejecutándose, la administración del túnel se realiza por el controlador (en el cliente) que normalmente está escuchando en el puerto 8477 a la espera del registro de nuevos túneles.

$ ./rdp2tcp.py info
ctrlsrv 127.0.0.1:8477
$ ./rdp2tcp.py add forward 127.0.0.1 1234 127.0.0.1 4567
tunnel [127.0.0.1]:1234 ­­> [127.0.0.1]:4567 registered
$ ./rdp2tcp.py info
ctrlsrv 127.0.0.1:8477
tunsrv  127.0.0.1:1234 127.0.0.1:4567

Recursos:

Descarga:

Check-out SVN:  
svn co https://rdp2tcp.svn.sourceforge.net/svnroot/rdp2tcp/trunk/rdp2tcp rdp2tcp

o descarga desde Sourceforge:
https://sourceforge.net/projects/rdp2tcp/files/