Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!
CVE-2019-19871-AuditGuide — Guia de Auditoria para a Vulnerabilidade Citrix ADC CVE-2019-19871. Coletado de múltiplas fontes e avaliações de ameaças. Será atualizado à medida que novos métodos surgirem. | Kitploit
Guia de Auditoria para a Vulnerabilidade Citrix ADC CVE-2019-19871. Coletado de múltiplas fontes e avaliações de ameaças. Será atualizado à medida que novos métodos surgirem.
Não existe uma maneira fácil neste momento de provar o que alguém fez. Com 4 exploits públicos, cada um deixa um artefato\assinatura diferente, o que é útil para detecção, mas não é 100%. O ponto importante é lembrar que estes são os exploits públicos que eram privados até o dia 10 e isso também não significa que ainda não existam outros por aí na natureza que as pessoas não estejam compartilhando para ganhos próprios. Exploits são editáveis na maioria dos casos, onde alguém pode alterar o nome do arquivo que será implantado, o nome da conta de usuário, o nome do processo, o caminho da consulta e muitas outras opções, o que significa que as possibilidades de alguém ter explorado o sistema aumentam exponencialmente. Também existem atacantes avançados e atacantes básicos; um fará a limpeza após si mesmo e criará maneiras muito engenhosas de desaparecer no sistema para se esconder da detecção.
Aviso legal: como dito anteriormente, isto não detectará todos os exploits, mas pode ajudar a detectar algumas anomalias se o atacante não modificou os exploits públicos e/ou não fez a limpeza após si mesmo. A maioria dos atacantes usará o exploit padrão, e estes são alguns dos artefatos documentados que podem ser deixados para trás. Esta lista de comandos foi coletada de muitas fontes e será bem dinâmica à medida que outras variantes, soluções alternativas e novos desenvolvimentos surgirem. Podemos contar com esta mudança constante à medida que mais infecções acontecem e mais perícias forem concluídas com um conjunto maior de amostras.
Olhe primeiro para coisas que você não fez. Se você normalmente não faz muita coisa no seu ADC, estes devem estar bem silenciosos; eles podem ter entradas de semanas, meses ou anos atrás, da última vez que você esteve lá. Existem consultas mais precisas logo abaixo. Entenda também que este é um jogo de gato e rato, mesmo neste blog. À medida que divulgamos o que vimos e como identificar os atacantes, eles estão usando essas informações contra nós, mudando suas táticas para evitar a detecção.
Lista Rápida de Verificação de Exploração v1
Verifique sua licença; ouvi dizer que alguns reiniciaram seus dispositivos e na verdade tinham uma licença expirada.
Obtenha um Arquivo de Suporte, também conhecido como Backup: Sistema -> Diagnóstico -> Obter Arquivo de Suporte, e salve esse arquivo.
Todos os comandos abaixo estão no NSCLI e, se você fizer SSH na máquina e usar o Shell, então você pode remover o prefixo Shell.
Verifique a data na máquina para ajudar a correlacionar as descobertas dos logs
a. shell date
Verifique a data de alteração da sua configuração
a. Shell ls -l /netscaler/ | grep netscaler
b. Shell ls -l /nsconfig | grep netscaler
i. Qual é a data do seu netscaler.conf?
ii. Isso parece correto? Procure links de arquivos para outros lugares.
Verifique o arquivo de senhas da conta local
a. Shell ls -lh /etc/passwd
i. Verifique quando o arquivo foi modificado. Se foi depois do exploit e não foi você, então você precisa alterar essa senha o mais rápido possível.
ii. Recomendo alterar a senha de nsroot ou de quaisquer contas locais se qualquer exploit for detectado. Em muitos casos
b. Shell cat /etc/passwd
i. Veja quais contas estão lá.
ii. Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor são os padrão.
Verifique seus Logs
a. shell ls -lh /var/logfile
i. Os arquivos estão lá? Eles são realmente pequenos?
a. Se qualquer um desses arquivos tiver mais ou menos de 8-9 caracteres e um nome de arquivo aleatório, então este é um sinal de um atacante mais avançado que alterou o exploit padrão. Se você vir isso, precisa ajustar sua remediação de acordo. Pwnpzi1337.xml é o nome do arquivo para o exploit Project India
b. shell ls /netscaler/portal/templates/*.xml
i. Não deve haver arquivos XML aqui.
ii. Se infectado, observe as datas dos arquivos aqui.
iii.shell ls -lh /netscaler/portal/templates/
c. shell ls /var/tmp/netscaler/portal/templates
i. Este diretório não deveria existir.
ii. Se infectado, observe as datas dos arquivos aqui.
iii.shell ls -lh /var/tmp/netscaler/portal/templates
d. shell ls /var/vpn/bookmark/*.xml
i. Na maioria das vezes não existe, mas também não deveria ter arquivos XML lá.
ii. Se infectado, observe as datas dos arquivos aqui.
iii.shell ls -lh /var/vpn/bookmark/
e. shell ls /tmp/.init
i. Este diretório não deveria existir.
Trabalhos Cron (Métodos de Persistência)
a. shell cat /etc/crontab
b. shell crontab -l -u nobody
Verificação de Criptomoeda
a. shell top -n 10
i. NSPPE-xx (Packet Engine) deve estar em 100% ou próximo disso; se outro processo estiver lá, você pode ter sido minerado
PCAP
a. Shell find / -name “*.cap”
b. Ajuda a encontrar quaisquer arquivos de captura perdidos que possam ter sido feitos.
c. Este será um sinal de um atacante mais avançado que pode ter estado farejando.
Logs do Shell
a. shell cat /var/log/bash.log | grep nobody
i. procurando por acesso de usuário a partir do usuário nobody.
b. shell gzcat /var/log/bash.*.gz | grep nobody
i. procurando por acesso de usuário a partir do usuário nobody em logs compactados.
Verificação do Log do Apache
a. shell "cat /var/log/httperror.log | grep -B2 -A5 Traceback"
b. shell "gzcat /var/log/httperror.log.*.gz | grep -B2 -A5 Traceback”
c. shell grep -iE 'POST.*.pl HTTP/1.1" 200 ' /var/log/httpaccess.log -A 1
d. shell grep -iE 'POST.*.pl HTTP/1.1" 200 143' /var/log/httpaccess.log -A 1
e. shell grep -iE 'GET.*.xml HTTP/1.1" 200' /var/log/httpaccess.log -B 1
f. shell grep -i '.pl HTTP/1.1" 200 143' /var/log/httpaccess.log | grep POST
i. Todos estes estão procurando por itens específicos quando se trata de mover arquivos .pl e .xml para dentro ou para fora do sistema.
g. shell cat /var/log/httperror.log
i. Isto está olhando o conteúdo bruto do arquivo; no geral, isto é apenas para procurar outros itens que se destaquem.
Scripts Persistentes
a. shell ps -aux | grep python
b. shell ps -aux | grep perl
c. shell ps -auxd | grep nobody
i. Estes são ambos métodos de persistência conhecidos para usar scripts para executar reverse shells e outras tarefas. Você só deve ver o comando grep nesta lista de processos.
i. Olhe a data do arquivo também se algo foi adicionado recentemente.
b. shell cat /etc/passwd
i. Algo parece suspeito, contas locais?
Verifique as Conexões TCP
a. Shell netstat -natu
b. Procure por endereços IP não locais em suas VLANs. IPs internos também devem ser verificados no caso de outra máquina ter sido comprometida.
Verifique seus Perfis de Autenticação
a. Eles estavam configurados para TLS ou SSL e agora estão em PlainText?
i. Vi alguns serem alterados em algumas auditorias e online.
ii. Este também é um sinal de um atacante avançado.
b. Isto se relacionará de volta ao fato de sua configuração ns.conf ter sido alterada ou não, felizmente.
c. Se estava em PlainText antes, então você precisa trabalhar para configurá-lo para TLS e SSL o mais rápido possível, encontre sinais de exploits ou não.
Verifique seus Certificados
a. Estes são os Certificados SSL que você pode querer reemitir, especialmente se sua máquina foi explorada.
b. Recomendo que, se você tiver quaisquer sinais de exploração, reemita seus certificados SSL. Algumas implantações maiores podem ter um caminho mais difícil pela frente por causa do número de outros lugares aos quais esse Certificado está vinculado e das possíveis indisponibilidades\interrupções que uma alteração de certificado SSL pode causar.
c. Vi alguns clientes não reemitirem porque tinham bons logs para poder provar que não fizeram nada além de executar o exploit e não migraram para a configuração do sistema. A maioria dos clientes pode ter apenas alguns dias de
Verifique seu Arquivo de Configuração para Potenciais Alvos de Nível 1
a. Veja seu ns.conf e isso criará sua lista de Alvos de Nível 1, que provavelmente foi acessada primeiro se o dispositivo foi explorado.
Se Explorado
O que você precisa fazer sempre variará com base no seu cenário de ameaças. Aqui estão alguns dos meus pensamentos que tenho dito a clientes que encontraram evidências de um exploit executado.
Quais órgãos de conformidade cobrem seu negócio? Finanças\Bancos, SOX, PCI, HIPPA, Leis Estaduais/Locais e Governamentais.
Se você está sob um destes marcos regulatórios, então você precisa seguir esses procedimentos para esses órgãos de conformidade. Também há considerações éticas baseadas em quais certificações e grupos profissionais você faz parte que têm disposições para resposta a incidentes e divulgação.
Uma coisa que sabemos até agora é que por volta de 1-10-20 o primeiro exploit público foi divulgado e há alguns relatos de infecções no dia 9, pois foi exatamente quando ele saiu. Na maioria dos casos, o risco é muito menor se você corrigiu seu sistema antes de 2020 em comparação com mais tarde neste mês.
Rampa de Risco Estimado da Ameaça CVE-2019-19781
17 de dezembro a 31 de dezembro – Menor Risco de Exploração
1 a 8 de janeiro – Risco Menor de Exploração
9 a 13 de janeiro – Risco Maior de Exploração
14 de janeiro até o presente – Maior Risco de Exploração
Isto deve entrar em seu processo para seus próximos passos.
Encontrei vestígios de uma exploração. E agora?
Isto ainda depende; uma coisa que a maioria das implantações do Citrix ADC não configura é um bom logging de SNMP e SYSLOG, e elas podem não ter uma boa maneira de pesquisar, filtrar ou alertar se artefatos forem encontrados. Se você tem logging absoluto e está confiante de que eles não fizeram nada, então você pode ser capaz de seguir com sua vida. Então, se você encontrou algo e foi capaz de remover com confiança o acesso remoto deles, então você poderia seguir em frente.
Mas a maioria descobrirá que encontrará alguns rastros e pode não ser capaz de conectar os pontos sobre o que foi feito e para onde eles podem ter ido, e pode ser mais fácil após a detecção simplesmente redefinir os dispositivos.
Meu Próximo Conselho mudará nas próximas 2 semanas.
Caminhos de Exemplo de Resposta a Incidentes
Não há uma resposta certa e perfeita que eu possa dar que se ajuste à situação de todos; estes são meus pensamentos neste momento, em 1-19-20, e eles podem mudar depois disto à medida que eu aprender mais sobre os próximos passos e à medida que coisas forem divulgadas no lado da defesa e/ou do ataque relacionadas a esta vulnerabilidade. Não há resposta certa; segurança de TI é a terra, como a maioria das terras, que é governada por "depende". Eu recomendo fortemente que, se você encontrar qualquer outra coisa além destes arquivos apenas nesses 3 diretórios, considere a máquina comprometida e siga o caminho mais cauteloso. Em alguns destes, estou sugerindo seguir o caminho mais cauteloso, especialmente quando não há logs para confirmar o que eles fizeram ou não. Você precisa trabalhar com sua equipe para decidir o melhor curso de ação com base em sua situação, porque isto é um esporte de equipe. Sempre pode haver uma maneira melhor de corrigir coisas assim, mas com base nas evidências que você tem no dispositivo e ao redor do dispositivo (Alvos de 1º Nível), então você pode estar bem reduzindo seu risco e seguindo a partir daí.
Mitigar: Este deve ser o ponto de partida, não importa o quê. Com o novo firmware ou a política de responder.
Exploits Detectados Durante sua Auditoria.
- Inicie seu processo de resposta a incidentes.
Com Bom Logging do Dispositivo
Sinais de Ataques Avançados ou Persistência
Construir Novo e Migrar
Sem Sinais de Ataques Avançados ou Persistência
Remediar e Continuar Executando
Sem Logging do Dispositivo
Sinais de Ataques Avançados ou Persistência
Construir Novo e Migrar
Restauração de Fábrica
Sem Sinais de Ataques Avançados ou Persistência
Construir Novo e Migrar
Restauração de Fábrica
Com Bom Logging de Alvos de 1º Nível
Sinais de Ataques Avançados ou Persistência
Construir Novo e Migrar
Restauração de Fábrica
Sem Sinais de Ataques Avançados ou Persistência
Remediar e Continuar Executando
Sem Logging de Alvos de 1º Nível
Sinais de Ataques Avançados ou Persistência
Construir Novo e Migrar
Restauração de Fábrica
Sem Sinais de Ataques Avançados ou Persistência
Construir Novo e Migrar
Restauração de Fábrica
Definição de Resposta e Pensamentos
Construir Novo e Migrar – Inicie seu processo de resposta a incidentes e então você pode iniciar este processo https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html. Isto é relativamente fácil para clientes VPX e SDX por causa da natureza virtual e da flexibilidade da plataforma de configuração. Migrações MPX são uma história diferente por causa de como a restauração de fábrica funciona e a imagem base é mantida; pode haver um risco muito baixo se foi um atacante avançado que persistiu através de uma atualização de firmware e/ou restauração de fábrica. A probabilidade pode ser menor, mas ainda é possível (como qualquer coisa no mundo cibernético).
Restauração de Fábrica – Inicie seu processo de resposta a incidentes e remova os arquivos .xml e qualquer outra coisa detectada, reinicie e verifique a persistência novamente. Então inicie o processo para fazer a restauração de fábrica. Existem scripts que podem ser obtidos da Citrix que passarão pelo processo. Isto limpará o sistema ao nível mais baixo antes de recarregar o sistema operacional, mas todos confiarão neste método até agora com base em seu cenário de ameaças e podem querer mais.
O método mais drástico seria fazer RMA dos dispositivos para que os drives sejam recarregados, e isto pode ser uma boa ou má ideia com base em seu ciclo de vida, plataforma e seu plano de redundância também. Eu só sugeriria isto se você viu técnicas avançadas usadas e confirmou movimento lateral com base em suas técnicas para possivelmente seguir por este caminho. Sei que a Citrix está trabalhando em opções de "e se" e
Remediar – Inicie o processo de resposta a incidentes e remova os arquivos .xml e qualquer outra coisa detectada, reinicie e verifique a persistência novamente. Se você tem bons logs, então saberá se algo foi feito; se não, então eu olharia seu cenário de ameaças e se você tem logging em Alvos de 1º Nível ou qualquer outra coisa para saber se você precisa considerar que seja necessária uma restauração de fábrica e/ou se você precisa construir novo e migrar.
Níveis de Logging
Bom Logging Local
Você está na melhor posição para ver o que aconteceu localmente para saber se houve quaisquer tentativas de movimento lateral ou se o exploit foi apenas executado como a maioria.
Bom Logging de Alvos de 1º Nível
Você está na melhor posição para ver se o movimento lateral aconteceu ou foi mesmo tentado. Estes devem ser as primeiras coisas que podem ser alvo, e se você viu movimento lateral bem-sucedido, então você deve estar mais preocupado e prosseguir com mais cautela em seu caminho de remediação. Se não, então você pode reduzir o risco da ameaça e apenas seguir o caminho de remediação.
Sem Logging Local
Você está na pior posição para ver o que aconteceu localmente para saber se houve quaisquer tentativas de movimento lateral ou se o exploit foi apenas executado como a maioria. Você tem que prosseguir com mais cautela em seu caminho de remediação.
Sem Logging de Alvos de 1º Nível
Você está na pior posição para ver se o movimento lateral aconteceu ou foi mesmo tentado. Estes devem ser as primeiras coisas que podem ser alvo, e se você viu movimento lateral bem-sucedido, então você deve estar mais preocupado e prosseguir com mais cautela em seu caminho de remediação.
Espero que as pessoas possam remover a infecção e ter logging bom o suficiente para se sentirem confiantes de que não estão mais lá dentro e possam retomar suas atividades normais sem algumas destas etapas.
Outros Bons Passos de Acompanhamento
Há duas coisas principais sobre as quais você precisa tomar uma decisão se houver quaisquer vestígios de exploração.
Alterar a Senha do NSROOT
a. Recomendo fazer isto não importa o que você encontre ou quais logs você tenha. Esta é uma chance de colocar nsroot na rotação para mudanças de senha. O Gerenciamento do ADC deve ser vinculado ao LDAP e o NSROOT só deve ser usado para emergências.
Alterar a Conta de Serviço do LDAP (ou outro serviço de autenticação)
a. Altere esta senha; junto com isso, recomendo alterar para outra conta, se possível, para que você também tenha um SID diferente. Isto pode ser uma alteração passiva sem que ninguém perceba se for testada antes da implementação.
Alterar as Chaves SSL
a. Bom Logging
i. Talvez você esteja bem se estiver 100% seguro de que é bom.
ii. Ainda há uma parte de mim que quer dizer para reemitir todas as coisas, mas sei o quanto de trabalho isso pode ser em um ambiente grande.
b. Sem Logging
i. Acho que você tem que reemitir tudo lá. Há proteção PEM e PFX, mas vi muitos lugares que usam senhas muito simples para essas e que podem ser forçadas offline. Já que não sabemos, precisamos proteger a empresa.
Pensamentos sobre Senhas
Recomendo alterar suas senhas para todas as suas contas locais na máquina se houver qualquer indício de um exploit bem-sucedido. Vá em frente e altere, porque em muitas implantações ela pode nunca ter sido alterada desde que foi originalmente implantada há 4-7 anos. Se você vir sinais de acesso por linha de comando e/ou adulteração, você pode muito bem contar com o atacante sendo capaz de quebrar a senha; em firmwares Pré 11.0 ela era AES256 e em builds posteriores está usando AES512, que também pode ser suscetível a quebra. Certifique-se também de que está vinculado ao LDAP com segurança e que você tenha alertas configurados para logins do NSROOT.
Pensamentos sobre LDAP
Se você viu alguns níveis de exploração, eu também garantiria e alteraria qualquer conta de serviço que foi definida dentro da configuração do Citrix ADC. A mais comum é a conta de vínculo LDAP\Kerberos. Alguém conseguir executar um exploit em um Citrix ADC não significa que eles são Administradores de Domínio, mas pode não levar muito tempo dependendo de seus controles e logging. Esta é uma alteração muito fácil que, se testada, pode ser transparente para os usuários.
Pensamentos sobre Certificados
Dependendo do que você encontrou com sua auditoria, isso ajudará a resolver este também. Se você tinha bom logging e pode ver acesso solicitado a este arquivo, então você deve reemitir. Se você não tem bom logging, então você também deve reemitir. Se você tem um certificado curinga, então esse também é outro grande problema, e quanto mais sites ele estiver vinculado, maior será seu risco e exposição. A pior coisa que pode acontecer é que você assuma que está tudo bem e alguém esteja montando um site de phishing com seu certificado, e todo o seu treinamento não impedirá os cliques. Isto pode levar a problemas muito maiores se alguém tiver acesso aos seus certificados, e eu sugeriria prosseguir com cautela e fazer uma reemissão. Este pode ser um momento ok com base na data de expiração do certificado atual. Vi alguns trocarem para outro registrador de certificados neste processo apenas para mudar as coisas, mas eles tinham logs de que o arquivo foi acessado e baixado, junto com outras técnicas avançadas que foram detectadas.
Créditos ###Por último, mas não menos importante, alguns créditos para algumas das pessoas que têm trabalhado nesta questão desde que ela surgiu. Há muito mais pessoas que não estão nesta lista porque estão nos bastidores e que eu também não vi.
Citrix Team – Trabalhando para divulgar as informações, além de trabalhar nesses novos firmwares. Eles precisam trabalhar em 5 patches ao mesmo tempo, com base nas diferenças entre as famílias de código, o que torna isso muito mais difícil.
Daniel Weppeler @_DanielWe – Registro da Política do Responder para Detectar Sondas\Ataques
Florian Roth @cyb3rops – Arquivo YAR do Nessus para Detecção de Exploração
CTP Anton van Pelt @AntonvanPelt & CTA Mads Petersen @mbp_netscaler & Jan Tytgat
@jantytgat – Trabalho constante com as equipes CTP\CTA e Citrix para atuar em muitas frentes.
KevTheHermit @KevTheHermit – Divulgação da vulnerabilidade de senha de instância da AWS além do CVE
Kevin Beaumont @GossiTheDog – Muita promoção dos problemas observados, juntamente com alguns detalhes sobre o honeypot dele e o que ele viu.
Mpgn @mpgn_x64 – Detalhes sobre o exploit e variações dos exploits
Nick Carr @ItsReallyNick – Detalhes sobre o exploit e dicas de resposta a incidentes.
Digi Cat u/digicat – Usuário do Reddit, incrível blog de notícias em tempo real.
Ben Sadeghipour @NahamSec – Vídeo no YouTube sobre DFIR e outras contribuições
SANs Team – Artigos e vídeos de DFIR e Deep Dive
Craig Dods @0xCraig – Implicações e Pesquisa sobre Senhas
Manuel Kolloff @manuelkolloff – Walkthroughs de exploração e pós-exploração.
FireEye e Mandient Equipe, obrigado a Rick Cole por criar nossa primeira cobertura de detecção e à equipe de respondedores a incidentes da Mandiant pelas contribuições para este blog—especialmente Austin Baker, Brandan Schondorfer e John Prieto—e a todos os consultores que estão respondendo ou protegendo os ambientes de seus clientes contra esta vulnerabilidade. Agradecemos também a Nicholas Luedtke, da nossa equipe de Inteligência de Vulnerabilidades, pela assistência no refinamento da linha do tempo de divulgação e ferramentas deste blog.
vdisec/cve-2019-19871-auditguide
