Duas Vítimas, Um Fornecedor: Quem Está Por Trás das Duas Invasões
O desafio
Um grupo de clínicas e uma transportadora, de setores diferentes e sem nenhum cliente, funcionário ou rede em comum, foram roubados na mesma semana por uma sessão em que ninguém nunca fez login. Nenhum dos dois encontra e-mail de phishing, senha roubada ou malware, e ambos usavam autenticação multifator que nunca foi acionada. O que duas organizações assim compartilham são fornecedores. Seis registros públicos estão no quadro. Descubra qual fornecedor aparece nas duas histórias e consegue criar uma sessão sem login.
O que você vai aprender
- Montar o inventário de fornecedores de duas organizações a partir de divulgações públicas
- Cruzar dois conjuntos e usar evidências secundárias para desempatar
- Reconhecer recursos de personificação de fornecedores como um caminho de autenticação sem registro em log
- Explicar por que o MFA não é acionado quando uma sessão é criada no lado do servidor
- Usar uma terceira organização, não afetada, como grupo de controle
Habilidades testadas
Pré-requisitos
- O que single sign-on e MFA fazem
- Leitura de uma divulgação de invasão
Como funciona
Quando duas organizações sem nada em comum são atingidas na mesma semana pelo mesmo mecanismo inexplicado, o elo compartilhado quase sempre é um fornecedor. Os inventários de fornecedores são muito mais públicos do que as empresas imaginam: avisos de invasão citam sistemas, registros regulatórios listam o escopo, anúncios de vaga descrevem a stack em detalhes e engenheiros respondem perguntas em fóruns.
A fragilidade específica aqui é um recurso de personificação. Ferramentas de suporte costumam trazer uma forma de um agente abrir a aplicação de um cliente como se fosse um dos usuários desse cliente, porque é a maneira mais rápida de reproduzir um bug. A sessão é criada no lado do fornecedor, então o provedor de identidade do cliente nunca é consultado. Nenhum evento de login, nenhum desafio de MFA, nenhuma localização anômala, nada no log de autenticação do cliente. Tudo que a vítima normalmente usaria para investigar é cego por design.
É por isso que o desempate não é sobre qual fornecedor é maior ou mais evidentemente crítico para a segurança. É sobre qual fornecedor consegue criar uma sessão sem realizar um login, porque essa é a única capacidade que corresponde ao que as duas vítimas descreveram.
Erros comuns
- Responder Latchkey SSO. Aparece nas duas stacks e é o provedor de identidade, o que o torna a resposta intuitiva. Seu histórico de status cobre a janela, sua avaliação externa está limpa, e a vítima afirma que não há nada em seus logs. Cruzar os conjuntos não basta: é preciso eliminar candidatos.
- Responder Northfield ou Vantage. Cada um aparece em apenas uma vítima.
- Tratar o post do fórum como ruído. A clínica que abandonou o Tidemark em julho e não foi atingida é o mais próximo de um grupo de controle no quadro.
- Procurar o vetor de acesso inicial nas vítimas. Nenhuma das vítimas foi a porta de entrada. O atacante já estava dentro do fornecedor.
Como se proteger
Trate todo fornecedor que pode agir como seus usuários como parte do seu perímetro de identidade.
- Faça o inventário de quais fornecedores têm direitos de personificação, assist ou login de suporte, e desligue o recurso onde ninguém de fato o usa.
- Exija aprovação do cliente por sessão para a personificação, com expiração, para que um comprometimento do lado do fornecedor não consiga criar sessões silenciosamente.
- Exija que os logs de auditoria do lado do fornecedor possam ser exportados para o seu próprio SIEM quase em tempo real. Harlow e Calder não conseguiram consultar o log que continha a resposta até uma semana depois da invasão.
- Configure alertas para atividade privilegiada em sessões sem evento de autenticação correspondente no seu provedor de identidade. Essa correlação é barata e é exatamente a brecha em que esse ataque vive.