Originalmente publicado por Ian Gallagher no blog da XM Cyber, parceira da Bravo para soluções de cibersegurança e líder global em segurança de nuvem híbrida.
No oeste selvagem, havia um cara, Willie Sutton. A profissão escolhida por Willie não foi a de dentista-barbeiro da cidade ou de dono de bar. Não, ele foi um prolífico ladrão de banco. E quando lhe perguntaram por que é que os bancos eram o seu alvo número um, ele respondeu “porque é lá que está o dinheiro”.
Não defendo suas escolhas profissionais, mas a observação foi extremamente astuta.
O mundo evoluiu mais do que um pouco e hoje, felizmente, os incidentes de roubos na vida real são menos comuns, mas os ataques cibernéticos estão mais comuns do que nunca. Até hoje, os serviços financeiros continuam a ser um dos setores mais visados e, de fato, um relatório do Boston Consulting Group concluiu que a indústria de serviços financeiros foi visada 300 vezes mais do que outras indústrias.
Para tentar evitar que tais eventos ocorram, equipes de segurança investem continuamente nas melhores ferramentas de detecção e resposta. Com o tempo, isso levou a uma grande melhoria no Tempo Médio de Detecção (Mean Time to Detect – MTTD) e no Tempo Médio de Resposta (Mean Time to Respond – MTTR). E os tempos de permanência também diminuíram. Essas estatísticas representam um grande avanço. No entanto, apesar das melhorias feitas pelos defensores nas áreas de detecção e resposta, violações e incidentes ainda acontecem. E não importa se leva 21 dias para identificar uma violação ou não, se o invasor atingiu seu alvo em menos dias.
Existem muitos blogs e artigos que focam em como essas abordagens podem potencialmente reduzir perdas e talvez prevenir ataques. As organizações de serviços financeiros continuam a contar com soluções de proteção de endpoint e ferramentas de correlação de log para evitar ataques em tempo real. As equipes de segurança de empresas de serviços financeiros estão mudando para uma prevenção mais proativa. Estas abordagens definitivamente têm mérito — mas voltando à questão do “300 vezes mais tentativas de ataque” — é evidente que não estão fazendo o suficiente.
Este blog adota uma abordagem um pouco diferente, explorando quatro casos reais de caminhos de ataque de organizações de serviços financeiros. Por que explorar seus caminhos de ataque? Caminhos de ataque são as rotas pelas quais os invasores podem seguir para entrar nos sistemas e alcançar os ativos. Certas exposições, por si só, não são capazes de serem aproveitadas de forma significativa por invasores. Mas invasores não olham para a exposição individual — em vez disso, aproveitam uma combinação de vulnerabilidades, configurações incorretas, identidades excessivamente permissivas e outras lacunas de segurança para se moverem entre sistemas e alcançarem ativos confidenciais. Isso lhes permite causar danos significativos e contínuos enquanto se escondem dentro das redes.
Compreender os caminhos de ataque nos ajuda a entender como os invasores comprometem ativos críticos em redes locais e de nuvem híbrida. A seguir, trouxemos quatro caminhos de ataque reais que encontramos e corrigimos em redes de empresas do setor financeiro. Ao compreender a construção dos caminhos de ataque, podemos entender melhor como os ataques teriam ocorrido – e, mais importante, como evitar ataques semelhantes no futuro.
Caminho de ataque nº 1 – Ataque man-in-the-middle em uma seguradora
Uma grande companhia de seguros descobriu que um pequeno subconjunto de máquinas estava enviando transmissões DHCP v6, permitindo que um invasor se posicionasse como o intermediário em um ataque man-in-the-middle — uma forma de ataque em que os dados trocados entre duas partes são, de alguma forma, interceptados pelo invasor sem que a vítima perceba — e explorasse uma vulnerabilidade de atualização do Windows nessas máquinas.
Uma das máquinas pertencia a um desenvolvedor e tinha diversas chaves SSH privadas desprotegidas em sua pasta de downloads. Usando essas chaves SSH, um invasor poderia facilmente comprometer cerca de 200 sistemas Linux no data center local da empresa e em seu ambiente de nuvem. A partir desses sistemas, o invasor poderia realizar ataques adicionais, como criptografar sistemas/dados para resgate ou exfiltrar dados.
Como isso foi remediado?
Ao desativar o DHCPv6 e corrigir a máquina do desenvolvedor, tanto a vulnerabilidade quanto a configuração incorreta foram resolvidas. Também foi um bom momento para revisar as melhores práticas com os desenvolvedores — conscientizando-os de como as chaves SSH podem colocar seus sistemas Linux em risco.
Caminho de ataque nº 2 – Instituição financeira global garante que desenvolvedores offshore não possam acessar dados de produção
Uma instituição financeira global passou um ano fortalecendo seu ambiente de desenvolvimento sandbox — ambiente isolado comumente usado por programadores e desenvolvedores na hora de testar novos programas — para desenvolvedores offshore, a fim de garantir que os desenvolvedores não pudessem acessar seu ambiente de produção. Eles procuravam evitar os riscos de um desenvolvedor offshore mal-intencionado começar a agir por conta própria ou de uma violação resultante de práticas de segurança negligentes na cadeia de fornecimento digital do contratante — qualquer um dos quais poderia representar riscos significativos para os dados de produção da empresa.
Nossa análise descobriu que não apenas era possível, mas também bastante simples, para qualquer desenvolvedor abusar de uma função Lambda na AWS, assumir uma função com privilégios e depois passar lateralmente para o ambiente de produção.
Como isso foi remediado?
A equipe de segurança compartilhou esse caminho de ataque com o time de arquitetura de nuvem, que então removeu a configuração incorreta do Lambda. Essa correção garantiu que não houvesse possíveis caminhos de ataque do ambiente sandbox do desenvolvedor para os sistemas de produção. Hoje, a instituição financeira realiza a mesma simulação todos os dias, para garantir que nenhum terceiro possa acessar os dados de produção.
Caminho de ataque nº 3 – Banco global não implantou totalmente o patch
Como parte do Patch Tuesday — termo não oficial para se referir aos dias em que empresas como Microsoft, Adobe, entre outras, lançam patches para seus softwares —, um banco global tentou corrigir todos os servidores usando SCCM. Isso incluiu o patch para a vulnerabilidade ZeroLogon (CVE-2020-1472) em seus controladores de domínio.
Como os controladores de domínio são muito sensíveis e de missão crítica, nem todos foram reinicializados após a atualização do patch. Assim, o patch foi implantado, mas a correção não foi totalmente implementada. Isso deixou um caminho aberto que os invasores poderiam usar para comprometer os controladores de domínio.
Como isso foi remediado?
Depois de entender o problema, a equipe do banco alterou os procedimentos para garantir reinicializações após a implantação de patches, quando necessário.
Caminho de Ataque #4 – O Banco e o caminho de ataque complexo
Uma instituição financeira global identificou uma automação usando uma conta de serviço que iniciou uma ação baseada na porta SMB. Isso poderia permitir que as credenciais da conta de serviço fossem usadas para um ataque man-in-the-middle dentro da rede, permitindo que um invasor se movesse lateralmente para outro dispositivo ou estação de trabalho.
Em seguida, eles descobriram chaves SSH privadas para um servidor em execução em uma instância AWS EC2. Anexado a este EC2 estava uma função do IAM. Usando as permissões desta função, seria possível criar um novo EC2. E isso poderia ser usado para comprometer um dos ativos mais críticos da empresa, utilizado para implantação no ambiente do cliente.
Se um ator de ameaça tivesse descoberto esse caminho, as consequências poderiam ter sido desastrosas.
Como isso foi remediado?
O banco corrigiu imediatamente cada etapa do caminho de ataque, removendo chaves SSH privadas, redefinindo as permissões de função do IAM e removendo usuários específicos.
Equipes de segurança corporativa enfrentam tantas exposições que é difícil entender qual nível de risco de impacto é mais agudo e como eles podem ser agrupados e explorados por um invasor experiente.
O cenário de ameaças aos serviços financeiros está em constante evolução, e o foco está mudando para a prevenção proativa, a compreensão e a proteção de caminhos de ataque complexos. Estes cenários da vida real sublinham a importância de abordar estrategicamente as vulnerabilidades e exposições para proteger ativos críticos.
