Безопасность

Полное или ответственное раскрытие информации: как раскрываются уязвимости безопасности

Полное или ответственное раскрытие информации: как раскрываются уязвимости безопасности

Три недели назад была обнаружена серьезная проблема безопасности в OS X 10.10.4. Это само по себе не особенно интересно.

Уязвимости безопасности в популярных пакетах программного обеспечения обнаруживаются постоянно , и OS X не является исключением. База данных уязвимостей с открытым исходным кодом (OSVDB) содержит не менее 1100 уязвимостей, помеченных как «OS X». Но что интересно, так это то, как эта конкретная уязвимость была раскрыта.

Раскрытие-osvdb-OSX

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

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

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

Полное и ответственное раскрытие информации

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

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

Второе называется ответственным раскрытием или ступенчатым раскрытием. Именно здесь исследователь связывается с поставщиком до того, как уязвимость будет выпущена.

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

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

Раскрытие-osvdb-vuln

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

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

Оказывается, есть веские аргументы для обеих сторон.

Аргументы в пользу ответственного раскрытия

Давайте посмотрим на пример, где лучше было использовать ответственное раскрытие информации.

Когда мы говорим о критически важной инфраструктуре в контексте Интернета, трудно не говорить о протоколе DNS. . Это то, что позволяет нам переводить удобочитаемые веб-адреса (например, .com) в IP-адреса.

Система DNS невероятно сложна, и не только на техническом уровне. В этой системе много доверия. Мы верим, что когда мы вводим веб-адрес, мы отправляемся в нужное место. Там просто много езда на целостность этой системы.

Раскрытие-сервер

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

Дэн Камински является уважаемым исследователем в области безопасности, с большим резюме поиска уязвимостей в известном программном обеспечении. Но он наиболее известен благодаря обнаружению в 2008 году, возможно, самой серьезной уязвимости в системе DNS, когда-либо обнаруженной. Это позволило бы кому-то легко выполнить атаку с отравлением кэша (или подделку DNS) на сервере имен DNS. Более технические детали этой уязвимости были объяснены на конференции Def Con 2008 года.

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

Затронуло несколько основных продуктов DNS, в том числе разработанные Alcatel-Lucent, BlueCoat Technologies, Apple и Cisco. Эта проблема также затронула ряд реализаций DNS, которые поставлялись с некоторыми популярными дистрибутивами Linux / BSD, в том числе для Debian, Arch, Gentoo и FreeBSD.

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

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

Уязвимость DNS Kaminsky в конечном итоге подводит итог суть аргумента в пользу ответственного, пораженного раскрытием. Некоторые уязвимости, такие как уязвимости нулевого дня уязвимость — настолько значительны, что публичное их опубликование нанесет значительный ущерб.

Но есть и веский аргумент в пользу того, чтобы не предупреждать заранее.

Дело для полного раскрытия

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

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

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

Чего хотят продавцы?

Продавцам действительно не нравится полное раскрытие информации.

В конце концов, это невероятно плохой пиар для них, и это подвергает их клиентов риску. Они пытались побудить людей сообщать об уязвимостях ответственно с помощью программ за вознаграждение. Они были исключительно успешными: Google заплатил 1,3 миллиона долларов только в 2014 году .

Хотя стоит отметить, что некоторые компании, такие как Oracle — отговаривать людей проводить исследования безопасности для своего программного обеспечения.

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

Похожие посты
Безопасность

Лучшие 36 сочетаний клавиш для Microsoft Edge и IE 11

Безопасность

Управляйте браузером Firefox с помощью команд «О программе»

Безопасность

Microsoft Security Essentials Бесплатное антивирусное программное обеспечение

Безопасность

Avira Rescue System v16