"사례로 본" 보편적인 공급망 공격 유형 6가지

요즈음 소프트웨어 공급망 사건이 보안 세계를 떠들석하게 만들고 있다. 이 보안 사건들은 서로 유사하기는 하지만 공급망 공격(Supply Chain Attack) 유형이 모두 동일한 것은 아니다.
 

 
공급망 공격은 공격자가 소프트웨어 제작 공정(소프트웨어 개발 수명주기)에 간섭하거나 이를 하이재킹해 결과적으로 최종 제품 또는 서비스의 다수의 소비자에게 해로운 영향을 주는 사례를 모두 아우른다. 

이는 소프트웨어 구축에 쓰인 코드 라이브러리나 개별 컴포넌트가 손상됐을 때, 소프트웨어 업데이트 코드가 트로이목마에 감염됐을 때, 코드 서명 인증서가 도난 당했을 때, 또는 심지어 서비스 소프트웨어(SaaS)를 호스팅하는 서버가 훼손된 경우도 공급망 공격에 속한다. 

소프트웨어 공급망 공격에 의해 공격자는 업스트림 또는 미드스트림 공정에 개입해 다운스트림의 다수의 사용자에게 악의적인 활동을 펼치고 영향을 준다. 따라서, 개별적인 보안 침해와 비교할 때 성공적인 공급망 공격은 훨씬 더 큰 파급 효과를 갖는다. 

이번 기사에서는 최근 실제적이고 성공적이었던 소프트웨어 공급망 공격의 6가지 기법을 조사한다. 

1. 업스트림 서버 훼손: 코드코브 공급망 공격(Codecov supply chain attack) 
대다수의 소프트웨어 공급망 공격에서 공격자는 업스트림 서버 또는 코드 리포지터리에 침투해 악성 페이로드를 주입한다(예를 들어, 악성코드 라인이나 트로이목마에 감염된 업데이트). 그 후 페이로드는 다운스트림의 여러 사용자에게 배포된다. 그러나 기술적 관점에서 볼 때 항상 이런 식은 아니다. 

코드코브 공급망 공격은 업스트림 서버 훼손 사례 가운데 하나다. 이 사건은 솔라윈즈(SolarWinds) 침해와 유사하지만 두 공격 사이에는 극명한 차이가 있다. 솔라윈즈 공급망 침해는 정당한 업데이트 코드인 ‘SolarWinds.Orion.Core.BusinessLayer.dll’을 변경했던 정교한 위협 행위자의 소행이었다. 이는 솔라윈즈 IT 성능 모니터링 제품인 오리온(Orion)의 일부였다. 

과거 파이어아이(FireEye)가 분석한 것처럼, 이 허위 DLL ‘RefreshInernal()’ 기법에 포함된 악성코드는 다음과 같다. 이 기법은 오리온이 인벤토리 매니저(Inventory Manager) 플러그인을 로드할 때 HTTP 기반의 백도어를 호출한다. 



솔라윈즈 업스트림 공격은 미국 정부기관을 포함해 1만 8,000 곳이 넘는 솔라윈즈 오리온 고객에게 변경 코드가 도달할 때에만 최대의 위력을 발휘했다. 그러나 코드코브 사례에서는 악성코드가 다운스트림으로 배포되지 않았다. 대신 공격의 사후 파급 효과가 있었다. 

코드코브의 공식 보안 발표에 따르면, 코드코브 공격자는 결함있는 도커 이미지 생성 프로세스로부터 인증 정보를 획득했고, 이는 코드코브 배시 업로더(Codecov Bash Uploader)를 변경하는 데 쓰일 수 있다. 이 후 공격자는 코드코브 서버가 호스팅하는 코드코브 배시 업로더를 변경해 고객의 CI/CD(Continuous Integration/Continuous Delivery) 환경으로부터 업로드 되는 환경 변수들을 수집했다.


 
코드코브 배시 업로더 스크립트는 코드코브 서버의 ‘codecov[.]io/bash’에 상주했지만, 수천 곳의 리포지터리가 CI/CD 환경으로부터 배시 업로더로 정보를 상향으로 전송하기 위해 이미 해당 링크를 가리키고 있었다. 

따라서 악성코드는 (훼손된) 업스트림 서버에만 잔류할 뿐이었고, 코드의 하향 배포는 전혀 일어나지 않았다. 그러나 이 다운스트림 리포지터리는 공격에 영향을 받았다. 이들의 데이터를 코드코브의 배시 업로더에 업로드하도록 설정되어 있었기 때문이다. 



실제로, 코드코브 공격자는 해킹된 배시 업로더로부터 수집한 인증정보를 이용해 수백 곳의 고객 네트워크를 침해했다. 얼마 지나지 않아, 하시코프(HashiCorp)는 코드코브 사건이 소프트웨어 패키지를 서명하고 검증하는 자사의 GPG(GNU Privacy Guard) 비밀 키의 노출로 이어졌음을 공표했다. 또한 트윌리오(Twilio) 역시 이 공격에 따른 영향을 밝혔으며, 이어 다른 기업들도 유사한 발표를 했다. 
 
2. 미드스트림 훼손에 의한 악성 업데이트 
‘미드스트림(midstream)’은 원래의 업스트림 소스코드 베이스가 아니라 중간의 소프트웨어 업그레이드 기능이나 CI/CD 도구를 훼손하는 사례를 느슨하게 지칭하는 용어이다. 

지난 달, 다수의 포춘500 기업이 사용하는 기업용 비밀번호 관리자인 패스워드스테이트(Passwordstate)의 제작자인 클릭 스튜디오(Click Studios)는 고객들에게 공급망 공격을 통지했다. 공격자는 패스워드스테이트의 ‘인-플레이스 업그레이드 기능(In-Place Upgrade functionality)’을 훼손해 악성 업데이트를 패스워드스테이스 사용자에게 배포했다. 

이 허위 업데이트는 ‘Moserware.SecretSplitter.dll’이라는 변경된 DLL 파일을 포함했고, 부분적 사례는 다음과 같다.


 
클릭 스튜디오는 다음과 같이 밝혔다. 
"침해 상황은 폐쇄되기까지 약 28시간 동안 존재했다. 앞서 명시한 시간 사이에 현재 위치 업그레이드를 수행한 고객만 영향을 받는 것으로 간주된다. 패스워드스테이트의 수동 업그레이드는 손상되지 않았다. 영향을 받은 고객의 비밀번호 기록이 수집됐을 수 있다."

당연한 말이지만, 클릭 스튜디오 사용자에 대한 피싱 공격에 이어 공격자들은 업데이트된 악성코드 버전에 대한 링크를 이메일 내에 배치했다.

이 공급망 공격은 업그레이드 프로세스 변경과 같은 기술적 공격뿐만 아니라 소셜 엔지니어링 공격까지 가미했다. 300MB가 넘는 허위 업데이트 압축 파일에서, 필자는 공격자가 사용자 매뉴얼, 도움말 파일, 파워셸 빌드 스크립트를 변경해 악성 CDN(Content Distribution Network) 서버를 가리키도록 했음을 발견했다.



 
소셜 엔지니어링 공격은 또 다른 약점을 보여준다. 다시 말해 인간, 특히 초급 개발자 또는 소프트웨어 사용자는 CDN의 악성 여부가 관계없이 CDN의 링크를 의심하지 않는다는 점이다. 이는 CDN이 소프트웨어 애플리케이션 및 웹사이트에 의해 정당하게 사용되어 업데이트, 스크립트, 여타 콘텐츠를 배포하기 때문이다.
 
메이지카드(Magecard) 등 온라인 신용카드 스키밍 공격은 이런 공급망 공격의 또 다른 사례다. 일부 공격에서 아마존 클라우드프런트 CDN(Amazon CloudFront CDN) 버킷이 훼손되어 이 CDN에 의존하는 수많은 웹사이트에 악성 자바스크립트 코드가 유포됐다. 

3. 의존성 혼동 공격(Dependency confusion attacks) 
2021년의 공급망 공격은 어느 것도 의존성 혼동(Dependency confusion)을 언급하지 않을 수 없다. 의존성 혼동 공격의 단순하면서도 자동화된 성질 때문이다. 의존성 혼동 공격은 공격자 측의 최소의 노력으로 가능하고 자동화된 형식으로 이뤄진다. 이는 여러 오픈소스 생태계에서 발견되는 내재적인 설계 약점을 악용한다. 

간단히 설명하자면, 의존성 혼동은 소프트웨어 빌드가 공개 오픈소스 리포지터리에 존재하지 않는 사적이고 내부적으로 생성된 의존성을 이용할 때 작용한다. 공격자는 공개 리포지터리 상에서 동일한 이름으로 의존성을 등록할 수 있다. 다만 버전 번호만 더 높다. 그 후, 사용자의 내부 의존성이 아니라 공격자의 공개 의존성이 더 높은 버전 번호로 인해 사용자의 소프트웨어 빌드로 유입될 가능성이 매우 높다.



윤리적 해커인 알렉스 버산은 PyPI, npm, 루비젬스(RubyGems) 등 보편적으로 이용되는 생태계에서 이 단순한 약점을 악용함으로써 35곳의 IT 대기업을 해킹해 버그 현상금으로 13만 달러 이상을 받았다. 

버산의 연구가 발표된 후, 며칠 동안 수천 개의 의존성 혼동 모방 패키지가 PyPI, npm, 여타 생태계에 넘쳐나기 시작했다. 패키지의 대다수는 다른 버그바운티 헌터에 의해 제작됐지만, 악의적으로 잘 알려진 기업을 노리는 사례도 없지 않았다. 

의존성 혼동을 해결하는 방법은 여러 가지가 있다. 예를 들어 모든 프라이빗 의존성의 이름을 해커보다 먼저 공개 리포지터리에 등록하고 자동화 솔루션, 예를 들어 상충되는 의존성 이름이 공급망에 유입되는 것을 차단하는 SDLC(Software Development Lifecycle) 방화벽 등을 이용하는 것이다. 

오픈소스 리포지터리의 소유자는 좀 더 엄격한 인증 프로세스를 도입하고 네임스페이스(namespace)/스코프(scope)를 강제할 수 있다. 예를 들어 ‘CSO’라는 네임스페이스 또는 스코프 하에서 패키지를 포스팅한다고 했을 때, 오픈소스 리포지터리는 패키지를 업로드하는 개발자가 ‘CSO’라는 이름 하에서 그 같이 할 권한이 있는지 검증할 수 있다. 

자바 컴포넌트 리포지터리인 메이븐 센트럴(Maven Central)은 단순한 도메인 기반 검증을 적용해 네임스페이스 소유권을 검증한다. 이는 다른 생태계가 쉽게 따라서 할 수 있는 관행이다. 
 
이와 유사하게, 고(Go) 패키지 리포지터리로 발표되는 패키지는 이들의 깃허브 리포지터리 URL에 따라 이름이 지정된다. 이는 의존성 혼동 공격을 완전히 막지는 못하더라도 훨씬 더 어렵게 만든다. 

4. 도난 당한 SSL 및 코드 서명 인증서 
HTTPS 웹사이트가 증가함에 따라 SSL/TLS 인증서는 어디에나 존재하고 온라인 커뮤니케이션을 보호한다. 따라서 SSL 인증서의 비밀 키의 훼손은 최종 사용자로의 엔드 투 엔드 암호화 연결이 제공하는 안전한 커뮤니케이션과 확신을 위협할 수 있다. 

2021년 1월, 마임캐스트(Mimecast)는 마이크로소프트 365 익스체인지 서비스로의 연결을 확립하기 위해 고객이 사용하는 인증서가 훼손되었고, 약 10%의 마임캐스트 사용자의 커뮤니케이션이 영향을 받았을 가능성이 있다고 발표했다. 마임캐스트는 해당 인증서가 SSL 인증서인지 명시적으로 밝히지는 않았지만, 일부 연구자들이 의심하는 것처럼 이는 SSL 인증서인 것으로 보인다. 

훼손된 SSL 인증서도 문제이지만, 도난 당한 코드 서명 인증서(code-signing certificate), 즉 훼손된 비밀 코드 서명 키는 소프트웨어 보안에 훨씬 광범위한 영향을 초래할 수 있다. 공격자가 비밀 코드 서명 키를 확보하면 유명 업체가 출하하는 진정한 소프트웨어 프로그램이나 업데이트로서 자신의 악성코드에 서명할 가능성이 있기 때문이다. 

스턱스넷(Stuxnet)이 이 정교한 공격의 대표적 사례다. 여기서 공격자는 두 유명한 기업으로부터 절취한 비밀 키를 이용해 자신의 악성코드를 ‘신뢰성 있음’으로 서명했다. 그러나 이 공격은 스턱스넷 이전에도 번성했었고 이후에도 계속 출현하고 있다. 

또한 이는 코드코브 공급망 공격에서 하시코프의 GPG 비밀 키 노출이 문제인 이유이기도 하다. 하시코프의 훼손된 키가 악성코드의 서명을 위해 사용되었다는 증거가 없지만 훼손된 키가 취소되기 전까지 이는 가능했다.
  
5. 개발자의 CI/CD 인프라 공격 
소나타입(Sonatype)는 최근 다차원적 소프트웨어 공급망 공격을 목격했다. 이 공격은 악의적인 풀 리퀘스트를 사용자의 깃허브 리포지터리로 도입하는 것에 의존했을 뿐 아니라 깃허브의 CI/CD 자동화 인프라인 깃허브 액션즈(GitHub Actions)를 악용해 암호화폐를 채굴했다. 깃허브 액션즈는 깃허브가 호스팅하는 리포지터리에 대한 자동화된 CI/CD 작업의 일정을 정하는 수단을 개발자에게 제공한다. 

이 공격은 깃허브 액션즈를 이용하는 정당한 깃허브 리포지터리를 복제하고 리포지터리 내의 깃허브 액션 스크립트를 살짝 변경한 후, 원래의 리포지터리에 변경을 융합하기 위해 프로젝트 소유자에게 풀 리퀘스트를 전송하는 것으로 이루어진다. 



프로젝트 소유자가 변경된 풀 리퀘스트를 무심코 승인한 경우 공급망 공격은 성공한 것이지만, 이는 전제 조건조차 되지 않았다. 악성 풀 리퀘스트는 ci.yml에 대한 변경을 포함했고, 이는 풀 리퀘스트가 전송되는 즉시 깃허브 액션즈에 의해 자동으로 실행되었다. 변경된 코드는 기본적으로 깃허브 서버를 악용해 가상화폐를 채굴한다.
 
이 공격은 일석이조의 효과를 갖는다. 개발자가 악성 풀 리퀘스트를 허용하도록 속이고, 이게 실패할 경우, 자동화된 CI/CD 인프라를 통해 악의적 활동을 이행하는 것이다. 

마찬가지로, 연구진은 UN 도메인에 성공적으로 침투해 10만 명 이상의 UNEP 직원 기록에 접근했다. 이 연구진은 이들 도메인 상에 노출된 깃 폴더와 ‘git-credentials’ 파일을 발견했기 때문에 성공할 수 있었다. 

이처럼 위협 행위자가 깃 허브 인증 정보로의 접근권한을 획득하면 이들은 비공개 깃 리포지터리를 복제할 수 있을 뿐 아니라 악성코드를 업스트림에 유입시켜 공급망 공격을 감행할 수 있고, 이는 훨씬 가혹한 결과로 이어질 것이다.
 
지금까지 공급망 공격을 방지하는 데에는 개발자의 안전한 코딩 관행, 또는 개발 환경에서 데브섹옵스(DevSecOps) 자동화 도구의 이용이 가장 중요했다. 그러나 젠킨스 서버와 같은 CI/CD 파이프라인, 클라우드-네이티브 컨테이너, 보완적인 개발자 툴링 및 인프라의 안전을 도모하는 일 역시 중요해졌다. 

6. 소셜 엔지니어링을 통한 악성코드 투하 
보안 전문가라면 누구나 알고 있듯이, 보안은 가장 취약한 고리만큼만 강력할 뿐이다. 인간 요소는 가장 약한 고리로 남아 있기 때문에 공격은 가장 예상치 못했던 부분에서 시작할 수 있다. 리눅스 재단은 최근 미네소타 대학교의 연구진을 차단했다. 이들은 의도적 오류가 있는 ‘패치’를 제안했고, 이는 차례로 리눅스 커널 소스코드에 취약점을 유입시켰다. 

이 사례는 적발되어 무난히 처리됐지만, 이는 몇 가지 단순한 사실을 드러낸다. 즉, 개발자는 시간이 충분하지 않고, 오류가 있거나 명백히 악의적일 수 있는 제안된 코드 변경이나 코드 커밋을 일일이 검증할 대역폭을 언제나 가지고 있지는 못할 수 있다는 것이다. 더 중요한 것은, 소셜 엔지니어링 공격은 가장 의심하지 않은 출처로부터 나올 수 있다. 앞서 설명한 사건은 ‘.edu’ 이메일 주소를 가진 신뢰성 있어 보이는 대학 연구진의 소행이었다.
  
또한 깃허브 프로젝트에 기여하는 협력자(collaborator)는 누구든지 심지어 프로젝트가 발표된 후에도 릴리즈를 변경할 수 있다. 여기서 다시 프로젝트 소유자가 기대하는 것은 대다수 협력자가 우호적으로 프로젝트에 코드와 커밋을 제출하고 있다는 것이다. 단 한 명의 악의적인 협업자만으로 공급망의 보안을 망칠 수 있다. 

지난 해 동안, 타이포스쿼팅(typosquatting) 및 브랜드재킹(brandjacking) 소프트웨어 패키지를 제작한 공격자들은 오픈소스 개발자의 업스트림 빌드에 악성코드를 유입시키기 위해 이들을 반복적으로 공격했고, 악성코드는 차례로 수많은 사용자에게 유포됐다.
  
이런 실 사례들은 위협 행위자가 성공적인 공급망 공격을 위해 이용하는 여러 약점, 공격 벡터, 기법을 보여준다. 이들 공격이 계속 진화하며 어려움을 야기함에 따라 소프트웨어 보안에 대한 참신한 해법과 전략이 필요한 상황이다. editor@itworld.co.kr