Hacking con buscadores IV: Buscando vulnerabilidades y objetivos

Muy buenas,

Continuamos con el maravilloso mundo del hacking con buscadores. Tras los primeros artículos más orientados a identificar fuga de información, ya sea de archivos ofimáticos y metadatos o bien descubriendo políticas de contraseñas, vamos a centrar en aprovechar los resultados indexados en los buscadores para identificar URL’s susceptibles de ser vulnerables a vulnerabilidades web, ya sabéis SQL, XSS o Directory Transversal entre otras.

Disclamer: Toda la información que se puede obtener a través de la indexación de los buscadores es de dominio público. En el post, no obstante, se va a pixelar toda la información relevante. No nos hacemos responsable de su uso para otro fin que no sea académico.

Para empezar, vamos a ver la URL más básica que nada más verla nos gustaría cambiar parámetros, inyectar y demás cosas…sí estoy hablando de index.php?id=XYZ

 

 

 

Estas URL’s pueden ser vulnerables o no, pero al menos los buscadores nos revelan la existencia de URL’s con dichos parámetros.

Todo sería ponerse a mirarlo (siempre que se tenga permiso claro 😉 o desarrollar un pequeño script con un diccionario de inyecciones para verificar si realmente es vulnerable…por ejemplo, cheat XSS de OWASP, así para empezar.

Recuerdo que a alguien que le gustaba la Cruzcampo (¿Cuándo fue la última vez que deje una Cruzcampo llena?-Cuando vi que servían Mahou xd 😉 de la Honeycon en el Hack&Beers había desarrollado un par de script’s con nombres de lo más original para hacer fuerza bruta contra URL suceptibles de XSS, por ejemplo, esta podría ser una aplicación. Si nos lee, ya nos dirá que paso con su cerveza 😉

O también podemos no molestarnos y preguntar al buscador si alguien ha pensado lo mismo que nosotros, lo ha hecho y además un bot lo ha indexado (o sí directamente ha solicitado que un bot realice esa petición).

 

Idem para XSS:

 

Si las búsquedas de inurl se ponen sin comillas en estos ejemplos, aparecen mazo de foros, dudas y resultados de OWASP sobre inyecciones y habría que ir tirando de -site hasta que nos aparezca el captcha en forma de regalo de Google por utilizar sus servicios 😉

Idem para Directory (Path) Transversal:

 

 

Visto esto, otras búsquedas interesantes que se podrían hacer son los portales de accesos de intranet o extranet, que tienen numerosas compañías accesibles desde el exterior para facilitar el acceso a herramientas o correo a empleados.

Con una simple búsqueda, ya tenemos resultados:

 

 

Análogamente, es posible encontrar servidores de intranet’s, a pesar a que en principio no se encuentran conectadas a Internet, es decir, no son accesibles (o no deberían) desde una red externa  de la local de la compañía:

 

 

También valen Dorks un poco más «elaborados» como:

inurl:http?://intranet

inurl:http intranet

Además también podemos combinar la búsqueda de intranet o extranet a través de Leak Information, por ejemplo, es sabido que muchas web’s no protegen de manera adecuada el acceso a recursos como pdf’s Downloads en WordPress o similares, provocando que los bot’s las encuentren, las visiten y por tanto, los indexen, entonces, ¿Y si buscamos ficheros en los que aparezca algo de intranet ya sea en el título o en el texto?

Combinando Leak+Intranet’s+metadatos

Dork: ext:pdf intitle:»http intranet»

Dork: ext:pdf intext:»http intranet»

 

De nuevo las universidades se llevan la palma ;(

Esto me lleva a pensar como se indicó en el post de «Preguntando contraseñas a los buscadores» si se detecta que una universidad emplea como política de contraseñas la misma que el nombre de usuario,… y se encuentran extranet…hasta ahí puedo leer en alto…

Creo que voy a parar que sino me lanzo y no acabo jajjaja. En el próximo capítulo más y mejor 😉

Espero que os haya gustado y os sea útil.

Saludos.

N4xh4ck5