[IT WORLD] "어떤 고리가 끊어졌나…" 사례로 보는 소프트웨어 공급망 공격 유형 6가지

 

https://www.itworld.co.kr/news/311911

“어떤 고리가 끊어졌나…” 사례로 보는 소프트웨어 공급망 공격 유형 6가지

 

위 글을 기반으로 작성했습니다.

 

 

 

 

최근 소프트웨어 공급망 사고가 여러 매체의 헤드라인을 장식하고 있다.

 

 

'소프트웨어 공급망 공격'

공격자가 소프트웨어 개발 프로세스(개발 수명 주기)를 방해하거나 탈취해 완성된 제품/서비스를 사용하는 소비자에게 해로운 영향을 미치는 모든 경우를 포함하는 포괄적인 용어

 

 

ⓒ Getty Images Bank

 

같은 이름으로 분류되더라도 모든 공격이 동일한 방식으로 발생하는 것은 아니다.

 

 

대표적인 경우

• 소프트웨어 빌드에 사용되는 코드 라이브러리 또는 개별 구성 요소가 오염
• 소프트웨어 업데이트 바이너리가 트로이 목마에 감염
• 코드 서명 인증서 도난
• SaaS를 호스팅하는 서버의 손상

 

모든 소프트웨어 공급망 공격에서 공격자는 업스트림 또는 미드스트림에 개입해 악의적인 활동의 파급 효과가 있는 다운스트림을 수많은 사용자에게 전달

→ 성공적인 공급망 공격은 고립된 보안 침해보다 훨씬 더 큰 규모로 광범위한 영향을 미친다.

 

 

 

소프트웨어 공급망 위험, 얼마나 큰가?

파일럼(Phylum)의 '2023년 3분기 소프트웨어 공급망 보안 진화 보고서(Q3 2023 Evolution of Software Supply Chain Security Report)'에 따르면, 대부분 카테고리에서 의심스러운 패키지가 증가했다. 또한 더 많은 맬웨어 제작자가 광범위한 접근 방식이 아닌 특정 기업을 표적으로 삼는 전술을 채택하고 있다.

→ 이런 표적 공격의 목표는 인증정보 탈취, 소스 코드 또는 지식 재산 도용이 포함

 

하지만 많은 개발자가 소프트웨어 공급망 안전을 위한 베스트 프랙티스를 따르지 않는 것으로 보인다. 파일럼에 따르면, 개발자는 수많은 패키지를 다운로드하지만, 다운로드한 코드의 무결성을 검증하는 개발자는 거의 없다.

→ 공격자는 이런 사실을 알고 있기 때문에 향후 대규모 랜섬웨어 공격이나 봇넷과 같은 더 광범위한 캠페인을 시작 가능

 

 

 

 

사례로 보는 6가지 소프트웨어 공급망 공격 유형

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

 

 

 

 

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

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

 

대표적 사례 - 코드코브(Codecov) 공급망 공격

솔라윈즈 침해 사고와 비교되기도 했지만, 두 공격 사이에는 뚜렷한 차이가 있다.

솔라윈즈 공급망 침해는 정교한 위협 행위자의 소행으로, 행위자들은 솔라윈즈 IT 성능 모니터링 제품 오리온(Orion)의 합법적인 업데이트 바이너리인 SolarWinds.Orion.Core.BusinessLayer.dll을 변조했다.

 

파이어아이가 분석한 바와 같이, 위조 DLL의 RefreshInternal() 메소드에 포함된 악성 코드는 아래와 같다. 이 메소드는 오리온이 인벤토리 매니저 플러그인을 로드할 때 HTTP 기반 백도어를 호출한다.

 

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

 

 

솔라윈즈 업스트림 공격은 변조된 바이너리가 미국 정부기관을 포함한 1만 8,000개 이상의 오리온 고객에게 다운스트림으로 전달된 후에야 본격적으로 시작됐다. 코드코브의 경우 악성 코드가 다운스트림으로 유포되지 않아도 공격의 파급효과가 있었다.

 

코드코브 공격자들은 공식 보안 권고에 따라 결함이 있는 도커 이미지 생성 프로세스를 통해 코드코브 bash 업로더를 수정하는 데 사용되는 자격 증명을 획득했다. 그런 다음 고객의 CI/CD 환경에서 업로드되는 환경 변수를 수집하기 위해 코드코브 서버 자체에 호스팅된 코드코브 bash 업로더를 수정했다.

 

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

 

 

코드코브 bash 업로더 스크립트는 코드코브 서버 자체의 codecov[.]io/bash에 존재했지만, 수천 개의 리포지토리가 이미 이 링크를 참조해 CI/CD 환경에서 수정된 bash 업로더로 정보를 업스트림하고 있었다.

 

따라서 악성 코드는 손상된 업스트림 서버에만 존재하고 있었고 코드의 다운스트림 배포는 발생X

→ 이유는 소위 다운스트림 리포지토리가 이미 bash 업로더 스크립트를 호스팅하는 코드코브 서버를 가리키고 있었기 때문이다. 그렇지만 이런 다운스트림 리포지토리는 코드코브의 bash 업로더에 데이터를 업로드하도록 구성되었으므로 공격의 영향을 받을 수밖에 없었다.

 

 

공격의 영향

• 수백 개의 고객 네트워크 침해
• 소프트웨어 패키지 서명 및 확인에 사용되는 GPG(GNU Privacy Guard) 개인 키 노출 

 

 

 

 

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

'미드스트림'이라는 용어는 공격자가 원래의 업스트림 소스 코드 기반이 아닌 중개 소프트웨어 업그레이드 기능 또는 CI/CD 도구를 손상시키는 사례를 지칭하기 위해 느슨하게 적용되고 있다.

 

2021년 4월, 기업용 비밀번호 관리 프로그램인 패스워드스테이트(Passwordstate)를 개발한 클릭 스튜디오(Click Studios)의 공급망 공격 소식 공지

공격자들은 패스워드스테이트의 '인플레이스 업그레이드(In-Place Upgrade)' 기능을 손상시켜 사용자에게 악성 업데이트를 배포했다. 이 불법 업데이트에는 Moserware.SecretSplitter.dll이라는 변경된 DLL 파일이 포함돼 있었다.

 

 

• 침해는 종료 전 약 28시간 동안 존재
• 명시된 시간 사이에 인플레이스 업그레이드를 수행한 고객만 영향
• 패스워드스테이트의 수동 업그레이드는 손상X
• 영향을 받은 고객의 비밀번호 기록이 수집되었을 가능성O

→ 사용자를 대상으로 한 피싱 공격이 이어지는 것은 자연스러운 일

 

 

 

패스워드스테이트 공급망 공격의 소셜 엔지니어링 측면

300MB가 넘는 크기의 가짜 업데이트 zip 파일에서 공격자가 사용자 설명서, 도움말 파일, 파워셸 빌드 스크립트가 악성 CDN(Contents Distribution Network) 서버를 가리키도록 변경한 흔적을 발견했다.

→ 사람, 특히 초보 개발자나 소프트웨어 소비자가 CDN에 대한 링크의 신뢰성을 항상 확인하지 않는다는 것을 증명한다. 소프트웨어 애플리케이션과 웹사이트에서는 업데이트, 스크립트 및 기타 콘텐츠를 전송하기 위해 CDN을 합법적으로 사용하기 때문이다.

 

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

 

 

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

 

 

이런 공급망 공격의 또 다른 예시 : 메이지카드(Magecart)와 같은 온라인 신용카드 스키밍 공격

일부 공격에서는 아마존 클라우드프론트(CloudFront) CDN 버킷이 손상돼 해당 CDN에 의존하는 더 많은 웹사이트에 악성 자바스크립트 코드가 유포되기도 했다.

 

 

 

 

3. 의존성 혼동 공격

의존성 혼동 공격은 다수의 오픈소스 생태계에서 발견되는 고유한 설계 약점으로 인해 최소한의 노력으로 자동화된 방식으로 작동한다.

 

즉, 의존성 혼동 또는 네임스페이스(namespace) 혼동은 소프트웨어 빌드가 오픈소스 리포지토리에 존재하지 않는 내부적으로 생성된 비공개 의존성을 사용하는 경우 발생할 수 있다. 공격자는 공개 리포지토리에 동일한 이름의 의존성을 더 높은 버전으로 등록할 수 있다.

→ 내부 의존성이 아닌 더 높은 버전 번호를 가진 공격자의 공개된 의존성을 소프트웨어 빌드로 가져올 가능성이 높다.

 

 

의존성 혼란의 해결 방법

공격자보다 먼저 모든 비공개 의존성의 이름을 공개 리포지토리에 등록(예약)하고, 충돌하는 의존성 이름이 공급망에 유입되는 것을 방지하는 SDLC(Software Development Lifecycle) 방화벽과 같은 자동화된 솔루션을 사용하는 등 여러 가지 방법이 있다.

 

오픈소스 리포지토리 소유자는 보다 엄격한 인증 프로세스를 채택하고 실행 중인 네임스페이스/범위를 적용할 수 있다.

ex) 'CSO' 네임스페이스 또는 범위로 패키지를 게시하려면 오픈소스 리포지토리는 패키지를 업로드하는 개발자가 'CSO'라는 이름으로 패키지를 업로드할 권한이 있는지 확인하는 것이다.

 

ex) 자바 컴포넌트 리포지토리인 메이븐 센트럴(Maven Central)은 네임스페이스 소유권을 확인하기 위해 간단한 도메인 기반 인증을 사용한다. 이는 다른 생태계에서도 쉽게 모델링할 수 있는 방식이다. 마찬가지로 고 패키지 리포지토리에 게시된 패키지는 해당 깃허브 리포지토리의 URL을 따서 이름이 지정되므로 의존성 혼동 공격이 완전히 불가능하지는 않더라도 훨씬 더 어려워진다.

 

 

 

 

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

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

 

2021년 1월, 마임캐스트(Mimecast)는 고객이 마이크로소프트 365 익스체인지 서비스 연결 설정에 사용하는 인증서가 손상돼 사용자의 약 10%의 통신에 영향을 미칠 수 있다고 전했다. SSL 인증서인지 명시적으로 밝히지 않았지만, 많은 연구자가 SSL 인증서일 것으로 보고 있다.

 

도난당한 코드 서명 인증서, 즉 손상된 개인 키는 소프트웨어 보안에 훨씬 더 광범위한 결과를 초래할 수 있다. 개인 코드 서명 키를 손에 넣은 공격자는 합법적인 정품 소프트웨어 프로그램에 맬웨어에 대한 서명을 할 수 있다(서명이 있는 경우 제로데이로 간주X).

 

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

 

 

 

 

5. 개발자의 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 파이프라인(ex. 젠킨스 서버), 클라우드 네이티브 컨테이너, 보조 개발자 도구 및 인프라를 보호하는 것 또한 그에 못지않게 중요해졌다.

 

 

 

 

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

보안 시스템은 '가장 약한 고리만큼만' 강하다. 인적 요소는 여전히 보안의 가장 약한 고리이기 때문에 공격의 시작은 예상치 못한 곳에서 발생할 수 있다. 2021년 4월 리눅스 재단은 '버그가 있는 패치'를 의도적으로 제안해 결과적으로 리눅스 커널 소스코드에 취약성을 유발한 미네소타 대학교 연구원이 앞으로 프로젝트에 기여하는 것을 금지했다.

 

 

이 사례에서 알 수 있는 몇 가지 사실

• 개발자는 분산되어 있으며, 버그가 있거나 악의적인 코드 커밋, 제안된 코드 변경을 모두 충분히 검토할 만한 여유가 없을 수 있다.
• 소셜 엔지니어링이 최소한의 의심도 받지 않는 출처, 즉 '.edu' 이메일 주소를 가진 신뢰할 수 있는 대학 연구자들로부터 시작될 수도 있다.

 

깃허브 프로젝트에 기여하는 공동 작업자가 릴리즈 게시 후에도 이를 변경할 수 있다는 점을 악용한 사례도 있다. 여기서도 프로젝트 소유자는 대부분이 선의로 코드와 커밋을 제출한다고 신뢰할 것이다. 하지만 공급망 보안을 손상시키는 데는 단 한 명의 공동 작업자만 있으면 된다.

 

여기서 설명한 모든 실제 사례는 위협 행위자가 성공적인 공급망 공격에 사용하는 다양한 약점, 공격 벡터, 기법을 보여준다. 이런 공격은 계속 진화하고 도전 과제를 야기하므로 소프트웨어 보안에 접근할 때 보다 효과적인 솔루션과 전략이 필요하다.

 

 

 

 

마치며

6가지 사례를 통해 자세히 알지 못했던 소프트웨어 공급망 공격 유형에 대해 알게 되었으며, 그 위험이 얼마나 큰지 깨닫게 되었다. 또한 이러한 공격을 방어하기 위해서는 더욱 효과적인 소프트웨어 보안 솔루션과 전략이 필요하기 때문에 이에 관한 지속적인 연구가 중요할 것이라고 생각한다.