개발자들이 매일 쓰는 툴 중 하나가 바로 Visual Studio Code(VS Code)죠.
그런데 최근 보안 연구자들이 VS Code 확장 프로그램 마켓플레이스에서 심각한 허점을 발견했습니다.
바로 삭제된 확장의 이름을 다른 공격자가 다시 가져와 악성 확장을 배포할 수 있다는 문제입니다.
즉, 예전에 쓰던 유명 확장이 사라졌다고 방심하다가, 똑같은 이름으로 돌아온 악성 확장에 속을 수 있다는 뜻이죠.
사건의 발단: "Shiba" 악성 확장 🐕
리버싱랩스(ReversingLabs, RL) 연구진은 올해 6월, ahbanC.shiba라는 확장을 발견했습니다.
문제는 이 확장이 올해 3월 삭제된 ahban.shiba라는 악성 확장과 똑같은 “shiba” 이름을 쓰고 있었다는 점입니다.
- 2025년 3월: ahban.shiba 확장 발견 → 파일 암호화 테스트용 랜섬웨어 모듈 내장 → 삭제 처리
- 2025년 6월: ahbanC.shiba라는 새로운 확장 출현 → 동일한 동작(데스크톱 파일 암호화) → 이름만 조금 달라짐
원래 VS Code 마켓플레이스 문서에는 확장 이름은 전역에서 유일해야 한다고 명시돼 있습니다.
그런데 현실은 달랐습니다. 삭제(Remove)된 확장은 이름이 완전히 풀려버려서, 공격자가 똑같은 이름을 새로 등록할 수 있었던 거죠.
이름 재사용 취약점, 어떻게 작동하나? 🕳️
VS Code 확장의 고유 ID는 <publisher>.<name> 형식으로 구성됩니다.
공식 가이드에 따르면 name은 유일해야 하며, 소문자와 공백 없는 형태여야 한다고 되어 있죠.
하지만 RL 연구팀이 직접 테스트한 결과, 상황은 이렇게 정리됩니다.
- Unpublish(게시 취소) → 이름은 계속 예약 상태라서 다른 퍼블리셔가 사용 불가
- Remove(삭제) → 이름이 완전히 풀려서 누구나 다시 등록 가능
즉, 공격자는 삭제된 유명 확장의 이름을 그대로 가져와 **악성 확장을 "부활"**시킬 수 있습니다.
실제로 RL은 “myextensiontest”라는 확장을 만들고, 삭제 후 동일 이름으로 다른 퍼블리셔가 등록할 수 있음을 입증했습니다.
심지어 과거 악성 확장으로 유명했던 “Solidity-Ethereum” 이름조차 다시 사용할 수 있다는 사실도 확인했죠.
공격 시나리오: 개발자를 노린 공급망 공격 💻
이번 취약점은 단순한 버그가 아닙니다.
개발자 IDE(개발 환경)라는 핵심 지점을 공격할 수 있는 공급망 위협이죠.
- 공격자가 유명 확장의 이름을 가져와 재등록
- 개발자가 “어? 이거 내가 예전에 쓰던 확장인데?” 하고 설치
- 실제로는 악성 코드(랜섬웨어, 크리덴셜 탈취, 백도어 등) 실행
특히 이번 ahbanC.shiba 확장은 PowerShell 스크립트를 내려받아 데스크톱 파일을 암호화하는 랜섬웨어 모듈을 실행했습니다.
게다가 VS Code 콘솔 확장(VSCode IDE Extension)까지 노려,
Nx와 같은 빌드 도구 확장 사용자들까지 타겟으로 삼은 사례도 있었습니다.
왜 위험하냐? 🚨
- 개발 환경 직접 감염 → 소스 코드, API 키, 클라우드 토큰 등 민감 자격 증명 유출
- 확산 속도 빠름 → 오픈소스 마켓플레이스라 설치 장벽이 낮음
- 탐지 어려움 → 기존에 쓰던 확장 이름이라 사용자 의심이 적음
더 무서운 건 이게 PyPI, npm, RubyGems 같은 다른 오픈소스 생태계에서 이미 여러 차례 반복된 문제라는 점입니다.
즉, 이름 관리 정책이 허술하면 언제든 공격자들이 이 길을 파고들 수 있습니다.
개발자와 보안팀이 할 수 있는 대응 🛡️
- 출처 확인: 확장 설치 시 퍼블리셔(출판자) 이름과 이력 확인 필수
- 코드 서명(Signing) 확인: 공식 서명된 확장 우선 사용
- 보안 도구 활용: ReversingLabs Spectra Assure 같은 플랫폼으로 확장 리스크 평가
- 마켓플레이스 개선 요구: 삭제된 확장은 이름을 재사용 못 하도록 예약하거나 블랙리스트 관리 필요
정리 ✍️
VS Code 마켓플레이스에서 발견된 이름 재사용 취약점은 단순한 실수가 아니라, 공급망 공격의 심각한 단서입니다.
누구든 삭제된 확장의 이름을 재등록할 수 있다면, 사용자들은 예전처럼 보이는 확장을 아무 의심 없이 설치할 수밖에 없습니다.
앞으로 개발자 생태계 보안은 단순히 코드 취약점만이 아니라, “이름과 식별자 관리 정책”까지 포함해야 합니다.
공격자는 기술뿐 아니라 신뢰 체계의 틈새를 노린다는 사실을 잊지 말아야 합니다.
'CyberSecurity > Cyber Risk Insights🔐' 카테고리의 다른 글
| WAF도 속았다! 😱 파라미터 오염을 이용한 XSS 신기술 (0) | 2025.09.09 |
|---|---|
| 워드프레스, 여전히 사이버 공격의 최전선에 서다 🌐🔒 (0) | 2025.09.03 |
| AI Waifu RAT, AI 커뮤니티를 노린 신종 원격 액세스 트로이목마 ⚠️ (2) | 2025.09.01 |
| AI가 15분 만에 익스플로잇을 만든다고? Auto Exploit 프로젝트의 충격 ⚠️ (2) | 2025.09.01 |
| CrowdStrike, Onum 인수로 차세대 SIEM 업그레이드 🚀 (3) | 2025.08.30 |

