“깃허브 액션 사용한 소프트웨어에 공급망 보안 취약성 발생” 레짓 시큐리티

빌드 플랫폼 깃허브 액션(GitHub Actions)를 통해 아티팩트(Artifact)가 저장되는 과정에서 악성 코드가 주입되고 있다는 보고서가 나왔다. 사이버보안 연구진은 수천 개의 저장소에서 많이 사용되는 아티팩트 다운로드 스크립트가 해당 보안 문제에 취약한 것으로 확인했다. 
 

공급망 보안 솔루션 옵체 레짓 시큐리티(Legit Security) 연구진은 자체 보고서를 통해 “우리는 서로 다른 워크플로 사이에 아티팩트를 전송할 때 심각한 아티팩트 중독(Poisoning) 공격 위험이 있음을 알게 되었다. 아티팩트 중독이란 공격자가 정상 아티팩트의 내용물을 수정된 악성 아티팩트로 교체함으로써 공급망 공격을 개시하는 수법이다”라고 밝혔다.

다른 워크플로에서 생성되는 아티팩트를 다운로드하여 사용하는 취약한 프로젝트의 CI/CD 파이프라인을 공격하는 방법은 간단한다. 해당 워크플로가 포함된 저장소를 포크(fork)하여 불량 아티팩트를 생성하도록 로컬 복사본으로 수정한 후 다시 원래의 저장소로 끌어오기 요청을 만들되 해당 요청이 수락될 필요가 없게 하면 된다.
 

아티팩트 스토리지 API의 논리적 결함

깃허브 액션은 소프트웨어 코드의 구축 및 테스트를 자동화하기 위한 CI/CD 플랫폼이다. 깃허브로 소스 코드 저장소를 호스팅하고 관리하는 프로젝트에서 깃허브 액션이 많이 사용되고 있다. 깃허브 액션 워크플로는 새로운 코드가 저장소에 커밋 되는 경우와 같이 특정 트리거 또는 이벤트가 발생할 때 실행되는 YAML 구문을 사용하여 .yml 파일에 정의되는 자동화된 프로세스다. 

빌드 아티팩트는 워크플로 및 개별 작업의 실행 결과로 생기는 컴파일 된 2진수, 로그 및 기타 파일이다. 이런 아티팩트는 스토리지 버킷 내부에 저장된다. 이때 실행되는 각 워크플로에는 파일을 업로드해 두었다가 나중에 다운로드할 수 있는 특정 버킷이 지정된다.

깃허브에서 제공되는 아티팩트 다운로드용 참조 ‘액션’ (스크립트)는 교차 워크플로 아티팩트 다운로드를 지원하지 않는다. 그러나, 다른 워크플로에 의해 생성되는 아티팩트를 후속 빌드 단계의 입력값으로 재사용하는 것은 소프트웨어 프로젝트에서 흔한 용례다. 이런 이유로 개발자들은 특정 워크플로 파일, 특정 사용자, 특정 브랜치 등등에서 생성된 아티팩트와 같이 보다 복잡한 필터링을 이용해 아티팩트를 다운로드하기 위해 깃허브 액션 API에 의존하는 자신만의 커스텀 스크립트를 만들었다.

레짓 시큐리티에서 발견한 문제는 다음과 같다. 해당 API는 포크 된 저장소에서 업로드한 아티팩트와 기본 저장소에서 업로드한 아티팩트를 구분하지 않는다. 따라서, 만일 다운로드 스크립트가 특정 저장소의 특정 워크플로 파일에서 생성된 아티팩트를 필터링한다면, API는 해당 파일이 생성한 최신 버전을 제공하게 되지만, 이는 저장소의 포크 된 버전의 끌어오기 요청 동작을 통해 자동으로 생성된 악성 버전일 수 있다.

연구진은 “간단히 말해, 취약한 워크플로에서는 어떤 깃허브 사용자도 아티팩트를 구축하는 포크를 만든 다음 이 아티팩트를 원래 저장소 빌드 프로세스에 주입하여 그 출력물을 수정할 수 있다. 이는 빌드 출력물이 공격자에 의해 수정되는 또 다른 형태의 소프트웨어 공급망 공격이다”라고 설명했다.

연구진은 아티팩트 다운로드 용도로 커뮤니티에서 개발한 4개의 커스텀 동작이 모두 취약한 것을 확인했다. 그중 하나는 12,000개가 넘는 저장소에 의존성으로 등록되어 있었다.
 

러스트 언어의 오픈소스 저장소도 침투

그러한 커스텀 스크립트를 워크플로에 사용한 저장소 중에는 러스트(Rust) 프로그래밍 공식 레포지토리도 있었다. ci.yml라는 취약한 워크플로가 저장소 코드의 구축 및 테스트를 담당했고, 써드파티 저장소의 워크플로에 의해 생성된 libgccjit.so라는 아티팩트(리눅스(Linux) 라이브러리 파일)를 다운로드하기 위해 커스컴 동작을 사용했다.

공격자들은 써드파티 저장소를 포크한 후 해당 저장소의 워크플로를 수정해 라이브러리의 악성 버전을 생성한 후 원래 저장소에 아티팩트를 생성하라는 끌어오기 요청을 내리기만 하면 되었다. 러스트의 워크플로가 라이브러리의 중독된 버전에 끌어오기 되었다면 공격자는 해당 워크플로의 권한으로 러스트 저장소 내에 악성 코드를 실행할 수 있었을 것이다. 연구진은 “악용 직후 공격자는 저장소 브랜치, 끌어오기 요청, 이슈, 릴리스, 기타 워크플로 토큰 권한에 이용 가능한 엔티티를 수정할 수 있다”고 밝혔다.

깃허브 측은 레짓 시큐리티의 보고 이후, API에 더 많은 필터링 기능을 추가했다. 개발자들이 이 기능을 활용하면 특정 워크플로 실행 인스턴스에 의해 생성된 아티팩트를 좀 더 잘 식별할 수 있다(워크플로 실행 id). 그러나, 이런 변화를 기존 구현판에 강요하면 워크플로 중단이 불가피하다. 따라서, 보호받기 위해 더욱 엄격한 필터링으로 워크플로를 업데이트하는 것은 사용자들에게 달려 있다.

또다른 완화 수단은 다운로드 된 아티팩트를 이를 생성한 커밋의 해시 값으로 필터링하는 것이다. 아니면 끌어오기 요청으로 생성된 아티팩트를 exclude_pull_requests 옵션을 사용하여 완전히 배제하는 것이다. 레짓 시큐리티 측은 또한 발견된 취약한 커스텀 아티팩트 다운로드 스크립트의 작성자들에게 연락을 취했다.

레짓 시큐리티 CTO 리아브 카스피는 CSO와의 인터뷰에서 “공급망 보안의 주안점은 사람들의 악성 코드 기여를 방지하는 것이었다. 따라서, 저장소에 변경 사항을 실행하고 끌어오기 요청을 생성하거나 변경 요청을 실행할 때마다 깃허브는 많은 내장 검증 통제장치를 갖추고 있다. 누군가가 사용자의 코드를 승인하고 병합해야 하므로 관계자가 존재한다. 우리가 찾으려고 노력해 온 것은 누구나 검토 없이 영향을 미칠 수 있는 논리 문제를 악용하는 수법인데 나는 이것이 그런 수법 가운데 하나라고 생각한다. 누군가가 이것에 대해 알고 있었다면 아무런 승인을 받지 않고도 아티팩트를 주입할 수 있었을 것이다”라고 말했다.

카스피는 이어 일반적으로 CI 파이프라인은 코드를 직접 검토하기에 앞서 테스트하기 위해 끌어오기 요청에 대해 자동으로 실행되는 워크플로를 갖추고 있으며 끌어오기 요청에 구축이 필요한 아티팩트가 포함되어 있다면 워크플로는 그 아티팩트를 구축한다고 설명했다. 수준 높은 공격자는 아티팩트를 구축할 수 있는 끌어오기 요청을 생성한 후 제출을 닫아 요청을 삭제할 수 있으며, 오늘날 소스 코드 저장소에 존재하는 모든 활동 소음을 감안할 때 이는 눈에 띄지 않은 채 지나갈 가능성이 높다고 덧붙였다. 
editor@itworld.co.kr