Содержание
Три недели назад была обнаружена серьезная проблема безопасности в OS X 10.10.4. Это само по себе не особенно интересно.
Обнаружены уязвимости в популярных программных пакетах все время, и OS X не является исключением. База данных уязвимостей с открытым исходным кодом (OSVDB) показывает не менее 1100 уязвимостей, помеченных как «OS X». Но что является Интересно, как именно эта уязвимость была раскрыта.
Вместо того, чтобы сказать Apple и дать им время, чтобы решить проблему, исследователь решил опубликовать свой эксплойт в Интернете, чтобы все могли его увидеть.
Конечным результатом стала гонка вооружений между Apple и хакерами в черной шляпе. Apple пришлось выпустить патч до того, как уязвимость была применена, и хакерам пришлось создать эксплойт до того, как системы риска будут исправлены.
Вы можете подумать, что конкретный метод раскрытия является безответственным. Вы можете даже назвать это неэтичным или безрассудным. Но это сложнее, чем это. Добро пожаловать в странный, запутанный мир раскрытия уязвимостей.
Полное и ответственное раскрытие информации
Существует два популярных способа раскрытия уязвимостей поставщикам программного обеспечения.
Первый называется полное раскрытие. Как и в предыдущем примере, исследователи немедленно публикуют свои уязвимости в открытом доступе, не давая производителям абсолютно никакой возможности выпустить исправление.
Второй называется ответственное раскрытие, или пошаговое раскрытие. Именно здесь исследователь связывается с поставщиком до того, как уязвимость будет выпущена.
Затем обе стороны договариваются о сроках, когда исследователь обещает не публиковать уязвимость, чтобы дать поставщику возможность создать и выпустить исправление. Этот период времени может составлять от 30 дней до года, в зависимости от серьезности и сложности уязвимости. Некоторые дыры в безопасности не могут быть легко исправлены, и для этого требуется полная перестройка программных систем с нуля.
Как только обе стороны удовлетворены созданным исправлением, уязвимость раскрывается и получает номер CVE. Они однозначно определяют каждую уязвимость, и эта уязвимость архивируется онлайн на OSVDB.
Но что произойдет, если время ожидания истечет? Ну, одна из двух вещей. Затем продавец договорится о продлении с исследователем. Но если исследователь недоволен тем, как продавец отреагировал или вел себя, или он считает, что запрос на расширение является необоснованным, он может просто опубликовать его в Интернете без готового исправления.
В области безопасности идут горячие споры о том, какой метод раскрытия является лучшим. Некоторые считают, что единственным этическим и точным методом является полное раскрытие информации. Некоторые считают, что лучше всего дать поставщикам возможность исправить проблему, прежде чем выпустить ее на волю.
Оказывается, есть веские аргументы для обеих сторон.
Аргументы в пользу ответственного раскрытия
Давайте посмотрим на пример, где лучше всего использовать ответственное раскрытие.
Когда мы говорим о критически важной инфраструктуре в контексте Интернета, трудно не говорить о протоколе DNS.
, Это то, что позволяет нам переводить удобочитаемые веб-адреса (например, makeuseof.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 в конечном итоге подводит итог суть аргумента в пользу ответственного, поразительного раскрытия. Некоторые уязвимости — например, уязвимости нулевого дня
— настолько значительны, что их публичное освобождение может нанести значительный ущерб.
Но есть и веский аргумент в пользу того, чтобы не предупреждать заранее.
Дело для полного раскрытия
Выпуская уязвимость в открытую, вы открываете ящик Пандоры, где сомнительные люди могут быстро и легко создавать эксплойты и ставить под угрозу уязвимые системы. Итак, почему кто-то решил сделать это?
Есть несколько причин. Во-первых, поставщики часто довольно медленно реагируют на уведомления безопасности. Эффективно форсируя свою руку, выпуская уязвимость в дикую природу, у них появляется больше мотивации для быстрого реагирования. Хуже того, некоторые склонны не публиковать
тот факт, что они поставляли уязвимое программное обеспечение. Полное раскрытие заставляет их быть честными со своими клиентами.
По-видимому, @PepsiCo не заботится о вульном на их сайте, не принимая незапрошенную помощь. Уже есть сек команды. Я сделаю полное раскрытие
— Белый пакет (@WhitePacket) 4 сентября 2015 г.
Но это также позволяет потребителям сделать осознанный выбор относительно того, хотят ли они продолжать использовать определенную уязвимую часть программного обеспечения. Я думаю, что большинство не будет.
Чего хотят продавцы?
Продавцы действительно не любят полное раскрытие информации.
В конце концов, это невероятно плохой пиар для них, и это подвергает их клиентов риску. Они пытались побудить людей раскрывать уязвимости ответственно с помощью программ за вознаграждение. Они были исключительно успешными: Google заплатил 1,3 миллиона долларов только в 2014 году.
Хотя стоит отметить, что некоторые компании — например, Oracle
— отговаривать людей проводить исследования безопасности своего программного обеспечения.
Но все еще будут люди, которые настаивают на использовании полного раскрытия, либо по философским причинам, либо для собственного развлечения. Никакая багти-программа не может противостоять этому.
