Шахрайство з криптовалютами

Децентралізовані платіжні системи (більш широко відомі як криптовалюти), які ще 10 років тому були екзотикою, наразі рішуче домінують на шпальтах престижних видань. Для всіх, хто хоч трохи розуміється на криптографії, очевидно, що так чи інакше ідеї децентралізації обміну цінностями, підкріплені сучасними технологіями, — це майбутнє світової економіки. Суперечки точаться хіба що навколо того, яку форму матимуть ти з них, що витримають випробування часом та задовольнять вимоги найширшої аудиторії користувачів. Отже, з Біткойном, чи без, на блокчейні, чи ні, в майбутньому світові фінансові системи — це, скоріш за все, крипта. Залишаючи поки що у спокої тотальну неготовність широкого загалу користуватися новими платіжними засобами, хочу поговорити про справжній економічний бум, що відбувся на тлі розвитку криптовалют у минулому році.

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

Протягом минулого року спільнота навколо криптовалют розрослася настільки, що розпочалася найсправжнісінька золота лихоманка. Багато хто чув про майнинг та яка це вигідна справа. Насправді, справжні гроші крутяться не в майнингу, адже це фактично сервісна функція мережі (певної криптовалюти), яка просто забезпечує її існування. Справжній капітал заробляли ті, хто створював нові мережі, або відгалуження (форки) вже існуючих мереж, що мають цінність та практичне застосування. Наприклад, криптовалюта Ethereum була розроблена із врахуванням недоліків та неповноти іншого блокчейну — Bitcoin. А Monero — це фактично “колективний” форк своєї першої версії, яка, м’яко кажучи, не сподобалася спільноті, тому була відгалужена та реформована. Прибуток від форків склав у багато разів більше, ніж всі ICO на базі справжніх криптовалют (про це згодом) разом взяті.

Різноманіття криптовалют та їхніх форків вражає, причому кожна версія має своє особливе застосування. Наприклад, є два форки Біткойну: Bitcoin Cash та Bitcoin Gold, які відіграють різні ролі. Або ж є “криптовалюта” Tether, яка прирівняна до 1 долару США та створена виключно для полегшення конвертації койнів в “звичайні” гроші. (Щодо легітимності та подальшої долі Tether, щоправда, зараз є великі сумніви, але приклад тим не менш яскравий).

А що ж з ICO? На базі криптовалют почали з’являтися так звані токени — засоби конвертації різноманітних цінностей у цифровий еквівалент. Спочатку токени створювалися здебільшого для залучення початкового капіталу у певну технологію або організацію, яка надалі планує здійснювати якусь навколо-криптовалютну діяльність. (Схожість термінів IPO, Initial Public Offering та ICO, Initial Coin Offering говорить сама за себе). Важливо відмітити, що ICO можливі як навколо нової криптовалюти, коли її творці таким чином поширюють початкову “грошову масу” та залучають нових користувачів, так і у випадку більш простішої “токенізації” звичайних грошей або інших цінностей, з метою накопичення капіталу та його подальшої інвестиції. Куди? Ось тут починається цікаве.

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

Як бачите, в цій пісочниці панує хаос, тому зорієнтуватися в ситуації непросто. Ризики високі, але й потенційна вигода приваблива, тому тема цікавить дуже багато людей, які не мали ще змоги в ній розібратися. Що ж робити, коли і хочеться і колеться? Коли мова заходить про “інвестиції” в токени, сумлінна людина порадить вам діяти виключно на ваш розсуд та провести достатньо роботи з вивчення предмету інвестицій перед тим, як вкладати гроші. Будь-які заклики інвестувати в той чи інший токен, як це полюбляє робити сумнозвісний Джон Макафі, краще ігнорувати, поки не переконаєтесь в тому, що у проекту може бути майбутнє. Але як це визначити?

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

Більше того, існують засоби перевірки легітимності та успішності ICO, причому не лише під час процесу збору коштів, але й під час їх застосування та здійснення, власне, проектів, під які кошти збиралися. Невеличка команда ентузіастів з проекту ConcourseQ проводить колосальну роботу з агрегації даних вимірювання Due Diligence сучасних ICO та дозволяє нам користуватися цими результатами. Звичайно, для прийняття серйозних інвестиційних рішень, цієї інформації замало, але для розуміння критеріїв успішності та ефективності ICO — цілком достатньо.



Originally published at blog.styran.com on February 2, 2018.

Spectre & Meltdown: покрокове пояснення

Оригінал: https://twitter.com/gsuberland/status/948907452786933762

Інтро

Коли процесор доходить до умовного розгалуження у коді (наприклад, “if”), він намагається передбачити, яку гілку буде обрано в програмі, перш ніж програма сама взнає результат. І він виконує цю гілку заздалегідь — ця функція процесора називається “спекулятивне виконання”.

Ідея полягає в тому, що якщо процесор правильно “вгадає” вибір програми (що усі сучасні процесори роблять досить добре), він вже виконає наступний біт коду до того часу, коли фактично стане відома обрана гілка. Якщо процесор помилиться, виконання “відкотиться” назад і почне виконання правильної гілки.

Що робить процесори такими успішними в прогнозуванні умовного вибору програм, — це збереження даних про попередні операції розгалуження в так званому Буфері історії розгалужень (Branch History Buffer, BHB). По принципу: якщо певна програма обирала шлях A раніше, вона, ймовірно, обере шлях А знову, замість шляху Б, який вона ще не обирала.

Цікаво, що код виконується “спекулятивно”, до того, як результат умовного розгалуження буде завершено. Це умовне розгалуження може бути критично важливим для безпеки. На щастя, процесори (в основному) досить розумні, щоб “відкотити” назад будь-які побічні ефекти спекулятивного виконання.

Але існує два важливих винятки з цього “відкочування” побічних ефектів: кеш пам’яті та сама історія розгалужень (BHB). Ці дані, як правило, не відкочуються назад, оскільки спекулятивне виконання має на меті збільшення продуктивності процесора, а відкочування кеш-пам’яті та вмісту BHB, шкодить продуктивності.

Існує три способи експлуатації цієї поведінки. У документі Spectre описано перші дві експлойти з наступними результатами:

  1. Розкриття пам’яті ядра користувацькому процесу на “залізі”.
  2. Розкриття пам’яті ядра хоста віртуальної машини (гіпервізора) процесу в “ядрі” віртуальної машини.

Атака #1

Перший експлойт працює, змушуючи ядро виконати деякий ретельно підготовлений зловмисником код, який містить перевірку обмежень масиву, а потім читає цей масив, причому індекс читання контролюється зловмисником. Це звучить як зухвала ідея, але це не так завдяки JIT (Just in Time compiling).

В Linux, Extended Berkley Packet Filter (eBPF) дозволяє користувачам записувати фільтри сокетів з режиму користувача, які компілюються ядром JIT, щоб ефективно фільтрувати пакети на сокеті. Подробиці неважливі, але це означає, що зловмисник може виконати код на рівні ядра.

Експлойт передбачає написання коду eBPF, який виконує наступні кроки:

  1. Виділяє два масиви фіксованого розміру
  2. Перевіряє наданий користувачем індекс на входження в масив 1
  3. Якщо все ОК, здійснює читання масиву 1 по цьому індексу
  4. Обчислює другий індекс з одного біту отриманого результату
  5. Читайте по другому індексу з масиву 2

Насправді, є ще один крок 4.5, який здійснює граничну перевірку другого індексу по читанню, але ми не маємо наміру робити читання за рамками масиву 2, тому це не має значення.

З точки зору “реального” виконання, цей код завжди обривається на кроці 2, коли/якщо користувач передає індекс за межами масиву 1. Але якщо процесор-“провидець” припускає, що перевірка буде успішною, він спекулятивно виконає читання з-поза меж архіву на кроці 3, та продовжить виконання аж до кроку 5.

Ось що прикольно. На кроці 4 ми беремо значення, яке ми отримали читанням з-поза меж масиву (куди ми, як правило, не маємо доступу), і використовуємо один біт (b) від нього, щоб вибрати конкретну адресу пам’яті (індекс масиву) для читання. Якщо b = 0, то читаємо індекс 0x200; якщо b = 1, то читаємо індекс 0x300.

Це гарантує, що пам’ять, на яку вказує індекс 0x200 або індекс 0x300 буде закешована. Коли процесор усвідомлює, що перевірка обмежень на кроці 2 провалилася, він “відкочується” назад до цього розгалуження, щоб продовжити виконання правильної гілки. Однак дані з кроку 5 все ще знаходяться в кеші!

Потім ми можемо піти й прочитати дані в 0x200 та 0x300 та пересвідчитися, що вони кешуються, вимірюючи швидкість читання. Щойно ми взнаємо, який індекс було закешовано, ми можемо безпосередньо визначити один біт з пам’яті ядра, виходячи з вибору індексу на кроці 4.

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

Атака #2

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

Виконавши ретельно відібрану послідовність непрямих переходів (indirect jumps), зловмисник може заповнити історію прогнозування розгалужень таким чином, що він зможе вибирати, яку гілку буде спекулятивно виконано під час виконанні непрямого переходу.

Це може бути дуже круто. Якщо я знаю, що в коді ядра є фрагмент коду, який демонструє поведінку, подібну до нашого прикладу з eBPF вище, і я знаю, яка в цього коду адреса, я можу непрямо перейти до цього коду, і процесор спекулятивно виконає його.

Якщо ви маєте досвід експлуатації вразливостей такого класу, ви, ймовірно, впізнаєте в цьому дещо подібне до ROP-гаджета (Return-Oriented Programming gadget). Ми шукаємо послідовність коду в просторі ядра, що має правильну послідовність інструкцій, щоб отримати витік інформації через кеш.

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

Ви також помітите, що нам потрібно знати адресу цільового коду ядра. З KASLR (Kernel Address Space Layout Randomization) це не так просто. Цей блог Project Zero пояснює, як можна перемогти KASLR, використовуючи прогнозування розгалужень та кешування як побічний канал, тому я не буду вдаватися до опису деталей: https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Надзвичайно круто те, що це працює поза межами віртуальних машин. Замість традиційного непрямого переходу (наприклад, jmp eax) ми можемо використовувати команду vmcall, щоб спекулятивно виконувати код в ядрі хоста VM (гіпервізору) таким же чином, як і в ядрі нашої ​​VM.

Атака #3

Нарешті, є третій підхід. Він передбачає атаку очищення та перезавантаження (flush + reload) кешу на пам’ять ядра, подібну до першого варіанту атаки, але не вимагає виконання коду в ядрі — все це можна зробити в режимі користувача.

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

Хитрість полягає в тому, що мікроархітектурна реалізація команди mov містить перевірку рівня привілеїв доступу до сторінки пам’яті, яка сама є інструкцією розгалуження. Процесор може спекулятивно виконувати цю гілку, як і будь-які інші.

Отже, якщо ви можете “обігнати” переривання, ви можете спекулятивно виконати якусь іншу інструкцію, яка завантажує дані в кеш на основі значення, прочитаного з пам’яті ядра. Тепер це стає кеш-атакою, подібною до попередніх трюків.

Власне, це все.

Для повної інформації я рекомендую прочитати ці два документи, а також пости Project Zero, вказані вище.

https://spectreattack.com/spectre.pdf

https://meltdownattack.com/meltdown.pdf

Від себе: #бережіться 🙂


Originally published at blog.styran.com on January 5, 2018.

Хто є хто на ринку кібер-безпеки

Ринок кібер-безпеки, який, за деякими оцінками, наступного року перестрибне об’єм 200 млрд на рік, для більшості населення планети залишається якоюсь містичною таємницею. Коли я спілкуюся на робочі теми з людьми, які не є інсайдерами цієї індустрії, мені нерідко доводиться розвінчувати стереотипи та відверту оману. Тому я спробую підсумувати найбільш популярні міфи про кібер-безпеку як галузь у цьому невеличкому пості.

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

Більше того, кібер-безпека це настільки різнопланова та мінлива галузь, що коли у 2013 році у Національній академії США підняли питання про формалізацію професії із аналогічною назвою, причому не просто так, а на запит Департаменту внутрішньої безпеки (DHS), призначена комісія відповіла відмовою. Аргументувалося це рішення в основному тим, що область знань кібер-безпеки змінюється та розвивається настільки динамічно, що стандартизувати її у вигляді якоїсь статичної професії наразі було б контрпродуктивно.

Продовжуємо. Для багатьох є новиною той факт, що більшість компаній, які надають послуги або розробляють товари з кібер-безпеки, не є зосередженими на цій галузі. Більше того, безпека продуктів та сервісів не є їхнім головним пріоритетом. Це звучить контр-інтуїтивно, але так і є: основні гравці на цьому ринку — це не ІБ-, а ІТ-компанії, які “за інерцією” вийшли на ринок безпеки, користуючись напрацьованими бізнес-стосунками з вже існуючими клієнтами.

Далі, багато хто знає про існування різних інструментів побудови організаційної безпеки, таких як міжнародні та галузеві стандарти, та вважає, що за абревіатурами ISO27001, PCI DSS, HIPAA та GDPR стоять містичні сили, які якимось чином впливають на вимоги безпеки, що компанії застосовують до своїх систем та процесів. Насправді, це не так. Єдина сила, яка рухає організаціями в напрямку захисту їхніх систем, це бюджет. Жодні фреймворки з управління ризиками та регуляторні акти не можуть змусити організацію витратити на безпеку більше, ніж вона собі може дозволити економічно. З іншого боку, ці фреймворки можуть допомогти їй більш ефективно витратити цей бюджет, але не більше.

Наступне, існує протилежна думка, що так званий комплаянс, тобто виконання норм зазначених вище стандартів та законів, не додає безпеки. Ця позиція культивується, зокрема, багатьма спеціалістами з кібер-безпеки та потрапляє в родючий ґрунт нонконформістськи налаштованих спеціалістів з ІТ. Але це невірно. Насправді, і PCI DSS, і GDPR, і навіть КСЗІ/НДТЗІ та інші страшні слова дуже навіть додають в безпеці менеджерам, які відповідають за їх додержання. Відповідність вимогам комплаянсу може позбавити їх серйозної політичної, адміністративної, а деколи навіть кримінальної відповідальності у випадку виникнення у організації гучного зламу чи іншого інциденту кібер-безпеки. Так що, комплаянс — це навіть дуже й дуже безпека, але треба пам’ятати чия і від кого.

Отже, не все так просто та одностайно в області кібер-безпеки. Ті, хто її продає, та навіть ті, хто її споживає, не завжди в ній зацікавлені. Хто ж насправді займається кібер-безпекою, поліпшує її рівень та розвиває її як галузь?

Поряд з постачальниками та споживачами безпеки, які до індустрії кібер-безпеки не мають прямого стосунку, в цій галузі існує таке явище як власне індустрія кібер-безпеки, англійською cyber security industry. Складається воно з таких підрозділів.

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

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

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

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

Власне, це все, що я хотів вам повідомити про “легітимних” гравців на цьому ринку. Тепер ви знаєте в загальних рисах які тут двіжухи та з ким мені доводиться мати справу день у день.


Originally published at blog.styran.com on December 27, 2017.

Ще трохи про хакерів

Раз вже розпочали, то продовжуємо невеличкий лікнеп щодо того, хто є хто в нашій пісочниці.

По-перше, хакери та кібер-злочинці це різні поняття. Завдяки сталому голлівудському стереотипу та неосвіченості медійників, хакерами здебільшого називають людей, які здійснюють злочини з допомогою комп’ютерів та мереж. Це неправильно. Оригінальне значення слова “хакер” в комп’ютерному сенсі — це людина, яка докладає неабияких зусиль, знань та навичок задля розв’язання складної проблеми. Коли йдеться про безпеку, то узагальнити можна так: хакери вивчають системи та намагаються використати їх у спосіб, який не передбачався творцями цих систем. Отже, хакер — це комбінація експертних знань, наполегливості, та творчого підходу.

По-друге, хакери бувають не “білі” та “чорні”. Коли людей розрізняють по кольору, це називається расизм. Натомість, хакери “носять” різнокольорові капелюхи: білі, чорні та сірі. Розібратися хто є хто у цих капелюхах дуже просто. Вайтхети зламують системи легально та з етичних міркувань. Блекхети зламують системи нелегально та з неетичних міркувань. Грейхети — це буквально сіра зона, в якій дії диктуються міркуваннями етики, але не завжди і не скрізь вміщуються в рамки закону. Чому все ж таки різнокольорові капелюхи а не хакери? Тому що, зважаючи на ситуацію, контекст та настрій, одна і та сама людина може виконувати дії, які можуть бути або легальними (вдень на роботі здійснюючи пентест з прямого документального дозволу клієнта) або не дуже (вночі вдома аналізуючи вразливості у веб-сайтах держустанов). І капелюх для цього змінити набагато легше і дешевше, ніж колір шкіри.

По-третє, і блекхети, і вайтхети, і грейхети надалі розгалужуються на цікаву та романтичну таксономію під-видів, але це вже тема окремого дослідження. Скажу лише, що блекота розрізняється за рівнем підготовки, мотивації та доступу до ресурсів. Скажімо, школота хачить щоб похизуватися, та тому що в неї багато часу, але це здебільшого обмежується запуском автоматичних засобів пошуку та експлуатації вразливостей, звідси й термін Script Kiddies. Кібер-злочинці в свою чергу роблять на цьому гроші, тому там не до хизування, адже в андерграунді опсек та анонімність найголовніше, бо вороги скрізь: це не тільки правоохоронці та вайтхети, але й усі інші блекхети. Ну а держави в свою чергу тримають собі в штаті чи на короткому мотузку власних хакерів, які, залежно від того, з якого боку подивитися, можуть носити кожну з перелічених капелюхів, адже питання моралі та законності в міжнародних конфліктах та шпигунстві це дуже складна та невдячна тема.

Якось так. Тепер ви тут всіх знаєте. Бережіться

Про Responsible Disclosure, Full Disclosure, та чому хакери — це добре для кібербезпеки

та чому хакери — це добре для кібербезпеки

Багато хто звернув увагу на вакханалію розкриття вразливостей у системах Українських державних установ, органів самоврядування та підприємств критичної інфраструктури. Якщо ви провели останні тижні на сонячному пляжі або у темній печері, подивіться на крайні пости Sean Brian Townsend та увійдіть у курс справи. Після цього можете повертатися до цього поста.

Отже, хлопці відриваються в форматі Full Dosclosure: знаходять у системі вразливість та повідомляють про неї публічно. Реакція на таку поведінку в суспільстві неоднозначна: власники вразливих систем, звичайно, нервуються, та реагують в міру власної обізнаності з кібербезпеки. Обізнані втирають сльози, зчіпляють зуби, беруть себе в руки, та виправляють вразливість. Необізнані волають на весь інтернет “це провокація”. Зовсім новачки ще й погрожують хакерам у відповідь, очевидно не маючи жодного уявлення про те, що у нас типу свобода слова, а “злам” — це навмисне подолання заходів безпеки, яких у їхньому випадку тупо не існувало. Спеціалісти з безпеки, принаймні ті, хто не просто так називається, а ще й розбирається в темі, майже одностайні: це краще, ніж мовчати, але… Ось тут можуть бути варіанти.

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

В 90-ті, коли інтернет з’явився в усіх цивілізованих країнах, веб перетворився з академічного інструменту в комерційний, а хакінг став масовим захопленням технічно обізнаної молоді, оця сама молодь першою зрозуміла, що інтернет до неї не готовий. Хакери знаходили вразливості пачками, дехто використовував їх для розваг (перші мережеві та веб-черв’яки не були фінансово вмотивованими), дехто перейшов на темний бік та почав тупо рубати з цього бабло. Але вендори, тобто розробники та продавці програм та систем були майже одностайні: вам не слід шукати та використовувати вразливості в наших системах, або ми вас нафіг засудимо, бо у нас є юристи та лобі в конгресі, а у вас — ні. Хакери, як відомо, не дуже полюбляють таке ставлення, тому десь у ті роки з’явився такий собі список розсилки під назвою Full Disclosure, в який зливалися всі публічні звіти про вразливості, причому робилося це здебільшого анонімно.

Десь наприкінці 90’х, початку 2000’х, найбільш просунуті вендори зрозуміли, що стратегія заперечення проблеми відсутності безпеки в їхніх продуктах — не дуже ефективна. Зокрема, вихід Windows XP показав, що вразливості безпеки являють собою екзистенціальну загрозу компанії Microsoft. Адже коли протягом днів після релізу твого флагманського продукту в ньому знаходять вразливість виконання коду на відстані, яка легко перетворюється на мережевого черв’яка, це, м’яко кажучи, не дуже добре. І десь в районі 2002–2003 років Майкрософт, точніше Білл Гейтс, прийняв рішення щось з цим робити. І не самостійно, а з залученням у процес хакерів з таких легендарних команд, як L0pht Heavy Industries, Foundstone, Sysinternals тощо. Останню, до речі, вони зрештою придбали та зробили частиною компанії. Результатом цієї співпраці програмістів, які пишуть програми, та хакерів, які ці програми зламують, було утворення першої методології Secure Development Lifecycle (SDL) та зрештою — розробка першого більш-менш захищеного продукту компанії Microsoft — SQL Server 2005.

Всі ці зрушення призвели до того, що вендори (не всі) зрештою усвідомили (Oracle так і не усвідомив), що з хакерами потрібно співпрацювати. Але правила цієї співпраці вони встановили власноруч, не порадившись з хакерами. І придумали вони таку річ, як Responsible Disclosure, що означало, що першими про вразливість мають дізнаватися вендори, а хто так не робить — той безвідповідальний. І почався багаторічний holy war між прихильниками Responsible та Full Disclosure, який не припиняється й досі, і повірте мені: ані українська Кібер-поліція, ані Херсонська обласна рада не будуть останньою інстанцією у цих дебатах. Це глобальна дискусія, яка напевно триватиме вічно, тому що в Responsible Disclosure є свої вади, такі як гальмування реакції вендора, а Full Disclosure… а FD, — це FD 🙂

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

Бережіться