Злом системи резервного копіювання iOS.
Починаючи з iOS 5, користувачі «яблучних» пристроїв отримали можливість автоматичного збереження даних пристрою в «хмару». У старих версіях iOS цю можливість потрібно було активувати вручну, але в останніх версіях iOS вона стала пропонуватися в якості опції «за замовчуванням». В iOS 9 «хмарні» копії зберігаються вже не в iCloud, а в більш універсальному iCloud Drive.
«Хмарних» Бекап - ЦЕ БЕЗПЕЧНО?
Зверни увагу на знак питання в заголовку. Безпека «хмарних» резервних копій iOS - під великим питанням, відповідь на який, втім, добре відомий.
Отже, перше і головне: «хмарні» резервні копії шифруються. Друге і не менш головне: ключ шифрування зберігається поряд з зашифрованими даними, і дістати його не складає жодної проблеми. Шифрування, таким чином, захищає дані тільки в момент їх передачі між пристроєм і сервером, а ось далі ... далі ні в Apple, ні у спецслужб не виникає жодних проблем з доступом до твоїх даними.
І дійсно, саме цей спосіб був використаний для крадіжки фотографій знаменитостей. Ні, так не годиться!
Викачуємо бекап з iCloud, захищений security code
Якщо ж зловмисник отримував доступ до комп'ютера користувача, то у нього з'являвся шанс і зовсім пройти повз всієї і всякої захисту - логінів, паролів і кодів. Досить було всього лише витягти двійковий маркер аутентифікації з комп'ютера, на якому була встановлена (і активована) програма iCloud for Windows. Далі - справа техніки: маркер вводиться в Elcomsoft Phone Breaker, резервні копії викачуються, а логін, пароль і одноразовий код - не потрібні.
Витягуємо маркер аутентифікації
Використовуємо маркер аутентифікації для скачування даних з iCloud
Як на це відреагували в Apple? Досить оперативно: термін життя маркера аутентифікації iCloud зменшили з декількох місяців до лічених годин. Правда, є нюанс: в iOS 9, як ми вже писали, резервні копії зберігаються не в iCloud, а в iCloud Drive, для якого маркери аутентифікації і понині діють дуже і дуже довго.
Як ФБР могла б отримати дані з iPhone стрілка з Сан-Бернандіно?
Природно, такий спосіб міг би спрацювати тільки в тому випадку, якщо хмарний бекап включений. ФБР наполягає що бекап був відключений, проте вірити їм немає ніяких підстав.
БЕЗПЕКА - ЦЕ ЗРУЧНО?
Подальше залежатиме від того, який саме вид двофакторної аутентифікації був використаний: старий Two-Step Verification (2SV) або новий Two-Factor Authentication (2FA). У першому випадку тобі доведеться використовувати код відновлення доступу (Recovery Key), який ти, звичайно ж, зберіг в безпечному місці. У другому - пройти процедуру відновлення доступу через автоматизований сервіс Apple, причому процедура може зайняти до декількох днів в залежності від ситуації. Або можна почекати, поки ти повернешся додому і відновиш SIM-карту з заповітним довіреною номером для отримання коду через SMS. В цілому ж ситуація така, що безпека вимагає жертв.
А ЯКЩО БЕЗ «ХМАРИ»?
РЕЗЕРВНІ КОПІЇ В ITUNES: З пароль або БЕЗ?
Зверни увагу на скріншот вище. Бачиш настройку «Encrypt iPhone backup»? Якщо активувати цю настройку і вказати пароль (до речі, він ніяк не пов'язаний з кодом блокування пристрою і паролем від Apple ID), то все новостворювані резервні копії будуть шифруватися з використанням цього пароля. Більш того, якщо ти забудеш пароль, то скинути або змінити його буде неможливо без повного перезавантаження пристрою (при цьому відновити його з зашифрованою резервної копії ти не зможеш, не вказавши правильний пароль).
З технічної точки зору шифрування в iOS реалізовано зразково-показово. Вся інформація шифрується безпосередньо в самому пристрої, а назовні видається вже зашифрований потік даних. iTunes в даному випадку всього лише видає команду на створення резервної копії, приймає зашифрований потік даних і зберігає його в файл. На місці iTunes могла б бути будь-яка інша програма, при цьому дані все одно залишилися б зашифрованими (у одній з наступних статей ми розглянемо цей момент детальніше).
Що ж, виходить, з шифруванням все добре? Можна встановити пароль і забути про проблеми з безпекою? Є два моменти, які заважають розслабитися і отримати задоволення. Момент перший: пароль можна спробувати зламати.
Є і другий момент, який вступає в деяке протиріччя зі здоровим глуздом. Якщо резервна копія зашифрована паролем, то майже всі дані з keychain (а це твої паролі від облікових записів і веб-сайтів, дані утиліт Health, HomeKit і багато інших) будуть також зашифровані тим же паролем. З одного боку, це дозволяє відновити резервну копію на новий пристрій і автоматично отримати доступ до всіх збережених паролів і облікових записів. З іншого - якщо пароль від резервної копії вдасться зламати, то всі ці дані стануть доступніші зловмисникові.
А якщо пароль не вказувати? Тоді дані додатків, фотографії та інша інформація зашифровані не будуть. А ось дані з keychain - навпаки, будуть зашифровані стійким апаратним ключем, зламати який на даному етапі розвитку технологій не представляється можливим. Правда, штатними засобами відновити дані з keychain можна буде тільки на те ж саме пристрій, з якого вони були скопійовані.
«Штатними засобами»? Що знову. Дійсно, і на цей замок є свій ключ, проте дістати його - дуже і дуже важко і далеко не завжди можливо. Скажемо тільки, що ключ цей (назвемо його «securityd») можна витягти тільки з пристроїв, що не оснащених системою безпеки Secure Enclave, і тільки в тому випадку, якщо на програвачі jailbreak. Коротше кажучи, витягти securityd для розшифровки keychain з незахищеною паролем резервної копії можна з iPhone 5c і старіших, iPad mini (але навіть не mini 2) і оригінальних iPad 1-4, заснованих на 32-бітних процесорах.
НАШІ РЕКОМЕНДАЦІЇ
Тепер ти знаєш, які варіанти резервного копіювання існують і в курсі потенційних проблем, в тому числі проблем з безпекою. Чи означає це, що від резервних копій варто відмовитися? З нашої точки зору - ні. Заощаджений час і зручність переважують; Бекап - бути! Оптимальною стратегією з нашої точки зору буде активувати «хмарні» резервні копії і дозволити системі регулярно зберігати дані. А щоб не опинитися в один момент «біля розбитого корита», варто час від часу (хоча б раз на місяць) створювати і локальні копії даних через iTunes, причому з досить довгим, але легко запам'ятовується (і важко вгадуваним) паролем.
А якщо включати двухфакторную аутентифікацію 2SV або 2FA, то в першому випадку дбайливо зберігати (хоч з паспортом разом) Recovery Key, у другому - як мінімум прив'язати до облікового запису кредитку (що роблять далеко не всі). Ще бажано додати додатковий номер для SMS-верифікації, що дозволить «в разі чого» отримати одноразовий код на іншу SIM-карту.
Досліджуючи ICLOUD: ЯК ЦЕ влаштували
iCloud - цікава динамічна система розподіленого зберігання даних, зав'язана на Apple ID користувача і працює на основі Google Protocol Buffers. Самі файли розбиті на окремі блоки (chunks), які розподілені між двома незалежними «хмарними» провайдерами - Amazon S3 і Microsoft Azure. Що цікаво, останнім часом ми спостерігаємо епізодичне використання і третього «хмарного» провайдера, яким став ... Google. Так-так, Apple використовує сервіси Amazon, Google і Microsoft для зберігання «хмарних» бекапов iCloud! А ось російські «хмарні» провайдери, такі як ... ну, якісь російські, - Apple для зберігання «хмарних» бекапов не використовує. Злісні порушники, однако!
На серверах Apple формуються запити в «хмарні» сховища Amazon і Microsoft для кожного блоку. Ключі шифрування при цьому генеруються для кожного блоку (chunk) окремо.
Витягти і розшифрувати резервну копію даних з iCloud можна і вручну. Наведемо послідовність дій.
Аутентифікація в «хмару» виконується в наступному форматі. запит:
Y. x - clientrequest - id = 739A222D - 0FF5 - 44DD - A8FF - 2A0EB6F49816 amp; Expir
es = 1371208272 amp; byterange = 25556011 - 25556262 amp; AWSAccessKeyId = AKIAIW
WR33ECHKPC2LUA amp; Signature = PxAdegw0PLyBn7GWZCnu0bhi3Xo% 3D
У «хмарі» зазвичай зберігається три останніх бекапа. Коли створюється новий, якийсь час в «хмарі» висить чотири останніх версії (а іноді і більше), але потім їх число знову скорочується до заповітної цифри «три». Зберігаються резервні копії Інкрементальний. Найперший бекап зазвичай повний, наступний істотно менше, найновіший ще менше. Витягти найстарішу копію найлегше; Наступного - трохи складніше, тому що потрібно завантажити і другу частину теж, а потім «застосувати» зміни. Для отримання найсвіжішого бекапа процедуру доводиться проробляти двічі.
Завантажити дані з «хмари» - півсправи. Тепер потрібно їх ще й розшифрувати. Навіть з урахуванням того, що ключі шифрування для більшої частини даних нам доступні (вони зберігаються паралельно з самими даними), завдання не найпростіше.
Що значить «для більшої частини»? Справа в тому, що далеко не всі дані з «хмарної» резервної копії можуть бути розшифровані. Частина даних шифрується за допомогою ключів з OTA (over-the-air) backup keybag, більшість з яких може бути розшифровано тільки на тому самому пристрої, з якого була зроблена резервна копія (за допомогою ключа 0x835 «securityd», який обчислюється ядром системи в момент завантаження пристрою).
Чи можна витягти дані, захищені securityd?
Так, це було можливо зробити на 32-розрядних платформах з iOS 5-7. Починаючи з iOS 8 і пристроїв, обладнаних Secure Enclave (а це - все 64-розрядні iPhone і iPad) витягти цей ключ з пристрою не представляється можливим навіть при наявності jailbreak, в тому числі - якщо вірити заявам компанії - навіть для самої Apple.
В результаті є «чисте» пристрій, скинуте до заводських налаштувань. Далі була виконується наступна послідовність дій:
Ключ 0x835 і є «securityd». Витягти його можна тільки з завантаженого пристрої з встановленим jailbreak, і тільки з пристроїв, не обладнаних Secure Enclave. Фактично він формується з ключа UID (унікальний ключ пристрою) за допомогою наступної функції: