LeaseWeb, AVG, Avira, WhatsApp: El fail es para...

AVISO SPOILER: El fail es para el registrador.

¡Hola amigos! Soy Co...(pido disculpas de nuevo, por tener que recurrir a este inicio de post por segunda vez desde aquel EU2010.es: El fail es para...)

Hoy vamos a explicar la diferencia entre Domain Hijacking y hackear un sitio web.

No voy entrar en el debate de si debe llamarse DNS Hijacking o Domain Hijacking. Considero que el DNS Hijacking se debería llamar al ataque sobre servidores DNS en si como servicio y su procesamiento de peticiones recibidas, algo que incluso algunos ISPs utilizan para introducirnos publicidad o redirigirnos a servicios personalizados o concertados con los originales.

Comenzaremos con conceptos básicos de este ataque que se está poniendo tan de moda entre los defacers (frente a la imposibilidad en un principio de comprometer los servidores en sí de su objetivo), de grupos como el KDSM Team, o incluso algunas de las últimas acciones de los ¿ya pasados de moda? Syrian Electronic Army.

Qué es el Domain Hijacking

En la mayoría de los casos en los que no se gestionan los registros DNS por el propio usuario, estos se delegan a empresas llamadas registradores sobre los cuales se contratan los nombres de dominio necesarios y se gestionan a través de su software o panel de control. El Domain Hijacking se conoce como al acceso no autorizado a la gestión de los registros de un dominio, modificando dichos registros para que se apunten a direcciones IP diferentes a los originales. Para el caso de lo ocurrido con Avira, WhatsApp y otros, se ha confirmado que el hack se ha realizado sobre el proveedor Network Solutions, el cual gestiona sus dominios, además de los de muchas más importantes compañías.

Quién se ve afectado/de quién es la responsabilidad

Este ataque afecta, obviamente, a los registradores de nombres los cuales ven comprometidas sus aplicaciones de gestión de nombres y registros de dominios, y por consecuencia, todos sus clientes. Hay dos casos, bien diferentes y que determinan el alcance del ataque y sus consecuencias:

• Si se consigue comprometer la aplicación de gestión de dominios por una vulnerabilidad en su software o en su procedimiento de actualización de servidores DNS, se comprometen todos.
• Si se consiguen obtener las credenciales de acceso al panel de gestión de dominios de un cliente en concreto, se comprometerán sus dominios y subdominios. Esta obtención de credenciales se puede realizar mediante ingeniería social, malware, campañas de phishing, acceso a la cuenta de e-mail utilizada al registrarse, etc. Así de simple.

La web parece modificada ¿han secuestrado el dominio?

Se puede utilizar cualquier herramienta de obtención de información sobre DNS y dominios para comprobar que la IP a la que se resuelve no corresponde con la original, o pertenece a un rango de direccionamiento IP sospechoso y no propio del dominio.

El impacto

Todos sabemos, sobretodo por las últimas noticias acerca de los compromisos a Leaseweb, AVG, Avira, así como las acciones realizadas por los SEA contra Twitter, The Hufington Post y demás, que lo que más llama la atención de estos ataques es que aparecen en los medios como modificaciones de la web, ya que estos grupos buscan sobretodo notoriedad. Pero parece que nadie se da cuenta en la gravedad que esto entraña en caso de caer en otro tipo de manos menos...propagandísticas. El comprometer un dominio puede suponer, a modo de ejemplo y si se prepara convenientemente, lo siguiente:

• Posibilidad de redireccionar todo correo electrónico dirigido @dominiocomprometido.com a servidores controlados por los atacantes.
• Creación de phishings de páginas supuestamente legítimas, pero que finalmente son controladas por usuarios ajenos (el usuario que navega a la web, sigue comprobando que el dominio es correcto, por lo que asume que es legítima)
• Imaginemos los dominios de AVG o AVIRA, si bajo sus dominios comprometidos tienen un servicio de actualizaciones para sus software antivirus, en actualizaciones.dominiocomprometido.com. Dicho subdominio podría prepararse para que al solicitarse el software realmente fuese un fichero binario malicioso. O directamente, la descarga de las versiones gratuitas de dicho software, se sustituyesen por otros ejecutables.
• Y un largo etcétera, mismas técnicas de post-explotación que afectarían a los usuarios que accediesen o utilizasen servicios en dichos dominios.

Como veis el impacto y el compromiso no se realiza sobre la empresa en si en la mayoría de los casos, si no contra su imagen pública (defaces) o contra los visitantes (¡¡nosotros!!).

Corrección inmediata, propagación lenta

Uno de los grandes inconvenientes que se encuentran en la recuperación ante un problema o incidente de seguridad que afecte al DNS es la propagación de las correcciones, debido al propio concepto de DNS y su arquitectura de Internet. Si bien las empresas como leaseweb detectaron el problema rápidamente y pudieron recuperar sus registros DNS originales, muchos servidores DNS dónde se queda establecida la versión anterior envenenada tardaron en actualizar, de ahí que la corrección sea progresiva.

Resumiendo

Una web o webs afectadas por un secuestro de dominio no implica un robo de datos de usuarios y un compromiso de sus servidores. Por lo tanto, recomiendo huir de titulares tipo "XXX Team hackea YYYY" y utilizar en su lugar "XXX Team hackea ZZZZ, empresa encargada de gestionar los dominios de YYYY", más que nada para no liar al personal.

Si queréis conocer todos los entresijos, peligros, amenazas, recomendaciones y demás temas a tener en cuenta acerca del secuestro de dominios o Domain Hijacking, os recomiendo este genial informe en PDF de la ICANN, publicado en 2005 por parte del Security and Stability Advisory Committee (SSAC).

Leer más...

EU2010.es: el FAIL es para...

¡Hola amigos! Soy Co...(perdón, no podía evitarlo)

Hoy vamos a explicar la diferencia entre usuarios que explotan Cross-Site Scriptings y "hackers" que consiguen saltarse sistemas de seguridad de una página web:

- Cross-Site Scripting

Versión teórica: Fallo en la validación de los datos introducidos por un usuario en la aplicación. En caso de que dichos datos sean código HTML o JavaScript, estos serán interpretados por el navegador del usuario.

Versión para toda la familia: Te hago hacer clic en un enlace el cual realiza la búsqueda directamente (al incluir el parámetro y valor de lo que queremos buscar ya en la petición web) y en tu navegador aparece la respuesta que devuelve la aplicación. Si el valor es una cadena de texto que contiene ciertos carácteres especiales, conseguiremos introducir código HTML o Javascript y mostrarlo en tu navegador (lado cliente).

- "hackers" que consiguen saltarse sistemas de seguridad de una página web

Versión teórica: Acceso al servidor que alberga la web o explotación de una vulnerabilidad en la aplicación que permite ejecutar sentencias con privilegios suficientes para modificar documentos del servidor web o introducir nuevos valores en base de datos.Conseguir actualizar la base de datos y modificar/añadir registros directamente, para que los cambios sean permanentes y todo el mundo los vea al acceder a la aplicación o conseguir explotar vulnerabilidades de ejecución remota de comandos, etc.

Versión para toda la familia: ¡Han entrado al servidor donde está la web, y han modificado los ficheros para mostrar otra cosa! ¡Oh Cielos!

Casi todos sabemos que el mensaje que se distribuía estos días por twitter era el correspondiente a quejas sobre el precio de la web de la Presidencia de España en la Unión Europea (eu2010.es), incluyendo un enlace a dicha web, en la que se mostraba la cara de Rowan Atkinson interpretando a su personaje más famoso, Mr.Bean. Ese enlace, al distribuirse mediante el servicio de microblogging, estaba acortado para que cupiese perfectamente. Si a uno no se le ocurre mirar la dirección a la que está apuntando realmente, y accede, se toparía con el supuesto "asalto de Mr.Bean".

La dirección completa a la que se apuntaba era la siguiente:

http://www.eu2010.es/en/resultadoBusqueda.html?query=%3Cscript%3Edocument.write%28%27%3Cimg%20src%3D%22http%3A%2F%2Fblog.tmcnet.com%2Fblog%2Ftom-keating%2Fimages%2Fmr-bean.jpg%22%20%2F%3E%27%29%3C%2Fscript%3E&index=buscadorGeneral_en

Análisis rápido:

• Funcionalidad vulnerable: resultadoBusqueda.html
• Parámetro vulnerable: query
• Código inyectado en la web, interpretado por el navegador:

La función javascript document.write recibe como parámetro una cadena de texto, y esta es escrita en el documento actual. Pero no escrita directamente en el fichero, si no en el documento que estamos visualizando en el navegador, repito, EN EL NAVEGADOR. Como podéis deducir, la cadena de texto es un código HTML que importa una imagen, que recoge de la dirección web http://blog.tmcnet.com/blog/tom-keating/images/mr-bean.jpg.

De Cross-Site Scripting y sus tipos (persistente y no persistente), así como modificaciones concretas en según que parámetros, os hemos hablado por aquí largo y tendido, e incluso, hemos practicado con ellos, teniendo corazonadas o estudiando audiencias web de los blogs, entre otros.

¿Y qué pasa? Que también os hemos hablado muchas veces de los medios de comunicación frente a "hackeos", como se toman las noticias, como las resumen, como se hacen eco de ellas, las palabras que utilizan y demás, el problema es que el público general, cuando veían el telediario hoy, o visitaban sus periódicos online, se han quedado con una idea que no es del todo...cierta, o por lo menos con tal magnitud.

Si, es mucho dinero para una web realizada sobre un software libre OpenCMS (versión 7.5.1, por lo menos es la última...), con traducciones automáticas a otros idiomas (eso cuesta 180.000 euros según esta nota de adjudicación), y tiene fallos de seguridad, pero este no es de los más graves-alerta-se.cae.el.mundo-todos.al.bunker-primero.mujeres.y.niños. Este se debería quedar en anecdótico.

Leer más...

Seguridad por oscuridad ¿verdadera seguridad?

En el día a día de mi profesión veo, entre otras otros hábitos y políticas, diferentes formas de afrontar la seguridad por parte de las empresas.

La primera y más reconocida por parte de clientes, organizaciones e incluso entre departamentos dentro de las mismas compañías, es la seguridad por oscuridad. Raro se me hace a veces el encontrar titulares en prensa especializada en el mundillo de los fabricantes, mayoristas, integradores y clientes españoles, como SIC, TCN, o Red Seguridad, en los que se publica que tal o cual organización ha confiado su seguridad en la solución de "nosequé" fabricante de UTMs o de antivirus. Cuando hago una presentación a clientes de los productos de mi empresa, suelo mantener la confidencialidad de los clientes con los que trabajo, mencionando los sectores a los que se adecúa mejor nuestra tecnología, pero sin identificar a nuestros actuales clientes.

En general, corporaciones cuya información requiere de especiales cuidados (véase bancos y cajas o como dice mi compañero Javier.... los que ponen la pasta colgando en Internet) suelen ser más comedidos ante determinadas publicaciones o "disclosures" de información. ¿Por qué? ¿Por qué ese tipo de corporaciones sí que tienen fuertes restricciones con lo que se publica en los medios de prensa y las demás no? ¿Es que los que sí que publican a los 4 vientos no les importa tanto lo que protegen? Organizaciones que pertenecen a la administración pública, están obligados porque han de publicar en el BOE cómo invierten los impuestos de los españoles. Otras, en general, relacionadas con el mundo de la industria, energéticas, salud, viajes,... lo que tienen para proteger no es dinero como beneficio directo, sino a través de producto transformado: sus datos. Sin embargo, éstas últimas, suelen tener menos tapujos a la hora de indicar qué mecanismos utilizan como primera o segunda línea de defensa, qué tipo de tecnología de autenticación, de cifrado, etc,...

Mi pregunta ante estos hechos son: ¿cuál de las dos políticas es la correcta? Parece de sentido común el pensar que el no divulgar información al exterior sobre los datos concretos de en qué producto/fabricante confiamos nuestros huevos (los de la cesta, claro) puede ser una medida de los más acertada.

Sin embargo, el otro día leyendo una de estas revistas que mencionaba anteriormente, en una entrevista realizada a un directivo de una aseguradora, una afirmación que me resultó muy interesante: "La seguridad no tiene que ser secreta: secretos son los procedimientos". Y en buena parte tiene razón.

Estaréis hartos de oirnos (o leernos) repetir en nuestros posts que las buenas prácticas en materia de seguridad han de incluir unos procedimientos sólidos y una metodología basada en la estrategia del diseño, la fortificación (1, 2, 3 y 4) (esta vez no me pilláis con el bastionado, aunque sea válido) de las infraestructuras, de política de parches y actualizaciones, de selección de la tecnología de calidad y adecuada a los tiempos y a los ataques actuales,... Al fin y al cabo "Quien nada hace, nada teme" por lo que, aunque te decantes por la elección de un fabricante u otro para proteger parte de la seguridad de tu organización, si partes de unos buenos principios como los mencionados, y mientras no se desvele la estrategia o detalles internos de la red.

Yo sin embargo, sigo pensando que, mientras no sea obligatorio, mejor dar un trabajo de más a los atacantes para averiguar qué me protege y qué versión, en vez de evitarles un montón de pruebas de auditoría.

Leer más...