깃허브, 윈도우 제로데이 공개한 보안 연구자 계정 차단

• 윈도우 보안 쪽에서 꽤 위험한 드라마가 이어지는 중임

  • 보안 연구자 나이트메어 이클립스가 윈도우 제로데이 익스플로잇을 공개해왔고, 깃허브 계정이 차단됨
  • 연구자는 깃랩으로 옮겼고, 마이크로소프트가 자신을 보복성으로 압박했다고 주장함
  • 기사에 따르면 마이크로소프트는 연구자가 버그를 제보하던 마이크로소프트 계정도 이미 삭제한 것으로 알려짐

• 연구자의 주장은 “제보했지만 제대로 소통도 보상도 못 받았다”에 가까움

  • 글에서는 마이크로소프트가 연락 시도를 거부했고, 자신은 “한 푼도 받지 못했다”고 주장함
  • 이는 마이크로소프트 보안 대응 센터의 버그 바운티 보상을 겨냥한 말로 보임
  • 해당 프로그램은 조건에 따라 엔드포인트 제로데이에 3만~10만 달러, 하이퍼브이 취약점에는 최대 25만 달러를 지급할 수 있음

• 갈등은 4월 초부터 본격화됐다고 함

  • 연구자는 사전 경고 없이 BlueHammer 제로데이를 공개했음
  • 이후 글들에서 마이크로소프트와 보안 대응 센터를 강하게 비난했고, 표현은 꽤 격앙돼 있음
  • 7월 14일에 추가 공개를 암시하는 발언도 했는데, 맥락상 더 많은 제로데이 공개 가능성으로 읽힘

• 공개된 취약점 목록이 꽤 심각함

  • BlueHammer는 윈도우 디펜더를 통해 시스템 권한을 얻는 취약점으로 설명됨
  • RedSun도 시스템 권한 상승을 가능하게 하는 취약점임
  • UnDefend는 디펜더를 무력화함
  • GreenPlasma는 CTFMon 서비스를 통해 시스템 권한을 얻고, MiniPlasma는 윈도우 클라우드 필터 드라이버 결함을 이용해 비슷한 권한 상승을 제공함
  • YellowKey는 비트로커 취약점으로, 암호화된 드라이브를 거의 힘들이지 않고 여는 문제로 설명됨

• 특히 BlueHammer, RedSun, UnDefend는 실제 공격에 악용 중인 것으로 확인됐다고 함

  • 나머지도 전체 또는 일부 개념증명 코드가 공개됐기 때문에 악용이 어렵지 않을 수 있음
  • 제로데이 공개가 보안 연구의 압박 수단이 되는 순간, 방어자에게는 패치 전 노출 시간이 그대로 공격 기회가 됨

• 외부 전문가 반응도 마이크로소프트에 우호적이지만은 않음

  • Tharros의 윌리엄 도먼은 과거 마이크로소프트 보안 대응 센터가 협업하기 좋았지만, 숙련 인력이 줄고 절차만 따르는 사람들이 남았다는 취지로 비판함
  • 그는 연구자가 익스플로잇 동영상을 제출하지 않아 케이스가 닫혔을 가능성을 언급했는데, 요즘 마이크로소프트 보안 대응 센터의 요구 조건이라는 설명도 덧붙임
  • 물론 마이크로소프트는 세부 내용을 밝히지 않았기 때문에, 연구자가 표준 공개 절차를 따르지 않은 것인지 회사 대응이 문제였는지는 확정하기 어려움

• 깃허브 계정 차단은 보안 측면에서 효과보다 역효과가 커 보인다는 평가가 나옴

  • 이미 코드가 퍼졌다면 계정 하나를 닫아도 보안 위험은 사라지지 않음
  • 오히려 마이크로소프트 소유 플랫폼이 비판적 연구자를 막았다는 인상을 주기 쉬움
  • 연구자는 이미 깃랩으로 옮겼기 때문에 유통 채널만 바뀐 셈임

• 이 사건은 90일 공개 관행이 흔들리는 더 큰 흐름과도 맞물림

  • 인공지능 기반 보안 연구로 취약점 탐색과 악용 속도가 빨라지면서, 기존의 제보 후 90일 패치 대기 모델이 낡았다는 지적이 커지고 있음
  • 공격까지 걸리는 시간과 미사용 익스플로잇의 여유가 줄어드는 상황에서는 기업의 보상·검증·패치 프로세스도 더 빨라져야 함
  • 연구자와 벤더 사이 신뢰가 깨지면 가장 손해 보는 쪽은 결국 패치 전 시스템을 운영하는 사용자와 기업임

• 한국 개발자와 보안팀 입장에서는 “해외 보안 커뮤니티 싸움”으로 넘기기 어렵다

  • 윈도우, 디펜더, 비트로커는 국내 기업과 공공기관에서도 널리 쓰는 기본 인프라임
  • 제로데이 공개와 실제 악용이 겹치면, 패치 관리·위협 인텔리전스·엔드포인트 탐지 정책을 바로 점검해야 함
  • 특히 보안 솔루션 자체를 우회하거나 무력화하는 취약점은 일반 애플리케이션 버그보다 대응 우선순위가 높아질 수밖에 없음

---

기술 맥락

• 제로데이가 위험한 이유는 패치보다 공격 정보가 먼저 움직이기 때문이에요. 제조사가 문제를 고치기 전에 개념증명 코드나 익스플로잇이 공개되면, 공격자는 바로 재현을 시도할 수 있고 방어자는 임시 완화책으로 버텨야 해요.

• 버그 바운티와 책임 있는 공개 절차는 이 시간차를 줄이기 위한 장치예요. 연구자는 취약점을 먼저 기업에 알려주고, 기업은 보상과 패치를 통해 공개 전 위험을 낮추는 구조죠. 그런데 보상이나 소통에서 신뢰가 깨지면 연구자가 공개 압박을 선택할 유인이 커져요.

• 이번 사례에서 특히 민감한 건 윈도우 디펜더와 비트로커가 언급됐다는 점이에요. 디펜더는 많은 조직에서 기본 방어선이고, 비트로커는 디스크 암호화의 핵심이에요. 이런 방어 계층 자체가 우회되거나 무력화되면 일반 앱 취약점보다 운영 리스크가 훨씬 커져요.

• 깃허브 계정 차단은 유통 경로를 막는 조치에 가깝지만, 보안 문제를 해결하는 조치는 아니에요. 코드가 이미 복제됐거나 다른 저장소로 옮겨가면 방어 효과는 제한적이에요. 결국 중요한 건 계정 제재보다 취약점 재현, 영향 범위 확인, 패치와 완화책 배포 속도예요.