DEV Community: Miguel Angel Falcón Muñoz

Limitar ataques a xmlrpc en Kubernetes

Miguel Angel Falcón Muñoz — Thu, 26 Aug 2021 17:00:51 +0000

Si has montado un wordpress en un cluster de Kubernetes y lo has publicado, habrás notado que al poco tiempo comienza a dar algunos problemas. No te preocupes no es tu fallo, puedes estar sufriendo un ataque de denegación de servicio. En esta entrada vamos a explicar cómo mitigarlo.

Por si no te suenan las sigas DDoS ( Denial Of Services ) es un tipo de ataque que consigue que un servicio publicado en internet deje de funcionar de forma adecuada. En algunas ocasiones puede ser un ataque completamente dirigido con un objetivo claro y en otras puede ser un daño colateral de cualquier otra actividad. Si se trata del primer caso , la solución puede ser un poco más compleja que la que planteamos hoy aquí , en mi caso se trata de un escaneo masivo desde distintas IP’s a un recurso que está accesible por defecto en WordPress , es “/xmlrpc.php” .

¿Qué hay detrás de XML RPC en WordPress ?

Se trata de un servicio de acceso remoto que permite interactuar con nuestro wordpress. Ideado en 2016 e incluido en la versión 2.6 de WordPress ha sido recientemente “reemplazado” por la API REST. Por tanto es muy probable que no lo necesites más.

¿Por qué es un peligro tenerlo activo?

Desde hace años es posible empleando este servicio que tu WordPress envíe “pings” a otras direcciones web. Un atacante puede usando tu sitio y otros que tengan XML-RPC activo lanzar ataques masivos sobre una Web concreta , por lo que sería partícipe, inconscientemente, del primer caso de DDoS que hemos comentado.

¿Por qué me afecta a mi sitio?

Cuando estos ataques emplean tu web consumen los recursos de tu sistema por lo que puedes experimentar problemas de uso de memoria o lentitud en tu web por falta de CPU. Si prestas atención a tu fichero de logs podrás observar muchas entradas como esta:

1XX.XXX.XXX.XXX - - [01/Jan/2021:00:00:01 +0000] "POST /xmlrpc.php HTTP/1.1" 200 222

¿Cómo puede verificar si está accesible el recurso xmlrpc ?

Una forma muy sencilla es acudir a un servicio de validación, que comprobará tu sitio y te dirá si xmlrpc.php está habilitado.

Cuando indique la url de tu wordpress, si el sitio puede acceder a tu xmlrpc te lo indicará con una pantalla como esta.

En el caso de que esta no sea accesible la pantalla será como la siguiente:

¿Como puedo eliminar el acceso a este recurso?

Cuando se trata de un WordPress alojado en un servicidor VPC , la solución es bastante fácil. Tan solo tenemos que denegar el acceso a este recurso en la configuración de nuestro servidor web. Ya sea mediante configuración o mediante el fichero .htaccess , vamos a indicar como:

En el caso del fichero .htaccess debemos añadir lo siguiente:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from none
</Files>

En el caso de un servidor web nginx, la configuración será :

# IMPORTANT: for security purposes, disable access to xmlrpc
location = /xmlrpc.php {
deny all;
return 404;
access_log off;
log_not_found off;
}

¿Qué pasa cuando WordPress se publica en Kubernetes?

Pues en este caso es probable que emplees un balanceador de carga de tu proveedor y un controlador de ingress dentro del cluster Kubernetes para habilitar el acceso a los distintos servicios que publicas.

En este caso debemos modificar el ingress asociado a WordPress para que descarte las peticiones que van dirigidas al recurso xmlrpc mediante un código de error.

Si como en mi caso empleas un controlador de ingress basado en nginx , uno de los más populares y que mejor rendimiento proporcionan tendrás que seguir los siguientes pasos.

Comencemos listando todos los ingress e identificando el que está asociado al dominio.

kubectl get ingress                                                                                                                                                                                                     
NAME      CLASS    HOSTS             ADDRESS                                     PORTS     AGE
wordpress <none>   www.domain.com    abcdefXXXXXXX.ab-east-4.elb.amazonaws.com   80, 443   1d20h

Ya hemos identificado como se llama , podemos obtener toda la configuración y enviarla a un fichero con :

kubectl get ingress wordpress -o yaml > wordpress.yaml

Veamos el contenido:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/issuer: wordpress-issuer
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    meta.helm.sh/release-name: wordpress
    meta.helm.sh/release-namespace: default
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
  labels:
    app.kubernetes.io/instance: wordpress
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: wordpress
    helm.sh/chart: wordpress-XX.X.X
  name: wordpress
  namespace: default
spec:
  rules:
  - host: www.domain.com
    http:
      paths:
      - backend:
          serviceName: wordpress-service
          servicePort: http
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - www.domain.com
    secretName: wordpress-tls
status:
  loadBalancer:
    ingress:
    - hostname: abcdefXXXXXXX.ab-east-4.elb.amazonaws.com

Debemos agregar a esta configuración una nueva anotación que se encargará de denegar el acceso y enviar un error 403 cuando se solicite el recurso “/xmlrcp.php”

Quedando el fichero así:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/issuer: wordpress-issuer
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    meta.helm.sh/release-name: wordpress
    meta.helm.sh/release-namespace: default
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/server-snippet: |
      location ~* "^/xmlrpc.php" {
          deny all;
          return 403;
        }
  labels:
    app.kubernetes.io/instance: wordpress
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: wordpress
    helm.sh/chart: wordpress-XX.X.X
  name: wordpress
  namespace: default
spec:
  rules:
  - host: www.domain.com
    http:
      paths:
      - backend:
          serviceName: wordpress-service
          servicePort: http
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - www.domain.com
    secretName: wordpress-tls
status:
  loadBalancer:
    ingress:
    - hostname: abcdefXXXXXXX.ab-east-4.elb.amazonaws.com

Tan solo debemos aplicar la nueva configuración y de inmediato dejarán de estar accesible el recurso.

Si revisar el log del pod asociado a wordpress observarás de inmediato que desaparecen las peticiones al recurso, y verás como se reduce el uso de recursos de la web.

El original está disponible en el blog de falc0n.es

Cómo mejorar la seguridad de tu API

Miguel Angel Falcón Muñoz — Fri, 06 Aug 2021 15:47:14 +0000

Como mejorar la seguridad de tu API

Existen en el mercado muchísimas herramientas que te ayudan a incrementar la seguridad de tu API, comenzando a bajo nivel mediante la revisión de vulnerabilidades de las librerías que emplea tu framework de desarrollo favorito hasta simulaciones de intentos de romper la API una vez publicada.

Hoy nos centraremos en estas últimas pero empleandolas en las primeras fases del desarrollo.

Usaremos stackhack , un servicio cloud que nos permite escanear nuestra API mediante fuerza bruta para identificar ciertas vulnerabilidades que podrían ser aprovechadas por un atacante que cuando la API esté publicada y expuesta al público.

Accediendo al servicio

Darse de alta en stackhawk.com es muy sencillo y en pocos minutos nos habrá proporcionado una cuenta para desarrolladores con 15 días de prueba.
Es importante que en el proceso de registro y mientras seguimos la guía guardemos el token de acceso que nos proporciona en un lugar seguro y además lo añadamos al fichero de configuración según los pasos que se indica.

Ya en el último paso nos indicará que descarguemos una plantilla del fichero de configuración.

Cómo funciona stackhawk

El funcionamiento es bien sencillo , pero no exento de cumplir unas mínimas reglas.

Dispondremos en su página web de un espacio de trabajo donde se representarán los "entornos" y se asociarán los resultados de las revisiones de nuestra aplicación.

Las revisiones se ejecutarán en nuestro equipo local mediante un contenedor de docker, por ello es importante que tengamos -docker- funcionando correctamente en nuestro equipo. En todo momento la url donde se encuentre publicada la API debe ser accesible desde nuestro equipo, en nuestro caso la API corre en http://localhost:3000 , por lo que no habrá ningún problema.

Cada vez que revisamos la API desde la línea de comando recibiremos un informe y este será remitido al espacio de trabajo de stackhawk por lo que podremos consultar los distintos informes y ver cómo afectan los cambios incorporados.

Por dónde comenzamos

El primer punto es configurar mediante la plantilla unos parámetros mínimos.

app:
  applicationId: XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX # (required)
  env: Development # (required)
  host: 'http://localhost:3000/'
  api: './openapi.json'

Habremos recibido una applicationId que representa la aplicación que vamos a testear. Podemos obtener uno desde el espacio de trabajo al pulsar sobre "Add an APP" aunque por estar en la versión demo solo podremos tener una aplicación.

Es importante indicar un entorno, ya que todas las ejecuciones se agrupan por este campo.

Indicaremos el host , sin indicar la ruta a la API, pero si el puerto.
(*) Recordar en todo momento emplear las comillas simples de lo contrario obtendréis un mensaje como este:

Error: HawkScan is unable to continue.
Please check the target host configuration -
        host: "http://localhost:3000/",
Be sure to include any additional host paths with their respected keys.
(e.g. `loginPath` or `schemaPath`)

Ahora quizás lo más complicado es que debemos disponer de la especificación openapi o swagger de nuestra API en formato .json o .yaml

Y debemos revisar que los recursos se correspondan con el uri completo.
En mi ejemplo la api se encuentra en /api , y el recurso es /qrisk2 , por ello en la definición de la api se modificar por :

    "paths": {
        "/api/qrisk2": {
            "get": {
                "responses": {
                    "200": {

Arrancamos

Bien con esto preparado es el momento de recibir nuestro primer resultado, para ello ejecutamos el contenedor con la siguiente línea de comandos:

$ source ~/.hawk/hawk.rc ; \
docker run -e API_KEY=${HAWK_API_KEY} --rm -v $(pwd):/hawk:rw \
-it stackhawk/hawkscan:latest

La primera vez que ejecutemos tardará un momento en descargar la imagen y una vez que comience la ejecución nos aparecerá algo similar a ...

Bien , ya tenemos nuestro primer informe. Veamos que podemos mejorar.

Al acceder al espacio de trabajo vemos nuestro entorno

Si pulsamos sobre el símbolo " ⋮ " , podemos seleccionar View Scans .

Vemos al última ejecución y nos encontramos con 6 incidencias de importancia media y otras 6 de carácter Low , si las revisamos nos damos cuenta pronto que en realidad una la podemos descartar porque hace referencia a que NO disponemos de un endpoint accessible mediante https , lógico estamos en local.

Como eliminar la primera incidencia de seguridad

Veamos otro de los aspectos que debemos revisar en nuestro desarrollo, nos centraremos en los de nivel Low , vemos que las 6 hacen referencia al mismo problema en diferentes rutas.

Esta indica que mediante el uso de la cabecera "X-Powered-By" un atacante puede identificar el framework que emplea nuestra API y puede focalizar el ataque en el o identificar una vulnerabilidad de último día que pueda afectarla. En este caso lo que debemos hacer es no aportar esta información.

Mi API usa Node.js y Express , por lo que para solventar este inconveniente puedo apoyarme en un módulo que me facilitará mucho el trabajo , llamado helmet.

Lo instalamos en el proyecto.

npm install helmet

He iremos a la sección de nuestro código donde configuramos el servidor express, importamos el módulo y hacemos uso de él.

const helmet = require('helmet');

// Hide the X-Powered-By header
server.use(helmet.hidePoweredBy());

Y voilá...
Arrancamos de nuevo nuestra api y lanzamos de nuevo el scanner desde la línea de comando.

Volvemos al espacio de trabajo y podremos observar que ya no aparecen los 6 fallos de tipo Low

Conclusiones

Una herramienta de estas características nos permitirá revisar que mantenemos en nuestro desarrollo un cierto nivel de control sobre la seguridad. Con el tiempo y solventando las incidencias iremos incorporando de forma continua a nuestras aplicaciones buenas prácticas que eviten exponer información comprometida a terceros o que facilite el acceso no autorizado a nuestros servicios.

Evidentemente, nunca podremos estar 100% seguros pero es un paso en la buena dirección.

La plataforma de stackhack permite la integración con la mayoría de soluciones de gestión de código y de despliegue, de modo que podemos validar nuestra API antes de publicarla e incluso modificando el fichero de configuración cuando esta esté publicada en su URL final.