Коллектив авторов - Защита от хакеров корпоративных сетей
Подготовка сообщения об уязвимости различных служб (сервисов) является крайне непростым делом, и нужно быть вдвойне внимательным, чтобы не переступить границы дозволенного при сборе информации. Если вы обнаружили проблему, четко опишите, в чем она состоит и при каких обстоятельствах возникает. Пусть детали проблемы выясняют те, кто обеспечивает эти службы. В этом случае вы не сможете ничего случайно повредить и избежите проблем с законом.
Не стоит думать, что производитель волшебным способом предоставит вам средство для устранения уязвимости в течение нескольких часов. Если даже вы сами способны быстро справиться с проблемами собственной системы, производитель должен протестировать внесенные исправления на системах различных конфигураций и на различных платформах. В конце концов, речь идет о его репутации.
Время от времени производитель будет связываться с вами, чтобы уточнить не до конца ясные детали сообщения. Также ему требуется время на изыскание ресурсов для решения проблемы, поэтому реакция может последовать не сразу, если проблема не настолько серьезна, что требует неотложной помощи. После внесения исправлений некоторое время уходит на серьезное тестирование обновленной версии. Только после этого она может быть предложена для использования.
Какие подробности следует опубликовать
После того как вы обнаружили и выявили уязвимость, потребуется определить, какие именно сведения следует включить в сообщение. В основном ваше решение будет зависеть от того, кому вы собираетесь направить сообщение. Но обычно в него входит информация, позволяющая независимо обнаружить и воспроизвести проблемную ситуацию. Самым сложным является вопрос, включать ли в сообщение код, использующий уязвимость.
Публикация кода, использующего уязвимость
Предположим, вы обнаружили уязвимость. Нужно ли обнародовать вместе с описанием проблемы код, использующий уязвимость? На этот сложный вопрос вам придется отвечать самостоятельно.
Создание кода, использующего уязвимость, позволяет другим быстро протестировать систему на ее наличие. Иным способом это сделать сложно. Например, если направить такой код производителю вместе с сообщением, это позволит ему быстрее воспроизвести проблемную ситуацию и начать работу над исправлениями. Кроме того, создание данного кода вынуждает производителя признать существование проблемы. Некоторые производители дешевой продукции отрицают существование любых проблем безопасности, пока вы не докажете обратное.
Обнародование кода, использующего уязвимость, ускоряет разработку производителем исправленной версии, так как отрицать наличие проблемы уже невозможно. С другой стороны, публикуя подобный код, вы даете оружие в руки хакеров. Впрочем, на этот счет имеется еще одно соображение. Если хакер может написать такой код за один день, в то время как системный администратор не имеет на это времени, как вы думаете, кому вы окажете помощь, если не опубликуете его?
Некоторые пользователи при создании такого кода стараются сделать так, чтобы он позволял тестировать систему на наличие проблемы, но не мог бы причинить вреда. Это делается для того, чтобы не дать злоумышленникам готового инструмента для проникновения в чужие системы. Впрочем, эффективность такого подхода не очень велика, так как образец кода легко можно модифицировать, сделав его вредоносным. Другими словами, этот способ создает препятствия только для неопытных хакеров, в то время как человек, обладающий необходимыми знаниями, получит в руки опасное оружие.
С подобным вопросом сталкиваются и многие производители программ для обнаружения уязвимости (security scanners). Они хотят продавать продукт, позволяющий пользователям тестировать систему на наличие уязвимостей, не давая им при этом в руки легкого в применении инструмента взлома. Впрочем, эти производители могут позволить себе роскошь создавать очень «шумные» сканеры, работу которых обнаружит любой, наблюдающий за сетью. В другом положении находятся те, кто публикует сообщение об обнаруженной уязвимости, обычно содержащее исходный код, поскольку опытный хакер может просто убрать из него любой «шум».
Проблемы
Всякое действие имеет последствия. Сообщения об уязвимости не являются исключением. Следует помнить об осложнениях, которые могут возникнуть после обнародования информации о проблемах с безопасностью. Особое внимание нужно обратить на то, как отреагирует производитель на публикацию кода уязвимости.
Реакция производителя
Хотя подобные случаи и очень редки, не стоит забывать о том, что производитель может подать на вас в суд за обнародование сведений о проблемах безопасности в его программном обеспечении. Также существует вероятность, что кто-то из пользователей захочет призвать вас к ответу за ущерб, возникший в результате атаки, осуществленной после публикации вами кода уязвимости.
Некоторые производители могут обвинить вас в нарушении лицензии на ограниченное использование, запрещающей восстановление исходного кода их программ или служб. Другие могут заявить, что вы разгласили коммерческую тайну. Достаточно осторожным нужно быть с технологиями, охраняющимися авторским правом, которые в США особо защищены от восстановления исходного кода законом Digital Millennium Copyright Act (DMCA) (его текст находится по адресу www.loc.gov/copyright/legislation/hr2281.pdf), а также международными договорами. Закон DMCA запрещает публикацию сообщений о проблемах безопасности, потому что это предполагает восстановление исходного кода определенного уровня, нарушение авторских прав и (или) обход шифрования.
Например, фирма Motion Picture Association of America (MPAA) подала в суд на ряд пользователей, исследовавших алгоритмы шифрования универсальных цифровых дисков (Digital Versatile Disk, DVD) и обнаруживших, что они очень слабы и ненадежны. Истца не смутило даже то обстоятельство, что ответчиками были иностранные граждане, на которых не распространяются американские законы.
...Инструментарий и ловушки
Публикация кода, использующего уязвимость, привела в тюрьму: история Дмитрия Склярова
Это дело имеет множество аспектов, например вопрос об обоснованности DMCA и бесполезности шифрования продуктов широкого потребления, которые, являясь крайне интересными, тем не менее выходят за рамки данной главы. Поэтому мы сосредоточимся на рассмотрении способа обнародования сведений об уязвимости и последствий, которые это сообщение имело для его автора.
После выступления в Лас-Вегасе, штат Невада, на конференции DefCon 9 хакеров и экспертов по безопасности, состоявшемся в 2001 году, российский гражданин Дмитрий Скляров был арестован и препровожден в тюрьму за нарушение закона DMCA, запрещающего обход защиты материалов, охраняемых авторским правом. Выступление Склярова было посвящено ненадежности механизма защиты от копирования электронных книг формата eBook фирмы Adobe.
Разумеется, действия суда имели определенные основания, поскольку московская фирма ElComSoft, сотрудником которой являлся Скляров, выпустила в продажу программу, позволяющую преодолевать механизмы защиты от копирования, что дало возможность потребителям создавать полноценные копии приобретенных ими электронных книг. Однако эта программа была разработана в России, на территории которой восстановление исходного кода является совершенно законным. И фирма Adobe, и ФБР были осведомлены о существовании этой программы и о том, что Скляров будет делать доклад о ней на конференции DefCon 9.
В своем докладе Скляров детально рассмотрел неадекватность механизмов защиты от копирования, используемого фирмой Adobe в eBook. В некоторых из этих механизмов были использованы такие ненадежные шифры, как, например, ROT-13 (о нем шла речь в главе 6). На следующий день после доклада Скляров был арестован агентами ФБР и препровожден в тюрьму, что возмутило сообщество специалистов в области компьютерной безопасности. Через некоторое время фирма Adobe признала, что требование ареста Склярова было ошибкой, и потребовала его освобождения. Однако это заявление не возымело никакого действия на ФБР, и Склярову пришлось просидеть под арестом еще пять месяцев, пока с него не было снято персональное обвинение. На момент написания данной книги работодатель Склярова, фирма ElComSoft, еще находилась под следствием. Самое ужасное в этой истории – то, что из-за абсурдных законов, которые лоббируют защитники интеллектуальной собственности, теперь можно взять под стражу любого, даже иностранного гражданина, если он открыто укажет на уязвимые места в механизмах защиты цифровых данных от копирования. Только время покажет, будут ли в самом деле приняты подобные законы, но даже сейчас нужно вести себя очень осторожно при выявлении уязвимости в некоторых продуктах, если при этом требуется обойти даже несложную схему шифрования.
