El proveedor de hosting, llamémoslo “Evilnet”, por motivos obvios no voy a dar nombres. Evilnet ofrece servicio de hosting, diseño y programación web, varios dominios que pertenecen a Evilnet, usan la misma estructura de CMS, el mismo con el que corre nuestro hosting1.com  por  acá tenemos otro similar y por supuesto junto con la misma SQLI :)

Siguiendo con el apartado cabe destacar algo interesante que me encontré mediante la recolección de información:

-Ambas webs usan el mismo password en el formulario de administración.

-Ambas webs cuentan con el mismo password en la base de datos.

Parece que el administrador de Evilnet no tiene buena memoria y prefiere usar la misma llave para todo, podría apostar que este “descuido” por llamarlo de manera elegante, se repite en los demás dominios bajo su autoría. Con este criterio quien sabe, si llegara a probar, hasta me podría cargar el facebook y el twitter del admin o hasta la sesión ssh personal, espero no llegarle hasta abajo de la cama jeje!.

Pero en fin ya estaba dentro de hosting2.com, solo me faltaba escalar hasta hosting1.com, lo primero que hice fue tratar de leer el fichero de configuración de la botnet que se encuentra en el directorio base /system/config.php, mediante la creación de un enlace simbólico, pero para mi mala suerte no funciono. Entonces recordé el descuido del administrador e intente ingresar con la llave maestra por así decirlo, mediante otro usuario en la db que pertenezca a hosting1.com, por lo que veía, la estrutura de nombres tiene la siguiente regla:

“Nombre que hace referencia al dominio”_XXXXXXX

ya había intentado loguearme como hosting1_xxxxxxx, entonces fui probando diversas combinaciones de usuarios.

Hasta que logre ingresar como hosting1 solamente, el cual tenia acceso a todas las dbs dentro de la aplicación.

Ya habiendo identificado la preciada base de datos.

Restaba consultar las credenciales en la tabla cp_users y rogar obtener el hash md5 en claro.

Afortunadamente el hashe del admin estaba presente en md5online.