Повне або відповідальне розкриття інформації: як розкриваються вразливості безпеки

Три тижні тому була виявлена серйозна проблема безпеки в OS X 10.10.4. Це саме по собі не особливо цікаво.

Вразливості безпеки в популярних пакетах програмного забезпечення виявляються постійно, і OS X не є винятком. База даних вразливостей з відкритим вихідним кодом (OSVDB) містить щонайменше 1100 вразливостей, позначених як «OS X». Але що цікаво, так це те, як ця конкретна вразливість була розкрита.

Замість того, щоб повідомити Apple і дати їм час для усунення проблеми, дослідник вирішив опублікувати свій експлойт в Інтернеті, щоб всі могли його побачити.

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

Ви можете подумати, що конкретний метод розкриття є безвідповідальним. Ви могли б навіть назвати це неетичним або нерозсудливим. Але це складніше, ніж це. Ласкаво просимо в дивний, заплутаний світ розкриття вразливостей.

Повне і відповідальне розкриття інформації

Існує два популярних способи розкриття вразливостей постачальникам програмного забезпечення.

Перше називається повним розкриттям. Як і в попередньому прикладі, дослідники негайно публікують свої вразливості у відкритому доступі, не даючи постачальникам абсолютно ніякої можливості випустити виправлення.

Друге називається відповідальним розкриттям або ступеневим розкриттям. Саме тут дослідник зв'язується з постачальником до того, як вразливість буде випущена.

Потім обидві сторони домовляються про терміни, коли дослідник обіцяє не публікувати вразливість, щоб дати можливість постачальнику створити і випустити виправлення. Цей період часу може становити від 30 днів до року, залежно від серйозності і складності вразливості. Деякі діри безпеки не можуть бути легко усунені, і для цього потрібне повне відновлення програмних систем з нуля.

Як тільки обидві сторони задоволені створеним виправленням, вразливість розкривається і отримує номер CVE. Вони однозначно ідентифікують кожну вразливість, і ця вразливість архівується онлайн на OSVDB.

Але що станеться, коли час очікування закінчиться? Ну, одна з двох речей. Потім продавець домовиться про продовження з дослідником. Але якщо дослідник незадоволений тим, як продавець відреагував або поводився, або він вважає, що запит на розширення є необґрунтованим, він може просто опублікувати його в Інтернеті без готового виправлення.

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

Виявляється, є вагомі аргументи для обох сторін.

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

Давайте подивимося на приклад, де краще було використовувати відповідальне розкриття інформації.

Коли ми говоримо про критично важливу інфраструктуру в контексті Інтернету, важко не говорити про протокол 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 - відмовляти людей проводити дослідження безпеки для свого програмного забезпечення.

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