DKIM, Domainkeys, Identified Internet Mail y el Spam (3 de 3)

                          El equipo de seccion9 ha visto interesante esta información.

Un correo no firmado, DKIM discardable y Gmail

Terminaba la segunda parte del artículo de esta serie preguntándose sobre cuál sería la implementación que harían los sistemas que implementasen DKIM cuando un correo no viniera firmado ya que, como vimos, el estándar no exige que se compruebe la política del dominio.

Para probarlo con Gmail, que cómo ya puse en el primer artículo Google había anunciado que había implementado DKIM en GoogleApps, configuré un dominio con una política discardable, es decir, solicitando que se eliminen todos los correos que no vengan firmados con DKIM. Le tocó el turno al dominio del blog de Forefront-es.com, así que creamos la pertinente entrada de política DKIM.

 

Figura 7: Registro DKIM con política discardable

Como podéis ver, esta entrada de registro en el servidor DNS es de tipo TXT y puede ser encontrada a través del servidor público de DNS de Google.

Para probar qué política está aplicando Gmail, envié un correo sin firmar utilizando un servicio de Enviar a un amigo desde una página web. Lógicamente ese correo va sin firma DKIM alguna que valga, y el objetivo era comprobar si Gmail está haciendo una consulta a la política DKIM del dominio del remitente para aplicar el borrado del mismo dentro de sus filtros antispam/antispoofing que implemente.

El resultado, como era de esperar, es que el correo entra en la bandeja de entrada de Gmail, sin firma DKIM ninguna. Lo del toque de la venta de la viagra es solo un poco de testing extra del sistema SCL.

Figura 8: Correo falso en el inbox, a pesar de la política DKIM

Reflexiones finales

DKIM no sirve para cifrar los mensajes. Tampoco garantiza el origen del mensaje de forma fiable, ya que como vimos en la primera parte se puede hacer abuso de las firmas al re-enviar el mensaje y las firmas vienen intactas. Por último, como el estándar no obliga a comprobar la política, todo recae en la decisión de la implementación y, como habéis podido comprobar, Gmail no hace esa comprobación en sus filtros antispam, sino que permite únicamente la parte de firmar.

Leer más »

Posted in: hacking

DKIM, Domainkeys, Identified Internet Mail y el Spam (2 de 3)

El equipo de seccion9 ha visto interesante esta información

¿Qué hacer con los correos no firmados con DKIM?

En teoría, el RFC que define el funcionamiento del servicio de DKIM dice que:

5.4. Unverified or Unsigned Mail

Messages lacking a valid author signature (a signature associated with the author of the message as opposed to a signature associated with an intermediary) can prompt a query for any published "signing practices" information, as an aid in determining whether the author information has been used without authorization.

Es decir, que el servidor que recibe “puede” y no “debe” realizar una consulta para conocer la política de firmas. Esto quiere decir que, si un correo no llega firmado desde un dominio que utiliza DKIM, pero el servidor decide no hacer la consulta al servidor DNS del dominio de origen para buscar la política que se quiere aplicar, entonces estaría cumpliendo con el estándar perfectamente.

Luego que una empresa haga la inversión en implementar DKIM no garantiza que en los servidores que usan DKIM no entren correos falsos de su dominio.

¿Cuáles son y dónde se guardan las políticas?

Dentro del dominio del emisor de un mensaje de correo electrónico, se guarda en un registro del DNS conocido como ADSP (Author Domain Signing Practices) en DKIM y en el registro _Domainkey en el caso del ya histórico Domainkey original.

Curiosamente, en el caso de Yahoo! la política aún está en el registro que usa Domainkey y no en DKIM, lo que puede significar muchas cosas.

Figura 4: Política de Yahoo 

Por su parte, Paypal, para que no le quede ninguna duda a nadie, aparte de implementar el registro en formato domainkey, lo tiene ya implementado en formato DKIM.

Figura 5: Políticas de Paypal 

Políticas DKIM y Domainkey

Las políticas en ambos protocolos han cambiado. Mientras que en Domainkey se utiliza un sistema similar a SPF, es decir, con Fail, Softail, Neutral y Pass que se almacenan en el valor o=, en DKIM se utilizan tres valores:

- All = Todos los mensajes vienen firmados.
- Unknown = No se sabe si todos vienen o no vienen firmados
- Discardable = Todos los mensajes son firmados, si no llega firmado, el dominio remitente solicita que sea eliminado el mensajes de correo electrónico.

Como se ha visto, Yahoo! tiene una política Softfail para Domainkeys, lo que indica que debería poner alguna marca al mensaje o similar. Por el contrario, la política DKIM, que debería estar en el regsitro ADSP _adsp._domainkeys.yahoo.com no está implementada.

¿Y Gmail?

Pues a pesar de que Gmail sí que está firmando sus mensajes con DKIM, resulta que ni Gmail.com, ni el propio Google.com, tienen política DKIM o DomainKeys.

Figura 6: Política "ausente" de Gmail

¿Y qué hacemos si un mensaje no viene firmado desde Gmail si no hay política? Pues nada, ya que según dice el RFC hay que aplicar la política unknown:

A.2. Domain Exists, ADSP Does Not Exist

A mail message contains this From: header line: From: alice@bbb.example (Old-fashioned Alice) The ADSP lookup first identifies the Author Address alice@bbb.example and the Author Domain bbb.example. It does an MX DNS query for bbb.example and gets back record (3). Since that query didn't return an error, it then proceeds to a TXT DNS query for _adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the domain exists but there is no ADSP record, ADSP returns the default unknown result: messages may or may not have an author domain signature.

O lo que es lo mismo, mientras no firmes todos los mensajes con DKIM no puedes pedir que se borren los correos que no vayan firmados. Y la pregunta que surge es... ¿y cómo están aplicando todo esto los filtros antispam?

Leer más »

Posted in: hacking

DKIM, Domainkeys, Identified Internet Mail y el Spam (1 de 3)

                              El grupo de seccion9 a visto interesante esta información

DKIM - Domakin Keys Identified Mail - es la unión de dos protocolos anteriores, conocidos como Domainkeys (catalagado ya como histórico) e Identified Internet Mail (del que cogió algunos aspectos) y su objetivo principal es garantizar que un mensaje en concreto procede de un determinado dominio. La garantía de procedencia desde un dominio en concreto se realiza mediante el uso de firmas digitales que se añaden a los mensajes de correo electrónico que son enviados desde los servidores legítimos de ese dominio.

Para que esta idea funcione, cuando un mensaje va a ser enviado desde un determinado servidor de correo, éste, es decir, el servidor de correo saliente, firma el mensaje y añade al correo electrónico una cabecera DKIM que lleva la firma resumen del mensaje, el algoritmo de firma utilizado y el nombre de la clave que se ha utilizado para firmar este mensaje. Será el servidor del correo entrante el que, una vez detectada la cabecera DKIM, leerá el nombre de la clave que se ha utilizado para firmar y se conectará al servidor DNS del dominio firmante para recuperar la clave pública asociada.

Para garantizar que ese es el correo que se envió desde ese servidor de correo se comprobará que la firma es correcta, garantizando que el mensaje viene de ese dominio.

Estos son los principios básicos de DKIM, cuya primera versión es de 2007 y la última revisión del estándar se ha publicado en Agosto de 2009, y , al igual que SPF y SenderID tiene muchas luces y sombras a sus espaldas.

Abuso de DKIM con procesos de re-envío

Google ha anunciado que añade DKIM a Google Apps para que pueda ayudar a la reducción del Spam, y la realidad es que esto, a pesar de que da más información y esos siempre es bueno a la hora de detectar un mensaje de spam, hay que tomarlo con mucho cuidado.

La primero y más evidente es que, si la firma del mensaje va incluida en el propio mensaje, es evidente que no va todo el mensaje firmado. Así, DKIM firma solo mensaje en sí y no todo el sobre, con lo que la protección de integridad del mensaje está sujeta solo al contenido del mismo. Fuera de esa firma de integridad se quedan, entre otros, campos como los destinatarios del mensaje.

Conocido esto, imaginemos que un atacante hace una lista de correo en cualquier servidor de listas y mete en ella todas las direcciones de correo a las que quiere spammear. Ahora utiliza un dominio legítimo que esté firmado con DKIM, como por ejemplo Yahoo! o Gmail y envía, desde ese correo el mensaje a la lista de correo. Cuando el bouncer reenvíe el mensaje este seguirá con la firma DKIM intacta y aparecerá firmado por el destinatario.

Este ejemplo de uso con una lista de correo se puede sustituir por cualquier programa automático o botnet, ya que con tener el mensaje y la firma que pone Gmail a ese mensaje, el atacante puede enviárselo a sí mismo y reenviarlo a cualquier otro destinatario.

Correos firmados por DKIM

Aunque no sea una bala de plata para acabar con el spam, la idea es que una vez que sepa que el mensaje viene en origen ese dominio deberá tener un tratamiento especial con dicho mensaje, ya sea mostrando una marca de garantía al usuario o no metiéndolo nunca en la bandeja de spam, o lo que decida la política del servidor de correo entrante.

Figura 1:Correo firmado por Yahoo

 Figura 2: Cabecera del mensaje de correo de Yahoo con firmas DKIM y DomainKeys

Como se puede ver Yahoo trae en el mensaje la cabecera de firma Domainkeys y la de DKIM, es decir, las dos por si acaso el servidor reconoce una u otra. En ambas cabeceras se especifica que se ha utilizado la misma clave, que está en este registro del DNS.

Figura 3: Clave pública de firma de Yahoo

ratamiento especial en los filtros antispam a los mensajes firmados DKIM

Al poderser abusar esa firma mediante procesos de reenvío, la pregunta que muchos se hacen es... ¿se deberá dar un tratamiento especial en los filtros antispam si los correos vienen firmados? Si se hiciera eso, se estaría tendiendo una alfombra roja a los spammers en los servidores de correo, por lo que nadie se atreve a hacer esa prioridad al correo firmado por DKIM.

No obstante, tenemos la garantía de que el mensaje original salió como ha llegado y desde un origen concreto, con lo que se podría localizar al spammer en el dominio de origen, por lo que tal vez sería posible hacer una operación de búsqueda y bloqueo de ese spammer en el dominio.

Leer más »

Posted in: hacking

El grupo de seccion9 a visto interesante esta información

DKIM - Domakin Keys Identified Mail - es la unión de dos protocolos anteriores, conocidos como Domainkeys (catalagado ya como histórico) e Identified Internet Mail (del que cogió algunos aspectos) y su objetivo principal es garantizar que un mensaje en concreto procede de un determinado dominio. La garantía de procedencia desde un dominio en concreto se realiza mediante el uso de firmas digitales que se añaden a los mensajes de correo electrónico que son enviados desde los servidores legítimos de ese dominio.

Para que esta idea funcione, cuando un mensaje va a ser enviado desde un determinado servidor de correo, éste, es decir, el servidor de correo saliente, firma el mensaje y añade al correo electrónico una cabecera DKIM que lleva la firma resumen del mensaje, el algoritmo de firma utilizado y el nombre de la clave que se ha utilizado para firmar este mensaje. Será el servidor del correo entrante el que, una vez detectada la cabecera DKIM, leerá el nombre de la clave que se ha utilizado para firmar y se conectará al servidor DNS del dominio firmante para recuperar la clave pública asociada.

Para garantizar que ese es el correo que se envió desde ese servidor de correo se comprobará que la firma es correcta, garantizando que el mensaje viene de ese dominio.

Estos son los principios básicos de DKIM, cuya primera versión es de 2007 y la última revisión del estándar se ha publicado en Agosto de 2009, y , al igual que SPF y SenderID tiene muchas luces y sombras a sus espaldas.

Abuso de DKIM con procesos de re-envío

Google ha anunciado que añade DKIM a Google Apps para que pueda ayudar a la reducción del Spam, y la realidad es que esto, a pesar de que da más información y esos siempre es bueno a la hora de detectar un mensaje de spam, hay que tomarlo con mucho cuidado.

La primero y más evidente es que, si la firma del mensaje va incluida en el propio mensaje, es evidente que no va todo el mensaje firmado. Así, DKIM firma solo mensaje en sí y no todo el sobre, con lo que la protección de integridad del mensaje está sujeta solo al contenido del mismo. Fuera de esa firma de integridad se quedan, entre otros, campos como los destinatarios del mensaje.

Conocido esto, imaginemos que un atacante hace una lista de correo en cualquier servidor de listas y mete en ella todas las direcciones de correo a las que quiere spammear. Ahora utiliza un dominio legítimo que esté firmado con DKIM, como por ejemplo Yahoo! o Gmail y envía, desde ese correo el mensaje a la lista de correo. Cuando el bouncer reenvíe el mensaje este seguirá con la firma DKIM intacta y aparecerá firmado por el destinatario.

Este ejemplo de uso con una lista de correo se puede sustituir por cualquier programa automático o botnet, ya que con tener el mensaje y la firma que pone Gmail a ese mensaje, el atacante puede enviárselo a sí mismo y reenviarlo a cualquier otro destinatario.

Correos firmados por DKIM

Aunque no sea una bala de plata para acabar con el spam, la idea es que una vez que sepa que el mensaje viene en origen ese dominio deberá tener un tratamiento especial con dicho mensaje, ya sea mostrando una marca de garantía al usuario o no metiéndolo nunca en la bandeja de spam, o lo que decida la política del servidor de correo entrante.

                                 
                                           Figura 1:Correo firmado por Yahoo

                              
             Figura 2: Cabecera del mensaje de correo de Yahoo con firmas DKIM y DomainKeys

Como se puede ver Yahoo trae en el mensaje la cabecera de firma Domainkeys y la de DKIM, es decir, las dos por si acaso el servidor reconoce una u otra. En ambas cabeceras se especifica que se ha utilizado la misma clave, que está en este registro del DNS.

                             
                                          Figura 3: Clave pública de firma de Yahoo

ratamiento especial en los filtros antispam a los mensajes firmados DKIM

Al poderser abusar esa firma mediante procesos de reenvío, la pregunta que muchos se hacen es... ¿se deberá dar un tratamiento especial en los filtros antispam si los correos vienen firmados? Si se hiciera eso, se estaría tendiendo una alfombra roja a los spammers en los servidores de correo, por lo que nadie se atreve a hacer esa prioridad al correo firmado por DKIM.

No obstante, tenemos la garantía de que el mensaje original salió como ha llegado y desde un origen concreto, con lo que se podría localizar al spammer en el dominio de origen, por lo que tal vez sería posible hacer una operación de búsqueda y bloqueo de ese spammer en el dominio.

Leer más »

Posted in: hacking

Eicar para hacer jailbreak en Terminal Services o Citrix

El equipo de seccion9 de seguridad a visto esta inforación interesante.http://www.seccion9.com/seguridad.html


Terminal Hackplications, fue el de conseguir hacer el jailbreak de la aplicación mediante un viejo amigo del mundo del malware Eicar.

Eicar es un virus de prueba, es decir, no es un virus, es simplemente un fichero firmado como malware por todas las compañías antimalware que se usa para testear canales sin que se te escape un virus por la red. Con esto, cuando se quiere probar si un antimalware está escaneando los ficheros que se suben por Ftp o que se descargan por Http, se pasa un Eicar y se espera la reacción. Si no hay ninguna reacción, es que el antimalware no está protegiendo ese punto del sistema.

Conocido esto, se me ocurrió que una buena forma de salir de la aplicación sería pasar a la consola de monitorización del antivirus y, desde allí, buscar acceso a la ayuda, al panel de control de la impresora, etc...

Para llegar a la consola de monitorización del antivirus lo que necesitamos es un virus y que mejor que Eicar. Además, este fichero se sirve desde Internet con conexiones Http-s lo que permite que, salvo que tenga un servicio de Http-s Inspection como tiene Forefront TMG 2010 y algunos firewalls de gama alta configurado, llegue hasta el servidor Citrix o Terminal Services sin levantar sospechas.

Figura 1: Eicar servido por https

Como podéis suponer, para meter Eicar en la aplicación lo único que necesitamos es una aplicación como Excel o Word, que permita navegar sin navegador. Es decir, que la aplicación haya hecho uso de los controles de Windows para la gestión de ficheros.

Figura 2: Descargando Eicar desde un servidor https

Así que el resto es esperar a ver qué antimalware tienen configurados y qué opciones nos ofrecen para hacer el jailbreak.

Figura 3: Servidores demo de Citrix protegidos

Por supuesto, esto no es solo útil para hacer el jailbreak, ya que conocer el antimalware puede ser muy útil para preparar un malware a medida con técnicas de morphing - incluso de Superman - o mutación que se salte esa solución de seguridad.

Figura 4: Symantec EndPoint Protection vigila este Citrix

Aunque a veces hay sorpresas y te encuentras que hay que preocuparse bastante poco por el antivirus.

Figura 5: Servidor Citrix sin antimalware alguno

Leer más »

Posted in: testador de antimalware

Captura de ficheros transmitidos por SMB con ataques man in the middle en IPv6 usando Evil FOCA.

                            El equipo de seccion9 seguridad ha visto interesante esta informacion.

Los equipos con Windows Server 2008 R2 y Windows 7 utilizan por defecto, siguiendo el algoritmo que elige entre IPv6 e IPv4 basado en la tabla de precedencias, el protocolo IPv6 para las comunicaciones SMB entre ellos. Debido a esto, algunas veces los ataques ARP-Spoofing para hacer ataques man in the middle en redes IPv4 parecen fallar, pero la explicación es tan simple como que el sistema no está haciendo uso de IPv4 para acceder al servidor SMB.

En la demostración que estoy haciendo en el Talentum Tour con la Evil FOCA, enseño cómo funciona esto por defecto en un entorno mixto con IPv4/IPv6 y se puede ver cómo el cliente y el servidor SMB se comunican por defecto con IPv6.

En esta primera captura se puede ver que Evil FOCA ha descubierto dos equipos que tienen tanto direcciones IPv4 como IPv6 configurado, pero que se ha elegido hacer un ataque man in the middle sólo en IPv6 utilizado un esquema de Neighbor Spoofing con ICMPv6.

                             Figura 1: Evil FOCA haciendo mitm con Neightbor spoofing

Activamos Wireshark en la máquina del atacante y después, desde el cliente nos conectamos a un recurso SMB en el servidor en el que se accede a un fichero llamado Password.txt en el que, como se puede ver en la previsulación está la contraseña buscada.

                                   Figura 2: Accediendo a un recurso compartido por SMB

Analizando el tráfico capturado en la máquina atacante, podemos ver que todo el tráfico SMB ha sido transmitido sobre IPv6, por lo que se han podido grabar todos los paquetes que forman parte de los ficheros.

                                                  Figura 3: Trafico SMB sobre IPv6

Haciendo un seguimiento del flujo TCP es posible, como se ve en la siguiente captura, acceder a los ficheros que se han transmitido.

                                       Figura 4: Ficheros transmitidos por SMB capturados

Para sacar los ficheros lo más molón hubiera sido poder utilizar el componente que desarrollaron para Wireshark nuestros amigos de Taddong, pero parece que no detecta bien los paquetes SMB que van sobre IPv6, por lo que utilizando el "canal de reporte de bugs oficial de Taddong"

Leer más »

Posted in: robo de datos

Actuaciones para establecer una estrategia frente al cibercrimen

Llevaba algún tiempo queriendo postear sobre estos 35 documentos del Gobierno australiano que detallan de forma sencilla y clara cual va a ser su estrategia en ciberseguridad.

Lo más destacable y que fué lo que me llamó la atención en su momento es que las pautas generales que se dan son cosas relativamente básicas y claras que en toda organización se pueden implementar con la debida planificación y ajuste de recursos. Es muy significativo el texto inicial de la Web donde se indica que al menos el 85% de las intrusiones detectadas en 2010 podrían haberse evitado aplicando 4 sencillas estrategias que son:

• Actualización y parcheo de aplicaciones.
• Parcheo de vulnerabilidades en sistemas operativos.
• Principio de mínimos privilegios en la asignación de acceso.
• Usar listas blancas con aplicaciones autorizadas para denegar la ejecución de todo lo demás.

Quizás el problema real por el que estas estrategias no son algo cotidiano en las empresas/organizaciones es que las áreas directivas creen que los sistemas de información se mantienen sólo con estar enchufados y que no se requieren recursos técnicos que realicen tareas a diario para que todo funcione con normalidad. Es el gran problema de las áreas TI, que puede que no sean capaces de hacer visible su duro e intenso trabajo diario para pelear porque "todo funcione con normalidad". A ello hemos de añadir ahora la virtualización que ha multiplicado exponencialmente el número de elementos a gestionar y que hace que el ratio administrador/servidor se haya disparado. Y precisamente las tareas operativas que forman parte de estas 4 actuaciones se tienen que realizar tanto en entornos físicos como en los virtuales. Por tanto, si los servidores se han multiplicado por 4, las tareas posiblemente también.

Además de esos documentos, Microsoft ha complementado esta iniciativa con otro documento donde describe qué medidas aplicar en cada uno de los dominios de seguridad de toda organización. Este dibujo representa muy buen las "zonas calientes en seguridad" de toda Empresa/Institución que se encuentra conectada a Internet y permite segmentar los riesgos por los niveles de sensibilidad y alcanzabilidad del intruso. Los dominios establecidos en el gráfico son:

Dominio de cliente final (end point)

• Usb y medios de almacenamiento portatiles.
• Usuarios remotos.
• Tablets, portátiles y equipos PC.

Protección perimetral y frontend

• Firewalls y equipos de protección perimetral.
• Elementos de red e infraestructura.
• Servidores de correo.

Backend

• Servidores de BB.DD. y aplicaciones.
• Servidores de directorio.

Es un dibujo de esos a poner como poster en cualquier departamento TI porque de un vistazo refleja qué vigilar y cómo. En cada dominio se indican las medidas de seguridad a aplicar y si son preventivas o de detección. El documento de Microsoft puede ser descargado en este enlace.

Este tipo de actuaciones son siempre interesantes aunque generalistas. Un análisis del riesgo aporta cierto criterio de ponderación del peligro atendiendo al propio modelo de negocio de la organización. En todo caso, no quita para que este tipo de enfoques basados solamente en gestionar amenazas también pueda ser relevante en aquellos casos donde se carece de este análisis porque siempre será mejor protegerte aun considerando que no es tu máximo riesgo que no hacer nada. Como reflexión final también quiero destacar que las 4 actuaciones esenciales tienen que ver con la correcta gestión y actualización de los sistemas de información. Esto pone de manifiesto que normalmente los intrusos no rompen puertas y ventanas.

Simplemente se cuelan por aquellas que dejamos entreabiertas o sin proteger. Quizás sea más un problema de dar la relevancia que tienen a estas tareas técnicas de mantenimiento que un mérito del atacante. Como ya comenté en el post "El cibercrimen ataca al eslabón más debil, ahora tramitación electrónica", hay una descompensación brutal entre el esfuerzo en proteger y la pericia en atacar. A nosotros nos toca vigilar a todas las ovejas mientras que el lobo sólo tiene que permanecer al acecho, buscar la más débil y atacar en un momento de despiste.

Leer más »