Выявление недостатков защиты продуктов при использовании
Каждый день обнаруживаются новые изъяны в безопасности представленных на рынке программных продуктов. Их раскрывают сами клиенты, исследователи (ученые и хакеры) и преступники. Насколько часто – это зависит от известности продукта, упорства исследователей, сложности программы и качества проведенного производителем испытания средств безопасности. Если речь идет о популярной операционной системе, то это случается несколько раз в неделю. В случае малоизвестной программы шифрования прореха обнаруживается лишь однажды за все время ее существования.
Так или иначе, кто-нибудь да находит уязвимые места в системе безопасности. И что дальше?
Существует несколько вариантов его дальнейших действий. Он может сохранять все в тайне и никому не сообщать об этом или поделиться только со своими друзьями. Он может уведомить производителя. Или оповестить своих собственных клиентов, постаравшись не раскрывать ошибку, чтобы только его продукты могли защищать пользователя (мне встречались компании, поступавшие таким образом). Или предать гласности свою находку. (Конечно, он всегда может использовать в преступных целях свои знания об уязвимых местах, но давайте предполагать, что он – честный человек.) Практика предания гласности, известная как полное раскрытие (full disclosure), стала популярна в последние годы. И остается предметом горячих споров.
Но сначала немного истории.
В 1988 году, после того как использование червя Морриса продемонстрировало, насколько легко провести нападение через Интернет, Агентство перспективных исследовательских программ (Defense Advanced Research Projects Agency, DARPA) начало финансирование группы, которая, как предполагалось, будет координировать ответные меры безопасности, повышать уровень осведомленности в вопросах безопасности и вообще делать много полезных вещей. Она называется Группой компьютерной «скорой помощи» (Computer Emergency Response Team, CERT), ее центральное подразделение находится в Университете Карнеги-Меллона в Питсбурге.
Все эти годы CERT действует как центр обмена информацией по вопросам уязвимости систем безопасности. Как и предполагалось, люди сообщают в CERT обо всех обнаруженных ими уязвимых местах. CERT проверяет, действительно ли они существуют, уведомляет об этом производителя и после того, как последний исправит ошибки, публикует подробные сведения о них (и о сделанных исправлениях).
Это хорошо выглядит в теории, но плохо работает на практике. Были три главные претензии к этой системе. Во-первых, CERT медленно проверяла наличие уязвимых мест, поскольку получала множество сообщений и не успевала справляться с работой. Во-вторых, производители не торопились исправлять ошибки, о которых им сообщала CERT, поскольку она не публиковала никакие сведения, прежде чем ошибки были исправлены, и не было необходимости в спешке. И в-третьих, CERT не сразу публиковала сообщения даже после того, как все исправления были сделаны.
Практика полного раскрытия возникла из-за общего разочарования в описанной процедуре. Конференции в Интернете, такие как Bugtraq и NT Bugtraq (организованные в 1993 и в 1997 годах соответственно), превратились в форум для людей, считавших, что производителей извещать бесполезно, а единственный способ повысить безопасность – предавать гласности случаи, когда ее средства оказываются ненадежны. Это была реакция протеста на «башню из слоновой кости», воздвигнутую учеными, хранившими в тайне свои познания. Как писал один хакер: «Теперь обсуждение проблем безопасности не будет ограничено закрытыми списками рассылки так называемых специалистов по вопросам безопасности, и подробности можно будет найти не только в пространных, перегруженных деталями академических статьях. Напротив, информация станет общедоступной, и каждый сможет использовать ее по своему усмотрению».
Сегодня многие исследователи публикуют в конференциях сообщения об обнаруженных ими уязвимых местах, иногда делая также сообщения в печати. Средства массовой информации и компьютерная пресса перепевают в рассылках эти сообщения, обрастающие слухами и домыслами. (Вот почему за прошедшие годы в прессе было так много подобных историй.) Производители стараются «залатать» прорехи в защите сразу, как только они становятся достоянием гласности, поэтому они также могут публиковать сообщения о том, как быстро и тщательно они исправляют ошибки. Системы безопасности совершенствуются намного быстрее благодаря практике полного раскрытия.
В то же время хакеры используют эти рассылки для сбора информации об уязвимых местах и для написания вредоносных программ. Некоторые виды нападений довольно сложны, но те, кто способен разобраться в них, могут составить программы с интерфейсом вида «выбрать и щелкнуть», которые сумеют использовать и все остальные. Это – обратная сторона полного раскрытия, которая может быть истолкована таким образом, что публикация подробностей об уязвимых местах приносит больше вреда, чем пользы, вооружая хакеров средствами для взлома системы. Те, кто придерживается такой точки зрения, считают, что средства безопасности лучше работают, если их уязвимые места не обнажаются перед публикой.
Сторонники полного раскрытия возражают на это, заявляя, что такие представления основаны на далеко не всегда верном предположении, будто сведения об уязвимых местах предает гласности обязательно тот, кто первым их обнаружил. Иногда уязвимые места становятся известны нападающим за месяц или даже год до того, как их обнаружит производитель (эти сведения тайно распространяются в хакерском подполье). Как говорится, пример поучительный. Чем скорее уязвимые места станут общеизвестны и будут исправлены, тем лучше будет всем.
Действительность показывает, что «латание» слабых мест не является решением проблемы; многие системные администраторы не используют «заплаты», сделанные производителями. Многие компании лукавят, заявляя: «Мы выпустили "заплату". Что еще мы можем сделать?» В физическом мире товары с браком часто возвращают продавцу. Но это никогда не случается в компьютерном мире. Даже после того как производитель устраняет ошибки и стихают волнения в прессе, системы так и остаются уязвимыми.
Следующий пример поясняет сказанное. В апреле 1999 года кто-то обнаружил брешь в Microsoft Data Access Components, которая позволяла контролировать удаленную систему Windows NT. Об этом сразу же было сообщено в открытой конференции. Хотя ее модератор утаил от публики подробности этой опасности больше чем на неделю, все же какой-то хакер провел анализ и выяснил детали, которые позволяли использовать уязвимость.
Примерно в то же самое время Microsoft выпустила «заплату», которая должна была препятствовать нападающим в использовании уязвимости пользовательских систем. Microsoft также издала бюллетень по этой теме безопасности и опубликовала несколько других сообщений по вопросам безопасности.
Но «заплата» Microsoft не смогла чудесным образом устранить причину опасности. В тот же год, во время празднования Дня Всех Святых хакеры, воспользовавшись уязвимостью системы, стерли более чем 25 веб-сайтов, основанных на NT, принадлежавших администраторам безопасности, которые не беспокоились (или даже не знали, что следовало побеспокоиться) об обновлении конфигурации в течение шести месяцев.
Вот и все в двух словах.
Microsoft никогда не исправила бы это уязвимое место, если бы не существовал сценарий его использования (exploit script). В других случаях Microsoft заходила так далеко, что или полностью игнорировала проблему, объявляя опасность «чисто теоретической» и поэтому не заслуживающей внимания, или утверждала, что исследователь лжет. Вопросы болевых точек безопасности беспокоят Microsoft лишь в связи с формированием общественного мнения. Когда возникает проблема, компания что-нибудь предпринимает, но редко заранее. Таким образом, огласка сведений об уязвимых местах приводит к их устранению.