침투 테스트라는 말을 들으면 아마 소프트웨어를 대상으로 비밀스런 테스트를 수행하는 외로운 천재가 연상될 것입니다. 사실 침투 테스트의 새로운 부흥기가 열리기 전까지 이러한 상상은 현실과 크게 다르지 않았습니다. 그러나 오늘날의 침투 테스트는 훨씬 더 조직적인 방식으로 수행됩니다. 이러한 조직적 방식이 필요한 이유는 SDL(보안 개발 수명 주기), 그리고 SDL이 전면에 내세우는 안전한 디자인 및 개발로 인해 잠재적인 결함의 수가 줄면서 테스트 중에 취약점을 찾기가 훨씬 더 어려워지고 있기 때문입니다. 소프트웨어 보안 테스트는 소규모 전문가 그룹에 맡기기엔 너무나 중요합니다. 보안 테스트는 교육이 가능해야 하고 조직적이어야 하며 다양한 환경에 적용할 수 있도록 반복 가능해야 합니다.

그렇다고 해서 침투 테스트를 과학이라고 말하기는 어렵습니다. 모든 테스트에는 실험적인 측면이 있습니다. 테스터는 입력을 적용하고, 이 입력은 소프트웨어 내부의 데이터를 변경시켜 여러 가지 반응을 유도합니다. 복잡성이 너무 높아 정확한 예측을 할 수는 없지만 미리 계획할 수 있는 부분도 많이 있습니다. 이번 칼럼에서는 Microsoft에서 이러한 계획을 어떻게 수립하는지에 대해 설명합니다.

일반적인 테스트에서는 사양, 사용자 설명서, 사용 사례 및 기타 디자인 문서를 풍부하게 사용할 수 있으며 이 정보를 사용하여 지정된 기능의 유효성을 검사하는 테스트 사례 집합을 디자인할 수 있습니다. 그러나 계획에서 사용할 수 있는 정보의 출처는 극히 제한적입니다. 침투 테스트는 기능의 유효성을 검사하는 테스트가 아니라, 안전하지 않은 기능의 존재 여부를 확인하는 테스트입니다. 아쉽게도 지금까지 누구도 이러한 동작에 대한 소프트웨어 개발 항목을 정의하지 않았기 때문에 테스터가 이러한 부분을 직접 처리해야 합니다.

침투 테스트 정보를 처음으로 수집할 부분은 소프트웨어와 외부 환경 사이의 인터페이스입니다. 사용자 인터페이스, 네트워크 인터페이스, API 및 기타 입력이 처리되는 모든 부분은 해커들에게 확실한 공격 경로입니다. 이러한 인터페이스가 불완전하게 디자인 또는 구현될 경우 악의적으로 작성된 입력이 침투하여 혼란을 일으킬 수 있습니다. 침투 테스트에서는 가장 먼저 이러한 인터페이스를 식별하고 문서화하는 것이 좋습니다.

각별한 주의가 필요한 두 번째 영역은 소프트웨어에서 외부 사용자로 정보를 전달하는 오류 메시지와 사용자 경고 대화 상자입니다. 외부 사용자가 악의적인 의도를 가진 사용자일 수도 있으므로 이들에게 어떤 정보가 어떤 방식으로 노출되는지 파악하는 것이 중요합니다.

마지막으로, 많은 경우 침투 테스터는 공격이 성공할 경우 어떻게 되는지 기술하는 재해 시나리오를 정의합니다. 이러한 오용 또는 남용 사례는 대개 위협 모델 또는 이미 알려진 공격을 사용하여 만들어집니다.

이러한 3개의 출처 모두에서 정보를 수집하는 것은 침투 테스트를 위한 중요한 준비 단계이며, 수집된 정보는 실제 테스트에서 길잡이 역할을 합니다.

테스트의 주 관심 대상은 변동입니다. 즉, 소프트웨어 및 관련 환경에서 변동될 수 있는 부분을 찾아 여러 가지로 변동시키면서 소프트웨어의 반응을 관찰합니다. 테스트의 목적은 소프트웨어가 적절한 프로덕션 시나리오는 물론 부적절한 프로덕션 시나리오에서도 안정적으로, 안전하게 역할을 수행하는지 확인하는 것입니다. 따라서 가장 기본적인 계획으로 테스터는 변동이 가능한 부분을 찾고, 테스트를 위해 이러한 변동을 어떤 방식으로 단계화해야 하는지 파악해야 합니다.

보안 관점에서 환경, 사용자 입력, 내부 데이터 및 논리는 이러한 변동으로 인해 보안 문제가 드러날 수 있는 1차적인 위치입니다. 환경은 파일, 응용 프로그램, 그리고 응용 프로그램에서 사용하는 시스템 리소스 및 기타 로컬 또는 네트워크 리소스로 구성됩니다. 이러한 구성 요소는 모두 공격 진입 지점이 될 수 있습니다. 사용자 입력은 외부(일반적으로 신뢰할 수 없는) 엔터티에서 비롯되어 소프트웨어에 의해 구문 분석되고 사용되는 데이터입니다. 내부 데이터 및 논리는 내부적으로 저장되는 변수 및 논리 경로로, 여기에는 여러 가지 잠재적인 계수가 있습니다.

소프트웨어의 환경, 입력 영역 및 데이터/논리 경로를 변동시키는 방법으로 공격을 수행할 수 있습니다. 이 세 가지 범주를 각각 자세히 살펴보겠습니다.

소프트웨어는 격리된 상태로 실행되지 않습니다. 소프트웨어는 스크립트, 플러그 인과 같은 바이너리 및 코드 상응 모듈에 의존합니다. 또한 레지스트리나 파일 시스템의 구성 정보, 그리고 특정 위치에 있는 데이터베이스 및 서비스를 사용할 수도 있습니다. 이러한 환경 상호 작용은 보안 침투의 원인이 되므로 테스트를 거쳐야 합니다.

또한 사용 중인 응용 프로그램이 이러한 상호 작용을 얼만큼 신뢰하는지에 대해서도 몇 가지 중요한 질문을 던져야 합니다. 이러한 질문에는 응용 프로그램이 로컬 환경 및 원격 리소스를 얼만큼 신뢰하는가? 응용 프로그램에서 다른 응용 프로그램이 읽을 수 있는 리소스(예: 레지스트리)에 중요한 정보를 두는가? 로드하는 모든 파일 또는 라이브러리를 그 내용에 대한 확인 없이 신뢰하는가? 공격자가 이러한 신뢰를 악용하여 응용 프로그램을 자신의 의도대로 움직일 수 있는가?

이러한 신뢰에 관한 질문 외에 침투 테스터는 ACL(액세스 제어 목록)에 의해 완전히 보호되지 않거나 다른 방법으로도 보호되지 않는 결함 가능성이 있는 DLL, 또는 공격자, 바이너리 또는 응용 프로그램과 상호 작용하는 파일에 의해 교체(또는 수정)된 DLL도 주시해야 합니다. 또한 테스터는 공유 메모리 리소스에 액세스하거나 중요한 데이터를 레지스트리 또는 임시 파일에 저장하는 다른 응용 프로그램에도 유의해야 합니다. 마지막으로 테스터는 느린 네트워크, 부족한 메모리와 같이 시스템 스트레스를 유발하는 요소를 고려하고 이러한 요소가 보안 기능에 미치는 영향을 확인해야 합니다.

많은 경우 환경 공격은 안전하지 않은 환경을 조성한 후 이 환경 내에서 응용 프로그램을 실행하여 반응을 살펴보는 방법으로 수행됩니다. 이는 간접적인 테스트 형식입니다. 즉, 공격은 응용 프로그램이 작동하는 환경을 대상으로 수행됩니다. 이제 직접적인 테스트에 대해 살펴보겠습니다.

침투 테스트에서 가장 중요한 부분은 신뢰할 수 없는 출처에서 비롯되는 입력 하위 집합입니다. 여기에는 네트워크 프로토콜 및 소켓과 같은 통신 경로, DCOM, RPC(원격 프로시저 호출) 및 웹 서비스와 같은 노출된 원격 기능, 데이터 파일(바이너리 또는 텍스트), 실행 중에 생성되는 임시 파일, 스크립트 및 XML과 같은 제어 파일 등이 포함되며, 이러한 요소는 모두 변조의 위험에 노출됩니다. 마지막으로 로그온 화면, 웹 프런트 엔드 등 직접적인 사용자 입력을 허용하는 UI 컨트롤도 확인해야 합니다.

구체적으로 말하자면 입력이 제대로 제어되고 있는지 여부를 확인해야 합니다. 즉, 적절한 입력은 허용되고 부적절한 입력(긴 문자열, 변형된 패킷 등)은 차단되고 있는지 확인해야 합니다. 적절한 입력 확인 및 파일 구문 분석은 필수적입니다.

위험한 입력이 UI 컨트롤에 입력될 수 있는지 테스트하고 그렇게 될 경우 어떤 일이 발생하는지 확인해야 합니다. 위험한 입력에는 특수 문자, 인코딩된 입력, 스크립트 조각, 형식 문자열, 이스케이프 시퀀스 등이 포함됩니다. 또한 패킷 필드 또는 파일에 내장되어 메모리 오버플로를 일으킬 수 있는 긴 문자열이 통과할 수 있는지 여부를 확인해야 합니다. 프로토콜 스트림의 손상된 패킷 역시 주의 대상입니다. 시스템 충돌 및 멈춤을 관찰하고 스택을 통해 악용 가능한 메모리 손상이 있는지 검사해야 합니다. 마지막으로, 유효성 검사 및 오류 메시지가 올바른 위치(서버 측이 아닌 클라이언트 측)에서 부적절한 입력에 대한 방어 수단으로 제공되는지 확인해야 합니다.

입력 공격은 응용 프로그램에 폭탄을 던져 넣는 것과 같습니다. 일부 폭탄은 빗나가지만 일부는 소프트웨어의 폭발을 유발합니다. 각 위험 요소를 확인하고 적절한 수정을 제안하는 것은 침투 테스트 팀의 책임입니다.

응용 프로그램의 내부 데이터 저장 메커니즘과 알고리즘 논리에 결함이 숨어 있는 경우도 있습니다. 이러한 경우는 개발자가 디자인 및 코딩 시에 선의의 사용자만 가정하거나 사용자가 추적할 수 있는 코드 경로를 고려하지 않았기 때문에 발생합니다.

서비스 거부는 이 범주에 속하는 공격의 대표적인 예이지만 가장 위험한 공격은 아닙니다. 서비스 거부 공격은 개발자가 대규모 사용자(또는 연결, 파일을 비롯해 일부 리소스를 한계까지 소모하는 모든 입력)에 대한 계획을 세우지 않은 경우에 성공합니다. 그러나 이보다 훨씬 더 위험한 논리적 결함이 있으며 이에 대한 테스트가 필요합니다. 예를 들어 정보 누설은 오류 메시지 및 기타 생성된 출력을 유도하는 입력이 악용 가능한 정보를 공격자에게 노출하는 경우 발생합니다. 항상 제거해야 하는 데이터의 실제적인 예는 테스트 자동화를 위해 종종 내부 빌드에 포함되는 하드 코딩된 테스트 계정 또는 테스트 API입니다. 이러한 데이터는 공격자에게 손쉬운 액세스 경로를 제공합니다. 두 가지 추가로 실행해야 하는 테스트는 잘못된 자격 증명을 입력하여 내부 권한 부여 메커니즘의 견고성을 확인하는 것, 그리고 코드 경로를 변경하는 입력을 선택하는 것입니다. 하나의 코드 경로는 안전하지만 동일한 기능을 다른 방법으로 액세스할 수 있는 경우가 많으며, 이 경우 중요한 확인 과정이 의도하지 않게 생략될 수 있습니다.

침투 테스트는 일반적인 기능 테스트와는 상당히 다릅니다. 적절한 문서도 제공되지 않으며, 테스터는 시스템에 피해를 주려는 사용자 입장으로 생각할 수 있어야 합니다. 이 점이 매우 중요합니다. 개발자는 합리적인 사용자라면 특정 시나리오를 실행하지 않을 것이라는 가정하에 버그를 수정하지 않는 경우가 많기 때문입니다. 그러나 침투 테스터는 이렇게 운에 맡길 수 없습니다. 해커는 취약점을 찾기 위해 집요하게 노력하며 가능한 모든 속임수, 회피, 또는 즉흥 테스트 사례를 연구합니다. 침투 테스터도 마찬가지입니다.