'보안 위협' vs. ‘권리'··· SW 소스 검열 ‘논란'

최근 러시아 정부가 소프트웨어를 납품하는 미국 업체에 소스 코드를 검열하겠다고 나서 논란이 되고 있다. 일부 보안 전문가가 심각한 보안 위협이 될 수 있다고 주장하는 가운데, 반론도 만만치 않다. 경쟁 관계에 있는 국가와 소스 코드를 공유하면 보안 허점이 노출될 가능성이 커지지만 소스코드가 모든 문을 다 열 수 있는 '만능 열쇠’는 아니라는 것이다.



미국과 러시아 양국의 사이버스파이 신경전이 한껏 고조된 가운데 소스 검열을 둘러싼 논쟁이 격화하고 있다. 전문가들은 미국 소프트웨어에 백도어가 있을 수 있다는 러시아 정부의 우려와 소스 코드 검열 요청은 충분히 가능한 것이라고 말한다.

소스 코드 검열의 안전성 여부를 놓고 벌어진 이러한 논쟁은 지난 10월, HP가 러시아 방위청에 자사의 아크사이트(ArcSight) SIEM(이 소프트웨어는 이후 영국 기업 마이크로 포커스 인터네셔널 Plc가 인수했다) 소스 코드를 제공했다는 사실이 밝혀지면서 시작됐다. 아크사이트 SIEM은 미국 내 기업에서 널리 사용될 뿐만 아니라 미국 펜타곤도 사용하는 것으로 알려져 있다.

이 소식이 전해지자 외국 정부와 소스 코드를 공유하는 것에 대한 ‘분개'의 목소리를 터져 나왔다. 시만텍 CEO 그렉 클라크는 로이터 통신과의 인터뷰에서 “소스 코드는 원칙적으로 기밀이며, (소프트웨어를) 보호하기 위해 필수적인 요소이다. 비밀로 유지하는 것이 가장 좋다”라고 말했다.

그러나 저명한 사이버보안 전문가들은 이러한 찻잔 속 태풍 같은 논란에 의문을 제기한다. 전직 NSA 해커 찰리 밀러는 트위터를 통해 “15년 간 버그 사냥을 해 온 사람으로서, 소스 코드를 안다고 해서 크게 이점이 될 만한 것은 없다”고 잘라말했다. 그는 몇 년 전 지프 체로키 차량의 테스트 해킹 팀에 참여해 성공적인 결과를 이끌어 낸 것으로 유명하다.

DARPA의 사이버 보안 연구 책임자 페이터 자코 역시 “언뜻 생각하면 보안에 위험이 될 것 같지만 그렇지 않다. 소스코드를 분석해서 찾아낼 수 있는 버그보다 바이너리와 퍼징(fuzzing)을 통해 찾아내는 버그가 훨씬 많다”라며 밀러의 말에 동의했다. 물론 소스코드를 알면 소프트웨어의 취약점을 찾기 더 쉬울 수 있다. 또 개발자가 간혹 코드에 “나중에 마저 완성할 것” 같은 코멘트를 달아놓기도 하는데 이러한 부분도 공격자에게 힌트가 된다. 

그렇지만 최종적인 결과는 소스 코드를 컴파일 한 후에야 알 수 있다는 것이 애플리케이션 보안 전문가의 공통된 지적이다. 소스코드에서는 커 보였던 보안상의 허점이 컴파일된 바이너리에서는 사라지는 경우가 있고, 때로는 컴파일 과정에서 전에는 없었던 새로운 취약점이 생겨나기도 한다는 것이다. 결국 애플리케이션 보안(appsec) 전문가 사이에서 소스 코드 리뷰는 보안상의 허점을 찾아낼 때 그다지 크거나 중요한 부분은 아닌 셈이다. 오히려 퍼징이 중요해지는 부분도 바로 여기다.

퍼징이란?
소프트웨어 테스트 기법인 퍼징은 예기치 못한 에러나 충돌을 일으키기 위해 컴퓨터 프로그램에 무작위 데이터를 주입하는 방식이다. 이렇게 발생한 예기치 못한 에러를 분석해 보안 허점을 찾는 것이 기본 개념이다. 퍼징은 자동화가 가능하므로 공격자는 소스 코드를 보지 않아도 복잡한 소프트웨어를 상대로 매우 효과적인 공격을 펼칠 수 있다.

뉴스타(Neustar)의 보안 연구 디렉터 브라이언 노프는 “소스코드를 보는 것보다 퍼징이 훨씬 더 만족스러운 결과를 가져다 준다. 제로 데이 공격을 발견하는 것 역시 코드 분석이 아니라 퍼징을 통해서다. 퍼징은 싱크대에 접시며 음식물이며 쓰레기까지 모든 것을 다 집어 넣은 후(컴파일된 바이너리) 거기서 생겨나서는 안 될 결과물이 생겨나는지를 지켜보는 방식이다”라고 말했다.

따라서 애플리케이션 보안 연구를 하기 위해 소스 코드는 크게 필요하지 않다. 외국 정부에서 소스코드 없이 미국 소프트웨어를 구매했다고 해도 열이면 열 반드시 이를 실제 환경에 배포하기 전에 퍼징 과정을 거친다는 것이 전문가의 지적이다. IO액티브(IOActive)의 자문 서비스 디렉터 대니얼 마이슬러는 “소스코드는 애플리케이션이 어떤 모습으로 만들어질 것인지 일종의 가능성을 보는 것이다. 반면 퍼징, 특히 애플리케이션 퍼징은 실제 애플리케이션이 현실 세계에서 어떤 모습으로 구현되는가를 본다”라고 말했다.

이 때문에 퍼징은 “바보 과학(dumb science)”이라는 별명을 얻기도 했다. 오늘날 온라인에는 누구나 쉽게 다운로드 해 사용할 수 있는 강력한 퍼징 툴이 많다. 대표적인 것이 버프수트(BurpSuite)와 와피티(Wapiti)다. 둘 모두 웹 취약성 스캐너 툴이다. 또 피치(Peach), 스파이크(SPIKE), 설리(Sulley)처럼 확장형 퍼징 프레임워크도 있다. 스케이피(Scapy)같은 네트워크 레벨 프로토콜 퍼저나, 아메리칸 퍼지 랍(American fuzzy lop)도 빼놓을 수 없다.

그러나 충분한 인력과 예산을 갖춘 정부 기관은 단순히 소프트웨어를 퍼징하는 데서 그치지 않는다. 더 나아가 리버스 엔지니어링을 시도한다.


미션 크리티컬 소프트웨어의 리버스 엔지니어링
콜롬비아 대학교 교수 스티븐 벨로빈에 따르면, 리버스 엔지니어링은 작은 나라의 정부도 충분히 할 수 있는 아주 효과적인 보안 리서치 툴이다. 그는 "소스 코드가 없어도 리버스 엔지니어링을 하면 그만이다. 이미 시중에는 성능이 뛰어는 리버스 엔지니어링 툴이 다양하게 나와 있고, 컴파일된 코드를 이해하기 위한 다양한 테크닉이 존재한다”고 말했다.

리버스 엔지니어링에는 컴파일된 바이너리가 필요하며, 그 이름에서 짐작할 수 있듯 이러한 컴파일 프로세스를 역으로 되짚어 소스 코드를 찾아낸다. 물론 이렇게 찾아낸 소스 코드는 뒤죽박죽 섞여 있어 이해하기 어렵지만 그래도 소스 코드임에는 분명하다. 악성코드 연구자나 안티바이러스 솔루션 업체도 리버스 엔지니어링을 많이 하는데, 바이러스가 소스 코드를 훤히 보여주며 침입하지는 않기 때문이다.

FLARE(FireEye Labs Advanced Reverse Engineering) 팀의 디렉터이자 ‘실용적 악성코드 분석(Practical Malware Analysis)’의 저자이기도 한 마이클 시콜스키도 이에 동의한다. 그는 “악성코드를 리버스 엔지니어링 한다는 것은 ‘과연 이 악성코드가 어떤 기능을 하는가’ 묻는 것과 같다. 그리고 이는 상업용 소프트웨어도 마찬가지다. 그 소프트웨어의 기능이 무엇인지 알아내고, 그 취약점을 발견하려면 리버스 엔지니어링을 하면 된다”라고 말했다.

이어 “물론 외국 정부에 소스코드를 노출하지 않을 수 있다면 그것이 가장 좋다. 그러나 (HPE나 시만텍 혹은 기타 미국의 IT 업체의) 보안 수준이 크리티컬한 단계 혹은 최소한 중간 단계만 된다고 해도, (해당 외국 정부 기관은) 퍼징을 시도할 것이 확실하다. 정적 분석만으로 제로데이 같은 ‘홈런’을 칠 수는 없기 때문이다”라고 덧붙였다(보안 취약점은 그 심각도에 따라 크리티컬(가장 위험한 단계)에서부터 고(high), 중(medium), 저(low)로 나뉜다. 정적 분석이란 대개 자동화된 소스 코드 리뷰를 의미한다).

소스 코드 요청, 어찌 보면 당연하다
전문가들은 제로 데이 외에도 소스 코드 검열을 요청할 이유는 다양하다고 지적한다. 시콜스키는 "외국 정부의 소프트웨어 소스 코드 검열 요청은 상당한 주의 의무(due diligence)를 다하고자 하는 것으로 보인다. 실제로 우리 고객사인 미국 기업으로부터 종종 “특정 국가로부터 대규모 솔루션을 도입하려 하는데 소프트웨어에 백도어가 있는지 확인해 달라”는 요청을 받는다. 이때 가능하다면 소스 코드를 ‘정중하게' 요청할 것 같다. 기업간 거래도 이 정도인데, 외국 정부 입장에서 소스 코드를 요청하는 것이 무리하다고 볼 수는 없다”라고 말했다.

벨로빈은 최근 외국 정부와 소스 코드를 공유하는 것을 둘러싸고 발생한 논쟁이 사실은 보안이 아니라 지적 재산권(IP)을 둘러싼 문제라고 지적했다. 그는 “만일 내가 시만텍(또는 다른 미국 IT 업체) 관계자라면 지적 재산 절도 문제에 더 민감하게 반응할 것이다. 러시아의 연방 보안국(FSB)이 보안 취약점을 찾는 것이 목적이라면, 소스코드가 있든 없든 이를 시도할 것이기 때문이다”라고 말했다. ciokr@idg.co.kr