Google Chrome, le bavard !

Hello,
Aujourd’hui je vais  parler de Google Chrome bien que je ne l’utilise pas ! (plus depuis un moment)

Ce petit billet va s’articuler autours de cette vulnérabilité :
https://seclists.org/fulldisclosure/2019/Jan/2

Alors vous n’êtes pas sans savoir que sur Android, il existe plusieurs navigateurs Web tel Firefox. Le plus utilisé d’entre eux est “Google Chrome” sans grande surprise.
Il peut en exister d’autres, mais globalement ils utiliseront soit le moteur de Chrome (WebView) soit celui de Firefox (Gecko).
Microsoft possédait lui aussi le sien fait maison (Edge), mais abandonné récemment au profit de WebView.

Entre parenthèses, un problème de grande taille est en train de se poser, vis-à-vis de la domination du Web par Google via WebView.
Domination sous plusieurs formes, mais ce n’est pas le but du billet de l’expliquer, et je m’y prendrai sûrement très mal.

Seulement voila, sur mobile, Chrome est un peu trop bavard par défaut et divulgue une info qui peut être considéré comme “sensible” pour le terminal via le “HTTP Header”. Cette info est le “Build Number” soit le Numéro de version du système installé sur votre téléphone. Ce numéro est spécifique à l’appareil et est choisi par le fabricant.
Une personne mal intentionné peut se servir de ce Numéro de Build pour connaître les vulnérabilités du téléphone. Avec ce numéro, on connaît la version exacte du système Android et à quelle niveau il en est vis-à-vis des Mises à jours de sécurité.

General Header. Request Line. Status Line. Request Header. Response Header. Entity Header. Empty Line. Message Body. (entity body or encoded entity body.

La disclosure annonce que Chrome fût mis à jour, et que le problème est réglé.

Du coup j’ai look dans mes logs apaches en mode gros porc (avec un cat et un grep), voici un résultat au hasard pour Chrome:
(Linux; Android 7.0; SM-G928F Build/NRD90M;wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/71.0.3578.99 Mobile Safari/537.36"
SM-G928F => GalaxyS7
NRD90M => Android 7.0.0, première build de Android Nougat, date de 2016…

Et voici deux En-tête HTTP différents depuis Firefox sur un Android :
(Android 8.1.0; Mobile; rv:64.0) Gecko/64.0 Firefox/64.0"
(Android 4.4.2; Tablet; rv:62.0) Gecko/62.0 Firefox/62.0"

C’est beaucoup moins bavard ! On peut savoir la version d’Android certes de base, mais pas le modèle de l’appareil, ni le numéro de version.

Ce qui est “Con” c’est que Chrome laisse fuiter une info comme ça tranquille alors que sur Firefox il faudrait vous l’extirper à coup de JS.
Pour le navigateur le plus utilise c’est très moyen. Et il y a de grandes chances qu’a l’avenir, grâce a leur futur hégémonie, Google contrôlera les standards du web de manière implicite…
Du coup sur un Android je conseille Firefox, sur le store Fdroid vous trouverez Fennec que je conseil. Et on y installe Noscript et ublock-origin à minima.
Si vous persistez à utiliser Google Chrome, apparemment vous êtes “protégés” en utilisant la fonction “Voir version ordinateur” (Je n’ai pas fait de test).

@++ et hésitez pas à réagir 😉 .

https://www.androidpolice.com/2016/08/23/aosp-changelog-posted-for-android-nougat-v7-0-0_r1-nrd90m/
https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/Google-Android.html
https://www.androidpolice.com/android-build-number-date-calculator/

Faire réparer son smartphone par un tiers

Hello,

Vous allez bien j’espère ? Sinon prenez soin de vous !

Quand on emmène sa voiture au garage, on vérifie qu’on à rien laissé traîner dedans et rien oublié de compromettant. Idem quand on sait qu’on va chez le médecin on met en général un calbute propre pour l’image. On ne laisse pas nawak s’immiscer chez soi. La liste est longue.

Mais pour le téléphone, le pc ou la tablette ? Quand je regarde autour de moi, dès qu’il y a une panne ou le moindre pépin, en général le premier réflexe est de confier la bête défaillante au premier gars qui s’y connaît selon la réputation général (Je connais un geek…). Il y a de grande chance que ce soit toi lecteur !

Ce geek peut être un simple amateur comme un pro et s’y on n’en connaît pas on emmène le produit au premier “réparateur” que l’on trouvera. Seulement voila, ses petits engins contiennent bien trop de données que vous ne voulez pas donner à n’importe qui. Mais déjà la personne dans le besoin est souvent inconsciente de l’existence de logs par exemple et ne sait pas ce que l’on peut faire avec ADB aussi. D’ailleurs il doit bien exister des ateliers de réparation mais seulement en façade, où le fond de commerce serait le vol des données.  Ça peut être tellement lucratif…

Mais que faire alors?
Suicide toi, tu as plus de téléphone !

Non je rigole et en plus c’est puni par la loi d’inciter quelqu’un à se suicider (La manipulation mentale devrait être punie plutôt).
Hormis la rigolade, il existe de nombreux cas répertoriés ou les personnes se suicidaient après la publication de leurs données (Photos de nues, etc) car justement elles n’avaient pas conscience des enjeux. Souvent c’est juste du RevengePorn mais ça c’est autre chose.

Dans le cas du smartphone et de la tablette :
Sauvegardez vos données.
Réinitialisez votre téléphone.
Enlevez la SDCard bien-sûr.

Si vous ne pouvez pas faire ces choses la, ne donnez pas le code de votre téléphone, demandez à le déverrouiller vous même le moment venu (afin de tester la réparation) et à assister à l’opération. (Pour changer une vitre brisée nul besoin de brancher le téléphone à quoi que ce soit). Si refus, cassez vous de la où vous êtes.

C’est le moment aussi de chiffrer votre smartphone si ce n’était pas déjà fait ! Allez faire un tour dans les paramètres de sécurité.

Dans le cas d’un PC :
Enlevez le/les disque(s) dur(s).

Si ce n’est pas lui le problème un réparateur sérieux saura pallier au manque du disque dur sinon cassez vous aussi et oubliez le ! Si votre disque est chiffré on suppose que la robustesse du mot de passe est bonne mais ça ne dispense pas d’enlever le DD si possible (On ne sait pas ce que l’avenir nous réserve), sinon le chiffrement devrait dissuader le “voleur” sauf si vous êtes vraiment une “cible” (Je regarde le BDL en ce moment…)
Sinon c’est le moment de conseiller BlackMirror si vous ne connaissez pas comme série. Ça glace le sang mais c’est pas pour rien 😉

En conclusion :
Il faut être conscient qu’au moment de la panne on sera le plus vulnérable à un vol de données car ces engins agissent tels de la drogue sur nos cerveaux. Ne vous faites pas piéger ! Et c’est l’occasion de s’essayer au DIY
Et si un proche a un problème, il vaut mieux l’aider soi-même plutôt qu’un inconnu. Le vol de données peut impacter, selon les cas, les contacts de la victime.

Un vol de données n’est pas forcement visible, quand on s’en rend compte c’est déjà trop tard !

Si vous avez d’autres conseils, expériences à partager, la moindre réaction, hésitez pas !

@++


https://www.hacker9.com/read-before-you-surrender-phone-to-repair-shop.html
https://dangerouspayload.com/2018/10/24/emmc-data-recovery-from-damaged-smartphone/
http://bits-please.blogspot.com/2016/06/extracting-qualcomms-keymaster-keys.html
https://www.ifixit.com/

Faille Zero-Day affectant virtualbox, se protéger facilement

Un petit billet sur le zéro-day de virtualbox :
VirtualBox E1000 Guest-to-Host Escape

Si Sergey Zelenyuk, chercheur russe basé à Moscou (Alors hein, ils sont pas tous méchant les Russes, Spasieba à lui !! ) a publié une seconde faille c’est pas car il déteste virtualbox mais car Oracle qui gère le logiciel, a traîné en longueur pour patcher et  à la va vite en plus, il dénonce aussi par la même occasion la gestion de la sécurité informatique et des bugs bounty ( comment lui en vouloir ).

Source : https://www.zdnet.fr/actualites/une-zero-day-sur-virtualbox-et-pas-mal-de-grognements-39876125.htm

Du coup dans les prochains jours faites attentions aux VMs qui apparaissent, et autant passer à la virtualisation avec QEMU/KVM, c’en sera plus performant est moins faillible. Le POC est pas valable sur des hyperviseurs de type 1.  Mais vu que tout les détails sont publies il faut s’attendre a ce que des VMs deviennent des cibles pour attaquer les systèmes hôtes.

Par contre coté cloud il y a pas de raisons de s’inquiéter, vu que la majorité des fournisseurs de services fonctionnent avec des hyperviseurs de type 1.

Le lien vers mon billet précédant pour mettre en place de la virtualisation avec QEMU/KVM (type1)

Si vous continuez d’utiliser VirtualBox, le seul moyen pour se protéger de cet exploit est de désactiver sur la VM le NAT et dans la configuration de la carte réseau, choisir autre chose que “Intel PRO/1000”.  Car cette vulnérabilité marche quel que soit le système d’exploitation virtualisé.

Pour savoir si on est sur une machine virtuelle, on peut utiliser l’utilitaire “dmidecode”.

Pour plus de détail notamment le code avec explications ( In English ), voir la vidéo ainsi que la page GitHub de l’exploit

 

Hésitez pas a réagir.