IIS - Internet Information Services
Test executable file extensions:
asp
aspx
config
php
Витікання внутрішньої IP-адреси
На будь-якому сервері IIS, де ви отримуєте 302, ви можете спробувати видалити заголовок Host і використовувати HTTP/1.0, а в відповіді заголовок Location може вказувати на внутрішню IP-адресу:
Відповідь, що розкриває внутрішню IP-адресу:
Виконання .config файлів
Ви можете завантажувати .config файли та використовувати їх для виконання коду. Один зі способів зробити це - додати код в кінець файлу всередині HTML коментаря: Завантажити приклад тут
Більше інформації та технік для експлуатації цієї вразливості тут
Брутфорс виявлення IIS
Завантажте список, який я створив:
Він був створений шляхом об'єднання вмісту наступних списків:
https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/IIS.fuzz.txt http://itdrafts.blogspot.com/2013/02/aspnetclient-folder-enumeration-and.html https://github.com/digination/dirbuster-ng/blob/master/wordlists/vulns/iis.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/aspx.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/asp.txt https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt
Використовуйте його без додавання будь-якого розширення, файли, яким це потрібно, вже мають його.
Перехід по шляху
Витік вихідного коду
Перевірте повний опис за адресою: https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html
У підсумку, є кілька web.config файлів всередині папок програми з посиланнями на "assemblyIdentity" файли та "namespaces". З цією інформацією можливо дізнатися де розташовані виконувані файли та завантажити їх. З завантажених Dll також можливо знайти нові простори імен, до яких слід спробувати отримати доступ і отримати web.config файл, щоб знайти нові простори імен та assemblyIdentity. Також файли connectionstrings.config та global.asax можуть містити цікаву інформацію.\
У .Net MVC додатках файл web.config відіграє важливу роль, вказуючи на кожен бінарний файл, на який покладається програма через XML теги "assemblyIdentity".
Дослідження бінарних файлів
Приклад доступу до файлу web.config показано нижче:
Цей запит виявляє різні налаштування та залежності, такі як:
EntityFramework версія
AppSettings для веб-сторінок, валідації клієнтів та JavaScript
System.web конфігурації для аутентифікації та виконання
System.webServer налаштування модулів
Runtime прив'язки збірок для численних бібліотек, таких як Microsoft.Owin, Newtonsoft.Json та System.Web.Mvc
Ці налаштування вказують на те, що певні файли, такі як /bin/WebGrease.dll, розташовані в папці /bin програми.
Файли кореневої директорії
Файли, знайдені в кореневій директорії, такі як /global.asax та /connectionstrings.config (який містить чутливі паролі), є важливими для конфігурації та роботи програми.
Простори імен та Web.Config
Додатки MVC також визначають додаткові web.config файли для специфічних просторів імен, щоб уникнути повторюваних декларацій у кожному файлі, як показано на прикладі запиту на завантаження іншого web.config:
Завантаження DLL
Згадка про власний простір імен вказує на наявність DLL з назвою "WebApplication1" у каталозі /bin. Після цього показано запит на завантаження WebApplication1.dll:
Це вказує на наявність інших важливих DLL, таких як System.Web.Mvc.dll та System.Web.Optimization.dll, у каталозі /bin.
У сценарії, де DLL імпортує простір імен під назвою WebApplication1.Areas.Minded, зловмисник може зробити висновок про існування інших файлів web.config у передбачуваних шляхах, таких як /area-name/Views/, що містять специфічні конфігурації та посилання на інші DLL у папці /bin. Наприклад, запит до /Minded/Views/web.config може виявити конфігурації та простори імен, які вказують на наявність іншої DLL, WebApplication1.AdditionalFeatures.dll.
Загальні файли
З тут
HTTPAPI 2.0 404 Error
Якщо ви бачите помилку, подібну до наступної:
Це означає, що сервер не отримав правильне ім'я домену в заголовку Host. Щоб отримати доступ до веб-сторінки, ви можете подивитися на наданий SSL сертифікат і, можливо, знайдете там ім'я домену/піддомену. Якщо його там немає, вам, можливо, потрібно буде брутфорсити VHosts, поки не знайдете правильний.
Старі вразливості IIS, на які варто звернути увагу
Вразливість/функція символу тильди “~” Microsoft IIS – Розкриття коротких імен файлів/папок
Ви можете спробувати перерахувати папки та файли всередині кожної виявленої папки (навіть якщо це вимагає базової аутентифікації), використовуючи цю техніку. Основне обмеження цієї техніки, якщо сервер вразливий, полягає в тому, що вона може знайти лише перші 6 літер імені кожного файлу/папки та перші 3 літери розширення файлів.
Ви можете використовувати https://github.com/irsdl/IIS-ShortName-Scanner для перевірки цієї вразливості:java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/
Оригінальне дослідження: https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf
Ви також можете використовувати metasploit: use scanner/http/iis_shortname_scanner
Обхід базової аутентифікації
Обійти базову аутентифікацію (IIS 7.5), намагаючись отримати доступ до: /admin:$i30:$INDEX_ALLOCATION/admin.php
або /admin::$INDEX_ALLOCATION/admin.php
Ви можете спробувати поєднати цю вразливість з останньою, щоб знайти нові папки та обійти аутентифікацію.
ASP.NET Trace.AXD увімкнено налагодження
ASP.NET включає режим налагодження, і його файл називається trace.axd
.
Він зберігає дуже детальний журнал усіх запитів, зроблених до програми протягом певного періоду часу.
Ця інформація включає IP-адреси віддалених клієнтів, ідентифікатори сесій, усі куки запитів і відповідей, фізичні шляхи, інформацію про вихідний код і потенційно навіть імена користувачів і паролі.
https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F31736688%2F112974448-2690b000-915b-11eb-896c-f41c27c44286.png&width=768&dpr=4&quality=100&sign=2de6df0b&sv=1)
ASPXAUTH Cookie
ASPXAUTH використовує таку інформацію:
validationKey
(рядок): ключ у шістнадцятковому кодуванні для використання для перевірки підпису.decryptionMethod
(рядок): (за замовчуванням “AES”).decryptionIV
(рядок): вектор ініціалізації у шістнадцятковому кодуванні (за замовчуванням вектор нулів).decryptionKey
(рядок): ключ у шістнадцятковому кодуванні для використання для розшифрування.
Однак деякі люди використовують значення за замовчуванням цих параметрів і використовують як куку електронну пошту користувача. Тому, якщо ви зможете знайти веб-сайт, що використовує ту ж платформу, яка використовує куку ASPXAUTH, і ви створите користувача з електронною поштою користувача, якого хочете видати на сервері під атакою, ви зможете використати куку з другого сервера на першому і видати себе за користувача. Цей напад спрацював у цьому описі.
Обхід аутентифікації IIS з кешованими паролями (CVE-2022-30209)
Повний звіт тут: Помилка в коді не перевіряла належним чином пароль, наданий користувачем, тому зловмисник, чий хеш пароля потрапляє в ключ, який вже є в кеші, зможе увійти як цей користувач.
Last updated