1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • 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

 
GN⁺ 4 시간 전
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

    • Se quiser, você pode reportar a vulnerabilidade ao Finnish Cyber Security Centre, e eles cuidam do reporte e da mediação com as partes afetadas
      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
    • Uma vez, uma linha ferroviária postou nas redes sociais uma foto sobre “ter feito algo bom para alguém”, e na parede do escritório que aparecia na foto havia uma folha A4 com vários nomes de usuário e informações de login de diversos sistemas
      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
    • É melhor não se importar
      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
    • Algumas pessoas podem criticar a regulação, mas a Cyber Resilience Act (CRA) obrigatória da UE fez com que empresas tivessem um canal claro de contato para receber reportes de vulnerabilidades e realmente respondessem a eles
    • Você também pode tentar reportar exploits anonimamente a um órgão governamental
  • 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

    • Lendo o texto da YellowKey, parece que, em pelo menos alguns casos, ele expôs um backdoor oficial da Microsoft usado por agências de inteligência dos EUA e afins. A implicação é que o BitLocker não é seguro e tem um backdoor
      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...
    • Isso começou quando a burocracia se recusou até a analisar o Bluehammer depois de não conseguir convencer o autor da denúncia a divulgar o vídeo
      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é
    • O bug apontado por essa pessoa parece ser um backdoor do BitLocker bastante evidente, e levanta questões muito sérias sobre o que a Microsoft está fazendo em criptografia
      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
    • Se tivessem sido espertos depois do banimento, teriam contratado ele por muito dinheiro. Essas grandes empresas ficam tensas com esse tipo de situação, mas, se não forem burras, pagam
      Como é a Microsoft, talvez não seja a empresa mais avançada nesse tipo de coisa, então não sei se perceberam isso
    • Quando trabalhei avaliando bug bounties, nunca vi evidência de relutância em pagar. A pior conduta que vi do lado da empresa foi pedir em uma prova de conceito “por favor, evite X” e depois pagar um valor maior a um pesquisador que ignorou essa instrução
      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

    • Mas essa história não é sobre vender um exploit zero-day, e sim sobre divulgá-lo publicamente? O título diz isso
      E ele também foi banido no GitLab, que não tem relação com a Microsoft
    • Há outras pessoas procurando zero-days também. Reputação importa muito
    • Parece tranquilo vender zero-days para outros lugares. A CIA pode entregar milhões de dólares em barras de ouro se algum alto funcionário pedir, então imagino que nem precisem de ordem de compra para adquirir exploits
  • 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

    • A maioria das empresas de consultoria em segurança corporativa com que tive de lidar no passado operava por checklist
    • Em muitas profissões de colarinho azul, como mecânicos, eletricistas e construtores, seguir um flowchart é praticamente a lei, e os procedimentos foram escritos com sangue e responsabilidade
      Já 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 for um exploit de criptografia de disco completo que ainda exige acesso físico ao hardware, talvez tenha sido feito para alguma agência governamental de três letras
  • Se atirarem no mensageiro, isso deve resolver

    • Talvez queiram incentivar a venda para agências estatais em vez de corrigir a vulnerabilidade
  • 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?

    • Não entendo por que essa medida passaria a significar uma obrigação de agir também contra outras contas no futuro
  • 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

    • Essa frase “essa divulgação expôs os clientes a riscos desnecessários” incomoda
      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
    • O motivo de a Nightmare-Eclipse não ter reportado isso pode ser que seja uma organização de fachada de um serviço de inteligência estrangeiro, fingindo ser um pesquisador ressentido
    • Os clientes aqui talvez não sejam as pessoas ou empresas que pagaram por uma licença, mas sim o ator que encomendou esse backdoor