반응형

일반적인 '공급망 공격(Supply Chain Attack)' 유형 6가지


자세한 내용은 참조 링크를 참고하기 바랍니다.
[참조] https://www.ciokorea.com/news/196249

공급망 공격은 공격자가 소프트웨어 제작 공정(소프트웨어 개발 수명주기)에 간섭하거나 이를 하이재킹해서 제품 또는 서비스의 소비자에게 악영향을 준다. 소프트웨어 구축에 쓰인 코드 라이브러리나 개별 컴포넌트가 손상됐을 때, 소프트웨어 업데이트 코드가 트로이목마에 감염됐을 때, 코드 서명 인증서가 도난 당했을 때, 심지어 서비스 소프트웨어(SaaS) 호스팅 서버가 훼손된 경우도 공급망 공격에 속한다. 

1. 업스트림 서버 훼손: 코드코브 공급망 공격(Codecov supply chain attack) 

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

2. 미드스트림 훼손에 의한 악성 업데이트 

‘미드스트림(midstream)’은 중간의 소프트웨어 업그레이드 기능이나 CI/CD 도구를 훼손하는 사례를 지칭하는 용어이다. 
이 공급망 공격은 업그레이드 프로세스 변경과 같은 기술 공격뿐만 아니라 소셜 엔지니어링 공격까지 추가하기도 한다. 소셜 엔지니어링 공격은 또 다른 약점을 보여준다. 초급 개발자 또는 소프트웨어 사용자는 CDN의 악성 여부 관계없이 CDN의 링크를 의심하지 않는다. CDN이 소프트웨어 애플리케이션 및 웹사이트에 의해 정당하게 사용되어 업데이트, 스크립트, 여타 콘텐츠를 배포하기 때문이다.

3. 의존성 혼동 공격(Dependency confusion attacks) 

의존성 혼동 공격의 단순하면서도 자동화된 성질 때문이다. 의존성 혼동 공격은 자동화된 형식으로 이뤄진다. 의존성 혼동은 내부에 생성된 의존성을 이용한다. 공격자는 공개 리포지터리 상에서 동일한 이름으로 의존성을 더 높은 버전으로 등록할 수 있다. 그 후, 공격자의 공개 의존성이 더 높은 버전 번호로 인해 사용자의 소프트웨어 빌드로 유입될 가능성이 매우 높다.
의존성 혼동을 해결하는 한 가지 방법은 모든 프라이빗 의존성의 이름을 해커보다 먼저 공개 리포지터리에 등록하고 자동화 솔루션, 예를 들어 상충되는 의존성 이름이 공급망에 유입되는 것을 차단하는 SDLC(Software Development Lifecycle) 방화벽 등을 이용하는 것이다. 
오픈소스 리포지터리의 소유자는 엄격한 인증 프로세스를 도입하고 네임스페이스(namespace)/스코프(scope)를 강제할 수 있다. 자바 컴포넌트 리포지터리인 메이븐 센트럴(Maven Central)은 단순한 도메인 기반 검증을 적용해 네임스페이스 소유권을 검증한다. 유사하게, 고(Go) 패키지 리포지터리로 발표되는 패키지는 이들 깃허브 리포지터리 URL에 따라 이름이 지정된다. 이는 의존성 혼동 공격을 훨씬 어렵게 만든다. 

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

HTTPS 웹사이트가 증가함에 따라 SSL/TLS 인증서는 어디에나 존재한다. 따라서 SSL 인증서의 비밀 키 훼손은 최종 사용자로의 엔드 투 엔드 암호화 연결이 제공하는 안전한 커뮤니케이션과 확신을 위협할 수 있다. 
도난 당한 코드 서명 인증서(code-signing certificate), 즉 훼손된 비밀 코드 서명 키는 소프트웨어 보안에 훨씬 광범위한 영향을 초래할 수 있다. 공격자가 비밀 코드 서명 키를 확보하면 유명 업체가 출하하는 진정한 소프트웨어 프로그램이나 업데이트로서 자신의 악성코드에 서명할 가능성이 있기 때문이다. 
 
5. 개발자의 CI/CD 인프라 공격 

예를 들어, 악의적인 풀 리퀘스트를 사용자의 깃허브 리포지터리로 도입하는 것에 의존했을 뿐 아니라 깃허브의 CI/CD 자동화 인프라인 깃허브 액션즈(GitHub Actions)를 악용해 암호화폐를 채굴하기도 한다. 깃허브 액션즈는 깃허브가 호스팅하는 리포지터리에 대한 자동화된 CI/CD 작업 일정을 정하는 수단을 개발자에게 제공한다. 프로젝트 소유자가 변경된 풀 리퀘스트를 무심코 승인한 경우 공급망 공격은 성공한 것이다.  
이 공격은 일석이조의 효과를 갖는다. 개발자가 악성 풀 리퀘스트를 허용하도록 속이고, 이게 실패할 경우, 자동화된 CI/CD 인프라를 통해 악의적 활동을 이행하는 것이다. 
마찬가지로, 위협 행위자가 깃 허브 인증 정보로의 접근권한을 획득하면 이들은 비공개 깃 리포지터리를 복제할 수 있을 뿐 아니라 악성코드를 업스트림에 유입시켜 공급망 공격을 감행할 수 있다.

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

리눅스 재단은 최근 미네소타 대학교의 연구진을 차단했다. 이들은 의도적 오류가 있는 ‘패치’를 제안했고, 이는 차례로 리눅스 커널 소스코드에 취약점을 유입시켰다. 
소셜 엔지니어링 공격은 가장 의심하지 않은 출처로부터 나올 수 있다. 
또한 깃허브 프로젝트에 기여하는 협력자(collaborator)는 누구든지 심지어 프로젝트가 발표된 후에도 릴리즈를 변경할 수 있다. 여기서 다시 프로젝트 소유자가 기대하는 것은 대다수 협력자가 우호적으로 프로젝트에 코드와 커밋을 제출하고 있다는 것이다. 단 한 명의 악의적인 협업자만으로 공급망 보안을 망칠 수 있다. 
타이포스쿼팅(typosquatting) 및 브랜드재킹(brandjacking) 소프트웨어 패키지를 제작한 공격자들은 오픈소스 개발자의 업스트림 빌드에 악성코드를 유입시키기 위해 이들을 반복적으로 공격했고, 악성코드는 차례로 수많은 사용자에게 유포됐다.

원문보기:
 https://www.ciokorea.com/news/196249#csidx3bc70a98f4723e4ac510c79fe58348c

 

실제 사례로 살펴보는 보편적인 '공급망 공격' 유형 6가지

요즘 소프트웨어 공급망 사건이 보안 세계를 떠들석하게 만들고 있다. 이 보안 사건들은 서로 유사하긴 하지만 공급망 공격(Supply Chain

www.ciokorea.com

 

반응형

+ Recent posts