Kritisches MediaTek-Rootkit betrifft Millionen von Android-Geräten

An jedem ersten Montag im Monat veröffentlicht Google die Android-Sicherheitsbulletin, eine Seite, die alle von Google selbst oder anderen Dritten übermittelten Sicherheitslücken und deren Patches offenlegt. Heute war keine Ausnahme: Google hat gerade das Android Security Bulletin für März 2020 veröffentlicht. Eine der im neuesten Bulletin dokumentierten Schwachstellen ist CVE-2020-0069, eine kritische Sicherheitslücke, insbesondere eine Rootkit, das Millionen von Geräten mit Chipsätzen von MediaTek, dem großen taiwanesischen Chipdesign-Unternehmen, betrifft. Obwohl das Android Security Bulletin vom März 2020 anscheinend das erste Mal ist, dass CVE-2020-0069 öffentlich bekannt gegeben wurde, Einzelheiten des Exploits liegen bereits seit April offen im Internet – genauer gesagt in den XDA-Developers-Foren von 2019. Obwohl MediaTek einen Monat nach Entdeckung einen Patch zur Verfügung stellt, ist die Schwachstelle immer noch auf Dutzenden von Gerätemodellen ausnutzbar.

Schlimmer noch: Die Sicherheitslücke wird von Hackern aktiv ausgenutzt. Jetzt hat sich MediaTek an Google gewandt, um diese Patch-Lücke zu schließen und Millionen von Geräten vor dieser kritischen Sicherheitslücke zu schützen.

Für alle Leser, die es nicht kennen XDA-Entwickler, wir sind eine Website, die die größten Foren für Android-Softwaremodifikationen beherbergt. Normalerweise geht es bei diesen Modifikationen darum, Root-Zugriff auf Geräte zu erlangen, um Bloatware zu löschen, benutzerdefinierte Software zu installieren oder Standardsystemparameter zu optimieren. Die Fire-Tablets von Amazon sind in unseren Foren beliebte Ziele für Hobby-Hacker – sie stecken voller nicht installierbarer Dateien Bloatware, haben keinen Zugriff auf grundlegende Softwareanwendungen wie den Google Play Store und sind, was am wichtigsten ist, sehr billig. Die Herausforderung beim Rooten von Amazon Fire-Tablets besteht darin, dass sie stark gesperrt sind, um zu verhindern, dass Benutzer den ummauerten Garten von Amazon verlassen. Amazon bietet keine offizielle Methode zum Entsperren des Bootloaders von Fire-Tablets an. Dies ist normalerweise der erste Schritt beim Rooten eines bestimmten Android-Geräts. Daher besteht die einzige Möglichkeit, ein Amazon Fire-Tablet zu rooten (ohne Hardware-Änderungen), darin, einen Exploit in der Software zu finden, der es dem Benutzer ermöglicht, das Sicherheitsmodell von Android zu umgehen. Im Februar 2019 also genau das, was XDA Senior Member diplomatic getan hat als er einen Thread in unseren Amazon Fire-Tablet-Foren veröffentlichte. Er erkannte schnell, dass dieser Exploit weitaus umfangreicher war als nur die Fire-Tablets von Amazon.

Nach einigen Tests durch diplomatische XDA-Mitglieder und andere Community-Mitglieder wurde bestätigt, dass dieser Exploit auf einer großen Anzahl von MediaTek-Chips funktioniert. Der Autor gibt an, dass der Exploit auf „praktisch allen 64-Bit-Chips von MediaTek“ funktioniert, und nennt insbesondere Folgendes als angreifbar: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6 580, und MT6595. Da viele MediaTek-Chipsätze von diesem Exploit betroffen waren, erhielt der Exploit den Namen „MediaTek-su“ oder kurz „MTK-su“. Am 17. April 2019 veröffentlichte Diplomatic einen zweiten Thread mit dem Titel „Erstaunlicher temporärer Root für MediaTek ARMv8" in unserem Forum „Verschiedene Android-Entwicklung“. In diesem Thread teilte er ein Skript mit, das Benutzer ausführen können, um ihnen Superuser-Zugriff in der Shell zu gewähren und festzulegen SELinux, das Linux-Kernelmodul, das die Zugriffskontrolle für Prozesse bis hin zu den äußerst unsicheren „permissiven“ Prozessen bereitstellt. Zustand. Für einen Benutzer ist es erschreckend einfach, Root-Zugriff zu erhalten und SELinux auf seinem eigenen Gerät auf „Permissiv“ zu setzen: Alles, was Sie tun müssen, ist, das zu kopieren Skript in einen temporären Ordner, ändern Sie die Verzeichnisse, in denen das Skript gespeichert ist, fügen Sie dem Skript ausführbare Berechtigungen hinzu und führen Sie es dann aus Skript.

Mitglieder der XDA-Community bestätigten, dass der Exploit zumindest auf den folgenden Geräten funktionierte:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Alba Tablet-Serie
4. Alcatel 1 5033-Serie
5. Alcatel 1C
6. Alcatel 3L (2018) 5034-Serie
7. Alcatel 3T 8
8. Alcatel A5 LED 5085-Serie
9. Alcatel A30 5049-Serie
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 – nur bis Fire OS 6.3.1.2 Build 0002517050244
15. Amazon Fire HD 8 2016 – nur bis Fire OS 5.3.6.4 Build 626533320
16. Amazon Fire HD 8 2017 – nur bis Fire OS 5.6.4.0 Build 636558520
17. Amazon Fire HD 8 2018 – nur bis Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 – nur bis Fire OS 5.6.4.0 Build 636558520
19. Amazon Fire HD 10 2019 – nur bis Fire OS 7.3.1.0
20. Amazon Fire TV 2 – nur bis Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163-basierte Serie
24. Barnes & Noble NOOK Tablet 7" BNTV450 & BNTV460
25. Barnes & Noble NOOK Tablet 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Life Max
29. BLU Life One X
30. BLU R1-Serie
31. BLU R2 LTE
32. BLU 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. KATZE S41
40. Coolpad Cool Play 8 Lite
41. Dragon Touch K10
42. Echogefühl
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Huawei Y6II MT6735-Serie
48. Lava Iris 88S
49. Lenovo C2-Serie
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-Serie (MTK)
56. LG Xpression Plus 2/K40 LMX420-Serie
57. Lumigon T3
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. Onn 7" Android-Tablet
69. Onn 8"- und 10"-Tablet-Serie (MT8163)
70. OPPO A5s
71. OPPO F5-Serie/A73 – nur Android 8.x
72. OPPO F7-Serie – nur Android 8.x
73. OPPO F9-Serie – nur Android 8.x
74. Oukitel K12
75. Protruly D7
76. Reich 1
77. Sony Xperia C4
78. Sony Xperia C5-Serie
79. Sony Xperia L1
80. Sony Xperia L3
81. Sony Xperia XA-Serie
82. Sony Xperia XA1-Serie
83. Southern Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3-Serie
85. Umidigi F1-Serie
86. Umidigi Power
87. Wiko Ride
88. Wiko Sunny
89. Wiko View3
90. Xiaomi Redmi 6/6A-Serie
91. ZTE Blade A530
92. ZTE Blade D6/V6
93. ZTE Quest 5 Z3351S

mehr lesen

Mit Ausnahme von MediaTek-basierten Telefonen von Vivo, Huawei/Honor (nach Android 8.0+), OPPO (nach Android 8.0+) und Mitglieder der Samsung- und Chipsätze. Laut XDA-Mitglied diplomatic verwenden Vivo-, Huawei/Honor-, OPPO- und Samsung-Geräte „Kernel-Modifikationen, um Root-Zugriff über zu verhindern.“ Exploits“, was bedeutet, dass der Entwickler in den Kernel-Quellcode dieser Geräte eintauchen müsste, um „maßgeschneiderte Versionen“ davon zu erstellen ausbeuten. Das war den zusätzlichen Aufwand nicht wert, daher entschied sich der Entwickler, keine Unterstützung für diese Geräte hinzuzufügen, obwohl der Exploit „theoretisch“ immer noch funktionieren könnte.

Mittlerweile sollte klar sein, dass dieser Exploit eine große Anzahl an Geräten auf dem Markt betrifft. MediaTek-Chips treiben Hunderte Budget- und Mittelklasse-Smartphone-Modelle, günstige Tablets und Fremdmarken an Set-Top-Boxen, von denen die meisten ohne die Erwartung rechtzeitiger Updates vom Hersteller verkauft werden. Es ist daher unwahrscheinlich, dass viele Geräte, die noch immer von MediaTek-su betroffen sind, Wochen oder Monate nach der heutigen Offenlegung eine Lösung erhalten, wenn sie überhaupt eine erhalten. Was bringt MediaTek-su also dazu, den Schweregrad „Kritisch“ mit einem zu verdienen? CVSS v3.0 Punktzahl von 9,3?

Warum MTK-su eine kritische Sicherheitslücke ist

Um es noch einmal zu wiederholen: Der typische Weg, Root-Zugriff auf einem Android-Gerät zu erhalten, besteht darin, zunächst den Bootloader zu entsperren, wodurch die Überprüfung der Boot-Partition deaktiviert wird. Sobald der Bootloader entsperrt ist, kann der Benutzer eine Superuser-Binärdatei in das System einführen und auch eine Superuser-Verwaltungs-App, um zu steuern, welche Prozesse Zugriff auf Root haben. Durch das Entsperren des Bootloaders wird absichtlich eine der wichtigsten Sicherheitsfunktionen des Geräts deaktiviert, weshalb der Benutzer dies tun muss Erlauben Sie dies explizit, indem Sie normalerweise einen Schalter in den Entwickleroptionen aktivieren und dann einen Entsperrbefehl an den ausführen Bootloader. Bei MediaTek-su muss der Benutzer den Bootloader jedoch nicht entsperren, um Root-Zugriff zu erhalten. Stattdessen müssen sie lediglich ein Skript auf ihr Gerät kopieren und es in der Shell ausführen. Der Benutzer ist jedoch nicht der Einzige, der dies tun kann. Jede App auf Ihrem Telefon kann das MediaTek-su-Skript in ihr privates Verzeichnis kopieren und es dann ausführen, um Root-Zugriff in der Shell zu erhalten. Tatsächlich ist das XDA-Mitglied diplomatisch unterstreicht diese Möglichkeit in ihrem Forenthread, wenn sie einen alternativen Satz von Anweisungen mit entweder dem vorschlagen Terminal-Emulator für Android-App oder Termux statt ADB.

Mit dem Root-Zugriff bricht das Sicherheitsmodell von Android grundsätzlich zusammen. Beispielsweise werden Berechtigungen im Kontext von Root bedeutungslos, da eine App mit Zugriff auf eine Root-Shell sich selbst jede gewünschte Berechtigung erteilen kann. Darüber hinaus ist mit einer Root-Shell die gesamte Datenpartition – einschließlich der Dateien, die in den normalerweise unzugänglichen privaten Datenverzeichnissen von Anwendungen gespeichert sind – zugänglich. Eine App mit Root kann auch stillschweigend jede andere gewünschte App im Hintergrund installieren und ihr dann alle erforderlichen Berechtigungen erteilen, um Ihre Privatsphäre zu verletzen. Laut XDA Recognized Developer topjohnwu, kann eine bösartige App sogar „Code mithilfe von ptrace direkt in Zygote einschleusen“, was bedeutet, dass eine normale App auf Ihrem Gerät gekapert werden könnte, um die Befehle des Angreifers auszuführen. Diese Beispiele berühren nur einige Möglichkeiten, wie eine App Ihr ​​Vertrauen im Hintergrund ohne Ihr Wissen verletzen kann. Allerdings können bösartige Apps auf Ihrem Gerät verheerende Schäden anrichten, ohne zu verbergen, was sie tun. Ransomware zum Beispiel ist es äußerst leistungsstark mit Root-Zugriff; Wenn Sie nicht zahlen, könnte es eine hypothetische Ransomware-App sein völlig und unwiderruflich Machen Sie Ihr Gerät funktionsunfähig, indem Sie das gesamte Gerät sauber wischen.

Die einzige „Schwäche“ von MediaTek-su besteht darin, dass es einer Anwendung nur „vorübergehenden“ Root-Zugriff gewährt, was bedeutet, dass ein Prozess nach einem Geräteneustart den Superuser-Zugriff verliert. Darüber hinaus ist auf Geräten mit Android 6.0 Marshmallow und höher das Vorhandensein von Verifizierter Boot- und DM-Verity Blockieren Sie Änderungen an schreibgeschützten Partitionen wie System und Hersteller. Allerdings sind diese beiden Faktoren meist nur Hindernisse für Modder in unseren Foren und nicht für böswillige Akteure. Um die Einschränkung des temporären Roots zu überwinden, kann eine bösartige App das MediaTek-su-Skript einfach bei jedem Start erneut ausführen. Andererseits besteht kaum Bedarf, dm-verity zu überwinden, da dauerhafte Änderungen am System oder an Herstellerpartitionen für die meisten Malware-Autoren wahrscheinlich kein Interesse darstellen; gibt es schließlich schon Tonnen Was eine bösartige App mit einer Root-Shell anstellen kann.

Wenn Sie sich auf technischer Ebene fragen, was MediaTek-su ausnutzt, hat MediaTek die folgende Tabelle mit uns geteilt, die den Einstiegspunkt zusammenfasst. Der Fehler besteht offenbar in einem der Linux-Kernel-Treiber von MediaTek namens „CMDQ“. In der Beschreibung heißt es: „Durch die Ausführung von IOCTL Befehle im CMDQ-Geräteknoten ausführen, kann ein lokaler Angreifer „den physischen Speicher willkürlich lesen/schreiben, [die] Kernel-Symboltabelle in den kopieren Vorab zugewiesener DMA-Puffer, [und] manipulieren Sie den DMA-Puffer, um die Kernel-Einstellungen zu ändern, um SELinux zu deaktivieren und zu „root“ zu eskalieren. Privileg."

Laut der Tabelle, die MediaTek mit uns geteilt hat, betrifft diese Schwachstelle MediaTek-Geräte mit den Linux-Kernel-Versionen 3.18, 4.4, 4.9 oder 4.14 und den Android-Versionen 7 Nougat, 8 Oreo oder 9 Pie. Die Schwachstelle ist auf MediaTek-Geräten mit Android 10 offenbar nicht ausnutzbar, da „die Zugriffsberechtigung von CMDQ Geräteknoten werden auch von SELinux erzwungen.“ Diese Abhilfe ist wahrscheinlich eher auf ein Update des BSP von MediaTek als auf Android zurückzuführen selbst. Die einzige Abhilfemaßnahme von Android 10 für diese Sicherheitslücke ist Einschränkung für Apps, die Binärdateien in ihrem Home-Verzeichnis ausführen; Allerdings kann eine bösartige App, wie XDA Recognized Developer topjohnwu feststellt, einfach den MediaTek-su-Code in einer dynamischen Bibliothek ausführen.

Obwohl MediaTek dieses Problem in allen betroffenen Chipsätzen behoben hat, können sie Gerätehersteller nicht zwingen, die Patches zu implementieren. MediaTek teilte uns mit, dass sie bereits im Mai 2019 Patches bereit hätten. Es überrascht nicht, dass Amazon das Problem sofort auf seinen Geräten behoben hat, nachdem es darauf aufmerksam gemacht wurde. Es sind jedoch 10 Monate vergangen, seit MediaTek seinen Partnern einen Fix zur Verfügung gestellt hat Im März 2020 haben Dutzende OEMs ihre Geräte nicht repariert. Bei den meisten betroffenen Geräten handelt es sich um ältere Android-Versionen mit veralteten Android Security Patch Levels (SPLs), und die Update-Situation ist noch schlimmer, wenn man bedenkt, dass Hunderte von weniger bekannten Gerätemodellen, die diese MediaTek-Chips verwenden. MediaTek hat eine ernst Hier liegt ein Problem vor, daher haben sie sich hilfesuchend an Google gewandt.

Im Gegensatz zu MediaTek, Google dürfen zwingen OEMs dazu, ihre Geräte zu aktualisieren Lizenzvereinbarungen oder Programmbedingungen (z. B. Android One). Damit ein OEM erklären kann, dass ein Gerät dem Security Patch Level (SPL) vom 05.03.2020 entspricht, muss das Gerät alle Frameworks enthalten. Linux-Kernel und anwendbare Herstellertreiber-Fixes im Android Security Bulletin vom März 2020, das einen Fix für CVE-2020-0069 enthält, oder MediaTek-su. (Google scheint das nicht wirklich durchzusetzen OEMs führen tatsächlich alle Patches zusammen allerdings bei der Angabe eines bestimmten Schalldruckpegels.) Jetzt, da das Bulletin vom März 2020 erschienen ist, sollte diese Geschichte vorbei sein, oder? Leider müssen wir auch Google dafür rügen, dass es bei der Einarbeitung der Patches zu langsam war.

Der Fehler im Sicherheitspatch-Prozess

Falls es noch nicht klar ist: Nicht jede Sicherheitslücke muss in einem Android-Sicherheitsbulletin aufgeführt werden. Viele Schwachstellen werden von Anbietern entdeckt und behoben, ohne dass sie jemals im monatlichen Bulletin erscheinen. MediaTek-su hätte einer von ihnen sein sollen, aber aus mehreren Gründen scheiterten mehrere OEMs daran, die von MediaTek angebotenen Patches zu integrieren. (Dafür gibt es viele mögliche Gründe, die von einem Mangel an Ressourcen über Geschäftsentscheidungen bis hin zu Kommunikationsfehlern reichen.) Als ich zuvor erklärte, dass MediaTek sich „an Google gewandt“ habe, um Hilfe zu erhalten. Dies deutete an, dass MediaTek aktiv Google um Hilfe gebeten habe, um OEMs dazu zu bringen, ihr Problem endlich zu beheben Geräte. Allerdings könnte das tatsächlich nicht der Fall gewesen sein. Soweit ich weiß, wusste Google nichts von MediaTek-su, bis es zufällig in einem Sicherheitsbericht von erwähnt wurde Trend Micro veröffentlicht am 6. Januar 2020. Im Bericht Trend Micro dokumentierte ein anderer Sicherheitslücke, genannt „Use-After-Free im Binder-Treiber„Sicherheitslücke, die in freier Wildbahn aktiv ausgenutzt wurde. Trend Micro stellte fest, wie drei bösartige Apps über eine von zwei Methoden Root-Zugriff erlangten, entweder über die Schwachstelle „Use-after-free in binder Driver“ oder über MediaTek-su.

Im Code das Trend Micro geteilt, können wir deutlich erkennen, wie die bösartigen Apps auf bestimmte Gerätemodelle abzielten (z. Nokia 3, OPPO F9 und Redmi 6A) und die Verwendung von MediaTek-su darauf.

Ich kann nicht dafür sprechen Trend Micro, aber es scheint, dass sie nicht wussten, dass MediaTek-su ein noch ungepatchter Exploit war. Ihr Fokus lag schließlich auf dem Exploit „Use-After-Free in Binder Driver“, und die Entdeckung der Verwendung von MediaTek-su scheint ein nachträglicher Einfall gewesen zu sein. (Ich bin sicher, wenn Trend Micro (Wer sich der Situation rund um MediaTek-su bewusst war, hätte seine Offenlegungsbemühungen mit Google koordiniert.) Wir wurden lediglich darauf aufmerksam gemacht Wir haben diesen Exploit am 5. Februar 2020 selbst ausgenutzt und nachdem wir selbst untersucht hatten, wie schlimm er war, haben wir am 7. Februar Google diesbezüglich kontaktiert. 2020. Google war so besorgt über die Auswirkungen der Veröffentlichung von MediaTek-su, dass sie uns gebeten haben, mit der Veröffentlichung dieser Geschichte bis heute zu warten. Unter Berücksichtigung des irreparablen Schadens, der Benutzern zugefügt werden kann, die von der Verwendung von Malware betroffen sind MediaTek-su, wir haben vereinbart, diese Geschichte bis zur Ankündigung des Android im März 2020 zurückzuhalten Sicherheitsbulletin. Dennoch, wenn man bedenkt, wie lange es auf vielen Geräten dauern wird, bis sie das neueste Sicherheitsupdate erhalten, wenn überhaupt Wenn Sie es überhaupt verstehen, wird es in ein paar Monaten bestimmt noch eine Menge Geräte geben, die für MediaTek-su anfällig sind Jetzt. Das dürfte für jeden mit einem anfälligen Gerät erschreckend sein.

Obwohl diese sehr schwerwiegende Sicherheitslücke mit dem Schweregrad „kritisch“ aktiv ausgenutzt wird, gilt dies nur für Google haben die Lösung für dieses Problem in das Bulletin vom März 2020 aufgenommen, also etwa zwei Monate, nachdem sie davon Kenntnis erlangt haben Ausgabe. Während Google seine Android-Partner volle 30 Tage vor der Veröffentlichung des Bulletins über das neueste Android-Sicherheitsbulletin informiert (d. h. OEMs wurden Anfang Februar 2020 auf den Inhalt des Bulletins vom März 2020 aufmerksam gemacht. Google kann das Bulletin mit Änderungen oder neuen Korrekturen aktualisieren und tut dies häufig auch. Warum Google sich nicht dafür entschieden hat, die Einbindung eines Patches für ein so schwerwiegendes Problem zu beschleunigen, ist mir ein Rätsel, insbesondere wenn MediaTek vor 10 Monaten eine Lösung dafür hatte. Wenn ein solcher Fehler in den Apple-Geräten entdeckt worden wäre, hätte man kaum Zweifel daran, dass sie einen Fix herausgegeben hätten viel, viel schneller. Google setzte im Wesentlichen auf die riskante Wette, dass MediaTek-su scheinbar so unauffällig bleiben würde, wie es bereits bis zum Bulletin vom März 2020 der Fall war. Obwohl Google in dieser Hinsicht offenbar Glück gehabt hat, haben wir keine Ahnung, wie viele Malware-Autoren bereits von dem Exploit wissen. Immerhin sitzt es schon seit einiger Zeit in einem zufälligen XDA-Forenthread fast ein ganzes Jahr.

Es gibt noch eine weitere Partei in diesem Debakel, auf die ich nicht viel eingegangen bin, und es ist der Urheber des Exploits, das XDA-Mitglied Diplomatic. Zu seiner Ehre muss ich sagen, dass er bei der Veröffentlichung von MediaTek-su keine böswillige Absicht hatte. Wir können den Ursprung des Exploits eindeutig auf den Wunsch der Diplomaten zurückführen, die Amazon Fire-Tablets zu modifizieren. Diplomatic erzählt mir, dass sein Hauptziel bei der Entwicklung dieser Wurzelmethode darin bestand, der Gemeinschaft zu helfen. Bei XDA geht es darum, Ihr Gerät individuell anzupassen, und die Bemühungen der Diplomatie in der Community sind das, was den Leuten an den Foren gefällt. Obwohl die Weigerung von Diplomatic, das Projekt als Open Source zu veröffentlichen, einige Bedenken hervorruft, erklärt er, dass er wollte, dass die Community so lange wie möglich in den Genuss dieses Root-Zugriffs kommt. Als ich Diplomatic zum ersten Mal kontaktierte, gab er auch an, dass er mit einigen Partnern zusammenarbeite, die ihn daran hinderten, den Quellcode und die Forschungsergebnisse des Projekts weiterzugeben. Obwohl ich nicht in der Lage war, weitere Details zu dieser Zusammenarbeit zu erfahren, frage ich mich, ob Diplomatic diesen Exploit öffentlich gemacht hätte, wenn MediaTek ein Bug-Bounty-Programm angeboten hätte. Ich kann mir nicht vorstellen, dass eine Schwachstelle dieser Größenordnung nicht eine saftige Summe auszahlen würde, wenn MediaTek tatsächlich ein solches Programm hätte. Diplomatic behauptet, dass dieser Exploit seit dem Ende 2015 erschienenen MediaTek MT6580-Chipsatz möglich sei. Man muss sich also fragen, ob Diplomatic überhaupt die erste Person ist, die diesen Exploit entdeckt hat. Er erzählt mir, dass er bis zur Veröffentlichung dieses Artikels keine Ahnung hatte, dass MediaTek-su aktiv ausgenutzt wurde.

Wenn Sie überprüfen möchten, ob Ihr Gerät für MediaTek-su anfällig ist, führen Sie das von XDA Member diplomatic veröffentlichte Skript manuell aus in diesem XDA-Forenthread. Wenn Sie eine Root-Shell aufrufen (Sie erkennen, wann sich das Symbol von $ zu # ändert), wissen Sie, dass der Exploit funktioniert. Wenn es funktioniert, müssen Sie warten, bis der Hersteller Ihres Geräts ein Update herausbringt, das MediaTek-su patcht. Wenn Ihr Gerät den Sicherheitspatch-Level 2020-03-05 meldet, also den neuesten SPL vom März 2020, dann ist es mit ziemlicher Sicherheit vor MediaTek-su geschützt. Andernfalls müssen Sie lediglich prüfen, ob Ihr Gerät angreifbar ist.

---

Update 1 (02.03.2020 um 21:45 Uhr EST): Dieser Artikel wurde aktualisiert, um zu verdeutlichen, dass sich das XDA-Mitglied Diplomatic tatsächlich von Anfang an über das Ausmaß dieser Sicherheitslücke im Klaren war entdeckte es bereits im Februar 2019, wusste jedoch bis zur Veröffentlichung nichts von der Verwendung des Exploits in freier Wildbahn Artikel. Wir haben auch unseren Wortlaut bezüglich eines Grundes korrigiert, warum Diplomatic es ablehnte, den Quellcode des Projekts weiterzugeben.