Comments 57
>>Как отметил Jack Koziol, «При работе этого эксплойта все эти ящики с Windows будут…
гугл-транслейт такой гугл-транслейт!
гугл-транслейт такой гугл-транслейт!
«Linux, FreeBSD и другие операционные системы не подвержены этой атаке»,
опять повод для холивара… мда…
опять повод для холивара… мда…
Судя по фамилии он русский?
«Linux, FreeBSD и другие операционные системы не подвержены этой атаке»
Не знаю, как они меряли, но у меня в Linux по умолчанию включен accept router advertisement.
Не знаю, как они меряли, но у меня в Linux по умолчанию включен accept router advertisement.
UFO just landed and posted this here
UFO just landed and posted this here
DHCP в сетях Windows требует авторизации с правами админа AD. И доменные машины с левого сервака или коробочки получать IP не будут. Здест MS кое-что продумал.
Уязвимость заключается в обратном. Что запустив поддельный DHCP сервер можно запустить трафик на себя. Но вообще, с двумя DHCP-серверами сеть начинает подглюкивать. Впрочем и с IPv6 с двумя роутерами наверное будет глючить.
Про IPv6, к сожалению, пока знают далеко не все, и такая атака может долго оставаться незамеченной (в отличие от варианта с DHCP), потому что «настоящего» роутера совсем и не будет. А когда Google с Facebook включат IPv6, то красть вполне будет что. Правда, там SSL.
Так я и пишу, что просто так запустить DHCP сервак не получится — его сначала должен авторизовать Active Directory Administrator. Без этого он не будет работать как сервис Windows в сети и ничего не будет раздавать. Компьютеры в сети, по умолчанию, пере-получают адрес сначала от того же сервера, что и в прошлый раз. Так что, поддельный DHCP будет работать только для новых компьютеров, ранее адреса в сети не получавших. И что-то мне говорит, что после регистрации в домене компы должны получать IP только от авторизированных в домене серверов. Но уверенности нет.
Речь идет о сетях Windows.
Речь идет о сетях Windows.
Да я вот что-то не припомню в протоколе DHCP авторизации. А переполучение адреса с того же компьютера, что и прошлый раз — это не защита, а уменьшение последствий. После включения компьютера DHCP-запрос идёт броадкастом, и неизвестно, от которого DHCP-сервера прийдёт раньше ответ.
Впрочем, слушая сеть такую ситуацию можно отловить. Причём и в варианте с IPv6 тоже.
Впрочем, слушая сеть такую ситуацию можно отловить. Причём и в варианте с IPv6 тоже.
Авторизация DHCP серверов в AD — это больше защита от дурака, чем от хакеров.
Зачем Rogue DHCP быть в вашем домене?
Зачем ему вообще быть на базе Windows?
Откуда информация про «тот же сервер, что и прошлый раз»? По RFC — кто первый прислал, того и тапки.
И MS тоже самое пишет: More than one DHCP server can respond with a DHCPOffer message. The client accepts the best offer, which, for a Windows DHCP client, is the first DHCPOffer message that it receives.
Да и если адрес DHCP проверять — что RogueDHCP мешает прислать Offer от адреса валидного DHCP?
«После регистрации в домене компы должны получать IP только от авторизированных в домене серверов» — как? У компьютера адреса нет — что он может проверить? Как он к DC обратится? С чего вы решили, что доменный компьютер может использоваться только в доменной сети?
Зачем Rogue DHCP быть в вашем домене?
Зачем ему вообще быть на базе Windows?
Откуда информация про «тот же сервер, что и прошлый раз»? По RFC — кто первый прислал, того и тапки.
И MS тоже самое пишет: More than one DHCP server can respond with a DHCPOffer message. The client accepts the best offer, which, for a Windows DHCP client, is the first DHCPOffer message that it receives.
Да и если адрес DHCP проверять — что RogueDHCP мешает прислать Offer от адреса валидного DHCP?
«После регистрации в домене компы должны получать IP только от авторизированных в домене серверов» — как? У компьютера адреса нет — что он может проверить? Как он к DC обратится? С чего вы решили, что доменный компьютер может использоваться только в доменной сети?
Спасибо за подробный комментарий. Плюс от меня.
Это все здорово, но с таким левым адресом с левого dhcp будет достаточно проблематично работать дальше. Нужно ведь не только айпишник получить, но и в домен войти, подмонтировать сетевые диски, в том числе с домашней папкой юзверя и далее по списку. И если домен настроен не на три компа на одном свиче, а в нормальной организации нормальным админом, то все это безобразие обрежется VLAN-ом на первой же циске или длинке. А если не вланом и не фаерволом — то уж точно инфраструктурой PKI.
Воткнуть же в корпоративную сеть поддельный контроллер домена с поддельным же маршрутизатором, поддельными сертификатами и черным маршрутом наружу — это, знаете ли, как-то слишком. Дело явно не в уязвимости dhcp или ipv6.
Воткнуть же в корпоративную сеть поддельный контроллер домена с поддельным же маршрутизатором, поддельными сертификатами и черным маршрутом наружу — это, знаете ли, как-то слишком. Дело явно не в уязвимости dhcp или ipv6.
С каким «левым адресом»? Чем он от «правого» отличается? «Такой же, но радости не приносит»?
Какое отношение к входу в домен, сетевым дискам, домашней папке пользователя, VLAN, циске, длинку, файрволу и PKI имеет DHCP вообще?
Не хочу хамить, но ник у вас очень точный…
Какое отношение к входу в домен, сетевым дискам, домашней папке пользователя, VLAN, циске, длинку, файрволу и PKI имеет DHCP вообще?
Не хочу хамить, но ник у вас очень точный…
Слушайте, уважаемый, вы хоть одну нормальную сеть под АД видели? Хотя б на пару сотен машин? Ну воткнете вы туда свой dhcp или slaac, ну вот что, ЧТО вы с этого получите? Юзер не сможет залогиниться, позвонит админам, те придут и надают вам по башке чтобы больше не баловали. Все, больше вам ничего не светит.
И даже постоил не одну :)
Давайте поспорим на какую-нибудь ощутимую сумму — $1000? С радостью воткну свой DHCP в вашу сеть и даже расскажу, что я получил.
Давайте поспорим на какую-нибудь ощутимую сумму — $1000? С радостью воткну свой DHCP в вашу сеть и даже расскажу, что я получил.
Вторая форма есть? А то можем и поспорить.
Впрочем, если вы действительно построили более одной сети с сотнями компов, то вас не затруднит объяснить мне на пальцах, что конкретно вы сможете взломать.
Итак, есть отдел №30 в здании №20. Внутри отдела есть местная l2 локалка силами тупого свитча, причем для упрощения вашей задачи пусть свитч даже стоит прямо в отделе, прибитый гвоздями к стене, и вы имеете к нему физический доступ.
От свитча идет аплинк уже на нормальную циску, которая с помощью своих коллег и маршрутизатор, и влан, и dhcp с фаерволом.
Внутри отдела, допустим, действует сеть 10.20.30.0/24, в которой айпишники раздаются динамически этой самой циской тупо на основании того факта, что запрос прилетел в конкретный порт этой циски.
Циска настроена так, что она что-то там натит, фильтрует и вланит, но в итоге она разрешает доступ из локалки отдела только с выданных ей же адресов и только на определенный набор сервисов адрес: порт. Никакого свободного инета нет, маршрута по умолчанию нет, вообще ничего нет, почта корпоративная на Exchange поверх шифрованных каналов, веб только избранным через запароленный прокси и опять же поверх SSL. Все компьютеры в АД, никаких локальных юзеров нет, при загрузке комп является мертвым ящиком, пока вы не войдете в домен при помощи брелка с зашитым намертво секретным ключом. БИОС запаролен, системники опечатаны, usb порты опечатаны, дисководов нет.
Ни физического, ни административного доступа к циске у вас тоже нет. И да, здание экранировано, мобильники не ловят, йота не ловит, зато гэбня ловит неопытных радиолюбителей при помощи пеленгаторов. Гостайна, фигли.
И вот приходите такой красивый вы и втыкаете в свитч отдела свой dhcp сервер. И?
Впрочем, если вы действительно построили более одной сети с сотнями компов, то вас не затруднит объяснить мне на пальцах, что конкретно вы сможете взломать.
Итак, есть отдел №30 в здании №20. Внутри отдела есть местная l2 локалка силами тупого свитча, причем для упрощения вашей задачи пусть свитч даже стоит прямо в отделе, прибитый гвоздями к стене, и вы имеете к нему физический доступ.
От свитча идет аплинк уже на нормальную циску, которая с помощью своих коллег и маршрутизатор, и влан, и dhcp с фаерволом.
Внутри отдела, допустим, действует сеть 10.20.30.0/24, в которой айпишники раздаются динамически этой самой циской тупо на основании того факта, что запрос прилетел в конкретный порт этой циски.
Циска настроена так, что она что-то там натит, фильтрует и вланит, но в итоге она разрешает доступ из локалки отдела только с выданных ей же адресов и только на определенный набор сервисов адрес: порт. Никакого свободного инета нет, маршрута по умолчанию нет, вообще ничего нет, почта корпоративная на Exchange поверх шифрованных каналов, веб только избранным через запароленный прокси и опять же поверх SSL. Все компьютеры в АД, никаких локальных юзеров нет, при загрузке комп является мертвым ящиком, пока вы не войдете в домен при помощи брелка с зашитым намертво секретным ключом. БИОС запаролен, системники опечатаны, usb порты опечатаны, дисководов нет.
Ни физического, ни административного доступа к циске у вас тоже нет. И да, здание экранировано, мобильники не ловят, йота не ловит, зато гэбня ловит неопытных радиолюбителей при помощи пеленгаторов. Гостайна, фигли.
И вот приходите такой красивый вы и втыкаете в свитч отдела свой dhcp сервер. И?
Продолжительные аплодисменты, переходящие в овацию. Все встают!
Сколько лишних подробностей… Надеюсь защитой гостайны в вашей организации не вы занимаетесь? А то за державу обидно…
Имеем DHCP сервер в L2 сегменте. Задача — MITM.
Для реализации необходимо, чтобы ответ от нашего сервера пришел раньше, чем от валидного. В заданных условиях это с хорошей вероятностью достигается просто потому, что мы а) ближе, б) ничем не загружены, в отличие от циски. Можно и понадежнее (долбить ответами постоянно, предварительно исчерпать диапазон выдаваемый циской), но упростим.
Обход ACL cisco — для уже выданных адресов можно не делать ничего, они уже в разрешенных, для новых — запросим их предварительно в качестве DHCP клиента.
Собственно все, вся остальная защита нам по боку.
Далее имеем возможность подменить default gateway, коль уж она у вас «с помощью своих коллег и маршрутизатор», то «маршрут по умолчанию» у вас таки есть, да если и не было — то будет. И пропустить весь трафик сегмента через себя — получив т.о. доступ к «гостайне». Ибо про IPSec внутри, например, до файл-сервера у вас не слова.
Так же имеем возможность подменить DNS сервера и через это подменить адрес
прокси (про подмену адреса DC и вытекающие возможности пока забудем) и перехватить ваш пароль от интернета. Про возможность MITM в SSL — отдельно спорить желаете?
(Здесь мы не будем вспоминать, про дополнительную возможность подмены WPAD)
Передаем гостайну в страшный интернет от вашего имени.
И остаетесь такой красивый вы объясняться с вашей гэбней.
Имеем DHCP сервер в L2 сегменте. Задача — MITM.
Для реализации необходимо, чтобы ответ от нашего сервера пришел раньше, чем от валидного. В заданных условиях это с хорошей вероятностью достигается просто потому, что мы а) ближе, б) ничем не загружены, в отличие от циски. Можно и понадежнее (долбить ответами постоянно, предварительно исчерпать диапазон выдаваемый циской), но упростим.
Обход ACL cisco — для уже выданных адресов можно не делать ничего, они уже в разрешенных, для новых — запросим их предварительно в качестве DHCP клиента.
Собственно все, вся остальная защита нам по боку.
Далее имеем возможность подменить default gateway, коль уж она у вас «с помощью своих коллег и маршрутизатор», то «маршрут по умолчанию» у вас таки есть, да если и не было — то будет. И пропустить весь трафик сегмента через себя — получив т.о. доступ к «гостайне». Ибо про IPSec внутри, например, до файл-сервера у вас не слова.
Так же имеем возможность подменить DNS сервера и через это подменить адрес
прокси (про подмену адреса DC и вытекающие возможности пока забудем) и перехватить ваш пароль от интернета. Про возможность MITM в SSL — отдельно спорить желаете?
(Здесь мы не будем вспоминать, про дополнительную возможность подмены WPAD)
Передаем гостайну в страшный интернет от вашего имени.
И остаетесь такой красивый вы объясняться с вашей гэбней.
У меня на работе сеть из десятков тысяч компьютеров и серверов, в том числе и на MS AD. Такие игрушки не пройдут за пределы ближайшего роутера, а на клиентских машинах отслеживаются специальным софтом. Это вполне управляемо, если знать, что искать.
Отслеживание, да — безусловно сработает. Ну разве что, за исключением одновременной DoS атаки на валидный DHCP — что обычно заметно.
Собственно мониторинг появления Rogue DHCP в сети (по кол-ву приходящих клиенту ответов) и есть нативный способ борьбы с этой угрозой.
Полный IPSec внутри (Domain Isolation) — наверное тоже спасет, но средство радикальное…
Собственно мониторинг появления Rogue DHCP в сети (по кол-ву приходящих клиенту ответов) и есть нативный способ борьбы с этой угрозой.
Полный IPSec внутри (Domain Isolation) — наверное тоже спасет, но средство радикальное…
Для предотвращения таких атак, есть DHCP snooping (как минимум на свитчах Cisco)
Для фальшивых DHCP есть средства блокирования на уровне сетевого оборудования.
blog.ioshints.info/2009/03/blocking-rogue-dhcp-servers.html
blog.ioshints.info/2009/03/blocking-rogue-dhcp-servers.html
причем тут «доменные машины»? DHCP инициализируется ДО связи с доменом. Обычная сеть (что с доменом, что без) от dhcp spoofing'а не защищена никак. Как и от туевой хучи других атак :)
К сожалению, этот механизм не заложен в сам протокол DHCP, и «реагируют» на авторизацию только Windows-сервера, введенные в домен. Если сервер не введен в домен, или это вообще не Windows а какой-нить кривожопо-настроенный D-Link — то он ничтоже сумящеся будет раздавать IP, что иногда может приводить к веселым ситуациям.
UFO just landed and posted this here
РЕШЕТО!
Ну это тоже самое, как поднять в сети DHCP сервер. и также красть информацию с машин. Хотя данный способ очень быстро выявляется, когда падает пол сети )
Далеко не обязательно — можно просто работать рилеем и отдавать все офферы легитимному серверу а от себя возвращать ацк кому надо (ну мы ж конкретную жертву ловим?).
Только вот в нормальных сетях это все не имеет смысла поскольку спотыкается о ряд вопросов:
1. что внутри этой сети делает поддельный дхцпд?
2. почему забыт dhcp snooping?
3. какой радости все боксы находятся в одном никак не изолируемом и не контролируемом л2 сегменте? Что тогда просто мешает посидеть в промискус моде и снифнуть все что надо без «высоких технологий» с кастомно-патчеными дхцп серверами?
А если по сабжу без дхцп то вопросов тоже не меньше, и добавляються они к вышестоящим:
1. почему никто не заметил что трафик в ipv4 сети улетает в невесть какой дефолтраут по ipv6 (это ж еще чтобы заюзать нужно вежливо попросить аплинков его раутить =)
2. если оное заворачивается где-то внутри сети в nat-pt чтобы транслировать в6 в в4 (вайрспид, ага, себе такой хотю) то ещеж и раутинг придется глобально спуфить — просто блин не експлойты а шедевры сетевой инженерии получаются :)
Итого все наталкивает на мысль о том, что для выполнения всех вышеперечисленных условий нам нужна сферически неуправляемая сеть, построенная на неуправляемых мыльницах, с неуправляемым гейтом в интернеты (ну если мы не хотим соснифанные данные на флешках носить) с неуправляемыморангутангом администратором в центре не умеющим пользоваться tcpdump и «случайно» не заметившим процеса настройки такого архитектурного решения находящегося физически внутри сети.
Феерически ажурное стечение всевозможных промахов сетестроения — никому не кажется?
Только вот в нормальных сетях это все не имеет смысла поскольку спотыкается о ряд вопросов:
1. что внутри этой сети делает поддельный дхцпд?
2. почему забыт dhcp snooping?
3. какой радости все боксы находятся в одном никак не изолируемом и не контролируемом л2 сегменте? Что тогда просто мешает посидеть в промискус моде и снифнуть все что надо без «высоких технологий» с кастомно-патчеными дхцп серверами?
А если по сабжу без дхцп то вопросов тоже не меньше, и добавляються они к вышестоящим:
1. почему никто не заметил что трафик в ipv4 сети улетает в невесть какой дефолтраут по ipv6 (это ж еще чтобы заюзать нужно вежливо попросить аплинков его раутить =)
2. если оное заворачивается где-то внутри сети в nat-pt чтобы транслировать в6 в в4 (вайрспид, ага, себе такой хотю) то ещеж и раутинг придется глобально спуфить — просто блин не експлойты а шедевры сетевой инженерии получаются :)
Итого все наталкивает на мысль о том, что для выполнения всех вышеперечисленных условий нам нужна сферически неуправляемая сеть, построенная на неуправляемых мыльницах, с неуправляемым гейтом в интернеты (ну если мы не хотим соснифанные данные на флешках носить) с неуправляемым
Феерически ажурное стечение всевозможных промахов сетестроения — никому не кажется?
UFO just landed and posted this here
Прикольная фамилия у Джека
А если сюда ещё teredo добавить?
Ребята из THC уже давно занимаются вопросами безопасности IPv6. В сети можно найти видео с их выступлений. Интересующимся рекомендуется.
http://www.thc.org/thc-ipv6/
http://www.thc.org/thc-ipv6/
Я бы сказал, что это «дырка» размером в DHCP. Как только мы просим данные у «дяди», то вместо доброго дяди мы можем столкнуться со злым.
Ну, вот, опять виноваты высокие технологии, а человек, как бы, не причем!
Эта «проблема» давно известна и расписана в RFC6104 — Rogue IPv6 Router Advertisement Problem Statement.
MITM всегда находится посередине любого соединения, за исключением синаптической щели.
Автор, зачем Вы используете короткие ссылки (goo.gl)? :)
Sign up to leave a comment.
[Перевод] Кража данных из-за новейших возможностей Windows и Mac OS X