GitHub bloqueia pesquisador de segurança que divulgou exploit zero-day do Windows
(tomshardware.com)- A conta do GitHub de Nightmare-Eclipse foi bloqueada, e ele afirma que transferiu seu ambiente de trabalho para o GitLab por considerar a medida uma retaliação da Microsoft
- O conflito ganhou força no início de abril com a divulgação do zero-day BlueHammer, e Eclipse diz que a Microsoft ignorou tanto a denúncia quanto o pedido de recompensa
- Como a Microsoft não revelou o motivo nem o contexto do bloqueio, segue incerto se o ponto central é a divulgação fora do padrão ou uma falha no processo de denúncia e recompensa
- Eclipse divulgou seis zero-days do Windows, incluindo BlueHammer, RedSun e UnDefend, e alguns deles já estão sendo ativamente explorados em ambientes reais
- O bloqueio no GitHub dificilmente impede o uso de código e exploits já públicos e expõe os limites dos processos de divulgação e correção diante da aceleração da descoberta de falhas por IA
Bloqueio da conta no GitHub e migração para o GitLab
- A Microsoft bloqueou a conta do GitHub do pesquisador de segurança Nightmare-Eclipse (Chaotic Eclipse) por um motivo que ainda não foi divulgado
- Eclipse afirmou que transferiu seu ambiente de trabalho para o GitLab e que a conta da Microsoft usada para relatar bugs também já foi excluída
- Em uma postagem no blog, ele afirma que a medida foi retaliatória e diz que a Microsoft se recusou a se comunicar e também não pagou recompensa
- O programa de recompensas do MSRC da Microsoft paga, dependendo das condições, até US$ 30 mil a US$ 100 mil por zero-days de endpoint e até US$ 250 mil por vulnerabilidades no Hyper-V
- Eclipse já divulgou seis exploits zero-day e deu a entender que pode haver uma nova divulgação relacionada à Microsoft em 14 de julho
O conflito entre Microsoft e Eclipse
- O conflito se intensificou no início de abril, quando Eclipse divulgou o zero-day BlueHammer sem aviso prévio
- O blog de Eclipse critica duramente a Microsoft e o MSRC, alegando que a empresa ignorou ou recusou denúncias de zero-day e não pagou a recompensa solicitada, causando prejuízo financeiro
- Eclipse também afirma que ouviu da Microsoft que “arruinariam sua vida” e que isso de fato aconteceu, além de dizer que possui uma espécie de dead man’s switch
- Como a Microsoft não divulgou os detalhes do caso, é difícil determinar se se trata de um pesquisador que não seguiu os procedimentos padrão de divulgação ou de uma empresa que tornou o processo de relato de falhas mais difícil
Controvérsia sobre o processo do MSRC e pressão sobre a política de divulgação
- William Dormann, da Tharros, criticou em um texto sobre o BlueHammer que o MSRC antes era bom para colaboração, mas que, para cortar custos, demitiu profissionais experientes e deixou pessoas que apenas seguem planilhas de processo
- Dormann avalia que o MSRC agora parece exigir o envio de vídeos do exploit, e que a Microsoft pode ter encerrado o caso porque o denunciante não enviou esse material
- Com o silêncio da Microsoft, ainda não fica claro se o ponto central desse conflito é o funcionamento real dos processos de divulgação responsável de vulnerabilidades e dos programas de recompensa
- Com pesquisas de segurança apoiadas por IA, surgiram avaliações de que o padrão de 90 dias entre divulgação e correção na prática se tornou um modelo ultrapassado
- Em um contexto em que o tempo até a criação de exploits e o volume de exploits não utilizados estão se aproximando de zero, cresce a necessidade de Microsoft e outras empresas de software ajustarem suas políticas
Zero-days do Windows já divulgados
- Eclipse divulgou vários exploits zero-day do Windows
- BlueHammer é uma vulnerabilidade que permite obter privilégios SYSTEM por meio do Defender
- RedSun também permite acesso com privilégios de usuário SYSTEM
- UnDefend pode colocar o Defender offline
- GreenPlasma obtém acesso SYSTEM por meio do serviço CTFMon
- MiniPlasma permite elevação de privilégio semelhante por meio de uma falha no driver Windows Cloud Filter
- YellowKey é uma vulnerabilidade no BitLocker que permite a um atacante abrir unidades criptografadas com esforço mínimo, comprometendo o propósito central do BitLocker
Exploração real e impacto para a segurança
- BlueHammer, RedSun e UnDefend já foram confirmados como ativamente explorados em ambientes reais
- As demais vulnerabilidades também tiveram código de prova de conceito total ou parcial divulgado, o que facilita o uso por atacantes interessados
- O bloqueio da conta no GitHub não é suficiente para remover código já público nem para impedir exploração, e tende a ampliar o conflito entre pesquisadores e empresas donas de plataformas
- A combinação de divulgação de zero-days, disputa por recompensas, bloqueio de conta e descoberta acelerada de falhas por IA torna ainda mais visíveis os limites dos processos tradicionais de relato, validação e correção de falhas de segurança
1 comentários
Comentários do Hacker News
Se eu encontrar um bug de segurança em um app web, não vou mais reportar. Na primeira vez que reportei, quase fui preso pela polícia; na segunda, nem me responderam e foram falar diretamente com meu empregador, dizendo que a denúncia foi desagradável e que eu queria escrever sobre isso depois da correção
Depois disso, concluí que não vale a pena passar por esse tipo de dor de cabeça, e se eu simplesmente deixar pra lá, também posso ter um dia tranquilo
Também é possível fazer isso de forma totalmente anônima, então não precisa se preocupar que uma empresa exageradamente sensível vá arruinar sua vida. O FCSC da Traficom é um ótimo recurso para que pesquisadores white hat continuem contribuindo para o interesse público
Reportei isso para três contatos que consegui encontrar, mas só um respondeu, perguntando o que aqueles sistemas faziam e qual era o risco. Eu não fazia a menor ideia, e certamente não iria entrar em sistemas desconhecidos para conferir, então respondi que encaminhassem para o TI interno verificar a troca ou substituição
No fim, recebi uma resposta agradecendo pela diligência e dizendo que apagaram a foto, então o problema estaria resolvido. Espero que alguém que entendesse do assunto tenha realmente analisado, mas decidi não me envolver mais
Trabalhei profissionalmente como white hat por um tempo, mas concordo que hoje em dia tentar ser honesto e útil é arriscado. Mesmo que alguém decida vender vulnerabilidades, eu já nem julgo
Não sei exatamente o que está acontecendo aqui, mas a primeira regra de um grande programa de bug bounty é que todas as pessoas relevantes do lado do fornecedor têm fortes incentivos para efetuar o pagamento
Em muitos casos, há alguém cujas métricas internas estão atreladas ao valor pago, e nesse tipo de programa o pagamento é motivo de comemoração. É quase certo que não faz sentido achar que a Microsoft está tentando economizar dinheiro assediando quem faz a reivindicação de bounty
Isso pode não se aplicar a empresas pequenas, e esse é justamente um motivo para empresas pequenas não operarem bug bounties, mas com certeza se aplica a empresas do porte de FAANG/MAG7. Isso não significa que esses programas sempre sejam generosos nos pagamentos ou nunca tomem decisões que irritem as pessoas. Só não bate com a alegação de que estariam retendo pagamento por ressentimento
Dito isso, faz um tempo que não falo com gente da Microsoft, então deixo uma pequena ressalva
Depois de o TrueCrypt ter encerrado as atividades de repente um dia, removido todos os downloads e recomendado que todo mundo migrasse para o Microsoft BitLocker, não foi exatamente algo que ninguém pudesse imaginar
[1] - https://www.tomshardware.com/tech-industry/cyber-security/mi...
E, em vez de consertar a burocracia, insistiram ainda mais no caminho de banir a conta, o que passa uma péssima imagem. Não entendo por que a Microsoft deveria ser interpretada como agindo de boa-fé
Parece haver uma chance bem real de que seja possível descriptografar o volume sem a chave do usuário, o que é extremamente preocupante. Parece que estão tentando fingir que nada aconteceu, mas isso já veio a público
Como é a Microsoft, talvez não seja a empresa mais avançada nesse tipo de coisa, então não sei se perceberam isso
Isso porque o risco demonstrado acabou sendo maior. Em contrapartida, um grande programa foi convencido, há muito tempo, por um pesquisador de que um exploit comum de XSS podia produzir um efeito que se enquadrava em uma faixa de pagamento maior; depois disso, sempre que encontrava XSS, ele anexava uma prova de conceito com o mesmo efeito e continuava recebendo classificações indevidamente mais altas. Os XSS de outros pesquisadores eram pagos conforme a faixa de XSS da tabela
Na verdade, agora me lembro de uma exceção. Alguém conseguiu a façanha máxima de instalar um web shell no servidor da empresa, algo que, pelos padrões atuais, valeria mais de 10 mil dólares. Mas não removeu o web shell e simplesmente enviou o relatório deixando aquilo lá. O responsável pelo programa ficou furioso e disse explicitamente que, por esse motivo, não queria pagar a bounty. Não me lembro se no fim pagaram ou não
Acho que a Microsoft vai se arrepender disso
Alguém encontra um zero-day, não recebe recompensa nenhuma e ainda tem a conta banida. Aí vai vender esse zero-day para outro lugar
E ele também foi banido no GitLab, que não tem relação com a Microsoft
Nos últimos meses, passei por muitas respostas digitais estranhas em vários assuntos relacionados, e foi frustrante não conseguir identificar exatamente o que eu estava fazendo de errado. Aí li esta frase no artigo
“Mas, para economizar custos, a Microsoft demitiu as pessoas experientes e deixou apenas os seguidores de fluxograma.”
Vale a pena guardar essa expressão, seguidores de fluxograma. Não são pessoas pagas para pensar, mas sim para seguir procedimentos predefinidos. Parece que, num futuro próximo, vamos lidar muito mais com esse tipo de seguidor de fluxograma, seja digital ou humano de verdade
flowcharté praticamente a lei, e os procedimentos foram escritos com sangue e responsabilidadeJá em TI, operações e entre desenvolvedores, eles se veem como trabalhadores do conhecimento artesanais, que pensam com liberdade. Consideram atalhos, hacks e pensar fora da caixa mais ligados à competência do que seguir procedimentos
Existe alguma posição pública sobre o que está acontecendo na Microsoft? Por que Microsoft e GitLab baniram esse usuário?
Eu achava que ambas as plataformas permitiam hospedar exploits e pesquisa de segurança, desde que isso fosse claramente sinalizado desde o início, então ele provavelmente violou alguma regra
Se atirarem no mensageiro, isso deve resolver
A Microsoft criou para si mesma uma responsabilidade editorial de remover zero-days do GitHub?
Se um zero-day do meu software aparecer no GitHub, a Microsoft também vai derrubar essa conta?
Esta situação mostra bem o conflito estrutural de interesses de a Microsoft ser dona do GitHub
O GitHub tem termos de serviço claros sobre hospedar exploits ativos e armamentizados, mas banir um pesquisador que tinha como alvo o Windows inevitavelmente vai parecer retaliação, mesmo que exista uma justificativa legítima
Informação muito importante:
https://www.theregister.com/security/2026/05/28/microsoft-0-...
No post de blog da Microsoft linkado, diz o seguinte
“Os detalhes dessas vulnerabilidades não foram compartilhados com a Microsoft antes da divulgação, e essa divulgação expôs os clientes a riscos desnecessários.”
Então a Microsoft está mentindo? Se não, por que a Nightmare-Eclipse não reportou isso? É uma situação bem estranha
Independentemente de ter sido divulgação responsável ou não, quem expôs os clientes ao risco não foi o pesquisador, e sim a própria Microsoft