Incidentes e Vulnerabilidades
Vazamento em massa do MOVEit (2023) — como um zero-day de SQL injection alcançou mais de 2.700 organizações, e como se defender
Um zero-day de SQLi (CVE-2023-34362) no MOVEit, explorado em massa pela Cl0p antes de um patch — mais de 2.700 organizações, cerca de 93,3M de pessoas, a maioria atingida por meio de um fornecedor. A cadeia de ataque como mapa de defesa e as correções que importam.
Lemos incidentes públicos reais não como reprises de notícias, mas pela ótica de "como você se defenderia disso". Este artigo é baseado em registros públicos (agências, avisos de fornecedores, inteligência de ameaças, reportagens), citados ao final. Sem passos de ataque ou payloads.
- Alvo
- MOVEit Transfer (produto de transferência de arquivos da Progress Software) e as organizações e clientes que o usam
- Exploração iniciada
- por volta de 27 de maio de 2023 (feriado de Memorial Day nos EUA)
- Classe
- um zero-day de SQL injection em app web público → web shell → roubo de dados do BD de retaguarda, mais extorsão
- Escala
- mais de 2.700 organizações, cerca de 93,3M de indivíduos (estimativas posteriores mais altas)
- Causa raiz
- falha de SQLi desconhecida + exploração em massa antes de um patch + uma camada web que podia ler todo o BD de retaguarda + propagação via fornecedores
- Correções reais
- patch rápido de KEV, minimizar a exposição, menor privilégio e segmentação entre web↔DB, inventário de fornecedores e minimização de dados
O que aconteceu (em termos simples)
O MOVEit Transfer é um produto para entregar arquivos com segurança entre organizações, e muitos o rodavam exposto à internet. Sua interface web pública tinha um zero-day de SQL injection — uma falha em que a entrada reescreve o significado de uma consulta ao banco de dados.
O grupo Cl0p a explorou antes de existir uma correção para plantar um web shell (um programa malicioso de controle remoto, chamado "LEMURLOOT" nos registros públicos) em instâncias MOVEit expostas. Com isso, eles leram em massa os arquivos e informações de usuário armazenados no banco de dados por trás do produto e os exfiltraram. A Cl0p então reivindicou a responsabilidade em um site de vazamentos e exigiu resgate, ameaçando publicar os dados.
Um 'appliance de transferência de arquivos' é um mapa do tesouro para o invasor
Produtos de transferência de arquivos, por sua natureza, concentram dados sensíveis de muitas organizações e tendem a ficar expostos à internet por necessidade de negócio. Para o invasor, isso é um alvo de alto valor: "quebre um, alcance muitos dados." Por isso, esse tipo de appliance público deve ser defendido partindo do princípio de que estará entre as primeiras coisas atingidas no instante em que um zero-day surgir.
A cadeia de ataque também é um mapa de defesa
O que importa é que esta foi uma cadeia de quatro saltos, e cada salto tinha um ponto para interrompê-la. Leia isto não como uma receita de ataque, mas como onde ela poderia ter sido cortada.
1. Entrada: zero-day de SQLi no app web público
uma falha desconhecida de SQL injection em uma interface exposta à internet.
⊘ pare: minimize a exposição (atrás de VPN/allowlist de IP)
2. Web shell plantado
a falha é usada para instalar um programa de controle remoto.
⊘ pare: patch rápido de KEV (feche o buraco ativo em horas-dias)
3. Dados roubados do BD de retaguarda
a camada web lê em massa os dados armazenados no banco.
⊘ pare: menor privilégio entre web↔DB, segmentação, detecção de leitura em massa
4. Propagação para milhares via fornecedores
de fornecedores que usavam o MOVEit, para os dados dos clientes deles.
⊘ pare: inventário de fornecedores + minimize os dados que você entrega
A linha do tempo divulgada
2023-05-27
A Cl0p começa a explorar em massa o zero-day do MOVEit Transfer (feriado de Memorial Day nos EUA).2023-05-31
A Progress Software divulga o CVE-2023-34362 e lança um patch de emergência.2023-06-02
A CISA adiciona o CVE-2023-34362 ao catálogo KEV (Vulnerabilidades Conhecidas Exploradas).2023-06-06
A Cl0p reivindica a responsabilidade em seu site de vazamentos e inicia a extorsão.2023-06-07
CISA/FBI publicam o aviso conjunto #StopRansomware (AA23-158A).2023→
As contagens de organizações e pessoas afetadas seguem subindo à medida que o impacto via fornecedores aflora.
A causa raiz não foi "um único erro", mas camadas falhando
Arquivar isto como "o MOVEit tinha um bug" garante a repetição. Na realidade, várias camadas falharam em sequência.
A configuração que falhou (na época)
- um appliance que concentra dados sensíveis, amplamente exposto à internet
- explorado em massa na janela zero-day, pré-patch
- uma camada web que podia ler todo o BD de retaguarda (segmentação/privilégio fracos)
- nenhuma visibilidade das práticas dos fornecedores, então a propagação não pôde ser interrompida
A configuração defendida (prevenção)
- minimizar a exposição (atrás de VPN/allowlist de IP; desativar funcionalidades não usadas)
- patch rápido de KEV (aplicar primeiro as correções ativamente exploradas)
- segmentar e menor privilégio entre web↔DB + detecção de leitura em massa
- inventário de fornecedores + minimização de dados para reduzir o raio de explosão
Cadeia de suprimentos: sua segurança depende de 'a quem você entregou'
A característica definidora deste vazamento é que a maioria das vítimas não usava o MOVEit ela própria. Porque um fornecedor ou prestador a quem haviam confiado dados (folha de pagamento, previdência, seguros) usava o MOVEit, os clientes deles foram arrastados cadeia abaixo (o mesmo formato aparece no incidente de cadeia de suprimentos da Codecov). Então, quando você entrega dados a um terceiro, pergunte tanto "qual é a prática de vulnerabilidades dele?" quanto "esses dados precisam mesmo ser entregues?"
Prevenindo uma repetição no seu ambiente
Correções priorizadas que funcionam em qualquer escala. Se você tem ao menos uma "funcionalidade de administração/transferência de arquivos exposta à internet" ou "uma relação em que entrega dados a um terceiro", isto é sobre você.
Minimize a exposição (reduza o alvo)
Não exponha funcionalidades de administração e transferência de arquivos diretamente à internet quando puder evitar. Coloque-as atrás de uma VPN ou allowlist de IP, e desative/isole funcionalidades não usadas e appliances antigos. Reduzir o que um invasor pode tocar é o primeiro movimento.
Corrija primeiro as falhas listadas na KEV (patch rápido)
Quando um produto que você roda entra na lista de ativamente exploradas (KEV), aplique a correção em horas a dias. Você não pode prevenir o zero-day, mas fechar com força a janela pós-patch evita a maior parte do dano (→ a prática da resposta a vulnerabilidades, o feed de alertas de ameaças).
Segmente o app web do BD de retaguarda, menor privilégio
Para que um app web público comprometido seja contido, restrinja privilégios de modo que a camada web não possa ler todo o BD de retaguarda, e segmente a rede. A correção real do SQLi são placeholders, mas segmentação e menor privilégio reduzem o raio de explosão se algo escapar.
Inventarie fornecedores e minimize os dados que você entrega
Liste quem guarda seus dados (fornecedores, SaaS, prestadores) e mantenha um canal de contato para incidentes maiores. E minimize os dados que você entrega em primeiro lugar — dados que você nunca enviou não podem vazar quando eles forem comprometidos.
Onde isso se sobrepõe ao design deste site
Este site, também, é construído sobre minimizar a exposição e monitorar por máquina as falhas ativamente exploradas (KEV) para corrigi-las rápido (via sua própria auditoria de dependências e feed de ameaças). Este incidente é o exemplo mais eloquente de por que os princípios que defendemos no produto — estreite o que você expõe, mate primeiro as falhas KEV, separe camadas para reduzir o raio de explosão, minimize os dados que você entrega — realmente importam. Você não pode evitar o zero-day em si, mas uma prática que fecha com força a janela pós-patch e um design que contém o dano quando comprometido são implementáveis por qualquer um, em qualquer escala.
Fontes (registro público)
Os fatos aqui são baseados nas seguintes informações públicas. Sem reprodução de ataque ou payloads — apenas as lições defensivas.
- CISA / FBI, "#StopRansomware: CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability" (AA23-158A, 2023) — cisa.gov
- Aviso oficial da Progress Software, "MOVEit Transfer Critical Vulnerability (CVE-2023-34362)" (2023) — community.progress.com
- Mandiant (Google Cloud), "Zero-Day Vulnerability in MOVEit Transfer Exploited for Data Theft" (2023) — cloud.google.com
- Rapid7, "CVE-2023-34362: MOVEit Vulnerability Timeline of Events" (2023) — rapid7.com
Leia em seguida
- Glossário: o que é SQL injection (a entrada deste vazamento, com a correção real)
- Incidente: o incidente de cadeia de suprimentos da Codecov (vazando por meio de quem você confiou)
- Na prática: a prática da resposta a vulnerabilidades (corrija KEV primeiro)
- Preparação: backup e recuperação (pronto para ransomware)
FAQ
QQual foi a causa raiz do vazamento do MOVEit?
Uma vulnerabilidade de SQL injection desconhecida (zero-day) (CVE-2023-34362) no produto MOVEit Transfer, exposto à internet. Os invasores a exploraram para plantar um web shell (um programa malicioso de controle remoto) e ler em massa os dados de arquivos armazenados no banco de dados por trás do produto. A combinação de exploração em massa antes de existir um patch, e uma camada web que podia ler todo o banco de dados de retaguarda, a tornou grave.
QEu não uso o MOVEit — por que isso me afeta?
A maioria das vítimas não era usuária do MOVEit; elas foram arrastadas porque um fornecedor, parceiro ou prestador de serviço a quem haviam confiado dados usava o MOVEit. Este é um vazamento clássico de cadeia de suprimentos: a segurança dos seus dados também depende das práticas de patch de quem os recebe. Um inventário de fornecedores e minimizar os dados que você entrega ajudam nos dois casos.
QHá algo que um pequeno serviço possa aprender?
Sim. (1) Funcionalidades de administração e transferência de arquivos expostas à internet são alvos primários, então minimize a exposição e corrija qualquer coisa na lista KEV (ativamente explorada) em horas a dias. (2) Segmente o banco de dados por trás de um app web e restrinja privilégios para que a camada web não possa ler tudo. (3) Minimize os dados que você entrega a terceiros. Tudo isso funciona em qualquer escala.