 |
Assiste.com
| |
Full disclosure (divulgation intégrale de failles)
Full disclosure : divulgation intégrale de failles de sécurité, incluant techniques d'exploitation et mode d'emploi pour utiliser la faille. Controverses sur l'intérêt/la nécessité du full disclosure.
16.09.2023 : Pierre Pinard.
 |
|
Dossier (collection) : Encyclopédie |
|---|
| Introduction Liste Malwarebytes et Kaspersky ou Emsisoft (incluant Bitdefender) |
| Sommaire (montrer / masquer) |
|---|
Sécurité informatique - Vie privée - Neutralité |
Il n'existe pas de programmes informatiques 100% sans erreur.
En matière de sécurité informatique, il existe, en permanence, des découvertes d'erreurs dans le code des programmes. Certaines erreurs ne sont que de simples « bugs » comme, par exemple, un programme de paie qui multipliérait par 100 mon salaire. Mais certaines de ces erreurs peuvent être exploitées pour provoquer un comportement inattendu du programme ou de l'appareil sur lequel il s'exécute. On appelle ces erreurs des failles de sécurité.
La manière dont les découvreurs de failles de sécurité communiquent les résultats de leurs découvertes est sujette à d'interminables polémiques.
- Certains sites d'alertes, dont des sites gouvernementaux, (l'un des CERT [« Computer Emergency Response Team » - « Équipe d'intervention d'urgence informatique »], en France, dépend du Premier Ministre), révèlent, à titre préventif, des failles non corrigées, mais sans en donner les caractéristiques techniques ni le mode d'emploi : uniquement l'état de l'art et d'éventuels moyens de contournement en attendant la publication d'un correctif par l'éditeur. Il s'agit d'alerter les responsables de la sécurité des systèmes d'information, par exemple pour suspendre l'usage d'un dispositif faillible, ou le déconnecter de l'Internet, le temps qu'un correctif soit disponible.
- Malheureusement, une lecture inverse de ces alertes constitue une source d'informations sur le failles de sécurité pour les cybercriminels.
Quant aux sites ou forums des « chevaliers blancs » (les « gentils hackers » ou « white hat » ou « chapeaux blancs ») et des « chevaliers noirs » (les « méchants hackers » ou « black hat » ou « chapeaux noirs »), ils publient le détail des failles et leurs modes d'emploi. C'est le « Full disclosure ». Ils le font :
- soit dès la découverte de la faille, pour se faire mousser dans le milieu des hackers (« chevaliers noirs ») - c'est un problème d'ego.
- soit pour faire bouger les choses lorsque, après une à plusieurs alertes auprès de l'auteur/éditeur du code faillible (période plus ou moins longue dite de « sécurité par l'obscurité »), l'alerte est totalement ignorée (« chevaliers blancs » outrés par la désinvolture de l'auteur/éditeur).
| Annonce |
Il s'agit de la découverte d'une faille de sécurité, par Google, dans Windows (de Microsoft, le concurrent, l'ennemi). Si le principe chronologique « découverte » 
« signalement secret et enregistrement CVE » « période de grâce » (« sécurité par l'obscurité ») « correction ou Full disclosure » est présenté dans cet exemple, il dévoile également les dessous pervers de son usage dans un monde concurrentiel (Google contre Microsoft) où blesser l'un rapporte des milliards à l'autre. Les mensonges et les politiques industrielles à long terme dirigent ces agissements qui n'ont rien à voir avec des conduites propres et honnêtes allant dans le sens de l'utilisateur pour lui offrir un WEB plus sûr. Google, en ce sens, oeuvre pour sortir ses coucurrents du premier cercle du pouvoir.
1ère étape - le prétendu signalement secret de la faille à l'auteur, le 30 septembre 2014
« Platform: Windows 8.1 Update 32/64 bit (No other OS tested)
On Windows 8.1 update the system call NtApphelpCacheControl (the code is actually in ahcache.sys) allows application compatibility data to be cached for quick reuse when new processes are created. A normal user can query the cache but cannot add new cached entries as the operation is restricted to administrators. This is checked in the function AhcVerifyAdminContext.
This function has a vulnerability where it doesn't correctly check the impersonation token of the caller to determine if the user is an administrator. It reads the caller's impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem's SID. It doesn't check the impersonation level of the token so it's possible to get an identify token on your thread from a local system process and bypass this check. For this purpose the PoC abuses the BITS service and COM to get the impersonation token but there are probably other ways.
It is just then a case of finding a way to exploit the vulnerability. In the PoC a cache entry is made for an UAC auto-elevate executable (say ComputerDefaults.exe) and sets up the cache to point to the app compat entry for regsvr32 which forces a RedirectExe shim to reload regsvr32.exe. However any executable could be used, the trick would be finding a suitable pre-existing app compat configuration to abuse.
It's unclear if Windows 7 is vulnerable as the code path for update has a TCB privilege check on it (although it looks like depending on the flags this might be bypassable). No effort has been made to verify it on Windows 7. NOTE: This is not a bug in UAC, it is just using UAC auto elevation for demonstration purposes.
The PoC has been tested on Windows 8.1 update, both 32 bit and 64 bit versions. I'd recommend running on 32 bit just to be sure. To verify perform the following steps:
1) Put the AppCompatCache.exe and Testdll.dll on disk
2) Ensure that UAC is enabled, the current user is a split-token admin and the UAC setting is the default (no prompt for specific executables).
3) Execute AppCompatCache from the command prompt with the command line "AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll".
4) If successful then the calculator should appear running as an administrator. If it doesn't work first time (and you get the ComputerDefaults program) re-run the exploit from 3, there seems to be a caching/timing issue sometimes on first run.
This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public."
Note
Google n'ayant pas enregistré de CVE, IL N'Y A PAS EU DE SIGNALEMENT A MICROSOFT - Ce prétendu signalement est un faux !
2ème étape : « full disclosure » (révélation publique complète) de la faille le 30 janvier 2015
Publié de 30 septembre 2014 - délais donné à l'éditeur : 90 jours (donc échéance au 29.12.2014)
Statut le 03.01.2015 :
Vendor-Microsoft
Product-Windows-Kernel
Severity-High
Finder-forshaw
Reported-2014-Sep-30
CCProjectZeroMembers
Deadline-90
MSRC-20544
PublicOn-2014-Dec-29
Deadline-Exceeded
La description de la faille et son mode d'emploi sont publiés sur le site de Google, ici.
| Annonce |
La tromperie de Google - un agissement criminel au sens de le sécurité comme au sens de l'industrie informatique.
Le code MSRC-20544 semble être un numéro d'identification/d'enregistrement d'une vulnérabilité chez Microsoft, « MSRC » étant l'acronyme du « Microsoft Security Response Center ». De fait :
- Le découvreur de la vulnérabilité, Forshaw, travaille chez Google, sur Google OS
- La publication a été faite sur google.com 3 mois après la prétendue communication faite à Microsoft, mais rien (pas de CVE) à la date d'origine (30 sept 2014)
- Cette faille a bien été enregistrée sur la liste des CVE (Common Vulnerabilities and Exposures), le dictionnaire unique et mondial des informations relatives aux vulnérabilités de sécurité (ce dictionnaire est maintenu par l'organisme MITRE (une organisation à but non lucratif américaine dont l'objectif est de travailler pour l'intérêt public.). Toutes les failles et vulnérabilités sont enregistrées sur la liste des CVE (le format du code est CVE-AAAA-NNNN (CVE-AAAA-NNNNN depuis 2018) où AAAA est l'année de publication et NNNNN est un simple numéro d'ordre (identifiant) de 00001 à 99999) et montrées au public en deux temps :
- de manière totalement secrète avant correction. Il n'y a que le numéro d'enregistrement (par exemple CVE-2015-0002) et sa date qui sont montrés et attestent simplement de l'horodatage dans la base de données du CVE d'un signalement d'une faille qui, elle (description et exploitation), est cachée.
- de manière détaillée une fois la vulnérabilité corrigée.
- Mais cette faille est enregistrée avec le code CVE-2015-0002, c'est-à-dire en tout début de janvier 2015, après l'échéance des 90 jours donnés à Microsoft par Google et juste après le « Full disclosure » du 29 décembre 2014 soit 3 jours après le « Full disclosure » qui a lieu en pleine période de fêtes de fin d'année (le 29 décembre 2014) !
Cette tromperie tente de faire croire à un laxisme de Microsoft mais prouve, surtout, que Google s'est livré à une tromperie et n'a jamais prévenu Microsoft le 30 septembre 2014 afin, 90 jours plus tard, de tirer à boulets rouges sur son concurent. Il s'agit de pratiques trompeuses habituelles de Google qui ne recule devant aucune malveillance pour pourrir et dégrader le WEB à partir du moment où cela se passe dans un domaine ou avec des outils en concurrence avec lui. - en moins de deux semaines, Microsoft publiait et déployait le correctif. Ceci relance les commentaires et polémiques sur l'utilité ou la nocivité du « Full disclosure ».
Tout cela met, une fois de plus, Google en position de tricheur, ce qui va le conduire, pour tenter de se blanchir, 6 mois plus tard, à créer le « Project Zero » pour ne pas passer par les fourches caudines de la liste des CVE en créant un concurrent du CVE pour ses propres besoins et, surtout, pour ses propres méthodes et pour se dédouaner.
| Annonce |
Le 15.07.2014, Google lance un « zero day project » (« Project Zero »).
Il s'agit d'un projet de haute politique industrielle visant à la domination du WEB en donnant une vitrine aux hackers pour publier des failles zero day. Le prétexte est de sécuriser le WEB en se donnant le beau rôle. Le but est surtout de taper sur tout le monde en pratiquant du « full disclosure ».
La découverte de Forshaw n'entre pas dans le cadre du « Project Zero » qui n'existait pas encore. En plus, la faille n'aurait pas été en cours d'exploitation, ou en tout cas, aucune preuve n'aurait été trouvée par le découvreur à la date de sa publication.
| Annonce |
Schneier - Janvier 2007 - Full disclosure - Une foutu de bonne idée !
Un célèbre spécialiste en cryptographie, sécurité informatique et protection de la vie privée, Bruce Schneier, a déclaré, dans un essai de janvier 2007, sur son site :
« Full disclosure -- the practice of making the details of security vulnerabilities public -- is a damned good idea. Public scrutiny is the only reliable way to improve security, while « secrecy only » makes us less secure. »
« Divulgation intégrale -- la pratique consistant à rendre publiques les détails des failles de sécurité est une foutue bonne idée. La transparence publique est le seul moyen fiable d'amélioration de la sécurité, tandis que la politique de « sécurité par l'obscurité » ne fait qu'abaisser notre niveau de sécurité. »
Source (archivée)
Note :
Depuis juillet 2002, il existe une page de centralisation des « Full disclosures » : la Full Disclosure Mailing List.
Full Disclosure Mailing List
| Annonce |
Il y a les hackers qui, après avoir découvert une faille de sécurité, la vendent confidentiellement à des cybercriminels.
Lire : Marché lucratif des ventes de failles de sécurité
La loi 2004-575 du 21 juin 2004, dite « LCEN » (Loi pour la Confiance en l'Économie Numérique), considère que ce type de pratique est incontestablement dangereux et peut entraîner au cas par cas une mise en cause pénale du chef de complicité par fourniture de moyens (portail d'accès) d'une infraction principale d'introduction frauduleuse sur le réseau à condition de rapporter la preuve de l'élément intentionnel du complice. Il sera tenu compte sur l'appréciation de l'élément intentionnel des conditions de la révélation, même si la correction du site n'a pas été établie en temps réel.
| Annonce |
