Microsoft의 오픈소스 도구가 AI 개발자의 비밀번호를 훔치기 위해 해킹됨

순전히 추측이고 개인적인 관찰이지만, 예전의 RBAC 모델은 이미 거의 망가져 있었고 이제는 완전히 깨진 것처럼 보임
코딩 어시스턴트와 엔지니어가 서로 무관한 여러 프로젝트를 동시에 만지고, 특히 예전엔 시간이 없어서 못 하던 실험까지 벌이면서 기업 내 공급망 위험이 크게 커졌다고 봄
직접 관련됐다고 말하는 건 아니지만 영향은 있다고 느끼고, 요즘 많은 곳에서 개인 장비로 대충 AI 코딩을 하라고 개발자와 관리자들이 부추기는 것도 곧 문제가 될 것 같음
최근 공급망 사고들 사이에 공통된 흐름이 없다고는 믿기 어렵고, 이런 공격을 전문으로 하는 해킹 그룹이 있는 것도 보상이 크기 때문이라고 봄

분명히 해두면, 원댓글이 관련 있다고 단정한 건 아니지만 이건 AI나 바이브 코딩과는 전혀 관계없음
오래전부터 존재해 온 개발자 의존성 설치 보안 부재와 Shai Halud 웜의 연장선임
해커들은 개발자를 속여 무언가 설치하게 만들기 쉽고, 개발자 장비에는 자격 증명, 클라우드 CLI, MCP 같은 민감한 정보가 많아서 이상적인 표적이라는 걸 알아냈음

우리 회사도 비슷함. “AI로 최대한 많이 하지 않으면 뒤처진다” 같은 교리가 퍼져 있음
보안은 신경 쓰지 않고 무리에서 제일 먼저 달리려는, 예전의 IoT 과열을 그대로 반복하는 느낌임

총 프로젝트 수에 비해 인력이 너무 적다고 몇 년 동안 주장했지만, 경영진은 대부분의 프로젝트가 유휴 상태라서 한 사람당 많이 맡겨도 괜찮다고 했음
결국 이렇게 됨

역할 기반 접근 제어, 즉 RBAC를 다른 것으로 대체해야 한다는 뜻인지, 아니면 현재 쓰는 특정 RBAC 모델들이 망가졌다는 뜻인지 궁금함
개인적으로는 이름이 좀 헷갈리지만 capability 기반 보안 모델이 미래라고 봄

제목 표현부터 편향적이고, 본문도 마치 오픈소스의 잘못인 것처럼 씀
그러고는 시도된 공급망 공격의 책임을 Microsoft에 돌리는 식이라 더 웃김 Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch.라고 하는데, 오픈소스가 원래 그렇게 동작하는 걸 TechCrunch가 설명하지 않음
Microsoft를 깔 수 있을 때 까는 걸 좋아하지만, 이번에는 Microsoft가 안전하고 올바른 조치를 했다고 봄
기사에서는 마치 전부 Microsoft 잘못이고 침해 범위를 제한한 것도 부끄러운 일인 것처럼 씀 steal passwords of AI developers라는 표현도 “AI 개발자”인지 “AI를 쓰는 개발자”인지 묘한 함의를 남김
공급망 공격에 대한 설명도 실제 의미가 아니라 결과와 공격 표면의 이유만 말하고 있어서, 이번 보도는 매우 좋지 않다고 봄

TechCrunch는 매우 부주의하고 신뢰하기 어려움
직접 일했던 내용을 보도하면서 검색 최적화용으로 사실을 지어낸 걸 본 적이 있고, 정정하게 만들 방법도 없었음

감염된 모든 저장소에서 웜을 수정하거나 제거할 수 있는 완화 도구를 만들었고, 이에 대한 글도 썼음
월요일에 Hades 캠페인이 Composer, Go, Pip 지원을 추가했음. 그 전에는 NPM과 AI 어시스턴트 편집기만 지원했고, Ruby도 있긴 했지만 요즘 Rubygems를 쓰는 사람이 거의 없어 보임
Microsoft조차 놓치는 점은, 이게 코드 생태계의 모든 플랫폼에서 실행되는 첫 웜이라는 것임. 개발자 호스트, 서버, CI/CD 실행기 모두에서 돌고, 그 장비들이 접근 가능한 모든 저장소로 웜을 퍼뜨림
이 웜을 이기려면 모든 컴퓨터와 AWS EC2, Google Cloud Platform, Azure, Kubernetes 클러스터를 동시에 100% 꺼야 함. 말 그대로 전체 인프라를 가로질러 퍼짐
APT28 악성코드에서 늘 그렇듯 킬 스위치는 호스트 언어를 ru_RU.KOI8-R로 설정하는 것, 즉 LANG 환경 변수 설정임. 그러면 전파 메커니즘이 비활성화됨
완화 도구: https://github.com/cookiengineer/antimiasma
블로그 글: https://cookie.engineer/weblog/articles/malware-insights-mia...

전통적인 개인 접근 토큰을 지저분하게 사용한 사례일 가능성이 높다고 강하게 의심함
이상한 openclaw 장치에서 AI 에이전트에 토큰을 넘길 거라면 세분화된 토큰을 써야 함
내 GitHub 계정은 정책이 완전히 다른 조직 3개에 걸쳐 있는데, 아직도 classic 토큰이 허용된다는 사실이 좀 놀라움
최소한 각 조직마다 수동으로 허용해야 하게 만들어야 함

AI 에이전트는 별도의 보안 주체여야 하고, 필요한 저장소나 조직에 대해서만 전용 접근 토큰을 발급받아야 한다고 봄
사람 계정용으로 “주조된” 접근 토큰을 AI 에이전트에 넘기는 건 새로운 “비밀번호를 포스트잇에 적어두기”처럼 느껴짐

맞는 말이지만, 세분화된 토큰의 권한 관리는 악몽에 가까움
어떤 작업에 무엇이 정확히 필요하고 올바른지 판단하기 쉽지 않음
게다가 소프트웨어 개발자는 권한보다 코드에 집중하는 게 중요하다고 생각하는 경우가 많고, 권한은 다른 사람 책임이라고 여기기도 함

classic PAT가 원인이라면, 최근의 GitHub 저장소들 말고도 추가적인 비공개 저장소가 위험할 수 있다는 뜻 아닌가?

공개 저장소 스크래핑에는 낮은 권한 계정의 classic 토큰을 쓰고 있음
조직 수준 권한이면 내 용도에는 충분히 잘 맞을 것 같음

어제 개인 Microsoft 계정 비밀번호를 재설정해야 했음. 루마니아에서 로그인 시도가 있었다는 2단계 인증 알림이 왔기 때문임
어떻게 비밀번호를 알아냈는지는 모르겠음. 내가 가진 Microsoft 제품은 Xbox뿐임
AI 이전부터 Microsoft는 체처럼 줄줄 새는 느낌이었고, 회사가 Microsoft에서 벗어나면 좋겠지만 이미 묶여 있음

개인 Microsoft 계정에서 비밀번호 없는 로그인을 허용하지 않도록 설정하는 건 거의 불가능함
그래서 실제로는 계정이 그렇게 설정되어 있고, 받은 MFA 요청도 2단계 인증이 아니라 단순히 계정 접근을 시도한 것일 가능성이 큼
나도 하루에 여러 번 이런 요청을 받았고, 휴대폰에서 Microsoft Authenticator 앱을 설정하면 얼굴, 지문, PIN 같은 잠금이 있는 경우 강제로 비밀번호 없는 방식으로 바뀐다는 걸 알게 됨
우회하려면 Authenticator 앱에 계정을 설정하는 동안 그런 잠금을 전부 꺼야 함
Microsoft 계정을 별로 쓰지 않아서 이제는 Authenticator 대신 별도 이메일로 인증함
이런 방식으로 동작한다는 것 자체가 미친 일이지만, 아마 Microsoft 내부 누군가는 비밀번호 없는 로그인 KPI를 채우고 있을 것 같음

내가 일했던 일부 조직에서는 비밀번호가 맞는지와 무관하게 다중 인증 프롬프트가 뜨게 했음. 공격자의 시간을 더 낭비시키려는 목적이었음
Microsoft도 그런지는 확실하지 않음

어떻게 이렇게 많은 저장소에 난독화된 파일을 추가할 수 있는지 누가 설명해줬으면 함. 코드 리뷰가 전혀 없나?
제목도 오해를 부름. setup이 저장소에서 일하는 사람들이 자동 실행하게 되는 설정을 추가하는 것이고, 그 사람들은 VSCode, Cursor, Claude, Gemini를 써야 함
Codex, opencode, 다른 실행 하네스를 쓰는 사람들은 안전할 것 같음
자세한 내용: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...

한 대기업에서 일하는 친한 친구가 있음. 어느 회사인지는 말할 수 없지만 S&P 500 기업임
꽤 오래 일했는데도 자신이 맡은 프로젝트가 실제로 어떻게 생겼는지 본 적이 없고, 저장소를 클론해두었고 사용 언어만 알 뿐 그 이상은 모름
모든 게 대충 AI로 이어붙여지고 있음. 그 프로젝트는 회사 전체 제품의 인증과 인가 시스템임
본인 말로는 “하루 종일 Tab만 누르고 리뷰에는 ‘의도된 동작’이라고 쓴다. 리뷰도 전부 AI가 하고 인간은 개입하지 않는다. CEO와 CTO가 진지하게 이렇게 하라고 한다. 무언가 깨지면 실제 코드를 본 사람이 없어서 아무도 어떻게 동작하는지 모른다. 성과 평가는 우리가 한 일이 아니라 사용한 토큰 수로 한다”라고 함
지금 많은 회사가 이럴 가능성이 있고, 실제 코드 리뷰가 없다고 생각해도 무리는 아님

악성 커밋 중 다수가 작성자 github-actions 로 표시됨
내부 GitHub CI/CD 쪽으로 인증하고 있다는 뜻이고, 그런 커밋이 너무 많아서 어떤 자동화 도구도 왕겨 산더미 속 독을 찾아내기 어려움
그래서 이건 2025년 9월 GitHub 보안 침해와 관련 있음
“다섯 저장소의 GitHub 별은 합쳐 1,459개이고, mantine-datatable 하나가 1,225개를 차지한다. 별은 얼마나 많은 개발자가 소스를 로컬에 체크아웃했는지에 대한 거친 대리 지표이며, 이 공격이 노리는 집단이다.”
“모든 커밋은 서명되지 않았고, github-actions 신원이며, 메시지는 chore: update dependencies [skip ci], 같은 여섯 파일 흔적을 남겼다. 다섯 저장소를 49초 만에 훑은 건 사람이 커밋한 게 아니라 자동화다. 이는 이전 감염에서 쓰기 권한이 있는 GitHub 토큰을 수집한 뒤, 그 토큰이 닿는 모든 저장소에 지속성 페이로드를 밀어 넣는 Shai-Hulud 자기 전파와 일치한다.” https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
실제 동작: https://safedep.io/config-files-that-run-code/
저 사람들과는 관련 없지만, 지금 무슨 일이 벌어지는지에 대해 내가 찾은 가장 단순하고 자세한 설명임

동료가 진지하게 “이제 코드 대부분을 생성한다면, 실제로 그 코드를 누가 다 읽고 있지?”라고 물었음
작은 회사지만 어떤 사람들은 신탁처럼 AI를 믿고 싶어 하는 충동이 거의 종교적이라고 느껴짐
나는 내가 생성한 코드의 90% 이상을 주니어 개발자 코드 리뷰하듯 읽음
지금 새 기능을 꽤 강하게 바이브 코딩 중인데, GitHub PR이 다시 동작하기 시작하면 철저히 읽을 예정임

저장소에 푸시할 수 있는 계정이 탈취됐다면 PR 리뷰는 필요 없었을 것임

이런 사람들에게 Secure Boot의 루트 CA 인증서를 맡기고 있는 건가?

2023년 보안 검토에서 실패한 그 회사를 말하는 건가? [0]
“위에서 설명한 결함 하나하나는 개별적으로 보면 이해 가능할 수 있다. 그러나 모두 합치면 Microsoft의 조직적 통제와 거버넌스, 그리고 보안에 관한 기업 문화의 실패를 가리킨다.”
Microsoft의 제품과 서비스는 어디에나 있다. 세계에서 가장 중요한 기술 기업 중 하나이며, 어쩌면 가장 중요할 수도 있다. 이 위치에는 최고 수준의 전 세계적 책임이 따른다. 재무나 시장 출시 요인이 사이버보안과 Microsoft 고객 보호를 약화시키지 않도록, CEO에서 시작되는 책임 있는 보안 중심 기업 문화가 필요하다.
“불행히도 이 검토 전반에서 위원회는 Microsoft가 기업 보안 투자와 엄격한 위험 관리를 모두 낮은 우선순위로 둔 기업 문화를 가리키는 일련의 운영·전략적 결정을 확인했다. 이 결정들은 전 세계 Microsoft 고객에게 상당한 비용과 피해를 초래했다.”
“위원회는 Microsoft가 보안 문화를 바로잡아야 한다고 확신한다.”
[0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...

“신뢰”라기보다 “강제로 받아들여야 함”에 가까움
이번 사건도 Microsoft가 보안을 제대로 챙기는 회사라기보다 보안 문제 자체였던 전적을 이어가는 것뿐임

Microsoft를 보안과 관련해 신뢰하는 건 어리석은 일임
지난 40년 동안 신경 쓰지 않는다는 걸 여러 번 보여줬음

늦게 깨달은 편일 수도 있지만, “코드가 나쁘다” 같은 이유로 AI를 쓰고 싶지 않더라도 보안 감사에는 AI를 쓰는 걸 고려하라고 한동안 말해왔음
적어도 코드에서 취약점을 스캔하는 도구는 써야 함
공격 벡터는 데이터를 훔치는 플러그인만이 아니라, 사용하는 거의 모든 소프트웨어의 0-day 취약점과 LLM을 든 스크립트 키디가 여러분의 웹 서비스를 공격하는 것까지 포함
해킹은 늘어날 것이고 더 나빠질 테니, 사이버보안 감사와 감사 도구에 투자하지 않는 곳은 재고해야 함