La tienda en línea fue hackeada, reparada pero aún está bajo ataque. ¿Qué hacer?

5

una tienda en línea basada en xt-commerce de un amigo mío fue hackeada recientemente. El atacante envió por correo electrónico que la tienda es vulnerable, mostró los datos extraídos (básicamente, abandonó las bases de datos y descifró los hashes md5, que no estaban salados) y pidió algunos bitcoins.

Mi amigo contrató a una compañía de seguridad, que realizó un escaneo de la aplicación web (bastante mal) utilizando el escáner web Accunetix. La salida fue casi ilegible, ya que contenía casi un 98% de falsos positivos (distribuidos en unas 40-50 páginas pdf). Así que me pidió que realizara un segundo análisis y encontré 4-5 inyecciones de SQL y algunos XSS, una versión obsoleta de Apache, así como PHP y MySQL. Las inyecciones de SQL fueron parcheadas y verifiqué los parches, ya que ya no pude realizar ningún SQLi.

Ahora, los usuarios de la tienda fueron informados sobre el incumplimiento y se les pidió que cambiaran su contraseña. Sin embargo, hace algunas horas, el hacker logró realizar un pedido falso en xt-commerce.

Me pregunto qué podrían hacer ahora los dueños de la tienda.

  1. El no habilitó el registro de MySQL ya que esto llenaría la memoria rápidamente.
  2. Les pedí que inspeccionaran los registros de Apache para ver qué sucedió en el momento en que se realizó el pedido falso.
  3. Les pedí que buscaran PHP / Web-Shells, que podrían haber sido colocados en el servidor web.
  4. Me pregunto si es posible analizar de alguna manera el contenido de la base de datos para detectar anomalías.
  5. Por supuesto, existe la posibilidad de seguir teniendo agujeros de seguridad en la aplicación web.
  6. Si el atacante elige explotar el servidor web, php-daemon o el servidor mysql, tendríamos dificultades para rastrear esto, ¿verdad? ¿Deberíamos así activar el registro del sistema de archivos?

¿Podrías sugerirme qué otros pasos tomar o quizás simplemente decirme tu instinto sobre esta situación?

    
pregunta Richard Laurant 04.09.2014 - 11:38
fuente

5 respuestas

3

En términos generales, debe seguir los siguientes pasos:

Asegure su sitio y recupere el acceso

  • Bloquee el sitio e impida todo acceso externo. Intente evitar la "contaminación" en el proceso modificando los archivos potencialmente comprometidos

  • Si necesita conservar una presencia en línea, configure algo como una página de destino separada alojada en una cuenta / servidor aislado. Sin embargo, no puede dejar su sitio en funcionamiento cuando sabe que es vulnerable, especialmente si se trata de un sitio de comercio electrónico. Usted se estaría abriendo a una responsabilidad legal sustancial por posibles pérdidas si lo hiciera.

  • Cambie todas sus contraseñas y trabaje con los proveedores de servicios si perdió el acceso a alguna de sus cuentas.

Identificar puertas traseras

  • Descargue una copia completa de su sitio.

  • Use una herramienta Diff como WinMerge para comparar los archivos descargados con su copia de seguridad más reciente y una copia nueva del software de su carrito (en la versión que está ejecutando).

  • Inspeccione cada variación que encuentre, registre cualquier variación que encuentre antes de revertirla. Mantener un registro le permite buscar instancias recurrentes en el futuro.

  • Pruebe y busque datos maliciosos en su base de datos. No hay una manera fácil de hacer esto, en particular, buscar nuevos usuarios y buscar cosas como "exec" (la función PHP para ejecutar código desde una cadena) en cosas como plantillas que pueden estar almacenadas en la base de datos. Usa lo que encuentres como pistas para lo que debes buscar. La comparación con las copias de seguridad también puede ser útil, especialmente para tablas que no cambian mucho.

  • Si puede simplemente tirar su base de código y comenzar con un conjunto de archivos nuevos (es decir, desde un paquete recién descargado desde el software de su carrito), considere esto seriamente.

Resolver vulnerabilidades

  • Asegúrese de que está ejecutando la última versión absoluta de cualquier software de carrito que esté usando. Si su carrito ya no se mantiene, considere cambiarlo.
  • Verifique cualquier otra fuente de código, como complementos de terceros. Elimine cualquiera que no sea absolutamente necesario, no se mantenga activamente o no tenga una reputación sólida.
  • Si tiene alguna pista de cosas como los registros, entonces investigue.

Restaurando el sitio y la prevención

  • Una vez que esté seguro de que se eliminaron las puertas de atrás y se resolvieron las vulnerabilidades, podrá restaurar el acceso.
  

El no habilitó el registro de MySQL ya que esto llenaría la memoria rápidamente. yo   les pidió que inspeccionaran los registros de Apache para ver qué sucedió durante el   Momento en el que se realizó el pedido falso.

Considere seriamente el registro externo. Las opciones como S3 y Glacier de AWS son ridículamente baratas y pueden garantizar que sus registros no se vean comprometidos en un ataque futuro.

  • Considere implementar un Firewall de aplicaciones web, como CloudFlare. No confíe en esto para resolver sus vulnerabilidades actuales, es solo una primera línea de defensa.

  • Mejore el aislamiento cuando sea posible, por ejemplo, si su sitio consta de un carrito y un blog, asegúrese de que ambos estén alojados como usuarios / cuentas independientes o, idealmente, servidores separados.

  • Asegúrese de que su software esté actualizado, tenga contraseñas seguras, etc.

  • Considere implementar chequeos de integridad de archivos de rutina. Algún software tiene esto incorporado, donde básicamente puede comparar las sumas de comprobación de los archivos contra las sumas de comprobación de archivos limpios para que se le notifique si un archivo se modifica inesperadamente.

  • Revise sus permisos de archivo, asegúrese de que el proceso web no pueda escribir en ninguno de sus archivos de código (y puede escribir en un mínimo absoluto de otros archivos en general).

respondido por el thexacre 04.09.2014 - 14:47
fuente
5

Haría algunas cosas más para limpiar el sitio:

  1. Cambiar cada contraseña

    Sí, antes de hacer nada, cambie todas las contraseñas de administrador, ftp, ssh, MySQL y demás.

  2. Mover todos los archivos del sitio web a una carpeta inaccesible

    Desconecte el sitio y ponga el signo En mantenimiento para que tenga tiempo de arreglarlo todo. Esto deshabilitará cualquier archivo modificado del atacante. Los depósitos también serán inutilizables.

  3. Reinstalar xt-commerce desde cero

    Parchar el xt-commerce actual no es suficiente. Hay muchos lugares para colocar una puerta trasera, y es fácil pasarla por alto incluso con un examen muy cuidadoso. Si hay temas personalizados o complementos instalados, vuelva a instalar desde cero. Intente no copiar ninguno de los recursos del sitio anterior, trátelos como infectados . No intentes arreglar ninguna infección, crea desde cero.

  4. Parche el nuevo xt-commerce para usar un mejor almacenamiento de contraseña

    Si el almacenamiento de contraseña predeterminado de xt-commerce no implementa salting, algo está muy mal. Se requiere el uso de salazón para cada gestión de contraseñas desde el lanzamiento de Intel Pentium MMX. O incluso antes.

  5. Tome un volcado completo de la base de datos e inspecciónelo para detectar signos de anomalías

    Cualquier signo de eval , replace , decode , exec o system será sospechoso. Eche un vistazo de cerca a esas entradas.

  6. Mira si hay alguna cuenta extraña creada

    Con el volcado de la base de datos en la mano, vea si alguna cuenta tiene más privilegios de los que debería tener. Tal vez el atacante creó una cuenta de administrador disfrazada.

  7. Inspeccionar los archivos de registro

    Esto le mostrará cómo el atacante obtuvo acceso al sitio. Como algunos shells PHP pueden usar POST, encabezados personalizados y cookies para enviar y recibir datos, la configuración predeterminada del registro de Apache no puede mostrar todo. Agregue la directiva %{Set-Cookie}o a la configuración para registrar cookies y registrar datos POST también.

respondido por el ThoriumBR 04.09.2014 - 14:31
fuente
1

Mi instinto es que no sabes cuánto tiempo hace que te hackearon.

Al parchear el sitio y combinar vulnerabilidades conocidas, básicamente esperas que el hacker no sepa lo que está haciendo.

Lo primero que hizo el hacker fue eliminar los registros e instalar varias puertas traseras. Incluso si instala un parche en el sistema de manera adecuada, incluso si elimina cualquier vulnerabilidad, es posible que existan puertas traseras salientes, cuentas administrativas adicionales, etc. Estas pueden ser de nivel de kernel y no ser detectables sin apagar y escanear los medios al montar el volumen externamente una máquina bien conocida.

Si puede averiguar cuándo ocurrió la infracción, puede restaurar desde copias de seguridad anteriores, parchear los sistemas y posiblemente restaurar datos más recientes.

Si no puede descubrir cuándo ocurrió la violación, elimine a la compañía. Reconstruye un segundo sitio web, introduce los datos antiguos y peina las listas de usuarios cuidadosamente. Si te piratean de nuevo, siempre puedes repetir este proceso, activar más registros, profundizar en tus datos, etc., es rápido reconstruir una segunda o tercera vez.

Es muy importante recordar: No traiga ningún código o archivos binarios del sitio anterior. Estás reconstruyendo desde cero.

Si eso no es financieramente posible, y no conoces copias seguras de tu código, entonces estuviste desprovisto de buena suerte por un tiempo. Puede que tenga que pagar la extorsión o simplemente seguir golpeando el sitio y esperar que supere al pirata informático. Asegúrese de obtener una copia de seguridad completa. Y espero que no tengan el código establecido para causar daños en el apagado / inicio.

    
respondido por el mgjk 04.09.2014 - 14:47
fuente
0
  

"Sin embargo, hace algunas horas, el hacker logró colocar un pedido falso en   xt-commerce. "

Realizar un pedido falso no equivale a piratería. Me parece que eso es un uso normal del sitio. Si están iniciando sesión como administrador, ¿qué cuenta están usando? Cambia la contraseña. Si esto se debe al acceso a la cuenta de administrador, entonces no descarte el hecho de que el ataque pudo haber ocurrido debido a un software de keylogger. Por lo tanto, aparte de la infraestructura del sitio, es posible que desee buscar cualquier software malicioso que el usuario haya instalado. Por lo tanto, es posible que deba cambiar esas contraseñas inmediatamente y dejar de usar esa computadora en particular hasta que haya sido formateada o el problema haya sido resuelto o el software malicioso haya sido eliminado.

    
respondido por el pal4life 28.07.2015 - 19:49
fuente
-1

Puede escanear el sitio para encontrar si el hacker había puesto un poco de javascript usando la cuenta de administrador. ¡Si lo hizo, puede seguir robando cookies a los usuarios del sitio!

También debe cambiar todas las contraseñas, incluida la contraseña de MySQL y la contraseña de FTP.

    
respondido por el Abdel Adim smaury Oisfi 04.09.2014 - 14:06
fuente

Lea otras preguntas en las etiquetas