Document

X remote ICMP based
OS fingerprinting techniques
by Ofir Arkin
武藤研究室
セキュリティグループINAS
ポジション：スーパーサブ
直江健介
Table of Contents
1.Introduction
2.Remote Active Operating System
Fingerprinting Methods Used By X
3.How Does X works?
4.The Future development of X and xprobe
1.Introduction – What is X?
• 背景技術＞X
– “ICMP Usage in Scanning”[1]
• ICMPを使った様々な手法を使ったActive
OS Fingerprinting
• コンセプトは簡単で、高速で、効率的で、ホ
ストを特定することに非常に強力である
事。
1.1 Why X?(1/2)
• XprobeはTCP/IPの実装にかなり依存している他のツー
ルとは対極にあるツールだ！
• 既存のツールは特にMicrosoft系を特定するときに大変
– Win2K,NT4,MEや98/98SEのfingerprinting processに差異を見出
すのが非常に困難
• 必要とするデータグラムの数（１～４パケット）
• 既存のツールと違いmalformedなpacketは使わないため
IDSにも検出されにくい。（通常運用ではありえるデータグ
ラムの形をしているため）
1.1 Why X?(2/2)
• 情報収集の形を変える！？
– 今まで
１．HostScanでAvailabilityをチェック
２．走ってるサービスを調べる
３．その下にあるOSを特定
ホストにknownなexploitがあるサービスがあればそこを突く
＞めでたく管理者権限をゲット、無許可アクセス可能
– Xprobeだと
・HostScanの時点で何のOSかが分かる
・最高でも４パケットでどの脆弱性があるシステムか分かってしまう
2. Remote Active Operating System
Fingerprinting Methods Used By X
• Xは[1]で発見したいくつかのremote active operating
system fingerprinting methodsを利用している
2.1 ICMP Error Message Quoting Size
• ICMPのエラーメッセージは最低でもIPヘッダとエラーの
原因となったパケットの最初の8byteのデータバイトを含
む。
• ほとんどのOSはこのエラーメッセージを吐く
• じゃあ、どのOSが一番長いエラーメッセージを吐くの？
2.2 ICMP Error Message Echoing
Integrity(1/3)
• ICMPエラーメッセージを返すときにスタックの実装でメッ
セージが若干違う
• 普通、値が変わるのは何処よ？
– IPのTTL値
• ヘッダが読まれるたびに一つ減るから
– IPヘッダのチェックサム
• TTLが減るたびにチェックサムは再計算される
• XはUDPデータグラムを閉じられたUDPポートに送ること
でICMP Port Unreachable error messageを得て利用する
2.2 ICMP Error Message Echoing
Integrity(2/3)
• IP Total Length Field
– OSのIPスタックは
• Offending packetに対するエコーパケットのIP total lengthに 20byte
足す
• Offending packetに対するエコーパケットと一緒にオリジナルのパ
ケットのIP total lengthから20byte減らす
• 正しい値をエコーする
• IPID
– OSのIPスタックは
• ICMP Error message のIPIDの値を正しく返さない
• ICMP Error message のIPIDの値を正しく返す
2.2 ICMP Error Message Echoing
Integrity(3/3)
• 3Bits Flags and Offset Fields
– 正しく返さない
– 正しく返す
• IP Header Checksum
– Offendingパケットに対するエコーバックのIPヘッダのチェックサムの計
算ミスをする
– 0を返す
– 正しい値を返す
• UDP Header Chekcsum
– Offendingパケットに対するエコーバックのUDPヘッダのチェックサムの
計算ミスをする
– 0を返す
– 正しい値を返す
結論：いくつかのOSスタックはある値に関して正常
にエコーしないものがある
2.3 Precedence Bits Issues with ICMP
Error Messages
• 各IPデータグラムには8byteの“TOS Byte”がある
• TOS(Type of Service) Byteには三つのfieldがある
– Procedence filed 3bit長、IPデータグラムの優先度（8段階）
• 優先度の高いものは優先度の低いものより先に送られる
– TOS 4bit長、throughput,delay,reliability,IPデータグラムのルー
ティングcostを表現する
– MBZ(Must Be Zero) 1bit長、使用しない、0でなくてはいけない
• ルータやホストはこの部分を無視する
ICMP Source Quench error messageが送信されているのならば、IP
Procedence fieldの値はそれを誘発したIP Procedence fieldと同じ
でなくてはいけない。
2.4 DF Bit Echoing with ICMP Error
Messages
• DF(Dont Frag) bit set, 分割禁止
• ICMP error messageを誘発するOffending packetと一緒に
DF bitをたてたら、どうなるであろうか？
– ICMP error message IP HeaderのDF bitもたつの？
2.5 IP Identification Field Value with
ICMP Query Messages with Linux
Kernel 2.4.x based machines
• Linux Kernel 2.4.5以上では直されているが、2.4.0-2.4.4
ではICMP query requestとreply messageと共にIP
Identification fieldが0にセットされる。
2.6 The IP Time-To-Live Field Value
with ICMP Messages
• IP Headerがプロセスされるたびに１づつ減らされる
– RFC791ではこの値は秒で計る
– 最高で255秒＝4.25分
• 0であればデータは破棄される
– 実際のルータなどは1秒以上かかるのもあれば一秒以下でプロセス終
了する
– 実際の使われ方は無限ループに陥ったいわゆるゴーストパケットの破
棄方法としてある（ようなもの）。また、古いデータが新しいデータが届い
た後に届くのを防ぐ
– IP TTL値にはICMP query messeageとICMP query replyと二つがある
• TTLベースのOS FingerprintingではあらかじめTTL距離（何ホップ
か）を知らなくてはいけない
2.7 Using Code Field Values Different
Than Zero with ICMP Echo Requests
• ICMP code filedを0以外のICMP Echo requestを送ると
– Microsoft系はICMP Echo replyとして0を返す
– それ以外はICMP Echo requestで使った値を返す
• Microsoft系のOSはRFC792[2] guidelineとは対照的な振
る舞いをする。
2.8 TOS Echoing
• RFC1349はICMP messagesのType-of-Service値を規定、以下の三つ
に区別する
– ICMP error message(Destination Unreachable,Source
Quench,Redirect,Time Exceeded,Parameter Problem)
– ICMP query message(Echo,Router Solicitation,Timestamp,Information
request,Address Mask request)
– ICMP reply messages(Echo reply,Router Advertisement,Timestamp
reply,Information reply,AddressMask reply)
• いくつかのOSはRFC1349を無視して、ICMP reply messagesのTOS値
をICMP request messagesのTOS値を返さないものがある。
2.9 DF Bit Echoing With ICMP Query
Messages
• ICMP query request messagesと一緒にDF bitを立てたらど
うなるだろう？
– DF bitはICMP query request messageと一緒に立てられるものな
のか？
2.10 The ?Who Answer What??
Approach
• OSを特定するのにICMP Query message requestを使う
–
–
–
–
ICMP Echo request
ICMP Timestamp request
ICMP Information request
ICMP Address Mask request
3. How does X works?
• アイデアは最初に静的な決定木を作る
– どう似たOSを特定のOSとして差別化（判定）するか
• まずUDPパケットをclosedなUDP destinationポートに送信
(default:3132byte)
– ICMP Destination Unreachable Port Unreachable error messageを
利用してOSFingreprintの違いを得る
– 送信したホストからリプライが無ければlinsten状態
– UDPパケットをブロックするフィルタ機器があれば空いたUDP
ポートの真似をする（従ってreplyは受け取らない）
3. How does X works?
アタック１
• UDPパケットを閉じたUDPポートに対して送るとICMP
Port Unreachable error messageを受け取れるので１パケッ
トを送る事で判別。
– 返ってくればホストは生きてるかトラフィックが許されてる
– かえってこなければフィルタリング機器が存在しているだろう
• どうやって閉ざされたＵＤＰポートを探すか
– IANAのポートリストなど
• http://www.Isi.edu/in-notes/Iana/assignments/port-numbers
3. How does X works?
• UDPデータグラムにDF bitをたてたものを送ることで2.4
のノウハウを使う
– UDP queryは70byteのデータを持つ
– 対象ホストが何バイト返すかを見る
• Errorを返せば対象ホストに対してこの手法が使える
• 返さなければフィルタリングされているかホストが落ちている
– この値が0xc0であればLinux Kernel 2.0.x/2.2.x/2.4.xベースマシ
ン、CISCO based router(IOS 11.x-12.x)、Extreme Networks
Switch
3. How does X works?
• 前述したIP Headerの先頭8byte以上をICMP error
messageに含むOS群はLinux Kernel 2.0.x/2.2.x/2.4.xであ
る
• ネットワークデバイスはPrecedence bitに0x0cを立てたも
のに対しては先頭8byteしか返さない
– これでLinuxKernelとCISCO routerとExtreme Network switchを差
別化できる
3. How does X works?
• Linux Kernel 2.0.xは初期IPTTL値を64にセットされる。
Linux Kernel 2.2.x/2.4.xは初期IPTTL値を255にセット
– Linux Kernel 2.4.0-2.4.4のICMP queryのIP ID値は常に0
– 2.4.5から直された
• Kernel2.2x/2.4.5以上と2.4.0-2.4.4とに差別か出来る
3. How does X works?
アタック２
• ICMP Port Unreachable Error Messagesパケットにどのくら
いのechoを返したかで判別
– 8byte返す
– 64byte返す
– 64byte以上返す
• 分かったことはfigure5の通り
3. How does X works?
• Sun Solaris 2.3-2.8,HPUX 11.x,MacOS 7.x-9.x
– ICMP Timestamp Requestを送信
• リプライがあるもの＞Sun Solaris 2.3-2.6
• リプライの無いもの＞HPUX 11.x,MacOS7.x-9.x
• アタック１で万が一Linux系が判別できなくてもここで判別
が出来る
3. How does X works?
アタック３
• ICMP Error messageが返すIP total lengthの値で判別
– 正しく返す
– 正しい値より20byte少ない
– 正しい値より20byte多い
• 正しい値より20byte少ない
– OpenBSD 2.6-2.9,Apollo Domain/OS SR10.4,NFR
IDS…..Figure7参照
3.正しい値より20byte少ない
• 返ってきたICMP error messageのUDPチェックサムで判
別
– 正しい値
– 0
– 正しくない値
• Figure8を参照
3.正しい値より20byte多い
• AIX,BSDI,NetBSD 1.x-1.2.xの判別
• offendingUDPを送ったことでOSが返したICMP error
messageの値で判別
– まずIP Header checksumのインテグリティチェック
• AIXはechoされた値をmicalculateする、それ以外は正しく計算する
– 次にIP Identification field valueのインテグリティチェック
• BSDI 2.x,3.xとNetBSD1.x-1.2.xはlittle endianの問題で値を正しく返
さない
• BSDI 4.x,NetBSD 1.x-1.2.xのbig endianとMacOS X 1.0-1.2は正しく
返す
3. How does X works?
• 元のbranchに戻り話をするめる
– IP Total Length field value echoed coreectly
• 3bit flags(Unused,MF,DF)とoffset filedを使い判別
• Figure10参照
3. How does X works?
• そしてWindowsファミリーを判別する
– どきどきしますねぇ～～
3. How does X works?
• Microsoft系列のOSを判別するには違うqueryを
使う必要がある。
– Code field value different than zero with ICMP Echo
requests
• ICMP Echo Request with the Precedence Bits !=0,
DF Bit Set,ICMP Code Field !=0
– 0が返るならMicrosoftWindowsFamily
– それ以外の値が返るなら、MSWindows系以外
3. How does X works?
• Windowの中でのバージョンの判別
– TTL値での判別
• TTLが32
– Windows95
• TTLが128
– Windows95以外
– Precedence Bitsでの判別
• !=0
– 98/98SE/ME/NTsp3-/NTsp4+
• =0
– Microsoft Windows 2000,SP1,SP2
3. How does X works?
• 98/98SE/ME/NTsp3-/NTsp4+の判別
– ICMP Time Stamp Requestによる判別
• Reply
– Windows98/98SE/ME
• No Reply
– Windows NT SP 3-,Windows NT SP 4+
3. How does X works?
• WIndows98/98SE/MEの判別
– ICMP Address Mask Request
• Reply
– Windows98/98SE
• No Reply
– Windows ME
• Windows NT SP 3-/Windows NT SP 4+の判別
– ICMP Address Mask Request
• Reply
– Windows NT SP 3-
• No Reply
– Windows NT SP 4+
3. How does X works?
• 残りは？
– DF Bit EchoingによるUltrix,Novell,BSD系の判別
[with the request]
• 返す
– Ultrix,Novell
• 返さない
– それ以外のOS(BSD系)
– TTLが128のものがNovell
– TTLが255のものがUltrix
3. How does X works?
– OpenBSD2.1-2.3.x,2.4-2.5と
NetBSD1.5,1.4.1,1.4の判別手法
• Echoing Integrity CheckのUDP Checksum of the
Offending Packet Echoed
– !=0
» OpenBSD 2.4.x-2.5.x
» NetBSD 1.5,1.4.1,1.4
– =0
» OpentBSD 2.1.x-2.3.x
4. The Future development of X
and xprobe
•
•
•
•
AIとシグネチャベースのアプローチ
Custom scenario
Fail over mechanism
出来ないことから学ぶ
– Static logicである
– いくつかのOSと少ない数のネットワークデバイスしか
判別できない
– ICMP/UDPベースであること
– Fingerprintのデータベースとの連携
4. The Future development of X
and xprobe
• やりたいこと
–
–
–
–
–
–
Fingerprintのデータベースとの連携
内部にAIを持たせて、Dynamicにロジックを構築
多くのネットワークデバイスの判別を可能にしたい
違うトポロジには違う手法を用いたい
フィルタリングデバイスを使ったテストをしたい
実際のアプリケーションデータベースを使いUDPquery
と絡めたい
– もっと使えるNetwork mappingも含まれるべき
Demo

Download Report