UIPI (User Interface Privilege Isolation) en Windows 8

Una de las tecnologías de seguridad que Microsoft introdujo en la rama 6 del kernel, es decir, Windows Vista (6.0), Windows 7 (6.1) y por supuesto Windows 8 (6.2) es el uso de la protección UIPI, que en Español viene a ser algo como Aislamiento de Privilegios en el Interfaz de Usuario.

La idea de esta protección es la evitar que procesos poco privilegiados inyecten código en procesos más privilegiados haciendo uso de los mensajes interfaz, es decir, del famoso control de Message Loop que distribuye los eventos entre las aplicaciones. 

Este truco de inyectar código mediante eventos de interfaz se había utilizado con éxito desde Windows 95 a Windows XP para conseguir elevaciones de privilegios, algo que hemos visto mediante la inyección de DLLs en programas arrancados para conseguir volcar passwords de servicios, o incluso para modificar en ejecución el comportamiento de un programa - en técnicas de cracking, por ejemplo -.

Desde Windows Vista, con la inclusión de los Niveles de Integridad y de MIC (Mandatory Integrity Control), el envío de mensajes entre aplicaciones está controlado por UIPI y  no se puede realizar entre procesos de distintos Niveles de Integridad. Para conseguir que todo funcione correctamente es necesario que UAC (User Account Control) esté activo, por lo que todos los que lo desactivaron tienen eliminada esta protección.

Hace unos días un compañero de Informatica 64 charlaba sobre esto conmigo, y quería comprobar su funcionamiento, así que le conté una de las demostraciones que siempre hacíamos para comprobar que está funcionando en el sistema esta protección. Aquí os la dejo.

Testeando UIPI en Windows 8

Para testear que UIPI está funcionando correctamente en tu sistema puedes hacer una prueba que nosotros hacíamos desde Windows Vista, y que es tan sencilla como intentar inyectar una pestaña de un navegador menos privilegiado en un navegador ejecutándose con más privilegios. 

En el primer paso yo voy a utilizar Windows 8 y tres instancias de Internet Explorer 10 que están ejecutándose con el mismo nivel de privilegios MIC. Esto se puede comprobar con Process Explorer, o para este caso sencillo con el mismo Task Manager de Windows 8.

Figura 1: Tres instancias arrancadas, pero que funcionan como una sola.

Como se puede ver, a pesar de que son tres ventanas separadas de Internet Explorer 10 que han sido abiertas con la opción Nuevo Internet Explorer, todas las pestañas son un proceso de la misma instancia de Internet Explorer. Para conocer más de esto puedes leer el post de hundir la flota que escribí hace poco más de dos años.

Figura 2: Es posible unir todas las pestañas en una sola instancia

Si en este entorno se intenta unir una pestaña a otra, puede verse que es posible realizarlo, ya que están corriendo en el mismo nivel MIC. No hay problema y UIPI permite el envío de mensaje al interfaz de la aplicación receptora de la pestaña.

En este otro entorno la instancia de Internet Explorer 10 que se está ejecutando con la web de El lado del mal ha sido arrancada con la opción de Ejecutar como adminsitrador. En el Task Manager se puede ver que  son dos procesos totalmente independientes, ya que están en diferentes niveles MIC.

Figura 3: Dos instancias de IE 10 corriendo con diferentes privilegios

Si lo comprobamos con Process Explorer, puede verse que están ejecutándose en distintos Niveles de Integridad (IL).

Figura 4: Las dos instancias de IE 10 funcionan con distintos IL

Cuando se intentan unir las pestañas de ambos navegadores se obtiene un mensaje de prohibición, ya que UIPI está bloqueando el envío de mensajes entre ambos procesos.

Figura 5: UIPI bloquea el envío de mensajes entre ambas

Esta es una de las medidas de seguridad que se introdujeron en el kernel de Windows Vista, que tienes en Windows 7 y en Windows 8. Si desactivas UAC te cargas del tirón, así que tú mismo.

Saludos Malignos!

Para aprender más sobre Windows: "Máxima Seguridad en Windows: Secretos Técnicos"

¿Se extinguieron los dinosaurios?

La respuesta a esta pregunta es un evidente sí. Sin embargo, si rehacemos la pregunta dentro del entorno de las TICs, no llegaremos a una respuesta tan tajante. A día de hoy, todavía podemos encontrar en los CPDs de todo el mundo sistemas que, por su fecha de aparición en el mercado, podrían considerarse arcaicos. Sin embargo, antiguo no es igual que obsoleto. Éste es el caso del conocido sistema de rango medio de IBM AS/400 - también conocido como iSeries, System i o IBM i for Power Systems -. Muchas compañías del sector financiero, de los seguros, de las grandes superficies, empresas logísticas y un largo etcétera, cuentan con este sistema como el corazón de sus infraestructuras tecnológicas.

Figura 1. Una familia de “Tyrannosaurus rex” en actitud desafiante.

Este sistema es considerado como uno de los sistemas más seguros, fiables y robustos. Incluso, algunos han llegado a manifestar que AS/400 es inmune a cualquier tipo de malware. Cuestión que, como muchos ya intuiréis, es falsa. Ya que el sistema invulnerable es aquel sistema no construido. Sin embargo, es interesante enumerar algunas de las características que hacen que este sistema sea capaz de alcanzar altas cotas de seguridad.

¿Por qué el sistema AS/400 puede alcanzar altas cotas de seguridad?

El sistema AS/400 fue uno de los primeros sistemas de propósito general en obtener el nivel C2 de la NSA. Las siguientes son algunas de las características que permitieron este hecho:

El sistema operativo del AS/400 (OS/400) es un sistema operativo basado en objetos. Un programa es un programa y un fichero es un fichero. Un programa no puede ser leído y/o actualizado como un fichero por medio de otro programa. Esto dificulta enormemente la creación de virus cuyo objetivo sea esta plataforma.

El sistema AS/400 es un sistema integrado. Incorpora su propio sistema de gestión de base de datos relacional y sus propios periféricos hardware. Esto último quiere decir que no se puede instalar hardware de terceros en el sistema con sus respectivos controladores. O, lo que es lo mismo, que no hay posibilidad de introducir código que se ejecute dentro del dominio kernel y que pueda “danzar por allí a sus anchas” (o, al menos, es estadísticamente improbable).

El sistema AS/400 incorporaba, desde sus comienzos, una máquina virtual con la que se pretendía aislar el código de aplicaciones de los posibles cambios futuros del hardware subyacente. Esta característica, por ejemplo, permitió el pase de la tecnología CISC a la tecnología RISC sin necesidad de modificar una línea de código por parte de los programadores de aplicaciones.

Todo programa de usuario es compilado, en una primera fase, a un lenguaje de tipo ensamblador y que es independiente de la arquitectura del procesador (MI). Posteriormente, un elemento llamado “el traductor de confianza” realiza una segunda compilación desde la representación MI hacia el código máquina nativo del procesador. El traductor de confianza realiza una verificación sobre el código para sólo traducir a código nativo aquellos programas con “un comportamiento correcto”.

El sistema AS/400 dispone de una pila de datos separada de otra pila de código. Esto imposibilita que ataques de desbordamiento de buffer basados en pila tengan éxito en este sistema. 

Prácticas de ingeniería conservativas. Es decir, se prima más la seguridad y la fiabilidad del sistema antes que el Time to market de nuevas características o funciones.

Sin embargo, la potencialidad de alcanzar altos niveles de seguridad no implica el hecho de alcanzarlos. De hecho, la experiencia demuestra que muchas instalaciones de AS/400 cuentan con implementaciones de seguridad ineficientes o inapropiadas.

¿Por qué hay instalaciones de AS/400 inseguras?

Existen varias razones por las que existen instalaciones de AS/400 inseguras:

Existe una falsa sensación de seguridad entre los clientes de la plataforma. El que el sistema incorpore numerosas herramientas y características de seguridad no sirve de nada si éstas no se activan y se configuran de forma correcta. 

Por el principio de seguridad por oscuridad, se piensa que el desconocimiento mayoritario de esta plataforma lo hace seguro. Hoy en día, existe numerosa información a alcance de cualquiera de cómo tratar de circunvalar la seguridad de esta plataforma. Es más, cuando la amenaza es de tipo APT (Advanced Persistent Thread), el principio de seguridad por oscuridad se desvanece como el amor en la pobreza. Muchos profesionales piensan que los creadores de malware y/o aquellos interesados en romper la seguridad de un sistema, buscarán objetivos que, por su popularidad y difusión, puedan otorgarles mayor notoriedad. Sin embargo, es conocido que en la actualidad los cibercriminales están más interesados en “hacer negocios” que en obtener fama. Los datos que normalmente se almacenan en un sistema AS/400 son para un cibercriminal como fruta fresca para las moscas en un día de verano. 

En un principio, el modelo de seguridad en este sistema se basaba en la restricción de las acciones del usuario final por parte de interfases basadas en menús. Aquel modelo debió morir cuando en el 1993 la plataforma incorporó una completa pila TCP/IP. Sin embargo, a día de hoy, muchas instalaciones se siguen basando en este modelo donde no se contemplan nuevos métodos de acceso (FTP, ODBC, etc.) Los sistemas AS/400 suelen estar ubicados, lógicamente y físicamente, en el centro de las infraestructuras tecnológicas. Por tanto, suelen estar bien “rodeados” de medidas de seguridad perimétricas y de red. Esto, en ocasiones, se interpreta como que es innecesario diseñar, configurar e implementar medidas y controles de seguridad en el propio sistema. Cuestión que rompe con la estrategia de la seguridad por capas o en profundidad. Además, deja el sistema abierto al 80% de los ataques. Ya que, como es conocido, el 80% de los ataques proceden del interior de la infraestructura y no del exterior.

Conclusiones

AS/400 es un sistema muy seguro, fiable y robusto, pero aún así es necesario realizar procesos de auditoría de seguridad en AS/400. El tener una alta capacidad de amar, por sí solo, no te hace un buen amante. Si piensas que estás a salvo de cualquier amenaza cibernética por disponer de un AS/400 como núcleo de tu sistema de información: ¡ Piénsalo otra vez !

Autor: Diego Camacho.

No Lusers 124: Daredevil "atontaddong"

El gran Daredevil y su sentido radar me han servido para hacerle un pequeño homenaje a mis amigos de Taddong y su charla de la RootedCON, que entre los artículos, las conferencias en las que los lío, las consultas de cabecera que les hago y el libro que les hice escribir los tengo todo el día trabajando. ¡Gracias!

Saludos Malignos!

Los "Juicy Files" de un sitio web y la FOCA

Como muchos de los que nos dedicamos a esto de romper cosas, la búsqueda de bugs en las auditorías de seguridad web se hace casi de manera automática, como si fuéramos perros perdigueros en busca de un fichero que está gritando que no está bien configurado. Además de esos, hay otros que tienen "cara de sospechosos", por las rutas en las que se encuentran o la extensión que tienen. Así, los .bak, los .old, o cualquier otro con una extensión "raruna" merecen un análisis más en profundidad.

Todos esos ficheros suelen contener datos jugosos, y en la FOCA hemos creado unas listas para clasificarlos cuando sean encontrados, son los "Juicy Files". Es configurable cuándo debe ser tomado un fichero de este tipo, y dependerá de cada proyecto, pero por defecto lo será cualquier fichero con una extensión que no sea de las comunes.

Figura 1: Juicy Files por extensión

O que se encuentre en una de las rutas que nos interesan habitualmente.

Figura 2: Juicy Files por path

Por supuesto, para encontrar esas rutas, hasta el momento nos aprovechábamos de Google Crawling y Bing Crawling, pero después añadimos el parseo de robots.txt - que todos tenéis en la versión 3 de la FOCA - y en la versión interna hemos añadido el parseo de ficheros .listing y directory listings así como la búsqueda de puertos inusuales, usando el "truco de la barra" con site:/dominio.com:*, algo que deja también jugosos resultados.

Figura 3: Puertos distintos de 80 se clasifican también como juicy files

Saludos Malignos!

Jugando con RoundCube (2 de 5)

************************************************************************************************
- Jugando con RoundCube (1 de 5)
- Jugando con RoundCube (2 de 5)
- Jugando con RoundCube (3 de 5)
- Jugando con RoundCube (4 de 5)
- Jugando con RoundCube (5 de 5)
Autor: Enrique Rando
************************************************************************************************

Finalmente, centré mi atención en el directorio “logs”. Para que pudiera haber algo allí, estuve un rato enviando correos. Cuando listé su contenido, aparecían dos ficheros: “sendmail” y “errors”. El primero de ellos era apasionante:

Figura 8: Privacidad

Aparecía un log en el que se indicaba quién enviaba correos a quién y desde qué dirección IP. La cosa empezaba a ser preocupante, de forma que no me sorprendió demasiado cuando en el fichero “errors” me encontré con perlas del tipo:

[23-Aug-2011 12:36:37 +0000]: IMAP Error: Login failed for tester@example.com from 127.0.0.1. Could not connect to localhost:143: Se produjo un error durante el intento de conexión ya que la parte conectada no respondió adecuadamente tras un periodo de tiempo, o bien se produjo un error en la conexión establecida ya que el host conectado no ha podido responder.


in /var/www/roundcubemail-0.6-beta/program/include/rcube_imap.php on line 199 (POST /roundcubemail-0.6-beta/?_task=login&_action=login)

La configuración del servidor al descubierto… Definitivamente, eso de las opciones por defecto es algo que uno debe comprobar detenidamente. Y leerse bien TODAS las instrucciones de instalación, por si acaso. Menos mal que quienes instalaron todos esos RoundCube que hay sueltos por Internet se leyeron los manuales y los configuraron correctamente. ¿O quizá algunos no?

Episodio 3. Buscando Cubos Redondeados

Era cuestión de comprobarlo. Así que iba a tener que hacer uso de “mis amigos, los buscadores”. Pero no iba a ser fácil, la distribución de RoundCube lleva un fichero “robots.txt” en su directorio raíz con el siguiente contenido:

User-agent: *
Disallow: /

O sea, que cualquier robot que se precie debería ignorar lo que hay ahí. Y eso, en principio, parece razonable. ¿Para qué vamos a querer que Google indexe nuestro servidor de correo y lo que contiene? Pero hay dos problemas: ni todos los robots respetan este tipo de recomendaciones ni siempre son aplicables. Y es que la especificación del fichero “robots.txt” habla de un único fichero para todo el site, ubicado en su directorio raíz. Sin embargo, hay casos, y el servidor que acababa de crear era un ejemplo, en que el webmail está alojado en un subdirectorio. Y los buscadores no comprueban los “robots.txt” de los subdirectorios.

Así que se obtienen bastantes resultados buscando en Google, Bing, etc..., cosas como: "welcome to roundcube" o "bienvenido a roundcube" O, para los más políglotas "benvenuto in roundcube" o incluso "witamy w roundCube"

Muchos de los resultados no pertenecen realmente a webmails sino a sitios que informan sobre las características de otros y muestran sus títulos. Whois, sitios de estadísticas y similares. Aún así, la información que proporcionan puede ser valiosa a la hora de fijar objetivos:

Figura 9: Delatando a otros

Y los robots.txt no protegen contra esto. Para ir acabando, no olvidemos a Shodan con su siempre admirable sencillez. Simplemente buscamos “roundcube” y …

Figura 10: ¿Tú también, Shodan?

Las cookies delatan estos webmails. Y los “robots.txt” tampoco ofrecen demasiada protección frente a Shodan, que no mira el contenido de los documentos. Ya teníamos posiblemente miles de “RoundCubes”. ¿Habría alguno mal configurado?... pues sí, más de alguno

Figura 11: Problemillas

Y… ¿por qué no probar alguna consulta más específica, incluso a riesgo de perderse resultados? Por ejemplo: inurl:"roundcube/logs"

Figura 12: Privacidad, otra vez.

Incluso, buscando, buscando, se encuentra algún documento adjunto:

Figura 12: Esto empieza a ser rayante... ¿verdad?

A estas alturas me di cuenta de que ya me había alejado demasiado de lo que me había hecho instalar aquel servidor con RoundCube: mi deseo de investigar la existencia una posible vulnerabilidad XSS y cómo explotarla de forma efectiva. Así que retomé el tema. Pero esa es otra historia (en realidad, otras dos historias) que habrá que contar otro día. Mientras tanto, creo, hay quien tiene un webmail que revisar…

************************************************************************************************
- Jugando con RoundCube (1 de 5)
- Jugando con RoundCube (2 de 5)
- Jugando con RoundCube (3 de 5)
- Jugando con RoundCube (4 de 5)
- Jugando con RoundCube (5 de 5)
************************************************************************************************

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

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

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.

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

OCSP, el update de Windows Raúl y el ataque de Roberto Carlos

Con el lío que se ha montado con los certificados digitales falsos creados de Comodo ha habido mucho ruido y mucha información, con lo que probablemente todos estéis ya informados de que un hacker iraní consiguió hacerse con certificados falsos de Gmail, Live, etcétera. En Una al día, como suelen hacer con estas noticias desde hace más de 12 años [guiño, guiño], lo explican de maravilla, y Yago, de Security By Default, amplía la información en Me inComodo - me encanta el título -.

Sin embargo, hay un aspecto que me no he leído en casi ningún sitio y es la vulnerabilidad de OCSP frente a ataques Man In The Middle, que ya demostró Moxie Marlinspike en 2009.

El asunto radica en que, para mitigar el impacto que puedan tener en la seguridad los certificados digitales, en casi todos los sitios se habla de tener activado OCSP (que Firefox lo trae por defecto) o activarlo en el resto de navegadores. Sin embargo, Microsoft ha optado por aplicar Security Fix con una descarga de la CRL en cada equipo. ¿Por qué ha hecho esto?

El protoolo OCSP (Online Certicate Status Protocol), como su propio nombre indica, es un sistema de consulta online para saber si un determinado certificado digital ha sido revocado o no. Para ello, el cliente envía la petición a la ubicación de la CRL (Certificate Revocation List), que viene indicada en el propio certificado digital. Si quieres saber más de certificados digitales, no dudes en comprarte el libro del DNI-e de Rames Sarwat [guiño, guiño]

Ahora viene el problema. Si un atacante está haciendo un ataque de Man in The Middle para utilizar uno de estos certificados digitales, entonces también puede interceptar las peticiones OCSP. Estas peticionees, aunque van firmadas en su cuerpo, no van firmadas en su cabecera y hay una respuesta especial que puede mandar el atacante para hacer que se de siempre por bueno un certificado digital, y es el número que llevaba Roberto Carlos en el Real Madrid.

Como explicaba Moxie en sus charlas, OCSP tiene una respuesta válida que puede devolver un servidor que es Try Later. Esta contestación, que tiene asignado el código 3, le dice al cliente que ahora no puede atender su peticion, que lo siente mucho. Así, la mayoría de los clientes, ante esta situación, aceptan el certificado digital o, en algunos casos, muestran una alerta totalmente distinta a la típica de los ataques Man in the Middle.

Lo cierto es que basta con conectar un Proxy en medio cancelar todas las peticiones OCSP que hace el cliente (yo lo he hecho con Firefox 4 y Gmail) y el navegador, no comprueba si está revocado o no el certificado y NO da niguna alerta.


Figura 1: Peticiones OCSP dropeadas en Firefox 4
Conocido el ataque de Roberto Carlos al protcolo OCSP, y el comportamiento de no generar alertas ante la imposibilidad de conectarse al servidor OCSP, es por lo que Microsoft, aka Spectra, ha optado por el security update, que yo tengo instalada en mi Windows Raúl.

Saludos Malignos!

Buscando sesiones rotas con componentes cliente

Uno de los fallos comunes en aplicaciones web son los de sesión rota. En este tipo de fallos, el programador del software no comprueba en todos los puntos de la aplicación que el usuario tenga una sesión autenticada y activa, lo que permite a atacantes sin sesión activa llegar a determinadas partes de la aplicación.

Encontrar partes de la aplicación web que pueden ser accedidas sin una sesión activa puede ayudar desde a encontrar más información del sitio hasta conseguir un acceso, dependiendo del lugar donde falle la comprobación.

Un entorno a explorar son aquellas aplicaciones web que cargan parte de la lógica mediante un componente que se carga en el navegador. Este componente puede ser un simple fichero en flash, un componente ActiveX o un Applet Java, por poner un ejemplo.

En el caso de que sen componentes fácilmente decompilables, una idea sencilla es abrir el cliente y buscar las URLS contenidas para poder realizar un spidering de las mismas, buscando todos los ficheros que aparezcan. Esto es muy común, por ejemplo, en los ficheros flash o los applets Java. Si el componente es un objeto escrito en Visual C, la cosa implica hacer reversing o fuzzing. Alejandro Ramos escribió un gran artículo sobre cómo analizar la seguridad de los ActiveX.

Sin embargo, en cualquier caso, debe existir una comunicación entre la aplicación web y el cliente para que este último vaya abriendo los paneles de interfaz de usuario a media que un usuario autenticado los vaya necesitando. Es por eso que, cuando el servidor se lo indique, el cliente deberá abrir un nuevo panel al usuario, con opciones que llamarán a nuevas partes del servidor.

Si se intercepta la comunicación entre el servidor y el cliente, es fácil indicarle al cliente que debe abrir otro panel del interfaz, y descubrir nuevas partes de la aplicación en el servidor.

En el ejemplo del otro día, con ThinWorx, se carga un applet Java o un control ActiveX dependiendo del navegador. Si se intercepta la comunicación entre el servidor y el cliente se puede ver que cuando el usuario no introduce una clave correcta se obtiene un mensaje de error.


Figura 1: Error de autenticación
Este mensaje de error es mostrado por el componente cliente porque el servidor se lo ha indicado por medio de un código configurado. En este caso, el valor 4.


Figura 2: Código de respuesta de servidor
Conseguir ver diferentes partes de la aplicación cliente será tan senillo en este caso como cambiar los códigos de control que el servidor envía al cliente. En este caso, para acceder al panel de usuario, basta con manipular el valor 4, y sustituirlo por un valor 0, tal y como se ve en la siguiente imagen.


Figura 3: Manipulación de código de respuesta de servidor
El resultado es que se accede a un panel de administración de usuario sin sesión. Lógicamente. Si el servidor tiene comprobada correctametne la sesión en todas las ubicaciones llamadas, no se podrá ver nada más que las partes clientes.


Figura 4: Panel de usuario de la aplicación
Sin embargo, con el descubrimiento de nuevas URLs, se puede continuar realizando un proceso de spidering, buscando nuevas ubicaciones, para intentar encontrar partes de la aplicación que no requieran sesiones. En la siguiente imagen se puede ver el panel de administración de la aplicación.


Figura 5: Panel de administración
Tal vez, con este sistema no consigas tener el acceso completo a un sitio, pero si descubrir mucha más información que, de buen seguro, será útil más adelante.

Saludos Malignos!

Calendario de Hols y Virtual Hols en Abril

Ya está cerrado el calendario de Hands on Lab en Madrid y Virtual Hands On Lab a través de Internet en Madrid, así que os dejo la lista de todas las sesiones por si quieres apuntanter a alguna. Tienes toda la información en la página de Hands On Lab en Madrid y los Virtual Hands On Lab.

Semana 1

28/03 [Madrid] Windows 7: Implementing
28/03 [Madrid] Windows 7. Integración Empresarial
29/03 [Madrid] Windows 7. Seguridad
30/03 [Madrid] Windows Server 2008 R2: Network Services
30/03 [Madrid] Windows Server 2008 R2: Implementing
31/03 [Madrid] Exchange Server 2010: Análisis Forense
31/03 [Madrid] Windows Server 2008 R2: Active Directory
01/04 [Madrid] Windows Server 2008 R2: Terminal Services

Semana 2

04/04 [Madrid] SQL Server 2008 R2: Implementing
04/04 [Madrid] SQL Server 2008 R2: Integration Services
05/04 [Madrid] SQL Server 2008 R2: Administración y Seguridad
06/04 [Madrid] SQL Server 2008 R2. Analysis Services
06/04 [Madrid] SQL Server 2008 R2. Reporting Services
07/04 [Madrid] SQL Server 2008 R2. Replication Services
08/04 [Madrid] SQL Server 2008 R2. Ajuste del Rendimiento

Semana 3

12/04 [Online] Seguridad de una organización con MS Forefront
12/04 [Online] MS Forefront Endpoint Protection 2010
13/04 [Online] MS Forefront Protection 2010 for Exchange Server
14/04 [Online] MS Forefront TMG 2010: Implementing

Semana 4

18/04 [Madrid] System Center Operations Manager 2007 R2
18/04 [Madrid] System Center Configuration Manager 2007 R2
19/04 [Madrid] System Center Operations Manager 2007 R2: Exchange

Semana 5

26/04 [Online] LOPD Aplicada en Windows: Sistemas Operativos
26/04 [Online] Esquema Nacional de Seguridad en entornos Microsoft
27/04 [Online] LOPD Aplicada en Windows: BBDD, Documentos y e-mail
28/04 [Online] Normativa en el comercio electrónico en Microsoft

Saludos Malignos!

HBGary y el correo electrónico

A día de hoy todos estaréis al tanto de la que se ha montado con la firma de seguridad HBGary, que ha sido atacada por el grupo Anonym0us para dejarla en evidencia antes sus clientes por todo el mundo, ya que se han expuesto contraseñas de todas sus bases de datos.

La parte técnica de cómo se hizo esto es bastante curiosa, todo comenzó por un SQL Injection en una aplicación PHP que usaban como CMS. Esta herramienta la habían creado ellos y… se llevó todo el premio.

Un SQL Injection… pues a por la tabla de los usuarios y contraseñas. Una vez sacadas todas, las passwords estaban en MD5 y sin salting ni política de complejidad, así que se las petaron pronto y consiguieron acceso a la intranet, donde pillaron backups, ficheros y aplicaciones.

Desde dentro del panel se podía, entre otras cosas, resetear la password, así que le resetearon la password del correo a “Gary” y con un poco de ingeniería social y un intercambio de correos de lo más divertido, consiguieron acceso de root a la máquina por SSH para poder terminar el pastel del ataque con una guinda. Por supuesto, los correos sin ningún tipo de firma digital de ninguna clase, solo enviados desde los servidores internos pidiendo abrir puertos y cambiar claves.

En este proceso, la gente de anonym0us dejo claro que HNGary había fallado en:

- Codificación Segura
- Pentesting
- Política de contraseñas
- Autenticación de más de 1 factor
- Política de seguridad en el reseteo de contraseñas (mail)
- Concienciación de sus usuarios

Y les han dejado fatal porque esto es lo que ellos venden. Punto para Anonym0us.

Saludos Malignos!

Preguntas rápidas... respuestas lentas

Hoy he decidido hacer un poco de Buzónleaks, un poco para justificarme por los retrasos, un poco para solicitar algo de comprensión y lloraros a todos.

El caso es que a mí me gusta contestar todos los correos, e intento hacerlo, pero cuando estás en la carretera muchos días, y recibes una media de 250 correos diarios, la cosa se complica. Intento mantener en mi inbox una cola máxima de 50 correos sin atender, que es lo que tengo configurado en OWA de paginación, así, cuando tengo un minuto, puedo intentar contestar alguno.

Es duro, no creáis que no, luchar contra el efecto e-pingpong, que te machaca. Sin embargo, hay unos correos que son especialmente dificiles de sacar del inbox. Son esos que ponen algo como:

"Una duda", "Una pregunta rápida", "Seguro que para tí es muy fácil", "Una consultilla", etcétera....



Preguntas rápidas
Es mentira - y las peores son las de los diminutivos "dudilla, consultilla, problemilla" y similares -, detrás de eso hay una lista de preguntas, un fichero de log, una captura de un problema o un análisis técnico que realizar de algún problema que tiene esa persona.

A mí no me importa que me escriban ese tipo de preguntas rápidas, pero lo que no puedo dar son las respuestas rápidas que muchos esperan. Yo contestaré, cuando tenga un momento, pero no siempre es fácil la respuesta ni encontrar ese hueco.

Lo peor es cuando contestas, y el susodicho avanza un paso, y quiere que le ayudes con el siguiente, y contestas... y luego quieren el siguiente paso y el siguiente, y el siguiente....

Informática 64 tiene un bonito departamento de consultoría, e incluso un SAT, donde se pueden contratar horas de soporte y, si no me equivoco, casi cualquier empresa de informática tiene un servicio así. Esto no quiere decir que no podáis seguir haciendome las "preguntas rápidas" a mí, pero sí que tenéis que entender que haya respuestas lentas a algunas de ellas.

Saludos Malignos!

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

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

¿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?

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

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

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

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
Tratamiento 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.

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

Fuera de la oficina y de sitio

Los mensajes de OoO (Out of Office) se configuran para indicar que uno se encuentra fuera de la oficina, es decir, que el mensaje que acabas de enviar no va a ser procesado durante un tiempo y dar información sobre quién te puede ayudar.

En este caso el mail de OoO que recibimos nos llamó mucho la atención. Conociendo el dominio, y el nombre del usuario, seguro que eramos capaces de conseguir un cambio de contraseña de algún usuario, pero nosotros somos gentes de bien...creo.


No pongáis estas cosas en los mensajes OoO....
Saludos Malignos!

¿Cuál te gusta más: SPF o SenderID? (2 de 2)

*********************************************************************************************
- ¿Cuál te gusta más: SPF o SenderID? (1 de 2)
- ¿Cuál te gusta más: SPF o SenderID? (2 de 2)
*********************************************************************************************

En el caso de Hotmail, la diferencia es sutil con Gmail.com, pero importante. Como podéis ver el mensaje llega también de lacaixa.es pero con una bonita alerta que deja muy claro quién lo ha enviado.


Figura 5: Mensaje en Hotmail.com con identificación de Sender:
Esto quiere decir que el mensaje llega con un mail from desde lacaixa.es pero que ha sido enviado desde un Sender: de sharethis.com. Como podéis imaginaros, esto también puede ser utilizado por los spammers y phishers para engañar a los clientes de La Caixa que no estén muy familiarizados con estos conceptos. La pregunta es ¿podría hacer algo lacaixa.es para evitar esto?

Por supuesto, puede hacer uso de SenderID para fortificar un poco más su dominio. Esta tecnología utiliza un algoritmo para dejar claro quién ha enviado el mensaje que se llama Purpoted Responsible Address. Esto, lo que trata es de averiguar de forma nítica es quién es el Sender del mensaje. El algoritmo está descrito en el RFC 4407 y es éste:

1.- Seleccionar el primer valor no vacío de Resent-Sender: en el mensaje.
->Si no existe ese campo, continuar con el paso 2.
->Si está precedido por un campo no vacío de Resent-form y una o más ocurrencias de campos de Recived: o Return-Path: detrás de Resent-From: y después de Resent-Sender:, continúa con el paso 2.
-> En otro caso ir al paso 5.

2.- Seleccionar el primer valor no vacío de Resent-From: en el mensaje.
-> Si existe ir al paso 5.
-> En otro caso ir al paso 3.

3.- Seleccionar todos los valores no vacíos de Sender: en el mensaje.
-> Si no hay ninguno ir al paso 4.
-> Si hay 1 y nada más que 1 ir al paso 5.
-> En otro caso ir al paso 6.

4.- Seleccionar todos los valores no vacíos de From:.
-> Si hay exactamente 1 valor, continuar con el paso 5.
-> En otro caso ir con el paso 6.

5.- Un paso anterior ha seleccionado un único valor en la cabecera.
-> Si el mensaje está malformado - por ejemplo, contiene múltiples buzones, o el buzón está desesperanzadamente malformado, o el buzón no contiene ningún nombre de dominio, continuar con el paso 6.
-> En otro caso devolver ese valor único de buzón como PRA.

6. El mensaje está manipulado/enfermo y es imposible determinar un valor PRA.

Bien, una vez determinado correctamente el valor de PRA, y saber quién es el que envía el mensaje, se debe elegir una política. Las políticas que puede usar el administrador del dominio son:

- Spf2.0/mfrom -> Mirando si el "sender", que será Sender:, o en su ausencia, From:, está autorizado en el domino del "sender".
- Spf2.0/pra-> Mirando si el valor PRA está autorizado en el dominio del "sender".
- Spf2.0/pra,mfrom o spf2.0/mfrom,pra -> Mirando si el valor de From: y pra están autorizados.

Si miramos la cabecera de Hotmail, vemos que el valor de PRA en este ejemplo está marcado para sharethis.com y el servidor es un sender autorizado en ese dominio. Sin embargo, la política de lacaixa.es es spf1, es decir que solo evita que alguien se identifique como "sender" de lacaixa.es y. no sea de sus servidors. En este caso queda claro que no es un "sender" de lacaixa.es, así que esa política no hace nada, ya que ese "sender" no es de su dominio y está autorizado en sharethis.com.


Figura 6: Mensaje original en Hotmail con cálculo de valor PRA
Para bloquear este tipo de comportamientos, hay que utilizar el registro spf2.0/pra,mfrom o spf2.0/pra,mfrom y, por supuesto, el servidor de correo que reciba este mensaje tiene que implementar SenderID.

Por desgracia, a día de hoy, no todos los servidores implementan este filtro, y muchos siguen aún con el filtro de SPF. Sin embargo, si la implementación SPF trata de evitar el Spoofing debería comprobar los valores de Sender:, X-Sender: o Return-Path:.

Lógicamente, si un servidor de correo entrante implementa SPF y lee en tu dominio un registro spf2.0 lo va a ignorar. Es por ello que la solución pasa por establecer 2 registros SPF y que el servidor de correo entrante decida si aplica spf1 o spf2.0 ya que el estándar de SenderID [RFC4406] contempla esta situación. De esta forma, un pequeño porcentaje de destinatarios tendrá la política más estricta, si así lo desea el dueño del dominio.

La controversia radica en que, los partidarios de SenderID solicitan que cuando sus filtros se encuentren con spf1 les dejen aplicar la política como spf2.0/pra,mfrom, pero a día de hoy, la política que se sigue aplicando es spf2.0/mfrom.

Espero que hayan quedado claras las “sutiles” e importantes diferencias entre SPF y SenderID. Y ahora la pregunta: ¿Cuál te gusta más: SPF o SenderID?

Saludos Malignos!

*********************************************************************************************
- ¿Cuál te gusta más: SPF o SenderID? (1 de 2)
- ¿Cuál te gusta más: SPF o SenderID? (2 de 2)
*********************************************************************************************

¿Cuál te gusta más: SPF o SenderID? (1 de 2)

*********************************************************************************************
- ¿Cuál te gusta más: SPF o SenderID? (1 de 2)
- ¿Cuál te gusta más: SPF o SenderID? (2 de 2)
*********************************************************************************************

Muchas veces, por falta de tiempo, no me meto en todos los detalles del funcionamiento de SenderID y Sender Policy Framework, es decir, en las pequeñas diferencias que existen entre ellos, pero a raíz de una petición de explicación sobre un caso concreto, he creído que era conveniente pararse un poco sobre ello. El asunto comienza con un mail enviado a Hotmail en el que, aparentemente, el mail llega desde un dominio con una política –all en el registro SPF.


Figura 1: Correo con dirección falsa en la bandeja de entrada de Hotmail.
Para replicar este caso, como habéis visto en la figura 1, he seleccionado el dominio de lacaixa.es que tienen esa política en su registro SPF de tipo Hardfail y el servicio de Enviar a un amgio de una web que re-escribe los campos necesarios para explicar como funcionan los registros.


Figura 2: Registro SPF de lacaixa.es
Sin embargo, enviamos un correo falso a Gmail y a Hotmail y obtenemos que entra en ambos, pero con algunas diferencias, que nos servirán para explicar los sutiles detalles de estas implementaciones. Si observamos, el correo, además de entrar perfectamente en la bandeja de entrada de Hotmail, entra también en la bandeja de Gmail. Como se puede ver, si vemos los detalles del mensaje se están mostrando los campos From: y Reply to: que, como se puede ver, ambos tienen la información es la misma, una dirección de correo de lacaixa.es.


Figura 3: Correo visto en Gmail con detalles mostrados
Sin embargo, si miramos el correo original, vamos a entender porque Gmail lo hace tan rematadamente mal - ¡Alerta: opinión personal! -.


Figura 4: Original del correo mostrado en Gmail.com
Como se puede ver, el cálculo del valor SPF dice que la política es hardfail, y por lo tanto, siguiendo la política del registro SPF de lacaixa.es debería eliminarlo. ¿Esto es así? Vamos a pensar un poco sobre ello.

Si echamos un vistazo al RFC2822 donde se definen los campos de un mensaje, podremos ver que en el apartado 3.6. se definen varios posibles campos para el originario de un mensaje.


Figura 5: Campos de posibles originarios de un mensaje
Para ello, hay que entender una sutil diferencia entre quién se supone que escribe el mensaje y quién se supone que lo envía. Para entender el orden de prioridad de los campos vamos a analizar la diferencia entre From: y Sender:. Tal y como dice el estándar, se supone que mail from es el originario de la carta, el contenido, del mensaje en sí, mientras que sender, es el originario de enviar ese mensaje. Es decir, ¿quién se supone que creo el mensaje? From:. ¿Quién se supone que lo envío? Sender:. Así, este orden de precedencia, a la hora de averigüar quién envía un mensaje, hay que entenderlo para Resent-sender:, Resent-From:, From: y Sender:. Por supuesto, a esto hay que añadir las implicaciones de los campos "X" com X-Sender:, X-Resent-Sender:, etc… ya que los campos "X", implican extensiones al estándar que algunos servidores de correo electrónico implementan de manera distinta. Por spuesto, si no hay ningún valor más, el valor que vale es el de From:.

Bien, dicho esto… ¿debería Gmail bloquear ese mensaje? Mi respuesta es que no, pero que lo hace aún peor que peor - ¡Alerta: Opinión personal!. Vamos por partes.

Si analizamos ese mensaje de correo, podemos ver que tiene tres campos muy significativos con valores, que son Sender:, X-Sender: y Return-Path:. El campo Sender: - y su versión extendida X-Sender: - marcan la dirección del que envió este correo a nuestro servidor, mientras que Return-Path: es un campo de traceo y monitorización que utilizan los servidores de correo para dejar claro que ese mensaje se originó en ellos. Así, Return-Path: lo añade el servidor que genera el primer mensaje de correo, dejando claro dónde se originó.

Conociendo esto, si Gmail aplica la política hardfail con el campo From:, estará impidiendo que ningún Sender:, envíe un correo en su nombre… y entonces se le acabaron las listas de correo a esta dirección de correo. Si jesus@lacaixa.es intentara suscribirse a alguna lista de correo en la que hubiera un reenviador de los correos, sus mensajes nunca llegarían a las direcciones destino de Gmail.

Dicho esto, el siguiente paso es buscar información sobre este caso, pues la cosa se torna muy turbia aquí. Si miramos la Wikipedia [Sender Policy Framework], en la información sobre el filtro SPF dice claramente:

“the owner of the example.com domain can designate which machines are authorized to send e-mail with the sender e-mail address ending in "@example.com"”

Así que hay que mirar quién es el sender y, tal y como dice la Wikipedia y en todas las explicaciones, esto debe ser mirado en los campos From: y Sender:. Lo suyo sería mirarlo en el campo Return-Path:, pero muchas implementaciones decidieron hacerlo con Sender: y From:, porque son los primeros valores que hay que entregar del mensaje y se puede bloquear el correo al principio. Ahora bien, si aparecen los dos… ¿cuál es el que debería utilizarse?

Según el RFC4408 del estándar SPF debería ser solo la dirección en From:, pero si quieres que te funcione el filtro SPF sin cepillarte las listas de correo, lo que deberías hacer es aplicar el valor Sender:, como hacen muchos servidores de correo y From: solo cuando no aparezca Sender:.

Por el contrario, si aplicamos el valor de Sender:, esto implicaría que hay que comprobar el registro SPF del dominio que aparezca en el Sender:, por lo que si el DominioB está enviando un correo en nombre de un usuario del DominioA, entonces se aplicaría la política SPF del DominioB y si ese usuario de Sender: lo hace desde un servidor autorizado por el SFP del DominioB, entonces podría enviar un correo del DominoA.

Como puedes observar Gmail:

PRIMERO: Gmail aplica From: y no Sender:.
SEGUNDO: No elimina el correo aún cuando lee la política del dominio que él ha decidio.
TERCERO: No muestra ninguna alerta al usuario.

Divertido, ¿verdad? Tranquilo, que aún aún hay mucho más, espera a ver la segunda parte para tomar partido.

Saludos Malignos!

*********************************************************************************************
- ¿Cuál te gusta más: SPF o SenderID? (1 de 2)
- ¿Cuál te gusta más: SPF o SenderID? (2 de 2)
*********************************************************************************************

Intimidad de las comunicaciones

Reconozco que no estaba haciendo nada bueno. Reconozco que las ideas que tenía/tengo en mente para estas pruebas no tenían nada que ver con las noticias que me estaba enviando, pero esto ha superado lo que esperaba encontrar.

En Pamplona, en el curso de Cibercrimen que se impartió la semana pasada tuve una discusión con un señor juez que tiró abajo pruebas aportadas por los cuerpos de seguridad del estado por incumplir la Ley de inviolabilidad de las comunicaciones. La idea es que tiró atrás una lista de direcciones IP de pederastas que compartían pornografía porque según su apreciación de las redes P2P, para saber eso hay que meterse en medio de las comunicaciones y eso es ilegal. Ya discutí yo con él un rato, intentando ver los sutiles matices del protocolo P2P.

El caso es que, en esta ocasión, estaba haciendo una revisión del artículo que escribí sobre "Enviar a un amigo" para hacer un par de cosas curiosas que se me han ocurrido, cuando en un sitio me ha pasado esto.

Iba yo tan campante "leyendo" noticias, cuando he visto una que me parecía muy interesante para enviarsela a mi amigo. En la página web, como se puede apreciar en la imagen, no había ninguna información extra de este servicio, y yo he asumido que era como los de todos. Lo curioso es que este panel de enviar a un amigo está en la web del, digamos, Dominio A.


Figura 1: Servicio de enviar a un amigo, no a dos
Una vez enviada la notica, a Gmail, por eso de que los filtros SPF se los pasa por el forro, resulta que me encuentro en CC un nuevo amigo que me ha salido del DominioB. WTF?


Figura 2: Mi e-mail, con un nuevo amigo
Lo curioso es que el DominioB, aparentemente, no tiene nada que ver con el DominioA, y sin yo saberlo se ha metido en medio del e-mail que le envío a mi amigo. ¿Es esto legal? Todavía más peculiar es que parece que ese del DominioB es de la empresa que diseña la web del DominioA, pero para nada es mi amigo, y no tengo interés en enviarle un mail a este señor para nada. A ver, los de leyes, ¿esto se puede hacer o es violar la intimidad de las comunicaciones?

Saludos Malignos!

Sprite Animation Contest

Tras el éxito que fue ver la creatividad de todos los asistentes al BlogCamp! en la creación de animaciones con el sencillo motor que habíamos preparado en HTML5 para Internet Explorer 9, nos pareció buena idea hacer un concurso para estas navidades y que algunos se lleven una XBOX 360 como regalo de navidades. Y así nació el Sprite Animation Contest.


El objetivo es realizar una animación de hasta 3 minutos en las que utilices la potencia de HTML para conseguir un objetivo. Enseñar a los demás las novedades del nuevo Windows Live Mail.

La prueba: Para ello, te vamos a enseñar a animar con sprites, el método clásico de animación en videojuegos de los 80, en el que podrás aprender a mover personajes y objetos por la pantalla. Con este fin hemos preparado un sencillo motor en HTML 5 que te ayudará a empezar a trabajar, pero tú puedes adaptarlo a tus necesidades e incluso conseguir cosas increibles. Eso sí, tiene que funcionar en Internet Explorer 9, ya sabes, el que ha sacado mejores resultados en los tests del W3C.

Para que aprendas, haremos un Webcast el próximo día 25 de Noviembre donde te enseñaremos los entresijos de como hacer este tipo de animaciones. Tienes que registrarte previamente para participar en el webcast.

Premios: Se darán tres consolas XBOX a los que ganen en las siguientes categorías:

- Mejor consecución de objetivos: Este premio se dará a la animación que mejor consiga aunar los objetivos de mostrar las novedades de Windows Live con la más cuidada animación.

- Mejor animación técnica: Aquella que consiga aunar mayor destreza técnica, artística y elegancia.

- Animación más divertida: Aquella que, con humor, mejor consiga expresar las ideas del concurso.

Este concurso está destinado solo a estudiantes, así que, si no eres estudiante... apúntate a aprender algo o tendremos que banearte (ya sabes que va por ti). Eso sí, al webcast y al motor podrás acceder y hacerte tus propias animaciones. Tienes más informaicón en Sprite Animation Contest.

Saludos Malignos!