04 Aug 22

PrestaShop: vulnerabilidad de seguridad

PrestaShop, la compañía que da nombre al conocido sistema de gestión de contenidos o CMS (content management system) de código abierto, ha informado recientemente de una vulnerabilidad de seguridad en su producto que permite la ejecución de código arbitrario en los servidores que dan soporte a sitios web que se basan en él. Ante escenarios como este, un WAF de nueva generación cobra una gran importancia. Te lo explicamos.

PrestaShop: vulnerabilidad por inyección de SQL 

Inyección de código malicioso

El CMS de PrestaShop es la solución elegida por un gran número de actores para la construcción de plataformas de e-commerce. Según la propia empresa, aproximadamente 300.000 negocios online se basan en su solución software, especialmente en Europa y en Latinoamérica. 

La explotación de esta vulnerabilidad de seguridad y la consiguiente inyección de código malicioso otorgaría al atacante la capacidad de recabar información confidencial referente a los clientes de esas plataformas de e-commerce. Esa información incluye los datos bancarios de esos clientes.

La vulnerabilidad, que está categorizada como CVE-2022-36408, es una vulnerabilidad por inyección de SQL o SQLi (SQL injection). Según los datos que ha ofrecido la empresa, afecta a las versiones de su producto desde la v1.6.0.10 en adelante. PrestaShop la ha subsanado a partir de la versión v1.7.8.7, aunque la empresa ha indicado que no puede garantizar que esta sea la única forma de ejecutar el ataque. 

Y, si bien hay que actualizar el software con sus correspondientes parches de seguridad, tal y como en Transparent Edge recomendamos, también es necesario tener en cuenta la gran relevancia de un WAF (web application firewall) como el nuestro ante escenarios como este. 

El WAF frente al tráfico malicioso 

Un WAF es, ante todo, una herramienta de seguridad, un firewall que analiza y, llegado el caso, intercepta y bloquea tráfico HTTP malicioso (intentos de SQLi, entre otros) hacia y desde una aplicación web como es el caso, por ejemplo, de una plataforma de comercio electrónico basada en PrestaShop.

Integrado en nuestra CDN de nueva generación, nuestro WAF es totalmente configurable desde nuestro panel (dashboard). 

De manera declarativa y mediante un conjunto acotado de cabeceras HTTP, es posible, entre otras cosas:

  • activar o desactivar el WAF a voluntad y de acuerdo a los criterios necesarios en cada escenario: geográficos, por cookies de usuario, URLs, etc.; 
  • indicar el modo de funcionamiento del WAF (detección y bloqueo o solo detección, para llevar a cabo un análisis preliminar del tráfico recibido, por ejemplo); 
  • aplicar excepciones a reglas en los casos en los que es justificado y necesario (ante la presencia de falsos positivos, por ejemplo), etc.

Así, una configuración como la siguiente desplegada en nuestro panel activaría el uso del WAF para el sitio web www.mi-sitio.es:

sub vcl_recv {

    if (req.http.host == "www.mi-sitio.es") {

        set req.http.TCDN-WAF-Enabled = "true";

        set req.http.TCDN-WAF-Set-SecRuleEngine = "#On";

    }

}

 

De este modo, las peticiones realizadas contra el sitio web serían procesadas en nuestra CDN. Esta, a su vez, se encargaría de delegar dichas peticiones al WAF. Y el WAF actuaría entonces como una capa L2 entre la CDN y el origen (backend) del sitio. 

Peticiones inocuas o maliciosas

Una vez una petición es recibida en el WAF, este ejecuta las comprobaciones oportunas para determinar su naturaleza, es decir, para ver si es inocua o, por el contrario, maliciosa. 

Así, en el caso de que sea inocua, la petición será delegada con seguridad al origen, la infraestructura subyacente. Pero si la petición es maliciosa, será bloqueada por el WAF, devolviendo en su lugar un status code 403 (Forbidden). Jamás llegará a interactuar en origen por lo que, consecuentemente, no podrá causar daño alguno.

El WAF de nueva generación de Transparent Edge está construido sobre Modsecurity e implementa y mantiene actualizado el CSR (core rule set) de OWASP (Open Web Application Security Project) a fin de contar siempre con las últimas reglas para la detección de ataques. 

El objetivo es, por un lado, proteger las aplicaciones web de un amplio abanico de distintos tipos de ataques, incluyendo el OWASP Top #10, y, por otra parte, minimizar el número de posibles falsos positivos.

Prestashop: vulnerabilidad SQLi

En el caso de la vulnerabilidad reportada por parte de PrestaShop, al tratarse de un SQLi, el conjunto de reglas del CRS de OWASP asociado a este tipo de ataques es aquel con la numeración 942XXX. Está vinculado al archivo de configuración rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf

Este conjunto de reglas aglutina las distintas casuísticas contempladas (grosso modo, encaje de expresiones regulares) que revelan que una petición concordante tiene como propósito, en realidad, el intento de acceso a la base de datos del sitio web, bien para destruir o para recabar datos, como ha sucedido con PrestaShop.

WAF de nueva generación

Nuestro WAF de nueva generación cuenta, además, con un antivirus integrado para el análisis de archivos adjuntos. Garantiza el acceso a las auditorías de seguridad generadas por el WAF bien desde nuestro panel o bien de manera externa a través de nuestro servicio de entrega de logs en streaming

Asimismo y gracias a su integración con nuestra CDN, es posible conjugar de una manera muy sencilla otros mecanismos de protección como el bloqueo de direcciones IP sospechosas, la definición de reglas de bloqueo geográfico o la aplicación de límites en el ratio de peticiones por unidad de tiempo (rate limit).

En resumen, disponer de una política adecuada para la instalación de parches de seguridad y la actualización del software es primordial. Pero acabas de ver que nuestro WAF es una herramienta con los atributos y la capacidad necesaria para contrarrestar y mitigar escenarios peligrosos, como el de PrestaShop y la vulnerabilidad que se ha detectado recientemente.