StrandHogg 2.0 е опасна нова уязвимост на Android. Ето как може да засегне потребителите и как разработчиците могат да защитят приложенията си срещу него.
Часът е 22:00. Знаете ли къде са вашите дейности? Има нова уязвимост, която може да бъде използвана на милиони устройства с Android и също е доста неприятна. Накратко, този дефект в дизайна позволява на атакуващия да представи своя собствена активност (страница) върху друго приложение, потенциално обърквайки потребителя да раздаде личните си данни. Уязвимостта е наречена StrandHogg 2.0 и наскоро беше разкрита от Промоция, норвежка охранителна фирма.
Уязвимостта StrandHogg 2.0 теоретично засяга всички Android устройства, работещи с версии на Android от Honeycomb (3.0) до Android 9 Pie (9.0). Базиран на статистика за разпространение на последната версия на Android, това означава, че приблизително 91,8% от всички устройства с Android са уязвими към StrandHogg 2.0. Уязвимостта беше определена CVE-2020-0096 и му беше дадена ниво на тежест на "критично".
Не изисква никакви специални разрешения за работа и може да функционира почти изцяло без намеса на потребителя. Всичко, което потребителят трябва да направи, е да отвори приложение със злонамерен код, скрит в него, и тогава той е уязвим за експлоатация.Promon беше достатъчно любезен да ни изпрати своето приложение за доказателство на концепцията и неговия изходен код, за да можем най-добре обяснете как работи експлойтът, защо има значение за потребителите и как разработчиците могат да защитят своите приложения срещу него.
Как работи
Да приемем, че използвате Gmail и щракнете върху уеб връзка. Ако отидете на екрана на скорошните си приложения, може да забележите, че уеб страницата изглежда е „вътре“ в Gmail. Визуализацията показва уебсайта, но иконата и името на приложението все още са от Gmail. Това е нещо, което се случва, когато приложение/Дейност стартира друго приложение/Дейност в същата задача. Сега си представете, че не сте отворили тази връзка нарочно. За вас изглежда, че е само част от приложението Gmail. Това е поведението, което StrandHogg 2.0 използва.
Тук ще трябва да пропуснем някои подробности, но ето приблизително как работи този експлойт. За следното нека приемем, че атакуващият иска да получи данните за вход в Gmail на потребителя.
- Потребителят изтегля злонамерено приложение (разбира се, без да знае, че е злонамерено) и го отваря.
- Във фонов режим приложението отваря Gmail, поставя подобен на вход Activity върху него и след това стартира друга Activity.
- Потребителят отваря Gmail и вижда нещо, което прилича на екрана за влизане в Gmail, но всъщност е фишинг дейността на нападателя.
Последната дейност, стартирана в стъпка 2, може да бъде всичко, което избягва подозрението. Приложението може да симулира срив и да се върне към началния екран или може просто да отвори основната си дейност, сякаш нищо не се е случило. Единственото подозрително нещо, което потребителят може да види, е куп отварящи анимации при стартиране на всички дейности. Най-лошата част: дори няма да изглежда, че Gmail е отворен.
Разбира се, нападателят може да направи повече от това просто да покаже фалшив екран за влизане. Вместо това злонамерено приложение може да представи подкана за разрешения, като подмами потребителя да предостави нежелани разрешения. Въпреки че искането на някакви специални разрешения като Достъпност може да направи потребителя подозрителен, възможно е да нанесете много щети с нещо като Достъп до съхранение.
Техническите части
Този следващ раздел е преглед на високо ниво на това как работи StrandHogg 2.0. Promon няма да публикува пълните подробности още няколко месеца, така че не можем да споделим как точно се прилага този експлойт. Все пак има някои технически подробности, за които можем да говорим.
С две думи, StrandHogg 2.0 отвлича Android Context.startActivities() API метод, използващ три намерения.
- Първото намерение е това, което стартира, в нашия пример, Gmail. Маркирано е с
Intent.FLAG_ACTIVITY_NEW_TASK. - Второто намерение е злонамереното. В нашия пример това е за дейността за влизане с прилика. Това намерение няма флагове.
- Третото намерение е разсейването. Той гарантира, че потребителят не е подозрителен към случайно отваряне на Gmail вместо приложението, което е докоснал (т.е. това, което стартира атаката). Маркирано е с
Intent.FLAG_ACTIVITY_NEW_TASK.
Всички тези намерения след това се предават в масив към startActivities() метод.
Липсата на флагове на второто намерение е ключът тук. Правейки това, ние просто репликирахме примера на Gmail от по-горе. Технически задачата е на Gmail, но най-горната активност е на атакуващия. Когато след това потребителят щракне върху иконата на началния екран на Gmail, активността на атакуващия се показва вместо тази на Gmail.
Доказване на концепцията
С информацията, която Promon ни изпрати, успяхме да възпроизведем тяхното доказателство за концепцията. Ето запис на екран от Samsung Galaxy Note8 с Android 9 Pie, който го показва в действие.
Техники и проблеми за смекчаване
Сега, просто копиране на горното в код всъщност няма да работи. Това не е пълен пример и има няколко други неща, които атакуващият трябва да направи, за да работи, които не можем да споделим. Но не е особено трудно да ги познаете сами и това е част от това, което прави тази атака толкова опасна. StrandHogg 2.0 е сравнително лесен експлойт за прилагане и труден за смекчаване.
Смекчаването не може да включва просто поставяне в черен списък на всички приложения, които използват startActivities(), тъй като има много законни приложения за него. Също така е наистина трудно да се автоматизира алгоритъм за откриване за него. Злонамерените разработчици могат да използват всякакви трикове, за да направят внедряването на StrandHogg 2.0 ефективно невидимо за услуги като Google Play Protect. StrandHogg 1.0 изисква от атакуващия да добави атрибут в AndroidManifest.xml на злонамереното приложение, което е относително лесно за откриване. StrandHogg 2.0, от друга страна, функционира изцяло в Java/Kotlin.
Като се вземат предвид обфускацията, отражението и дори само различните стилове на кодиране, изглежда непрактично автоматично да се открие правилно приложение, което използва този експлойт. Нещо повече е, че ако даден потребител е обект на StrandHogg 2.0 атака, той може дори да не знае. Ако отворите Gmail и видите неговия екран за вход, може просто да си помислите, че сесията ви е изтекла и да въведете данните си за вход, без да се замисляте.
Когато се свързахме с Google за отговор, говорител предложи следното изявление:
„Оценяваме работата на изследователите и пуснахме корекция за проблема, който идентифицираха. Освен това Google Play Protect открива и блокира злонамерени приложения, включително такива, които използват тази техника."
Това звучи добре и се надяваме, че има поне някакъв ефект срещу атаките на StrandHogg 2.0. Заслужава да се отбележи обаче, че Google Play Protect не бях разпознават нашето приложение за доказателство на концепцията като злонамерено дори след извършване на ръчно сканиране.
Promon казва, че те "не са забелязали злонамерен софтуер в реалния живот, използващ уязвимостта на StrandHogg 2.0”, но няма гаранция, че експлойтът е открит за първи път. Поради тази причина Promon препоръчва на разработчиците да продължат напред и да защитят приложенията си, като зададат активността на своя стартер launchMode флаг на едно от двете singleTask или singleInstance. Всеки от тези флагове ще предотврати инжектирането на задача, на което StrandHogg 2.0 разчита. Въпреки това, ако вашата дейност използва един от тези флагове, може да причини проблеми с определени потоци на приложения, така че не винаги е желателно.
Promon също така рекламира своя собствен продукт „Защита в приложението от Promon SHIELD“, който звучи като библиотека които разработчиците на приложения могат да внедрят, за да наблюдават задачите в процеса на приложението ви, за да проверяват за нередности вмъквания. Тъй като няма наистина ефективна стратегия за смекчаване на разработчиците или потребителите, е много важно производителите да внедрят корекцията, за да коригират това възможно най-скоро.
За щастие, Promon следваше указанията за отговорно разкриване, преди да направи публично достояние този експлойт (и все още не е напълно публичен—Promon чака 90 дни, преди да разкрие напълно как StrandHogg 2.0 върши работа). Оттогава Google пренесе обратно корекции за този експлойт към Android 8.0 Oreo, Android 8.1 Oreo и Android 9 Pie с Ниво на корекция за сигурност на Android от май 2020 г. (SPL). Потребителите на Android 10 и по-нови версии не са уязвими, въпреки че не сме напълно сигурни защо е така. Вероятно има нещо общо с новите ограничения на Android 10 относно стартирането на дейности и как Google ги интегрира в стека на задачите. Promon казва, че „на Android 10 атаката е напълно неефективна и дейностите се разделят на различни задачи и в отделни стекове задачи според adb shell dumpsys activity activities."
Ако производителят на вашето устройство все още предоставя актуализации за защита (можете да прочетете повече за как работи процесът на корекция за сигурност тук), трябва да ги досаждате за актуализация възможно най-скоро. В противен случай просто ще трябва да внимавате кои приложения изтегляте и стартирате (въпреки че така или иначе трябва да го правите).
За повече подробности и случаи на употреба на StrandHogg 2.0 вижте официално съобщение на уебсайта на Promon. За персонализирани разработчици на ROM можете да намерите съответните ангажименти на AOSP за предотвратяване на атаки на StrandHogg 2.0 тук и тук.
График на разкриването
Ето графика за разкриване, който Promon сподели в своя документ StandHogg 2.0:
- 4 декември 2019 г – Докладван проблем на Google
- 4 декември 2019 г – Сподели PoC „злонамерено приложение“ и видео с Google
- 4 декември 2019 г – Google потвърди получаването на доклада
- 9 декември 2019 г – Google зададе сериозността на находката като «Критична»
- 9 декември 2019 г – Google потвърждава, че е в състояние да възпроизведе проблема
- 14 февруари 2020 г – Информираме Google, че 90-дневното разкриване наближава в началото на март и искаме статус от тяхна страна
- 14 февруари 2020 г – Google отговаря, че април е най-скорошният момент, в който могат да пуснат корекция
- 14 февруари 2020 г – Информираме Google, че работим по смекчаване
- 14 февруари 2020 г – отговаря Google. Те работят по ремонти и питат дали можем да споделим какви смекчаващи мерки препоръчваме
- 17 февруари 2020 г – Уведомяваме Google, че можем да задържим разкриването до април. Искаме CVE номера
- 17 февруари 2020 г – Споделяме нашите стратегии за смекчаване, както и как предвиждаме смекчаване на платформата
- 23 март 2020 г – Google отговаря с CVE ID (CVE-2020-0096)
- 23 март 2020 г – Google отговаря, че общата наличност на корекцията за Android ще бъде налична през май
- 23 март 2020 г – Google пита дали ще обмислим отлагане на разкриването до Мей
- 27 март 2020 г – Отговаряме, че ще отложим разкриването до май
- 22 април 2020 г – Google ни информира, че майският бюлетин за сигурността е планиран да съдържа корекция за уязвимостта