Vazamento na loja oficial da Good Smile Company (dados completos de cartão de 2.800 pessoas possivelmente vazados, dados parciais de 402.466 cartões, até 202 pedidos possivelmente vistos): o que cada grupo deve fazer

No grupo B, podem ter sido capturados o nome do titular, o número completo de 16 dígitos, a data de validade e o código de segurança. A empresa pede que se confiram as faturas e que se contate o emissor indicado no verso do cartão em caso de qualquer cobrança não reconhecida. Também aconselha considerar a reemissão.

Este site recomenda ainda perguntar ao seu emissor sobre a troca do número mesmo que nenhuma cobrança fraudulenta tenha aparecido. O código de segurança pode ter vazado e essa combinação continua utilizável até o número mudar. Você mesmo solicita a reemissão. A empresa diz que pediu aos emissores que não cobrem taxas de reemissão dos usuários; até 3 de novembro, nenhum resultado foi anunciado pelos emissores.

O grupo B inclui:

• Pessoas que fizeram um pedido com cartão no período (384 pessoas)
• Pessoas que trocaram o cartão de pagamento depois de uma pré-venda no período (185 pessoas)
• Pessoas que tentaram pagar mas não concluíram
• Pessoas que entraram na conta e colocaram itens no carrinho mas não passaram ao pagamento (a empresa acredita que nada vazou nesses casos, mas as inclui em seus avisos)

A empresa diz que não tem registros que distingam quem tentou pagar de quem só usou o carrinho. Diz também que quem tentou trocar o cartão depois de fazer o pedido e não concluiu pode ter tido dados vazados, mas que não consegue identificá-los. Se for o seu caso, leia as observações no aviso oficial de suporte da empresa.

O grupo A é qualquer pessoa que já registrou dados de cartão na loja oficial. Vazaram apenas os quatro últimos dígitos do número do cartão e a data de validade. A empresa diz que o nome do titular e o código de segurança não vazaram, e que não vazaram dados de membros vinculados. Considera extremamente improvável o uso indevido apenas com isso.

O número de pessoas ainda está sendo verificado, por isso não foram enviados e-mails individuais. Não receber um e-mail não significa estar fora do escopo. Se você se lembra de ter registrado um cartão na loja oficial, confira as faturas e contate o emissor em caso de qualquer cobrança não reconhecida.

Os itens do grupo C são o nome de entrega e de cobrança, o endereço, o telefone, o e-mail, o conteúdo do pedido, o valor e o tipo de forma de pagamento. Dados de cartão e de conta bancária não estão incluídos. A forma de pagamento não importa: quem pagou com PayPal ou Amazon Pay também pode estar no escopo se o pedido não tinha sido enviado.

A empresa diz que no máximo 202 dos 7.774 pedidos (feitos por 5.356 pessoas) podem ter sido de fato vistos, mas não sabe dizer quais, então enviou e-mail às 5.356 pessoas. De fora, não dá para saber se o seu foi visto. Como uma mensagem poderia citar seu endereço e seu pedido reais, siga a cautela do passo seguinte.

A empresa pede que não se responda a e-mails, ligações ou mensagens de texto suspeitos que digam ser da empresa, de órgãos públicos ou de instituições financeiras, e que não se clique em seus links. Esses não são exemplos dados pela empresa; como suposição própria deste site, são plausíveis mensagens sobre um procedimento de desculpas, o novo registro do cartão ou o reembolso de taxas de reemissão. Trate como falsa qualquer mensagem que peça dados de cartão ou senhas e confirme por um site oficial que você mesmo abra (como distinguir: O que é phishing?).

Para verificar se um e-mail é genuíno, não use os links dele. Vá, em vez disso, aos avisos oficiais de suporte da empresa.

A empresa diz que sua loja no Rakuten Ichiba está fora do escopo porque funciona em um sistema separado. Diz que nenhum vazamento de dados de pagamento do PayPal ou da Amazon Pay foi confirmado. Dados de pedidos não enviados ainda podem se enquadrar no grupo C. As consultas são feitas pelo formulário de atendimento ao cliente da empresa, que funciona em um sistema separado.

Segundo a empresa, o acesso não autorizado veio à tona em 23 de outubro e o programa na página de pagamento foi encontrado em 28 de outubro. A adulteração da página de pagamento foi descoberta separadamente, depois de confirmada a visualização de dados de clientes. Não leia isso como sinal de resposta lenta; leia como um exemplo de que a visualização de dados e a adulteração da página de pagamento podem ocorrer separadamente.

Em um site em que privilégios de administrador foram obtidos, enquanto investiga o que foi visto, tire também uma lista dos scripts que a página de pagamento carrega e compare com a lista prevista. Se você não tem uma lista prevista, salve a de hoje e compare a partir de amanhã.

A empresa publicou o relatório de sua contratada segundo o qual a vulnerabilidade considerada a causa não é a vulnerabilidade do PHP divulgada recentemente. Corrigir a vulnerabilidade de que todos falam e dar a causa por encerrada deixa outras entradas abertas. Até que os logs mostrem como os privilégios de administrador foram obtidos, continue verificando como se outras entradas permanecessem.

A resposta da empresa incluiu invalidar e renovar todas as credenciais entre sistemas. Quando privilégios de administrador são obtidos, é preciso substituir não só as contas de administração do site, mas também as chaves e senhas que se conectam ao processador de pagamentos, ao banco de dados e a serviços externos. Sem uma lista de quais credenciais existem e onde, algumas são esquecidas. Comece hoje fazendo essa lista. Se você terceiriza o desenvolvimento ou a operação, pergunte se a contratada pode fornecê-la (isso inclui verificar que não restou nenhum backdoor).