V najnovšom blogovom príspevku Project Zero tím objavil spôsob, ako obísť ochranu jadra spoločnosti Samsung v reálnom čase s názvom Knox Hypervisor.
Tím projektu Google Project Zero overil množstvo exploitov, ktoré umožňujú napadnutie telefónov Samsung s údajne bezpečným bezpečnostným balíkom Samsung Knox. Blog poznamenáva, že všetky zraniteľnosti boli odovzdané spoločnosti Samsung, ktorá ich v januárovej aktualizácii softvéru vydala.
Pozadie
Ako súčasť balíka bezpečnostného softvéru Samsung Knox predstaveného spoločnosťou Samsung existuje softvér, ktorý sa nachádza medzi aplikáciami pre Android a jadrom, tzv. Hypervízor. Toto možno použiť ako ďalšiu vrstvu na ďalšie zabezpečenie zariadení so systémom Android. Hypervisor Samsung Knox sa nazýva „Ochrana jadra v reálnom čase“ alebo skrátene RKP, ako na to budem odkazovať vo zvyšku tohto článku.
Jadro sa nachádza pod RKP v zásobníku softvéru Android a aplikácie, ktoré bežia na zariadení, sú navrchu. Myšlienkou RKP je poskytnúť ďalšiu vrstvu zabezpečenia pre zariadenie, pretože všetky požiadavky (pamäť a iné zdroje) aplikácie do jadra musia najskôr prejsť cez Knox, ktorý sa snaží zistiť, či aplikácia niečo robí nemal by. RKP tiež poskytuje bezpečnosť prostredníctvom utajenia s ďalšou vrstvou na skrytie citlivých informácií, ktoré by aplikácia mohla použiť na kompromitáciu zariadenia.
Blogový príspevok ide dosť hlboko do toho, ako funguje pamäť Android, RKP a operačné systémy vo všeobecnosti, takže som ho zhustil a zjednodušil, aby som poskytol rýchly prehľad o tom, čo bolo objavené. Odporúčam vám prečítať si celý článok, ak máte čas, pretože je veľmi poučný.
Využiť #1:
KASLR alebo Rozloženie priestoru adries jadra Randomizácia je proces zmeny umiestnenia kódu jadra v pamäti o náhodnú hodnotu pri zavádzaní systému. Pri každom spustení zariadenia sa jadro načíta do iného adresného priestoru (oblasť v pamäti). Cieľom je sťažiť nájdenie, kde sa nachádza kód jadra, aby ste naň mohli zaútočiť, pretože po každom spustení sa kód jadra „posunie“ o náhodnú hodnotu v pamäti. Znie to ako skvelý krok na zabránenie prípadným útočníkom, ale nedávno výskumu ukázal, že to môžete skutočne poraziť bez potreby softvérovej chyby alebo zraniteľnosti, pretože KASLR je v skutočnosti veľmi ťažké implementovať robustným spôsobom proti miestnym útočníkom.
V prípade softvéru RKP je schopnosť obísť KASLR v skutočnosti jednoduchšia ako výskum uvedený vyššie. Na pamäť všetkých zariadení so systémom Android sa odkazujú ukazovatele a na ochranu zariadení pred útokom vždy, keď zariadenia so systémom Android vytlačia alebo vytlačia (či už na obrazovku alebo pri ukladaní protokolov alebo ladení), odkazy na ukazovatele sú anonymizované, - pri čítaní súboru nie je možné zistiť, kam ukazovateľ skutočne ukazuje výkon.
Predstavte si ukazovatele pamäte ako značku ulice, ktorá ukazuje na miesto, a anonymizáciu si predstavte ako rozmazanie. Podobne ako v televízii sa anonymizácia vykonáva po natáčaní, Android túto anonymizáciu používa aj pri výstupe a iba vtedy, ak je anonymizácia správne nakonfigurovaná a autor uvádza že každé zariadenie, s ktorým sa stretol, má správne nakonfigurovanú anonymizáciu ukazovateľa. Môže to znieť, že je to veľmi ťažké prelomiť, ale všetko, čo musíte urobiť, je nájsť jediný ukazovateľ (premýšľajte o značke ulice), ktorý nebol anonymizovaný (rozmazaný) vývojárom jadra (pozor, toto nie je váš priemerný vývojár aplikácií pre Android), keď je ukazovateľ zapísaný do denníkov alebo na iné miesto, napr. obrazovka alebo a súbor.
Takže ak nájdete ukazovateľ, ktorý nebol anonymizovaný, potom môžete vypočítať náhodný posun adresy jadra ako rozdiel medzi nimi. Zaujímavé je, že autor nemohol nájsť zneužiteľný ukazovateľ v jadre, ale našiel ho v RPK kde vývojári zabudli anonymizovať ukazovateľ vo výstupe ladenia (protokolovania), ktorý vznikol spôsobom preklep. Na anonymizáciu ukazovateľov v systéme Android musíte použiť špeciálny kód a ukázalo sa, že vývojári RPK omylom použili malé písmeno 'k' namiesto an veľké 'K'. Preto bolo relatívne jednoduché zistiť veľkosť náhodného posunu kódu jadra a zaútočiť naň.
Využiť #2:
Ďalší exploit je o niečo zložitejší: Samsung Knox chráni vaše zariadenie aplikovaním súboru pravidiel na pamäť zariadenia na zastavenie škodlivého kódu. Pravidlá sú nasledovné:
- Všetky stránky (kód v pamäti), s výnimkou kódu jadra, sú označené ako "Privileged Execute Never" (čo znamená, že kód sa tu nikdy nemôže spustiť)
- Dátové stránky jadra (údaje používané programom v pamäti) nie sú nikdy označené ako spustiteľné (takže kód sa tu nikdy nemôže spustiť)
- Kódové stránky jadra (kód v pamäti) nie sú nikdy označené ako zapisovateľné (takže ich nemôže zmeniť žiadny škodlivý kód)
- Všetky stránky jadra sú v prekladovej tabuľke fázy 2 označené ako iba na čítanie (tabuľka, ktorá sa nachádza medzi aplikáciou a jadrom, aby sa aplikáciám ďalej zabránilo vedieť o skutočných miestach pamäte)
- Všetky položky prekladu pamäte sú pre aplikácie označené ako určené len na čítanie.
Zameriame sa na pravidlo 3, pretože práve tu autor našiel problém s implementáciou vyššie uvedených pravidiel. RPK v skutočnosti označí pamäť pre jadro ako iba na čítanie, avšak prehliadnutím KASL bola objavená diera, ktorá viedla k písanie kódu do sekcie údajne „len na čítanie“.. Aby sa zahmlilo umiestnenie jadra pri zavádzaní, je jadru pridelená pamäť, ale toto množstvo pamäte je oveľa väčšie ako textový segment jadra. Vyhradením väčšieho množstva pamäte je oveľa ťažšie nájsť skutočný kód jadra, ktorý by mohol byť kdekoľvek, a ako sme videli vyššie, presúva sa náhodne pri každom spustení zariadenia.
Autorovi sa podarilo potvrdiť, že pamäť používaná jadrom bola skutočne označená ako „iba na čítanie“, avšak zvyšok veľkého množstva pamäte použitej na skrytie jadra bol nie označené ako „iba na čítanie“. Je to preto, že RKP chráni iba oblasť obsahujúcu text jadra po použití snímky KASLR.
Využite #3
V treťom exploite sa autorovi podarilo získať prístup k inej oblasti pamäte, ktorá by mala byť tiež obmedzená len na čítanie. RKP chráni pamäť a využíva a Register konfigurácie hypervízora (HCR) na ovládanie kľúčových operácií jadra. Cieľom HCR je umožniť platným a skutočným operáciám jadra prístup k registrom a blokovať škodlivé útoky. Robí to kontrolou volaní uskutočnených do registrov, ktoré riadia funkcie virtualizácie. HCR je nakonfigurovaný tak, aby blokoval špecifické operácie, ktoré by sa normálne vykonávali, čo umožňuje RKP vybrať si, či povolí alebo nepovolí požiadavku.
Pri tomto využití bola kontrola HCR nepokrývajú dva registre to sa ukázalo ako veľmi dôležité. Autor sa pohrabal hlboko v príručke ARM Reference a zistil, že prvý register mu umožnil v podstate vypnúť RKP pre aplikácie. "Systémový riadiaci register pre EL1 (SCTLR_EL1) poskytuje najvyššiu úroveň kontroly nad systémom vrátane pamäťového systému." V dokonalom svete by aplikácia používala pamäť, ktorá bola mapovaná prostredníctvom RKP, aby RKP mohla kontrolovať, k čomu má aplikácia prístup. Vypnutie tohto registra však umožnilo RKP deaktivovať efektívnym vrátením zariadenia do stavu, v akom fungovalo pred nainštalovaním RKP – čo znamená, že zariadenie je namapované do fyzickej pamäte bez dodatočného zabezpečenia, ktoré poskytuje RKP. To zase znamenalo, že autor mohol čítať a zapisovať do pamäte, ktorá bola pôvodne a správne zablokovaná softvérom RKP.
Druhý register, ktorý sa minul, mal jemnejší účinok, ale v konečnom dôsledku rovnako zničujúci pre bezpečnosť. The Register kontroly prekladov pre EL1 Register (TCR_EL1) priamo súvisí s množstvom pamäte, s ktorou aplikácia pracuje, nazývaná stránka. RKP je pevne zakódovaný na veľkosť stránky 4 kB, pretože linuxové jadrá AARCH64 (napríklad Android) používajú veľkosť prekladu 4 kB. Príslušný register (TCR_EL1) nastavuje čipové sady ARM na veľkosť pamäte, ktorá sa má vrátiť. Ukazuje sa, že tento register nie je chránený HCR a preto to útočník môže zmeniť tak, ako to autor zmenil na veľkosť stránky 64 kb.
To znamená, že keď RKP splní požiadavku, skutočné množstvo dostupnej pamäte je teraz 64 kb namiesto 4 kb. Dôvodom je, že čipset ARM stále kontroluje veľkosť stránky a exploit bol nastavený na 64 kb. Keďže RKP chráni pamäť pred zápisom, ako súčasť pravidiel uvedených v exploite #2, pamäť je stále skutočne chránená. Ale tu je háčik - keďže RKP je napevno zakódovaný na 4 kb, pri aktualizácii registra sa nemení na veľkosť stránky 64 kb, takže chránené sú iba prvé 4 kb pamäte čo umožňuje útočníkovi urobiť čo chce so zvyšnými 60kb.
Využite #4
Posledným exploitom, ktorý autor ukazuje, je odkazovanie na pamäť, kde je softvér RKP, takže útočník by mohol napadnúť samotný softvér RKP. Jeden trik na zastavenie tohto typu útoku, ktorý používajú aj jadrá Linuxu, je odmapovať váš program z adresného priestoru virtuálnej pamäte, aby ho žiadne aplikácie nemohli napadnúť, pretože naň nemôžu odkazovať.
Pamätajte, že pamäť je o ukazovateľoch a tabuľkách, ktoré mapujú fyzickú pamäť na virtuálnu pamäť. Podľa normálnej obrany pri tomto type útoku sa RKP odmapuje, takže nemôže byť napadnuté. Avšak tam, kde jadro neposkytuje takéto schopnosti, RKP umožňuje namapovať časť pamäte a označiť ju ako Read/Write. Jedinou kontrolou je, že to nie je samotné jadro, pretože RKP nekontroluje, či adresy, ktoré sa majú zmapovať, sú oblasťou, kde sa samotný RKP nachádza v pamäti. V podstate RKP nechá sa premapovať späť do adresného priestoru, ku ktorému môžu aplikácie pristupovať, a ako vedľajší účinok ovplyvňujú pamäť je automaticky označená ako Read/Write takže útočník môže teraz použiť pamäť, ako chce.
Záver
Jedným z najväčších problémov so štyrmi exploitmi uvedenými vyššie je, že autor spomína, aké ťažké by ich bolo vykonať kvôli nedostatku funkcií v základnom jadre Androidu. Je iróniou, že bezpečný RKP Hypervisor poskytoval všetky nástroje, ktoré boli potrebné na vykonanie útokov. Ukazuje sa, že niekedy dobre mienený softvér spôsobuje viac problémov, ako rieši, a my sme šťastní, že máme ľudí ako Gal Beniamini ochotný zašpiniť si ruky a otestovať, že dokumentácia sa zhoduje so softvérom v skutočnosti robí.
Aj keď tieto zneužitia vyzerajú strašidelne a robia Knoxa veľmi zraniteľným, rád by som všetkých uistil, že všetky tieto problémy boli opravené v januárovej aktualizácii od spoločnosti Samsung. Okrem toho tieto exploity vyžadujú veľmi hlboké pochopenie ARM procesorov a programovania, takže bariéra vstupu do používania týchto exploitov je astronomicky vysoká.
Zdroj: Project Zero