WordPress: Time-Based XSPA (Cross-Site Port Attack) #WordPress #XSPA #Pentest

Si tienes un WordPress funcionando en tu web, seguro que has ido a través del proceso de instalación que se hace direcatmente desde el propio servidor. Invocando el script de install.php llegas a setup-config.php y ahí le pones los datos necesarios para realizar la conexión al motor de bases de datos MySQL y listo. A comenzar el proceso de puesta en marcha de tu WordPress.

Figura 1: WordPress - Time-Based XSPA (Cross-Site Port Attack)

Sin embargo, como descubrió mi amigo de los dorks "rootkit", en Google se pueden encontrar muchos de estos ficheros con instalaciones a medias, es decir, que no están completadas y por tanto el servidor deja jugar con ellas, lo que puede ser un problema para el servidor web que dejó el WordPress a medio instalar y una ventaja para un atacante en la red.

Figura 2: Ficheros de configuración de WordPress indexados en Google

Los scripts de install.php y setup-config.php son dos de los archivos que se buscan siempre en los procesos de fuzzing a un servidor web, ya que puedes acabar topándote con algo turbio y, si tienes un WordPress, lo mejor es que los quites o los protejas con una ACL. Si la instalación está realizada y se invoca uno de estos scripts - y están aún en el servidor -, el resultado que se obtendrá es algo como esto.

Figura 3: Instalación de WordPress realizada pero script aún en el servidor web

No obstante, aunque esté hecha correctamente y no se pueda lanzar el asistente, lo recomendable es quitarlos o protegerlos como ya he dicho, ya que pueden generar problemas eventualmente en el futuro por culpa de una credencial perdida o robada.

Figura 4: Setup-config.php en el servidor de WordPress

Si das con un servidor en el que el asistente no se ha ejecutado aún, es decir, se han copiado los scripts pero no se ha hecho la instalación, entonces llegarás a una pantalla en la que puedes configurar los patrones de conexión a la base de datos.

Figura 5: Un panel de setup de WordPress expuesto en Internet

Si has estado atento a la serie que le he dedicado el mes pasado a los paneles de gestión de las bases de datos - como Vty PHP, SIDU, Chive o MySQLDumper -  recordarás que los ataques de XSPA (Cross-Site Port Attack) son de lo más común cuando tienes un panel que intenta conectarse a una base de datos, que es al final lo que intenta hacer este script tal y como se puede ver en el código.

Figura 6: Código de conexión a la base de datos en el script de Setup-config.php de WordPress

Es decir, que desde ese panel, jugando con los puertos y las direcciones IP de los servidores se puede obtener un resultado u otro cuando el puerto está abierto o cuando el puerto está cerrado. Y esto se puede hacer también con este panel.

Time-Based XSPA [Cross-Site Port Attack]

Lo cierto es que el mensaje de error que se obtiene es siempre el mismo, pero prestando un poco de atención es posible detectar que el tiempo de respuesta es totalmente distinto cuando el puerto está abierto o está cerrado, por lo que que se podría escanear la DMZ o cualquier servidor de Internet haciendo unas mediciones de tiempo en las respuestas. 

Figura 7: Error que se obtiene cuando no se puede conectar a la base de datos

Para este ejemplo he elegido la web de Eleven Paths donde está abierto el puerto 80 y el puerto 443, pero no tiene abiertos los puertos 4444 ni el puerto 23. Como se puede ver en la imagen superior el mensaje de error será siempre el mismo, pero si lo llevamos a Burp y lo metemos en el Repeater podremos ver los cambios en los tiempos. 

Figura 8: El tiempo de respuesta al intentar conectar al puerto 443 es muy alto

En la imagen anterior se ve que para un intento de conexión al puerto 443 hemos obtenido un tiempo de respuesta muy alto mientras que para el puerto 4444 en la imagen inferior hemos obtenido un tiempo de respuesta infinitamente más corto.

Figura 9: El puerto 4444 da una respusta muy corta en tiempo. Está cerrado.

Si repetimos el mismo experimiento con el puerto 80 y con el puerto 23 veremos un comportamiento en los tiempos similares.

Figura 10: Tiempo de respuesta al intentar al puerto 80 es muy alto

Es decir, un retardo largo de tiempo cuando el puerto está abierto y un retardo corto cuando el puerto está cerrado.

Figura 11: Tiempo de respuesta muy corto. El puerto 23 está cerrado

Al final los tiempos dependen de muchos factores. Del tráfico de la red, del comportamiento de los firewalls de salida y entrada tanto del servidor WordPress que se está utilizando para escanear como del servidor que está siendo escaneado, y por supuesto de la configuración de los servicios y protocolos, que pueden generar bloqueos en muchos puntos de la red. 

Figura 12: Cuando el puerto está abierto se hace el 3-Way Handshake

Pero al final, si el puerto está abierto y se hace el 3-Way Handshake y hay algún servicio esperando paquetes de un determinado tipo el tiempo de respuesta será distinto que si se hace un envío del RESET cuando el puerto esté cerrado y nadie espera nada ahí.

Figura 13: El puerto 2728 está cerrado y se reciben los RESETS

Artículos sobre seguridad en WordPress: Toma nota

En cualquier caso, si tienes un WordPress, ten presente que está en el punto de mira de los atacantes en Internet, así que fortificalo todo lo que puedas. Aquí te dejo una lista de artículos de seguridad en WordPress que te pueden interesar:

- Fortificar WordPress frente ataques de fuerza bruta
- Hackear WordPress con ataques de NetWork Packet Manipulation

- WordPress: Fortificación de la comunicación con MySQL para evitar ataques de Network Packet Manipulation.
- WordPress: XSS en el plugin de WP-UserAgent
- WordPress Troyanizados roban usuarios y contraseñas
- Cómo robarle las contraseñas a los administradores de WordPress con un ataque XSS haciendo uso de Unfiltered HTML.


Figura 14: Proteger WordPress con Latch en 10 minutos
- WPHardening: Automatizar la fortificación de WordPress
- Ataques para listar los plugins de WordPress
- Buscar exploits para WordPress
- WordPress: SQL Injection en plugin de Scarcity Builder
- Agrupar el control de varios WordPress bajo un solo Latch
- WordPress: Ten cuidado con el cacheo de los borradores
- WordPress: Drama de malware por un bug de RFU en MailPoet
- WordPress: Command Injection en plugin TimThumb
- Registrate en WordPress y evalúa su seguridad

Saludos Malignos!