.jpg)
.jpg)
데브옵스 퍼지면서 각광받기 시작한 오픈소스...사용하지 않는 게 최선이지만
오픈소스는 결국 신뢰의 문제...의심하고 확인한 후 사용하는 문화 퍼져야 안전
[보안뉴스 문가용 기자] 수많은 조직들의 프로젝트에 사용되는 오픈소스 소프트웨어는 커다란 위험 요소로 발전할 가능성이 다분하다. 특히 그 오픈소스를 만든 사람들이나, 그 오픈소스를 활용한 프로젝트에 참여한 사람들은 꽤나 자유롭게 악성 행위를 저지를 수 있다는 주장이 나왔다. 이제 너무나도 편만한 오픈소스들은, 그 편만함 때문에 크나큰 위협이 되어버렸다 보안 전문가들은 말한다.
악의를 품은 자가 어떤 오픈소스 프로젝트에 개입할 수 있게 된다면, 할 수 있는 일이 많아진다. 다만 한계가 없는 건 아니다. “백도어를 심든, 트로이목마로서 오픈소스를 활용하든, 공격을 매우 빠르게 진행하거나 은밀하게 행동을 취해야 합니다. 그래야 최대한 들키지 않고 오랫동안 공격을 진행할 수 있거든요.” 보안 업체 제로데이 컨설팅(Zero Day Consulting)의 브래드 코지(Brad Causey)가 하는 설명이다.
오픈소스 프로젝트의 가장 큰 특징은 가용성과 유연성이다. 그래서 개발자들이 오픈소스를 좋아하는 건데, 이는 해커들도 마찬가지다. “오픈소스를 통해 해킹 공격을 실시하는 건 이미 유명한 수법이죠. 다만 그러한 일이 우리가 인지하는 것보다 훨씬 자주, 편만하게 일어난다는 건 그리 유명하지 않을 겁니다.” 보안 업체 베라코드(Veracode)의 수석 연구 책임자인 크리스 엥(Chris Eng)의 설명이다.
보안 업체 체크막스(Checkmarx)의 보안 연구원인 에란 얄론(Eran Yalon)도 이에 동의한다. “아직도 오픈소스를 통한 해킹이 먼 나라 일로만 여겨지고 있습니다. 지금도 실제 우리 가까이에서 벌어지고 있는데 말이죠. 앞으로도 오픈소스 해킹 전략이 사라질 거라고 보기 힘듭니다.”
오픈소스 프로젝트는 여러 사람이나 조직의 참여로 이뤄지는 게 보통인데, 이 참여자들을 컨트리뷰터(contributor)라고 한다. 각 컨트리뷰터는 동료 컨트리뷰터들의 작업물을 검사하고, 이 과정을 통과해야만 코드가 오픈소스의 일부로서 접수된다. 검사의 난이도는 컨트리뷰터마다 달라진다. 신뢰도가 높고 명망도 높은 인물의 작업물이라면 검사가 그리 엄격하게 이뤄지지 않을 때가 많다. 물론 그 신뢰를 쌓는다는 게 그리 쉬운 일은 아니다.
“예를 들어 유명 리눅스 버전의 컨트리뷰터들의 경우, 직원들도 많고 커뮤니티 참여자들도 많으며, 수정과 패치가 자주 이뤄진 역사를 가지고 있기 때문에 신뢰가 두터운 편에 속합니다. 실제로 리눅스는 오픈소스 프로젝트들 중에서 안전한 편이며, 충분한 감시와 검사를 받는 편입니다.”
하지만 리눅스와 비교도 안 될 만큼 작은 오픈소스 프로젝트의 경우, 신뢰를 그리 크게 받지 못한다. 그만큼 검사를 주기적으로 꼼꼼하게 실시할 자원을 갖추고 있지 못하기 때문이다. 따라서 해커들의 1차 타격을 받는 것도 바로 이러한 ‘소규모 오픈소스 프로젝트’, 라고 코지는 설명한다.
프로젝트의 크기와 디펜던시
“아주 작은 패키지라고 하더라도 대형 패키지의 디펜던시가 될 수 있습니다. 이 디펜던시의 깊이가 어느 수준에 이르는지 예측하는 건 불가능에 가깝고요. 한두 개의 디펜던시만을 가지고 프로젝트를 구축할 계획을 세운다고 한다해도, 나중에 완성본을 놓고 보면 수백 개의 디펜던시가 종종 발견되기도 합니다. 디펜던시의 수를 정확히 확인할 수 있는 방법이 따로 존재하는 것도 아닙니다.” 얄론의 설명이다.
예를 들어 유명 오픈소스 중에 이벤트 스트림(Event-stream)이라는 것이 있다. 한 개인이 공개하고 유지하는 프로젝트다. NPM이라고 하는 인기 패키지 관리자를 통해 배포됐다. 하지만 누군가 이 소스 안에 공격용 코드를 삽입하는 데 성공했다. “이벤트 스트림의 개발자는 1인으로, 유지보수를 충실히 할 수 있는 시간이 없었습니다. 악성 행위자가 그런 걸 파악하고 ‘내가 관리하겠다’며 그에게 접근했고, 공격 코드를 삽입할 수 있었던 겁니다.”
공격자가 삽입한 건 특정 비트코인 지갑을 중간에서 가로채는 기능을 가진 코드였다. 무료이기 때문에 사방으로 빠르게 확산하던 이벤트 스트림과 함께 이 코드도 같이 퍼져갔다. “공격 코드가 다운로드 된 회수는 1주일에 150만번이었습니다. 1600여개의 패키지들에도 이 이벤트 스트림이 삽입되어 퍼졌고, 이 패키지들 역시 일주일에 수백만 번씩 다운로드 되거나 사용됐습니다. 걷잡을 수 없이 코드가 퍼진 것이죠.”
침해된 오픈소스의 파급력을 확인할 수 있는 또 다른 사건이 있다. 2016년 3월 23일, 아저 코쿨루(Azer Koculu)라는 개발자가, 자신이 직접 작성한 모듈 250개를 삭제한 일이 벌어졌다. 이 역시 NPM을 통해 배포되고 있었다. 그런데 이 모듈 중 하나는 11줄의 코드로 작성되었을 정도로 작았다. 텍스트 왼쪽 면에 공간을 추가해주는 모듈로, 이름은 레프트 패드(left-pad)였고, 세계의 수많은 조직들에서 이미 사용되고 있는 중이었다.
오픈소스가 이렇게 갑자기 사라지자 그 수많은 조직들에서 무슨 일이 벌어졌을까? 애플리케이션이나 서비스들이 중단됐다. 물론 치명적으로 작용하지는 않았지만 수천만 명의 사람들이 일대 혼란을 겪어야만 했다. 간단한 기능이었기 때문에 복구하는 데 긴 시간이 걸리진 않았지만, 작은 오픈소스의 영향력을 확인하기에는 충분했다.
그렇기에 전 세계 공통의 위협
엥은 “오픈소스의 생리와 기술적 요소를 다 알지 않아도 그 위험성을 이해할 수 있다”는 입장이다. “그저 오픈소스가 얼마나 많은 곳에서 사용되고 있다는 것만 알아도 충분하지 않나요? 가트너(Gartner)가 조사한 바에 의하면 95%의 기업들이 오픈소스를 사용하고 있다니 말이죠. 대단히 위태로운 상황이라고 볼 수도 있습니다.”
문제는 방어 방법에 있다. 엥은 “가장 완벽한 방어 방법이 존재합니다. 그건 바로 내부 개발 인력이 코드를 전부 처음부터 쓰는 겁니다. 라이브러리부터 전부 말이죠. 하지만 애자일이나 데브옵스가 점점 확산되는 지금, 가능한 것일까요? 아니라고 봅니다.” 오픈소스는 앞으로 더 많이 쓰이면 쓰였지, 줄어들 가능성은 극히 낮아 보이는 게 현실이다.
그렇다면 오픈소스가 만연한 현 개발 환경에서 코드를 안전하게 보호하려면 어떻게 해야 할까? “먼저는 자기가 고른 라이브러리를 꼼꼼하게 점검해야 합니다. 보안 점검은 물론이고, 애초에 ‘정말로 사용해야만 하는 요소인가?’부터 묻고 또 물어야 합니다. 그러면서 더 많은 사람들에 의해 검증된 것인지도 확인해야 하고요.” 코지의 설명이다.
다음으로는, 사용하기로 한 프로젝트가 현재 활발하게 업데이트 되고 있다는 걸 확인해야 한다. “살아있는 프로젝트만을 사용하라는 것입니다. 그 동안의 내력을 점검해 사용해본 사람들의 반응이 좋았는지, 사고 이력은 없는지, 개발자가 충실하게 업데이트를 하고 있는지 알아봐야 합니다. 오픈소스 코드는 생물과 같아서 잘 보관하지 않으면 금방 상하고 썩습니다. 문제 없는 코드는, 취약점이 없는 것이 아니라 개발자가 시기적절하게 업데이트를 해온 것입니다.”
얄론은 “결국 오픈소스의 문제는 신뢰의 문제”라고 정리한다. “개발자들이 오픈소스를 신뢰하지 않기 시작하면 문제가 확실히 줄어들 것입니다. 아무리 해커들이 오픈소스에 악성 코드를 심고 퍼트려도, 개발자들이 의심하고 확인해서 사용하지 않으면 아무런 소용이 없는 겁니다. 지금에 와서 오픈소스를 사용하지 말라고 하는 건 무리입니다. 대신 조직들마다 오픈소스 사용에 관한 규칙은 있어야 합니다.”
3줄 요약
1. 오픈소스, 너무나 사랑스러워 너무나 만연한 현대 개발자들의 필수품.
2. 그래서 오픈소스에 악성 코드를 살짝만 집어넣어도 빠르고 넓게 퍼짐.
3. 개발자들이 오픈소스를 의심하고 또 의심해야 확산 가능성 줄어듦.
[국제부 문가용 기자(globoan@boannews.com)]
오픈소스는 결국 신뢰의 문제...의심하고 확인한 후 사용하는 문화 퍼져야 안전
[보안뉴스 문가용 기자] 수많은 조직들의 프로젝트에 사용되는 오픈소스 소프트웨어는 커다란 위험 요소로 발전할 가능성이 다분하다. 특히 그 오픈소스를 만든 사람들이나, 그 오픈소스를 활용한 프로젝트에 참여한 사람들은 꽤나 자유롭게 악성 행위를 저지를 수 있다는 주장이 나왔다. 이제 너무나도 편만한 오픈소스들은, 그 편만함 때문에 크나큰 위협이 되어버렸다 보안 전문가들은 말한다.
[이미지 = iclickart]
악의를 품은 자가 어떤 오픈소스 프로젝트에 개입할 수 있게 된다면, 할 수 있는 일이 많아진다. 다만 한계가 없는 건 아니다. “백도어를 심든, 트로이목마로서 오픈소스를 활용하든, 공격을 매우 빠르게 진행하거나 은밀하게 행동을 취해야 합니다. 그래야 최대한 들키지 않고 오랫동안 공격을 진행할 수 있거든요.” 보안 업체 제로데이 컨설팅(Zero Day Consulting)의 브래드 코지(Brad Causey)가 하는 설명이다.
오픈소스 프로젝트의 가장 큰 특징은 가용성과 유연성이다. 그래서 개발자들이 오픈소스를 좋아하는 건데, 이는 해커들도 마찬가지다. “오픈소스를 통해 해킹 공격을 실시하는 건 이미 유명한 수법이죠. 다만 그러한 일이 우리가 인지하는 것보다 훨씬 자주, 편만하게 일어난다는 건 그리 유명하지 않을 겁니다.” 보안 업체 베라코드(Veracode)의 수석 연구 책임자인 크리스 엥(Chris Eng)의 설명이다.
보안 업체 체크막스(Checkmarx)의 보안 연구원인 에란 얄론(Eran Yalon)도 이에 동의한다. “아직도 오픈소스를 통한 해킹이 먼 나라 일로만 여겨지고 있습니다. 지금도 실제 우리 가까이에서 벌어지고 있는데 말이죠. 앞으로도 오픈소스 해킹 전략이 사라질 거라고 보기 힘듭니다.”
오픈소스 프로젝트는 여러 사람이나 조직의 참여로 이뤄지는 게 보통인데, 이 참여자들을 컨트리뷰터(contributor)라고 한다. 각 컨트리뷰터는 동료 컨트리뷰터들의 작업물을 검사하고, 이 과정을 통과해야만 코드가 오픈소스의 일부로서 접수된다. 검사의 난이도는 컨트리뷰터마다 달라진다. 신뢰도가 높고 명망도 높은 인물의 작업물이라면 검사가 그리 엄격하게 이뤄지지 않을 때가 많다. 물론 그 신뢰를 쌓는다는 게 그리 쉬운 일은 아니다.
“예를 들어 유명 리눅스 버전의 컨트리뷰터들의 경우, 직원들도 많고 커뮤니티 참여자들도 많으며, 수정과 패치가 자주 이뤄진 역사를 가지고 있기 때문에 신뢰가 두터운 편에 속합니다. 실제로 리눅스는 오픈소스 프로젝트들 중에서 안전한 편이며, 충분한 감시와 검사를 받는 편입니다.”
하지만 리눅스와 비교도 안 될 만큼 작은 오픈소스 프로젝트의 경우, 신뢰를 그리 크게 받지 못한다. 그만큼 검사를 주기적으로 꼼꼼하게 실시할 자원을 갖추고 있지 못하기 때문이다. 따라서 해커들의 1차 타격을 받는 것도 바로 이러한 ‘소규모 오픈소스 프로젝트’, 라고 코지는 설명한다.
프로젝트의 크기와 디펜던시
“아주 작은 패키지라고 하더라도 대형 패키지의 디펜던시가 될 수 있습니다. 이 디펜던시의 깊이가 어느 수준에 이르는지 예측하는 건 불가능에 가깝고요. 한두 개의 디펜던시만을 가지고 프로젝트를 구축할 계획을 세운다고 한다해도, 나중에 완성본을 놓고 보면 수백 개의 디펜던시가 종종 발견되기도 합니다. 디펜던시의 수를 정확히 확인할 수 있는 방법이 따로 존재하는 것도 아닙니다.” 얄론의 설명이다.
예를 들어 유명 오픈소스 중에 이벤트 스트림(Event-stream)이라는 것이 있다. 한 개인이 공개하고 유지하는 프로젝트다. NPM이라고 하는 인기 패키지 관리자를 통해 배포됐다. 하지만 누군가 이 소스 안에 공격용 코드를 삽입하는 데 성공했다. “이벤트 스트림의 개발자는 1인으로, 유지보수를 충실히 할 수 있는 시간이 없었습니다. 악성 행위자가 그런 걸 파악하고 ‘내가 관리하겠다’며 그에게 접근했고, 공격 코드를 삽입할 수 있었던 겁니다.”
공격자가 삽입한 건 특정 비트코인 지갑을 중간에서 가로채는 기능을 가진 코드였다. 무료이기 때문에 사방으로 빠르게 확산하던 이벤트 스트림과 함께 이 코드도 같이 퍼져갔다. “공격 코드가 다운로드 된 회수는 1주일에 150만번이었습니다. 1600여개의 패키지들에도 이 이벤트 스트림이 삽입되어 퍼졌고, 이 패키지들 역시 일주일에 수백만 번씩 다운로드 되거나 사용됐습니다. 걷잡을 수 없이 코드가 퍼진 것이죠.”
침해된 오픈소스의 파급력을 확인할 수 있는 또 다른 사건이 있다. 2016년 3월 23일, 아저 코쿨루(Azer Koculu)라는 개발자가, 자신이 직접 작성한 모듈 250개를 삭제한 일이 벌어졌다. 이 역시 NPM을 통해 배포되고 있었다. 그런데 이 모듈 중 하나는 11줄의 코드로 작성되었을 정도로 작았다. 텍스트 왼쪽 면에 공간을 추가해주는 모듈로, 이름은 레프트 패드(left-pad)였고, 세계의 수많은 조직들에서 이미 사용되고 있는 중이었다.
오픈소스가 이렇게 갑자기 사라지자 그 수많은 조직들에서 무슨 일이 벌어졌을까? 애플리케이션이나 서비스들이 중단됐다. 물론 치명적으로 작용하지는 않았지만 수천만 명의 사람들이 일대 혼란을 겪어야만 했다. 간단한 기능이었기 때문에 복구하는 데 긴 시간이 걸리진 않았지만, 작은 오픈소스의 영향력을 확인하기에는 충분했다.
그렇기에 전 세계 공통의 위협
엥은 “오픈소스의 생리와 기술적 요소를 다 알지 않아도 그 위험성을 이해할 수 있다”는 입장이다. “그저 오픈소스가 얼마나 많은 곳에서 사용되고 있다는 것만 알아도 충분하지 않나요? 가트너(Gartner)가 조사한 바에 의하면 95%의 기업들이 오픈소스를 사용하고 있다니 말이죠. 대단히 위태로운 상황이라고 볼 수도 있습니다.”
문제는 방어 방법에 있다. 엥은 “가장 완벽한 방어 방법이 존재합니다. 그건 바로 내부 개발 인력이 코드를 전부 처음부터 쓰는 겁니다. 라이브러리부터 전부 말이죠. 하지만 애자일이나 데브옵스가 점점 확산되는 지금, 가능한 것일까요? 아니라고 봅니다.” 오픈소스는 앞으로 더 많이 쓰이면 쓰였지, 줄어들 가능성은 극히 낮아 보이는 게 현실이다.
그렇다면 오픈소스가 만연한 현 개발 환경에서 코드를 안전하게 보호하려면 어떻게 해야 할까? “먼저는 자기가 고른 라이브러리를 꼼꼼하게 점검해야 합니다. 보안 점검은 물론이고, 애초에 ‘정말로 사용해야만 하는 요소인가?’부터 묻고 또 물어야 합니다. 그러면서 더 많은 사람들에 의해 검증된 것인지도 확인해야 하고요.” 코지의 설명이다.
다음으로는, 사용하기로 한 프로젝트가 현재 활발하게 업데이트 되고 있다는 걸 확인해야 한다. “살아있는 프로젝트만을 사용하라는 것입니다. 그 동안의 내력을 점검해 사용해본 사람들의 반응이 좋았는지, 사고 이력은 없는지, 개발자가 충실하게 업데이트를 하고 있는지 알아봐야 합니다. 오픈소스 코드는 생물과 같아서 잘 보관하지 않으면 금방 상하고 썩습니다. 문제 없는 코드는, 취약점이 없는 것이 아니라 개발자가 시기적절하게 업데이트를 해온 것입니다.”
얄론은 “결국 오픈소스의 문제는 신뢰의 문제”라고 정리한다. “개발자들이 오픈소스를 신뢰하지 않기 시작하면 문제가 확실히 줄어들 것입니다. 아무리 해커들이 오픈소스에 악성 코드를 심고 퍼트려도, 개발자들이 의심하고 확인해서 사용하지 않으면 아무런 소용이 없는 겁니다. 지금에 와서 오픈소스를 사용하지 말라고 하는 건 무리입니다. 대신 조직들마다 오픈소스 사용에 관한 규칙은 있어야 합니다.”
3줄 요약
1. 오픈소스, 너무나 사랑스러워 너무나 만연한 현대 개발자들의 필수품.
2. 그래서 오픈소스에 악성 코드를 살짝만 집어넣어도 빠르고 넓게 퍼짐.
3. 개발자들이 오픈소스를 의심하고 또 의심해야 확산 가능성 줄어듦.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
