Хардуерното удостоверяване на SafetyNet ще направи скриването на root в Magisk наистина трудно

click fraud protection

Скриването на root достъп в Magisk е на път да стане много по-трудно благодарение на скорошна промяна в SafetyNet, която носи хардуерна атестация.

Още през март няколко потребители с инсталиран Magisk забелязано че техните устройства не са преминали атестацията на SafetyNet. Тази новина беше обезпокоителна за общността в XDA, защото означава, че много важни банкови/финансови приложения и популярни игри като Pokémon Go и Fate/Grand Order отказват да работят на руутнати устройства. За известно време изглеждаше, че затегнатите ограничения в SafetyNet бяха оттеглени, само за да бъдат въведени отново за шепа потребители през последните няколко седмици. Google обаче тихомълком потвърди в началото на май, че тества хардуерно удостоверяване за Отговори на SafetyNet, което накара Magisk да не може да скрие състоянието на отключване на буутлоудъра обратно в Март. Ако тази промяна се разпространи широко, това ще означава, че потребителите ще трябва да избират между достъп до root/персонализирани ROM/ядра/и т.н. или предпочитаните от тях банкови приложения и игри. Едно от най-големите привличания на Android за опитни потребители може скоро да изчезне.

За да обобщим тази поредица от събития, първо трябва да поговорим за самата SafetyNet. SafetyNet е набор от API в услугите на Google Play. SafetyNet Attestation API е един от тези API и може да бъде извикан от приложения на трети страни, за да провери дали софтуерната среда на устройството е била манипулирана по някакъв начин. API проверява за различни неща като знаци за двоични файлове на суперпотребител, състояние на отключване на буутлоудъра и др. Когато руутвате устройство с Magisk, то „[създава] изолирана „безопасна среда“ за процеса на откриване [SafetyNet] и преминава през API на Google, за да създаде законен Резултат от SafetyNet, който не отразява реалното състояние на устройството“, според XDA Senior Recognized Developer topjohnwu. Това позволява на потребителя да руутне своя телефон, като същевременно гарантира, че API винаги връща „false“ за всички проверки за отключване на буутлоудъра. Този метод за заобикаляне на откриването на отключване на буутлоудъра на SafetyNet работи за Magisk през последните няколко години, но това е само защото Google отложи проверката на целостта на изображението за зареждане с помощта на хардуер атестация. През март изглеждаше, че Google най-накрая започва да използва хардуерно удостоверяване в SafetyNet, за да провери изображение за зареждане, но никога не получихме официално изявление от Google, потвърждаващо промяната, и само няколко потребители получиха засегнати. Както е забелязано от старши член на XDA ДисплаксВъпреки това Google потвърди на 5 май 2020 г., че отговорите на SafetyNet Attestation API от някои устройства вече включват проверки, обезпечени с хардуер.

В групата на Google за „Клиенти на SafetyNet API“ Google описа подробно нова функция за API за удостоверяване: evaluationType. Отговорът на JSON уеб подпис (JWS) от някои устройства ще има поле, наречено „evaluationType“, което „ще предостави на разработчиците представа в типовете сигнали/измервания, които са допринесли за всеки отделен отговор на API за удостоверяване на SafetyNet." Един от поддържаните токени в това поле е „HARDWARE_BACKED“, което показва, че API „[използва] наличните хардуерно поддържани функции за сигурност на отдалеченото устройство (напр. хардуерно обезпечено удостоверяване на ключове), за да повлияе [неговата] оценка." Google казва, че те "в момента оценяват и коригират критериите за допустимост за устройства, където ще разчитаме на хардуерно обезпечени функции за сигурност." Това означава, че на някои устройства услугите на Google Play вече използват хардуерно удостоверяване, за да открият, че софтуерът на устройството не е бил подправени. Google не е документирал официално тази промяна извън съобщението в Google Group, така че някои разработчици, които използват SafetyNet, може не са наясно с тази промяна (и следователно все още не проверяват за полето „HARDWARE_BACKED“ в отговорите на JWS.) Въпреки това, за тези приложения, които проверяват за това поле, сега няма начин да скриете root достъпа от тях, при условие че вашето устройство е част от теста, който Google е бягане.

Според topjohnwu хардуерно обезпеченото удостоверяване означава, че услугите на Google Play сега „[изпращат] немодифициран сертификат за хранилище на ключове до сървърите на SafetyNet, [потвърждават] неговата легитимност и [проверява] данните за разширението на сертификата, за да знае дали вашето устройство [има] потвърдено активирано зареждане (състояние на зареждащия механизъм).“ Тъй като частните ключове, от които се извличат сертификатите за хранилище за ключове са подкрепени от изолирана защитена среда на телефона, извличането им би включвало нарушаване на сигурността на Trusted Execution Environment (TEE) на телефона или специална хардуерна защита модул (HSM). Ако някой може по някакъв начин да изтече частен ключ, ключовете бързо ще бъдат отменени след като Google разбра. Google предлага стотици хиляди долари награди за всякакви критични уязвимости в сигурността, засягащи TEE в телефоните Pixel, което просто показва, че е невероятно малко вероятно това да бъде потенциален път за заобикаляне на откриването на отключване на буутлоудъра както и да е.

Друг потенциален начин, по който Magisk може да продължи да фалшифицира състоянието на отключване на буутлоудъра, е чрез модифициране на клиентския код на SafetyNet, за да използва винаги BASIC оценката. Като topjohnwu отбелязва, но това ще изисква инжектиране на персонализиран код в Google Play Services чрез закачаща се рамка като Xposed Framework. Това не само е трудно да се направи, тъй като услугите на Google Play са силно объркани, но също така е невъзможно да се скрие, тъй като „някои анализи на пространството в паметта ще разкрият много манипулиране на кода лесно." Освен това, това също ще работи само ако сървърите на Google продължават да приемат BASIC оценки и ако HARDWARE_BACKED оценките не се прилагат на устройства, които поддържат тях. (Отговорите на SafetyNet „[идват] от сървърите на Google и са подписани с частния ключ на Google“, според topjohnwu, така че действителните отговори не могат да бъдат подправени.)

От Android 7 Nougat Google изисква всички устройства да имат изолирана защитена среда, което означава, че тази промяна в начина, по който SafetyNet проверява отключването на буутлоудъра, ще засегне повечето устройства, които не работят там. Тъй като по-старите устройства без изолирана защитена среда очевидно не могат да извършват хардуерно удостоверяване, Magisk все още ще може да скрие root достъпа на тези устройства. Но ако тази промяна се разпространи широко, всички останали ще трябва да направят труден избор между root достъп и банкови приложения.

За съжаление вероятно има много приложения, които използват проверки на SafetyNet, когато всъщност не им е необходимо. Един пример, цитиран от topjohnwu, е официалното приложение на McDonald's, което изглежда отказва да работи на устройство с отключен буутлоудър. В Twitter topjohnwu нарича приложенията, които прекомерно използват API, като създаващи враждебна среда за опитни потребители. XDA признат разработчик Куини899 се присъединява с анекдот за това как екипът му е обмислял да използва SafetyNet, за да провери състоянието на защита на устройството. Те в крайна сметка решиха да не преминават през това, тъй като приложението на неговия екип криптира всички чувствителни данни, с които работи. SafetyNet, твърди той, не трябва да се използва вместо подходящи практики за сигурност и обработка на данни, особено когато се има предвид възможност за експлоатация на суперпотребител.

За повече информация как новата промяна на SafetyNet засяга Magisk, вижте topjohnwu's отлични ЧЗВ в Twitter. Ако просто искате да проверите дали вашето устройство е част от новия SafetyNet тест на Google, тогава можете да следвате това ръководство от XDA Senior Member Displax или изтеглете най-новата версия на Magisk Manager.


Тази статия беше актуализирана в 10:46 ч. EST на 30 юни 2020 г., за да коригира, че Google изплаща награди само за TEE уязвимости, открити в телефони Pixel. Освен това бяха добавени подробности относно най-новата версия на Magisk Manager, която вече показва полето evaluationType във вградената програма за проверка на SafetyNet.