==Phrack Inc.== Volume 0x0b, Issue 0x39, Phile #0x07 of 0x12 |=---=[ ICMP 기반 원격 OS TCP/IP 스텍 fingerprinting 기술들 ]=---=| |=-----------------------------------------------------------------------=| |=---------------=[ Ofir Arkin & Fyodor Yarochkin ]=---------------------=| --[ICMP 기반 fingerprinting 접근]-- TCP 기반의 원격 OS fingerprinting 은 꽤 오래되고도, 잘 알려진 바다. 근래들어, 이곳에서, 우리는 호스트로부터의 ICMP 응답에 기반해 원격에 있는 OS를 알아내는 또 다른 방법을 제시하고자 한다. 어떤 시스템 또는 플래폼 그룹(i.g.Win*)에서 얻어 왔던 정확성면에서 TCP 기반의 fingerprinting 방법보다 더욱 정확하다. 앞서 언급한 TCP 기반의 방법처럼, ICMP fingerprinting은 원격 OS TCP/IP 스택 프루브를 실행하기 위해 몇가지 테스트 절차를 이용한다. 하지만, TCP fingerprinting 과는 다르게 OS를 알아내기 위해 필요한 테스트의 수가 1개에서 4개로 다양하다. ( 현재의 개발 단계에 따른것이다. ) ICMP fingerprinting 방법은 다양한 운영체계에서의 ICMP 응답의 차이점을 발견하는데 기반하고 있다(대개, 부정확한, 또는 일관성없는 구현에 기인한것이다.) 이는 Ofir Arkin이 "스캐닝에서의 ICMP 사용"(ICMP Usage in Scanning) 이라는 연구프로젝트에서 발견한 사실이다. 훗날 이러한 발견은 'X project'라 Ofir가 이름 붙인 선택 트리(decision tree)로 요약되었고 'Xprobe' 툴로서 구현되었다. --[ICMP fingerprints이 갖고 있는 정보대 노이즈 비율]-- 이미 밝힌대로 ICMP기반의 검침을 통해 대상 머신을 원격에서 알아내기 위해 우리가 필요로 하는 데이타그램의 수는 작다. 매우 작다. 사실, 우리는 하나의 데이타그램을 보내고, 하나의 응답을 통해서 8가지 다른 운영체계(또는 한 클래스의 운영체계들)을 알아내게 할수 있다. 현재 개발단계에서 우리의 툴이 사용하는 최대 데이타그램의 수는 4개이다. 이는 우리가 분석할 필요가 있는 응답의 수가 같다. 이것이 ICMP 기반의 fingerprinting이 효율적인 이유다 ICMP 기반의 검침은 매우 비밀스럽게 이루어진다. 보통의 fingerprinting 방법과는 다르게 어떤 순간에도 잘못형성된/깨진/훼손된 데이타그램을 원격 OS 타입을 알아내는데 사용되지 않는다. 현재 핵심 분석은 유효하지 않은 패킷을 가공하는 것 보다는 유효한 패킷에 기반해 송신된 ICMP 응답의 확인에 주안점을 두고 있다. 그러한 상당수의 패킷들은 날마다 보통의 네트웍에서 나타나는 것들이고 극소수의 IDS만이 그러한 패킷들을 발견되도록 튜닝되어 있다(아마, 노이즈나 네트웍 설정이 잘못되어서 돌아다니는 트래픽으로 간주할것이다.) --[왜 이것이 동작하는가?]-- 다른 RFC 표준( 최초본 RFC792, 추가본 RFC1122 등등)을 구현한 ICMP 처리루틴을 가진 다양한 TCP/IP 스텍 구현들 사이의 태생적인 혼란, 부분적 또는 불완전한 ICMP 지원( 다양한 ICMP 요구가 모든곳에서 지원되는게 아니다.), ICMP 에러 메세지 데이타를 경시함(누가 최초의 데이타그램 모든 필드를 확인하겠는가?!), ICMP 프로토폴 구현에 있어서의 오해나 실수들, 이런것들이 우리의 방법이 실행가능토록 하는 것이다. --[우리는 무엇을 fingerprint 하는가]-- 원격 운영 체게를 알아내기 위해서 ICMP 기반 fingerprinting에서는 몇몇 OS 특성차이를 이용하게 된다. 검사하는 '공격'(offending) 데이타그램의 IP 필드들 : * IP 총 길이 필트( IP total length field) 어떤 운영체게(i.g. BSD 계열)은 최초 IP 총 길이 필드에 20 바이트( sizeof(ipheader))를 추가하게 될것이다.(이는 내부의 데이타그램 처리 실수에 의해 발생하는것이다. 같은 패킷이 SOCK_RAW를 통해 읽을때 값은 행동을 보인다는 사실을 주목해라.; 송신 패킷의 ip_len field는 20 바이트만큼 어긋나 있다.) 어떤 다른 운영 체계는 공격 패킷의 IP 총 길이 필드의 값을 20바이트만큼 감소시킬 것이다. 제3의 그룹에 있는 시스템들은 이 필드 값을 정확하게 반송할것이다. * IP ID 어떤 시스템들은 이 필드를 정확하게 반송하지 않는다.( 이 필드의 비트 순서가 바뀐다). * 3 비트 플래그 와 오프셋 어떤 시스템들은 이 필드를 정확하게 반송하지 않는다.( 이 필드의 비트 순서가 바뀐다). * IP 해더 체크섬 어떤 운영 체계는 이 필드를 잘못계산하게 되고, 다른 시스템들은 단지 0으로 만들어 버린다. 또다른 제3의 시스템들은 정확하게 이 필드를 반송한다. * UDP 해더 체크섬( UDP 데이타 그램인경우 ) UDP 체크섬에도 같은 현상을 보이고 있다. 반송된 ICMP 패킷의 IP 해더들 : * 선행 비트들 각각의 IP 데이타그름은 'TOS 바이트'라 불리는 8 비트 필드를 갖고 있다. 이는 우선순위와 서비스타입(Type of Service) 처리를 위한 IP 지원을 표현한 것이다. 'TOS 바이트'는 3개의 필드로 구성된다. 선행비트(RFC791)는 3비트 길이로 IP 데이타그램의 우선순위를 나타낸다. 이는 8단계의 우선순위 레벨을 가지고 있다. 더 높은 순위의 트래픽이 더 낮은 트래픽 보다 먼저 보내질 수 있어야 한다. 두번째 필드는 4비트 길이로 '서비스 타입(Type-of-Service)' 필드이다. 이는 네트웍이 처리율, 지연, 신뢰성, 그리고 IP 데이타그램의 라우팅에 있어서의 코스트 사이에서 협상하는 방법을 기술하는 것으로 본다. 마지막 필드, 'MBZ(must be zero)',는 사용되지 않고 반드시 0 이어야 한다. 라우터들과 호스트들은 이 마지막 필드를 무시한다. 이 필드는 1비트 길이다. TOS 비트들과 MBZ는 QoS를 위한 딮서브(DiffServ)에 의해 교체된다. IPv4 라우터를 위한 이하 RFC1812 요구사항들 : "4.3.2.5 TOS와 선행 ICMP 소스 Quench 에러 메세지들이 조금이라도 보내지면, ICMP 소스 Quench 메세지 송신을 발생시킨 패킷에 IP 선행 필드와 같은 값으로 설정된 IP 선행 필드 값을 가지고 있어야 한다. 다른 모든 ICMP 에러 메세지들(목적지 도달불가, 리다이렉트, 시간초과, 설정값오류)은 선행필드 값이 6 ( 내부동작 제어) 또는 7 ( 네트웍 제어)으로 설정되어야 한다. 이러한 에러 메세지들의 IP 선행 필드 값은 설정할수 있는 것이어야 한다. Linux 커널 2.0.x, 2.2.x, 2.4.x 는 라우터 처럼 동작하고, ICMP 에러 메세지에 선행 비트 필드 값을 0xc0 로 설정할 것이다. 이와 같이 동작하는 네트워크 장비들은 IOS 11.x-12.x 기반의 CISCO 라우터들과 Foundry Networks의 스위치들이다. * DF 비트들 반송 어떤 TCP/IP 스텍들은 ICMP 에러 데이타그램에 DF를 반송하고, 어떤 것은(Linux같은) 모든 옥텍을 완전히 복사하고, 특정 비트들을 제로로 만든고, 어떤 것은 이러한 필드 를 무시하고, 그들만의 값으로 설정한다. * IP ID filend ( linux 2.4.0 - 2.4.4 커널들 ) 커널 2.4.0-2.4.4 에 기반한 Linux 머신들은 IP Identification 필드 값에 그들의 ICMP Query 요구 값으로 설정하고 0 이라는 값으로 메세지에 응답한다. 이것은 Linux 커널 2.4.5 이상에서는 Fix 되었다. * IP ttl 필드 ( 타겟에 대한 ttl 거리는 정확도를 보장하기 위해 미리 계산되어야 한다. ) "송신자는 데이타그램이 인터넷에서 움직일수 있는 최대 시간을 나타내는 생존시간 (Time to live, TTL) 값을 설정한다." 그 필드 값은 IP 해더가 처리되는 각각의 곳에서 감소된다. RFC791에서 이르길 이 필드의 감소는 데이타그램 처리를 위한 소모된 시간을 반영하는 것이라 한다. 이 필드 값은 초단위로 측정된다. RFC는 또한 최대시간을 255초로 설정할수 있다고 한다. 4.25분과 같다. 목적지에 도달하기 전에 이 필드 값이 0이 되면 데이타 그램은 폐기되어야 한다. 시간을 측정하는 도구로서 이 필드를 연관시키는 것은 약간 잘못된 면이 있다. 어떤 라우터는 1초보다 데이타그램을을 더빨리 처리하곤하고 어떤것은 이 초보다 더 오랫동안 처리하곤 한다. 실제 의도야 데이타그램 존속시간에 상한선을 갖게 해서 전송되지 않는 데이타그램의 무한 루프가 인터넷을 혼잡하게 하지 않게 하기 위함이다. 데이타그램의 생존시간에 한계를 준다는 것은 우리에게 특정시간이 지나서 도착한 오래된 패킷들을 막는데 도움을 준다. 그래서, 우리가 미리 전송되지 않은 정보를 재전송할때, 우리는 더 오래된 패킷이 이미 폐기되고, 프로세스에 간섭하지 않음을 보장받는다. ICMP가 갖고 있는 IP TTL 필드 값은 다른 두개의 값들을 갖는다, 하나는 ICMP Query 메세지를 위한 것이고, 다른 하나는 ICMP Query 응답을 위한것이다. IP TTL 필드 값은 우리가 어떤 운영체계인지 운영체계 그룹인지 알게 해준다. 또한, 우리에게 다른 호스트에 문의를 하거나 트래픽을 감지(Sniffing)할때 다른 체크 기준을 추가하는 가장 간단한 수단을 제공한다. TTL 기반의 fingerprinting은 미리 계산된 타겟까지의 TTL 거리를 요구한다.( 로컬 네트웍 기반 네트웍의 fingerprinting이 실행 시스템이 아니라면 ) ICMP 에러 메세지들은 ICMP Query 요구들에 의해 사용된 값을 사용한다. OS 타입에 따른 TTL 관련성에 대한 좋은 통계가 아래에 모아져 있다. : http://www.switch.ch/docs/ttl_default.htm ( 디폴트 ttl 값에 대한 연구 논문 ) * TOS 필드 RFC 1349는 ICMP 메세지가 가지고 있는 서비스 타입(Type-of-Service)의 용도를 정의한다. 이는 ICMP에러 메세지들(목적지 불도달, 소스 Quench, 리다이렉트, 시간초과, 설정값오류)과 ICMP Query 메세지(반송, 라우터 요청, 타임스템프, 정보 요청, 주소 마스크 요청) 그리고 ICMP 응답 메세지( 반송 응답, 라우터 광고, 타임스템프 응답, 정보 응답, 주소 마스크 응답). 간단한 규칙들이 아래와 같이 정의되어 있다. : * ICMP 에러 메세지는 항상 디폴트 TOS(0x0000)을 가지고 보내진다. * ICMP 요청 메세지는 TOS 필드에 어떤 값을 가지고 보내진다. "사용자가 사용되는 TOS 값을 특정하도록 허용하는 메카니즘은 ICMP 요청 메세지를 생성하는 많은 어플리케이션에 유동한 특징이 될 것이다. " RFC는 ICMP 요청 메세지가 디폴트 TOS 값을 가지고 정상적으로 보내진다고 해도 가끔은 어떤 다른 TOS 값을 가지고 보내져야 하는 이유들이 있다고 더 상세히 기술한다. * ICMP 응답 메세지는 대응하는 ICMP 요청 메세지에서 사용된것과 같은 TOS 필드값알 가지고 보내진다. 어떤 운영 체계는 ICMP 반송 응답 메세지를 보낼때 RFC1349를 무시하고, 대응하는 ICMP 요청 메세지에서 사용된 TOS 필드값과 같은 값을 보내지 않을것이다. 응답받은 ICMP 패킷의 ICMP 해더들 : * ICMP 에러 메세지 할당 크기: 모든 ICMP 에러 메세지들은 IP 해더, ICMP 해더, 에러를 유발한(aka 공격 데이타 그램) 최초 데이타그램의 어떤 양의 데이타로 구성된다. RFC792에 따르면 최초 데이타그램의 64 비트(8 옥텟)만이 ICMP 에러 메세지에 포함된 것으로 간주된다. 그러나, RFC1122(나중에 언급될)는 할당크기를 576까지 늘릴것을 추천한다. 과거의 TCP 스텍 구현의 대개는 ICMP 에러 메세지에 8 옥텟을 포함한다. Linux/HPUX 11.x Solaris, MacOS 그리고 다른 시스템은 더 많은것을 포함하게 될 것이다. 눈에 띄게 흥미로웃것은 Solaris 엔지니어들은 아마 RFC를 정확히 읽지 않은것 같은 사실이다. ( Solaris 2.x는 최초 데이타그램에 64비트 대신 64옥텟(512비트)를 포함한다.) * 무결성을 반송하는 ICMP 에러 메세지 알려져 있는 다른 인공물은 어떤 스텍 구현은 ICMP 에러 메세지를 되돌려 보낼때, 공격 패킷의 IP 해더, ICMP 에러 메세지에 반송되는 하부 프로토콜 데이타를 바꾼다는 것이다. TCP/IP 스택 프로그래머들이 만들어낸 실수들이 운영 체계마다 다르고 특징이 있기 때문에, 이런 실수에 대한 분석은 실력있는 공격자들에게 목적지의 운영 체계 타입에 대한 가정을 할 수 있게 한다. 추가적인 비집고 비틀기: * ICMP 반송 요쳥에서 zero code 필드의 상이점 이용하기 0과 다른 ICMP code 필드가 ICMP 반송 요청 메세지(type 8)와 함께 보내질때, Microsoft 기반의 운영 체계중 하나가 ICMP 반송 응답 메세지로 우리의 질의에 답하게 될 운영 체계는 그들의 ICMP 반송 응답 메세지에 ICMP code 필드값을 0으로 해서 보낼 것이다. 다른 운영 체계(그리고, 네트워크 장치들)은 우리가 ICMP 반송 요청시에 사용했던 ICMP code 필드값을 반송 하게 될것이다. Microsoft 기반의 운영 체계는 응답 운영 체계가 ICMP 타입을 반송 응답(type 00로 바꾸도록 지시한 RFC792와는 반대로, 체크섬을 다시 계산하고, ICMP 반송 응답을 보낸다. * ICMP Query 메세지에 포함된 DF 비트 사용 ICMP 에러 메세지의 경우에, 어떤 tcp 스텍은 이러한 질의들을 응답할것이지만, 다른 시스템은 그렇지 않을것이다. * 다른 ICMP 메세지 : * ICMP 타임스템프 요청 * ICMP 정보 요청 * ICMP 주소 마스크 요청 어떤 TCP/IP 스텍은 이런 메세지들을 지원하고 이들중 몇몇에 응답한다. --[ Xprobe 구현 ]-- 현재 Xprobe는 'Project X'에서 Ofir Arkin에 의해 개발된 굳은 논리 트리를 갖고 있다. 초기 UDP 데이타 그램은 ICMP 에러 메세지를 유발하기 위해 닫혀진 포트로 보내진다. : ICMP 부도달/port 부도달. (이는 서비스 되지 않는 타겟 시스템에 필터링 하지 않는 적어도 하나의 포트를 가져야 하는 제한을 설정하는 것이다. 일반적으로, 말해서 ICMP 부도달 패킷을 유발하는 다른 방법이 사용될 수 있다. 이는 더 상세히 다룰것이다.) 게다가, 몇몇 테스트(ICMP 부도달 내용, DF 비트들, TOS ...)는 그들이 서로에게 영향을 미치지 ㅇ낳을것이기 때문에 하나의 질의내에 결합될 수도 있다. ICMP 부도달 데이타그램의 수령시, 수신 데이타그램의 내용들은 검사되고, 진단 결정이 이뤄지고, 더 세심한 테스트를 요구하고, 논리 트리에 따라, 다 상세한 질의들이 보내진다. --[ 논리 트리 ]-- 논리 트리 조직의 빠른 재생: 초기의 모든 TCP/IP 스택 구현은 두 그룹으로 나뉜다. 반송 선행 비트들을 되돌려 주는 것들과 그렇지 않은 것들이다. 반송 선행 비트들을 사용하는 것들(Linux 2.0.x, 2.2.x, 2.4.x, cisco IOS, 11.x-12.x, Extreme Network 스위치 등)은 ICMP 에러 할당 크기 면에서 매우 다르다. (Linux는 RFC1122를 고수해서 576 옥텍까지 반송하는 반면에, 서브그룹에 있는 다른 것들은 64 비트(8옥텟)만을 반송한다). 세심한 반송 무결성 체크는 cisco 라우터와 Extreme Network 스위치를 구별하는데 사용된다. ICMP 반송 응답의 생존 시간(Time to live) 과 IP ID 필드들은 Linux 커널의 버전을 인식하는데 사용된다. 똑 같은 방법이 다른 TCP/IP 스택을 인식하는데 사용된다. 유효함을 반송하는 데이타(반송된 최초 데이타그램의 옥텟양, 체크섬 인증, 등). 두개의 '비슷한' IP 패킷들을 구분하는데 더 많은 정보가 필요하다면, 추가적인 질의를 보낸다. ( 논리 트리의 더 상세한 설명과 그래픽 표현을 보고 싶다면 http://sys-security.com/html/projects/X.html에 있는 데이타그램을 참조해라.) 논리 트리의 심각한 문제들중에 하나는 새로운 운영 체계 타입을 추가하는것이 극도로 힘들다는 것이다. 가끔 전체 논리 트리가 하나의 기술을 만족시키기 위해 재작성되어야 한다. 고로, 서명 기반의 fingerprinting 방법이 우리들의 깊은 관심을 끌고 있다. --[ 서명 기반의 접근]-- 서명 기반의 접근은 우리가 현재 주목하고 있는것이자, 우리가 몇기에, 더욱 더 안정하며, 신뢰성있고 유연한 원격 ICMP 기반의 fingerprint 방법이다. 서명 기반의 방법은 현재 선택적으로 각각의 운영 체계에 포함될수 있는, 다섯가지 다른 테스트들에 기반하고 있다. 초기에는 더 작은 양의 테스트를 가지는 시스템으로 점검해 볼것이다.(보통 ICMP 부도달 테스트로 시작한다. ) 어떤 하나의 OS 스택도 딱 드러 맞는 수신서명을 발견하지 못하면, 일부가 맞는 스택들로 다시 그룹지어지고, 또 다른 테스트( 언급된 원칙에 따른 더 작은 테스트를 기반해서)가 선택되어 실행된다. 이러 확인작업이, OS 스텍이 완전히 서명을 발견할때까지 반복된다. 또는 테스트들을 소모케한다.? 현재 아래 테스트들이 배치되어 있다. : * ICMP 보도달 테스트(udp의 닫힌 포트를 기반한것, 호스트 부도달, 네트웍 부도달( 게이트웨이로 보이는 시스템에 대해서)) * ICMP 반송 요청/응답 테스트 * ICMP 타임스템프 요청 * ICMP 정보 요청 * ICMP 주소 마스크 요청 --[ 미래의 구현/개발]-- 아래의 사항들이 배치될 계획이다 ( 우리는 그래도 항상 토론과 제안을 환영한다.) * Fingerprint 데이타 베이스(현재 테스트 중이다.) * 동적, 인공지능 기반의 논리( 장기 프로젝트다. :)) * 네트웍 위상에 깊이 의존한 테스트들( 기 테스트 네트웍 매팅이 발생할것이다. ) * 장비 검침을 차단하는 타겟과의 경로 테스트(타겟과의 홉 거리를 계산하기 위함이다.) * 미래의 구현사항들은 탐지를 피하기 위해 실제 어플리케이션 데이타를 갖는 페킷을 사용하게 될것이다.) * 다른 네트웍 매팅 능력이 포함될 것이다.(네트웍 역할 인지, 닫힌 UDP 포트 찾기, 도달성 테스트 등) --[ 초보를 위한 코드들 ]-- 현재 구현된 코드와 상세한 문서는 아래 위치에서 구할수 있다.: http://www.sys-security.com/html/projects/X.html http://xprobe.sourceforge.net http://www.notlsd.net/xprobe/ Ofir Arkin Fyodor Yarochkin |=[ EOF ]=---------------------------------------------------------------=|