1.1.4 Незащищенный и защищенный траффик в сетях. Перехват парольных хэшей

Открытый и зашифрованный трафик в сетях Windows, хэши LM, NTLM, NTLMv2

Что обычно ходит открытым в вашей сети (или передается в Интернет) и может быть перехвачено?

К совсем открытому трафику относятся в основном стандартные протоколы TCP/IP (Интернета):

·        ARP - протокол разрешения IP-адресов в MAC-адреса. Незащищенность этого протокола дает возможность выполнять DoS-атаки в локальной сети практически кому угодно. Кроме того, слабости этого протокола могут использоваться и для других атак, например, обхода свитчей (ARP poisoning). Существует защищенная реализация протокола ARP - SARP, но эта реализация обычно применяется только в локальных сетях;

·        DHCP - выдача IP-адресов в локальных сетях. Протокол также не защищен. Существуют варианты реализации DHCP с защитой, основанной на MAC-адресах (в стандартном DHCP в Windows NT/2000/2003 предлагается, например, весь диапазон раздать на client reservations), но они не очень эффективны (например, в случае использования уже рассмотренного SMAC). Технической защиты от rogue DHCP Server (DHCP сервера в локальной сети, неподконтрольного администратору) вообще не существует - можно лишь обнаруживать такие серверы (например, при помощи утилиты DHCPLoc из Resource Kit) и принимать административные меры;

·        DNS - разрешение имен хостов в IP-адреса и обратно, а также (в сетях Windows) поиск важных сетевых служб - например, контроллеров домена. Существует проект SDNS (Secure DNS, подробнее - http://www.research.ibm.com/intsec/secure-dns.html), но его широкое внедрение в ближайшее время не планируется. Помимо возможности перехвата запросов на сервер DNS и возможности подмены ответов, существуют также проблемы, связанные с динамическими обновлениями зон (на многих предприятиях динамическое обновление включено без проверки прав);

·        WINS - разрешение имен NETBIOS в IP-адреса в сетях Windows/LANManager и поиск сетевых служб (контроллеров домена, просмотрщиков сети и т.п.). Защищенных реализаций протокола WINS не существует и, видимо, их и не будет (поскольку Microsoft постепенно отказывается от WINS);

·        LDAP - обращение к серверу каталогов. По изначальному Интернет-стандарту не защищен, хотя клиент Microsoft при обращении по LDAP к контроллеру домена использует защищенный Security Support Provider Interface (SSPI). Обычно проблемы с безопасностью возникают при обращении по LDAP клиентов третьих фирм;

·        Telnet - существует бесчисленное множество реализаций защищенного Telnet (например, SSH), однако Telnet-сервер, который идет в стандартной поставке Windows Server 2003, шифрование трафика не поддерживает (только защищенную аутентификацию, по умолчанию - NTLM).

·        FTP - трафик (включая передаваемые имя пользователя и пароль) изначально никак не защищен. Есть возможность установить одну из множества реализаций защищенного FTP, но проще перевести передачу файлов на Web/SSL (HTTPS);

·        HTTP (так же, как и WebDAV, и протокол публикации Web-сайтов FrontPage), как мы видели в IRIS, изначально незащищен. О методах защиты Web-сервера - в соответствующем модуле.

·        SMTP/POP3/IMAP4/NNTP - пожалуй, одна из главных целей для злоумышленников. Помимо перехвата текста электронной почты, часто можно также перехватить пароли, передаваемые открытым текстом (в POP3 и IMAP4). Подробнее про защиту электронной почты - в соответствующем модуле.

·        SNMP - этот Интернет-протокол обычно используется не для обращения к компьютерам Windows, а для мониторинга и управления сетевыми устройствами. Тем не менее он также незащищен. К этой же категории можно отнести и трафик протокола автоматического обновления таблиц маршрутизации RIP, в котором пароли передаются открытым текстом.

·        трафик IM-систем (ICQ, Microsoft Instant Messenger, AOL Messenger и т.п.). Большинство этих систем передают открытым текстом (или так, что сломать защиту не представляет труда) не только текст сообщений, но и пароли. Несколько специализированных снифферов, которые позволяют перехватывать сообщения и пароли ICQ, находятся на компакт-диске. Учитывая, что в последнее время появились вирусы, распространяющиеся в IM-сетях, а также общую низкую защищенность этих продуктов, следует хорошо подумать, прежде чем разрешать использование ICQ и аналогичных продуктов в организации. Точно так же незащищен (по умолчанию) и трафик IRC.

·        трафик SQL Server и Oracle. Обе этих системы передают данные (текст запросов и ответы на них) по умолчанию в открытом виде, в то время как пароли при аутентификации все-таки защищены. Однако при определенных условиях (ALTER USER в Oracle, sp_password в SQL Server) можно увидеть и пароли пользователей. В обоих СУБД имеются средства защиты трафика (SSL и шифрование сетевой библиотеки Multiprotocol в SQL Server, Advanced Security в Oracle), но на практике они используются редко. Такие же проблемы существуют у Sybase и PostgreSQL.

·        трафик Citrix (протокол ICA). Как ни странно, он защищен гораздо хуже, чем протокол RDP в Microsoft Terminal Server. Особенно дырявой является конфигурация с *nix-клиентами и сервером Windows. Расшифровывать трафик можно, например, при помощи Unix-сниффера sniffit.

·        трафик множества утилит удаленного доступа (например, PC Anywhere и VNC).

Относительно защищенным (данные по умолчанию шифруются) можно считать трафик:

·        обращения к файловой системе и принтерам по протоколу SMB в линейке Windows NT (NT/2000/XP/2003) - видны имена ресурсов, к которым производится обращение, но само содержание файлов прочитать не получится;

·        трафик аутентификации - опять-таки для линейки NT, особенно начиная с версии NTSP4, когда используется NTLMv2. Однако про хэши - разговор отдельный и про них будет рассказано ниже;

·        трафик стандартных административных утилит Windows (например, тех, которые работают в MMC) - он шифруется при помощи средств RPC;

·        трафик сеансов Terminal Server (он более защищен, чем трафик Citrix).

Вся безопасность Windows зависит от паролей Windows. Если знать пароль администратора, то в этом случае в сети можно делать практически все, что угодно. Поэтому про перехват паролей Windows необходимо рассказать более подробно.

После того, как пользователь ввел пароль (например, при его смене), пароль не сохраняется в Windows - вместо этого сохраняется его хэш (значение фиксированной длины, получаемое путем преобразования данных произвольной длины, подробнее про хэши на русском языке, например, http://infobez.ru/docfaq.asp?ob_no=1121). При этом в теории по хэшу восстановить исходное значение невозможно.

При аутентификации то, что ввел пользователь, передается такой же хэш-функции и полученное значение хэша сравнивается с сохраненным. Если они совпадают, то аутентификация проходит успешно, если нет - происходит отказ.

В теории такая схема выглядит очень надежно. Однако на практике из-за слабости алгоритмов хэширования и некоторых особенностей реализации их от Microsoft становится вполне возможно перехватить парольные хэши, передаваемые по сети, и подобрать пароли, которые при преобразовании дают то же значение хэша. В сетях Windows используются три типа парольных хэшей:

·        хэши LANManager. Самые старые и уязвимые. Используются по умолчанию линейкой DOS/Win3.11/Win95/98/ME, не различают регистр, вскрываются очень быстро. Windows NT/2000/XP/2003 при каждом создании/изменении пароля пользователя генерируют такие пароли (хотя по сети их и не передают) - для целей совместимости со старыми системами. Поэтому при получении локального доступа к компьютеру обычно подобрать пароль удается очень быстро.

·        хэши NTLanManager - NTLM. Намного лучше защищены и различают регистр символов. Использовались по умолчанию в Windows NT. Тем не менее, хотя подбор паролей по хэшам NTLM и требует значительно большего времени, большой защиты NTLM не обеспечивает.

·        наиболее современный и защищенный вариант - NTLMv2. Возможность его использования появилась начиная с NTSP3, однако в Windows NT использование этого варианта аутентификации нужно было включать руками через реестр (в соответствии со статьей в Technet). В Windows 2000/XP/2003 NTLMv2 используется по умолчанию (его можно использовать даже в 95/98/ME, если установить Directory Service Client).

Надо сказать, что с точки зрения реализации хэширования во всех трех вариантах Microsoft реализован уникальный (и удивительный) алгоритм: пароль бьется на блоки из 7 символов и каждый блок хэшируется отдельно. Таким образом, пароль из 14 символов - это на самом деле два пароля из семи символов, что, конечно, сильно облегчает задачу по их подбору. Если же пароль состоит из 8 или 9 символов, то программы переборы паролей подбирают вторую часть пароля (последние 1 или два символа) практически мгновенно, что иногда помогает догадаться и о первой части.

Теперь о программах, которые могут использовать слабости парольных хэшей Windows, перехваченных при передаче по сети, на практике. Программ, которые умеют производить подбор по хэшам NTLM и LanMan, очень много. На практике многие зарубежные программы не понимают пароли на русском языке и не умеют подбирать пароли, которые содержат такие символы, поэтому обычно используются русские варианты таких программ (например, L0phtCrack+ или набор PacketCatch/PacketInside - все эти программы лежат в каталоге Снифферы на компакт-диске). Единственная известная мне на настоящий день программа, которая умеет подбирать хэши NTLMv2 - это Cain&Abel, однако если по словарю такая проверка проходит довольно быстро, то при применении brute force, например, при 14 символах, он показывает время перебора, измеряемое годами (подробнее о сроках подбора паролей NTLMv2, включая распределенные системы и кластеры - в презентации "Cracking NTLMv2 auth.ppt", слайд 53. Там же - множество ссылок на дополнительные ресурсы).

Лучшее описание того, как устроены хэши и как производится их расшифровка - в документации к L0phtCrack 5 (есть на компакт-диске).

Рекомендуется регулярно производить аудит (проще говоря, попытку взлома) паролей своих пользователей с целью выявления слабых паролей. Однако администратору намного проще получить парольные хэши напрямую из базы данных Active Directory или реестра, чем перехватывать их по сети. Как получать хэши напрямую, будет рассказано в модуле про физическую защиту компьютеров.

Получить учебные материалы по этому курсу