Nouvelle semaine, nouveau problème avec un firmware embarqué par certains smartphones Android. La société de sécurité BitSight a découvert en effet un trou béant dans le code, ouvrant la voie à des communications non chiffrées vers deux domaines qui, heureusement, n’étaient pas enregistrés.
La société BitSight a publié les résultats de ses recherches sur une importante faille de sécurité dans le code d’un firmware que l’on trouve dans certains modèles de smartphones Android, la plupart orientés vers l’entrée de gamme. Une fois de plus, le constructeur BLU est concerné. La recette appliquée est en effet la même que la semaine dernière : un composant conçu par une entreprise chinoise, mais cette fois avec un potentiel d’action pratiquement sans limite.
Deux domaines laissés vacants
Contrairement en effet au problème soulevé par Kryptowire – envoi de données personnelles vers des serveurs chinois – le firmware concocté par la société Ragentek dispose d’un rootkit. Autrement dit, d’un composant se chargeant au démarrage du système, possédant des droits root, pouvant exécuter n’importe quelle action et cherchant à masquer sa présence (il ne répond pas aux commandes classiques, comme PS).
Le potentiel de ce rootkit est très vaste, même si BitSight indique que rien ne semble indiquer une volonté de nuisance, tout portant à croire qu’il s’agisse d’une vraie erreur technique. La porte ouverte cherche à se connecter à deux domaines qui n'auraient curieusement jamais été achetés. BitSight les a donc réclamés, s’étonnant qu’aucun pirate n’ait visiblement cherché à les avoir plus tôt.
Avec les droits root, tout est possible
Une fois les domaines achetés, BitSight a testé les capacités du rootkit. Il n’y a pas vraiment de limite, puisque des pirates auraient pu provoquer des exécutions distances de code arbitraire, avec installation d’enregistreurs de frappe, de malwares et globalement tout ce qu’il fallait pour contourner la sécurité d’Android, voler des données personnelles, bancaires et ainsi de suite. Et ce d’autant plus facilement que ces opérations étaient effectuées en secret et que l’utilisateur n’a aucun signe visible d’activité suspecte.
Les tests de BitSight ont été effectués sur un smartphone de marque BLU, déjà concerné par la porte dérobée la semaine dernière. Ce constructeur américain, basé en Floride, commercialise une série de modèles, dont beaucoup sont orientés vers l’entrée de gamme. Comme nous l’expliquait le chercheur Azzedine Benameur de chez Kryptowire, il est courant que les fabricants sous-traitent une partie des composants, car ils « n’ont pas le temps ou les moyens de travailler chaque aspect du système », laissant ce type d’incident survenir.
BLU a déjà mis à jour les modèles concernés, l’entreprise étant visiblement réactive sur les problèmes de sécurité. Cependant, BitSight n’a pas encore pu tester l’efficacité du correctif, et le problème souligne une situation plus générale des composants logiciels et matériels fournis par d’autres entreprises. De plus, même si les domaines avaient été achetés pour des raisons légitimes, les smartphones touchés auraient quand même été susceptibles de subir des attaques de type homme du milieu.
Des communications en clair
Car non seulement les communications sont silencieuses et peuvent transporter à peu près n’importe quelle commande, mais elles ne sont en plus pas chiffrées. Elles circulent donc en clair, le composant ne vérifiant pas non plus la signature électronique pour contrôler la provenance des fichiers binaires éventuellement envoyés.
Ce qui fait dire à BitSight, interrogé par Ars Technica, qu’il s’agit d’une « compromission complète du système » et que les pirates menant une attaque de type homme du milieu « peuvent faire ce qu’ils veulent ». En clair, ces smartphones étaient vulnérables dès lors qu’ils étaient connectés à des points d’accès Wi-Fi publics ou plus globalement l’ensemble des réseaux non-sécurisés.
55 modèles, pour environ trois millions d'utilisateurs
Selon les propres statistiques fournies par la société de sécurité, 55 modèles différents se sont connectés aux fameux domaines. 26 % provenaient de chez BLU, 11 % de chez Infinix, 8 % de chez Doogee, et environ 4 % pour Leagoo et Xolo. Tous ces constructeurs ont été avertis, mais actuellement seul BLU a réagi.
La situation est loin d’être résolue, car la société chinoise Ragentek n’a pas encore réagi. En outre, 47 % des modèles qui se sont connectés aux domaines ne renvoyaient aucune information sur les constructeurs. BitSight indique donc que les prochaines semaines devraient faire grandir la liste des fabricants à avertir. Actuellement, trois millions d’utilisateurs seraient concernés, essentiellement sur le marché américain.
En attendant, les utilisateurs éventuellement touchés ne peuvent rien faire pour colmater le trou béant dans la sécurité, à moins d’utiliser systématiquement une connexion VPN quand ils se connectent sur un réseau public. Notez que l’US-CERT a publié un bulletin d’avertissement listant notamment l’ensemble des modèles touchés par le problème.
Commentaires (72)
#1
j’comprends mieux pourquoi Trump fait pas confiance aux autorités et aux entreprises chinoises…
#2
C’est triste… mais bon, c’est une des (nombreuses) différences entre des tél chinois à 50-100 balles et du matos moyen/haut de gamme d’une marque reconnue.
La qualité du firmware, sa validation technique, son suivi, etc ont un cout non négligeable…
Ca empeche pas les grandes marques d’avoir des problèmes de sécurité mais ça évite au moins les cas aussi graves de ce genre.
#3
Comment l’entreprise a-t-elle pu laisser sortir de l’usine des produits avec un rootkit qui tente de joindre des domaines que personne ne possédait ?! Les mecs qui ont trouvé la faille ont du halluciner en voyant qu’ils pouvaient acheter les domaines " />
#4
Lol! Tous les jours c’est jackpot!
Un jour, les gens réfléchiront.
Ou pas. Mais au moins ils auront été avisés…
#5
Mais grave, t’as l’impression un pouvoir énorme je suis sûr en découvrant ça. " />
#6
[Mode théorie du complot ON]
C’est la NSA, ne pouvant plus aspirer directement les données des Américains directement et sachant que les terroristes achètent des cartes prépayées et des téléphones jetables (pas chères), donc la NSA a piraté directement le constructeur de composant chinois pour y introduire ces failles justes après la phase de validation du code et ainsi pourvoir poursuivre leur travail de surveillance.
d’une pierre deux coups, continuation de la surveillance massive + en cas de découverte mettre ça sur le dos des chinois.
[Mode théorie du complot OFF]
#7
si c’est sur des smartphones bas de gamme, ça veut dire qu’ils veulent espionner les pauvres ?
#8
#9
#10
#11
Voilà qui résume bien la situation catastrophique de l’univers Android.
Et oui je mets tout le monde dans le même panier car combien de temps avant que des failles similaires soient découvertes chez les autres ?
Les constructeurs ont beaucoup trop de pouvoir sur le software, situation paradoxale vu qu’ils n’ont pas le temps ou les compétences pour s’en occuper.
#12
#13
Ordre direct des services de renseignements Chinoise, puis finalement ils en mettent tellement partout qu’ils l’ont oublié dans un coin :d
#14
Merci pour l’article. Et donc, elle est où la liste de terminaux concernés ? Je ne comprends pas.
“En attendant, les utilisateurs éventuellement touchés ” => mais quels utilisateurs ??
EDIT : Donc ce serait restreint à uniquement la marque BLU inconnue au bataillon et dont personne ne parle sur les forums. A voir si l’on découvre le problème sur d’autres marques (Huawei " />).
#15
lol Android :)
vive Symbian !
#16
C’est surtout qu’après 18 mois t’as plus de mises à jour officielles… Et encore parfois c’est avant, coucou Samsung… Pendant ce temps-là Apple et iOS sont suivis pendant 4 ans.
CQFD.
" />
#17
#18
En est-on réellement sûr?
Vu que beaucoup de choses sont sous traités et que tout dépend de qualcomm and co, ils restent dépendant d’eux.
JE doute franchement qu’un contrôle précis soit fait ni puisse être fait…
Genre si le bordel ne s’active qu’après une date précise postérieur au contrôle, va t’en voir quoi que ce soit.
#19
#20
Ça se règle toujours à coup de WireShark : j’adore !
Moi j’ai laché l’affaire , j’en avais marre de voir que tout le monde espionne tout le monde …
Les pires étant les GAFAM, Apple en tête.
En ce moment dans ma DMZ j’ai même du DNS tunneling avec des débits à 4 Mbit .. sur le serveur windows 2008 r2 du gamin : Teamspeak et consort , AH MORT !
#21
on dirait du pure CNC
#22
#23
Si on avec le bon matos on voit largement 99.9 % de ce qui rentre ou sort … j’ai ça chez moi.
le problème c’est qu’il faudrait “taper sur la gueule” de tout le monde pour qu’ils arrêtent leur backdoor commerciale ou pirate … alors on lâche l’affaire …
#24
sniff le traffic d’un matos apple sur ton réseau revient en discuter … (curieusement vers les 1-3 h du mat … il s’en passe bcp de choses sur un matos apple …)
#25
#26
Non ce n’est pas complexe il suffit de bien isolé le traffic de chaque matos : ce que je fais chez moi.
#27
#28
Je ne me souviens pas de Sony, mais Lenovo oui (et Acer dans une moindre mesure). Mais, uen fois qu’on leur a mis leur nez dans leur m, ils ont préféré stopper …
#29
… régle de base : isolation de traffic …
on voit tout.
#30
#31
Moi j’attends juste qu’une société Chinoise spécialisée dans la sécurité démontre la présence de portes dérobées dans du matériel US (même si ça a déjà été fait par un Français).
C’est quand même impressionnant de voir à quel point certains ont une confiance aveugle dans le matériel Américain. " />
#32
faut pas lire “BitSight” trop vite. Ils ont du potentiel en contrepèteries. " />
#33
#34
#35
… les métadonnée ma caille … les métadonnées … chiffré ou pas … on s’en fout.
De plus :
Note : Mon firewall décrypte le SSL à la volé (il intercepte les certificats si tu préfère) mais sur du GRE ou autre … je suis aveugle sur le contenu … mais pas en terme de métadonnée … .
Je suis d’accord que le smartphone est un chiasse à ce niveau : il te nique dés qu’il prends un flux GSM !
(même éteint on le choppe !)
je parlais pour ce qui est à la maison hors flux GSM
#36
#37
Tout cela serait évité si tous les éléments (en plus du kernel Linux modifié), les drivers et applications par défaut, étaient publiés sous license GPL. Les utilisateurs avancés pourraient auditer leur téléphone.
#38
#39
#40
Mais lancer un DDOS à partir de Sigfox, c’est compatible avec la limitation drastique en terme de débit de données ?
#41
Oui enfin pour les téléphones chinois c’est comme le reste d’Android, tu prends ceux qui ont un suivi logiciel connu et tu vires la ROM du revendeur pour en mettre une à ton goût. Bref, un peu de discernement à l’achat et non ils ne seront pas meilleur que le dernier Samsung Galaxy mais pas forcément moins bien sur certains aspects (enfin en dessous de 100€ ça commence à être chaud la ;P)
#42
Un code obfusqué ne peut être considéré comme du code source.
#43
#44
#45
#46
#47
Tu es bien optimiste. Tu pourrais être touché.
#48
“En outre, 47 % des modèles qui se sont connectés aux domaines ne renvoyaient aucune information sur les constructeurs.”
#49
Pas si c’est actif uniquement avec les données mobiles.
#50
une importante porte dérobée dans 55 modèles de terminaux Android
rien ne semble indiquer une volonté de nuisance, tout portant à croire qu’il s’agisse d’une vraie erreur technique
" />
Pardon, mais une porte dérobée et une faille ce n’est pas la même chose. Du tout. Du coup le titre de l’article est inexact, voire mensonger.
Alors Vincent, simple erreur de ta part ou volonté de mettre un titre racoleur?
#51
#52
On peut difficilement nier la présence de la porte dérobée avec les éléments avancés. Par contre vu qu’elle n’est pas exploitée, sa présence n’est peut-être qu’une erreur technique.
Edit : arf, grillé.
#53
C’est pourtant clair: soit c’est volontaire et donc c’est bien une backdoor, soit c’est involontaire et alors c’est une faille.
#54
#55
Pas besoin de posséder le nom de domaine pour exploiter ce rootkit ; Il suffit de DNS menteurs dans des wifi ouverts au publique (genre Macdo ou starbuck)
. Une petite promo pour pousser ces téléphones à une population donnée et il n’y a plus qu’à attendre les connections.
#56
#57
#58
fabrication chinoise
qualité chinoise
rootkit chinois
tout ça pour un prix chinois
mais distribution chinoise (à savoir pire qu’une pandémie) " />
One rootkit to rules them all … Sauron said " />
(ils ont vraiment oubliés d’être des nocs les noichis " /> ).
#59
J’ai parlé de milions de hot spots? Réfléchis un peu avant de déverser ton fiel.
Réserver un nom de domaine laisse des traces, aménager une résolution de nom sur des hot spots n’est pas compliqué.
Cas 1: une socitété qui s’occuperait des hot spots pour Macdo (un pur exemple), pourrait introuire cela et c’est indétectable. Cela peut vite concerner beaucoup de routeurs car le nombre de sociétés sous-traitantes est limité au maximum.
Cas 2: un état peut se permettre de placer cette résolution pirate dans beaucoup de routeurs, grace aux failles qu’ils maîtrisent.
#60
… on fait ce qu’on peu : on résiste , non ?
#61
Sigfix, LoRa pareil pour moi: j’ai donné un nom, mais tous ces protocoles, par construction, n’ont pas une bande passante phénoménale (en vertu du théorème de Shannon sur le rapport S/B)
Celà étant, ma question était une vraie question, pas une mise en doute totale. Sans données quantifiées, pas moyen de savoir si le nombre d’appareils peut compenser le faible débit à l’unité.
Par contre, je n’y avait pas pensé, mais comme réseau de commande (du DDoS envisagé), c’est royal.
#62
+1
#63
#64
#65
justement, si on veut être prudent on met au moins un point d’interrogation à la fin du titre…
#66
… ce qui en emmerde beaucoup c’est ce qui bossent … à l’ancienne .
pas de smartphone, pas d’ordi , pas d’internet … et ouaih !
#67
Il ferait bien de ne pas faire confiance aux autorités de son pays aussi ^^
#68
#69
… les braconniers , entre autres.
Puis les FAMOUS “terroristes” (djihadistes) , ben non eu y sont bêtes : ils utilisent le web , les smartphone, laissent leurs cartes d ‘identités sur place (etc et etc) : bref tout pour se faire chopper , qu’est ce qu’y sont bêtes ces terroristes ! !
#70
Ah oui, je me souviens de ça maintenant. Ce n’était pas la branche PC mais la branche musique.
#71
#72