Взлом сервера Windows NT

скрізь, але спробувати варто.  Це все логічно, якщо на сервері распологается Web-сайт.  Якщо до скрипту після його імені в рядку браузера додати точку (file. asp. ) Або замінити її в імені на. , То іноді ми бачимо відображення вихідного коду сценарію.  Що нам це дасть? Там зберігаються некотрое паролі (незашифровані), наприклад, на сайті xakep. ru в скрипті edit. asp вони (паролі) є абсолютно точно, але там дірки заткнуті.  Також можна додати до імені файлу ось такий запит:: $ DATA і теж отримаємо вихідний код.  Але це нам не так важливо, як перегляд резервної копії SAM.  Справа в тому, що адмін в WinNT ніяким чином не може перевести паролі в інше місце ніж SAM.  При пошуку файлів на сервері ми можемо натрапити на скрипт codebrws. asp, він дає нам можливість отримання SAM, синтаксис запиту має бути такою: codebrws. asp? Source =/. . /. . /. . /. . / winnt / repair / sam. _

Діагностичний сценарій shopdbtest. asp, доступний будь-якому користувачеві, дозволяє розкрити місцеположення бази даних посеред значення xDatabase. Може стати в нагоді не кожному.

В установку за замовчуванням, файли конфігурації shopping400. mdb/shopping300. mdb доступні через інтернет.  У файлах міститься всі дані конфігурації, включаючи деталі про користувачів і їх кредитних картках в незашифрованому вигляді.  За замовчуванням встановлюється пароль адміністратора vpasp / vpasp або admin / admin.  На багатьох Web сайтах цей пароль не змінюють.  Також можливо обійти ідентифікацію ім'я користувача та пароль, вводячи такі значення в поле імені та пароля: 'or''=' в сценарії shopadmin. asp

 Але це тільки для інтернет-магазинів.

Ось ще кілька дірок:

- Уразливість механізму пакетної передачі даних.  У версіях 4. 0, 5. 0 та 5. 1 IIS виявлена уразливість даного роду, яка призводить до помилки присвоєння розміру буфера переданих даних.

- Уразливість при обробці інформації http-заголовка.

- Уразливість при обробці? Server-side includes | і ISAPI

фільтра, що відповідає за HTR файли.

Крім названих дір, також є наступні проблеми:

- Дірки, що призводять до відмови системи в роботі і бесполезностівеб-сервера.  Одна з них викликана некоректною роботою ISAPIфільтров в збійних ситуаціях, а інша - неправильної обработкойзапросов про стан поточного з'єднання FTP службою FTP.

- Три уразливості ряду? Cross-Site Scripting |: одна пов'язана состраніцей пошуку файлів IIS, інша - з сторінкою ошібкіhttp-з'єднання (http error page), і третя - з сторінкою, що повідомляє про помилку перенаправлення URL

Однією з найбільш перспективних дір є уразливість в default. asp.  При наступному синтаксисі ми отримуємо шлях з деяких файлів на серваке:

Використовувати цю уразливість можна таким шляхом:

http://www. xxx. com/default. asp?sector=anything

Наприклад: http://www. xxx. com/zzz/default. asp?sector=lamers

видасть вам вікно з наступною інформацією:

error '80020009 'Exception occurred.  D: SITIOS_WEBTECTIMESNUEVOzzz. . / body. htm,

line 74 Як ви можете чудово бачити, що це показаний реальний шлях до каталогу сайту.  У интеренете достатньо документації про дірки в asp можете почитати і там. :-)

Про cgi дірках писати немає сенсу (багато бо це йшлося).  У WinNT їх до того ж затикають не так часто як на Unix, тому що в юніксойде перл є стандартною мовою, а в віндузе вбудовуваним.

Крок 4.  Зусилля на SAM або перебиральників.

Якщо вже ви задалися метою отримати доступ до цього сервак, то вам так чи інакше потрібні паролі його адміністраторів або спочатку просто користувачів. Можна спробувати стандартний guest у всіх його поєднаннях.  Ще є тут одна заковика, справа в тому, що при користуванні Unix, адмін завжди має ім'я користувача root, a тут це може бути admin, administrator, тощо.  Зрозуміло ніби.

Якщо усіма попередніми способами вам не вдалося тягнути "самки", то напевно цей сервант круто захищена, чтож доведеться атакувати в лоб.  Тягнемо з рідною хакзони

1 2 3 4