Acesso não autorizado a alguns servidores web do ConoHa WING (GMO Internet) (426 contas): dados nas áreas de servidor web dos clientes afetados e o que os donos de sites devem fazer hoje

A empresa diz que entrou em contato individualmente com os clientes afetados "no endereço de e-mail cadastrado como informação do contrato", e que os clientes que não foram contatados não são afetados.

Verifique também a pasta de spam, além da caixa de entrada. Se uma agência web fez o contrato por você, ou se você cadastrou um endereço antigo, o e-mail deve ter sido enviado para lá. Faça login pelo site oficial que você abre por conta própria para ver qual endereço está cadastrado, ou entre em contato com o canal indicado no comunicado (listado em "O que aconteceu" abaixo).

A empresa alerta sobre e-mails de phishing que aproveitam este incidente e diz que nunca pede senhas ou dados de cartão de crédito por e-mail. Também pede que os clientes verifiquem o remetente e o conteúdo dos comunicados individuais antes de agir.

Depois de um incidente de hospedagem, é provável que apareçam e-mails falsos com frases como (exemplos nossos) "sua conta foi afetada e precisa ser redefinida" ou "confirme seu contrato", levando a páginas feitas para parecer a tela de login. Não faça login por links em e-mails; abra o site oficial pelos favoritos ou por uma busca própria (veja o que é phishing).

A empresa diz que enviou aos clientes afetados os detalhes e as "ações que gostaríamos que você realizasse" por e-mail individual. Esse conteúdo não é público, por isso este artigo não pode reproduzi-lo. Antes de agir, confirme que o e-mail é genuíno, como no passo 2: verifique pelo site oficial, não pelos links do e-mail.

Os dados envolvidos são os "dados armazenados nas áreas de servidor web dos clientes". O comunicado não diz se eles foram copiados, mas este site recomenda tratá-los como possivelmente lidos ou alterados. Trocar as credenciais custa menos, em esforço e em risco, do que deixá-las em um estado desconhecido.

• O nome de usuário e a senha do banco de dados no wp-config.php do WordPress (depois de trocar a senha do banco, coloque o mesmo valor no wp-config.php)
• Chaves de API de serviços externos (pagamentos, envio de e-mails, mapas etc.) no .env e em arquivos semelhantes: gere novas no painel de cada serviço e desative as antigas
• Senhas de administrador do WordPress e as chaves secretas (salts) no wp-config.php; regenerar os salts desconecta todos os usuários
• Senhas e chaves de FTP e SSH, e quaisquer chaves públicas cadastradas no servidor
• Arquivos de backup guardados no servidor (como exportações do banco de dados): trate também as credenciais e os dados pessoais que eles contêm como lidos

Faça as trocas a partir de um computador verificado com antivírus. Para repensar onde ficam os arquivos de configuração, veja como manter o .env fora da web pública na hospedagem compartilhada; para lidar com chaves de API, veja noções básicas de .env e chaves de API.

A empresa diz que removeu os programas maliciosos em 18 de setembro. Mesmo assim, vale verificar por conta própria se não restou nenhuma alteração que você não fez no seu site. O acesso começou em 3 de setembro, então concentre-se nas mudanças desde essa data.

• No gerenciador de arquivos, ordene a pasta pública pela data de modificação e procure arquivos alterados em datas em que você não mexeu, ou arquivos PHP dentro de pastas de imagens
• Na lista de usuários do WordPress, procure administradores que você não criou e plugins ou temas que você não instalou
• No painel de controle, nas tarefas agendadas (cron), procure entradas que você não adicionou

Onde e em que ordem procurar, conforme o ambiente, está em como verificar se seu site ou servidor foi invadido. Se encontrar algo desconhecido, copie antes de apagar e entre em contato com a empresa. Se seu site guardava dados pessoais de terceiros, como mensagens de formulários de contato ou cadastros de membros, leia também a seção desse artigo sobre quando dados pessoais podem ter vazado.

Segundo a empresa, os dados de membros, contratos e pagamentos eram gerenciados em um ambiente separado dos servidores afetados e não vazaram. É um exemplo de uma ideia geral: manter coisas em lugares separados limita até onde a violação de uma parte pode chegar.

Você pode fazer o mesmo no seu site. Não deixe exportações de banco de dados ou backups antigos na área de servidor web, emita chaves de API apenas com as permissões necessárias e mantenha os arquivos de configuração fora da pasta pública. Como verificar isso está em você deixou um arquivo secreto em um diretório público?

Pelas datas publicadas, passaram-se 13 dias entre o início do acesso (3 de setembro) e a detecção (16 de setembro). Isso é a diferença entre duas datas, não um julgamento sobre se a detecção foi lenta. Ainda assim, perceber mudanças no seu próprio site quando algo acontece do lado do provedor depende do que você tem implementado.

Um primeiro passo simples: uma vez por semana, exporte a lista de usuários administradores do WordPress e a lista de arquivos PHP da pasta pública, e compare com a semana anterior. Qualquer item novo é motivo para começar a investigar. Para reforçar o WordPress como um todo, veja segurança do WordPress — uma referência de endurecimento para produção.

Neste incidente, a forma de saber se você foi afetado é um e-mail individual enviado ao endereço cadastrado no contrato. Se esse ainda for o endereço de uma agência web ou um que você não usa mais, você vai perdê-lo. Verifique agora, enquanto nada está errado, se o endereço cadastrado é um que você lê e se os e-mails do provedor não estão indo para o spam.