То есть вероятность того, что два студента отмечают день рождения в один день, превышает 50 %.
Вообще, если имеется сопоставление n входных значений (людей, идентификаторов и т.д.) и k возможных выходных значений (дней рождения, идентификаторов и т.д.), то мы имеем n(n – 1)/2 входных пар. При n(n – 1)/2 > k вероятность того, что будет получено хотя бы одно совпадение, довольно значительна. Таким образом, оно вероятно уже примерно при n > √2k. Ключевой момент состоит в том, что мы не ищем совпадение с днем рождения одного конкретного человека, а сравниваем даты рождения всех студентов и считаем успехом любое найденное соответствие.
Учитывая вышесказанное, хакеры сначала отправляют несколько сотен DNS-запросов в отношении того домена, для которого им нужно фальсифицировать сопоставление. Локальный сервер имен пытается поочередно разрешить каждый из этих запросов путем отправки запроса серверу имен следующего уровня. Вероятно, это не слишком разумно — какой смысл многократно запрашивать данные по одному и тому же домену? Но никто и не утверждает, что серверы имен отличаются большой сообразительностью, и именно так, к примеру, работает популярный сервер имен BIND. Как бы там ни было, сразу после отправки запросов злоумышленники также отсылают сотни поддельных ответов на поисковые запросы, якобы от сервера имен следующего уровня. Эти ответы содержат разные варианты идентификатора запроса. При этом локальный сервер имен косвенно производит сравнение по принципу «многие ко многим», поскольку будет принят любой ответ, идентификатор которого совпадает с идентификатором запроса от локального сервера имен. Обратите внимание, что, как и в случае с днями рождения студентов, сервер имен сравнивает все запросы от локального сервера имен со всеми поддельными ответами.
Произведя отравление локального сервера имен какого-нибудь веб-сайта, взломщики могут, к примеру, получить доступ к трафику, который передают на этот сайт все клиенты сервера имен. Настроив свои соединения на получение данных от сайта и обеспечив ретрансляцию всего трафика между клиентами и сервером, они реализуют атаку типа «человек посередине».
Атака Каминского
Ситуация может принять еще более серьезный оборот, если злоумышленники не будут ограничиваться отдельным веб-сайтом и решат отравить данные сопоставления для целой зоны. Такое нарушение получило известность как DNS-атака Дэна Каминского; в свое время она повергла в шок многих специалистов по информационной безопасности и сетевых администраторов по всему миру. Чтобы понять, чем они были так напуганы, необходимо детально разобраться в том, как происходит DNS-поиск.
В качестве примера рассмотрим процесс обработки DNS-запроса на поиск IP-адреса домена www.cs.vu.nl. После получения этого запроса локальный сервер имен, в свою очередь, отправляет запрос либо на корневой сервер имен, либо на сервер имен домена верхнего уровня (ДВУ) по отношению к домену .nl. Второй сценарий происходит чаще по той причине, что IP-адрес сервера имен ДВУ обычно уже имеется в кэше локального сервера имен. На илл. 8.3 показан такой запрос локального сервера имен (запрашивающий A-запись домена) при выполнении рекурсивного поиска с идентификатором 1337.
Илл. 8.3. DNS-запрос в отношении домена www.cs.vu.nl
Серверу имен ДВУ не известно точное сопоставление, однако он знает имена DNS-серверов Университета Врийе и возвращает их в ответе, поскольку не производит рекурсивный поиск. На илл. 8.4 показан ответ, несколько полей которого заслуживают особого внимания. Во-первых, мы сразу видим, что флаги напрямую сообщают о нежелании сервера выполнять рекурсивный поиск, и потому дальнейший поиск будет итеративным. Во-вторых, в ответе содержится идентификатор 1337, который был использован в поисковом запросе. В-третьих, ответ содержит символьные наименования серверов имен университета ns1.vu.nl и ns2.vu.nl в виде записей NS. Эти данные являются авторитетными и, в принципе, достаточными для того, чтобы локальный сервер имен мог завершить обработку запроса. Ему нужно лишь свериться с А-записью одного из этих серверов имен, связаться с ним и запросить IP-адрес домена www.cs.vu.nl. Но чтобы это сделать, он должен еще раз связаться с тем же сервером имен ДВУ, на этот раз чтобы запросить IP-адрес сервера имен университета. Поскольку это вводит дополнительную задержку в пути туда и обратно, данный подход не слишком эффективен. Чтобы исключить необходимость в этой дополнительной операции поиска, сервер имен ДВУ услужливо предоставляет в своем ответе IP-адреса двух серверов имен университета в виде дополнительных записей с коротким временем жизни. Эти связующие DNS-записи (DNS glue records) как раз и являются ключевым элементом атаки Каминского.
Илл. 8.4. DNS-ответ, отправляемый сервером имен ДВУ
Злоумышленники действуют так. Сначала они отправляют запросы на поиск данных о несуществующем поддомене в домене университета, таком как ohdeardankaminsky.vu.nl. Поскольку этого поддомена нет, ни один сервер имен не может предоставить данные сопоставления из своего кэша. Вместо этого локальный сервер должен связаться с сервером имен ДВУ. Сразу после отправки запросов взломщики отсылают множество поддельных ответов, якобы от сервера имен ДВУ, как и в случае обычного спуфинга DNS. Однако на этот раз в ответе говорится, что сервер имен ДВУ не располагает нужными данными (то есть он не предоставляет A-запись), не выполняет рекурсивный поиск и рекомендует локальному серверу имен завершить поиск путем обращения к одному из серверов имен университета. Он даже может предоставить реальные имена этих серверов. Единственное, что при этом фальсифицируется, это связующие записи: вместо них злоумышленники дают подконтрольные им IP-адреса. В результате при запросе данных о любом поддомене в домене .vu.nl производится обращение к серверу имен злоумышленников, которые могут предоставить в ответ какой угодно IP-адрес. Таким образом, они способны провести атаку типа «человек посередине» против любого сайта в домене университета!
Очень многие (хотя и не все) реализации серверов имен были уязвимы к этой атаке. Очевидно, у интернета возникла проблема. В связи с этим в штаб-квартире компании Microsoft в Редмонде было собрано экстренное совещание. Как позже вспоминал Каминский, оно было окутано столь строгой атмосферой секретности, что «многие из прилетевших в Microsoft людей даже не знали, о какой программной ошибке пойдет речь».
Каким же образом все эти умные люди справились с проблемой? По правде говоря, решить ее полностью им не удалось, хотя они и сумели существенно усложнить хакерам задачу. Напомним, что корневая проблема, из-за которой спуфинг DNS возможен, заключается в том, что длина идентификатора запроса составляет лишь 16 бит. Это позволяет получить его либо путем прямого перебора, либо с помощью атаки «дней рождения». Увеличение длины идентификатора запроса существенно снижает вероятность успешного проведения такой атаки. Однако просто изменить формат сообщения протокола DNS затруднительно; кроме того, это нарушило бы работу многих существующих систем.
Было принято решение дополнить длину произвольного идентификатора путем введения элемента случайности и в UDP-порт отправителя (не прибегая к реальному увеличению идентификатора запроса). К примеру, при отправке DNS-запроса на сервер имен ДВУ модифицированный сервер имен будет случайным образом выбирать номер порта из тысяч доступных номеров и использовать этот порт в качестве UDP-порта отправителя. Теперь злоумышленнику нужно подобрать не только идентификатор запроса, но и номер порта, успев сделать это до поступления реального ответа. Кодировка 0x20, о которой мы говорили в главе 7, дополняет идентификатор транзакции еще несколькими битами. При этом учитывается, что DNS-запросы нечувствительны к регистру.