Crear configuraciones personalizadas para el WAF puede ser beneficioso para organizaciones, permitiéndoles ajustar sus mecanismos de protección de acuerdo con sus necesidades específicas. En ciertas situaciones, confiar en configuraciones por defecto puede ser demasiado restrictivo y bloquear peticiones legítimas. Esto es particularmente cierto para aplicaciones que aceptan información, como queries SQL para reportar o tareas de pipelining. Un WAF con reglas CRS por defecto que trata patrones como UNION, SELECT, --, ; o queries multilínea como maliciosas podría bloquear peticiones de reporte legítimas, resultando en fallos en las ejecuciones de trabajo e información.
Sin embargo, crear una configuración WAF robusta que permita peticiones legítimas mientras se asegura de que las maliciosas son bloqueadas puede ser retador para la organización. En algunos casos, incluso un pequeño despiste puede introducir debilidades que comprometan el sistema.
En esta tarea exploraremos cómo una regla de WAF pobremente configurada puede ser bypasseada para explotar una vulnerabilidad de inyección SQL en una página de login. Consideremos las siguientes reglas:
# Rule 4002: SQL - Only blocks case sensitive SQL keywords SecRule ARGS "@rx \b(select|union|insert|update|delete|or|and|SELECT|UNION|INSERT|UPDATE|DELETE|OR|AND|1=1|true|TRUE))\b" \ "id:4003,phase:2,t:none,deny,status:403,log,msg:'Case-sensitive SQL keywords blocked'"
La regla con ID 4002 busca coincidencias de palabra clave SQL que estén en el input. Esta regla salta explícitamente en minúscula y mayúscula, lo que puede ser bypasseado simplemente usando mixed-case (uNioN).
En el login de la aplicación de Blog, intenta bypassear la autentificación subiendo un payload de inyección SQL básico ' or 1=1-- en el username y password.
Verás que el WAF lo bloquea y devuelve 403 Forbidden.
Por otro lado, subir una query SQL con mixed-case, como 'oR tRue-- bypassea la configuración débil, permitiéndonos acceder al panel de administración.