침해사고 대응을 위해 보안 취약점 발굴이 필수!

[CCTV뉴스=이승윤 기자] 과거부터 극소수의 보안 전문가에 의해서 다뤄졌던 소프트웨어 대상 보안 취약점 발굴 작업은 최근 폭발적인 소프트웨어의 증가와 발전에 따라 대량으로 발굴이 이뤄져야 하는 필요성이 부각되고 있다. 이에 수작업으로 진행되던 은밀했던 발굴 방법이 다수에 의해 공개적으로 연구되고 있으며, 수많은 소프트웨어를 대상으로 발굴 자동화가 이어지고 있는 추세이다.

글 아이넷캅 | 유동훈 기술이사

최근에는 특정 환경에서 제한적이지만, 취약하게 작성된 소프트웨어를 대상으로 사람이 아닌 기계가 자동으로 보안 취약점을 발굴하고 공격하는 해킹 대회까지 진행되고 있다. 이번 글에서는 이처럼 변화되고 있는 보안 취약점의 발굴 방법과 그 현황에 대해 다루고자 한다. 나아가 보안 취약점에 대응하기 위해 기술적인 내용과 정책적인 내용에 대해서도 다룰 예정이다.

보안 취약점 발굴을 위한 소프트웨어 점검 방법

우선 보안 취약점 발굴을 위한 소프트웨어 점검과 시험 방법은 일반적인 소프트웨어 시험과 상당히 많은 개념을 공유하고 있기 때문에 닮아 있는 것이 사실이다. 하지만, 일반적인 소프트웨어 테스트의 경우 소프트웨어가 의도하지 않은 기능 동작을 야기하는 모든 경우의 수를 결함이나 버그로 해석하지만, 보안 취약점 발굴을 위한 테스트의 경우에는 해당 버그나 결함이 메모리의 주요 정보 유출과 프로세스 흐름 변화를 일으키는 등의 보안 위반 행위를 유발하는지 여부를 유심히 보는 차이점이 있다.

소프트웨어의 보안 취약점을 발굴하는 방법은 소프트웨어를 점검하는 환경이나 종류에 차이점이 있는데 크게 화이트박스 기반 검사와 블랙박스 기반 검사 방법으로 구분하는 것이 일반적이다. 두 가지 점검 방법 모두 보안 취약점을 효과적으로 발굴하는 것을 궁극적인 목표로 하고 있지만, 소프트웨어를 코드 관점에서 점검 또는 코드에 대한 분석과 이해 과정 없이 보안 취약점 발굴을 시도하는지 여부에 따라 각기 다른 검사 방법의 차이를 구분할 수 있다.

화이트박스 기반 점검 방법

일반적으로 화이트박스 기반 점검 방법은 소스 코드가 주어진 소프트웨어를 점검하는 방법을 의미한다. 주로 점검 대상 소프트웨어의 코드가 공개돼 있는 오픈소스나 코드 제공이 가능한 벤더 제품을 점검할 때 이용된다. 이런 소스 코드 감사(Auditing) 방법은 단순 프로그래밍 오류인 버그부터 구현 오류인 설계 결함을 검출하는데 매우 유용하다. 소스코드 감사 방법은 선택방식에 따라서 장시간이 소요되기도 하고 반대로 단시간 내에 수행할 수 있는 자동 점검도 존재한다.

먼저 장시간이 소요되는 수동 검사의 경우 분석가가 일일이 수작업으로 주어진 소스 코드를 분석하는 고전적인 방법으로 보안 취약점 유발 원인이나 결과에 대해 보다 명확한 전후 관계 확인이 가능하며 누락되는 지점 없이 전체 기능에 대한 전수 조사가 가능하다는 장점이 있다. 하지만 점검 과정에서 메모리 구조를 추상적으로 파악하거나 구조 이해를 위한 전문적인 지식이 요구되므로 전적으로 분석가의 능력에 의존하게 되는 한계점을 가지고 있다.

빠른 시간 내에 수행할 수 있는 자동 점검의 경우 분석가에 의존하기 보다는 주로 소스 코드 내에 보안 취약점이 존재하는지 자동으로 전수 조사를 수행해주는 정적 감사 도구를 이용한다. 이러한 자동 점검은 단 시간 내에 소프트웨어의 안전성을 검사하는데 수동 점검에 비해 유용한 방식이지만, 기술 특성상 실질적인 위협이 없는 보안 취약점을 포함하는 과탐지가 존재하기 때문에 분석가에 의한 2차 분석을 필요로 하는 단점을 가지고 있다.

블랙박스 기반 점검 방법

블랙박스 점검 방법은 소스 코드가 주어지지 않거나, 바이너리를 코드로 변환하기 어려운 상황에서 소프트웨어를 점검해 보안 취약점을 발굴하는 방법이다. 해당 방법은 주로 소프트웨어에 여러 가지 입력을 넣어 동작하는 반응에 따라 보안 취약점 유무를 파악하기 때문에 분석가가 수작업으로 보안 취약점을 점검하기 보다는 자동화된 결함 주입 도구인 웹 취약점 스캐너와 퍼지 테스트(Fuzzy test)를 이용하는 경우가 많다.

블랙박스 점검 방법은 화이트박스 점검 방법에 비해 소프트웨어 점검 대상이 넓다는 장점이 있다. 대부분의 소프트웨어는 소스 코드 형태가 아닌 바이너리 형태로 배포되기 때문이다. 또한, 필요로 하는 전문 지식 수준이 높지 않아 관련 지식의 비전문가도 누구나 쉽게 시험을 수행할 수 있으며, 화이트박스 점검에 비해 비교적 짧은 시간 내에 점검을 완료할 수 있다는 장점을 가지고 있다. 하지만 해당 점검 방법은 특성상 실질적인 위협이 없는 보안 취약점이 과탐지 될 수 있으며, 검사 시 점검 대상 프로그램에 대한 전수 조사를 수행하기 어려운 한계점을 갖고 있기 때문에 점검 대상 기능과 범위를 넓히기 위한 추가적인 노력이 필요하다.

그레이박스 기반 점검 방법

그레이박스 점검은 화이트박스와 블랙박스 기반 점검이 융합된 형태로 소프트웨어가 소스 코드 형태로 변환 가능한 바이너리 형태 또는 점검 대상에 일부 소스 코드가 포함되는 경우에 주로 이용된다. 그레이박스 기반 점검 방법은 화이트박스 기반 점검과 유사하게 바이너리를 리버싱 하거나 역 컴파일해 사람이 식별할 수 있는 형태의 언어로 번역한 후 점검하는 모든 형태를 포함하는데 역 컴파일러를 이용해 변환된 코드를 얻어서 점검하는 방법도 이에 해당된다.

역 컴파일러는 바이너리가 가진 기계어 코드를 상위 레벨 언어(자바 또는 C언어)로 변환해주는 도구로 조건문과 반복문을 사람이 쉽게 볼 수 있도록 변경해주기 때문에 분석가가 직접 프로그램의 동작 흐름을 따라가면서 점검하기에 유용하다. 그레이박스 기반 점검은 화이트박스와 블랙박스의 장점 모두를 가지기 때문에 점검 시 누락되는 부분 없이 바이너리를 대상으로 전체 기능에 대한 전수 조사가 가능하다. 하지만 시험과 점검 과정 모두 분석가의 전문 지식이 필요하며 각 분야에 대한 깊은 이해도를 필요로 하는 한계점과 점검을 수행하기 전에 진행해야 하는 사전처리 작업에 많은 비용과 시간이 소모되는 단점이 있다.

소프트웨어 결함 주입을 통한 보안 취약점 발굴 방법 동향

보안 취약점 발굴을 위한 결함 주입 도구는 소프트웨어에 올바르지 않은 부적절한 값을 점검 대상 프로그램에 입력해 오류나 결함을 유발시키는 방법을 통해 보안 취약점을 점검하기 때문에 실질적인 위협이 없는 단순 결함을 과 탐지하는 경우가 발생할 수 있다. 소프트웨어 결합 주입 방식은 점검 환경에 따라 크게 네트워크 기반 결함 주입과 호스트 기반 결함 주입으로 구분할 수 있다. 네트워크 기반 결함 주입은 원격 네트워크 노드에 연결된 각 서버들의 결함을 일괄적으로 파악하기 위해 네트워크 스캐닝, 보안 취약점 식별, 결함 주입 단계 과정을 거치는 점검 방법이다. 호스트 기반 결함 주입은 점검 대상 프로그램에 디버깅 툴을 붙이고 입력 값에 따라 동적인 상태 변화를 확인하는 방법으로 이루어지며 점검 대상에 따라 단순 바이너리 동적 검사부터 서비스 동적 검사, 운영체제 커널 동적 검사로 구분할 수 있다. 대표적인 호스트 기반 결함 주입 방법으로 퍼지 테스트 기술이 널리 알려져 있다.

네트워크 기반 결함 주입 기법

네트워크 기반 결함 주입은 과거부터 현재까지 꾸준히 사용되는 기술로 원격 네트워크의 보안 취약점을 점검할 때 주로 쓰인다. 점검 대상은 각종 네트워크 라우터와 스위치, AP(Access Point), 일반 서버부터 웹 서버까지 다양한데, 네트워크 침입탐지시스템과 차단시스템 도입 이후 공격자들이 침입 경로를 바꾸면서 네트워크 전수 조사보다는 웹 서비스상의 결함을 자동으로 점검해주는 도구들이 유행하게 됐다. 최근에는 이런 웹 서비스의 결함 주입에 대응하기 위한 웹 방화벽 제품들이 대거 도입되고 있는 추세이며 일반적인네트워크 기반 결함 주입 과정은 [표2]와 같이 정리할 수 있다.

호스트 기반 결함 주입 기법

호스트 기반 결함 주입은 대부분 퍼지 테스트를 통해 이뤄졌는데 퍼지 테스트(이하 퍼징)는 분석가들이 소프트웨어에 존재하는 버그를 효과적으로 찾아낼 수 있는 보안 취약점 발굴 기술 중 하나로 널리 알려져 있다.

퍼징(Fuzzing)을 통해 보안 취약점을 발견하기 위해서는 우선 통신 시 프로토콜 스택이나 헤더, 특정한 규약과 정해진 데이터 포맷에 비정상적인 데이터를 주입해 동작하는 애플리케이션의 오류를 유발시킨다. 발견된 프로그램 오류들은 실질적인 위협이 없는 단순 결함일 수 있기 때문에 분석가가 추가적으로 위협이 존재하는 보안 취약점인지 분석하는 과정을 필요로 한다.

점검 대상에 따라 단순 바이너리 퍼징부터 데몬 서비스 퍼징, 운영체제 커널 퍼징으로 구분할 수 있다. 퍼징의 유형은 크게 두 가지로 분류할 수 있는데 제너레이션 퍼징(Generation fuzzing)과 뮤테이션 퍼징(Mutation fuzzing)이다. 먼저 제너레이션 퍼징은 포맷에 맞는 신규 데이터를 생성해 애플리케이션에 주입하는 방법으로 예를 들어 동영상 플레이어를 대상으로 퍼징을 수행할 경우 해당 플레이어가 재생할 수 있는 ‘mp4’ 확장자 포맷에 맞게 임의로 데이터를 생성하는 경우이다.

반면 뮤테이션 퍼징은 기존에 존재하는 데이터에 수정을 가해 어플리케이션에 주입하는 방법으로 기존에 존재하는 샘플 ‘mov’ 파일을 기반으로 변조를 수행한 뒤 동영상 플레이어가 해당 파일을 재생하도록 만드는 경우라고 볼 수 있다. 뮤테이션 퍼징을 통한 보안 취약점 발굴 과정은 [표 3]와 같이 정리할 수 있다.

퍼징 기술 한계 극복을 위한 연구

보안 취약점 발굴 시 해결해야 하는 과제 중 하나는 전수 조사 문제이다. 보안 취약점을 점검하고자 하는 코드의 범위가 전체 기능 중 어느 정도의 비율을 차지하는지 여부가 보안 취약점을 찾는데 있어 중요하기 때문이다. 예로 퍼징을 통해 소프트웨어 보안 취약점 발굴 시 퍼징 검사를 수행하는 분석 대상 애플리케이션의 수행코드가 전체 코드 중 매우 적은 부분에 해당된다면, 나머지 수행되지 않는 코드의 보안 취약점을 찾을 수 없고 유발되는 보안 취약점의 개수가 한정적일 수밖에 없다. 이에 대해 보안 분석가들은 코드 커버리지를 측정하는 여러 가지 기술에 대해 연구하고 있으며, 분석 범위를 확장할 수 있는 다양한 방법에 대해서도 연구를 진행하고 있다.

과거에는 주로 퍼징을 수행하는 동안 단순히 얼마나 많은 함수가 호출되었는지 카운팅 하는 방식을 사용했다. 실제 많은 수가 카운팅 되는 경우 더 복잡한 프로그램일 확률이 높으며, 코드 커버리지도 클 것이라고 가정할 수 있기 때문이다. 최근에는 각 프로그램의 명령이 담긴 노드가 얼마나 호출되었는지 정량화해 다양한 코드 실행 경로 중 얼마나 많은 부분이 수행되었는지 코드 커버리지를 측정할 수 있는 다양한 기술들이 등장하였으며, 이 과정에서 대표적으로 오염 분석과 기호 실행 기술이 쓰이고 있다.

오염 분석 기술

대표적인 코드 커버리지 측정을 위한 오염 분석은 어떤 프로그램에 외부 입력이 발생 할 경우, 데이터가 어느 부분에 영향을 미치고 어떤 라이프 사이클을 갖는지 파악해 프로세스 실행 과정을 관찰하고 동작 흐름을 추적하는 기술이다. 이러한 과정을 통해 정확한 코드 커버리지 측정이 가능해 보다 큰 커버리지를 갖는 샘플을 얻을 수 있는 기준을 제공해준다. 하지만 해당 기술은 구체적인 하나의 입력으로 실행된 결과만을 관찰하기 때문에 해당 결과에 대한 실행 경로만을 파악해 더 다양한 실행 경로를 찾는 테스트 샘플 확보만을 도와준다. 즉. 실행 경로가 거치지 않는 곳에 존재하는 보안 취약점은 여전히 발견하기 힘들다는 기술적 한계점이 존재한다.

기호 실행 기술

프로그램의 변수를 심볼로 표현하는 기호 실행은 프로그램의 실행 경로를 전반적으로 살피기 위해 여러 갈래로 분기되는 다양한 케이스를 실행한다는 점에서 오염 분석과 차이를 가지고 있다. 해당 기술은 프로그램 내의 분기 조건을 파악해 어떤 지점에서 각 변수가 어떤 값을 갖는지 파악하고 특정 경로를 실행하기 위해 만족해야 하는 입력 값에 해당하는 경로 조건을 수집한다.

이후 ‘SMT solver’ 프로그램을 통해 수집된 경로 조건에 만족하는 입력을 생성하고 다양한 실행 경로를 추적할 수 있게 된다. 하지만 분기마다 실행 경로를 추적해 모든 경로를 살펴보려면 막대한 시간이 소비되고 ‘SMT solver’가 풀지 못하는 복잡한 경로 조건이 존재하기 때문에 간단한 소프트웨어나 규모가 작은 모듈에 대해서만 분석이 가능하다는 제약을 가지고 있다.