Analiza la información de tu Directorio Activo con AdFind

Joe Richards, MVP de Microsoft, tiene un interesante recopilatorio de utilidades gratuitas conocidas como "joeware" que seguro harán las delicias de cualquier administrador de Windows. Concretamente hoy vemos AdFind, una herramienta de consulta del Directorio Activo que es una mezcla de ldapsearch, search.vbs, ldp, dsquery y dsget además de incluir otras utilidades adicionales. Veréis con los ejemplo como es posible desgranar por completo la información de un dominio...

Aquí encontraras el uso de AdFind y ejemplos.


Añade los siguientes parámetros con el nombre de host/IP del controlador de dominio y las credenciales del usuario de dominio si realizas las consultas desde una máquina fuera de dominio:

AdFind -h direccion_ip -u "usuario@dominio.inet" -up password

Consulta la versión del esquema

AdFind -schema -s base objectVersion

Consulta wellKnownObjects

AdFind -default -s base wellknownObjects

Lista los objetos borrados

AdFind -default -rb "CN=Deleted Objects" -showdel

Lista los objetos en conflicto

AdFind -b -gc -f "(Name=*\0ACNF:*)" -dn

Obtiene todos los atributos

AdFind.exe -schema -f “objectClass=attributeSchema” cn lDAPDisplayName -nodn -csv >Attributes.txt

Obtiene todas las Classes

AdFind.exe -schema -f “objectclass=classSchema” cn lDAPDisplayName -nodn -csv >Classes.txt

¿Se borran todos los datos al resetear de fábrica un dispositivo Android? Parece que no...

La función de reseteo de fábrica de Android no es tan efectiva como nos gustaría que fuera, según un equipo de investigadores de la Universidad de Cambridge. El grupo estima que de 500 a 630 millones de dispositivos Android podrían no ser capaces de borrar por completo los datos guardados en sus discos internos y tarjetas SD.

Los investigadores llegaron a esta conclusión tras probar 21 dispositivos con versiones 2.3 a 4.3 de Android y a partir de cinco fabricantes diferentes. Durante las pruebas, fueron capaces de recuperar al menos parte de los datos almacenados en cada dispositivo probado - incluso si fue protegido con el cifrado completo de disco. Los datos que se recuperaron incluían contactos, imágenes y vídeos, textos, correos electrónicos y logins para aplicaciones de terceros como Facebook y WhatsApp. También fueron capaces de recuperar el token principal necesario para acceder a todos los datos de usuario de Google en el 80 por ciento de los teléfonos.

Hay muchas razones por las que falla el reseteo de fabrica: según los investigadores, los fabricantes a veces no cargan el software del teléfono con los drivers necesarios para limpiar completamente su disco o la tarjeta SD interna. Además, las unidades flash son muy difíciles de borrar.

Por el momento no está claro si Google o cualquiera de los fabricantes cuyos teléfonos fueron probados están haciendo algo sobre este tema. Pero si realmente quieres proteger tu información antes de tirar, vender o regalar un teléfono antiguo, utiliza la contraseña más complicada que puedas ... o, ya sabes, sal a comprar un martillo.

Fuente: Researchers find Android factory reset faulty and reversible

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.