Limpid Byte http://lbyte.void.ru ==================== DHCP : Отклонения от норм общественной безопасности +-------------------------------------------------------------------+ + DHCP : Отклонения от норм общественной безопасности.[rus] + + the l0bstah + + freezer2k@mail.ru + +-------------------------------------------------------------------+ Основным предназначением DHCP (Dynamic Host Configuration Protocol) являеться задача обеспечения сетевых клиентов корректной информацией о конфигурации TCP/IP. В сетях Windows NT 5.0 существует метод предотвращения появления неавторизованных в AD DHCP-серверов. Это существенно затрудняет задачу появления DHCP-серверов, способных использовать расширенную область диапозонов с назначаемыми конфигурационными данными. Успешный сценарий начального выделения адреса выглядит так: +<-------------------------+ / DHCPACK(4)^ +------+ | +<-|клиент|<----------------------+ | |D +------+ DHCPOFFER(2)^ | |H | | | |C | | | |P |DHCPDISCOVER(0xffffffff) | | |R +(1) | | |E \ | | |Q +-----------+ опред.конфиг. | | |U |DHCP-сервер|--------------->+ | |E +-----------+ | |S(secs) ^ | конфиг.параметры | |T(3) | +-------------------->+ +------->+ Существует много способов перехвата трафика у клиента, все зависит от возможности исполнения, и конкретной ситуации. --------------------------------------- При необходимости физически перехватывать трафик, идущий на конкретный адрес, можно попытаться эмулировать освобождение адреса со стороны. Когда клиенту нужно отказаться от конфигурационного набора, который не устраивает нас, мы должны послать сообщение DHCPRELEASE от лица атакуемого, иначе он будет использовать текущую конфигурацию, как минимум, до полного истекания срока аренды. Атакующему необходимо узнать идентифицирующий набор параметров, от которого клиент отказывается, и с помощью клиентского идентификатора, или ("chaddr" - аппаратный адрес) и сетевого адреса,(а также возможно серийный номер производителя будет использован в качестве идентификатора) включить в сообщение DHCPRELEASE. Хотя бывает ситуация когда поле ("client identifier") при регистрации в сообщении DHCPREQUEST не используеться, и тогда этот идентификатор не требуеться. Стоит упомянуть о поле ("xid"), которое используется клиентом для установления соответствия между приходящим DHCP-сообщением и отправленного ранее. Но т.к. клиент сам решает использовать новое псевдослучайное число или нет, то проблем с генерацией запроса от лица чужого клиента с этим полем не будет. Cценарий: 1.подделка текущего MAC-адреса чужим. (spoofing) CI получаем способом прослушивания либо CI=chaddr::ciaddr Используя назначенные данные и полученную информацию необходимо занести данные в структуру пакета DHCPRELEASE 2.смена MAС-адреса на предыдущий. CI = chaddr::ciaddr (где ciaddr = поле ("Запрошеный IP-адрес"). и посылка DHCPDISCOVER(0xffffffff). В результате атаки, чужой назначенный адрес может быть использован атакующим для осуществления прослушивания трафика, идущего уже на ваш выделенный адрес. Сетевой адрес в любом случае, происходит регистрация на стороне обслуживающего или ложного сервера, не будет призначен другому участнику сессии, при условии что связь с атакуемым клиентом будет установлена. Иначе, даже если адрес будет храниться в таблице соответствий, механизм выделения адресов, при недостатке незанятых IP-адресов будет повторно присваивать адреса чье время истекло или (взависимости от настроек) выбирать из пула доступных, которые не отвечают на запрос. При этом сервер выполняет контроль посредством ICMP эхо-запроса. Поэтому все попытки появления в сети конкурентно-способных областей, пренадлежащим ложным DHCP-серверам будут безуспешены. Есть небольшой недостаток этого варианта, но все таки такой случай бывает - сервер может отвечать на запросы регистрации новых адресов только тем клиентам, которые предварительно прошли специальную аутенфикацию. --------------------------------------- Клиент получает сетевой адрес на определенный период времени. В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности. Но если в вашем случае вариант spoofing'а не пройдет, а вопрос времени не столь важен, тогда можно попытаться назначить конфигурационные данные самостоятельно. Для этого необходимо прервать конечные точки связи клиета с сервером. 90% этого варианта требует полного истекания срока аренды. (чтобы убедиться в правильности данных необходимо проанализировать работу ПО со стороны клиента. - Клиент может отказаться в дальнейшем использовать текущий IP в случае, если при обновлении конфигурационных данных связь с сервером, идентификатор сообщений которого ("server identifier"), не будет установлена. ) Если сервер уязвим, и подвергаеться удаленной атаке, то в случае отказа в обслуживании необходимо ждать отказа от использования адреса со стороны клиента. Можно отключить клиента от сети (если ситуация это позволяет) каким либо физическим, либо канальным способом, либо выводом из строя передающих агентов, маршрутизаторов. Если клиент знает предыдущий сетевой адрес и не может контактировать с локальным для его области DHCP-сервером, клиент продолжает использовать предыдущий сетевой адрес до тех пор, пока время действия адреса не истечет. Как только время действия исчерпано до того, как клиент смог контактировать с DHCP-сервером, клиент прекращает использование текущего сетевого адреса. СЦЕНАРИЙ ДЕЙСТВИЙ: +-------------------------------------->+ | DHCPREQUEST(DHCPSERV)(1)| +------+ | |клиент|------------------->+ | +------+ DHCPDISCOVER(0xff.)| | (3)fakeIP (2)| | +----------------------.------------------------+ |Сегмент Сети + | | / | | +------------+ +---------------------+ | | |Наш DHCPSERV|(4) |Локальный DHCP-сервер| | | +------------+ +---------------------+ | | | ^ | | | | +-------------+ | | |(5) +<------+ложный клиент+ | | +-------------->+-------------+ | +-----------------------------------------------+ 1.Попытки клиента посылать DHCPREQUEST будут безуспешны до окончания использования срока аренды. 2.Клиент посылает широковещательный DHCPDISCOVER. 3.Наш сервер обрабатывает запрос, и становиться участником сессии. В итоге назначаеться другой Ip-адрес, а атакуемый освобождаеться, т.к. сервер не может обновить адрес, принадлежащий не к его области. 4.Сервер решает взять администрацию области адресов другого Простым назначением администрирования области. (с учетом что локальный DS недоступен) 5.Наш клиент обращаеться к ложному DHCP-серверу и получает необходимый запрошенный адрес. +--------------- Более простым методом решения проблемы, но более сложным в реализации будет метод использования первого метода, только в момент отключенния клиента. ------------------------------------------------------- Остальные, маловероятные варианты: Когда от клиента приходит DHCPREQUEST-RENEWING(1/2), если DHCP сервер находиться в другом сегменте, а у вас есть доступ к передающему агенту, сообщение будет послано по уникастному адресу, таким образом, в обмене не будут участвовать агенты транспортировки. Все попытки перехвата агентов будут безуспешны. В случае DHCPREQUEST-REBINDING(7/8 истекания срока аренды), сообщение должно быть передано широковещательно по IP-адресу 0xffffffff. Любой DHCP-сервер может расширить наборы параметров клиента, только если он имеет для этого административные привилегии. Если сервер авторизован в AD, как вариант зависящий от предыдущих сообщений клиента, клиент, не требуя от сервера идентификационных данных может обновить свои параметры. ------------------------------------------------------ Этот материал был написан исключительно с наиболее безопасной точки зрения DHCP-серверов. Наиболее потенциально-вероятными DHCP-серверами будут сервера не поддерживающие ряд параметров, повышающих отказоустойчивость и безопасность своих решений по отношению общим и атакуемым клиентом. +------------------------- + http://l0bstah.1s.to +------------------------- ==================== Limpid Byte http://lbyte.void.ru