무기체계는 국방과 직결되는 분야로, 공개적인 연구에 많은 어려움이 수반되는 분야이기에 보안 취약점에 대한 관련 연구 분야가 많지 않다. 또한 연구가 존재 하는 경우, 무기체계의 실질적인 보안취약점에 대한 연구가 아닌, 무기체계에 적 용되는 일반적인 구조론적 관점에서 발생하는 보안 취약점에 대한 논의, 무기체 계에 대한 사이버 공격에 의해 발생할 수 있는 현실적인 위험성에 대한 연구가 중점적으로 진행되고 있다. 따라서 본 절에서는 무기체계가 가지는 근본적인 보 안 취약점을 분석하고, 사이버 공격에서 요구되는 기술을 통해 발생할 수 있는 보안 취약점을 소개한다.[29]
1) 무기체계 보안 취약점 분석
(1) 개발 및 운용 환경상의 문제와 대책
개발 및 운용 환경상의 문제는 대상 무기체계의 개발 및 운용 환경에서 사용 하는 운영체제의 보안 취약점으로 인해 해당 무기체계에서 사용하는 소프트웨어 가 보안에 취약해지는 경우이다. Windows/Linux, RTOS 등 운영체제 버전 및 커널의 버전에 따른 공개된 취약점 항목이 존재하며, 취약점이 존재하는 버전의 커널 및 운영체제를 사용할 시 취약점을 이용하여 버퍼 오버플로우, 관리자 권한 획득, 원격코드 실행 등의 해당 무기체계 소프트웨어에 치명적인 공격이 가능하 다. 따라서 개발 및 운용 환경에 구성된 무기체계 소프트웨어 운영체제와 커널의 공개된 취약점, 익스플루잇, 제로데이 취약점에 대해 지속적으로 확인하여야 하 고, 취약점이 발표된 운영체제는 해당 취약점이 해결된 버전으로 업데이트가 반 드시 필요하다. 운영체제 취약점이 발표되어 해결된 버전으로의 업데이트가 필요 한 경우, 현재 개발중인 무기체계 소프트웨어는 개발 환경과 테스트 베드의 운영 체제를 최신 버전으로 업데이트하여야 하고, 개발 완료되어 현재 야전에서 운영 중인 무기체계 소프트웨어는 사용중인 운영체제의 버전을 확인하고 취약점이 해
결된 최신 버전으로 운영체제를 업데이트 해야 한다.
소스코드 컴파일러 취약점은 개발 당시 사용한 컴파일러의 취약점이 발견되어 해당 컴파일러를 사용한 바이너리가 문제가 되는 경우이다. 메모리의 중요 정보 를 사용 후 초기화하였지만, 컴파일러 최적화 옵션으로 인해 초기화가 되지 않는 경우(CWE-14 Compiler Removal of Code to Clear Buffers), 언어나 OS에서 정의된 특별 한 이름을 사용할 경우(CWE-733 Compiler Optimization Removal or Modification of Security-critical Code), Visual Studio의 스택 기반 버퍼 오버런 탐지 기능 추가 등 컴파일러 자체 취약점이 각 버전별로 공개되어 있고, 취약점을 해결한 상위 버전 의 컴파일러가 각 프로그램 언어별로 존재한다.
무기체계 소프트웨어 개발자는 개발 시에 가능한 최신 버전의 컴파일러를 사 용하여 구 버전에 존재하는 컴파일러 취약점을 최소화하도록 개발하여야 하며, 컴파일러 보안 취약점 발표 시 개발 및 전력화된 무기체계의 소스코드를 컴파일 한 컴파일러가 포함되는지 확인하고, 적용 가능한 컴파일러 패치 및 핫픽스를 적 용한다. 이미 전력화된 무기체계 소프트웨어에 취약점이 존재하는 구 버전의 컴 파일러로 컴파일된 바이너리 운용 시, 취약점이 제거된 최신 버전의 컴파일러로 재컴파일한 패치를 무기체계에 신속히 배포하여 최단 시간에 취약점을 제거하여 야 한다. 라이브러리 관련 취약점은 무기체계 소프트웨어 개발 간 사용하는 오픈 소스 라이브러리 등 개발에 필요한 라이브러리에 취약점이 포함되어 있는 경우 이다.
(2) 취약 함수 및 취약한 버전 API 사용
무기체계 개발 간 개발자가 통상적으로 사용하는 함수에서 취약점이 다수 발 생할 수 있다. 특히 strcpy() 등과 같은 메모리 경계를 체크하지 않는 함수로 인 해 Heap Overflow/Stack Overflow 등의 문제가 발생 가능하고, User After Free와 같은 메모리를 할당하고 해지한 후 동일한 사이즈의 메모리를 다시 할당 할 경우 이전에 할당된 영역을 재사용시 원하지 않는 값을 참조할 수 있으며, Double Free 등의 다양한 문제가 발생될 수 있다. 이러한 개발 간의 문제를 예 방하기 위해 메모리 內 데이터를 복사하는 함수는 항상 경계를 체크하는 개선된 함수를 사용하여 코딩하도록 하며, 선언된 변수 사용이나 메모리 할당 등 메모리
를 사용할 경우 반드시 초기화 후에 사용하여야 한다. 위의 취약 함수 사용을 예 방 및 수정하기 위해서는 내부적으로 사내 표준 코딩 규칙에 취약 함수 사용 금 지 관련 사항을 포함하거나 코드 리뷰시 취약 함수 사용 부분 확인 등 개발 간 개발자가 항상 준수할 수 있는 강제성이 있는 시큐어 코딩 방안을 제시하여야 한다. 또한 시큐어 코딩 취약점 검사 제품 및 개발 후 시니어 개발자 코드 검토 등을 이용하여 무기체계 소프트웨어에 작성된 코드를 검사하여, 취약한 함수 사 용 여부 및 버퍼 오버플로우, 힙 참조 등의 문제가 발생할 수 있는 잘못된 코드 작성 여부를 반드시 확인하여야 한다.
(3) 운영체제 명령어 삽입 취약점
운영체제 명령어 삽입은 사용자 입력값이 검증 절차 없이 운영체제 명령어로 실행되어 의도하지 않은 명령어 실행으로 인해 발생할 수 있는 보안 취약점이다.
운영체제 명령어 삽입 취약점을 이용하여 공격자가 악의적인 명령어를 입력함으 로써 부적절하게 권한이 변경되거나 시스템 동작에 악영향을 미칠 수 있다. 일례 로 내장형 시스템의 경우 CGI 등을 통한 관리자 페이지로 다수의 기기를 통제하 는 경우가 있다.이 때 시스템을 관리하기 위해 사용자 입력을 받아 운영체제 명 령어의 인자로 주는 경우가 있는데, 시스템 명령어 실행 인수로 외부 입력값을 사용할 경우 공격자가 원하는 명령어를 실행할 수 있다. 외부 입력이 시스템 명 령어 실행 인수로 사용될 경우, 미리 적절한 후보 명령어 리스트를 만들고 그 중 에서 선택하게 하거나, 예외처리 후 사용해야 하며 명령어 실행에 사용되는 특수 문자를 필터링 처리하도록 한다.
(4) 중요 정보 하드 코딩
중요한 정보의 하드 코딩으로 인한 정보 노출은 개발자가 작성한 코드 내부 에 중요정보(계정, 비밀번호, 암복호화 키 등)가 하드 코딩되어 있는 경우, 프로그램 소 스가 노출되었을 때 핵심정보도 동시에 노출되는 취약점을 가진다. 또한 실행 파 일 역공학(Reverse Engineering)을 통해 해당 정보를 추출하면 공격자가 추출 데이 터 복호화 등의 공격 시도가 가능하다. 따라서 중요 정보는 소스 코드 내 하드코 딩 하지 않아야 하며, 외부에 저장할 때는 암호화하여 저장하여야 한다.
또한 중요 정보를 저장하는 파일은 정보가 포함된 파일임을 파일의 이름만으 로 쉽게 유추할 수 없도록 사용하여야 한다.
(5) 중요 데이터 평문 통신
중요한 데이터의 평문 통신은 보안 관련 민감한 데이터를 평문 통신 채널을 통해 송수신할 경우, 공격자가 통신 채널 중간에서 오고가는 데이터 패킷을 스니 핑하고 분석하여 민감한 데이터를 획득할 수 있는 사항이다. 보안에 민감한 중요 정보는 전송 전 반드시 암호화하는 코드를 삽입하여야 하며, 통신 채널에서 민감 한 정보를 전송하는 코드 작성시에는 OpenSSL 등의 오픈소스 라이브러리 등을 활용하여 반드시 통신 채널을 암호화하여 전송하여야 한다. 웹 시스템은 HTTP 대신 HTTPS와 같은 보안 채널을 사용해야 하며, 브라우저 쿠키에 중요 데이터 를 저장하는 경우 쿠키 객체에 보안 속성을 설정하여 중요 정보 노출을 방지하 여야 한다.