По-перше , перш ніж спалахнути, переконайтесь, що ви розумієте, чи ця вразливість стосується вас чи ні. Якщо у вас є сервер, але ви ніколи не мали жодного додатку, що використовує TLS, то це не є пріоритетною справою. Якщо, з іншого боку, у вас коли-небудь були програми з підтримкою TLS, то тоді ви хочете поласувати. Читати далі:
Що саме таке CVE-2014-0160 aka "Heartbleed"?
Це велика безладна каша, ось що це таке. Коротше кажучи, відкриті вразливі вразливості були виявлені у версіях OpenSSL 1.0.1 - 1.0.1f, через які зловмисник може читати певні частини системної пам'яті. Ці частини - це та, у якій зберігаються конфіденційні дані, такі як приватні ключі, попередні ключові ключі, паролі та високоцінні корпоративні дані.
Проблему виявили незалежно Ніл Мехта з Google Security (21 березня 2014 р.) Та фінська фірма з тестування безпеки ІТ Codenomicon (2 квітня 2014 р.).
У чому причина?
Ну, помилковий код у OpenSSL. Ось фіксація, яка ввела вразливість, і ось фіксація, яка виправила вразливість. Помилка з'явилася у грудні 2011 року та була зафіксована сьогодні, 7 квітня 2014 року.
Помилка також може розглядатися як симптом більшої проблеми. Дві пов'язані з цим проблеми (1), який процес існує для того, щоб код помилки не був введений до бази коду, і (2) чому протоколи та розширення є настільки складними і важкими для перевірки. Пункт (1) - питання управління та процесів у OpenSSL та багатьох інших проектах. Багато розробників просто протистоять таким практикам, як огляд коду, аналіз та сканування. Пункт (2) обговорюється в робочій групі TLS IETF. Див. Складність сердечного доступу / протокол .
Чи був зловмисно вставлений код помилки?
Я не буду міркувати про те, чи справді це була помилка чи, можливо, трохи коду, який прослизнув від імені поганого актора. Однак особа, яка розробила код для OpenSSL, заявляє, що це було ненавмисно. Дивіться, людина, яка представила серйозний недолік безпеки "Heartbleed", заперечує, що він вставив її навмисно .
Які ОС та версії OpenSSL вразливі?
Як було сказано вище, будь-яка операційна система, яка використовує, або додаток, який пов'язаний між OpenSSL 1.0.1 та 1.0.1f.
Які симптоми, чи є якісь методи виявлення успішного подвигу?
Це страшна частина. Наскільки нам відомо, не існує відомого способу виявити, чи була використана ця вразливість чи ні. Теоретично можливо, що незабаром будуть опубліковані підписи IDS, які зможуть виявити цей подвиг, але станом на цей текст вони недоступні.
Є дані, що Heartbleed активно експлуатувались в дикій природі ще в листопаді 2013 року. Дивіться EFF Wild in Heart: Чи розвідувальні агенції використовували Heartbleed у листопаді 2013 року? І повідомляє Bloomberg, що АНБ озброїло цей вибух незабаром після введення вразливості. Ознайомтеся з NSA, що роками експлуатує помилку, що боїться серця . Однак американська розвідувальна спільнота заперечує претензії Bloomberg. Див. СК НА ЗАПИС .
Як я можу перевірити, чи впливає на мою систему?
Якщо ви підтримуєте OpenSSL у своїй системі, ви можете просто видавати openssl version
:
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
Якщо розподіл підтримує OpenSSL, то ви , ймовірно , не може визначити версію OpenSSL з - за спини Patching з допомогою openssl
команди або інформацію про пакет (наприклад, apt-get
, dpkg
, yum
або rpm
). У процесі зворотного виправлення, який використовується у більшості (усіх?) Дистрибутивах, використовується лише базовий номер версії (наприклад, "1.0.1e"); і не включає ефективну версію безпеки (наприклад, "1.0.1g").
Суперкористувач відкритий питання, щоб визначити ефективну версію безпеки для OpenSSL та інших пакетів, коли пакети проводяться з виправленням. На жаль, корисних відповідей немає (крім перевірки веб-сайту дистрибутива). Див. Розділ " Визначення ефективної версії безпеки", коли ви стикаєтесь з Backpatching ?.
Як правило: якщо ви коли-небудь встановлювали одну з постраждалих версій і коли-небудь запускали програми чи сервіси, пов’язані з підтримкою OpenSSL для підтримки TLS, то ви вразливі.
Де можна знайти програму для тестування на вразливість?
Протягом кількох годин після оголошення Heartbleed кілька людей в Інтернеті оприлюднили загальнодоступні веб-додатки, які нібито можуть бути використані для перевірки сервера на наявність цієї вразливості. Станом на це написання я не переглядав жодного, тому більше не публікую їх заявки. Їх можна знайти відносно легко за допомогою бажаної пошукової системи.
Як зменшується ця вразливість?
Оновіть до невразливої версії та скиньте або повторно захистіть вразливі дані. Як зазначається на сайті Heartbleed , відповідні кроки реагування в цілому:
- Виправити вразливі системи.
- Відновити нові приватні ключі.
- Надішліть нову КСВ у свій КА.
- Отримайте та встановіть новий підписаний сертифікат.
- Недійсні ключі та файли cookie сесії
- Скидання паролів та загальних секретів
- Скасувати старі сертифікати.
Більш детальний аналіз та відповідь див. У розділі Що повинен робити оператор веб-сайту щодо OpenSSL Heartbleed? на біржі стека безпеки.
Чи повинен я бути стурбований тим, що мої ключі чи інші приватні дані були порушені? Які ще побічні ефекти слід турбувати?
Абсолютно. Системним адміністраторам потрібно припустити, що їх сервери, які використовували вразливі версії OpenSSL, дійсно компрометовані і відповідно реагувати на них.
Незабаром після виявлення вразливості Cloudfare запропонував виклик, щоб перевірити, чи можна відновити приватний ключ сервера на практиці. Виклик незалежно виграли Федір Індутний та Ілька Маттіла. Дивіться виклик Heartbleed .
Де я можу знайти більше інформації?
Дамп посилання, для тих, хто шукає більше деталей:
Досить детальну шкалу подій розкриття можна знайти на шкалі розкриття Heartbleed: хто знав, що і коли .
Якщо ви програміст і цікавитесь різними прийомами програмування, як виявлення нападу Heartbleed через msg_cb
зворотний виклик OpenSSL , перегляньте розділ рекомендацій щодо безпеки 2014047 OpenSSL .