"Mas não é chato!" - este é o lema informal dos funcionários do nosso centro de monitoramento de ameaças cibernéticas Solar JSOC (e devo dizer que 2019 correspondeu totalmente a ele). No início do ano novo, muitas pessoas gostam de fazer um balanço e estabelecer novas metas, mas decidimos contar alguns “horrores da nossa cidade” - os casos de 2019, que impressionaram até analistas experientes. A conclusão dessas histórias é apenas uma: a tecnologia se desenvolve e evolui, e a preguiça, a negligência e o descuido são eternos.
Guest Wifi
Ao conectar clientes ao monitoramento, solicitamos antes de tudo as informações mais importantes: contas críticas, grupos de domínios, segmentos não confiáveis, endereços brancos, DMZ, sub-redes críticas, etc. As sub-redes não confiáveis são apenas Wi-Fi convidado, bem como redes de prestadores de serviços, segmentos de teste com permissões para permitir qualquer, etc. ... Geralmente vemos que a possibilidade de interação com esses segmentos está ausente ou seriamente limitada, porque controlá-los muito difícil, se não impossível. Na rede do cliente, não havia possibilidade de tais interações, exceto a página de autorização na rede de convidados. Acalmamo-nos adicionando uma proibição de interagir do Wi-Fi com os servidores TOR, C&C e outros espíritos malignos, para que não fôssemos bombardeados com operações pelas quais o cliente em potencial não estava interessado (embora ainda coletemos estatísticas sobre esses incidentes para relatórios resumidos). E na terceira manhã do projeto piloto, notamos uma anomalia: o fluxo de eventos do firewall aumentou 4 vezes!
Eles começaram a procurar a causa do "bloqueio" e, com surpresa, o encontraram no segmento de Wi-Fi convidado. Um determinado host gerou 4 milhões (!) De eventos por hora. E os eventos são bastante interessantes - conexões na porta 445 com endereços brancos aleatórios do espaço da Internet. Quatro milhões, Karl!
Tendo informado o cliente sobre isso, eles começaram a aguardar informações sobre o host e o incidente, já que o DHCP (é o servidor de autorização) não estava conectado ao SIEM. Após cerca de 3-4 horas, o cliente informou que o host é um telefone celular. Dizer que ficamos surpresos é não dizer nada. Um telefone celular comum não pode gerar esse fluxo de eventos. Eles começaram a descobrir os detalhes, e o celular não teve nada a ver com isso - alguém acabou de usar um dos dispositivos registrados como cobertura. Não foi possível encontrar a verdadeira fonte de atividade, e nosso cliente disse que não estava interessado nesse caso, portanto, a atividade teve que ser minimizada. No entanto, alertamos os especialistas do cliente sobre os possíveis riscos: como a atividade (obviamente maliciosa) provém de seus endereços, eles podem, por exemplo, entrar nas listas de servidores C&C de fornecedores de antivírus e receber reclamações de órgãos policiais (quem sabe qual infraestrutura esse host verificará - afinal, pode haver KII, e a verificação de vulnerabilidades refere-se a incidentes que precisam ser relatados ao GosSOPKA). Após esses argumentos, o cliente ainda decidiu entender com mais detalhes e cumprir nossas recomendações. E eles eram os seguintes:
- feche todas as portas, exceto 80 e 443 (essa foi a decisão certa, porque após 445 uma varredura na porta 22 seguiu),
- introduzimos restrições à velocidade da Internet distribuída,
- ativar chips UTM, incluindo controle de aplicativos, e cortar categorias estranhas como torrents, navegadores TOR, scanners detectados e muito mais,
- ative o limite do número de conexões por intervalo de tempo.
O cliente nunca foi capaz de descobrir quem era esse usuário ativo de Wi-Fi, mas pelo menos o bloqueou com oxigênio (e, provavelmente, o atacante foi procurar o próximo Wi-Fi disponível.
Alguns meses depois, esse piloto foi fechado e transferido com sucesso para o contrato, mas ainda encontramos casos semelhantes em empresas completamente diferentes, de modo que as recomendações acima podem ser classificadas como universais.
Por padrão, ou sabotagem de fornecedor
Paralelamente à conexão piloto ao monitoramento Solar JSOC, o cliente encomendou um novo UTM. A migração para ela foi faseada: primeiro transferiu a ACL pelas sub-redes e depois as políticas do aplicativo. A sobremesa é a mais interessante.
Tudo aconteceu de acordo com os clássicos - na sexta à noite. A primeira linha registrou contratempos no contato com a infraestrutura do cliente para nós TOR, aparecendo como C&C em uma das listas de discussão do FinCERT. Como o projeto era piloto e o cliente transferiu todos os incidentes para Baixa criticidade, não havia um cartão de incidente, além da notificação por correio, um cartão de incidente. Portanto, a primeira operação de hosts diferentes em um endereço, apesar de suscitar suspeitas entre os engenheiros de monitoramento, não foi mais ampliada. Quando o número de viagens chegou a três, os caras perceberam que algo estava errado e informaram o analista que levou o incidente para o trabalho.
Primeiro, o analista entrou em contato com os funcionários responsáveis do cliente e sugeriu conectar hosts no nível do log local para identificar a fonte da atividade. No momento da discussão com os especialistas do cliente, o número de hosts havia aumentado para 7. A situação era muito semelhante à epidemia, mas o antivírus nos hosts estava funcionando e silencioso, não havia ações ativas e interações de host na rede.
A conexão de três hosts no nível do log local também não forneceu um entendimento de qual processo gerou a atividade. A ansiedade cresceu, a única opção de trabalho foi o isolamento de hosts com a remoção paralela de um despejo de RAM e a imagem do disco rígido. O analista começou a preparar instruções e, ao mesmo tempo, decidiu pesquisar o IP que os hosts acessavam para disponibilidade em outras correspondências e incidentes (porque o tipo de atividade que observamos era diferente daquele descrito no boletim informativo do FinCERT). Na maioria das vezes, a idéia é bastante infeliz, mas não desta vez.
Foi dada atenção ao artigo cujo título apareceu o endereço IP e o nome do fornecedor da UTM. Para resumir a essência da publicação, o fornecedor comprou um endereço IP que anteriormente pertencia ao nó TOR, que foi apresentado no boletim informativo da FinCERT. E isso não é tudo! Além disso, o fornecedor decidiu tornar esse endereço padrão para o redirecionamento de todas as chamadas suspeitas da infraestrutura de seus clientes para endereços potencialmente maliciosos. Ou seja, qualquer conexão com um endereço IP estranho foi interpretada pela UTM como ilegítima e redirecionada para esse endereço milagroso.
Depois de especificar se o módulo de proteção antimalware já está ativado e após receber a confirmação, os especialistas em analistas e clientes expiraram.
PS A análise das falhas que o UTM detectou confirma que todas as 7 atividades foram falsas positivas.
Prometemos recomendações para cada caso, mas aqui, talvez, damos apenas um: não implante na sexta-feira. E avise todos os interessados e simpatizantes.
Historicamente
Este leitmotif reúne uma grande variedade de casos. Veja o descomissionamento, por exemplo. Muitas vezes, processos que perderam relevância nas empresas são simplesmente esquecidos: ninguém “analisa” a infraestrutura antiga, deixando as antigas máquinas virtuais, servidores e acessos à rede. Ao mesmo tempo, ninguém monitora atualizações, antivírus e eventos nesses hosts, e mesmo os administradores geralmente não conhecem os proprietários dos sistemas. Portanto, após algum tempo, esses elementos de infraestrutura não apresentam as surpresas mais agradáveis. Quanto custa apenas enviar telemetria significativa de uma organização ambiental em um projeto concluído em 2005 para servidores FTP de um país não amigável!
Muitas vezes, ninguém lida com a manutenção de sistemas de 10 anos de idade, embora eles continuem sendo usados. Por exemplo, um portal de redefinição de senha que usa o mecanismo antigo e para a conveniência dos usuários examina a Internet, ou RDP, que o contratado precisa configurar aplicativos de negócios e se destaca por 5 a 6 anos.
A existência de tais problemas geralmente se torna conhecida quando:
- o host foi hackeado e a criptografia ocorreu com mais extorsão (houve muitos desses incidentes recentemente),
- há uma migração de uma solução no perímetro para outra,
- chegamos ao piloto e coletamos o perfil das portas abertas no perímetro.
Mas também existem situações completamente míticas: em 2013, a empresa construiu um túnel com um contratado atendendo seu sistema financeiro. O contrato terminou, mas o túnel permaneceu, como foi feito pela empresa da qual o contratado alugou as instalações juntamente com a infraestrutura de TI. Uma nova empresa ocupou o mesmo lugar e ficou surpresa ao encontrar endereços disponíveis da infraestrutura de outras pessoas. A curiosidade assumiu, e depois a tentação e a sede de lucro. Eles lançaram um banco de dados de contrapartes e contratos com o barulho - o benefício da competição foi interessante, mas ninguém fez barulho na empresa vítima. A história durou mais de um ano (não foi possível rastrear mais adiante os registros), mas no final, a investigação, as demissões e a cereja no bolo são um caso criminal.
AWOL, ou porque é mais conveniente
O caso como um todo é bastante trivial, o que não pode ser dito sobre a "metodologia de implementação".
Dado:
- projeto piloto de monitoramento de clientes;
- fontes conectadas no perímetro, bem como entre os segmentos corporativo e tecnológico;
- administração de plantão no local de trabalho e atendimento ao segmento de rede fechada;
- o desejo agudo do administrador é trabalhar menos, dormir mais e fazer tudo com conforto.
Como eu já disse, ao conectar, solicitamos ao cliente informações diferentes, incluindo endereços em branco, para coletar estatísticas sobre as conexões a eles da Internet e, assim, formar um perfil de perímetro externo. Depois de criar uma regra que preenche a lista no SIEM, em cerca de uma semana ou duas coletamos estatísticas sobre todas as portas abertas no perímetro, descarregamos para o cliente, observamos e corrigimos juntos (ao fechar o que é ilegítimo). Reunindo informações para o perfil, periodicamente percorremos os olhos pela lista, verificando se as portas estavam abertas para todos ou apenas alguns endereços nas listas brancas. Chamava-se atenção a porta 43388, que não parecia digna de nota, mas foi transmitida em 3389 e o endereço cinza, cujo proprietário era desconhecido para nós na época.
Ao verificar, verificou-se que está fechado para nossos endereços. Achamos que ele estava aberto nas listas brancas, mas durante o dia não observamos nenhuma conexão bem-sucedida nele. Chegando na manhã seguinte, eles notaram novamente que um pacote de eventos havia chegado da noite para o dia. Desta vez, examinamos mais atentamente os endereços de origem e vimos várias sessões de Moscou com uma duração total de mais de 5 horas e um número bastante grande de sessões curtas de todo o mundo. Então ficou claro que a questão não era que o porto estivesse acessível apenas aos endereços da lista branca, mas que ele fosse aberto apenas à noite - das 00:00 às 06:00 da manhã. Depois de escavar os logs do domínio e do antivírus (eles haviam sido conectados naquela época), ficamos surpresos ao descobrir que o endereço pertence ao administrador de plantão, que deveria estar no local de trabalho durante esse intervalo de tempo! Depois de analisar as conexões do carro, encontramos outra situação interessante: todas as noites, o porto também era aberto (acho que não é difícil adivinhar qual) no segmento dedicado fechado. É quase impossível notar essa atividade no quarto dia do piloto, a essa altura o número de conexões permitidas entre segmentos ainda é mais do que portas abertas no perímetro. Depois de informar os guardas de segurança sobre a situação, eles conectaram o host no nível do log local e certificaram-se de que o administrador estivesse escapando silenciosamente de casa do trabalho. Como se viu, ele morava quase em uma casa vizinha, e a conexão remota, é claro, se tornou uma tentação demais.
Talvez, se o administrador descrevesse a situação, ele poderia trabalhar remotamente através do SKDPU, desde que, no momento do acidente, ele pudesse trabalhar em 15 minutos e não houvesse problemas.
Total
Na realidade, uma das principais ameaças à segurança da informação é a goivagem no terreno. Portanto, minimize os riscos:
- Acompanhe as configurações de perímetro e firewall.
- Tente fazer o controle remoto em uma empresa gerenciada (VPN através de um servidor de terminal). E se ele já existir, controle quem o usa (removendo vários RATs em hosts que agora detectam facilmente quase todos os mecanismos antivírus).
- Siga as ações de usuários privilegiados: muitas vezes eles perdem a vigilância, acreditando que têm tudo sob controle e facilitam o acesso dos invasores a dados críticos.