Конкурс IDS Bypass проходил на конференции Positive Hack Days уже в третий раз (разбор одного из прошлых конкурсов). В этом году мы сделали шесть игровых узлов с флагом на каждом. Для получения флага участнику предлагалось либо проэксплуатировать уязвимость на сервере, либо выполнить другое условие, например перебрать списки пользователей в домене.  Сами задания и уязвимости были достаточно простыми. Сложность представлял обход IDS: система инспектирует сетевой трафик от участников специальными правилами, которые ищут атаки. Если такое правило срабатывает, сетевой запрос участника блокируется и бот присылает ему текст сработавшего правила в Телеграм.  И да, в этом году мы попробовали уйти от привычных CTFd и журналов IDS в сторону более удобного телеграм-бота. Для участия необходимо было всего лишь написать боту и выбрать имя пользователя. Затем он присылал OVPN-файл для подключения к игровой сети, и в дальнейшем все взаимодействие (просмотр заданий и игрового дашборда, сдача флагов) происходило только через бота. Этот подход оправдал себя на 100%!  Визуализация конкурса в этом году превзошла все ожидания. На стенде стояло семь ЭЛТ-телевизоров: по телевизору на каждое задание и один для общей информации. На экраны выводились дашборд, информация о числе участников и о количестве взломов сервисов.  Число участников в этом году было рекордным. Отчасти этому способствовало и то, что IDS Bypass был доступен любому участнику онлайн и продолжался ночью: на момент завершения конкурса главное табло показывало 101 участника, примерно четверть из которых решили хотя бы одно задание. В общей сложности IDS Bypass длился почти 30 часов. Теперь перейдем к разбору заданий. Стоимость задания составляла 20 очков, но уменьшалась на одно очко за каждое решение. Из названия понятно, что необходимо было проэксплуатировать нашумевшую недавно уязвимость Log4Shell в популярной библиотеке log4j. В качестве уязвимого приложения использовался докер-контейнер. Тут же приведен эксплойт: Такую атаку обнаруживает IDS, и участник видит, например, следующее сообщение: ATTACK [PTsecurity] log4j RCE aka Log4Shell TCP attempt (CVE-2021-44228) Несколько месяцев назад, вскоре после размещения эксплойта для Log4Shell, стали публиковаться различные его варианты для обхода WAF и IDS. Например, в репозитории на GitHub приведен тот же эксплойт, но с обфускацией управляющих конструкций. Итоговый запрос, который эксплуатирует уязвимость и обходит IDS, может быть таким: Отдав полезную нагрузку и приняв подключение к порту 4444, получаем флаг: flag{L0g_FOR_Wh4t?} Одна из недавно найденных уязвимостей Zabbix — CVE-2022-23131. Эта уязвимость в механизме авторизации SSO позволяет подменить куки и войти в Zabbix без авторизации с учетной записью администратора. Эксплойт размещен на GitHub, и он обнаруживается одним из трех IDS-правил: ET EXPLOIT Zabbix v5.4.0 - 5.4.8 SSO/SALM Auth Bypass (CVE-2022-23131) M1 ET EXPLOIT Zabbix v5.4.0 - 5.4.8 SSO/SALM Auth Bypass (CVE-2022-23131) M2 ET EXPLOIT Zabbix v5.4.0 - 5.4.8 SSO/SALM Auth Bypass (CVE-2022-23131) M3 Эти правила открыты и доступны для скачивания. Распространяются они вместе с ET Open Ruleset. Вот, например, как выглядит первое правило: Многие участники воспользовались другим популярным эксплойтом. Если раскомментировать в нем строку 62, то эксплойт выводил значение куки zbx_session, которое нужно было задать в браузере: Таким образом участник должен был попасть в панель администратора Zabbix. Но проделав этот путь, он получал оповещение от IDS: ET EXPLOIT Zabbix v5.4.0 - 5.4.8 SSO/SALM Auth Bypass (CVE-2022-23131) M1 Чтобы обойти IDS, многие участники закодировали значение куки zbx_session в URL encoding: Это наглядный пример того, что задания на IDS Bypass могут иметь несколько решений. Изначально задумывался обход конкретного правила. Например, после декодирования мы получаем такое содержимое куки zbx_session: {"saml_data": {"username_attribute": "Admin"}, "sessionid": "fdbd6cbbbb21133df4376e4c4af74920", "sign": "DChdvVPpnlFA0JjTUCWiGZFZefz9ML2yqNZno5ORDPx2Chhb7HNUeuV4O7d0af9OgyoON68ObgNZH30hgWW76Q=="} Фрагменты base64 из правила IDS декодируются следующим образом: "username_attribute": "saml_data Поставив пробел перед двоеточием в ключе username_attribute, мы не нарушим структуру json, но обойдем IDS-правило выше. Это тоже приводит к получению флага (поля sessionid и sign необязательны): Cookie: zbx_session= eyJzYW1sX2RhdGEiIDp7InVzZXJuYW1lX2F0dHJpYnV0ZSIgOiJBZG1pbiJ9LCAic2Vzc2lvbmlkIjoiIiwic2lnbiI6IiJ9  Флаг скрывался в списке пользователей Zabbix. В тексте задания говорилось о том, что участнику необходимо перебрать список пользователей в домене EVIL.CORP по протоколу Kerberos. Имена пользователей имеют строго оговоренный формат: user[1..16]_[a..z0..9]. Казалось бы, что может пойти не так? Однако в задании упоминалась некая система защиты, основанная на ML… Для перебора пользователей подойдет любой инструмент (например, kerbrute). Генерируем список пользователей и запускаем перебор:  kerbrute -dc-ip 10.0.0.145 -domain evil.corp -threads 2 -users usernames.txt; Почти сразу мы получаем оповещения от IDS (по одному на каждый тред). Некоторые участники ставили количество тредов, равное количеству пользователей, но успеха это, конечно, не принесло: ANOMALY [PTsecurity] Your traffic looks like kerberos user enumeration (Too many usernames). Blocked for 300 seconds Мы получаем не только срабатывание правила, но и блок на пять минут. Есть время подумать. Аббревиатура ML в тексте задания нужна только для устрашения. Вместо ML — простой алгоритм, который увеличивает счетчик, если обнаруживает попытки входа под разными пользователями, и уменьшает счетчик, если пользователь повторяется. Срабатывание происходит, если счетчик достигает порогового значения. Для обхода этого алгоритма достаточно добавить каждого пользователя в список три раза подряд. Тогда kerbrute заработает с двумя потоками: Получаем флаг d2de3e88e1fa800fbed902a999511e33 за 6 минут 40 секунд. При выполнении этого задания, просканировав порты узла 10.0.0.21, участник обнаруживал лишь порт 445. Зайдя по SMB на узел любым клиентом, участник находил только одну доступную анонимному пользователю шару: Знание The Lord of the Rings в этом задании ограничивается лишь тем, что пользователя зовут sammy. Предприняв попытку логина под этим пользователем, участник получал оповещение (в файле users.txt ведь написано, что IDS хорошая), причем smbclient из набора samba-tool и smbclient.py из библиотеки Impacket выдавали разные оповещения: Как правило, тот пакет, который блокирует IDS и после которого присылает оповещение, и является причиной этого оповещения. Записав свой сетевой трафик перед алертом, участник обнаруживал, что IDS блокировала пакет NTLMSSP с сообщением NTLMSSP_AUTH. Сравнив эти пакеты, полученные от двух упомянутых инструментов, можно было обнаружить, что один инструмент (smbclient.py) не задавал значение поля Host name в сообщении NTLMSSP_AUTH, а другой задавал. Узел автора на скриншоте ниже, например, назывался UBUNTU1. Дело оставалось за малым — перебрать имя узла, начиная с первой буквы, и найти верное. Проценты в названии алерта помогали участнику понять, что он подобрал следующий символ верно. Необходимый узел назывался SAMDESKTOP.  Это задание похоже на один из механизмов обнаружения злоумышленников, когда они используют пользовательские учетные записи с необычных узлов. Чем сложнее задание, тем больше его стоимость, и наоборот. Это задание решил лишь один участник — psih1337, тем самым обеспечив себе первое место. Участникам были даны домен ABC.XYZ и узел с именем DC. Данные учетной записи sammy:samm3P@ssw0rd велено было взять из предыдущего задания. На узле было всего два открытых порта: 88 и 445. Этот набор портов как бы намекал на то, что участнику необходимо было получить Kerberos-билет и с его помощью попасть по SMB в шару. Механизм авторизации NTLM был отключен в этом задании. smbclient.py -k -dc-ip 10.0.0.233 ABC.XYZ/sammy:samm3P@ssw0rd@DC  После такой команды участник получал оповещение: ATTACK [PTsecurity] Block TGS request with probably malicious TGT ticket  IDS заблокировала TGS-запрос для сервиса cifs/DC, так как в нем содержался вредоносный TGT-билет. Слово «вредоносный» здесь не имеет прямого значения, а вся фраза лишь помогала участнику обратить внимание на TGT-билет. Оставалось три часа до окончания конкурса, а решить это задание никто не мог. Тогда были даны две подсказки: Hint for task ABC: Do not stick to the TGT details. Take a look at the whole picture  Hint 2 for task ABC: How many ways of getting TGT you know?  Участник psih1337 смог обойти защиту IDS и добыть флаг, но помогла ему в этом его операционная система (удивительно, но это действительно так): TGS-запрос имеет внушительный размер (около полутора килобайт) и превышает стандартный MTU, поэтому сетевому стеку приходится разбивать один запрос на два TCP-фрагмента. Выглядит это следующим образом: Блокирующее правило проверяло контент в начале и в конце пакета — так устроены Kerberos-запросы. Пока ОС разбивала пакеты таким же образом, как на картинке, проблем с обнаружением и блокированием атаки не возникало. Однако спустя три TGS-запроса без ответа сетевой стек Windows разбивал запрос на три более мелкие части размером около 500 байт. Блокирующее правило не справилось с таким трюком и пропустило выдачу TGS-билета. Как результат, был получен флаг. Сетевой стек на Linux ведет себя другим образом и не разбивает пакет на более мелкие фрагменты. Поскольку заложенный вектор решения не был реализован, задание переносится на следующий IDS Bypass, где описанный способ уже не будет работать. Описание задания не соответствует действительности! Оно было самым простым и имело множество решений. На узле был расположен веб-сервер. В форму нужно было ввести IP-адрес, чтобы сервер послал флаг на этот узел. Введя свой адрес (10.8.0.26), участник получал оповещение: ATTACK [PTsecurity] IP address in URL. Probably code execution exploit Механизм срабатывания максимально прост: правило для IDS ищет IP-адрес в строке URL регулярным выражением: \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}. Сервер же, напротив, использует введенный пользователем IP-адрес в качестве адреса назначения в Scapy, чтобы отправить ICMP-пакет на указанный узел. Как известно, существует множество форм представления IP-адреса и многие из них принимаются сетевыми утилитами. Вот те решения, которые мы увидели на конкурсе: 10.8.0000.26 168296474 10.8.0x0.26 Доменное имя В результате сервер присылал флаг в виде пакета ICMP echo.  Надеемся, участники получили удовольствие, решая это задание. Это был огонь! Борьба за призовые места шла до последней минуты: участник Abr1k0s закончил перебирать пользователей в таске EVIL.CORP за минуту до конца конкурса и ворвался на 3-е место со 111 очками. Тем самым он на одно очко опередил участника, оказавшегося на 4-м месте. Победители получили денежные призы и сувениры. Результаты: 1️⃣ psih1337 2️⃣ OneManTeam 3️⃣ Abr1k0s 💰 Очки: 162 💰 Очки: 121 💰 Очки: 111 🏅 Решено заданий: 6 🏅 Решено заданий: 5 🏅 Решено заданий: 5 Спасибо всем! В следующем году мы приготовим для вас еще более интересные задания. Увидимся на PHDays 12!