Filtración en la tienda oficial de Good Smile Company (datos completos de tarjeta de 2.800 personas posiblemente filtrados, datos parciales de 402.466 tarjetas, hasta 202 pedidos posiblemente vistos): qué debe hacer cada grupo

En el grupo B pudieron capturarse el nombre del titular, el número completo de 16 dígitos, la fecha de caducidad y el código de seguridad. La empresa pide revisar los extractos y contactar con el emisor que figura en el reverso de la tarjeta ante cualquier cargo que no reconozca. También aconseja considerar la reemisión.

Este sitio recomienda además preguntar a su emisor por el cambio de número aunque no haya aparecido ningún cargo fraudulento. El código de seguridad pudo filtrarse y esa combinación sigue siendo utilizable hasta que cambie el número. La reemisión la solicita usted mismo. La empresa dice que ha pedido a los emisores que no cobren comisiones por la reemisión a los usuarios; a 3 de noviembre, los emisores no han anunciado ningún resultado.

El grupo B incluye:

• Personas que hicieron un pedido con tarjeta en ese periodo (384 personas)
• Personas que cambiaron la tarjeta de pago tras una reserva en ese periodo (185 personas)
• Personas que intentaron pagar pero no lo completaron
• Personas que iniciaron sesión y añadieron artículos al carrito pero no pasaron al pago (la empresa cree que en su caso no se filtró nada, pero las incluye en sus avisos)

La empresa dice que no tiene registros que distingan a quienes intentaron pagar de quienes solo usaron el carrito. Dice también que quienes intentaron cambiar la tarjeta tras hacer el pedido y no lo completaron pueden haber sufrido una filtración, pero no puede identificarlos. Si es su caso, lea las notas del aviso oficial de soporte de la empresa.

El grupo A es cualquiera que haya registrado alguna vez datos de tarjeta en la tienda oficial. Solo se filtraron los últimos cuatro dígitos del número de tarjeta y la fecha de caducidad. La empresa dice que el nombre del titular y el código de seguridad no se filtraron, y que no se filtraron datos de socios vinculados. Considera extremadamente improbable un uso indebido solo con esto.

El número de personas aún se está comprobando, así que no se han enviado correos individuales. No recibir un correo no significa estar fuera del alcance. Si recuerda haber registrado una tarjeta en la tienda oficial, revise sus extractos y contacte con el emisor ante cualquier cargo que no reconozca.

Los datos del grupo C son el nombre de entrega y de facturación, la dirección, el teléfono, el correo electrónico, el contenido del pedido, el importe y el tipo de método de pago. No incluyen datos de tarjeta ni de cuentas bancarias. El método de pago da igual: quienes pagaron con PayPal o Amazon Pay también pueden estar dentro del alcance si el pedido no se había enviado.

La empresa dice que como máximo 202 de los 7.774 pedidos (realizados por 5.356 personas) pueden haberse visto realmente, pero no puede saber cuáles, así que envió correo a las 5.356 personas. Desde fuera no se puede saber si el suyo se vio. Como un mensaje podría citar su dirección y su pedido reales, siga la precaución del paso siguiente.

La empresa pide no responder a correos, llamadas o mensajes de texto sospechosos que digan proceder de la empresa, de organismos públicos o de entidades financieras, y no hacer clic en sus enlaces. No son ejemplos dados por la empresa; como suposición propia de este sitio, son plausibles mensajes sobre un trámite de disculpas, volver a registrar la tarjeta o el reembolso de comisiones de reemisión. Considere falso cualquier mensaje que pida datos de tarjeta o contraseñas y compruébelo a través de un sitio oficial que abra usted mismo (cómo distinguirlos: ¿Qué es el phishing?).

Para comprobar si un correo es auténtico, no use sus enlaces. Vaya en su lugar a los avisos oficiales de soporte de la empresa.

La empresa dice que su tienda en Rakuten Ichiba está fuera del alcance porque funciona con un sistema aparte. Dice que no se ha confirmado ninguna filtración de datos de pago de PayPal ni de Amazon Pay. Los datos de pedidos sin enviar aún pueden entrar en el grupo C. Las consultas se hacen mediante el formulario de atención al cliente de la empresa, que funciona con un sistema aparte.

Según la empresa, el acceso no autorizado salió a la luz el 23 de octubre y el programa de la página de pago se encontró el 28 de octubre. La manipulación de la página de pago se descubrió por separado, después de confirmarse que se habían visto datos de clientes. No lo lea como señal de una respuesta lenta; léalo como un ejemplo de que la visualización de datos y la manipulación de la página de pago pueden ocurrir por separado.

En un sitio donde se obtuvieron privilegios de administrador, mientras investiga qué se vio, saque también una lista de los scripts que carga la página de pago y compárela con la lista prevista. Si no tiene una lista prevista, guarde la de hoy y compare a partir de mañana.

La empresa publicó el informe de su contratista según el cual la vulnerabilidad que se cree causa del incidente no es la vulnerabilidad de PHP notificada recientemente. Parchear la vulnerabilidad de la que todos hablan y dar la causa por cerrada deja abiertas otras entradas. Hasta que los registros muestren cómo se obtuvieron los privilegios de administrador, siga comprobando como si quedaran otras entradas.

La respuesta de la empresa incluyó invalidar y renovar todas las credenciales entre sistemas. Cuando se obtienen privilegios de administrador, hay que sustituir no solo las cuentas de administración del sitio, sino también las claves y contraseñas que conectan con el procesador de pagos, la base de datos y servicios externos. Sin una lista de qué credenciales existen y dónde, se pasan por alto algunas. Empiece hoy haciendo esa lista. Si externaliza el desarrollo o la operación, pregunte si el contratista puede proporcionarla (esto incluye comprobar que no queda ninguna puerta trasera).