Критичний руткіт MediaTek впливає на мільйони пристроїв Android

У перший понеділок кожного місяця Google публікує Бюлетень безпеки Android, сторінка, яка розкриває всі вразливості безпеки та їх виправлення, надіслані самими Google або іншими третіми сторонами. Сьогоднішній день не став винятком: Google щойно оприлюднив бюлетень безпеки Android за березень 2020 року. Однією з уразливостей, задокументованих в останньому бюлетені, є CVE-2020-0069, критичний експлойт безпеки, зокрема руткіт, який впливає на мільйони пристроїв із чіпсетами від MediaTek, великої тайванської компанії з розробки мікросхем. Хоча Бюлетень безпеки Android за березень 2020 року, здається, є першим публічним оприлюдненням CVE-2020-0069, подробиці експлойту фактично відкрито публікуються в Інтернеті, точніше, на форумах XDA-Developers, починаючи з квітня 2019 року. Незважаючи на те, що MediaTek випустила виправлення через місяць після виявлення, уразливість все ще може використовуватися на десятках моделей пристроїв.

Що ще гірше, уразливість активно використовується хакерами. Тепер MediaTek звернувся до Google, щоб усунути цю прогалину в виправленні та захистити мільйони пристроїв від цього критичного експлойту безпеки.

Для тих читачів, які не знайомі з XDA-розробники, ми є сайтом, на якому розміщені найбільші форуми для модифікацій програмного забезпечення Android. Зазвичай ці модифікації зосереджені навколо отримання кореневого доступу на пристроях, щоб видалити розповсюджене програмне забезпечення, встановити спеціальне програмне забезпечення або налаштувати параметри системи за замовчуванням. Планшети Amazon Fire є популярними цілями для хакерів-любителів на наших форумах — вони повні неінсталюваних вірусне програмне забезпечення, не мають доступу до базових програм, таких як Google Play Store, і, що найважливіше, дуже дешевий. Проблема з рутуванням планшетів Amazon Fire полягає в тому, що вони жорстко заблоковані, щоб користувачі не могли вийти за межі огородженого саду Amazon; Amazon не надає офіційного методу розблокування завантажувача планшетів Fire, який зазвичай є першим кроком у рутуванні будь-якого пристрою Android. Таким чином, єдиний спосіб рутувати планшет Amazon Fire (без апаратних модифікацій) — це знайти експлойт у програмному забезпеченні, який дозволяє користувачеві обійти модель безпеки Android. У лютому 2019 року, тобто саме те, що зробив дипломатичний старший член XDA коли він опублікував тему на наших форумах планшетів Amazon Fire. Він швидко зрозумів, що цей експлойт має набагато ширший масштаб, ніж просто планшети Amazon Fire.

Після невеликого тестування дипломатичними членами XDA та іншими членами спільноти було підтверджено, що цей експлойт працює на великій кількості мікросхем MediaTek. Автор стверджує, що експлойт працює на «практично всіх 64-розрядних чіпах MediaTek», і вони конкретно називають такі вразливими: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8 173, MT8176, MT8183, MT6580 та MT6595. Через те, скільки чіпсетів MediaTek постраждало від цього експлойту, експлойт отримав назву «MediaTek-su» або скорочено «MTK-su». 17 квітня 2019 року Diplomatic опублікував другу тему під назвою "Дивовижний тимчасовий корінь для MediaTek ARMv8" на нашому форумі "Різна розробка Android". У цій темі він поділився сценарієм, який користувачі можуть виконати, щоб надати їм доступ суперкористувача в оболонці, а також встановити SELinux, модуль ядра Linux, який забезпечує контроль доступу для процесів до дуже незахищених «дозвільних» стан. Для користувача отримати root-доступ і налаштувати SELinux на власний пристрій надзвичайно легко: все, що вам потрібно зробити, це скопіювати сценарій у тимчасову папку, змініть каталоги, де зберігається сценарій, додайте дозволи на виконання сценарію, а потім виконайте сценарій.

Члени спільноти XDA підтвердили, що експлойт працював принаймні на таких пристроях:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Серія планшетів Alba
4. Серія Alcatel 1 5033
5. Alcatel 1C
6. Серія Alcatel 3L (2018) 5034
7. Alcatel 3T 8
8. Серія Alcatel A5 LED 5085
9. Серія Alcatel A30 5049
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 — лише до Fire OS 6.3.1.2, збірка 0002517050244
15. Amazon Fire HD 8 2016 -- тільки до Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 -- тільки до Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018 -- лише до Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 -- тільки до Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019 — лише до Fire OS 7.3.1.0
20. Amazon Fire TV 2 -- лише до Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. Серія ASUS ZenPad Z3xxM(F) MT8163
24. Barnes & Noble NOOK Tablet 7" BNTV450 & BNTV460
25. Планшет Barnes & Noble NOOK 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Life Макс
29. BLU Life One X
30. Серія BLU R1
31. BLU R2 LTE
32. БЛУ S1
33. BLU Tank Xtreme Pro
34. BLU Vivo 8L
35. BLU Vivo XI
36. BLU Vivo XL4
37. Bluboo S8
38. BQ Aquaris M8
39. CAT S41
40. Coolpad Cool Play 8 Lite
41. Dragon Touch K10
42. Відчуття відлуння
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Серія Huawei Y6II MT6735
48. Lava Iris 88S
49. Серія Lenovo C2
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. LG Tribute Dynasty
55. Серія LG X power 2/M320 (MTK)
56. Серія LG Xpression Plus 2/K40 LMX420
57. Люмігон Т3
58. Meizu M5c
59. Meizu M6
60. Meizu Pro 7 Plus
61. Nokia 1
62. Nokia 1 Plus
63. Nokia 3
64. Nokia 3.1
65. Nokia 3.1 Plus
66. Nokia 5.1
67. Nokia 5.1 Plus/X5
68. На планшеті Android 7".
69. Серія планшетів Onn 8" і 10" (MT8163)
70. OPPO A5s
71. Серія OPPO F5/A73 -- лише Android 8.x
72. Серія OPPO F7 -- лише Android 8.x
73. Серія OPPO F9 -- лише Android 8.x
74. Oukitel K12
75. Протрулі D7
76. Realme 1
77. Sony Xperia C4
78. Серія Sony Xperia C5
79. Sony Xperia L1
80. Sony Xperia L3
81. Серія Sony Xperia XA
82. Серія Sony Xperia XA1
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3 серії
85. Серія Umidigi F1
86. Сила Umidigi
87. Wiko Ride
88. Віко Сонячний
89. Wiko View3
90. Серія Xiaomi Redmi 6/6A
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

читати далі

За винятком телефонів на базі MediaTek від Vivo, Huawei/Honor (після Android 8.0+), OPPO (після Android 8.0+) і Учасники спільноти Samsung і XDA виявили, що MediaTek-su частіше працює на пристроях із ураженими програмами чіпсети. За словами члена XDA Diplomatic, пристрої Vivo, Huawei/Honor, OPPO та Samsung «використовують модифікації ядра, щоб перешкоджати кореневому доступу через експлойтів", що означає, що розробнику потрібно буде копатися у вихідному коді ядра цих пристроїв, щоб створити "спеціалізовані версії" експлуатувати. Це не коштувало додаткових зусиль, тому розробник вирішив не додавати підтримку для цих пристроїв, хоча «теоретично» експлойт все ще міг працювати.

Наразі має бути зрозуміло, що цей експлойт впливає на велику кількість пристроїв на ринку. Чіпи MediaTek оснащені сотнями бюджетних і середніх моделей смартфонів, дешевих планшетів і інших брендів приставки, більшість з яких продаються без очікування своєчасних оновлень від виробника. Таким чином, багато пристроїв, на які все ще впливає MediaTek-su, навряд чи отримають виправлення протягом тижнів або місяців після сьогоднішнього розкриття, якщо вони взагалі його отримають. Отже, що змушує MediaTek-su отримати «Критичну» серйозність за допомогою a CVSS v3.0 оцінка 9,3?

Чому MTK-su є критичною вразливістю безпеки

Повторюємо, типовий спосіб отримати root-доступ на пристрої Android – це спочатку розблокувати завантажувач, який вимикає перевірку завантажувального розділу. Після того, як завантажувач розблоковано, користувач може ввести двійковий файл суперкористувача в систему, а також програму керування суперкористувачем, щоб контролювати, які процеси мають доступ до root. Розблокування завантажувача навмисно вимикає одну з ключових функцій безпеки на пристрої, тому користувач повинен явно дозволити це зробити, зазвичай увімкнувши перемикач у параметрах розробника, а потім видавши команду розблокування завантажувач. Однак із MediaTek-su користувачеві не потрібно розблоковувати завантажувач, щоб отримати root-доступ. Натомість їм потрібно лише скопіювати сценарій на свій пристрій і виконати його в оболонці. Однак користувач не єдиний, хто може це зробити. Будь-яка програма на вашому телефоні може скопіювати сценарій MediaTek-su до свого приватного каталогу, а потім виконати його, щоб отримати root-права в оболонці. Насправді член XDA дипломатичний підкреслює цю можливість у своїй темі форуму, коли вони пропонують альтернативний набір інструкцій, використовуючи або Емулятор терміналу для програми Android або Термукс а не ADB.

З кореневим доступом модель безпеки Android фактично розвалюється. Наприклад, дозволи стають безглуздими в контексті root, оскільки програма з доступом до кореневої оболонки може надати собі будь-який дозвіл, який забажає. Крім того, за допомогою кореневої оболонки доступний весь розділ даних, включаючи файли, що зберігаються в зазвичай недоступних приватних каталогах даних програм. Програма з root-правами також може мовчки встановити будь-яку іншу програму, яку вона хоче, у фоновому режимі, а потім надати їм будь-які дозволи, необхідні для порушення вашої конфіденційності. За даними XDA Recognized Developer topjohnwu, зловмисний додаток може навіть «вставити код безпосередньо в Zygote за допомогою ptrace», що означає, що звичайний додаток на вашому пристрої може бути зламано, щоб виконати накази зловмисника. Ці приклади стосуються лише кількох способів, якими програма може порушити вашу довіру у фоновому режимі без вашого відома. Однак шкідливі програми можуть завдати шкоди вашому пристрою, не приховуючи того, що вони роблять. Наприклад, програми-вимагачі надзвичайно потужний з root-доступом; якщо ви не заплатите, гіпотетична програма-вимагач може повністю і безповоротно зробити ваш пристрій непрацездатним, протерши весь пристрій.

Єдиним «слабким місцем» MediaTek-su є те, що він надає програмі лише «тимчасовий» кореневий доступ, що означає, що процес втрачає доступ суперкористувача після перезавантаження пристрою. Крім того, на пристроях під керуванням Android 6.0 Marshmallow і вище наявність Перевірене завантаження та dm-verity блокувати модифікації розділів лише для читання, таких як система та постачальник. Однак ці два чинники здебільшого лише перешкоджають моддерам на наших форумах, а не зловмисникам. Щоб подолати обмеження тимчасового root-права, шкідлива програма може просто повторно запускати сценарій MediaTek-su під час кожного завантаження. З іншого боку, немає потреби долати dm-verity, оскільки постійні модифікації системи або розділів постачальника навряд чи зацікавлять більшість авторів шкідливих програм; адже вже є тонн того, що шкідлива програма може робити з кореневою оболонкою.

Якщо вам цікаво на технічному рівні, що використовує MediaTek-su, MediaTek поділився з нами наведеною нижче таблицею, яка підсумовує точку входу. Очевидно, недолік існує в одному з драйверів ядра Linux MediaTek під назвою "CMDQ". В описі зазначено, що «виконуючи IOCTL команд у вузлі пристрою CMDQ, локальний зловмисник може «довільно читати/записувати фізичну пам’ять, скидати [] таблицю символів ядра до попередньо виділений буфер DMA [та] маніпулювати буфером DMA, щоб змінити налаштування ядра, щоб вимкнути SELinux і перейти до «кореневого» привілей».

Відповідно до діаграми, якою MediaTek поділився з нами, ця вразливість впливає на пристрої MediaTek із ядром Linux версій 3.18, 4.4, 4.9 або 4.14 під керуванням Android версій 7 Nougat, 8 Oreo або 9 Pie. Цю вразливість не можна використовувати на пристроях MediaTek під керуванням Android 10, очевидно, оскільки «дозвіл на доступ CMDQ вузлів пристроїв також забезпечується SELinux." Це пом’якшення, швидше за все, походить від оновлення BSP MediaTek, а не від Android себе. Єдиним пом’якшенням цієї вразливості в Android 10 є її обмеження програм, які виконують двійкові файли у своєму домашньому каталозі; однак, як зазначає визнаний XDA розробник topjohnwu, зловмисна програма може просто запустити код MediaTek-su в динамічній бібліотеці.

Незважаючи на те, що MediaTek виправила цю проблему на всіх уражених чіпсетах, вони не можуть змусити виробників пристроїв застосувати ці виправлення. MediaTek повідомила нам, що виправлення були готові ще в травні 2019 року. Amazon, як не дивно, негайно виправила проблему на своїх пристроях, як тільки їм стало відомо. Проте минуло 10 місяців відтоді, як MediaTek надала доступ до виправлення своїм партнерам У березні 2020 року десятки OEM-виробників не відремонтували свої пристрої. Більшість уражених пристроїв працюють на старіших версіях Android із застарілими рівнями виправлень безпеки Android (SPL), і ситуація з оновленням ще гірша, якщо врахувати сотні менш відомих моделей пристроїв, які використовують ці чіпи MediaTek. MediaTek має a серйозний проблема на руках, тому вони звернулися до Google по допомогу.

На відміну від MediaTek, Google може змусити OEM-виробників оновлювати свої пристрої через ліцензійні договори або умови програми (наприклад, Android One). Щоб OEM міг заявити, що пристрій відповідає вимогам рівня виправлення безпеки 2020-03-05 (SPL), пристрій має містити всі рамки, Виправлення ядра Linux і відповідного драйвера постачальника в бюлетені безпеки Android за березень 2020 р., який містить виправлення для CVE-2020-0069, або MediaTek-su. (Схоже, Google насправді цього не дотримується OEM-виробники фактично об’єднують усі патчі але при оголошенні певного SPL.) Тепер, коли вийшов бюлетень за березень 2020 року, ця історія має бути закінчена, чи не так? На жаль, ми також змушені тримати Google у вогні за те, що вони зволікають із впровадженням патчів.

Помилка в процесі оновлення безпеки

Якщо це ще не зрозуміло, не кожна вразливість системи безпеки повинна потрапляти в бюлетень безпеки Android. Постачальники виявляють і виправляють багато вразливостей, не повідомляючи про них у щомісячному бюлетені. MediaTek-su мав бути одним із них, але з кількох причин кілька OEM-виробників не змогли інтегрувати виправлення, запропоновані MediaTek. (Є багато потенційних причин, починаючи від браку ресурсів і бізнес-рішень до невдачі в спілкуванні.) Коли я раніше заявив, що MediaTek «звернулася до Google» за допомогою, це означало, що MediaTek активно зверталася за допомогою до Google, щоб змусити виробників нарешті виправити свої пристроїв. Однак насправді це могло бути не так. Наскільки я розумію, Google не знав про MediaTek-su, доки це випадково не було згадано у звіті безпеки від TrendMicro опубліковано 6 січня 2020 р. У звіті TrendMicro документував інший вразливість безпеки, яка називається "використовувати після-вільно в драйвері підшивки" вразливість, яку активно використовували в дикій природі. TrendMicro зазначив, як три шкідливі програми отримали кореневий доступ за допомогою одного з двох методів: уразливості «use-after-free in binder driver» або MediaTek-su.

У коді що TrendMicro ми можемо чітко бачити, як шкідливі програми націлювалися на конкретні моделі пристроїв (наприклад, Nokia 3, OPPO F9 і Redmi 6A) і використання на них MediaTek-su.

Я не можу говорити за TrendMicro, але, здається, вони не знали, що MediaTek-su — це ще не виправлений експлойт. Зрештою, їхня увага була зосереджена на експлойті «use-after-free in binder driver», і відкриття про використання MediaTek-su, здається, було запізнілою думкою. (Я впевнений, що якщо TrendMicro знали про ситуацію навколо MediaTek-su, вони координували б свої зусилля щодо розкриття інформації з Google.) Нас повідомили лише про 5 лютого 2020 року ми самі перевірили, наскільки це погано, і зв’язалися з Google 7 лютого, 2020. Google був настільки стурбований наслідками публікації MediaTek-su, що попросив нас відкласти публікацію цієї історії до сьогодні. Після врахування непоправної шкоди, яка може бути завдана користувачам, націленим на використання шкідливих програм MediaTek-su, ми погодилися затримати цю історію до анонсу Android у березні 2020 р. Бюлетень безпеки. Тим не менш, враховуючи, скільки часу знадобиться багатьом пристроям, щоб отримати останнє оновлення системи безпеки, якщо вони взагалі взагалі отримають отримати це взагалі, через кілька місяців після зараз. Це повинно викликати жах у тих, хто має вразливий пристрій.

Незважаючи на те, що ця дуже серйозна, «критична» вразливість активно використовується в дикій природі, лише Google розмістили виправлення цієї проблеми в бюлетені за березень 2020 року, приблизно через 2 місяці після того, як їм стало відомо про проблема. Хоча Google інформує своїх Android-партнерів про останній бюлетень безпеки Android за 30 днів до оприлюднення бюлетеня (тобто. На початку лютого 2020 року виробникам обладнання було повідомлено про те, що міститься в бюлетені за березень 2020 р.), Google може оновлювати бюлетень і часто оновлює його, додаючи зміни або виправляючи. Чому Google не вирішила прискорити включення виправлення для такої серйозної проблеми, я не розумію, особливо коли MediaTek знайшла її виправлення 10 місяців тому. Якби така помилка була виявлена ​​в пристроях Apple, я не сумніваюся, що вони видали б виправлення набагато, набагато швидше. Google, по суті, зробив ставку на ризиковану ставку на те, що MediaTek-su залишиться такою ж, здавалося б, маловідомою, якою вона була до березневого бюлетеня 2020 року. Хоча Google, здається, пощастило в цьому відношенні, ми не знаємо, скільки авторів шкідливого програмного забезпечення вже знають про експлойт. Зрештою, він сидів у випадковій темі форуму XDA майже цілий рік.

У цій катастрофі є ще одна сторона, про яку я не згадував, і це автор експлойту, дипломатичний член XDA. До його честі, я не думаю, що він мав злий намір, публікуючи MediaTek-su. Ми можемо чітко простежити походження експлойту до бажання дипломатів модифікувати планшети Amazon Fire. Дипломатик каже мені, що його основною метою при розробці цього кореневого методу була допомога громаді. Налаштування вашого пристрою – це те, що означає XDA, а зусилля Diplomatic у спільноті – це те, що людям подобається на форумах. Хоча відмова дипломата відкрити вихідний код проекту викликає деякі занепокоєння, він пояснює, що хотів, щоб спільнота якомога довше користувалася цим, маючи root-доступ. Коли я вперше зв’язався з дипломатичними службами, він також заявив, що він співпрацює з деякими партнерами, які заважають йому ділитися вихідним кодом проекту та дослідженнями. Хоча я не зміг отримати більше деталей про цю співпрацю, мені цікаво, чи вирішив би дипломат оприлюднити цей експлойт, якби MediaTek запропонувала програму винагороди за помилки. Я не можу уявити, що вразливість такого масштабу не виплатила б солідну суму грошей, якби у MediaTek справді була така програма. Diplomatic стверджує, що цей експлойт став можливим з кінця 2015 року на чіпсеті MediaTek MT6580, тож варто задатися питанням, чи Diplomatic взагалі є першою людиною, яка знайшла цей експлойт. Він каже мені, що не мав уявлення про активну експлуатацію MediaTek-su до публікації цієї статті.

Якщо ви хочете перевірити, чи ваш пристрій вразливий до MediaTek-su, тоді вручну запустіть сценарій, опублікований XDA Member diplomatic у цій темі форуму XDA. Якщо ви введете кореневу оболонку (ви дізнаєтеся, коли символ зміниться з $ на #), тоді ви знатимете, що експлойт працює. Якщо це працює, то вам потрібно буде дочекатися, поки виробник вашого пристрою випустить оновлення, яке виправляє MediaTek-su. Якщо ваш пристрій повідомляє про рівень безпеки 2020-03-05, який є останнім березневим 2020 SPL, то він майже напевно захищений від MediaTek-su. В іншому випадку вам доведеться просто перевірити, чи є ваш пристрій уразливим.

---

Оновлення 1 (3/2/2020 о 21:45 EST): Цю статтю було оновлено, щоб уточнити, що дипломатичний член XDA фактично знав про масштаби цієї вразливості, як тільки він виявив його ще в лютому 2019 року, але він не знав про використання експлойту в дикій природі до публікації цього стаття. Ми також виправили наше формулювання щодо однієї з причин, чому дипломати відмовилися поділитися вихідним кодом проекту.