Los atacantes han encontrado una manera de utilizar una vulnerabilidad de seguridad para llevar a cabo la ejecución de código arbitrario en los servidores que ejecutan sitios web PrestaShop.
¿Qué está pasando?
El equipo de mantenimiento ha sido informado de que actores maliciosos están explotando una combinación de vulnerabilidades de seguridad conocidas y desconocidas para inyectar código malicioso en sitios web de PrestaShop, lo que les permite ejecutar instrucciones arbitrarias, y potencialmente robar la información de pago de los clientes.
Mientras investigábamos este ataque, encontramos una cadena de vulnerabilidad desconocida hasta ahora que estamos arreglando. Sin embargo, por el momento no podemos asegurar que sea la única forma de realizar el ataque. A nuestro entender, este problema parece afectar a las tiendas basadas en las versiones 1.6.0.10 o superiores, sujetas a vulnerabilidades de inyección SQL. Las versiones 1.7.8.2 y superiores no son vulnerables, a menos que ejecuten un módulo o código personalizado que incluya una vulnerabilidad de inyección SQL. Tenga en cuenta que las versiones 2.0.0~2.1.0 del módulo Wishlist (blockwishlist) son vulnerables.
Cómo funciona el ataque
El ataque requiere que la tienda sea vulnerable a exploits de inyección SQL. Por lo que 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 no descubierta.
Según nuestras conversaciones con propietarios de tiendas y desarrolladores, el modus operandi recurrente es el siguiente:
- El atacante envía una solicitud POST al punto final vulnerable a la inyección SQL.
- Después de aproximadamente un segundo, el atacante envía una solicitud GET a la página principal, sin parámetros. Esto da lugar a la creación de un archivo PHP llamado blm.php en la raíz del directorio de la tienda.
- El atacante ahora envía una solicitud GET al nuevo archivo que se creó, blm.php, lo que le permite ejecutar instrucciones arbitrarias.
Una vez que los atacantes lograron hacerse con el control de una tienda, inyectaron un formulario de pago falso en la página de pago de la tienda. En este escenario, los clientes de la tienda podrían introducir la información de su tarjeta de crédito en el formulario falso y, sin saberlo, enviarla a los atacantes.
Aunque este parece ser el patrón común, los atacantes podrían estar utilizando uno diferente, colocando un nombre de archivo distinto, 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 la seguridad de su tienda
En primer lugar, asegúrese de que su tienda y todos sus módulos están actualizados a su última versión. Esto debería evitar que su tienda esté expuesta a vulnerabilidades de inyección SQL conocidas y activamente explotadas.
De acuerdo con nuestra comprensión actual del exploit, los atacantes podrían estar utilizando las características de almacenamiento en caché de MySQL Smarty como parte del vector de ataque. Esta característica se utiliza raramente y está desactivada por defecto, pero puede ser activada remotamente por el atacante. Hasta que se publique un parche, recomendamos desactivar físicamente esta función en el código de PrestaShop para romper la cadena de ataque.
Para ello, localice 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):
if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php';
$smarty->caching_type = 'mysql';
}Cómo saber si está afectado
Considere la posibilidad de 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:
- [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, like Gecko) Version/10.0.1 Safari/602.2.14" - [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, like Gecko) Chrome/54.0.2840.98 Safari/537.36" - [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"
(Nota: la ruta del módulo vulnerable ha sido modificada por razones de seguridad)
Tenga en cuenta que el hecho de 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 realizarlo, y los atacantes también podrían intentar ocultar sus huellas.
Considere la posibilidad de contactar con un especialista para que realice una auditoría completa de su sitio y se asegure de que no se ha modificado ningún archivo ni se ha añadido ningún código malicioso.
