el ataque mas comun son los ataques de fuerza bruta para logearse con permisos privilegiados sin autorizacion en paneles de administrador, en este caso veremos como funciona esto en sitios web generados por WordPress como este y como para los atacantes se hace mas facil cuando los sysadmin tienen nulas practicas de seguridad ya que wordpress no fue creado pensando en la ciberseguridad
- Github: https://github.com/gn0sys11root/gnosiswp-brute-force (adaptado al ingles tambien)
Herramienta para demostrar el funcionamiento de los ataques de fuerza bruta:
Mientras estaba haciendo el plugin GnosisGuard, tambien hice algunos scripts para verificar los metodos de seguridad pensando con la mente de Red Team (atacante) asi que hice un script para realizar un ataque de fuerza bruta de 2 formas distintas, una por wp-login.php (este oculto o no) y otra de forma alternativa y muchas veces mas desconocida que es utilizando la API de wordpress XML-RPC
Probando en un subdominio con wp-login.php abierto hice una simulacion con 15 contraseñas poniendo una correcta para imitar perfectamente un ataque de fuerza bruta. el script detecta cuando es la correcta por la respuesta del servidor redireccionando al directorio wp-admin. en un escenario real un atacante correría el script dias utilizando un diccionario muy grande demorando algunos dias o semanas.
Para evitar este ataque de fuerza bruta es necesario un sistema que agregue un limite de intentos fallidos y que como resultado bloquee por IP nuevos intentos por X tiempo como 30 minutos, horas o en una configuración mas agresiva agregar un bloqueo permanente despues de intentos fallidos determinados. en el video se ve como el script no detecta la contraseña correcta a pesar de estar en la lista por esto.
este tipo de seguridad es lo que tiene que tener cualquier sitio como minimo, personalmente prefiero ademas de esto ocultar el portal de inicio de sesion configurandolo en un directorio oculto ademas de un captcha como el de reCAPTCHA ademas de solo permitir que se logeen por un ASN de un ISP autorizado. con esto hara extremdamente dificil realizar un ataque de fuerza bruta por el portal de inicio de sesion.
Ataque de fuerza bruta con solicitudes wp.getUsersBlogs en la API XML-RPC:
incluso con unas politicas de seguridad que cubran el 100% de los posibles ataques en el portal de login, algo de por si imposible pero hipotéticamente hablando si fuera posible, si queda abierta la API de WP llamada XML-RPC (archivo xmlrpc.php) todavia un atacante podria utilizar diferentes parametros como wp.getUsersBlogs para saber si un usuario y contraseña es valida para iniciar sesión
en el video podemos ver como todavia es posible realizar un ataque de fuerza bruta al wordpres instalado en el subdominio incluso con todas las protecciones en el portal de inicio de sesion todavia sigue siendo vulnerable al enviar muchas solicitudes a XML-RPC. es posible agregar protecciones aqui tambien limitando parametros pero esto solo es recomendable si utilizas XML-RPC pero si no recomiendo bloquear a nivel de servidor cualquier tipo de solicitud a esta API para detener cualquier ataque
en el video podemos ver como al bloquear solicitudes a XML-RPC tampoco es posible realizar el mismo ataque de fuerza bruta que mostramos antes. ademas de estos ataques se bloquean otros como la posibilidad de explotar vulnerabilidades antiguas via XML-RPC como los que puedes ver en esta lista