Информационная безопасность » Удаленные атаки

Переполнение буфера

admin — Mon, 06 Oct 2008 07:18:36 +0000

Способ под названием переполнение буфера (англ. buffer overflow) — это большой отдельный класс атак, основанный на возможности изменить ход исполнения атакуемой программы с помощью специально сформированных некорректных входных данных. Переполнение буфера используется различными зловредными программами и атаками: вирусами, программами повышения полномочий, удаленными атаками на сервера и клиентов. Те специалисты, которые отслеживают появления информационных бюллетеней по безопасности, согласятся, что такие атаки очень актуальны и в настоящее время.
Способ основан на том, что все программы для своей работы используют некоторые данные, получаемые, возможно и не от авторизованных клиентов. Обработкой полученных данных в программе занимается некоторая функция (или метод, если говорить языком объектно-ориентированного программирования). При этом предполагается, что данные, подлежащие обработке, имеют некоторый, заранее предопределенный формат, скажем, введенный пароль состоит не более чем из 15 символов.
Перед обработкой полученные данные (в нашем случае — пароль) будут записаны в некоторую переменную, место памяти которой будет выделено в некотором оперативном пространстве, которое и называется стеком. Не вдаваясь в особенности функционирования стека, скажем, что в нем же хранится и служебная информация, например, адрес возврата исполнения программного кода, куда программа должна будет вернуть управление после завершения работы данной функции (метода) — в нашем случае, после обработки пароля.
А теперь представим, что введенный пароль оказался длиной не 15 символов, а гораздо больше, настолько, что данные, вводимые как пароль, при записи в стек, “затерли” команды возврата управления. В этом случае скорее всего, программа не сможет продолжать исполнение инструкций кода и прекратит работу с сообщением об ошибке.
Если же предположить, что данные, вводимые как пароль, были не бессмысленным набором символов, а тщательно подобранными двоичными байтами, то при возврате управления из функции (метода) вполне можно добиться, чтобы они были интерпретированы программой как корректный код процессора и выполнены компьютером. Тогда получается, что программа анализа пароля (то есть часть программы аутентификации, а следовательно, процесс с достаточно высокими привилегиями), выполнила инструкции, направленные пользователем, который еще не был авторизован (он еще только вводил пароль), возможно, злоумышленником. Естественно, данный пример утрирован. Реально программы аутентификации пишутся без возможностей реализации таких атак, хотя то, что о них ничего не известно, еще не означает, что их нет или не будет через некоторое время. Даже в приведенном нами примере опытные программисты сразу укажут ряд возможностей избежать подобных уязвимостей. Это и проверка данных на соответствие предопределенному размеру перед началом обработки, и корректная обработка исключительных ситуаций, когда программа возвращает код ошибки, и специальное размещение данных в стеке, и т.п. Вся беда заключается в том, что в программах на сотни строк кода, да еще создаваемых различными программистами, не всегда уделяется должное внимание таким подозрительным моментам.
В качестве реального примера приведем сообщение CERT Advisory СА-2001-21 Buffer Overflow in telnetd. Telnetd — это программа-сервер, обеспечивающая работу удаленных виртуальных терминалов. В данном случае результат выполнения функции telrcv сохраняется в буфере фиксированного размера, при этом предполагается, что размер результата меньше, чем размер буфера. Если же результат окажется по размеру большим, даже еще и сформированным специальным образом, то это может привести к сбою в работе сервера (отказ в обслуживании) или выполнению постороннего кода с привилегиями программы telnetd (обычно привилегии root).

Атаки на клиентов: ActiveX, Java и другие

admin — Mon, 06 Oct 2008 07:17:42 +0000

При взаимодействии клиента и Веб-сервера возможен запуск кода и на клиентской стороне; наиболее популярные технологии на сегодняшний день, это Java Virtual Machine и ActiveX. Необходимо сразу осознать, что загружаемый с удаленного сервера код — это набор команд, которые ваш хост (компьютер) будет исполнять, возможно, не информируя вас о результатах. Поэтому и относиться к такому коду следует соответственно. Возможно, мы загружаем этот код с доверенного сервера, но что мы можем, знать о его безопасности? Достаточно ли уверенности, что механизм электронно-цифровой подписи сообщил нам, что код не был модифицирован после того, как его разместил на сервере уполномоченный программист? Возможно, мы считаем, что настройка прав такова, что данный код не сможет получить большие привилегии?
Прежде всего необходимо определиться, что мы хотим от данного кода? Большая часть такого кода в Интернете предназначена для визуализации или озвучивания красивых, в значительной степени рекламных, эффектов при посещении данного сайта. Поэтому необходимо разделять следующее.
□ С какого компьютера (хоста) мы сейчас работаем? Это компьютер в Интернет-кафе, обычная пользовательская рабочая станция или компьютер, выполняющий важную роль в сети либо хранящий конфиденциальную информацию?
□ Что мы делаем? Либо это просто просмотр новых сайтов для удовольствия, либо поиск необходимой информации в Интернете, либо работа с функциональностью удаленного сервера?
Соответственно этому будут актуальны и разные варианты ответов на вопрос о том, что можно позволить загружаемой программе на нашем компьютере. При развлечении на временном, общедоступном компьютере мы можем загружать все что угодно, какое нам дело до последствий? Если мы ищем справочную информацию, то необходимы ли нам сложные, загружающие память и канал эффекты? Ведь мы ищем чаще всего текст. Графические файлы, исполняемые модули и даже видео-аудио клипы можно скачать отдельно и просмотреть позже, возможно, на другом компьютере соответственно поддержку исполнения загружаемого кода можно отключить.
Другой вариант — работа значимого компьютера с сервером, обеспечивающим доставку некоторой функциональности для выполнения задач. Наиболее очевидный пример — обслуживание организацией своих банковских операций на сервере банка. С одной стороны, и на хосте организации находятся важные финансовые сведения, но, с другой стороны, задача может функционировать в режиме тонкого клиента, т. е. все функциональные компоненты для обработки финансовой информации загружаются с сервера банка. В этом случае поддержка загружаемого кода должна быть включена. Но должны быть соблюдены все необходимые меры по обеспечению безопасности:
□ идентификация и аутентификация и клиента и сервера;
□ создание защищенного канала обмена информацией;
□ проверка целостности и авторизованности загружаемого кода;
□ обеспечение настройки прав, с которыми будет работать код;
□ доступность данных для кода и т. п.

Атаки на серверы: CGI и HTTP

admin — Mon, 06 Oct 2008 07:17:14 +0000

Не вдаваясь в подробности функционирования механизма CGI (Common Gateway Interface — Интерфейс Единого Шлюза), скажем, что это набор программ (исполняемых скриптов, интерпретаторов и т. п.), выполняемый на сервере по запросу клиента. Он предназначен обеспечивать динамическое (то есть более гибкое) взаимодействие между удаленным клиентомбраузером и Веб-сервером посредством запуска на серверной стороне приложений, выполняющих задания клиента.
Как и любым другим программам, данному механизму присущ ряд возможных уязвимостей, которые усиливаются тем, что он обслуживает клиентов (пользователей), о которых предварительно ничего не известно, т. е. возможны и потенциальные злоумышленники.
Основные проблемы, связанные с работой CGI, сводятся к тому, что:
□ разработчиком допущены ошибки при написании кода;
□ в коде оставлены преднамеренные люки;
□ злоумышленник получил возможность (права) модифицировать код либо данные, используемые кодом на сервере;
□ злоумышленник получил доступ к интерпретатору с правом исполнения команд.
Наиболее часто встречаются уязвимости, относящиеся к ошибкам на этапе разработки, причем в значительной степени это касается необходимости проверок данных, которые поступают от клиента на обработку программой. Этому вопросу был посвящен отдельный бюллетень CERT — CERT Advisory СА-1997-25 Sanitizing User-Supplied Data in CGI Scripts. В качестве примера возможности реализации атаки приведем CERT Advisory СА-1997-24 Buffer Overrun Vulnerability in Count.cgi cgi-bin Program. В документе говорится о программе count.cgi, которая ведет подсчет посещений Веб-вервера. По причине недостаточной проверки данных, вводимых клиентом, возможно произвести переполнение стека. В результате Count.cgi исполнит команды злоумышленника, наделив их при этом правами доступа, равными правам доступа сервиса httpd в данной системе.
В целом, специальным образом подобранные некорректные (в смысле скорее “неожидаемые разработчиком”) наборы данных представляют собой угрозу, характерную не только для CGI. Известны случаи, когда использование специальных символов (“/”, “.” и ряда других) в URL при обращении к Веб-серверу приводило к совсем иным последствиям, чем это предполагалось разработчиками и администраторами Веб-сервера — от отказа в обслуживании до возможности исполнения зловредного кода с высокими привилегиями. Не будем приводить весь список подобных атак — он довольно однообразен (сформированный особым образом URL — в ответ недокументированная реакция сервера). Остановим внимание специалистов на том вопросе, что, обеспечивая защиту своих Веб-серверов, например, с помощью межсетевых экранов, необходимо уделять внимание не только правильной адресации и обращению к службам, но и тому, какие данные получает конкретное приложение. Другими словами, строя защиту, необходимо в анализе угроз подниматься от сетевого и транспортного уровня сетевой модели — вверх до прикладного.

Атаки на маршрутизацию

admin — Mon, 06 Oct 2008 07:16:42 +0000

Возможно, читатель обратил внимание, что иногда в сфере интересов злоумышленника находится не только собственно хост жертвы, но и некоторые промежуточные узлы. В связи с этим рассмотрим еще один класс атак — атаки на маршрутизацию пакетов. Довольно часто для достижения атакующим пакетом хоста-жертвы может существовать альтернативный путь, либо путь, игнорирующий и изменяющий правила доступа к хосту-жертве. Кроме того, сам хост-жертва может по-разному реагировать на пакеты, поступившие различными путями. В любом из этих случаев в область интересов злоумышленника попадают промежуточные устройства доставки пакетов — маршрутизаторы. Учитывая то, что некоторые организации вместо полноценных межсетевых экранов используют маршрутизаторы с фильтрующими функциями либо без таковых, интерес злоумышленников будет вполне обоснованным.
Наиболее удобным с точки зрения атакующего вариантом будет получение доступа на редактирование таблиц маршрутизации — в этом случае он получает полный контроль над способами направления пакетов данным устройством. Однако получение такого доступа — задача нетривиальная, так как маршрутизаторы обычно находятся под пристальным вниманием администраторов и соответствующим образом защищены.
Одним из вариантов атаки на маршрутизацию без получения доступа к таблицам маршрутизации является возможность, заложенная в IP пакетах и называемая маршрутизацией от источника (англ. source routing). Данная опция позволяет отправителю управлять движением пакета, предоставляя промежуточным шлюзам маршрутизирующую информацию и игнорируя тем самым настройки, определенные администратором сети. При этом возможны два варианта: гибкий (англ. loose source route), когда между двумя соседними адресами в пути маршрутизации может стоять несколько других шлюзов, и жесткий (англ. strict source route), когда два соседних адреса должны находится в сетях, соединенных напрямую. Сама опция состоит из добавления к стандартному IP-заголовку набора из нескольких IP-адресов и указателя смещения, определяющего следующий адрес, который должен быть обработан.

Это свойство дает возможность реализации, например, такой атаки, которая реализуема в некоторых сервисах TCP/IP. Злоумышленник формирует пакет, в котором смещение уже больше длины. Хост назначения, получив пакет, считает маршрут исполненным и формирует пакет ответа, выстраивая обратную цепочку промежуточных узлов и направляя пакет первому хосту в этой цепочке. Поскольку эта цепочка была сформирована злоумышленником, то первым хостом в ней может стоять хост из внутренней сети, на границе которой стоит хост назначения, то есть внутренний хост, достижимый только через внутренний сетевой интерфейс хоста назначения.

Маскировка

admin — Mon, 06 Oct 2008 07:15:40 +0000

Маскировка (англ. masguerading) — общее название для очень большого класса атак, которые заключаются в том, что атакующий выдает себя не за того, кем является на самом деле. Атака, например, использовалась на ранних стадиях развития межсетевых экранов, а в настоящее время может быть использована на маршрутизаторах там, где идентификация и аутентификация производилась только на основе сетевого адреса. Если определенные существенные права присваиваются процессам, инициированным рядом доверенных хостов (то есть пакеты, с адресом источника, входящим в список доверенных, пропускаются без применения к ним ограничивающих правил, и инструкции в этих пакетах принимаются на получающем хосте к исполнению), то злоумышленнику достаточно указать доверенный адрес отправителя в сформированном деструктивном пакете, и он будет пропущен без ограничения.
Маскировкой можно назвать и случай, когда злоумышленник присваивает себе аутентификационные параметры (идентификатор и пароль) легального пользователя и, таким образом, выдает себя за него. Более сложный вариант — это, например, уязвимость в сервере ключей протокола Kerberos версии 4, которая заключалась в слабом генераторе случайных чисел, что давало злоумышленнику возможность взломать сессионный ключ и благодаря этому стать авторизованным пользователем.
Все рассмотренные случаи атак исходят из того, что, маскируясь, злоумышленник является активным субъектом. Но маскировка может происходить и в пассивном варианте. Например, если злоумышленником был получен доступ на изменение записей на соответствующем DNS-сервере, то он сможет выдать свой хост за HTTP, FTP или другой сервер и ввести в заблуждение пользователей, которые станут к нему обращаться. В этом случае атакующий может разместить на ложном сервере выгодную для себя информацию либо, имитируя приглашение к входу, собирать идентификаторы и пароли пользователей для реальных серверов.
Маскировка под другим названием — подмена (англ. spoofing) — используется тогда, когда атакуемый хост использует для сетевого взаимодействия с другим хостом некоего посредника в качестве поставщика определенного рода справочной информации. Наиболее известный вариант — использование сервера разрешения имен DNS. В определенных случаях злоумышленник, выдавая себя за такой сервер, может произвести успешную атаку вне зависимости от того, насколько хорошо защищены общающиеся между собой хосты или сам сервер. Кратко опишем эту атаку. Как известно, основная задача сервера DNS — предоставить запрашивающему хосту (хосту-жертве) в ответ на имя хоста-назначения сетевой адрес хоста-назначения. Если злоумышленнику удается вместо ответа легитимного DNS-сервера направить хосту-жертве свой ответ, то хост-жертва будет направлять свои пакеты не на адрес хоста-назначения, а на тот адрес, который укажет злоумышленник в своем ложном ответе.
Аналогичного эффекта можно добиться, атакуя и другие протоколы и базы данных, ответственные за сопоставление адресов или имен одного уровня адресам другого уровня — ARP (преобразует IP-адреса в МАС-адреса канального уровня), WINS (преобразует Windows-имена хостов в IP-адреса) и т. д.

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

admin — Mon, 06 Oct 2008 07:15:02 +0000

Атаки на отказ в обслуживании (англ. deny-of-service — DoS) являются одними из самых распространенных. Это связано с тем, что они сводятся к выведению информационного объекта из строя, а не к получению какого-либо вида несанкционированного доступа к нему. Действительно, наиболее примитивный вариант подобной атаки — разрыв сетевого кабеля или физическое разрушение сетевого устройства — не требует от злоумышленника серьезной технической квалификации. Несмотря на некую крайность, тем не менее этот пример хорошо демонстрирует сущность атак: приведение в неработоспособное состояние устройства приема/передачи либо приведение канала передачи информации в состояние невозможности транспортировки данных, т. е. возможны два основных направления реализации подобных атак.
□ Критическая часть информационного объекта, отвечающая за обеспечение доступа к информации, разрушается или приводится в неработоспособное состояние. Ситуация требует дополнительного вмешательства администратора для восстановления работы.
□ Некий контейнер приема/передачи информации подвергается запредельной нагрузке, превышающей его пропускную способность, и не может функционировать до тех пор, пока нагрузка не вернется к нормальной. Ситуация может не требовать дополнительного вмешательства, если такая нагрузка не приводит к повреждению или разрушению контейнера.
Другая классификация атак на отказ в обслуживании носит более подробный технический характер.
□ Перегрузка пропускной способности сети. Атакующий генерирует такое количество сетевого трафика, которое полностью занимает возможности данного сетевого соединения.
□ Перегрузка системного процессора. Атакующий создает вычислительные задания для атакуемого узла, которые превосходят возможности процессорной обработки.
□ Занятие возможных портов. Атакующий устанавливает соединения с имеющимися портами таким образом, что занимает все имеющиеся открытые порты и допустимое количество соединений на порт.
□ Перерасход системных ресурсов (памяти, процессорного времени). Атакующий генерирует либо огромное количество данных, сохраняемых в системной памяти, либо большое количество запросов, на обработку которых уходит практически все процессорное время системы. Этот класс атак опасен тем, что может быть выполнен на каком-нибудь другом (более уязвимом) сервисе этого же компьютера, а приведет в итоге к неработоспособности всех служб.
Соответственно, согласно этой классификации природа атак на отказ в обслуживании разделяется:
□ на формирование некоего специального, возможно, некорректного, запроса информационному объекту, обработка которого приведет к выводу объекта из строя;
□ генерирование ненормально большого количества корректных данных, с обработкой которых не справятся либо канал передачи информации, либо устройство (объект) приема/передачи информации. Первый вид атак связан с определенной технической и интеллектуальной работой злоумышленника, которая заключается в поиске уязвимого параметра информационного объекта, который может быть подвергнут нападению. Такой вид атак наиболее непредсказуем при реализации в первый раз, однако после того как он становится известен производителю, выпускается соответствующее обновление, которое, будучи установленным на объект, решает проблему с данной атакой (по крайней мере на данном объекте), т. е. после установки такого обновления можно с высокой степенью вероятности утверждать, что данная атака больше не достигнет успешного результата.
Второй вид атак не требует специальной подготовки и может быть осуществлен даже случайно. Например, когда пользователь посылает письмо большого объема (атака типа mailbomb) или большое количество писем (атака типа spam), он может серьезно блокировать работу корпоративного почтового сервиса. Такие атаки при соответствующей квалификации администратора легко обнаруживаются и обычно устраняются путем выдачи устройству приема/передачи инструкций по запрету обработки информации от источника атаки.
Так было до тех пор, пока не появился новый вид атак на отказ в обслуживании — распределенный отказ в обслуживании (англ. distributed deny-of-service — DDoS). О ней стоит рассказать подробнее.
Сама атака состоит из нескольких частей. В подготовительной части атаки хост потенциальной жертвы не принимает участия. Злоумышленник набирает некое количество хостов — промежуточных жертв, на которых размещает некое программное обеспечение, вообще говоря, троянскую программу. Способ доставки троянской программы здесь не рассматривается, это может быть и вирус, и обычное письмо с вложением: главная задача злоумышленника на данном этапе — это набрать количество, вне зависимости от того, кто конкретно это будет. После размещения достаточно большого количества программ, в определенное время или по дополнительной команде промежуточные жертвы (которые называются в терминах данной атаки зомби) начинают посылать запросы собственно на основную цель атаки, выполняя таким образом функции инструмента атаки злоумышленника. Запросы на хост-жертву либо представляют из себя реальные корректные запросы от клиентов хоста (например, от браузеров — веб-серверу), либо очень похожи на них таким образом, что атакуемый хост не может отличить ложные запросы от реальных и вынужден расходовать время на их обработку. То, что запросы приходят не от одного источника, затрудняет идентификацию их, как атаки. Большинство рекомендаций по противодействию такой атаке сводятся к увеличению производительности атакуемого хоста путем приостановки на нем второстепенных сервисов и процессов. Также, если возможно по какому-либо параметру отделить ложные запросы от запросов реальных клиентов, необходимо установить соответствующий фильтр на обработку запросов хостом.

Приведем примеры некоторых известных атак.
Атака Ping смерти (Ping-of-death), декабрь 1996. Атака производится на сервис стека сетевых протоколов, отвечающего за работу с протоколом ICMP, частью которого является утилита Ping. Превышение стандартной длины сетевого пакета (в данном случае 65 536 байт) может привести к тому, что соответствующий сервис выйдет из строя и операционная система даст сбой (зависание или перезагрузку). Формирование такого пакета может осуществляться, например, стандартной командой ping операционной системы с указанием в качестве цели адреса хоста-жертвы и размера посылаемого пакета, превышающего стандартный.
Атака потоком SYN запросов (англ. SYNflood), сентябрь 1996. Атака основана на специфике функционирования процесса установления соединения протокола TCP. Для установления соединения с сервером клиент посылает серверу запрос SYN, сервер отвечает подтверждением готовности к установке соединения SYN-ACK и ожидает от клиента согласия на соединение АСК, при получении которого соединение считается установленным и можно передавать данные. Однако, если клиент не ответил пакетом АСК, соединение считается полуоткрытым, и сервер, в зависимости от конфигурации, некоторое время ждет сообщения от клиента. Обычно, если время ожидания указано достаточно большим (а ведь количество соединений, которое может быть установлено с сервером одновременно, — это конечное число), то в такой ситуации может быть достигнуто состояние, когда сервер не может больше принимать запросы на соединение и оказывается фактически недоступным. По истечении установленного времени ожидания, полуоткрытое соединение ликвидируется, однако, если злоумышленник посылает SYN-запросы быстрее, чем истекают тайм-ауты фальшивых соединений, то сервер останется недоступным до тех пор, пока SYN-поток не прекратится. Для некоторых систем переполнение списка текущих соединений может привести к зависанию операционной системы.
Атака обычно сопровождается также и подменой IP-адреса отправителя SYN-запроса — каждый раз в пакет помещается в новое произвольное значение адреса, с тем чтобы на сервере нельзя было предотвратить атаку установкой ограничений на количество одновременных соединений с одного IP-адреса. Атака SYN-flood опасна по следующим причинам:
П потенциально она непреодолима, так как неразрывно связана с идеологией протокола TCP (полумерами могут быть только повышение производительности серверов, увеличение их служебных буферов, и, как следствие, количества поддерживаемых одновременно соединений, а также сокращение времени ожидания ответа клиента до предельно возможной разумной величины — например, 0,2—3 с — в зависимости от характера сетевых маршрутов к клиентам);
П у довольно большой части серверов для создания подобного потока достаточно модемного соединения (30—40 Кбит/с) от злоумышленника, несмотря на то, что сам сервер может быть подключен к Интернету качественным каналом пропускной способностью в несколько Мбит/с.
Атака Smurf. Для полного понимания технического механизма атаки необходимо знание принципов функционирования протокола ICMP (Internet Control Message Protocol — Протокол Управляющих Сообщений Интернета). Не углубляясь в технические подробности, укажем, что одной из функций протокола является выяснение, доступен ли для работы удаленный хост. Выяснение производится выполнением команды операционной системы ping, которая формирует пакет запроса (ICMP echo) с указанием адреса удаленного хоста и обратного адреса, куда присылать ответ. Если удаленный хост получают такой запрос и в состоянии его обработать, он посылает в ответ на обратный адрес пакет подтверждения (ICMP echo reply). Протокол допускает широковещательную рассылку запроса, когда сразу все хосты подсети получают запрос на доступность. Этой возможностью и воспользовались злоумышленники. Атака состояла из трех частей. В первой части (рис. 11.2) атакующий формирует широковещательные запросы на несколько подсетей, однако при этом вместо обратного адреса указывает не свой сетевой адрес, а адрес хоста-жертвы. На втором этапе шлюз промежуточной подсети получает запрос хостам подсети и, если на шлюзе не установлена фильтрация широковещательного ICMP-трафика, то шлюз направляет запросы хостам подсети. Уже в этот момент данная промежуточная подсеть может испытать проблемы с пропускной способностью, когда все работающие хосты подсети направят ответ на запрос по обратному адресу, принадлежащему жертве.
На третьем этапе (рис. 11.3) хост-жертва получит множественные ответы на запросы, которые он не посылал. При достаточном количестве запрошенных подсетей с большим количеством хостов в них, подобный поток ответов приведет к тому, что хост-жертва будет выведен из рабочего состояния.

Вирусы и троянские программы

admin — Mon, 06 Oct 2008 07:11:37 +0000

Как уже указывалось в главе 2, вирусы и троянские программы (трояны) функционально похожи, и многие из зловредных программ в настоящее время несут в себе черты и тех и других, поэтому как пример удаленной атаки рассмотрим их совместно. Теоретически и вирус и троянская программа могут быть примером и локальной атаки (когда злоумышленник сам находится за консолью управления атакуемой системы), но этот случай не так интересен, как удаленная атака “в чистом виде”.
Для того чтобы начать свои деструктивные действия, вирус/троянская программа должны быть доставлены на атакуемый хост, и далее, в зависимости от реализации кода и используемой уязвимости, возможны два варианта развития событий.
□ Внедрение вируса/троянской программы произойдет только после некоторых действий пользователя.
□ Внедрение произойдет автоматически, используя уязвимость одного из работающих сервисов.
На самом деле оба случая довольно трудно различимы, так как даже во втором случае автоматическое срабатывание, возможно, будет вызвано некими действиями (либо, наоборот, бездействием) пользователя за некоторое время до поступления деструктивного субъекта на хост, т. е. например, пользователь неверно сконфигурировал настройки определенной службы либо вовремя не произвел обновление уязвимого модуля, что и послужило причиной успеха атаки. В чистом виде успех атаки совершенно без участия пользователя может быть только в случае серьезной уязвимости в службе, допущенной скорее всего разработчиком при проектировании или реализации службы. Такие атаки встречаются реально не очень часто, но тем не менее возможны.
Большую же часть успешных попаданий вирусов/троянских программ на хост обуславливают соответствующие действия пользователя, поэтому интересны именно такие случаи.
Пользователь может выступать либо активной, либо пассивной стороной. Яркий пример активных действий — ситуация, когда пользователь сам загружает на свой хост программное обеспечение или другой объект, который может скрывать деструктивный код — с дискеты, компакт-диска, по сети. Пассивный вариант действий атакуемого пользователя — он получает предложение от некоего субъекта к загрузке кода (письмо, переданная дискета, диск и т. п.). В этом случае успех или неуспех реализации атаки будет зависеть от того, насколько легкомысленно пользователь отнесется к такой загрузке.
Теперь попробуем еще раз перечислить возможные причины потенциального успеха атаки вируса/троянской программы и дать общие рекомендации (рис. 11.1).
1. Ошибки в работе сервиса. Наиболее сложный вид атак, так как может быть произведен без участия самого пользователя. Решение — быть постоянно осведомленным о новостях по безопасности производителя сервиса, о новостях с основных форумов и он-лайн служб безопасности.
2. Несвоевременное обновление ПО. Различают два вида таких ошибок.
• Несвоевременное обновление соответствующих модулей самого сервиса. Решение — подписка на регулярную рассылку информации об имеющихся обновлениях сервиса.
• Несвоевременное обновление модулей системы защиты сервисов (например, антивирусного программного обеспечения). Решение — приобретать лицензионные системы защиты с соответствующей поддержкой производителем обновления систем.
3. Ошибки в конфигурации. Подобные ошибки довольно трудно предупреждать, так как они требуют серьезной квалификации администратора сервиса. В качестве общей рекомендации можно высказать следующее: не давать сервису в функционировании больше прав и возможностей, чем это нужно для выполнения работы. Скажем, если FTP-сервер предназначен только для публикации материалов, нет необходимости оставлять поддержку команды PUT.
4. Загрузка пользователем постороннего программного обеспечения или других контейнеров зловредных программ (документов и таблиц с макросами, скриптов, компонент и т. п.). Наилучшей рекомендацией в данном случае, конечно, был бы полный запрет на любую загрузку перечисленных объектов, однако по производственной задаче такие загрузки могут быть необходимыми. В этом случае возможны следующие варианты.
• Служба безопасности должна иметь отдельный “полигон” (компьютер или набор компьютеров) для проверки посторонних информационных объектов. На этот “полигон” пользователи соответственно направляют подозрительные или незнакомые информационные объекты.
• Если создание подобного “полигона” невозможно, то его аналог придется создать на своем хосте. Последовательность действий в этом случае такова. Следует обеспечить ограничение распространения возможного ущерба — отключить компьютер от сети. Затем создать учетную запись тестового пользователя с минимальными привилегиями, необходимыми для исследования информационного объекта. При этом особое внимание обратить на то, чтобы права этой учетной записи на доступ к критическим разделам (системные каталоги и файлы, другие важные объекты) были минимальными — скажем, только на чтение, а полный контроль или даже право на запись на жесткий диск имелось бы только для ограниченного (проще всего, одного) каталога, в котором и проводить исследование. Далее, необходимо зарегистрироваться на хосте от имени этого тестового пользователя и получить доступ к исследуемому объекту (переписать его на жесткий диск, вставить дискету и т. д.), произвести его проверку имеющимися средствами защиты — скажем, антивирусным программным обеспечением. Перед запуском исполняемой части объекта на выполнение рекомендуется посчитать и записать все процессы, выполняемые в текущий момент на хосте, с тем чтобы можно было обнаружить новые несанкционированные процессы. Кроме того, если есть возможность, запустить службу аудита — регистрации попыток записи и другой работы с критическими разделами, либо сосчитать и сохранить на независимом устройстве контрольные суммы системных и наиболее важных пользовательских файлов. После этого можно произвести запуск исполняемой части и протестировать ее функциональность, получить и скопировать необходимую информацию и т. д. Затем остановить выполнение модуля и проанализировать имеющиеся результаты (новые процессы, новые и модифицированные файлы на диске, журнал аудита). По указанным источникам можно сделать определенные выводы об опасности или безопасности исследуемого объекта.

Поиск уязвимостей

admin — Mon, 06 Oct 2008 07:04:18 +0000

Поскольку на конкретной машине может быть (и почти всегда бывает) запущено более одного сервиса, то возникает необходимость после поступления пакета в адрес хоста определить, какой из служб он направлен. Эта функция возложена на операционную систему, которая анализирует небольшой числовой параметр транспортного уровня — логический порт, специально размещаемый в пакете отправляющей стороной для этой цели. Так как за распределение пакетов между службами ответственна операционная система, то она же и занимается простейшими служебными сообщениями по поводу того, функционирует ли в данный момент тот или иной логический порт или нет. При этом о некоторых служебных пакетах (например, для протокола TCP о самом первом пакете — SYN — запросе на соединение) операционная система заботится сама. Поэтому удаленный субъект, исследующий систему, всегда имеет возможность получить полную информацию о запущенных на ней службах, даже если потенциально имелась бы возможность их скрывать — например, отвечать на запрос только в том случае, если его аутентичность проверена с помощью криптографической подписи.
За огромным количеством различных служб интернет-сообществом закреплены фиксированные значения логических портов по умолчанию. Например, WWW-сервер, будучи установлен на любой машине, по умолчанию будет ожидать запросов на порт 80. Наиболее известные пары “номер логического порта/служба” для протокола TCP следующие: 21 — FTP, 23 — Telnet, 25 — SMTP, 80 — HTTP, 110 — РОРЗ. Более подробный список приведен в приложении 1.
Например, если такое исследование обнаружило подтверждение установления связи с хостом — потенциальной жертвой по порту 23, то с высокой степенью вероятности можно утверждать, что там функционирует сервис Telnet, который обладает для злоумышленника рядом привлекательных свойств. Например, позволяет выполнять команды в режиме удаленного терминала и не шифрует никакие данные (в том числе и пароли) при передаче. Почему речь идет только о высокой степени вероятности работы сервиса? Потому, что на самом деле хост-жертва может быть лишь приманкой для взломщика (англ. honey-pot), и вместо реального Telnet там функционирует программа-имитатор. Автоматизированные программы поиска уязвимостей разнятся по своей функциональности и назначению. Наиболее простые — это действительно просто сканеры портов, которые последовательно пытаются установить связь с удаленным хостом по имеющемуся списку портов и выдают отчет о выявленных открытых портах. Более проработанные программы могут на основе информации, хранимой в своей базе знаний, пытаться обнаружить параметры, указывающие на то, что та или иная известная уязвимость в конкретной службе не была устранена. Наиболее ужасные (для жертвы) программы могут при обнаружении признаков уязвимости инициировать соответствующую атаку вплоть до ее полного успешного завершения. Необходимо добавить, что такие программы бывают свободно распространяемыми и коммерческими.
Специалист по безопасности должен быть осведомлен о таких программах (их последних модификациях), тем более что независимые эксперты периодически проводят их сравнения по различным параметрам и публикуют результаты в изданиях, посвященных безопасности, в том числе и в Интернете.
До этого момента разговор шел только о наличии работающей службы на атакуемом хосте, но на самом деле очевидно, что успех атаки зависит в значительной степени от того, как реализована работа службы:
□ как написано программное обеспечение, реализующее работу службы;
□ какие настройки работы программного обеспечения установлены.
Указанное означает, что помимо потенциальных ошибок, заложенных в самой природе работы протокола или стандарта, уязвимости могут скрываться в некорректной реализации или настройке, т. е., говоря, например, о FTP-сервере, необходимо отметить не только уязвимость самого протокола FTP, но и то, какое конкретно программное обеспечение поддерживает этот сервер, а также, какие настройки сервера установлены — например, разрешены ли доступ анонимным пользователям или команда PUT.
Составление полного списка известных уязвимостей практически невозможно, поскольку сведения о новых ошибках в реализации и уязвимостях поступают чуть ли не ежедневно. Рассмотрим наиболее известные.
Без сомнения первой широко известной сетевой уязвимостью явилась не-устраненная функция debug в программе приема/отправления электронной почты sendmail, которую использовал знаменитый червь Моррисона. Уязвимость позволяла исполнять код, содержащийся в полученном программой письме. Дата обнаружения уязвимости — ноябрь 1988 года. Одним (но, конечно, не определяющим) из признаков работы программы sendmail на хосте можно считать функционирование сервиса протокола SMTP.
А вот, например, бюллетень об уязвимости в одном из самых популярных современных почтовых серверов Microsoft Exchange 5.5. Бюллетень имеет номер MS02-037 и уведомляет о том, что ошибка в реализации разбора параметров одной из команд протокола SMTP позволяет при некоторых дополнительных условиях выполнить в потоке почтового сервера свой программный код. Это дает возможность получить полное управление над службой почтового сервера и, при неправильно сконфигурированных настройках безопасности Microsoft Windows, над всем компьютером.
Эти два примера приведены, как достаточно разнесенные во времени, но имеющие схожие условия проявления уязвимостей. На наш взгляд, это демонстрирует потенциальную неиссякаемость источников уязвимостей с развитием программного обеспечения, особенно в связи с ориентацией программного обеспечения на предоставление максимального количества услуг и удобства для пользователей.

Выяснение адресов

admin — Mon, 06 Oct 2008 07:03:17 +0000

Известно, что самый надежный корабль — это тот, который стоит на берегу и никогда не выходит в море. Так же и самая безопасная информационная система — это компьютер, не имеющий никаких сетевых соединений, выключенный и запертый в сейф.
Но как только информационная система начинает функционировать, готовиться обмениваться информацией с другими системами (напомним, что пока рассматривается пассивная система, которая сама не инициирует отправку данных куда-либо вовне), она становится уязвимой. В большем или меньшем смысле, для определения этого и существует информационная безопасность. Службы или сервисы, работающие в информационной системе, используют и предоставляют какие-либо информационные ресурсы, которые также могут быть использованы внешним субъектом, в том числе и несанкционированно. Для этого злоумышленнику необходимо иметь данные о том, какие службы/сервисы работают в системе. Но первое, что он должен узнать о самой системе — ее сетевой адрес.
Получение сетевого адреса (IP-адреса) или имени домена/хоста потенциальной жертвы уже дает злоумышленнику информацию, на основе которой он может начинать строить план атаки. Он может получить дополнительно альтернативным путем (без непосредственного обращения к системам жертвы) ряд сведений о ней, например, используя службу WHOIS. Дело в том, что, регистрируясь в Глобальной информационной сети, организация (например, ее провайдер) должна предоставить определенную информацию о себе — название, местоположение, возможно, имена и адреса электронной почты администраторов и т. п. Эту информацию можно найти, обратившись в соответствующую службу Глобальной сети. А это уже может послужить основой для формирования, например, списка типовых паролей на основе имен/фамилий, районов города, где расположена организация, городских телефонов и т. д.
Сетевой адрес — это параметр, уникально идентифицирующий хост в пределах сети (локальной или глобальной), и именно его нужно указывать автоматизированной программе, которая займется сбором информации о службах, запущенных на исследуемой системе.

По характеру взаимодействия с жертвой

admin — Mon, 06 Oct 2008 06:40:01 +0000

Относительно характера взаимодействия злоумышленника с системой все удаленные атаки можно разделить на “интерактивные” и “безусловные”.
□ Интерактивная атака отличается тем, что в ходе ее хотя бы раз возникает ситуация, когда ее дальнейшее успешное продолжение зависит исключительно от того, правильные или неправильные действия предпримет пользователь или администратор атакуемой системы, т. е. приложение интерактивных атак на автоматические станции невозможно. Классическими примерами подобного класса атак является:
• приглашение зайти на определенную страничку в Интернете, в теле которой злоумышленник заблаговременно разместил зловредную програму, автоматически выполняющуюся на компьютере, с которого идет ее просмотр (а ошибок в программном обеспечении (ПО), позволяющих это сделать, на сегодняшний день обнаружено порядка нескольких десятков);
• письмо, с приложенной к нему зловредной программой, но имеющей какое-либо деловое или “соблазнительное” название и описание;
• сообщение, адресованное пользователям якобы от администратора системы с требованием установить на своем компьютере новую антивирусную программу, выложенную им на каком-либо файл-сервере, и которая на самом деле является ни чем иным, как троянской программой.