Uma vulnerabilidade foi descoberta (CVE ainda não emitido) em uClibc e uClibc-ng Bibliotecas padrão C. Essas bibliotecas são amplamente utilizadas em Dispositivos IoT. A vulnerabilidade recém-descoberta torna possível colocar dados forjados no cache DNS, permitindo definir um endereço IP arbitrário nesse cache com o subsequente redirecionamento de todas as consultas direcionadas ao domínio para os malfeitores’ servidor.
A falha afeta firmware Linux usado em vários roteadores, pontos de acesso, e outros dispositivos IoT. Ele também atinge distribuições Linux para sistemas operacionais embarcados como Embedded Gentoo e OpenWRT. A vulnerabilidade se revela em muitos dispositivos diferentes. Por exemplo, Linksys, Netgear, e Axis usam bibliotecas uClibc. Como a vulnerabilidade ainda não foi curada em uClibc e uClibc-ng, os detalhes sobre dispositivos e fabricantes específicos em cujos produtos ocorre o problema ainda não foram divulgados ao público.
O mecanismo de vulnerabilidade
A vulnerabilidade vem do uso de identificadores de transação previsíveis nas solicitações DNS geradas pela biblioteca. Os IDs de solicitação de DNS são formados pelo simples incremento do contador, sem qualquer randomização adicional dos números das portas.. Este mecanismo, por sua vez, permitiu o envenenamento do cache DNS por meio do envio proativo de um pacote UDP com uma resposta forjada. A falsificação será aceita se apresentar um ID de solicitação correto e chegar antes da resposta do servidor genuíno. Ao contrário do método Kaminsky proposto em 2008, a abordagem atual nem sequer requer suposições, uma vez que o ID da transação é inicialmente previsível. O valor inicial (1) é incrementado a cada consulta, não escolhido aleatoriamente.
As recomendações de segurança contra quebra de ID incluem números aleatórios de portas de rede de origem de onde a solicitação DNS. Esta medida deve compensar o curto comprimento do identificador. Se a randomização estiver ativada, a falsificação de um ID de 16 bits não é suficiente – os hackers teriam que forçar adicionalmente o número da porta da rede. Em uClibc e uClibc-ng, a porta UDP de origem aleatória não apareceu durante a solicitação de ligação. Portanto, o o randomizador foi desativado, e sua aplicação exigia a alteração das configurações do sistema operacional.
Com a randomização desligada, o problema de adivinhar um ID de solicitação incrementado torna-se trivial. Mas mesmo que a randomização fosse aplicada, os invasores precisariam apenas obter um número de porta no intervalo de 32768 a 60999 (Linux usa isso.) Eles poderiam ter usado um envio simultâneo massivo de respostas falsas para diferentes portas de rede para vencer a resposta DNS legítima.
História do inquérito
O problema foi confirmado em todas as versões de trabalho do uClibc e uClibc-ng, incluindo o mais recente uClibc 0.9.33.2 e uClibc-ing 1.0.40. Em setembro 2021, as informações sobre a vulnerabilidade foram enviadas para CERT/CC para preparação coordenada de correções. Além disso, Em janeiro 2022, os dados foram entregues a mais de 200 fabricantes que trabalham com CERT/CC. Em março, houve comunicação com o suporte do projeto uClibc-ng. Eles admitiram que não poderiam corrigir a vulnerabilidade sozinhos e recomendaram a divulgação das informações à comunidade para que ela pudesse ajudar no desenvolvimento da correção.. Redes Nozomi, a empresa que detectou a falha, trouxe a informação ao público em um relatório completo em maio 2, 2022. Enquanto isso, Netgear anunciou uma atualização na qual promete lidar com a vulnerabilidade.
