Google détaille une partie de sa lutte contre les malwares sur Android

Google détaille une partie de sa lutte contre les malwares sur Android

Dead or Alive

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

19/01/2017 4 minutes
17

Google détaille une partie de sa lutte contre les malwares sur Android

La sécurité sur Android a souvent été remise en cause à la faveur de vagues d’attaques provoquées par des malwares. Google a décidé de communiquer pour indiquer – en partie seulement – les actions entreprises contre ces fléaux. Des protections pas toujours suffisantes.

Le problème des malwares sur Android est régulier, mais ne tient pas nécessairement à un manque de sécurité du Play Store. Il y a plusieurs moyens de parvenir à installer un logiciel malveillant sur un smartphone et la boutique officielle est sans doute le plus difficile. Souvent, les contaminations par malwares se font via des applications infectées ou spécifiquement créées, disponibles depuis des boutiques tierces. Une possibilité qu’il suffit de déverrouiller dans les options d’Android.

La vérification active du comportement applicatif

Google souhaite donc communiquer sur une partie des efforts mis en place pour lutter contre les malwares. En partie seulement car, comme l’éditeur l’avait indiqué il y a quelques semaines au sujet des faux avis, trop en révéler pourrait renseigner les pirates sur d’éventuelles méthodes pour contourner les protections. L’éditeur se concentre avant tout sur le Play Store, qui devrait être selon lui le seul moyen d’installer une application.

La première protection est la plus connue : un scanner des applications quand elles sont proposées par les développeurs sur le Store, pour y détecter toute menace éventuelle. Une mesure efficace dans la plupart des cas, bien qu’il puisse y avoir des ratés. De fait, une menace peut potentiellement passer ce premier filtre et se retrouver sur un appareil Android.

Survient alors « Verify Apps ». Il s’agit d’une autre protection qui vérifie le comportement des applications. Elle est liée aux serveurs de Google, dispose en permanence d’une base à jour de facteurs à surveiller. Si une PHA (Potentially Harmful App, application potentiellement dangereuse) est repérée, l’utilisateur est averti et une fenêtre lui proposer de la désinstaller.

Le taux de rétention comme base de calcul

Puisqu’il s’agit d’un service actif, il a besoin normalement que les appareils restent connectés pour envoyer de temps en temps des informations statistiques sur le fonctionnement, autrement dit des données télémétriques. Mais si la connexion se coupe, Verify Apps peut se baser sur d’autres informations pour calculer un risque.

Quand un appareil Android ne vient plus consulter Verify Apps, il est ainsi considéré par les serveurs comme « Dead or Insecure » ou DOI. Google met cependant en corrélation plusieurs types d’informations, notamment le nombre d’installations tentées et réussies, et surtout le nombre d’appareils DOI. Si les serveurs remarquent une nette augmentation des DOI après l’arrivée d’une application en particulier, c’est peut-être qu’il y a anguille sous roche.

C’est ce que Google nomme taux de rétention. Un appareil est considéré comme « retenu » tant qu’il contacte les serveurs pour exécuter Verify Apps pour le premier lancement d’une application. L’éditeur précise que la rétention est un facteur clé dans l’écosystème Android et qu’il est donc important de la maximiser.

google android malware doi verify

25 000 applications bloquées par ce mécanisme

Google ajoute bien sûr qu’il s’agit de la théorie centrale mais que d’autres informations entrent en piste, même si elles ne sont pas nommées. L’idée toutefois est toujours la même : propulser en tête de liste les menaces qui semblent les plus sérieuses. Un processus qui a permis de traquer 25 000 applications contenant un malware des familles Hummingbad, Ghost Push et Gooligan, trois des plus actives sur Android.

Ce qu’il faut retenir surtout des explications de Google, même si la firme ne l’indique pas de cette manière, c'est que ces mécanismes ne vont pas forcément permettre de stopper une infection en cours sur un appareil jusqu’au point de non-retour. Le système semble beaucoup plus adapté pour une contre-attaque par accumulation des « preuves ». En d’autres termes, Verify Apps ne peut pas toujours empêcher la primo-infection sur le parc Android, mais peut agir par la suite pour juguler la menace.

Dans la plupart des cas cependant, la sécurité sur Android est remise en cause par des applications provenant de sources tierces. Davantage que sur le Play Store, il est alors nécessaire de faire particulièrement attention à ce que l’on installe, surtout si l’appareil a été rooté.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

La vérification active du comportement applicatif

Le taux de rétention comme base de calcul

25 000 applications bloquées par ce mécanisme

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (17)


En gros ils attendent qu’il y ait déjà des victimes pour se bouger les fesses.


non, y’a de la détection automatique sur les risques usuels.


Question aux super-geeks [dans le vrai = ‘bon’ sens du terme <img data-src=" />] :



Si l’appareil est rooté mais que le mot de passe root à été changé soi-même par un bon mot de passe, il y a-t-il un quelconque risque ? Une application “mauvaise” peut-elle avoir des privilèges supérieurs en dehors de son champ d’action (remise en cause de l’isolation de l’environnement d’exécution) dans un tel cas ?








picatrix a écrit :



En gros ils attendent qu’il y ait déjà des victimes pour se bouger les fesses.





En même temps, il est impossible d’avoir une détection de menaces potentielles efficace à 100 %.

La méthode du “DOI” de Google a au moins le mérite de permettre une détection rapide d’une application malveillante et la détection est potentiellement (à voir en pratique) fonctionnelle, même avec des apk ne provenant pas du store.









Nozalys a écrit :



Question aux super-geeks [dans le vrai = ‘bon’ sens du terme <img data-src=" />] :



Si l’appareil est rooté mais que le mot de passe root à été changé soi-même par un bon mot de passe, il y a-t-il un quelconque risque ? Une application “mauvaise” peut-elle avoir des privilèges supérieurs en dehors de son champ d’action (remise en cause de l’isolation de l’environnement d’exécution) dans un tel cas ?





S’il y a un bug au niveau de la gestion des privilèges, oui, on peut avoir une escalade des privilèges, même avec un mot de passe root modifié et complexe.



t’as pas de risque zéro, mais ça réduit. Cela dit j’y compterais pas trop <img data-src=" />


je suppose que si c’est une faille est exploitée, que tu ai changé ton mot de passe root ne te protege en rien.



Le but des failles c’est bien de faire de l’elevation de privilege sans que le mot de passe ne soit demandé.








picatrix a écrit :



En gros ils attendent qu’il y ait déjà des victimes pour se bouger les fesses.





Possible. Je pense qu’ils ont aussi une grosse flotte de téléphones/tablettes sur lesquelles ils installent les apps pour voir ce qu’elles font (et ça permet aussi de mesurer ce niveau de rétention)



&gt; y a-t-il un quelconque risque ?



À partir du moment où tu as un binaire qui te permet de passer root en plus sur ton système, tu augmentes la surface d’attaque, donc oui. Par exemple quand le développeur de CopperheadOS (Version plus sécurisé de AOSP) voulait se baser sur CyanogenMod, il a regardé leur appli permettant de donner l’accès root aux applications et a trouvé plusieurs failles.


“L’éditeur se concentre avant tout sur le Play Store, qui devrait être selon lui le seul moyen d’installer une application.”



Le fait que ça ne soit pas le cas reste un gros, sinon le seul, avantage d’Android sur les autres OS mobile.

Donc, non, trouvez autrechose svp <img data-src=" />


Et si on commencait par éradiquer la fragmentation d’Android ?&nbsp;



<img data-src=" />


Je suis assez d’accord avec toi.



À quelle heure les mises à jour ?

[troll]

À quelle heure on profite de l’état d’urgence pour condamner les fabricants et opérateurs &nbsp;qui mettent des années voire jamais à mettre à jour leurs terminaux, favorisant ainsi des pirates djihadistes qui pourraient aller jusqu’à l’extrémité de ne pas payer la redevance copie privée ?

[/troll]

Plus sérieusement, s’il y a des connaisseurs d’android, ce serait faisable de mettre à jour le cœur d’android en OTA, sans passer par le constructeur/l’opérateur ? Au pire, si samsung filtre de photo à la con (ça existe vraiment) ne marche plus, c’est tant pis pour eux (?)


Bah y’avait CyanogenMOD pour ça ! Avoir un vieux téléphone toujours à jour, ou même un récent avec les dernières versions avant les ROM constructeurs ! Bon, on attend tout LineageOS en official. Y a des builds unofficial mais je ne me lance pas pour l’instant pour mon OPO me servant aux jeux, ça avait été dit qu’une procédure de migration simplifiée CM &gt; LineageOS était en cours donc wait & see !&nbsp;





<img data-src=" />



<img data-src=" />


Ok mais quelle différence avec ce mode rooté et ce qui se passe quand Android n’est pas rooté ?

Car quand le téléphone n’est pas rooté, il y a quand même un comtpe “root” par défaut avec un mot de passe par défaut. Je ne sais pas vraiment ce que l’action de rooter engendre, donc je ne comprends pas pourquoi une faille ne pourrait pas générer une élévation de privilège en mode non rooté, si elle le peut en mode rooté.


Encore une fois, la différence est la surface d’attaque. En gros sur un android non rooté tu vas attaquer le noyau pour avoir une élévation de privilège. Sur un android rooté, en plus du noyau, tu peux attaquer l’infrastructure de gestion du droit root (au minimum un /bin/su), et toutes apps auquel l’utilisateur aura donné le droit root (ton adblocker root est-il penser pour la sécurité? spoiler: probablement pas)


Le passage en root se limite à installer les binaires qui permettent aux applications de tourner en mode root.

Le mécanisme existe déjà.

D’ailleurs le passage en root est obtenu par un piratage volontaire du téléphone.


C’est devenu incontournable, toutes plateformes confondues. Les concepteurs de malwares passent leur temp à modifier la signature de leurs “produits” pour esquiver la détection, ils savent que ça ne durera que quelques heures mais ça suffit.&nbsp;



On en est donc réduits à réagir à posteriori, mais dans ce domaine Google a les moyens d’être un des plus réactifs, notamment via virustotal et son immense base d’utilisateurs Gmail, Android etc. qui l’alimente.