Меня зовут Роб Стакл, я консультант по безопасности из Феникса, штат Аризона, и в основном работаю пентестером. Я участвую в конференциях DefCon с 1996 года, увлекаюсь высотной фотографией, а в эти выходные была одиннадцатая годовщина нашей свадьбы. Я хочу поблагодарить мою удивительную и понимающую жену Линду, которая не ожидала, что моё участие в DefCon означает, что каждый год я буду вынужден проводить годовщину нашей свадьбы в Вегасе, о чём я очень сожалею.
Я собираюсь поговорить с вами о нескольких вещах, связанных с исследованиями, над которыми я работал несколько последних лет. Их объединяет общая тема — если вы не мониторите свой DNS трафик и не понимаете, что там происходит, когда всё в порядке, то вы наверняка не обратите внимания, когда с ним начнут происходить плохие вещи. Я «насиловал» DNS в течение нескольких лет и это всегда было одним из моих любимых векторов атаки. Вы можете потратить целое состояние на упрочнение периметра сети, но если я могу получить контроль над одним из ваших устройств, поверьте мне, ваша игра закончена.
Отсутствие на рынке сканеров уязвимости, позволяющих обнаружить неправильные конфигурации, всегда дают мне возможность «просунуть ногу в дверь». Сегодня мы обсудим различные темы, в которых я расскажу о моих приключениях с DNS и моих проделках над людьми, связанных с DNS.
Эти темы посвящены непониманию поведения DNS конечными пользователями сети, я немного расскажу о людях, которые не зарегистрировали свои домены, и о самом взломе доменов.
На конференциях Black Hat и DefCon в 2011 году Артём Дайнеберг рассказал о том, что назвал бит-сквоттинг, или «переворачивание бита». Те, кто не знаком с этим исследованием, но заинтересован этой проблемой в DNS популярных доменов, могут скачать материалы его презентации по ссылкам, приведённым на этом слайде.
Страница проекта / видеопрезентация / слайды
Когда я прочитал анонс его выступления, опубликованный ещё перед докладом на Black Hat, я сразу заинтересовался, как это можно использовать в своих целях. Не вдаваясь в детали, я объясню, что такое бит-сквоттинг, почему он происходит и на что влияет. Я покажу вам несколько примеров того, какой риск представляет случайный переворот бита в памяти, когда 1 превращается в 0 и наоборот. На следующих слайдах показано, как это выглядит на примере строки в памяти, которая отображает доменное имя.
В середине такой строки единица превращается в ноль. Артём исследовал явление, при котором ошибка единичного бита в правильной части памяти в нужный момент заставляла клиента запросить полностью легитимное, но неправильное имя домена.
По поводу вероятности возникновения и причин такой ошибки велось много разговоров, но я принялся изучать все способы, которые позволяют использовать эту ошибку в злонамеренных целях. Так что бит-сквоттинг DNS позволяет исказить доменные имена, затем зарегистрировать эти «неправильные» домены и направлять на них запросы пользователей.
На следующем слайде показано, что в результате бит-сквоттинга доменного имени Google, когда протон высокой энергии в памяти «ударяет» по 1, означающей букву g, превращает её в 0, означающий букву f, и в результате пользователь перенаправляется на сайт goofle.com.
Итак, ваш браузер совершенно законно перенаправит вас на другой сайт и с радостью заберёт оттуда ответ для вас. При этом DNS SEC никоим образом не сможет вам помочь, и на самом деле существует очень мало возможностей предотвратить эту ошибку совершенно невидимым способом, кроме использования памяти ECC, которая автоматически распознаёт и исправляет ошибки битов.
Однако такой вид памяти не очень распространён, и даже если бы вы использовали ECC, существует ещё множество мест, где может произойти бит-сквоттинг и где память ECC никогда не применяется, например, в сетевой карте или в кэше DRAM жесткого диска.
Дайнеберг подробно описал причины возникновения проблемы, но в целом можно сказать, что ошибки памяти случаются, иногда они повреждают память и иногда это оказывает эффект на DNS. В основном «переворачивание» бита происходит из-за физического повреждения памяти, перегрева, электрических проблем, воздействия радиации и даже космического излучения.
Презентация прерывается появлением на сцене организаторов DefCon, которые поздравляют докладчика и его супругу Линду, которая впервые присутствует на конференции, с одиннадцатилетием свадьбы. Роберт благодарит их за поздравление и продолжает выступление.
Космическая радиация является чрезвычайно редким фактором, влияющим на бит-сквоттинг, зато перегрев является очень частой причиной ошибок памяти. Я заметил, что смартфоны особенно уязвимы по причине условий экстремальной эксплуатации, которым они подвергаются. Перегрев аккумулятора смартфона довольно частое явление. Большинство других устройств имеют охлаждение, но даже им люди умудряются создавать тяжёлые условия эксплуатации.
Не так давно Google опубликовала информацию о работе своих дата-центров. Одной из интересных вещей, о которой я узнал, было сообщение о том, что с целью экономии электроэнергии они эксплуатируют свои дата-центры в условиях, которые большинство из нас посчитали бы неразумными. Если типичные дата-центры работают при максимальной температуре 60-70 градусов по Фаренгейту (15-20°C), то специалисты Google рекомендуют компаниям эксплуатировать дата-центры при температуре минимум 80 градусов (27°C), а один бельгийский дата-центр Google эксплуатировал свои сервера при температуре 95 градусов ( 35°C).
Надпись на карикатуре: «Я слышал, что это экономит нам деньги».
Intel и Microsoft утверждают, что их серверы отлично ведут себя при высоких температурах, а Dell гарантирует запуск своих серверов при температуре 115 градусов по Фаренгейту (46°C). Я считаю это плохой идеей, так как температура является главным фактором обеспечения стабильной работы памяти, а дата-центры Google работают на «пожарных» температурах.
Я стал изучать, какие преимущества это может дать, и какие домены наиболее уязвимы для бит-сквоттинга, то есть пытался найти наиболее часто запрашиваемые имена для повышения вероятности того, что столкнусь с подобными ошибками. Я стал собирать DNS-логи крупных компаний, чтобы найти наиболее распространённые доменные имена и выяснил, что наиболее запрашиваемым именем было gstatic.com. Это один из доменов, который служит Google для предоставления такой статической информации, как CSS, изображения, JavaScript и XML файлы.
Я написал скрипт для определения возможных «переворотов» бита в этом доменном имени gstatic.com, и получил список всех вариаций данного имени в количестве 34 штук. Пять из них использовались в легальных целях, остальные 29 были доступны, поэтому я все их купил.
Я сразу же попал в цель. Кто-то искал изображения в Google и содержание запроса вернулось к ним каким-то образом повреждённым, потому что его браузер попросил меня обслужить одну из картинок в запросе. Я вижу их IP-адрес, искаженное имя, которое они запросили, ресурс, который они пытались восстановить с помощью этого изображения, страницу, относящуюся к этому содержимому, и клиент, который использовался в качестве браузера для отсылки данного запроса.
На странице вы можете увидеть интересный артефакт в виде запроса конкретного имени Trisha Jones.
Далее количество запросов росло, возникало больше искажённых имён, больше запросов изображений и больше ссылок на исходный запрос, в результате чего я собрал более 50 000 уникальных запросов, и подобное, как выяснилось, было распространённым явлением.
На слайде показан запрос на «отфотошопленное» изображение актрисы Селены Гомез, что вызывает смех в зале.
Так что иногда бит-сквоттинг случается как раз в правильное время, чтобы совпасть с одним из ваших запросов, и если это происходит не слишком часто, можно не беспокоиться. Но иногда это случается в тот самый момент, когда происходит сохранение на жёсткий диск, что уже более интересно. Существуют шансы, что бит-сквоттинг возникнет при обычных условиях эксплуатации памяти, но очень похоже, что преимущественно подобное происходит в дата-центрах с температурой 95 градусов.
Сейчас мои логи полны всякого шума, я получаю искажённые запросы каждый день в таком количестве, что не в состоянии просмотреть их вручную.
Поэтому я пишу скрипты в попытке найти одинаковые шаблоны запросов, и самый крупный, который у меня появился, заключался в множестве запросов одного и того же изображения на одно и то же искажённое доменное имя, и все они приходили с мобильных телефонов. Я получал эти запросы каждые несколько секунд, так как все эти телефоны пытались использовать поисковую страницу сайта Google и просили меня предоставить им крошечную картинку оригинального логотипа страницы.
Я нашел один веб-сервер из всего облака Google, которое обслуживал контент и постоянно искажал имя домена, указывая на один из моих серверов, где совершенно случайно оказался логотип с таким названием, и клиенты его забирали.
На слайде показано, как логотип поисковой страницы Google на экране мобильного устройства заменяется логотипом Occupy (Захвачено), что вызывает в зале одобрительный смех.
За два года мне на этот сервер с искажённым DNS именем пришли сотни тысяч запросов на этот логотип, вместо того, который планировал использовать Google. Затем в один прекрасный день они прекратились, так как Google отказался от изменения контента для мобильных сайтов, и этот порядок был отменён.
Итак, я продолжил изучать шаблоны запросов и попытался выяснить другие закономерности. Одна из них появлялась регулярно и происходила явно естественным путём «переворота бита» в памяти, а не в результате сохранённой ошибки бит-сквоттинга.
Я получал запросы, изображённые на следующем слайде, с периодичность один в час. Они не выглядели знакомыми, все использовали клиент Feedfetcher Google, все поступали от устройств, находящихся в одной и той же сети, и все запросы касались XML-файлов. Поэтому я немного покопался в сети и нашёл, что Feedfetcher – это механизм, который Google использует для захвата обновленного контента для iGoogle, а IP-адреса источника запросов располагались в Бельгии.
Эти запросы касаются собственных серверов Google, которые используются для получения обновленного контента для различных виджетов, формирующих персонализацию домашней страницы iGoogle, личного интернет-портала.
Каждый виджет представляет собой XML-файл, определяющий контент, и Google просил меня предоставить этот контент своим презентационным серверам (аплодисменты и смех в зале).
Поэтому я подумал, что если Google случайно захотел от меня контент, который смог бы предоставить своим пользователям, то он его получит. Я взял XML-файлы, о которых спрашивал меня Google, и разделил их на части. Как видите, здесь есть два раздела: заголовок, описывающий модуль, и блок данных на языке C, упакованный в HTML-код CSS и JavaScript, которые составляют виджет.
Так что я просто изменил ссылку на фоновое изображение, изменил адрес gstatic.com на grtatic.com, а всё остальное оставил без изменений, вложил XML-файлы в строку, откуда их берёт Feedfetcher, и немного подождал.
Практически сразу после этого Feedfetcher запросил у меня XML-файлы, после чего я немедленно начал получать запросы от множества IP-адресов Google на это фоновое изображение.
Поэтому я удалил модифицированные мной XML-файлы и стал ждать, пока запросы прекратятся, но в течение 35 дней подряд 61 устройство продолжали спрашивать меня об этом изображении каждый день. И что еще интересно, каждое из этих устройств было клиентом Virgin Media в Великобритании.
Так что этот XML-файл Google обслуживал 61 человека, и за прошедший год 500 уникальных IP-адресов Feedfetcher попросили меня предоставить эти модули 15000 раз. Так что я бы мог предоставить своим пользователям нечто более вредоносное, чем простую замену фонового изображения.
Вот ещё несколько трюков, которые можно проделать с Google. Если вы не знаете, Postini — это служба электронной почты, веб-безопасности и архивирования электронной почты для защиты от спама, которую недавно приобрёл Google.
Эта служба позволяет вам изменить свой DNS, чтобы указать свою запись MX в их домене и сделать свой домен, изменив 4 символа MX перед psmtp.com. Самое интересное здесь то, что домен настолько короткий, что вы легко сможете зарегистрировать все возможные версии имени с «перевернутыми» битами. Другой интересный момент заключается в том, что очень много компаний указывают свои записи MX для единого домена и никто не додумался до того, что это была плохая идея.
Поэтому я зарегистрировал только три возможных бит-сквоттинга для этого домена, и занятость psmtp.com оказалась такой большой, что на 4-х следующих слайдах показаны запросы, которые я получил в течение всего одного месяца.
Так что если вы пользуетесь почтой Postini, ваш запрос в какой-то момент придёт на мой сервер. Я не думаю, что кто-то может сказать, что Google не серьезно относится к вопросу интернет-безопасности. Но если бы кто-нибудь задумался, к каким проблемам может привести перегрев, вызывающий ошибки памяти, то он бы смог поставить вопрос о рассмотрении возможности компенсации за такие вещи. Поэтому не позволяйте своим доменным именам быть такими короткими, потому что это негативно влияет на ваш бизнес, такой, как Postini, особенно если ваш домен популярен.
Я настоятельно рекомендую людям применять политику управления внутренними доменными именами, позволяющую исправлять ошибки искажения имён, и четко понимать, каким образом на вас могут повлиять подобные вещи. Если у вас есть gstatic.com и дата-центр, работающий при температуре 95 градусов, вероятно, вы захотите убедиться, что любая ошибка бит-сквоттинга не позволит клиенту добраться до вредоносной внешней сети.
Кстати, среди всех доменов, которые я исследовал, единственной компанией, которая зарегистрировала все возможные искажения собственного имени, была Yahoo.
В следующей части выступления я собираюсь продемонстрировать поведение DNS, которое многие люди, как оказывается, не полностью понимают.
Честно говоря, Microsoft очень плохо провела работу по документированию, тем более, что поведение DNS часто меняется. Это приводит к непониманию происходящего конечными пользователеми, тем более, что такое поведение часто противоречиво.
Поэтому я начну с того, что все должны понимать, как должны вести себя устройства при запросе DNS и чего от них стоит ожидать. Затем объясню, насколько это поведение становится непредсказуемым при использовании путей поиска суффиксов DNS, как на всё это влияет недостаточная документация, и закончу кратким обзором уроков, которые из всего этого можно извлечь. Но сначала я продемонстрирую, насколько опасным может быть непонимание конечным пользователем того, что происходит с DNS.
Итак, после того, как вы набрали в адресной строке браузера www.google.com, ваш компьютер отправляет запрос на локальный DNS-сервер, и работа по поиску нужной вам вещи, возврату запроса и ответу теперь возлагается на него. Локальный сервер обращается к root-серверу с запросом на доступ к серверу .com, и корневой сервер отсылает его к серверу .com. Тот проверяет, авторизирован ли локальный сервер для запросов к google.com и отсылает его к серверу ns.google.com. Наконец, локальный сервер получает ответ с IP-адресом нужного вам ресурса и отправляет его вам.
Это нормальное поведение DNS, которое все от него ожидают. Все думают, что достаточно просто отослать запрос с устройства вашему локальному DNS-серверу, чтобы тот проделал всю тяжелую работу, и затем получить ответ на свой запрос. Но не все представляют, что этот процесс состоит из множества важных шагов.
Например, ваше устройство пытается найти ответ на сайте www.google.com, но весь этот процесс, который занял у нас целых 8 слайдов, будет происходить так только в том случае, если вы напечатаете в строке запроса браузера именно такой адрес — www.google.com. Это полное имя домена, которое ассоциировано именно с root DNS. Многие люди верят, что полное имя домена заканчивается точкой, что неверно. Наличие точки в конце полного имени всё равно предполагается, и из-за этого случаются неприятности. Попробуем напечатать 4 вариации имени:
www.google.com
google.com
www
www.google.com.
каждое из которых ведёт себя по-разному в отношении поведения DNS. Всё это настраивается, но обычно никто этого не делает.
Давайте рассмотрим, что на самом деле происходит в таких ситуациях. Существует несколько факторов, влияющих на принятие решений со стороны клиента, прежде чем он решит отправить запрос DNS. Два из них – это пути поиска суффикса и деволюция DNS.
Оба имеют множество настраиваемых параметров, влияющих на их поведение, и ведут себя по-разному в разных версиях Windows и в разных сервис-паках.
Вот как большинство людей будет использовать суффикс пути поиска. Если ваша компания называется foo и вы владеете доменом foo.com, а имя активной директории ad.foo.com, вы можете использовать суффикс путей поиска ad.foo.com или foo.com и «втолкнуть» это в клиентскую часть системной сборки или в групповую политику.
Если один из ваших клиентов пытается разрешить короткое имя www, то поведение Windows ХР по умолчанию будет таким. Сначала она отправит запрос DNS по пути www.ad.foo.com, затем по пути www.foo.com и в конце последует запрос NetBIOS – просто www.
Если ваше устройство запрашивает ресурс www.phx, при поведении ХР по умолчанию первым будет сам запрос www.phx, потому что он имеет две метки, затем последует запрос www.phx.ad.foo.com, потом www.phx.foo.com. Так как всё имя занимает менее 15 байт, также последует попытка обращения к NetBIOS, и запрос будет выглядеть как www.phx.
Начиная с версий Windows, вышедших после XP sp.3, все запросы сводятся к виду DNS — www.phx и NetBIOS — www.phx, после чего всё останавливается, других путей нет.
Так как большинство людей разрабатывают дизайн решений, основанный на ожидаемом поведении, то после того, как привычный порядок вещей ломается, они начинают игры с реестром и параметрами групповой политики безопасности, чтобы исправить проблемы совместимости. Таким образом, получается, что Microsoft сломал деволюцию DNS.
До XP и до того, как Microsoft изменил поведение в XP, в отсутствие путей поиска DNS операционная система Windows использовала деволюцию DNS для поиска и ответа. Без пути поиска, если клиент запрашивает www, Windows добавляет только один домен, который знает, она присоединяет конкретный домен, который берёт из DHCP или из службы каталогов Active Directory. Если первый запрос был www.phx.ad.foo.com, то поднимаясь по домену, запрос последовательно меняется на www.ad.foo.com, www.foo.com, наконец, www.com и на этом всё останавливается.
18:30 мин
Конференция DEFCON 21. DNS может быть опасен для вашего здоровья. Часть 2
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до декабря бесплатно при оплате на срок от полугода, заказать можно тут.
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Я собираюсь поговорить с вами о нескольких вещах, связанных с исследованиями, над которыми я работал несколько последних лет. Их объединяет общая тема — если вы не мониторите свой DNS трафик и не понимаете, что там происходит, когда всё в порядке, то вы наверняка не обратите внимания, когда с ним начнут происходить плохие вещи. Я «насиловал» DNS в течение нескольких лет и это всегда было одним из моих любимых векторов атаки. Вы можете потратить целое состояние на упрочнение периметра сети, но если я могу получить контроль над одним из ваших устройств, поверьте мне, ваша игра закончена.
Отсутствие на рынке сканеров уязвимости, позволяющих обнаружить неправильные конфигурации, всегда дают мне возможность «просунуть ногу в дверь». Сегодня мы обсудим различные темы, в которых я расскажу о моих приключениях с DNS и моих проделках над людьми, связанных с DNS.
Эти темы посвящены непониманию поведения DNS конечными пользователями сети, я немного расскажу о людях, которые не зарегистрировали свои домены, и о самом взломе доменов.
На конференциях Black Hat и DefCon в 2011 году Артём Дайнеберг рассказал о том, что назвал бит-сквоттинг, или «переворачивание бита». Те, кто не знаком с этим исследованием, но заинтересован этой проблемой в DNS популярных доменов, могут скачать материалы его презентации по ссылкам, приведённым на этом слайде.
Страница проекта / видеопрезентация / слайды
Когда я прочитал анонс его выступления, опубликованный ещё перед докладом на Black Hat, я сразу заинтересовался, как это можно использовать в своих целях. Не вдаваясь в детали, я объясню, что такое бит-сквоттинг, почему он происходит и на что влияет. Я покажу вам несколько примеров того, какой риск представляет случайный переворот бита в памяти, когда 1 превращается в 0 и наоборот. На следующих слайдах показано, как это выглядит на примере строки в памяти, которая отображает доменное имя.
В середине такой строки единица превращается в ноль. Артём исследовал явление, при котором ошибка единичного бита в правильной части памяти в нужный момент заставляла клиента запросить полностью легитимное, но неправильное имя домена.
По поводу вероятности возникновения и причин такой ошибки велось много разговоров, но я принялся изучать все способы, которые позволяют использовать эту ошибку в злонамеренных целях. Так что бит-сквоттинг DNS позволяет исказить доменные имена, затем зарегистрировать эти «неправильные» домены и направлять на них запросы пользователей.
На следующем слайде показано, что в результате бит-сквоттинга доменного имени Google, когда протон высокой энергии в памяти «ударяет» по 1, означающей букву g, превращает её в 0, означающий букву f, и в результате пользователь перенаправляется на сайт goofle.com.
Итак, ваш браузер совершенно законно перенаправит вас на другой сайт и с радостью заберёт оттуда ответ для вас. При этом DNS SEC никоим образом не сможет вам помочь, и на самом деле существует очень мало возможностей предотвратить эту ошибку совершенно невидимым способом, кроме использования памяти ECC, которая автоматически распознаёт и исправляет ошибки битов.
Однако такой вид памяти не очень распространён, и даже если бы вы использовали ECC, существует ещё множество мест, где может произойти бит-сквоттинг и где память ECC никогда не применяется, например, в сетевой карте или в кэше DRAM жесткого диска.
Дайнеберг подробно описал причины возникновения проблемы, но в целом можно сказать, что ошибки памяти случаются, иногда они повреждают память и иногда это оказывает эффект на DNS. В основном «переворачивание» бита происходит из-за физического повреждения памяти, перегрева, электрических проблем, воздействия радиации и даже космического излучения.
Презентация прерывается появлением на сцене организаторов DefCon, которые поздравляют докладчика и его супругу Линду, которая впервые присутствует на конференции, с одиннадцатилетием свадьбы. Роберт благодарит их за поздравление и продолжает выступление.
Космическая радиация является чрезвычайно редким фактором, влияющим на бит-сквоттинг, зато перегрев является очень частой причиной ошибок памяти. Я заметил, что смартфоны особенно уязвимы по причине условий экстремальной эксплуатации, которым они подвергаются. Перегрев аккумулятора смартфона довольно частое явление. Большинство других устройств имеют охлаждение, но даже им люди умудряются создавать тяжёлые условия эксплуатации.
Не так давно Google опубликовала информацию о работе своих дата-центров. Одной из интересных вещей, о которой я узнал, было сообщение о том, что с целью экономии электроэнергии они эксплуатируют свои дата-центры в условиях, которые большинство из нас посчитали бы неразумными. Если типичные дата-центры работают при максимальной температуре 60-70 градусов по Фаренгейту (15-20°C), то специалисты Google рекомендуют компаниям эксплуатировать дата-центры при температуре минимум 80 градусов (27°C), а один бельгийский дата-центр Google эксплуатировал свои сервера при температуре 95 градусов ( 35°C).
Надпись на карикатуре: «Я слышал, что это экономит нам деньги».
Intel и Microsoft утверждают, что их серверы отлично ведут себя при высоких температурах, а Dell гарантирует запуск своих серверов при температуре 115 градусов по Фаренгейту (46°C). Я считаю это плохой идеей, так как температура является главным фактором обеспечения стабильной работы памяти, а дата-центры Google работают на «пожарных» температурах.
Я стал изучать, какие преимущества это может дать, и какие домены наиболее уязвимы для бит-сквоттинга, то есть пытался найти наиболее часто запрашиваемые имена для повышения вероятности того, что столкнусь с подобными ошибками. Я стал собирать DNS-логи крупных компаний, чтобы найти наиболее распространённые доменные имена и выяснил, что наиболее запрашиваемым именем было gstatic.com. Это один из доменов, который служит Google для предоставления такой статической информации, как CSS, изображения, JavaScript и XML файлы.
Я написал скрипт для определения возможных «переворотов» бита в этом доменном имени gstatic.com, и получил список всех вариаций данного имени в количестве 34 штук. Пять из них использовались в легальных целях, остальные 29 были доступны, поэтому я все их купил.
Я сразу же попал в цель. Кто-то искал изображения в Google и содержание запроса вернулось к ним каким-то образом повреждённым, потому что его браузер попросил меня обслужить одну из картинок в запросе. Я вижу их IP-адрес, искаженное имя, которое они запросили, ресурс, который они пытались восстановить с помощью этого изображения, страницу, относящуюся к этому содержимому, и клиент, который использовался в качестве браузера для отсылки данного запроса.
На странице вы можете увидеть интересный артефакт в виде запроса конкретного имени Trisha Jones.
Далее количество запросов росло, возникало больше искажённых имён, больше запросов изображений и больше ссылок на исходный запрос, в результате чего я собрал более 50 000 уникальных запросов, и подобное, как выяснилось, было распространённым явлением.
На слайде показан запрос на «отфотошопленное» изображение актрисы Селены Гомез, что вызывает смех в зале.
Так что иногда бит-сквоттинг случается как раз в правильное время, чтобы совпасть с одним из ваших запросов, и если это происходит не слишком часто, можно не беспокоиться. Но иногда это случается в тот самый момент, когда происходит сохранение на жёсткий диск, что уже более интересно. Существуют шансы, что бит-сквоттинг возникнет при обычных условиях эксплуатации памяти, но очень похоже, что преимущественно подобное происходит в дата-центрах с температурой 95 градусов.
Сейчас мои логи полны всякого шума, я получаю искажённые запросы каждый день в таком количестве, что не в состоянии просмотреть их вручную.
Поэтому я пишу скрипты в попытке найти одинаковые шаблоны запросов, и самый крупный, который у меня появился, заключался в множестве запросов одного и того же изображения на одно и то же искажённое доменное имя, и все они приходили с мобильных телефонов. Я получал эти запросы каждые несколько секунд, так как все эти телефоны пытались использовать поисковую страницу сайта Google и просили меня предоставить им крошечную картинку оригинального логотипа страницы.
Я нашел один веб-сервер из всего облака Google, которое обслуживал контент и постоянно искажал имя домена, указывая на один из моих серверов, где совершенно случайно оказался логотип с таким названием, и клиенты его забирали.
На слайде показано, как логотип поисковой страницы Google на экране мобильного устройства заменяется логотипом Occupy (Захвачено), что вызывает в зале одобрительный смех.
За два года мне на этот сервер с искажённым DNS именем пришли сотни тысяч запросов на этот логотип, вместо того, который планировал использовать Google. Затем в один прекрасный день они прекратились, так как Google отказался от изменения контента для мобильных сайтов, и этот порядок был отменён.
Итак, я продолжил изучать шаблоны запросов и попытался выяснить другие закономерности. Одна из них появлялась регулярно и происходила явно естественным путём «переворота бита» в памяти, а не в результате сохранённой ошибки бит-сквоттинга.
Я получал запросы, изображённые на следующем слайде, с периодичность один в час. Они не выглядели знакомыми, все использовали клиент Feedfetcher Google, все поступали от устройств, находящихся в одной и той же сети, и все запросы касались XML-файлов. Поэтому я немного покопался в сети и нашёл, что Feedfetcher – это механизм, который Google использует для захвата обновленного контента для iGoogle, а IP-адреса источника запросов располагались в Бельгии.
Эти запросы касаются собственных серверов Google, которые используются для получения обновленного контента для различных виджетов, формирующих персонализацию домашней страницы iGoogle, личного интернет-портала.
Каждый виджет представляет собой XML-файл, определяющий контент, и Google просил меня предоставить этот контент своим презентационным серверам (аплодисменты и смех в зале).
Поэтому я подумал, что если Google случайно захотел от меня контент, который смог бы предоставить своим пользователям, то он его получит. Я взял XML-файлы, о которых спрашивал меня Google, и разделил их на части. Как видите, здесь есть два раздела: заголовок, описывающий модуль, и блок данных на языке C, упакованный в HTML-код CSS и JavaScript, которые составляют виджет.
Так что я просто изменил ссылку на фоновое изображение, изменил адрес gstatic.com на grtatic.com, а всё остальное оставил без изменений, вложил XML-файлы в строку, откуда их берёт Feedfetcher, и немного подождал.
Практически сразу после этого Feedfetcher запросил у меня XML-файлы, после чего я немедленно начал получать запросы от множества IP-адресов Google на это фоновое изображение.
Поэтому я удалил модифицированные мной XML-файлы и стал ждать, пока запросы прекратятся, но в течение 35 дней подряд 61 устройство продолжали спрашивать меня об этом изображении каждый день. И что еще интересно, каждое из этих устройств было клиентом Virgin Media в Великобритании.
Так что этот XML-файл Google обслуживал 61 человека, и за прошедший год 500 уникальных IP-адресов Feedfetcher попросили меня предоставить эти модули 15000 раз. Так что я бы мог предоставить своим пользователям нечто более вредоносное, чем простую замену фонового изображения.
Вот ещё несколько трюков, которые можно проделать с Google. Если вы не знаете, Postini — это служба электронной почты, веб-безопасности и архивирования электронной почты для защиты от спама, которую недавно приобрёл Google.
Эта служба позволяет вам изменить свой DNS, чтобы указать свою запись MX в их домене и сделать свой домен, изменив 4 символа MX перед psmtp.com. Самое интересное здесь то, что домен настолько короткий, что вы легко сможете зарегистрировать все возможные версии имени с «перевернутыми» битами. Другой интересный момент заключается в том, что очень много компаний указывают свои записи MX для единого домена и никто не додумался до того, что это была плохая идея.
Поэтому я зарегистрировал только три возможных бит-сквоттинга для этого домена, и занятость psmtp.com оказалась такой большой, что на 4-х следующих слайдах показаны запросы, которые я получил в течение всего одного месяца.
Так что если вы пользуетесь почтой Postini, ваш запрос в какой-то момент придёт на мой сервер. Я не думаю, что кто-то может сказать, что Google не серьезно относится к вопросу интернет-безопасности. Но если бы кто-нибудь задумался, к каким проблемам может привести перегрев, вызывающий ошибки памяти, то он бы смог поставить вопрос о рассмотрении возможности компенсации за такие вещи. Поэтому не позволяйте своим доменным именам быть такими короткими, потому что это негативно влияет на ваш бизнес, такой, как Postini, особенно если ваш домен популярен.
Я настоятельно рекомендую людям применять политику управления внутренними доменными именами, позволяющую исправлять ошибки искажения имён, и четко понимать, каким образом на вас могут повлиять подобные вещи. Если у вас есть gstatic.com и дата-центр, работающий при температуре 95 градусов, вероятно, вы захотите убедиться, что любая ошибка бит-сквоттинга не позволит клиенту добраться до вредоносной внешней сети.
Кстати, среди всех доменов, которые я исследовал, единственной компанией, которая зарегистрировала все возможные искажения собственного имени, была Yahoo.
В следующей части выступления я собираюсь продемонстрировать поведение DNS, которое многие люди, как оказывается, не полностью понимают.
Честно говоря, Microsoft очень плохо провела работу по документированию, тем более, что поведение DNS часто меняется. Это приводит к непониманию происходящего конечными пользователеми, тем более, что такое поведение часто противоречиво.
Поэтому я начну с того, что все должны понимать, как должны вести себя устройства при запросе DNS и чего от них стоит ожидать. Затем объясню, насколько это поведение становится непредсказуемым при использовании путей поиска суффиксов DNS, как на всё это влияет недостаточная документация, и закончу кратким обзором уроков, которые из всего этого можно извлечь. Но сначала я продемонстрирую, насколько опасным может быть непонимание конечным пользователем того, что происходит с DNS.
Итак, после того, как вы набрали в адресной строке браузера www.google.com, ваш компьютер отправляет запрос на локальный DNS-сервер, и работа по поиску нужной вам вещи, возврату запроса и ответу теперь возлагается на него. Локальный сервер обращается к root-серверу с запросом на доступ к серверу .com, и корневой сервер отсылает его к серверу .com. Тот проверяет, авторизирован ли локальный сервер для запросов к google.com и отсылает его к серверу ns.google.com. Наконец, локальный сервер получает ответ с IP-адресом нужного вам ресурса и отправляет его вам.
Это нормальное поведение DNS, которое все от него ожидают. Все думают, что достаточно просто отослать запрос с устройства вашему локальному DNS-серверу, чтобы тот проделал всю тяжелую работу, и затем получить ответ на свой запрос. Но не все представляют, что этот процесс состоит из множества важных шагов.
Например, ваше устройство пытается найти ответ на сайте www.google.com, но весь этот процесс, который занял у нас целых 8 слайдов, будет происходить так только в том случае, если вы напечатаете в строке запроса браузера именно такой адрес — www.google.com. Это полное имя домена, которое ассоциировано именно с root DNS. Многие люди верят, что полное имя домена заканчивается точкой, что неверно. Наличие точки в конце полного имени всё равно предполагается, и из-за этого случаются неприятности. Попробуем напечатать 4 вариации имени:
www.google.com
google.com
www
www.google.com.
каждое из которых ведёт себя по-разному в отношении поведения DNS. Всё это настраивается, но обычно никто этого не делает.
Давайте рассмотрим, что на самом деле происходит в таких ситуациях. Существует несколько факторов, влияющих на принятие решений со стороны клиента, прежде чем он решит отправить запрос DNS. Два из них – это пути поиска суффикса и деволюция DNS.
Оба имеют множество настраиваемых параметров, влияющих на их поведение, и ведут себя по-разному в разных версиях Windows и в разных сервис-паках.
Вот как большинство людей будет использовать суффикс пути поиска. Если ваша компания называется foo и вы владеете доменом foo.com, а имя активной директории ad.foo.com, вы можете использовать суффикс путей поиска ad.foo.com или foo.com и «втолкнуть» это в клиентскую часть системной сборки или в групповую политику.
Если один из ваших клиентов пытается разрешить короткое имя www, то поведение Windows ХР по умолчанию будет таким. Сначала она отправит запрос DNS по пути www.ad.foo.com, затем по пути www.foo.com и в конце последует запрос NetBIOS – просто www.
Если ваше устройство запрашивает ресурс www.phx, при поведении ХР по умолчанию первым будет сам запрос www.phx, потому что он имеет две метки, затем последует запрос www.phx.ad.foo.com, потом www.phx.foo.com. Так как всё имя занимает менее 15 байт, также последует попытка обращения к NetBIOS, и запрос будет выглядеть как www.phx.
Начиная с версий Windows, вышедших после XP sp.3, все запросы сводятся к виду DNS — www.phx и NetBIOS — www.phx, после чего всё останавливается, других путей нет.
Так как большинство людей разрабатывают дизайн решений, основанный на ожидаемом поведении, то после того, как привычный порядок вещей ломается, они начинают игры с реестром и параметрами групповой политики безопасности, чтобы исправить проблемы совместимости. Таким образом, получается, что Microsoft сломал деволюцию DNS.
До XP и до того, как Microsoft изменил поведение в XP, в отсутствие путей поиска DNS операционная система Windows использовала деволюцию DNS для поиска и ответа. Без пути поиска, если клиент запрашивает www, Windows добавляет только один домен, который знает, она присоединяет конкретный домен, который берёт из DHCP или из службы каталогов Active Directory. Если первый запрос был www.phx.ad.foo.com, то поднимаясь по домену, запрос последовательно меняется на www.ad.foo.com, www.foo.com, наконец, www.com и на этом всё останавливается.
18:30 мин
Конференция DEFCON 21. DNS может быть опасен для вашего здоровья. Часть 2
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps до декабря бесплатно при оплате на срок от полугода, заказать можно тут.
Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
