Як розробнику захистити пристрій на Linux від хакерських атак: практичні поради

Привіт! Мене звати Андрій, і я — Software Engineer у PLVision. Наша компанія займається розробкою програмних продуктів для комп’ютерних мереж і вбудованих систем. В основі більшості наших проєктів лежать опенсорс-технології, що дозволяє нам бути в курсі останніх трендів і працювати на рівні з експертами зі світових техгігантів, робити відкриті коміти під власним іменем та доповнювати наявні рішення.

Я працюю у напрямку Embedded-розробки вже близько 8 років, з яких 3,5 — на проєкті PLVision для відомої технологічної корпорації. Зараз належу до підкоманди, що займається Linux Security, та глибоко досліджую цей напрямок.

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

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

Інформаційна безпека Linux-пристрою на різних етапах розробки

Уявімо, що у вас є стартап, пов’язаний з розробкою Linux-девайса. Це може бути роутер, IP-камера, дрон, мережеве сховище чи хаб розумного будинку. І перед розробкою кожного з цих пристроїв постає важливе питання — чи достатньо він захищений від потенційних хакерських атак? Пропоную розглянути типові рішення і засоби для цього. Водночас маємо розуміти, що не існує на 100% ідеального методу, але є достатньо хороші рішення, які використовують і у великих технологічних корпораціях, і в стартапах.

Підхід, коли команда розробників при плануванні девайсу за місяць до релізу вирішувала «додати security», давно втратив актуальність. Зараз це відбувається більш продумано.

Отже, на яких етапах розробки вам потрібно передбачати безпеку Linux-пристрою? Я виділяю наступні етапи: Deploy, Product Lifecycle та Access Control.

Deploy

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

Припустимо, що вигадана компанія Homeinc надсилає оновлення на певний розумний пристрій. До файлу застосовується hash-функція, наприклад, SHA 1, і результатом обчислення цієї функції буде певне число. Це число ми зашифровуємо за допомогою приватного ключа. Результат шифрування власне і буде цифровим підписом.

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

Валідний цифровий підпис фактично говорить про дві речі:

• власником цього файлу є компанія, а не зловмисник;
• файл не був змінений по дорозі до нашого девайсу.

Цифровий підпис для файлів оновлення

Крім підписування і перевірки файлів оновлень чи патчів, цікавим кейсом є Secure Boot. Це безпечне завантаження Linux на девайсі. Спершу на всіх девайсах була система BIOS — Basic Input/Output System, і на заміну їй зараз приходить система UEFI — Unified Extender Firmware Interface. UEFI дозволяє зберігати публічні ключі для перевірки різного типу цифрових підписів.

UEFI Secure Boot для Linux-систем

Як це відбувається? У нас є UEFI-система, є завантажувачі (loaders) операційної системи, є базовий завантажувач shim, а також grub і власне ядро Linux . Бінарні файли завантажувачів мають бути в UEFI-форматі: вони повинні збілдитись відповідно до цього формату. Під час завантаження shim, grub і kernel система UEFI перевіряє цифровий підпис кожного з перелічених бінарників. Перевірка здійснюється за допомогою тих ключів, які зберігаються в UEFI-системі. Це називають активним захистом. Якщо раптом валідація цифрового підпису не проходить, девайс зупиняє завантаження, і його потрібно відновлювати з попереднього етапу.

Крім активного захисту Secure Boot існує також Trusted Boot, який використовує апаратний компонент — Trusted Platform Module (TPM). Відповідно, якщо він апаратний, його потрібно передбачити при проектуванні апаратної частини вашого девайсу, адже для нього необхідно буде виділити місце на платі.

Існують різні етапи завантаження операційної системи — hardware, firmware та інші, і в результаті виконання кожного етапу до TPM записується так званий хеш виконання всіх цих операцій.

Measured Boot з використанням модуля TPM

Результат виконання операцій у формі числа записується у Platform Configuration Register (PCR), і вже на наступних етапах можна буде побачити чи сума hash збігається з попереднім завантаженням, чи ні. Це покаже, чи були зміни на якомусь з попередніх етапів в порівнянні з попереднім завантаженням.

Американська National Security Agency рекомендує використовувати комбінацію UEFI Secure Boot та TPM разом, тобто активного та пасивного захисту.

Цікавим випадком є поєднання TPM і шифрування диску. Можливо зробити налаштування Linux-системи таким чином, щоб використовувати TPM та шифрування диску для блокування завантаження системи, якщо відбулись зміни в процесі UEFI Boot. Детальніше про це можна почитати тут.

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

• UEFI Database. Коли Linux запущено, ми можемо витягнути ключі з UEFI Databasе, переформатувати їх у відкритий формат SSL і перевіряти цифрові підписи тих файлів, які будемо отримувати.
• Linux Kernel. Під час білду ядра Linux у нього можна зашивати ключі, одним з параметрів build-root, і таким чином перевіряти файли в run-time. Це називається Linux Trusted Keys.
• TPM. Можна використовувати TPM, якщо ви передбачили його на своїй платі.
• І найгірший варіант — це власне WEB (upgrade server). Якщо є постійний доступ до інтернету, тоді ключі можна зберігати на upgrade-сервері на веб-сторінці. Багато компаній, які випускають дистрибутиви Linux, зберігають цифровий підпис на upgrade-серверах. В такому випадку потрібно докласти зусиль і придумати кастомну перевірку сертифікату, щоб впевнитись, що сервер той, який потрібно.

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

Product Lifecycle

Будь-яка Linux-система — це перш за все відкритий код. У контексті інформаційної безпеки тут є ряд переваг та недоліків. Якщо говорити про мінуси, то ключовим є те, що будь-яка вразливість, яка стає відомою у глобальному ком’юніті, може бути одразу використана щодо вашого девайсу. Доводиться постійно стежити за новинами свого напрямку та аналізувати, які вразливості можуть задіяти проти вашого пристрою, використовуючи CVE-сканери.

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

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

Є декілька хороших безкоштовних СVE-сканерів:

• snyk.io;
• cve search;
• nvd.nist.gov, де ви можете підписатись відповідно до свого ПЗ для отримання безкоштовної розсилки про вихід нових вразливостей.

Серед платних сканерів є blackduck, nessus і vdoo (тепер jfrog). Це достатньо дорогі інструменти, і часто в їхню підписку входить і підтримка, і додатковий аналіз CVE.

Оцінка серйозності (severity sсoring) вразливості після аналізу на передплаченому сервісі може відрізнятись від оцінки на загальноприйнятому ресурсі nvd.nist.gov. Маючи оцінку від ком’юніті і від сервісу, компанія самостійно вирішує як діяти зі знайденою вразливістю.

Власний код

Крім опенсорсу, на типовому комерційному Linux-девайсі завжди буде написаний пропрієтарний (комерційний) код, здебільшого на С або С++. Для нього потрібно регулярно робити статичний аналіз, звертати увагу на різного типу попередження при компіляції.

Серед платних аналізаторів хорошими є coverity та sonarQube. Серед динамічних аналізаторів Valgrind — монополіст, за допомогою якого можна проаналізувати та зрозуміти невалідні доступи до пам’яті.

Також існує Fuzzing-тестування — таке собі «годування» певної функції вибірковими вхідними даними. Ця система тестує виходи за межі дозволеної пам’яті, відповідно, можна знаходити інші вразливості. До прикладу, з допомогою Fuzzer можна було за 15 секунд знайти вразливість heartbleed, яка була дуже критичною в OpenSSL.

Access Control

Часто користувачі Linux-девайсів мають можливість отримати конфігураційні файли та інші речі через scp, (s)ftp або telnet. У такому випадку не потрібно давати користувачеві можливість завантажувати критично важливі файли.

Якщо є можливість завантажити /var/log/messages, то можна спробувати /etc/shadow. А якщо буде можливість отримати цей файл, це буде досить хорошим приводом для продовження атаки.

Щодо snmp, рекомендую використовувати третю версію, бо принаймні там вся комунікація проходить зашифровано.

Багато Linux-девайсів мають замість звичайного bash так званий Cisco-like CLI (Command Line Interface) або Сustom CLI. Ідея в тому, що користувач може виконувати лише ті команди, які є передбачені CLI. Відповідно, треба щонайменше фільтрувати всі бажані та небажані символи в user input, а ще краще — використовувати fuzzing-тестування для цього CLI.

Наведу приклад типової помилки при додаванні команди в такий cli або web-інтерфейс: реалізація команди ping. При такій команді користувачу потрібно ввести ip чи hostname для того, щоб здійснити пінг. Типовий і найлегший підхід — це взяти вхідні дані від користувача, виконати bash-команду ping з введеною адресою. Це і буде коректний робочий підхід, допоки користувач не спробує поряд з адресою додати ще якусь команду.

Типова вразливість пристрою в CLI чи вебінтерфейсі

У такому випадку виконається і ping 8.8.8.8, і наступна команда cat /etc/shadow. Для того, щоб не виникало подібних випадків, потрібно завжди перевіряти вхідні дані від користувача.

Якщо говорити про політики паролів, то найперше — необхідно змушувати користувачів регулярно змінювати пароль і мати так званий brute force protection, тобто блокувати користувача на деякий час після неправильно введеного пароля впродовж кількох спроб. У жодному разі не можна давати можливість користувачу встановлювати прості паролі. З цими вимогами допоможуть pam rules: pluggable authentication modules.

Важливим є також використання систем контролю доступу: AppArmor, SELinux, grsecurity. З допомогою систем контролю доступу можна налаштувати політики так, щоб будь-яка програма мала доступ тільки до тих файлів, для яких це необхідно.

Інша корисна інформація

Наостанок поділюсь ще кількома порадами:

• Варто завжди зберігати логи і дампи. Вони постфактум допомагають встановити послідовність дій, які виконав зловмисник, і проаналізувати ваші помилки.
• Критично важливим є вимкнення дебаг-прапорців для релізів компіляції ядра та програм на С чи C++.
• Не забувати застосовувати політику Cisco і вимикати порти та сервіси за замовчуванням до того моменту, коли вони будуть потрібні.
• І основне — не довіряти тому, що вводить користувач. Тобто перевіряти вхідні символи, бо у площині інформаційної безпеки кожен користувач сприймається як потенційний зловмисник.

Підсумки

Підсумовуючи все сказане вище, можемо виділити ключові моменти інформаційної безпеки при розробці Linux-пристрою.

• На етапі Deploy пристрою потрібно звернути увагу на процес безпечного оновлення прошивки, а також на процес завантаження Secure Boot. За можливості варто передбачити ТРМ при створенні апаратної частини.
• Щодо етапу Product Lifecycle, то однією з ключових порад є постійне сканування опенсорс-частини на вразливості, а також регулярне здійснення статичного та динамічного аналізів пропрієтарного коду.
• Для Access Control звертаю особливу увагу на політику паролів, в яких нам в основному допомагатимуть PAM-модулі та системи доступу типу SELinux або AppArmor.

Сomputer Networking — динамічний, цікавий напрямок, який лежить в основі Інтернету та багатьох похідних розробок, до яких ми всі звикли. Щодня до мережі підключається величезна кількість пристроїв, і прогнозують, що в 2025 їх буде в 10 разів більше, ніж людей на планеті. Це спонукає до побудови нових, інноваційних рішень, до пошуку нових підходів у роботі, в тому числі у напрямку інформаційної безпеки.

Сподіваюсь, що викладена мною інформація буде для вас корисною. Діліться у коментарях своїми історіями про роботу у напрямку Linux Device Security — що вдалося вирішити у цій площині та які виклики стоять перед вами.