Door de Janus-kwetsbaarheid kunnen aanvallers apps wijzigen zonder hun handtekening te beïnvloeden. Het werd ontdekt door GuardSquare en is opgelost door Google.
Android wordt op een groot aantal apparaten geïnstalleerd en is daardoor een doelwit voor kwaadwillende aanvallers. Er worden nog steeds maandelijks kwetsbaarheden ontdekt in het mobiele besturingssysteem van Google, maar het goede nieuws is dat Google is meestal ijverig in het oplossen ervan in reguliere beveiligingspatches die vervolgens worden aangeboden aan OEM's, die het vervolgens naar hen verzenden apparaten.
Onlangs hebben beveiligingsonderzoekers een kwetsbaarheid ontdekt waardoor gebruikers werden misleid zodat aanvallers het scherm van hun apparaat konden opnemen. Die specifieke exploit werd opgelost in Android Oreo, maar analisten bij BewakerVierkant heeft onlangs een andere ernstige kwetsbaarheid gemeld die Android-apps treft die zijn ondertekend door een ouder handtekeningschema.
BewakerVierkantIn het rapport staat dat de
Janus profiteert van het feit dat extra bytes onopgemerkt blijven in APK-bestanden en DEX-bestanden. De BewakerVierkant Het rapport legt uit dat een APK-bestand een ZIP-archief is dat aan het begin, vóór en tussen de ZIP-items willekeurige bytes kan bevatten. Het JAR-handtekeningschema houdt alleen rekening met de ZIP-gegevens en negeert eventuele extra bytes bij het berekenen of verifiëren van de handtekening van de toepassing.
Het legt verder uit dat een DEX-bestand aan de andere kant willekeurige bytes kan bevatten - na de reguliere secties van strings, klassen, methodedefinities, enz. Daarom kan een bestand tegelijkertijd een geldig APK-bestand en een geldig DEX-bestand zijn.
BewakerVierkant vermeldt ook dat een belangrijk element van de kwetsbaarheid een "onschadelijk" kenmerk van de virtuele Dalvik/ART-machine is. Het rapport stelt dat de Android-runtime in theorie het APK-bestand laadt, het DEX-bestand extraheert en vervolgens de code uitvoert. In de praktijk kan de virtuele machine (VM) echter zowel APK-bestanden als DEX-bestanden laden en uitvoeren. Het probleem is dat wanneer de VM een APK-bestand ontvangt, deze nog steeds naar de magische bytes in de header kijkt om te beslissen welk type bestand het is: DEX of APK. Wanneer een DEX-header wordt gevonden, wordt het bestand geladen als een DEX-bestand. Als er geen header wordt gevonden, wordt het bestand geladen als een APK-bestand met daarin een zip-item met een DEX-bestand. Het kan dus dubbele DEX/APK-bestanden verkeerd interpreteren.
BewakerVierkant zegt dat een aanvaller deze dualiteitsfunctie van de VM kan gebruiken om een kwaadaardig DEX-bestand aan een normaal APK-bestand toe te voegen zonder de handtekening ervan te beïnvloeden. De Android-runtime accepteert het APK-bestand als een geldige update naar een legitieme eerdere app-versie, maar de Dalvik VM laadt de code uit het DEX-bestand, dat is geïnjecteerd met kwaadaardige code.
Normaal gesproken wordt, telkens wanneer een gebruiker een bijgewerkte versie van een app installeert, de handtekening van de app geverifieerd door de Android-runtime om er zeker van te zijn dat deze overeenkomt met de oudere versie. Wanneer de verificatie positief is, krijgt de bijgewerkte applicatie de machtigingen die aan de oorspronkelijke applicatie waren verleend. Op deze manier kunnen aanvallers de Janus-kwetsbaarheid gebruiken om het handtekeningverificatieproces te omzeilen en niet-geverifieerde code op de apparaten van nietsvermoedende gebruikers te laten installeren.
Wat nog erger is, is dat deze niet-geverifieerde code toegang kan krijgen tot krachtige machtigingen. Dit geeft aanleiding tot enkele ernstige mogelijkheden. BewakerVierkant luidt:
“Een aanvaller kan een vertrouwde applicatie met hoge rechten (een systeemapp bijvoorbeeld) vervangen door een aangepaste update om misbruik te maken van de rechten. Afhankelijk van de beoogde toepassing kan de hacker hierdoor toegang krijgen tot gevoelige informatie die op het apparaat is opgeslagen of het apparaat zelfs volledig overnemen. Als alternatief kan een aanvaller een aangepaste kloon van een gevoelige applicatie doorgeven als een legitieme update [die] eruit kan zien en zich kan gedragen als de originele applicatie, maar kwaadaardig gedrag kan veroorzaken."
Het bedrijf voegde eraan toe dat ze tot nu toe geen enkele toepassing hadden gezien die Janus in het wild exploiteerde. Het andere goede nieuws is dat de kwetsbaarheid vereist dat een gebruiker een kwaadaardige update installeert van een bron buiten de Google Play Store. Daarom zijn gebruikers die app-installaties beperken tot de Play Store beschermd.
De Janus-kwetsbaarheid treft apparaten met Android 5.0+. Dit geldt voor applicaties die zijn ondertekend met APK-handtekeningschema v1. APK's ondertekend met handtekeningschema v2 zijn beschermd tegen de kwetsbaarheid. Dit vereist dat de APK's worden uitgevoerd op apparaten die het nieuwste handtekeningschema ondersteunen (Android 7.0 en nieuwer). Schema v2 is beveiligd omdat het, in tegenstelling tot schema v1, rekening houdt met alle bytes in het APK-bestand.
"Oudere versies van applicaties en nieuwere applicaties die op oudere apparaten draaien, blijven vatbaar. Ontwikkelaars moeten in ieder geval altijd handtekeningschema v2 toepassen," BewakerVierkant staten.
BewakerVierkant heeft dit probleem op 31 juli 2017 bij Google gemeld en dezelfde dag een bevestiging ontvangen. In het rapport van het bedrijf staat dat Google in november een patch voor zijn partners heeft uitgebracht en de bug (CVE-2017-13156) op 4 december 2017 in het Android Security Bulletin heeft gepubliceerd. De kwetsbaarheid heeft is opgelost in de Android-beveiligingspatch van december 2017. Daarnaast is bevestigd dat F-Droid-applicaties uit hun officiële repository veilig zijn. Ten slotte is bevestigd dat de kwetsbaarheid is gepatcht APKMirror.
Bron: GuardSquare