Внимание, Мошенник!
Пользователь был уличен в мошенничестве. Мы не рекомендуем совершать сделки с ним!
Пользователь был уличен в мошенничестве. Мы не рекомендуем совершать сделки с ним!
Цель тестирования — попасть из внешней сети в локальную сеть кампании, после чего получить доступ к любой информации, предоставляющей собою хоть какую-то коммерческую ценность. Исходные данные — сайт организации (представим его как site.com).
Началось всё с поиска машин, находящихся в той же подсети что и официальный сайт. Было найдено 10 таких хостов. С ходу подкопаться было не к чему: все сервисы, «смотрящие» наружу, были последних версий, бруту по популярным словарям логинов/паролей не поддавались либо противодействовали ему (бан по IP, большая задержка между попытками входа), на веб-серверах при обращениях по IP переборщик не нашёл никаких подозрительных директорий или файлов.
Тогда с помощью Google, Bing и пары переборщиков был собран список поддоменов site.com. Оказалось, что когда-то давно на отдельном сервере провайдер предоставлял услуги веб-хостинга. Простенькие условия, небольшая плата, домен третьего уровня в подарок. Многие из этих доменов функционируют и по сей день.
При осмотре этих сайтов на одном из них был обнаружен форум 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. Благо, пароли хранились в открытом виде, и брутить ничего не пришлось. Собранные данные добавились к уже сбрученным паролям, и я получил список логинов/паролей привилегированных пользователей, который мог бы мне помочь попасть на другие сервера.
Несколько административных аккаунтов от найденных ранее форумов подошли к админ-панели форума действующего сайта. Это был IPB3, и залить шелл через админку не составила труда. Тут же был сверен текущий список аккаунтов персонала с тем, что был у меня. Всплыли 2 новых логина, чьи хеши сразу отправились на перебор. С теми хешами, что не успели сбрутиться за это время, я поступил проще. В код форума был встроен бекдор, записывающий вводимые пароли интересующих меня логинов, а из базы были удалены сессии этих пользователей, из-за чего каждому из них пришлось проходить авторизацию заново. К концу следующего дня мой список действенных логинов и паролей администраторов увеличился ещё на несколько записей. Пришло время использовать его.
Для выбора целей на самом первом хосте, где мне удалось получить шелл, был собран nmap, и им были просканированы всё те же 10 хостов, доступных извне, но уже от лица сервера, который находился с ними в одной сети. Это дало свои результаты — «всплыли» новые сервисы, доступ из Интернет к которым отсутствовал.
Затем была собрана Hydra и запущен брут SSH (решил начать с него) всех 10 серверов. Это дало доступ на 3 дополнительных сервера. Теперь я мог закрепиться на 5 из 10. Но делать этого не пришлось, т. к. один из них оказался подключен к локальной сети компании.
Развернув на нём те же Nmap и Hydra, я начал исследовать локалку. Было найдено много интересного, но первыми внимание привлекли внутренний FTP-сервер и административная веб-панель Open-E NAS-XSR (файловое хранилище). FTP сразу был поставлен на брут, а вот по Open-E NAS-XSR я полез в Google, т. к. ранее никогда с этим продуктом не встречался.
Там, помимо общей информации, были найдены дефолтовые административные пароли, которые, как вы, наверное, уже догадались, подошли к обнаруженной панели управления. В ней находился список директорий smb-хранилища и имена пользователей, которые имели туда доступ. Hydra опять меня удивила, сообщив, что к smb доступ по этим логинам осуществляется без паролей. С помощью 3proxy на доступном из внешней сети сервера я сделал проброс портов к «шаре» и, соединившись с ней со своей машины, скачал несколько случайно выбранных doc-файлов, которые и были переданы заказчику в качестве желаемых доказательств.
Началось всё с поиска машин, находящихся в той же подсети что и официальный сайт. Было найдено 10 таких хостов. С ходу подкопаться было не к чему: все сервисы, «смотрящие» наружу, были последних версий, бруту по популярным словарям логинов/паролей не поддавались либо противодействовали ему (бан по IP, большая задержка между попытками входа), на веб-серверах при обращениях по IP переборщик не нашёл никаких подозрительных директорий или файлов.
Тогда с помощью Google, Bing и пары переборщиков был собран список поддоменов site.com. Оказалось, что когда-то давно на отдельном сервере провайдер предоставлял услуги веб-хостинга. Простенькие условия, небольшая плата, домен третьего уровня в подарок. Многие из этих доменов функционируют и по сей день.
При осмотре этих сайтов на одном из них был обнаружен форум 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. Благо, пароли хранились в открытом виде, и брутить ничего не пришлось. Собранные данные добавились к уже сбрученным паролям, и я получил список логинов/паролей привилегированных пользователей, который мог бы мне помочь попасть на другие сервера.
Несколько административных аккаунтов от найденных ранее форумов подошли к админ-панели форума действующего сайта. Это был IPB3, и залить шелл через админку не составила труда. Тут же был сверен текущий список аккаунтов персонала с тем, что был у меня. Всплыли 2 новых логина, чьи хеши сразу отправились на перебор. С теми хешами, что не успели сбрутиться за это время, я поступил проще. В код форума был встроен бекдор, записывающий вводимые пароли интересующих меня логинов, а из базы были удалены сессии этих пользователей, из-за чего каждому из них пришлось проходить авторизацию заново. К концу следующего дня мой список действенных логинов и паролей администраторов увеличился ещё на несколько записей. Пришло время использовать его.
Для выбора целей на самом первом хосте, где мне удалось получить шелл, был собран nmap, и им были просканированы всё те же 10 хостов, доступных извне, но уже от лица сервера, который находился с ними в одной сети. Это дало свои результаты — «всплыли» новые сервисы, доступ из Интернет к которым отсутствовал.
Затем была собрана Hydra и запущен брут SSH (решил начать с него) всех 10 серверов. Это дало доступ на 3 дополнительных сервера. Теперь я мог закрепиться на 5 из 10. Но делать этого не пришлось, т. к. один из них оказался подключен к локальной сети компании.
Развернув на нём те же Nmap и Hydra, я начал исследовать локалку. Было найдено много интересного, но первыми внимание привлекли внутренний FTP-сервер и административная веб-панель Open-E NAS-XSR (файловое хранилище). FTP сразу был поставлен на брут, а вот по Open-E NAS-XSR я полез в Google, т. к. ранее никогда с этим продуктом не встречался.
Там, помимо общей информации, были найдены дефолтовые административные пароли, которые, как вы, наверное, уже догадались, подошли к обнаруженной панели управления. В ней находился список директорий smb-хранилища и имена пользователей, которые имели туда доступ. Hydra опять меня удивила, сообщив, что к smb доступ по этим логинам осуществляется без паролей. С помощью 3proxy на доступном из внешней сети сервера я сделал проброс портов к «шаре» и, соединившись с ней со своей машины, скачал несколько случайно выбранных doc-файлов, которые и были переданы заказчику в качестве желаемых доказательств.
