¿Qué hacer contra la última vulnerabilidad: datos de tarjetas de crédito robadas?


11

Después de que se publicó la noticia hace unos días, no he escuchado mucho, ni ninguna declaración oficial, sobre la vulnerabilidad más reciente. Sucuri dice que es posible recibir información de la tarjeta de crédito, o incluso todos los datos, $_POSTincluidas las contraseñas de administrador y similares.

Todavía no he tenido un caso en el que un cliente fue pirateado, pero no quiero esperar hasta que esto suceda para tomar medidas. ¿Alguien ha visto un parche todavía?


Dado el último artículo de Sucuri, también podría estar interesado en las respuestas de @Ben Lessani (Sonassi) aquí: magento.stackexchange.com/a/72697/231
Anna Völkl

Respuestas:


8

¿Qué tipo de parche o declaración oficial esperas? La publicación del blog solo dice que una aplicación web puede verse comprometida una vez que el atacante tiene acceso al código. Eso se aplica a todas y cada una de las aplicaciones web. El término Magento es completamente intercambiable allí. Actualmente, no tienen idea de cómo se vio comprometido el host afectado. La puerta abierta en los ejemplos dados podría ser todo, desde problemas de servidor hasta "capa 8".

Siempre y cuando se mantengan tan vagos y no encuentren información valiosa, todo se trata de marketing como difundir el nombre de su empresa, hacer olas, posicionarse como expertos en seguridad, etc. Combinar palabras de moda como "robar" "tarjeta de crédito" " Magento "hace una buena historia obviamente.

Lo que aún podemos aprender de esta publicación:

  • Observe regularmente su base de código para detectar cambios inesperados.
  • Deje el manejo de los datos de pago a un PSP.

Actualización: Hay una declaración oficial de Ben Marks ahora.


Sí, sé que la fuente es bastante inespecífica. Tampoco sé si se han contactado con Magento / eBay por este problema. De todos modos, todavía es posible (y ha sucedido dos veces en los últimos meses) que sea un error central, y hubiera esperado al menos una declaración como "estamos investigando" o "no es nuestra culpa, algún módulo".
simonthesorcerer

Estoy de acuerdo en que la causa básica también puede ser una de las miles de extensiones disponibles o cualquier versión de Magento (sin parches). Todavía muy poca información para tomar medidas específicas en mi humilde opinión.
mam08ixo

3

Mientras su versión de Magento esté actualizada, ha instalado todos los parches más recientes y su servidor cumple con las mejores prácticas con respecto a la configuración (permisos de archivos, no otro software / sitio web en ejecución, firewall, etc.) esto es todo lo que puede hacer por ahora .

Creo que es importante mencionar que todavía no hay un vector de ataque específico:

Entonces, ¿cómo funciona el ataque? Todavía estamos investigando los vectores de ataque. Sin embargo, parece que el atacante está explotando una vulnerabilidad en el núcleo de Magento o algún módulo / extensión ampliamente utilizado.

Editar:

Como se mencionó en mi comentario anterior, también puede consultar la respuesta detallada de Ben Lessani a otra pregunta relacionada que proporciona información básica: /magento//a/72697/231


2

No (solo) Magento

He visto muchos otros sitios web pirateados de esta manera, insertando código malicioso en la base de código, y no solo en Magento. Y hay muchas variantes: scripts que roban datos POST, scripts que agregan XSS, scripts que intentan robar contraseñas raíz, scripts que permiten que las llamadas entrantes procesen datos (para minería de Bitcoin, para enviar correos electrónicos no deseados desde ese servidor), etc.

En algunos casos, la causa fue el robo de credenciales FTP (por virus / malware) de una computadora cliente; en otros casos, utilizó un exploit en la aplicación.

Hay muchas otras aplicaciones que pueden proporcionar acceso al servidor a través de exploits, por ejemplo WordPress.

Solo hay un caso en el que Magento tendría la culpa y es de esperar una acción de Magento y es: si la aplicación explotada fuera Magento de la última versión y esté completamente parcheada.

Entonces, hay una pequeña posibilidad de que este caso destacado haya sido causado por una falla en Magento en primer lugar. Por eso no escuchas nada de Magento.

Lo nuevo aquí es que el código insertado está dirigido específicamente a Magento y utiliza la arquitectura y los principios del código de Magento.

Qué hacer

Ahora para dar una respuesta a su pregunta "¿Qué hacer contra ella?"

  • Nunca ejecute dos aplicaciones diferentes en la misma instancia del servidor,
    como WordPress + Magento. En algún momento ves WordPress ejecutándose como en www.magentoshop.com/blog/ o Magento ejecutándose en www.wordpresswebsite.com/shop/. No hagas eso. Las vulnerabilidades en WordPress pueden dar al atacante acceso a sus datos de Magento.

  • Use un sistema de control de versiones
    Estoy usando GIT y también tengo esto en el servidor (acceso de solo lectura) para implementar el sitio web. Esto también me da una idea rápida de los cambios en el sistema mediante la ejecución git status.

  • Nunca use FTP, solo SFTP, nunca almacene contraseñas
    . Mencioné anteriormente que las contraseñas FTP fueron robadas de una computadora cliente. Además, el uso de FTP no es seguro, ya que enviará datos sin cifrar a través de Internet. Así que use SFTP y nunca almacene sus contraseñas en su aplicación FTP, simplemente no sea flojo y escríbalas cada vez que se conecte a su servidor.


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.