Текст книги "Атака на Internet"

• модификация передаваемых данных;

• модификация передаваемого кода.

Модификация передаваемых данных

Одна из функций, которой может обладать система воздействия, построенная по принципу «ложный объект», – модификация передаваемых данных. В результате селекции потока перехваченной информации и его анализа система может распознавать тип передаваемых файлов (исполняемый или текстовый). Поэтому в случае обнаружения текстового файла или файла данных появляется возможность модифицировать проходящие через ложный объект данные. Особую угрозу эта функция представляет для сетей обработки конфиденциальной информации.

Модификация передаваемого кода

Другим видом модификации может быть модификация передаваемого кода. Проводя семантический анализ перехваченной информации, ложный объект способен выделять из потока данных исполняемый код. Известный принцип неймановской архитектуры гласит, что не существует различий между данными и командами. Следовательно, чтобы выяснить, код или данные передаются по сети, необходимо использовать некоторые особенности, свойственные реализации сетевого обмена в конкретной РВС или присущие конкретным типам исполняемых файлов в данной локальной операционной системе.

Представляется возможным выделить два различных по цели вида модификации кода:

• внедрение разрушающих программных средств (РПС);

• изменение логики работы исполняемого файла.

В первом случае при внедрении РПС исполняемый файл модифицируется по вирусной технологии, то есть к нему одним из известных способов дописывается тело РПС, и точка входа изменяется таким образом, чтобы она указывала на начало кода внедренного воздействия. Описанный способ практически ничем не отличается от стандартного заражения вирусом, за исключением того, что файл оказывается зараженным вирусом или РПС в момент передачи его по сети. Такое возможно только при использовании системы воздействия, построенной по принципу «ложный объект». Конкретный вид разрушающих программных средств, их цели и задачив данном случае не имеют значения, но можно рассмотреть, например, вариант использования ложного объекта для создания сетевого червя (наиболее сложного на практике удаленного воздействия в сетях) или в качестве РПС использовать анализаторы сетевого трафика (сниферы – от англ. «sniffer»). Во втором случае происходит модификация исполняемого кода с целью изменения логики его работы. Данное воздействие требует предварительного исследования работы исполняемого файла и может принести самые неожиданные результаты. Так, при запуске на сервере (например, в ОС Novell NetWare) программы идентификации пользователей распределенной базы данных ложный объект способен модифицировать код этой программы таким образом, что появится возможность беспарольного входа в базу данных с наивысшими привилегиями.

Подмена информации

Ложный объект позволяет не только модифицировать, но и подменять перехваченную им информацию. Если модификация приводит к частичному искажению информации, то подмена – к ее полному изменению. При возникновении в сети определенного контролируемого ложным объектом события одному из участников обмена посылается заранее подготовленная дезинформация, которая может быть воспринята им либо как исполняемый код, либо как данные. Рассмотрим пример дезинформации подобного рода.

Предположим, что ложный объект контролирует подключение пользователя к серверу. В этом случае взломщик ожидает, например, запуска соответствующей программы входа в систему. Если такая программа находится на сервере, то при ее запуске исполняемый файл передается на рабочую станцию (например, в случае загрузки бездисковой рабочей станции в ОС Novell NetWare). Вместо того, чтобы выполнить данное действие, ложный объект передает на рабочую станцию код заранее написанной специальной программы – захватчика паролей. Эта программа выполняет те же действия, что и настоящая программа входа в систему, например запрашивает имя и пароль пользователя, после чего полученные сведения посылаются на ложный объект, а пользователю выводится сообщение об ошибке. При этом пользователь, предположив, что он неправильно ввел пароль (пароль обычно не отображается на экране), снова запустит программу подключения к системе (на этот раз настоящую) и со второго раза получит доступ. Результат такой атаки – имя и пароль пользователя, сохраненные на ложном объекте.

Отказ в обслуживании

Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов распределенной ВС, является обеспечение надежного удаленного доступа к данному объекту с любого объекта сети: каждый субъект (пользователь) системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях такая возможность реализуется следующим образом: на объекте РВС в сетевой ОС запускается ряд программ-серверов, входящих в состав телекоммуникационных служб предоставления удаленного сервиса (например, FTP-сервер, WWW-сервер и т. д.). Задача сервера – находясь в памяти операционной системы объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. При получении подобного сообщения сервер должен по возможности передать запросившему ответ, разрешая подключение или не разрешая. По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие извне запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (порт или сокет) прикладному процессу, которым является соответствующий сервер.

Очевидно, что сетевая операционная система способна поддерживать ограниченное число открытых виртуальных соединений, а также отвечать на ограниченное число запросов (ограничена длина очереди запросов на подключение, тайм-аут очистки очереди и число одновременно открытых соединений). Эти ограничения устанавливаются индивидуально для каждой сетевой ОС. Основная проблема, возникающая в таком случае, состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с какого-либо объекта системы передавать на атакуемый объект бесконечное число анонимных запросов на подключение от имени других объектов (тем самым переполняя очередь запросов), числом на несколько порядков меньше пропускной способности канала (направленный мини-шторм), то этои будет реализацией типовой угрозы безопасности РВС «отказ в обслуживании» (denial of service – DoS). Результат такой реализации – нарушение на атакованном объекте работоспособности соответствующей службы предоставления удаленного сервиса, то есть невозможность получения удаленного доступа с других объектов РВС из-за переполнения очереди (буфера) запросов.

Суть второй разновидности реализации этой типовой угрозы заключена в передаче с одного адреса стольких запросов на атакуемый объект, сколько позволит пропускная способность канала передачи (направленный шторм запросов; от англ. «flooding» – наводнение). Если в системе не предусмотрено ограничение числа принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может быть нарушение работы системы от возможного переполнения очереди запросови отказа одной из телекоммуникационных служб, вплоть до полной остановки компьютера из-за того, что система не может заниматься ничем другим, кроме обработки запросов.

Типовая удаленная атака «отказ в обслуживании» является активным воздействием (класс 1.2), осуществляемым с целью нарушения работоспособности системы (класс 2.3), относительно объекта атаки (класс 3.3). Данная атака является однонаправленным (класс 4.2) внутрисегментным (класс 5.1) или межсегментным воздействием (класс 5.2), осуществляемым на канальном (класс 6.2), сетевом (класс 6.3), транспортном (класс 6.4) и прикладном (класс 6.7) уровнях модели OSI.

Для моделирования механизмов реализации данной типовой угрозы воспользуемся графовой моделью взаимодействия объектов РВС в проекции на канальный и сетевой уровни модели OSI (рис. 3.10).

Рис. 3.10. Графовая модель взаимодействия объектов РВС при реализации типовой угрозы «отказ в обслуживании» в проекции на канальный и сетевой уровни модели OSI

Пусть объект X_k взаимодействует с объектом X_M. Пусть с объекта X₁ осуществляется данное воздействие с целью нарушить работоспособность объекта X_k. Тогда с объекта X₁ осуществляется направленный шторм (или мини-шторм) запросов на объект X_k от имени любых объектов в сети (ls_xik). Если атака достигла цели, на сетевом уровне нарушается взаимодействие объекта X_k с объектом X_M, а на канальном уровне может нарушиться взаимодействие X_k с ближайшим роутером G_M+k. Следовательно, на графе взаимодействия объектов РВС пропадают однонаправленные линии связи ls_kM и ks_kM+k.

Глава 4
Удаленные атаки на хосты Internet

Многое

Наша Земля повидала,

Но не видала

Такого скандала!

Б. Заходер. География всмятку

В Internet базовыми протоколами удаленного доступа являются TELNET и FTP (File Transfer Protocol). TELNET – это протокол виртуального терминала (ВТ), позволяющий с удаленных хостов подключаться к серверам Internet в режиме ВТ. FTP – протокол, предназначенный для передачи файлов между удаленными хостами. Для получения доступа к серверу по данным протоколам пользователю необходимо пройти процедуры идентификации и аутентификации. В качестве информации, идентифицирующей пользователя, выступает его имя, а для аутентификации используется пароль. Особенностью протоколов FTP и TELNET является то, что пароли и идентификаторы пользователей передаются по сети в открытом, незашифрованном виде. Таким образом, необходимым и достаточным условием для получения удаленного доступа к хостам по протоколам FTP и TELNET являются имя и пароль пользователя.

Одним из способов получения таких паролей и идентификаторов в Internet является анализ сетевого трафика. Этот анализ осуществляется с помощью специальной программы-анализатора пакетов (sniffer), перехватывающей все пакеты, передаваемые по сегменту сети, и выделяющей среди них те, в которых передаются идентификатор пользователя и его пароль. Сетевой анализ протоколов FTP и TELNET показывает, что TELNET разбивает пароль на символы и пересылает их по одному, помещая каждый символ пароля в соответствующий пакет, а FTP, напротив, пересылает пароль целиком в одном пакете.

Рис. 4.1. Схема осуществления анализа сетевого трафика

У внимательного читателя, наверное, уже возник вопрос, почему разработчики базовых прикладных протоколов Internet не предусмотрели возможностей шифрования передаваемых по сети паролей пользователей. Даже во всеми критикуемой сетевой ОС Novell NetWare 3.12 пароли пользователей никогда не передаются по сети в открытом виде (правда, указанная функция этой ОС не особенно помогает [11]). Видимо, проблема в том, что базовые прикладные протоколы семейства TCP/IP разрабатывались очень давно, в период с конца 60-х до начала 80-х годов, и с тех пор абсолютно не изменились. При этом точка зрения на построение глобальных сетей стала иной. Инфраструктура Сети и ее протоколы разрабатывались исходя, в основном, из соображений надежности связи, но не из соображений безопасности. Мы, пользователи Internet, вынуждены сейчас прибегать к услугам этой устаревшей с точки зрения защищенности глобальной сети. Совершенно очевидно, что вычислительные системы за эти годы сделали колоссальный скачок в своем развитии, существенно изменился и подход к обеспечению информационной безопасности распределенных ВС. Были разработаны различные протоколы обмена, позволяющие защитить сетевое соединение и зашифровать трафик (например, протоколы SSL, SKIP и т. п.). Однако новые протоколы не сменили устаревшие и не стали стандартом для каждого пользователя (за исключением, может быть, SSL, да и то лишь применительно к некоторым Web-транзакциям). К сожалению, процесс перехода на эти протоколы может длиться еще многие годы, так как в Internet централизованное управление сетью отсутствует. А на сегодняшний день подавляющее большинство пользователей продолжают работать со стандартными протоколами семейства TCP/IP, разработанными более 15 лет назад. В результате, как показывают сообщения американских центров по компьютерной безопасности (CERT, CIAC), в последние годы анализ сетевого трафика в сети Internet успешно применяется кракерами, и, согласно материалам специального комитета при конгрессе США, с его помощью в 1993–1994 годах было перехвачено около миллиона паролей для доступа в различные информационные системы.

Как уже неоднократно подчеркивалось, в вычислительных сетях связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. Как правило, такой пакет независимо от используемого протокола и типа сети (Token Ring, Ethernet, X.25 и др.) состоит из заголовка и поля данных. В заголовок пакета обычно заносится служебная информация, необходимая для адресации пакета, его идентификации, преобразования и т. д.; такая информация определяется используемым протоколом обмена. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного уровня может быть помещен в пакет сетевого уровня, а тот, в свою очередь, вложен в пакет канального уровня. Спроецировав это утверждение на сетевую ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) помещен в пакет IP (сетевой уровень), вложенный в пакет Ethernet (канальный уровень). Структура TCP-пакета в Internet выглядит следующим образом:

1. Заголовок Ethernet.

2. Заголовок IP.

3. Заголовок TCP.

4. Данные.

Иерархия протоколов сети Internet в проекции на модель OSI приведена на рис. 4.2.

Рис. 4.2. Иерархия протоколов сети Internet в проекции на модель OSI

Данный рисунок требует некоторого уточнения. Здесь показано, на каких протоколах (TCP или UDP) обычно – по умолчанию – реализованы прикладные службы. Но это отнюдь не означает, что не существует, например, реализаций FTP на базе UDP – в стандартном файле /etc/services в ОС FreeBSD дается перечень возможных реализаций прикладных служб как на основе протокола TCP, так и протокола UDP.

Рассмотрим схему адресации пакетов в Internet и возникающие при этом проблемы безопасности. Как известно, базовым сетевым протоколом обмена в Internet является протокол IP (Internet Protocol). Протокол IP – это межсетевой протокол, позволяющий передавать IP-пакеты в любую точку сети. Для адресации на сетевом уровне (IP-уровне) в Internet каждый хост имеет уникальный 32-разрядный IP-адрес. Для передачи IP-пакета на хост в IP-заголовке пакета в поле Destination Address необходимо указать IP-адрес данного хоста. Однако, как видно из структуры TCP-пакета, IP-пакет находится внутри аппаратного пакета (если среда передачи – Ethernet, IP-пакет находится внутри Ethernet-пакета), поэтому каждый пакет в сетях любого типа и с любыми протоколами обмена в конечном счете посылается на аппаратный адрес сетевого адаптера, непосредственно осуществляющего прием и передачу пакетов в сети (в дальнейшем мы будем рассматривать только Ethernet-сети).

Из всего вышесказанного следует, что для адресации IP-пакетов в Internet кроме IP-адреса хоста необходим еще либо Ethernet-адрес его сетевого адаптера (в случае адресации внутри одной подсети), либо Ethernet-адрес маршрутизатора (в случае межсетевой адресации). Первоначально хост может не иметь информации о Ethernet-адресах других хостов, находящихся с ним в одном сегменте, в том числе и о Ethernet-адресе маршрутизатора. Следовательно, хост должен найти эти адреса, применяя алгоритмы удаленного поиска (о них мы говорили в главе 3). В сети Internet для решения этой задачи используется протокол ARP (Address Resolution Protocol), который позволяет получить взаимно однозначное соответствие IP-и Ethernet-адресов для хостов, находящихся внутри одного сегмента. Это достигается следующим образом: при первом обращении к сетевым ресурсам хост отправляет широковещательный ARP-запрос на Ethernet-адрес FFFFFFFFFFFFh, где указывает IP-адрес маршрутизатора и просит сообщить его Ethernet-адрес (IP-адрес маршрутизатора является обязательным параметром, который всегда устанавливается вручную при настройке любой сетевой ОС в Internet). Этот широковещательный запрос получат все станции в данном сегменте сети, в том числе и маршрутизатор. Получив такой запрос, маршрутизатор внесет запись о запросившем хосте в свою ARP-таблицу, а затем отправит ARP-ответ, в котором сообщит свой Ethernet-адрес. Полученный в ARP-ответе Ethernet-адрес будет занесенв ARP-таблицу, находящуюся в памяти операционной системы на запросившем хосте и содержащую записи соответствия IP-и Ethernet-адресов для хостов внутри одного сегмента. Отметим, что в случае адресации к хосту, расположенному в той же подсети, также используется ARP-протокол, и рассмотренная выше схема полностью повторяется. Как указывалось ранее, при использовании в распределенной ВС алгоритмов удаленного поиска существует возможность осуществления в такой сети типовой удаленной атаки «ложный объект РВС». Анализ безопасности протокола ARP показывает, что, перехватив на атакующем хосте внутри данного сегмента сети широковещательный ARP-запрос, можно послать ложный ARP-ответ, в котором объявить себя искомым хостом (например, маршрутизатором), и в дальнейшем активно контролировать сетевой трафик дезинформированного хоста, воздействуя на него по схеме «ложный объект РВС».

Рассмотрим обобщенную функциональную схему ложного ARP-сервера (рис. 4.3):

Рис. 4.3. Ложный ARP-сервер

1. Ожидание ARP-запроса.

2. При получении такого запроса – передача по сети на запросивший хост ложного ARP-ответа, где указывается адрес сетевого адаптера атакующей станции (ложного ARP-сервера) или тот Ethernet-адрес, на котором будет принимать пакеты ложный ARP-сервер. Совершенно необязательно указывать в ложном ARP-ответе свой настоящий Ethernet-адрес, так как при работе непосредственно с сетевым адаптером его можно запрограммировать на прием пакетов на любой Ethernet-адрес.

3. Прием, анализ, воздействие на пакеты обмена и передача их между взаимодействующими хостами.

Данная схема атаки требует некоторого уточнения. На практике мы столкнулись с тем, что даже очень квалифицированные сетевые администраторы и программисты часто не знают или не понимают тонкостей работы протокола ARP. При обычной настройке сетевой ОС, поддерживающей протоколы TCP/IP, не требуется настройка модуля ARP (нам не встречалось ни одной сетевой ОС, где нужно было бы создавать ARP-таблицу «вручную»), поэтому протокол ARP остается как бы «прозрачным» для администраторов. Необходимо обратить внимание и на тот факт, что у маршрутизатора тоже имеется ARP-таблица, в которой содержится информация об IP-и соответствующих им Ethernet-адресах всех хостов из сегмента сети, подключенного к маршрутизатору. Информация в эту таблицу на маршрутизаторе также обычно заносится не вручную, а при помощи протокола ARP. Именно поэтому так легко в одном сегменте IP-сети присвоить чужой IP-адрес: выдать команду сетевой ОС на установку нового IP-адреса, потом обратиться в сеть – сразу же будет послан широковещательный ARP-запрос, и маршрутизатор, получив такое сообщение, автоматически обновит запись в своей ARP-таблице (поставит Ehternet-адрес вашей сетевой карты в соответствие с чужим IP-адресом), в результате чего обладатель данного IP-адреса потеряет связь с внешним миром (все пакеты, адресуемые на его бывший IP-адрес и приходящие на маршрутизатор, будут направляться им на Ethernet-адрес атакующего). Правда, некоторые ОС анализируют все передаваемые по сети широковещательные ARP-запросы. Например, ОС Windows 95 или SunOS 5.3 при получении ARP-запроса с указанным в нем IP-адресом, совпадающим с IP-адресом данной системы, выдают предупреждающее сообщение о том, что хост с таким-то Ethernet-адресом пытается присвоить себе (естественно, успешно) данный IP-адрес.

Из анализа механизмов адресации, описанных выше, становится ясно: так как поисковый ARP-запрос кроме атакующего получит и маршрутизатор, то в его таблице окажется соответствующая запись об IP-и Ethernet-адресе атакуемого хоста. Следовательно, когда на маршрутизатор придет пакет, направленный на IP-адрес атакуемого хоста, он будет передан не на ложный ARP-сервер, а непосредственно на хост. При этом схема передачи пакетов в этом случае будет следующая:

1. Атакованный хост передает пакеты на ложный ARP-сервер.

2. Ложный ARP-сервер посылает принятые от атакованного хоста пакеты на маршрутизатор.

3. Маршрутизатор, в случае получения ответа на запрос, адресует его непосредственно на атакованный хост, минуя ложный ARP-сервер.

В этом случае последняя фаза, связанная с приемом, анализом, воздействием на пакеты обмена и передачей их между атакованным хостом и, например, маршрутизатором (или любым другим хостом в том же сегменте) будет проходить уже не в режиме полного перехвата пакетов ложным сервером (мостовая схема), а в режиме «полуперехвата» (петлевая схема). Действительно, в режиме полного перехвата маршрут всех пакетов, отправляемых как в одну, так и в другую сторону, обязательно проходит через ложный сервер (мост); в режиме «полуперехвата» маршрут пакетов образует петлю (рис. 4.4). Петлевой маршрут может возникнуть и при рассмотренной ниже атаке на базе протоколов DNS и ICMP.

Рис. 4.4. Петлевая схема перехвата информации ложным АRP-сервером

Однако придумать несколько способов, позволяющих ложному ARP-серверу функционировать по мостовой схеме перехвата (полный перехват), довольно просто. Например, получив ARP-запрос, можно самому послать такое же сообщение и присвоить себе данный IP-адрес (правда, в этом случае ложному ARP-серверу не удастся остаться незамеченным: некоторые сетевые ОС, например Windows 95 и SunOS 5.3, перехватив такой запрос, выдадут предупреждение об использовании их IP-адреса). Другой, значительно более удобный способ – послать ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном сегменте IP-адрес, и в дальнейшем вести работу с данного IP-адреса как с маршрутизатором, так и с «обманутыми» хостами (кстати, это типичная proxy-схема).

Заканчивая рассказ об уязвимостях протокола ARP, покажем, как различные сетевые ОС используют этот протокол для изменения информации в своих ARP-таблицах.

Исследования различных сетевых ОС выявили, что в ОС Linux при адресации к хосту, находящемуся в одной подсети с данным хостом, ARP-запрос передается, если в ARP-таблице отсутствует соответствующая запись о Ethernet-адресе, и при последующих обращениях к данному хосту ARP-запрос не посылается. В SunOS 5.3 при каждом новом обращении к хосту (в том случае, если в течение некоторого времени обращения не было) происходит передача ARP-запроса, и, следовательно, ARP-таблица динамически обновляется. ОС Windows 95 при обращении к хостам, с точки зрения использования протокола ARP, ведет себя почти так же, как и ОС Linux, за исключением того, что периодически (каждую минуту) посылает ARP-запрос о Ethernet-адресе маршрутизатора; в результате в течение нескольких минут вся локальная сеть с Windows 95 без труда берется под контроль ложным ARP-сервером. ОС Windows NT 4.0 также использует динамически изменяемую ARP-таблицу, и ARP-запросы о Ethernet-адресе маршрутизатора передаются каждые 5 минут.

Особый интерес вызвал следующий вопрос: можно ли осуществить данную удаленную атаку на UNIX-совместимую ОС CX/LAN/SX, защищенную по классу B1 (мандатная и дискретная сетевая политики разграничения доступа плюс специальная схема функционирования SUID/SGID процессов), установленную на двухпроцессорной мини-ЭВМ? Эта система является одним из лучших в мире полнофункциональных межсетевых экранов (МЭ) CyberGuard 3.0 (мы тестировали этого «монстра» в 1996 году). В процессе анализа защищенности этого МЭ относительно удаленных воздействий, осуществляемых по каналам связи, выяснилось, что в случае базовой (после всех стандартных настроек) конфигурации ОС защищенная UNIX-система также поражается ложным ARP-сервером (что, в общем, было вполне ожидаемым).

В заключение отметим, что, во-первых, причина успеха данной удаленной атаки кроется не столько в Internet, сколько в широковещательной среде Ethernet, а во-вторых, эта атака является внутрисегментной и представляет для вас угрозу только в том случае, если атакующий находится внутри вашего сегмента сети. Однако не стоит полагать, что из-за этого атака не представляет опасности, так как по статистике нарушений информационной безопасности вычислительных сетей известно, что большинство состоявшихся взломов производилось именно собственными сотрудникам компаний. Причины понятны: осуществить внутрисегментную удаленную атаку значительно легче, чем межсегментную. Кроме того, практически все организации имеют локальные сети (в том числе и IP-сети), хотя далеко не у всех они подключены к сети Internet. Это объясняется как соображениями безопасности, так и отсутствием у организации необходимости такого подключения. И наконец, сотрудникам, знающим тонкости своей внутренней вычислительной сети, гораздо легче осуществить взлом, чем кому бы то ни было. Поэтому администраторам безопасности нельзя недооценивать данную удаленную атаку, даже если ее источник находится внутри их локальной IP-сети.