Когда сервер получает данные, которые он принимает за очередную копию пакета, он посылает еще одно уведомление. Посылка очередного уведомления означает, что сервер уже получил эти данные ранее и продолжил свою работу дальше. При получении неожиданного внеочередного уведомления следует ответить пакетом уведомления 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 в зашифрованных соединениях