Я разрабатываю приложение ASP.NET, использующее проверку подлинности Windows. Я установил web.config файл, чтобы запретить всем неаутентифицированным пользователям и разрешить только пользователей с определенной ролью.
Используя Fiddler, я могу размыть свой идентификатор сеанса, воспроизвести запрос и все равно получить 200 OK ответ ... очевидно, без каких-либо повторных переговоров.
У меня сложилось впечатление, что учетные данные для аутентификации на основе NTLM связаны с базовым TCP-соединением. Во-первых, так ли это? Это реальная угроза безопасности? Если да, то какие шаги нужно предпринять, чтобы захватить такое соединение, чтобы присвоить себе личность другого пользователя?
Чтобы ответить на ваш последний вопрос, отравление arp с помощью Cain - относительно простая и тривиальная задача. Сказав это, для этого требуется одно из двух: физический доступ к вашей сети или беспроводной доступ к вашей сети.
После того, как arp-отравлен и Каин собрал достаточно данных, NTLM-хеши могут быть взломаны прямо внутри Каина. Конечно, чем надежнее пароль, тем больше времени потребуется.
Internet Explorer может выполнять прозрачную проверку подлинности NTLM. Я мало использовал Fiddler и не знаю, показывает ли он вам эту часть разговора или нет. Я предполагаю, что ваш браузер прозрачно аутентифицирует вас, но я не могу сказать наверняка.
Вы можете попробовать обнюхать трафик браузера / сервера с помощью Wireshark или чего-то подобного, чтобы увидеть, происходит ли это. Аутентификация NTLM между клиентом и IIS выполняется внутри канала TCP-соединения, а не как часть какого-либо внешнего процесса, связанного с запуском TCP-соединения. Если он там, вы его увидите.
Вы не видите перехвата TCP. Вы либо видите результат прозрачной аутентификации, либо ваше приложение фактически не требует аутентификации.
Чтобы напрямую поговорить с TCP-захватом (TCP-последовательность и т. Д.): Чтобы захватить TCP-соединение, злоумышленник должен предсказать последовательность и номера подтверждений и подделать трафик в качестве клиента. Обычно это заканчивается слепой атакой, потому что ответы от серверного компьютера возвращаются к настоящему клиенту. (Если вы объедините последовательность TCP с отравлением кеша ARP, вы можете получить двусторонний захват, но это обычно ограничивает атаку злоумышленником на машине в той же подсети, что и клиент или сервер.) Последовательность TCP живых соединений между клиентами и серверов через Интернет сложно, если злоумышленник не скомпрометировал узкую точку между клиентом и сервером.
Атаки слепого секвенирования TCP, использующие соединение для использования доверия к протоколу (атака Кевина Митника на рабочую станцию Шимомуры с целью сбросить на нее файл .rhosts), становятся возможными благодаря угадываемым начальным порядковым номерам и немного отличаются от прямого угона.
SSL, IPSEC или другие протоколы зашифрованного туннелирования - ваш друг для предотвращения перехвата TCP. В общем, даже если вы выполняете аутентификацию с использованием системы запроса / ответа с непрозрачным текстом (например, NTLM, NTLMv2 и т. Д.), TCP-соединение все равно уязвимо для взлома.