Warberry: convierte tu Raspberry Pi en una máquina de "guerra" sigilosa

Warberry es una herramienta en Python con un objetivo en mente: ser utilizada por un red team en un entorno donde quieran obtener tanta información como sea posible, en un corto período de tiempo y de la forma más sigilosa posible. Sólo hay que encontrar un puerto de red y enchufar la RPi. Los scripts han sido diseñados de manera que se intente evitar lo máximo posible el ruido en la red para evitar la detección y ser lo más eficiente posible. 


Uso

Para obtener una lista de todas las opciones:

sudo python warberry.py -h

Parameters:
-h,  --help         [*] Print this help banner
-m,  --man          [*] Prints WarBerry's Man Page
-A,  --attack       [*] Run All Enumeration Scripts
-S,  --sniffer      [*] Run Sniffing Modules Only
-C,  --clear        [*] Clear Output Directories
-F,  --fulltcp      [*] Full TCP Port Scan
-T,  --toptcp       [*] Top Port Scan
-U,  --topudp       [*] Top UDP Port Scan

example usage: sudo python warberry.py -A
               sudo python warberry.py --attack
               sudo python warberry.py -C

Las contraseñas más usadas por los usuarios comprometidos en el último ataque a Linkedin

Seguro que ya os enterasteis del último ataque a Linkedin que se saldó con unos 167 millones de cuentas comprometidas (Linkedin tiene más de 400 millones de usuarios). Además, debido a los problemas con el algoritmo utilizado para proteger las contraseñas, SHA-1 sin Salt, se estima que el 90% de las contraseñas han sido crackeadas. A continuación se muestran las peores contraseñas ordenadas por frecuencia:

Po. Password Frecuencia
1 123456 753,305
2 linkedin 172,523
3 password 144,458
4 123456789 94,314
5 12345678 63,769
6 111111 57,210
7 1234567 49,652
8 sunshine 39,118
9 qwerty 37,538
10 654321 33,854

Abusando de WPAD para implantar ficheros PAC maliciosos (colisión de nombres gTLD)

Normalmente en las empresas los usuarios utilizan un servidor proxy para navegar por Internet, mejorando así el rendimiento (caché), la monitorización y la seguridad. Para no tener que configurar manualmente los navegadores se suelen utilizar los llamados ficheros PAC (proxy auto-config) donde se define el proxy apropiado para acceder a cada URL, y para saber la ubicación de estos ficheros se utiliza WPAD (Web Proxy Autodiscovery Protocol) mediante descubrimiento por DHCP o DNS.

Recientemente un estudio de la Universidad de Michigan ha revelado la existencia de una vulnerabilidad en WPAD que podría ser aprovechada por un atacante para interceptar estas peticiones de descubrimiento y retornar un fichero PAC que haga que un usuario utilice un proxy malicioso.

Veamos un poco en qué consiste. Por ejemplo, si en el navegador de un equipo está marcada la opción de 'Detectar la configuración automáticamente' (como se muestra en la imagen de arriba) el sistema se basará en el hostname para buscar el fichero .pac en este orden:

Hostname: 

computer.team.division.company.example

Búsqueda de fichero .pac:
wpad.team.division.company.example/wpad.dat
wpad.division.company.example/wpad.dat
wpad.company.example/wpad.dat

 

Si el dominio .company.example no es resuelto por los DNS internos la petición se reenviará automáticamente a los DNS públicos.

El problema es que WPAD está activado por defecto en todos los sistemas operativos Microsoft Windows y en el navegador Internet Explorer, por lo que si en una empresa no está implementado su uso se estarán enviando de forma incontrolada peticiones a Internet


De hecho, los investigadores confirman en su whitepaper: "en dos de los 13 root servers, se observan todos los días aproximadamente 20 millones de este tipo de consultas que contienen fugas al espacio de nombres DNS público. Este ha sido un problema conocido desde hace años, pero ... no ha sido explotable con anterioridad".

Y dicen no "explotable con anterioridad" porque en 2012 la ICANN abrió la puerta a la contratación de dominios de nivel superior genéricos pasando de 22 a los 1300 que se prevé que habrá en los próximos años. Es decir, podéis imaginar que si los atacantes son capaces de comprar el nombre de dominio .company.example podrían poner un sitio web en wpad.company.example y publicar su propio archivo PAC que indique a los navegadores usar el servidor proxy del atacante...

Para evitarlo, el US-CERT recomienda:

- Considerar desactivar la detección/configuración automática de proxy en los navegadores y sistemas operativos cuando se trata de dispositivos que no serán utilizados en redes internas.
- Considerar el uso de un nombre de dominio completo (FQDN) de un DNS global como el root de la empresa y espacio de nombres interno.
- Configurar los servidores DNS internos para responder autoritariamente a las consultas internas de TLD.
- Configurar los firewalls y servidores proxy para registrar y bloquear las solicitudes de salida para archivos Wpad.dat.
- Identificar el tráfico WPAD esperado y vigilar el espacio de nombres público o considerar registrar dominios de forma defensiva para evitar futuros conflictos de nombres.
- Presentar un informe a la ICANN si se está sufriendo un daño grave demostrable como consecuencia de la colisión de nombres.

Fuentes:
- When domain names attack: the WPAD name collision vulnerability
- WPAD name collision bug opens door for MitM attackers
- White paper: enterprise remediation for wpad name collision vulnerability

Pastejacking: usando Javascript para sobrescribir el portapapeles con contenido malicioso

Ahora los navegadores permiten a los desarrolladores añadir automáticamente el contenido al portapapeles de un usuario, dependiendo de ciertas condiciones, normalmente mediante eventos del navegador. 
Recientemente Dylan Ayrey aka dxa4481 ha desarrollado una técnica bautizada como pastejacking que se aprovecha de ésto para engañar al usuario y conseguir que ejecute comandos maliciosos.

Cabe señalar que durante un tiempo también se podían realizar ataques similares a través de HTML/CSS. La diferencia con esta técnica es que el texto puede ser copiado después de un evento o copiado después de un breve periodo de tiempo, y puede ser utilizado para explotar VIM, como se muestra a continuación.

Demo

El siguiente sitio sugiere al usuario copiar un inocente comando: https://security.love/Pastejacking

echo "not evil"

Si el usuario lo copia con la típica combinación de teclas ctrl+c o command+c se establece un temporizador de 800 ms y sobrescribirá el portapapeles del usuario con código malicioso:

echo "evil"\n

El salto de línea que se incluye al final hará que se ejecute el comando sin darle al usuario la oportunidad de revisarlo.

bt2, un backdoor escrito en Python que utiliza Telegram como C&C

bt2 (Blaze Telegram Backdoor Toolkit) de Julio Cesar Fort es un bot IM escrito en Python que utiliza la infraestructura y la API de Telegram actuando como un C&C. Incluye las funcionalidades típicas de un backdoor como ejecución de comandos, downloader, shell inverso, descarga y subida de archivos, etc.

El bot se encuentra en la red de Telegram a la espera de las órdenes procedentes del botmaster. El master puede controlar los bots desde cualquier cliente Telegram, ya sea de escritorio, móvil o en línea de comandos permitiendo una gran flexibilidad durante la fase de post-explotación. Además las comunicaciones se realizan a través de HTTPS estándar pudiendo evadir varios filtros de red corporativa.

Dependencias

$ sudo pip install telepot
$ sudo pip install requests


Limitaciones

Actualmente la ejecución del shellcode depende de ctypes y funciona sólo en plataformas Windows

Uso

Antes de utilizar bt2 es necesario registrar un bot en Telegram. Una vez configurado se obtendrá una clave para interactuar con la API de bot.

Para más información, ver:
Telegram bots: an introduction for developers

Además, es muy recomendable sustituir 'botmaster ID' con el ID del maestro, bloqueando la comunicación entre el bot y el ID específico del botmaster para evitar abusos por parte de terceros no autorizados.

$ python bt2.py



Proyecto Github: https://github.com/blazeinfosec/bt2

Cómo firmar digitalmente los correos enviados desde Yahoo o Gmail

Cada vez surgen nuevos y más sofisticados ataques de phishing o de suplantación de identidad mediante correos electrónicos fraudulentos que intentan engañar a los usuarios. El objetivo es que faciliten información confidencial, o que sigan un enlace e introduzcan sus credenciales en un portal falso, o que abran un fichero adjunto y se infecten, etc.

Por eso hoy en día es de vital importancia firmar digitalmente los mensajes, para dar al destinatario la posibilidad de comprobar su autenticidad e integridad. 


No voy a entrar en el detalle de qué es y cómo funciona la firma electrónica pues no es objeto de esta entrada que pretende ser principalmente práctica. Sólo recordaros que, a grandes rasgos, para firmar un mensaje se calcula su hash (message digest) y se firma con la clave privada del remitente. El resultado es la firma digital que se adjunta en el mensaje al enviarlo para que el destinatario pueda comprobarlo mediante su clave pública correspondiente, tal y como se muestra en la imagen de la derecha.

Si el destinatario no dispone de la clave pública del remitente este último puede también adjuntarlo en el mensaje, eliminando así la necesidad del intercambio manual previo o el acceso a una PKI, GAL o keyserver público, a diferencia que con el cifrado (asimétrico) que si necesitaría si o si y previamente la clave pública del destinatario. 

Es decir, tenemos la posibilidad de firmar digitalmente y de forma fácil nuestros mensajes para darle a nuestros contactos la posibilidad de comprobar quién ha enviado un correo somos realmente nosotros.

Entonces, ¿por qué no firmar nuestros correos si podemos hacerlo de manera gratuita, en unos sencillos pasos e incluso con las cuentas de correo de Yahoo o Gmail que usamos a diario? Veamos cómo hacerlo.

Uso elevado de CPU si utilizas un nombre de usuario que contenga "user" en Windows 8.1

Estoy algo liado pero permitirme dejaros sólo una pequeña píldora, en este caso un bug que apareció en mayo del año pasado pero que ha vuelto a salir a la palestra a raíz de comentarse recientemente en Reddit y otros medios sociales. Se trata de que si usáis un nombre de cuenta de usuario que contenga la palabra "user" en Windows 8.1 veréis como el proceso taskhost.exe consume un alto porcentaje de CPU de forma intermitente debido a un problema en el componente DFPCommon.dl.

Pero lejos de publicar un parche, para resolverlo Microsoft nos lo pone fácil: "Para resolver el problema, no cree una cuenta de usuario que contenga la cadena 'user' en el equipo":


https://support.microsoft.com/en-us/kb/3053711


Sin comentarios. Y si ya la estabas utilizando tienes dos opciones, borrarla o renombrarla... o como leía en algún otro foro otra solución sería "No usar Windows". Lol!

Demuestra tu ingenio en criptografía participando en CryptoCTF

Desde hoy y hasta el próximo 27 de mayo se desarrolla CryptoCTF, un CTF en el que encontraréis un montón de pruebas de ingenio, programación y destreza en criptografía dirigidos a estudiantes de secundaria de todo el mundo.

Se puede participar en grupos de hasta cuatro participantes y puede haber varios equipos de un mismo instituto, si bien no deben colaborar entre ellos. Basta con tener unos conocimientos mínimos de criptografía y programación. Los premios serán en Bitcoins, aunque todavía no se han concretado cantidades.

Algunos ejemplos de los retos que encontraréis:

- Cifrado de jardín de infancia: Cuando eres pequeño, vas a la escuela para aprender a leer y contar. ¿Y si se enseña un poco de la criptografía también?

6-12-1-7 { 1-2-3 ' 19 _ 1-14-4 _ 15-14-5 _ 20-23-15 _ 20-8-18-5-5 ' 19 }

- Toda su base: El último paso para muchos algoritmos de cifrado es cambiar la base de varios valores. Intenta averiguar qué base se utilizó en este caso:

666c61677b7072657474795f62617369
635f69665f796f755f61736b5f6d657d


- Padre de la máquina de escribir remota: Llegarán tiempos en los que no tendrás ninguna idea de lo que significan las cosas, por lo que tendrás que recurrir a Google para entenderlas. Estas avisado.

1000010100000010110110010000111101000110
0010101101100100001111010110001011000001
0110011001010100001101110000010111011000
0011101100100000011001100110101001000110
0111100001000111100100011001010000100101
0000101110110000110001001110100101000011
0100100001010100111010010110000010100001
1100101010000110111000001


Tenéis la solución a estos ejemplos en la web de CryptoCTF, donde además podréis inscribiros:

http://cryptoctf.com/

Vulnerabilidad crítica de envenamiento de caché en proxies Squid

Jianjun Chen, un estudiante de la Universidad de Tsinghua, ha reportado una vulnerabilidad crítica de envenenamiento de caché en el servidor proxy Squid, recordemos uno de los cachés transparentes más desplegados por los proveedores de servicios de Internet.

La vulnerabilidad, todavía sin CVE, permite a un atacante redireccionar el tráfico de los usuarios que utilizan el proxy a sitios maliciosos mediante una única petición, siempre que el tráfico no sea HTTP cifrado. "El ataque permite envenenamiento de caché de cualquier sitio web HTTP sin cifrar", confirma Chen, y por ejemplo podría realizarse de forma silenciosa mediante anuncios Flash maliciosos.

Para explotarlo con éxito, un atacante debe ser capaz de enviar peticiones a un sitio web (como attack.com) a través del servidor proxy. Bajo este escenario, el atacante primero establece una conexión TCP contra el servidor web attack.com. Al funcionar Squid en modo proxy transparente, estas solicitudes son interceptadas y transmitidas. A continuación, el atacante inicia la siguiente petición HTTP:

GET http://victim.com/ HTTP/1.1 Host: attack.com

El módulo de caché utiliza la dirección de host de la cadena de la petición (victim.com) para crear la clave; sin embargo, el módulo de verificación utiliza el encabezado de host (attack.com) para comprobar la comunicación entre el host y la dirección IP. Esto es lo que hace posible el ataque.

Chen ha publicado también el siguiente vídeo con la PoC:


Ya se ha publicado el parche para las versiones diarias (dayly builds), pero aún no se distribuido para las regulares y el ataque puede ser ejecutado contra las versiones anteriores a la 3.5.18 y 4.0.10. Mientras, como workaround, se recomienda activar la opción host_verify_strict y usar la siguiente regla de Suricata:

alert http $HOME_NET any -> $HOME_NET $HTTP_PORTS (msg: "[PT Open] Possible Squid cache poisoning"; content: "GET"; http_method; content: "http://"; http_raw_uri; pcre: "/GET\s+\w+:\/\/\S+\s+.*?[\r\n].*?Host: +[\w\.:]+\b/is"; pcre:! "/GET\s+\w+:\/\/([^\/\s]+)[\/\s]\S*.+?Host:\s*\1\S*\b/is"; classtype: attempted-recon; sid: 10000035; rev: 1; )

Fuente: Popular cache Squid skids as hacker pops lid

PornHub lanza un programa de recompensas de vulnerabilidades

Ya tienes excusa para ver porno tranquilamente en cualquier momento y lugar: ¡PornHub lanza un programa de recompensas de vulnerabilidades (bug bounty program)!


Con el creciente número de ataques informáticos un número significativo de empresas y organizaciones han iniciado programas de recompensas y los sitios de pornografía no pueden ser una excepción. PornHub, quizás el sitio más famoso de este tipo, ha puesto en marcha un programa de recompensas de errores para que los investigadores de seguridad y los cazadores de bugs puedan encontrar y reportar las vulnerabilidades de seguridad en su sitio web.

El programa se realiza a través de HackerOne, una plataforma para conectar a los investigadores de tecnología que descubren vulnerabilidades, bugs y otros temas con las empresas afectadas por ellos. Las recompensas en este caso van desde los 50$ a los 25.000$ dependiendo del impacto de la vulnerabilidad encontrada en el sitio web:

- http://*.pornhub.com/