03 junio 2009

Para los que conozcáis zone-h, el portal de seguridad informática con uno de los archivos de defaces más activos, estaréis hartos de ver como día a día, miles y miles de sitios web sufren las alteraciones de personas o grupos, que dejan mensajes patrióticos, dedicatorias a novios/as y/o amigos/as o un simple "hacked by ponga-aqui-su-nick-con-números-en-vez-de-vocales". En este archivo, además de poder definir servidor web y sistema operativo afectados, junto al dominio atacado puede marcarse si se considera un ataque especial por tratarse de un sitio web importante o relevante.


Todo esto viene a que recientemente se ha publicado una noticia en informationweek en la que se informaba que el ejército de Estados Unidos había sufrido un ataque en sus servidores web, más concretamente el MCAAP - Army's McAlester Ammunition Plant, por parte de un grupo turco que se hacía llamar "m0sted" allá por Enero de este año. Realicemos una búsqueda simple en google de este nombre para saber un poco más de ellos, así como en bing.com que parece que da karma positivo últimamente por hablar de él. Se ha tenido constancia de que anteriormente, a finales del 2007, también atacaron los servidores del Army Corps of Engineers.

"m0sted" es un claro protagonista de los archivos de Zone-H, con más de 300 dominios "fusilados", todos marcados como especiales.


Y diréis, "Bien, ha pasado medio año ya del MCAAP, y casi dos años del otro tema, ¿y ahora qué?". Ahora es cuando el Departamento de Defensa está investigando estos dos sucesos, para evaluar si dichas entradas fueron más allá del deface, y si se pudo llegar a robar información sensible. ¿El actuar después de tantos meses tendrá que ver con la noticia de que Obama ha creado su pequeño equipo que vela por la seguridad cibernética? Igual se lo toman como entrenamiento para cuando vengan esas ciberguerras del futuro de las que nos hablan.

"m0sted" pudo modificar las páginas (como en el caso de la amplia mayoría de sus más de 300 defaces archivados) mediante vulnerabilidades de tipo SQL Injection, inyectando su propio contenido a la base de datos que gestionaba la aplicación para mostrar en los sitios webs mensajes a su antojo. Si revisamos algunos de sus ataques, veremos como sus actos pasados han aparecido en varios medios por los defaces a las páginas web de Naciones Unidas y a la de los laboratorios Karpesky, en su dominio de Malasia entre otras.


Sinceramente, y bajo mi humilde opinión, tras analizar casi todos sus ataques, que se han basado en añadir noticias con dedicatoria de tipo "hacked-by blablabla por la patria blabla guerras de US malas blabla", sean páginas del gobierno, del ejército como de marcas de coches (mientras manejen sentencias SQL para rescatar contenido y que no se realice una correcta validación en caso de que un visitante introduzca sus propias peticiones modificadas en la URL) y de un modo masivo (si se utiliza el mismo motor de noticias para todas las versiones de la página según idioma u otros criterios, atacando uno ya puedes romper varias), podría poner la mano en el fuego sobre el hecho de que estos ataques por parte de este grupo turco con tanto tiempo libre no han ido más allá de simples sentencias SQL de UPDATE contra las bases de datos. Ya veremos que dice Defensa al respecto, es mi opinión y puedo equivocarme perfectamente.

Esto no quita que ya en pleno siglo XXI, después de años y años y años sabiendo de las posibilidades que dan las vulnerabilides de tipo inyección SQL, todavía muchos desarrolladores web no tengan constancia de como evitar este tipo de ataques.

Collejas hay para todos.

[+] Anti-U.S. Hackers Infiltrate Army Servers
[+] Archive de la antigua web del grupo m0sted
[+] Portal de seguridad Zone-H

9 comments :

Zerial dijo...

Error (o falta de) parseo en los parametros pasados por GET y POST. Mientras los desarrolladores sigan cayendo en cosas como estas, siempre habrá gente explotando esas fallas humanas. Si bien los "hackers" nunca entran al servidor lo que si hacen es un deface sin, necesariamente, tener un usuario y clave para acceder, simplemente modifican una consulta de alguna busqueda o algun parametro que les permita indagar más allá de la web.

José A. Guasch dijo...

Un fallo lo tiene cualquiera, pero si ese cualquiera está al frente de según que sitios web, que contengan información MUY relevante, la cosa cambia muy mucho.

Es más, esto es lo de siempre: cuando un día te despiertas por la mañana, entras en la web que administras y de repente ves la bandera de tu país en llamas en un gif, con doce calaveras girando escupiendo fuego morado, símbolos raros y demás, es cuando te das cuenta que tienes un problema de seguridad.

Pero...¿y si no te dan esa señal, y el grupo en vez de querer llamar la atención y salir en ZONE-H, le da por recuperar toda tu base de datos y hacer con ella quién sabe qué?

Más vale prevenir que curar

eduardo abril dijo...

Este ataque es muy vistoso pero, por ello mismo, es un tanto inocente ...

A mí me preocupan mucho más los ataques contra, por poner un ejemplo, tiendas online, de donde pueden intentar recuperarse números de tarjetas de crédito que pueden usarse luego para compras fraudulentas.

Y lo mejor de todo es que, aunque parezca lo contrario, los ataques por SQL-i están todavía de moda. En los foros underground (los de verdad), se publican todo los días sql-i contra varios sitios web ...

Saludos,

José A. Guasch dijo...

Exacto eduardo, no hay más que ver noticias que hemos comentado anteriormente por aquí sobre los ataques con su correspondiente petición de rescate, información muy valiosa, o como comentas, tiendas online a los que les cuesta también tanto esfuerzo, además de filtrar las peticiones y validar correctamente sus parámetros, cifrar según que columnas de las tablas de sus bases de datos.

Asfasfos dijo...

Ya pero aunque a veces los SQL Injection solo metan una frase que diga "hacked by..." yo creo que si se puede evitarlo hay que hacerlo y mas si es una web importante. Que luego vienen los periodistas y no tienen otro post que hacer mas que "LA PAGINA DE TAL TAL ATACADA POR NO SE QUIEN" siendo que igual tienen un script ya hecho y no hacen mas que darle a un boton

eduardo abril dijo...

>>cifrar según que columnas de las tablas >>de sus bases de datos.

Uyyy .. esto en particular es un poco complicado. Intento explicarlo rápido:

P.ej. en un banco, las bases de datos gordas suelen estar en los mainfranes, o haber sido "exportadas" a algún oracle, pero lo importante es que es una estructura creada hace siglos (20 años) y que todo ha sido programado en cobol/packbase o algo así a partir de esa estructura.

Las aplicaciones que necesitan esas bases de datos (una aplicación sería la que lleva los créditos, otra la de los préstamos, otra los impagados, ...) tiran de esas bases de datos, que deberían estar cifradas.

Lo cual quiere decir que, para cifrarlas, tienes que cambiar un MONTÓN de aplicaciones, del orden de cientos, lo cual suele ser demasiado trabajo, y por lo tanto no se hace.

Y sí, en un mundo ideal sería cambiar una rutina por otra, pero en la práctica es un cambio enorme, que requiere un montón de normativa, pruebas, desarrollos, subidas a test, subidas escalonadas a producción ... la leche ...

Sería algo así como el paso al euro: en principio trivial, pero en la práctica es la leche.

Saludos,


Así que, muchas veces, en entornos financieros esto no se cumple, y mucho digamos en una tienda de libros.

Anónimo dijo...

+1 ( lástima que esto no tenga karma ) al post y a la reflexión.

Coincido en que lo "importante" no son "hackers" turcos haciendo defaces, sino la cantidad de sitios: aplicativos de administración electrónica local, regional y nacional, tiendas online, redes sociales, etc, que son vulnerables a ataques ( unas veces triviales y otras no tanto ) que permiten desde recuperar información sensible, a acceder a los aplicativos con usuarios legítimos, pasando por ejecutar comandos en el servidor.

Parece mentira, y lamentablemente no lo es, que tras más de 10 años de "inseguridad" en entornos web no se esté cerca del fin del problema, sino que cada día, debido a la proliferación de soluciones y servicios web desarrollados "a prisa" y con "la seguridad muy lejos de la mente", el número de escenarios explotables aumente y sobre todo se acerque más y más al usuario "final".

Inyecciones de todo tipo, desde SQL, pasando por LDAP y terminando en comandos, abundan y mucho.Y lo que es peor, la escasa homogeneidad de los aplicativos web, el "me hago yo el mío", el no usar ningún framework de desarrollo ... en definitiva la "inexistencia" de buenas prácticas en el desarrollo de muchos entornos que se presuponen debían contar con unos mínimos criterios de seguridad, hacen que el hecho de que unos turcos hagan un deface sea una mera anécdota.

Anonymous dijo...

+1 ( lástima que esto no tenga karma ) al post y a la reflexión.

Coincido en que lo "importante" no son "hackers" turcos haciendo defaces, sino la cantidad de sitios: aplicativos de administración electrónica local, regional y nacional, tiendas online, redes sociales, etc, que son vulnerables a ataques ( unas veces triviales y otras no tanto ) que permiten desde recuperar información sensible, a acceder a los aplicativos con usuarios legítimos, pasando por ejecutar comandos en el servidor.

Parece mentira, y lamentablemente no lo es, que tras más de 10 años de "inseguridad" en entornos web no se esté cerca del fin del problema, sino que cada día, debido a la proliferación de soluciones y servicios web desarrollados "a prisa" y con "la seguridad muy lejos de la mente", el número de escenarios explotables aumente y sobre todo se acerque más y más al usuario "final".

Inyecciones de todo tipo, desde SQL, pasando por LDAP y terminando en comandos, abundan y mucho.Y lo que es peor, la escasa homogeneidad de los aplicativos web, el "me hago yo el mío", el no usar ningún framework de desarrollo ... en definitiva la "inexistencia" de buenas prácticas en el desarrollo de muchos entornos que se presuponen debían contar con unos mínimos criterios de seguridad, hacen que el hecho de que unos turcos hagan un deface sea una mera anécdota.

eduardo abril dijo...

Este ataque es muy vistoso pero, por ello mismo, es un tanto inocente ...

A mí me preocupan mucho más los ataques contra, por poner un ejemplo, tiendas online, de donde pueden intentar recuperarse números de tarjetas de crédito que pueden usarse luego para compras fraudulentas.

Y lo mejor de todo es que, aunque parezca lo contrario, los ataques por SQL-i están todavía de moda. En los foros underground (los de verdad), se publican todo los días sql-i contra varios sitios web ...

Saludos,