LU.NET.UA - Захист інформації в інтернеті

:: Меню ::

Головна
Введення

Частина I.
Вивчення мети

1. Попередній збір даних
2. Сканування
3. Інвентаризація

Частина II.
Уразливість систем

4. Уразливість Windows 95/98/me
5. Уразливість Windows NT
6. Уразливість Windows 2000

Частина III.
Уразливість мереж

9. Уразливість видалених з'єднань, РВХ, Voicemail і віртуальних приватних мереж
10. Мережеві пристрої
11. Брандмауери
12. Атаки DOS

   Частина IV.
Уразливість програмного забезпечення

13. Вади засобів видаленого управління
14. Розширені методи
15. Уразливість в Web
16. Атаки на користувачів Internet
 Братани
Карта сайту
Добавити у вибране

:: Друзі ::

--

:: Статистика ::

 

 

 

 

 


Використання довірчих стосунків

Для того, щоб "отримати в своє розпорядження" домен, недостатньо володіти правами адміністратора на одному з комп'ютерів мережі. Фактично у великих мережах багато серверів NT є незалежними серверами додатків (тобто комп'ютерами, які використовуються кінцевими користувачами, але що працюють під управлінням операційної системи Windows NT Server, а не NT Workstation), а не контроллерами доменів, на яких зберігаються копії бази даних SAM домена. Проте у розпорядженні зломщика є декілька способів отримання інформації від автономного сервера, на підставі якої можна дістати доступ до всього домена.

Дублювання даних облікових записів адміністраторів домена і локальної системи


Найпростішим методом проникнення є використання досить поширеної порочної практики адміністрування, що полягає в зберіганні даних про користувачів домена на окремих комп'ютерах, що працюють під управлінням NT Server або Workstation. У ідеальній ситуації ніхто не повинен володіти правом реєстрації на робочій станції NT як Local Administrator з тим же паролем, що і Domain Admin. To же саме відноситься і до створення локального облікового запису з тими ж призначеним для користувача ім'ям і паролем, які використовуються в обліковому записі на рівні домена. Проте в реальності така практика є, швидше, правилом, а не виключенням. Подібна один-єдина вада в системі захисту може привести до створення "лазівок" для проникнення в домен NT, з чим нам не раз доводилося стикатися при тестуванні різних мереж.
Наприклад, допустимо, що що розсердився на керівництво службовець виявив в домені тестовий сервер, що дозволяє реєструватися на нім як локальний адміністратор з порожнім паролем. Сам по собі цей факт ще нічого не означає, оскільки користувач не зможе дістати доступ до домена, тому що привілеї локального облікового запису не розповсюджуються на домен. Проте якщо адміністратор цього тестового сервера створив на нім обліковий запис, який дублює його обліковий запис на рівні домена (як правило, це робиться для того, щоб спростити доступ до ресурсів домена, необхідних для тестування), зломщик без яких-небудь проблем отримає дамп SAM з реєстру, як було показано в попередньому розділі, і зламає пароль адміністратора домена. Після цього він без зусиль реєструватиметься на контроллері домена з привілеями системного адміністратора — і все це, лише скориставшись даними обліковому запису Domain Admin.
На жаль, такі ситуації зустрічаються набагато частіше, ніж хотілося б. Щоб виправити положення, необхідно перевірити, чи не мають місця у вашій мережі наступні факти.

  •  Паролі локальних облікових записів Administrator збігаються з паролями членів групи Domain Admins.
  •  Паролі і призначені для користувача імена локальних облікових записів збігаються з паролями і призначеними для користувача іменами облікових записів домена (особливу увагу необхідно приділити обліковим записам, які входять до групи Domain Admins).
  •  У полях коментаря вказана інформація, яка може послужити підказкою для отримання даних про пароль домена, наприклад: "Пароль такий же, як і у адміністратора на Server1".

Контрзаходи проти дублювання даних облікових записів


Самим кращим захистом від таких "підводних каменів" є використання складних паролів для всіх облікових записів групи адміністраторів домена і їх подальша регулярна зміна (не рідше, ніж один раз в місяць). Крім того, призначені для користувача облікові записи не повинні використовуватися для виконання адміністративних функцій. Якщо в цьому є необхідність, створіть для таких користувачів спеціальні облікові записи і встановите режим їх аудиту. Наприклад, замість того щоб вносити обліковий запис jsmith до групи Domain Admins, створіть обліковий запис jsmitha з відповідним рівнем привілеїв. (Звернете увагу, що не варто створювати облікові записи виду isadmin, оскільки вони відразу ж привернуть увагу зломщика.)
Ще одним хорошим практичним методом є використання NT-варианта утиліти UNIX su (з набору NTRK) для запуску команд з привілеями іншого користувача.

Вбудована команда runae Windows 2000 надає простіший спосіб запуску додатків з необхідними привілеями. Наприклад, наступна команда runas запускає сеанс командної оболонки, що працює в контексті облікового запису Administrator домена Domain2.

runas /user:domain2\administrator cmd.exe

Атака на секрети LSA


Ця атака може послужити одним з найяскравіших прикладів тієї небезпеки, до якої може привести зберігання реєстраційних даних в незашифрованому вигляді. Така інформація разом з деякими іншими важливими даними зберігається системою NT в багатьох місцях. Процес отримання конфіденційної інформації носить назва атаки на секрети підсистеми захисту LSA (Local Security Authority). Ету інформація визначається параметром системного реєстру Hkey_local_machine\-security\policy\secrets. До секретів LSA відносяться наступні дані.

  •  Паролі облікових записів служб (зберігаються у вигляді незашифрованого тексту). Спеціальні облікові записи потрібні додаткам, яким необхідно реєструватися в контексті локального користувача для виконання певних завдань, наприклад резервного копіювання. Такі облікові записи зазвичай є в зовнішніх доменах і при зломі якого-небудь комп'ютера можуть використовуватися зломщиком для прямої реєстрації в зовнішньому домені.
  •  Кешированниє хэш-коды паролів останніх десяти користувачів, що реєструвалися.
  •  Паролі FTP і Web (також у вигляді незашифрованого тексту).
  •  Імена і паролі облікових записів служб RAS. 
  •  Паролі робочих станцій для доступу до домена.
Очевидно, що такі відомості, як паролі облікових записів служб, запушених з привілеями користувачів домена, інформація про останніх користувачів, що реєструвалися, паролі доступу робочих станцій до домена і так далі можуть надати зломщикові істотну допомогу в дослідженні структури домена.
Наприклад, представимо автономний сервер, на якому запущені служби SMS (Systems Management Server) або SQL, що працюють в контексті користувача домена. Якщо локальний адміністратор такого сервера використовує порожній пароль, то за допомогою даних LSA зломщик може отримати зведення про обліковий запис користувача домена. Ця вада може привести до просочування інформації на рівні багаторангового домена (multimaster domain). Якщо на сервері ресурсів домена запущена служба, що працює в контексті облікового запису користувача головного домена, то просочування інформації на рівні сервера ресурсів може забезпечити зловмисникові доступ до головного домена.
Можна привести і небезпечніший приклад, який досить типовий для корпоративних користувачів портативних комп'ютерів. Допустимо, співробітник компанії захопив з собою в поїздку такий комп'ютер, щоб за допомогою служби видаленого доступу підключатися до корпоративної мережі або до провайдера Internet. Оскільки він не новачок в питаннях безпеки, він не встановлює прапорець, що включає режим збереження паролів облікових записів видаленого доступу. Але, на жаль, система NT все одно глибоко в надрах системного реєстру зберігає призначене для користувача ім'я, номер телефону і пароль.
Початковий код, що дозволяє отримати секрети LSA, в 1997 році був опублікований в бюлетені Ntbugtraq (http://www.ntbugtraq.com) Полом Ештоном (Paul Ashton). Виконуваний код, що проте згенерував, не набув широкого поширення. Оновлену версію цієї коди, звану Isadump2, можна знайти за адресою http://razor.bindview.com/tools/desc/lsadump2_readme.html. Утиліта Isadump2 використовує той же прийом, що і утиліта pwdump2. Це дозволяє обійти засоби захисту компанії Microsoft (див. нижчий), які раніше не дозволяли успішно застосовувати попередню версію цього засобу, Isadump. Утиліта Isadump2 виконує автоматичний пошук ідентифікатора PID процесу LSASS, упроваджує себе в його потік управління і витягує секрети LSA, як показано в наступному прикладі.

D:\toolbox>lsadump2 $MACHINE.ACC
6e 00 76 00 76 00 68 00 68 00 5a 00 30 00 41 00
n.v.v.h.h.z.0.a.
66 00 68 00 50 00 6c 00 41 00 73 00 f.h.p.l.a.s.
_sc_mssqlserver
32 00 6d 00 71 00 30 00 71 00 71 00 31 00 61 00
.p.a.s.s.w.о.г.d.
_sc_sqlserveragent
32 00 6d 00 71 00 30 00 71 00 71 00 31 00 61 00
p.a.s.s.w.о.г.d.

Як видно з приведеного фрагмента, в отриманих даних міститься пароль облікового запису домена, а також два паролі, пов'язаних з обліковими записами служби SQL, які витягують з даних LSA.
У програмі Internet Scanner 5.6 від компанії Internet Security Systems (ISS) вбудована можливість інвентаризації секретів LSA, яка входить як складова частина в технологію Smartscan. Якщо цей сканер зможе дістати доступ до вузла NT на рівні адміністратора, він спробує інвентаризувати всі можливі паролі, які коли-небудь використовувалися на даному вузлі. Всі знайдені пари "ім'я облікової запіси/пароль" зберігаються у файлі Knownusers. У тих випадках, коли сканер виявляє (через нульове з'єднання) в мережі інший вузол, на якому є обліковий запис з таким же ім'ям, він намагається підключитися до нього, вказавши тільки що знайдений пароль. Не потрібно володіти великою уявою, щоб зрозуміти, наскільки швидко можна зібрати найважливішу інформацію про всіх або майже всіх облікових записах великої мережі.

Контрзаходи: захист секретовlsa


На жаль, компанія Microsoft не сказала нічого оригінального, заявляючи, що до подібної інформації адміністратор має доступ відповідно до прийнятої архітектури. У статті бази знань KB Q184017 описується модуль оновлення, призначений для виправлення вад початкової версії підсистеми LSA. Після його установки за допомогою шифрування SYSKEY кодуються паролі облікових записів служб, що зберігаються на комп'ютері, кешируємиє дані для реєстрації в домені, а також паролі робочої станції.
Вада, що полягає у відкритому зберіганні кешируємих даних RAS, була виправлена в сервісному пакеті Sp6a (спочатку після появи сервісного пакету Sp5 компанією Microsoft був випущений модуль оновлення). Докладніша інформація приведена в статті KB Q230681.

Параметри реєстру, призначені для автоматичної реєстрації


Систему NT можна набудувати так, щоб при завантаженні виконувалася автоматична реєстрація в системі. Для цього використовується параметр системного реєстру Hklm\sofwtare\microsoft\windows Nt\currentversion\winlogon\autoadminlogon. Автоматична реєстрація може виявитися корисною в тих окремих випадках, коли неже-
лательно, щоб користувач знав реєстраційне ім'я і пароль. Проте необхідно знати, що в цьому режимі в реєстрі (група параметрів Hklm\sofwtare\microsoft\ Windows Nt\currentversion\winlogon\) зберігаються в незашифрованому вигляді такі відомості, як використовувані за умовчанням ім'я домена (Defaultdomainname), призначене для користувача ім'я (Defaultusername) і пароль (Defaultpassword).
Остерігайтеся також застосування процедур автоматичної установки програмного забезпечення, яким після перезавантаження потрібна автоматична реєстрація з привілеями адміністратора.

Контрзаходи проти автоматичної реєстрації


Для того, щоб заборонити автоматичну реєстрацію, видалите значення параметра Defaultpassword. Крім того, потрібно видалити значення параметра Autoadmin Logon або встановити його рівним 0.

Реєстратори натиснення клавіш


Якщо решта всіх спроб зломщика, що має статус адміністратора локальної системи, отримати аналогічні привілеї в домені не увінчалися успіхом, він може спробувати піти найпростішим шляхом: встановити реєстратор натиснення клавіш (keystroke logger). Так називаються програми, які скритно від користувача перехоплюють всі натиснення клавіш і, перш ніж передати їх операційній системі, записують в прихований файл на диску. Рано чи пізно який-небудь користувач, реєструється в системі, залишить відповідний "відбиток" свого імені і пароля у файлі програми-реєстратора.
Існує безліч різних реєстраторів для Windows NT, проте, мабуть, одним з кращих є Invisible Кеу Logger Stealth (IKS) for NT, який можна знайти на вузлі http: //www.amecisco.com/iksnt.htm за ціною $149.
IKS for NT — це, по суті справи, драйвер клавіатури, який працює усередині ядра NT. Саме цим і пояснюється те, що його присутність практично ніяк не відображається в системі. IKS перехоплює навіть натиснення комбінації клавіш <Ctrl+alt+del>, що дозволяє дуже легко ідентифікувати кожен факт реєстрації в системі.
Проте ще важливіше те, що дуже просто здійснити видалену установку IKS. Для цього досить скопіювати один файл, відредагувати деякі параметри реєстру, а потім перезавантажитися. Зловмисник, швидше за все, перейменує драйвер iks.sys, привласнивши йому якесь ім'я, що не викликає підозр, наприклад scsi.sys (у кого підніметься рука, щоб видалити такий драйвер?), а потім скопіює його в каталог %systemroot%\system32\drivers. Після цього залишається лише внести зміни до системного реєстру відповідно до вмісту файлу iks.reg, що входить в комплект постачання, або просто запустити на видаленому комп'ютері файл .reg. Можна скористатися також програмою regini.exe, що входить до складу NTRK, яка може внести зміни в реєстр видаленого вузла. У файлі readme.txt, який входить в комплект постачання IKS, пояснюється, як приховати драйвер і файл журналу з перехопленими натисненнями клавіш, змінивши вміст файлу .reg. Після внесення змін до реєстру необхідно перезавантажити систему, щоб драйвер IKS приступив до роботи. Для виконання цього завдання найпростіше скористатися інструментом Remote Shutdown з NTRK (shutdown. exe), як показано в наступному прикладі (докладний опис параметрів командного рядка міститься в документації по NTRK). shutdown \\<±р_адрес> /r /t:l /y /с
Якщо все пройде гладко і ніхто не оберне уваги на дивну поведінку комп'ютера-жертви, то всі натиснення клавіш зберігатимуться у файлі, вказаному в останньому рядку файлу iks . reg. Почекавши якийсь час, зломщик знову реєструватиметься як адміністратор, перепише отриманий файл (за умовчанням він називається iks.dat, але, швидше за все, він буде перейменований), а потім проглядає його за допомогою утиліти datview, вхідного в комплект постачання IKS. Нижче приведено діалогове вікно налаштування параметрів datview.


За декілька тижнів роботи утиліта IKS, як правило, перехоплює хоч би одну пару "ім'я користувача/пароля" рівня домена, які зазвичай знаходяться після запису, що згенерував при натисненні <Ctrl+alt+del>.

Контрзаходи: захист від програм-реєстраторів


Виявити програми-реєстратори не так-то просто. Це пояснюється тим, що вони упроваджуються в систему на низькому рівні. Що стосується IKS, ми рекомендуємо пошукати в системному реєстрі параметр Logname, який повинен знаходитися десь в групі параметрів Hklm\system\currentcontrolset\services. Значенням цього параметра є шлях до журналу реєстрації клавіш, що натискаються. Параметр, в якому знаходиться дане значення, можна безболісно видалити (природно, дотримуючи звичайні обережності, пов'язані з редагуванням системного реєстру). Для виявлення ж самого драйвера IKS потрібно володіти якоюсь мірою навиками сищика, щоб розпізнати його серед інших файлів . sys, що зберігаються в каталозі %systemroot%\system32\drivers. Найпростішим методом є перевірка властивостей кожного файлу. У вкладці Version діалогового вікна властивостей IKS буде вказано IKS Nt4 Device Driver, а як внутрішнє ім'я — iksnt. sys.
Діставши доступ до домена, зломщик захоче скористатися своїм статусом адміністратора сервера як плацдарм для подальшого "захоплення територій". У наступному розділі описуються деякі методики досягнення цієї мети і відповідні ним контрзаходи.




:: Реклама ::

>Страница статей


:: Посилання ::

-

аипи

:: Рекомендуємо ::

-


 

 

 

 


Copyright © Klab-F 2008