퇴치 선언이 내려진 지 불과 몇 주 만에 글래스웜(GlassWorm)이 다시 모습을 드러냈다. 이번에도 보이지 않는 유니코드 문자와 블록체인 기반 C2(Command and Control) 기법을 활용해 오픈소스 확장 기능을 감염시키고 있다.
오픈소스 확장 레지스트리 프로젝트 오픈VSX(OpenVSX)가 글래스웜을 “완전히 차단하고 격리했다”라고 발표한 지 불과 2주 만에 이 자기 복제형 웜이 다시 활동을 재개했다. 이번에는 비주얼 스튜디오 코드(Visual Studio Code, VS 코드)의 확장 기능을 표적으로 삼았다. 이 확장 기능은 오픈소스 VS 코드에 새로운 기능, 디버깅 도구, 워크플로우 향상 기능 등을 추가해 개발 효율성을 높이는 애드온 형태다. 보안업체 코이(Koi) 연구팀은 최근 새로운 감염 사례를 확인했으며, 3가지 확장 기능이 추가로 손상된 사실을 발견했다.
2024년 10월 처음 발견된 글래스웜은 표시되지 않는 유니코드 문자를 활용해 맬웨어를 VS 코드 환경의 코드 에디터에서 보이지 않게 숨기는 방식으로 작동한다. 이번에는 더 나아가 AI가 생성한 정상적인 코드 커밋처럼 위장한 악성 페이로드를 깃허브 리포지토리에 삽입하며 개발자가 신뢰하는 코드 리포지토리 내부까지 침투하고 있다.
러시아 기반의 공격 집단이 배포한 것으로 추정되는 글래스웜은 전 세계로 확산 중이다. 미국, 유럽, 아시아, 남미의 개발자와 기업 다수가 피해를 입었으며, 중동 지역의 한 주요 정부 기관도 감염된 것으로 확인됐다.
코이 연구팀은 “공격 인프라가 여전히 완전하게 가동 중이며, 동일한 해커 집단이 활동을 지속하고 있다. 이제는 단순히 감염된 확장 기능의 문제가 아니다. 실제 피해자가 발생하고 있으며, 주요 인프라가 위험에 노출돼 있다. 글래스웜은 경고했던 것처럼 개발자 생태계 전반으로 확산하고 있다”라고 경고했다.
깃허브 리포지토리까지 침투
코이 연구팀은 오픈VSX 레지스트리에 등록된 3가지 확장 기능에서 글래스웜 감염을 새롭게 확인했다고 밝혔다. 이들 확장 기능은 합산 다운로드 수가 1만 회 이상에 달하는 것으로 집계된다.
- - adhamu.history-in-sublime-merge – 약 4,000회 다운로드
- - ai-driven-dev.ai-driven-dev – 약 3,300회 다운로드
- - yasuyuky.transient-emacs – 약 2,400회 다운로드
이들 확장 기능은 정상적으로 표시되고 설치할 수 있지만 내부 코드에 글래스웜이 “실제로는 보이지 않는 상태”로 존재한다. 이들은 출력 불가능한 유니코드 문자로 인코딩돼 있어, 사람 눈에는 단순한 공백처럼 보이지만 실제로는 자바스크립트 코드로 실행된다.
공격자들은 악성 페이로드 배포를 위한 원격 C2 엔드포인트 갱신 정보를 담은 새로운 트랜잭션을 솔라나(Solana) 블록체인에 게시했다. 다만 연구팀은, 이들 트랜잭션이 최근에 올라왔음에도 불구하고 실제 페이로드 서버는 변함없이 유지되고 있다고 지적했다.
코이 연구팀은 “이 사례는 블록체인 기반 C2 인프라의 복원력을 보여준다. 페이로드 서버가 제거되더라도 공격자는 1센트도 채 안 되는 비용으로 새로운 트랜잭션을 게시할 수 있고, 감염된 모든 기기는 자동으로 새 위치를 가져온다”라고 설명했다.
일부 개발자들은 최근 자신의 깃허브 리포지토리가 침해된 정황을 보고하고 있다. 정상적인 개발 과정에서 생성된 것처럼 보이는 AI 생성 코드 커밋이 추가됐지만, 실제로는 VS 코드 확장 기능에서 발견된 것과 동일한 보이지 않는 유니코드 기반 맬웨어가 포함된 것으로 드러났다. 또한 공격자들은 개발자의 깃허브 인증 정보를 탈취한 뒤, 웜 기법을 이용해 추가 리포지토리로 악성 커밋을 전파하고 있는 것으로 확인됐다.
위협 인텔리전스 업체 SOC레이더(SOCRadar)의 CISO 엔사르 세케르는 “글래스웜이 이렇게 빠르게 재등장한 것은 매우 우려스러운 일이지만, 완전히 예상 밖은 아니다”라고 평가했다.
이번 사태의 위험성은 공급망 형태의 웜이 제거된 뒤에도 다시 재등장했다는 점에 있다. 세케르는 “몇 개의 확장 기능을 삭제하는 것만으로는 충분하지 않다. 공격자가 전파 메커니즘을 통제하고 여러 마켓플레이스에 걸쳐 확산 지점을 장악하고 있는 상황에서는 감염을 완전히 차단하기 어렵다”라고 설명했다.
오픈소스의 근본적인 취약점
이번 사건과 관련해 흥미로운 점이 있다. 공격자들이 자신들의 인프라를 관리하는 과정에서 실수를 범했다는 것이다. 코이 연구팀은 공격자 측에서 노출된 엔드포인트를 통해 일부 데이터를 확보하고, 피해자 목록의 일부분을 추출하는 데 성공했다고 밝혔다. 또한 공격자들의 키로거 데이터를 분석한 결과, 이들은 오픈소스 C2 프레임워크 브라우저 확장 프로그램 ‘레드엑스트(RedExt)’를 사용하고 있으며, 여러 메신저 플랫폼과 암호화폐 거래소의 사용자 ID에도 접근할 수 있었던 정황을 포착했다.
코이 연구팀은 확보한 피해자 명단을 수사 당국에 전달했으며, 피해자들에게 개별 통지가 진행 중이라고 설명했다. 현재 해당 사건에 대한 공식적인 조사 절차가 진행 중이다.
보서론 시큐리티(Beauceron Security)의 데이비드 시플리는 이번 글래스웜 사태가 단순히 기술적 문제를 넘어 프로세스와 시장 구조에 기반한 문제이기도 하다며 “오픈VSX 커뮤니티는 제출된 코드를 일일이 수동 검토할 만큼의 인력과 자원을 갖추고 있지 않다. 현재는 자동화된 도구와 배포자 계약에 의존하고 있는 상황”이라고 설명했다.
이런 구조적 한계는 오픈소스 생태계의 근본적인 취약점이다. 시플리는 “오픈소스 시장 모델은 무료 또는 저비용 접근 방식을 기반으로 하기 때문에 충분한 자원이 확보되지 못하고 보안 강화를 위한 인센티브도 제대로 작동하지 않는다. 이로 인해 오늘날의 위협 환경에 필요한 수준의 보안 검증이 제대로 이루어지지 못하고 있다”라고 분석했다.
시플리는 “간단히 말해 수동 코드 리뷰를 할 만큼 충분한 보상을 받지 못하면 아무도 그 일을 하지 않는다. 교묘한 해킹 기법을 찾아낼 수 있는 인력이 부족하면 결국 그 교묘한 해킹은 그대로 통과한다”라고 덧붙였다.
오픈VSX의 가치를 다시 물어야 할 때
시플리는 보안 담당자가 오픈VSX의 실질적 가치를 재검토할 필요가 있다고 말했다. 시플리는 “오픈소스 레지스트리에서 내려받은 코드를 직접 검토하고 이상 징후를 탐지해 경고를 보낼 의지가 있다면 위험을 줄일 수 있다. 그렇지 않다면, 더 엄격한 검증 절차와 리뷰 체계를 갖춘 큐레이션된 코드 출처를 사용하는 것이 바람직하다”라고 조언했다.
또한 시플리는 “지금의 사이버보안 경쟁에서 공급망과 오픈소스는 핵심 표적이 됐다. 이 구조는 당분간 계속될 것이다. 경제적 균형이 재조정돼 보안에 더 많은 자원이 투입되거나, 아니면 이 모델이 ‘보안 불안정성’ 아래 붕괴될 때까지 이런 상황은 이어질 것”이라고 내다봤다.
시플리는 “100% 완벽하게 이런 위협을 막아줄 마법 같은 AI 자동화 기술은 존재하지 않는다”라고 강조하며, “지금까지는 자동화된 보안 스캔이 충분히 효과적이라고 여겨졌지만 공격자들이 이 방식을 매우 유효한 공격 전달 수단으로 악용할 수 있다는 점을 깨닫는 순간, 그 방어 체계는 한계에 부딪힌다”라고 지적했다.
SOC레이더의 세케르도 이에 동의하며 “문제의 본질은 맬웨어 자체가 아니라 공급망 위협의 구조적 변화에 있다”라고 분석했다.
세케르는 “이제 소프트웨어 공급망은 단순히 의존도 문제에 그치지 않는다. 툴체인, 마켓플레이스, 그리고 전체 개발 생태계가 모두 보안의 일부로 포함돼야 한다. 개발자 인프라를 실제 서비스가 운영되는 프로덕션 인프라처럼 동일한 수준으로 보호해야 한다”라고 강조했다.
감염을 방지하기 위해 개발자와 보안팀은 보이지 않는 유니코드 문자를 포함한 악성 확장 기능이 업로드되는 정황, 블록체인 메모나 구글 캘린더 등 정상 서비스를 악용해 차단을 회피하는 숨은 C2 채널, 감염된 개발자 머신이 프록시 노드로 악용돼 추가 감염을 확산시키는 사례 등에 주목해야 한다.
또한 신뢰할 수 있는 배포자가 제공한 구성 요소만 사용하고, 가능한 경우 자동 업데이트 기능을 비활성화하며, 설치된 확장 기능의 목록을 체계적으로 관리한다. 워크스테이션에서 비정상적인 외부 연결, 개발자 인증 토큰(npm, 깃허브, VS 코드 등)의 탈취 시도, 프록시나 VNC 서버 생성 활동은 실시간으로 모니터링해야 한다. 더불어 서드파티 라이브러리 검증에 적용하는 동일한 수준의 보안 기준과 절차를 자체 개발 도구 체인에도 적용해야 한다.
세케르는 “공격자가 개발자의 IDE를 공격 출발점으로 활용하게 되면 공급망 전체의 노출 범위가 급격히 확장된다. 이런 공격은 단일 라이브러리를 패치하면 끝나는 일반적인 공급망 공격과는 다르다. 지속성을 염두에 두고 설계된 공격”이라고 강조했다.
dl-itworldkorea@foundryco.com
Taryn Plumb editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
