Если злоумышленник попытается вклиниться в TCP-соединение и претендует на то, чтобы стать участником соединения, то он должен вступить в конкурентную борьбу с хостом, за который злоумышленник себя выдает, для того чтобы раньше него получить пакет с правильными последовательными номерами. Для разбираемого примера предположим, что злоумышленник не может блокировать пакеты, поступающие от легитимного хоста. Случаи, когда это возможно, ранее обсуждались. Во время конкурентной борьбы наступает момент, когда злоумышленник получает один из пакетов раньше легитимного хоста. Если это произошло, то можно сказать, что перехват соединения состоялся. Проблема заключается в том, что хост, за который злоумышленник себя выдает и который только что уступил в конкурентной борьбе, все еще собирается отослать свой пакет.
Хост, который только что получил пакет злоумышленника, собирается отметить пакет как полученный, подтвердить его посылкой уведомления (ACK-пакета) и в большинстве случаев сдвинуть пакет в потоке данных дальше. Когда хост получит второй пакет с теми же самыми последовательными номерами, он предположит, что получил дублирующий пакет. Дублирующие пакеты не редкость. Поэтому установленное на хостах программное обеспечение протокола TCP написано таким образом, чтобы игнорировать любые пакеты с данными, похожими на уже полученные. При этом оно не заботится о точном соответствии данных в полученных пакетах, как должно быть в случае с истинными дубликатами.
Получатель поддельного пакета собирается послать уведомление об успешном приеме данных ACK другому хосту, с которым он первоначально обменивался данными. В зависимости от того, на какой стадии пересылки данных находится хост, под который маскируется злоумышленник, посылка уведомления может иметь или не иметь смысла. Если хост в момент прихода уведомления еще не отослал пакет из-за своей занятости, то большинство хостов в таких обстоятельствах просто проигнорируют пришедшее уведомление, так или иначе отошлют незаконченные данные, а затем будут ожидать повторного уведомления.
Когда сервер получает данные, которые он принимает за очередную копию пакета, он посылает еще одно уведомление. Посылка очередного уведомления означает, что сервер уже получил эти данные ранее и продолжил свою работу дальше. При получении неожиданного внеочередного уведомления следует ответить пакетом уведомления ACK с ожидаемым последовательным номером. Поэтому когда сервер посылает истинному клиенту неожиданное для него уведомление (то есть ответ на «незаконное» уведомление само по себе незаконно), клиент делает то же, что и сервер в аналогичной ситуации: отвечает пакетом уведомления ACK с ожидаемым последовательным номером. В результате наступает перегрузка сети уведомлениями ACK (ACK storm).
Налетевший шторм уведомлений продолжается до тех пор, пока не произойдет одно из перечисленных ниже условий. Во-первых, если какое-нибудь из уведомлений затеряется или будет искажено во время пути, шторм прекратится. На быстрой, надежной локальной сети пакеты теряются нечасто. В зависимости от конфигурации сети шторм уведомлений может продолжаться некоторое время до тех пор, пока не накопятся ошибки, из-за которых будет утеряно достаточное количество пакетов для прекращения шторма.
Во-вторых, может произойти ситуация, когда после посылки нужных злоумышленнику команд он может сбросить соединение. RST-пакет, который злоумышленник посылает клиенту и/или серверу, вынуждает их прекратить отправку уведомлений ACK и фактически полностью закрыть соединение. С точки зрения пользователя, находящегося перед монитором клиента, он увидит какое-то сообщение об «аварийном завершении соединения». Увидев подобное сообщение, большинство людей не станут долго задумываться над ним и просто откроют новое окно соединения. Зачастую некоторые клиенты Telnet стирают содержимое экрана при сбросе соединения или после получения окна диалога, сообщающего о сбросе соединения. Другими словами, подведя курсор к кнопке «OK», они щелкают по кнопке мыши. Подобное поведение пользователей на руку злоумышленнику. Ему становится легче избежать обнаружения, поскольку обычно единственной подсказкой легитимному пользователю о проблемах в сети является любой подозрительный вывод данных на экран.
В-третьих, в некоторых случаях возможна повторная синхронизация клиента и сервера, для того чтобы клиент мог возобновить свою обычную деятельность. Тем не менее этот способ является проблематичным и зависит от ряда факторов. Основная идея способа состоит том, что переданное истинным клиентом количество данных должно каким-то образом сравняться с количеством данных, переданных сервером и злоумышленником. Например, если легитимный клиент во время сеанса отправил 100 байт данных, а затем вмешался злоумышленник, перехватил соединение и послал серверу от имени клиента еще 10 символов, то сервер полагает, что клиент переслал 110 байт. Программа вмешавшегося злоумышленника также считает, что отослано 110 байт. В случае, если злоумышленник собирается и далее отсылать данные, то удерживает канал. Но истинный клиент все еще полагает, что отослано только 100 байт. Тогда, когда злоумышленник захочет повторно синхронизировать сервер и легитимного клиента, он должен каким-либо способом заставить клиента догнать сервер. Злоумышленник не может вернуть сервер вспять к 100 байтам. Его действия могут привести только к увеличению сервером количества принятых данных. Итак, по мере того как клиент посылает данные, злоумышленник фабрикует уведомления на них от сервера. Клиент увеличивает свой внутренний счетчик размера пересланных данных до 110, а затем злоумышленник освобождает соединение. С этого момента сервер и клиент опять синхронизированы, и истинный клиент опять может передавать данные.
Безусловно, сложность реализации протокола TCP отзывается по-разному в различных операционных системах. Во время тестирования автором программы Hunt (см. соответствующий пункт в этой главе) он обнаружил, что определенная комбинация операционных систем клиента и сервера не вызывает десинхронизации. При подсоединении с помощью Telnet к древней машине NextOS (да, те черные кубы, которые сделал Стив Джобс (Steve Jobs) после ухода из Apple) клиента с установленной Red Hat 6.2 программа Hunt может вставлять команды, но это сможет сделать и клиент. По завершении работы не было необходимости в повторной синхронизации, поскольку, во-первых, клиент никогда не был десинхронизирован. Такой же тест, но с использованием еще одной операционной системы Red Hat 6.2 в качестве сервера Telnet породил ожидаемый результат: истинный клиент мог видеть введенные команды, но не мог их выдавать.
Представляется, что проблема шторма уведомлений (перегрузки сети уведомлениями ACK) – следствие проблемы синхронизации, по крайней мере в данном случае. На комбинации NextOS/Linux перегрузки сети не наблюдалось, но они были при комбинации Linux/Linux.
Исследование атак типа MITM в зашифрованных соединениях
Как было показано в главе 10, широкое использование шифрования является одним из самых легких способов усиления защиты от многих атак злоумышленника. Решения этой проблемы предусмотрены на всех уровнях модели OSI Международной организации по стандартизации ISO, начиная с шифрующих сетевых интерфейсных плат на уровне канала передачи данных и до многочисленных технологий шифрования на прикладном уровне. Прикладной уровень – верхний уровень модели OSI, обеспечивающий такие коммуникационные услуги, как электронная почта, пересылка файлов и другие. Большинство из протоколов, традиционно используемых для перехвата сессии, могут быть заменены протоколом SSH2, функциональные возможности которого позволяют заменить Telnet, FTP, rlogin и rcp. Вдобавок с помощью SSH2 можно туннелировать другие протоколы, например HTTP или X Windows. Отчасти протокол SSH1 также решает эти проблемы, но этот пункт наравне с главой 13 объясняет, почему SSH2 лучше.
Другим хорошим вариантом укрепления защиты является использование протокола SSL. Прежде всего он предназначен для Web-серверов, где он чаще всего и используется, но многие не осознают, что его можно использовать и с такими протоколами, как почтовый протокол POP, простой протокол электронной почты SMTP, протокол доступа к сообщениям в сети Интернет IMAP, и некоторыми другими.
Если для обеспечения своей безопасности принято решение идти по пути шифрования передаваемых данных, убедитесь в том, что выбор сделан в пользу открытых, общепризнанных алгоритмов и протоколов, основанных на стандартах. Такие протоколы, как SSH2, SSL и IPSec, возможно, не совершенны, но они подвергаются критическому анализу гораздо чаще других, поэтому есть шансы, что в них меньше недостатков. По мере обнаружения в них очередных ошибок сведения о найденных ошибках предаются широкой гласности, поэтому всегда можно узнать о необходимости внесения исправлений. Уместно заметить, что доказан факт применения в ряде удаленно управляемых программ либо плохой криптографии, либо плохой реализации хорошей криптографии.
