Esta vez, Goliat ganó
A las 4 AM del día de hoy, el dominio "matiaskatz.com" dejó de estar en funcionamiento.
Nadie, absolutamente nadie me avisó del problema. Ni el hosting, ni el registrar. Nadie. Si yo no hubiese intentado acceder al blog esta mañana para postear sobre el Día Internacional de IPv6, jamás me habría enterado.
La cuestión es que tanto el acceso web como el ingreso de mails quedó inhabilitado. Todo el mundo que quiso entrar al blog hoy, no pudo. Todo el mundo que quiso escribirme, recibió un "delivery failure" desde su servidor de correo electrónico.
Luego de comenzar la indagación (es decir, abrir un ticket de soporte en el hosting) comenzó mi "preocupación/enojo/bronca por impotencia" sobre el tema. Cómo puede ser que un dominio entero quede deshabilitado?? Ni siquiera los DNS respondían a los requests, era como si el dominio no existiese.
Recién pude obtener el primer indicio de información a las 15 hs, 11 horas después del inicio del problema:
Alumnos, ex-alumnos, amigos, colegas, y público en general que sigue mis clases y charlas, blog, twitter y demás, conoce del sitio de phishing que tenía en mi website como PoC (prueba de concepto) con motivos de concientización:
El sitio era muy similar a la pantalla de login de Gmail, con algunas diferencias. Al ingresar el usuario las credenciales en el sitio, era automáticamente redirigido a la siguiente pantalla:
El sitio alertaba al usuario de que había sido víctima de phishing, y aclaraba que las credenciales no habían sido guardadas. Esto era cierto, el sitio era una simple demostración de las técnicas de phishing.
Sobre mi ticket de soporte elevado, recibo un mail de mi proveedor de hosting con un forward de un email enviado por Google diciendo lo siguiente:
Google Trust & Safety wrote:
Hello, Dear Abuse Team: Notice of DOMAIN hosted on your service used for FRAUD/PHISHING: Domain:MatiasKatz.com Full URL: http://www.matiaskatz.com/gmail/ IP:190.183.60.137 Target of Attack:gmail Abuse Detected: 6/6/2011 Based on our investigation, the website is reported unauthorized and unrelated to Google or any of its products or services, and likely constitutes an unauthorized attempt to collect Google user credentials. In order to protect users from being misled or victimized, we request that you remove the domain from the DNS and lock it against future changes by the perpetrators. We also ask that you take the following actions wherever relevant or possible: - Please provide us with a tar/zip file of the source code for this website, so that we may analyze it to help prevent further attacks - If any customer data has been captured that is stored on your systems or equipment, please send us that data so that the customers to whom that data relates can be notified and steps taken to protect their sensitive information - Please provide a copy of any records you maintain that indicate the name, contact information, method of payment or similar information that may be useful in helping learn the identity and location of the customer for whom the website has been operated Please investigate this report and take appropriate action. If you have any questions, please direct them in a reply to this email Sincerely, Google Trust & Safety
Resumiendo, el mail de Google decía que encontraron un sitio que podría estar realizando tareas de phishing a nombre de la empresa y que por eso le pedían a mi proveedor de hosting lo siguiente:
- Deshabilitar completamente el dominio
- Entregar el código fuente del sitio web en cuestion
- Entregar información sobre nombre, contacto y tarjeta de crédito sobre el titular de la cuenta (yo)
Paralelamente, Google se contactó con mi Registrar y ordenó lo mismo. Mi Registrar acató las órdenes de Google al pie de la letra y me deshabilitó por completo el acceso al dominio, sin darme ningún tipo de notificación, advertencia, consulta, pedido de confirmación ni derecho a réplica:
Me tomó 4 horas y una conversación telefónica de 1 hora con USA (que nadie jamás me reembolsará) el resolver la situación. Tuve que eliminar el sitio sospechoso y escribirle un email a Google pidiendo disculpas de mis hechos. Y de los daños y perjuicios de tener mi website deshabilitado durante un día entero, y cientos de mails de terceros habiendo sido rebotados.... Nadie se hará cargo.
En resumen... Goliat es fuerte. Si, es bueno en lo que hace y nos simplifica y ayuda la vida en Internet. Pero también demuestra que puede hacer lo que le plazca con nosotros, sin que tengamos derecho a defendernos.
Cierro este post con una frase de Gerald Ford, comúnmente mal atribuída a Thomas Jefferson:
"Government big enough to supply everything you need is big enough to take everything you have. The course of history shows that as a government grows, liberty decreases."
"Un gobierno lo suficienemente grande como para darte todo lo que necesitas, es suficientemente grande como para sacarte todo lo que tienes. El curso de la historia nos muestra que a medida que un gobierno crece, la libertad decrece"
Saludos,
Primer SPAM no filtrado por mi cuenta de Google Apps
Hace 4 meses que migré el manejo de mis cuentas de e-mail a Google Apps.
Hasta el día de hoy, su nivel de efectividad anti-spam fue de un absoluto 100%. Ni un sólo falso negativo, ni un sólo falso positivo.
El día de hoy me encontré con el primer SPAM en mi inbox:
Aunque la llegada de este SPAM ha logrado vencer el invicto del servicio proveído por el grande de Sillicon Valley, debo decir que igualmente estoy muy conforme con su nivel de calidad.
Les recomiendo a todos los que puedan hacerlo, que migren a este maravilloso set de servicios.
Prevenir ser identificado como SPAM con tu cuenta de Google Apps Mail
Como todos sabemos, una de las mejores formas de combatir el SPAM en nuestros mensajes salientes es mediante el uso de políticas de SPF y evitar el Open Relay.
Pero, qué pasa si la organización posee sus cuentas de mail a través de Google Apps ?
La respuesta es simple:
Mediante el agregado de un registro SPF en nuestro servidor DNS que apunte al dominio google.com, estaremos indicando que los servidores de mail de Google están autorizados a enviar correos electrónicos pertenecientes a nuestro dominio.
Para lograrlo, sólo deben agregar un registro TXT en su dominio DNS, que contenga la siguiente información:
v=spf1 include:_spf.google.com ~all
Luego de eso, deberemos esperar algunas horas hasta lograr una replicación DNS completa.
Para revisar si el registro haya sido distribuido a través de Internet, debemos realizar una consulta de dominio a un servidor DNS fuera de la infraestructura interna de la organización.
En este caso, utilizaré uno de los servidores públicos de OpenDNS.
También podría utilizarse un servidor público de Google

Si el registro TXT se ve reflejado en el servidor DNS público, eso significa que nuestra cuenta de Google Apps Mail está lista para enviar correos electrónicos pertenecientes a nuestro dominio con verificación de origen.
Luego de confirmar la replicación DNS, podremos verificar la implementación enviando un e-mail a check-auth@verifier.port25.com desde una cuenta perteneciente a nuestro dominio. Si todo salió bien, deberíamos recibir una respuesta inmediata con la siguiente información:
Nota: Los resultados pueden diferir en cada caso
========================================================== Summary of Results ========================================================== SPF check: pass DomainKeys check: neutral DKIM check: neutral Sender-ID check: pass SpamAssassin check: ham ========================================================== Details: ==========================================================
Este resultado indica que la implementación fue exitosa.
El resultado "SPF check: pass" verifica la existencia del registro SPF.
El resultado "SpamAssassin check: ham" establece que dicho filtro no calificará al mail como SPAM.
Una vez implementada esta medida, nuestros e-mails no serán identificados como SPAM
Ataque de phishing hecho en casa
Se me ocurrió ver hasta que punto podría llegar al tratar de armar un sitio de phishing.
Primero elegí un provider, en este caso fue Gmail. Luego, descargué el sitio web de login original y realicé las siguientes modificaciones:
- Corté todas las comunicaciones que el sitio hacía con Google
- Cambié el destino del envío de datos de usuario y contraseña
- Agregué manualmente un Favicon desde el repositorio oficial de íconos del provider
- Creé un nuevo script que reciba la información enviada desde el formulario de login y la muestre en pantalla
El producto terminado resultó ser un home de Gmail peligrosamente similar al original, con un comportamiento peligrosamente diferente.
Para que puedan interpretar la facilidad de realización de esta parte del ataque, les comento que me tardó aproximadamente media hora de trabajo muy relajado.
Para que esto logre ser un Phishing por completo, el próximo paso será lograr engañar al usuario a que entre a la dirección donde está hosteado este site, creyendo que está accediendo al sitio real de gmail.
Claramente no les facilitaré esa tarea, pero si los dejaré con el site de login, que independientemente es inofensivo.
Los invito a que prueben el site (ingresando credenciales falsas, obviamente).
Próximo provider, Facebook
2 golpes duros para Microsoft, en 1 semana
Todos lo sabemos. Está por todos lados. No hay necesidad de explayarnos demasiado porque cada medio informativo (sea de IT o no) ya ha publicado en los últimos días sobre las 2 grandes noticias en el mundo de Microsoft y la seguridad.
Tema 1 - Microsoft confirmó una vulnerabilidad de 17 años de edad:
La empresa de Redmond confirmó el día 20 de Enero que existe una vulnerabilidad en su Kernel de sistema operativo, vigente desde el Windows NT 3.51, que data del año 1993. Aunque la vulnerabilidad en sí no es grave, sí lo es el hecho de que haya estado presente por casi 2 décadas.
Microsoft ya nos mostró su lado oscuro con respecto a estos temas hace poco tiempo, con el tema del potencial Blue Screen a Vista y 7 debido a una falla en el protocolo SMB v2. Sin embargo, la ambición de la empresa es incondicional, esta gente trata constantemente de superar a todo el mundo, inclusive a ellos, trayéndonos ahora una primicia peor. No sólo porque esta vulnerabilidad es más vieja, sino porque aparentemente (citation needed) Microsoft sabía de esto desde Junio 2009.
Somos todos humanos, correcto. Pero 17 años sin descubrir una vulnerabilidad y no hacer nada cuando alguien de afuera te la hace conocer, es simplemente inaudito.
Más Información: ZDNet (Inglés)
Tema 2 - Operación Aurora, Hydraq, Google Hack, China Hack, IE Hack y 1000 nombres más:
Un grupo de hackers chinos se meten en Google y causan daños inmesurables de magnitud histórica. Google está como loco, queriendo retirar su subsidiaria en el país; mientras tanto, otras grandes firmas empiezan a caer en el mismo ataque (Adobe, Juniper y otras).
Resultó ser una vulnerabilidad 0-day en Internet Explorer la que permitió a los chinos generar el ataque. El mundo entra en pánico porque la exposición es inevitable, salen por todos lados notificaciones masivas diciendo que no usen IE temporalmente, o que suban la configuración de seguridad a "alta", sabiendo (o quizás inocentemente sin saber) que lograr eso en un usuario común es prácticamente imposible.
Microsoft se arremanga la camisa y promete sacar un parche out-of-band de emergencia ASAP. Y lo logra, liberando el boletín MS10-002, el 21 de Enero. Todo vuelve a la normalidad, el nivel DEFCON se baja nuevamente y todos los administradores estamos como locos parcheando equipos.
En resumen, se podría decir que es un empate para Microsoft. Aunque una acción buena no tapa una mala, debo decir que cuando las papas quemaban, los chicos de MS se portaron muy bien.
Para leer los detalles del acontecimiento, sigan los links de abajo. La realidad es que no le ví el sentido a repetir lo mismo que miles de otros sitios ya notificaron. Solamente me remití a dar mi opinión al respecto.
Más Información: ZDNet (Inglés) - Blog de Cristian Linacre (Español) - Blog de ESET Latinoamérica (Español)







