[SW 공급망 보안④] 공격자 놀이터 된 ‘깃허브’
상태바
[SW 공급망 보안④] 공격자 놀이터 된 ‘깃허브’
  • 김선애 기자
  • 승인 2023.07.17 10:34
  • 댓글 0
이 기사를 공유합니다

개발 편의성 높이기 위해 사용하는 코드 저장소, ‘공격 편의성’도 높여
서드파티 코드 이용 다양한 공격 등장하며 보안 대응 어렵게 해

[데이터넷] 소프트웨어 공급망이 공격자들의 중요한 먹잇감이 되고 있다. 복잡한 공급망의 한 지점만 침투하면 공급망에 연결된 모든 조직을 공격할 수 있기 때문이다. 보안에 소홀한 SW 개발사, 깃허브와 같은 코드 저장소, 오픈소스 취약점 등은 공급망 공격에 매우 취약하다. 대형 글로벌 기업의 코드서명 인증서가 탈취도 공격에 악용되고 있기도 하다. 소프트웨어 공급망 공격 동향을 분석하고, 필요한 대안을 제안한다.<편집자>

감염된 NPM 패키지 이용 공격 반복

감염된 NPM 패키지를 이용하는 공격이 반복적으로 발생하고 있다. 이 때문에 NPM이 일시적인 서비스 중단 공격을 받기도 했으며, 오픈소스 생태계의 좋은 평판을 악용해 140만개 이상 악성 NPM 패키지를 유포시키기도 했다.

체크막스는 지난 3월 140만개가 넘는 악성 NPM 패키지로 인해 도스, 스팸, SEO 포이즈닝, 악성코드 유포 공격이 발생하고 있다고 분석했는데, 공격을 진행한 동일한 사용자 NPM 계정에서 수천개의 추가 스팸 패키지가 플러딩됐다. 이 캠페인에는 알리익스프레스에 연결된 추천사기, 텔레그램 러시아 사용자 대상 암호화폐 사기 캠페인도 포함돼 있었다.

체크막스는 악성 NPM 패키지 계정을 제거하는 것은 ‘히드라의 머리를 자르는 것과 같다’고 설명한다. 그러나 유해 패키지 유포 방지를 위해 악성 계정을 삭제하다가 합법적인 사용자까지 영향을 받아서는 안된다는 점을 강조하면서 악성 계정에 대한 정보를 공유해야 한다고 주장한다. 왜냐하면 공격자는 신뢰할 수 있는 계정을 탈취하거나 사칭해 공격하기 때문이다.

체크막스에 따르면 공격자는 잘 관리되는 깃허브 프로젝트, 신뢰할 수 있는 NPM 기여자의 프로필을 위조해 감염된 패키지를 개발자들이 사용하도록 한다. 불행히도 스푸핑 당하는 그룹과 사용자는 가짜 커밋에 자신의 이름이 도용되고 있다는 사실을 알지 못한다.

잘 알려진 커뮤니티 기여자의 신뢰를 도용한 공격 사례(자료: 체크막스)
잘 알려진 커뮤니티 기여자의 신뢰를 도용한 공격 사례(자료: 체크막스)

코드 리포지토리, 가장 위험한 공급망 요소

이 처럼 깃허브 등 코드 저장소를 이용한 공격이 너무나 자주 발생하고 있다. 코드 저장소는 개발팀이 코드를 수정, 삭제, 복원 등 관리 작업을 공동으로 할 수 있으며, 코드변경을 추적할 수 있어 다중개발자 환경에서 사용되고 있다. 오픈소스 소프트웨어는 개발자의 자발적 기여가 중요하기 때문에 코드 저장소에 자신이 개발한 코드를 업로드한다.

자발적 기여자는 자신의 패키지가 얼마나 다운로드 되는지, 평가 점수가 얼마인지에 따라 명예를 얻는다. 유명 개발자의 코드는 많은 개발팀에서 내려받으면서 그 사람의 명성을 더 높게 만든다. 그래서 공격자는 유명 개발자의 계정을 탈취해 악성패키지를 업로드하거나 유명 개발자와 비슷한 이름의 계정을 만들어 악성 패키지를 다운로드 받게 한다.

기업의 공식 깃허브 계정을 탈취한 공격자들이 깃허브 리포지토리에세 개발된 코드를 탈취하며, 악성코드를 주입해 업로드한다. 이 패키지를 적용한 서비스는 공격당할 수 있다. 깃허브 계정탈취는 어렵지 않다. 개발자가 코드를 작성할 때 편의에 따라 계정 비밀번호를 적어 놓는 경우가 많은데, 개발 완료 후 커밋할 때 중요한 데이터와 자격증명, 비밀번호를 삭제해야 하지만, 이를 잊고 커밋해 배포된 코드에 계정 정보가 포함된다.

코드 보안 플랫폼 제공업체 깃가디언 조사에서는 IT 의사결정권자 58%가 소프트웨어 공급망의 주요 위험 요소로 소스코드와 리포지토리를 꼽았다. 그만큼 코드 저장소로 인한 위협은 매우 높다.

오타를 내는 습관을 이용하는 타이포스쿼팅과 의존성 혼동(Dependency Confusion)도 심각하다. 유명 패키지와 유사한 이름 혹은 유명 패키지를 타이핑할 때 오타를 내는 습관을 이용하는 것이다. 예를들어 ABC라는 유명 패키지가 있으면 ABV라는 이름의 가짜 패키지를 NPM에 업로드한다. C 옆의 V를 잘못 입력하는 습관을 악용하는 것이다.

지난해 깃허브에는 금융·통화 응용프로그램에 사용되는 rust_decimal과 비슷하게 보이는 이름의 rustdecimal이 등록된 것이 발견됐다. 정상 패키지와 코드가 거의 같지만, 특정 함수에서 악성코드를 내려받도록 교묘하게 조작돼 있었다.

송대근 체크막스 지사장은 “체크막스 조사에서는 타이포스쿼팅으로 50만건 이상 다운받은 악성 패키지도 발견됐다. 오픈소스 커뮤니티 계정이 해킹당해 해당 커뮤니티의 유명 개발자 명성을 이용해 악성 패키지가 유포된 사례도 있었다. 유명 개발자의 코드, 신뢰할 수 있는 조직의 코드라고 해도 정확히 정상 계정인지, 유사 계정인지, 탈취된 것은 아닌지 확인해야 하며, SCA와 같은 툴을 이용해 취약한 코드가 포함돼 있는지 반드시 점검해야 한다”고 말했다.

수백만 깃허브 저장소 취약성 영향 받아

최근 발견된 깃허브 취약성 리포재킹(RepoJacking)도 심각한 영향을 미치는 것으로 나타난다. 깃허브 리포지토리 이름을 바꾸면 새로운 이름으로 종속성 정보가 이동하는데, 리포재킹 취약점은 이전에 사용하던 이름을 공격자가 가로채 해당 리포지토리와 종속성 정보까지 모두 볼 수 있는 것이다.

지난해 말 이 취약점이 공개돼 깃허브는 이름이 변경될 때 복제본 100개 이상 저장소는 폐기된 것으로 간주해 다른 사람이 사용하지 못하도록 했다. 그런데 체크막스 조사에서는 고, 스위프트, PHP 등 깃허브에서 직접 패키지 코드를 가져오면서 깃허브 URL을 패키지 포인터로 사용하는 언어는 이 조치를 피할 수 있다. 체크막스는 5월 이러한 우회공격으로 수천개의 패키지가 즉시 하이재킹 될 수 있으며, 수백만명의 사용자와 애플리케이션에 악성코드를 제공할 수 있다고 설명했다.

아쿠아시큐리티가 실제 이 취약성의 영향을 받는 리포지토리가 수백만개에 이를 것으로 분석했다. 아쿠아시큐리티 위협 조사 전문조직 노틸러스가 임의의 기간으로 설정한 2019년 6월 한 달 동안 GH토렌트 로그에서 활성화된 저장소의 1%에 해당하는 152만개 저장소를 조사했더니 3%가량이 취약한 것으로 나타났다. 현재 활성화된 전체 저장소는 3억개 이상이므로, 실제로 취약한 리포지토리는 수백만개에 달할 것이라는 분석이다.

노틸러스는 기업·기관의 깃허브 저장소가 리포재킹 영향을 받는지 확인하기 위해서는 조직에서 사용하는 깃허브 저장소 이름과 변경내역, 인수합병 시 피인수 회사의 상황, 현재 사용중인 코드에 리포재킹 취약한 깃허브 저장소로 이어지는 종속성이 있는지 등을 파악해야 한다고 설명했다.

리포재킹 공격 방식(자료: 아쿠아시큐리티)
리포재킹 공격 방식(자료: 아쿠아시큐리티)

모든 단계서 발생하는 공급망 공격

실제 개발자가 사용하는 빌드 시스템 자체에서도 취약점이 발견됐다. 지난 3월 CI/CD 도구 젠킨스 서버에서 임의의 코드를 실행할 수 있는 취약점이 발견됐는데, 이 취약점을 이용하면 백도어가 삽입된 패키지가 정상 데브옵스 프로세스를 따라 배포될 수 있다. 이 패키지가 업데이트 파일이라면 이를 내려받은 모든 고객이 감염될 수 있다.

API도 공급망 공격에 취약하다. 기업·기관이 사용하는 API는 셀 수 없이 많으며, 중요한 정보가 유통되기 때문에 보안에 각별히 신경써야 한다. 그런데 많은 기업·기관이 사용중인 API조차 제대로 파악하지 못하는 실정이다. API 자체의 논리적 설계 오류와 잠재된 취약점, 접근권한 노출로 인한 정보 탈취와 API 취약점 삽입 등이 가능하다.

클라이언트 사이드의 서드파티 코드로 인한 공급망 공격도 성행하고 있다. 주로 이커머스 서비스 사용자를 대상으로 수행되는 메이지카트 공격의 경우, 신용카드 결제 창을 직접 개발하지 않고 미리 개발된 결제 서비스를 가져온다. 이 서비스에 취약점이 있어서 소비자가 입력하는 신용카드와 개인정보를 탈취하고, 상품을 비싼 것으로 바꾸고 배송지를 공격자 주소로 바꾼다.

이러한 피해를 미연에 방지하기 위해 PCI-DSS V4.0에서는 최종 사용자 브라우저의 보안 문제까지 책임지도록 하고 있다. 그래서 서드파티 코드 중 클라이언트 사이드에서 발생하는 위협을 막을 수 있는 방법이 시급하다.


관련기사

댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.