Quando há CUPS demais: a ameaça de DDoS
Comentários editoriais e adicionais por Tricia Howard
Resumo executivo
Os pesquisadores da Akamai confirmaram um novo vetor de ataque usando o CUPS que pode ser aproveitado para preparar ataques de DDoS (negação de serviço distribuído). (CVE-2024-47850)
A pesquisa mostra que, para iniciar o ataque, o sistema atacante só precisa enviar um único pacote para um serviço CUPS vulnerável e exposto com conectividade com a Internet.
A SIRT (Security Intelligence and Response Team, equipe de resposta e de inteligência de segurança) da Akamai descobriu que mais de 198.000 dispositivos são vulneráveis a esse vetor de ataque e estão acessíveis na Internet pública; cerca de 34% deles poderiam ser usados para abuso de DDoS (mais de 58.000).
Dos mais de 58.000 dispositivos vulneráveis, centenas exibiram um “loop infinito” de solicitações.
Os recursos limitados necessários para iniciar um ataque bem-sucedido destacam o perigo: Um invasor levaria apenas alguns segundos para cooptar todos os serviços CUPS vulneráveis atualmente expostos na Internet e isso custaria a ele menos de um centavo de dólar americano em plataformas modernas de hiperescaladores.
Os CVEs
Em 26 de setembro de 2024, o pesquisador de segurança evilsocket divulgou vulnerabilidades de execução remota de código (RCE) no Common Unix Printing System (CUPS). Em resumo, um invasor poderia manipular remotamente os URLs do IPP (Internet Printing Protocol) para executar comandos maliciosos. Isso poderia ser feito juntando quatro vulnerabilidades diferentes.
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
Mais para a história do CUPS
Ao analisar a redação técnica sobre as vulnerabilidades, descobrimos que outro vetor de ataque não havia sido discutido: DDoS. O DDoS continua sendo um vetor de ataque viável usado para assediar e perturbar as vítimas em toda a internet, de grandes setores e governos a pequenos criadores de conteúdo, lojas online e jogadores. Embora a análise original tenha se concentrado no RCE, que poderia ter um resultado mais grave, a amplificação de DDoS também é facilmente abusada neste caso.
O problema surge quando um invasor envia um pacote criado especificando o endereço de um destino como uma impressora a ser adicionada. Para cada pacote enviado, o servidor CUPS vulnerável gerará uma solicitação IPP/HTTP maior e parcialmente controlada por invasor direcionada ao destino especificado. Como resultado, não só o alvo é afetado, mas o host do servidor CUPS também se torna uma vítima, pois o ataque consome sua largura de banda de rede e recursos da CPU.
Exploração
Um script simples pode ser usado para enviar o pacote UDP malicioso para uma instância vulnerável do CUPS. A carga útil trabalhada direciona o CUPS para enviar uma solicitação IPP/HTTP para o destino e a porta especificada pelo invasor. A vulnerabilidade aparece quando o cups-browsed tenta buscar o URI especificado para baixar o arquivo de atributos IPP.
Esse URI de arquivo PPD é um tanto arbitrário e pode ser modificado pelo invasor. Nos testes, descobrimos que essa carga útil de URI pode ser preenchida com 989 bytes. Esse preenchimento será incluído duas vezes na solicitação IPP/HTTP: uma vez nos cabeçalhos HTTP e outra nos dados POST que serão direcionados ao sistema visado.
Ao usar essa técnica de preenchimento, os invasores podem agravar ainda mais o impacto dos ataques DDoS suportados pelo CUPS, consumindo largura de banda e recursos adicionais nas redes e sistemas visados. A Figura 1 representa visualmente como seria esta técnica.
Fig. 1: Network diagram of attack flow
Sistema de ataque
O lado mais preocupante disso tudo é que são necessários pouco recursos para executar esta ameaça. As figuras 2 e 3 mostram que o sistema atacante só precisa enviar um único pacote para um serviço CUPS vulnerável e exposto com conectividade com a Internet para fazer com que o sistema que está executando o CUPS inicie o ataque.
./cups.py [CUPS_IP] [TARGET_IP]:1337 attacker_controlled-payload%20goes.here
Sending UDP Payload to target [TARGET_IP] and port 1337
Bytes Sent: 78
Fig. 2: Staging da exploração
09:05:03.072432 IP 192.168.12.143.43937 > X.X.X.X.631: UDP, length 78
0x0000: 4500 006a 1991 4000 4011 2ed5 c0a8 0c8f E..j..@.@.......
0x0010: xxxx xxxx aba1 0277 0056 bb25 3020 3000 .......w.V.%0.0.
0x0020: 6874 7470 3a2f 2fxx xxxx 2exx xx2e xxxx http://xxx.xx.xx
0x0030: 2exx xxxx 3a31 3333 372f 7072 696e 7465 .xxx:1337/printe
0x0040: 7273 2f61 7474 6163 6b65 725f 636f 6e74 rs/attacker_cont
0x0050: 726f 6c6c 6564 2d70 6179 6c6f 6164 2532 rolled-payload%2
0x0060: 3067 6f65 732e 6865 7265 0goes.here
Fig. 3: Pacote UDP de saída (modificado para ser uma carga útil não funcional)
Sistema-alvo
O resultado é o serviço CUPS tentando buscar o que ele acredita ser um arquivo de atributos IPP, mas que, na realidade, é o que o invasor especificou. O destino especificado no pacote UDP começará a receber conexões TCP de entrada do sistema executando CUPS (figura 4).
Fig. 4: CUPS service establishing a connection to the target
Se observarmos mais de perto os dois pacotes recebidos que continham os dados reais da solicitação, poderemos ver a solicitação IPP bruta e os dados POST que a acompanham, parcialmente controlados pelo invasor, provenientes do serviço CUPS (Figura 5).
Fig. 5: IPP/HTTP request received by the target
Podemos ver nos registros do daemon cups-browsed que as tentativas percorridas de buscar os atributos IPP são, em última análise, o que gera essas solicitações direcionadas ao host visado (Figura 6).
Fig. 6: Cups-browsed logs
Impacto e exposição
Para garantir uma análise completa, testamos e observamos diferentes padrões de máquinas, tanto no laboratório controlado quanto na Internet. Esses padrões impactam muito os cenários de ataque e os fatores de amplificação.
O SIRT da Akamai examinou e analisou a Internet global em busca de dispositivos vulneráveis a essa falha e acessíveis na Internet pública (mais de 198.000), com base nos dados fornecidos pelo evilsocket. Com base nesses dados, descobrimos que aproximadamente 34% desses dispositivos (mais de 58.000) estavam vulneráveis a esse ataque.
Além disso, nossos testes descobriram que alguns desses servidores CUPS ativos retornam repetidamente após receberem as solicitações iniciais, sendo que alguns deles parecem fazer isso infinitamente em resposta às respostas HTTP/404. Centenas desses sistemas em uso estabeleceram individualmente milhares de requisições e as enviaram para nossos sistemas de teste.
Isso mostra que a amplificação potencial dessa vulnerabilidade é bastante grande e pode causar problemas significativos para as organizações que executam esses servidores afetados. Também confirmamos, por meio de nossos testes, que alguns dos servidores CUPS vulneráveis conseguiram concluir os handshakes do TLS (Transport Layer Security, segurança da camada de transporte) de nossas tentativas de sondagem contra websites válidos protegidos por HTTPS. A possibilidade de afetar o TLS também coloca mais lenha na fogueira, pois cria mais pressão sobre o hardware do servidor e a sobrecarga de consumo de recursos devido ao handshake e ao processamento de criptografia/descriptografia.
A tecnologia ultrapassada ataca novamente
Devemos observar que muitas dessas máquinas identificadas estavam sendo executadas em versões muito antigas do CUPS, como a versão 1.3, que foi lançada inicialmente em 2007. Não é incomum que algumas organizações deixem máquinas funcionando com hardware e software extremamente desatualizados, e é improvável que esses dispositivos sejam atualizados em breve. Isso apresenta uma oportunidade privilegiada para os atores de ameaças maliciosas: Eles podem aproveitar o hardware desatualizado para amplificar o DDoS ou (considerando o RCE nesse cenário) criar botnets para muitas finalidades, incluindo DDoS.
Estimativas de amplificação
As taxas de amplificação podem variar significativamente, portanto, cobrimos um cenário médio e um cenário pessimista para ajudar os leitores a avaliar a ameaça em potencial.
Em última análise, a orientação de direcionamento determina o tamanho dessa carga útil, mas, para cálculos de referência, usaremos um tamanho mínimo viável de pacote UDP de 30 bytes e um pacote UDP de 1028 bytes com preenchimento máximo para o pior caso. Esse pacote usa a orientação IPP URI e a preenche com 989 bytes (o máximo encontrado durante os testes), que é duplicado e incluído no tráfego de ataque resultante.
Na pior das hipóteses, observamos o que parecia ser um fluxo interminável de tentativas de conexões e solicitações como resultado de uma única sondagem. Esses fluxos parecem não ter fim e continuarão até que o daemon seja eliminado ou reiniciado. Isso significaria uma amplificação infinita neste cenário. Durante os testes dos mais de 58.000 respondentes, algumas centenas exibiram esse padrão.
Aproximadamente 62% (mais de 35.900) dos sistemas enviaram pelo menos 10 solicitações TCP/IPP/HTTP para o nosso sistema de destino em resposta ao pacote UDP. De modo geral, a taxa de resposta dos mais de 58.000 respondentes (incluindo os respondentes infinitos com escopo de tempo) foi em média de 45 respostas, que é o que usaremos para calcular ainda mais as possíveis taxas de amplificação.
No cenário de sondagem viável mínima (30 bytes), vemos que a máquina de destino recebeu uma conexão TCP completa e dois pacotes com cargas úteis. O primeiro pacote contém a solicitação HTTP e cabeçalhos e o segundo contém os dados POST para a solicitação (Figura 7).
Fig. 7: Minimal viable amplification flow
Esses pacotes (226 bytes e 174 bytes) totalizam 400 bytes. Presumindo que receberemos essas conexões e solicitações 45 vezes por refletor CUPS, isso representa 18.000 bytes de tráfego resultante para cada sondagem de 30 bytes, ou aproximadamente um fator de amplificação de 600 vezes em uma tentativa média.
Menor amplificação não significa menor impacto
O pior cenário tem resultados diferentes fora do tamanho do pacote. Se executarmos esse mesmo exercício usando cargas úteis UDP com preenchimento máximo de 1.028 bytes (Figura 8), veremos fluxos muito maiores direcionados ao alvo, mas com amplificação menor.
Fig. 8: Maximally padded attack payloads arriving at the target
Nesse cenário, nossa carga útil de dois pacotes ainda chega, mas os respectivos tamanhos agora são 1.217 bytes e 1.164 bytes, totalizando 2.381 bytes. Assumindo a mesma média de 45 respostas por refletor, acabamos com um total de 107.000 bytes de tráfego por sondagem de 1.028 bytes, e nossa taxa de amplificação cai para 104 vezes.
Embora a taxa de amplificação tenha caído, a largura de banda consumida na rede de destino é quase seis vezes maior do que a carga útil minimamente viável. Este cenário também resultaria na necessidade de o servidor HTTP visado alocar recursos para tratar e processar essas solicitações. Portanto, embora não melhore as taxas de amplificação, ele apresenta um ataque mais problemático (e realista) para os defensores.
Dimensionamento dessas possibilidades
Se presumirmos que todos os mais de 58.000 hosts CUPS identificados foram reunidos na mesma campanha, isso poderia resultar em uma enxurrada de 1 GB de tráfego de ataque de entrada por pacote UDP do exemplo minimamente preenchido. Um cenário com o máximo de preenchimento poderia resultar em um fluxo de tráfego de 6 GB. Embora esses números de largura de banda possam não ser considerados surpreendentes, eles ainda resultariam na necessidade do alvo de lidar com cerca de 2,6 milhões de conexões TCP e solicitações HTTP em qualquer cenário.
Opções de DDoS no CUPS
Ataques dessa natureza fazem parte da tendência preocupante de uma barreira técnica cada vez menor para que os agentes de ameaças realizem tais ataques, direcionando sistemas vulneráveis em toda a Internet para enviar fluxos contínuos de tráfego para as vítimas. Para piorar a situação, isso pode ser feito enviando um único pacote para serviços CUPS expostos à Internet. Um invasor levaria apenas alguns segundos para cooptar todos os serviços CUPS vulneráveis atualmente expostos na Internet e isso custaria a ele menos de um centavo de dólar americano em plataformas modernas de hiperescaladores.
Como a pesquisa do evilsocket apontou, há um pouco mais de 198.000 dispositivos encontrados na Internet que respondem a sondagens UDP e, desses, o SIRT descobriu que aproximadamente 34% (mais de 58.000) reagiram à nossa sondagem UDP de uma maneira que poderia ser facilmente utilizada para DDoS.
Um invasor remoto que usasse uma carga útil criada poderia explorar essa vulnerabilidade para fazer com que o daemon cups-browsed fizesse conexões TCP de saída com terceiros. Se o alvo estiver executando um servidor HTTPS na porta de destino, o servidor terá de gastar ciclos e recursos tentando analisar e tratar essas solicitações e dados, o que pode tornar o ataque ainda mais impactante. No caso de CDNs e cache, é improvável que os URLs especificados na solicitação POST existam, resultando em um erro 404 que ignora os acessos ao cache e encaminha essas cargas úteis para os servidores de origem.
Com base na pesquisa realizada pelo evilsocket, muitas distribuições e versões de CUPS foram afetadas. Em última análise, a vulnerabilidade está no “cups-browsed” empacotado com “cups-filters” ao receber uma solicitação para adicionar uma impressora via UDP. Parece haver mitigações em várias distribuições Linux que vinculam o cups-browsed ao localhost ou desativam totalmente a escuta do cups-browsed.
Mitigação das vulnerabilidades do CUPS
A decisão de atualizar para a versão mais recente do CUPS ou removê-lo totalmente depende das necessidades específicas de seu sistema. Se seu sistema depende da funcionalidade de impressão, a atualização para a versão mais recente do CUPS garante maior segurança, desempenho e suporte para dispositivos modernos. No entanto, se a impressão não for necessária para sua configuração, a remoção do CUPS pode simplificar seu sistema, reduzir possíveis vulnerabilidades e economizar recursos.
Em última análise, essa decisão deve se basear na necessidade dos recursos de impressão para seu ambiente e na importância de manter um sistema atualizado e seguro. No mínimo, se a remoção ou atualização do software CUPS não for viável, os defensores devem proteger as portas de serviço (UDP/631) com firewall, especialmente se elas forem acessíveis a partir da Internet em geral.
Os agentes de ameaças costumam aproveitar rapidamente as vulnerabilidades recém-relatadas, com muitas novas versões sendo exploradas em apenas sete dias após a divulgação inicial. A correção leva tempo, e os hackers estão loucos para aproveitar esse período de transição vulnerável. Muitas organizações também negligenciam a atualização de alguns de seus softwares mais antigos, o que pode tornar especialmente lucrativo para os hackers surfarem a onda de exploração de novas vulnerabilidades como essa.
Mitigação de DDoS para vítimas
Para as vítimas de um ataque DDoS lançado a partir de sistemas CUPS vulneráveis, há algumas características do tráfego para ajudar a alertar, confirmar e eliminar o tráfego de ataque na rede ou no Web Application Firewall (WAF).
Todas as solicitações provenientes do serviço CUPS começam com POST /printers/ ou POST /classes/ e, embora a carga útil após a string /printers/ seja controlável pelo invasor, a parte inicial da carga útil não é. Além disso, as strings do User-Agent do CUPS são muito informativas e usam o formato CUPS/[VERSION]bem como uma referência ao IPP. Essas são strings muito exclusivas no UA e não são normalmente observadas no tráfego orgânico.
Há também elementos estáticos nos cabeçalhos HTTP e nos dados POST. O cabeçalho Content-Type de application/ipp e a carga útil printer-uri nos dados POST são valores estáticos que identificamos durante os testes (Figura 9).
Fig. 9: Highlighted values in observed traffic that could aid in detection and blocking
Para ajudar os defensores, também incluímos uma regra Snort que deve ajudar a identificar esses fluxos que entram em sua rede por meio de soquetes de texto sem formatação (Figura 10).
alert http any any -> any any (msg:"CUPS Reflected DDoS IPP Request";
pcre:"/POST \/printers\/|POST \/classes\//"; http_method;
content:"Content-Type: application/ipp"; http_header;
content:"User-Agent: CUPS/"; http_header;
content:"printer-uri"; http_client_body;
metadata:service http;
reference:url,https://akamai.com/blog/security-research/2024/october-cups-ddos-threat;
sid:100004; rev:2;)
Fig. 10: Regra Snort para tráfego de ataque CUPS
Conforme mencionado, encontramos sistemas em uso que concluíam handshakes de HTTPS antes de entregarem suas cargas úteis de HTTP, portanto, os defensores que usam HTTPS devem considerar a implementação dessas regras de correspondência em suas configurações de WAF em vez de em seus sistemas de monitoramento de rede.
Conclusão
Às vezes, novos vetores de ataque DDoS são encontrados e, com frequência, rapidamente utilizados por invasores oportunistas pouco qualificados. Essa vulnerabilidade no CUPS e o grande número de dispositivos que podem ser usados dessa maneira nos levam a acreditar que é provável que os defensores encontrem ataques baseados no CUPS.
Até que os esforços de mensagens e limpeza ganhem força para reduzir o número de dispositivos vulneráveis e expostos na Internet (atualmente mais de 58.000), suspeitamos que esse vetor sofrerá abusos enquanto estiverem em uso. Esperamos que os defensores, operadores de rede e administradores de sistemas recebam a mensagem e, para o bem de todos, lidem rapidamente com suas respectivas exposições ou, pelo menos, estejam preparados para identificar e afastar os invasores que possam aproveitar as exposições no futuro.
Também gostaríamos de agradecer ao evilsocket (Simone Margaritelli) por sua valiosa assistência e contribuição. ♥️