Защита от хакеров корпоративных сетей
Шрифт:
Приоткрывая завесу
Автоматическое обновление – благо или вред?
Автор будет честен. В слишком многих приложениях реализованы такие опасные вещи, как собственные механизмы автоматического обновления старых версий программы на новые. Хотя это позволяет облегчить внесение исправлений в хамски взломанный код. Централизация процесса обновления программ имеет свои преимущества. Когда была найдена вопиющая брешь в системе защиты AOL Instant Messenger, которая потенциально могла оставить без защиты свыше 50 млн хостов, централизованная архитектура AOL IM позволила устранить угрозу. Благодаря централизованной архитектуре если не удавалось полностью в автоматическом режиме исправить установившую соединение клиентскую программу, то при помощи фильтрации можно было защитить сеть от атакующих сетевых пакетов. Несмотря
Эффект обмана
Атаки фальсификации могут обладать большой разрушительной силой, и не только в компьютерных сетях. Вот что пишет Дорон Гелар (Doron Gellar):
«Взлом израильтянами шифров Египетской армии позволил им дезинформировать Египетскую армию и их военно-воздушные силы. Израильские офицеры отдавали приказы пилотам египетских МиГов сбрасывать бомбы над морем вместо нанесения бомбовых ударов по позициям израильских войск. Если пилот сомневался в правдивости приказа, офицер израильской разведки сообщал пилоту подробные сведения о его семье. В итоге пилот сбрасывал бомбы над Средиземным морем и катапультировался».
Дорон Гелар (Doron Gellar), израильская разведка в войне 1967 года
В рассмотренном примере пилот характеризуется своим «индексом потенциального доверия». Его законное командование, возможно, знало его подноготную, но было уверено, что только оно осведомлено о «персональной энтропии» пилота, о которой никто из посторонних не должен был знать. Израильтяне бросили вызов «персональной энтропии», которая по существу является разделяемым ключом. Тем самым они создали предпосылку для манеры поведения, которая нарушила стандартную процедуру защиты. (Вообще, чем более разрушительным является запрос, тем более высоким должен быть уровень аутентификации, иначе любой может оказаться опасным. Для получения прав суперпользователя должны быть запрошены наиболее полные подтверждения легитимности пользователя.) Пилот был обманут. В этот день израильская разведка вернула на нем все потраченные на нее деньги. Рассмотренные методы доступа к пилоту были совершенны и основаны на звуковой речи. Что пилот мог сделать? Он мог бы потребовать, чтобы с ним по рации переговорила его жена, но ее голос мог быть заранее записан на магнитофон. Будучи достаточно подозрительным, он мог бы потребовать, чтобы его жена затронула тему, о которой могли знать только они вдвоем. В этом случае пилот и его жена могли знать, что голос легко узнать, но его трудно подделать, а тайны брака являются чем-то, что не является общедоступным даже случайно.
В конце концов, обман (атака спуфинга) удался и имел огромные последствия. Возможность фальсификации идентификационных данных имеет огромное методологическое значение, если по разным причинам многое зависит от того, кому доверяют, а фальсификация гарантирует получение к нему доступа. Атака типа грубой силы могла бы вывести радиостанцию пилота из строя и не позволить ему получать легитимные приказы, а эквивалент атаки переполнения буфера мог бы (скорее всего, вряд ли) напугать пилота или вынудить его дезертировать. Спуфинг позволил устранить угрозу для Израиля.
Утонченные фальсификации и экономический саботаж
Основное различие между фальсификацией и использованием уязвимости следующее. Использование уязвимости извлекает пользу из различия между тем, что есть на самом деле, и тем, что только кажется. А фальсификация извлекает пользу из разницы между тем, что кто-то что-то посылает, и тем, кто маскируется под отправителя сообщения. Это различие имеет большое значение, потому что наиболее мерзкие атаки фальсификации основаны на маскировке не только злоумышленника, но и самого факта атаки.
Если пользователи не знают, что стали жертвой атаки злоумышленника, то они обвиняют администраторов в некомпетентности. Если и администраторы ничего не знали об атаке, то они обвиняют производителей… Возможно, что дальше читатель продолжит самостоятельно.
Лестью ничего не достичь
Это не только гипотетическая дискуссия. В 1991 году Microsoft была вынуждена реагировать на достижения операционной системы DR DOS, одного из удачливых клонов операционной системы MS DOS, которая серьезна подрывала позиции компании Microsoft. Грэм Леа (Graham Lea) из популярной технической бульварной малоформатной газеты The Register в прошлом году написал следующее (текст статьи можно
«30 сентября 1991 года Дэвид Кол (David Cole) и Фил Барретт (Phil Barrett) обменялись электронной почтой, в которой говорилось: „Совершенно ясно, что следует обеспечить возможность запуска Windows 3.1 только под управлением MS DOS или ее OEM версии“ и, далее, „следует использовать подход, который позволит обнаружить версию dr 6 и отказать ей в загрузке Windows 3.1. При этом должно выдаваться сообщение типа „Недопустимый интерфейс драйвера устройства (Invalid device driver interface)““.
У компании Microsoft было несколько способов обнаружения и саботирования использования операционной системы DR-DOS, пытающейся загрузить Windows. Один из них был реализован в программном коде под именем Bambi. Этот код был написан Microsoft для утилиты организации дискового кэша SMARTDRV, которая после определения выполняющейся DR-DOS отказывалась загружать Windows 3.1. Также хорошо известна уловка, использовавшаяся в коде AARD, но в настоящее время Caldera занята разбирательством четырех других известных случаев преднамеренной несовместимости программных продуктов. Одно из них связано с версией XMS в программе установки Windows 3.1, которая выдавала сообщение «Установленный вами драйвер XMS несовместим с Windows. Следует удалить его прежде, чем программа установки сможет продолжить инсталляцию Windows». Конечно, для подобной деятельности у компании Microsoft не было никаких оснований.
Возможно, основания все-таки были. Бывший администратор Microsoft Брад Силверберг (Brad Silverberg) достаточно откровенно привел их: «Как вы думаете, что должен делать чувствующий дискомфорт пользователь, если он обнаруживает ошибки, подозревая при этом, что их причиной является DR-DOS? Он идет и покупает MS-DOS. Или решает не рисковать при покупке других машин в офис».
Компания Microsoft действовала явно, открыто давая понять о своем желании помешать совместной работе графической оболочки Windows и операционной системы DR-DOS (действительно, было итоговое сообщение AOL о совместной работе клиентов Instant Messenger). Но поскольку это могло привести к недовольству слишком большого числа пользователей, то они изменили тактику своих действий. Конечно, определенное давление со стороны клиентов вынудило бы Microsoft смягчить свою политику в отношении операционной системы DR-DOS, но реакции пользователей все равно не оказалось бы достаточной для обеспечения совместной работы DR-DOS и Windows. В конечном счете производитель DR-DOS утратил доверие на рынке компьютерных программ и ушел с него в соответствии с планом Microsoft.
Что позволило случиться этому? Прежде всего точным оказался злонамеренный расчет. Прямой отказ компании Microsoft поддержать выполнение операционной системой DR-DOS своих функций мог бы вызвать ряд серьезных вопросов, суть которых сводилась к следующему: каким образом две столь похожие друг на друга системы, как DR-DOS и MS-DOS, в конечном итоге оказались столь несовместимыми? Поэтому компания Microsoft приняла блестящее решение: прямо не отказывая DR-DOS в поддержке, представить DR-DOS невразумительной и ненадежной программой, недостойной претендовать на роль настоящей операционной системы. Действуя таким образом, Microsoft смогла обратить в свою пользу все выдвинутые против компании обвинения в бесстыдстве и завышенной стоимости своих продуктов, переложив ответственность на чужие плечи, причем сделано это было вовсе не для обширных исследований Caldera, которая в конечном счете купила DR-DOS. Информация на этот счет до сих пор не увидела свет. Это была блестящая победа.
Всюду поможет тонкость расчета
Случай с компанией Microsoft предоставил превосходную возможность проникнуть в суть экономически мотивированного саботажа и увидеть его проявления. Распределенные приложения и системы, как, например, информационно-справочные системы продажи билетов, очень трудно проектировать с соблюдением требований масштабируемости. Часто страдает стабильность их работы. Из-за чрезвычайных последствий выхода из строя подобных систем они должны быть проверены на способность противостоять скрытым и недоказуемым атакам, ставящим перед собой цель нарушить стабильность и безопасность систем, которые намериваются эксплуатировать, продавать или администрировать. Успех проверки определяется способностью системы к самообороне. Предположение, что пользователь всегда сможет отличить активную атаку от повседневных отказов систем, по меньшей степени является ложным, если не сказать больше.