Kritieke MediaTek-rootkit beïnvloedt miljoenen Android-apparaten

Elke eerste maandag van de maand publiceert Google de Android-beveiligingsbulletin, een pagina die alle beveiligingsproblemen en de bijbehorende patches onthult die door Google zelf of door andere derde partijen zijn ingediend. Vandaag was geen uitzondering: Google heeft zojuist het Android-beveiligingsbulletin voor maart 2020 openbaar gemaakt. Een van de kwetsbaarheden die in het laatste bulletin zijn gedocumenteerd is CVE-2020-0069, een kritieke beveiligingsexploit, met name een rootkit, dat gevolgen heeft voor miljoenen apparaten met chipsets van MediaTek, het grote Taiwanese chipontwerpbedrijf. Hoewel het Android-beveiligingsbulletin van maart 2020 schijnbaar de eerste keer is dat CVE-2020-0069 openbaar wordt gemaakt, details van de exploit staan ​​sinds april openlijk op internet – meer specifiek op de XDA-Developers-forums van 2019. Ondanks dat MediaTek een maand na ontdekking een patch beschikbaar heeft gesteld, kan de kwetsbaarheid nog steeds worden misbruikt op tientallen apparaatmodellen.

Erger nog: de kwetsbaarheid wordt actief misbruikt door hackers. Nu heeft MediaTek zich tot Google gewend om deze patchkloof te dichten en miljoenen apparaten te beveiligen tegen deze kritieke beveiligingsuitbuiting.

Voor alle lezers die er nog niet mee bekend zijn XDA-ontwikkelaars, we zijn een site met de grootste forums voor Android-softwareaanpassingen. Meestal draaien deze aanpassingen rond het verkrijgen van root-toegang op apparaten om bloatware te verwijderen, aangepaste software te installeren of standaard systeemparameters aan te passen. De Fire-tablets van Amazon zijn populaire doelwitten voor hobbyistische hackers op onze forums: ze staan ​​vol met verwijderbare programma's bloatware, hebben geen toegang tot basissoftwareapplicaties zoals de Google Play Store, en, belangrijker nog, zijn erg goedkoop. De uitdaging bij het rooten van Amazon Fire-tablets is dat ze zwaar zijn vergrendeld om te voorkomen dat gebruikers buiten de ommuurde tuin van Amazon stappen; Amazon biedt geen officiële methode om de bootloader van Fire-tablets te ontgrendelen, wat meestal de eerste stap is bij het rooten van een bepaald Android-apparaat. Daarom is de enige manier om een ​​Amazon Fire-tablet te rooten (zonder hardwareaanpassingen) het vinden van een exploit in de software waarmee de gebruiker het beveiligingsmodel van Android kan omzeilen. In februari 2019, dat is precies wat XDA Senior Member diplomatic deed toen hij een thread publiceerde op onze Amazon Fire-tabletforums. Hij realiseerde zich al snel dat deze exploit een veel bredere reikwijdte had dan alleen de Fire-tablets van Amazon.

Na wat testen door diplomatieke leden en andere leden van de XDA-gemeenschap werd bevestigd dat deze exploit op een groot aantal MediaTek-chips werkt. De auteur stelt dat de exploit werkt op "vrijwel alle 64-bits chips van MediaTek", en zij noemen specifiek het volgende als kwetsbaar: 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, en MT6595. Vanwege het aantal MediaTek-chipsets dat door deze exploit werd getroffen, kreeg de exploit de naam "MediaTek-su" of kortweg "MTK-su". Op 17 april 2019 publiceerde diplomatiek een tweede draad met de titel "Geweldige tijdelijke root voor MediaTek ARMv8" op ons forum "Diverse Android-ontwikkeling". In deze thread deelde hij een script dat gebruikers kunnen uitvoeren om hen superuser-toegang in de shell te verlenen, maar ook om in te stellen SELinux, de Linux-kernelmodule die toegangscontrole voor processen biedt aan de zeer onveilige "toegeeflijke" staat. Het is schokkend eenvoudig voor een gebruiker om root-toegang te krijgen en SELinux op zijn eigen apparaat op permissief in te stellen: het enige wat je hoeft te doen is de script naar een tijdelijke map, wijzig de mappen waar het script is opgeslagen, voeg uitvoerbare machtigingen toe aan het script en voer vervolgens de script.

Leden van de XDA-gemeenschap bevestigden dat de exploit op ten minste de volgende apparaten werkte:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Alba-tabletserie
4. Alcatel 1 5033-serie
5. Alcatel 1C
6. Alcatel 3L (2018) 5034-serie
7. Alcatel3T8
8. Alcatel A5 LED 5085-serie
9. Alcatel A30 5049-serie
10. Alcatel Idool 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 - alleen tot Fire OS 6.3.1.2 build 0002517050244
15. Amazon Fire HD 8 2016 - alleen tot Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 - alleen tot Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018 -- alleen tot Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 - alleen tot Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019 -- alleen tot Fire OS 7.3.1.0
20. Amazon Fire TV 2 - alleen tot Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. ASUS ZenPad Z3xxM(F) MT8163-gebaseerde serie
24. Barnes & Noble NOOK-tablet 7" BNTV450 en BNTV460
25. Barnes & Noble NOOK-tablet 10,1 inch BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Leven Max
29. BLU Life One X
30. BLU R1-serie
31. BLU R2 LTE
32. BLAUW 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. KAT S41
40. Coolpad CoolPlay 8 Lite
41. Draak Touch K10
42. Echo-gevoel
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-dynastie
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. Nokia1
62. Nokia 1 Plus
63. Nokia-3
64. Nokia 3.1
65. Nokia 3.1Plus
66. Nokia 5.1
67. Nokia 5.1 Plus/X5
68. Op een 7" Android-tablet
69. Onn 8" & 10" tabletserie (MT8163)
70. OPPO A5's
71. OPPO F5-serie/A73 - alleen Android 8.x
72. OPPO F7-serie - alleen Android 8.x
73. OPPO F9-serie - alleen Android 8.x
74. Oukitel K12
75. Protruut D7
76. Realme 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-kracht
87. Wiko rit
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

Lees verder

Met uitzondering van op MediaTek gebaseerde telefoons van Vivo, Huawei/Honor (na Android 8.0+), OPPO (na Android 8.0+) en Leden van de Samsung- en XDA-gemeenschap ontdekten dat MediaTek-su vaker wel dan niet werkt wanneer het wordt geprobeerd op apparaten met de getroffen apparaten chipsets. Volgens diplomatieke XDA-leden gebruiken Vivo-, Huawei/Honor-, OPPO- en Samsung-apparaten "kernelwijzigingen om root-toegang te ontmoedigen via exploits", wat betekent dat de ontwikkelaar in de kernelbroncode van deze apparaten zou moeten graven om "op maat gemaakte versie[s]" van de uitbuiten. Dat was de extra moeite niet waard, dus koos de ontwikkelaar ervoor om geen ondersteuning voor deze apparaten toe te voegen, ook al zou de exploit "in theorie" nog steeds kunnen werken.

Het zou inmiddels duidelijk moeten zijn dat deze exploit een groot aantal apparaten op de markt treft. MediaTek-chips voeden honderden budget- en middenklasse smartphonemodellen, goedkope tablets en merken van andere merken settopboxen, waarvan de meeste worden verkocht zonder de verwachting van tijdige updates van de fabrikant. Het is dus onwaarschijnlijk dat veel apparaten die nog steeds door MediaTek-su worden getroffen, weken of maanden na de bekendmaking van vandaag een oplossing zullen krijgen, als ze er al een krijgen. Dus wat zorgt ervoor dat MediaTek-su zijn "kritieke" ernst verdient met a CVSS v3.0 score van 9,3?

Waarom MTK-su een kritiek beveiligingslek is

Nogmaals: de gebruikelijke manier om root-toegang op een Android-apparaat te verkrijgen, is door eerst de bootloader te ontgrendelen, waardoor de verificatie van de opstartpartitie wordt uitgeschakeld. Zodra de bootloader is ontgrendeld, kan de gebruiker een superuser-binair bestand in het systeem introduceren en ook een superuser-beheerapp om te bepalen welke processen toegang hebben tot root. Het ontgrendelen van de bootloader schakelt opzettelijk een van de belangrijkste beveiligingsfuncties op het apparaat uit. Daarom moet de gebruiker laat dit expliciet gebeuren door doorgaans een schakelaar in de ontwikkelaarsopties in te schakelen en vervolgens een ontgrendelopdracht te geven aan de bootlader. Met MediaTek-su hoeft de gebruiker de bootloader echter niet te ontgrendelen om root-toegang te krijgen. In plaats daarvan hoeven ze alleen maar een script naar hun apparaat te kopiëren en dit in de shell uit te voeren. De gebruiker is echter niet de enige die dit kan doen. Elke app op uw telefoon kan het MediaTek-su-script naar hun privémap kopiëren en vervolgens uitvoeren om root-toegang in de shell te krijgen. Sterker nog, XDA-lid diplomatiek benadrukt deze mogelijkheid in hun forumthread wanneer ze een alternatieve reeks instructies voorstellen met behulp van de Terminalemulator voor Android-app of Termux in plaats van ADB.

Met root-toegang valt het beveiligingsmodel van Android feitelijk uiteen. Permissies worden bijvoorbeeld zinloos in de context van root, omdat een app met toegang tot een rootshell zichzelf elke gewenste toestemming kan verlenen. Bovendien is met een rootshell de gehele gegevenspartitie toegankelijk, inclusief bestanden die zijn opgeslagen in de doorgaans ontoegankelijke privégegevensmappen van applicaties. Een app met root kan ook stilletjes elke andere app installeren die hij wil op de achtergrond en hem vervolgens alle rechten verlenen die hij nodig heeft om uw privacy te schenden. Volgens XDA erkende ontwikkelaar topjohnwu, kan een kwaadaardige app zelfs "code rechtstreeks in Zygote injecteren met behulp van ptrace", wat betekent dat een normale app op uw apparaat kan worden gekaapt om de bevelen van de aanvaller uit te voeren. Deze voorbeelden hebben slechts betrekking op enkele manieren waarop een app uw vertrouwen op de achtergrond kan schenden zonder dat u het weet. Kwaadaardige apps kunnen echter grote schade aanrichten op uw apparaat zonder te verbergen wat ze doen. Ransomware is dat bijvoorbeeld uiterst krachtig met root-toegang; als u niet betaalt, kan een hypothetische ransomware-app dat wel doen totaal en onomkeerbaar maak uw apparaat onbruikbaar door het hele apparaat schoon te vegen.

De enige "zwakte" in MediaTek-su is dat het een applicatie slechts "tijdelijke" root-toegang verleent, wat betekent dat een proces de superuser-toegang verliest nadat het apparaat opnieuw is opgestart. Bovendien is op apparaten met Android 6.0 Marshmallow en hoger de aanwezigheid van Geverifieerde Boot en dm-verity blokkeer wijzigingen aan alleen-lezen partities zoals systeem en leverancier. Deze twee factoren vormen echter meestal alleen maar hindernissen voor modders op onze forums en niet voor kwaadwillende actoren. Om de beperking van tijdelijke root te omzeilen, kan een kwaadwillende app het MediaTek-su-script eenvoudigweg opnieuw uitvoeren bij elke opstart. Aan de andere kant is het weinig nodig om dm-verity te overwinnen, aangezien permanente wijzigingen aan het systeem of de partities van de leverancier waarschijnlijk niet interessant zullen zijn voor de meeste malware-auteurs; die zijn er immers al ton van de dingen die een kwaadaardige app kan doen met een rootshell.

Als je je op technisch niveau afvraagt ​​wat MediaTek-su exploiteert, heeft MediaTek het onderstaande diagram met ons gedeeld dat het startpunt samenvat. De fout bestaat blijkbaar in een van MediaTek's Linux Kernel-stuurprogramma's genaamd "CMDQ". In de beschrijving staat dat "door het uitvoeren van IOCTL commando's in [het] CMDQ-apparaatknooppunt", kan een lokale aanvaller "willekeurig fysiek geheugen lezen/schrijven, [de] kernelsymbooltabel dumpen naar de vooraf toegewezen DMA-buffer, [en] manipuleer de DMA-buffer om de kernelinstellingen te wijzigen om SELinux uit te schakelen en te escaleren naar 'root' voorrecht."

Volgens de grafiek die MediaTek met ons heeft gedeeld, treft dit beveiligingslek MediaTek-apparaten met Linux Kernel-versies 3.18, 4.4, 4.9 of 4.14 met Android-versies 7 Nougat, 8 Oreo of 9 Pie. De kwetsbaarheid kan blijkbaar niet worden misbruikt op MediaTek-apparaten met Android 10, aangezien "de toegangsrechten van CMDQ apparaatknooppunten worden ook afgedwongen door SELinux." Deze beperking komt waarschijnlijk voort uit een update van MediaTek's BSP in plaats van uit Android zelf. De enige oplossing voor dit beveiligingslek in Android 10 is de beperking voor apps die binaire bestanden uitvoeren in hun thuismap; Zoals XDA Recognized Developer topjohnwu opmerkt, kan een kwaadaardige app echter eenvoudig de MediaTek-su-code in een dynamische bibliotheek uitvoeren.

Hoewel MediaTek dit probleem in alle getroffen chipsets heeft opgelost, kunnen ze apparaatfabrikanten niet dwingen de patches te implementeren. MediaTek vertelde ons dat ze al in mei 2019 patches klaar hadden. Het is niet verwonderlijk dat Amazon het probleem onmiddellijk op al zijn apparaten heeft gepatcht zodra ze hiervan op de hoogte waren gesteld. Er zijn echter tien maanden verstreken sinds MediaTek een oplossing beschikbaar stelde aan zijn partners Maart 2020 hebben tientallen OEM's hun apparaten niet gerepareerd. De meeste getroffen apparaten draaien op oudere Android-releases met verouderde Android Security Patch Levels (SPL's), en de updatesituatie is zelfs nog erger als je bedenkt dat honderden van minder bekende apparaatmodellen die deze MediaTek-chips gebruiken. MediaTek heeft een serieus probleem hier aan de orde is, dus hebben ze zich tot Google gewend voor hulp.

In tegenstelling tot MediaTek, Google kan dwing OEM's om hun apparaten bij te werken licentieovereenkomsten of programmavoorwaarden (zoals Android One). Als een OEM wil verklaren dat een apparaat voldoet aan het Security Patch Level (SPL) van 2020-03-05, moet het apparaat alle frameworks, Linux-kernel en toepasselijke driverfixes van leveranciers in het Android-beveiligingsbulletin van maart 2020, dat een oplossing bevat voor CVE-2020-0069, of MediaTek-su. (Google lijkt dat eigenlijk niet af te dwingen OEM's voegen feitelijk alle patches samen bij het declareren van een bepaalde SPL.) Nu het bulletin van maart 2020 uit is, zou dit verhaal voorbij moeten zijn, toch? Helaas moeten we ook de voeten van Google tegen het vuur houden omdat ze hun voeten slepen bij het opnemen van de patches.

De fout in het beveiligingspatchproces

Voor het geval het nog niet duidelijk is: niet elk beveiligingsprobleem hoeft in een Android-beveiligingsbulletin terecht te komen. Veel kwetsbaarheden worden door leveranciers ontdekt en gepatcht zonder dat ze ooit in het maandbulletin verschijnen. MediaTek-su had er één van moeten zijn, maar om meerdere redenen slaagden verschillende OEM's er niet in de door MediaTek aangeboden patches te integreren. (Er zijn veel mogelijke redenen hiervoor, variërend van een gebrek aan middelen tot zakelijke beslissingen en een communicatiefout.) Toen ik eerder verklaarde dat MediaTek "zich tot Google wendde" voor hulp, het impliceerde dat MediaTek actief hulp zocht bij Google om OEM's eindelijk hun probleem te laten oplossen apparaten. Maar misschien was dat in werkelijkheid niet het geval. Ik heb begrepen dat Google niet op de hoogte was van MediaTek-su totdat het per ongeluk ter sprake kwam in een beveiligingsrapport van TrendMicro gepubliceerd op 6 januari 2020. In het rapport staat TrendMicro was aan het documenteren een andere beveiligingsprobleem, genaamd de "gebruik-na-gratis in binder driver"kwetsbaarheid, die in het wild actief werd uitgebuit. TrendMicro merkte op hoe drie kwaadaardige apps root-toegang verkregen met behulp van een van de twee methoden: de kwetsbaarheid "use-after-free in binder driver" of MediaTek-su.

In de code die TrendMicro gedeeld, kunnen we duidelijk zien hoe de kwaadaardige apps zich op specifieke apparaatmodellen richtten (bijv. Nokia 3, OPPO F9 en Redmi 6A) en gebruik MediaTek-su daarop.

Ik kan niet voor spreken TrendMicro, maar het lijkt erop dat ze zich er niet van bewust waren dat MediaTek-su een nog niet gepatchte exploit was. Hun focus lag immers op de exploit "use-after-free in binder driver", en de ontdekking van het gebruik van MediaTek-su lijkt een bijzaak te zijn geweest. (Ik weet zeker dat als TrendMicro op de hoogte waren geweest van de situatie rond MediaTek-su, zouden ze hun inspanningen op het gebied van openbaarmaking hebben gecoördineerd met Google.) We werden alleen op de hoogte gebracht van deze exploit zelf op 5 februari 2020, en nadat we zelf hadden onderzocht hoe erg het was, hebben we er op 7 februari contact over opgenomen met Google, 2020. Google was zo bezorgd over de gevolgen van het publiceren van MediaTek-su dat ze ons vroegen om te wachten met het publiceren van dit verhaal tot vandaag. Na overweging van de onherstelbare schade die kan worden toegebracht aan gebruikers die het doelwit zijn van het gebruik van malware MediaTek-su, we hebben afgesproken dit verhaal op te schorten tot de aankondiging van de Android van maart 2020 Beveiligingsbulletin. Maar als je bedenkt hoe lang het zal duren voordat veel apparaten de nieuwste beveiligingsupdate krijgen, als ze ooit ooit komen Als je het überhaupt begrijpt, zullen er over een paar maanden ongetwijfeld nog een heleboel apparaten kwetsbaar zijn voor MediaTek-su nu. Dat zou gruwelijk moeten zijn voor iedereen met een kwetsbaar apparaat.

Ook al wordt deze zeer ernstige, ‘kritieke’ kwetsbaarheid actief misbruikt, alleen door Google hebben de oplossing voor dit probleem in het bulletin van maart 2020 geplaatst, ongeveer twee maanden nadat ze op de hoogte waren gesteld van de probleem. Hoewel Google zijn Android-partners wel 30 dagen voordat het bulletin openbaar wordt gemaakt, informeert over het nieuwste Android-beveiligingsbulletin (dat wil zeggen OEM's werden begin februari 2020 op de hoogte gebracht van wat er in het bulletin van maart 2020 staat), Google kan het bulletin bijwerken met wijzigingen of nieuwe oplossingen, en doet dit vaak ook. Waarom Google er niet voor heeft gekozen om het opnemen van een patch voor zo'n ernstig probleem te bespoedigen, is mij een raadsel, vooral toen MediaTek er tien maanden geleden een oplossing voor had. Als zo'n bug in de apparaten van Apple zou worden ontdekt, twijfel ik er niet aan dat ze een oplossing zouden hebben uitgebracht veel, veel sneller. Google ging in wezen uit van de riskante gok dat MediaTek-su net zo schijnbaar onopvallend zou blijven als het al was tot het bulletin van maart 2020. Hoewel Google in dat opzicht geluk lijkt te hebben gehad, hebben we geen idee hoeveel malware-auteurs al op de hoogte zijn van de exploit. Het heeft tenslotte in een willekeurige XDA-forumthread gestaan bijna een heel jaar.

Er is nog een partij in dit debacle waar ik niet veel over heb gesproken, en dat is de auteur van de exploit, een diplomatiek XDA-lid. Het strekt hem tot eer dat ik denk dat hij geen kwade bedoelingen had met het publiceren van MediaTek-su. We kunnen de oorsprong van de exploit duidelijk herleiden tot de wens van de diplomatieke partij om de Amazon Fire-tablets te modificeren. Diplomatiek vertelt mij dat zijn voornaamste doel bij het ontwikkelen van deze basismethode was om de gemeenschap te helpen. Het aanpassen van je apparaat is waar XDA om draait, en de inspanningen van diplomatieke mensen in de gemeenschap zijn wat mensen leuk vinden aan de forums. Hoewel de weigering van de diplomaten om het project open source te maken enige zorgen oproept, legt hij uit dat hij wilde dat de gemeenschap zo lang mogelijk van deze root-toegang zou kunnen genieten. Toen ik voor het eerst contact opnam met diplomatiek, verklaarde hij ook dat hij samenwerkte met een aantal partners, waardoor hij de broncode en het onderzoek van het project niet kon delen. Hoewel ik niet meer details over deze samenwerking heb kunnen krijgen, vraag ik me af of de diplomatieke partij ervoor zou hebben gekozen deze exploit openbaar te maken als MediaTek een bugbounty-programma had aangeboden. Ik kan me niet voorstellen dat een kwetsbaarheid van deze omvang niet veel geld zou opleveren als MediaTek daadwerkelijk zo'n programma zou hebben. Diplomatieke beweringen dat deze exploit mogelijk is sinds de MediaTek MT6580-chipset van eind 2015, dus je moet je afvragen of diplomatiek zelfs de eerste persoon is die deze exploit ontdekt. Hij vertelt me ​​dat hij tot de publicatie van dit artikel geen idee had dat MediaTek-su actief werd uitgebuit.

Als u wilt controleren of uw apparaat kwetsbaar is voor MediaTek-su, voer dan handmatig het script uit dat is gepost door het diplomatieke XDA-lid in deze XDA-forumthread. Als u een rootshell invoert (u weet wanneer het symbool verandert van $ in #), dan weet u dat de exploit werkt. Als het werkt, moet je wachten tot de fabrikant van je apparaat een update uitrolt waarmee MediaTek-su wordt gepatcht. Als uw apparaat het beveiligingspatchniveau van 05-03-2020 rapporteert, wat de laatste SPL van maart 2020 is, dan is het vrijwel zeker beschermd tegen MediaTek-su. Anders moet u gewoon controleren of uw apparaat kwetsbaar is.

---

Update 1 (2-3-2020 om 21:45 uur EST): Dit artikel is bijgewerkt om te verduidelijken dat het diplomatieke XDA-lid zich daadwerkelijk bewust was van de omvang van dit beveiligingslek zodra hij ontdekte het in februari 2019, maar dat hij zich tot de publicatie van dit bericht niet bewust was van het gebruik van de exploit in het wild artikel. We hebben ook onze formulering gecorrigeerd met betrekking tot één reden waarom de diplomatieke dienst weigerde de broncode van het project te delen.