Ця вразливість має високий потенційний вплив, тому що якщо ваша система атакується, вона залишатиметься вразливою навіть після виправлення, і атаки, можливо, не залишать слідів у журналах. Швидше за все, що якщо ви швидко виконали патч і не є гучною ціллю, ніхто не змусить вас напасти, але важко бути впевненим.
Я вразливий?
Баггі версія версії OpenSSL
Програмне забезпечення баггі - це бібліотека OpenSSL від 1.0.1 до 1.0.1f , а OpenSSL 1.0.2 - до beta1. Старіші версії (0.9.x, 1.0.0) та версії, де виправлено помилку (1,0,1 г далі, 1,0,2 бета-2), не впливають. Це помилка реалізації, а не недолік у протоколі, тому впливають лише програми, які використовують бібліотеку OpenSSL.
Ви можете використовувати інструмент командного рядка openssl version -aдля відображення номера версії OpenSSL. Зауважте, що в деяких дистрибутивах виправлено помилку на попередні версії; якщо журнал змін вашого пакета згадує виправлення помилки Heartbleed, це добре, навіть якщо ви бачите версію типу 1.0.1f. Якщо openssl version -aзгадується дата складання (а не дата в першому рядку) 2014-04-07 біля вечора UTC або пізніше, вам слід добре. Зауважте, що пакет OpenSSL може мати 1.0.0свою назву, навіть незважаючи на те, що версія 1.0.1 ( 1.0.0стосується двійкової сумісності).
Постраждалі програми
Експлуатація здійснюється через додаток, який використовує бібліотеку OpenSSL для реалізації SSL-з'єднань . Багато програм використовують OpenSSL для інших криптографічних сервісів, і це добре: помилка полягає у впровадженні певної функції протоколу SSL, «серцебиття».
Ви можете перевірити, які програми пов'язані з бібліотекою у вашій системі. У системах, які використовують dpkg та apt (Debian, Ubuntu, Mint, ...), наступні команди перелічують встановлені пакети, окрім бібліотек, які використовують libssl1.0.0(уражений пакунок):
apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'
Якщо ви запускаєте серверне програмне забезпечення, яке є в цьому списку, і прослуховує з'єднання SSL, ви, мабуть, постраждали. Це стосується веб-серверів, серверів електронної пошти, VPN-серверів тощо. Ви знатимете, що ви включили SSL, оскільки вам довелося генерувати сертифікат, або подавши запит на підписання сертифікату до органу сертифікації, або зробивши свій власний самопідпис довідка. (Можливо, що певна процедура встановлення створила сертифікат, який підписав самостійно, не помічаючи, але це робиться лише для внутрішніх серверів, а не для серверів, що потрапляють в Інтернет.) якщо ваші журнали не мають зв’язку з моменту оголошення 2014-04-07. (Це передбачає, що вразливість не була використана до її оголошення.) Якщо ваш сервер був відкритий лише внутрішньо,
Клієнтське програмне забезпечення впливає лише в тому випадку, якщо ви використовували його для підключення до шкідливого сервера. Тож якщо ви підключились до свого постачальника електронної пошти за допомогою IMAPS, вам не потрібно турбуватися (якщо тільки на цього не напали - але якщо це так, вони повинні повідомити про це), але якщо ви переглядаєте випадкові веб-сайти з уразливим браузером, можливо, вам знадобиться турбуватися. Поки здається, що вразливість не використовувалася до її виявлення, тому потрібно хвилюватися лише в тому випадку, якщо ви підключились до шкідливих серверів з 2014-04-08.
На такі програми не впливає, оскільки вони не використовують OpenSSL для реалізації SSL:
- SSH (протокол не SSL)
- Хром / Хром ( використовує NSS )
- Firefox (використовує NSS) (принаймні, з Firefox 27 на Ubuntu 12.04, але не з усіма збірками?
Який вплив?
Помилка дозволяє будь-якому клієнту, який може підключитися до вашого SSL-сервера, одночасно отримувати близько 64 кБ пам'яті. Клієнту не потрібно ніякої автентифікації. Повторивши атаку, клієнт може скидати різні частини пам'яті в послідовних спробах. Це потенційно дозволяє зловмиснику отримати будь-які дані, що були в пам'яті серверного процесу, включаючи ключі, паролі, файли cookie тощо.
Одним із найважливіших фрагментів даних, який зловмисник може отримати, є приватний ключ сервера SSL. За допомогою цих даних зловмисник може представити себе за ваш сервер.
Помилка також дозволяє будь-якому серверу, до якого підключений ваш клієнт SSL, одночасно отримувати близько 64 кБ пам'яті. Це хвилює, якщо ви використовували вразливий клієнт для маніпулювання конфіденційними даними, а потім пізніше підключилися до ненадійного сервера з тим самим клієнтом. Таким чином, сценарії атаки на цій стороні значно менше, ніж на стороні сервера.
Зауважте, що для типових дистрибутивів не впливає безпека на розповсюдження пакунків, оскільки цілісність пакетів покладається на підписи GPG, а не на транспорт SSL.
Як виправити вразливість?
Усунення відкритих серверів
Перенесіть всі сервери, які постраждали, офлайн Поки вони працюють, вони потенційно витікають критичні дані.
Оновіть пакет бібліотеки OpenSSL . В усіх дистрибутивах має бути виправлено до цього часу (або з 1.0.1 г, або з патчем, який виправляє помилку, не змінюючи номер версії). Якщо ви компілювали з джерела, оновіть до 1,0,1 г або вище. Переконайтесь, що всі постраждалі сервери перезапущені.
У Linux ви можете перевірити, чи все ще запущені потенційно впливають процесиgrep 'libssl.*(deleted)' /proc/*/maps
Створіть нові ключі . Це необхідно, тому що помилка, можливо, дозволила зловмиснику отримати старий приватний ключ. Дотримуйтесь тієї ж процедури, яку ви використовували спочатку.
- Якщо ви використовуєте сертифікати, підписані органом із сертифікації, надішліть свої нові відкриті ключі у свій ЦА. Отримавши новий сертифікат, встановіть його на свій сервер.
- Якщо ви використовуєте самопідписані сертифікати, встановіть їх на свій сервер.
- Так чи інакше, переміщуйте старі ключі та сертифікати (але не видаляйте їх, просто переконайтеся, що вони більше не використовуються).
Тепер, коли у вас є нові безкомпромісні ключі, ви можете повернути свій сервер в Інтернет .
Скасуйте старі сертифікати.
Оцінка пошкоджень : будь-які дані, що потрапили в пам'ять процесу, що обслуговує з'єднання SSL, потенційно могли просочитися. Це може включати паролі користувачів та інші конфіденційні дані. Потрібно оцінити, якими були ці дані.
- Якщо ви працюєте з сервісом, який дозволяє перевірити паролі, то паролі користувачів, які підключились трохи раніше, ніж було оголошено про вразливість, слід вважати компрометованими. Перевірте свої журнали та змініть паролі будь-якого зачепленого користувача.
- Також недійсні всі файли cookie сеансу, оскільки вони можуть бути порушені.
- Клієнтські сертифікати не ставлять під загрозу.
- Будь-які дані, якими було обмінено трохи раніше, ніж вразливість, можливо, залишилися в пам’яті сервера і тому можуть потрапити до зловмисника.
- Якщо хтось записав старе з’єднання SSL та отримав ключі вашого сервера, він тепер може розшифрувати свою стенограму. (Якщо не було забезпечено PFS - якщо ви не знаєте, це не було.)
Санація в інших випадках
Сервери, які слухають лише в localhost або в інтрамережі, вважаються відкритими лише в тому випадку, якщо до них можуть підключитися недовірені користувачі.
З клієнтами є лише рідкісні сценарії, коли помилка може бути використана: експлуатація вимагає, щоб ви використовували той самий клієнтський процес, щоб
- маніпулювати конфіденційними даними (наприклад, паролі, клієнтські сертифікати, ...);
- а потім у тому ж процесі підключається до шкідливого сервера через SSL.
Так, наприклад, клієнт електронної пошти, який ви використовуєте лише для підключення до свого (не зовсім недовіреного) постачальника пошти, не викликає занепокоєння (не зловмисного сервера). Запуск wget для завантаження файлу не викликає занепокоєння (немає конфіденційних даних для протікання).
Якщо ви робили це між 2014-04-07 вечором UTC та оновленням своєї бібліотеки OpenSSL, вважайте, що будь-які дані, що знаходяться в пам’яті клієнта, можуть бути порушені.
Список літератури