Entradas con la etiqueta Hackear webs

El falso “hackeo” de la web de la presidencia española, XSS y lecciones para aprender

A estas horas ya todo el mundo debe saber lo ocurrido durante el día de ayer con la web de la Presidencia española de la Unión Europea (www.eu2010.es). De este “supuesto ataque” se pueden sacar conclusiones y tratar de aprender algo.

Durante el día de ayer saltó a los medios más generalistas la noticia de que un “hacker” (no se podía emplear otro término) había entrado en la recién inaugurada web de la Presidencia española de la Unión Europea (www.eu2010.es) y había incrustado en ella una imagen del conocido humorista británico Rowan Atkinson en su papel de Mr. Bean.

La noticia está causando un gran revuelo, incluso más después de conocer el dato de que el proyecto había costado más de 11 millones de euros, si bien este presupuesto no solo cubre el alojamiento, desarrollo y seguridad del sitio. También se incluyen otros asuntos relacionados con la instalación y funcionamiento de los medios de telecomunicaciones, sistemas informáticos y servicios de videostreaming de los centros de prensa que se habilitarán en las cumbres internacionales.

Pero realmente el sitio no ha sido vulnerado, en el sentido de que nadie ha tomado su control. En esta ocasión se volvió a cumplir aquello de “no dejar que la realidad estropee una buena noticia”. El problema radicaba en un cross-site scripting (XSS) que a través de una petición especialmente manipulada, había circulado en forma de URL por redes sociales, mensajería, etc. Alguien pulsó sobre el enlace del XSS y la noticia ya estaba creada.

La petición real que circuló tenía la forma:

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

Se trata de un XSS tradicional no persistente. Es decir, si no se accede a través de ese enlace, en realidad no se puede ver ningún ataque. No deja de ser un problema de seguridad en el desarrollo de la web, pero no tiene nada que ver con el hecho de que alguien entre y tome el control de unos servidores.

En el blog Security By Default, lo han explicado de una forma muy
instructiva en:
http://www.securitybydefault.com/2010/01/eu2010es-el-fail-es-para.html

Por otra parte, tampoco se puede considerar totalmente correcta la explicación dada por el gobierno español para negar el supuesto “hackeo”:

“El supuesto ataque -señala Moncloa en un comunicado- ha consistido en que se ha empleado una captura de una página de búsqueda del sitio para hacer un fotomontaje al que se ha asignado una dirección (url o enlace) que luego se ha distribuido en Internet, a través de redes sociales y blogs”.

En un fallido intento de restar importancia al asunto, se ha usado la palabra “fotomontaje”, pero la verdad es que la imagen capturada y el fallo de seguridad eran reales, no producto del “PhotoShop”. La explicación certera hubiese sido que la imagen de Mr. Bean, debido a un problema de seguridad, se mostraba “interpretada en” la página, pero no “desde” ella. No hubiese estado de más aclarar que mostrar una imagen es el menos grave los daños que se podrían haber causado. En cualquiera de los casos, el daño a la reputación está hecho, y es quizás el problema más serio a los que se enfrentan los responsables de la página en estos momentos.

Con esto, está claro que la web no fue “hackeada”, pero está igual de claro que contenía un problema de seguridad en su buscador. O bien no se había realizado una auditoría de seguridad o no se había prestado atención a los problemas de cross-site scripting encontrados. Ambas circunstancias suelen ser habituales.

En muchas ocasiones en nuestros trabajos de auditoría nos planteamos cómo calificar la gravedad de un cross-site scripting; desde luego, no permite “entrar” en el servidor, pero el alcance que puede provocar (y aquí tenemos un claro ejemplo) puede ser igual de serio. No se presta la suficiente atención en corregirlo (dado que no se considera un problema grave) y se da carpetazo al asunto con un “este fallo no permite entrar en el servidor”.

En una página sin control de sesión y sin datos que robar, el riesgo de un error como el que nos ocupa actualmente (“de libro” y más habitual de lo que parece) puede ser considerado como de riesgo medio desde el punto de vista técnico, si bien ya hemos visto que el impacto mediático ha sido alto y por tanto también debe valorarse el daño potencial a la imagen de este tipo de vulnerabilidades.

También existen casos en que las vulnerabilidades por XSS son consideradas de riesgo alto por criterios técnicos. Debemos pensar que los vectores de ataques de las vulnerabilidades XSS son variados y dependen del contexto, pudiendo ser utilizados en casos de phishings, distribución de malware desde fuentes teóricamente confiables, suplantación de sesiones, robos de cookies, etc.

Aunque en este caso no llegaron a entrar en el servidor (tal como múltiples medios aseguraban), a efectos prácticos el resultado final que se ha transmitido a la conciencia colectiva es equivalente a si hubieran tomado el control. La imagen que se ha transmitido sobre el gobierno español y sobre Telefónica como encargada del proyecto, tanto en España como en Europa (donde el incidente también ha transcendido), no es nada positiva. Por eso, una vez más es importante recordar la importancia de auditar y corregir cualquier tipo de fallo encontrado, aunque sea un cross-site-scripting que no permita “entrar” en el servidor.

Fuente: Hispasec

Etiquetas: , ,

Seguridad en webs con mod_rewrite

Para el que no lo sepa, mod_rewrite es un módulo del servidor web Apache que nos permite, a través de un .htaccess, reescribir urls. Con esto, a parte de ganar puntos en Google, para mejorar el posicionamiento de nuestra página, también permite ‘ocultar’ los parámetros que se envían de una página a otra, dificultando una posible inyección de SQL. Por ejemplo, una llamada que antes era:

http://miweb.com/noticia.php?id=30

pasa a ser, por ejemplo:

http://miweb.com/listado_de_noticias/30

Todo esto conseguido gracias a un pequeño fichero .htaccess similar a este:

<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine on
RewriteRule ^listado_de_noticias/([0-9]+) noticia.php?id=$1 [L,NC]
</IfModule>

Como vemos, por un lado oculta la url original y por otro restringe mediante el .htaccess la entrada de parámetros, en este caso, el id sólo puede ser un número entre 0 y 9, por lo que no podremos escribir nada del estilo:

http://miweb.com/listado_de_noticias/30+and+1=1

Otro caso diferente sería cuando la inyección no se realiza en un valor numérico, por ejemplo:

RewriteRule ^listado_de_noticias/([a-zA-Z0-9]+) noticia.php?id=$1 [L,NC]

En este caso, nos permite introdudir números y letras, pero tampoco podríamos inyectar código SQL ya que ni el espacio ni las comillas están permitidos:

http://miweb.com/listado_de_noticias/titulo’+and+’1′=’1

En resumen, todo varía en función de cómo esté configurado el .htaccess, al que por supuesto no tenemos acceso. Pero eso no es todo. Muchos administradores piensan que con esto la web ya está protegida a ataques de inyección SQL pero realmente el mod_rewrite es sólo una máscara ya que si el fichero PHP final (noticia.php en este caso) tenía problemas de inyección, los seguirá teniendo. Y si alguien llega a averiguar el nombre del fichero original, podrá acceder directamente sin necesidad de pasar por el mod_rewrite.

Sólo hay que echarle un poco de imaginación. Por ejemplo, buscar nombres similares a ver si hay suerte. Si la url es  http://miweb.com/listado_de_noticias/30 se pueden realizar búsquedas a ver si hallamos la página original:

http://miweb.com/listado_de_noticias.php?id=30

http://miweb.com/noticias.php?id=30

http://miweb.com/noticias.php?idnoticia=30

…..

Aunque parezca un trabajo de chinos, muchas veces da resultado.

Y si el mod_rewrite se ha aplicado sólo por mantener la seguridad (o mejorar el posicionamiento) y no viene unido a un cambio de estética o remodelación de la web, lo más probable es que podamos encontrar el nombre de algún fichero original mediante otras técnicas, por ejemplo:

  • Buscando en Google y demás buscadores un listado de las páginas indexadas de esa web, con la búsqueda:  ‘site:miweb.com inurl:.php’. Esto nos puede mostrar páginas antiguas que aún sigan indexadas.
  • Buscando con un spider el contenido de cada página de la web. Muchas veces se olvida cambiar una URL para que apunte a la nueva dirección en lugar de al fichero PHP
  • Buscando en Google enlaces hacia esa web, donde es posible que un link antiguo apunte a una noticia o cualquier otra sección de la web, con la búsqueda: ‘link:miweb.com’ o bien: site:.com “miweb.com” -site:miweb.com
  • Buscando en WayBack Machine, que guarda un histórico de muchísimas webs (150 billones … casi nada jeje) y además suele guardar una captura de toda la web cada mes, por lo que muy probablemante escontremos la estructura antigua.

Etiquetas: , ,

eNYe Spider v1.2

Tras un año sin tocar este programa, he subido una nueva actualización en la que se solucionan varios problemas internos. Básicamente problemas de navegabilidad en ciertas webs. Hice estos cambios porque en Squipy he incorporado también un Spider … bueno, he integrado este Spider :)

Y como llevaba tiempo haciendo arreglos cada vez que me topaba con alguna web especial o que provocaba algún error, pues los he agrupado todos en el nuevo release.

El motivo por el que subí de la 1.0 a la 1.2 es porque tras crear la 1.1 arreglé un error jejeje .. pero la 1.1 nunca vio la luz.

Etiquetas: , , , , , ,

Squipy está a punto de parir

Aprovechando que es fin de año y todo el mundo hace promesas, yo me he propuesto escribir más a menudo en el blog. Se que no lo lee ni dios, salvo la gente que llega directamente al POST del TPlus a preguntar una y otra vez lo mismo (esto es un infierno!!!!) pero escribiré para leerme yo mismo :)

Bueno, estas Navidades, además de inflarme a turrón de chocolate, he estado programando una pequeña aplicación a la que llamé Squipy. Se trata de un proxy, no para navegar a través de él con varios equipos, sino para analziar el comportamento de algunas páginas y modificar los datos que se mandan.

Algo similar a lo que hace Tamper Data o Paros o muchos otros pero personalizado a mi gusto … si es que soy algo maniático con las cosas, lo se!

El Tamper Data está muy bien para hacer un cambio o dos pero cuando son muchos te vuelves loco ya que hay que modificar cada paquete.

El Paros está también muy bien pero no me permite poner cambios generales y hay que modificar también cada paquete muchas veces.

La idea de hacer este programa surgio por varias deficiencias que vi en el Paros y que, a pesar de que otros programas si que lo tenían, eran algo complicados para lo que realmente necesito. Yo principalmente lo eché en falta en algunos detalles:

  • La opción de poder modificar el User-Agent de forma indefinida para entrar en la web móvil de Tuenti y subir fotos (ya que tiene un filtro por User-Agent)
  • La opción de convertir de forma automática las peticiones POST a GET o a la inversa, para probar inyecciones SQL por POST realizando los envíos cómodamente mediante GET
  • Poder modificar tanto los datos que se mandan al servidor como los que se reciben hacia el navegador
  • No tener que contar los bytes que envío en un POST tras una modificación, para ajustar el tamaño del paquete
  • No tener un bombardeo de peticiones para filtrar cuando activo el análisis (como ocurre con el Tamper Data) y poder analizar sólo una determinada URL o dentro de una URL sólo ciertos ficheros …

Squipy

Puedes descargar el manual que espero ir ampliándolo si incluyo nuevas funcionalidades. Es muy breve pero trae varias capturas en las que explica cada opción del programa.

En cuanto termine de testearla la subiré a la web. Si alguien tiene alguna sugerencia que me lo diga.

Etiquetas: , , , , , , ,

eNYe-Spider

He subido a la web http://www.pepelux.org y pronto estará también en la web de eNYe (http://www.enye-sec.org) un programa que analiza remotamente una web sacando la estructura de ficheros y directorios … vamos, lo que es un spider o web crawler.

eNYe-Spider

Leer el resto de esta entrada »

Etiquetas: , , , , ,

Defacear páginas web

En el IRC, foros, blogs, etc te encuentras mucha gente (sobre todo menores de edad) que su máxima diversión es defacear páginas web. No sólo son unos inconscientes sino que además son un peligro, ya que muchos de ellos no saben ni lo que están haciendo. Se limitan a seguir manuales de los que entienden la mitad.

Leer el resto de esta entrada »

Etiquetas: , ,