¿Cómo puedo saber si se está utilizando un archivo de imagen corrupto para el roce de tarjetas de crédito?

17

Estoy trabajando con un sitio que creo que ha sido pirateado para recopilar datos de tarjetas de crédito de clientes, pero no puedo estar seguro.

Yo no encuentro ningún código sospechoso en los lugares comunes que he visto se sugiere en varios artículos.

Me hice encontrar un sospechoso "roto" archivo de imagen en:

/skin/adminhtml/default/default/images/db-tab-bottom-right-bg_bg.gif

Cambié la extensión del archivo y la abrí, pero es solo una pared de texto cifrado con JPEG-1.1dispersos.

¿Cómo puedo saber si el sitio está comprometido?

He confirmado que el parche se ha aplicado, pero el hack podría haber ocurrido antes del parche.

EDITAR: la versión afectada es 1.7.0.2

travisw
fuente

Respuestas:

21

Para ver la respuesta específica a su pregunta, consulte /magento//a/72700/361

Antecedentes

En primer lugar, no hay una vulnerabilidad específica : hay una serie de artículos que circulan en este momento que no han leído ni entendido el artículo original.

El artículo original simplemente decía (y estoy parafraseando),

Si un hacker eran capaces de obtener acceso a sus archivos de Magento, que podrían capturar la información de su cliente

La parte clave es que el hacker necesita acceder a su servidor y modificar los archivos.


No se asuste ... esto no es nada específico de Magento

En términos de captura de información, no hay nada específico para Magento que cualquier otro sitio web / plataforma. Si un pirata informático obtiene acceso a sus archivos, se termina el juego de manera efectiva: podría capturar la información que quisiera.

Lo mejor que puede hacer (y, en última instancia, lo mínimo que debe hacer) es mantener una buena política de seguridad que cumpla con los Estándares de Seguridad PCI de la industria de procesamiento de pagos, puede encontrar la lista aquí, https://www.pcisecuritystandards.org /documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf


Endurece tu tienda

Realmente puede bloquear las facetas de su tienda que reducen en gran medida el área de ataque de superficie para un pirata informático, o al menos, retrasan su progreso si logran entrar /

Bloquear permisos

Puede restringir los permisos en la raíz del documento para permitir solo la escritura en directorios esenciales ( /vary /media)

Esto es lo que hacemos por defecto en MageStack ,

echo -n "Fixing ownership"
chown -R $SSH_USER:$WEB_GROUP $INSTALL_PATH && echo " ... OK" || echo " ... ERROR"
INSTALL_PATH="/path/to/public_html"
chmod 750 $INSTALL_PATH
find $INSTALL_PATH -type d ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing file permissions"
find $INSTALL_PATH -type f ! -perm 740 -exec chmod 740 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing cron permissions"
find $INSTALL_PATH/*/cron.sh -type f ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var file permissions"
chmod -R 760 $INSTALL_PATH/*/media $INSTALL_PATH/*/var && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var directory permissions"
find $INSTALL_PATH/*/media $INSTALL_PATH/*/var -type d ! -perm 770 -exec chmod 770 {} \; && echo " ... OK" || echo " ... ERROR"

Ajustar INSTALL_PATH,SSH_USER,WEB_GROUPa la medida. Lo importante es que SSH_USERno es el mismo usuario que PHP usa para el proceso del servidor web, de lo contrario, esencialmente estaría proporcionando acceso de escritura completo al servidor web (mitigando cualquier beneficio).

Bloquee su acceso de administrador / descargador

En MageStack, configuraría esto en ___general/x.conf

set $magestack_protect_admin true;
set $magestack_protect_downloader true;

En Nginx, puedes usar esto,

location ~* ^/(index.php/)?admin{
  satisfy any;

  allow x.x.x.x;

  auth_basic "Login";
  auth_basic_user_file /microcloud/data/domains/x/domains/x/___general/.htpasswd;

  deny all;

  location ~* \.(php) {
    include fastcgi_params;
  }
  try_files $uri $uri/ /admin/index.php ;
}

Hay un poco más de documentación sobre cómo preparar un .htpasswdarchivo aquí

Envuelva el cron.shproceso

Me he encontrado con otros proveedores de alojamiento que usan máquinas dedicadas para el uso de cron / admin, lo que significa que modificar el cron.sharchivo permitiría la ejecución remota de código en el cron / admin sin necesidad de acceder a él. Terminar el proceso con el usuario correcto en un fakechroot puede ir un poco más allá para bloquear el proceso.

Hay demasiado código para publicar, pero hay un script aquí . Es específico de MageStack, pero podría ajustarse para su uso en configuraciones de servidor menos elegantes :)

Auditoria, auditoria, auditoria

Linux es fantástico en términos de inicio de sesión y aprovechar eso le dará una visión completa de lo que está haciendo su servidor.

Una característica fantástica en MageStack es la herramienta de auditoría que registra todos los tipos de acceso e incluso los cambios de archivos a diario. Puedes encontrar los registros aquí,

/microcloud/logs_ro
|-dh[0-9]+
|---access-YYYY-MM-DD.log.gz
|---backup-YYYY-MM-DD.log.gz
|---magescan-YYYY-MM-DD.log.gz
|---php-differential-YYYY-MM-DD.log.gz
|-acc[0-9]+
|---access-YYYY-MM-DD.log.gz

Si no está utilizando MageStack, puede replicar algo de esto con su propio proveedor de alojamiento con bastante facilidad, rsyncsiendo la herramienta más simple para hacerlo.

P.ej. Si sus copias de seguridad están disponibles localmente, puede hacer lo siguiente. Esto ejecutará en seco comparar dos directorios y producir una lista de parches diff.

rsync -na /path/to/public_html/ /path/to/backup/public_html/ > change.log
grep -E '\.php$' change.log | while read FILE; do
  diff -wp /path/to/public_html/$FILE /path/to/backup/public_html/$FILE >> php-differential.log
done

Los cambios en PHP son tan poco frecuentes que puede programar que se ejecuten diariamente (o varias veces al día) y notificarle por correo electrónico si hay un cambio en el archivo PHP.


En resumen

  • Use el control de versiones, es más fácil rastrear cambios
  • Solo tener un certificado SSL no es suficiente para que su sitio sea seguro
  • No esperes a ser hackeado para considerar la seguridad
  • El hecho de que redirija a su proveedor de pasarela de pago (en lugar de capturar información) no significa que pueda evitar el cumplimiento de PCI, aún debe cumplir
  • Sea proactivo, esté seguro y completo: verifique el código del módulo antes de instalarlo, revise los archivos PHP diariamente, revise los registros, verifique el acceso FTP / SSH, cambie las contraseñas regularmente

Sus clientes depositan una enorme cantidad de confianza en usted cuando pasan toda su información privada, y si traiciona esa confianza al no operar un negocio seguro, perderá su costumbre y toda la costumbre futura.

Las investigaciones forenses de PCI son increíblemente caras, requieren mucho tiempo y, en última instancia, arriesgan su capacidad de poder volver a aceptar pagos con tarjeta. ¡Nunca te dejes poner en esa posición!


Parchear

Magento lanzó recientemente una serie de parches que arreglaron agujeros, incluidos algunos que permitían la ejecución remota de código. Puede buscarlos aquí, https://www.magentocommerce.com/products/downloads/magento/

Pero estos nuevos artículos no se refieren a un nuevo exploit, simplemente indican cómo los hackers están aprovechando los exploits históricos (o cualquier otro vector de ataque) para poder capturar la información del titular de la tarjeta.


Fuentes

Ben Lessani - Sonassi
fuente
44
¡Gracias! Esta es una redacción sorprendente y mucha información muy útil.
Piotr Kaminski
9

Estoy agregando otra respuesta solo porque la otra en realidad no respondió la pregunta, ¡y ciertamente no necesita ser más!

¿Cómo puedo verificar si una imagen contiene información CC?

En definitiva, no puedes. A veces hay indicadores que lo hacen destacar,

P.ej.

  • Tamaño de archivo grande
  • Presencia de texto plano en el archivo
  • Encabezados de imagen incorrectos

Pero puede ser particularmente difícil digerir el contenido de los archivos binarios para determinar el contenido si el contenido no está simplemente en texto plano.

El más común que he visto explotar no implica la escritura de datos de texto sin formato a un archivo con una .jpg|png|gif|etcextensión, que por lo general implican algún tipo de codificación / cifrado para ocultar los datos (por ejemplo. base64, O mcryptetc.). Lo que significa que un grep simple no funcionará.

Podrías (y esto no es exhaustivo) ...

Encuentra archivos anormalmente grandes

find \
/path/to/public_html/skin \
/path/to/public_html/media \
-type f -size +20M 2>/dev/null

Buscar archivos que coincidan con CC regex

grep -lE '([0-9]+\-){3}[0-9]{4}|[0-9]{16}' \
/path/to/public_html/skin \
/path/to/public_html/media 2>/dev/null

Compruebe si los archivos de imagen son válidos

find \
/path/to/public_html/skin \
/path/to/public_html/media -type f \
-regextype posix-egrep -regex '.*\.(jpg|gif|png|jpeg)' |\
xargs identify 1>/dev/null

O

find \
/path/to/public_html/skin \
 -name '*' -exec file {} \; | grep -v -o -P '^.+: \w+ image'

¿Cómo puedo verificar los archivos PHP en mi instalación para ver si se ha modificado?

La forma más fácil de comparar sus archivos de instalación sería diferenciar el núcleo de una copia limpia. Esto no tendrá en cuenta sus archivos de tema, pero ayuda mucho a verificar algunos miles de archivos en su instalación.

El proceso es realmente fácil.

P.ej. Para Magento versión 1.7.0.2

wget sys.sonassi.com/mage-install.sh -O mage-install.sh
bash mage-install.sh -d -r 1.7.0.2
tar xvfz latest-magento.tar.gz
diff -w --brief -r magento-ce-*/app/code/core app/code/core
diff -w --brief -r magento-ce-*/lib lib

Tenga en cuenta que las versiones anteriores de Magento no están (molestamente) parcheadas, por lo que al hacer una diferencia de núcleo se mostrarán cambios. Para evitar esto, aplique los parches a la fuente limpia recién descargada, luego difunda nuevamente después.

Ben Lessani - Sonassi
fuente
2
Dadas ambas respuestas, esta parece relacionarse mejor con la pregunta.
pspahn
Ben, presioné enter antes de que pudiera terminar mi justificación para la edición que sugerí ... no es algo importante, solo que PCI es un estándar de la industria y no una regulación o ley aprobada por un organismo gubernamental, al menos no en los EE. UU .: en.wikipedia.org/wiki/…
Bryan 'BJ' Hoffpauir Jr.
1
Solo estaba usando "regulación" en el contexto de ser intercambiable con "regla" (no ley)
Ben Lessani - Sonassi
Aprecio la distinción y puede estar más basada en la configuración regional de lo que me di cuenta originalmente. Según mi padre, el abogado y la hermana, decana de la facultad de derecho (odio discutir con ellos, como se puede suponer) aquí en los EE. UU. Incluso la palabra regla tiene un significado específico cuando está precedido por un modificador específico, como la Regla de la industria como en este caso contra la regla de la agencia (donde una agencia gubernamental como la EPA puede emitir requisitos detallados que son legalmente vinculantes, como una ley, pero que no son aprobados como una regulación por nuestras cámaras del Congreso del Senado o la Cámara de Representantes). No quiero ser pedante, solo compartir :)
Bryan 'BJ' Hoffpauir Jr.
3

Gran publicación, pero desafortunadamente no todas las cosas son iguales.

Permisos de archivo

Cuando el alojamiento compartido se hizo popular, se consideró más importante que a las personas no se les permitiera ver el contenido de otros en el mismo servidor. Hasta la llegada de las cárceles de FreeBSD, esto significaba:

  • proyectiles restringidos
  • / home como root: root 700
  • Cuentas de usuario con umask 007.
  • UID que cambia el software del servidor web
  • Y el UID al que cambió, es el propietario de esa cuenta.

Esto permitió la modificación de los archivos HTML (entonces) por parte del propietario de la cuenta, mientras que al mismo tiempo, tanto el proceso del servidor web como el propietario de la cuenta no tenían acceso a otros en la misma máquina.

Esto no ha cambiado mucho y los paquetes de software que se adaptan al alojamiento compartido (CPanel, DirectAdmin, Plex) utilizan todos esos principios. Esto significa que el punto de entrada principal (servidor web y / o intérprete de guiones) puede escribir en cualquier archivo de la cuenta, haciendo que los permisos de archivo sean inútiles.

No hay CC para robar si no lo tienes

Informe a su proveedor de pagos de CC si los datos de CC realmente se envían a su servidor y, de ser así, si se envían sin cifrar sin cifrar. JavaScript es bastante poderoso en estos días y existen proveedores de servicios de pago que utilizan el motor JavScript de su cliente para cifrar información confidencial antes de la transmisión al servidor. Si bien es posible que este recolector de información obtenga la clave de sesión así como los datos cifrados (y así poder descifrarlos), es menos interesante para el recolector ya que los datos recopilados son más grandes y la IA del bot es mucho más compleja .

Detección de modificación

Más de 15 años de Unix y todavía pone una sonrisa nostálgica en mi rostro cuando veo reencarnaciones de TripWire . Es una buena herramienta para esto también. En comparación con una buena versión conocida, algo menos, ya que no tiene en cuenta las adiciones y nuevamente es una buena herramienta aquí, ya que las modificaciones locales del sitio son más frecuentes que las instalaciones impecables.

El descargador

Es tan fácil mover el descargador fuera de la raíz del documento como instalar alguna forma de autenticación HTTP. Luego solo vuelva a colocarlo cuando lo use. Si eso no es práctico, prefiero bloquearlo en función de la dirección remota en lugar de otra capa de usuario / contraseña, especialmente las que envían contraseñas en texto plano.

WAF y alternativas

Un firewall de aplicaciones web puede evitar muchos problemas, ya en la etapa de escaneo de un ataque. Desafortunadamente, estas son cajas negras caras, pero existen algunas alternativas:

  1. El que fue el compañero de Tripwire en el pasado, Snort, está a la altura de los WAF comerciales. Tiene una curva de aprendizaje empinada, pero puede detectar anomalías y patrones malos conocidos bastante bien.
  2. Naxsi para nginx y mod_security para Apache niegan las solicitudes que contienen firmas de ataque conocidas. Naxsi es un poco más genérico y niega el servicio de "cosas que no deberían pertenecer aquí", como SQL oculto, en contraste con parte de un bit conocido de SQL.
  3. Fail2ban / sshguard se sientan entre los dos anteriores. Pueden manejar diferentes tipos de registros y tienen acciones personalizables. La desventaja es que funcionan después del hecho. Las líneas de registro generalmente llegan al registro después de que se haya completado una acción y, además, las herramientas tienen un umbral para combatir los falsos positivos. Esto puede ser suficiente para que el atacante obtenga acceso, si obtuvo información precisa en etapas anteriores.

Creo que cubrimos muchas cosas, pero déjame terminar con mi petpeeve:


DEJA DE USAR FTP


Allí. Lo dije. Y aquí tienes: https://wiki.filezilla-project.org/Howto

Melvyn
fuente
1

No hay nada seguro sobre este nuevo truco, Ben Marks publicó ayer que están investigando el problema y también está este artículo.

El mejor enfoque que puede intentar es iniciar sesión a través de SSH y hacer una búsqueda dentro de todos los archivos que tiene para una determinada cadena, algo así como

find . | xargs grep 'db-tab-bottom-right-bg_bg.gif' -sl

de su carpeta raíz de Magento y si obtiene una coincidencia, revise manualmente el archivo para ver qué está sucediendo. Lo mismo con otras cadenas como "END PUBLIC KEY", por ejemplo.

mbalparda
fuente