Существует альтернативный, но схожий подход, при котором используется одна особенность: таблица коммутатора имеет ограниченный размер. Злоумышленник «заваливает» коммутатор фреймами Ethernet с поддельными адресами отправителей. Не зная, что они фальшивые, коммутатор фиксирует их, пока таблица не заполнится и для размещения новых записей не потребуется удаление старых. Поскольку теперь у коммутатора нет записи для целевого хоста, предназначенный для этого хоста трафик начинает рассылаться по всей сети. Лавинная рассылка MAC-адресов (MAC flooding) снова превращает сеть Ethernet в широковещательную среду, какой она была в далеком 1979 году.
Вместо того чтобы вводить коммутатор в заблуждение, злоумышленник может напрямую атаковать хост с помощью метода подмены ARP (ARP spoofing) или отравления ARP (ARP poisoning). Как упоминалось в главе 5, протокол ARP помогает компьютеру определить, какой MAC-адрес соответствует тому или иному IP-адресу. Для этого реализация ARP на компьютере ведет таблицу сопоставления IP-адресов с MAC-адресами для всех хостов, которые связывались с данным компьютером, — таблицу ARP (ARP table). Время жизни каждой записи в ней обычно составляет несколько десятков минут. По истечении этого срока MAC-адрес удаленного абонента забывается, исходя из предположения, что абоненты больше не обмениваются данными (в этом случае значение TTL сбрасывается), и для последующих коммуникаций сначала нужно выполнить ARP-поиск. ARP-поиск представляет собой обычную широковещательную рассылку сообщения примерно следующего содержания: «Мне нужен MAC-адрес хоста с IP-адресом 192.168.2.24. Если это ваш адрес, пожалуйста, сообщите об этом». Этот поисковый запрос включает MAC-адрес отправителя, чтобы хост 192.168.2.24 знал, кому отвечать, и его IP-адрес, чтобы хост 192.168.2.24 добавил в свою ARP-таблицу сопоставление IP- и MAC-адресов отправителя.
Каждый раз, когда хакер видит ARP-запрос к хосту 192.168.2.24, он может попытаться первым предоставить источнику запроса свой собственный MAC-адрес. В этом случае весь трафик, предназначенный для хоста 192.168.2.24, будет направляться на компьютер злоумышленника. На самом деле, поскольку реализации ARP обычно просты и не отслеживают состояние, взломщик зачастую может отправлять ARP-ответы, даже не дожидаясь появления запросов: реализация ARP беспрекословно примет все эти ответы и сохранит в ARP-таблице соответствующие сопоставления.
Применив этот трюк к обоим участникам коммуникации, злоумышленник сможет принимать весь трафик, которым они обмениваются. Обеспечив пересылку этих фреймов на правильный MAC-адрес, он тем самым установит скрытый шлюз атаки «человек посередине» (Man-in-the-Middle, MITM), способный перехватывать весь трафик между двумя хостами.
8.2.3. Подмена данных (помимо ARP)
Как правило, подмена данных подразумевает передачу байтов по сети с использованием поддельного адреса отправителя. Злоумышленники могут подделывать не только ARP-пакеты, но и любой другой сетевой трафик. В качестве примера можно вспомнить SMTP — удобный текстовый протокол, который сегодня повсеместно используется для отправки электронной почты. В нем применяется заголовок Mail From: для указания адреса отправителя письма, но по умолчанию указанный адрес не проверяется. То есть при желании вы можете поместить в этот заголовок что угодно, и все ответы будут отправляться на этот адрес. При этом получатель даже не увидит содержимого Mail From: — вместо него почтовый клиент отобразит содержимое отдельного заголовка From:. Но и это поле SMTP не проверяет, что позволяет подменить его содержимое. Например, вы можете отправить своим однокурсникам письмо с сообщением о том, что они провалили экзамен, и в качестве отправителя указать преподавателя. Если вы также укажете свой электронный адрес в заголовке Mail From:, то все ответы паникующих студентов окажутся в вашем почтовом ящике. Вот это веселье! Однако когда злоумышленники подделывают адрес для рассылки фишинговых писем, якобы приходящих из надежного источника, это уже далеко не так невинно. Например, письмо от «вашего доктора» может содержать ссылку на срочную информацию о результатах медосмотра, щелкнув по которой вы попадете на сайт, сообщающий, что ваше здоровье в полном порядке (без упоминания о том, что на ваш компьютер загружен вирус). А письмо от «вашего банка» может нести угрозу вашим финансам.
Хотя подмена ARP осуществляется на канальном уровне, а подмена SMTP — на прикладном, в принципе, методы подмены могут применяться на любом уровне стека протоколов. Иногда это достаточно просто сделать. Например, любой, кто умеет создавать пользовательские пакеты, может легко подделать фрейм Ethernet, IP-дейтаграмму или UDP-пакет. Достаточно лишь изменить адрес отправителя, и эти протоколы никак не смогут выявить обман. Многие другие протоколы гораздо труднее поддаются обману. Например, в случае TCP-соединений конечные точки сохраняют такие данные о состоянии, как порядковые номера и номера подтверждения, что сильно усложняет подмену данных. Если злоумышленнику не удастся получить порядковые номера путем прослушивания или угадать их, то получатель отбросит поддельные TCP-сегменты как выходящие за рамки установленного окна. Как мы увидим далее, помимо этого имеется ряд других существенных сложностей.
Даже простые протоколы позволяют злоумышленникам наносить весьма значительный ущерб. Вскоре мы узнаем, насколько разрушительными могут быть DoS-атаки, вызванные подменой UDP-пакетов. Но сначала мы обсудим, как хакеры с помощью подмены UDP-дейтаграмм службы DNS перехватывают информацию, отправляемую клиентами на сервер.
Спуфинг DNS
Поскольку служба DNS использует протокол UDP для пересылки своих запросов и ответов, подмена данных здесь не представляет большого труда. Например, как и в случае подмены ARP, можно подождать, пока клиент не отправит поисковый запрос в отношении домена trusted-services.com, а затем, опередив настоящую службу DNS, предоставить клиенту поддельный ответ. В нем будет указано, что для этого домена следует использовать принадлежащий вам IP-адрес. Это легко сделать, если вы можете прослушать поступающий от клиента трафик (и таким образом увидеть содержимое запроса на DNS-поиск, на который нужно ответить). Но что, если вы не можете увидеть этот запрос? В конце концов, если вы уже и так прослушиваете линию, то перехват этого трафика путем спуфинга DNS не имеет особого смысла. Кроме того, что, если вам нужно перехватить трафик не одного, а сразу нескольких пользователей?
Если злоумышленник использует тот же локальный сервер имен, что и жертва, он просто отправляет собственный запрос, скажем, для домена trusted-services.com. После этого сервер начинает искать этот IP-адрес и пытается связаться со следующим сервером имен в процессе поиска. На этот запрос локального сервера имен злоумышленник немедленно выдает поддельный ответ, якобы от следующего сервера. В результате локальный сервер имен сохраняет в своем кэше сфальсифицированное сопоставление и предоставляет его, когда жертва (или кто-то еще), наконец, запрашивает данные по домену trusted-services.com. Обратите внимание, что этот метод может сработать и в том случае, если взломщик не использует тот же локальный сервер имен, что и цель атаки. Для этого нужно как-то склонить жертву к отправке поискового запроса с доменным именем, предоставленным злоумышленником. Например, он может отправить письмо со ссылкой, при активации которой браузер выполнит поиск по нужному имени. После отравления данных сопоставления для домена trusted-services.com все последующие запросы по нему будут возвращать сфальсифицированные данные.
Проницательный читатель может возразить, что это далеко не так просто. Ведь у каждого DNS-запроса есть 16-битный идентификатор, и ответ принимается, только если он содержит такой же идентификатор. Но если хакер не видит запрос, то ему придется подбирать этот идентификатор наугад. Вероятность успеха подбора для отдельного ответа составляет 1 : 65 536. В среднем хакеру придется отправить десятки тысяч DNS-ответов за очень короткий промежуток времени, чтобы сфальсифицировать лишь одно сопоставление на локальном сервере имен, не имея при этом никакой обратной связи. Это нельзя назвать простой задачей.
Атака «дней рождения»
Существует и более простой метод, который называют атакой «дней рождения» (birthday attack), или парадоксом «дней рождения» (birthday paradox); хотя, строго говоря, это вовсе не парадокс. Идея этого метода заимствована из задачи, часто используемой профессорами математики при изложении теории вероятности. Вопрос: сколько студентов должно быть в классе, чтобы вероятность того, что двое из них родились в один день, превысила 50 %? На первый взгляд кажется, что ответом будет число, значительно превышающее 100. Однако согласно теории вероятности это число на самом деле равно 23. Для 23 людей вероятность того, что ни у кого из них не совпадает день рождения, равна:
То есть вероятность того, что два студента отмечают день рождения в один день, превышает 50 %.
Вообще, если имеется сопоставление n входных значений (людей, идентификаторов и т.д.) и k возможных выходных значений (дней рождения, идентификаторов и т.д.), то мы имеем n(n – 1)/2 входных пар. При n(n – 1)/2 > k вероятность того, что будет получено хотя бы одно совпадение, довольно значительна. Таким образом, оно вероятно уже примерно при n > √2k. Ключевой момент состоит в том, что мы не ищем совпадение с днем рождения одного конкретного человека, а сравниваем даты рождения всех студентов и считаем успехом любое найденное соответствие.
Учитывая вышесказанное, хакеры сначала отправляют несколько сотен DNS-запросов в отношении того домена, для которого им нужно фальсифицировать сопоставление. Локальный сервер имен пытается поочередно разрешить каждый из этих запросов путем отправки запроса серверу имен следующего уровня. Вероятно, это не слишком разумно — какой смысл многократно запрашивать данные по одному и тому же домену? Но никто и не утверждает, что серверы имен отличаются большой сообразительностью, и именно так, к примеру, работает популярный сервер имен BIND. Как бы там ни было, сразу после отправки запросов злоумышленники также отсылают сотни поддельных ответов на поисковые запросы, якобы от сервера имен следующего уровня. Эти ответы содержат разные варианты идентификатора запроса. При этом локальный сервер имен косвенно производит сравнение по принципу «многие ко многим», поскольку будет принят любой ответ, идентификатор которого совпадает с идентификатором запроса от локального сервера имен. Обратите внимание, что, как и в случае с днями рождения студентов, сервер имен сравнивает все запросы от локального сервера имен со всеми поддельными ответами.