EtiquetaHacking

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.

Seguir leyendo

[Proof-of-Concept] DoS gracias al script wp-trackbacks de wordpress

Un par de horas atrás, publiqué un artículo luego de haber leído una publicación de jcarlosn. Me di el tiempo de realizar una prueba de concepto (PoC) usando el exploit que él mismo propone. Si bien el código que él publicó tiene algunos problemas, luego de hacerle un par de modificaciones logré ejecutarlo y analizar su comportamiento y ver cómo sufre el servidor objetivo.

Duración de la prueba de concepto: 2 minutos
Sitio o servidor objetivo: blog.zerial.org
Tipo de exploit: remoto
Vulnerabilidad: Resource Exhaustion (DoS)
Descripción: El servidor comienza a consumir recursos hasta agotarlos, provocando la denegación del servicio.

wpress-test

Ejecuté el exploit en tres consolas distintas de forma simultanea, y al pasar 10 o 15 segundos ya se comenzó a notar el consumo de recursos en el servidor.

Seguir leyendo

Más Full Path Disclosure en WordPress y sin solución

Hace unos días publiqué un artículo sobre varios plugins que nos permitian ver el directorio completo de la instalación de wordpress (full path disclosure). Luego de esta publicación de una discusión en un hilo de la lista en full disclosure, me llegó un correo donde me comentaban que no sólo eran esos ficheros los que tenian esta vulnerabilidad, sino muchos más dentro de todo el sistema de wordpress.pwnpress
En la lista full disclosure y por otros medios, la gente me decia que eso se desactivaba facilmente deshabilitando la opcion “display errors” de php (ya sea en el php.ini, htaccess o en el mismo fichero php) pero mi opinión fue siempre la misma: Esta forma de ‘solucionarlo’ ocultaría el error pero en ningún caso lo solucionaría, es decir, el problema continuaría estando, pero oculto. Otras personas dieron otro tipo de solución como la de editar los ficheros e incluir una validación de la existencia de algunas constantes o variables que WordPress setea y, de esta forma, saber si el fichero se está ejecutando directamente o mediante wordpress.

Este problema lo reporté a security en wordpress.com el mismo día que hice la publicación pero no obtuve respuesta.

Ahora les mostraré los otros ficheros por los cuales es posible descubrir la ruta completa del sistema y las posibles soluciones que me han palnteado.

Seguir leyendo

Cómo validar correctamente la descarga de un archivo en php

Este post es debido a un correo que recibí preguntando como evitar el full path disclosure y el directory transversal desde un fichero php que realiza descargas. El error que plantearé a continuación es muy común en muchos sistemas web y ya he publicado varias webs vulnerables con este mismo problema. Corresponde a la forma de descarga tipo download.php?dir=ficheros/&file=test.pdf.

secure

Con una URL de este tipo, es posible forzar un FPD modificando las variables “dir” y “test”, cambiadolas por cualquier cosa que sepamos que no existe y de esta forma obtendremos un fichero php con un error, el cual nos revelará el path de la aplicación. Si cambiamos el valor de la variable “dir” a “../../../../../../etc/” y “file” a “passwd”, es muy probable que nos deje descargar el fichero /etc/passwd, lo mismo con cualquier otro fichero. De esta misma forma, podemos ir descargando uno a uno los códigos fuentes del sistema php y poder acceder a los usuarios y claves de conexion a la base de datos y otro tipo de información confidencial.

Seguir leyendo

Vulnerabilidad en la mayoría de los plugins para WordPress

pwnpressHace un par de días, mientras hacia unas pruebas y revisaba unos sistemas descubrí una vulnerabilidad que afectaba a unos cuantos plugins de WordPress instalados.
Continuando mi investigación llegúe a la conclusión de que se trata de una vulnerabilidad Full Path Disclosure (FPD) que afecta a la mayoría de los plugins de WordPress, incluyendo al “Hello Dolly” y Akismet (plugins por defecto). Para explotar esta vulnerabilidad, no es necesario que el plugin esté activo, simplemente que esté instalado. Esta vulnerabilidad es debido a un problema o error a la hora de programar los plugins, al no validar la existencia de funciones antes de ejecutarlas el sistema devuelve un error fatal, mostrandonos la ruta completa de la instalación del CMS. Por ejemplo, en Akismet:

Fatal error: Call to undefined function add_action() in /home/XXYYZZ/public_html/wp-content/plugins/akismet/akismet.php on line 26

Hablando un poco sobre la vulnerabildiad FPD y recordando lo que dije en el post pasado, explotar esta vulnerabilidad no significa que podamos hacer grandes cosas, simplemente nos entregará información que podría ser utilizada para lo que uno estime conveniente.

Seguir leyendo

La vulnerabilidad Full Path Disclosure …

fpd

Según OWASP:

Full Path Disclosure (FPD) vulnerabilities enable the attacker to see the path to the webroot/file. e.g.: /home/omg/htdocs/file/. Certain vulnerabilities, such as using the load_file() (within a SQL Injection) query to view the page source, require the attacker to have the full path to the file they wish to view.

Según Acunetix:

Description
By injecting unexpected data into a parameter. it’s possible to generate an error that will reveal the full path of the script.

Impact
A remote user can determine the full path to the web root directory and other potentially sensitive information.

Si bien esta vulnerabilidad no es peligrosa, es una ayuda para obtener información que nos permitirá a explotar otro tipo de vulnerabilidades como por ejemplo Local File Include, por ejemplo en el caso que publiqué hace un tiempo del sitio de Veramonte, en el cual la combiné con una Directory Traversal.

Seguir leyendo