Блиск і злидні BlackBerry Priv. Колонка Євгена Зобнина

1. Зміст статті Властиві платформі Android гнучкість і відкритість разом з прийшли пізніше популярністю...
2. Покращення в підтримці ASLR
3. Поліпшення політик SELinux
4. утиліта Pathtrust
5. додаток DTEK
6. Криптобібліотеки, сертифікована за стандартом FIPS 140-2
7. висновки

Зміст статті

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

Існує кілька проектів смартфонів, що працюють під управлінням Android з нібито посиленою безпекою. Є серед них як зовсім смішні розробки типу GATCA: Elite , Так і на перший погляд досить серйозні пристрої від іменитих компаній. Найбільш відомий представник друге - це BlackBerry Priv, про який компанія написала безліч статей і блог-постів. Один з них носить дуже претензійну назву «Чому Android від BlackBerry - кращий вибір в плані безпеки і приватності» .

Сам пост досить короткий і, крім кількох абзаців маркетингового булшіта, містить список функцій, які роблять їх Android таким крутим. Я приведу цей список цілком, намагаючись не надто спотворювати зміст сказаного (хоча в деяких місцях це зробити досить складно через початку хибного сенсу):

• реалізація довіреної завантаження всіх компонентів ОС (маркетингове ім'я Root of Trust, аналог UEFI Secure boot);
• поліпшення в підтримці технології ASLR, що робить експлуатацію вразливостей набагато більше важким завданням;
• поліпшення в системі мандатної контролю доступу SELinux;
• утиліта Pathtrust, що гарантує, що неперевірений код не буде впроваджений в систему через шкідливе ПО;
• безліч модифікацій в ядрі Linux і Android в цілому, введених для підтримки DTEK, фірмового додатка для забезпечення безпеки і приватності;
• сертифікована за стандартом FIPS 140-2 криптобібліотеки і інші поліпшення, спрямовані на захист паролів від brute-force-атак;
• підтримка смарт-карт і інші Enterprise-функції, необхідні бізнес-користувачам.

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

довірена завантаження

BlackBerry не дарма поставила цю технологію на перше місце. Root of Trust - це дійсно хороша ідея, яка дає змогу підтвердити цілісність системи на всіх рівнях, починаючи з завантажувача. Реалізована вона за допомогою звірки контрольної суми завантажувача, з подальшою звіркою контрольної суми ядра ОС, перевіркою SHA-хешу розділу / system і звіркою контрольних сум встановлених додатків. Все це в дещо спотвореному вигляді показано на малюнку нижче.

Root of Trust

Говорячи простою мовою, Root of Trust гарантує, що ні завантажувач, ні ядро, ні сама система, ні навіть встановлені програми не були змінені з моменту минулого завантаження. Наприклад, якщо ти випадково підхопив особливо хитрий зловредів, який зумів отримати root і впровадитися в одне з встановлених легітимних додатків або навіть ядро ​​ОС, то під час наступного завантаження система це визначить і відкотиться до попереднього стану.

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

Друга: BlackBerry не дає ніяких пояснень з приводу реалізації даної функції. Як і де зберігаються ключі і хеш-кодування? Як вони захищені? Як система зберігає хеши встановлених додатків і чи можна отримати до них доступ, маючи права root? Іншими словами, наскільки більшу безпеку надає Root of Trust в порівнянні зі звичайним залоченним загрузчиком, який точно так же відмовиться завантажувати систему при зміні ядра? Поки на ці питання не буде дана відповідь, система нічим не кращий за ідею залоченних загрузчиков.

Ну і як ми всі знаємо, всі подібні системи вбивають будь-які можливості модифікації прошивок, рутінга, установки Xposed або зміни прошивки. Через рік-другий BlackBerry випустить Priv 2 і заб'є на поточний смартфон. А ще через рік в ньому знайдуть дірку і користувачі виявляться не захищені. Так, через три роки смартфон вже пора і викинути, але це зовсім не аргумент (та ж Apple до цих пір оновлює iPhone 4S, наприклад). Але я можу бути і не правий, і BlackBerry буде підтримувати смартфон років п'ять.

Покращення в підтримці ASLR

технологія ASLR (Address space layout randomization) з'явилася як відповідь на різні види атак, спрямованих на переповнення буфера, і вперше була реалізована в рамках проекту PaX (патч для ядра Linux) в 2001 році. Суть технології проста і зводиться до того, щоб замість розміщення коду програми, його стека, Хіпа і бібліотек-залежностей послідовно в оперативній пам'яті (при завантаженні програми) рандомно розкидати їх по різних дільницях. ASLR сильно ускладнює роботу зломщика (а точніше, написання експлойтів), так як, викликавши переповнення, він не буде точно знати, на яку адресу «стрибнути», щоб виконати шелл-код або, наприклад, викликати потрібну функцію libc (її адреса в пам'яті може бути буквально будь-яким).

Сьогодні ASLR в тому чи іншому вигляді підтримується практично всіма популярними ОС, і Android зовсім не виняток: повна підтримка цієї технології з'явилася у версії 4.1, а в урізаному вигляді (тільки для стека) була доступна аж з перших версій системи. Проблема тільки в тому, що через самого принципу роботи Android, який передбачає використовувати одну і ту ж завантажену в пам'ять середу виконання для запуску всіх додатків (форк процесу zygote в режимі copy-on-write), ASLR тут не так ефективна, як в інших системах (адреси всіх бібліотек і класів середовища виконання залишаються однаковими для всіх додатків).

Практично єдиний спосіб вирішити цю проблему - повторно завантажувати середу виконання для кожної програми окремо. Саме так, до речі кажучи, вчинили творці прошивки CopperheadOS , Що призвело до додаткової витрати пам'яті (від 3 до 15 Мбайт на кожен додаток). Чи зробили так само творці BlackBerry Priv? Звичайно, немає, тому говорити про якісь поліпшення вони просто не мають права.

Поліпшення політик SELinux

SELinux (Security Enhanched Linux) - це один з так званих security-модулів ядра, який додає в нього реалізацію моделі мандатної контролю доступу. Дві його основні функції - це тонка настройка прав доступу до файлів і обмеження додатків в повноваженнях (а точніше, в можливості виконувати системні виклики ядра). Простіше кажучи, SELinux дозволяє точно вказати, що може робити додаток (наприклад, створювати мережеві підключення) та до яких файлів воно може отримати доступ.

В Android SELinux з'явився у версії 4.2 і в першу чергу використовується для урізання прав низькорівневих сервісів, написаних на мові C або C ++ (якщо в одному з них буде знайдений баг, зломщикові буде набагато важче використовувати його для отримання доступу до системи). На більш високому рівні (там, де працюють прості програми і велика частина системи) в Android і раніше існували свої досить надійні механізми захисту: пісочниці для додатків, права доступу (своя окрема реалізація) і контрольована ядром система обміну повідомленнями. За допомогою SELinux до неї лише додали додатковий захисний шар.

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

утиліта Pathtrust

Pathtrust - це утиліта з операційної системи QNX 6.6, на якій раніше базувалися всі смартфони BlackBerry. Сама по собі вона не дуже цікава, але є частиною технології так званих довірених файлових систем. Остання являє собою просто захист від запуску додатків з певних розділів диска або каталогів. В общем-то, штука досить корисна, але є одне але - в Android все це вже є з коробки.

Наприклад, звичайна програма має право запускати будь б то не було файли тільки зі своєї пісочниці або одного з каталогів, що містять стандартний набір UNIX-команд (/ system / bin і інші), а запуск файлів з карти пам'яті заборонений в принципі (все це контролюється за допомогою не тільки звичайних прав доступу, але і політик SELinux). Більш того, в даному випадку, кажучи про запуск, я маю на увазі саме нативні додатки, що працюють поверх ядра Linux, запуск Android-додатків повністю контролюється системою, і можна запустити тільки ті, що явно встановлені. Тобто не можна просто кудись кинути пакет APK з вірусом і запустити його з іншої програми (принаймні до тих пір, поки смартфон не рутованних).

додаток DTEK

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

Роботу обох функцій в справі можна оцінити по скриншотам нижче. Неважко помітити, що той самий «аналізатор безпеки» - це не що інше, як просто система для перевірки тих чи інших налаштувань: включена налагодження по USB - погано, включена установка додатків зі сторонніх джерел - погано, немає ПІН-коду - погано і так далі. Зверни особливу увагу, що відсутність логіна в акаунт Google - це теж погано: BlackBerry Priv повністю покладається на гугловський функції скидання до заводських налаштувань і пошуку смартфона, але на то, що дані будуть витікати в Google, можна, на їхню думку, і забити. В цілому досить марна штуковина, яка не враховує реальні потреби користувача і розрахована на недосвідченого користувача.

«Менеджер повноважень» (це я його так називаю) - набагато більш цікава штука. Він дозволяє точно визначити, які функції ОС (камера, місце розташування та інше) і коли використовували встановлені додатки, а найголовніше - повідомляє користувача про це в режимі реального часу. Зручно? Безумовно. Якщо не брати до уваги той факт, що ця функція тимчасово з'явилася в Android 4.3 і є стандартною починаючи з CyanogenMod 10.1 (звідки, я впевнений, її сперла BlackBerry). Причому реалізація даної функції в CyanogenMod дозволяє також і відкликати повноваження, що в BlackBerry зробити не можна з простої причини: додаток може працювати некоректно або падати.

До речі, штатна функція коректного відкликання повноважень і їх запиту прямо під час роботи додатків з'явилася в Android 6.0, однак працює вона тільки щодо нових додатків, зібраних спеціально для неї (Target SDK: 23).

Криптобібліотеки, сертифікована за стандартом FIPS 140-2

FIPS 140-2 - це стандарт США, який використовується для сертифікації криптографічних модулів (як залізних, так і програмних). Його призначення в тому, щоб не пропустити в держустанови і компанії, що працюють з важливою інформацією (фінансовий і медичний сектор), потенційно небезпечний софт, який реалізує вразливі методи захисту даних (або не реалізує їх зовсім). В рамках програми CMVP (Cryptographic Module Validation Program) будь-яка компанія може отримати сертифікат відповідності FIPS 140-2, віддавши свій софт на експертизу.

З одного боку, все відмінно, серйозна організація дала своє добро на використання криптоалгоритмів BlackBerry Priv для зберігання і обробки критично важливих даних. З іншого боку, пройти перевірку на відповідність 140-2 може практично будь-яка випробувана часом реалізація вважається надійним криптоалгоритма. Тобто в буквальному сенсі її пройде і реалізація алгоритмів шифрування ядра Linux, і OpenSSH, і OpenSSL. Тому у випадку з BlackBerry Priv відповідність FIPS 140-2 не означає зовсім нічого і використовується просто як маркетинг, а на ділі це, швидше за все, все той же алгоритм шифрування AES, який використовується в Android.

І так, не варто забувати, що в останній раз стандарт FIPS 140-2 оновлювався в 2002 році.

висновки

Як бачиш, якщо навіть BlackBerry, компанія, що дорожить своїм іміджем серед Enterprise-клієнтів, сильно перебільшує значимість своєї ОС і своїх технологій, то що говорити про всі інші?

Так, творці GATCA: Elite, смартфона, наведеного як приклад на початку статті, взагалі порушують всі межі нахабства в своєму брехня і заявляють про технології, які є навіть у голом Android (256-бітний ключ шифрування, необхідність моргнути при знімку особи, блокування при виході з географічної зони) або легко реалізуються за допомогою одного з десятків АНТИВОР (блокування в разі зміни SIM-карти). Так що будь уважний і не ведісь на маркетингові розводки.