공공 코드 리포지터리의 핵심이면서 악용 가능성이 전혀 없어 보였던 기능 하나가 공격자들에게 악용되기 시작했다. 아직 대처법이 없다는 게 더 큰 문제다.
[보안뉴스 문가용 기자] 해커들이 공개되지 않은 깃허브 및 깃랩 코멘트들을 활용해 피싱 링크를 만들어내기 시작했다. 이렇게 하니 정상적인 오픈소스 소프트웨어와 연결된 링크처럼 보이게 됐다. 매우 영리한 기법으로, 지난 달 오픈애널리시스(Open Analysis)의 세르게이 프랭코프(Sergei Frankoff)가 처음 발견했다. 아무나 아무 프로젝트를 사칭할 수 있게 해 주며, 프로젝트의 원 주인이 그 사실을 알아내기가 힘들다고 한다. 알아낸다 한들 할 수 있는 일이 없다.
사실 이 기법은 이미 일부 공격자들 사이에서 알려져 있던 것이었다. 보안 업체 맥아피(McAfee)에 의하면 해커들은 MS의 깃허브에 호스팅 되어 있던 vcpkg와 STL이라는 프로젝트를 통해 레드라인스틸러(Redline Stealer)라는 정보 탈취 멀웨어를 유포한 적이 있다고 한다. 다만 프랭코프는 이런 기법이 보다 널리 사용되는 것을 발견해 알린 것이며, 보안 외신 블리핑컴퓨터도 자체적으로 httprouter라는 프로젝트가 이런 식으로 악용되고 있는 사실을 찾아냈다.
탐지도 어렵고, 막기도 어렵고
이 피싱 기법의 근간이 되는 건 깃허브와 깃랩이라는 공공 코드 리포지터리에 있는, 전혀 악용의 가능성이 없어 보이는 기능이다. 개발자들이 ‘코멘트’를 남길 수 있게 해 주는 기능이 바로 그것이다. 개발자들은 오픈소스 프로젝트 페이지에 코멘트를 남길 수 있는데, 주로 기능 향상에 대한 제안이나 버그 제보를 위해 이 기능을 활용한다. 내용이 길 경우 문서 파일로 작성해 코멘트를 남기기도 하고, 스크린샷 등의 형태도 가능하다.
깃허브와 깃랩의 프로젝트에 파일 형태로 코멘트를 남긴다고 했을 때, 해당 코멘트에는 자동으로 URL이 배정된다. 누가 봐도 해당 프로젝트와 관련이 있어 보이는 URL이다. 예를 들어 깃랩의 프로젝트에 파일을 코멘트로서 업로드 하면 URL이 이런 식으로 생성된다.
* http://gitlab.com/{프로젝트_그룹_이름}/{리포지터리_이름}/uploads/{파일_id}/{파일_이름}
이것을 보고 해커들은 ‘누군가를 속이기에 딱 좋은 URL’이라고 생각하게 됐다. 코멘트 부분에 멀웨어를 업로드 하면 URL이 자동으로 생성되는데, 그 URL에 깃허브나 깃랩의 이름이 들어가고 각종 프로젝트의 이름까지 같이 들어가니 가짜라는 걸 육안으로 판별하는 게 상당히 어려워질 게 뻔해 보였던 것이다. MS의 프로젝트에 코멘트를 그런 식으로 남기면 심지어 MS의 이름까지도 URL에 담을 수 있다니, 피싱 링크로서는 더할 나위 없었다. 그래서 실제 MS의 일부 프로젝트들의 코멘트로부터 레드라인이 퍼졌던 것이다.
해당 프로젝트의 운영자들은 코멘트까지 하나하나 살피기 어렵다. 코멘트에 파일을 올려두었을 때 생성되는 URL을 전량 검사하기도 힘든 일이다. 그렇기 때문에 이러한 전략은 프로젝트 관리자의 눈을 쉽게 피할 수 있게 해 준다. 그래도 언젠가 프로젝트 관리자가 수상한 코멘트를 발견할 수 있지 않을까? 그렇다면 해당 코멘트를 삭제하면 그만 아닐까? 아니다. 코멘트를 지우더라도 생성됐던 URL은 여전히 작동하고, 업로드 된 파일도 코멘트에서만 지워지지 해당 사이트의 CDN에는 그대로 남아있다. 지워도 위협은 잔존한다는 것이다.
심지어 파일을 업로드 한 후 코멘트를 등록하지 않아도 된다. 깃허브에서나 깃랩에서나 파일이 업로드 되는 순간에 URL이 생성되기 때문이다. 즉 ‘등록’ 버튼을 누르지 않아도, 파일 업로드 기능만 활성화시키는 것으로 URL을 만들 수 있게 된다. 그리고 이 URL은 정상적으로 작동하며, 이렇게 코멘트를 등록시키지 않으면 프로젝트 관리자가 그 어떤 조치를 취할 수도 없고, 애초에 발견 자체가 어려워진다.
이러한 미묘한 코멘트 기능의 특성 때문에 공격자들은 깃허브와 깃랩에 아무 멀웨어나 올려둘 수 있게 되며, 동시에 그 멀웨어로 향하는 URL을 매우 ‘신뢰할 만한 형태’로 뽑을 수 있게 된다. 게다가 코멘트 섹션에 아무런 흔적도 남기지 않는 것도 가능하다.
이런 식의 공격이 정말로 악독한 것은 공격자들이 사칭하는 프로젝트의 신뢰도를 훼손시키기 때문이다. 그리고 여기에 대응할 방법이 사실상 전무하다. 깃허브와 깃랩의 프로젝트 관리자들이 설정을 만져서 이 문제를 해결할 수 있는 것도 아니다. 코멘트 자체를 비활성화시킬 수 있긴 한데 임시적인 조치일 뿐이며 득보다 실이 많을 수 있다. 또한 공공 리포지터리를 사용하는 이유가 사실상 사라지게 되기도 한다.
보안 업체 섹티고(Sectigo)의 부회장인 제이슨 소로코(Jason Soroko)는 “깃허브 프로젝트 이름이 포함되어 있는 URL을 보고 악성인지 아닌지를 판단하는 건 불가능한 일”이라며 “실제로 URL에 포함된 내용이나 글자와 신뢰도는 아무런 상관이 없다는 지적이 예전부터 나왔었는데, 그것이 실제로 입증되고 있는 모양새”라고 말한다. “즉 내가 알고 있는 이름들이 URL에 있다고 해서 믿어버리는 건 지양해야 할 것입니다. 보다 확실한 확인 방법이 필요합니다.”
3줄 요약
1. 깃허브와 깃랩, 공격자들에게 간편한 멀웨어 호스팅 서비스 제공.
2. 문제는 깃허브와 깃랩의 코멘트 기능으로 여기에 멀웨어 업로드 하면 자동으로 피싱 URL도 생성됨.
3. 지금 이 전략에 대처할 수 있는 방법은 사실상 하나도 없는 상황.
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 해커들이 공개되지 않은 깃허브 및 깃랩 코멘트들을 활용해 피싱 링크를 만들어내기 시작했다. 이렇게 하니 정상적인 오픈소스 소프트웨어와 연결된 링크처럼 보이게 됐다. 매우 영리한 기법으로, 지난 달 오픈애널리시스(Open Analysis)의 세르게이 프랭코프(Sergei Frankoff)가 처음 발견했다. 아무나 아무 프로젝트를 사칭할 수 있게 해 주며, 프로젝트의 원 주인이 그 사실을 알아내기가 힘들다고 한다. 알아낸다 한들 할 수 있는 일이 없다.
[이미지 = gettyimagesbank]
사실 이 기법은 이미 일부 공격자들 사이에서 알려져 있던 것이었다. 보안 업체 맥아피(McAfee)에 의하면 해커들은 MS의 깃허브에 호스팅 되어 있던 vcpkg와 STL이라는 프로젝트를 통해 레드라인스틸러(Redline Stealer)라는 정보 탈취 멀웨어를 유포한 적이 있다고 한다. 다만 프랭코프는 이런 기법이 보다 널리 사용되는 것을 발견해 알린 것이며, 보안 외신 블리핑컴퓨터도 자체적으로 httprouter라는 프로젝트가 이런 식으로 악용되고 있는 사실을 찾아냈다.
탐지도 어렵고, 막기도 어렵고
이 피싱 기법의 근간이 되는 건 깃허브와 깃랩이라는 공공 코드 리포지터리에 있는, 전혀 악용의 가능성이 없어 보이는 기능이다. 개발자들이 ‘코멘트’를 남길 수 있게 해 주는 기능이 바로 그것이다. 개발자들은 오픈소스 프로젝트 페이지에 코멘트를 남길 수 있는데, 주로 기능 향상에 대한 제안이나 버그 제보를 위해 이 기능을 활용한다. 내용이 길 경우 문서 파일로 작성해 코멘트를 남기기도 하고, 스크린샷 등의 형태도 가능하다.
깃허브와 깃랩의 프로젝트에 파일 형태로 코멘트를 남긴다고 했을 때, 해당 코멘트에는 자동으로 URL이 배정된다. 누가 봐도 해당 프로젝트와 관련이 있어 보이는 URL이다. 예를 들어 깃랩의 프로젝트에 파일을 코멘트로서 업로드 하면 URL이 이런 식으로 생성된다.
* http://gitlab.com/{프로젝트_그룹_이름}/{리포지터리_이름}/uploads/{파일_id}/{파일_이름}
이것을 보고 해커들은 ‘누군가를 속이기에 딱 좋은 URL’이라고 생각하게 됐다. 코멘트 부분에 멀웨어를 업로드 하면 URL이 자동으로 생성되는데, 그 URL에 깃허브나 깃랩의 이름이 들어가고 각종 프로젝트의 이름까지 같이 들어가니 가짜라는 걸 육안으로 판별하는 게 상당히 어려워질 게 뻔해 보였던 것이다. MS의 프로젝트에 코멘트를 그런 식으로 남기면 심지어 MS의 이름까지도 URL에 담을 수 있다니, 피싱 링크로서는 더할 나위 없었다. 그래서 실제 MS의 일부 프로젝트들의 코멘트로부터 레드라인이 퍼졌던 것이다.
해당 프로젝트의 운영자들은 코멘트까지 하나하나 살피기 어렵다. 코멘트에 파일을 올려두었을 때 생성되는 URL을 전량 검사하기도 힘든 일이다. 그렇기 때문에 이러한 전략은 프로젝트 관리자의 눈을 쉽게 피할 수 있게 해 준다. 그래도 언젠가 프로젝트 관리자가 수상한 코멘트를 발견할 수 있지 않을까? 그렇다면 해당 코멘트를 삭제하면 그만 아닐까? 아니다. 코멘트를 지우더라도 생성됐던 URL은 여전히 작동하고, 업로드 된 파일도 코멘트에서만 지워지지 해당 사이트의 CDN에는 그대로 남아있다. 지워도 위협은 잔존한다는 것이다.
심지어 파일을 업로드 한 후 코멘트를 등록하지 않아도 된다. 깃허브에서나 깃랩에서나 파일이 업로드 되는 순간에 URL이 생성되기 때문이다. 즉 ‘등록’ 버튼을 누르지 않아도, 파일 업로드 기능만 활성화시키는 것으로 URL을 만들 수 있게 된다. 그리고 이 URL은 정상적으로 작동하며, 이렇게 코멘트를 등록시키지 않으면 프로젝트 관리자가 그 어떤 조치를 취할 수도 없고, 애초에 발견 자체가 어려워진다.
이러한 미묘한 코멘트 기능의 특성 때문에 공격자들은 깃허브와 깃랩에 아무 멀웨어나 올려둘 수 있게 되며, 동시에 그 멀웨어로 향하는 URL을 매우 ‘신뢰할 만한 형태’로 뽑을 수 있게 된다. 게다가 코멘트 섹션에 아무런 흔적도 남기지 않는 것도 가능하다.
이런 식의 공격이 정말로 악독한 것은 공격자들이 사칭하는 프로젝트의 신뢰도를 훼손시키기 때문이다. 그리고 여기에 대응할 방법이 사실상 전무하다. 깃허브와 깃랩의 프로젝트 관리자들이 설정을 만져서 이 문제를 해결할 수 있는 것도 아니다. 코멘트 자체를 비활성화시킬 수 있긴 한데 임시적인 조치일 뿐이며 득보다 실이 많을 수 있다. 또한 공공 리포지터리를 사용하는 이유가 사실상 사라지게 되기도 한다.
보안 업체 섹티고(Sectigo)의 부회장인 제이슨 소로코(Jason Soroko)는 “깃허브 프로젝트 이름이 포함되어 있는 URL을 보고 악성인지 아닌지를 판단하는 건 불가능한 일”이라며 “실제로 URL에 포함된 내용이나 글자와 신뢰도는 아무런 상관이 없다는 지적이 예전부터 나왔었는데, 그것이 실제로 입증되고 있는 모양새”라고 말한다. “즉 내가 알고 있는 이름들이 URL에 있다고 해서 믿어버리는 건 지양해야 할 것입니다. 보다 확실한 확인 방법이 필요합니다.”
3줄 요약
1. 깃허브와 깃랩, 공격자들에게 간편한 멀웨어 호스팅 서비스 제공.
2. 문제는 깃허브와 깃랩의 코멘트 기능으로 여기에 멀웨어 업로드 하면 자동으로 피싱 URL도 생성됨.
3. 지금 이 전략에 대처할 수 있는 방법은 사실상 하나도 없는 상황.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-04] 
