Fork Trovejano: De uma Brincadeira a um Ataque Crítico

64K+ Alcance em 30 dias Bastion 277,31 Classificação 26.911 Assinantes Assinar breakmirrors Há 55 minutos Fork Trovejano: De uma Brincadeira a um Ataque Crítico 5 min 2.3K Blog da Empresa Bastion Segurança da Informação * GitHub * Teste de Serviços Web * Caçadores de Bugs * Caso

Fazer um fork de um repositório é uma operação tão comum que raramente é vista com suspeita. Mas e se, por meio de um fork comum, fosse possível executar código arbitrário em um worker CI/CD de uma empresa privada?

Foi exatamente essa cadeia que descobrimos no GitFlic, uma plataforma russa para desenvolvimento de software colaborativo e armazenamento de código-fonte da empresa "ReSolut".

GitFlic é muito semelhante ao GitLab - o que é lógico, pois foi criado como sua alternativa. E os desenvolvedores tiveram sucesso: se você trabalhou com o GitLab, o GitFlic lhe dará uma agradável sensação de déjà vu.

Neste artigo, analisaremos não apenas a própria vulnerabilidade, mas também mostraremos o curso de raciocínio: por que você deve olhar para operações familiares com suspeita e como um problema "insignificante" com direitos pode se transformar em um ataque em larga escala à infraestrutura.

As vulnerabilidades que descobrimos foram prontamente corrigidas pelos desenvolvedores da empresa "ReSolut" e registradas no BDU FSTEC: BDU:2025-12462 , BDU:2025-12463 , BDU:2025-12464 .

A primeira descoberta: fork sem verificação de direitos Sistemas modernos de desenvolvimento colaborativo operam com muitas entidades: usuários, equipes, empresas, repositórios públicos e privados, forks e uma massa de objetos mais específicos. As matrizes de acesso completo para esses sistemas raramente são documentadas de forma exaustiva - muitas vezes, elas existem na forma de acordos implícitos. Isso leva a vulnerabilidades no controle de acesso.

Foi com o controle de acesso que começamos a olhar para o GitFlic. Então, para a atenção dos leitores, esta solicitação é apresentada:

O que está acontecendo aqui? Fork do repositório. Uma operação bastante comum para sistemas git, mas há uma nuance - o campo "owner" é controlado pelo usuário

Normalmente, ao fazer um fork, criamos uma cópia do repositório "para nós mesmos". Mas em cenários corporativos complexos, pode ser necessário fazer um fork não para si mesmo, mas para o espaço de uma equipe ou empresa. Portanto, o fato de o usuário poder especificar o proprietário não é um bug, mas um fenômeno bastante normal. Mas a questão de como os direitos relacionados ao valor que passamos são verificados é muito crítica.

Que perguntas o sistema deve fazer:

• O usuário tem acesso ao repositório?
• É possível fazer o fork do repositório?
• O usuário tem direitos para fazer o fork do repositório?
• O usuário tem direitos sobre a entidade de destino (usuário, equipe, empresa) para a qual o repositório será copiado?

A lista pode ser complementada ao seu gosto, mas apresentamos as perguntas mais importantes. E, infelizmente, o GitFlic não fez a pergunta nº 4. O que isso pode levar?

Um certo invasor pode criar um repositório e copiá-lo para o espaço de qualquer entidade no sistema ("usuário", "equipe", "empresa"). É importante notar: é copiar, não será possível sobrescrever um repositório existente com tal fork.

O que complementa esse problema é o fato de que tal fork tem dois proprietários de pleno direito: aquele que iniciou o fork e aquele a quem ele formalmente pertence. Simplificando, o repositório criado tem dois campos: "creator" e "owner". E os direitos de ambos são iguais e completos. Na interface, isso é exibido de forma torta, mas do ponto de vista do sistema, ambos podem fazer o que quiserem com o repositório.

Isso soa como uma boa preparação para engenharia social: criar um "cavalo de Troia" entre os repositórios da empresa e, em seguida, esperar que um dos desenvolvedores o copie e o execute. O mundo já viu exemplos de ataques semelhantes que afetam as ferramentas de desenvolvimento local, exploits para esses cenários estão disponíveis publicamente. No entanto, esses ataques dependem diretamente do comportamento e da composição da infraestrutura da potencial vítima. Devido a essas restrições, a vulnerabilidade recebeu inicialmente "baixa" criticidade.

Ainda é crítico O GitFlic se posiciona como uma plataforma moderna, e em termos de integração e implantação contínuas, ele realmente não fica atrás das tendências.

Herdando em muitos aspectos a estrutura CI/CD do GitLab, o sistema recebeu uma série de melhorias em termos de isolamento e distribuição de workers. No GitFlic, um modelo mais flexível é implementado: os workers podem ser vinculados não a repositórios, mas a entidades de nível superior - usuários, equipes ou empresas. Agora, os workers não estão em um pool geral, que é gerenciado apenas por um administrador, mas cada um decide por si mesmo se precisa de um worker e o que ele fará.

Com uma análise mais detalhada desse recurso, um paradoxo interessante foi descoberto: o mecanismo que permite tornar o sistema mais flexível e seguro transforma uma vulnerabilidade que parecia adequada apenas para social ou travessuras em uma ferramenta séria para ataques ao ambiente de desenvolvimento ou a toda a cadeia de desenvolvimento como um todo. Como isso vai parecer?

Vamos imaginar que existe uma empresa "priv-comp". Ela tem projetos fechados, desenvolvedores, CI/CD configurado. E, o que é importante, seu próprio worker privado, conectado no nível da empresa. Por padrão, tal worker atenderá a todas as tarefas CI/CD dos projetos pertencentes à empresa. A equipe é privada, os projetos não são visíveis externamente, o acesso é apenas por convite. O cenário é típico do mercado, onde muitos projetos são implementados por contratados.

Empresa privada "priv-comp" com worker privado conectado para CI/CD

E há um invasor teórico "test", que penetrou em nosso GitFlic. Ele roubou a senha de alguém ou usou o registro não desativado, não importa. Sua primeira ação será preparar um "cavalo de Troia" - um repositório com uma configuração para CI/CD.

Repositório do usuário test com configuração para CI/CD

O exemplo fornecido de configuração CI/CD é simples, acadêmico, mas reflete totalmente a essência das ações. Ao executar essa configuração, o comando no nível do sistema operacional será executado no worker conectado. Além disso, acontecerá exatamente o que dissemos antes: um fork do "cavalo de Troia" criado para a empresa "priv-comp".

O resultado para o usuário "test" será assim:

Fork criado do "cavalo de Troia" na empresa "priv-comp"

Lembra da parte sobre as peculiaridades dos privilégios do fork criado, onde foi dito sobre os direitos iguais de "owner" e "creator"? Então, a "igualdade e completude" dos direitos sobre o repositório inclui a capacidade de iniciar o pipeline CI/CD. Ou seja, o usuário "test" pode simplesmente pegar e iniciar o pipeline no fork criado, que será processado pelo worker da empresa "priv-comp".

Na verdade, o resultado:

Código arbitrário executado com sucesso no worker da empresa "priv-comp". O ataque pode ser considerado bem-sucedido.

Em vez de uma conclusão O objetivo deste artigo não era tanto falar sobre a vulnerabilidade encontrada, mas, em vez disso, mostrar o curso de nossos pensamentos ao estudar sistemas.

Ao pesquisar software, é extremamente importante entender seu propósito e as características dos mecanismos internos inerentes a ele. Isso pode sugerir em que direção cavar: afinal, os problemas típicos são chamados de típicos por uma razão.

Você também deve se lembrar que as vulnerabilidades encontradas não ficam no vácuo. Pode haver muitas outras funções próximas, aumentando ou diminuindo o nível de criticidade da descoberta. Não se esqueça de, de vez em quando, abstrair um pouco e olhar para o sistema um pouco mais amplamente - talvez haja algo por perto que o ajudará a fazer essa mesma "ruptura".

P. S. Para aqueles que leram até o fim Para os leitores mais atentos que já estavam prestes a fazer uma pergunta razoável: "Como o invasor saberá os nomes das empresas privadas para fazer o fork do repositório? Eles são privados, não são visíveis na interface".

Bem, encontramos várias vulnerabilidades, algumas delas funcionam em conjunto. Como um bônus e um convite para uma pesquisa independente, daremos uma dica na direção: /api/search/company

Explore este endpoint. Há algumas pequenas, mas informativas surpresas esperando por você lá. 😉

PURP - Canal do Telegram, onde a segurança cibernética é revelada de ambos os lados das barricadas t.me/purp_sec

• insights e insights do mundo do hacking ético e proteção orientada a negócios de especialistas da Bastion

Tags: pentest vulnerabilidades repositório gitflic controle de acesso segurança de código proteção de repositório atque à cadeia de suprimentos segurança da informação