Ataques a sistemas UNIX via CUPS

 (evilsocket.net)
1 pontos por GN⁺ 2024-09-27 | 1 comentários | Compartilhar no WhatsApp
  • Se o caminho de descoberta automática de impressoras do CUPS se combinar com a falta de validação de atributos IPP, um invasor remoto não autenticado pode injetar configurações maliciosas de impressora e até induzir a execução de comandos arbitrários durante a impressão
  • O ponto de partida do ataque é o comportamento do cups-browsed, que recebe pacotes de qualquer origem na porta UDP 631 e envia uma requisição IPP Get-Printer-Attributes para uma URL controlada pelo invasor
  • As vulnerabilidades se dividem em CVE-2024-47176, CVE-2024-47076, CVE-2024-47175 e CVE-2024-47177, encadeando-se pela geração de PPD em libcupsfilters, libppd, cups-filters até o fluxo de execução do foomatic-rip
  • O impacto abrange a maioria das distribuições GNU/Linux, alguns BSDs, Oracle Solaris e possivelmente Chromium/ChromeOS; em varreduras públicas de IPv4, foram observados callbacks de centenas de milhares de dispositivos e picos de 200 mil a 300 mil clientes simultâneos
  • Na prática, recomenda-se desativar ou remover o cups-browsed quando ele não for necessário e atualizar os pacotes do CUPS; se a atualização for difícil, vale considerar o bloqueio da UDP 631 e, se necessário, do tráfego DNS-SD

Núcleo da cadeia de vulnerabilidades

  • Essa cadeia começa no recurso de descoberta automática de impressoras do CUPS e segue pelo processamento de atributos IPP, geração de arquivos PPD e execução de filtros
  • As principais vulnerabilidades se encaixam em quatro etapas
    • CVE-2024-47176: o cups-browsed 2.0.1 ou anterior faz bind em UDP INADDR_ANY:631 e confia em pacotes de qualquer origem, disparando uma requisição IPP Get-Printer-Attributes para uma URL controlada pelo invasor
    • CVE-2024-47076: cfGetPrinterAttributes5 do libcupsfilters 2.1b1 ou anterior repassa ao sistema CUPS atributos recebidos do servidor IPP sem validação nem sanitização
    • CVE-2024-47175: ppdCreatePPDFromIPP2 do libppd 2.1b1 ou anterior grava atributos IPP em um arquivo PPD temporário sem validação nem sanitização, permitindo a inserção de dados controlados pelo invasor
    • CVE-2024-47177: o foomatic-rip do cups-filters 2.0.1 ou anterior permite a execução de comandos arbitrários por meio do parâmetro FoomaticRIPCommandLine no PPD

Ponto de entrada do ataque e alcance do impacto

  • Um invasor remoto não autenticado pode trocar silenciosamente a URL IPP de uma impressora existente por uma URL maliciosa ou fazer com que uma nova impressora seja instalada
  • A execução efetiva do comando ocorre quando um trabalho de impressão é iniciado naquele computador
  • Há dois vetores de entrada
    • WAN / Internet pública: o invasor remoto envia pacotes para a porta UDP 631, sem necessidade de autenticação
    • LAN: um invasor local pode falsificar anúncios zeroconf, mDNS e DNS-SD e chegar ao mesmo caminho de código até o RCE
  • O CUPS e o cups-browsed são empacotados em vários sistemas do tipo UNIX
  • Após varrer várias vezes por dia toda a faixa IPv4 da internet pública durante algumas semanas, observou-se que centenas de milhares de dispositivos faziam callback após o envio de pacotes UDP, com picos de 200 mil a 300 mil clientes simultâneos

O caminho deixado aberto pelo cups-browsed

  • Em um notebook Ubuntu, ao executar netstat -anu, foi encontrada uma porta UDP escutando em 0.0.0.0:631
  • Ao verificar com lsof -i :631, confirmou-se que a TCP 631 era usada pelo cupsd e a UDP 631 pelo cups-browsed
  • Em ps aux, o processo cups-browsed aparecia em execução como root
  • O cups-browsed faz parte do sistema CUPS e tem a função de descobrir novas impressoras e adicioná-las automaticamente ao sistema
  • A inspeção do código-fonte mostrou que o serviço fazia bind em INADDR_ANY:631 UDP e esperava pacotes UDP no formato HEX_NUMBER HEX_NUMBER TEXT_DATA
  • Com o arquivo de configuração padrão quase todo comentado, as restrições de acesso acabam ficando, na prática, bastante fracas

Problemas de parsing e bugs adicionais

  • O próprio pacote CUPS está incluído no oss-fuzz, mas o cups-browsed aparentemente não tem cobertura de fuzzing
  • Ao criar um alvo de fuzzing baseado em AFL em torno de process_browse_data, cinco entradas dispararam stack-buffer-overflow
  • A causa apontada foi um fluxo em que a desreferenciação de ponteiros ocorria antes da verificação da condição de término em dois loops
  • Depois disso, também foram encontrados um race condition e um possível DoS em um ponto de locking
  • Esses problemas foram reportados aos desenvolvedores e ao CERT, mas, segundo o pesquisador, ainda não haviam sido reconhecidos nem corrigidos

Requisições IPP e injeção de PPD

  • found_cups_printer trata como URL um dos campos de texto extraídos do pacote UDP
  • Essa URL e os dados associados passam pelo fluxo examine_discovered_printer_record, create_remote_printer_entry e chegam à chamada cfGetPrinterAttributes do libcupsfilters
  • Se o invasor enviar um pacote no formato 0 3 http://<ATTACKER-IP>:<PORT>/printers/whatever, o cups-browsed do alvo se conectará à URL do invasor
  • Durante a conexão, o cabeçalho User-Agent incluía a versão do kernel e a arquitetura, e em algumas requisições também foi observado o nome de usuário do alvo
  • O Internet Printing Protocol é o protocolo de comunicação entre cliente e impressora ou servidor de impressão, usado para consultar o estado da impressora e enviar trabalhos de impressão
  • O sistema alvo reconhece o servidor do invasor como se fosse uma impressora e envia uma requisição Get-Printer-Attributes encapsulada em HTTP
  • Ao responder com atributos controláveis usando o pacote Python ippserver, a impressora falsa foi adicionada à lista local sem qualquer notificação ao usuário

PPD e o caminho de execução do foomatic-rip

  • Os logs de depuração mostravam a criação da fila de impressão, a geração do arquivo PPD temporário e o processo de uso e edição do PPD
  • A função create_queue passa atributos IPP para a API ppdCreatePPDFromIPP2 do libppd
  • ppdCreatePPDFromIPP2 grava no arquivo PPD atributos de texto controlados pelo invasor, como printer-make-and-model, sem validação nem escaping
  • O arquivo PostScript Printer Description é um arquivo de texto que descreve os recursos e capacidades da impressora e, no CUPS, define funcionalidades e forma de uso da impressora
  • Entre várias diretivas do PPD, a extensão do CUPS cupsFilter2 pode executar binários sob /usr/lib/cups/filter como filtros durante o trabalho de impressão
  • O foomatic-rip é tratado como um filtro capaz de executar comandos por meio da diretiva FoomaticRIPCommandLine no PPD
  • No passado, o foomatic-filters recebeu correções relacionadas a CVE-2011-2964 e CVE-2011-2697, mas foi confirmado que essas correções não foram portadas durante a integração com o CUPS
  • A CVE-2024-35235, mais recente, também menciona execução de comandos arbitrários via FoomaticRIPCommandLine
  • Segundo a explicação dos desenvolvedores do CUPS, restringir o que pode ser fornecido em FoomaticRIPCommandLine é muito difícil sem quebrar drivers existentes, e é possível que centenas de modelos antigos de impressora anteriores a 2010 dependam apenas do Foomatic

Fluxo de reprodução do RCE

  • A cadeia de RCE é composta por três etapas
    • fazer o sistema alvo se conectar ao servidor IPP malicioso do invasor
    • retornar strings de atributos IPP controladas pelo invasor para inserir diretivas no arquivo PPD temporário
    • quando um trabalho de impressão for enviado para a impressora falsa, as diretivas do PPD e o comando serão executados
  • Na configuração do servidor IPP, a execução de comandos é montada fechando a string do PPD, inserindo uma nova linha e depois adicionando as diretivas FoomaticRIPCommandLine e cupsFilter2
  • O alvo da demonstração era um Ubuntu 24.04.1 LTS totalmente corrigido com cups-browsed 2.0.1, e a execução de comandos foi obtida a partir da máquina do invasor
  • Esse fluxo só se estabelece quando várias etapas de processamento de cups-browsed, libcupsfilters, libppd e cups-filters se encaixam em sequência

Mitigação e recomendações

  • Se o cups-browsed não for necessário, recomenda-se desativar o serviço e removê-lo
  • Os pacotes CUPS do sistema devem ser atualizados
  • Se não for possível atualizar e o serviço for necessário, deve-se bloquear o tráfego UDP 631
  • Dependendo do cenário, também é possível bloquear tráfego DNS-SD, embora isso possa ser difícil em ambientes que usam zeroconf
  • Como recomendação pessoal, o pesquisador afirma que removerá de seus sistemas os serviços, binários e bibliotecas do CUPS e deixará de imprimir para sistemas UNIX
  • Ele também acrescenta que removerá listeners de zeroconf, Avahi e Bonjour

Processo de divulgação e trabalhos seguintes

  • Embora a pesquisa em si tenha levado poucos dias, depois de abrir um advisory de segurança no repositório OpenPrinting cups-browsed em 5 de setembro e iniciar a divulgação responsável, a publicação levou 22 dias
  • A discussão relacionada se estendeu para advisories de segurança de cups-browsed, libcupsfilters, libppd e cups-filters
  • A pesquisa consumiu 2 dias, o exploit funcional teve 249 linhas, e o processo de divulgação gerou discussões, e-mails, mensagens e mais de 100 páginas de texto
  • Sobre a controvérsia da pontuação CVSS 9.9, foi explicado que a nota inicial 9.9 foi uma estimativa de um engenheiro da RedHat no relatório VINCE, revisada por outro engenheiro
  • O pesquisador avalia que o 9.9 inicial provavelmente decorreu da facilidade de exploração do RCE e da ampla presença dos pacotes, mas acrescenta que, em termos de impacto, ele próprio não classificaria o caso como 9.9
  • Ele afirma que o relatório exato em Markdown e o exploit compartilhados apenas com o CERT VINCE vazaram
  • O exploit.py inicial apenas enviava pacotes UDP e criava um servidor IPP malicioso, mas depois foi transformado em ferramenta com a adição de anúncios zeroconf
  • Mais tarde, ele foi reescrito em Go e integrado ao bettercap, com recursos para se passar de forma transparente por serviços anunciados via zeroconf, Bonjour e Avahi na LAN, além de processamento relacionado a IPP
  • No próximo texto, o autor pretende abordar o ataque ao Apple macOS com um módulo do bettercap ainda não publicado, mas o cronograma permanece indefinido por causa de outros processos de divulgação

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-27
Opiniões no Hacker News

  • Achei que fosse piada. A descrição diz que “um atacante remoto não autenticado pode alterar a URL IPP de uma impressora existente para uma URL maliciosa, ou instalar uma nova, possibilitando a execução de comandos arbitrários quando um trabalho de impressão for iniciado naquele computador”, mas Heartbleed foi 7,5, então não parece fazer sentido isso ser 9,9
    O tweet original falava em “execução remota de código não autenticada em todos os sistemas GNU/Linux etc.”, mas, na prática, em muitas distribuições o CUPS fica vinculado apenas ao loopback ou nem sequer vem instalado
    Também dizem que varreram todo o IPv4 público várias vezes ao dia por algumas semanas e receberam callbacks de centenas de milhares de dispositivos; se entendi corretamente, isso significa que havia cerca de 300 mil instâncias de CUPS abertas em todo o IPv4 público, e, para ocorrer execução remota de código, esse servidor CUPS teria que receber um trabalho de impressão, então imagino que na maioria dos casos isso não aconteça

    • Lendo o texto, é mesmo algo bem ruim, mas parece mais um caso de que o daemon cups-browsed precisa deixar de existir e de que o ecossistema Linux precisa discutir seriamente o futuro do CUPS
      Os bugs parecem surpreendentemente simples e, no fim das contas, são questões de segurança bastante graves, mas a resposta upstream não está no nível que se esperaria de um pacote de Linux desktop instalado por padrão
      Ainda assim, definitivamente não é um pânico CVSS 9,9 que paralisa o mundo
    • Sendo justo, o autor também disse algo como “eu não classificaria como 9,9 com base no impacto, mas, na verdade, o que eu sei?”
    • Também há um buffer overflow explorável sem ação do usuário. O caminho do foomatic que exige um trabalho de impressão era apenas um dos mais fáceis de escanear e explorar
    • Ri muito do meme “Look at me, I'm the printer now”. Independentemente da avaliação de severidade, pelo menos a piada foi certeira
    • Heartbleed é vazamento de memória; isto é execução remota de código completa sem ação do usuário. Execução remota de código obviamente significa vazamento total de informações e mais
      Mais precisamente, a execução é adiada até a próxima vez que o usuário imprime na própria impressora usando a configuração alterada pelo atacante, e a vulnerabilidade está no cupsd-browser, não no cupsd
      Pode haver problema na postura do autor, mas a vulnerabilidade em si é, sim, algo muito sério

  • Quem expõe CUPS à internet já está num nível de descuido que CVE nenhuma consegue alcançar

    • O serviço vulnerável em questão parece escutar em 0.0.0.0, e isso é preocupante. Significa que, por padrão, ele é vulnerável a ataques na LAN e, se o servidor estiver exposto à internet, é preciso bloquear explicitamente a porta 631
      Claro, para disparar o ataque, o usuário precisa imprimir alguma coisa, e pessoalmente acho que nunca imprimi nada no Linux, mas a alegação de terem recebido callbacks de centenas de milhares de máquinas Linux parece plausível
    • Neste caso, “expor CUPS à internet” soa como “rodar um desktop Linux conectado à internet”. Eu não faria isso, mas não chega a ser uma loucura, e dá para esperar que uma instalação Debian desktop padrão seja suficientemente segura mesmo sem firewall
      No mínimo, acho que um notebook Linux não deveria ficar altamente vulnerável a todos os outros dispositivos em lugares como o Wi‑Fi de aeroporto
    • Quem vai a um café e usa Wi‑Fi público está, na prática, expondo o CUPS e pode ser explorado. Simplesmente descartar o problema não ajuda ninguém
    • De forma absurda, o CUPS roda como daemon de sistema, não como um programa de usuário fortemente sandboxed
    • Ainda assim, para movimento lateral e elevação de privilégios, é uma vitória completa

  • Dependendo de como se interpreta a métrica Scope do CVSSv3, parece ser mais precisamente 8,8 ou 9,6
    Em resumo, em algumas variantes de Linux desktop, o CUPS exposto na LAN sobe em 0.0.0.0, roda como root e é vulnerável a execução remota de código não autenticada. Na maior parte dos Linux voltados a servidor, como Ubuntu Server ou CentOS, não é um serviço padrão, mas parece iniciar por padrão na maioria das distribuições Linux de desktop
    Para acionar a execução remota de código, o usuário da máquina Linux vulnerável precisa imprimir um documento depois da exploração
    evilsocket disse ter recebido centenas de milhares de callbacks, e, mesmo que a maioria de nós quase nunca imprima no Linux, um impacto desse tamanho pode ser suficiente para formar uma grande botnet

    • Em universidades há muita gente usando desktops Linux com IP público e imprimindo continuamente artigos, textos próprios ou textos de outras pessoas
    • A participação do Linux desktop é de cerca de 4,5%, mesmo excluindo ChromeOS. Mesmo que a maioria de nós não imprima, ainda deve haver bastante trabalho de impressão saindo de hosts Linux
    • Heartbleed foi 7,5 e isso fica só 0,4 abaixo do caso xz; não entendo como isto poderia ser 9,6

  • Eu estava com o cupsd aberto para a internet e entrei em leve pânico ao ver a notícia, mas, como no título daqui, este problema também foi comunicado de forma equivocada em parte. O problema não está no cupsd central, e sim no cups-browsed, que é um pacote/componente separado
    No Gentoo Linux que uso para servidor, o cups-browsed é oferecido como pacote separado, e, como não o instalei, não sou afetado. A maioria dos usuários de CUPS que não instalou esse pacote adicional também não é afetada por este bug
    Dizer que todo sistema que roda CUPS pode ser hackeado é representar mal a escala

    • O Debian é até conservador, mas sempre me incomodou que, ao instalar o cups, normalmente o cups-browsed venha junto por padrão. Parece que “no install recommends” resolve, mas, se bem me lembro, drivers adicionais como o hplip acabam puxando isso de novo
      Em casa, eu simplesmente deixei o serviço desativado, mas é bem irritante ver cada vez mais software fugindo do escopo e transformando em obrigatório aquilo que deveria ser opcional
      Um exemplo parecido é o avahi-daemon. Se você tentar removê-lo no Debian/Ubuntu desktop, é provável que acabe removendo junto outros softwares em que é difícil entender por que avahi deveria ser uma dependência forte

  • A parte que diz que “espera-se demais dos pesquisadores, e isso é tratado como algo natural, por causa de triagers que agem como se pesquisadores de segurança como você tivessem de ‘provar que valem ser ouvidos’” é compreensível, mas também existe uma realidade lamentável
    Para cada relatório bem pesquisado como esse, chegam 57 relatórios de spam de baixa qualidade tentando arrancar recompensas de bug bounty ou colocar a descoberta de um CVE no currículo. Especialmente com o aumento dos LLMs, esse tipo de spam consegue enganar com facilidade
    É uma situação triste, mas é difícil culpar totalmente os desenvolvedores por serem céticos

  • Em resumo, o cups-browsed escuta na porta UDP 631 e pode instalar impressoras automaticamente sem confirmação do usuário
    Um invasor usa esse “recurso” para instalar, sem confirmação do usuário, uma impressora falsa com um driver customizado que pode ser baixado de um host arbitrário, e especifica o comando a ser executado quando um trabalho de impressão for enviado
    Se o usuário imprimir algo nessa impressora falsa, esse comando é executado

    • Como o CUPS foi introduzido em 1999, talvez naquela época a instalação automática sem confirmação do usuário fizesse sentido. Mas não sei por que isso ainda existe hoje

  • Neste caso, parece que as distribuições incluíram o cups-browsed como funcionalidade, mas sempre achei ruim que Ubuntu/Debian e provavelmente todas as distribuições baseadas em deb iniciem automaticamente quase todos os serviços na instalação
    Isso significa que, ao instalar apenas um pacote, outro serviço de rede instalado como dependência pode acabar sendo aberto por engano
    O exim4 é um caso conhecido, mas, para ser justo, o padrão é escutar apenas em localhost, então talvez não seja um grande problema. Acabei de instalar o cups-browsed em uma máquina Debian, e subiram dois serviços que escutam em 0.0.0.0: cups-browsed e avahi
    Em distribuições da família Arch/Gentoo e CentOS, isso não acontece

  • A pontuação CVSS original publicada no Twitter dizia que não era necessária interação do usuário. Mas, ao ler a cadeia de execução remota de código na página, ela diz que “aguarda que um trabalho de impressão seja enviado para a impressora falsa para que a diretiva PPD e o comando correspondente sejam executados”
    Se Alice não clicar no botão de imprimir, parece que o trabalho de impressão não será disparado; fico me perguntando se estou deixando passar algo. Não é que eu esteja duvidando do evilsocket, é mais para confirmar meu entendimento

    • Também há um buffer overflow encontrado com fuzzer, e isso pode levar à execução remota de código sem interação do usuário. Porém, o autor não tinha especialização suficiente nessa área para criar um exploit real
    • Depende da definição de “interação”. Pelo que entendi, Alice não precisa imprimir um documento fornecido pelo invasor; basta imprimir qualquer coisa

  • Toda vez que preciso imprimir algo no MacOS, lembro de novo o quanto odeio impressoras e softwares relacionados a impressoras. Mexo com computadores há 40 anos e, de verdade, a cada década as impressoras ficam mais problemáticas

    • É curioso que o movimento da FSF tenha começado em grande parte pela irritação de Stallman com a qualidade dos drivers de impressora. Mas, por algum motivo, esse movimento não conseguiu melhorar de forma visível a qualidade dos softwares relacionados a impressoras em 40 anos
    • Escrevi código para impressoras por mais de 10 anos. Entendo como os problemas técnicos são difíceis, mas os fornecedores tornam a situação muito pior. Impressoras são detestáveis, e acho que o auge foi a LaserJet III
    • Sinto que as impressoras estão muito melhores do que há 10 anos. Pelo menos no MacOS e no iOS, não tenho problemas para encontrar a impressora e imprimir. Há 10 anos era sofrido, mas hoje, para mim, é fluido e nem precisa instalar driver
    • Últimas notícias: a HP está adicionando IA aos drivers de impressora. Não é piada: https://hardware.slashdot.org/story/24/09/27/0030239/hp-is-a...
    • Você perde o controle do trabalho, mas, se converter o documento para PostScript e depois enviá-lo com netcat para a porta da impressora, funciona bem
      pdf2ps - | nc 9001