Un ataque, 5 errores

Hace pocos días se ha dado a conocer que el popular
periódico Washington Post sufrió un ataque coordinado y su web fue comprometida. Lograron redirigir a los visitantes a una página panfletaria. Se sabe
que un simple phishing a ciertos reporteros ha supuesto una parte del origen del problema.
Nada fuera de lo común, pero después del incidente cabe reflexionar, ¿cuántos
errores en cadena se han cometido y cómo se podría haber evitado?

El autodenominado grupo de atacantes Syrian Electronic Army,
consiguió tomar cierto control de la web del  prestigioso periódico. La propia cabecera
admitió que una parte del ataque comenzó el robo a un reportero de deportes la cuenta
de correo a través de una simple falsificación del portal interno de Outlook. ¿Qué
errores se esconden tras este incidente?

1) Como todo ataque, comenzó con algo de investigación. Los
atacantes recopilaron nombres y cuentas de correo de reporteros (al parecer los
que disponían de cuenta en Twitter). A estos les enviaron correos
personalizados “que parecían venir de colegas de trabajo” invitando a introducir su contraseña de email puesto que al
parecer la sesión había “expirado”. Aunque en algunos casos sea
inevitable, conviene controlar en lo posible la fuga de información sensible
que pueden suponer datos como el correo,  nombres o direcciones URL internas que se
pueden filtrar a través de diversos medios, como metadatos, cuentas personales
de trabajadores en redes sociales… Esta es una asignatura pendiente para
muchas empresas, que facilitan la labor de investigación previa de muchos
atacantes.

2) Como se puede apreciar en la imagen del ataque real, el
correo llevaba a un phishing normal y corriente (no es “sofisticado” como lo califican desde el Washington Post), donde se falsifica a través de
un dominio de tercer nivel (site88.com) la dirección del periódico.

Fuente: http://krebsonsecurity.com/2013/08/washington-post-site-hacked-after-successful-phishing-campaign/

El dominio
real que se pretende suplantar se puede apreciar en esta otra imagen:

Aunque no se ha dado a conocer el contenido del correo
enviado en primera instancia que invitaba a visitar el enlace, es más que
probable que también falsificara el dominio de procedencia, haciendo creer que venían de otros compañeros. Se sabe que se enviaron en una segunda ronda, correos desde una cuenta ya robada. Aquí los errores son claros y variados. Washington
Post (como la mayoría)  no utiliza DKIM y
ni siquiera es muy restrictivo a la hora de usar SPF (no bloquea por defecto,
sino que deja la elección al cliente).

… puede que técnicamente se pudiese haber evitado que el primer correo llegara a los buzones de los usuarios. Al menos esa primera ronda que proviene de un tercero (una vez que una cuenta es robada, no hay forma de evitar que el atacante la use para enviar nuevos correos aún más creíbles). En todo caso, una vez el correo está en el buzón de entrada, quizás lo más
importante es que los administradores tampoco han “entrenado” a sus
usuarios para no caer en este tipo de estafas simples (correos que redirigen a
enlaces que piden credenciales) aunque parezcan provenir de compañeros.

3) Ya con la web falsa mostrada en el navegador, la víctima no
comprueba que el acceso no se hace cifrado, ni por supuesto, el certificado. El
SSL, socialmente roto, es otra de las grandes asignaturas pendientes para los
usuarios. Entrenarlos y ayudarles en este sentido es algo muy necesario.

4) Con la contraseña del correo de la víctima en las manos,
el atacante probablemente, ya podría haber publicado en la web oficial como si de un
editor se tratara. Sin embargo, la versión oficial salta (sin relación aparente con el phishing perpetrado previamente) a un problema de un tercero para justificar el ataque a su web. Parece que el phishing se utilizó solo para acceder al Twitter de algunos editores y el ataque a la web es en realidad un acto “complementario” al ataque. Washington Post utiliza Outbrain, una red de publicidad que se encarga de sugerir al lector otros temas y artículos en los que puede estar interesado. Outbrain reconoce un problema de seguridad, que fue comprometida, y que eso explica por qué consiguieron atacar a la CNN, y la revista Time “de un solo golpe” (también usan Outbrain).

Por tanto (aunque en un principio no quedaba claro) parece que no hubo relación entre el problema de seguridad en Outbrain que condujo a la redirección en la web y el robo de credenciales de ciertos redactores o editores. En otros escenarios, lo habitual hubiese sido (simplificando):

• Se podría haber utilizado algún sistema de
  “recordar contraseña” a través del correo ya robado para obtener el
  acceso tanto al Twitter de sus editores como quizás a algún componente de la web manejada por los editores. Nunca se debe devolver el dato en texto claro en un correo, sino que se debe obligar a la generación de una contraseña nueva, y que este hecho sea notificado inmediatamente al administrador.
• El usuario podría utilizar la misma contraseña para
  el correo que para editar en la página. Esto debe estar prohibido por políticas. 
• El atacante, haciéndose pasar por el legítimo dueño de la cuenta de correo, podría haber solicitado acceso especial para publicar en la web (ingeniería social). 

5) Finalmente, es probable que atacante escalara privilegios o eludiese restricciones para poder controlar artículos en la web gracias al fallo de seguridad en Outbrain. En cualquier caso, una auditoría previa interna de su web, tipo “caja blanca”
podría haber facilitado el descubrir lo antes posible la vulnerabilidad y
solucionar previamente el fallo.

Conclusiones

Puede resultar muy aventurado deducir cómo
ocurrió un ataque sin manejar los datos reales, sin embargo, esta estructura
básica de errores en cadena expuesta con el caso del Washington Post de fondo,
resulta el escenario más habitual en la mayoría de los ataques.

El phishing poco sofisticado sigue siendo una herramienta
eficaz y muy usada para cumplir los objetivos de los atacantes. El usuario, su
desconocimiento, las tecnologías que no se entienden y la falta de políticas
estrictas por miedo a incomodar al propio usuario, son el cóctel perfecto para
que cualquiera que sepa clonar una página, pueda conseguir unas credenciales valiosas para realizar otros ataques más dañinos.

Sergio de los Santos

ssantos@11paths.com