RCE crítica no Linux no CUPS: o que sabemos e como se preparar
Resumo executivo
Uma cadeia crítica de vulnerabilidades de RCE (execução remota de código), que se acredita afetar muitos hosts semelhantes ao Unix, foi divulgada em 26 de setembro de 2024.
O componente vulnerável é o CUPS (Common Unix Printing System), especificamente o cups-browsed.
Uma cadeia de quatro vulnerabilidades é necessária para uma exploração bem-sucedida: CVE-2024-47176, CVE-2024-47076, CVE-2024-47175 e CVE-2024-47177.
Neste post de blog, a Akamai compartilha detalhes sobre a vulnerabilidade, analisa a divulgação técnica e fornece recomendações sobre o que pode ser feito para se preparar e mitigar os riscos enquanto aguarda um patch.
Introdução
Em 23 de setembro de 2024, o pesquisador de segurança Simone Margaritelli compartilhou detalhes nas redes sociais sobre uma divulgação de vulnerabilidade que estava por vir. Em sua postagem, Margaritelli descreveu uma vulnerabilidade crítica que ele havia revelado aos desenvolvedores três semanas antes: uma vulnerabilidade de RCE não autenticada que pode potencialmente afetar todas as máquinas GNU/Linux.
Em 26 de setembro de 2024, uma divulgação técnica completa foi liberada. Existem quatro vulnerabilidades no total:
CVE-2024-47176 em cups-browsed, que força uma solicitação para um endereço controlado pelo invasor
CVE-2024-47076 em libcupsfilters, que não valida ou sanitiza os dados retornados do servidor do invasor, e os passa para o restante do sistema CUPS
CVE-2024-47175 em libppd, que novamente envolve a falta de sanitização de entrada e gravação em um arquivo temporário
CVE-2024-47177 em cups-filters, que permite a execução de um comando arbitrário
Nosso objetivo com este post de blog é ajudar as organizações a se prepararem, para que o processo de remediação seja o mais suave possível. Para isso, oferecemos um resumo técnico da cadeia de exploração e algumas etapas de mitigação (na forma de recomendações de segmentação) que os administradores de rede podem empregar enquanto aguardam o patch.
O que pode ser feito para se preparar?
Para que um invasor possa explorar uma vulnerabilidade de RCE, são necessárias duas "partes": um software vulnerável e, é claro, acesso remoto. Como sabemos que o componente vulnerável é o CUPS, podemos simplesmente corrigi-lo (quando o patch estiver disponível) ou aplicar algumas etapas de mitigação especificamente para esse componente. No entanto, acreditamos que a melhor abordagem é aproveitar esta oportunidade para abordar o acesso remoto de forma mais ampla.
Vamos começar, no entanto, com o assunto mais urgente.
Exposições e potenciais explorações do CUPS
Nosso alvo de discussão e componente vulnerável é o CUPS, que é um serviço que permite que um computador atue como um servidor de impressão. É muito popular e pode ser encontrado em uma ampla variedade de máquinas semelhantes ao Unix.
Esse serviço é muito comum e certamente pode ser um alvo de alto valor para exploração, pois tende a estar exposto a outras máquinas (e potencialmente à Internet) por sua natureza. Vulnerabilidades anteriores em serviços de impressão, como CVE-2021-34527 (PrintNightmare) ou até mesmo CVE-2010-2729, demonstraram o impacto potencial desse vetor de ataque.
Antes mesmo da divulgação "oficial", teorizamos que o CUPS era o componente vulnerável. Ao inspecionar a conta do GitHub de Margaritelli, encontramos um detalhe interessante: um fork do repositório CUPS da Apple de 17 de setembro de 2024, poucos dias antes de sua postagem inicial (Figura 1).
Fig. 1: Um fork do repositório CUPS da Apple, feito por Margaritelli uma semana antes de sua postagem sobre a vulnerabilidade
Também há um problema no cups-browsed que cita Margaritelli (@evilsocket) sobre o que é provavelmente um efeito colateral da vulnerabilidade principal. (Há também alguns comentários interessantes lá, então prepare a pipoca. )
Análise de exploração
O ataque não é particularmente complexo, mas requer várias etapas para ser explorado com sucesso. A Figura 2 ilustra nosso resumo do processo, mas incentivamos a leitura do blog de divulgação completo para uma explicação mais detalhada.
Fig. 2: Cadeia de exploração bem-sucedida
Etapa 1: primeiro, o daemon cups-browsed está ouvindo conexões UDP de entrada pela porta 631. Seu propósito é adicionar impressoras descobertas ao sistema. Um invasor que se comunica com o daemon pode simplesmente forçar a máquina vítima a registrar um endereço mal-intencionado como uma impressora legítima; essa é a CVE-2024-47176.
Etapa 2: a próxima parte acontece durante o registro da "impressora" mal-intencionada. Como parte do registro, libcupsfilters enviará uma solicitação de saída ao invasor, requisitando atributos da impressora por meio do IPP (Internet Printing Protocol). Como parte desses atributos, as impressoras podem definir arquivos específicos de PPD (PostScript Printer Description), que, quando usados legitimamente, definem as capacidades da impressora. Esses atributos são então escritos em um arquivo .ppd, sem sanitização e sem restrições. Isso é a CVE-2024-47076 e a CVE-2024-47175.
Agora temos um arquivo .ppd mal-intencionado. Mas como executamos comandos por meio dele?
Etapa 3: a diretiva cupsFilter2 é inserida no PPD, que executa vários filtros (arquivos executáveis) sempre que um novo trabalho de impressão é criado. Usamos a diretiva de filtro para executar o filtro foomatic-rip , que é vulnerável a uma injeção de comando arbitrário. Isso é a CVE-2024-47177.
Um olhar mais atento
Usando o Shodan, conseguimos verificar que aproximadamente 75.000 máquinas em todo o mundo expõem o CUPS à Internet, na maioria das vezes utilizando a porta 631 padrão (Figura 3).
Fig. 3: Aproximadamente 75.000 máquinas em todo o mundo expõem o CUPS à Internet
O seguinte filtro pode ser usado para consultar o Shodan em busca de servidores CUPS expostos:
product:"CUPS (IPP)"
Insights adicionais
Utilizando os insights únicos da Akamai sobre dados de tráfego, observamos que o serviço CUPS está sendo executado em uma ampla variedade de plataformas, incluindo Ubuntu, macOS, CentOS, Debian, Fedora, OpenShift, Oracle Linux Server, Red Hat, Rocky Linux, SUSE, openSUSE, AlmaLinux, Amazon Linux e mais.
Um total de 10,1% das máquinas Linux no ecossistema Akamai têm a porta 631 (a porta do CUPS) aberta. No entanto, apenas 3% dessas máquinas recebem regularmente tráfego externo nessa porta.
Embora esses números possam indicar que o serviço não está comumente exposto externamente, ainda é importante que as organizações avaliem sua própria exposição e revisem suas políticas de segurança em conformidade.
Análise da exposição à Internet
Uma das maneiras mais comuns para os invasores invadirem organizações é por meio de serviços expostos à Internet. O CUPS é apenas um exemplo desse tipo de serviço, mas o problema, obviamente, não termina aí. Novamente, utilizando os insights da Akamai sobre dados de tráfego, avaliamos o status de exposição de diferentes serviços em milhares de organizações.
De acordo com os dados da Akamai, aproximadamente 5,4% das máquinas Linux estão expostas à Internet e recebem tráfego de entrada de fontes externas (Figura 4).
Fig. 4: Exposição à Internet de máquinas Linux
Ao inspecionar as políticas de rede que afetam esse tráfego, vimos que 19,3% dessas máquinas permitem tráfego de Internet de entrada por padrão, o que significa que não há políticas de rede específicas em vigor para restringir ou controlar o fluxo de tráfego de entrada.
Como serviços expostos podem facilmente se tornar um vetor de ataque, é crucial que as organizações revisem e reforcem seus controles de acesso.
Recomendações
Como a vulnerabilidade ainda não é pública e não há um cronograma de aplicação de patches, a melhor maneira de se preparar para essa divulgação é mapear todos os pontos de "fricção" em sua rede (seja uma lista de todas as máquinas Linux, sua exposição à Internet ou até mesmo o uso do CUPS) e as políticas de segmentação relacionadas a elas.
Uma vez que tudo esteja mapeado, recomendamos que você aplique políticas de segmentação para limitar o raio de impacto de qualquer ataque potencial. Essa é uma boa prática, independentemente da situação atual, já que o movimento lateral Linux não se limita apenas a SSH ou RCEs.
Identificação do uso do CUPS na organização
Para identificar o CUPS em execução nas máquinas, você pode procurar por nomes de serviços e processos. Nossas observações, que abrangem uma variedade de sistemas e distribuições Unix, indicam que os seguintes processos podem sinalizar o uso do CUPS:
cups-browsed (o processo afetado)
cupsd
cancel.cups
lpq.cups
cupsfilter
lpc.cups
lp.cups
cupsaccept
cups-lpd
lpstat.cups
lpr.cups
cupsctl
Organizações que utilizam osquery podem usar as seguintes consultas para identificar o uso potencial do CUPS em seus sistemas (Os clientes do Akamai Guardicore Segmentation podem executar essas consultas usando o recurso Insight).
Detectar máquinas ouvindo na porta 631:
SELECT pid, port, protocol, family, address, path
FROM listening_ports
WHERE port = 631
Detectar processos em execução que podem estar relacionados ao CUPS:
SELECT name, parent, cwd, cmdline, pid, start_time, path
FROM processes
WHERE path LIKE '%cups%'
Identificação da exposição à Internet
Você pode usar serviços de escaneamento de exposição, como o Shodan, para identificar serviços expostos à Internet, incluindo o CUPS.
Os clientes do Akamai Guardicore Segmentation podem usar o filtro de conexão com a Internet na aba de revelação para visualizar todos os seus serviços e máquinas que recebem tráfego da Internet (Figura 5).
Fig. 5: O filtro de conexão com a Internet revela todos os serviços e máquinas que recebem tráfego da Internet
Uso da segmentação para limitar o potencial raio de impacto
Considere o seguinte cenário: a vulnerabilidade é divulgada, não é o que esperávamos nem para o que estávamos preparados, alguém cria um exploit funcional e um agente de ameaça mal-intencionado o utiliza para invadir sua rede.
E então, o que acontece? Eles podem simplesmente pular para o controlador de domínio, infectar toda a rede, instalar seu botnet/miner de criptomoeda/ransomware/trojan e sair sem serem detectados? Ou eles precisam trabalhar mais, realizar varreduras complexas de reconhecimento, usar vários saltos de movimento lateral e ser mais proativos, o que daria a você amplas oportunidades para detectar a violação e reagir?
As violações continuam acontecendo, e é por isso que a segmentação é tão importante. Se não for esta RCE hoje, será outra zero-day amanhã. Redes planas são alvos fáceis, mas se dificultarmos a vida do invasor, podemos fazê-lo desistir (e mudar para alvos mais fáceis) ou forçá-lo a gastar tempo suficiente e realizar ações suficientes para cometer erros e ser detectado.
Aumente sua postura de segurança em dois passos
Existem dois passos relativamente simples que podem aumentar significativamente sua postura de segurança: implementar uma DMZ e segmentar seus servidores de aplicativos.
Implementar uma DMZ. Servidores abertos à Internet estão inerentemente em maior risco; portanto, eles não devem ter acesso total ao restante da rede. Implementar uma DMZ de perímetro para esses servidores, garantindo que eles não possam acessar as partes mais confidenciais da rede, torna a vida de qualquer invasor muito mais difícil.
Segmentar servidores de aplicativos. Normalmente, é possível segmentar servidores de aplicativos semelhantes juntos, e pode ser fácil restringir seu tráfego de entrada e saída com base em sua lógica de aplicativo.
Tomemos o servidor CUPS como exemplo: sabemos sua porta (UDP 631), seu processo (cupsd), e que, tecnicamente, ele só precisa gerar tráfego para as impressoras reais. Com isso, podemos criar um segmento de aplicativo para esses servidores CUPS, permitindo tráfego específico e mantendo a maior parte do tráfego fora.
Dessa forma, qualquer invasor que explorar com sucesso o CUPS para invadir o servidor só poderá se conectar à impressora: e um trabalho de impressão de brincadeira não é tão assustador.
Saiba mais
Existem outras soluções de "ganho rápido" que uma organização pode aplicar por meio da segmentação para aumentar sua postura de segurança. Leia sobre elas em nosso blog sobre segmentação prática.