Сервер сообщает что он находится в digest
Сервер сообщает что он находится в digest
Общие обсуждения
Все ответы
1) Уточните на сервере какое ПО установлено?
Возможно одно из ПО использует 80 порт, к примеру Skype, сторонние веб-сервера apache, nginx и т.п.?
2) Сколько сайтов настроено на веб-сервере IIS?
Покажите результат выполнения следующих команд в powershell:
1) Покажите пожалуйста результат следующей команды в командной строке (cmd.exe):
P.S. Также для исключения блокировок со стороны firewall, попробуйте отключить firewall, если он используется на сервере, как Windows Firewall или сторонний.
2) Также в некоторых случаях помогает удаление Microsoft Web deploy, в случае если он требуется то пробуете его установить заново.
By default, the remote service will be URL http://+:80/MsDeployAgentService. This default URL should only be used on test computers, not on production servers.
Подробнее: Web Deployment Tool Installation
Порт 80 прослушивается драйвером http.sys (что есть правильно).
Посмотреть, каким URL какие очереди подключены, и какие процессы с этими очередями связаны можно командой
netsh http show servicestate requestq
В выдаче команды можно увидеть PID процесса, который зарегистрировал URL-адрес http://*:80/. Определить имя процесса по его PID можно командой tasklist /FI «PID eq значение_PID».
Если такого процесса нет, то следует посмотреть зарезервированные URL командой netsh http show urlacl
1. результат одинаковый, что с firewall, что без:
C:\Windows\system32>netsh http show urlacl
Зарезервированный URL-адрес : http://+:80/Temporary_Listen_Addresses/
Пользователь: \Все
Прослушивать: Yes
Делегировать: No
SDDL: D:(A;;GX;;;WD)
Зарезервированный URL-адрес : http://*:80/
Пользователь: NT AUTHORITY\LOCAL SERVICE
Прослушивать: Yes
Делегировать: No
SDDL: D:(A;;GX;;;LS)
2. Microsoft Web deploy у меня не установлена, службы msdepsvc нет, а предложенная статья, я так поняла, расчитана на Windows Server 2008
Сервер сообщает что он находится в digest
Общие обсуждения
Ночью работало. Утром не работает. Моя ситуация чем то близка к https://social.technet.microsoft.com/Forums/ru-RU/7e6eb6ae-70d7-4b24-ad7f-c0954c565fdb/exchange-2013-powershell-?forum=exchange2013ru Только у меня земля горит под ногами. Клиенты (10 штук всего) не могут подключиться к Excnahge 2013
Диспетчер служб IIS Не удается запустить этот веб-сайт. Возможно, этот же порт используется другим веб-сайтом.
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4 System
Не могу понять – что же мешает Default Web Site стартануть на 80 порту – не пойму кто там живет.
HTTP Error 400. The request verb is invalid.
Не посрамим же Exchange – прошу помощи J
PS : у меня сегодня День Рождения.
Служба веб-публикаций не зарегистрировала префикс URL-адреса http://*:80/ для сайта 1. Возможно, необходимая привязка к сети уже используется. Сайт был отключен. Поле данных содержит номер ошибки. Код 1007
C:\Windows\System32\inetsrv>appcmd.exe list site
SITE «Default Web Site» (id:1,bindings:net.msmq/localhost,msmq.formatname/localh
ost,net.tcp/808:*,net.pipe/*,https/:443:,https/127.0.0.1:443:,http/127.0.0.1:80:
sr1.****.local,http/192.168.2.254:80:sr1.****.local,state:Stopped)
SITE «Exchange Back End» (id:2,bindings:http/*:81:,https/*:444:,net.pipe/*,state
:Started)
Все ответы
Defalt Web Site запустил, удалив привязки. рестартовал IIS но https://localhost/ecp/?ExchClientVer=15 выдает » Соединение было сброшено Во время загрузки страницы соединение с сервером было сброшено.»
«http://sr1.***.local» запрашивает имя пользователя и пароль. Сайт сообщает: «Digest»
powershel exchange всю ту же ошибку kerberos.
Система аутентификации на базе протокола HTTP Digest. Усиление модуля.
У Basic есть один недостаток, а именно username и password передаются по сети открыто (clear text), base64 кодировка не может считаться защитой.
Аутентификация Digest
Расширим нашу систему из предыдущей статьи.
К преимуществам Digest можно отнести следуещее:
Один сайт может одновременно использовать несколько систем защиты, например Basic и Digest
Пришло время рассмотреть работу алгоритма Digest аутентификации:
Разберём заголовок WWW-Authenticate (как вы заметили, он усложнился по сравнению с заголовком Basic):
3. У юзера всплывает модальное окно, предлагающее ввести username и password (обратите внимание, окно отличается от Basic окна). Происходит запрос юзера для аутентификации:
Теперь разберём заголовок Authorization:
4. Последовательность обработки запроса пользователя
5. Проверка пароля пользователя
6. выдаём состояние ответа сервера 401, поднимающее модальное окно как в пункте 2 иначе говоря формируем WWW-Authenticate по типу Digest
HTTP Модуль AuthDigest
Ну что ж, вооружившись рассмотренными выше теоретическими выкладками напишем наш HttpModule, который воплотит Digest аутентификацию.
Всё. HttpModule готов. Подключим его к веб приложению: Для этого в файле web.config в разделе sytem.web пишем
отменяем встроенную аутентификацию
и сохраняем данные для Digest аутентификации (realm string, алгоритм, qop string, server opaque)
Алгоритм Digest аутентификации не претендует на решение всех задач, связанных с безопасностью в интернете. Эта схема не кодирует содержимое запроса-ответа. Цель Digest заключается в том, чтобы обеспечить систему аутентификации, такую же простую и удобную, как и Basic, но в которой бы отсутствовали недостатки, присущие Basic аутентификации. Тем не менее эта система гораздо сильнее, чем например CRAM-MD5, которая была предложена для LDAP, POP и IMAP(rfc 2195).
К коду прилагаются database scripts и упрощённый класс для работы с базой.
Аутентификация и авторизация в микросервисных приложениях
Автор: Вячеслав Михайлов, Solutions Architect
Это вводная часть материала, основанного на докладе, прочитанном мной прошлым летом. Печатный материал предполагает больше информации, т.к. в одном докладе обычно не получается рассказать обо всех деталях.
Что такое аутентификация?
На процессах аутентификации и авторизации основано разделения прав доступа, без которого не обходится ни одно более или менее серьезное приложение. Поэтому понимать, как они происходили раньше и происходят теперь, очень важно, но, прежде чем углубиться в описание технологии, давайте разберемся с ключевыми терминами.
Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию.
В ходе аутентификации мы удостоверяемся, что человек, который к нам пришел, обладает доказательствами, подтверждающими личность. В этой статье речь в основном пойдет как раз об аутентификации.
Способы аутентификации
При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.
HTTP Basic Authentication
Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.
HTTP Digest Authentication
Следующим этапом развития технологии стала чуть более сложная система HTTP digest authentication, которая исключает передачу учетных данных в открытом виде — здесь для проверки используется MD5-хеш с некоторыми примесями, что позволяет избежать подбора логина и пароля. Конечно, этот алгоритм выглядит более надежным, но и он подвержен целому ряду не самых сложных атак. Например, вот тут можно почитать об атаках более подробно.
Forms Authentication
Позднее появился процесс Forms authentication, при котором аутентификация происходит на более высоком уровне модели абстракции. HTTP-сервер при этом не сообщает об ошибке доступа, а просто перенаправляет неаутентифицированного пользователя на другую страницу. Обычно на этой странице отображаются поля для ввода логина и пароля, после заполнения которых формируется POST-запрос с данными и через защищенный канал направляется на сервер. Серверная сторона в свою очередь возвращает пользователю токен или идентификатор сессии, который сохраняется в Cookies и в дальнейшем используется для доступа к защищенному ресурсу.
Token Authentication
На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.
На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.
OAuth2 & Open ID Connect
Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.
В случае сервиса, который от имени пользователя должен через определенные промежутки времени опрашивать некий третий ресурс, — допустим, получать доступ к списку контактов в социальной сети — токен-аутентификация работать уже не будет. Дело в том, что идентификаторы сессии обычно живут очень недолго, чтобы в случае их перехвата злоумышленники получили доступ к сервису лишь на ограниченное время. Но из-за короткого срока действия токена не хватает, например, на ночной процесс.
В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.
Разбираемся детально ху из ху
OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.
Взгляд сверху
Обычно в системах встречаются разные компоненты: пользователи, работающие через браузер, пользователи, взаимодействующие с сервером через мобильные приложения, и просто серверные приложения, нуждающиеся в принадлежащих вам данных, хранящихся на других серверах, доступ к которым осуществляется через Web API.
Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов.
В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.
На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.
Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.
Терминология OAuth2 & OpenID Connect
Сервис выдачи токенов
Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.
Клиент
Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).
Пользователь
User — собственно конечный пользователь — человек.
Область (scope)
Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.
По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов.
Scopes бывают двух видов:
Запрос на аутентификацию
Authentication/Token Request — процесс запроса аутентификации.
Токен личности
Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.
Токен доступа
Access Token — информация, что конкретному пользователю разрешается делать. Клиент запрашивает Access Token и затем использует его для доступа к ресурсам (Web APIs). Access Token содержит информацию о клиенте и пользователе, если она присутствует. Важно понимать, что есть такие типы авторизации, при которых пользователь в процессе непосредственно не участвует (подробнее об этом в следующей части)
Токен обновления
Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.
Более подробно о составе токенов в разделе «структура токена».
Процесс аутентификации
При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.
Структура токена
Формат
В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.
В том, что токены в процессе обмена передаются незашифрованными, ничего страшного нет. Мы изначально исходим из предположения, что коммуникация происходит по защищенному HTTPS-каналу, и повторное шифрование токена было бы избыточным. Единственное, в чем нам нужно убедиться – то, что токен не был подменен или сфальсифицирован на клиентской стороне, для этого достаточно иметь подпись и проверять ее на сервере. Кроме того, токен не содержит никакой критически важной информации.
Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.
Основные поля
Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:
Заключение первой части
В этой статье мы постарались дать теоретический и терминологический фундамент, который понадобится нам создании работающего решения в следующих статьях.
Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:
Минимальная реализация интеграции веб-клиента с Identity Server:
Минимальная реализация интеграции веб-API с Identity Server:
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Атаки на HTTP Basic и Digest аутентификацию
Оглавление
Что такое HTTP Basic и Digest аутентификация
HTTP Basic и Digest аутентификации предназначены для контроля доступа на уровне веб-сервера. Если при попытке открыть веб-страницу или войти в настройки роутера вы видите такое окно:
То это означает, что на веб-сервере используется аутентификация одного из этих видов.
Нам более привычна аутентификация с помощью веб-форм, когда чтобы попасть в раздел с ограниченным доступом мы вводим логин и пароль в форму на веб-странице, например:
Эти два вида аутентификаций довольно разные. Алгоритм работы аутентификации через веб форму входа примерно следующий:
Теперь, когда повсеместно используется шифрование HTTPS и перехват логина, пароля и кукиз стал практически невозможным, это довольно надёжный способ аутентификации. При добавлении защиты от брут-форса и политики, требующей сложных и длинных паролей, это весьма надёжный способ защиты доступа к данным пользователей.
Как можно догадаться, правильная и безопасная реализация описанного метода требует определённых усилий (проверка пароля, который обычно хранится в виде хеша, необходима база данных с паролями и токенами, нужно написать код веб-формы и код на стороне сервера, принимающий данные, получение и отправка кукиз и так далее).
HTTP Basic и Digest аутентификации очень сильно отличаются. Во-первых, они очень простые для реализации — достаточно создать на сервере файл с хешами пользователей и подключить его к веб-серверу.
Во-вторых, проверка проходит на уровне веб-сервера, не нужно заботиться о реализации аутентификации в веб-приложении, на веб-сайте.
Но и минусов у HTTP Basic и Digest аутентификации слишком много:
Кстати, при HTTP Basic и Digest аутентификации не используются кукиз, поэтому чтобы не приходилось вводить пароль каждый раз при доступе к серверу, веб-браузер пользователя запоминает введённые логин и пароль и отправляет их при каждом последующем запросе — в результате создаётся ощущения, что веб-сервер нас запомнил.
Насколько актуальны HTTP Basic и Digest Authentication
Фактически, HTTP Basic и Digest Authentication нечасто используются на веб-сайтах. Но если нужно быстро закрыть доступ к сайту, например, на период реконструкции, то можно встретить такой способ защиты. По крайней мере, даже в 2020 году выходят инструкции как установить защиту паролем с помощью HTTP Basic и Digest Authentication, например «How To Set Up Password Authentication with Apache on Ubuntu 18.04».
Кстати, я совершенно случайно, используя показанный ниже метод поиска хостов с HTTP Basic аутентификацией, вместо диапазона 100.64.0.0-100.127.255.255 (локальные IP адреса провайдера) начал сканировать диапазон 100.16.0.0-100.31.255.255 (обычные IP адреса Интернета). Ошибку я заметил далеко до окончания сканирования, но уже собрал около сотни хостов с HTTP Basic Authentication. Так что вполне себе актуально.
Но где действительно всё хорошо с HTTP Basic аутентификацией, так это в роутерах! Производителям роутеров нравилось её использовать благодаря простоте реализации — никаких баз данных, никакой проверки кукиз, только простейшая настройка веб-сервера. А пользователям нравится не менять свои роутеры по 5-10 лет, поэтому армия уязвимых к брут-форсу роутеров уже ждёт нас.
Как включить защиту паролем с помощью HTTP Basic и Digest аутентификации
Но начнём мы с того, что настроем свой веб-сервер для защиты паролем папок с помощью HTTP Basic аутентификации и HTTP Digest аутентификации.
Во-первых, те, кто не нашёл серверы для тренировки, смогут тренироваться на своём собственном (плюс этика и всё такое).
Во-вторых, когда настраиваешь сам, смотришь на работу службы или протокола «изнутри», то можно увидеть другие возможные слабости и костыли.
Я покажу на примере Kali Linux, но практически наверняка эта же инструкция будет работать и в Ubuntu, Debian, Linux Mint и их производных.
Как включить HTTP Basic аутентификацию в Apache (Kali Linux, Ubuntu, Debian, Linux Mint)
Для начала нужно включить поддержку файлов .htaccess, чтобы веб-сервер использовал настройки из этих файлов — по умолчанию это отключено.
Откройте файл /etc/apache2/apache2.conf
Найдите группу строк:
Сохраните и закройте файл.
Создайте папку, где будут защищённые паролем файлы:
С помощью утилиты htpasswd мы создадим файл с именем пользователя и хешем пароля. Если указана опция -c, то старый файл будет удалён, а новый создан. Утилита htpasswd присутствует и в Apache для Windows, но нужно указать полный путь до неё.
Если файл .htpasswd уже существует, то для добавления ещё одного пользователя, без удаления старых, используйте эту же команду, но без опции -c:
Для смены пароля, вновь используйте эту же команду без опции -c, указав имя пользователя, чей пароль вы хотите поменять.
Конечно же файл .htpasswd рекомендуется хранить в директориях, не доступных для постороннего доступа (например, /etc/apache2/.htpasswd). Особенно не нужно его хранить в папках веб-сервера вместе с файлами сайтов. Но иногда веб-мастер в силу простоты или невозможности сохранить файл где-либо ещё (на виртуальных хостингах, например) хранит этот файл прямо вместе с файлами сайтов.
Поэтому при обнаружении HTTP Basic и Digest аутентификации всегда есть смысл поискать что-то похожее:
Посмотрим содержимое файла .htpasswd:
Теперь создадим файл .htaccess:
И скопируем в него:
Кстати, с программой htpasswd вы можете использовать опцию -B. Опция -B означает использовать для шифрования пароля bcrypt. В настоящее время это считается очень безопасным. Для наших тестов это безразлично, но для реальной защиты папки или сайта паролем рекомендуется выполнять показанные выше команды с опцией -B. В дополнении к этой опции вы можете использовать флаг -C со значением от 4 до 17. Он устанавливает время вычисления, используемое для алгоритма bcrypt (чем выше, тем безопаснее, но медленнее). Значением по умолчанию является 5.
Примечание: показанный способ (хранение файла .htpasswd в директории веб-сервера) универсален и может применяться даже на виртуальных хостингах. Но если у вас есть доступ к папке с настройками Apache (в производных Debian это /etc/apache2/), то храните этот файл там, то есть по пути /etc/apache2/.htpasswd. Инструкция с правильными для продакшена путями: «Как настроить аутентификацию по паролю с Apache в Debian, Ubuntu и производных».
Если вы хотите настроить базовую аутентификацию на Apache в Windows, то смотрите статью «Как защитить папку Apache паролем в Windows».
Как включить HTTP Digest аутентификацию в Apache (Kali Linux, Ubuntu, Debian, Linux Mint)
По умолчанию модуль Digest аутентификации отключён, включим его:
Откройте файл /etc/apache2/apache2.conf:
Найдите группу строк:
Сохраните и закройте файл.
Создайте папку, где будут защищённые паролем файлы:
Для генерации хешей паролей нужно использовать команду htdigest. Если указать опцию -c, то будет создан новый файл, а старый удалён.
Общий формат команды:
REALM — это область применения. Она соответствует директиве AuthName в файле .htaccess. То есть можно для одного пользователя установить разные пароли, изменяя значения REALM. В разных директивах можно менять значение AuthName в файле .htaccess и в зависимости от этого значения будет подходить тот или иной пароль.
Посмотрим содержимое файла .htpasswd:
Пример содержимого файла:
Теперь создадим .htaccess:
И скопируем в него следующее:
Отроем в веб-браузере адрес http://localhost/digest-protected/ и убедимся, что теперь для доступа к странице необходим пароль.
HTTP Basic и Digest аутентификация в командной строке
Чтобы узнать, какой тип аутентификации используется, достаточно посмотреть заголовки. Их можно посмотреть прямо в веб-браузере, открыв инструменты разработчика (F12).
Подробности о работе в Инструментах разработчика веб-браузеров смотрите в статьях:
Можно также посмотреть в командной строке с помощью утилиты cURL:
Для Basic аутентификации будет показан примерно следующий HTTP заголовок:
Для Digest будет присутствовать примерно следующий заголовок:
Чтобы в cURL выполнить авторизацию, то есть ввести логин и пароль для входа к ограниченным данным, используйте опцию —user ‘ПОЛЬЗОВАТЕЛЬ:ПАРОЛЬ’, а также одну из опций —basic или —digest — в зависимости от типа аутентификации.
Обратите внимание, что для Digest аутентификации ввод данных выполняется в 2 этапа и хотя бы один раз в любом случае получаем статус ответа 401 Unauthorized.
Поиск хостов с Basic и Digest аутентификацией
«Полезной нагрузкой», которая может найти хосты с Basic и Digest аутентификацией, может быть команда вида:
Если вы запутались в знаках >, то рекомендую вам разобраться, поскольку здесь используется довольно занимательная конструкция, которая имеет следующий результат:
Дело в том, что HTTP заголовки команда cURL выводит в stderr, а команда grep не ищет по stderr. Но мы не может сделать просто перенаправление stderr для слияния со стандартным выводом, то есть не можем 2>&1, поскольку текст страницы может содержать слово «Unauthorized» и мы получим ложное срабатывание. Поэтому мы используем указанную выше конструкцию — вывод ошибок обрабатывается, стандартный вывод уничтожается.
Если вы хотите разобраться в этом глубже, то смотрите статью «Операторы перенаправления вывода в Bash: что означает &1 и другие».
Для поиска хостов мы будем использовать конструкцию вида:
То есть если в заголовках ХОСТА найдена срока «Unauthorized», то выводим адрес этого хоста.
Чтобы сделать эту кастомную полезную нагрузку многопоточной, я буду использовать утилиту Parallel (смотрите «Руководство по использованию GNU Parallel»).
Пример сканирования портов 80 и 8080 диапазона IP адресов 100.101.0.0-100.101.255.255 с выводом данных прямо на экран:
Пример сканирования портов 80 и 8080 диапазона IP адресов 100.64.0.0-100.127.255.255 с сохранением данных в файл auth_basic.txt:
Брут-форс HTTP Basic и Digest аутентификаций
Basic и Digest стандартизированы и довольно просты для реализации брут-форса. Поэтому их поддерживают все популярные брут-форсеры, в том числе:
patator
Я покажу команды на примере patator. Модуль для брут-форса называется http_fuzz.
Команда для запуска брут-форса HTTP Basic аутентификации, когда имена пользователей и пароли находятся в разных файлах:
Всё остальное в этой команде можно оставить без изменений.
Команда для запуска брут-форса HTTP Basic аутентификации и когда имена пользователей и пароли находятся в одном комбинированном файле:
Команды для запуска брут-форса HTTP Digest аутентификации точно такие, всего лишь замените опцию auth_type=basic на auth_type=digest.
Router Scan by Stas’M
Router Scan тоже прекрасно брут-форсит эти типы аутентификации, поскольку они активно применялись на роутерах прошлых поколений:
Возможно, для ваших целей стоит задуматься о дополнении или изменении поставляемых с Router Scan словарей, поскольку они всё-таки заточены под роутеры. Выше пример брут-форса IP адресов, которые я собрал случайно просканировав неверный диапазон. Как можно увидеть, даже с дефолтными словарями удалось подобрать пару паролей (правда один из этих хостов роутер, а второй DVR.
Фильтры Wireshark для HTTP Basic и Digest аутентификации
Wireshark может фильтровать сессии аутентификации. Для этого имеются следующие фильтры:
Все сессии аутентификации (BASIC/DIGEST/NTLM):
Только HTTP Basic аутентификация:
Только HTTP Basic аутентификация с определёнными учётными данными:
Как взломать хеш HTTP Basic
HTTP Basic Auth в HTTP заголовке
Если вы перехватили передаваемую аутентификацию по сети, например, заголовок:
то вставьте строку из этого заголовка в команду вида:
и вы получите логин и пароль в виде простого текста.
Если вам удалось найти файл .htpasswd с хешами, то там вы увидите примерно следующее:
То есть файл включает имя пользователя и хеш.
Если программа htpasswd использовалась с опцией -B (что рекомендуется), то для шифрования хеша вместо MD5 используется bcrypt, который считается очень надёжным. Пример хеша:
В данном случае нужно использовать режим Hashcat -m 3200.
В любом случае вы сможете определить тип хеша воспользовавшись этим онлайн сервисом по определению типов хешей.
Как взломать хеш HTTP Digest
HTTP Digest Auth в HTTP заголовке
Для взлома перехваченной Digest вам нужно собрать хеш самостоятельно. Для его взлома используется тип хеша -m 11400 = SIP digest authentication (MD5)
Формат хеша следующий:
Подробности на страницах:
Пример содержимого файла .htpasswd:
Хешами здесь являются строки после второго двоеточия, то есть, например, 48e54f80673b884a8d6f23f48aa2ade3.
Данный хеш вычисляется по формуле:
Для взлома этого хеша используйте алгоритм MD5 с номером -m 0. Пароль составьте из трёх элементов, разделённых двумя двоеточиями: «ИМЯ:REALM:ПАРОЛИ». Третья часть ПАРОЛИ должна меняться, а первые две должны остаться неизменными.
Заключение
Аутентификация Basic и Digest в настоящее время считаются слабыми. Если вам нужно использовать какую-то из них, то рекомендуется Basic в паре с HTTPS, чтобы невозможно было перехватить пароль, поскольку хотя Digest и не пересылает пароль в открытом виде, он очень быстр для брут-форса.