Статьи

Security Week 43: непрості прості числа, криптографія в HDD, патчі Adobe і Oracle

  1. Прості числа - слабке місце протоколу Діффі - Хеллмана
  2. Численні уразливості у вбудованих системах шифрування жорстких дисків
  3. Черговий набір патчів для Adobe Flash (три уразливості, одна критична) і Oracle Java (154 уразливості (!), 84 серйозні)
  4. Що ще сталося:
  5. Старожитності:

Відкриваючи двері в світ криптографії, будьте обережні! Може вийти так, що закрити не вийде. Звичайно, це збіг, але тільки-но я прийшов до тями від новини минулого тижня про колізії в SHA-1, як тут же виникла тема про злом зашифрованого трафіку, з атакою на протокол Діффі - Хеллмана. Ну, вже за назвою зрозуміло, в чому справа, да? Експерт в області криптографії Брюс Шнайер в травні цього року опублікував гнівний пост про «любительському шифруванні». Відкриваючи двері в світ криптографії, будьте обережні

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

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

Всі епізоди серіалу можна знайти тут .

Прості числа - слабке місце протоколу Діффі - Хеллмана

новина . дослідницька робота .

Цього разу я навіть не буду намагатися пояснювати щось простими словами. Марно. Діффі - Хеллмана - це протокол безпечного обміну ключами для установки зашифрованих зв'язків, які спочатку опублікований в 1976 році. Вітфілд Діффі і Мартін Хеллман (а також деякі інші товариші) одними з перших запропонували вирішення важливої ​​проблеми - як обмінятися ключами для шифрування так, щоб підслуховування сторона не змогла їх перехопити.

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

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

Передбачуваний юзернейм і ненадійний пароль плавають в океані з цифр і букв

Так ось, щоб цей алгоритм дійсно працював і його неможливо було зламати, то найпростіше число, яке передається відкрито, повинно бути Велике і Випадкове. Якщо воно Випадкове, але невелике (наприклад, використовується довжина ключа в 512 біт), то ймовірність злому підвищується. Що і було показано в двох методах атаки, опублікованих дослідниками на початку цього року, - FREAK і Logjam .

Треба розуміти, що знати ключ (то найпростіше число) недостатньо, щоб відразу все взяти і розшифрувати. Але обчислювальна потужність, наприклад, для атаки Logjam потрібна невелика - за допомогою потужностей Amazon EC2 дослідникам знадобилося всього 7,5 години, щоб провести необхідні обчислення, які значно спрощують подальшу розшифровку перехопленого зашифрованого трафіку.

Але то були ключі довжиною 512 біт, які вже давно визнані ненадійними, а з'явилися вони завдяки експортним обмеженням США на стійку криптографію, запровадженими ще у 80-х. Ключі довжиною 1024 біта вважалися надійними, але, як показало нове дослідження групи з 14 криптографов, можливі варіанти. Тут 7,5 години на «Амазон» не обійдешся - потрібні величезна і дуже дорога обчислювальна система і приблизно рік часу. Якби прості числа, використовувані на практиці, дійсно були випадковими, то і це б не допомогло.

На жаль, в реальних імплементації протоколу Діффі - Хеллмана вони недостатньо випадкові. Тобто якась дуже багата організація по імені А (або Н, або Б) може експлуатувати цю невипадковість, побудувати суперкомп'ютер за кілька сотень мільйонів доларів, поганяти його рік і отримати - ні, не шифри, а вихідні дані, які далі вже дозволяють зламувати конкретний трафік порівняно швидко.

В результаті така могутня організація дозволяє зламувати до 66% з'єднань IPSec VPN, 26% підключень через SSH і 18% підключень HTTPS. Судячи з даних з документів, вкрадених Едвардом Сноуденом, бюджет АНБ на експлуатацію вразливостей в мережевих комунікаціях дійсно величезний - $ 1 млрд щорічно. А значить, ймовірність, що там дійсно побудували суперкомп'ютер і дали йому проаналізувати велику кількість перехопленого зашифрованого трафіку, ненульова.

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

І що робити? Так поки нічого. Бажано переконатися, що ваш браузер не використовує зовсім вже слабку версію протоколу DH з 512-бітними ключами (можна виконати тут ). А якогось готового рішення для можливого злому комунікацій з використанням 1024-бітного ключа поки немає. Діффі - Хеллмана використовується у величезній кількості протоколів, тому ось прямо зараз взяти і починають не вийде. За словами Алекса Халдермана, одного з авторів дослідження, на це потрібні роки. Це погані новини. Щодо хороші новини в тому, що це як і раніше Дуже Дорогий Метод злому і таким він залишиться ще дуже довго.

Численні уразливості у вбудованих системах шифрування жорстких дисків

новина . дослідження .

ОК, атаку на протокол Діффі - Хеллмана тривіальної назвати не можна, а ось ця новина показує, як можна значно послабити криптографію через куди більш простих помилок. Автори нового дослідження купили відразу багато зовнішніх жорстких дисків з функцією шифрування даних. Детальне вивчення методів шифрування показало, що способів зламати захист там, м'яко кажучи, чимало. Почнемо з самого простого: за замовчуванням в деяких моделях WD навіть не питають пароль для доступу до даних. Тобто інформація, з одного боку, шифрується, з іншого - доступна будь-кому.

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

Йдемо далі. Якщо власник все-таки вказав власний пароль, то він в зашифрованому вигляді зберігається або в пам'яті контролера, або в прихованих секторах диска. Його досить просто звідти добути, і теоретично можливо розшифрувати простим перебором. Але і це не все. Один з контролерів дослідникам вдалося перевести в режим оновлення прошивки і таким чином здобути зашифрований пароль, хоча подібний метод дозволяє зробити і багато інших погані речі.

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

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

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

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

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

Черговий набір патчів для Adobe Flash (три уразливості, одна критична) і Oracle Java (154 уразливості (!), 84 серйозні)

новина про Adobe. Новина про Oracle. пост в блозі Oracle.

Що сталося у Oracle? Вийшло велике оновлення, що закриває 154 уразливості в 54 різних продуктах. З них 84 уразливості можуть експлуатуватися віддалено. 24 уразливості в Java SE різних версій, з них 7 небезпечних. За словами Еріка Моріса, відповідального в Oracle за Security Assurance, експлуатації вразливостей in-the-wild вони не спостерігають. Така кількість знайдених і закритих багів пов'язано частково з поквартальною моделлю випуску оновлень. Тобто наступний апдейт варто очікувати тільки в січні 2015 року.

Кредитна карта з замком, дуже мило. На безпеку не впливає ніяк

Що сталося у Adobe? Закрито три уразливості в Flash Player, з них одна критична ( CVE-2015-7645 ), Що дозволяє запустити код на комп'ютері з встановленим Flash. Патч Adobe вийшов раніше запланованого (збиралися на наступному тижні), поспіх пов'язаний з тим, що уразливість вже експлуатується.

Можливо, було б цікаво поговорити про різному підході двох компаній до випуску оновлень: Adobe дотримується щотижневого графіка (як і Microsoft), Oracle - поквартального. Але цікавіше подивитися на цей скріншот з сайту Adobe:

Але цікавіше подивитися на цей скріншот з сайту Adobe:

І в Oracle Java, і в Adobe Flash багато, дуже багато вразливостей. Новини цього тижня знову підняли стару тему - про те, що давайте вже все перестанемо використовувати і те, і інше. Ось і в Google Chrome з 1 вересня вже зробили запуск Flash-об'єктів тільки на вимогу, а ще раніше там була фактично заблокована Java «за замовчуванням». Так, в общем-то можна розглядати і те, і інше як тяжкий спадок з Інтернету початку 2000-х, але підхід «давайте вже заборонимо», зрозуміло, працювати не буде.

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

Що ще сталося:

Для iOS 9 таки зробили джейлбрейк, але вже закрили в апдейте до 9.1. А все тому, що джейлбрейк був публічний, і мільйон доларів за приватний експлойт поки ніхто не отримав.

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

Старожитності:

«Hard-662»

Дуже небезпечний резидентний вірус, стандартно записується в запускаються .COM-файли. Щопонеділка о 18.00 виводить на екран текст «It's hard days night!» І стирає з 50 перших секторів на всіх доступних дисках. Перехоплює int 21h.

Цитата по книзі «Комп'ютерні віруси в MS-DOS» Євгена Касперського. 1992 рік. Сторінка 69.

Disclaimer: Ця колонка відображає лише приватна думка її автора. Воно може збігатися з позицією компанії «Лабораторія Касперського», а може і не збігатися. Тут уже як пощастить.

Ну, вже за назвою зрозуміло, в чому справа, да?
Що сталося у Oracle?
А взагалі, чи є сенс намагатися донести звістку про уразливий Flash до найширшого кола користувачів?

Новости