Hostings: O como cagarla soberanamente (Segunda Parte)

Buenas a todos otra vez, como ya sabreis, os prometí la segunda parte de esto y aquí esta. Asi que sin mas dilacion, empezemos.

Esta vez nos desplazamos a Gijón, para poder, con este articulo, finalizar la historia que empezé antes.

Esta empresa es un show puro y duro, ademas del exponente maximo de caradurismo. Solo hay que hacer una busqueda en Google de dicha empresa, y aparece directamente en trabajobasura.info, y cuando tu empresa aparece alli, algo malo has hecho o estas haciendo. Y los comentarios (del año pasado, por cierto) de esa pagina hablan por si solos, hay  gente descontenta por lo que parece.

Nunca esta demás corroborar y comprobar que lo que dicen en esos comentarios es cierto. Y como decía en el primer comentario, le he pasado el W3c validator, y aunque pongan que usan XHTML y el logo de W3c en la pagina, no esta validado ni lo estará nunca si no corrigen los 69 errores que devuelve.

Y ahora pasamos al test de campo, en el que siempre suelo comprobar primero si existe una vulnerabilidad de Inyeccion SQL y si no existe busco otras vulnerabilidades o configuraciones mal hechas.

En este caso cogí una web cualquiera y me puse a mirar por encima. Parece ser que no hay por donde mirar, pero como siempre, la barra de direcciones me delata las cosas. Al acceder a un articulo de la web, me encuentro con el mismo panorama que en la empresa de Granada, solo que en esta pega el cante que no veas (/index.php/id/11/objeto/).

Enseguida que le hago la técnica del codo-comílla delante de /objeto/, la web se queja, mira tu por donde.

Extraigo los usuarios de la base de datos con sqlmap, y me voy a otra web, hago lo mismo y encuentro a un usuario que se repite en la anterior web, con la misma contraseña. Madre mía….

Me voy directamente al panel, entro y veo una advertencia recordandole al administrador la importancia de la implantacion de la LOPD por parte de esa empresa, que en este caso, es nula.

Y ahora viene lo mejor, me voy a revisar la parte del panel que pone Datos y allí estan los datos de la empresa, metadatos, etc.

Veo un apartado que pone “documentación”, y le doy clic, pensándome que seria algún manual sobre el CMS o algo así. Que va, para nada. Ahí estaba, guardado en el mismo dominio, en un puto PDF… LAS CONTRASEÑAS DE TODO EL SITIO. Contraseñas de emails, panel de administrador, estadísticas… y el ISPConfig (es un cpanel Open-Source con licencia BSD) del dominio, pudiendo acceder y subir archivos vía Web-FTP.

Ya que tenia la ruta de la documentación, me dije a mi mismo: “esto seguramente este así en todas las paginas web que hayan diseñado, probaré en otra a ver”. Y exacto, acerté con mi premonición. Todos y cada uno de los sitios web de esa empresa, tenían la documentación en esa misma ruta.

De hecho tambien me pasee por su pagina principal, la unica que no tenia documentacion, pero he logrado acceder tambien a su panel.

Hostings: O como cagarla soberanamente (Primera Parte)

Hola a todos otra vez. Hoy os vengo a hablar de los hostings, ese caso aparte donde te pueden joder (y arruinar) vivo si tienes una vulnerabilidad grave y se hacen con el control de tu servidor al completo. Así que siguiendo la misma pauta de siempre, voy a contaros como dos hostings que son en mayor o menor medida, importantes, la han cagado pero bien, y se arriesgan a perderlo todo si se hace un Full-Disclosure de la vulnerabilidad o vulnerabilidades presentes en su servidor.

Bueno, pues comencemos con esto. Nos desplazamos hasta Granada para empezar a contar nuestra historia.

Día si y día también, me paso los días detrás del ordenador viendo otras empresas de hosting y diseño web, para ver que tipo de trabajos hacen y si me convence la maquetación de las mismas y mirar a ver si puedo copiarles algo que me pueda ayudar de cara al futuro venidero.

Viendo una de estas paginas, descubro algo que me llama muchísimo la atención, y es que tanto lo que es producto.php?id= y el id del producto van separados por barras (/). Suele ser una particularidad de un CMS propio, pero ya que me llamo la atención, por que no probar a ver si era Inyectable con parámetros SQL, para saber si el CMS estaba bien hecho o por el contrario, era una putísima mierda y había que arreglarlo cuanto antes.

Pasando directamente a la acción, compruebo que el parámetro es vulnerable pero me encuentro con una sorpresa, me devuelve un error 404.

Una vez que me había devuelto el maravilloso error 404, pienso: “Y si pruebo a ponerle la extensión a producto y tirar directamente una consulta en el id?” .

Y ahí empezó la fiesta o el desastre, como lo queráis llamar.

Tras inyectar manualmente y ver que me devolvía la versión de la base de datos, procedí a inyectar automáticamente con sqlmap.

Una vez con la tabla usuarios en la mano, revise a ver que usuarios eran los que mas se repetían. Habían dos usuarios que se repetían que eran administradores en todos los sitios hosteados por esta empresa y usaban siempre la misma contraseña.

Así que, decidí echar un vistazo a su pagina principal, y de paso, saber si también era vulnerable o no.

Revisando un poco el pie de la web para ver como ponerme en contacto con ellos después, vi que estaban asociados a las comunidades de diseñadores web de Granada, además de ser una empresa joven y emprendedora.

Así que, decidido, accedí al panel de administración, y subí una shell. Estuve curioseando un poco para ver los limites del usuario propietario de la web. Me impresione al saber que podía llegar a ver el contenido de /usr/home/ viendo todas las web almacenadas en el servidor.

Claramente, esto no me bastaba, y me fije en los permisos de las carpetas. Tenemos permiso de ejecución en todas, y sabiendome de antemano la ruta donde se alojaban los archivos de las diferentes web (/usr/home/usuario/www/) procedí a investigar aun mas, pero tenia que hacer uso de otra shell ya que, esta no me permitía precisamente hacer lo que yo quería.

Subí una shell cgi y la escondí en un directorio que no usaban mucho, y con esa shell pude hacer lo que me proponía desde el principio.

Una vez dentro de la shell cgi, fui carpeta por carpeta, buscando los archivos de configuración  tanto del CMS propio como de WordPress (Averigue que habia varios WordPress instalados paseandome de dominio en dominio) y mostrandolos con cat, para luego posteriormente guardarlos en un archivo de texto en mi propio PC que después eliminaría.

Una vez con los usuarios y passwords de conexión a las bases de datos, el crearme una cuenta y darme permisos de administrador tanto en WordPress como en el CMS propio era coser y cantar.

Y eso es todo por ahora, seguiremos con la segunda parte, que es cuanto menos, mas de lo mismo, pero mas interesante y con demasiados clientes.