Уразлівасць у Android, якая дазваляе абыйсці блакаванне экрана

У платформе Android выяўлена ўразлівасць (CVE-2022-20465), якая дазваляе адключыць блакіроўку экрана шляхам перастаноўкі SIM-карты і ўводу PUK-кода. Магчымасць адключэння блакавання прадэманстравана на прыладах Google Pixel, але бо выпраўленне закранае асноўную кодавую базу Android, верагодна, што праблема дакранаецца і прашывак ад іншых вытворцаў. Праблема ўхілена ў лістападаўскім наборы выпраўленняў праблем з бяспекай для Android. Які звярнуў увагу на праблему даследнік атрымаў ад кампаніі Google узнагароду, памерам 70 тысяч даляраў.

Праблема выклікана няслушнай апрацоўкай разблакіроўкі пасля ўвядзення PUK-кода (Personal Unblocking Key), які ўжываецца для аднаўлення працы SIM-карты, заблакаванай пасля шматразовага няправільнага ўвядзення PIN-кода. Для адключэння блакіроўкі экрана дастаткова ўсталяваць у тэлефон сваю SIM-карту, у якой выстаўлена абарона на аснове PIN-кода. Пасля змены SIM-карты, абароненай PIN-кодам, на экран спачатку выводзіцца запыт PIN-кода. Калі тры разы няправільна ўвесці PIN-код, адбудзецца блакіроўка SIM-карты, пасля чаго для разблакіроўкі будзе прадастаўлена магчымасць увесці PUK-код. Аказалася, што правільны ўвод PUK-кода не толькі разблакуе SIM-карту, але прыводзіць да пераходу ў асноўны інтэрфейс у абыход захавальніка экрана, без пацверджання доступу пры дапамозе асноўнага пароля або графічнага ключа.

Уразлівасць выклікана памылкай у логіцы праверкі PUK-кодаў у апрацоўшчыку KeyguardSimPukViewController, які адказвае за адлюстраванне дадатковага экрана аўтэнтыфікацыі. У Android выкарыстоўваецца некалькі тыпаў экранаў аўтэнтыфікацыі (для PIN, PUK, пароля, графічнага ключа, біяметрычнай аўтэнтыфікацыі) і гэтыя экраны выклікаюцца паслядоўна, калі патрабуецца выкананне некалькіх праверак, напрыклад, калі патрабуецца PIN і графічны ключ.

Пры правільным уводзе PIN-кода спрацоўвае другая стадыя праверкі, якая патрабуе ўводу асноўнага кода разблакіроўкі, але пры ўводзе PUK-кода падобная стадыя прапускаецца і доступ прадастаўляецца без запыту асноўнага пароля або графічнага ключа. Адкідванне наступнага этапу разблакіроўкі вырабляецца бо пры выкліку KeyguardSecurityContainerController#dismiss() не вырабляецца параўнанне чаканага і пройдзенага метаду праверкі, г.зн. апрацоўшчык лічыць, што змены метаду праверкі не адбылося і завяршэнне праверкі PUK-кода сведчыць аб паспяховым пацверджанні паўнамоцтваў.

Уразлівасць была выяўлена выпадкова - у карыстальніка разрадзіўся тэлефон і пасля зарадкі і ўключэння ён некалькі разоў памыліўся пры ўводзе PIN-кода, пасля чаго зняў блакіроўку PUK-кодам і здзівіўся, што сістэма не запытала асноўны пароль, які выкарыстоўваецца для расшыфроўкі дадзеных, пасля чаго завісла з паведамленнем "Pixel is starting…". Карыстальнік апынуўся скурпулёзным, вырашыў разабрацца ў чым справа і стаў рознымі спосабамі эксперыментаваць з уводам PIN- і PUK-кодаў, пакуль выпадкова не забыўся перазагрузіць прыладу пасля змены SIM-карты і не атрымаў замест завісання доступ да асяроддзя.

Адмысловая цікавасць уяўляе рэакцыя Google на паведамленне аб уразлівасці. Інфармацыя аб праблеме была адпраўлена ў чэрвені, але да верасня даследчык так і не змог дамагчыся зразумелага адказу. Ён палічыў, што такія паводзіны тлумачацца тым, што ён не першы, хто паведаміў аб дадзенай памылцы. Падазрэнні, што нешта ідзе не так узніклі ў верасні, калі праблема засталася нявыпраўленай пасля ўстаноўкі абнаўлення прашыўкі, упушчанага праз 90 дзён, калі ўжо скончыўся заяўлены перыяд невыдавання.

Бо ўсе спробы пазнаць стан адпраўленага паведамлення аб праблеме прыводзілі толькі да аўтаматызаваных і шаблонных адпісак, даследнік паспрабаваў звязацца асабіста з працаўнікамі Google для высвятлення сітуацыі з падрыхтоўкай выпраўлення і нават прадэманстраваў уразлівасць у лонданскім офісе Google. Толькі пасля гэтага праца па ўхіленні ўразлівасці ссунулася з мёртвай кропкі. Падчас разбору аказалася, што аб праблеме ўжо нехта паведамляў раней, але Google вырашыў зрабіць выключэнне і выплаціць узнагароду за паўторнае паведамленне аб праблеме, бо толькі дзякуючы настойлівасці яго аўтара на праблему звярнулі ўвагу.

Крыніца: opennet.ru

Дадаць каментар