이 문서는 현재 보안을 향상시키기 위한 도구로서 인기를 끌고 있는 IDS (침입탐지시스템) 중에서도 특히 네트워킹 상의 돌아다니는 패킷을 수집하여 침입을 탐지하는 NIDS 의 취약성에 대해서 다루고 있다. 이 취약성은 아마도 NIPC(National Infrastructure Protection Center) 에서 말하고 있는 것과 일맥 상통하는 것이라고 할수있을 것이다. 이곳에서 제공하는 정보는 여기를 참조 하기 바란다. 또한 이 취약점을 공격하는 프로그램을 얻어 테스트해 볼수도 있다. 이 문서의 저작권은 리얼어택에 있음을 알려드리며 임의로 복사,유포, 인용할수 없음을 알려드립니다. 1. 배 경 현재 대부분의 IDS (침입탐지시스템)은 네트워크 상의 돌아다니는 패킷을 수집하고 이를 분석 함으로서 침입을 탐지 하는 방법을 많이 쓰고 있다. 대부분의 상용 IDS(무지 비싼걸로 알고 있다.)와 SNORT (오픈소스로 공짜다) 등또한 마찬가지라고 할수 있다. 2. 침입을 탐지하는 방법 침입을 탐지하는 방법에 대한 개략적인 개념을 알아보자. 예를 들어 어떤 스크립트 키드가 인터넷에서 새로운 해킹 툴을 다운받았다고 하자. 그 툴은 포트번호 25번을 사용하는 sendmail 프로그램을 원격에서 공격하는 프로그램이라고 가정하자. 작동원리는 목표로하는 타겟호스트의 25번 포트로 Croot:root 라는 문자열을 전송하는 것이라고 하자. 그런데 침입탐지시스템은 현재 알려진 해킹 유형에 대한 데이터베이스를 가지고 있다. 침입탐지시스템이 만약 위의 해커가 입수한 공격방법에 대한 데이터베이스가 있다면 그것은 아마도 Croot:root 라는 문자열을 가진 패킷이 메일서버의 25번 포트로 전송되는 것을 탐지하면 이것을 침입시도로 간주하는 것이다. 물론 정상적인 편지 내용에 Croot:root 라는 문자열이 있다면 이것도 침입으로 간주될수 있다. 3. snort 룰을 통한 예 그렇다면 open-source 로 쉽게 구할수 있는 snort 를 통해서 예를 들어보자. snort는 침입탐지를 위한 데이터베이스가 있다. 한가지 예를 들어보기로 하자. alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-CGI webdriver access"; flags: A+; content: "/webdriver"; nocase;reference:arachnids,473;) 위의 간단한 룰셋을 보면 외부의 임의의 IP , 임의의 PORT 로 부터 웹서버의 80번 포트로 가는 패킷에 대해서 경고를 보낸다는 것이다. 이때 중요한 것은 flags: A+ 와 content: "/webdriver" 이다. content 는 패킷안에 이러한 내용이 들어있어야 한다는 것이다. 즉 패킷안에는 "/webdriver" 라는 내용이 있어야 한다는 것이다. 그렇다면 A+ 가 의미하는 것이 무엇인지가 중요하다. 4. flags: A+ 가 의미하는것 이것을 이해하기 위해서는 일단 TCP 의 간단한 작동 원리에 대해서 알아보아야 한다. TCP 프로토콜은 처음에 연결을 설정하기 위해 3-WAY HANDSHAKE 과정이 필요하다. 만약 A 라는 컴퓨터와 B 라는 컴퓨터가 최초 TCP 연결을 시도하는 과정은 다음과 같다. A 컴퓨터가 B 컴퓨터에게 SYN이 설정된 패킷을 보낸다. A ----- SYN ----> B B 컴퓨터가 A 컴퓨터에게 SYN ,ACK 설정된 패킷을 보낸다. A <----- SYN,ACK ----- B A 컴퓨터가 B 컴퓨터에게 ACK 설정된 패킷을 보낸다. A ------ ACK ------> B 위에서 SYN 이 의미하는 것은 어떠한 연결을 요청하기 위해 필요한 것이고 ACK 는 상대방의 요청에 대해 알았다는 표시라고 간단히 생각하면 된다. 위의 최초 연결 설정시의 3단계가 끝나게 되면 그 다음부터 전송되는 패킷은 SYN, ACK 가 동시에 설정된 패킷이 주를 이룬다. ACK+ 가 의미하는것은 ACK 설정은 꼭있고 ACK 설정외에 다른것이 있어도 된다는 것이다. 즉, 여기서 중요한 것은 ACK가 설정되어 있다는 것은 이미 상호간의 연결설정이 완료되고 상호간의 연결이 이루어진 것이라고 가정한다는 것이다. 5. 간단한 실험 일단 리눅스 머신에 SNORT 1.7 을 인스톨 했다. 그리고 나서 간단한 패킷을 생성하는 프로그램을 만들었다. 이 프로그램은 IP 와 PORT 를 입력받고 패킷안에 가질 데이터를 입력받는 간단한 것이다. 자 이제 SNORT 를 기만시킬 준비가 다끝났다. 임의의 IP 의 임의의 포트에서 SNORT 가 설치된곳의 80번 포트로 SYN,ACK 가 설정된 "/webdriver"라는 문자열을 가진 패킷을 만들어서 보냈다. 그랬더니 snort 는 침입 경고를 만들었다. 여기서 중요한것은 실제로는 80번 포트에 대한 어떠한 연결시도가 없었음에도 일어난 것이다. 6. 왜 그랬을까? 이러한 일이 일어난 이유는 snort 가 실제로는 어떠한 tcp 연결 과정이 일어나는 가에 대한 정보를 가지고 있지 않기 때문이다. 즉, 80번 포트에 대한 실제 3-way HANDSHAKE 가 일어났는지데 대한 여부를 알수가 없기 때문이다. 이러한 문제는 옛날 구형 방화벽에서도 유사하게 일어났는데 이를 해결한것을 STATEFUL INSPECTION 이라고 말한다. 즉 SNORT 는 STATEFUL 한 것이 아니기 때문에 현재 돌아다니는 패킷이 실제로 연결 설정이 끝난후에 전송되는 패킷인지의 여부를 판단할수 없다.. 7. 공격 프로그램 MAERONG 이라는 프로그램을 만들었다. 이 프로그램은 SNORT 가 보유하고 있는 룰중에서 400 개정도의 침입유형에 부합하는 패킷을 생성해서 계속해서 SNORT 가 작동하는 호스트로 보내는 곳이다. 공격하는 곳의 시스템 사양은 펜티엄 100에 32MB 램을 가지고 있고 SNORT 가 돌아가는 곳은 128MB 에 듀론 800 CPU 를 사용한다. SWITCHING HUB 를 통해서 두 시스템을 연결시켰다.(더미허브가 없어서) 공격을 시작하자 2초도 안되서 SNORT 는 1메가에 가까운 로그파일을 생성하더니 멈추었다. 그리고 공격당한 시스템은 다른곳엔 문제가 없었지만 외부 인터페이스에 대한 네트웍기능이 정지해 버렸다. SNORT 때문이 아닌 PCAP 라이브러니나 커널의 문제가 아닐까 의심스러워서 침입패턴이 아닌 임의의 패킷을 만들어서 돌렸지만 끄떡 없었다. 시스템의 속도가 줄었다. 하지만 네트웍 기능 정지등의 문제는 일어나지 않았다. 공격자의 패킷 전송 속도가 어느정도에 달하면 충분히 외부 네트웍의 snort 를 다운시킬수 있을지도 모른다. 8. 다른 상용의 침입탐지 시스템들은 ? 다른 상용의 침입탐지 시스템에 대해서는 실험해 보지 않았다.(상용 IDS가 없어서...) 하지만 snort 와 유사한 문제를 일으킬 것이라고 생각한다. 테스트를 원하는 분은 공격프로그램 을 다운받아서 한번 실험해서 테스트해보라... 하지만, 절대로 타인의 네트웍에 대해서는 실험해 보지 말아라. 그리고 이 프로그램의 사용에 대한 피해는 자기자신이 져야 한다. 이 프로그램이 심각한 오류상태를 발생하더라도 우리는 책임지지 않는다는 것을 명심하고 테스트하길 바란다. 9. 결론 STATEFUL 하지 않은 방식의 IDS 들에게 거짓으로 조작된 침입탐지 시도를 주는 것이 가능하다. 또한 DOS 공격을 감행할수도 있다. 이는 관리자로 하여금 컴퓨터가 아닌 사람을 향한 DOS 가 될수 있다. ( 매일 밤마다 침입탐지 메세지를 받는다고 생각해보라...) 아마도 STATEFUL 한 방식의 IDS 가 문제를 해결할수 있을거라고 생각한다. 10. MAERONG 에 대해서 이 프로그램은 400개 정도의 침입유형에 부합되는 패킷을 생성해서 전송하는 프로그램이다. 작동방식은 한번에 400개의 패킷을 생성한다음에 원형리스트를 생성해서 한개씩 돌아가면서 무한히 보낼수 있다. LIBNET 이라는 패킷 생성 라이브러리를 기반으로 만들어져 있기 때문에 시스템에 LIBNET 이 설치되어 있어야 한다. 이것은 여기서 구할수 있다. -s 옵션은 패킷이 가질 source ip 를 설정하고 -d 옵션은 패킷이 가질 destination ip 를 설정하고 -i 는 랜덤함수를 위해 필요한 적당한 정수값이고 -f 옵션에 0 이상의 값을주면 ctrl+c 를 누를때까지 패킷을 계속 보낼 것이다. 소스가 지저분할것이다. 업데이트할 계획은 없다. 단순한 테스트용이다. 11. 후에 덧붙이는 글 이 글이 진짜 의미하려고 하는 바를 잘 모르는것 같아서 아쉽다. 상용 IDS의 경우에 세션관리를 한다고 어떤 분이 그랬는데 TCP 프로토콜이 아닌 connection-less 한 프로토콜의 경우에는 아직도 문제의 여지가 있다는 것을 알기 바란다. Written By: 고 영 준 , 고 성 준 , 고 태 훈