Sécurité info - Page 51

Ça fonctionne toujours

https://www.zdnet.com/article/israeli-military-tricked-into-installing-malware-by-hamas-agents-posing-as-women/

Comme quoi, il faut se méfier des femmes

Ah les femmes, toujours un trou de sécurité

https://www.zdnet.com/article/intel-csme-bug-is-worse-than-previously-thought/ :
Security researchers say that a bug in one of Intel's CPU technologies that was patched last year is actually much worse than previously thought.

"Most Intel chipsets released in the last five years contain the vulnerability in question," said Positive Technologies in a report published today.

Attacks are impossible to detect, and a firmware patch only partially fixes the problem.

To protect devices that handle sensitive operations, researchers recommend replacing CPUs with versions that are not impacted by this bug. Only the latest Intel 10th generation chips are not vulnerable, researchers said.

Youpi !

D'apres les gens bien informés ici c'est pas si pire que ca en a l'air

pour l'instant l'exploitation est loin d'être triviale, et en plus, elle ne concerne que des systèmes qui ont absolument besoin de ce genre de secure boot.

L'attaque n'est peut-être pas triviale à réaliser sur une machine donnée, mais une fois que quelqu'un l'aura réalisée, d'après ce qu'indique le chercheur en sécurité qui trouvé le problème, les informations qu'on peut en dériver s'appliqueront à toutes les machines du même modèle, et pourront être utilisées pour faire des choses... intéressantes:
https://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html
indique notamment

An early-stage vulnerability in ROM enables control over reading of the Chipset Key and generation of all other encryption keys. One of these keys is for the Integrity Control Value Blob (ICVB). With this key, attackers can forge the code of any Intel CSME firmware module in a way that authenticity checks cannot detect. This is functionally equivalent to a breach of the private key for the Intel CSME firmware digital signature, but limited to a specific platform.

The EPID issue is not too bad for the time being because the Chipset Key is stored inside the platform in the One-Time Programmable (OTP) Memory, and is encrypted. To fully compromise EPID, hackers would need to extract the hardware key used to encrypt the Chipset Key, which resides in Secure Key Storage (SKS). However, this key is not platform-specific. A single key is used for an entire generation of Intel chipsets. And since the ROM vulnerability allows seizing control of code execution before the hardware key generation mechanism in the SKS is locked, and the ROM vulnerability cannot be fixed, we believe that extracting this key is only a matter of time. When this happens, utter chaos will reign. Hardware IDs will be forged, digital content will be extracted, and data from encrypted hard disks will be decrypted.

"Digital content will be extracted" sera une bonne chose, et c'est peut-être d'ailleurs de là que viendront les extractions de Chipset Keys: l'incitation est puissante.
"Data from encrypted hard disks will be decrypted" ne sera pas une bonne chose, même si j'imagine que ça s'appliquera seulement à ceux - nombreux - qui utilisent le chiffrement transparent délégué au firmware du processeur/chipset (et/ou au firmware du disque, même combat), ce qui a toujours été une mauvaise idée, certains l'ont dit bien avant qu'il soit prouvé que c'était fait n'importe comment. BitLocker n'aurait jamais dû les utiliser.
"Forge the code of any Intel CSME firmware module in a way that authenticity checks cannot detect" sera encore pire.

Ah ils ont trouvé Intel comment faire racheter des proços malgré le fait qu’il n’y a aucun changement positif 🇺🇸

On savait que les processeurs AMD étaient sujets à un sous-ensemble des vulnérabilités liées à l'exécution spéculative qui affectent les processeurs Intel, ou des variantes de ces vulnérabilités. Eh bien, il y a d'autres failles dans les processeurs AMD, sans grande surprise, du reste
https://www.tomshardware.com/uk/news/new-amd-side-channel-attacks-discovered-impacts-zen-architecture et autres.

https://www.amd.com/en/corporate/product-security contient au moins deux recommandations stupides combinées dans une phrase, "Utilizing safe computer practices and running antivirus software": la vulnérabilité est exploitable en utilisant JS, qui est activé sur tous les sites par presque tout le monde, et les pro-virus, outre leur incapacité structurelle persistante à détecter les vraies menaces, ajoutent des failles.

Celle-là va plaire à Lionel :

Avast disables JavaScript engine in its antivirus following major bug :
Vulnerability would have allowed attackers to take over computers running the Avast antivirus.

Oui, je l'avais vu passer par relais de Tavis Ormandy.
A une époque, Avast était plutôt moins mauvais que les autres, c'était notamment un des rares pro-virus qui faisaient l'interception des communications TLS du browser sans massacrer complètement le chiffrement (downgrades TLS 1.2 clean -> TLS 1.0 avec Poodle TLS...), mais entre le fait d'espionner les actions utilisateur dans le browser et de vendre les données, ainsi que des stupidités de sécurité comme celle-ci, ils baissent...

Parmi les autres actualités importantes de la semaine, dans le sens où elles touchent des centaines de millions d'équipements chacune, il y a:
* , Snoop Assisted L1D Sampling;
* , Load Value Injection sur une large gamme de processeurs Intel, pas de vraie mitigation hors SGX pour l'instant, et il est toujours indispensable (depuis RIDL / Fallout / ZombieLoad) de désactiver l'hyperthreading des processeurs Intel;
* , Rowhammer amélioré qui fonctionne super bien sur un nombre certain de modèles de DDR4 et LPDDR4 (grâce à une méthode pour fuzzer les mitigations de Rowhammer);
* CVE-2020-0796, RCE wormable (CVSSv3 10.0) dans les services SMB de Windows 10 et Windows Server modernes (mais pas les anciennes versions, pour une fois, c'est à cause d'une nouvelle feature).

Deux 0-days de CVSS élevé, et 3 autres problèmes de CVSS maximal, dans un pro-virus déjà pointé du doigt récemment:
https://www.zdnet.com/article/two-trend-micro-zero-days-exploited-in-the-wild-by-hackers/

Faille grave dans Windows avec la gestion des polices, pas encore de patch (mais quelques workarounds) :

Changer n'importe quel mdp Windows 10 (avec accès à la machine): https://korben.info/mot-de-passe-windows-perdu-ou-oublie-comment-faire-recuperer-un-acces-a-la-machine.html

C'est gros quand même ?

Où est le problème ? Si le disque n'est pas chiffré, tu peux toujours changer le mot de passe de n'importe quel compte sur n'importe quel OS (y compris macOS ou Linux) en montant la partition système depuis un autre OS.

Des qu'il y a acces physique a une machine tu peux la considerer compromise quelque soit les solutions que tu ai pu mettre en place.

(certes, mais ce n'est pas totalement inutile non plus)

ca ralentit, comme une serrure 3 points...

Oui, et ça demande de changer de gamme d'attaquants, c'est toujours ça de pris.

Bien sur

de "gamme d'attaquant", première fois que j'entends l'expression

"Alors vous avez ici nos attaquants entrée de gamme, accessibles à toutes les bourses, et plus loin les attaquants premium "

Bah tu rigoles, mais c'est effectivement ça
Les attaquants sont classés en fonction des ressources qu'ils peuvent investir dans une attaque, par exemple par ordre croissant "amateur éclairé", "entreprise commerciale", et "État" (j'avais vu un tableau comme ça quelque part, avec les ordres de grandeur de budget et de puissance de calcul dispo).

Même pour un État, tu auras plusieurs niveaux d'attaques.
Tu peux par exemple avoir accès à un personnel d'entretien qui ne sait que brancher une clef USB discrètement (mais qui n'a aucune autre compétence). Faire venir un vrai geek qui saura faire davantage sera tout de suite plus compliqué.

flanker (./1514):
Où est le problème ?

Bin, euh... quand même !

flanker (./1514):
Si le disque n'est pas chiffré

Oui il y a quand même cette limite, il dit bien qu'il faut la clé bitlocker dans un coin. Ouf.

flanker (./1514):
tu peux toujours changer le mot de passe de n'importe quel compte sur n'importe quel OS (y compris macOS ou Linux)

Justement, pour Windows j'aurais pas pensé.

Godzil (./1516):
Des qu'il y a acces physique a une machine tu peux la considerer compromise quelque soit les solutions que tu ai pu mettre en place.

Ouais... ça dépend où, à qui et pour quel niveau de données, mais dans l'absolu, oui certes ^^

M'enfin typiquement, piquer un ordi portable et fouiner son compte en quelques dizaines de minutes, je pensais que c'était pas à la portée du premier venu. En fait si (si pas chiffré, on est d'accord).

Bin pour fouiner dans le contenu d'un ordi portable, pas besoin de changer le mot de passe : suffit de booter sur n'importe quel LiveCD de Linux.
Le chiffrement intégral du disque sert très exactement à contrer cette menace (du coup, ce n'est pas très étonnant qu'on puisse le faire si ce n'est pas activé).

Je radote peut-être (0^2 ^^ ?), mais une autre méthode intéressante pour fouiner dans le contenu d'un ordinateur consiste à tirer parti de l'AMT d'Intel.
Les machines grand public en sont en général dépourvues, mais beaucoup de machines d'entreprise, portables ou fixes, sont équipés de cette partie du ME. Le vilain AMT est parfois activé, personne ne met à jour le firmware des machines plus anciennes alors qu'il y a eu plusieurs vulnérabilités critiques au cours du temps, Intel ne maintient pas très longtemps les versions de firmware ME donc il y a des failles non corrigées... et même quand AMT est désactivé par défaut et que le firmware ME est une version récente sans failles critiques publiées, comme personne ne change le mot de passe par défaut de la MEBx ("admin") malgré les guidelines de déploiement d'Intel, un accès physique de quelques minutes suffit pour redémarrer l'ordinateur, le bouton marche-arrêt étant le plus rapide, rentrer dans la MEBx avec le mot de passe par défaut, le changer en ce qu'on veut et activer l'AMT pour pouvoir ultérieurement faire des bêtises sur la machine à distance (sans que l'utilisateur en soit forcément averti), puis redémarrer l'ordinateur. Quand la personne qui utilise la machine cible reviendra, ce redémarrage la fera râler, mais il ne paraîtra même pas forcément suspect, surtout au moment du Reboot "Wednesday" (parfois légèrement décalé en entreprise)...

Les BMCs (iLO, iDRAC, etc.), même combat: souvent activés par défaut mais pas utilisés, firmwares obsolètes, multiples RCE sans authentification. Compromission complète des machines à bas niveau.

Le remote management à bas niveau, c'est bon, mangez-en

Lionel Debroux (./1526):
Les BMCs (iLO, iDRAC, etc.), même combat:

Au moins pour iLO (et je suppose pour les autres), le mdp par défaut est unique sur chaque machine.
Par contre, il est écrit sur une languette sur le serveur, donc si c'est pas soit changé () soit arraché, bin effectivement pas très dur de se connecter en remote.

flanker (./1525):
Bin pour fouiner dans le contenu d'un ordi portable, pas besoin de changer le mot de passe : suffit de booter sur n'importe quel LiveCD de Linux.

Oui et non. Je suis d'accord avec toi, mais consulter le Outlook/Thunderbird de la victime, ça va plus vite en bootant sur sa session qu'en extrayant ses fichiers... voir en imap, ça marche pas du tout avec le contenu du disque dur.

redangel (./1527) :
voir en imap, ça marche pas du tout avec le contenu du disque dur.

Il y a un généralement un cache local, donc exploitable. En tout cas pour les clients natifs (je ne sais pas si les clients web le font aussi via Local Storage).

avec thunderbird les emails imap sont téléchargés (et ca pèse vite, ouille!)

redangel (./1527) :

Lionel Debroux (./1526):
Les BMCs (iLO, iDRAC, etc.), même combat:

Au moins pour iLO (et je suppose pour les autres), le mdp par défaut est unique sur chaque machine.
Par contre, il est écrit sur une languette sur le serveur, donc si c'est pas soit changé () soit arraché, bin effectivement pas très dur de se connecter en remote.

flanker (./1525):
Bin pour fouiner dans le contenu d'un ordi portable, pas besoin de changer le mot de passe : suffit de booter sur n'importe quel LiveCD de Linux.

Oui et non. Je suis d'accord avec toi, mais consulter le Outlook/Thunderbird de la victime, ça va plus vite en bootant sur sa session qu'en extrayant ses fichiers... voir en imap, ça marche pas du tout avec le contenu du disque dur.

Mais soit tu as un accès pérenne à son ordi et dans ce cas, j'imagine que le critère de vitesse n'a pas trop d'importance, soit tu dois rendre l'ordi à la victime et il va vite se rendre compte de quelque chose si tu as changé son mot de passe.
Bref, dans tous les cas : il faut chiffrer intégralement son disque