[Информационная безопасность, Спортивное программирование, IT-инфраструктура, Конференции] Защищаем кибергород с PT Application Firewall: полезные правила для обнаружения хакеров
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет! Ранее мы делились итогами работы песочницы PT Sandbox на The Standoff. Продолжаем традицию — теперь черед PT Application Firewall. Посвящаем этот материал истории о том, как на кибербитве отработал наш межсетевой экран уровня приложений. Мы расскажем, как глобальный SOC The Standoff, состоящий из специалистов нашего PT Expert Security Center, готовил PT Application Firewall к игре, какие хитрости мы использовали при написании правил, с чего мы начинали на The Standoff и что нового почерпнули. Некоторые результаты работы продукта на кибербитве стали для нас бесценными, и мы точно используем их в будущем.В этот раз киберполигон включал шесть компаний, у каждой из которых была корпоративная сеть, в точности имитирующая реальную — с внешними сервисами, DMZ и сегментацией. Чтобы пробраться внутрь сети, атакующим предстояло пройти периметр. Для этого можно было найти уязвимость во внешнем сервисе, проэксплуатировать ее и закрепиться или использовать фишинговую рассылку с вредоносным вложением, которое открыло бы атакующим доступ из внешнего мира напрямую в пользовательскую сеть компании. Но основным вектором проникновения стали атаки на веб-ресурсы — примерно 90%.
На периметре каждого из шести офисов было заложено от 5 до 8 веб-уязвимостей разного уровня сложности. Простые уязвимости атакующие легко находили и могли сдавать их в программу Bug Bounty, за что получали очки. При этом серверы не имели внутреннего интерфейса и не давали пройти дальше. Чтобы пробраться внутрь, командам атакующих надо было найти и проэксплуатировать уязвимость удаленного исполнения кода средней или высокой сложности.Все веб-ресурсы были под защитой PT Application Firewall, но тот работал в режиме мониторинга и не блокировал запросы, а только логировал их. Это позволяло синим командам видеть все действия атакующих, но не препятствовало проведению атак.Атаки на веб в цифрахПриведем статистику того, сколько всего атак мы зафиксировали за четыре дня противостояния:
Рисунок 1. Количество атак, зафиксированных PT Application FirewallДалее на графике можно увидеть распределение атак по времени и критичности:
Рисунок 2. График атак на веб-ресурсы офисов за четыре дня The StandoffОсновные пики мы видим после обеда в первый день, когда атакующие уже исследовали инфраструктуру, изучили доступные веб-сервисы и начали активно искать уязвимости в них, а также во второй и третий день. В последний день игры уже практически все команды получили доступы в офисы и сосредоточились на продвижении внутри сети.Теперь разберем время прохождения периметра. Первый отчет о выявлении уязвимости глобальный SOC получил на 23-й минуте игры. Это была Path Traversal, которая позволяла читать произвольные файлы на сервере. Атакующие первым делом вытащили /etc/passwd.Первый отчет о найденной RCE-уязвимости мы получили от команды TSARKA на 40-й минуте игры. Хотя наши аналитики SOC увидели эксплуатацию намного раньше: примерно через минуту после первой успешной команды, выполненной в 10:22.
Рисунок 3. Успешный вывод команды phpinfo(). Фрагмент запроса и тела ответаЧто позволило нашим аналитикам так быстро обнаружить атаку?Как найти успешные атакиПервый день кибербитвы. В 10:00 атакующие получили доступ к инфраструктуре, в 10:03 запустили сканеры. В 10:08 PT Application Firewall зафиксировал 4359 атак высокого уровня и 12 269 — среднего:
Рисунок 4. PT Application Firewall в первые восемь минут игрыАтакующие вооружились сканерами и стали добавлять кавычки и другой вредоносный контент во все поля, которые находили. За пять минут мы увидели, что PT Application Firewall выдал большее количество сработок, чем то, на которое аналитик в состоянии отреагировать. И среди них не было ложноположительных. Действительно, каждый запрос подходил под паттерн, например SQL-инъекции или File Inclusion.Домашние заготовкиНам было важно отследить удачные попытки атакующих использовать уязвимости, особенно те, что позволяли исполнить произвольный код (RCE).Изначально мы не знали, какие уязвимости будут заложены в веб-сервисы офисов. Единственное, что мы могли, — это изучить сами приложения и их функциональные возможности. Все, как в реальной жизни. А дальше мы следили за атакующими и теми уязвимостями, которые они находили. Чтобы эффективнее фильтровать сработки, еще до старта мы написали очень простое правило, которое впоследствии сильно нам помогло. Как атакующие понимают, что могут исполнять код? Правильно: читают /etc/passwd, выполняют whoami или id, ping и другие простые команды. А потом смотрят ответ сервера и ищут паттерны вывода этих команд. Нам тоже нужно было увидеть вывод команд в ответах сервера. Для этого мы написали следующее правило:
Рисунок 5. Фрагмент правила для обнаружения успешного исполнения кодаЕсли в запросе есть id, а в ответе что-то подходящее под паттерн uid=\d+\(.*\) — о да, атакующие получили RCE.Если в запросе есть whoami, а в ответе www-data, tomcat или apache, то это, скорее всего, преуспели атакующие. Сюда можно включить bitrix и другие распространенные учетные записи, от имени которых работают веб-сервисы. Но мы ориентировались на то, что действительно было в инфраструктуре, чтобы минимизировать количество ложных срабатываний.Проблемы были с выводом команды ls. Сложно найти паттерн, если заранее не знаешь, в какой папке атакующие получат возможность исполнить код и какие файлы там лежат. Поэтому мы пошли на компромисс: мы искали паттерн вывода не ls, а ls -la: (dwrx|-rw) — действительно мало страниц содержат информацию о разрешениях файлов. Если на вашем сайте такие есть, то PT Application Firewall позволяет добавить исключение по URL или пути запроса.Что получилосьСпустя 23 минуты мы поймали первый вывод phpinfo(). Этого было достаточно, чтобы создать правило для конкретной уязвимости. Мы знали, что POST-запрос по пути /cockpit/auth/check позволяет исполнить код, который специальным образом передается в теле запроса. Это уязвимость в CMS Cockpit версии 0.6.1. Вышло вот так:
Рисунок 6. Правило на RCE-уязвимость в CMS CockpitНам даже показалось, что мы нашли успешное исполнение команды раньше, чем это сделали атакующие. Они запустили сканер и оставили его на несколько минут. К моменту, когда они увидели результаты и стали раскручивать полученную уязвимость, наше правило было уже готово и вовсю отлавливало хакеров. Вот такое мы ловили правилом [BB] Cockpit CMS RCE:
Рисунок 7. Выполнение команд атакующими через найденную уязвимость в CMS CockpitНа самом деле этот запрос поймали и стандартные правила, которые есть у каждого, кто использует PT Application Firewall. Они ищут паттерны веб-атак в запросах, не определяя их успешность, что позволяет остановить атакующих еще до того, как те смогут исполнить свои злые намерения. Несомненно, в реальной жизни такие запросы нужно сразу блокировать! Но на киберполигоне у нас была другая задача, так как PT Application Firewall работал в режиме мониторинга: среди тысяч запросов от сканеров нам нужно было выделить удачные попытки эксплуатации.Всего в ходе игры мы оперативно написали более 30 правил для уязвимостей различного типа. Вот некоторые из них:AlienSec — это сайт, предназначенный для отображения содержимого файлов на сервере. Изначально атакующим предстояло найти уязвимость Local File Inclusion, прочитать через нее исходный код приложения и понять, что уязвимым к RCE параметром является filename по пути /2591c98b70119fe624898b1e424b5e91.php. Сложность эксплуатации этой ошибки имеет средний уровень сложности. В итоге ее сумели найти и успешно проэксплуатировать три команды. 
Рисунок 8. Выполнение команд через уязвимость AlienSecUbuntu YAML — очень простая для эксплуатации уязвимость: нужно передать код в параметре на ext.php. Легко обнаруживается сканерами.
Рисунок 9. Атакующие выводят версию PHP, установленную на уязвимом сервереphpCollab — система управления проектами. Версия 2.7.2 и ниже позволяют неавторизованным пользователям загрузить произвольные файлы на сервер и исполнить код от имени www-data. Подробнее об уязвимости и ее эксплуатации можно почитать по ссылке. Ошибка имела низкий уровень сложности, но тем не менее только шесть команд смогли ее обнаружить.
Рисунок 10. Выполнение команды uname -a через уязвимость в phpCollabFileHosting стал одним из самых популярных сервисов у атакующих — 26 команд смогли провести успешные атаки. Скорее всего, это связано с количеством и разнообразием заложенных уязвимостей (SQLi, RCE, XSS, Path Traversal) и их простотой. Сервис представляет собой хранилище файлов, позволяет загружать и просматривать документы. Написан на Python Flask.
Рисунок 11. Пример атаки Path Traversal на приложение FileHosting. Атакующие читают исходный код FlaskНо, наверное, самое интересное, что мы смогли поймать, — это RCE в base64-encoded cookie. Отчасти это было даже случайно. Когда мы готовили наше большое правило для обнаружения успешных RCE, мы поспорили: а действительно ли стоит искать паттерн в запросе и в ответе? С одной стороны, это позволит минимизировать число ложноположительных срабатываний, с другой, у нас будут все шансы пропустить то, что мы не предусмотрели заранее. В итоге мы пришли к выводу, что такое правило лишним не будет. Оно получилось похожим на первое, только не проверяло запрос, а лишь искало специфичный вывод в ответе. Написали и забыли. Но в какой-то момент в ходе игры мы поймали сработку, где в запросе не было ничего, а вот в ответе…
Рисунок 12. Ответ на с виду обычный запросЕсли вы внимательно посмотрите, значение Cookie user_id было следующим: dW5hdXRob3Jpc2VkOyBpZDs, что при декодировании превратилось в unauthorised; id;. И у нас появилось правило [BB] Tomcat cookie RCE — оно декодирует параметр user_id заголовка Cookie и ищет в нем признаки выполнения команд операционной системы.
Рисунок 13. Правило [BB] Tomcat cookie RCEНовый уровень понимания действий атакующихА дальше нам стало интересно отслеживать не отдельные сработки, а цепочки исполнения команд атакующими. Поэтому мы стали коррелировать события.В правиле корреляции мы объединяли сработки успешных RCE в атаки по CLIENT_IP и REQUEST_PATH. То есть мы стали собирать все запросы от одной команды по одному пути вместе. И в этот момент нам стало понятнее, что делают атакующие, так как мы смогли наглядно разделить цепочки действий по командам и часто даже между членами одной команды — когда ребята параллельно пытались раскрутить сразу несколько найденных уязвимостей.
Рисунок 14. Атакующие скачали и запустили майнер через полученную RCE-уязвимостьЭто было первое, но далеко не единственное, что нам удалось получить от корреляций. Их суть в том, чтобы обнаруживать такие атаки, где каждое действие по отдельности кажется нормальным, но последовательность запросов может быть опасной. Самое простое и очевидное — перебор пользователей на GitLab через API. API для того и создан, чтобы можно было быстро автоматизированными средствами получить информацию. Но, согласитесь, подозрительно, что кто-то забирает информацию обо всех пользователях:
Рисунок 15. Атакующие перебрали 1000 пользователей GitLab за минутуБлагодаря корреляциям, мы обнаружили, что система CMS Cockpit была уязвима не только к RCE, но и к User Enumeration (перебору пользователей) через восстановление пароля. Если в POST-запросе на страницу /cockpit/auth/requestreset отправлялось имя существующего пользователя, то страница возвращала ответ Recovery email sent, иначе — User not found. Что интересно, в JSON можно было отправить не только полное имя пользователя, но и регулярное выражение. И если хотя бы одно имя пользователя под него подходило, то такому пользователю отправлялось электронное письмо с инструкциями по восстановлению пароля. Уязвимость не самая опасная, да и атакующие, скорее всего, первым делом попробовали имя Admin. Но тем не менее знать о такой «особенности» работы своего приложения всегда полезно. Еще полезнее — иметь правило, позволяющее обнаружить и заблокировать подозрительную активность.
Рисунок 16. Атакующие обнаружили имя зарегистрированного пользователя последовательностью запросовА что с рискамиНо все же главной целью атакующих был не поиск уязвимостей. Для каждой из шести компаний был сформирован список событий — бизнес-рисков, реализация которых в реальной жизни могла бы стать фатальной для бизнеса. И вот за решение этой задачи команды красных получали больше всего баллов — все как в реальной жизни, но вместо денег — очки.В офисе Heavy Ship Logistics, компании, которая занимается перевозками, был определен риск «Сбой системы регистрации пассажиров». А задание было следующим: продемонстрировать возможность зарегистрировать на рейс пять пассажиров. Звучит как корреляция!
Рисунок 17. Запрос, отправляемый приложением при регистрации пассажира на рейс В данном случае мы ждали более пяти событий за не очень большой промежуток времени с одного IP-адреса и в рамках одной сессии. Чтобы это отследить, нам пришлось добавить в правило значения заголовка Cookie: они могли быть любыми, но сессионные cookie должны были попасть в MATCHED.VARIABLE_NAME, чтобы бы мы могли скоррелировать запросы.Другой интересный риск, реализацию которого нам удалось обнаружить с помощью PT Application Firewall, — удаление информации о штрафах граждан. Суть задания была в изменении записи в базе данных городского портала. А именно: надо было изменить размер штрафа пользователя Todd Smith. И атакующие могли действовать любым удобным способом — никто заранее не знал, каким путем можно пойти. Одна команда атакующих, видимо, сильно хотела быть первой и решила не искать нужный идентификатор штрафа. Получив права администратора портала, они перехватили запрос на удаление штрафа и просто перебором идентификаторов очистили базу со штрафами:
Рисунок 18. Пример запроса на удаление штрафаИнтересно, но не по заданию. Организаторам пришлось восстанавливать всю базу данных. Хотя команда глобального SOC была очень благодарна. Теперь мы знали, что нужный штраф имеет идентификатор 9, а номер документа — 6534 976653. Нам осталось только выяснить, как атакующие получили необходимые права на портале. Для этого мы провели небольшой ретроспективный анализ по IP-адресу. Поле авторизации на портале оказалось уязвимым к SQL-инъекции:
Рисунок 19. Запрос для обхода авторизации на портале 25HНа самом деле анализ был большой и трудоемкий. Запросов было много, и почти все возвращали ответ 302 (redirect), то есть мы не могли сказать точно, была ли авторизация удачной, так как в любом случае перенаправление осуществлялось на главную страницу. Нам пришлось повторить вручную множество запросов атакующих, прежде чем мы смогли авторизоваться на портале под пользователем BIGBOSS. В результате мы написали правило: если при запросе на страницу /index.php?page_controller=create_fine пользователь видит номер документа 6534 976653 и кнопку «Delete» fine, то, скорее всего, команда атакующих получила доступ на портал с правами, достаточными для удаления штрафа. И конечно, мы не забыли правило для уязвимого к SQL-инъекции поля. Некоторое время спустя мы поймали авторизацию другой команды — также через SQL-инъекцию. А еще чуть позже третья команда реализовала риск, на этот раз точно в соответствии с заданием:
Рисунок 20. Одна из команд изменяет размер штрафа с id=9Информация к размышлениюThe Standoff — это четыре дня напряженной работы, за которые мы приобрели тонну опыта. Прежде всего кибербитва — это шанс отработать навыки оперативного реагирования: выявлять реальные веб-уязвимости и мгновенно писать правила, позволяющие их закрыть. За четыре дня мы написали более 30 правил, которые помогали выявлять атакующих на первых шагах входа в инфраструктуру и уже прицельно следить за дальнейшим развитием векторов реализации рисков.Конечно, в реальной жизни при обнаружении подобных уязвимостей самое верное — это устранять их на уровне кода приложения. Но это небыстрый процесс, поэтому оперативное написание правила, блокирующего вредоносные запросы, является важной задачей команды защиты. В повседневной жизни специалисты PT Expert Security Center каждый день анализируют тысячи запросов к веб-ресурсам наших клиентов, чтобы обнаруживать новые векторы атак на всевозможные системы и противодействовать им.Главным показателем нашей работы как глобального SOC стало то, что мы полностью понимали ход игры, знали, где есть уязвимости, где команды находятся в конкретный момент, и в большинстве случаев видели реализацию рисков задолго до получения отчета от атакующих. Киберполигон The Standoff — отличный шанс найти пробелы в собственных знаниях и стать лучше, расти и совершенствовать подходы к мониторингу.Автор: Юлия Фомина, специалист отдела мониторинга информационной безопасности PT Expert Security Center
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Финансы в IT] Банки заявили о росте кибератак на свои системы
- [Информационная безопасность] Как Россия поднялась на 5 место в «международном индексе кибербезопасности»
- [Информационная безопасность, Конференции, Социальные сети и сообщества] Конференция RSA извинилась за твит с призывом усилить безопасность протокола TCP/IP блокчейном
- [Информационная безопасность, Криптография, IT-компании] Операторы криптовымогателя REvil потребовали $ 70 млн выкупа
- [Платежные системы, Разработка под Android, Администрирование баз данных, Финансы в IT] Запускаем softPOS. Почему пилоты бывают полезны не только бизнесу, но и разработчикам
- [Usability, Разработка под e-commerce, Управление продажами, Управление персоналом, Поисковая оптимизация] Как №1 влияет на всю последовательность
- [Информационная безопасность, Исследования и прогнозы в IT] InfoWatch: доля умышленных утечек персданных в РФ превышает мировую
- [Информационная безопасность, Социальные сети и сообщества] Социальную сеть сторонников Трампа Gettr взломали в день запуска
- [Open source] Сайт Pudn был закрыт
- [Ненормальное программирование, Open source, Обработка изображений, Программирование микроконтроллеров] Benchmark OpenCV на STM32
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_sportivnoe_programmirovanie (Спортивное программирование), #_itinfrastruktura (IT-инфраструктура), #_konferentsii (Конференции), #_the_standoff, #_informatsionnaja_bezopasnost (информационная безопасность), #_vebprilozhenija (веб-приложения), #_vebujazvimosti (веб-уязвимости), #_napisanie_pravil (написание правил), #_patterny (паттерны), #_rce, #_hakery (хакеры), #_blog_kompanii_positive_technologies (
Блог компании Positive Technologies
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_sportivnoe_programmirovanie (
Спортивное программирование
), #_itinfrastruktura (
IT-инфраструктура
), #_konferentsii (
Конференции
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:21
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Всем привет! Ранее мы делились итогами работы песочницы PT Sandbox на The Standoff. Продолжаем традицию — теперь черед PT Application Firewall. Посвящаем этот материал истории о том, как на кибербитве отработал наш межсетевой экран уровня приложений. Мы расскажем, как глобальный SOC The Standoff, состоящий из специалистов нашего PT Expert Security Center, готовил PT Application Firewall к игре, какие хитрости мы использовали при написании правил, с чего мы начинали на The Standoff и что нового почерпнули. Некоторые результаты работы продукта на кибербитве стали для нас бесценными, и мы точно используем их в будущем.В этот раз киберполигон включал шесть компаний, у каждой из которых была корпоративная сеть, в точности имитирующая реальную — с внешними сервисами, DMZ и сегментацией. Чтобы пробраться внутрь сети, атакующим предстояло пройти периметр. Для этого можно было найти уязвимость во внешнем сервисе, проэксплуатировать ее и закрепиться или использовать фишинговую рассылку с вредоносным вложением, которое открыло бы атакующим доступ из внешнего мира напрямую в пользовательскую сеть компании. Но основным вектором проникновения стали атаки на веб-ресурсы — примерно 90%.  На периметре каждого из шести офисов было заложено от 5 до 8 веб-уязвимостей разного уровня сложности. Простые уязвимости атакующие легко находили и могли сдавать их в программу Bug Bounty, за что получали очки. При этом серверы не имели внутреннего интерфейса и не давали пройти дальше. Чтобы пробраться внутрь, командам атакующих надо было найти и проэксплуатировать уязвимость удаленного исполнения кода средней или высокой сложности.Все веб-ресурсы были под защитой PT Application Firewall, но тот работал в режиме мониторинга и не блокировал запросы, а только логировал их. Это позволяло синим командам видеть все действия атакующих, но не препятствовало проведению атак.Атаки на веб в цифрахПриведем статистику того, сколько всего атак мы зафиксировали за четыре дня противостояния:  Рисунок 1. Количество атак, зафиксированных PT Application FirewallДалее на графике можно увидеть распределение атак по времени и критичности:  Рисунок 2. График атак на веб-ресурсы офисов за четыре дня The StandoffОсновные пики мы видим после обеда в первый день, когда атакующие уже исследовали инфраструктуру, изучили доступные веб-сервисы и начали активно искать уязвимости в них, а также во второй и третий день. В последний день игры уже практически все команды получили доступы в офисы и сосредоточились на продвижении внутри сети.Теперь разберем время прохождения периметра. Первый отчет о выявлении уязвимости глобальный SOC получил на 23-й минуте игры. Это была Path Traversal, которая позволяла читать произвольные файлы на сервере. Атакующие первым делом вытащили /etc/passwd.Первый отчет о найденной RCE-уязвимости мы получили от команды TSARKA на 40-й минуте игры. Хотя наши аналитики SOC увидели эксплуатацию намного раньше: примерно через минуту после первой успешной команды, выполненной в 10:22.  Рисунок 3. Успешный вывод команды phpinfo(). Фрагмент запроса и тела ответаЧто позволило нашим аналитикам так быстро обнаружить атаку?Как найти успешные атакиПервый день кибербитвы. В 10:00 атакующие получили доступ к инфраструктуре, в 10:03 запустили сканеры. В 10:08 PT Application Firewall зафиксировал 4359 атак высокого уровня и 12 269 — среднего:  Рисунок 4. PT Application Firewall в первые восемь минут игрыАтакующие вооружились сканерами и стали добавлять кавычки и другой вредоносный контент во все поля, которые находили. За пять минут мы увидели, что PT Application Firewall выдал большее количество сработок, чем то, на которое аналитик в состоянии отреагировать. И среди них не было ложноположительных. Действительно, каждый запрос подходил под паттерн, например SQL-инъекции или File Inclusion.Домашние заготовкиНам было важно отследить удачные попытки атакующих использовать уязвимости, особенно те, что позволяли исполнить произвольный код (RCE).Изначально мы не знали, какие уязвимости будут заложены в веб-сервисы офисов. Единственное, что мы могли, — это изучить сами приложения и их функциональные возможности. Все, как в реальной жизни. А дальше мы следили за атакующими и теми уязвимостями, которые они находили. Чтобы эффективнее фильтровать сработки, еще до старта мы написали очень простое правило, которое впоследствии сильно нам помогло. Как атакующие понимают, что могут исполнять код? Правильно: читают /etc/passwd, выполняют whoami или id, ping и другие простые команды. А потом смотрят ответ сервера и ищут паттерны вывода этих команд. Нам тоже нужно было увидеть вывод команд в ответах сервера. Для этого мы написали следующее правило:  Рисунок 5. Фрагмент правила для обнаружения успешного исполнения кодаЕсли в запросе есть id, а в ответе что-то подходящее под паттерн uid=\d+\(.*\) — о да, атакующие получили RCE.Если в запросе есть whoami, а в ответе www-data, tomcat или apache, то это, скорее всего, преуспели атакующие. Сюда можно включить bitrix и другие распространенные учетные записи, от имени которых работают веб-сервисы. Но мы ориентировались на то, что действительно было в инфраструктуре, чтобы минимизировать количество ложных срабатываний.Проблемы были с выводом команды ls. Сложно найти паттерн, если заранее не знаешь, в какой папке атакующие получат возможность исполнить код и какие файлы там лежат. Поэтому мы пошли на компромисс: мы искали паттерн вывода не ls, а ls -la: (dwrx|-rw) — действительно мало страниц содержат информацию о разрешениях файлов. Если на вашем сайте такие есть, то PT Application Firewall позволяет добавить исключение по URL или пути запроса.Что получилосьСпустя 23 минуты мы поймали первый вывод phpinfo(). Этого было достаточно, чтобы создать правило для конкретной уязвимости. Мы знали, что POST-запрос по пути /cockpit/auth/check позволяет исполнить код, который специальным образом передается в теле запроса. Это уязвимость в CMS Cockpit версии 0.6.1. Вышло вот так:  Рисунок 6. Правило на RCE-уязвимость в CMS CockpitНам даже показалось, что мы нашли успешное исполнение команды раньше, чем это сделали атакующие. Они запустили сканер и оставили его на несколько минут. К моменту, когда они увидели результаты и стали раскручивать полученную уязвимость, наше правило было уже готово и вовсю отлавливало хакеров. Вот такое мы ловили правилом [BB] Cockpit CMS RCE:  Рисунок 7. Выполнение команд атакующими через найденную уязвимость в CMS CockpitНа самом деле этот запрос поймали и стандартные правила, которые есть у каждого, кто использует PT Application Firewall. Они ищут паттерны веб-атак в запросах, не определяя их успешность, что позволяет остановить атакующих еще до того, как те смогут исполнить свои злые намерения. Несомненно, в реальной жизни такие запросы нужно сразу блокировать! Но на киберполигоне у нас была другая задача, так как PT Application Firewall работал в режиме мониторинга: среди тысяч запросов от сканеров нам нужно было выделить удачные попытки эксплуатации.Всего в ходе игры мы оперативно написали более 30 правил для уязвимостей различного типа. Вот некоторые из них:AlienSec — это сайт, предназначенный для отображения содержимого файлов на сервере. Изначально атакующим предстояло найти уязвимость Local File Inclusion, прочитать через нее исходный код приложения и понять, что уязвимым к RCE параметром является filename по пути /2591c98b70119fe624898b1e424b5e91.php. Сложность эксплуатации этой ошибки имеет средний уровень сложности. В итоге ее сумели найти и успешно проэксплуатировать три команды.  Рисунок 8. Выполнение команд через уязвимость AlienSecUbuntu YAML — очень простая для эксплуатации уязвимость: нужно передать код в параметре на ext.php. Легко обнаруживается сканерами.  Рисунок 9. Атакующие выводят версию PHP, установленную на уязвимом сервереphpCollab — система управления проектами. Версия 2.7.2 и ниже позволяют неавторизованным пользователям загрузить произвольные файлы на сервер и исполнить код от имени www-data. Подробнее об уязвимости и ее эксплуатации можно почитать по ссылке. Ошибка имела низкий уровень сложности, но тем не менее только шесть команд смогли ее обнаружить.  Рисунок 10. Выполнение команды uname -a через уязвимость в phpCollabFileHosting стал одним из самых популярных сервисов у атакующих — 26 команд смогли провести успешные атаки. Скорее всего, это связано с количеством и разнообразием заложенных уязвимостей (SQLi, RCE, XSS, Path Traversal) и их простотой. Сервис представляет собой хранилище файлов, позволяет загружать и просматривать документы. Написан на Python Flask.  Рисунок 11. Пример атаки Path Traversal на приложение FileHosting. Атакующие читают исходный код FlaskНо, наверное, самое интересное, что мы смогли поймать, — это RCE в base64-encoded cookie. Отчасти это было даже случайно. Когда мы готовили наше большое правило для обнаружения успешных RCE, мы поспорили: а действительно ли стоит искать паттерн в запросе и в ответе? С одной стороны, это позволит минимизировать число ложноположительных срабатываний, с другой, у нас будут все шансы пропустить то, что мы не предусмотрели заранее. В итоге мы пришли к выводу, что такое правило лишним не будет. Оно получилось похожим на первое, только не проверяло запрос, а лишь искало специфичный вывод в ответе. Написали и забыли. Но в какой-то момент в ходе игры мы поймали сработку, где в запросе не было ничего, а вот в ответе…   Рисунок 12. Ответ на с виду обычный запросЕсли вы внимательно посмотрите, значение Cookie user_id было следующим: dW5hdXRob3Jpc2VkOyBpZDs, что при декодировании превратилось в unauthorised; id;. И у нас появилось правило [BB] Tomcat cookie RCE — оно декодирует параметр user_id заголовка Cookie и ищет в нем признаки выполнения команд операционной системы.  Рисунок 13. Правило [BB] Tomcat cookie RCEНовый уровень понимания действий атакующихА дальше нам стало интересно отслеживать не отдельные сработки, а цепочки исполнения команд атакующими. Поэтому мы стали коррелировать события.В правиле корреляции мы объединяли сработки успешных RCE в атаки по CLIENT_IP и REQUEST_PATH. То есть мы стали собирать все запросы от одной команды по одному пути вместе. И в этот момент нам стало понятнее, что делают атакующие, так как мы смогли наглядно разделить цепочки действий по командам и часто даже между членами одной команды — когда ребята параллельно пытались раскрутить сразу несколько найденных уязвимостей.  Рисунок 14. Атакующие скачали и запустили майнер через полученную RCE-уязвимостьЭто было первое, но далеко не единственное, что нам удалось получить от корреляций. Их суть в том, чтобы обнаруживать такие атаки, где каждое действие по отдельности кажется нормальным, но последовательность запросов может быть опасной. Самое простое и очевидное — перебор пользователей на GitLab через API. API для того и создан, чтобы можно было быстро автоматизированными средствами получить информацию. Но, согласитесь, подозрительно, что кто-то забирает информацию обо всех пользователях:  Рисунок 15. Атакующие перебрали 1000 пользователей GitLab за минутуБлагодаря корреляциям, мы обнаружили, что система CMS Cockpit была уязвима не только к RCE, но и к User Enumeration (перебору пользователей) через восстановление пароля. Если в POST-запросе на страницу /cockpit/auth/requestreset отправлялось имя существующего пользователя, то страница возвращала ответ Recovery email sent, иначе — User not found. Что интересно, в JSON можно было отправить не только полное имя пользователя, но и регулярное выражение. И если хотя бы одно имя пользователя под него подходило, то такому пользователю отправлялось электронное письмо с инструкциями по восстановлению пароля. Уязвимость не самая опасная, да и атакующие, скорее всего, первым делом попробовали имя Admin. Но тем не менее знать о такой «особенности» работы своего приложения всегда полезно. Еще полезнее — иметь правило, позволяющее обнаружить и заблокировать подозрительную активность.   Рисунок 16. Атакующие обнаружили имя зарегистрированного пользователя последовательностью запросовА что с рискамиНо все же главной целью атакующих был не поиск уязвимостей. Для каждой из шести компаний был сформирован список событий — бизнес-рисков, реализация которых в реальной жизни могла бы стать фатальной для бизнеса. И вот за решение этой задачи команды красных получали больше всего баллов — все как в реальной жизни, но вместо денег — очки.В офисе Heavy Ship Logistics, компании, которая занимается перевозками, был определен риск «Сбой системы регистрации пассажиров». А задание было следующим: продемонстрировать возможность зарегистрировать на рейс пять пассажиров. Звучит как корреляция!  Рисунок 17. Запрос, отправляемый приложением при регистрации пассажира на рейс В данном случае мы ждали более пяти событий за не очень большой промежуток времени с одного IP-адреса и в рамках одной сессии. Чтобы это отследить, нам пришлось добавить в правило значения заголовка Cookie: они могли быть любыми, но сессионные cookie должны были попасть в MATCHED.VARIABLE_NAME, чтобы бы мы могли скоррелировать запросы.Другой интересный риск, реализацию которого нам удалось обнаружить с помощью PT Application Firewall, — удаление информации о штрафах граждан. Суть задания была в изменении записи в базе данных городского портала. А именно: надо было изменить размер штрафа пользователя Todd Smith. И атакующие могли действовать любым удобным способом — никто заранее не знал, каким путем можно пойти. Одна команда атакующих, видимо, сильно хотела быть первой и решила не искать нужный идентификатор штрафа. Получив права администратора портала, они перехватили запрос на удаление штрафа и просто перебором идентификаторов очистили базу со штрафами:  Рисунок 18. Пример запроса на удаление штрафаИнтересно, но не по заданию. Организаторам пришлось восстанавливать всю базу данных. Хотя команда глобального SOC была очень благодарна. Теперь мы знали, что нужный штраф имеет идентификатор 9, а номер документа — 6534 976653. Нам осталось только выяснить, как атакующие получили необходимые права на портале. Для этого мы провели небольшой ретроспективный анализ по IP-адресу. Поле авторизации на портале оказалось уязвимым к SQL-инъекции:  Рисунок 19. Запрос для обхода авторизации на портале 25HНа самом деле анализ был большой и трудоемкий. Запросов было много, и почти все возвращали ответ 302 (redirect), то есть мы не могли сказать точно, была ли авторизация удачной, так как в любом случае перенаправление осуществлялось на главную страницу. Нам пришлось повторить вручную множество запросов атакующих, прежде чем мы смогли авторизоваться на портале под пользователем BIGBOSS. В результате мы написали правило: если при запросе на страницу /index.php?page_controller=create_fine пользователь видит номер документа 6534 976653 и кнопку «Delete» fine, то, скорее всего, команда атакующих получила доступ на портал с правами, достаточными для удаления штрафа. И конечно, мы не забыли правило для уязвимого к SQL-инъекции поля. Некоторое время спустя мы поймали авторизацию другой команды — также через SQL-инъекцию. А еще чуть позже третья команда реализовала риск, на этот раз точно в соответствии с заданием:  Рисунок 20. Одна из команд изменяет размер штрафа с id=9Информация к размышлениюThe Standoff — это четыре дня напряженной работы, за которые мы приобрели тонну опыта. Прежде всего кибербитва — это шанс отработать навыки оперативного реагирования: выявлять реальные веб-уязвимости и мгновенно писать правила, позволяющие их закрыть. За четыре дня мы написали более 30 правил, которые помогали выявлять атакующих на первых шагах входа в инфраструктуру и уже прицельно следить за дальнейшим развитием векторов реализации рисков.Конечно, в реальной жизни при обнаружении подобных уязвимостей самое верное — это устранять их на уровне кода приложения. Но это небыстрый процесс, поэтому оперативное написание правила, блокирующего вредоносные запросы, является важной задачей команды защиты. В повседневной жизни специалисты PT Expert Security Center каждый день анализируют тысячи запросов к веб-ресурсам наших клиентов, чтобы обнаруживать новые векторы атак на всевозможные системы и противодействовать им.Главным показателем нашей работы как глобального SOC стало то, что мы полностью понимали ход игры, знали, где есть уязвимости, где команды находятся в конкретный момент, и в большинстве случаев видели реализацию рисков задолго до получения отчета от атакующих. Киберполигон The Standoff — отличный шанс найти пробелы в собственных знаниях и стать лучше, расти и совершенствовать подходы к мониторингу.Автор: Юлия Фомина, специалист отдела мониторинга информационной безопасности PT Expert Security Center =========== Источник: habr.com =========== Похожие новости:
Блог компании Positive Technologies ), #_informatsionnaja_bezopasnost ( Информационная безопасность ), #_sportivnoe_programmirovanie ( Спортивное программирование ), #_itinfrastruktura ( IT-инфраструктура ), #_konferentsii ( Конференции ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:21
Часовой пояс: UTC + 5