Vulnerabilidad de inyección SQL de día cero en PrestaShop. Parche no disponible

Los hackers están atacando a sitios web que utilizan la plataforma PrestaShop, aprovechando una cadena de vulnerabilidad previamente desconocida para realizar la ejecución de código y potencialmente robar la información de pago de los clientes. El equipo de PrestaShop emitió una advertencia urgente el viernes pasado, instando a los administradores de 300 000 tiendas que utilizan su software a revisar su postura de seguridad después de que se descubrieran ataques cibernéticos dirigidos a la plataforma.

El ataque parece afectar las versiones 1.6.0.10 o posteriores de PrestaShop y las versiones 1.7.8.2 o posteriores si ejecutan módulos vulnerables a la inyección SQL, como el módulo Wishlist 2.0.0 a 2.1.0.

La vulnerabilidad explotada activamente está siendo rastreada como CVE-2022-36408.

Cómo funciona el ataque

El ataque requiere que la tienda sea vulnerable a las vulnerabilidades de inyección SQL. Hasta donde sabemos, la última versión de PrestaShop y sus módulos están libres de estas vulnerabilidades. Creemos que los atacantes se dirigen a tiendas que utilizan software o módulos obsoletos, módulos de terceros vulnerables o una vulnerabilidad aún por descubrir.

Según su conversaciones con propietarios de tiendas y desarrolladores, el modus operandi recurrente se ve así:

  1. El atacante envía una solicitud POST al punto final vulnerable a la inyección SQL.
  2. Después de aproximadamente un segundo, el atacante envía una solicitud GET a la página de inicio, sin parámetros. Esto da como resultado que se cree un archivo PHP llamado blm.php en la raíz del directorio de la tienda.
  3. El atacante ahora envía una solicitud GET al nuevo archivo que se creó, blm.php, lo que le permite ejecutar instrucciones arbitrarias.

Después de que los atacantes obtuvieran con éxito el control de una tienda, inyectaron un formulario de pago falso en la página de pago de la oficina principal. En este escenario, los clientes de la tienda podrían ingresar la información de su tarjeta de crédito en el formulario falso y, sin saberlo, enviársela a los atacantes.

Si bien este parece ser el patrón común, los atacantes pueden estar usando uno diferente, colocando un nombre de archivo diferente, modificando otras partes del software, plantando código malicioso en otro lugar o incluso borrando sus huellas una vez que el ataque ha tenido éxito.

Qué hacer para mantener tu tienda segura

En primer lugar, asegúrate de que tu tienda y todos tus módulos estén actualizados a su última versión. Esto debería evitar que su tienda quede expuesta a vulnerabilidades de inyección SQL conocidas y explotadas activamente.

De acuerdo con comprensión actual del exploit, los atacantes podrían estar utilizando las funciones de almacenamiento en caché de MySQL Smarty como parte del vector de ataque. Esta característica rara vez se usa y está deshabilitada de forma predeterminada, pero el atacante puede habilitarla de forma remota. Hasta que se publique un parche, recomendamos deshabilitar físicamente esta función en el código de PrestaShop para romper la cadena de ataque.

Para hacerlo, ubique el archivo config/smarty.config.inc.php en su instalación de PrestaShop y elimine las líneas 43-46 (PrestaShop 1.7) o 40-43 (PrestaShop 1.6):

<!-- wp:paragraph -->
<p><strong>if</strong> (<strong>Configuration::get</strong>('PS_SMARTY_CACHING_TYPE') <strong>==</strong> 'mysql') {</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>&nbsp;&nbsp;&nbsp;&nbsp;<strong>incluir</strong> _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php';</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>&nbsp;&nbsp;&nbsp;&nbsp;$inteligente<strong>-&gt;</strong>tipo_de_caching <strong>=</strong> 'mysql';</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>}</p>
<!-- /wp:paragraph -->

Cómo saber si ha sido afectado

Considere buscar en el registro de acceso de su servidor el patrón de ataque explicado anteriormente. Este es un ejemplo compartido por un miembro de la comunidad:

<!-- wp:paragraph -->
<p>- [14/Jul/2022:16:20:56 +0200] "POST /modules/XXX/XXX.php HTTP/1.1" 200 82772 "-" "Mozilla/5.0 ( Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, como Gecko) Versión/10.0.1 Safari/602.2.14"</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>- [14/Jul/2022:16:20:57 +0200] "GET / HTTP/1.1" 200 63011 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/54.0.2840.98 Safari/537.36"</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>- [14/jul/2022:16:20:58 +0200] "POST /blm.php HTTP/1.1" 200 82696 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox /50.0"</p>
<!-- /wp:paragraph -->

(Nota: la ruta del módulo vulnerable se ha modificado por razones de seguridad)

Tenga en cuenta que no encontrar este patrón en sus registros no significa necesariamente que su tienda no se haya visto afectada por el ataque: la complejidad del exploit significa que hay varias formas de hacerlo, y los atacantes también pueden tratar de ocultar sus huellas.

Considere contactar a un especialista para realizar una auditoría completa de su sitio y asegurarse de que no se haya modificado ningún archivo ni se haya agregado ningún código malicioso.