Доброго времени суток,
уважаемые читатели. Давно я не писал
примеров по пен-тесту из собственной
практики, пора это исправить. Как раз
имеется один заказ, после выполнения
которого прошло уже достаточно времени,
и клиент разрешил опубликовать информацию
в сети, но, естественно, без упоминания
названия предприятия, имён его сотрудников
и т. д. Чтоб не отнимать много времени
постараюсь изложить всё кратко, без
воды.
В один прекрасный день
я получил заказ на тестирование
защищённости компании-провайдера Х.
Цель тестирования — попасть из внешней
сети в локальную сеть кампании, после
чего получить доступ к любой информации,
предоставляющей собою хоть какую-то
коммерческую ценность. Исходные данные
— сайт организации (представим его как
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-файлов, которые и были переданы
заказчику в качестве желаемых
доказательств.
Комментариев нет:
Отправить комментарий