Как раз имеется один заказ, после выполнения которого прошло уже достаточно времени, и клиент разрешил опубликовать информацию в сети, но, естественно, без упоминания названия предприятия, имён его сотрудников и т. д. Чтоб не отнимать много времени постараюсь изложить всё кратко, без воды.
В один прекрасный день я получил заказ на тестирование защищённости компании-провайдера Х. Цель тестирования — попасть из внешней сети в локальную сеть кампании, после чего получить доступ к любой информации, предоставляющей собою хоть какую-то коммерческую ценность. Исходные данные — сайт организации (представим его как
Началось всё с поиска машин, находящихся в той же подсети что и официальный сайт. Было найдено 10 таких хостов. С ходу подкопаться было не к чему: все сервисы, «смотрящие» наружу, были последних версий, бруту по популярным словарям логинов/паролей не поддавались либо противодействовали ему (бан по IP, большая задержка между попытками входа), на веб-серверах при обращениях по IP переборщик не нашёл никаких подозрительных директорий или файлов.
Тогда с помощью Google, Bing и пары переборщиков был собран список поддоменов
. Оказалось, что когда-то давно на отдельном сервере провайдер предоставлял услуги веб-хостинга. Простенькие условия, небольшая плата, домен третьего уровня в подарок. Многие из этих доменов функционируют и по сей день.
При осмотре этих сайтов на одном из них был обнаружен форум phpBB очень старой версии 2.0.15, содержащей уязвимость RCE (удалённое выполнение кода). Уязвимость была сразу же проэксплуатирована, и в одну из директорий форума влит шелл. Однако в настройках PHP для каждого клиента включалась опция open_basedir с указанием его рабочей директории, что ограничивало действия интерпретатора. Был включен и safe_mode.
Но выход из сложившейся ситуации нашёлся. Порывшись в phpinfo(), я обнаружил опцию safe_mode_exec_dir с путём «/usr/bin/». Как оказалось, такое разрешение администратор вписал по просьбе одного из клиентов, которому понадобился доступ к бинарникам imagemagick. Конечно, в /usr/bin находился и perl. Поэтому на хосте через system() сразу был запущен перловый бекдор, влитый в ту же директорию, что и шелл.
Внутри меня ждало небольшое разочарование — данный сервер не был подключен к локальной сети компании, но шелл на нём – это уже что-то. Тем более, разграничений в правах там особых не было, и я с лёгкостью бродил по веб-директориям всех развёрнутых хостов. На обработку информации с этого сервера ушло примерно 2 дня. Собирались все пароли от БД, админок размещённых сайтов, их пользователей и прочего, в надежде на то, что среди них попадётся какой-нибудь тестовый проект, заведённый кем-нибудь из администраторов и содержащий привилегированные логин и пароль.
Ожидания оправдались, и в итоге я нашёл 2 проекта, оставленных админами. Первый являлся копией старой версии главного сайта компании, а второй — бета-хостом, на котором размещали новую версию того же сайта перед полноценным запуском. И там, и там был форум, на котором сотрудники компании общались с пользователями, давали консультации и выкладывали новости. Все их хеши были сразу слиты и поставлены на брут.
Там же были найдены скрипты старой версии личного кабинета, через который пользователи могли смотреть статистику своего счёта и менять тарифные планы. Новой версии на бета-хосте не наблюдалось, но старая содержала актуальные реквизиты доступа к PostgreSQL, не доступного для подключения извне. Pgsql-клиента на хосте, где я находился, установлено не было. Был только соответствующий модуль у Perl (скрипты старого ЛК были написаны на нём). Пришлось написать на нём же небольшую консольную утилиту, принимающую от пользователя sql-запрос и выводящую его результат в удобочитаемом виде.
С её помощью мне удалось подключиться к БД и добраться до клиентской базы. В частности, до таблицы, содержащей логины и пароли пользователей для подключении.
В один прекрасный день я получил заказ на тестирование защищённости компании-провайдера Х. Цель тестирования — попасть из внешней сети в локальную сеть кампании, после чего получить доступ к любой информации, предоставляющей собою хоть какую-то коммерческую ценность. Исходные данные — сайт организации (представим его как
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
).Началось всё с поиска машин, находящихся в той же подсети что и официальный сайт. Было найдено 10 таких хостов. С ходу подкопаться было не к чему: все сервисы, «смотрящие» наружу, были последних версий, бруту по популярным словарям логинов/паролей не поддавались либо противодействовали ему (бан по IP, большая задержка между попытками входа), на веб-серверах при обращениях по IP переборщик не нашёл никаких подозрительных директорий или файлов.
Тогда с помощью Google, Bing и пары переборщиков был собран список поддоменов
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
. Оказалось, что когда-то давно на отдельном сервере провайдер предоставлял услуги веб-хостинга. Простенькие условия, небольшая плата, домен третьего уровня в подарок. Многие из этих доменов функционируют и по сей день.
При осмотре этих сайтов на одном из них был обнаружен форум phpBB очень старой версии 2.0.15, содержащей уязвимость RCE (удалённое выполнение кода). Уязвимость была сразу же проэксплуатирована, и в одну из директорий форума влит шелл. Однако в настройках PHP для каждого клиента включалась опция open_basedir с указанием его рабочей директории, что ограничивало действия интерпретатора. Был включен и safe_mode.
Но выход из сложившейся ситуации нашёлся. Порывшись в phpinfo(), я обнаружил опцию safe_mode_exec_dir с путём «/usr/bin/». Как оказалось, такое разрешение администратор вписал по просьбе одного из клиентов, которому понадобился доступ к бинарникам imagemagick. Конечно, в /usr/bin находился и perl. Поэтому на хосте через system() сразу был запущен перловый бекдор, влитый в ту же директорию, что и шелл.
Внутри меня ждало небольшое разочарование — данный сервер не был подключен к локальной сети компании, но шелл на нём – это уже что-то. Тем более, разграничений в правах там особых не было, и я с лёгкостью бродил по веб-директориям всех развёрнутых хостов. На обработку информации с этого сервера ушло примерно 2 дня. Собирались все пароли от БД, админок размещённых сайтов, их пользователей и прочего, в надежде на то, что среди них попадётся какой-нибудь тестовый проект, заведённый кем-нибудь из администраторов и содержащий привилегированные логин и пароль.
Ожидания оправдались, и в итоге я нашёл 2 проекта, оставленных админами. Первый являлся копией старой версии главного сайта компании, а второй — бета-хостом, на котором размещали новую версию того же сайта перед полноценным запуском. И там, и там был форум, на котором сотрудники компании общались с пользователями, давали консультации и выкладывали новости. Все их хеши были сразу слиты и поставлены на брут.
Там же были найдены скрипты старой версии личного кабинета, через который пользователи могли смотреть статистику своего счёта и менять тарифные планы. Новой версии на бета-хосте не наблюдалось, но старая содержала актуальные реквизиты доступа к PostgreSQL, не доступного для подключения извне. Pgsql-клиента на хосте, где я находился, установлено не было. Был только соответствующий модуль у Perl (скрипты старого ЛК были написаны на нём). Пришлось написать на нём же небольшую консольную утилиту, принимающую от пользователя sql-запрос и выводящую его результат в удобочитаемом виде.
С её помощью мне удалось подключиться к БД и добраться до клиентской базы. В частности, до таблицы, содержащей логины и пароли пользователей для подключении.