侵入技術の紹介 Eiji James Yoshida zaddik@geocities.co.jp penetration technique research site http://www.geocities.co.jp/siliconvalley/1667/index.htm
侵入技術 (penetration technique) の調査と報告 脆弱性の調査や報告ではなく 脆弱性に潜む侵入技術として利用できる可能性の調査と報告 侵入技術の提供 弱点を修正する技術ではなく 弱点を知る技術の提供 セキュリティシステムを構築する技術ではなく セキュリティシステムの動作を確認する技術の提供 セキュリティ意識の啓蒙と向上 侵入技術を知ることで受ける危機感によるセキュリティ意識の啓蒙と向上
紹介する侵入技術 OS 推測 IP Fragment ID Scan 受動的攻撃 File Transfer Techniques
紹介する侵入技術 OS 推測 IP Fragment ID Scan 受動的攻撃 File Transfer Techniques 調査 ( 情報収集 ) 検証 ( 攻撃 ) 移動 ( 視点変更 )
侵入技術の紹介 OS 推測 ( 調査 )
推測 素早く的確に弱点を見つけることを目的として行う情報収集技術の一つ insecure.org の Fyodor 氏や Sys-Security Group の Ofir Arkin 氏 TESO Security Group などが確立 OS 推測として使われる技術は主に 5 種類 Banner grabbing Telnetd fingerprinting Identd fingerprinting TCP stack fingerprinting ICMP responses based TCP/IP stack fingerprinting
推測について Banner grabbing
サービスやアプリケーションなどが提供する情報に含まれているバージョン情報の収集 比較的容易に収集できるが 殆どは設定ファイルの変更等で隠蔽や偽装が可能 そのため情報の信頼性は低い
の一例 telnet (port:23) telnet コマンドなどで接続すると表示される ( 例 ) # telnet 192.168.1.23 Red Hat Linux release 6.0 (Hedwig) Kernel 2.2.5-15 on an i586 login:
推測について Telnetd fingerprinting
Telnet 接続を確立する際に行われる交渉 (Negotiation) の初期値が 各 OSごとに異なっていることを利用したOS 推測 Telnet daemonへの接続が必要 TESO Security Groupが検証用ツール telnetfpを公開 TESO Security Group( http://teso.scene.at/ )
の一例 Netcat を使って Telnet daemon(port:23) に接続すると交渉 (Negotiation) が表示される ( 例 ) # nc -n -o telnet_hexdump.log 192.168.1.23 23 # この部分 < telnet_hexdump.log > ff fd 18 ff fd 20 ff fd 23 ff fd 27 255 253 24 255 253 32 255 253 35 255 253 39 この値をFingerprintとして利用
の Linux DO: 255 253 24 255 253 32 255 253 35 255 253 39 DONT: 255 250 32 1 255 240 255 250 35 1 255 240 255 250 39 1 255 240 255 250 24 1 255 240 FreeBSD 4.1-STABLE DO: 255 253 37 DONT: 255 250 37 1 6 SunOS 5.6 DO: 13 10 77 97 115 116 101 114 46 13 10 DONT: 255 251 3 Windows 2000 DO: 255 253 37 255 251 1 255 253 3 255 253 31 255 253 DONT: 255 250 37 1 15
推測について Identd fingerprinting
各 OSに初期インストールされるIdent daemonのバージョンが異なっていることなどを利用したos 推測 Ident daemonへの接続が必要 TESO Security Groupが検証用ツール ldistfpを公開 TESO Security Group( http://teso.scene.at/ )
の一例 telnet コマンドなどで auth(port:113) に接続して VERSION と入力することで表示される ( 例 ) # telnet 192.168.1.23 113 VERSION 0, 0 : X-VERSION : 2.8.5 (Compiled: 22:13:48 Mar 21 1999) Connection closed by foreign host.
の FreeBSD i386 4.2-STABLE "Compiled: 11:18:59 Oct 23 2000" "pidentd 2.8.5" 1 SunOS 5.8 "UNKNOWN-ERROR" "unknown" 0 RedHat i386 6.0 "Compiled: 22:13:48 Mar 21 1999" "pidentd 2.8.5" 1 HP-UX 11.00 "2.7.4" "pidentd 2.7.4" 0 Debian i386 2.2 "Dec 22 2000 17:00:25" "pidentd 3.0.12" 1
推測について TCP stack fingerprinting
OS ごとに TCP/IP の実装が異なっていることから 使用される初期シーケンス番号の特徴や 多種のパケットを送信した際の返信パケット種類とフラグの設定 window サイズなどの情報を利用した OS 推測 特異なパケットを多数送信するので 検知が容易 またダイナミック パケットフィルタリング越しでの推測は困難
9 種類のテストを用いて OS を推測するので 他の OS 推測より信頼性が高い Insecure.org で公開されているポートスキャナ NMAP の OS 推測機能が有名 Insecure.org ( http://www.insecure.org/nmap/ )
の一例 ポートスキャナ NMAP の OS 推測オプション (-O) を設定したポートスキャンを行うことで 容易に OS 推測を行うことが可能 ( 例 ) # nmap -n -ss -O 192.168.1.23 Interesting ports on (192.168.1.23): (The 1520 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 23/tcp open telnet TCP Sequence Prediction: Class=random positive increments Difficulty=3080148 (Good luck!) Remote operating system guess: Linux 2.1.122-2.2.14
の仕組み 9 種類のテストを行い それぞれのテストで得た情報から推測 TSeq( 初期シーケンス番号テスト ) T1(OpenPort に SYN パケットを送った場合の返信内容テスト ) T2(OpenPort に NULL パケットを送った場合の返信内容テスト ) T3(OpenPort に SYN FIN URG PSH パケットを送った場合の返信内容テスト ) T4(OpenPort に ACK パケットを送った場合の返信内容テスト ) T5(ClosePort に SYN パケットを送った場合の返信内容テスト ) T6(ClosePort に ACK パケットを送った場合の返信内容テスト ) T7(ClosePort に FIN URG PSH パケットを送った場合の返信内容テスト ) PU(UDP を利用した 'port unreachable'message テスト )
nmap-os-fingerprints ファイルまたは NMAP のデバッグ機能 (-d) を設定すれば表示される OS Fingerprint: TSeq(Class=RI%gcd=1%SI=4C23BD) T1(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENN TNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENN TNW) T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E %RIPCK=E%UCK=E%ULEN=134%DAT=E)
推測について ICMP responses based TCP/IP stack fingerprinting
ICMP responses based TCP/IP stack fingerprinting 各種 ICMPパケットを送信した際の返信されるICMPパケットや 閉じているUDPポートに対してUDPパケットを送信した際の返信されるICMP 不達通知 (type 3) パケットの特徴からOSを推測 UDPパケットに対して返信されるICMP 不達通知パケット及び各種 ICMPパケットが 推測行為を行う側に到達することが必要
ICMP responses based TCP/IP stack fingerprinting OS によっては数回のパケット送信で推測可能なため 検知や遮断が困難 Sys-Security Group が検証用ツールとして X を公開 Sys-Security Group ( http://www.sys-security.com/html/projects/x.html )
ICMP responses based TCP/IP stack fingerprinting # x -v 192.168.1.1 X probe ver. 0.0.1p1 ------------------ Interface: eth0/192.168.1.2 LOG: Target: 192.168.1.1 LOG: Netmask: 255.255.255.255 LOG: probing: 192.168.1.1 TEST: UDP to 192.168.1.1:32132 [98 bytes] sent, waiting for reponse. TREE: Cisco IOS 11.x-12.x! Extreme Network Switches.Linux 2.0.x!2.2.x!2.4.x. TREE: Linux kernel 2.0.x!2.2.x!2.4.x! Based. TREE: Linux kernel 2.2.x!2.4.x! Based. TEST: ICMP echo request to 192.168.1.1 [68 bytes] sent, waiting for reponse. TREE: ICMP echo/echo reply are not filtered FINAL:[ Linux 2.2.x/2.4.5+ kernel ]
ICMP responses based TCP/IP stack fingerprinting の仕組み 返信される ICMP パケットから以下の値を調べることで OS を推測 IP total length field IP ID 3 bits flags and offset IP header checksum UDP header checksum (in case of UDP datagram) Precedence bits DF bits echoing IP ID filend (linux 2.4.0-2.4.4 kernels) IP ttl field (ttl distance to the target has to be precalculated to guarantee accuracy).
ICMP responses based TCP/IP stack fingerprinting TOS field An ICMP error message is always sent with the default TOS (0x0000) An ICMP request message may be sent with any value in the TOS An ICMP reply message is sent with the same value in the TOS ICMP Error Message Quoting Size: ICMP error Message echoing integrity Using difererent from zero code fields in ICMP echo requests Using DF bit echoing with ICMP query messages Other ICMP messages: ICMP timestamp request ICMP Information request ICMP Address mask request
侵入技術の紹介 IP Fragment ID Scan( 調査 )
ポートスキャンの送信元 IPアドレスの隠蔽や パケットフィルタリングの回避に利用する侵入技術の一つ hping.orgのsalvatore Sanfilippo 氏が確立 検証用ツールとしてhping.orgのhping2や insecure.orgのnmapがある Insecure.org ( http://www.insecure.org/nmap/ ) hping.org ( http://www.hping.org/ )
IP Fragment ID Scan は次の 2 点に着目して対象ホストのポートの開閉を判断 フラグメント化された IP パケットの再構築に利用される ID(Identification) が 殆どの OS で推測が容易 SYN+ACK パケットや RST+ACK パケットに対するレスポンスの有無
IP Fragment ID Scan を行うには 次の 3 台が必要 ポートスキャンを行う Scanner host ポートスキャンの結果を受信するReceiver host ポートスキャンの対象となるVictim host Receiver host には ID が推測しやすいホストを選ぶ
の一例 NMAP の idle scan オプション (-si) を設定するだけで IP Fragment ID Scan が可能 ( 例 ) # nmap -n -P0 -si 192.168.1.12 192.168.1.45 Idlescan using zombie 192.168.1.12 (192.168.1.12:80); Class: Broken little-endian incremental Interesting ports on (192.168.1.45): (The 1546 ports scanned but not shown below are in state: closed) Port State Service 135/tcp open loc-srv 139/tcp open netbios-ssn Nmap run completed -- 1 IP address (1 host up) scanned in 10 seconds
の仕組み IP Fragment ID Scan は Scanner host が Receiver host の IP アドレスに偽装して Victim Host にポートスキャンを行い Victim Host から返信されるパケットが Receiver host の ID に及ぼす影響の有無を検出することで成立
の仕組み Scanner から Receiver へ ID 検出用 SYN パケットを連続送信 Scanner host 192.168.1.2 SYN SYN+ACK Receiver host 192.168.1.1 Victim host 192.168.1.17
の仕組み hping2 を使った ID 検出 (Scanner Receiver) ( 例 ) # hping2 -n -r -S 192.168.1.1 -p 80 eth0 default routing interface selected (according to /proc) HPING 192.168.1.1 (eth0 192.168.1.1): S set, 40 headers + 0 data bytes 46 bytes from 192.168.1.1: flags=sa seq=0 ttl=128 id=55829 win=8576 rtt=1.3 ms 46 bytes from 192.168.1.1: flags=sa seq=1 ttl=128 id=+256 win=8576 rtt=1.0 ms 46 bytes from 192.168.1.1: flags=sa seq=2 ttl=128 id=+256 win=8576 rtt=1.0 ms 46 bytes from 192.168.1.1: flags=sa seq=3 ttl=128 id=+256 win=8576 rtt=1.0 ms 46 bytes from 192.168.1.1: flags=sa seq=4 ttl=128 id=+256 win=8576 rtt=1.0 ms
の仕組み Receiver の IP に偽装して Scanner から Victim に SYN パケット送信 Scanner host 192.168.1.2 SYN SYN+ACK SYN src:192.168.1.1 dst:192.168.1.17 dst-port:80 Receiver host 192.168.1.1 Victim host 192.168.1.17
の仕組み Victim は受け取った SYN パケットのレスポンスを Receiver に送信 Scanner host 192.168.1.2 SYN SYN+ACK Receiver host 192.168.1.1 SYN+ACK or RST+ACK Victim host 192.168.1.17
の仕組み Victim は受け取った SYN パケットのレスポンスを Receiver に送信 Scanner host 192.168.1.2 SYN SYN+ACK SYN+ACK RST を返信 Receiver host 192.168.1.1 RST+ACK 反応しない Victim host 192.168.1.17
の仕組み Victim の 80 番ポートが開いている場合 46 bytes from 192.168.1.1: flags=sa seq=30 ttl=128 id=+256 win=8576 rtt=1.1 ms 46 bytes from 192.168.1.1: flags=sa seq=31 ttl=128 id=+512 win=8576 rtt=1.6 ms 46 bytes from 192.168.1.1: flags=sa seq=32 ttl=128 id=+256 win=8576 rtt=1.5 ms Victim の 80 番ポートが閉じている場合 46 bytes from 192.168.1.1: flags=sa seq=11 ttl=128 id=+256 win=8576 rtt=1.1 ms 46 bytes from 192.168.1.1: flags=sa seq=12 ttl=128 id=+256 win=8576 rtt=1.1 ms 46 bytes from 192.168.1.1: flags=sa seq=13 ttl=128 id=+256 win=8576 rtt=1.1 ms
侵入技術の紹介 受動的攻撃 ( 検証 )( 移動 )
受動的攻撃 Georgi Guninski 氏やJuan Carlos Cuartango 氏が発見し続けているWebBrowserの脆弱性と 従来の侵入技術を掛け合せた複合型侵入技術 増殖と破壊 を重視するウィルスとは異なり コマンドやファイルの実行 を重視した攻撃 攻撃対象側から攻撃の流れが始まるので 従来のセキュリティ製品では対策が困難
受動的攻撃 攻撃対象の行動を引き金として攻撃が始まるので 成功率やタイミングが攻撃対象によって大きく異なる 受動的攻撃検証サイトでサンプルファイルや報告書を公開 受動的攻撃検証サイト ( http://isweb27.infoseek.co.jp/computer/zaddik/ )
受動的攻撃の一例 不適切な MIME ヘッダーが原因で Internet Explorer が電子メールの添付ファイルを実行する (MS01-020) という致命的な脆弱性を受動的攻撃の起爆剤として利用 ( 例 ) <IFRAME> タグを使い添付ファイルを表示するように HTML を記述した拡張子.eml のファイルを作成 任意のコマンドが書かれたバッチファイルや実行ファイルを MIME 形式に変換 MIME 形式に変換された悪意のあるファイルの MIME ヘッダーにある Content-Type の値を audio/x-wav に変更して 作成した拡張子.eml のファイルに追加 Web サーバにファイルを置いて 攻撃対象のユーザーがファイルを表示するのを待つ
受動的攻撃の流れ 攻撃対象ユーザーが.eml ファイルを表示 1..eml ファイルを要求 2..eml ファイルを送信 Web サーバ 攻撃対象
受動的攻撃の流れ.eml に書かれた <IFRAME> と不適切な MIME ヘッダーにより ユーザーの許可なく添付ファイルを実行 Web サーバ 攻撃対象 3. 添付ファイルを実行
受動的攻撃の流れ 実行された添付ファイルの内容に従って 自己破壊や他のホストへの攻撃 backdoor の設置 シェルやファイルの転送などを開始 シェルの転送 Webサーバ他のホストを攻撃 攻撃対象 4. 攻撃開始
受動的攻撃の可能性 セキュリティ製品に保護された環境への侵入 Web サーバ ( 侵入者 ) I.N DMZ 社内 Web サーバ 社員 社内サーバ
受動的攻撃の可能性 セキュリティ製品に保護された環境への侵入 Web サーバ ( 侵入者 ) I.N DMZ 社内 Web サーバ 社員 社内サーバ
侵入技術の紹介 File Transfer Techniques( 移動 )
報告書作成中につき公開延期 ( 今年度中の報告書公開を予定しています )
侵入技術の紹介 最後に
最後に 侵入技術は常に進化し続けているので 侵入対策も常に進化し続けることが必要 進化し続ける侵入技術に対応するには 侵入対策 だけではなく 事後対策 も必要 単に対策を 設定 設置 するのではなく 動作確認 限界確認 をすることが必要 侵入技術を用いた定期的な調査が必要