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

· Протокол SSL может быть фальсифицирован с помощью способа, состоящего из трех шагов. Во-первых, увеличение длины URL для запутывания фактического адреса во всплывающем диалоговом окне. Во-вторых, создание строки состояния с включенным признаком «блокировки SSL» и выделение в самостоятельный элемент произвольного, но заслуживающего доверия с точки зрения графики, содержимого окна, j накладываемого на основную экранную форму. В-третьих, для большого правдоподобия может быть определен размер полноэкранного всплывающего прямоугольного окна без обеспечиваемых операционной системой границ или рамок. Впоследствии, по капризу удаленного сервера, они могут быть добавлены.

Малоизвестные подробности: разработка систем спуфинга

· Прямой доступ к сетевым ресурсам характеризуется минимальными ограничениями на данные, передаваемые по проводным каналам связи. Когда пытаются проектировать системы, которые скорее опровергают общепринятые правила, чем чрезмерно следуют им, то это может привести к удивительным по своей эффективности результатам.

· Своим существованием библиотека Libnet доказывает возможность построения эффективного, переносимого с платформы на платформу инструментального средства генерации и посылки фальсифицированных пакетов по проводным каналам связи. Одновременно библиотека libpcap предоставляет противоположные функциональные возможности приема пакетов из канала связи. Комбинация названных инструментальных средств работает вполне прилично.

· Маршрутизатор, реализующий основные функции маршрутизации, должен отвечать на ARP-запросы разрешения «несуществующего» IP-адреса и выдавать ARP-ответы, обслуживающие «несуществующий» MAC-адрес аппаратного устройства, который перехватывает приходящие пакеты. Адресованные маршрутизатору пакеты утилиты ping могут быть перехвачены на месте и отосланы ей обратно. Что-либо еще, адресованное по правильному МАС-адресу, может рассматриваться как нечто, предназначенное для дополнительной сети. Конечно, рассмотренный маршрутизатор сильно упрощен, но тем не менее его можно реализовать.

Вопрос:Есть ли хорошие решения противодействия спуфингу?

Ответ:Существуют решения, которые могут внести существенный вклад в предотвращение определенных типов спуфинга. Например, реализованный должным образом протокол SSH является хорошим решением удаленного терминала. Но ничто не совершенно. Протокол SSH уязвим к атакам типа «злоумышленник посередине», например во время первого обмена ключами. Если обеспечить безопасность получения ключей в первый раз, то об изменении ключей в последующем будет сообщено. Другой большой проблемой использования основанных на криптографии решений является централизованное распределение и управление ключами. Эта проблема уже обсуждалась в главе.

Вопрос:Какие инструментальные средства спуфинга доступны? Ответ:Большинство инструментальных средств спуфинга относятся к сфере сетевых средств. Например, в главе 11 рассказано об использовании инструментальных средств, которые могут как фальсифицировать, так и перехватывать (похищать) сессии, решая задачи активного спуфинга. Другие инструментальные средства спуфинга предназначены для работы с DNS, IP, SMTP и многим другим.

Вопрос:Существуют ли способы проверки получения фальсифицированных пакетов? Ответ:Как правило, фальсифицированные пакеты посылаются вслепую, поэтому «хост отправителя» будет вести себя подозрительно, будто он и вправду не получает никаких ответов на свои пакеты. Забавно, не правда ли? Но только что был обнаружен блестящий способ простого и в разумной степени надежного определения, является ли пакет, полученный от другого отправителя, фальсифицированным. Принцип работы программы Despoof, разработанной печально известным Simple Nomad, основан на следующем простом предположении: нападающий не знает числа сетевых «прыжков» (ближайших маршрутизаторов, находящихся на расстоянии одного «прыжка»), которые нужно совершить хосту для передачи пакета адресату. Поскольку в большинстве случаев маршрутизация в Интернете симметрична, то число «прыжков» к выбранному хосту дает адекватную оценку числа «прыжков», необходимых для ответного сообщения. (Ошибочно полагать, что при простом прозванивании хоста утилитой ping и контроле числа вычитаний единицы из значения счетчика предписанного времени жизни пакета TTL во время обратного путешествия пакета будет получено верное значение числа «прыжков» до хоста адресата. На самом деле будет возвращено число «прыжков», далекое от истинного значения.) Вот что интересно. Злоумышленник не сможет проверить сеть между хостом читателя и фальсифицируемым им узлом. Сравнивая число «прыжков» во время путешествия тестирующего пакета с установленным числом фактически сделанных «прыжков», можно определить, что пакет передавался от отправителя до адресата по неправильному маршруту, и поэтому вполне возможно, что он фальсифицирован. Число «прыжков» во время путешествия тестирующего пакета можно определить по значению ORIGINAL_TTL-TTL_OF_PACKET, которое обычно равно двум в степени некоторого смещения минус число между единицей и двенадцатью. Достаточно интересно, что таким образом можно что-то узнать о фальсификаторе, потому что число пройденных «прыжков» характеризует его сетевой путь. Конечно, фальсификатор вполне может фальсифицировать исходную величину счетчика предписанного времени жизни пакета TTL, для того чтобы защитить себя от такого сетевого мониторинга. Но пока злоумышленник не знает о возможности подобных действий, он так делать и не будет. Если не будут выполнены какие-либо отвлекающие действия, то можно определить, что злоумышленный трафик начинается с середины маршрута, как будто это сетевая атака. Конечно, это вопрос выбора рисков читателя. Программу Despoof можно найти по адресу http://razor.bindview.com/tools/desc/despoof_readme.html. Это действительно интересное инструментальное средство.

Вопрос:Каким образом атакующий сможет перенаправить сетевой трафик так, чтобы он казался пришедшим от других хостов? Ответ:Простейшие и наиболее эффективные способы захвата хоста одной и той же физической подсети описаны в главе 11. Изредка возможно похищение сетевого трафика вне подсети при помощи компрометации промежуточных маршрутизаторов, но наиболее часто это осуществляется с помощью DNS-серверов. Дэвид Уелевич (David Uelevich), основатель Everydns.Net, пишет: «Когда ищется запись домена на сервере имен, то это обычно сервер имен клиентской сети, который осуществляет поиск и по очереди возвращает ответ клиенту. Проблема с «отравлением» DNS возникает в случае, когда сервер имен клиентов воспринимает неверную информацию от удаленного сервера, который либо преднамеренно, либо случайно бездумно раздает коды возврата, изменяющие поведение клиентов сервера имен». Помните, IP-адреса обычно не указывают непосредственно на адресата. (Действительно, в протоколе IPV6 почти невозможно непосредственно указать адресата. Длина адресов в протоколе IPV6 почти в 4 раза длиннее IP-адреса в протоколе IPV4.) Обычно на адресата ссылаются по DNS-имени. Компрометация отображения DNS-имен в IP-адреса будет иметь тот же самый эффект, как если бы оказалось взломано соответствие между приятелем читателя и его телефонным номером. В конце концов, читатель сможет распознать, что на другом конце линии находится не его приятель, а кто-то другой, но компьютер – нет, за исключением, пожалуй, случая использования для такой попытки подключения протокола SSL. В подобном случае нападающий, как брокер соединения, может законным образом перенаправить читателя к его фактическому адресату.