Olá pessoal! Meu nome é Vitaliy Malkin. Sou chefe do departamento de análise de segurança da Informzashchita e capitão em tempo parcial da equipe True0xA3. Com este artigo, iniciamos um ciclo de 3 materiais dedicados ao nosso desempenho no PHDays IX Standoff. Neste artigo, explicaremos por que a preparação competente é metade do sucesso, por que é tão importante coletar "frutos" a tempo e como você pode organizar a interação da equipe mais experiente em um único projeto.
O artigo TL; DR contém um grande número de inglesismos e termos técnicos complexos, pelos quais peço desculpas separadamente.
I. Entrada
Tínhamos 16 pentesters selecionados, 4 trainees, 6 servidores, nossa própria estação CUDA e um grande desejo de vencer.
Iniciamos a fase de preparação ativa 8 dias antes do início do StandOff. Esta foi a nossa terceira tentativa como atacante, e muitos de nós já possuíam experiência suficiente para entender o que procurar este ano. Vimos cinco áreas prioritárias para elaboração:
- Coordenação eficaz;
- Coleta de frutas baixas;
- Exploração de vulnerabilidades de tecnologias atípicas (para nós) (ACS TP, IoT, GSM);
- Preparação de infraestrutura e equipamentos externos;
- Adicionar desenvolvimento. métodos de persistência e endurecimento.
Vamos tentar analisar esses itens em ordem.
1. Coordenação eficaz
É mais fácil falar sobre esse ponto, porque a decisão geral de que eu era responsável por sua implementação. Durante o StandOff, o problema mais comum para iniciantes, na minha opinião, é a falta de coordenação. Os membros da equipe resolvem as mesmas tarefas, não há um entendimento claro do que já foi assistido e do que não é. As informações recebidas na tarefa não são transmitidas umas às outras, como resultado, a eficiência do trabalho diminui bastante. E quanto mais participantes, mais a eficiência cai. Além disso, é muito útil ter uma pessoa que entenda bem a imagem geral da infraestrutura e possa vincular vulnerabilidades individuais a um vetor de ataque completo.
Este ano, a plataforma Discord foi escolhida para a interação da equipe. Em geral, é muito semelhante ao bom e velho bate-papo do IRC com recursos adicionais, como upload de arquivos a e comunicação por voz. Pegamos uma descrição de todos os objetos das competições do Agend e criamos um canal para cada um deles, no qual as informações foram postadas. Assim, qualquer pessoa que se conectasse à tarefa poderia ver tudo o que surgia, incluindo os resultados do lançamento de várias ferramentas e pesquisas manuais. Em todos os canais de informações, foi definido um limite de uma mensagem por minuto para evitar inundações. E toda a discussão foi conduzida em bate-papos separados, que também foram criados para cada objeto.
Também foram tomadas várias decisões organizacionais para melhorar a coordenação. Em geral, não é habitual definir tarefas com a redação “NECESSÁRIO” em nossa equipe. Tentamos discutir por que essa ou aquela tarefa está definida, a que sua implementação levará e também como realizá-la com mais eficiência. Porém, dentro da estrutura do StandOff, esse modelo pode levar a discussões desnecessárias, por isso decidimos confiar ao coordenador autoridade completa sobre o processo. Dentro de 28 horas da competição, suas decisões praticamente não foram discutidas, o que certamente nos poupou muito tempo. Embora possa ter afetado a qualidade das comunicações. Além disso, decidimos delinear claramente as áreas de responsabilidade: apesar do fato de alguns membros da equipe não terem as tarefas mais emocionantes.
2. Coleta de frutas baixas
Na minha opinião, o principal segredo do nosso sucesso foi: uma enorme experiência diária de projetos e a correta priorização de tarefas. No ano passado, conseguimos capturar um escritório inteiro e mantê-lo durante todo o jogo simplesmente devido a vulnerabilidades simples hackeadas rapidamente. Este ano, abordamos o problema centralmente e compilamos uma lista dessas vulnerabilidades.
ms17-010; ms08-67; SMBCRY LibSSH RCE; Protectoer HP DATA; HP iLo; ipmi Instalação inteligente da Cisco Java RMI JDWP; JBOSS; drupalgeddon2; weblogic com coração shellshock; ibm websphere iis-webdav; serviços; vnc; ftp-anon; NFS smb-null; Tomcat
Em seguida, foram escritos dois serviços de verificador e penetrador, que de modo automatizado, usando explorações públicas e metasploit, primeiro checaram as vulnerabilidades e depois tentaram explorá-las. O utilitário recebeu um relatório nmap na entrada, o que acabou acelerando o processo.
3. Exploração de vulnerabilidades de tecnologias atípicas (para nós) (ACS TP, IoT, GSM)
Na maioria das vezes, fazemos projetos para bancos e outras organizações financeiras. Os sistemas SCADA, se houver, são mais prováveis no estilo: "Se você conseguiu obter acesso à rede ao scada, corrija isso e conte-o como um dos critérios para o sucesso do projeto". Portanto, não temos uma boa experiência aplicada na análise da segurança dos sistemas de controle de processos. Por sua vez, isso levou ao fato de que uma semana antes do StandOff nos sentávamos com urgência para estudar vulnerabilidades típicas. Com a IoT e o GSM, a situação é ainda pior: se a IoT às vezes é encontrada em projetos, vimos o GSM apenas nos StandOffs anteriores.
Assim, durante a preparação, identificamos duas pessoas separadas no sistema de controle de processo automatizado e mais duas no GSM e IoT. Durante a semana preparatória, o 1º grupo escreveu abordagens típicas para os mais avançados sistemas SCADA e também estudou em detalhes um vídeo sobre a infraestrutura ICS do ano passado. Os caras também lançaram cerca de 200 GB de várias IHMs, drivers e outros softwares diretamente relacionados aos controladores. Quanto ao GSM e à IoT, preparamos aqui várias peças de ferro, lemos todos os artigos disponíveis sobre o GSM e esperamos que isso fosse suficiente. (SPOILER: Na verdade não!)
4. Preparação de infraestrutura e equipamentos externos
Entendendo que nossa equipe será grande o suficiente este ano, decidimos imediatamente que precisávamos de equipamento adicional. A seguir, é apresentada uma lista de sugestões que coletamos dentro da equipe. O sinal "+" indica que finalmente recebemos:
- máquina de café;
+ - servidor CUDA (eles não levaram com eles, mas usaram);
+ laptop de reposição;
+ Roteador Wi-Fi;
+ switch gerenciado;
+ cabos de rede de vários comprimentos (20 peças);
+ piloto (3 peças);
+ Wi-fi Alfa (3 peças);
+ pato de borracha (2 peças);
- proxmark;
uma câmera
Quanto à infraestrutura, esta é uma música separada. No ano passado, percebemos o quão útil é usar uma estação CUDA, quebrando vários apertos de mão, portanto não havia dúvida sobre a necessidade de usá-la. É importante que este ano, assim como no passado, todos os atacantes estivessem por trás do NATth, que geralmente rejeitava a possibilidade de conexões reversas da DMZ. Mas absolutamente todos os hosts devem ter acesso à Internet, exceto os nós do ICS. Nesse sentido, decidimos criar três servidores ouvintes, acessíveis a partir da Internet. Além disso, para simplificar a dinâmica e a consolidação, usamos nosso próprio servidor OpenVpn com o modo cliente a cliente ativado. Infelizmente, é impossível automatizar o processo de conexão de um gateway; portanto, por cerca de 12 horas em 28, um dos membros da equipe estava trabalhando com gateways.
5. Desenvolvimento de add. métodos de persistência e endurecimento
Nossa experiência anterior com o StandOff mostrou claramente que não é suficiente invadir um servidor com êxito: é importante não deixar que outras pessoas se estabeleçam nele. Portanto, foi dada atenção suficiente ao RAT com novas assinaturas e scripts para fortalecer a proteção do Windows. Usamos nosso RAT padrão, alterando ligeiramente os métodos de ofuscação. As regras eram um pouco mais complicadas. Em geral, determinamos por nós mesmos o seguinte conjunto de scripts:
- fechamento de SMB e RPC;
- portando o RDP para uma porta não padrão;
- Desativando criptografia reversível, contas de convidado e outras configurações da linha de base de segurança.
Para Linux, foi desenvolvido um script init especial que fechou todas as portas, abriu o SSH em uma porta não padrão e registrou as chaves públicas do comando para acessar o SSH.
II Briefing
Em 17 de maio, 5 dias antes do StandOff, foi realizado um briefing para os atacantes. No decorrer disso, muitas informações surgiram que influenciaram nosso treinamento.
Em primeiro lugar, os organizadores publicaram um mapa da rede, e isso se tornou uma grande ajuda para nós. Conseguimos dividir as áreas de responsabilidade antecipadamente, atualizar os segmentos da rede e, o mais importante, entender o que é a rede. Na minha opinião, a declaração mais importante feita no briefing foi a frase de que a rede ICS seria acessível a partir de apenas um segmento, e esse segmento não seria protegido. Além disso, o ICS e os escritórios seguros receberão mais pontos, e os organizadores incentivam diretamente a luta por redes entre hackers.
Pegamos essas informações assim: "Quem captura o grande grupo provavelmente ganhará o jogo". O fato é que nossa experiência nos disse: não importa quais punições os organizadores inventariam por um serviço simples, os defensores abandonariam os serviços vulneráveis se não pudessem corrigi-los. Afinal, é muito pior quando eles anunciam, desde o estágio da maior conferência de segurança da informação, que você estragou os hackers do que se eles tirassem alguns pontos do jogo. Nossa teoria foi confirmada, mas falaremos sobre isso em detalhes no 2º artigo.
Como resultado, decidimos dividir toda a equipe em 4 partes:
1. Bigbrogroup. Essa foi a tarefa à qual atribuímos a maior prioridade. A equipe envolveu as pessoas que têm mais experiência em invadir a infraestrutura interna de diferentes clientes. No total, essa mini equipe era composta por 5 pessoas. Seu objetivo era conquistar uma posição no domínio o mais rápido possível e impedir que outras equipes acessassem o ICS.
2. Rede sem fio. A equipe responsável pelo monitoramento do Wi-Fi acompanhou novos pontos, interceptou os apertos de mão e os brutalizou. O GSM também entrou em suas tarefas, mas antes de tudo era necessário capturar o Wi-Fi e interromper outros comandos.
3. Redes desprotegidas. A equipe que durante as primeiras quatro horas escolheu todas as redes desprotegidas quanto a vulnerabilidades. Entendemos que nessas quatro horas nada de importante acontecerá nos segmentos protegidos e, se isso acontecer, os defensores o reverterão. Portanto, eles se concentraram no que poderia ter mudado irreversivelmente. Como se viu - não em vão. Quatro horas depois, o mesmo grupo começou a analisar segmentos protegidos.
4. Grupo de scanners. Os organizadores declararam diretamente que as redes mudarão, então tínhamos duas pessoas que pesquisavam continuamente a rede em busca de mudanças. Não foi tão fácil automatizar, porque em redes diferentes, configurações diferentes eram necessárias em momentos diferentes. Por exemplo, na primeira hora na rede fe.phd, o nmap funcionou bem para nós no modo T3 e, após 12 horas, mal funcionou no T1.
Outro vetor importante para nós foi a lista de software e tecnologias publicada pelos organizadores. Para cada tecnologia, tentamos criar nosso próprio centro de competência, o que poderia ajudar muito rapidamente e ver vulnerabilidades típicas.
Para alguns serviços, encontramos vulnerabilidades muito interessantes, mas não houve explorações públicas. Assim foi, por exemplo, com o RCE pós-exploração Redis. Tínhamos certeza de que essa vulnerabilidade apareceria na infraestrutura de jogos, por isso decidimos escrever nossa própria exploração de 1 dia. Não foi possível escrever um dia especificamente para esta vulnerabilidade, mas no geral, tínhamos cerca de cinco explorações não públicas em mãos que estávamos prontas para usar.
Infelizmente, não conseguimos compartilhar todas as tecnologias, mas não foi tão assustador. Cobrimos o cenário principal, e isso foi suficiente. Havia também uma lista de controladores de processo, que também resolvemos e tentamos preparar para isso.
Em preparação para a batalha, preparamos várias ferramentas para conectar-se perfeitamente à rede física do ICS. Por exemplo, implementamos um análogo barato de abacaxi - usando framboesa. O módulo foi conectado via Ethernet à rede industrial e via GSM ao serviço de gerenciamento. Em seguida, poderíamos configurar remotamente a conexão Ethernet e distribuí-la no local usando o módulo Wi-Fi embutido. Infelizmente, no briefing, os organizadores deixaram claro que você não pode se conectar fisicamente ao ICS, então deixamos este módulo até tempos melhores.
Muita informação era sobre o banco, o banco offshore e o trabalho antifraude. Mas, tendo aprendido que não há muito dinheiro, decidimos não nos preparar para isso com antecedência, mas apresentar algo ao longo do caminho.
Resumindo, fizemos uma quantidade bastante grande de trabalho em preparação. É importante observar que, além das vantagens óbvias na forma de um desempenho bem-sucedido no StandOff, também não havia as óbvias.
- Essa preparação é uma ótima maneira de me distrair e fazer algo que há muito tempo queria tentar explorar, e simplesmente não havia tempo na estrutura da atividade do projeto.
- Não temos projetos que envolvam toda a equipe como parte de uma tarefa; por isso, construímos uma boa equipe, buscando objetivos específicos.
- Muito do que fizemos pode ser usado em projetos reais; portanto, além de expandir nossas competências, também temos ferramentas prontas.
Agora, tendo descrito tudo isso no texto, entendo que não realizamos nada tão grandioso quanto parecia antes. Em geral, parece-me que o estágio de preparação corretamente organizado se tornou o principal motivo da vitória de nossa equipe. E o que aconteceu diretamente durante o StandOff - contarei no segundo artigo do ciclo.