소프트웨어 공급망 공격이란?

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기]: https://www.itworld.co.kr/news/311911

최근 소프트웨어 공급망 사고가 여러 매체의 헤드라인을 장식하고 있다. 파일럼(Phylum)의 ‘2023년 3분기 소프트웨어 공급망 보안 진화 보고서(Q3 2023 Evolution of Software Supply Chain Security Report)’에 따르면, 대부분 카테고리에서 의심스러운 패키지가 증가했다. 파일럼이 검사한 300만 개의 패키지 중 1만 개 이상의 파일이 알려진 악성 URL을 참조했다. 8만 6,000개에 가까운 패키지는 미리 컴파일된 바이너리를 포함하고 있어 맬웨어를 검사하기 어려웠다. 5,500개는 코드 난독화를 시도했으며, 5,000개는 일회용 이메일 계정으로 등록된 것이었다.

파일럼의 보고서를 보면 더 많은 맬웨어 제작자가 광범위한 접근 방식이 아닌 특정 기업을 표적으로 삼는 전술을 채택하고 있음을 알 수 있다. 특정 그룹이나 기업을 표적으로 삼은 악성 패키지는 2023년 2분기보다 47.4% 증가한 1,000개에 육박했다. 이런 표적 공격의 목표는 인증정보 탈취, 소스 코드 또는 지식 재산 도용이 포함된다. 하지만 많은 개발자가 소프트웨어 공급망 안전을 위한 베스트 프랙티스를 따르지 않는 것으로 보인다. 파일럼에 따르면, 개발자는 매주 자바스크립트 패키지 레지스트리 npm에서 약 240억 개의 패키지를 다운로드하지만, 다운로드한 코드의 무결성을 검증하는 개발자는 거의 없다. 파일럼은 공격자가 이런 사실을 알고 있기 때문에 향후 대규모 랜섬웨어 공격이나 봇넷과 같은 더 광범위한 캠페인을 시작할 수 있다고 지적했다.

ⓒ Getty Images Bank

‘소프트웨어 공급망 공격’은 공격자가 소프트웨어 개발 프로세스(개발 수명 주기)를 방해하거나 탈취해 완성된 제품/서비스를 사용하는 소비자에게 해로운 영향을 미치는 모든 경우를 포괄한다. 같은 이름으로 분류되더라도 모든 공격이 동일한 방식으로 발생하는 것은 아니다. 소프트웨어 빌드에 사용되는 코드 라이브러리 또는 개별 구성요소가 오염되거나, 소프트웨어 업데이트 바이너리가 트로이 목마에 감염되거나, 코드 서명 인증서가 도난당하거나, SaaS를 호스팅하는 서버가 손상되는 경우가 대표적이다.

모든 소프트웨어 공급망 공격에서 공격자는 업스트림 또는 미드스트림에 개입해 악의적인 활동의 파급 효과가 있는 다운스트림을 수많은 사용자에게 전달한다. 따라서 성공적인 공급망 공격은 고립된 보안 침해보다 훨씬 더 큰 규모로 광범위한 영향을 미친다. 의심스러운 패키지를 모니터링하고 제거하려는 노력에도 불구하고 모든 코드 저장소나 라이브러리에는 악성 코드가 포함될 수 있다. 깃허브 같은 리포지토리는 맬웨어를 사이트에서 차단하기 위해 적극적인 조치를 취하고 있지만, 공격자는 의심하지 않는 개발자에게 자신의 코드를 성공적으로 배포할 수 있는 방법을 찾고 있다.

소프트웨어 공급망 공격 사례

지난 몇 년 간의 사례를 통해 대표적인 소프트웨어 공급망 공격 유형을 살펴본다.

업스트림 서버 침해: 코드코프 공격

소프트웨어 공급망 공격 대부분은 공격자가 업스트림 서버 또는 코드 리포지토리에 침입해 악성 페이로드(예: 악성 코드, 트로이 목마에 감염된 업데이트)를 삽입하는 방식으로 이루어진다. 그런 다음 해당 페이로드가 다운스트림된다. 하지만 기술적인 관점에서 볼 때 항상 이런 방식으로 진행되는 것은 아니다.

코드코브(Codecov) 공급망 공격이 대표적인 사례다. 이 사건은 솔라윈즈 침해 사고와 비교되기도 했지만, 두 공격 사이에는 뚜렷한 차이가 있다. 솔라윈즈 공급망 침해는 정교한 위협 행위자의 소행으로, 행위자들은 솔라윈즈 IT 성능 모니터링 제품 오리온(Orion)의 합법적인 업데이트 바이너리인 SolarWinds.Orion.Core.BusinessLayer.dll을 변조했다. 파이어아이가 분석한 바와 같이, 위조 DLL의 RefreshInternal() 메서드에 포함된 악성 코드는 아래와 같다. 이 메서드는 오리온이 인벤토리 매니저 플러그인을 로드할 때 HTTP 기반 백도어를 호출한다.

악의적인 RefreshInternal() 메서드가 포함된 백도어 DLL 버전 2019.4.5200.9083 ⓒ Foundry

솔라윈즈 업스트림 공격은 변조된 바이너리가 미국 정부기관을 포함한 1만 8,000개 이상의 오리온 고객에게 다운스트림으로 전달된 후에야 본격적으로 시작됐다. 코드코브의 경우 악성 코드가 다운스트림으로 유포되지 않아도 공격의 파급 효과가 있었다. 코드코브 공격자들은 공식 보안 권고에 따라 결함이 있는 도커 이미지 생성 프로세스를 통해 코드코브 배시(bash) 업로더를 수정하는 데 사용되는 자격 증명을 획득했다. 그런 다음, 고객의 CI/CD 환경에서 업로드되는 환경 변수를 수집하기 위해 코드코브 서버 자체에 호스팅된 코드코브 배시 업로더를 수정했다.

환경 변수를 수집하고 이를 공격자 IP 주소로 전송하는 코드코브의 배시 업로더의 수정된 라인 ⓒ Foundry

코드코브 배시 업로더 스크립트는 코드코브 서버 자체의 codecov[.]io/bash에 존재했지만, 수천 개의 리포지토리가 이미 이 링크를 참조해 CI/CD 환경에서 수정된 배시 업로더로 정보를 업스트림하고 있었다. 따라서 악성 코드는 손상된 업스트림 서버에만 존재하고 있었고 코드의 다운스트림 배포는 발생하지 않았는데, 그 이유는 소위 다운스트림 리포지토리가 이미 배시 업로더 스크립트를 호스팅하는 코드코브 서버를 가리키고 있었기 때문이다. 그렇지만 이런 다운스트림 리포지토리는 코드코브의 배시 업로더에 데이터를 업로드하도록 구성되었으므로 공격의 영향을 받을 수밖에 없었다.

코드코브 공격자들은 해킹된 배시 업로더에서 수집한 자격 증명을 사용해 수백 개의 고객 네트워크를 침해한 것으로 알려졌다. 얼마 지나지 않아 해시코프는 코드코브 사건으로 인해 소프트웨어 패키지 서명 및 확인에 사용되는 GPG(GNU Privacy Guard) 개인 키가 노출됐다고 밝혔다. 트윌리오와 다른 회사에서도 이 공격의 영향을 일부 공개했다.

악성 업데이트 배포를 위한 미드스트림 침해

‘미드스트림’이라는 용어는 공격자가 원래의 업스트림 소스 코드 기반이 아닌 중개 소프트웨어 업그레이드 기능 또는 CI/CD 도구를 손상시키는 사례를 지칭하기 위해 느슨하게 적용되고 있다. 2021년 4월, 기업용 비밀번호 관리 프로그램인 패스워드스테이트(Passwordstate)를 개발한 클릭 스튜디오(Click Studios)가 공급망 공격 소식을 공지했다. 공격자들은 패스워드스테이트의 ‘인플레이스 업그레이드(In-Place Upgrade)’ 기능을 손상시켜 사용자에게 악성 업데이트를 배포했다. 이 불법 업데이트에는 Moserware.SecretSplitter.dll이라는 변경된 DLL 파일이 포함돼 있었다.

클릭 스튜디오는 공지에서 “침해는 종료 전 약 28시간 동안 존재했다. 명시된 시간 사이에 인플레이스 업그레이드를 수행한 고객만 영향을 받은 것으로 생각된다. 패스워드스테이트의 수동 업그레이드는 손상되지 않았다. 영향을 받은 고객의 비밀번호 기록이 수집되었을 수 있다”라고 밝혔다. 클릭 스튜디오 사용자를 대상으로 한 피싱 공격이 이어지는 것은 자연스러운 일이었다.

패스워드스테이트 공급망 공격에는 소셜 엔지니어링 측면도 있었다. 300MB가 넘는 크기의 가짜 업데이트 zip 파일에서 공격자가 사용자 설명서, 도움말 파일, 파워셸 빌드 스크립트가 악성 CDN(Contents Distribution Network) 서버를 가리키도록 변경한 흔적을 발견했다. 사람, 특히 초보 개발자나 소프트웨어 소비자가 CDN에 대한 링크의 신뢰성을 항상 확인하지 않는다는 것을 증명한다. 소프트웨어 애플리케이션과 웹사이트에서는 업데이트, 스크립트 및 기타 콘텐츠를 전송하기 위해 CDN을 합법적으로 사용하기 때문이다.

악성 CDN 서버를 공식 서버로 명시한 도움말 문서 예시 ⓒ Foundry

악성 CDN 서버 링크가 포함된 파워셸 설치 스크립트 ⓒ Foundry

메이지카트(Magecart)와 같은 온라인 신용카드 스키밍 공격은 이런 공급망 공격의 또 다른 예다. 일부 공격에서는 아마존 클라우드프론트(CloudFront) CDN 버킷이 손상돼 해당 CDN에 의존하는 더 많은 웹사이트에 악성 자바스크립트 코드가 유포되기도 했다.

의존성 혼동 공격

의존성 혼동을 언급하지 않고서는 공급망 공격의 어떤 부분도 다룰 수 없다. 의존성 혼동 공격은 다수의 오픈소스 생태계에서 발견되는 고유한 설계 약점으로 인해 최소한의 노력으로 자동화된 방식으로 작동한다. 즉, 의존성 혼동 또는 네임스페이스(namespace) 혼동은 소프트웨어 빌드가 오픈소스 리포지토리에 존재하지 않는 내부적으로 생성된 비공개 의존성을 사용하는 경우 발생할 수 있다. 공격자는 공개 리포지토리에 동일한 이름의 의존성을 더 높은 버전으로 등록할 수 있다. 이렇게 되면 내부 의존성이 아닌 더 높은 버전 번호를 가진 공격자의 공개된 의존성을 소프트웨어 빌드로 가져올 가능성이 높다.

윤리적 해커 알렉스 버산은 PyPI, npm, 루비젬스 등 일반적으로 사용되는 생태계 전반에서 이런 간단한 취약점을 악용해 대기업 35곳을 해킹하고 13만 달러가 넘는 버그 바운티 현상금을 받았다. 버산의 연구가 공개된 뒤 수천 개의 의존성 혼동 모방 패키지가 PyPI, npm 및 기타 생태계에 넘쳐나기 시작했다. 이런 모방 패키지 대부분은 버그 현상금 사냥꾼이 만든 것이지만, 일부는 악의적인 방식으로 유명 업체를 표적으로 삼았다.

의존성 혼동은 공격자보다 먼저 모든 비공개 의존성의 이름을 공개 리포지토리에 등록(예약)하고, 충돌하는 의존성 이름이 공급망에 유입되는 것을 방지하는 SDLC(Software Development Lifecycle) 방화벽과 같은 자동화된 솔루션을 사용하는 등 여러 가지 방법으로 해결할 수 있다. 오픈소스 리포지토리 소유자는 보다 엄격한 인증 프로세스를 채택하고 실행 중인 네임스페이스/범위를 적용할 수 있다. 예를 들어, ‘CSO’ 네임스페이스 또는 범위로 패키지를 게시하려면 오픈소스 리포지토리는 패키지를 업로드하는 개발자가 ‘CSO’라는 이름으로 패키지를 업로드할 권한이 있는지 확인하는 것이다. 예를 들어, 자바 컴포넌트 리포지토리인 메이븐 센트럴(Maven Central)은 네임스페이스 소유권을 확인하기 위해 간단한 도메인 기반 인증을 사용한다. 이는 다른 생태계에서도 쉽게 모델링할 수 있는 방식이다. 마찬가지로 고 패키지 리포지토리에 게시된 패키지는 해당 깃허브 리포지토리의 URL을 따서 이름이 지정되므로 의존성 혼동 공격이 완전히 불가능하지는 않더라도 훨씬 더 어려워진다.

도난당한 SSL 및 코드 서명 인증서

HTTPS 웹사이트가 증가함에 따라 SSL/TLS 인증서는 이제 어디에서나 온라인 통신을 보호한다. 따라서 SSL 인증서의 개인 키가 손상되면 엔드투엔드 암호화의 안전한 통신 보증이 위협받을 수 있다.

2021년 1월, 마임캐스트(Mimecast)는 고객이 마이크로소프트 365 익스체인지 서비스 연결 설정에 사용하는 인증서가 손상돼 사용자의 약 10%의 통신에 영향을 미칠 수 있다고 전했다. 마임캐스트는 해당 인증서가 SSL 인증서인지 명시적으로 밝히지 않았지만, 많은 연구자가 SSL 인증서일 것으로 보고 있다. 손상된 SSL 인증서도 문제지만 도난당한 코드 서명 인증서, 즉 손상된 개인 키는 소프트웨어 보안에 훨씬 더 광범위한 결과를 초래할 수 있다. 개인 코드 서명 키를 손에 넣은 공격자는 합법적인 정품 소프트웨어 프로그램에 맬웨어에 대한 서명을 할 수 있다(서명이 있는 경우 제로데이로 간주되지 않는다).

맬웨어 스턱스넷(Stuxnet)은 공격자가 훔친 개인 키를 사용해 악성 코드에 ‘신뢰할 수 있는’ 서명을 한 정교한 공격 사례다. 하지만 이런 공격은 스턱스넷 이전부터 지금까지 계속 존재한다. 앞서 언급한 코드코프 공급망 공격에서 해시코프의 GPG 개인 키가 노출된 사례가 문제가 되는 이유도 바로 이 때문이다. 공격자가 해시코프의 손상된 키를 악용하여 맬웨어에 서명했다는 증거는 없지만, 손상된 키가 취소되기 전까지는 이런 사고가 일어날 수 있는 가능성이 있었다.

개발자의 CI/CD 인프라 타겟팅

소프트웨어 공급망 관리 업체 소나타입(Sonatype)은 사용자의 깃허브 프로젝트에 악성 풀 리퀘스트를 도입하는 것뿐 아니라 암호화폐 채굴을 위해 깃허브의 CI/CD 자동화 인프라인 깃허브 액션(GitHub Action)을 악용한 다각적인 소프트웨어 공급망 공격을 관찰했다. 깃허브 액션은 개발자가 깃허브에서 호스팅 되는 리포지토리에 대해 자동화된 CI/CD 작업을 예약하는 방법을 제공한다. 이 공격은 공격자가 깃허브 액션을 사용하는 합법적인 깃허브 리포지토리를 복제하고 리포지토리의 깃허브 액션 스크립트를 약간 변경한 다음 프로젝트 소유자에게 이 변경 사항을 원래 리포지토리에 다시 병합하도록 풀 리퀘스트를 제출하는 방식으로 이루어졌다.

합법적인 프로젝트 소유자에게 변경된 코드를 병합하도록 풀 리퀘스트를 제출하는 공격자 'edgarfox1982' ⓒ Foundry

프로젝트 소유자가 변경된 풀 리퀘스트를 아무렇지 않게 승인하면 공급망 공격이 성공한 것이지만, 여기서는 그런 전제 조건조차 없었다. 악성 풀 리퀘스트에는 공격자가 풀 리퀘스트를 제출하자마자 깃허브 액션에 의해 자동으로 실행되도록 수정된 ci.yml이 포함돼 있었다. 수정된 코드는 기본적으로 암호화폐 채굴을 위해 깃허브 서버를 악용한다. 이런 공격은 일석이조 효과를 가져온다. 개발자를 속여 악성 풀 리퀘스트를 수락하도록 유도하며, 실패할 때는 자동화된 CI/CD 인프라를 악용해 악의적인 활동을 수행한다.

UN 도메인에 침입해 10만 명 이상의 UNEP(UN Environment Programme) 직원 기록에 액세스한 연구자들도 이런 도메인에서 노출된 깃 폴더와 ‘git-credentials’ 파일을 발견했기 때문에 액세스에 성공했다. 깃 인증서에 대한 액세스 권한을 얻은 위협 행위자는 비공개 깃 리포지토리를 복제할 수 있을 뿐 아니라 업스트림에 악성 코드를 주입해 훨씬 더 심각한 결과를 초래하는 공급망 공격을 유발할 수도 있다. 지금까지 공급망 공격 방어자는 주로 개발자에게 안전한 코딩에 대한 베스트 프랙티스를 권장하거나 개발 환경에서 데브섹옵스 자동화 도구를 사용하는 데 중점을 뒀다. 하지만 이제는 CI/CD 파이프라인(예: 젠킨스 서버), 클라우드 네이티브 컨테이너, 보조 개발자 도구 및 인프라를 보호하는 것 또한 그에 못지않게 중요해졌다.

소셜 엔지니어링을 통한 악성 코드 유포

보안 전문가라면 누구나 알고 있듯이 보안 시스템은 ‘가장 약한 고리만큼만’ 강하다. 인적 요소는 여전히 보안의 가장 약한 고리이기 때문에 공격의 시작은 예상치 못한 곳에서 발생할 수 있다. 2021년 4월 리눅스 재단은 ‘버그가 있는 패치’를 의도적으로 제안해 결과적으로 리눅스 커널 소스코드에 취약성을 유발한 미네소타 대학교 연구원이 앞으로 프로젝트에 기여하는 것을 금지했다. 이 사례에서 알 수 있는 몇 가지 사실이 있다. 개발자는 분산되어 있으며, 버그가 있거나 악의적인 코드 커밋, 제안된 코드 변경을 모두 충분히 검토할 만한 여유가 없을 수 있다. 더 중요한 것은, 소셜 엔지니어링이 최소한의 의심도 받지 않는 출처, 즉 ‘.edu’ 이메일 주소를 가진 신뢰할 수 있는 대학 연구자들로부터 시작될 수 있다는 것이다.

깃허브 프로젝트에 기여하는 공동 작업자가 릴리즈 게시 후에도 이를 변경할 수 있다는 점을 악용한 사례도 있다. 여기서도 프로젝트 소유자는 대부분이 선의로 코드와 커밋을 제출한다고 신뢰할 것이다. 하지만 공급망 보안을 손상시키는 데는 단 한 명의 공동 작업자만 있으면 된다. 여기서 설명한 모든 실제 사례는 위협 행위자가 성공적인 공급망 공격에 사용하는 다양한 약점, 공격 벡터, 기법을 보여준다. 이런 공격은 계속 진화하고 도전 과제를 야기하므로 소프트웨어 보안에 접근할 때 보다 효과적인 솔루션과 전략이 필요하다.

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.