S3 Ep95: витік даних, натиск Github і постквантове крипто [Аудіо + текст]

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

ДУГ.  Невиправдані витоки, неслухняний код GitHub і постквантова криптографія.

Все це та багато іншого в подкасті Naked Security.

[МУЗИЧНИЙ МОДЕМ]

Ласкаво просимо в подкаст, усі.

Я Дуг Аамот.

Зі мною, як завжди, Пол Даклін.

Павле, як ти сьогодні?

---

КАЧКА.  Супер-пупер, як завжди, Дуг!

---

ДУГ.  Я супер-дупер радий потрапити на цей тиждень Історія техніки сегмент, тому що...

…ти був там, чоловіче!

Цього тижня, 11 серпня…

---

КАЧКА.  О ні!

Я думаю, що копійка просто впала…

---

ДУГ.  Мені навіть не потрібно називати рік!

11 серпня 2003 року – світ звернув увагу на хробака Blaster, який вразив системи Windows 2000 і Windows XP.

Blaster, також відомий як Lovesan і MsBlast, використовував переповнення буфера і, мабуть, найвідоміший за повідомлення, «Біллі Гейтс, чому ти робиш це можливим? Припиніть заробляти гроші та виправте програмне забезпечення».

Що сталося, Поле?

---

КАЧКА.  Ну, це була епоха раніше, можливо, ми дуже серйозно ставилися до безпеки.

І, на щастя, сьогодні таку помилку було б набагато важче використовувати: це було переповнення буфера на основі стека.

І якщо я правильно пам’ятаю, серверні версії Windows вже створювалися з тим, що називається захист стека.

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

Отже, він має закрити програму-порушник, але шкідливе програмне забезпечення не запускається.

Але цього захисту не було в клієнтських версіях Windows на той час.

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

Ви на 2000? Ви на NT? Ви на XP?

І якщо він помилився, важлива частина системи призведе до збою, і ви отримаєте попередження «Ваша система збирається вимкнутись».

---

ДУГ.  Ха, я їх пам'ятаю!

---

КАЧКА.  Отже, був той побічний збиток, який для багатьох людей був ознакою того, що вас забивають інфекції...

…що може бути ззовні, наприклад, якби ви були просто домашнім користувачем і у вас не було б маршрутизатора чи брандмауера вдома.

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

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

---

ДУГ.  Гаразд, добре, це було близько 20 років тому.

І якщо повернути годинник на п’ять років назад, то саме тоді Слаба почала витікати хешовані паролі. [СМІХ]

---

КАЧКА.  Так, Slack, популярний інструмент для співпраці…

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

І ви уявіть собі: ви натискаєте кнопку з написом «Створити посилання», і це створить якийсь мережевий пакет, у якому, ймовірно, є якийсь JSON.

Якщо ви коли-небудь отримували запрошення на зустріч Zoom, ви знатимете, що в ній є дата, час, особа, яка вас запрошує, і URL-адреса, яку ви можете використовувати для зустрічі, і пароль, і все таке речі – там досить багато даних.

Зазвичай ви не копаєтеся в необроблених даних, щоб побачити, що там є – клієнт просто каже: «Гей, ось зустріч, ось деталі. Ви хочете прийняти / можливо / відмовитися?»

Виявилося, що коли ви робили це за допомогою Slack, як ви сказали, протягом більше ніж п’яти років, у цьому запрошенні були упаковані сторонні дані, які не стосувалися суто самого запрошення.

Отже, не URL, не ім’я, не дата, не час…

…але *хеш пароля користувача, який запрошує* [СМІХ]

---

ДУГ.  Гммммм.

---

КАЧКА.  Я малюк тебе не!

---

ДУГ.  Звучить погано…

---

КАЧКА.  Так, це дійсно так, чи не так?

Погана новина: як це там потрапило?

І як тільки він був там, як він міг уникати уваги протягом п’яти років і трьох місяців?

Фактично, якщо ви відвідаєте статтю про Naked Security і подивіться на повна URL -адреса статті, ви помітите, що в кінці сказано, blahblahblah-for-three-months.

Тому що, коли я вперше прочитав звіт, мій розум не хотів бачити це як 2017 рік! [СМІХ]

Це було з 17 квітня по 17 липня, тому там було багато «17».

І мій розум викреслив 2017 рік як рік початку – я неправильно прочитав його як «з квітня по липень *цього року*» [2022].

Я подумав: «Ого, *три місяці*, а вони не помітили».

І тоді перший коментар до статті був: «Гем [КАШЕЛЬ]. Насправді це було 17 квітня *2017*».

Ось це так!

Але хтось це зрозумів 17 липня [2022], і Slack, до їх честі, виправив це того ж дня.

На кшталт: «Боже, про що ми думали?!»

Тож це погана новина.

Хороша новина полягає в тому, що принаймні це були *хешовані* паролі.

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

Ідея цього двояка.

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

І по-друге, ви не можете попередньо обчислити словник відомих хешів для відомих вхідних даних, оскільки вам потрібно створити окремий словник для кожного пароля *для кожної солі*.

Тож зламати хешовані паролі — непроста вправа.

Зважаючи на це, вся ідея полягає в тому, що вони не повинні бути предметом публічного запису.

Їх перетирають і солять *на випадок* витоку, а не *щоб вони могли* витікати.

Отже, яйце на обличчя Слеку!

Slack каже, що постраждав приблизно один із 200 користувачів, або 0.5%.

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

Отже, все одно змініть свій пароль… Ви також можете.

---

ДУГ.  Гаразд, ми також кажемо: якщо ви не використовуєте менеджер паролів, подумайте про його придбання; і увімкніть 2FA, якщо можете.

---

КАЧКА.  Я думав, тобі це сподобається, Дуг.

---

ДУГ.  Так!

А потім, якщо ви Slack або вам подобається компанія, виберіть a надійний алгоритм хешування та розтягування під час самостійної роботи з паролями.

---

КАЧКА.  Так.

Велика річ у відповіді Slack, і те, чого, на мою думку, не вистачає, полягає в тому, що вони просто сказали: «Не хвилюйтеся, ми не тільки хешували паролі, ми їх також підсолювали».

Моя порада полягає в тому, що якщо ви потрапили в подібне порушення, ви повинні бути готові оголосити алгоритм або процес, який ви використовували для соління та хешування, а також, в ідеалі, те, що називається розтягування, де ви не просто хешуєте підсолений пароль один раз, але, можливо, ви хешуєте його 100,000 XNUMX разів, щоб уповільнити будь-який вид атаки за словником або грубої сили.

І якщо ви вкажете, який алгоритм ви використовуєте та з якими параметрами... наприклад, PBKDF2, bcrypt, scrypt, Argon2 – це найвідоміші з існуючих алгоритмів «розтягнення хешування» пароля.

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

І така відкритість насправді може дуже допомогти.

Slack цього не зробив.

Вони просто сказали: «О, їх посолили і перемели».

Але ми не знаємо, чи вони додали два байти солі, а потім хешували їх один раз за допомогою SHA-1…

…чи вони мали щось більш стійке до злому?

---

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

…у нас є ще одна така історія.

---

КАЧКА.  Так, хтось зараз нібито вийшов у Twitter і сказав: «Не хвилюйтеся, хлопці, нічого страшного. Це було лише для дослідження. Я збираюся написати звіт, виділятися з Blue Alert».

Вони створили буквально тисячі фальшивих проектів GitHub на основі копіювання існуючого законного коду, навмисно вставляючи туди деякі команди зловмисного програмного забезпечення, такі як «зателефонуйте додому для подальших інструкцій» і «інтерпретуйте тіло відповіді як бекдор-код для виконання», і так далі.

Отже, речі, які дійсно можуть завдати шкоди, якщо ви встановите один із цих пакетів.

Дати їм законні імена…

…очевидно запозичення історії комітів справжнього проекту, щоб річ виглядала набагато легальнішою, ніж ви могли б очікувати, якби вона просто з’явилася з: «Гей, завантаж цей файл. Ти знаєш, що хочеш!»

Справді?! Дослідження?? Ми цього ще не знали?!!?

Тепер ви можете заперечити: «Ну, Microsoft, яка володіє GitHub, що вони роблять, щоб людям було так легко завантажувати такий матеріал?»

І в цьому є частка правди.

Можливо, вони могли б зробити краще, щоб захистити шкідливе програмне забезпечення.

Але сказати: «О, у всьому винна Майкрософт» — це дещо надмірно.

На мій погляд, ще гірше сказати: «Так, це справжнє дослідження; це дійсно важливо; ми повинні нагадати людям, що це може статися».

Що ж, [A] ми це вже знаємо, дуже дякую, тому що багато людей робили це раніше; ми отримали повідомлення голосно та чітко.

І [B] це *не* дослідження.

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

Для мене це більше схоже на «велике виправдання», ніж на законну мотивацію для дослідження.

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

---

ДУГ.  Гаразд – ми повернемося до цього та до коментарів читача в кінці шоу, тож тримайтеся.

Але спочатку давайте поговоримо про світлофорі яке відношення вони мають до кібербезпеки.

---

КАЧКА.  Аааа, так! [СМІХ]

Ну, є така річ, яка називається TLP Протокол світлофора.

А TLP — це те, що можна назвати «протоколом дослідження людської кібербезпеки», який допомагає вам позначати документи, які ви надсилаєте іншим людям, щоб дати їм натяк на те, на що ви сподіваєтеся, що вони зроблять (і, що більш важливо, на що ви сподіваєтеся, що вони зроблять * не*) робити з даними.

Зокрема, як широко вони мають його перерозподіляти?

Це щось настільки важливе, що ви можете оголосити про це світові?

Або це потенційно небезпечно, чи потенційно містить деякі речі, які ми поки що не хочемо оприлюднювати… тож тримайте це при собі?

І все почалося з: TLP:RED, що означало «Тримай це при собі»; TLP:AMBER, що означало «Ви можете розповсюдити це у своїй власній компанії або своїм клієнтам, яким, на вашу думку, може терміново це знадобитися»; TLP:GREEN, що означало: «Добре, ви можете дозволити цьому широко поширюватися серед спільноти кібербезпеки».

і TLP:WHITE, що означало: «Ви можете сказати будь-кому».

Дуже корисно, дуже просто: ЧЕРВОНИЙ, БУРШТИНОВИЙ, ЗЕЛЕНИЙ… метафора, яка працює глобально, не хвилюючись про те, яка різниця між «секретно» та «конфіденційно» та яка різниця між «конфіденційно» та «секретно», усі ці складні речі, які потребує багато законів навколо цього.

Що ж, TLP щойно отримав деякі модифікації.

Отже, якщо ви займаєтеся дослідженнями кібербезпеки, переконайтеся, що ви їх знаєте.

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

Отже, TLP:WHITE щойно став TLP:CLEAR, яке, на мій погляд, є набагато кращим словом, оскільки воно говорить: «Ви маєте право використовувати ці дані», і цей намір сформульовано, гм, дуже чітко. (Вибачте, я не втримався від каламбуру.)

І є додатковий шар (тому він трохи зіпсував метафору – тепер це *п’ятиколірний* світлофор!).

Є спеціальний рівень, який називається TLP:AMBER+STRICT, а це означає: «Ви можете поділитися цим у своїй компанії».

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

але TLP:AMBER+STRICT означає, що, незважаючи на те, що ви можете поширювати його у своїй організації, *будь ласка, не повідомляйте своїм клієнтам або замовникам* або навіть людям за межами компанії, яких, на вашу думку, може знадобитися.

Для початку тримайте його в тісній спільноті.

TLP:AMBER, як і раніше, означає: «Добре, якщо ви вважаєте, що вам потрібно повідомити своїм клієнтам, ви можете».

І це може бути важливо, тому що іноді ви можете повідомити своїх клієнтів: «Гей, ми маємо виправлення. Вам потрібно буде вжити деяких запобіжних заходів, перш ніж надійде виправлення. Але оскільки це делікатне питання, ми можемо попросити вас поки що не розповідати світу?»

Іноді занадто рано говорити світу насправді більше на руку шахраям, ніж захисникам.

Отже, якщо ви відповідаєте за кібербезпеку, я пропоную вам піти: https://www.first.org/tlp

---

ДУГ.  А ти можеш читайте більше про це на нашому сайті, nakedsecurity.sophos.com.

І якщо ви шукаєте інше легке читання, забудьте про квантову криптографію… ми переходимо до цього постквантова криптографія, Павло!

---

КАЧКА.  Так, ми вже говорили про це кілька разів у подкасті, чи не так?

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

Іншими словами, замість того, щоб брати 2²⁵⁶ намагається знайти файл із певним хешем, можливо, ви зможете зробити це лише («всього»!) 2¹²⁸ намагається, що є квадратним коренем.

Очевидно, набагато швидше.

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

Отже, замість того, щоб брати, скажімо, 2¹²⁸ днів, щоб зламати [ЗНАЧНО ДОВШЕ, НІЖ ПОТОЧНИЙ ВІК ВСЕСВІТУ], для злому може знадобитися лише 128 днів.

Або ви можете замінити «дні» на «хвилини» або щось інше.

І, на жаль, цей алгоритм логарифмічного часу (наз Алгоритм квантової факторизації Шора)… теоретично це можна застосувати до деяких із сучасних криптографічних методів, зокрема тих, що використовуються для криптографії з відкритим ключем.

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

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

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

І нещодавно вони вибрали чотири алгоритми, які вони готові стандартизувати зараз.

У них круті імена, Дуг, тож я мушу їх зачитати: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON та SPHINCS+. [СМІХ]

Тому вони мають круті імена, якщо нічого іншого.

Але в той же час NIST вирішив: «Ну, це лише чотири алгоритми. Що ми зробимо, так це виберемо ще чотирьох як потенційних другорядних кандидатів, і ми побачимо, чи хтось із них також пройде».

Отже, зараз є чотири стандартизовані алгоритми та чотири алгоритми, які можуть бути стандартизовані в майбутньому.

Або 5 липня 2022 року *було* чотири, і один з них був SIKE, скорочено суперсингулярна інкапсуляція ключа ізогенії.

(Нам знадобиться кілька подкастів, щоб пояснити суперсингулярні ізогенії, тому ми не будемо турбуватися. [СМІХ])

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

Тож, на щастя, незадовго до того, як він був або може бути стандартизований, двоє бельгійських криптографів зрозуміли: «Знаєте що? Ми вважаємо, що ми знайшли спосіб обійти це, використовуючи обчислення, які займають близько години, на досить середньому ЦП, використовуючи лише одне ядро».

---

ДУГ.  Я вважаю, що краще з’ясувати це зараз, ніж після того, як стандартизувати це та випустити в дику природу?

---

КАЧКА.  Дійсно!

Я думаю, якби це був один із алгоритмів, які вже були стандартизовані, їм довелося б скасувати стандарт і придумати новий?

Здається дивним, що протягом п’яти років цього не помічали.

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

Гарне нагадування, що якщо ви *коли-небудь* думали створити власну криптографію...

---

ДУГ.  [СМІЄТЬСЯ] Ні!

---

КАЧКА.  ..попри те, що ми N разів казали вам у подкасті Naked Security: «Не робіть цього!»

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

Отже, це, звичайно, не виглядає добре для цього SIKE алгоритм.

І хто знає, може, його знімуть?

---

ДУГ.  Ми будемо стежити за цим.

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

Грабувати пише:

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

---

КАЧКА.  Так, дякую, RobB, за цей коментар, тому що я вважаю, що важливо бачити обидві сторони аргументу.

Були коментатори, які просто казали: «У чому тут проблема? Це чудово!"

Одна людина сказала, «Ні, насправді, це тестування ручкою хороше і корисне. Будьте раді, що їх тепер викривають, а не піднімають свою потворну голову від справжнього нападника».

І моя відповідь на це така: «Ну, це *насправді* напад».

Просто хтось потім вийшов і сказав: «О, ні, ні. Жодної шкоди! Чесно кажучи, я не пустував».

Я не думаю, що ви зобов’язані погоджуватися на це виправдання!

Але все одно це не тестування на проникнення.

Моя відповідь була дуже простою: «Відповідальні тестери на проникнення діють [A] лише після отримання явного дозволу, а [B] — у межах поведінки, чітко погоджених заздалегідь».

Ви не просто створюєте власні правила, і ми обговорювали це раніше.

Отже, як сказав інший коментатор, це, я думаю, мій улюблений коментар… – сказав Екурб, «Я думаю, що хтось повинен ходити від будинку до будинку і бити вікна, щоб показати, наскільки неефективні дверні замки насправді. Це прострочено. Хтось, будь ласка, перейдіть до цього».

І тоді, на випадок, якщо ви не зрозуміли, що це була сатира, люди, він каже, "Ні!"

---

КАЧКА.  Я розумію, що це гарне нагадування, і я розумію, що якщо ви користувач GitHub, і як виробник, і як споживач, є речі, які ви можете зробити.

Перераховуємо їх в коментарях і в статті.

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

І не просто сліпо споживайте речі, тому що ви здійснили пошук і «здавалося», що це може бути правильний проект.

Так, ми всі можемо навчитися з цього, але чи це насправді вважається навчанням, чи це просто те, чого ми все одно повинні навчитися?

Я думаю, що це *не* навчання.

Це просто *недостатньо високий стандарт*, щоб вважати його дослідженням.

---

ДУГ.  Чудова дискусія навколо цієї статті, і дякую, що надіслав її, Робе.

Якщо у вас є цікава історія, коментар або запитання, яке ви хотіли б надіслати, ми будемо раді прочитати це в подкасті.

Ви можете надіслати електронною поштою tips@sophos.com; ви можете коментувати будь-яку нашу статтю; або ви можете написати нам у соціальних мережах: @NakedSecurity.

Це наше шоу на сьогодні – велике спасибі, що послухали.

Щодо Пола Дакліна, то я Дуг Аамот нагадую вам до наступного разу, щоб…

---

ОБИМ.  Будьте в безпеці!

[МУЗИЧНИЙ МОДЕМ]