martes, abril 30, 2013

Vladimir H4rK0n3N: Recuerdos de un viejo pirata...

Mientras escribo estoy escuchando Cowgirl de la BSO de “Hackers: Piratas informáticos” Sí,  yo también me flipé cuando Angelina estaba para mojar pan. Como no sé a quienes me diríjo en cuanto a edades y experiencia, trataré de hacer como si os conociese de toda la vida, que en ingeniería social siempre funciona, y os trataré como las personas inteligentes que sé que abundan por el mundo y tratan de encontrar su camino. Lo que sí que quiero primero es dar las gracias a Chema en particular y a sus colaborador@s en general por esta pequeña propuesta, que aunque este blog no es la DEFCON, hay tanto nivel por aquí que estoy seguro de que son muchos los que merecen más que yo dirigirse a vosotros. Y ahora sí, quiero contaros una pequeña parte de mi historia, encuadrada en este hermoso mundo del Hacking, con las cosas buenas y malas que puede tener.

De niño a hacker

La primera vez que tuve acceso a un cacharro (no sé si llamarlo computador) fue un Atari 1600. Era una especie de primitiva vídeoconsola, que eso sí, traía teclado y un par de mandos que aún conservo en mi tratero. La gracia radicaba en que aquella cosita tenía la capacidad de servir como plataforma de texto (no sé si sería correcto decir que procesaba insitu) y entendía Basic. No Visual Basic, BASIC del de toda la vida, aquel GWBasic, que por cierto podía cargarse en el Windows 3.30. Después, casi un año más tarde con unos 9 añitos me compraron mi ZX Spectrum que también tenía a Basic como su lenguaje.

Empecé como much@s de mi generación, jugando a juegos y copiándolos en cintas vírgenes que canjeaba por cromos de “V los visitantes” y chucherias colegiales variadas. Hasta un día me dió por poner a cargar el mítico juego “Game Over” (que por cierto tardaba lo suyo y a veces se quedaba pillado) y me quedé, al contrario que otras veces, fente al monitor viendo simbolitos raros y las salidas del código que para mi éran un misterio hipnótico junto con la estética ciberpunk del juego.

Figura 1: Portada de Game Over

A partir de ese momento empecé a interesarme en revistas de ordenadores de la época. Tenéis que entender que para un chavalín de aquellos tiempos, sin Internet y sin adultos que entendiesen nada de informática fué un verdadero reto meterse casi todos los días en la biblioteca con tropecientos libros de informática y un diccionario VOX, porque la mayoría venían en inglés y, por entonces no se enseñaba obligatorio. ¿Os reís? Bien, eso espero porque es parte de la lectura.

Sólo cuando era la hora de los TRANSFORMERS en la tele dejaba de leer porque los Transformes de aquellos tiempos eran cosa sagrada. Entre revistas y libros he continuado hasta hoy mi vida, sacrificando a veces las relaciones sentimentales y las horas de fiesta, que muchos somos así de fanátic@s, y sabemos que si no le dedicas tiempo, no aprendes.

En mi vida personal, como en las de muchos otros, las cosas no me fueron fáciles. Soy un poco autista, y siempre he logrado que nadie se diese cuenta salvo mi madre, ellas saben esas cosas. La relación con mi padre tampoco me fue sencilla, ya que era bastante violento conmigo. El alcohol y la mala baba no son compatibles. No me importa hoy en día, refugiado al otro lado de la pantalla, hablar de esto, ya que ciertamente es un hecho de mi vida que me ha marcado muy dentro haciendo que yo creciera queriendo ser un tipo totalmente distinto a él.

Con la pasión por los ordenadores como refugio personal, en la biblioteca descubrí la electrónica. Hasta entonces los rayos catódicos, el infrarojo y la señal de televisión me parecían cosa de magia, pero no, ciertamente tenían su cosita. Así que el pequeño crío que fui empezó a chupar conocimiento y a descubrir por qué True y False tienen su equivalencia en un uno y un cero. La electrónica no se me ha dado mal aunque no sea ni mucho menos un mago con ella, pero con 11 años y, alentado por una película de USA (cuyo nombre no recuerdo pero éra de clase B) me gasté mis ahorros de la hucha en componentes electrónicos. Tenía como base un circuito que venía de regallo en una revista de informática, un circuito de modem. El circuito lo monté sobre una caja de cartón de un 1Kg de las galletas Maria Fontaneda, y ya veréis la que acabé liando con aquél modem.

Al cabo de tres meses de soldar, quemarme y cortarme las manos cosa mala, y huelga decir que escondiendo el material de las garras de mi padre, tenía un modem casero de 5600 baudios. Entonces aquello era canela fina, máxime si pensáis que, según creo, yo éra el único niño de España que con 11 años tenía su propio modem. Con un poco de esfuerzo y de investigación empecé a comprender cómo iba el tema de la telefonía cableada. Tanto es así que tuve un golpe de suerte. De repente se pusiéron de moda las llamadas internacionales y había que marcar un porrón de numeritos para llamar a Portugal pero yo estába ya elaborando mis planes. Quería conectar con las viejas BBS, las cuales sirven aún de modelo a los foros actuales y, perdonadme pero para mí eran mucho más rápidas y emocionantes. Sin gráficos, el hipertexto de aquellos días era lo mejor y aquellos ruidos en el modem que parecían decir - Ok chaval, ¡vamos allá! - ¡Eso sí que era música en mis oídos.

Había que introducir la dirección IP, aquella Arpanet 2, sin DNS de ninguna clase y si quieres algo cómodo configúrate el fichero hosts. Así que, valiente de mí, empecé a usar las direcciones IP de las publicaciones americanas. Sin tener ni idéa de inglés me embarqué por los canales de lo desconocido. Y en esas microcomputadoras copié listados a papel y lápiz de otras direcciones IP. Supongo que aquello me convirtió en un newie solitario. Di con una BBS que permitía almacenar mensajes (algo así como el Evolution de GNU/LINUX). Ya que sólo disponía de 30 minutos al día para usar el modem, después se acababa ya que éra una medida de seguridad de la compañía de teléfonos para que no se disparásen las facturas. La primera imagen digitalizada que vi tardó unos 5 minutos en cargar, en blanco y negro. Era la portada del disco Oxygen de Jean Michael Jarre modificada y con un letrero ASCII con el siguiente mensaje: LoD [Welcome you at Legion of Doom]

Figura 2: Un Arte ASCII de Legion Of Doom

A veces pienso si mi vida sería la misma de no haber llegado a semejante paraíso del conocimiento. Estoy seguro de que habría acabado cual común usuari@ (y tod@s somos usuari@s). Obviamente, como niño que era, yo no tenía ni idea de a donde acababa de llegar, pero recuerdo que apunté y subrayé aquella dirección IP. Aquella noche dejé mi AMSTRAD PC 8086 (30 Megas de disco duro y disquetera 3/5 de baja densidad) encendido, y me dormí mirando emocionado aquel letrero ASCII, preguntándome cómo y quién sería capaz de hacer eso con BASIC que era el único lenguaje que conocía y mi única referencia a nivel de programación.

Al día siguiente, después del colegio, con el diccionario VOX escribí la carta más literal y horrible que conseguí en un papel. Luego con RPED (ese editor del MS-DOS) la transcribí a formato digital y la guardé en un disquete. La envié a los LOD, elegí un Nick que me pareció superatractivo, Lex Luthor, ¡como el calvo que quiere matar a Superman! Esos fuéron mis inicios... apasionantes.

La caída en el infierno de la cárcel

Cuando posteriormente se va perdiendo la inocencia también se pierde algo de moral, y aunque me he marcado siempre unos niveles aceptables de qué no estoy dispuesto a hacer ni por todo el oro del mundo, no siempre pude mantenerlos. Por un problema en casa, acepté un trabajo delictivo, no me gusta decir criminal, ya que separo bastante la línea del delito de la del crímen. La mayor “hazaña” de hacking de mi vida es precisamente la que me llevó a prisión, donde he pasado 4 años sin ver a mi familia, donde he perdido a mi padre y se me negó incluso asistir a su funeral (superilegal). En ese tiempo solo he tocado computadoras a conveniencia de las autoridades de la prisión pero eso sí, escoltado cual pelígro bípedo.

No queráis pisar jamás una prisión, se pasa bastante mal y es un reto psicológico que la mayoría no soportan. Algo tocado te quedas para siempre. Mi experiencia, ésta en concreto, debería serviros para aplicaros la máxima de Spiderman... - Un gran poder, conlleva una gran responsabilidad- . Para mí el mundo ya no será nunca igual de hermoso. Solo me queda “mendigar” espacios de expresión desde cierto anonimato, a personas como Chema que no son malignas, son de esa clase de personas que si te ven caer mil veces no se cansan de levantarte.

Hoy trato de llevar una vída sencilla, lejos de la “fama digital”. Sí, de cuando en cuando me vuelvo a poner el traje de supervillano, pero más como homenaje a días pasados, eso sí, cumpliendo las normas del hacking ético. Lo hago para encontrarme con algún superhéroe (como Chema) y estrecharle con afecto y admiración mi mano, pues nunca llegué a despreciar a mis oponentes; seguramente lo más inteligente que he hecho sea escribir este texto (y un par de troyanos en los 90 a los que guardo mucho cariño).

Quiero dejar claro que ni Chema, ni nadie me ha pagado por escribir aquí, lo digo porque hay mucha malicia por el mundo, ni fue él quien me encontró aunque de alguna forma sabía de mí. Otra de las cosas que me he currado bien, es que much@s hackers me han conocido pero cada uno con identidades distintas. He sido un gran camaleón aunque no sé si tan experto en ingeniería social como otr@s dícen que soy.

Algo para acabar con mucha esperanza

Tampoco quiero romper el romanticismo que lleva implícito el hacking con mi paso por la cárcel. Desde luego con ciertas edades es imposible resistirse a fardar ante otr@s de tus habilidades y descubrimientos, especialmente si entre esas personas se encuentra tu primer amor. Pero mejor disfrutad del hacking. Id a todas las conferencias a las que podáis. Se conoce a gente muy interesante y se aprende muchísimo. Si ya estáis en ese punto en el que os sentís capaces de aprender durante el resto de vuestra vida (se llama madurez) sin descanso, entonces es hora de jugar un poco menos a los videojuegos y estudiar todo el tiempo que puedas. Por la noche, escondidos bajo las sábanas linterna en mano. No hay un libro mejor que otro, casi todos tienen sus secretos y si podéis ignorar las interfaces gráficas y cacharrear con PowerShell o las shells *NIX* os aseguro que lo pasaréis bomba.

A día de hoy tengo un empleo normal. No sólo me viene bien para pagar las facturas sino que además me protege. Donde yo vivo soy invisible, nadie de mi entorno sospecha quién he sído ni por asomo. Contados amig@s saben esa parte de mí, y de verdad que disfruto mi nueva vida bastante aunque a veces se torne un poco aburrido.

La red ha cambiado mucho las cosas, por ejemplo GNU/Linux no habría llegado a lo que es hoy sin la red, ni podríamos tratarnos tan íntimamente sin ella. Es nuestra misión cuidarla. Hoy existen gentes (a quienes no llamaré Hackers porque no los considero como tales) que son delincuentes e incluso criminales. No tienen escrúpulos ni el menor conocimiento de la cultura del Hacking y manchan nuestra cibersociedad. Es importante que vosotros renovéis el espíritu original del Hacking. No olvidéis que somos tod@s usuari@s, que la red es también nuestro espacio y que en definitiva, como l@s más avezad@s, somos la primera línea de combate.

Con estas palabras no pretendo crear una biblia del comportamiento Hacker - yo no soy nadie para enseñar qué camino debéis tomar - pero si pudiese empezar otra vez, y viendo mi experiencia desde la barrera, tengo claro que desde luego trataría de elegir un camino distinto. Tod@s tenemos nuestr@s referentes. Yo tengo a Mr. Richard Stallman y sí, a Kevin Mitnick también, aunque el tercer puesto se lo doy a Chema (aunque porte su merecido título de Microsoft XD ).

Espero que este texto pueda ayudar a un@s cuant@s a ver a través de mis ojos y les sirva para evitar vivir uno de los peores caminos. Otra vez gracias a todos y un fuerte saludo de:

 Vladimir H4rK0n3N, un viejo pirata... que aún conserva guardada su bandera.

lunes, abril 29, 2013

Buscar sitios web con Applets Java usando Shodan

En el post de ayer os hablé del Decompilador de Flash y Java Online y os puse un par de ejemplos con ficheros SWF de Apple.com que había buscado de forma sencilla con Google o Bing. Para encontrar esos archivos basta con utilizar el operador EXT y salen miles. Pero eso no funciona bien para los Applets, por múltiples causas.

La primera es que puede que la extensión en la que se guarda un Applet sea Class si es un único documento, JAR o ZIP si son varios comprimidos o incluso ninguna extensión como sucedía en la fase 2 del Reto de Boinas Negras. La segunda parte es que los ficheros no están metidos en la web  con un enlace, con lo que los buscadores no suelen indexar su contenido, así que lo más probable es que no aparezcan en los resultados a no ser que se den otras circunstancias de indexación de ficheros.

Así que, para resolver estos problemas, decidí tirar de trucos de hacking con buscadores y utilizar  Shodan y el operador HTML para buscar los sitios donde hay una etiqueta Applet en la primera página de la web y encontrar muchas muestras, y como podéis ver aparecieron miles de sitios así.

Figura 1: Etiqueta HTML en Shodan

Shodan no indexa todas las páginas a día de hoy, pero si lo que hay en la primera página es un panel de control de una videocámara, un sistema de energía, un termostato o un sistema de control de antenas que utiliza un Applet Java, saldrá a la primera. 
Figura 2: Seguridad basada en Applet Java

Como os podéis imaginar, echando un vistazo preliminar salen decenas de sitios que validan la password en el propio Applet, o que custodian el acceso aún con la password por defecto.  Para analizarlo, hay que mirar el nombre del archivo en la etiqueta Applet.

Figura 3: Configuración de Applet en HTML

Si solo está el .class, entonces se le puede pasar la URL a Show My Code. Si hay un archivo que empaqueta todo el código, hay que descargarlo, descomprimirlo y enviar uno a uno los ficheros a Show My Code, comenzando por el que aparezca en el Applet.

Figura 4: Código decompilado y descargado desde Show My Code

Para hacer el seguimiento y perder un poco de tiempo como hago yo de vez en cuando con estos programitas, es importante que recuerdes que los parámetros de entrada del Applet pueden estar no solo en los que introduzca el usuario por el GUI, sino que también los configura la página web mediante los parámetros del objeto Applet en HTML.

Saludos Malignos!

domingo, abril 28, 2013

Decompilador Flash, Java, .NET y QR Codes Online

En el artículo de sacar URLs de un sitio web os hablaba de la necesidad de decompilar los ficheros SWF y Java para poder sacar más información de ficheros de un sitio web. Para hacer esta tarea el servicio online Show My Code te lo pone bastante fácil, ya que solo tienes que decirle la URL del fichero que quieras decompilar y un sencillo captcha de una única letra, con lo que es rápido y cómodo analizar ficheros.

Figura 1: Show My Code

En este ejemplo he buscado un SWF de Apple.com, y como veis es posible acceder a las URLs que está utilizando para manejar, por ejemplo en este caso, la tienda de música de Apple iTunes.

Figura 2: Código de un SWF en Apple.com

El sitio es muy cómodo, y además de mostrar el código rápidamente, también permite descargarlo para poder hacer búsquedas de cadenas que sean de interés - cada uno sabrá qué es lo que busca -. Eso sí, no te devuelve el FLA, por lo que los archivos embebidos o el resto de información del SWF se queda fuera y necesitarías otro tipo de herramientas.

Figura 3: URLs de iTunes para conseguir el Top de Albumes

Si quieres perder un poco el tiempo rebuscado en los SWF, podrás encontrar un montón de información de rutas, usuarios y passwords embebidos, links a archivos locales, rutas a ficheros almacenados en perfiles locales, etcétera.

Saludos Malignos!

sábado, abril 27, 2013

Time-Based Blind SQL Injection en Yahoo!

Las técnicas de Time-Based Blind SQL Injection me tuvieron enganchado largo tiempo. La posibilidad de poder extraer datos de una consulta generando retardos de tiempo en las respuestas True es algo que me enamoraba.

Herramientas como SQL Ninja, las Time-Based Blind SQL Injection using Heavy Queries - de las que hablé en mi primera Defcon -, el exploit de Solar Empire, el Deep Blind SQL Injection o Marathon Tool, llenaron muchos de los posts de este blog durante mucho tiempo. Me encantaba, y de hecho terminaron por convertirse en el libro de Hacking de Aplicaciones Web: SQL Injection que escribimos entre Enrique Rando/**/AND/**/Chema Alonso.

Tanto tiempo le dediqué que Palako y yo estuvimos dando la charla de seguridad en la Yahoo! Security Week hablando largo tiempo de estas cosas - hasta jugándonos el pellejo con algunas demos de lo más "on the blade" posible -, de cómo es posible extraer grandes fuentes de información, incluido ficheros con técnicas de Remote Downloading Files usando los retardos de tiempo. Así que estoy seguro que los equipos de seguridad de Yahoo! sabían de esto, porque los Paranoids otra cosa no, pero de esto deben saber sí o sí.

Dicho esto, sorprende que Yahoo! se haya comido un par de Time-Based Blind SQL Injection en el lugar más típico, en parámetros numéricos de ficheros PHP, algo que los número tres que se prueba en cualquier auditoría de seguridad que cuenta con PHP de por medio. Este es el lugar donde se encontró:
http://tw.ysm.emarketing.yahoo.com/soeasy/index.php?p=2&scId=113; select SLEEP(5)--
Basta con lanzarle un Havij a cualquier sitio de estas características para que la auditoría termine justo ahí. Así que... esto tiene pinta de ser otra web que salió a producción sin auditoría previa.

Saludos Malignos!

viernes, abril 26, 2013

Bing y la no existencia de búsquedas privadas bajo HTTPs

Las búsquedas que una persona realiza en un lugar como Google o Bing pueden afectar seriamente a su privacidad, por lo que desde hace ya tiempo se reclamó que estas pudieran hacerse bajo una conexión cifrada para evitar inspecciones de red por terceros, que ya es suficiente con que los buscadores tengan bien catalogada la huella digital de nuestra conexión. Google lo puso y es posible buscar bajo una conexión cifrada con HTTP-s con un certificado de validación extendida. Bien.

Figura 1: Certificado de www.google.es

En el caso de Bing me ha sorprendido ver que a día de hoy aún no está así. Haciendo alguna prueba de hacking con buscadores usando un poco Bing Hacking quise probar bajo una conexión segura, y lo primero que salió fue un certificado de Akamai y la alerta de que el certificado no pertenece a ese nombre de dominio.

Figura 2: Alerta al solicitar una conexión https://www.bing.com

El problema es que Bing tiene un frontal en Akamai y el certificado digital que hay en esa dirección IP no está creado para el nombre de dominio de Bing, con lo que los navegadores generan la alerta de seguridad. Aún aceptando usar ese certificado digital como "confiable", lo cierto es que el servicio Bing no se ofrece por HTTPs, así que vuelve a una página con conexión HTTP y deja desprotegidas las búsquedas que se realicen en el servicio. Mal.

Saludos Malignos!

jueves, abril 25, 2013

Navegadores y passwords HTTP en ataques CSRF con IMG

Cuando escribí el artículo sobre el tema de las passwords HTTP en esquemas de Clickjacking y el comportamiento de los navegadores me quedó por probar cómo se comportarían los en un caso de CSRF (Cross-Site Request Forgery) en el que la password HTTP fuera en una URL dentro una etiqueta IMG, ya que me parecía a mí que iban a comérselo con patatas todos, así que le pedí a mi compañero Ricardo que hiciera las pruebas pertinentes. Sin embargo, no ha sido así, todos los navegadores no envían la contraseña... aunque si la gran mayoría.

Para hacer la prueba basta con poner un imagen en un servidor web protegida por usuario y contraseña y ver quién envía esos datos. Parecía lo más evidente sería que los navegadores que ya vimos que no tenían protección para iframe no iban a tener tampoco protección para etiquetas IMG, así que, como era de esperar Google Chrome y Mozilla Firefox envían el usuario y la password por HTTP en esquemas de CSRF.

Figura 1: Google Chrome 26 envía usuario y password en el campo Authorization

Si decodificamos el valor BASE 64 que va en él se verá que el resultado es que aparece el usuario y la contraseña que van en la URL del protocolo HTTP.

Figura 2: Campo Authorization decodificado de BASE 64.

Lo mismo sucede con Mozilla Firefox, tal y como se puede ver en la siguiente captura realizada con la misma prueba.

Figura 3: Mozilla Firefox también envía la password sin decir nada

El navegador en que tenía menos fe para tener protección era Apple Safari, y como era de esperar, en una URL de una etiqueta IMG que envía usuario y contraseña dentro de un posible esquema de CSRF, envía la contraseña. Esto lo suponía ya que en el caso del ataque CSRF de los routers se usaba un iPhone, así que era casi evidente.

Figura 4: Apple Safari envía la password HTTP

El último en discordia de los cuatro navegadores más populares era Internet Explorer, que a diferencia del resto, por motivos de seguridad, desde IE 7 se prohibió enviar las passwords por HTTP en etiquetas IMG para evitar los ataques CSRF.

Figura 5: Internet Explorer bloquea la petición

Supongo que viendo que IE fue el navegador con menos bugs en 2012 muchos ya suponéis que en el equipo de desarrollo de este producto en Microsoft se toman la seguridad en serio... al menos desde IE 7.

Saludos Malignos!

miércoles, abril 24, 2013

WebCast Windows 8 Seguridad

El pasado día 16 de Abril impartí un webcast sobre novedades de seguridad en Windows 8. Fue una evolución de la charla de 1 hora de duración evolucionada de Lo que será Windows 8 que ya había dado en Enero de 2012, pero con alguna cosa nueva. La charla quedó grabada, y aunque no es muy bueno el audio, os lo he subido a Youtube para los que queráis verlo.



De todas, la mejor forma de aprender seguridad en Windows 8 es probando. En el libro de Máxima Seguridad en Windows (2ª Edición) de Sergio de los Santos (@ssantosv) tienes información detallada de todas las tecnologías de seguridad en kernel 6.x (Windows Vista, Windows 7 y Windows 8) con ejemplos y demos como el de cómo funciona UIPI en Windows 8.

Saludos Malignos!

martes, abril 23, 2013

Hacking con Archive.org "The Wayback Machine"

La realización de procesos de hacking con buscadores puede dar muchas sorpresas. Shodan, Robtex, por supuesto Google o Bing pueden ofrecer resultados que no te encuentres en la página web que estas auditando, debido al momento en que el buscador hizo la prueba y la copia del sitio que se capturó cuando se hizo. Hoy le quiero echar un ojo a Archive.org "The Wayback Machine", que te puede dar también alguna alegría, y os dejo algunas cosas que puedes sacar de él.

1.- Obtener todas las URLs históricas de un sitio

El otro día, en el artículo de Técnicas para descubrir los ficheros de un sitio web, hacía referencia a Archive.org como forma de generar una lista de URLs históricas de un sitio para poder utilizarlas en un diccionario. La forma de sacarlas todas es utilizando un par de * en la URL, tal y como se puede ver en esta captura, donde aparecen las URLs históricas de consultants.apple.com.

Figura 1: 1.492 URLs capturadas para este dominio

Como se puede ver, hay que usar un par de asteriscos. Uno en la parte de la fecha de la copia, y otro después del nombre del sitio. Esta tabla es fácilmente analizable por cualquier script para sacar las URLs, y es la que meteremos en FOCA.

2.- Copias históricas del mismo archivo

Como se puede ver en la imagen, en la tabla aparece el número de copias distintas que se han recogido, así que podremos saber si hay varias aplicaciones distintas en el pasado. Por ejemplo, si filtramos por TXT los resultados para ver los cambios en robots.txt vemos que hay 13 copias diferentes que deberemos analizar.

Figura 2: 13 copias distintas de robots.txt en Archive.org

3.- Metadatos históricos

Al igual que los ficheros de aplicaciones o el robots.txt, una de las mayores utilidades es la de poder sacar diferentes copias de los documentos ofimáticos, pudiendo obtener versiones con metadatos distintos en cada una de ellas.

Figura 3: De este documento hay 2 copias diferentes

4.- Navegar por el tiempo hasta el punto de fallo

Como todo buen buscador, puede llegar al sitio adecuado en el momento preciso, así que podría ser que incluso pillara al servidor web en algún momento con un fallo de seguridad. Así podríamos navegar por páginas web aparentemente normales, como macameria.php en todas sus versiones.

Figura 4: MacAmerica.php y su barra de navegación en el tiempo

Y podría suceder como en este caso que una de las copias fuera pillada con el código fuente PHP del sitio entregado al buscador, y obtendríamos nuevos resultados, y nuevas URLs.

Figura 5: Una copia de MacAmerica.php en Archive.org devuelve el código PHP con comentarios y todo

Vamos, que si tienes que hacer un pentesting a un sitio web que ya lleva un tiempo en Internet, no te olvides de darte una vuelta por su pasado, no vaya a tener fotos con hombreras en el album de fotos o medio desnudo o con el pelo corto, traje y corbata...- oh, wait -.

Saludos Malignos!

lunes, abril 22, 2013

En China se permite el porno pero no la privacidad

Realmente iba a titular a este post algo como "Mastúrbate pero que yo lo vea" pero algun@ podría pensar que estoy haciendo alguna proposición voyeurista a alguien. De hecho, con ese título, las respuestas en Twitter podrían haber sido de lo más curiosas. Al final, haciendo uso de un poco de mesura, decidí no usar ese título aunque bien podría haber sido ese, ya que parece que en China está permitido casi todo en Internet, a excepción de la privacidad, que está bloqueada por el Great Firewall of China.

Figura 1: Web para comprobar si un sitio está censurado en China

Para probar esto, puedes irte a esta web, y comprobar si el sitio que quieres visitar sería posible verlo desde una conexión en China. El primer sitio que he elegido, como no, es de "contenido adulto", y como podéis ver, el porno no está censurado.

Figura 2: Sitio no censurado en China

Eso sí, si lo que quieres es comprarte una conexión VPN que te permita conectarse con privacidad a esas webs de relajo momentaneo, la cosa cambia y mucho, ya que como podéis ver están bloqueadas.

Figura 3: Sitio censurado en China

Por suerte, El lado del mal no está bloqueado, así que cualquier hispanoparlante allí podrá leer mis artículos antes o después de ver porno.

Figura 4: El Lado del Mal no está bloqueado en China

Primero se quejó Google por la operación Aurora, después las acusaciones de intrusión en los satélites américanos, luego las organizaciones pro-Tibet sufren el acoso de los ataques dirigidos - según ellos desde China - . Después llegó la publicación del informe Mandiant sobre APT1 y desde China publicaron un vídeo ridicularizando la idea de que pudieran estar haciendo espionaje industrial desde el ejercito. De estos tres casos todo lo que hay son negaciones desde China, pero está claro que las comunicaciones internas del país las quieren tener bien controladas, como el resto de los "enemigos de Internet".

No solo hay un montón de sitios bloqueados, sino que también se bloquean los puertos de conexión tradicionales L2TP y PPTP, además de aplicaciones que puedan hacer conexiones VPN-SSL, es decir, sobre HTTP-s. De hecho, en la App Store estaban prohibidas todas las apps para hacer redes privadas virtuales hasta hace no mucho en que Apple puso HTTPs a su tienda. No obstante, no creo que se tarde mucho en volver a aplicar un esquema de Bridging-HTTPs a iTunes para filtrar las apps de VPNs otra vez.

Saludos Malignos!

domingo, abril 21, 2013

Tiras Deili Electrónico 41 a 44

Durante el último mes hemos tenido muchas novedades con Cálico Electrónico. Hemos acabado de publicar la temporada 4 completa, hemos publicado el cómic de El Fin de Cálico y nuestra app para Windows Phone ha sido elegida App del día en la Store de Windows. Pero mientras seguimos con todo esto, no hemos parado de seguir publicando nuevo material, en este caso con el proyecto de las Tiras de prensa de Deili Electrónico que publicamos semanalmente, gracias a la colaboración de Ediciones Babylon.


Las tiras anteriores las podéis ver en los siguientes posts o en la web de Deili Electrónico:
Además durante este tiempo hemos recuperado la serie de Los Telepis, y hemos publicado algunos de los capítulos de DonRamon y Perchita, junto con este Harlem Shake que "es para verlo".


Para que te puedas enterar de todo esto con facilidad, recuerda que además tienes una aplicación de Cálico Electrónico para Windows Phone y una aplicación para Windows 8 - además de la que ya hizo un fan para Android - donde podrás saber cuándo hemos publicado una nueva tira de comic de Deili Elecrónico o un nuevo capítulo de Cálico Electrónico, que ya estamos pensando en la Quinta Temporada.


Si eres fan de Cálico Electrónico y te quieres enterar de todas las novedades ya sabes que también puedes seguir la actividad del gordito en su cuenta oficial Twitter, en su página fan de Facebook, en Tuenti, a través de Google+ o suscribirte al Canal Oficial Youtube Cálico Electrónico. Además te agradeceremos mucho que nos ayudes a continuar con el proyecto comprando algo de merchan en la Tienda Oficial, donde puedes comprar cosas como esta nueva supertaza de desayuno de jioru!

Saludos Malignos!

sábado, abril 20, 2013

Tuenti Challenge 3

Hace mucho que no os hacemos trabajar en un Reto Hacking - y creo que ya va tocando - pero el día a día de los proyectos nos va comiendo el tiempo. Mientras preparamos algo, os invito a que os partáis el alma un rato en el Tuenti Challenge 3 que comenzará el próximo 29 de abril de 2013.

Figura 1: Tuenti Challenge 3

Luis Peralta (@luisperalta), el hacker digi-evolucionado a VP de Ingeniería en Tuenti, ha prometido que en esta tercera edición del reto, los amantes del hacking van a encontrar su hueco, ya que habrá pruebas para ellos. Python, algo de ingeniería inversa y mucho coding para ganar este reto, al que debes apuntarte. En la sección de tools tienes los archiperres necesarios para participar en el reto desde sistemas *NIX* y Windows

Figura 2: Fecha de inicio del reto. Aún tienes tiempo de prepararte

Si eres un ingeniero joven o senior que adore la programación, la algorítmica, la seguridad web y los retos de arquitectura, tal vez descubras que trabajar en el equipo de Tuenti sea una buena oportunidad para ti - que yo he estado varias veces por allí y no los tratan mal -. Ni que decir tiene que espero que todos mis Talentums Startups se apunten...¡que os pasaré lista!

Si lo que te gusta sólo es el hacking, no te preocupes, que prometo poner un reto hacking de El lado del mal a la vieja escuela, como hacíamos antes, para que os partáis un poco el cobre con él. Además, los premios serán igual de buenos, y me daré la misma prisa de siempre en entregarlos. Prometido.

Saludos Malignos!

viernes, abril 19, 2013

Técnicas para descubrir los ficheros de un sitio web 2 de 2

Continuando con la primera parte de este artículo, vamos a ver otras diez técnicas más para sacar nombres y rutas de ficheros que se encuentran ocultos en un servidor web. Vamos con ellas:

11.- Multiple Choices con Mod_negotiation

Cuando se solicita un fichero que no existe en el servidor web este módulo de Apache devuelve la lista de ficheros que se llaman igual que el solicitado, pero que tienen distintas extensiones. Es perfecto para encontrar backups de ficheros, por lo que la idea es tan sencilla como solicitar todos los ficheros  que se conocen en el servidor y pedirlos sin extensión. A ver qué sale.

Figura 6: Ficheros de backup descubiertos con mod_negotiation

12.- Fuzzing estático

Las técnicas de fuzzing en web construyen a partir de palabras de un diccionario reglas de predicción de nombres de archivos y carpetas. Estas técnicas tuvieron su exponente hace tiempo ya en la herramienta Wikto de Sensepost, que hacía todo esto de manera eficiente y añadió lógicas de inspección de carpetas y parametrización por tipos de archivos.

Figura 7: Wikto

13.- Fuzzing dinámico

En este caso la idea es generar los nombres de fuzzing en tiempo real a media que el crawler, o el motor de spidering que se utilice descubra nuevos ficheros basandose en los nombres encontrados. En FOCA se añadió un pequeño módulo llamado Backups que realiza fuzzing dinámico buscando los posibles nombres de las copias de seguridad de los ficheros seleccionados. Si no recuerdo mal, esto solo estaba en la FOCA PRO.

Figura 8: Backups buscados con FOCA PRO

14.- Diccionario de software conocido

Por supuesto, puestos a hablar de fuzzing, hay que citar que otra manera es utilizar las herramientas que llevan cargadas las rutas donde se instalan los archivos de las aplicaciones web más comunes, como el caso de Moodle, Wordpress, Joomla, etcétera. El éxito es tener el diccionario de todas las rutas de todas las versiones de todo el software, así que sería fácil localizar una buena cantidad de archivos en el momento en que se detecte el software instalado. Una buena herramienta para hacer esto es SWAT (Swiss Web Attack Tool).

Figura 9: Módulos que se pueden probar en SWAT

15.- Metadatos de documentos ofimáticos

Por supuesto, si os digo que la FOCA hace esto, supongo que no os digo nada nuevo. La idea es que en muchos archivos, especialmente archivos PDF generados con impresoras virtuales que crean documentos desde un sitio web, en el mismo campo título queda la ruta de la aplicación que lo generó.

16.- Directorios de usuarios con Mod_user_dir en Apache

Este es otro ejemplo para descubrir URLs haciendo uso de la publicación de los $HOME de los usuarios del sistema en servidores web Apache. Si se detecta uno de ellos, es bueno hacer un poco de fuzzing a las rutas /~usuario para ver si existen. Para ello se puede usar un diccionario de nombres de usuarios a lo bestia o nombres de usuario extraídos de los metadatos de los archivos publicados en el sitio, o de alguna web que hayas podido "scrappear".

Además, si has descubierto el módulo mod_user_dir, deberías probar a lanzar un fuzzing de los archivos de perfil de los usuarios en *NIX*. Puede que aparezcan los .login, .bashrc, .profile, .bash_profile y compañía por allí.

17.- Bug de IIS Short name

Ya hemos hablado mucho de esto. Si hay un IIS 6 o un IIS 7, debes probar a ver si es posible enumerar los nombre 8:3 de los archivos mediante este bug. En FOCA hicimos un plugin, pero puedes hacerlo a manopla en el sistema.

18.- URLs de web históricas

A veces, cuando se migra la web, los archivos del sitio web anterior siguen en el servidor. Solo hay que tener las rutas y buscarlas. Para ello, usar un servicio como Archive.org puede darte una buena cantidad de URLs que utilizar. Para ello hay que hacer crawling con las copias, limpiar un poco las URLs que te salen y por último generar un fichero de diccionario que puedas lanzar con tu fuzzer favorito. Trabajosillo, pero salen cosas.

Figura 10: URLs de la web del FC Barcelona del año 1998

19.- Decompiladores

Otro sitio donde pueden salir muchas URLs es en los archivos compilados. Casos como los Applets Java o los archivos .swf pueden darte mucha información de nuevas URLs, y puede que localices hasta los códigos fuentes de estos mismos. Esto también pasa en los archivos binarios, ya que también salen rutas en ellos, aunque normalmente son del equipo donde se trabajó con ellos, como en el caso de la operación Aurora.

Figura 11: La ruta que dio nombre a la operación Aurora

20.- Peticiones de plugins

El último sitio que os voy a dejar en esta lista son los componentes que hacen peticiones al servidor. Casos como los ActiveX que son difíciles de decompilar - a pesar de que hay muchas y buenas alternativas para analizarlos - en el caso de que quieras hacer una lista de URLs, podrías analizar las peticiones que espera recibir del servidor y enchufárselas, a ver qué sale por ahí...

Al final, como se ve en estos casos, hay muchas formas de conseguir sacar un poquito más de información de una web y cuando se alcanza la justa... se acaba el juego.

Saludos Malignos!

jueves, abril 18, 2013

Técnicas para descubrir los ficheros de un sitio web 1 de 2

Una de las cosas que es necesario realizar cuando se hace una auditoría es qué archivos hay en el servidor web, ya que en cualquiera de ellos puede estar la llave con que abrir la lata. Para ello existe una gran variedad de maneras de intentar encontrar todas las carpetas y ficheros que en el servidor web están "ocultos" a simple vista. Encontrarlos es un juego divertido similar a buscar las piezas de un puzzle que permitan ver la foto completa que se esconde tras el nombre de dominio original, y son diversas.

Muchas de estas técnicas están implementadas en FOCA, otras no, y como quiero que se implementen, este fin de semana pasado le dedique un tiempo a recopilarlas todas en una lista que me ha quedado un poco larga, por lo que os la voy a publicar en un par de posts. Estas son todas ellas:

1.- Crawling

La primera y más evidente es leer los códigos fuentes de las páginas web de un sitio y seguir todos los enlaces que de ellas se pueden extraer. Esto es algo que tradicionalmente hacemos con Burp Suite ya que podemos conectar la búsqueda de URLs con las pruebas de FOCA. El módulo de spidering es suficientemente bueno cómo para sacar un fichero con todas las rutas a archivos de un sitio.

Figura 1: Spidering con Burp

2.- Robots.txt

Estos archivos guardan rutas a documentos y carpetas, así que por si el crawling no hubiera encontrado todos, merece la pena darles una lectura a ver qué aparece por allí. Algunas veces pueden aparecer rutas sorprendentes como vimos con el robots.txt de RTVE o curiosas como el famoso robots.txt de la Casa Real.

3.- Sitemap.xml

Los archivos sitemap.xml también recogen ficheros y contenidos de un sito. Generalmente son URLs públicas con información para mejorar la indexación que de un sitio hacen los buscadores. Conviene sacar estas URLs y alimentar con ellas el motor de crawling, por si el sistema se hubiera parado antes de localizar una de esas direcciones.

Figura 2: El sitemap.xml de Casa Real a día de hoy

4.- Buscadores

Los buscadores pueden indexar URLs que hayan llegado a su base de datos por medio de un enlace directo que se haya puesto en alguna otra página - recordad el caso de los XSS-Google Persistentes - o porque alguna barra del navegador o el mismo Google Chrome, hayan reportado esa URL como el caso de Blogger y la predicción del futuro o el sofá del Bank of América. Hay que revisar los archivos indexados por los buscadores. Además, un fallo de configuración antiguo de un sitio puede haber sido utilizado para indexar los archivos, y están en la base de datos del buscador. Por supuesto, encontrar objetivos rápidos se puede hacer con el truco de la barra en Google.

5.- Directory Listing

Por supuesto, hay que revisar todas las carpetas de todas las URLs para encontrar aquellas que puedan tener un directory listing abierto. Esta es la mejor de las opciones, pues permite ver todo lo que hay en una carpeta sin necesidad de buscar más.

6.- Ficheros .listing

Los ficheros .listing, que son creados por el wget son un ls -la de la carpeta donde se ha subido o de donde se han descargado determinados ficheros. Aunque no tienen porque ser lo que haya en ese directorio, si que salen muchas URLs que deben ser probadas.

Figura 3: Aspecto de un fichero .listing

7.- Ficheros .DS_Store

Los ficheros .DS_Store generados por el infame Finder de Mac OS X han demostrado ser una fuente jugosa de información para obtener archivos y carpetas de un directorio, tal y como vimos esta semana con el programa DS_Store.

8.- Ficheros Thumbs.db

Los ficheros Thumbs.db también guardan nombres de archivos - y miniaturas - de los thumbnails asociados a los archivos en Windows XP o Windows 2003. Para analizar los ficheros thumbs.db podéis utilizar el servicio online que está disponible hace mucho tiempo en Informática64 llamado Thumbando.

Figura 4: Salida de Thumbando cuando se le pasa un Thums.db

9.- Repositorios de código fuente de los sitios web

En ellos suelen quedar ficheros que registran los archivos subidos y/o actualizados en cada post de un desarrollador. Sistemas como subversion o BuildBot pueden ser auténticas fuentes de información para conocer qué hay en un sitio web escondido, donde el amigo .SVN/Entries y su base de datos wc.db junto con el directorio pristine son un autentico regalo en una auditoria. 

10.- Ficheros de error 404

Los mensajes de error también pueden tirar rutas internas o del sitio web. De ellos merece la pena recordar los mensajes de error 404 en aplicaciones ASP migradas a IIS 7, o los mensajes de error 404 en documentos TCL de WebDNA.

Figura 5: Rutas en un mensaje de error 404 de IIS con ASP

Hasta aquí los 10 primeros sitios a mirar, en la segunda parte tienes otra buena tanda de sitios y formas para encontrar las URLs que nos lleven a los nombres de los ficheros, para así poder encontrar los que sean juicy files.

Saludos Malignos!

miércoles, abril 17, 2013

Mundo Hacker en Discovery Max

Como sabéis se está emitiendo Mundo Hacker en Discovery Max. Yo participé unos minutos en el Capítulo 3, dedicado a la Ciberguerra, y como se ha publicado ya en Internet, lo tenéis aquí para poder verlo.


Si queréis saber más de este tema, yo he recopilado algunos incidentes de ciberguerra y ciberespionaje en un artículo. Además, puedes ver los demás capítulos de Mundo Hacker de Discovery Max en Flu-Project y la madrugada del jueves al viernes de esta semana podrás ver el siguiente.

Saludos Malignos!

martes, abril 16, 2013

Subversion: wc.db & pristine

Los riesgos de los repositorios de código de Subversion en los sitios web públicos ya los hemos comentado muchas veces. El ejemplo de Apple que se dejó un .svn/Entries y que mediante el SVN/Extractor de FOCA nos permitió llegar a una shell es uno de los casos más claros, pero esto puede ser mucho peor, ya que también tenemos la base de datos wc.db y el directorio pristine

wc.db

Esta es la base de datos de subversion y en ella se puede encontrar información de todos los ficheros que se han subido, incluso cuando el fichero .svn/entries esté vacío, algo que puede ser habitual. Encontrar estas bases de datos es tan sencillo, como encontrar el fichero .svn/entries con FOCA o hacer un poco de hacking con buscadores para hacer unas pruebas. En este caso un sencillo dork en Bing.

Figura 1: Buscando bases de datos de subversion en Bing

Una vez te descargas las base de datos se puede ver que es un SQLite, así que lo primero que puedes probar es a abrirla con un SQLite Browser o similar. En mi caso, el resultado es que la base de datos aparece vacía, aún cuando tiene más de 400 Kb de tamaño.

Figura 2: Base de datos vacía al analizarla con SQLite Browser

Por supuesto, ya que tenemos Recover Messages que hace análisis forense de todos los archivos SQLite, la subí y la analicé, apliqué una licencia y me descargué el fichero txt con el Raw Data Recovered y lo abrí con un editor de texto.

Figura 3: Analizando la base de datos de Subversion con Recover Messages

Como se puede ver en el editor de texto, aparecen los nombres de los archivos que se encuentran en el servidor, así que nada, como si tuviéramos el .svn/entries completo.

Figura 4: El volcado forense del fichero SQLite hecho con Recover Messages

Y basta con pedir el fichero a la URL a la ubicación concreta para acceder a él, tal y como se puede ver en la imagen.

Figura 5: El fichero está en su sitio

Pristine

Si lo de arriba te ha parecido chulo, espera a lo siguiente. Resulta que subversion guarda una copia de los archivos originales que se suben al servidor en una carpeta llamada pristine. La gracia es que allí el nombre de los archivos se ofusca en sha1, con una extensión .svn-base, lo que hace que no se le apliquen los tipos MIME asociados.

Figura 6: Estructura del nombre de los ficheros en el directorio pristine

Es decir, que un archivo .php está almacenado como un archivo .svn-base en la carpeta pristine y por lo tanto puede ser descargado. Para hacer eso, existe el programa svnpristine, al que solo hay que pasarle la ruta del servidor donde se encuentra la raiz de subversion, y se volcará toda la carpeta pristine a local.

Figura 7: Volcado de pristine con svnpristine

Con lo que si con el fichero .svn/entries se pueden hacer muchas cosas, con wc.db y pristine, las auditorías de seguridad pueden quedar vistas para sentencia con solo encontrar el subversion.

Saludos Malignos!

Entradas populares