dilan-diaz/point-to-point-protocol-daemon-rce-vulnerability-cve-2020-8597-Trabalho universitário documentando CVE-2020-8597, um estouro de buffer de pilha no analisador EAP do pppd, com uma demonstração de exploração de execução remota de código usando uma configuração de servidor pppoe e cliente.
Sri Lanka Institute of Information Technology
Trabalho 1
M. P. D. M. Dias
IT19165530
MLB_WD_Y2S1_13.1
Execução Remota de Código no Daemon do Protocolo Ponto a Ponto
Vulnerabilidade (CVE-2020-8597)
Programação de Sistemas e Redes – IE2012
Conteúdo
Introdução
O Protocolo Ponto a Ponto (PPP) é um protocolo full-duplex que permite que dados simples sejam encapsulados e distribuídos através da Camada 2 ou infraestrutura de enlace de dados, abrangendo desde conexões discadas até banda larga DSL e redes privadas virtuais (VPNs) que incorporam criptografia SSL. Como estes protocolos não permitem comunicações ponto a ponto, o PPP também é usado para impor IP e TCP sobre dois nós diretamente conectados. Pppd é um daemon usado em sistemas operacionais do tipo Unix para gerenciar o estabelecimento de sessões PPP e a terminação de sessões entre dois nós.
O PPP é o protocolo usado para criar conexões de internet através de modems discados, conexões DSL e várias outras formas de conexões ponto a ponto via Redes Privadas Virtuais (VPN), como o Protocolo de Tunelamento Ponto a Ponto (PPTP). O programa pppd também pode autenticar um par que se conecta à rede e/ou fornecer ao par detalhes de autenticação utilizando vários protocolos de autenticação, como o EAP.
Devido a uma falha no tratamento do pacote do Protocolo de Autenticação Extensível (EAP) pelo Daemon do Protocolo Ponto a Ponto (pppd), um atacante remoto não autenticado pode causar um estouro de buffer de pilha, o que pode permitir a execução arbitrária de código no sistema alvo. Esta fraqueza é desencadeada por um erro na validação do tamanho da entrada antes de copiar os dados fornecidos para a memória. Dado que a validade do tamanho dos dados está errada, dados aleatórios podem ser copiados para a memória, o que pode provocar vazamento de arquivos contribuindo para a execução não intencional de código.
A fraqueza reside na lógica do código de análise do eap, especificamente nas funções eap_request() e eap_response() em eap.c, que são chamadas por um manipulador de entrada de rede. Estas funções, usando o primeiro byte como um tipo, recebem um ponteiro e um comprimento como entrada. Se o tipo for EAPT MD5CHAP(4), então ele analisa uma área embutida de 1 byte de comprimento. A lógica neste código destina-se a garantir que a duração embutida seja menor que o comprimento total do pacote. Após esta verificação, ele tenta copiar os dados fornecidos (hostname), que estão localizados em um buffer local da pilha após o campo de comprimento embutido. Esta verificação de limite é incorreta e permite que a cópia de memória ocorra com um comprimento de dados arbitrário.
Um erro lógico adicional faz com que a função eap_input() não teste se o EAP foi resolvido durante o processo do Protocolo de Controle de Linha (LCP). Isto permite que um atacante não autenticado envie um pacote EAP mesmo que o ppp tenha recusado negociar autenticação devido à falta de suporte para EAP ou devido a uma não conformidade com uma senha pré-compartilhada acordada na fase LCP. Em eap_input, o código inseguro do pppd ainda deve processar o pacote EAP e causar o estouro de buffer de pilha. Estes dados não verificados e de tamanho desconhecido podem ser usados para comprometer a memória do dispositivo alvo. O pppd também é executado com altos privilégios (sistema ou root) e opera em conjunto com drivers de kernel.
O programa pppd também é usado com o projeto LWIP (lightweight IP) para fornecer capacidade pppd em computadores pequenos. A instalação e as instalações padrão do lwIP não são suscetíveis a este estouro de buffer. No entanto, se o código-fonte do lwIP for usado e modificado explicitamente para permitir EAP em tempo de compilação, o programa pode ser suscetível a estouro de buffer.
CVE-2020-8597 é um bug de estouro de buffer no pppd devido a um defeito conceitual no processador de pacotes do Protocolo de Autenticação Extensível (EAP). Um atacante remoto não autorizado que envia um pacote EAP especialmente criado para um cliente ou servidor PPP vulnerável pode causar uma condição de negação de serviço ou uma execução arbitrária de código. Como o pppd opera em conjunto com drivers de kernel e também possui altos privilégios, como dispositivo ou até mesmo núcleo, qualquer execução de código também pode ser realizada com os mesmos privilégios.
Referência sobre quem descobriu a vulnerabilidade
Descoberta pelo Pesquisador de Proteção da IOActive Ilja Van Sprundel, o problema crucial é uma falha de estouro de buffer de pilha que ocorre devido a um erro lógico no analisador do módulo do Protocolo de Autenticação Extensível (EAP) das aplicações pppd, um aprimoramento que oferece suporte para métodos de autenticação adicionais em conexões PPP.
A fraqueza, monitorada como CVE-2020-8597 com Pontuação CVSS 9.8, pode ser abusada por atacantes não autorizados para executar remotamente código arbitrário em dispositivos afetados e obter controle total sobre eles.
Como foi descoberta
Esta fraqueza é atribuída a um erro na validação do tamanho da entrada antes de transferir os dados para a memória. Como a validação do tamanho dos dados está errada, dados aleatórios podem ser copiados para a memória e podem desencadear fragmentação de banco de dados, provavelmente contribuindo para a execução de código não autorizado.
A vulnerabilidade é encontrada na lógica do código de análise do eap, especificamente nas funções eap_request() e eap_response() em eap.c, que são chamadas pelo manipulador de entrada de rede.
É errado concluir que o pppd não é inseguro se o EAP não for permitido ou se o EAP não tiver sido iniciado por um par remoto usando uma senha ou frase secreta. Isto porque um intruso autenticado pode sempre ser capaz de submeter um pacote EAP não solicitado para induzir um estouro de buffer.
A vulnerabilidade foi identificada no daemon do Protocolo Ponto a Ponto (PPP), ou pppd. PPP é um protocolo de Camada 2 usado para estabelecer conexões através de modems discados, conexões DSL e muitas outras redes físicas, incluindo redes móveis. O PPP foi incluído e expandido para incluir protocolos adicionais, como o Protocolo de Tunelamento Ponto a Ponto (PPTP) que é usado em Redes Privadas Virtuais (VPNs) para fornecer conexões criptografadas.
Ao longo desta situação, a equipe de colaboração do SEI CERT fez parceria com o analista de proteção Ilja Van Sprundel (IOActive) que descobriu esta falha e o desenvolvedor de software Paul Mackerras (OZlabs) que gerencia o código-fonte para examinar facilmente o problema e encontrar uma solução alternativa. O problema envolveu um estouro de buffer no código-fonte do pppd devido a um estouro de buffer básico na expressão booleana e na implementação das instruções condicionais que resultaram. A frase abaixo pode ser enganada para permitir feedback de duração desconhecida e copiá-lo para um buffer de pilha. Isso é comumente referido como sobrecarga de quadro ou estouro de buffer de pilha.
if (vallen >= len + sizeof(rhostname)) { // Copiar para o buffer rhostname
A correção para a vulnerabilidade foi simplesmente alterar a declaração acima para a lógica booleana abaixo.
if (len-vallen >= sizeof(rhostname)) { // Copiar para o buffer rhostname
Paul emitiu CVE-2020-8597 para esta falha e continuou a repará-la no código-fonte que gerenciou. A atualização do sistema necessária para corrigir o bug é uma pequena que requer apenas algumas linhas de código. No entanto, esta tecnologia insegura reside em milhares de bibliotecas de projetos de software. Foi adotada por mais de 100 empresas que oferecem dispositivos de acesso à rede, desde roteadores domésticos até hardware de rede empresarial. Como esta fraqueza afeta todos os clientes e servidores PPP, também afeta os Provedores de Serviços de Internet (ISPs).
Quando foi descoberta
Em 4 de março de 2020, pesquisadores do Centro de Coordenação CERT (CERT/CC) publicaram a nota de vulnerabilidade #782301 para vulnerabilidade crítica no Daemon do Protocolo Ponto a Ponto (pppd) versões 2.4.2 a 2.4.8, com divulgação creditada a Ilja van Sprundel da IOActive.
Qual o dano que pode causar
Ao submeter um pacote EAP não solicitado a um cliente ou servidor ppp vulnerável, um intruso remoto não autorizado pode desencadear corrupção de memória no mecanismo pppd, o que pode exigir execução arbitrária de código.
De acordo com o pesquisador, as versões 2.4.2 a 2.4.8 do Daemon do Protocolo Ponto a Ponto — todas as versões publicadas nos últimos 17 anos — são suscetíveis a este novo bug de execução remota de código. Algumas das distribuições Linux comumente usadas e bem-sucedidas mencionadas abaixo já foram relatadas como impactadas, e vários outros projetos provavelmente também são afetados.
Debian Ubuntu SUSE Linux Fedora NetBSD Red Hat Enterprise Linux
Além disso, o número de outras aplicações e dispositivos suscetíveis (alguns dos quais mencionados abaixo) que distribuem apps pppd também é provavelmente vasto, fornecendo uma ampla superfície de ataque para hackers.
Cisco CallManager Produtos TP-LINK SO Embarcado OpenWRT Produtos Synology
Devido a uma falha no processamento de pacotes do Protocolo de Autenticação Extensível (EAP) no Daemon do Protocolo Ponto a Ponto (pppd), um atacante remoto não autenticado pode ser capaz de causar um estouro de buffer de pilha, o que pode permitir a execução arbitrária de código no sistema alvo. Esta vulnerabilidade deve-se a um erro na validação do tamanho da entrada antes de copiar os dados fornecidos para a memória. Como a validação do tamanho dos dados é incorreta, dados arbitrários podem ser copiados para a memória e causar corrupção de memória, possivelmente levando à execução de código indesejado.
Quais são as técnicas de exploração
O problema crítico é uma vulnerabilidade de estouro de buffer de pilha que existe devido a um erro lógico no analisador de pacotes do Protocolo de Autenticação Extensível (EAP) do software pppd, uma extensão que fornece suporte para métodos de autenticação adicionais em conexões PPP.
Para isso, tudo o que um atacante precisa fazer é enviar um pacote EAP malformado não solicitado para um cliente ou servidor ppp vulnerável através de um link serial direto, ISDN, Ethernet, SSH, socket CAT, PPTP, GPRS ou redes ATM. Além disso, como o pppd frequentemente é executado com altos privilégios e funciona em conjunto com drivers de kernel, a falha poderia permitir que atacantes executassem potencialmente código malicioso com privilégios de sistema ou nível root. Qual método de exploração escolheu
Método de execução remota de código usado para explorar o cliente vulnerável. A execução remota de código (RCE) refere-se à capacidade de um intruso cibernético entrar e fazer modificações em um dispositivo controlado por alguém, sem permissão e sem saber onde a máquina está situada. RCE permite que um atacante assuma o controle de um computador ou servidor executando software malicioso (malware) arbitrário.
Eu uso duas máquinas virtuais para testar no mesmo computador. Uma como servidor e uma como cliente. Para conectar máquinas virtuais, instalo ssh. Usando seus endereços IP, conecto a máquina virtual Fedora 29 como lado do servidor e a máquina virtual Kali Linux como lado do cliente vulnerável. Conforme as instruções, configuro um pppoe-server. Após abrir o modo de depuração e definir o arquivo de log, adiciono o seguinte ao arquivo de log ‘/etc/ppp/pppoe-server-options’. Em seguida, configuro um pppoe-client inserindo ‘sudo pppoeconf’. Finalmente, usando o código python, posso explorar o cliente vulnerável. Além disso, ao enviar um pacote EAP não solicitado para um cliente ppp vulnerável, um atacante remoto poderia causar corrupção de memória no processo pppd, o que pode permitir a execução arbitrária de código.
Capturas de tela do exploit
Ping com cliente vulnerável
Instalar SSH no servidor
Obtendo acesso root ao lado do cliente
Após obter o acesso root do cliente
Habilitar SSH no lado do cliente
Crash
Resultado
Conclusão
GitHub Security Lab ao Resgate
Enquanto Vijay Sarvepalli pesquisava a mais recente iniciativa de proteção do GitHub, Vijay Sarvepalli queria identificar oportunidades para alavancar a API e as soluções CodeQL do GitHub para abordar o problema, e ele usou código para propor a correção aos usuários do repositório de software. Ele contatou nosso Líder de Proteção Governamental, Allan Friedman (Diretor de Iniciativas de Segurança Cibernética na Administração Nacional de Telecomunicações e Informação (NTIA) do Departamento de Comércio dos Estados Unidos), que reuniu uma variedade de organizações, incluindo o GitHub, para criar uma Lista de Materiais de Software (SBOM). Allan apresentou Vijay Sarvepalli às pessoas no GitHub que são dedicadas à confidencialidade, e elas me colocaram em contato com o chefe do GitHub Security Lab, Nico Waisman.
Nico e sua equipe internacional no GitHub Security Lab rapidamente encontraram uma maneira de adaptar seu mecanismo de correção de segurança a este problema. Eles acionaram uma tecnologia automática de "robô" que entrou em contato com os proprietários de todos os repositórios afetados por este bug. Os proprietários dos repositórios só precisavam tomar algumas medidas rápidas para corrigir e proteger sua versão copiada ou bifurcada do programa pppd, corrigindo o bug. Esta iniciativa da comunidade nos levou ao estágio em que a tecnologia estava sendo corrigida. Isso ofereceu uma abordagem modular e oportuna para implementar melhorias no código-fonte, a fim de melhorar a proteção. Dentro de quatro dias das atualizações automáticas do GitHub Security Lab, 1.896 proprietários de repositórios receberam detalhes do bug e tiveram a opção de corrigi-lo em alguns cliques. Pelo menos 42 desses proprietários de repositórios aprovaram um patch automático; mais 13 confirmaram que o problema já foi corrigido. Sem automação, levaria vários dias para entrar em contato com os proprietários dos repositórios afetados para corrigir seus aplicativos.
Desafio do DoD e o Papel do CERT no Futuro do Software
Como um centro de pesquisa e desenvolvimento financiado federalmente (FFRDC), o Instituto de Engenharia de Software (SEI) da Universidade Carnegie Mellon e sua Divisão CERT são constantemente confrontados pelos desafios que o Departamento de Defesa dos EUA (DoD) enfrenta no ciberespaço. O CIO do DoD, Terry Halvorsen, um renomado evangelista de segurança cibernética, disse que "ações defensivas cibernéticas e contra-ações ocorrerão em milissegundos" em seu discurso na conferência AFCEA. Essas ações defensivas cibernéticas desejadas não podem ser feitas manualmente ou através de processos de comunicação complicados. Elas devem ser entregues via software e automatizadas o máximo possível para limitar problemas com modelos atuais de correção com humano no circuito.
Ao longo das atividades potenciais de gerenciamento de ameaças, esperamos identificar situações onde podemos tirar vantagem de incentivos (como esta parceria com o GitHub Security Lab) para acelerar a correção do código-fonte contra vulnerabilidades de segurança da informação. Embora entendamos que isso não corrigirá qualquer problema de proteção da informação e não é uma substituição para boas práticas de codificação, percebemos que bugs podem tender a ser encontrados na informação após ela ter sido publicada. Quando a informação é pervasiva em nossas vidas diárias, a informação só pode ser protegida pela identificação rápida de vulnerabilidades — e, se possível, automatizando tanto a identificação quanto a resposta.
Referências
• https://www.kb.cert.org/vuls/id/782301/ • https://thehackernews.com/2020/03/ppp-daemon-vulnerability.html • https://www.tenable.com/blog/cve-2020-8597-buffer-overflow-vulnerability-in-point-to-point-protocol-daemon-pppd • https://insights.sei.cmu.edu/cert/2020/03/security-automation-should-begin-at-the-source.html • https://packetstormsecurity.com/files/156802/pppd-2.4.8-Buffer-Overflow.html • https://www.drizgroup.com/driz_group_blog/what-is-remote-code-execution-attack-how-to-prevent-this-type-of-cyberattack • https://github.com/WinMin/CVE-2020-8597 • http://www.howtodoityourself.org/pppoe-server-how-to-do-it-yourself.html