Acceder a una base de datos, que sólo permite conexiones desde localhost, remotamente

Hace unos días recibí un correo preguntandome cómo acceder -remotamente- a un servidor de base de datos que sólo acepta conexiones desde localhost, sin tener phpMy/PgAdmin ni acceso “directo” (ssh) al servidor. Responderé publicamente la pregunta.

s_key

La respuesta a primera vista sería “Es imposible, ya que sólo tiene permitido ingresar desde localhost y, generalmente, el puerto no está a la escucha de 0.0.0.0” pero si vamos más allá y tenemos un poco de imaginación, podemos llegar a pensar de que si es posible; jugando un poco con los conceptos y aplicando distintas técnicas de penetración y de búsqueda de vulnerabilidades que nos lo permitan.

La idea de ingresar “remotamente” queda descartada si pensamos en conectarnos directamente a la base de datos desde un client externo, pero podemos pensarlo cómo el hecho de lograr acceder (remotamente) de una u otra forma para lograr la conexion con el host. Por ejemplo, subiendo un fichero php que tenga las líneas necesarias para conectarse a la base de datos y hacer lo que necesitemos.

No vamos a usar fuerza bruta ni técnicas de robo de información, simplemente nos aprovecharemos de algunas vulnerabilidades comunes.

Existen muchas vulnerabilidades que nos van a permitir ejecutar algún tipo de código arbitrario de manera tal de poder conectarnos a la base de datos a nuestra manera. A continuación enumeraré las distintas vulnerabildiades que nos podrían permitir lograr nuestro objetivo.

  • Remote Code Execution (RCE): Mediante ejecución de código remoto, es posible manejar arbitrariamente una conexión a la base de datos y de esta forma obtener y/o modificar los datos que nos interesan. Esta técnica podría permitir al atacante tener un control total sobre la base de datos del usuario en cuestión. Podemos ejecutar comandos como mysqldump o pg_dump en el caso de mysql o postgres, respectivamente. Tambien podemos ejecutar código php usando el la interfáz de línea de comandos (php-cli), python, perl, etc.
  • Local|Remote File Include (L|RCI): Incluyendo ficheros remotos tambien es posible ejecutar código arbitrariamente, tal cómo lo describí en el punto anterior. Podemos escribir un script en php que nos haga un dump de la base de datos y que la deje en un directorio al cual tengamos acceso desde internet para luego poder descarga la información. Tambien se puede usar usando la técnica de inclusión de ficheros locale, siempre y cuando tengamos algún tipo de acceso para lograr subir ese fichero (cómo lo que explicaré en el próximo punto).
  • File Upload by Authentication Bypass: Esta vulnerabilidad es muy común (lo digo por experiencia) y corresponde nada más ni nada menos al hecho de ingresar en un sistema de gestión de contenido y/o usuarios, el cual permita subir algún archivo sin validarlo (o validandolo incorrectamente). Por ejemplo, típico sistema de gestión de usuario que nos permite adjuntar un curriculum, imágen o sistema de gestión de contenido que nos permite subir alguna imágen adjunta o archivo relacionado a alguna noticia o contenido. Muchas veces estos ficheros no son validados correctamente, aveces simplemente usan una triste validación por javascript o simplemente validan la extensión, sin tomar en cuenta el mime. Entonces es cuando debemos subir algún fichero en php o el lenguaje que sea necesario para ejecutar arbitrariamente el código que necesitemos.
  • FTP password discovery: Esto es súper sencillo. Con este punto me refiero al intentar descargar ficheros de configuración (mediante Directori Transversal) y tener acceso a distintos usuarios y claves para probar el acceso ftp y poder subir algún fichero que nos permita lograr nuestro propósito.
  • PhpMy/PgAdmin: Simplemente, con este último punto, quiero hacer referencia a buscar instalaciones de phpmyadmin o phppgadmin en otros sitios del servidor. Generalmente, un servidor aloja más de un sitio web y más de alguno es vulnerable (nuestra puerta de entrada).

Hay veces que hay que recorrer todo el servidor para encontrar una única puerta de entrada. Como bien dije en el último punto, generalmente los servidores alojan más de un sitio web y nunca falta que uno de ellos sea vulnerable, el que nos permita el ingreso directo o indirecto al servidor y de esta forma ejecutar código arbitrariamente.

5 comentarios

  1. Buen post Bro, a digerir y tratar de practicar, Saludos Daslav.

  2. Buen post. Me llevará tiempo estudiar todo esto. Ya tengo con que entretenerme… Un saludo.

  3. Zerial

    octubre 23, 2009 a las 11:16 am

    Redalert y Doktor Who: Espero que les sirva la informacion y puedan ponerlo en practica. Si bien este post es solo teoria, llevarla a la practica solo requiere un poco de destreza 🙂

  4. El artículo hubiese estado más completo si pones ejemplos de cada vulnerabilidad, nombrarlas sólo es insuficiente si acudes con el problema y quieres resolverlo cuanto antes.

  5. Zerial

    octubre 25, 2009 a las 2:36 pm

    @shakaran: Gracias por tu comentario! La idea de este post es que fuera teorico, es una respuesta publica a un email que me enviaron haciendome unas preguntas (tal y como explico al principio del post). Pero si, encuentro que tienes razon, un post tiene mas entretencion cuando se dan ejemplos *reales* y cuando lo teorico se lleva a la practica. Lo tendre en cuenta.

    saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esto sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.