Google Hacking I - Lo que escondn los buscadores

allmy

Google, una medida de nuestra seguridad

Ya que la cosa se está haciendo popular ("un saludo para meneame xD") decir que este artículo ha sido escrito con el único propósito de enseñar a la gente que NO se ha de hacer cuando se es webmaster. No me hago responsable de cualquier mal uso que se le de a lo que aquí expongo.

Todos sabemos que en Google se pueden encontrar cosas muy interesantes, y no es para menos! Google dispone de una serie de "arañas" que van rastreando todo internet y van listando todas las páginas que existen, y todas las páginas dentro de las páginas. Es un proceso rápido, y, como no podía ser de otra manera, está completamente automatizado.

En los casos que os presento a continuación os voy a mostrar por qué una combinación entre robot de Google que hace demasiado bien su trabajo, y administrador web, que no lo hace tan bien, puede dar como resultado la vulneración de la seguridad y la privacidad de, en ocasiones, hasta cientos de miles de personas, incluso de entidades estatales y militares.

Probad a poner lo siguiente en google: site:*.com ext:sql

Donde "site" se refiere a sitio web, en este caso le hemos pedido que nos busque entre todos los sitos que sean .com, pero también le podríamos pedir que nos busque en uno concreto "puzz******.com" [lo he censurado] por ejemplo os resultará interesante. Este campo lo podríamos no poner, o buscar directamente por otros parámetros. Lo explicaré más adelante.

Y "ext:sql" para pedirle que nos busque una extensión de archivo determinada. Con SQL lo que hacemos es buscar únicamente bases de datos, o copias de estas. Si pusiéramos "ext:pdf", encontraríamos solo dpf.

Como veis, los resultados que arroja la búsqueda son nada más y nada menos que de bases de datos (dumps) que, por alguna razón, están donde no deberían.

No se si sabréis como funciona un Servidor, os lo explicaré antes de seguir. Para servir una página al público desde un ordenador, instalamos un programa. Hay muchos, dos ejemplos muy populares serían "Xampp" y "Apache". Para poder servir de toda la complejidad que una página web necesita, esos servidores tienen en sí muchas carpetas, no obstante, hay algunas públicas, y otras no. Las públicas se suelen llamar httpdocs, como se ve en la foto, o, en otros casos public_html, entre otros.

En nuestro caso, esos dumps, no son otra cosa que copias de seguridad de las bases de datos de una web, ¡¡que se encuentran en la carpeta pública!! Estas bases de datos pueden contener desde información trivial, hasta información de contacto, o incluso los usuarios, mails y contraseñas del administrador y todos los usuarios.

Esto por sí solo, representa una vulneración en cuanto a la seguridad de la web y los datos que han sido proporcionados a esta, pero se puede agarbar si el administrador del sitio no ha encriptado toda la base de datos. Por ejemplo, en esta base de datos podemos ver, nada más y nada menos que los usuarios y contraseñas de 430000 personas, así, sin encriptar ni nada. Buscad "puzz****** ext:sql". Lo que encontráis es esto:

https://****legems.com/twodee_games.sql

[lo he censurado, pero podeis sumar 2 + 2 xD]

Pensad en cuantas personas utilizan comúnmente, la misma contraseña para todo. Tenemos el mail, y tenemos la contraseña que seguramente utilizará para el mail. Y seguramente tendremos cuentas de todo tipo asociadas a ese mail, desde la cuenta de la universidad, hasta la cuenta del banco.

Pero... vayamos un poco más allá, que pasaría si en esa base de datos buscáramos (Control +F xD) ".gov". Pues si, lo que encontramos son cuentas de correo gubernamentales, que no se porque cojones han utilizado para registrarse en mierdas así. Si empezáis a buscar por abajo podéis encontrar la cuenta de correo de una empleada del ministerio de trabajo de EEUU. Si buscáis por ".mil" podéis encontrar unas cuantas cuentas de militares, y si buscáis por "admin@" podéis encontrar un par de cuentas de, administradores, que han utilizado sus cuentas de correo de administrador para registrarse (despedidos tendrían que estar todos ellos).

Si queréis podéis utilizar esa base de datos para buscar la frecuencia de algunas contraseñas, probad a buscar (123456) y alucinareis.

Por supuesto esta es una vulneración terrible de la seguridad de muchos usuarios, y ya he mandado un mail al fbi con el link a la base de datos, ya que la mayoría de los usuarios, por contraseñas muy fuertes que utilicen, no pueden hacer nada si la base de datos está sin encriptar.

Bases de datos sin encriptar y de manera pública podríamos decir que es una de las peores cosas que le podemos hacer a nuestros usuarios. No obstante, en algunas ocasiones, hay webs que encriptan las contraseñas dentro de las bases de datos, y se les cuela el dejarlas públicas. En ese caso, no tendremos la contraseña de manera directa, sino que tendremos el hash (contraseña encriptada), seguramente con algoritmos como md5 o sha1. Para buscar un ejemplo de estas báses de datos lo mejor podemos, o probar suerte buscando por los parámetros que os enseñé antes, o calcular un hash de una contraseña suficientemente frecuente, como para que aparezca en la mayoría de las bases de datos.

Aquí teneis un calculador: http://www.fileformat.info/tool/hash.htm Podéis meter en el recuadro "Target text" la contraseña a calcular, y darle a botón hash. Para la contraseña "123456" que según algunos estudios, es una de las más frecuentes, el hash md5 (que es el más utilizado, aunque sha1 sea más seguro y se esté implementando) para esa contraseña es "e10adc3949ba59abbe56e057f20f883e". Vamos a buscar ese hash en Google de la siguiente manera:

e10adc3949ba59abbe56e057f20f883e ext:sql

A continuación se nos mostrarán todas las bases de datos que han sido puestas donde no deberían con una contraseña que corresponde a ese hash. Animaos a calcular los hashes de las contraseñas que soléis utilizar y junto a vuestro username (o vuestro mail), podéis ver si algún sitio tiene vuestros datos de forma pública. Por ejemplo

Allmy e10adc3949ba59abbe56e057f20f883e ext:sql

Sin entrar mucho en password cracking os diré que con una gráfica GTX560M de portátil una contraseña con números y letras de 7 caracteres en md5 se puede calcular en unos minutos. Para hacer esto no hay otra manera que no sea lanzar todas las passwords posibles, con todas las combinaciones posibles. Estamos hablando de una gráfica de portátil, imaginaos lo que puede hacer una grande, o 4 grandes juntas, o una instancia de gráficas en Ámazon, una empresa, o un gobierno. Es por esta razón por la que las passwords han de ser largas. Sha1 es algo más fuerte.

MD5:

SHA1

Pero, aún una password larga, puede ser vulnerada muy fácilmente, si esta corresponde a una serie muy común, como por ejemplo 123456789, o si la contraseña es una palabra que se puede encontrar en el diccionario. ¿Por qué? Cuanto la gente empezó a encriptar las contraseñas con algoritmos que no permitían ser revertidos, y que no tenían una contraseña, lo primero que se hizo fue, coger el diccionario de lengua inglesa, y una base de datos con las contraseñas más frecuentes, y calcular los hashes de cada palabra, y cada contraseña. Por tanto, tenemos en internet grandes bases de datos con contraseñas ya calculadas (bien por ser demasiado frecuentes, por aparecer en el diccionario, o porque alguien las ha metido).

Hay cientos de bases de datos, esta es una bastante decente: http://md5.rednoize.com/ Vamos a coger nuestro anterior calculador de hashes, y vamos a calcular el hash de "University" como guiño a censored. Obtenemos el hash 50c60ac437e4d4ef19c77bdca5bbcf3b. Si procedemos a buscarlo en rednoize, vemos como, efectivamente, nos devuelve la palabra "University". Vamos a hacer lo mismo con una contraseña más dura, por ejemplo " ()hululu=5432", cuyo hash es "3015d599c9e98fa5ea94947908db5061". Si procedemos a comprobar si está en la base de datos obtenemos que ?hash not found?. Esto significa que la contraseña es, al menos, un poco segura. Ahora ¡¡probad vuestras contraseñas!!

Como nota adicional he de decir, que estas vulneraciones de seguridad, y esas contraseñas no seguras, suelen serlo menos en países asiáticos. ¿Por qué? Pues bien, la mayoría del software solo está preparado para procesar caracteres puramente occidentales. Os imagináis a vosotros recordando una contraseña en chino cuando, seguramente, ni tengáis instalada esa opción? ¿No verdad? Pues es por eso por lo que las páginas web chinas, generalmente, utilizan solo números en sus contraseñas. Por lo tanto, cuando lo que tienes son hashes de usuarios chinos, sabes casi con total seguridad, que la mayoría de las contraseñas van a ser numéricas, con todo lo que ello implica. En vez de probar todas las combinaciones posibles para contraseñas con todos los números y todas las letras (y todos los caracteres), tener que hacer combinaciones solo con los números, se convierte en algo mucho más fácil y rápido.

Por supuesto, podéis recurrir a otros buscadores como bing para encontrar resultados diferentes, pero igual de interesantes.

Manitas si queréis segunda parte :)

250
iAtlas

Buen curro

3 1 respuesta
A

juankers

allmy

#2 Bua, lo tenía escrito en word y no se porqué al pegarlo aquí se me han comido algunas palabras, y cambiado símbolos, que locura xD

Denver

ya me veo a la gente intentando hacer esta mierda con mediavida jajajajajaja

3 1 respuesta
danao

Probare desde casa, muy molon !

Habia leido algo de esto pero nunca me habia molestado :p

iAtlas

Admins de bases de datos que se ponen de contraseña: admin

35 2 respuestas
allmy

#7 routers de telefonica con usuario: 1234, contraseña 1234
routers de jazztel con usuario: admin, contraseña admin
routers...

2
Kirie

Buen post. La moraleja de esto es: Utiliza contraseñas largas alternando mayúsculas, minúsculas, números, caracteres especiales y caracteres no imprimibles, esto último si es algo muy importante. Por otro lado, hay que encriptar las contraseñas cuando se guardan en una base de datos, y no en md5 que se puede romper fácilmente.

1
sharker

Como nota, SHA1 se supone que era seguro antes, pero con la evolución que estamos viviendo ya no lo es.

Una opción es PBKDF2, que frameworks web como Django por ejemplo va a usar a partir de su versión 1.4 xD
http://en.wikipedia.org/wiki/PBKDF2

MD5 si mal no recuerdo era menos "poderoso" que SHA1.

PD: si pones un thread de la SQLInjection también se podría flipar con la cantidad de sitios vulnerables a este ataque, o al Cross Site Scripting

2 respuestas
Deoxys

Buen curro. ¿Ext funciona igual que filetype?

#7 sé de uno que tenía como contraseña de administrador "1" (Sin las comillas, ojo) xDDD

1 respuesta
Sonos

Son busquedas que poca gente conoce. Tb se suelen encontrar cosillas interesantes buscando .xml, .csv, .as entre otras.

allmy

#11 Es básicamente eso, buscas un formato específico de archivo.

#10 La cuestión es que eso ya no se si me dejarán publicar.

I

Veo que has usado el viejo truco de la interfaz gráfica en Visual Basic para localizar IP's y desencriptar contraseñas.

28
NeB1

Hace años, era una herramienta brutal para obtener bases de datos. Ahora está bastante capado, recuerdo que encontre 20 megas de tarjetas de crédito y tal xD

B

Vaya es que hay cada admin/webmaster por ahí que deja mucho que desear.

luzius

#5 Lo he probado! jajajajaja

#1 Muy buen post. Queremos segunda parte yaa!!

Krosita

Ahora por fin sere el mas molon de la escuela, soy un hacker.

1 respuesta
Joey

Muy interesante, si señor. Aún recuerdo que algunos módulos de esos prefabricados (phpbb2 y similares) no encriptaban las contraseñas, por lo tanto quien tuviera la base de datos, tenía todos los usuarios y contraseñas del foro/portal/etc ...

B

yo lo que no termino de ver es lo de usar contraseñas excesivamente complicadas. yo lo que hago es tener 3 niveles de seguridad (= 3 contraseñas, cada una mas segura que la anterior). el correo y todo lo que vaya asociado a tarjetas de credito estan en el nivel maximo y mediavida, por ejemplo, esta en el minimo.

no se como de seguro sera esto, al menos la contraseña que utilizo para el nivel minimo de seguridad no aparece en la base de datos, que es un buen sintoma

2
B

Pero esto ya estara arreglao en la mayoria de las paginas no? ya encriptaran las contraseñas y no tendras las bases de datos publicas.Queremos metodos que se usen ahora!!

1 respuesta
Z3R0KULL

Me recuerda tanto a un libro que tengo por aqui....hacking con buscadores de Enrique Rando

allmy

#21 el dump de puzzlegems con los 430000 usuarios y contraseñas es de abril del 2011 xD Es ponerse a buscar. Hay cosas más sofisticadas obviamente, pero he presupuesto que la mayoría no tiene conocimientos específicos de como utilizar exploits y cosas así, por eso esto del Google Hacking me ha parecido bueno para publicarlo.

1 respuesta
sharker

El tema de usar una contraseña complicada es tanto para evitar ataques por fuerza bruta como para evitar "adivinar el hash".

Es decir, como os han comentado por ahí, existen páginas con bases de datos que corresponde un texto plano con su resultado hash.

La función hash (ej: MD5, SHA1) es un algoritmo matemático que aplicado a por ejemplo un texto (ej: contraseñas, cuentas bancarias, incluso para firmas electrónicas), nos da un resumen único y que en teoría no puede calcularse el mensaje origen a partir de ese resumen.

Por eso, si ponemos de contraseña 1234, aunque no veamos ese 1234 y veamos el resumen generado, podremos saber que la contraseña es esa xD. Si metemos una contraseña difícil, será jodida de obtener, no existirá probablemente en bases de datos, un ataque por fuerza bruta llevaría muchísimo más tiempo, etc...

Incluso cambiando una letra en las contraseñas que usáis generarán un hash completamente diferente.

1 1 respuesta
Sinso

La verdad es que es un tema de lo más interesante, esperando segunda parte

allmy

#24 Exactamente, la cosa es hacer que no salga rentable. Me explico. Cuando tu tienes una base de datos con contraseñas o algún otro tipo de datos encriptados y que quieras obtener, seguramente tendrás un ingente número. Por lo tanto, directamente, no merece la pena pasarse 3 horas para sacar una contraseña de 8 o 9 caracteres, es mejor comprobar solo los rangos del 1-7 por ejemplo.

allmy

#10 Si nos dejaran comprobar si MV es vulnerable a XSS...

1 respuesta
Arai

Muy currado e interesante #1

calico

¿en resumidas cuentas que gamberradas se podrían hacer con esta información?

2 1 respuesta
quickkk

yo prefiero utilitzar virtual basic

Usuarios habituales

  • truer1990
  • allmy
  • Nucklear
  • luzius
  • Strangelove
  • iAtlas
  • sharker