Защита от хакеров корпоративных сетей

Программа SMBRelay

Давайте более внимательно рассмотрим предыдущий пример. Как, не рассматривая вставку ложных пакетов, легче всего перехватить SMB-сессию? Конечно, c помощью программы SMBRelay.

SMBRelay – это программа, написанная SirDystic cDc, которая позволяет перехватывать SMB-сообщения, вынуждая клиента разорвать соединение после аутентификации пользователя. После разрыва соединения злоумышленник захватывает существующую SMB-сессию, используя тот же самый мандат (учетную запись с параметрами доступа пользователя, сформированную после его успешной аутентификации). Единственный способ противодействовать этому – использовать возможность подписи SMB-сообщений на обоих концах соединения. Вполне вероятно, что в результате этого производительность работы сети снизится на 10–15 % и будут разорваны большинство совместимых назад (не исключающих использование прежних версий или модификаций) соединений клиента, поэтому при выборе данной возможности следует проявить осторожность.

Подробные сведения об изменениях, которые необходимо выполнить для поддержки подписи SMB-сообщений, можно найти по адресу http://support.microsoft.com/support/kb/articles/Q161/3/72.asp.

Наблюдатели перегрузки сети

Далее будет показано, что эксперименты с протоколом ARP и перехват TCP-сессий могут доставить много неприятностей. Кроме того, многие атаки будут выявлены, если они могут только вставлять пакеты, и не могут предотвратить отправку данных истинными коммуникаторами. Например, в рассмотренном сценарии использования службы имен доменов DNS факт посылки двух несоответствующих друг другу ответов является серьезным сигналом, что что-то не так. Давайте глубже разберем этот пример.

Повторные передачи и дублирующие пакеты не являются чем-то необычным в обычных сетях, но в большинстве случаев содержимое пакетов должно быть одинаковым. Для рассмотренных примеров работы протоколов ARP и службы DNS вполне возможно написать программу, которая наблюдала бы за ответами, вычисляла бы кэш-величину пакета, а затем сохраняла бы эти данные в течение определенного периода времени. Поступление другого пакета с согласованными подходящим образом характеристиками, но с различными кэш-величинами свидетельствовало бы о возможных сетевых проблемах. (Следует очень внимательно отнестись к игнорированию частей пакета, которые нельзя на 100 % считать подозрительными до подсчета кэш-величины, как, например, время жизни пересылаемого пакета TTL). В основном это принцип систем обнаружения вторжения IDS со всеми их преимуществами и недостатками.

Ранее в этой главе был кратко рассмотрен пример перехвата Telnet-сессии. Цель перехвата заключалась в выполнении команды на сервере. Для этого примера автор сознательно выбрал короткую команду, в выводе результатов выполнения которой не было необходимости. На то были причины. Протокол TCP может идеально подойти для перехвата сессии. Если злоумышленник попытается контролировать оба конца соединения или удержать затянувшееся перехваченное соединение, то он может столкнуться с некоторыми трудностями. Давайте выясним, почему.

Напомним, что протокол TCP является надежным средством доставки сетевых пакетов данных. Так как TCP находится выше обслуживаемого протоколом IP ненадежного уровня, на котором пакеты иногда теряются, искажаются или принимаются вне очереди, то протокол TCP вынужден взять на себя ответственность за решение этих проблем. Существенным является то, что протокол TCP в случае необходимости решает подобные проблемы путем повторной передачи пакетов. Реализующее протокол TCP программное обеспечение сохраняет на каждом хосте копию всех ранее посланных данных до тех пор, пока не будет получено уведомление (ACK-пакет) об успешном приеме данных, генерируемое получателем пакетов на другом конце соединения. Данные удаляются только после подтверждения приема. Если в поддерживаемой программным обеспечением очереди на отправку данных имеются данные, на которые в течение определенного промежутка времени не получено уведомление об их приеме, то они посылаются повторно, предполагая, что ранее эти данные потерялись при передаче.

Если злоумышленник попытается вклиниться в 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.