Nos han hackeado una Tienda 1.7.6.7 ayuda...

[Nacho..]

Buenos días,
Nos han hackeado la entrada al backoffice de un PS 1.7.6.7, Al intentar entrar, nos devuelve a la pantalla de login una y otra vez.
No tenemos backup de la tienda. 
Podemos acceder al hosting, BBDD y ficheros.

¿Por donde podemos empezar?
Gracias

[JuanjoG]

Lo primero que puedes probar es a activar el modo DEBUG.

Abre el archivo “config/defines.inc.php” y encuentra el siguiente código:

if (!defined('_PS_MODE_DEV_')) { define('_PS_MODE_DEV_', false); }

Reemplázalo por este, «TRUE».

if (!defined('_PS_MODE_DEV_')) { define('_PS_MODE_DEV_', true); }

Ahora intenta volver a acceder al backoffice. Si consigues entrar, borra cache, y desactiva cualquier módulo que hayas podido activar recientemente.

[JuanjoG]

Revisa que tengas la versión correcta de php la 7.2 según indicas por la versión que tienes de prestashop.

[Enrique Gómez]

Necesitarías poder comparar con una versión "limpia" de tu tienda para restablecer los ficheros corruptos, ya que suelen ser varios.

Puedes descargar una 1.7.6.7 limpia de https://www.prestashop.com/en/versions

este script puede ayudarte a saber que ficheros han sido tocados y que ficheros no cuadran

Si no te aclaras.. contacta con un profesional, mas que nada porque a parte de limpiar hay que mirar por donde se han colado.. 

 

[ExpertoPrestaShop]

Intenta resetear la contraseña del backoffice (en caso de que te la hubieran cambiado): https://youtu.be/KwjT8EMqiik

Luego desde el backoffice menu Parámetros Avanzados -> Información ->  Listado de archivos modificados podrás ver el listado de archivos modificados. Si los restauras al menos deberías poder recuperar el funcionamiento de la tienda.

Luego deber intentar ver por donde entraron, probablemente algún modulo obsoleto, revisando los access_logs de la tienda y intentar parchear el problema para que no se vuelvan a meter.

Suerte!!

 

[Mediacom87]

Hola,

Aquí tienes un artículo que aborda el principio de una solución a tu problema:

https://www.mediacom87.fr/en/how-to-prevent-hacking-on-prestashop-and-thirty-bees/

[Nacho..]

Muchas gracias a todos por vuestra ayuda.
Ya había activado el modo DEBUG y comprobado la versión 7.2 de PHP
He borrado las caches dev y prod
He mirado el report que nos ha pasado el hosting
 

Quote

Control sobre archivos confidenciales que se sabe que han sido modificados:
Comprobar defines.inc.php => Aceptar
Comprobación de Dispatcher.php: archivo php modificado de la versión original => MIDOMINIOINFECTADO.com/classes/Dispatcher.php Ver
Comprobación de Hook.php: archivo php modificado de la versión original => MIDOMINIOINFECTADO.com/classes/Hook.php Ver
Control FrontController.php: archivo php modificado de la versión original => MIDOMINIOINFECTADO.com/classes/controller/FrontController.php VerComprobando Db.php => Aceptar 
Comprobando Module.php => Aceptar 
Comprobando alias.php => Aceptar 
Comprobando config.inc.php => Aceptar
Control IndexController.php: archivo php modificado de la versión original => MIDOMINIOINFECTADO.com/controllers/front/IndexController.php Ver
Comprobación de seguridad en los archivos php principales:
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/classes/Product.php Ver
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/classes/Store.php Ver
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/classes/Tools.php Ver
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/classes/controller/Controller.php Ver
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/classes/controller/ModuleFrontController.php Ver
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/classes/shop/Shop.php Ver
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/config/defines.inc.php VerArchivo MIDOMINIOINFECTADO.com/config/smarty.config.inc.php parcheado con éxito (inyección SQL posible por caché Smarty)
INTEGRIDAD MD5: archivo php modificado de la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/controllers/admin/AdminLoginController.php Ver
Encontrar archivos php agregados:
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/app/config/parameters.php Ver
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/config/settings.inc.php Ver
Archivo php inexistente en la versión original. Contenido para controlar => MIDOMINIOINFECTADO.com/override/controllers/front/AuthController.php Ver
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/override/modules/contactform/contactform.php Ver
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/zinfo.php Ver
Búsqueda de vulnerabilidades en los módulos (para información, si se conoce el módulo no hay riesgo a priori):
Función sensible para verificar: file_put_contents => MIDOMINIOINFECTADO.com/modules/redsysoficial/apiRedsys/redsysLibrary.php Ver
Función sensible a controlar: file_put_contents => MIDOMINIOINFECTADO.com/modules/revsliderprestashop/include/filemanager/ajax_calls.php Ver
Función sensible a controlar: file_put_contents => MIDOMINIOINFECTADO.com/modules/revsliderprestashop/include/filemanager/execute.php Ver
Función sensible a controlar: move_uploaded_file => MIDOMINIOINFECTADO.com/modules/revsliderprestashop/include/filemanager/upload.php Ver
Función sensible para verificar: file_put_contents => MIDOMINIOINFECTADO.com/modules/stripe_official/vendor/stripe/stripe-php/build.php Ver
ANÁLISIS COMPLETO
 

Y he sustituido el fichero AdminLoginController.php que era el que evitaba que accediese.
Ya puedo acceder pero veo que hay ficheros que han sido modificados,
¿Sabeis si puedo modificar todos estos ficheros con los originales de su versión original sin riesgo de perder algo?
GRACIAS A TODOS

[Nacho..]

**He restablecido estos ficheros que me indicaba PS que habían sido modificados:
classes/Product.php

classes/Store.php

classes/Dispatcher.php

classes/Hook.php

classes/Tools.php

classes/controller/ModuleFrontController.php

classes/controller/Controller.php

classes/controller/FrontController.php

classes/shop/Shop.php

config/defines.inc.php

controllers/front/IndexController.php
**Pero estos no sé si debo de restablecerlo??:
MIDOMINIOINFECTADO.com/config/smarty.config.inc.php parcheado con éxito (inyección SQL posible por caché Smarty)

**Y estos que han sido agregados no se si los puedo eliminar??
Encontrar archivos php agregados:
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/app/config/parameters.php Ver
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/config/settings.inc.php Ver
Archivo php inexistente en la versión original. Contenido para controlar => MIDOMINIOINFECTADO.com/override/controllers/front/AuthController.php Ver
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/override/modules/contactform/contactform.php Ver
Archivo php inexistente en la versión original. Contenido a controlar => MIDOMINIOINFECTADO.com/zinfo.php Ver
**Y ya por último sería esto:
Búsqueda de vulnerabilidades en los módulos (para información, si se conoce el módulo no hay riesgo a priori):
Función sensible para verificar: file_put_contents => MIDOMINIOINFECTADO.com/modules/redsysoficial/apiRedsys/redsysLibrary.php Ver
Función sensible a controlar: file_put_contents => MIDOMINIOINFECTADO.com/modules/revsliderprestashop/include/filemanager/ajax_calls.php Ver
Función sensible a controlar: file_put_contents => MIDOMINIOINFECTADO.com/modules/revsliderprestashop/include/filemanager/execute.php Ver
Función sensible a controlar: move_uploaded_file => MIDOMINIOINFECTADO.com/modules/revsliderprestashop/include/filemanager/upload.php Ver
Función sensible para verificar: file_put_contents => MIDOMINIOINFECTADO.com/modules/stripe_official/vendor/stripe/stripe-php/build.php Ver

5 hours ago, ExpertoPrestaShop said:

Intenta resetear la contraseña del backoffice (en caso de que te la hubieran cambiado): https://youtu.be/KwjT8EMqiik

Luego desde el backoffice menu Parámetros Avanzados -> Información ->  Listado de archivos modificados podrás ver el listado de archivos modificados. Si los restauras al menos deberías poder recuperar el funcionamiento de la tienda.

Luego deber intentar ver por donde entraron, probablemente algún modulo obsoleto, revisando los access_logs de la tienda y intentar parchear el problema para que no se vuelvan a meter.

Suerte!!

 

**He revisado los registros Logs desde Parámetros avanzados->Registros/Logs y en la fecha que previsiblemnete lo hackearon no aparece nada raro.
¿Como podría saber por donde han entrado? 


Gracias a todos por vuestra efectiva ayuda

Edited April 3, 2023 by Nacho.. (see edit history)

[joseantgv]

Ejecuta este script igualmente:

 

[Nacho..]

10 minutes ago, joseantgv said:

Ejecuta este script igualmente:

 

Siii, muchas gracias, ha sido de gran ayuda.
Parece que todo está ok.
Con vuestros consejos, todo ha vuelto a su normalidad.
GRACIAS

 

[delefant]

Hola

Yo he tenido este problema (exactamente mismos archivos infectados) en varios sitios webs que gestiono.

Aun pasando el script de nettoyage y haciendo limpia, se me siguen infectando.

Lo único que comparten las webs en común (a priori) es que utilizan el módulo de Redsys para pagos online y la plantilla Warehouse.

¿Puedes decirme si tú pudiste eliminar el hack del todo? No tengo claro donde está la brecha, he actualizado todos los plugins de la web.

Muchas gracias

[gusman126]

Hay que pasar el script, limpiar, cambiar contraseñas , todas, y actualizar PS a 1.7.8.9 y todos los módulos.

Importante cambiar contraseñas de servidor, FTP , usuario etc.

[Nickz]

23 minutes ago, delefant said:

Aun pasando el script de nettoyage y haciendo limpia, se me siguen infectando.

Rehacer la tienda y ver quien te infectó por access.log. Que hosting tienes?

[delefant]

12 hours ago, gusman126 said:

Hay que pasar el script, limpiar, cambiar contraseñas , todas, y actualizar PS a 1.7.8.9 y todos los módulos.

Importante cambiar contraseñas de servidor, FTP , usuario etc.

Hola. En su momento cambié contraseñas pero estas últimas veces la verdad que no lo he hecho. ¿Es posible que obtengan las contraseñas del servidor? Pensaba que solo sería posible de Prestashop al intentar hacer login.

12 hours ago, Nickz said:

Rehacer la tienda y ver quien te infectó por access.log. Que hosting tienes?

He consultado el access.log pero veo muchos accesos "normales" a imágenes y recursos de la web. ¿Puedes darme una indicación de qué patrón buscar exactamente?

El hosting es un Plesk con Ubuntu y otro con CentOS.

 

Saludos

[Hue2]

On 5/22/2023 at 8:03 PM, delefant said:

Hola

Yo he tenido este problema (exactamente mismos archivos infectados) en varios sitios webs que gestiono.

Aun pasando el script de nettoyage y haciendo limpia, se me siguen infectando.

Lo único que comparten las webs en común (a priori) es que utilizan el módulo de Redsys para pagos online y la plantilla Warehouse.

¿Puedes decirme si tú pudiste eliminar el hack del todo? No tengo claro donde está la brecha, he actualizado todos los plugins de la web.

Muchas gracias

Hola,

Repasando el hilo esta claro que es un ataque XSS, en resumen de inyección de archivos. Encontrar el agujero puede ser un poco laborioso si no se sabe que se busca. Trataré de resumir para no complicarnos. Es cierto que mediante lo logs de acceso puedes intuir o averiguar como inyectan ficheros.

1. Para empezar, estaría bien que tuvieras una estimación de cuando se realizo el ataque, a veces puedes precisarlo por la fecha de modificación de ficheros, pero no siempre funciona.
2. Una vez ya sabes a que hora ha sido modificado aproximadamente, filtra las lineas, adquiriendo solo las que tengan la petición POST ya que están inyectando y no recuperando(de momento).
3. Es posible que encuentres peticiones que accedan a sitios que no existan o que no tengan coherencia, es habitual encontrarte peticiones que están buscando vulnerabilidades genéricas, como la ya conocida de PHPUnit. Pero filtra por las que han tenido éxito, es decir los que reciben código 200. 
4. Un ejemplo que he encontrado en varios entornos atacados se representaba así: (Dirección IP) (hora) POST /b2b.php HTTP/1.1" 200 63 "-" (user-agent) Este seria un ejemplo de éxito, sin embargo el fichero b2b.php en este caso no lo vas a encontrar ya que normalmente una vez realizada la acción, suelen ser eliminados para que no sepas que hicieron.
5. Una vez localizado el ataque, comprueba que peticiones se hicieron con éxito justo antes, normalmente serán peticiones a ficheros que contengan ajax o permitan subida de ficheros de alguna forma u otra.

6. En mi caso suelo comprobar el estado de la máquina buscando otros tipos de ataques, por ejemplo en algún caso trataban de acceder al panel del servidor o al puerto de base de datos.

También existen herramientas que puedes usar para realizarte tareas de pentesting para comprobar la seguridad de tu aplicación.

Suerte

[delefant]

On 6/14/2023 at 5:48 PM, Hue2 said:

Hola,

Repasando el hilo esta claro que es un ataque XSS, en resumen de inyección de archivos. Encontrar el agujero puede ser un poco laborioso si no se sabe que se busca. Trataré de resumir para no complicarnos. Es cierto que mediante lo logs de acceso puedes intuir o averiguar como inyectan ficheros.

1. Para empezar, estaría bien que tuvieras una estimación de cuando se realizo el ataque, a veces puedes precisarlo por la fecha de modificación de ficheros, pero no siempre funciona.
2. Una vez ya sabes a que hora ha sido modificado aproximadamente, filtra las lineas, adquiriendo solo las que tengan la petición POST ya que están inyectando y no recuperando(de momento).
3. Es posible que encuentres peticiones que accedan a sitios que no existan o que no tengan coherencia, es habitual encontrarte peticiones que están buscando vulnerabilidades genéricas, como la ya conocida de PHPUnit. Pero filtra por las que han tenido éxito, es decir los que reciben código 200. 
4. Un ejemplo que he encontrado en varios entornos atacados se representaba así: (Dirección IP) (hora) POST /b2b.php HTTP/1.1" 200 63 "-" (user-agent) Este seria un ejemplo de éxito, sin embargo el fichero b2b.php en este caso no lo vas a encontrar ya que normalmente una vez realizada la acción, suelen ser eliminados para que no sepas que hicieron.
5. Una vez localizado el ataque, comprueba que peticiones se hicieron con éxito justo antes, normalmente serán peticiones a ficheros que contengan ajax o permitan subida de ficheros de alguna forma u otra.

6. En mi caso suelo comprobar el estado de la máquina buscando otros tipos de ataques, por ejemplo en algún caso trataban de acceder al panel del servidor o al puerto de base de datos.

También existen herramientas que puedes usar para realizarte tareas de pentesting para comprobar la seguridad de tu aplicación.

Suerte

Muchas gracias por los consejos, los tendré en cuenta.

Por ahora he dejado de tener las infecciones pero hice los mismos pasos que otras veces...

Un saludo