Olá! Recentemente, com o processamento de RBK.money, participamos ativamente do polígono cibernético The Standoff - isto é, quando eles fazem um modelo virtual de uma metrópole inteira com toda a sua infraestrutura, usinas de energia, lojas e outros elementos importantes. E então eles deixaram o time azul (6 times este ano) e o time vermelho (29 times este ano, respectivamente) times neste gêmeo digital da cidade, o primeiro protege toda esta infraestrutura, o segundo está ativamente tentando quebrar alguma coisa.
do filme "Blade Runner 2049"
Claro, trouxemos nosso processamento para o evento, que você poderá ler nos posts anteriores do nosso blog. O processamento era parte do bancoe prestou serviços financeiros e de pagamento aos moradores da cidade cibernética, atendeu a emissão de cartões de pagamento e possibilitou a comercialização de bens e serviços.
Neste post, quero contar a vocês como os hackers nos quebraram (alerta de spoiler: e não quebraram), bem como nós mesmos atiramos no próprio pé algumas vezes no processo de preparação e implantação de nossa solução. E sim, o principal é que para nós foi inicialmente uma situação ganha-ganha: eles não vão nos quebrar, o que significa que não é à toa que estamos tão confiantes em nosso processamento que o colocamos em código aberto e agora estamos dando para hackers. Eles vão quebrar - geralmente ótimo, vamos ver onde estão os pontos fracos, e ficaremos ainda mais protegidos em termos de segurança para nossos clientes.
Nós nos infiltramos na cidade cibernética com uma pressa tangível: esta é uma de nossas primeiras implantações no Kubernetes (antes disso, implantamos tudo com estados de Salt) e tivemos que usar novas abordagens de instalação. E as consequências dessa pressa não demoraram a chegar.
Dicas para hackers
Mesmo antes de implantar o processamento em uma cidade cibernética, deixamos deliberadamente dois pontos fracos ali.
O primeiro é uma vulnerabilidade associada aos métodos de tokenização de cartão. Esses métodos eram suscetíveis a vulnerabilidades na forma de ataques de repetição, ou seja, o cartão poderia ser tokenizado com sucesso em uma loja e, com esse token, chegar a outra e reutilizado lá. Tínhamos esperança de que a vulnerabilidade fosse encontrada, mas, infelizmente.
A segunda é uma contabilidade simples do comerciante principal. Criamos apenas um comerciante oligarca, uma pessoa jurídica que possuía lojas online na cidade cibernética. E esse saco de dinheiro tinha credenciais bastante simples, ou seja, uma senha como Parolec0, a princípio, poderia estar danificada . Mas também não decolou.
Mas nossas próprias ombreiras surgiram.
Com pressa - você não pode proteger tudo
Um leitor atento concluirá do ponto sobre o comerciante principal - espere um minuto, você tem um e único oligarca que possui todas as lojas online, basta hackear uma dessas lojas online e você terá acesso às demais. Bem, sim, eles não pensaram nesse momento com pressa ..
E de fato, após hackear este comerciante, foi possível pegar sua chave API para nosso processamento e gerenciar totalmente esse processamento. Na verdade, foi isso que aconteceu - os invasores hackearam uma solução de terceiros, uma loja de entretenimento online da cidade, pegaram a chave API do nosso comerciante de lá, vieram com ela para o nosso processamento e chamaram um método que permite ligar / desligar sua loja online. E como uma pessoa jurídica possuía todos os pontos de venda da cidade, todos eles desligaram.
Em princípio, isso é correto, se você é um oligarca ganancioso que agarrou tudo para si - sofra. Tiramos conclusões e decidimos despojar imediatamente o saco de dinheiro, criando mais 5 entidades legais independentes e para cada “senha de login” e pares de chave API separados. Acho que nas próximas competições vamos tentar deixar a situação ainda mais próxima da realidade na parte empresarial.
E também “voou” pelas peculiaridades do kuber.
No Kubernetes, o principal repositório para o estado do cluster é ETCD , um sistema distribuído útil no qual você pode construir coisas muito, muito confiáveis. Mas é muito crítico em relação à latência dos discos rígidos.
Conforme escrevi, implantamos o processamento em um ambiente de cidade virtual virtual. Houve ataques bastante ativos aos objetos adjacentes a nós, e uma vez que um desses objetos “ruidosos” foi movido para o nosso armazenamento de dados, a infraestrutura de um dos participantes, que estava quebrada por um longo tempo e persistentemente. E embora de fato não fôssemos um alvo neste caso, e naquele momento ninguém quebrou o processamento, ele continuou a funcionar normalmente, mas o próprio cluster começou a ficar muito lento, os discos rígidos simplesmente não conseguiram lidar (eles conseguiram notar que a saída do comando ls -l levou cerca de 19 segundos). Acontece que uma espécie de DoS foi lançada e, em uma noite, oferecemos nossos gatos padrão para todas as solicitações.
Depois dessa situação, os organizadores do The Standoff nos mudaram para outros discos, ou seja, desligaram uma máquina virtual e ligaram outra, em um local diferente. Depois disso, nosso SGBD distribuído felizmente pegou um cérebro dividido, metade dos nós continha uma informação, metade - outra, e não podiam realmente concordar com eles mesmos. Na batalha, nós, é claro, teríamos nos confundido mais seriamente com migração e não teríamos permitido que isso acontecesse. E em um ambiente de teste, era muito mais fácil simplesmente bater em tudo que estava disponível e reinstalar, o que fizemos, gastando, aliás, 2 horas. Por que enfatizo isso - porque implantamos um fluxo de trabalho completo com todos os componentes em duas horas, e você pode fazer isso com nosso processamento em batalha em sua empresa. O processamento clássico geralmente é implantado em empresas por 3 meses.
Então, sobre o cérebro dividido, é tudo uma correria. Acabamos de derrubar / tmp em um dos nós sob a raiz . Quem diria que o módulo CSI LVM , que distribui volumes locais de hardware para pods, secretamente (!) Monta um volume Kuber persistente em / tmp . Assim, descobriu-se que com nossas próprias mãos destruímos os dados sob os pés do DBMS que estava girando sobre ele. Além disso, apesar de termos demolido o armazenamento de alguns dos nós nos clusters base, tudo continuou a funcionar para nós até o primeiro reinício da máquina virtual, que aconteceu quando eles começaram a nos transferir para novos lados.
O time azul está lentamente desligando suas defesas ...
Um dia, a equipe azul decidiu desligar a proteção externa (firewall, etc.). Ou seja, nos primeiros dias os hackers tentaram quebrar sistemas com esse tipo de proteção habilitada, e depois - sem. Também tínhamos um WAF de terceiros, que no ingresso com njinks como um módulo foi carregado e protegeu nosso tráfego.
E então chegou o dia, fomos desligar o WAF e percebemos que ele já estava desligado. Dois dias atrás. Como somos ótimos e estamos com pressa (sim, sim), estávamos configurando kubernetes de entrada, que tinha uma instância WAF. E tudo ficaria bem, mas o WAF simplesmente não alcançou o servidor de controle, não pôde baixar o arquivo de licença dele, encolheu os ombros e simplesmente saiu do pecado. E acontece que todos esses dois dias em que “Rompemos com a proteção incluída” ficamos sentados, de fato, sem essa proteção.
Mas ainda não estávamos quebrados.
Outra confirmação da tese de que a pressa é prejudicial (se você não tem o suficiente das anteriores) - a situação com nosso antifraude. I descreveu em anteriores do blog mensagens , há uma caixa mágica com um conjunto de regras. O Antifraud protege contra violação de cartões bancários, tentativas de pagamento em um ponto de diferentes locais / IP / e-mail e outras ações hostis. Dissemos à equipe de defesa que deveríamos definir todas essas regras de maneira cuidadosa.
E fizemos isso - configuramos cuidadosamente todas as regras antifraude. Em nosso servidor de produção RBK.money em vez de instalar para o The Standoff. Os urls da IU na barra de endereço do navegador são piegas. Ou seja, o antifraude nessa época era uma caixa com um vazio silencioso e misterioso.
Isso se tornou um dos vetores de sucesso para refazer:
por exemplo, eles haviam previamente hackeado um banco de Internet de terceiros roubando o código PAN do cartão (os próprios números, número da conta principal), o nome do titular do cartão e pegando a data de validade. Depois disso, já em nosso processamento neste PAN, eles começaram a separar os CVVs. E tudo ficaria bem, após 3 tentativas de estourar as cartas, elas seriam bloqueadas por nosso antifraude. Se apenas ... veja acima.
Em geral, havia muitas dessas histórias engraçadas. Em algum ponto, nossos serviços pararam de resolver e o tempo nos nós parou de sincronizar, e de alguma forma aleatoriamente, de alguns dos hosts.
Claro, a primeira coisa que fizeram foi culpar o erro de configuração, o trabalho incompreensível do cluster.
Com o DNS, o problema foi resolvido rapidamente movendo os pods CoreDNS diretamente para os nós onde esse tráfego não foi disparado, mas com o NTP tivemos sorte - felizmente, não detectamos uma grande defasagem do relógio e, ao criar um cluster, os nós ainda conseguiram sincronizar.
Descobriu-se que, em algum ponto no nível do firewall, as solicitações NTP e DNS de saída foram desativadas para alguns dos nós. Aparentemente, alguém apertou demais as porcas de filtragem.
Outros ataques
Ataques a outros alvos de cidades cibernéticas próximas também tiveram sucesso às vezes, incluindo aqueles, como nós, no sistema financeiro de cidades cibernéticas.
É bom que não confundimos os urls de alerta acima do elástico e no monitoramento, e os vimos com bastante precisão e rapidez.
Por exemplo, como no caso de hackear nosso oligarca e a chave API retirada. Ele foi hackeado às 22,17, horário de Moscou. Às 22h22, nós do nosso lado percebemos isso e imediatamente relatamos aos defensores e organizadores. Percebemos, aliás, graças ao uso torto da API - os hackers passaram um cabeçalho de tipo de conteúdo estranho na primeira solicitação, chamado de um método raro de nossa API, e algumas outras nuances - esse foi o motivo para acionar o alerta.
Quando o sistema funciona normal e automaticamente, raramente coincide tudo ao mesmo tempo. Mas se algo assim acontecer, significa que alguém está brincando com a API com as mãos. Aqui está o alerta e funcionou.
Se não estamos falando de uma cibercidade, mas de situações reais desse tipo, então tudo acontece ainda mais rápido, nesses casos o sistema bloqueia automaticamente as ações do comerciante para que nada seja retirado de sua conta e, a princípio, não prejudique trabalho e negócios de forma alguma, gera pânico conecta funcionários já vivos
Para o futuro
O formato de hacking da cidade cibernética é, sem brincadeira, o futuro da segurança da informação. Com certeza voltaremos aqui, levaremos em consideração todos os erros e pensaremos na infraestrutura e nos esquemas de negócios para que estejam o mais próximos possível da realidade. O ideal é que geralmente as pessoas do Banco Central ou dos Serviços Estaduais cheguem às mesmas conclusões - para testar sua infraestrutura em batalha, oferecer uma oportunidade de encontrar vulnerabilidades e se tornar ainda melhor e mais confiável para usuários e empresas.
E foi muito legal e divertido. Na verdade, recebemos um grande conjunto de casos do Chaos Monkey que não seriam necessariamente reproduzidos na produção, testamos o processamento de ataques, tendo recebido mais ataques em 2 dias do que normalmente recebemos em seis meses.
Aprendemos muito e, o mais importante, vimos que nosso produto, que estamos escrevendo para nós e para você, é popular entre os participantes das cidades cibernéticas, para nossa TI foi uma forte motivação - afinal, é bom quando as pessoas usam o resultado do seu trabalho, mesmo que neste caso e para fins muito específicos.
Gostamos muito e queremos MAIS.
No próximo Standoff, espere por nós com esquemas ainda mais interessantes, mais funções de pagamento e novos vetores de ataque!