Рекламное объявление

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

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

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

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

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

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

instagram viewer

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

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

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

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

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

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

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

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

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

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

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

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

Когда мы говорим о критически важной инфраструктуре в контексте Интернета, трудно не говорить о протокол DNS Как изменить свои 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 в конечном итоге подводит итог суть аргумента в пользу ответственного, пошагового раскрытия. Некоторые уязвимости - как уязвимости нулевого дня Что такое уязвимость нулевого дня? [MakeUseOf Объясняет] Подробнее - настолько значительны, что их публичное освобождение может нанести значительный ущерб.

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

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

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

Есть несколько причин. Во-первых, поставщики часто довольно медленно реагируют на уведомления безопасности. Эффективно форсируя свою руку, выпуская уязвимость в дикую природу, у них появляется больше мотивации для быстрого реагирования. Еще хуже, некоторые склонны не публиковать Почему компании, хранящие нарушения в секрете, могут быть хорошими вещамиС таким большим количеством информации в Интернете мы все беспокоимся о возможных нарушениях безопасности. Но эти нарушения могут храниться в секрете в США, чтобы защитить вас. Звучит безумно, так что же происходит? Подробнее тот факт, что они поставляли уязвимое программное обеспечение. Полное раскрытие заставляет их быть честными со своими клиентами.

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

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

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

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

Хотя стоит отметить, что некоторые компании - как Oracle Oracle хочет, чтобы вы прекратили посылать сообщения об ошибках - вот почему это безумиеОракул в горячей воде из-за ошибочной записи в блоге главы безопасности Мэри Дэвидсон. Эта демонстрация того, как философия безопасности Oracle отходит от мейнстрима, не была хорошо воспринята сообществом безопасности ... Подробнее - отговаривать людей проводить исследования безопасности своего программного обеспечения.

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

Мэтью Хьюз - разработчик программного обеспечения и писатель из Ливерпуля, Англия. Его редко можно найти без чашки крепкого черного кофе в руке, и он абсолютно обожает свой Macbook Pro и свою камеру. Вы можете прочитать его блог на http://www.matthewhughes.co.uk и следуйте за ним в твиттере на @matthewhughes.