소프트웨어 결함 공개, 쉽지 않은 일

대학원생인 크로스토퍼 소고이안(Christopher Soghoian)은 자주 논쟁에 휘말린다.

작년에 그는 시스템의 약점을 이용해 항공기 탑승권을 인쇄하는 코드를 공개해 연방 항공청, 교통 보안청 및 국토안보부를 크게 당황하게 만들면서 명성을 얻었다. 그 다음에 그는 인디애나 대학교의 피싱 스캠을 공개하고 아메리카 은행의 주요 사이트 인증 시스템을 이용해 맨-인-더-미들 공격을 할 수 있음을 밝혔다.

바로 지난 주, 소고이안은 파이어폭스 브라우저에서 사용하는 일부 인기 있는 확장 기능에 영향을 주는 완전히 새로운 취약점을 밝히는 소식을 공개했다.

수백만명이 사용하는 시스템에 구멍을 내는 것이 재미있는 것으로 보일지 모르지만, 취약점을 공개하는 과정에는 많은 위험이 도사리고 있는 것이 보통이다.

최근에 전용 코드를 리버스 엔지니어링했다는 이유로 디지털 밀레니엄 저작권법(DMCA)을 위반했다고 연구자들을 고소한 회사들이 있었기 때문이다. 이에 대응해, 일부 연구자들은 벤더들에게 통지하기에 앞서 취약점을 공개 메일링 리스트에 게시하기 시작했다.

어떤 사람들은 벤더와 연구자들 사이에서 취약점 공개를 조절하는 역할을 하는 독립적인 단체들의 뒤에 숨으려고 한다. 또, 어떤 사람들은 발견한 내용은 아이디펜스(iDefense)와 같은 보안 회사들에게 팔아 먹는다. 아이디펜스가 모든 위험 부담을 감수하고 벤더와 협력해 취약점을 직접 처리하게 하는 것이다.

파이어폭스 결함의 경우, 소고이안은 관련된 벤더에게 직접 연락하기로 선택하고 공개하기 전에 문제를 해결할 기회를 각각 45일간 주기로 결정했다. CNET은 소고이안에게 보안 취약점을 보고하는 복잡미묘한 과정 및 허용한 기한이 끝나면 달라지는 점에 대해 물어보았다.

당신이 보고한 취약점은 파이어폭스 브라우저 자체가 아니라 모질라에서 통제하지 않는 확장 서버에 있는 것이다. 이 취약점을 어떻게 발견하게 되었는가? 직감으로 알아낸 것인가?

이 경우 기본적으로 직감에 따른 것이라고 할 수 있다. 처음에는 파이어폭스를 로드하면 어떤 일이 진행되는가를 보려고 했을 뿐이었다. 파이어폭스가 홈을 호출해 개인 정보 또는 그와 비슷한 어떤 것을 드러나게 만들지 모른다는 의심을 했었기 때문이다.

그래서 그냥 파이어폭스가 무슨 일을 하고 있는지, 그리고 시작할 때 누구와 대화를 하는지 알고 싶었다. 따라서 그냥 브라우저를 시작하고 브라우저와 인터넷 상의 어딘가와 이루어지는 정보 교환을 관찰했다.

필자에게 있는 확장 기능의 경우 모질라가 실행하는 다양한 서버로 연결되는 SSL(Secure Socket Layer) 연결을 몇 개 사용했다. 하지만 그 외의 확장 기능의 경우 구글이나 그 외의 회사들로 나가는 일반 텍스트 요청이 무수하게 많이 있었다. 그런 요청은 의도가 뻔한 것이었다. 그런 요청은 정보를 보내는 것이 아니라 정보를 다운로드하는 것이었다.

게다가 업데이트를 다운로드하고 있었으므로 훨씬 더 큰 문제였다. 그것을 네트워크 스니퍼로 지켜보다가 약 두 시간 후에 필자는 실행이 가능한 익스플로잇을 만들었다. 따라서 직감으로 떠오른 것을 실행이 가능한 코드로 만드는 데는 거의 시간이 걸리지 않았다.

지금 말하는 것은 브라우저에서 인터넷 상의 암호화되지 않은 서버로 보내는 호출을 가로채는 것을 가리키는 것으로 보인다. 무선 랩톱을 사용한다면 그런 공격이 발생할 가능성이 더 높은가?

반드시 그렇지는 않다. 무선 연결은 공격자가 근처에 있지 않아도 된다는 점 때문에 공격권을 차지하기가 정말, 정말 쉽다. 네트워크의 스위치 환경이 아니라 (LAN) 허브 환경을 사용하고 있다면, 이 공격이 가능하다. 같은 허브에 연결된 사람은 누구나 그렇게 할 수 있다.

무선 라우터든 유선 라우터든 간에 홈 라우터를 사용하는 경우 기본 암호를 변경하지 않았다면, 소위 말하는 드라이브-바이(drive-by) 피싱 공격을 할 수 있다. 즉, 사용자가 악의적인 웹 사이트를 방문할 때 공격자가 라우터 설정을 변경할 수 있다. 그런 경우에도 역시 공격이 가능하다.

누군가가 스타벅스에서 커피를 먹다가 감염된다는 이 시나리오가 가장 일반적인 시나리오이지만, 다른 시나리오도 있다.

한 제품의 보안에 대해 직감적으로 느끼던 것이 있었는데 그것이 사실로 증명되었다고 하자. 그리고, 익스플로잇을 만들어서 시연할 수도 있다고 하자. 그 다음에 어떻게 해야 하는가?

할 수 있는 일은 많다. 어쩌면 자신의 사고방식에 따라 결정된다고 할 수 있다. 예를 들면, 책임 공개 주의와 완전 공개 주의가 있다. 완전 공개 주의를 지지한다면 그 정보를 공개하고 아마도 처음부터 메일링 리스트에 기능 검증(Proof-of-Concept) 익스플로잇을 올리고 자신의 이름도 밝힐 것이다.

당신은 그렇게 하지 않았지 않는가?

나는 대부분의 경우 그런 방식에 동의하지 않는다. 작년에 내가 관련되었던 항공기 탑승권 문제의 경우 익스플로잇이 3년 동안이나 알려졌었는데도 무시되었었다. 하지만, 벤더에게도 최소한 공정한 기회는 주어야 한다고 생각한다.

수백만명의 사용자들이 위험에 처할 가능성이 있는 소프트웨어의 경우에는 특히 그렇다. 나는 벤더들에게 문제를 바로잡을 기회를 줄 책임이 있다고 느낀다.

하지만 우리가 그들에게 줄 수 있는 시간은 별로 많지 않다. 나는 이번 사건에서 구글과 야후가 문제를 시정할 시간을 45일이나 주었는데 그들은 그 기한 내에 문제를 해결하지 못했다. 그 후에 문제가 공개되자, 서두르기 시작했다. 일단 공개되었으므로, 그것을 시정해야 할 강력한 인센티브가 생긴 것이 분명했다. 어쨌든 창피할 테니까 말이다.

하지만 적어도 내 마음이 편하기 위해서도 나는 그 사실이 공개된 후에 비난을 받을 때 할말을 남기기 위해 벤더에게 경고를 하고 싶었다. 적어도 내가 올바른 일을 했다고 주장할 수 있어야 하지 않겠는가!

왜 45일인가? 그 숫자를 무작위로 선택하지는 않았을 것 아닌가?

(카네기 멜론 대학교)에서 운영하는 보안 단체인 CERT에 45일 기한이 있다. 내가 볼 때 그 정도 기간이 적당한 것 같다. 책임 공개의 다른 부정적인 점 중 하나는 다른 누군가가 동시에 그 공격을 당하게 될 수 있다는 점이다.

이번에도, 몇몇 다른 사람들이 지난 몇 주 이내에 해결 방법을 찾아내고 그들도 공개할 준비를 한 후에 (내가 공개)한 것이다. 따라서 더 많이 기다릴수록 누군가가 당신의 천둥을 훔쳐가려고 할 가능성이 높아진다.

그렇다면, 그 부담은 전적으로 연구자가 지는 것이 아닌가? 취약점을 찾아내면 책임감을 가지고 행동해야 할 뿐만 아니라, 동시에 다른 사람들이 그 동안 그것을 악용할 위험까지 감수해야 한다는 이야기가 된다. 그렇다면, 취약점을 찾아내면 신고할 곳이 있어야 하지 않겠는가?

CERT에 알려주어도 되고, 수입을 올리고 싶다면 아이디펜스에 알려도 된다. 그러면 그들이 그 일을 떠맡을 것이다. 익스플로잇을 5만달러에 미국 정부 기관에 판매한 사람에 대해 학술지에서 읽은 적이 있다. 그 경우 미국 정부는 누구에 대해서도 누설하지 않고, 내부 기밀로 유지했다. 하지만 할 수 있는 일은 많다.

이번 경우, 나는 회사와 우호적인 관계를 유지하고 싶었다. 작년에 구글에서 일했었는데, 구글이 내 은행 계좌에 넣어준 돈으로 세계 여행을 다녔다. 그래서 그들을 존중심을 가지고 대해야 한다는 책임감을 어느 정도 느꼈다. 따라서 나는 CERT에 정보를 주거나 공개된 시장에서 판매하는 대신 벤더와 직접 접촉하기로 선택했다.

물론, 이렇게 되자 훨씬 더 많은 일을 해야 했고, 직접 협상을 해야 했다.

관련된 위험부담도 어느 정도 있다. 몇 년 전에 시스코와 함께 어떤 성분을 발견한 마이크 린(Mike Lynn)의 경우가 있고, 블랙보드 학술용 소프트웨어에서 몇 가지 취약점을 발견한 두 명의 연구자의 경우와 작년에 애플 무선 장치 드라이버에서 사소한 문제들을 찾아낸 연구자들의 경우가 있었다.

연구자들이 직접 공개를 하기로 결정하고 벤더에게 사전에 통지하면, 위험해 질 수 있다. 걸핏하면 싸우려고 덤비는 회사들이 보여주는 첫 번째 반응은 대체로 연구자를 조용하게 만들기 위해 고소하는 것이기 때문이다.

책임 공개 방식을 따르는 경우, 항상 위험을 감수해야 한다. 회사는 당신의 이름을 알고 있고 변호사들을 시켜 당신을 공격할 수 있기 때문이다. 나의 경우에는 유럽에 있을 것이므로 사소한 소송이 겁나지 않는다고 생각할 수 있지만, 항상 위험 부담은 있다.

연구자들을 고발해 유명해진 애플을 위해 무언가를 하고 있다면, 그리고 더욱 가능성이 높은 것으로 책임 공개 방식을 따를 예정이라면, 불행하게도 그 일을 익명으로 하는 것이 좋을 것이다.

회사들은 종종 리버스 엔지니어링이 DMCA를 위반하는 것이라고 주장한다. 맞는가?

그들은 DMCA를 목적을 달성하기 위한 수단으로 사용한다. 한 마디로 말해서 그들이 하려고 하는 것은 연구자를 조용하게 만드는 것이다. DMCA는 그렇게 하는 수단일 뿐이다. DMAC가 존재하지 않는다면, 컴퓨터 사기 및 남용 금지법과 같은 무언가 다른 규정을 들먹일 것이다.

DMCA는 기본적으로 누구든 암호화 알고리즘을 사용하도록 허용하며, 그 알고리즘이 아무리 허약하다 해도 저작권이 있는 무언가를 보호하는 역할을 하는 경우 그것을 리버스 엔지니어링하는 사람은 누구나 이론적으로 법을 위반하는 것이 된다. 이론상으로는 과자 상자에 들어 있는 코드에도 DMCA를 적용할 수 있다. 그 법을 인정해야 하지만, 그 법이 산업계에 많은 존경을 받고 있다고는 생각하지 않는다.

이 파이어폭스 확장 기능 취약점을 공개하면서 택한 행로가 효과가 있다고 생각하는가? 이런 방식을 다시 택할 것인가?

CERT에 알리거나 공개된 시장에서 판매하는 것에 비해 취약점 공개를 조절하는 것이 분명히 해야 할 일이 더 많았다. 특히 구글이 비협조적이었다는 점이 나에게는 문제였다.

그들에게 메일을 대여섯 번 보냈는데, 30일 동안 아무 회신도 받지 못했다. 이것은 연구자에게는 정말 짜증나는 일이다. 올바른 일을 하려고 하는 연구자가 듣고 싶어하는 것은 현재 작업 중이다. 곧 답을 주겠다라는 말 뿐이다.

그들이 죽지 않았고 관련된 작업을 하고 있음을 알 수 있으려면 심장 박동 소리 같은 것을 들어야 하기 때문이다. 그리고 단순히 나를 피한다는 느낌을 받는 것을 원하는 사람은 없다.

따라서 회사들이 당신의 이메일에 전혀 응답하지 않는다면 정말 짜증나는 일이다. 그렇게 되면 자꾸 생각하게 되고, 다음 번에 그들에게 가고 싶은 마음이 사라지게 된다. 더군다나 아이디펜스는 이메일로 답신을 보내 주고 우편으로 진짜 수표도 보내줄 것이라는 사실을 알고 있기 때문이다.

나는 이제 막 컴퓨터 보안 박사가 되었기 때문에 앞으로 다른 취약점도 찾아낼 것이다. 하지만, 이것이 애플의 취약점이었다면, 나에겐 기회가 없었을 것이다. 애플은 틀림없이 나를 고소했을 것이기 때문이다. 구글은 상황에 대응하는 면에서 보안 커뮤니티에서 평판이 아주 좋다.

하지만 현재까지 대부분의 문제는 공개가 된 문제였고, 구글은 하루나 이틀 안에 문제를 해결하느라고 허둥댔다. 책임 공개 방식에 대한 구글의 반응에 대해 별로 알려진게 없다. 따라서 이번 경험으로 눈이 뜨였다고 할 수 있다.

일부 벤더는 응답하지 않았다.

다른 종류의 책임 공개 방식도 나와 있다. 그것은 연구자들에게 상당히 존중을 받는 것이다. 소위 RFP 정책이라고 한다. 그리고 이것은 벤더가 보안 연구자와 5일 간격으로 이메일로 연락을 해야 하며, 그렇게 하지 않으면 즉시 공개하게 된다고 규정한다.

그건 다소 거칠다고 생각했기 때문에 나는 그런 식으로 진행되는 것을 원하지 않았다. 하지만, 다음 번에 처음에 공개 이메일을 보내게 된다면 5일 간격으로 소식을 듣지 못하면 공개할 것이라고 말하게 될 것으로 생각한다.

이번 경우는 내가 처음으로 취약점을 공개하는 것이다. 내가 무엇을 하고 있는지 정말 몰랐기 때문에 진행하면서 배워야 했다. 다음번에는 규칙이 무엇인지, 그리고 정보를 교환하지 않으면 어떻게 되는지 훨씬 더 명확해질 것이라고 생각한다.

하지만 사실은 회사들이 연구자들이 처음부터 그것을 공개하거나 공개된 시장에서 팔아먹지 않고 회사를 찾아오기를 원한다면 가능한 한 그렇게 하기 쉽게 만들어야 하며 연구자들이 그렇게 하고 싶은 마음을 가지게 해야 한다고 느낀다. 그렇다고 대대적으로 환영해달라는 이야기하는 것이 아니다.

우리가 그들에게 서비스, 그것도 많은 경우 무료 서비스를 하고 있다는 사실을 감안하면 적어도 합리적이 되어 우리의 이메일에 응답은 해야 하지 않겠는가?

당신이 공개한 지 이틀이 지났다. 그 동안에 벤더의 연락을 받았는가?

받았다. 일부는 예상 못한 곳에서 온 것이었다. 야후의 자회사인 Del.icio.us는 나의 블로그와 다른 몇몇 언론인들의 블로그에 내가 공개하기 전에 실제로 문제를 해결했음을 알리는 글을 남겼다. 어쨌든 그 뉴스는 야후 보안 팀을 거쳤고 Del.icio.us의 직원들은 제시간에 패치를 해 바로잡았기 때문에 실제로 내가 공개한 날에는 취약하지 않은 상태였다.

구글은 문제를 해결하려고 노력했다. 그들은 시스템의 일부는 패치했지만, 아직까지 공격에 노출된 상태이다. 어제 밤 새벽 1시까지 모든 것을 수정하지 못했기 때문에 사용자들은 아직도 취약하다. 그 중에는 내가 생각하기에는 많은 정보가 공개되고 있는 것으로 보이는 새로 나온 구글 기어스 확장 기능이 포함된다.

전체 구글 계열 확장 기능이 아직 취약하다. 야후는 오늘(6월 1일 금요일) 이메일로 나에게 조만간 문제를 시정할 것으로 예상된다고 말했지만, 그들은 업데이트를 호스팅하기에 충분한 시스템을 찾아내느라 정신이 없다. 일반 HTTP에서 SSL 방식 웹 서버로 전환할 때(매일 약 2~300만명의 고객이 조회를 한다고 생각해 보라) CPU가 훨씬 더 많이 필요하기 때문이다.

따라서 그들이 전에 그런 업데이트를 처리하는 백 대의 시스템을 갖추고 있었다면, 지금은 2~300대의 시스템이 필요할 것이다. 따라서 필요한 CPU 파워가 실제로 증가하게 된다. 현재 야후가 그것을 처리할 충분한 시스템을 찾아내느라 허둥대고 있다고 확신한다. 하지만, 그 외의 벤더에게서는 소식을 전혀 듣지 못했다.

패치하는 데 더 많은 CPU가 필요하다는 점이 일부 벤더가 연락을 하지 않은 이유가 아닐까?

우리가 여기서 살펴본 대부분의 회사들은 수백만달러 규모의 회사이다. AOL이나 애플 또는 애스크닷컴(Ask.com)이 몇 대의 추가 시스템을 구입할 돈이 없을 것이라고 생각하지 않는다. 그런 비용을 부담할 수 없는 회사들의 경우, 원한다면 언제든지 모질라의 확장 기능 서버를 사용할 수 있다.

(수백만달러 규모의 회사들이) 이렇게 혼란에 빠져 허둥대는 것은 사용자들이 그들에게서 직접 자료를 다운로드받기를 원했기 때문이다. 그들은 그 과정을 완벽하게 지켜보기를 원했고, 다운로드와 그 외의 모든 것을 모니터할 수 있기를 원했기 때문에, 지금 그 대가를 치르고 있는 것이다.

그것이 그들에게 너무 힘들다고 결정을 한다면, 그들은 항상 모질라 서버를 사용하는 것으로 돌아갈 수 있다.

다소 복잡한 것은 확장 기능을 모질라에 호스팅하는데는 세부 조건이 있으며 업데이트 요청 기능을 정지시켜서는 안된다는 점 밖에 없다.

만일 확장 기능을 모질라 서버에서 호스팅하게 하면, 확장 기능을 업데이트할 때 사용자에게 알려야 한다. 특히 구글은 확장 기능 업데이트 통지 기능을 정지시켰기 때문에 사용자에게 단 한 마디 말도 하지 않고 확장 기능이 은밀하게 다운로드할 수 있다. 그런 식으로 행동하게 되면 모질라 서버를 버리는 것이 될 것이다.

구글이 그렇게 하는 이유가 있는가?

많은 이유가 있다. 사람들은 업데이트하기로 선택할 필요가 없을 때 업데이트를 할 가능성이 커진다. 보안상의 관점에서 보면, 사람들이 최신 코드를 실행하게 하는 것은 아마 좋은 생각이겠지만, 업데이트 프로세스 자체가 취약한 경우 그렇게 하면 사람들이 많은 위험에 노출되게 된다. 바로 그 부분에서 어떤 사람이 내린 경영상의 결정이 잘못된 것이었다. @