Subiendo shell con sqlmap + Cloak
Bueno nada para esta oportunidad me tomé el tiempo de realizar este post ya que en una de las labores diarias de “pentesting” y en esta oportunidad con @ArthusuxD nos topamos con un aplicativo web el cual tenía la vulnerabilidad mas explotada actualmente SQLi , lo curioso en esta ocasión es que era un server dedicado y aparte de eso el usuario que corría la db era “root” como lo podemos ver a continuación:
Para saber el usuario con el que corre la db usamos el comando –current-user
Luego de ver el usuario pues nada me imagine lo que todo mundo pensaría “Debe tener full permisos” así que para salir de la duda consulté los permisos con los que contaba dicho usuario usando el comando –privileges y ¡ voila !
Fue cuando me dije: “esto será igual que siempre subir Shell – darle pwn3d al server y reportarlo” por lo cual me puse en la tarea de subir una Shell al servidor como tal para lograr el acceso que quería, entonces hice uso del parámetro de sqlmap –os-shell el cual nos permite subir una Shell vía SQLi y a su vez nos retornar una Shell code del O.S dentro del servidor para un mejor manejo.
Pues nada quería subir una Shell en php, así que le di la opción de subirla en php, luego me pidió que ingresara el PATH en el que deseo subir la Shell y pues como es de saber debe de ser en el PATH público el cual se puede consultar desde internet es decir en el que se encuentra alojado el aplicativo web por ejemplo en servidores Linux suelen alojarse en /home/user/public_html/
Por lo cual sería o probar suerte y digitar un PATH al asar tratando de dar con el verdadero, ocasionar un FPD (Full Path Disclosure) o buscar el tan conocido script info.php, afortunadamente me tope con el info.php el cual nos dice muchas cosas sobre las configuraciones del servidor en el que se encuentra y entre todo nos indica el PATH público el cual necesitamos.
Como podemos observar en la imagen el PATH público se encuentra en C:\inetpub\wwwroot\ ahora solo era cuestión de ingresarlo en Sqlmap y esperar que hiciera lo que debía.
Pues bien ¡! Por suerte mía si logró subir la Shell que trae por defecto sqlmap en php, pero corrí con tan mala suerte de que en el Directorio en el que se subió la shell no habían permisos para modificar, ni subir archivos desde el mismo!! – por lo cual se me hizo raro que dejara subir la backdoor, aprovechando la Shell del sistema que retorna este proceso, hice un DIR para ver si habían quedado ambos archivos y como podemos ver así fue:
tmpbgkeg.php y tmpubztg.php
Entonces me fui al navegador e ingresé la url de uno de los scripts que subió Sqlmap y efectivamente ahí estaba, era un uploader obviamente sin filtros para poder subir cualquier tipo de archivo sin restricciones.
Pero de lo que me había olvidado era de que el directorio en el que había subido la Shell no tenía permisos para subir o crear archivos ¡! Por lo cual intenté subir mi Shell pero sin obtener resultados.
Por lo cual me puse a pensar en cual era el script que sube sqlmap por defecto entonces me dirigí a la carpeta en la cual tengo sqlmap, veo la carpeta que dice Shell y al entrar me encuentro con varios archivos llamados backdoor con distintas extensiones entre las cuales estaba la que necesitaba que era backdoor.php_
Me causó curiosidad del por qué terminaba en .php_ por lo cual abrí el documento para editarlo y al abrirlo me encuentro con que el archivo estaba encriptado ¡!!
No sabía cual era la necesidad de encriptar el contenido del archivo, entonces hice lo que haría cualquiera con la mas mínima iniciativa de experimentar y pues nada renombre mi Shell.php a backdoor.php_ y la reemplace por la que estaba en el directorio de shells de sqlmap, pues esto con la idea de que si no me dejaba subir nada en ese directorio y los otros que habían no tenía los permisos suficientes entonces decidí no subir la backdoor por defecto de sqlmap sino subir mi Shell directamente para luego tener un mejor control y ya poder tener control del server como tal PERO la sorpresa al repetir el proceso de subir la Shell, sqlmap me dice que el archivo no se encuentra encriptado por lo cual puede ser detectado por AVs , entonces ahí entendí la necesidad del por qué encriptaba los archivos antes de subirlos, así que nada viendo el archivo README.txt me encontré con la siguiente instrucción:
Como mi inglés es muy básico entendí unas cuantas líneas, me dirigí a la carpeta extra/cloak/ ya que es el script que usaron para encriptar las backdoors e hice uso de ella para encriptar mi Shell y poder subirla sin problema.
cloak.py -i Shell.php -o backdoor.php_
Siendo -I el parámetro en el que indicaremos la ruta del archivo a encriptar.
-o siendo el nombre del script luego de encriptarlo.
Por lo cual respeté el formato que tenían las backdoors por defecto, entonces copié mi Shell dentro de la carpeta “cloak” para no liarme con rutas de archivos y esas cosas, luego de eso procedí a encriptar la Shell.
Y como podemos ver se logró el objetivo sin problema.
Procedí a abrir la Shell que acababa de encriptar y bueno el resultado fue exitoso, aquí podemos ver la Shell encriptada.
Ya estando encriptado el archivo, procedí a reemplazarlo por el backdoor.php_ que se encontraba en la carpeta Shell de sqlmap, posterior a esto sólo fue repetir el proceso de subir la backdoor….
Bueno subió de nuevo sin dificultad pero con el mismo “problema” de permisos en el directorio en el que se subió el script, me dirigí al navegador para abrir el archivo tmpuupij.php y ¡voila!
La Shell funcionando sin problema (oculté nombres de directorios por “seguridad” ya que es un pentest “ético” ), ya teniendo la Shell arriba en el server el resto era cuestión de saber moverse y lograr el objetivo que era darle pwn3d ¡!
Luego de buscar la manera logré permisos en uno de los directorios y subir un simple archivo .txt haciendo el “pwn3d” – solo queda agradecer a todos por leer está entrada y dar gracias a arthusu por la compañía en las horas de la madrugada xD.
EL SERVER QUEDÓ REPORTADO A SUS RESPECTIVOS DUEÑOS .
Para saber el usuario con el que corre la db usamos el comando –current-user
Luego de ver el usuario pues nada me imagine lo que todo mundo pensaría “Debe tener full permisos” así que para salir de la duda consulté los permisos con los que contaba dicho usuario usando el comando –privileges y ¡ voila !
Fue cuando me dije: “esto será igual que siempre subir Shell – darle pwn3d al server y reportarlo” por lo cual me puse en la tarea de subir una Shell al servidor como tal para lograr el acceso que quería, entonces hice uso del parámetro de sqlmap –os-shell el cual nos permite subir una Shell vía SQLi y a su vez nos retornar una Shell code del O.S dentro del servidor para un mejor manejo.
Pues nada quería subir una Shell en php, así que le di la opción de subirla en php, luego me pidió que ingresara el PATH en el que deseo subir la Shell y pues como es de saber debe de ser en el PATH público el cual se puede consultar desde internet es decir en el que se encuentra alojado el aplicativo web por ejemplo en servidores Linux suelen alojarse en /home/user/public_html/
Por lo cual sería o probar suerte y digitar un PATH al asar tratando de dar con el verdadero, ocasionar un FPD (Full Path Disclosure) o buscar el tan conocido script info.php, afortunadamente me tope con el info.php el cual nos dice muchas cosas sobre las configuraciones del servidor en el que se encuentra y entre todo nos indica el PATH público el cual necesitamos.
Como podemos observar en la imagen el PATH público se encuentra en C:\inetpub\wwwroot\ ahora solo era cuestión de ingresarlo en Sqlmap y esperar que hiciera lo que debía.
Pues bien ¡! Por suerte mía si logró subir la Shell que trae por defecto sqlmap en php, pero corrí con tan mala suerte de que en el Directorio en el que se subió la shell no habían permisos para modificar, ni subir archivos desde el mismo!! – por lo cual se me hizo raro que dejara subir la backdoor, aprovechando la Shell del sistema que retorna este proceso, hice un DIR para ver si habían quedado ambos archivos y como podemos ver así fue:
tmpbgkeg.php y tmpubztg.php
Entonces me fui al navegador e ingresé la url de uno de los scripts que subió Sqlmap y efectivamente ahí estaba, era un uploader obviamente sin filtros para poder subir cualquier tipo de archivo sin restricciones.
Pero de lo que me había olvidado era de que el directorio en el que había subido la Shell no tenía permisos para subir o crear archivos ¡! Por lo cual intenté subir mi Shell pero sin obtener resultados.
Por lo cual me puse a pensar en cual era el script que sube sqlmap por defecto entonces me dirigí a la carpeta en la cual tengo sqlmap, veo la carpeta que dice Shell y al entrar me encuentro con varios archivos llamados backdoor con distintas extensiones entre las cuales estaba la que necesitaba que era backdoor.php_
Me causó curiosidad del por qué terminaba en .php_ por lo cual abrí el documento para editarlo y al abrirlo me encuentro con que el archivo estaba encriptado ¡!!
No sabía cual era la necesidad de encriptar el contenido del archivo, entonces hice lo que haría cualquiera con la mas mínima iniciativa de experimentar y pues nada renombre mi Shell.php a backdoor.php_ y la reemplace por la que estaba en el directorio de shells de sqlmap, pues esto con la idea de que si no me dejaba subir nada en ese directorio y los otros que habían no tenía los permisos suficientes entonces decidí no subir la backdoor por defecto de sqlmap sino subir mi Shell directamente para luego tener un mejor control y ya poder tener control del server como tal PERO la sorpresa al repetir el proceso de subir la Shell, sqlmap me dice que el archivo no se encuentra encriptado por lo cual puede ser detectado por AVs , entonces ahí entendí la necesidad del por qué encriptaba los archivos antes de subirlos, así que nada viendo el archivo README.txt me encontré con la siguiente instrucción:
“Due to the anti-virus positive detection of shell scripts stored inside
this folder, we needed to somehow circumvent this. As from the plain
sqlmap users perspective nothing has to be done prior to their usage by
sqlmap, but if you want to have access to their original source code use
the decrypt functionality of the ../extra/cloak/cloak.py utility.”
Como mi inglés es muy básico entendí unas cuantas líneas, me dirigí a la carpeta extra/cloak/ ya que es el script que usaron para encriptar las backdoors e hice uso de ella para encriptar mi Shell y poder subirla sin problema.
cloak.py -i Shell.php -o backdoor.php_
Siendo -I el parámetro en el que indicaremos la ruta del archivo a encriptar.
-o siendo el nombre del script luego de encriptarlo.
Por lo cual respeté el formato que tenían las backdoors por defecto, entonces copié mi Shell dentro de la carpeta “cloak” para no liarme con rutas de archivos y esas cosas, luego de eso procedí a encriptar la Shell.
Y como podemos ver se logró el objetivo sin problema.
Procedí a abrir la Shell que acababa de encriptar y bueno el resultado fue exitoso, aquí podemos ver la Shell encriptada.
Ya estando encriptado el archivo, procedí a reemplazarlo por el backdoor.php_ que se encontraba en la carpeta Shell de sqlmap, posterior a esto sólo fue repetir el proceso de subir la backdoor….
Bueno subió de nuevo sin dificultad pero con el mismo “problema” de permisos en el directorio en el que se subió el script, me dirigí al navegador para abrir el archivo tmpuupij.php y ¡voila!
La Shell funcionando sin problema (oculté nombres de directorios por “seguridad” ya que es un pentest “ético” ), ya teniendo la Shell arriba en el server el resto era cuestión de saber moverse y lograr el objetivo que era darle pwn3d ¡!
Luego de buscar la manera logré permisos en uno de los directorios y subir un simple archivo .txt haciendo el “pwn3d” – solo queda agradecer a todos por leer está entrada y dar gracias a arthusu por la compañía en las horas de la madrugada xD.
EL SERVER QUEDÓ REPORTADO A SUS RESPECTIVOS DUEÑOS .