Hace unos días, presa del aburrimiento y un toque de romanticismo a "flor de piel", decidí unirme a la corriente ("cuando el río suena, agua lleva" o eso nos dijo el que nos mintió) y comprobar el por que de la moda fotologuera, o floguera (usando el termino alternativo a Fotolog). Como no soy menos que nadie, me lo cree en Fotolog.com, casi diría siguiendo una suerte de lógica inconsciente dada por el nombre del dominio, ¿quien mejor para brindar un servicio de Fotolog, que alguien que se denomina a si mismo Fotolog?, eso si algunas cosas escapan a la lógica, y es que la lógica desaparece cuando se dota del factor humano a ciertas cosas de esta vida, y resulta que Fotolog.com no es la excepción.
Antes que nada, o mejor dicho de lo que sigue, quiero hacer un breve párrafo a modo de reflexión del motivo de creación del 90% de los fotologs:
Egocentrismo y falta de seguridad, combinado con tiempo libre en exceso y faltas de ganas de cambiar su situación de seres no vivientes, atados a un servicio que pretende dar a la luz a un yo interior marcado por la sociedad en la que vivimos (esto último va dedicado a una amiga), lo cual lleva a que las personas intenten proyectarse fuera de lo mund ano, o en otros términos un poco mas duros sus "fucking five minutes of glory". Hace bastante, Arlt (motivo de orgullo para todo argentino, o así debiera ser) escribía sobre esto, y hoy, 65 años después de su muerte, se consuma de manera evidente lo que el describiera como "manía fotográfica".
Volviendo, como ser pensante (o al menos eso es lo que pienso :P) y curioso que soy, de esto no me queda duda, decidí explorar un poco la inseguridad del servicio, solo para saber en las manos de quien se suponía que estaba confiando datos confidenciales, como dirección de correo, nombre, apellido, etc. Así fue que puse en práctica algo de lo citado en uno de los artículos anteriores, y use parte de la teoría aplicada a la navaja suiza, NetCat para los incultos :P, pero esta vez lo hice a través de lo que me gustaría denominar como "Python Hacking Tips".
Como ya he dicho varias veces en algunos foros, lo primero que hago cuando quiero verificar la seguridad de un sitio, es hacer un pequeño sondeo del servidor web que corre el mismo. Esto pasado a NetCat sería:
Bien, ustedes a esta altura ("están a 5000 bytes sobre el limite vertical, ya se están aburriendo"), un poco cansados de que no lleguemos al punto culmine dirán, ¿y que se supone que es eso?. Bien, esa es la respuesta ante una excepción, o error, generada en html por un conocido servidor web llamado Apache. Lo agradable del mismo, es que si no se toquetea un poco entre sus opciones, por defecto nos indica cual es su versión :O y en este caso su sistema operativo (véase la imagen). Hasta aquí, si bien eso es información un tanto crítica, siempre y cuando nadie lo descubra (jajaja) podemos decir que nadie esta muerto. Pero no, ja!, resulta que yo no me conformo con saber que los administradores de www.fotolog.com no actualizan su servidor web (ya que tienen la versión 1.3.33 haciendo muchas por delante), si no que voy y busco si existen "exploits"(explode it) para ganar acceso ilegal al sitio y robar información. Para esto, voy a Google y tipeo:
Pero amigos aquí no termina la fiesta, es que como muchos otros sitios, Fotolog.com tiene varios servidores (todos dentro de la misma red), entre ellos www1.fotolog.com. Este último, presenta una vulnerabilidad real y concisa, y para decirlo de manera mas pragmática, mucho mas grave en comparación a lo visto anteriormente. Repetimos el proceso con NetCat y el resultado esta vez es:
Lo interesante son los nuevos resultados. Esta vez no solo nos dio la versión y el sistema operativo, si no también que esta usando un parche especial llamado "mod_jk" en su versión "1.2.19". ¿Repetimos el proceso de Google y con que nos encontramos?, Fotolog.com vulnerable a una vulnerabilidad conocida como "remote buffer overflow", o "desbordamiento de buffer remoto" según mis capacidades de traductor. Esto, nos permitiría ganar acceso remoto al sitio por medio del uso de una "shell code". En definitiva, si bien no lo he probado (por cuestiones legales) estamos ante a una vulnerabilidad crítica, y si bien es posible que en este servidor no se guarden los datos confidenciales, si es posible que desde el mismo se pueda realizar una escalada de privilegios a otros servidores, donde se guarden bases de datos de los usuarios, o "sabe dios que otros documentos confidenciales".
Bien, ya vimos los errores/vulnerabilidades/inoperancia que yacen bajo el dominio www.fotolog.com, pero y ¿en donde quedo lo que dije sobre "Python hacking tips"?. No no, no soy un mentiroso, solo que pensé que sería mas práctico ejemplificar con NetCat. Sin embargo las pruebas son mejores en Python, es así que en los "ir y venir de la vida" (o como diría Vicentico, los caminos de la vida!!!) cree un pequeño "explorador" de esta vulnerabilidad y otras que subyacen en Apache, automatizando la búsqueda de los exploits para las mismas:
En principio solo es funcional para servidores Apache, pero con unas modificaciones mínimas, se puede adaptar a otros servidores web.
Y finalizando el tema, cabe destacar que en principio como "grave" se ve lo expuesto, de lo cual pienso alertar a Fotolog.com, pero también he encontrado un par de cosas interesantes, o ideas posibles, que si bien no las he implementado, si pienso hacerlo y dejar nota de ello aquí.
Espero que disfrutaran leyéndolo tanto como yo al escribirlo,
Saludos.
Pd: En un principio esto iba dentro del artículo en un comentario, pero por cierto motivo, me olvidé :P. En fin, en "Sueños en binario" se hace alusión al asunto, pero desde otro enfoque diferente. Así, que al que le interese leer otra "óptica" del mismo tema, ya sabe a donde ir :P.
Antes que nada, o mejor dicho de lo que sigue, quiero hacer un breve párrafo a modo de reflexión del motivo de creación del 90% de los fotologs:
Egocentrismo y falta de seguridad, combinado con tiempo libre en exceso y faltas de ganas de cambiar su situación de seres no vivientes, atados a un servicio que pretende dar a la luz a un yo interior
Volviendo, como ser pensante (o al menos eso es lo que pienso :P) y curioso que soy, de esto no me queda duda, decidí explorar un poco la inseguridad del servicio, solo para saber en las manos de quien se suponía que estaba confiando datos confidenciales, como dirección de correo, nombre, apellido, etc. Así fue que puse en práctica algo de lo citado en uno de los artículos anteriores, y use parte de la teoría aplicada a la navaja suiza, NetCat para los incultos :P, pero esta vez lo hice a través de lo que me gustaría denominar como "Python Hacking Tips".
Como ya he dicho varias veces en algunos foros, lo primero que hago cuando quiero verificar la seguridad de un sitio, es hacer un pequeño sondeo del servidor web que corre el mismo. Esto pasado a NetCat sería:
nc -vv www.fotolog.com 80Resultado?
get / http/1.0
get / http/1.0
Bien, ustedes a esta altura ("están a 5000 bytes sobre el limite vertical, ya se están aburriendo"), un poco cansados de que no lleguemos al punto culmine dirán, ¿y que se supone que es eso?. Bien, esa es la respuesta ante una excepción, o error, generada en html por un conocido servidor web llamado Apache. Lo agradable del mismo, es que si no se toquetea un poco entre sus opciones, por defecto nos indica cual es su versión :O y en este caso su sistema operativo (véase la imagen). Hasta aquí, si bien eso es información un tanto crítica, siempre y cuando nadie lo descubra (jajaja) podemos decir que nadie esta muerto. Pero no, ja!, resulta que yo no me conformo con saber que los administradores de www.fotolog.com no actualizan su servidor web (ya que tienen la versión 1.3.33 haciendo muchas por delante), si no que voy y busco si existen "exploits"(explode it) para ganar acceso ilegal al sitio y robar información. Para esto, voy a Google y tipeo:
Apache 1.3.33 site:www.milw0rm.comEsto, nos permite buscar las palabras "Apache 1.3.33" en el sitio www.milw0rm.com que segun mi punto de vista, es uno de los sitios que mejor trata el tema de los exploits. En principio todo parece correcto, los exploits que aparecen, son para diferentes distribuciones de Linux, pero sin embargo la arquitectura kernel de un Unix y un Linux no son tan diferentes, así que existe la probabilidad de que dichos exploits sean funcionales en el sistema operativo que utiliza el servidor de Fotolog.com.
Pero amigos aquí no termina la fiesta, es que como muchos otros sitios, Fotolog.com tiene varios servidores (todos dentro de la misma red), entre ellos www1.fotolog.com. Este último, presenta una vulnerabilidad real y concisa, y para decirlo de manera mas pragmática, mucho mas grave en comparación a lo visto anteriormente. Repetimos el proceso con NetCat y el resultado esta vez es:
Lo interesante son los nuevos resultados. Esta vez no solo nos dio la versión y el sistema operativo, si no también que esta usando un parche especial llamado "mod_jk" en su versión "1.2.19". ¿Repetimos el proceso de Google y con que nos encontramos?, Fotolog.com vulnerable a una vulnerabilidad conocida como "remote buffer overflow", o "desbordamiento de buffer remoto" según mis capacidades de traductor. Esto, nos permitiría ganar acceso remoto al sitio por medio del uso de una "shell code". En definitiva, si bien no lo he probado (por cuestiones legales) estamos ante a una vulnerabilidad crítica, y si bien es posible que en este servidor no se guarden los datos confidenciales, si es posible que desde el mismo se pueda realizar una escalada de privilegios a otros servidores, donde se guarden bases de datos de los usuarios, o "sabe dios que otros documentos confidenciales".
Bien, ya vimos los errores/vulnerabilidades/inoperancia que yacen bajo el dominio www.fotolog.com, pero y ¿en donde quedo lo que dije sobre "Python hacking tips"?. No no, no soy un mentiroso, solo que pensé que sería mas práctico ejemplificar con NetCat. Sin embargo las pruebas son mejores en Python, es así que en los "ir y venir de la vida" (o como diría Vicentico, los caminos de la vida!!!) cree un pequeño "explorador" de esta vulnerabilidad y otras que subyacen en Apache, automatizando la búsqueda de los exploits para las mismas:
http://www.ale666.com/Foro/index.php?action=dlattach;topic=2989.0;attach=1261
En principio solo es funcional para servidores Apache, pero con unas modificaciones mínimas, se puede adaptar a otros servidores web.
Y finalizando el tema, cabe destacar que en principio como "grave" se ve lo expuesto, de lo cual pienso alertar a Fotolog.com, pero también he encontrado un par de cosas interesantes, o ideas posibles, que si bien no las he implementado, si pienso hacerlo y dejar nota de ello aquí.
Espero que disfrutaran leyéndolo tanto como yo al escribirlo,
Saludos.
Pd: En un principio esto iba dentro del artículo en un comentario, pero por cierto motivo, me olvidé :P. En fin, en "Sueños en binario" se hace alusión al asunto, pero desde otro enfoque diferente. Así, que al que le interese leer otra "óptica" del mismo tema, ya sabe a donde ir :P.
2 comentarios:
Yo ya sabia de bug de fotolog solo que soy nuevo en esto del defacing y no supe aprovecharlo,yo lo habia escaneado con acunetix,tengo un topic
en ale666 pidiendo ayuda sobre como
explotar el bug.
dpl54
Flaco, le erraste feo. Lo que vos me comentaste por el foro era una vulnerabilidad "html injection", relacionada con un "xss", la verdad que no recuerdo muy bien. Lo que yo deje a la vista acá, eran vulnerabilidades de desbordamiento de bufer...
El como explotarla, eso varía. Lee los "papers" asociados con los exploits de dichas vulnerabilidades. Mas que eso no te puedo decir, ya que el objetivo de este artículo nunca fue convertirse en una "guía paso por paso de como hackear fotolog".
Saludos.
Publicar un comentario