Há muito que entender, existe um background bastante complexo por trás da recente vulnerabilidade (deveria chama-la assim??, acho que não) do xz/liblzma, que não apenas consiste em um simples ataque, em uma simples vulnerabilidade; eh contudo, reflexo do precário estado atual que muitos desenvolvedores de projetos open-source se encontram. Eh mas que tudo uma falha massiva na comunidade, em como enxergamos estes projetos

Sinceramente o ataque ta sendo amplamente explicado por diversos médios e não acho que neste momento haja informação que eu pessoalmente possa entregar nem trazer ou ao menos como apresenta-la com um visão do todo que possam agregar, estarei esperando analises mais profundas do reversing onde eu poderei talvez ser util ao explicar um pouco

(mas se vc não viu ainda, recomendo bastante procurar sobre a falha de xz e tmb fazer um downgrade ou upgrade seu pacote xz principalmente em ambiente debian e com uso de openssh)

Mas uma coisa precisa ser altamente divulgada, a origem deste ataque surge de um desenvolvedor cansado, sozinho, mantendo com todas suas forças um projeto que ele ama, que recorreu a única ajuda que encontrou e infelizmente era um agente mal-intencionado que explorou a precariedade do ecossistema atual de muitos projetos que se mantem por um ou dois desenvolvedores
Precisamos apoiar projetos open-source, precisamos fortalecer a união da comunidade como um todo, este eh so o começo de um modelo de ataque que sera cada vez mais presente em projetos open, este eh um aviso, e a maior vulnerabilidade aqui, o maior vetor de ataque foi um desenvolvedor isolado, foi a escassez de uma comunidade entrelaçada e unida
este sera o vetor que foi e sera explorado se as coisas continuarem desta forma


Pra entender melhor a situação deixo aqui um post do vlog Rob Mensching

https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/

(eu modifiquei algumas partes soh pra ser mais preciso na tradução)
as partes marcadas com — — se referem a conversar entre o desenvolvedor e o suposto usuario (ou melhor, consumidor)

Haverá muitas análises da vulnerabilidade xz/liblzma. No entanto, a maioria pulou o primeiro passo do ataque:

—
Mantenedor original se cansa, e apenas o atacante oferece para ajudar (para que o atacante herda a confiança construída pelo mantenedor original)
—


Surpreendentemente, alguém encontrou um arquivo com um tópico de e-mail que capturou o estado do mundo, assim como este passo 0 estava ocorrendo. Vamos ler as suas palavras.

Primeiro, começamos com um pedido razoável solicitado razoavelmente. A questão força o mantenedor a abordar seus “fracassos”. Eu uso “fracassos” nas citações aqui porque o

a. mantenedor não deve realmente nada aqui, então ele não falhou e
b. Eu sei exatamente como isso se sente. É terrível decepcionar sua “comunidade”.

—

XZ para Java ainda é mantido? Eu fiz uma pergunta aqui há uma semana e não ouvi de volta.” - https://www.mail-archive.com/xz-devel.tukaani.org/msg00562.html

—

O mantenedor reconhece que está “atrás” (em uma tradução melhor eu diria que 'esta procurando sobre') e está lutando para acompanhar. Isto é um grito de dor. É um grito de socorro. A ajuda não virá neste tópico.
—

“Sim, pelo menos por alguma definição, como se alguém relatar um bug, ele será corrigido. O desenvolvimento de novos recursos definitivamente não é muito ativo. :-(" - https://www.mail-archive.com/xz-devel.tukaani.org/msg00563.html

—

Oh! Aqui somos apresentados ao nosso atacante xz/liblzma, na mesma mensagem. Esta não é a ajuda que você esperava.

—

“Jia Tan me ajudou ... e ele pode ter um papel maior no futuro ... É claro que meus recursos são muito limitados ... então algo tem que mudar a longo prazo.” - https://www.mail-archive.com/xz-devel.tukaani.org/msg00563.html

—

Em vez disso, um consumidor inútil diz coisas inúteis. É exatamente aqui que esses tipos de tópicos de e-mail vão.

—

“O progresso não acontecerá até que haja um novo mantenedor. O atual mantenedor perdeu o interesse ou não se importa mais em manter. É triste ver para um repo como este.” - https://www.mail-archive.com/xz-devel.tukaani.org/msg00566.html

—

Além disso: Dado que a vulnerabilidade xz/liblzma parece um ataque proposital de “Jia Tan” deve “Jigar Kumar” ser considerado um cúmplice ao maximizar ativamente o mantenedor original para desistir? - Não tenho a certeza? Veremos este consumidor inútil “Jigar Kumar” novamente em breve.

Inevitavelmente, o mantenedor tenta se defender. Os mantenedores lidam com o estresse de cansaço de forma diferente. Eu costumo ficar com raiva, o que acaba se deparando com o sarcasmo. No entanto, esta reação é de partir o coração.

—

“Eu não perdi o interesse, mas minha capacidade de cuidar tem sido bastante limitada, principalmente devido a problemas de saúde mental de longo prazo, mas também devido a
algumas outras coisas.” – https://ww.mail-archive.com/xz-devel.tukaani.org/msg00567.html

—

...e então o mantenedor também lembra a todos como o software do mundo é construído agora.

—

“Também é bom ter em mente que este é um projeto de hobby não remunerado” - https://www.mail-archive.com/xz-devel.tukaani.org/msg00567.html

—

Uma semana depois, o consumidor inútil retorna. A porra de uma semana (o post original não usa essa palavra, porém achei adequada pra expressar este absurdo)

—

“Você ignora os muitos patches apodrecendo nesta lista de discussão. Agora você engasga seu repo. Por que esperar até 5.4.0 para mudar o mantenedor? Por que adiar o que seu repo precisa?” - https://www.mail-archive.com/xz-devel.tukaani.org/msg00568.html

—

Para que serve isto? Eu não posso te dizer o quão irritado isso me faz sentir por esse mantenedor.

Então, nosso solicitante razoável que iniciou este tópico de e-mail decide que agora é um bom momento para fazer exigências também.

—

“Sinto muito sobre seus problemas de saúde mental, mas é importante estar ciente de seus próprios limites. Eu opo que este é um projeto de hobby para todos os colaboradores, mas a comunidade deseja mais” - https://www.mail-archive.com/xz-devel.tukaani.org/msg00569.html

—

Leia a última frase novamente, “a comunidade deseja mais”. Os consumidores devem ser alimentados. As necessidades do mantenedor, das quais existem claramente algumas
importantes, são ignoradas.

Nosso solicitante não mais razoável também oferece sugestões. Observe que não há oferta para realmente ajudar.

—

Por que não passar na manutenção do XZ para C para que você possa dar mais atenção ao XZ para Java? Ou passar o XZ para Java para outra pessoa para se concentrar no XZ para C? Tentar manter ambos significa que nenhum dos dois é mantido bem.” – https://www.mail-archive.com/xz-devel.tukaani.org/msg00569.html

—
Então, o mantenedor tem que explicar a realidade.

-—-

“Encontrar um co-manitenedor ou passar os projetos completamente para outra pessoa tem estado em minha mente há muito tempo, mas não é uma coisa trivial a se fazer. Por exemplo, alguém precisaria ter as habilidades, tempo e interesse suficiente a longo prazo especificamente para isso.” – https://www.mail-archive.com/xz-devel.tukaani.org/msg00571.html

—

É preciso habilidade e conhecimento para escrever software. E enquanto muitas habilidades e algum conhecimento serão transferidos, trabalhar em um novo projeto de software inevitavelmente requer o desenvolvimento de novas habilidades e mais conhecimento.

Os desenvolvedores de software não são engrenagens fungíveis que você pode trocar por dentro e fora à vontade.

O tópico de e-mail termina com os consumidores reclamando que não oferecem ajuda enquanto continuam a fazer exigências. Só resta o atacante.

—

“Jia Tan pode ter um papel maior no projeto no futuro. Ele tem ajudado muito e é praticamente um co-manitainer já. :-)” - https://www.mail-archive.com/xz-devel.tukaani.org/msg00571.ht

—

Este thread é um microcosmo das interações em projetos de código aberto. Os consumidores fazem exigências (algumas educadas, algumas não tão educadas) de um mantenedor (rarariamente dois) que faz tudo.

Não se enganem. É assim que funciona.

E ISSO PRECISA MUDAR.

OverlayFS, uma historia de vulnerabilidades que afeta até as versões mais recentes do kernel em distros modernas (e como a gestão de permissões a low-level pode ser um problema)

# OverlayFS

OverlayFS (ou union-filesystems) eh basicamente um sistema de arquivo hibrido que permite manipular vários tipos de sistemas de arquivos diferentes em camadas (ou seja, por sobreposição) mantendo uma estrutura de base (Lower) segura e com estruturas de diretorios distintas que podem ser sobrepostos e manipulados temporariamente

Assim, podemos pensar nesta funcionalidade como um modelo de 4 camadas, designadas como Lower, upper, work e union -merged (respectivamente, lower corresponde a camada mas baixa, neste ponto (montada como read-only) manipulações feitas aos arquivos de esta camada não serão salvos diretamente nela durante a camada de sobreposição (union) porém serão armazenados na camada superior; a camada upper corresponde a camada superior, aqui podemos manipular seus arquivos e salvar eles de forma direta atraves da camada de sobreposição union), este sistema eh bastante interessante pra manipulação de dados sem modficar seu estado original (copy-on-write) e manter as caracteristicas do filesystem de um backup ou projeto original mesmo durante testes em sua estrutura, preservando os dados originais enquanto a camada superior efetua modificações temporárias (muito usado em dispositivos IoT e containers)

Enfim, existe diversa documentação sobre, mas a questao que quero focar aqui consiste me principalmente duas coisas, gestão de permissos e implementação de dispositivos

# capabilities

No nosso queridissimo kernel temos diversas forma de gestionar permissões sobre processos e binarios (incluindo threads e e arquivos de biblioteca), uma das que pretendo dar relevância aqui são as chamada capabilities
sem querer fugir muito do assunto principal, devo só tomar emprestada a seguinte explicação deste mecanismo

Para efetuar controles de permissão, UNIX tradicionalmente implementa distinção de dois tipos de processos (os pertencentes ao usuário root ou supervaca (ID 0) e processos sem privilegios ..
enquanto processos do root bypassam todos os controles do kernel, processos sem privilegios estão sujeitos aos controles de credenciais (UID (ID do usuario), GID (grupo))

Apartir do kernel linux 2.2 são implementadas as capabilities (em tradução direta: capacidades, escolhi manter o nome original pq se não poderia confundir um pouco as coisas), que dividem o conjunto de permissões root em distintas unidades, que podem ser independentemente ativadas ou desativadas por thread

traduzido do manual oficial

existe uma lista bastante grande de capabilites que podem ser designada a um processo, podemos pensar em elas como flags, estas nos permitem fazer bypass em distintos elementos do sistema e dividir o conjunto de permissões em pedaços (ou unidades), desde escritura e leitura em areas especificas ou espaços e alocações de memoria, sinais, descritores de dispositivo, até a possibilidade de designação de prioridades em threads (devo dizer que podemos outorgar diferentes capabilities a threads do um mesmo processo)
Assim, podemos expandir o conjunto de permissões de um processo a seus childs, sem necessariamente outorgar privilégios

esse assunto eh bem profundo e recomendo demais ler mais a fundo se vc possui interesse, existe bastante documentação sobre este mecanismo (pra area defensiva e ofensiva)

# OverlayFS, a mina de vulnerabilidades

em um busca simples sobre escalação de privilegios e overlayFS, podemos encontrar ao menos 8 PoCs disponíveis de distintos cves, além de vulnerabilidades criticas que permitem efetuar escalação de privilégios ( CSS 8.0 >), como o kit de vulnerabilidades descoberto pela equipe Wiz conhecido como GameOver(lay) que afetavam as versoes do kernel no Ubuntu 18.4 ate o 23.04.

vcs podem encontrar a pesquisa completa da Wiz na primeira referencia

Estas duas vulnerabilidades categorizadas como CVE-2023-2640 e CVE-2023-32629, se originam em uma implementação especifica realizada pela equipe da Canonical no kernel. Durante uma correção a outro vulnerabilidade existente no overlayfs -> (

CVE-2023-0386, permitia a um atacante copiar arquivos do seu ponto de montagem pra diretorios privilegiados, o problema grave aqui basicamente consistia em que se o arquivo fosse definido com o bit SUID pelo atacante, ele seria transferido com o bit intacto pra o diretorio local

) <- a equipe percebeu que a correção verificava a transferência das permissões, porem unicamente no dominio do arquivo (usuario, grupo). Porém a correçao ignorou as capabilities. O resto vcs provavelmente já devem imaginar, bastava montar a camada superior por cima de uma base contendo um arquivo com capabilities e modificar ou efetuar uma operação touch no arquivo assim a função copy-on-write iria transferir o arquivo pra a camada superior e junto com ele as permissões e os bypass definidos nos seus capibilities (explorar esse ataque eh tao simples como procurar um arquivo com as capabilities que desejamos obter e modifica-lo pra efetuar a operação que desejamos com esse nivel de privilegios). A segunda vulnerabilidade consiste em definir uma flag no ponto de montagem ( metacopy=on ) e copiar um arquivo arbitrario com as capabilities que queremos obter e podemos rescrever ele
O que acontece aqui eh que quando esta flag eh definida os metadados são copiados junto com o arquivo original, bastante semelhante a primeira CVE, porem neste caso podemos simplesmente reescrever o arquivo do zero sem nos preocupar por o tipo de arquivo que copiam, jah que o que importa eh termos transferido os metadados
Estas duas flaws surgem apartir da mesma função ovl_do_setxattr

Bem, sinceiramente posso continuar aqui falando de varias flaws com natureza semelhante no mecanismo do overlayfs, mas a vulnerabilidade especifica que me fez escrever este artigo e a qual a maioria das versoes debian ainda eh vulneravel eh a CVE-2021-3847


CVE-2021-3847 - o problema nosuid
-


CVE-2016-1575
CVE-2016-2853
CVE-2016-1575

So it is 5 years and not so much changed :-)

- > (dps de 5 anos, quase nada mudou)

lista de email Open-Source Sec - halfdog


Antes de tudo devo ressaltar a função da opção nosuid no mecanismo de montagem, basicamente quando definimos esta opção, deveríamos poder confiar em que qualquer processo criado pelo usuário vai herdar as permissões deste, ou seja, se um usuário sem privilegios inicia um processo de um binario criado pelo root, ele devera ser executado com as permissoes do usuario sem privilégios, nesta flaw isso nao acontece

Olha, se vc leu ate aqui ja sabe o que esperar, e assim como nosso amigo halfdog diz na lista de email oficial, depois de 5 anos temos vulnerabilidades da mesma natureza correndo soltas, dessa vez o mais surprendente (pelo menos pra mim), eh que esta flaw ainda nao foi corrigida e nem possui previsão, isto eh ate um pouco comum em bugs que nao tem um fator real e pratico de exploração e pra isso basta apenas olhar as security tracker das distros, algo que eu tenho costume em fazer,,ate mesmo pra aportar como correções (dificilmente chego nesse nível de fato, mas eu tento kkjjjjjkkk).
Mas neste caso temos um fator relativamente comum, uma tecnologia amplamente usada e uma técnica de exploração simples, devo mencionar contudo que a melhor solução aqui foi apresentada na propia lista de email original.
A solução é ate obvia, consiste em um fator comum e eh que os sysadmin devem ter a noção de como funciona o modelo de permissões do overlayfs, isto porque a copia (incluindo a copy-on-write) eh feita pelo processo que montou os filesystem (isto porque o modulo herda seus atributos); Assim se o overlayfs vai ser acessado por usuarios nao privilegiados, o interessante eh ele ser montado por um usuário especifico com as permissões definidas (ou por um processo com opções de segurança bem definidas) que serão herdadas ao overlayfs, porque infelizmente como podemos ver, as opções de montagens não diferem entre si e quando uma copia é feita os filesystem compartilham os metadados

Umas das soluções apresentadas na lista de email consiste em forçar os dois filesystem (upper & lower) a compartilhar as configurações do suid (coisa que na minha opinião apenas resolve uma parte do problema, ignorando as tantas incidências de problemas de credenciais neste modelo de permissões)

Referencias:

OpenWall - CVE-2021-3847

Security Tracker - Debian

Uma explicação bem interessante da CVE-2021-3493 - Terenceli


https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability

https://news.1rj.ru/str/tgresistancebot/letter
Join the #DigitalResistance. Sign the Open Letter to #FREEDUROV.

Pessoal, estaremos migrando do Telegram para um novo site hospedado no github. Nos próximos dias estarei disponibilizando o link

Todo o conteudo que eu postei no canal sera migrado pra lá junto com dois novos artigos sobre kernel exploiting que to trampando ha alguns meses

Pra quem não viu, tweet da Proton sobre o bloqueio do X no Brasil.

A Proton VPN pode ser usada gratuitamente (com limitações) ou em planos premium.

📌 @PrivacyMap

Explorando 4 CVEs em CUPS para obter uma RCE e hackear o mundo

depois de ter feito todas as maquinas disponíveis na temporada pelo HackTheBox, procurei pelas maquinas gratuitas disponíveis para jogar
entre elas estavam o EvilCups, o qual eu não tinha feito ainda, então ela foi meu proximo objetivo e devo revelar que foi uma experiencia no mínimo interessante.
Antes de tudo devo esclarecer duas coisas.
Primeiro, esta maquina não da pontos e possui writeup disponível
segundo, ela consiste em atacar uma serie de CVEs descobertas no mesmo serviço.
Para conseguir explorar e obter um RCE na maquina, é necessário ler o artigo original da pesquisadora (evilsocket) que descobriu as vulnerabilidades, deixo o link no final. Porem a parte mais legal é de fato explorar as vulnerabilidades e entender o processo de descoberta delas e é com base nele que irei tocar em dois pontos extremamente relevantes para os pesquisadores (pelo menos na minha experiencia).

Para obter a flag iremos explorar a CVE-2024-47176 (vulnerabilidade por falta de validação do cups-browsed onde este escuta na porta 361 e espera o atributo Get-Printer-Attributes que define as propiedades, estado e configuraçoes de uma impresora, desta forma um atacante pode enviar uma requisição com as propiedades de uma suposta impresora, mesmo esta não existindo de fato e instalar uma impressora)
CVE-2024-47076 (não valida nem sanitiza os atributos recebidos por um servidor IPP (aqueles injetados através da requisição de uma nova impressora usando a CVE anterior) permitindo ao ataque carregar atributos malicioso)
CVE-2024-47175 (não valida nem sanitiza os atributos recebidos por um servidor IPP os quais são escritos e carregador a um arquivo temporario PPD, permitindo ao atacante injetar dados dentro do arquivo)
CVE-2024-47177 (permite enviar comandos pelos atributos do PPD ao FoomaticRIPCommandLine que serão executados durante o pré-processamento)

Para explorar esta vulnerabilidade basta forçar a conexão a um servidor IPP se aproveitando do broadcast sem validação e carregar os atributos de uma nova impressora usando Get-Printer-Attributes, assim carregamos uma impressora nova dentro do sistema de gerenciamento. depois basta carregar nela um arquivo de impressão PPD de teste qualquer usando nos seus atributos o parâmetro de pre-procesamento FoomaticRIPCommandLine (

o qual nos permite definir arquivos de pré-processamento, automatizar novas açoes, converter arquivos e executar noscripts

) ->

*FoomaticRIPCommandLine: "echo 'Ola linkedin;hi debutysec' > /tmp/exploited"
*cupsFilter2 : "application/pdf application/vnd.cups-postnoscript 0 foomatic-rip

executando assim o comando personalizado no pre-processamento do arquivo de teste desde uma suposta impressora injetada por um dominio externo de um atacante se aproveitando da falta de verificação do servidor IPP e a falta de sanitização de múltiplos componentes
* Isto só foi possivel porque o projeto cups implemento um componente com CVE conhecida
* mas basicamente o segundo fator relevante consiste em determinar o nivel e superfície de ataque dos ativos ao expor um serviço

já que segundo um dos desenvolvedores do CUPS "o vetor de ataque na internet apenas é preocupante se o serviço estiver exposto diretamente"
este comentario demonstra que até mesmo desenvolvedores experiente podem ter pouca ou nenhuma noção de segurança em camadas. cabe aos pesquisadores analisar constantemente os modelos de segurança das aplicações e profissionais de segurança cibernetica avaliar e implementar com cuidado este tipo de serviços

publicado por alexys sunil:
https://www.linkedin.com/posts/alexys-sunil_explorando-4-cves-em-cups-para-obter-uma-activity-7257511153415692288-JrQ8

Isso aqui é melhor que tomar sorvete num dia quente! Agradeço a todos os membros, em nome de todos os admins do RubyOfSec. Obrigado pessoal, que nostalgia :3