오픈소스 리포지터리는 여러 사람이 사용하기도 하지만, 여러 사람이 수정하기도 한다. 그래서 주요 관리자가 있는데, 이 관리자들이 최근에는 자동화 기능을 적극 사용해 수정된 내용을 잘 검토하지 못하고 있다. 이 지점에서 문제가 발생한다.
[보안뉴스 문가용 기자] 사이버 공격자가 깃허브에 개설된 오픈소스 리포지터리에 여러 변경 사항을 제출하면서 악성 요소를 슬쩍 주입하면 어떻게 될까? 대부분 유지 관리를 담당하는 사람이나 단체가 이를 걸러낸다. 하지만 그런 관리 시스템에 걸리지 않고, 공격자가 살짝 바꾼 오픈소스 리포지터리로 만들어진(혹은 그 리포지터리가 개발에 사용된) 소프트웨어 프로젝트들이 악성 코드를 내포한 채 컴파일링 하도록 유도하는 방법이 있다고 한다.
이러한 공격법을 발견한 건 소프트웨어 공급망 보안 전문 업체 레짓시큐리티(Legit Security)다. 레짓 측은 12월 1일 발표한 보안 권고문을 통해 위에 언급한 공격 방법(아티팩트 포이즈닝 : artifact poisoning)을 언급하며 깃허브 액션즈(GitHub Actions)라는 기능을 활용한 소프트웨어 프로젝트들을 위협할 수 있다고 경고했다.
깃허브 액션즈는 개발의 일부 프로세스를 자동화로 처리해주는 서비스다. 소프트웨어 프로젝트를 구성하는 요소에서 변화가 탐지되면(그래서 그 구성 요소가 최신 버전으로 바뀌었다는 게 탐지되면) 자동으로 최신 버전을 가져다가 컴파일링 작업을 다시 할 수도 있다. 깃허브 액션즈를 이런 식으로 구성해 놓거나 이런 구성으로 관리되는 소프트웨어 프로젝트를 파악한다면 아티팩트 포이즈닝 기법으로 리포지터리와 연결된 수많은 소프트웨어들에 영향을 줄 수 있게 된다.
레짓 측 전문가들은 아티팩트 포이즈닝 공격을 러스트(Rust)를 관리하는 소프트웨어 프로젝트에 시뮬레이션 방식으로 시도해 보았고, 해당 프로젝트는 레짓시큐리티 연구원들이 공격 시뮬레이션을 위해 임의로 추가한 요소들을 걸러내지 않고 재컴파일링 했다.
이 공격이 인기 높은 리포지터리에서 제대로 발동된다면 수많은 소프트웨어들에 악영향을 줄 수 있다고 레짓 측은 경고했다. “오픈소스 프로젝트들의 유지 관리 책임자들 중 상당 수가 변경 신청이 들어왔을 때 코드 점검을 먼저하고 싶어하지 않습니다. 일단 먼저 테스트부터 시작하죠. 테스트를 하려면 컴파일을 해야 하고요. 그게 굉장히 흔한 패턴입니다.” 레짓의 CTO인 리아브 카스피(Liav Caspi)의 설명이다.
“간단히 말해 깃허브 액션즈를 활용하는 개발자들 혹은 리포지터리 관리자들의 워크플로우가 취약하다고 볼 수 있습니다. 이런 현장의 트렌드를 악용한다면 누구나 소프트웨어 구성 요소를 변질시킬 수 있고, 이를 통해 악성 소프트웨어를 대량으로 만들어낼 수 있게 되는 겁니다. 이것 역시 일종의 소프트웨어 공급망 취약점이라고 말할 수 있습니다.”
레짓은 워크플로우를 교차하는 여러 아티팩트들 간 확인 및 교신 절차가 깃허브에 마련되어 있지 않다는 것이 문제의 근원이라고 볼 수 있다고 지적하기도 했다. 깃허브 측은 레짓시큐리티의 이러한 문제 제기를 확인한 후 취약성을 인정했고, 레짓 측에 버그바운티 상금까지 수여했다. 시뮬레이션 공격에 활용된 러스트 관련 프로젝트 관리자들도 취약점을 패치했다.
“누군가 오픈소스에 기여(contribution)하겠다며 제출한 변경 코드를 자동화 스크립트로 확인한 후에 주 관리자가 점검하는 식의 작업 절차는 널리 퍼져 있습니다. 사람이 직접 한 줄 한 줄 확인하기 전에 자동화 기술로 기계가 먼저 훑는 것이죠. 자동화 기술을 사용하면 시간이 대단히 많이 절약되는 게 사실입니다. 하지만 그 때문에 확인되어야 할 것이 다 확인되지 않고 넘어가기도 하죠.”
오픈소스는 전 세계 수많은 개발자들의 ‘기여’가 가능하다는 특징을 가지고 있다. 이름도 얼굴도 모르고 친분도 없는 누군가가 내가 관리하는 오픈소스를 더 낫게 혹은 더 튼튼하게 만들어 세상을 이롭게 하고 싶다며 접근할 때, 지금처럼 자동화 점검 기술에만 기댄다는 건 그 자체로 꽤나 리스크가 큰 행동일 수밖에 없다. 그런데 실제 그런 식으로 오픈소스와 소프트웨어 프로젝트를 관리하니 지금과 같은 ‘아티팩트 포이즈닝’ 공격이 성립하는 것이다.
깃허브는 이 문제를 인지하고 외부 기여자 혹은 기여 희망자들이 제출한 코드가 깃허브 액션즈를 통해 자동으로 컴파일링 되지 않도록 기능을 일부 수정했다. 또한 GetArtifact와 ListArtifact라는 아티팩트 관련 API들도 수정해 특정 아티팩트의 신뢰도를 보다 꼼꼼하게 확인할 수 있도록 했다.
“생각해 보면 너무나 당연한 문제입니다. 외부인이 제공한 코드를 별 다른 의심없이 그대로 컴파일링 해서 내보낸다니, 위험 천만한 일일 수밖에 없죠. 다만 이러한 당연한 사실이, 깃허브 액션즈라는 서비스와 깃허브 생태계 내 개발자들의 보편적인 워크플로우와도 연결되는 것이라고 아무도 생각한 적이 없었던 것이죠. 지금도 어디에 너무나 명백하고 뻔한 공급망 위협 요소들이 숨어 있을지 아무도 모릅니다. 계속해서 찾아내야 할 것입니다.”
3줄 요약
1. 깃허브 생태계에서 색다른 공급망 취약점 발견됨.
2. 깃허브라는 플랫폼의 로직과 개발자들의 워크플로우가 결합하여 나타나는 취약점.
3. 다행히 깃허브 측에서 문제를 인지하고 패치함.
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 사이버 공격자가 깃허브에 개설된 오픈소스 리포지터리에 여러 변경 사항을 제출하면서 악성 요소를 슬쩍 주입하면 어떻게 될까? 대부분 유지 관리를 담당하는 사람이나 단체가 이를 걸러낸다. 하지만 그런 관리 시스템에 걸리지 않고, 공격자가 살짝 바꾼 오픈소스 리포지터리로 만들어진(혹은 그 리포지터리가 개발에 사용된) 소프트웨어 프로젝트들이 악성 코드를 내포한 채 컴파일링 하도록 유도하는 방법이 있다고 한다.
[이미지 = utoimage]
이러한 공격법을 발견한 건 소프트웨어 공급망 보안 전문 업체 레짓시큐리티(Legit Security)다. 레짓 측은 12월 1일 발표한 보안 권고문을 통해 위에 언급한 공격 방법(아티팩트 포이즈닝 : artifact poisoning)을 언급하며 깃허브 액션즈(GitHub Actions)라는 기능을 활용한 소프트웨어 프로젝트들을 위협할 수 있다고 경고했다.
깃허브 액션즈는 개발의 일부 프로세스를 자동화로 처리해주는 서비스다. 소프트웨어 프로젝트를 구성하는 요소에서 변화가 탐지되면(그래서 그 구성 요소가 최신 버전으로 바뀌었다는 게 탐지되면) 자동으로 최신 버전을 가져다가 컴파일링 작업을 다시 할 수도 있다. 깃허브 액션즈를 이런 식으로 구성해 놓거나 이런 구성으로 관리되는 소프트웨어 프로젝트를 파악한다면 아티팩트 포이즈닝 기법으로 리포지터리와 연결된 수많은 소프트웨어들에 영향을 줄 수 있게 된다.
레짓 측 전문가들은 아티팩트 포이즈닝 공격을 러스트(Rust)를 관리하는 소프트웨어 프로젝트에 시뮬레이션 방식으로 시도해 보았고, 해당 프로젝트는 레짓시큐리티 연구원들이 공격 시뮬레이션을 위해 임의로 추가한 요소들을 걸러내지 않고 재컴파일링 했다.
이 공격이 인기 높은 리포지터리에서 제대로 발동된다면 수많은 소프트웨어들에 악영향을 줄 수 있다고 레짓 측은 경고했다. “오픈소스 프로젝트들의 유지 관리 책임자들 중 상당 수가 변경 신청이 들어왔을 때 코드 점검을 먼저하고 싶어하지 않습니다. 일단 먼저 테스트부터 시작하죠. 테스트를 하려면 컴파일을 해야 하고요. 그게 굉장히 흔한 패턴입니다.” 레짓의 CTO인 리아브 카스피(Liav Caspi)의 설명이다.
“간단히 말해 깃허브 액션즈를 활용하는 개발자들 혹은 리포지터리 관리자들의 워크플로우가 취약하다고 볼 수 있습니다. 이런 현장의 트렌드를 악용한다면 누구나 소프트웨어 구성 요소를 변질시킬 수 있고, 이를 통해 악성 소프트웨어를 대량으로 만들어낼 수 있게 되는 겁니다. 이것 역시 일종의 소프트웨어 공급망 취약점이라고 말할 수 있습니다.”
레짓은 워크플로우를 교차하는 여러 아티팩트들 간 확인 및 교신 절차가 깃허브에 마련되어 있지 않다는 것이 문제의 근원이라고 볼 수 있다고 지적하기도 했다. 깃허브 측은 레짓시큐리티의 이러한 문제 제기를 확인한 후 취약성을 인정했고, 레짓 측에 버그바운티 상금까지 수여했다. 시뮬레이션 공격에 활용된 러스트 관련 프로젝트 관리자들도 취약점을 패치했다.
“누군가 오픈소스에 기여(contribution)하겠다며 제출한 변경 코드를 자동화 스크립트로 확인한 후에 주 관리자가 점검하는 식의 작업 절차는 널리 퍼져 있습니다. 사람이 직접 한 줄 한 줄 확인하기 전에 자동화 기술로 기계가 먼저 훑는 것이죠. 자동화 기술을 사용하면 시간이 대단히 많이 절약되는 게 사실입니다. 하지만 그 때문에 확인되어야 할 것이 다 확인되지 않고 넘어가기도 하죠.”
오픈소스는 전 세계 수많은 개발자들의 ‘기여’가 가능하다는 특징을 가지고 있다. 이름도 얼굴도 모르고 친분도 없는 누군가가 내가 관리하는 오픈소스를 더 낫게 혹은 더 튼튼하게 만들어 세상을 이롭게 하고 싶다며 접근할 때, 지금처럼 자동화 점검 기술에만 기댄다는 건 그 자체로 꽤나 리스크가 큰 행동일 수밖에 없다. 그런데 실제 그런 식으로 오픈소스와 소프트웨어 프로젝트를 관리하니 지금과 같은 ‘아티팩트 포이즈닝’ 공격이 성립하는 것이다.
깃허브는 이 문제를 인지하고 외부 기여자 혹은 기여 희망자들이 제출한 코드가 깃허브 액션즈를 통해 자동으로 컴파일링 되지 않도록 기능을 일부 수정했다. 또한 GetArtifact와 ListArtifact라는 아티팩트 관련 API들도 수정해 특정 아티팩트의 신뢰도를 보다 꼼꼼하게 확인할 수 있도록 했다.
“생각해 보면 너무나 당연한 문제입니다. 외부인이 제공한 코드를 별 다른 의심없이 그대로 컴파일링 해서 내보낸다니, 위험 천만한 일일 수밖에 없죠. 다만 이러한 당연한 사실이, 깃허브 액션즈라는 서비스와 깃허브 생태계 내 개발자들의 보편적인 워크플로우와도 연결되는 것이라고 아무도 생각한 적이 없었던 것이죠. 지금도 어디에 너무나 명백하고 뻔한 공급망 위협 요소들이 숨어 있을지 아무도 모릅니다. 계속해서 찾아내야 할 것입니다.”
3줄 요약
1. 깃허브 생태계에서 색다른 공급망 취약점 발견됨.
2. 깃허브라는 플랫폼의 로직과 개발자들의 워크플로우가 결합하여 나타나는 취약점.
3. 다행히 깃허브 측에서 문제를 인지하고 패치함.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
.jpg)
.jpg)
