Menudo tocho de libro!! La verdad es que me lo compré hace unos meses en Amsterdam pero lo tenia guardado para esta ocasión. A ver si mañana saco un poco de tiempo para empezar a leerlo aunque con lo gordo que es veremos lo que me lleva jeje
Archivo del enero de 2010
Mi regalo de reyes
ene 5
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
TPlus v3.15 disponible
ene 4
Ya está disponible la versión 3.15 en la que se solucionan algunos errores:
- solucionado el problema al buscar un usuario por nombre sin introducir una provincia
- solucionado problema al enviar mensajes
- solucionado problema al ver amigos de tus amigos
Además he añadido la opción de cambiar el estado automáticamente al abrir TPlus. Para ello he añadido un nuevo formulario donde podeis meter las frases que luego se escogerán de forma aleatoria al abrir TPlus.
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.
eNYe Spider v1.2
ene 3
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.
Concursos CrackSLatinoS
ene 3
Para el que no conozca CrackSLatinoS, es una comunidad de crackers en la que se todan todos los temas de ingeniería inversa (cracking, reverses, exploits, malwares, etc). De la mano del gran maestro Ricardo Narvaja, hay toda una lista de expertos en la materia que puedes encontrar en el grupo: http://groups.google.com/group/crackslatinos?hl=es.
Si te gusta la ingeriería inversa, en la web de Ricardo tienes manuales para aburrir, de todo tipo. Es más, cada mes hay concursos con diversas secciones en los que vengo colaborando desde hace unos meses. Entre los concursos y la cantidad de manuales (miles) que hay en su web (y todos en la lengua de cervantes) he podido aprender muchisimo. Gracias a la ayuda de todos los miembros de CrackSLatinoS que son una gente fantástica y siempre hacen lo posible por ayudar con tus dudas.
Como ya he comentado, llevo unos meses haciendo los concursos, en los que a final de mes enviamos un tutorial con nuestras soluciones. Luego Ricardo los sube todos a su web y se convierten en nuevos manuales de obligada lectura. De esta forma la información nunca está obsoleta ya que, muchas veces buscamos información en Internet sobre algo y vemos manuales muy antiguos que ya no sirven en estos tiempos.
Dejo un link al último tutorial que mandé para el concurso (correcpondiente a la sección de Exploitme) en el que había que hacer un exploit para el programa NaviCOPA, que es un servidor web para Windows. Podeis descargar el tutorial aquí: exploit NaviCOPA
El exploit lo resuelvo de dos formas:
- Buscando con un pequeño script y con la ayuda del OllyDbg el tamaño donde se desborda el buffer
- Comparando con Turbodiff las diferencias entre esta versión y la siguien en la que está parcheado el error
Aprovecho para dar las gracias al maestro Ricardo Narvaja por el tuto de Turbodiff y por resolver siempre mis dudas.
¿Quién dijo que programar en .NET era coser y cantar? Hay muchas librerías que nos facilitan la vida pero a veces no funcionan del todo bien haciendo cosas raras o simplemente se les olvido incluir el control de ciertas situaciones.
Programando Squipy me he topado con un gran problema y es que cuando llego a una web que me hace una redirección (por ejemplo un 302) para que el HttpWebRequest la siga y obtenga luego la página a donde se redirige, he de poner AllowAutoRedirect = true
Pero si configuramos AllowAutoRedirect = true entonces no podremos capturar las cookies y, por tanto, no entrar a ciertas webs en las que necesitamos validación.
Si ponemos AllowAutoRedirect = false podremos capturar la cookie sin problemas usando GetResponseHeader(“Set-Cookie“) pero no se hará la redirección y no llegaremos a la página a la que se redirige.
Así que la solución final pasa por poner la redirección a false, capturar la cookie con Set-Cookie y luego comprobar el StatusCode para ver si la página devuelve una redirección, en cuyo caso, incluiremos nuestra cookie con Headers.Add(“Cookie“, nuestraCookie) y capturaremos la página a donde nos redirige con GetResponseHeader(“Location“). Tras esto crearemos manualmente otro HttpWebRequest para llamar a la nueva página.
Os dejo un código de ejemplo:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(urlDestino);
request.AllowAutoRedirect = false;
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
while (response.StatusCode == HttpStatusCode.Found) {
String nuevaUrl = “http://” + response.ResponseUri.Host + response.GetResponseHeader(“Location“);
request = (HttpWebRequest) WebRequest.Create(nuevaUrl);
request.AllowAutoRedirect = false;
response = (HttpWebResponse) request.GetResponse();
}
A falta de comprobar con Set-Cookie si tenemos alguna cookie y guardarla en un contenedor de Cookies para luego usarla en el nuevo envío.
Feliz Año nuevo a todos!
