Google détaille une partie de sa lutte contre les malwares sur Android
Dead or Alive
Le 19 janvier 2017 à 15h30
4 min
Société numérique
Société
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.
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é.
Google détaille une partie de sa lutte contre les malwares sur Android
-
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
Commentaires (17)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 19/01/2017 à 16h17
Le 19/01/2017 à 16h19
Le 19/01/2017 à 16h20
t’as pas de risque zéro, mais ça réduit. Cela dit j’y compterais pas trop " />
Le 19/01/2017 à 16h21
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é.
Le 19/01/2017 à 16h29
Le 19/01/2017 à 16h43
> 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.
Le 19/01/2017 à 17h14
“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 " />
Le 19/01/2017 à 18h03
Et si on commencait par éradiquer la fragmentation d’Android ?
" />
Le 19/01/2017 à 18h19
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 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 (?)
Le 19/01/2017 à 21h35
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 > LineageOS était en cours donc wait & see !
" />
" />
Le 20/01/2017 à 09h01
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é.
Le 20/01/2017 à 10h29
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 20/01/2017 à 12h25
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.
Le 20/01/2017 à 12h40
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.
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.
Le 19/01/2017 à 15h31
En gros ils attendent qu’il y ait déjà des victimes pour se bouger les fesses.
Le 19/01/2017 à 15h36
non, y’a de la détection automatique sur les risques usuels.
Le 19/01/2017 à 15h52
Question aux super-geeks [dans le vrai = ‘bon’ sens du terme " />] :
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 ?