Resumo: path traversal .tgz do cdnjs até à exposição do GITHUB_REPO_API_KEY no ambiente
- Confiado por ser Cloudflare: Toda a gente confia no cdnjs porque é a Cloudflare que o gere, mas a descoberta de RyotaK em 2021 transformou um nome de ficheiro .tgz forjado num path traversal que substituiu um script executado regularmente e expôs o GITHUB_REPO_API_KEY e o WORKERS_KV_API_TOKEN a partir de /proc/self/environ.
- Comportamento sobre origem: A cside não recorre a listas de permissões (whitelisting) de fontes; o seu agente no navegador observa o comportamento em tempo de execução de cada script em 100% das sessões, monitoriza mais de 60 atributos com IA e tem em conta o contexto histórico — exatamente o que teria detetado a execução arbitrária de comandos a passar pelo CDN em que mais de 12% da internet confia.
- Verificar, não confiar: O post-mortem da Cloudflare é um exemplo de transparência, mas o exploit teria sido executado diretamente no navegador e contornado a WAF, pelo que a questão é se confiar nas fontes continua a ser o modelo do lado do cliente ou se verificar o que estas entregam é a única opção defensável.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Verificar se as fontes dos seus scripts de terceiros são fiáveis é importante. Mas isso, por si só, pode não ser suficiente.
Foi isso que o mundo aprendeu em 2021, quando foi assinalada uma vulnerabilidade massiva no cdnjs da Cloudflare. Eis o resumo do que aconteceu e como.
O cdnjs é uma das Redes de Distribuição de Conteúdo (CDN) JavaScript mais utilizadas atualmente. Mais de 12% de todos os sites na internet injetam pelo menos um script através do cdnjs. Um investigador com o nome de utilizador 'RyotaK' partilhou uma vulnerabilidade na cadeia de abastecimento do cdnjs, que permitia a qualquer pessoa na internet submeter alterações às bibliotecas do cdnjs seguindo uma sequência de passos específicos. Aqui estão as suas conclusões completas.
A vulnerabilidade existia dentro do servidor de atualização de bibliotecas do cdnjs. Este módulo específico ajuda os programadores a integrar de forma segura pacotes populares nos seus sites.
A vulnerabilidade em detalhe
Ao publicar um ficheiro .tgz no registo npm com um nome de ficheiro concebido para explorar esta falha de path traversal, um atacante podia levar o servidor de atualização de bibliotecas do cdnjs a processar o ficheiro malicioso. Isto substituiria um ficheiro de script executado regularmente, levando à execução arbitrária de comandos nos servidores da Cloudflare.
Para provar a explorabilidade, foi planeada uma demonstração. Esta envolvia a criação de um ficheiro .tgz que, ao ser processado pelo mecanismo de atualização do cdnjs, substituiria um script inofensivo por código malicioso. No entanto, antes de executar este plano, o investigador descobriu outro vetor de ataque potente através de atualizações de repositórios Git, envolvendo symlinks que podiam ler ficheiros arbitrários a partir do servidor de atualização.
Um erro durante o processo de demonstração expôs algo pior. Uma ligação simbólica destinada a apontar para um ficheiro inofensivo foi, por engano, direcionada para /proc/self/environ, expondo variáveis de ambiente sensíveis, incluindo GITHUB_REPO_API_KEY e WORKERS_KV_API_TOKEN. Isto mostrou como um atacante podia obter acesso à maior parte da infraestrutura do cdnjs.
Os potenciais problemas
Isto poderia ter resultado em execução remota de código nos servidores da Cloudflare e na possibilidade de executar código malicioso nos scripts, que são usados por todos os utilizadores finais. Isto contorna as Web Application Firewalls (WAF) e quaisquer outros mecanismos de filtragem, uma vez que é executado diretamente no próprio navegador.
Como mencionado anteriormente, isto teria exposto mais de 12% dos sites e todos os seus visitantes a perigo imediato caso fosse explorado (após a expiração das caches).
A Cloudflare reagiu rapidamente e tomou as medidas adequadas antes que alguém conseguisse tirar partido do exploit. É conhecida pelos seus post-mortems e divulgações de incidentes detalhados e muito transparentes. Os detalhes completos podem ser lidos aqui.
A melhor forma de o fazer
Tudo isto demonstra que não se pode simplesmente confiar nas fontes.
Até os melhores do mundo são propensos a erros. Uma forma mais segura e protegida é verificar o que essas fontes entregam.
É por isso que a cside existe. Oferecemos um pequeno script para adicionar a uma página web, que faz 2 coisas:
- Reescreve as origens dos scripts para que a cside os obtenha e analise. Isto coloca a cside no fluxo do pedido entre o utilizador e o script de terceiros, permitindo visibilidade total sobre os scripts servidos. A cside inspeciona cada script em profundidade, em 100% das sessões, em vez de se limitar a colocar fontes em lista de permissões. Em alguns casos, é até possível fazer otimizações através do cache de scripts estáticos.
- Realiza algumas verificações de comportamento do lado do navegador.
A cside também monitoriza mais de 60 atributos e usa IA para sinalizar, em tempo real, quaisquer indicadores de intenção maliciosa. A nossa solução também tem em conta o contexto histórico, pelo que as alterações ao longo do tempo são mais fáceis de identificar como possíveis sequestros. A cside também usa IA para analisar o código do script de terceiros. A combinação dos nossos mecanismos de deteção significa que conseguimos identificar a tentativa em milissegundos e podemos travá-la antes de qualquer operação maliciosa, ou alertar caso surja comportamento perigoso.
