Ця стаття написана за мотивами дуже вдалого пентесту, який кілька років тому провели фахівці Group-IB: трапилася історія, яка претендує на екранізацію в Боллівуді. Зараз, напевно, буде реакція читача: «О, чергова піар-стаття, знову ці малюються, які вони хороші, ще не забудьте купити пентест». Ну, з одного боку, так і є. Проте є ще низка мотивів, чому з'явилася ця стаття. Хотілося показати, чим саме займаються пентестери, наскільки ця робота може бути цікавою та нетривіальною, які кумедні обставини можуть складатися на проектах та найголовніше — показати живий матеріал із реальними прикладами.
Щоб відновити баланс скромності у світі, за деякий час напишемо про пентест, який не пішов. Покажемо, як добре поставлені процеси у компанії можуть захистити від цілого спектру атак, навіть добре підготовлених, тому що ці процеси є і реально працюють.
У замовника з цієї статті теж все загалом було чудово, принаймні краще, ніж у 95% ринку в РФ за нашими відчуттями, але була низка дрібних нюансів, які склалися в довгий ланцюжок подій, що і призвело спочатку до довгого звіту з робіт , А потім до цієї статті.
Отже, запасаємося попкорном, і ласкаво просимо до детектива. Слово - Павлу Супрунюку, технічному керівнику напряму "Аудит та Консалтинг" Group-IB.
Частина 1. Почкін лікар
2018 рік. Є замовник – високотехнологічна ІТ-компанія, яка сама обслуговує безліч клієнтів. Хоче отримати відповідь на запитання: чи можна без будь-яких початкових знань та доступів, працюючи через інтернет, отримати права адміністратора домену Active Directory? Ніяка соціальна інженерія не цікавить), заважати роботам спеціально не збираються, але можуть випадково перезалити дивно працюючий сервер, наприклад. Додаткове завдання — виявити якнайбільше інших векторів атак щодо зовнішнього периметра. Компанія регулярно проводить подібні тестування, і ось настав термін нового тесту. Умови майже типові, адекватні, зрозумілі. Приступаємо.
Є назва замовника - нехай буде "Company", з основним сайтом . Звичайно, називається замовник по-іншому, але в цій статті все буде знеособлено.
Проводжу мережну розвідку - з'ясовую, які адреси та домени вважаються за замовником, малюю схему мережі, як розподіляються послуги за цими адресами. Отримую результат: понад 4000 живих IP-адрес. Переглядаю домени в цих мережах: на щастя, переважна більшість — мережі, призначені клієнтам замовника, і вони нас формально не цікавлять. Замовник вважає так само.
Залишається одна мережа на 256 адрес, для якої до цього моменту вже є розуміння розподілу доменів та піддоменів по IP-адресах, є інформація про проскановані порти, отже — можна очима дивитися сервіси на предмет цікавих. Паралельно запускаються всілякі сканери за доступними IP-адресами і окремо - по веб-сайтах.
Сервісів є дуже багато. Зазвичай це радість для пентестера та передчуття швидкої перемоги, оскільки чим більше сервісів, тим більше поле для атаки і тим простіше знайти артефакт. Побіжний перегляд веб-сайтів показав, що більшість із них — це веб-інтерфейси відомих продуктів великих світових компаній, які кажуть, що вони вам не раді. Просять логін-пароль, з порога трясуть полем для введення другого фактора, просять клієнтський сертифікат TLS або надсилають подалі в Microsoft ADFS. Деякі просто недоступні з Інтернету. До деяких явно необхідно мати спеціальний платний клієнт за три зарплати або знати точний URL на вхід. Опустимо ще тиждень поступового приниження в процесі спроб «пробити» софт за версіями на предмет відомих уразливостей, пошуку прихованого контенту в веб-шляхах і обліків з сторонніх сервісів типу LinkedIn, спроб підбору паролів по них, а також розкопок вразливостей в самописаних веб-сайтах — до речі, за статистикою, це найперспективніший вектор зовнішньої атаки на сьогоднішній день. Відразу відзначу ту кіношну рушницю, яка згодом вистрілила.
Отже, знайшлося два сайти, що вибиваються із сотні сервісів. У цих сайтах було спільне: якщо не займатися скрупульозною мережевою розвідкою по доменам, а «в лоб» шукати відкриті порти або цькувати сканер уразливостей за відомим діапазоном IP, то ці сайти уникнуть перевірки, їх просто не буде видно без знання DNS-імені. Можливо, їх так і пропустили раніше, принаймні, і наші автоматичні інструменти проблем у них не знайшли навіть якщо їх нацьковували прямо на ресурс.
До речі, про те, що загалом знайшли раніше запущені сканери. Нагадаю: для деяких людей «пентест» рівносильний «автоматизованому скануванню». А сканери цього проекту нічого не сказали. Ну, максимум показали Medium-уразливості (3 із 5 за рівнем небезпеки): на якомусь сервісі поганий сертифікат TLS або застарілі алгоритми шифрування, а на більшості сайтів Clickjacking. Але на цьому до мети не приїдеш. Можливо, сканери були б тут корисніші, але нагадаю: замовник сам може закупити такі програми і перевірити ними себе, і, судячи з сумних результатів, уже перевірив.
Повернімося до «аномальних» сайтів. Перший щось типу місцевої Wiki за нестандартною адресою, але в цій статті нехай буде wiki.company[.]ru. Вона також відразу просила логін і пароль, але вже через NTLM у браузері. Для користувача таке виглядає як аскетичне вікно із проханням ввести логін та пароль. І це погана практика.
Невелика ремарочка. NTLM у веб-сайтах на периметрі погана з низки причин. Перша причина – розкривається ім'я домену Active Directory. У нашому прикладі воно також виявилося company.ru, як і «зовнішнє» DNS-ім'я. Знаючи це, можна якісно підготувати щось шкідливе, щоб воно виповнилося лише на доменній машині організації, а не в якійсь пісочниці. Друге — аутентифікація йде безпосередньо через контролер домену за NTLM (сюрприз, так?), з усіма особливостями політик «внутрішньої» мережі, включаючи блокування обліків від перевищення числа спроб введення пароля. Якщо зловмисник дізнається про логіну, він перебиратиме до них паролі. Якщо налаштовано блокування обліків від неправильного введення паролів, воно спрацює, і облік буде заблоковано. Третє – до такої аутентифікації неможливо додати другий фактор. Якщо хтось із читачів все ж таки знає як — повідомте, будь ласка, реально цікаво. Четверте – вразливість до pass-the-hash-атак. ADFS придумали навіть для захисту від цього всього.
Є одна погана якість у продуктів Microsoft: навіть якщо ви спеціально не публікували такий NTLM, він опиниться в установці за замовчуванням в OWA і Lync, як мінімум.
До речі, автор цієї статті одного разу у такий же спосіб випадково заблокував приблизно 1000 обліків працівників одного великого банку буквально за одну годину і мав потім трохи блідий вигляд. ІТ-служби банку теж були блідими, але все закінчилося добре та адекватно, нас навіть похвалили, що ми першими знайшли цю проблему та спровокували швидке та рішуче виправлення.
Другий сайт мав адресу «явно якесь прізвище.company.ru». Знайшовся через Google приблизно так на 10-й сторінці. Дизайн початку-середини двотисячних, і з головної сторінки дивилася солідна людина, приблизно так:
Тут взяв кадр із «Собачого серця», але повірте, там було віддалено-схоже, навіть колірне оформлення у схожих тонах. Нехай сайт зветься preobrazhensky.company.ru.
То був персональний сайт… уролога. Стало цікаво, що робить сайт уролога на піддоміні високотехнологічної компанії. Побіжне копання в Google показало, що цей лікар був співзасновником однієї з юридичних осіб нашого замовника і навіть вніс близько 1000 рублів статутного капіталу. Ймовірно, сайт було створено багато років тому, а серверні ресурси замовника використали як хостинг. Сайт давно втратив актуальність, але навіщось був залишений працюючим на довгий час.
З точки зору вразливостей сам веб-сайт був безпечним. Забігаючи вперед, скажу, що він являв собою набір статики - прості html-сторінки зі вставками ілюстрацій у вигляді нирок та сечових міхурів. "Ломати" такий сайт марно.
А ось веб-сервер під ним був цікавішим. Судячи із заголовка HTTP Server, там був IIS 6.0, а отже, застосовувався Windows 2003 як операційна система. Сканер раніше виявив, що цей конкретний сайт уролога, на відміну від інших віртуальних хостів на цьому веб-сервері, відповідав на команду PROPFIND, тобто там працював WebDAV. До речі, сканер видав цю інформацію з позначкою Info (мовою звітів сканерів це нижча небезпека) — такі речі зазвичай просто пропускаються. У поєднанні це давало цікавий ефект, який вдалося виявити лише після чергового копання в Google: рідкісна вразливість переповнення буфера, пов'язана із набором Shadow Brokers, а саме CVE-2017-7269, яка вже мала готовий експлоїт. Інакше кажучи, буде біда, якщо у вас Windows 2003 і IIS запущений WebDAV. Хоча працюючий у продакшені Windows 2003 у 2018 році — це вже сама по собі біда.
Експлойт опинився в Metasploit і тут же був випробуваний із навантаженням, яке надсилало DNS-запит на підконтрольний сервіс — традиційно використовується Burp Collaborator для вилову DNS-запитів. На подив, спрацювало з першого разу: було отримано відстукування в DNS. Далі була спроба створити бекконнект через 80 порт (тобто мережне з'єднання від сервера до атакуючого, з доступом до cmd.exe на хосте-жертві), але тут трапилося фіаско. З'єднання не прийшло, а після третьої спроби експлуатації сайт разом з усіма цікавими картинками зник назовні.
Зазвичай після цього слідує лист у стилі «замовник, прокинься, ми всі впустили». Але нам відповіли, що сайт ніякого відношення до бізнес-процесів не має і працює там взагалі незрозуміло навіщо, як і весь сервер, і що цей ресурс можна використовувати як нам завгодно.
Приблизно за добу сайт раптово заробив сам. Збудувавши стенд з WebDAV на IIS 6.0, я виявив, що за умовчанням стоїть налаштування на перезапуск робочих процесів IIS кожні 30 годин. Тобто при виході управління з шелл-коду завершувався робочий процес IIS, потім він пару разів перезапускався сам і далі йшов відпочивати на 30 годин.
Так як вперше бекконект на tcp не вдалося, я списав цю проблему на закритий порт. Тобто припустив наявність деякого міжмережевого екрану, який пропускав вихідні з'єднання назовні. Почав запускати шелл-коди, які перебирають безліч tcp-і udp-портів, ефекту не було. Не працювали навантаження зворотного з'єднання через http(s) з Metasploit - meterpreter/reverse_http(s). Раптом з'єднання на той самий 80 порт встановилося, але одразу обірвалося. Списав це на дію поки що уявної IPS, якій не подобався трафік meterpreter. У світлі того, що з'єднання чистого tcp на 80 порт не пройшло, а http - пройшло, зробив висновок, в системі була якось налаштована http-проксі.
Пробував навіть meterpreter через DNS (спасибі за праці, врятувало багато проектів), згадуючи перший успіх, але він не відпрацював навіть на стенді — шелл-код був занадто об'ємний для цієї вразливості.
Насправді це виглядало так: 3-4 спроби атак протягом 5 хвилин, потім очікування на 30 годин. І так три тижні поспіль. Я навіть заводив нагадування, щоб не гаяти часу. Додатково спостерігалася різниця в поведінці тестового та бойового середовищ: для цієї вразливості було два схожі експлойти, один зі складу Metasploit, другий з просторів інтернету, перероблений від версії Shadow Brokers. Так ось, на бойовому відпрацьовував лише Metasploit, на стенді — лише другий, що ще більше ускладнювало налагодження та ламало мозок.
Зрештою, ефективним себе показав шелл-код, який качав із заданого сервера по http exe-файл і запускав його на цільовій системі. Шелл-код був досить невеликий, щоб пролізти за розміром, та й він хоча б працював. Якщо трафік TCP серверу взагалі не подобався і http(s) перевірявся на наявність meterpreter, я вирішив, що найшвидший спосіб — завантажити через цей шелл-код exe-файл, який містив DNS-meterpreter.
Тут знову виникла проблема: при скачуванні exe-файлу і, як показали спроби, будь-якого, завантаження обривалося. Знову якомусь пристрої захисту між моїм сервером та урологом не подобався трафік http з exe всередині. "Швидким" рішенням здалося змінити шелл-код так, щоб він обфусував трафік http нальоту, щоб замість exe передавалися абстрактні двійкові дані. Нарешті атака пройшла успішно, через тонкий DNS-канал надійшло керування:
Відразу з'ясувалося, що маю найпростіші права робочого процесу IIS, які дозволяють робити нічого. Ось так це виглядало на консолі Metasploit:
Будь-які пентест-методології наполегливо говорять про те, що потрібно підвищувати права при отриманні доступу. Зазвичай я це не роблю локально, оскільки перший доступ розглядається просто як точка мережного входу, а скомпрометувати іншу машину в цій же мережі зазвичай простіше і швидше, ніж підвищувати привілеї на наявному хості. Але тут не той випадок, оскільки канал DNS дуже вузький і не дасть розгулятися трафіку.
Припускаючи, що цей сервер з Windows 2003 не ремонтували від знаменитої вразливості MS17-010, тунелюю трафік на порт 445/TCP через DNS-тунель meterpreter на localhost (так, так теж можна) і намагаюся запустити через вразливість раніше закачаний exe. Атака спрацьовує, мені приходить друге з'єднання, але вже з правами SYSTEM.
Цікаво те, що сервер все ж таки намагалися захистити від MS17-010 — у нього були відключені вразливі мережеві служби на зовнішньому інтерфейсі. Це дійсно захищає від атак через мережу, але атака зсередини на localhost спрацювала, так як не можна просто взяти і швидко вимкнути SMB на localhost.
Далі з'ясовуються нові цікаві деталі:
- Маючи права SYSTEM, можна без проблем встановити бекконект через TCP. Очевидно, заборона на прямий TCP є виключно проблемою обмеженого користувача IIS. Спойлер: трафік користувача IIS якось було загорнуто в локальний ISA Proxy в обидві сторони. Як саме це працює, не відтворював.
- Я в якійсь DMZ (і це не домен Active Directory, а WORKGROUP) — звучить логічно. Але замість очікуваної приватної («сірої») IP-адреси у мене цілком собі «білий», такий самий, що я атакував раніше. Отже, компанія настільки стара для світу адресації IPv4, що може дозволити собі тримати зону DMZ на 128 «білих» адрес без NAT за схемою, як малювали у посібниках за Cisco зразка 2005 року.
Оскільки сервер старий, гарантовано запрацював Mimikatz прямо з пам'яті:
Отримую пароль локального адміністратора, тунелюю трафік RDP через TCP і заходжу до затишного робочого столу. Так як з сервером можна було робити все, що завгодно, - видаляю антивірус, знаходжу, що сервер доступний з інтернету тільки портами TCP 80 і 443, причому 443 не був зайнятий. Піднімаю на 443 сервер OpenVPN, додаю функції NAT для мого VPN-трафіку та отримую прямий доступ до мережі DMZ у необмеженому вигляді через свій OpenVPN. Примітно, що ISA, маючи деякі функції IPS, що не відключаються, блокувала мій же трафік зі скануванням портів, за що її довелося замінити на більш простий і зговірливий RRAS. Тож пентестерам ще іноді доводиться адмініструвати всяке.
Уважний читач запитає: "А що другий сайт - wiki з NTLM-автентифікацією, про яку стільки написано?" Про це далі.
Частина 2. Ви ще не шифруєте? Тоді ми йдемо до вас вже тут
Отже, є доступ до мережного сегменту DMZ. Потрібно йти до адміністратора домену. Перше ж, що спадає на думку, — автоматизовано перевірити на безпеку сервіси всередині сегмента DMZ, тим більше, що їх тепер відкрилося для дослідження набагато більше. Типова картина при тесті на проникнення: зовнішній периметр захищений краще, ніж внутрішні сервіси, і при отриманні будь-якого доступу всередину великої інфраструктури отримати розширені права в домені набагато простіше тільки за рахунок того, що цей домен починає бути доступним для інструментарію, а по-друге, в інфраструктурі на кілька тисяч хостів завжди знайдеться кілька критичних проблем.
Заряджаю сканери по DMZ через OpenVPN-тунель, чекаю. Відкриваю звіт — знову нічого серйозного, мабуть, хтось пройшовся таким самим способом до мене. Наступна дія - дослідження того, як обмінюються інформацією хости всередині мережі DMZ. Для цього спочатку запускається звичайний Wireshark з прослуховуванням широкомовних запитів, в першу чергу ARP. ARP-пакети колекціонувалися цілодобово. З'ясовується, що у цьому сегменті застосовується кілька шлюзів. Це стане в нагоді далі. Склеюючи дані по запитам-відповідям ARP і дані сканування портів, знайшов вихідні точки користувача трафіку зсередини локальної мережі на додаток до тих сервісів, про які раніше було відомо, типу web і пошти.
Так як на даний момент у мене не було ніякого доступу в інші системи і не було жодного обліку для корпоративних сервісів, було вирішено вивудити хоч якусь облік з трафіку за допомогою ARP Spoofing.
На сервері уролога було запущено Cain&Abel. З урахуванням виявлених потоків трафіку було обрано найбільш перспективні пари для атаки «людина посередині», далі шляхом короткострокового запуску на 5-10 хвилин, з таймером на перезавантаження сервера на випадок «зависання», було отримано деякий мережевий трафік. Як в анекдоті, було дві новини:
- Гарна: облікових даних наловилося дуже багато і атака загалом працювала.
- Погана: всі облікові дані були від клієнтів замовника. Надаючи послуги з підтримки, фахівці замовника підключалися до сервісів клієнтів, які не завжди мали налаштування шифрування трафіку.
У результаті я розжився безліччю марних в контексті проекту облікових даних, але однозначно цікавих як демонстрація небезпеки атаки. Прикордонні роутери великих компаній з telnet, прокинуті налагоджувальні http-порти на внутрішні CRM з усіма даними, прямий доступ на RDP від Windows XP у локальній мережі та інше мракобісся. Вийшов такий собі .
Також знайшов кумедну нагоду збирати листи з трафіку, приблизно ось так. Це приклад готового листа, який йшов від нашого замовника на порт SMTP його клієнта, знову ж таки, без шифрування. Якийсь Андрій просить свого тезку заново вислати документацію, і вона викладається на хмарний диск з логіном, паролем і посиланням в одному листі у відповідь:
Це ще одне нагадування про те, що необхідно шифрувати всі послуги. Невідомо, хто і коли прочитає і застосує ваші дані — провайдер, системний адміністратор іншої фірми або ось такий пентестер. Мовчу про те, що просто перехопити нешифрований трафік може багато хто.
Незважаючи на успіх, що здається, до мети це не наблизило. Можна було, звичайно, довго сидіти і вивужувати цінну інформацію, але не факт, що вона там з'явилася б, та й сама атака дуже ризикована в плані цілісності роботи мережі.
Після чергового копання в сервісах на думку спала цікава ідея. Є така утиліта, називається Responder (легко знайти приклади застосування цього імені), яка шляхом «отруєння» широкомовних запитів провокує на себе підключення по безлічі протоколів типу SMB, HTTP, LDAP і т.д. різними способами, потім кожного, хто підключився, просить аутентифікуватися і підлаштовує це так, що аутентифікація проходить через NTLM і в прозорому для жертви режимі. Найчастіше атакуючий таким чином збирає NetNTLMv2-хендшейки і з них за словником швидко відновлює доменні паролі користувачів. Тут хотілося щось подібне, але користувачі сиділи "за стіночкою", а точніше, були відокремлені міжмережевим екраном, а в WEB виходили через кластер проксі Blue Coat.
Пам'ятаєте, я уточнював, що ім'я домену Active Directory збігалося із зовнішнім доменом, тобто було company.ru? Так ось, Windows, точніше Internet Explorer (і Edge, і Chrome), дозволяють користувачеві прозоро автентифікуватися в HTTP через NTLM, якщо вважають, що сайт знаходиться в деякій "Intranet Zone". Одна з ознак «Intranet» — звернення за «сірою» IP-адресою або за коротким ім'ям DNS, тобто без точок. Так як у розпорядженні був сервер з «білим» IP і DNS-іменем preobrazhensky.company.ru, а доменні машини зазвичай отримують суфікс Active Directory домену через DHCP для спрощеного введення імен, їм достатньо було написати в адресному рядку URL , щоб вони знайшли правильний шлях до скомпрометованого сервера уролога, не забуваючи, що це тепер називається Intranet. Тобто заразом віддавши мені NTLM-handshake користувача без його відома. Залишилося змусити клієнтські браузери подумати про термінову потребу звертатися на цей сервер.
На допомогу прийшла чудова утиліта Intercepter-NG. ). Вона дозволяла змінювати трафік на ходу і чудово працювала на Windows 2003. Там навіть був окремий функціонал модифікації тільки JavaScript-файлів у потоці трафіку. Планувався такий собі масовий Cross-Site Scripting.
Проксі Blue Coat, через які користувачі виходили до глобального WEB, періодично займалися кешуванням статичного контенту. Шляхом перехоплення трафіку було видно, що вони працюють цілодобово, нескінченно запитуючи статику, що часто використовується, для прискорення показу контенту в піковий годинник. До того ж, у BlueCoat був специфічний User-Agent, що однозначно відрізняло його від живого користувача.
Був підготовлений Javascript, який за допомогою Intercepter-NG вночі цілу годину впроваджувався на кожну відповідь із JS-файлами для Blue Coat. Скрипт робив таке:
- Визначав User-Agent поточний браузер. Якщо це був Internet Explorer, Edge чи Chrome, працював далі.
- Чекав, доки сформується DOM сторінки.
- Вставляв у DOM невидиму картинку з атрибутом src виду :8080/NNNNNNN.png де NNN — довільні цифри, щоб BlueCoat не закешував.
- Виставляв глобальну змінну-прапор, що ін'єкція була зроблена і більше не потрібно вставляти картинки.
Браузер намагався підвантажити цю картинку, на порту 8080 скомпрометованого сервера на нього чекав TCP-тунель до мого ноутбука, де був запущений той самий Responder, що вимагає від браузера входу по NTLM.
Судячи з логів Responder, вранці люди прийшли на роботу, включили свої робочі станції, потім масово і непомітно для себе почали відвідувати сервер уролога, не забуваючи «зливати» NTLM-хендшейки. Хендшейки сипалися цілий день і явно накопичили матеріал для наперед успішної атаки по відновленню паролів. Приблизно так виглядали логи Responder:
Масові таємні відвідування сервера уролога користувачами
Ви, напевно, вже помітили, що ця вся історія будується за принципом «все було добре, але тут чекав облом, далі відбулося перемогу, а потім усе прийшло до успіху». Так ось, тут чекав облом. З півтисячі унікальних хендшейків не було розкрито жодного. І це з урахуванням того, що навіть на ноутбуці з дохлим процесором ці NTLMv2-хендшейки перебираються зі швидкістю кілька сотень мільйонів спроб за секунду.
Довелося озброюватися техніками мутацій паролів, відеокартою, товстішим словником і чекати. Через тривалий час розкрилося кілька обліків з паролями виду «Q11111111….1111111q», що говорить про те, що всіх користувачів колись змусили придумати дуже довгий пароль з різним регістром символів, який мав бути ще й складним. Але матерого користувача просто так не проведеш, і він таким чином полегшив собі запам'ятовування. Усього обліків розкрилося близько 5 штук, і тільки одна з них мала якісь цінні права на сервісах.
Частина 3. Роскомнагляд завдає удару у відповідь
Отже, було отримано перші доменні обліки. Якщо ви до цього моменту не заснули від довгого читання — ви, мабуть, згадаєте, що я згадував сервіс, який не вимагав другого фактора аутентифікації: це wiki з аутентифікацією NTLM. Зрозуміло, туди насамперед було здійснено вхід. Копання у внутрішній базі знань швидко дало результати:
- У компанії є WiFi-мережа з автентифікацією за доменними обліками з доступом до локальної мережі. З поточним набором даних це вже робочий вектор атаки, але потрібно йти в офіс ногами та десь розміщуватись на території офісу замовника.
- Знайшлася інструкція, згідно з якою був сервіс, що дозволяв самостійно зареєструвати пристрій «другого фактора» аутентифікації, якщо користувач знаходиться всередині локальної мережі і впевнено пам'ятає свої доменні логін і пароль. У разі «всередині» і «зовні» визначалося шляхом доступності порту цього сервісу користувача. Порт не був доступний з інтернету, але цілком був доступний через DMZ.
Зрозуміло, до скомпрометованого обліку був відразу доданий «другий фактор» у вигляді програми на моєму телефоні. Там була програма, яка може голосно послати на телефон push-запит з кнопками «схвалити»/«не схвалити» дію, або мовчки показати код OTP на екрані для подальшого самостійного введення. Причому перший спосіб передбачався інструкцією єдино правильним, але з працював, на відміну способу з OTP.
З поламаним «другим фактором» вдалося зайти в пошту Outlook Web Access і на віддалений доступ до Citrix Netscaler Gateway. В Outlook на пошті чекав сюрприз:
На цьому рідкісному кадрі ви можете помітити, як Роскомнагляд допомагає пентестерам
Це були перші місяці після знаменитого "віялового" блокування Telegram, коли невблаганно зникали з доступу цілі мережі на тисячі адрес. Стало зрозуміло, чому відразу не спрацював push і чому моя «жертва» не забила на сполох через те, що її обліком почали користуватися у відверто неробочий час.
Хто знайомий з Citrix Netscaler, той уявляє, що його зазвичай впроваджують таким чином, щоб можна було донести до користувача лише картинку-інтерфейс, намагаючись не давати йому в руки інструментів для запуску сторонніх додатків та передачі даних, всіляко обмежуючи дії через стандартні оболонки керування. Моїй «жертві» за діяльністю дісталася лише 1С:
Трохи погулявши інтерфейсом 1С, знайшов, що там є зовнішні модулі обробки. Їх можна підвантажувати з інтерфейсу, і вони будуть виконуватися на клієнті чи сервері, залежно від прав та налаштувань.
Попросив друзів-програмістів 1С створити таку обробку, яка б приймала рядок та виконувала його. Мовою 1С запуск процесу виглядає приблизно так (взято з просторів інтернету). Погодьтеся, синтаксис мови 1С вражає російськомовну людину своєю безпосередністю?
Обробка чудово виконалася, вийшло те, що пентестери називають «шеллом» - через неї було запущено Internet Explorer.
Раніше в пошті було знайдено адресу системи, яка дозволяє замовляти перепустки на територію. Я замовив перепустку на випадок, якщо доведеться використовувати вектор атаки через WiFi.
В інтернетах подейкують, що в офісі замовника було ще смачне безкоштовне громадське харчування, але я вважав за краще все ж таки розвивати атаку через віддалення, так спокійніше.
На сервері програм із Citrix було активовано AppLocker, але його вдалося обійти. Був завантажений і запущений той самий Meterpreter через DNS, тому що http(s)-версії підключатися не хотіли, а внутрішню адресу проксі я тоді не знав. До речі, з цього моменту зовнішній пентест, по суті, остаточно перейшов у внутрішній.
Частина 4. Адмінські права у користувачів - це погано, п-нятенько?
Перша справа пентестера при отриманні контролю над сесією доменного користувача - це зібрати всю інформацію про права в домені. Є така утиліта BloodHound, яка автоматично дозволяє вивантажити через протокол LDAP з контролера домену інформацію про користувачів, комп'ютери, групи безпеки, а через SMB - інформацію про те, який користувач де нещодавно здійснював вхід і хто де локальний адміністратор.
Типова техніка захоплення прав адміністратора домену спрощено виглядає як цикл монотонних дій:
- Йдемо на доменні комп'ютери, де є права локального адміністратора, виходячи із вже захоплених доменних обліків.
- Запускаємо Mimikatz та отримуємо кешовані паролі, квитки Kerberos та хеші NTLM доменних обліків, які нещодавно здійснювали вхід до цієї системи. Або знімаємо образ пам'яті процесу lsass.exe і робимо те саме на своїй стороні. Це добре працює з Windows молодше 2012R2/Windows 8.1 з налаштуваннями за замовчуванням.
- Визначаємо де скомпрометовані обліки мають права локального адміністратора. Повторюємо перший пункт. На якомусь етапі отримуємо права адміністратора всього домену.
«КінецьЦикл;», як написали б тут програмісти 1С.
Так ось, наш користувач виявився локальним адміністратором всього на одному хості з Windows 7, в імені якого було слово VDI, або Virtual Desktop Infrastructure, особисті віртуальні машини. Ймовірно, проектувальник сервісу VDI передбачав, що коли VDI — особиста операційна система користувача, нехай тоді користувач змінює програмне оточення, як завгодно, все одно хост можна «перезалити». Я теж подумав, що загалом ідея хороша, зайшов на цей особистий хост VDI і звив собі там гніздо:
- встановив туди OpenVPN-клієнт, який робив тунель через інтернет до сервера. Клієнт довелося змусити проходити через ті ж Blue Coat з доменною автентифікацією, але OpenVPN впорався, що називається, «з коробки».
- Встановив VDI OpenSSH. Ну, правда, що це за Windows 7 без SSH?
Ось так це виглядало живцем. Нагадую, що це все доводиться робити через Citrix та 1С:
Одна з технік просування доступу на сусідні комп'ютери — перевірка паролів локальних адміністраторів на збіг. Тут одразу чекала удача: хеш NTLM локального адміністратора за умовчанням (який раптово звався Administrator) підходив через атаку pass-the-hash до сусідніх VDI-хостів, яких було кілька сотень. Зрозуміло, атака тут же пройшлася по них.
Тут адміністратори VDI вистрілили собі в ногу двічі.
- Перший раз, коли не ввели машини VDI під дію LAPS, по суті, зберігши однаковий пароль локального адміністратора з образу, який масово розвертали на VDI.
- Адміністратор за умовчанням - єдина локальна облік, яка вразлива до pass-the-hash атак. Навіть за однакового пароля можна було б уникнути масової компрометації, зробивши друге облік локального адміністратора зі складним випадковим паролем, а дефолтного — заблокувати.
Навіщо служба SSH на тій Windows? Дуже просто: тепер OpenSSH-сервер не тільки надавав зручну інтерактивну командну оболонку без перешкод для роботи користувача, але і socks5-проксі на VDI. Через цей socks я підключався SMB і збирав з усіх цих сотень машин VDI кешовані обліки, потім шукав по них у графах BloodHound шлях до доменного адміністратора. Маючи сотні хостів у розпорядженні, я знайшов такий шлях досить швидко. Права адміністратора домену було отримано.
Ось картинка з просторів інтернету, що показує такий пошук. Зв'язки показують хто де адміністратор і хто куди увійшов.
До речі, пам'ятайте умову зі старту проекту – «не застосовувати соціальну інженерію». Так ось, пропоную поміркувати, наскільки б зрізався весь цей Боллівуд зі спецефектами, якщо все-таки можна було б застосувати банальний фішинг. Але особисто мені було дуже цікаво це все робити. Сподіваюся, вам було цікаво це читати. Звичайно, не кожен проект виглядає так інтригуюче, але робота в цілому дуже головоломна і не дає застоюватися.
Напевно, у когось виникне питання: а як захиститись? Навіть у цій статті описано багато технік, багато з них адміністратори Windows навіть не знають. Проте пропоную подивитися на них із позиції побитих принципів та заходів інформаційної безпеки:
- не застосовувати застаріле програмне забезпечення (пам'ятаєте Windows 2003 на початку?)
- не тримати включеними непотрібні системи (навіщо був сайт уролога?)
- перевіряти паролі користувачів на міцність самостійно (інакше це зроблять солдати... пентестери)
- не мати однакових паролів до різних облікових записів (компрометація VDI)
- та інше
Звичайно, реалізувати це дуже важко, але в наступній статті ми покажемо практично, що це цілком можливо.
Джерело: habr.com