После того как вы обнаружили и выявили уязвимость, потребуется определить, какие именно сведения следует включить в сообщение. В основном ваше решение будет зависеть от того, кому вы собираетесь направить сообщение. Но обычно в него входит информация, позволяющая независимо обнаружить и воспроизвести проблемную ситуацию. Самым сложным является вопрос, включать ли в сообщение код, использующий уязвимость.

Публикация кода, использующего уязвимость

Предположим, вы обнаружили уязвимость. Нужно ли обнародовать вместе с описанием проблемы код, использующий уязвимость? На этот сложный вопрос вам придется отвечать самостоятельно.

Создание кода, использующего уязвимость, позволяет другим быстро протестировать систему на ее наличие. Иным способом это сделать сложно. Например, если направить такой код производителю вместе с сообщением, это позволит ему быстрее воспроизвести проблемную ситуацию и начать работу над исправлениями. Кроме того, создание данного кода вынуждает производителя признать существование проблемы. Некоторые производители дешевой продукции отрицают существование любых проблем безопасности, пока вы не докажете обратное.

Обнародование кода, использующего уязвимость, ускоряет разработку производителем исправленной версии, так как отрицать наличие проблемы уже невозможно. С другой стороны, публикуя подобный код, вы даете оружие в руки хакеров. Впрочем, на этот счет имеется еще одно соображение. Если хакер может написать такой код за один день, в то время как системный администратор не имеет на это времени, как вы думаете, кому вы окажете помощь, если не опубликуете его?

Некоторые пользователи при создании такого кода стараются сделать так, чтобы он позволял тестировать систему на наличие проблемы, но не мог бы причинить вреда. Это делается для того, чтобы не дать злоумышленникам готового инструмента для проникновения в чужие системы. Впрочем, эффективность такого подхода не очень велика, так как образец кода легко можно модифицировать, сделав его вредоносным. Другими словами, этот способ создает препятствия только для неопытных хакеров, в то время как человек, обладающий необходимыми знаниями, получит в руки опасное оружие.

С подобным вопросом сталкиваются и многие производители программ для обнаружения уязвимости (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, еще находилась под следствием. Самое ужасное в этой истории

- то, что из-за абсурдных законов, которые лоббируют защитники интеллектуальной собственности, теперь можно взять под стражу любого, даже иностранного гражданина, если он открыто укажет на уязвимые места в механизмах защиты цифровых данных от копирования. Только время покажет, будут ли в самом деле приняты подобные законы, но даже сейчас нужно вести себя очень осторожно при выявлении уязвимости в некоторых продуктах, если при этом требуется обойти даже несложную схему шифрования.

Ошибки в сообщениях Что может случиться, если в сообщении окажутся ошибки? Иногда недостаток времени или ресурсов для тщательного исследования проблемы заставляет делать необоснованные обобщения. Обычно специалисты в области компьютерной безопасности замечают ошибки такого типа, поправляют автора и дополняют его сообщение.

Но предположим, что была сделана серьезная ошибка, и, следовательно, сообщение о проблеме совершенно не соответствует действительности. Однако оно способно вызвать панику среди пользователей соответствующих продукта или службы. В результате вы, а возможно, и фирма, в которой вы работаете, приобретете недобрую славу, а ваши будущие сообщения о проблемах безопасности будут восприниматься скептически. Следовательно, прежде чем обнародовать любые сведения об уязвимости, нужно дважды или даже трижды проверить полученные результаты и убедиться, что ваша информация в высшей степени точна.

Общественное значение Как уже упоминалось, обнародование информации о проблемах безопасности не только позволяет обычным пользователям вовремя позаботиться о средствах защиты, но и дает оружие тем, кто может применить полученные сведения в преступных целях. Впрочем, несложно догадаться, что сохранение подобной информации в секрете вовсе не является гарантией того, что хакеры никогда не обнаружат уязвимое место.

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

Резюме

Когда вы сталкиваетесь с необходимостью сообщить о найденной уязвимости, вам приходится решать множество сложных вопросов. Например, нужно решить, стоит ли делать проблемы безопасности достоянием широкой публики или же достаточно сообщить о них производителю. Что же касается вопроса, стоит ли вообще кого-либо информировать об обнаруженном изъяне, ответ на него вполне однозначен. Долг каждого - донести эти сведения до специалистов в области компьютерной безопасности раньше, чем уязвимое место обнаружат хакеры. Даже если вы не способны на полное исследование уязвимости, по крайней мере следует сообщить о ее существовании.

Концепция полного раскрытия предполагает, что обнародованию подлежат все детали уязвимости. Разумеется, таким способом хакеры получают полную информацию о слабых местах систем, но это также вынуждает производителя быстро выпустить исправленную версию и обратить пристальное внимание на вопросы безопасности. Кроме того, когда пользователи осведомлены о проблемах, обычно повышенным спросом пользуются наиболее защищенные приложения.

Наши попытки понять, кому именно следует направлять сообщение о проблемах компьютерной безопасности, привели к созданию их классификации. Проблемы можно разделить на три основные категории в зависимости от того, в каких продуктах они обнаруживаются: узкоспециализированный (low-profile) продукт или служба; продукт или служба, рассчитанные на широкий круг пользователей (high profile); продукты или службы, работающие на различных платформах. Для каждой из этих трех категорий требуется отдельный подход. В этой главе были рассмотрены процедуры направления производителю сообщения о проблемах безопасности, а такжето, какие сведения следует в него включать. В числе прочего сообщение должно содержать дату и время обнаружения уязвимости, описание конфигурации ваших аппаратных средств и действий, при которых было обнаружено уязвимое место, а также контактную информацию.

Не существует единого мнения по поводу того, стоит ли включать в сообщение код, использующий уязвимость, но в некоторых случаях это, несомненно, имеет смысл. Иногда только таким способом можно привлечь внимание производителя к проблеме и заставить искать пути ее решения.

Сообщение о проблемах безопасности сопряжено с определенным риском, например судебного преследования со стороны производителя, а наличие в нем ошибок может негативно сказаться на вашей репутации.

Конспект

Почему необходимо сообщать о проблемах безопасности

• Долг каждого - сообщать об уязвимостях, так как в противном случае их может обнаружить злоумышленник, который использует свое знание для атаки на чужие системы.

• Не стоит беспокоиться о том, что вам не хватит знаний и навыков для составления исчерпывающего сообщения об уязвимости. Многие будут готовы или помочь вам, или принять на себя выполнение этой задачи.

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

Когда и кому направить сообщение

• Все обнаруживаемые уязвимости можно отнести к одной из трех основных категорий в зависимости от того, в каких продуктах они обнаруживаются: узкоспециализированный (low-profile) продукт или служба, продукт или служба, рассчитанные на широкий круг пользователей (high profile), или же продукты или службы, работающие на различных платформах. В качестве примеров можно привести приложение CD-Ex, почтовый сервис Hotmail и ядро операционной системы Linux соответственно.

• Каждая из этих категорий требует специального подхода к составлению сообщения об уязвимости, соответственно влиянию последней на ресурсы пользователя.

• Сообщение, направляемое производителю, должно содержать как можно более полную информацию. Недостаток сведений затрудняет процесс устранения уязвимости, а в некоторых случаях производитель даже не станет этим заниматься.

Какие подробности следует опубликовать

• Стоит тщательно оценить ситуацию, прежде чем включать в сообщение об уязвимости использующий ее код. Впрочем, в некоторых случаях лишь его обнародование способно заставить производителя признать существование проблемы.

• Сообщение о проблемах безопасности связано с определенным риском, который нужно осознавать. Можно столкнуться с судебным преследованием со стороны производителя. Можно также вызвать панику в рядах обычных пользователей.

• Следует быть особо осторожным при обнародовании способов обхода механизма защиты авторского права, так как в настоящее время эти вопросы не урегулированы окончательно законом.

Часто задаваемые вопросы

Вопрос: Как убедиться, что безопасность моей системы соответствует современным стандартам?

Ответ: Лучше всего подписаться на рассылку Buqtraq, отправив пустое сообщение по адресу bugtraq-listserv@securityfocus.com. После подтверждения подписки вы начнете получать сообщения.

Информацию о проблемах безопасности операционной системы Windows можно получить в рассылке NTBugtraq. Чтобы подписаться на нее, отправьте сообщение по адресу listserv@listserv.ntbugtraq.com. В теле письма должна быть помещена фраза «SUBSCRIBE ntbugtraq Firstname Lastname», где в поле Firstname указывается ваше имя, а в поле Lastname

- ваша фамилия.

Вопрос: Как понять, вызвано ли уязвимостью обнаруженное отклонение от обычной работы системы, если у меня нет времени на проведение детальных исследований? Ответ: Сообщение о неисследованной или сомнительной уязвимости можно отправить в рассылку vuln-dev по адресу vuln-dev@securityfocus.com. Она создана специально для сообщений о потенциальных проблемах безопасности от пользователей, не имеющих времени, желания или навыков самостоятельно исследовать дефект. Для подписки на эту рассылку нужно отправить пустое сообщение по адресу vuln-dev-listserv@securityfocus.com. Затем требуется подтвердить свою подписку. Следует помнить, что, отправляя письмо о потенциальной или неисследованной уязвимости, вы делаете эту информацию достоянием широкой публики.

Вопрос: В процессе проверки моей системы на наличие недавно обнаруженной уязвимости оказалось, что проблема гораздо глубже, чем описано в сообщении. Стоит ли публиковать новую информацию? Ответ: Вероятнее всего, делать этого не стоит. В подобных случаях лучше связаться с автором сообщения и сравнить ваши результаты. Чтобы не умножать число источников информации об одной и той же уязвимости, можно попросить автора внести в свое сообщение дополнения и исправления (разумеется, упомянув про ваш вклад). Если же исходное сообщение было анонимным, имеет смысл опубликовать всю информацию еще раз, дополнив ее новыми сведениями.

Вопрос: Можно ли тестировать на уязвимость чужие системы? (Например, можно ли протестировать на безопасность почтовый сервис Hotmail?) Ответ: В большинстве стран, включая США, противозаконно даже пытаться проникнуть в чужую систему, даже если вас интересует всего лишь степень ее уязвимости. Ведь таким образом можно случайно повредить ее или оставить открытой для атак, а кроме того, получить доступ к конфиденциальной информации. Перед тестированием чужой системы следует получить письменное разрешение на подобные действия. Это разрешение должно быть дано владельцем системы, которую вы планируете «атаковать». Нужно также связаться с человеком, который будет следить за состоянием системы в процессе испытаний и сможет восстановить ее работоспособность после ваших испытаний. Если вы не можете найти человека, который разрешил бы вам протестировать свою систему, можно послать запрос в рассылку vuln-dev. Члены подобных рассылок обычно более благоприятно реагируют на подобные вещи. Что же касается таких сервисов, как почтовая служба Hotmail, их несанкционированное тестирование может даже привести к вашему аресту за нарушение DMCA.

Вопрос: Попытавшись сообщить производителю о проблемах безопасности, я получил ответ, что сначала требуется заключить контракт на обслуживание. Что делать в таких случаях? Ответ: Все равно попытайтесь позвонить в отдел обслуживания клиентов и объяснить, что обнаруженная вами уязвимость может создать проблемы их клиентам. Если это не сработает, попытайтесь найти клиента, у которого имеется контракт на обслуживание. Для подобного поиска можно использовать открытые форумы, посвященные обсуждению соответствующего программного продукта или услуги. Если и эта попытка не увенчается успехом, вы имеете полное право сделать информацию о найденной уязвимости доступной для широкой публики.

Когда и кому направить сообщение | Защита от хакеров корпоративных сетей


Защита от хакеров корпоративных сетей



Новости за месяц

  • Октябрь
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс