Netscape обычно предлагала 1000 долларов (и тенниску в придачу) в награду нашедшему дефект в безопасности своего программного обеспечения. Было выписано всего несколько чеков, однако в 1997 году датский хакер нашел прореху в системе безопасности и потребовал большие деньги. Дело обернулось так, что он не получил своих денег: его описание эффектов, связанных с программными ошибками, позволило инженерам Netscape воспроизвести и устранить их и без его помощи. В 2000 году французский исследователь обнаружил, как взломать систему безопасности смарт-карт СВ (Groupement des Cartes Bancaries). Затем, по сведениям из разных источников, он то ли предложил свои услуги, то ли занялся шантажом. В конечном счете он был арестован и осужден условно.
Безопасность рождается в соперничестве, даже в академических «башнях из слоновой кости». Кто-то предлагает новую схему: алгоритм, протокол, техника; другой взламывает ее; кто-то третий все восстанавливает и т. д. Все превращается в забаву. Но когда дело касается уже выпущенных и используемых систем, это может обернуться мошенничеством. Действительно ли выгода от огласки нападения перевешивает возрастание угрозы со стороны противника, получившего сведения о таких возможностях? (На языке Агентства национальной безопасности это называется «выпуском акций».) Почему компания должна наживаться на работе исследователя? Будет ли компания игнорировать проблему до тех пор, пока исследователь не обнародует данные? Заботит ли самого исследователя реакция публики? В любом случае, как вести себя исследователю?
Этот последний вопрос никогда не имел должного обсуждения. Публикация слабых мест безопасности – это своего рода «атака ради огласки»: исследователь хочет увидеть свое имя в газете. Иногда такие сведения разглашает или консультант по вопросам безопасности, или служащий компании, которая занимается оценкой уязвимости или предлагает средства защиты сети. Это особенно верно, если новость появилась в прессе; сообщение в PR Newswire или Business Wire дорого обходится, и никто не будет этого делать, не будучи уверенным, что затраты окупятся.
Вообще я одобряю практику полного раскрытия и думаю, что она скорее укрепляет безопасность, нежели наоборот. Эта книга, которую могут прочитать как хорошие, так и плохие парни, не представляет угрозы безопасности потому лишь, что в ней описаны методы нападений. Точно так же разглашение сведений о слабых местах не то же самое, что их появление. Производители не беспокоятся об устранении обнаруженных, но неопубликованных ошибок (этим грешит не только Microsoft, мы наблюдаем такое почти в каждой крупной компании), поэтому публикация – первый шаг к ликвидации ошибки. Наказывать того, кто разгласил сведения об ошибках, – все равно, что казнить гонца, принесшего дурные вести. Виноват во всем сам производитель, выпустивший ненадежное программное обеспечение.
Но бывают и исключения из правил.
Во-первых, я против такой огласки, которая, прежде всего, сеет панику. Сообщения о слабых местах, о которых нет достаточных свидетельств, очень вредны. (Пример тому – случай, когда кто-то обнаружил переменную, содержащую три буквы NSA, в шифровании API Microsoft[59] и объявил, что Агентство национальной безопасности (National Security Agency) установило лазейку в изделия Microsoft.) Так же плохи сообщения об уязвимых местах в ответственных системах, которые не могут быть легко устранены и знания о которых способны причинить серьезный вред (например, программное обеспечение управления воздушным движением). Я полагаю, что это остается на совести исследователей – определять баланс выгоды от раскрытия уязвимости и связанных с этим опасностей.
Во-вторых, я верю в эффективность предварительного уведомления производителей. CERT впадает в крайность, давая иногда компаниям годы для разрешения проблемы. В результате многие производители не принимают уведомление всерьез. Но если предупреждение о том, что сведения об уязвимых местах будут опубликованы через месяц, исходит от исследователя, то может оказаться, что такое сообщение появится одновременно с объявлением о сделанных исправлениях. Это выгодно каждому.
И в-третьих, я полагаю, что эта практика заходит слишком далеко. Написание научных статей по вопросам уязвимости помогает исследованиям и помогает в разработке систем безопасности. Написание демонстрационного кода – часто необходимая часть исследования. С другой стороны, массовое распространение средств нападения – плохая идея. Создание хакерских инструментов с интерфейсом «выбрать и щелкнуть», которые может использовать каждый начинающий хакер, не приводит ни к чему хорошему. Эта тенденция помогает преступникам и делает вычислительные сети менее безопасными. Она не решает проблему, а создает новые.
59
Программный интерфейс шифрования Crypto API, обеспечивающий шифрование и передачу электронной подписи для приложений независимых производителей. – Примеч. ред.