PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Microsoft Exchange : attention, la faille CVE-2021-28482 dispose d’un exploit

mardi 4 mai 2021 à 08:09

Au sein de son Patch Tuesday d'Avril 2021, Microsoft avait corrigé quatre vulnérabilités Exchange découvertes par la NSA. Il s'avère que l'une d'entre elle dispose désormais de sa propre documentation technique et d'un PoC pour l'exploiter.

Un exploit est disponible sur GitHub pour montrer que la faille référencée sous le nom CVE-2021-28482 est réelle et exploitable. Il s'agit de la faille la moins grave parmi les 4 vulnérabilités découvertes par la NSA car elle nécessite une authentification, mais il ne faut pas la négliger pour autant.

Le chercheur en sécurité Nguyen Jang a publié un PoC écrit en Python sur son GitHub, dans le but de montrer qu'il est possible d'exploiter la faille CVE-2021-28482. Un code validé par Will Dormann, un analyste en vulnérabilité pour le CERT/CC aux États-Unis. Concrètement, un attaquant peut exploiter cette faille en étant authentifié sur un serveur Exchange où les mises à jour d'avril ne sont pas installées.

Exchange CVE-2021-28482

En soi, la faille CVE-2021-28482 n'est pas aussi critique que les vulnérabilités ProxyLogon car elle ne permet pas d'effectuer une attaque massive puisqu'il faut s'authentifier sur le serveur de messagerie. Néanmoins, elle peut tout à fait être exploitée dans le cas d'une attaque ciblée : il suffit à l'attaquant de récupérer le compte d'un utilisateur standard pour passer cette barrière liée à l'authentification.

Rappelons également que Nguyen Jang est déjà à l'origine d'un PoC permettant d'exploiter les failles ProxyLogon.

Cette fois encore, il est indispensable de mettre à jour rapidement vos serveurs Exchange. Les correctifs contre la faille ProxyLogon d'une part, mais aussi les correctifs du Patch Tuesday d'Avril 2021 pour corriger les quatre failles Exchange révélées par la NSA. Il est vrai que depuis quelques mois, il est devenu fréquent que des failles critiques soient révélées au sein de Microsoft Exchange et cela pousse les entreprises à adopter un rythme élevé pour les mises à jour.

Source

The post Microsoft Exchange : attention, la faille CVE-2021-28482 dispose d’un exploit first appeared on IT-Connect.

Une faille similaire à Spectre découverte : nos CPUs vont encore souffrir !

lundi 3 mai 2021 à 13:52

Mauvaise nouvelle pour commencer la semaine : il s'avère qu'une faille de sécurité similaire à Spectre vient d'être découverte au sein des processeurs Intel et AMD. Une grande partie des ordinateurs à l'échelle mondiale sont vulnérables.

Trois ans après la découverte de Spectre, l'histoire semble se répéter. Des chercheurs en sécurité de l'Université de Virginie et de l'Université de Californie ont découvert une faille de sécurité qui touche les processeurs Intel et AMD. Pour exploiter cette vulnérabilité, il faut s'appuyer sur le cache micro-op implémenté dans une grande partie des processeurs des dix dernières années. En effet, AMD intègre cette instruction depuis 2017 tandis qu'Intel le fait depuis 2011. Concrètement, on parle de quelques milliards de machines...

De nos jours, il est difficile de se passer de ce cache micro-op dans nos processeurs, car il améliore grandement les performances des processeurs. Il sert notamment à mettre en mémoire des instructions simples dans le but de permettre aux processeurs d'être plus efficace et rapide dans l'exécution des tâches concernées.

Il serait préjudiciable de reproduire la situation du passé : les correctifs déployés par les fabricants pour contrer la vulnérabilité Spectre et les attaques associées avaient eu un impact non négligeable sur les performances des CPUs. Bien sûr, un impact négatif avec une perte de performances.

Dans le cas présent, d'après les chercheurs, ce ne sera pas simple de corriger la faille de sécurité. Ce serait même plus difficile qu'avec Spectre. Le chercheur Xida Ren, précise que si un correctif désactive le cache micro-op ou stoppe l'exécution spéculative, cela reviendrait à retirer des innovations importantes dans la plupart des processeurs modernes d'Intel et d'AMD. L'impact sur les performances serait alors très important ! Il faut se rendre à l'évidence : ce n'est tout simplement pas faisable.

Ils précisent également que la faille est difficile à exploiter, mais cela ne veut pas dire qu'il ne faut pas s'en protéger. Certains secteurs y seront plus sensibles que d'autres 😉.

Source

The post Une faille similaire à Spectre découverte : nos CPUs vont encore souffrir ! first appeared on IT-Connect.

Git : Comment résoudre l’erreur « fatal : pathspec is in submodule »

lundi 3 mai 2021 à 13:00

I. Présentation

J’ai récemment réorganisé mes repository Git afin de me faciliter la vie. Plutôt que d’avoir un repository unique PowerShell, un autre Bash, un autre Python, etc, j’ai décidé de me créer un unique repository « Scripts », avec un sous-dossier par langage de scripting : Bash, Python, PowerShell.

J’étais confiant, j’y suis allé à vrai dire un peu vite, et ce qui devait arriver arriva : bim ! Une erreur ! Fatale en plus !

fatal: Pathspec '.\PowerShell\*' is in submodule 'PowerShell'

fatal: Pathspec '.\PowerShell\*' is in submodule 'PowerShell'

Restez avec moi si vous voulez savoir pourquoi cette erreur s’est affichée, et comment la corriger.

II. Prérequis

 

III. Explications de l’erreur fatale : Pathspec is in submodule

Jusqu’à aujourd’hui, j’avais 3 dossiers, répartis dans 3 repository Git distincts, pour stocker & gérer mes scripts :

J’ai décidé de réunir ces 3 dossiers dans un nouveau repository Git, nommé « Scripts ».

Logiquement, et naïvement, j’ai donc créé un nouveau répertoire « Scripts » sur mon PC, et j’ai copié le contenu des 3 autres dedans, pour me retrouver dans la configuration suivante :

Que du classique lorsqu’on prépare un nouveau répertoire Git.

Me restait donc à initialiser le suivi du répertoire via Git :

cd E:\Repos\Scripts

git init

Une fois fait, il faut encore dire à Git quels sont les fichiers sur lesquels tracker les modifications. Ça s’effectue via la commande :

git add .

NOTE : Le . agit comme un ./* Il indique à Git de tracker tous les fichiers & sous-répertoires présents dans le répertoire de travail actuel.

 

Et c’est à ce moment-là que ça a commencé à coincer.

Mon dossier PowerShell était déjà tracké par Git, dans un autre repository, et il possédait toujours un dossier .git, avec la configuration associée.

Comme vous pouvez le voir sur la capture d'écran ci-dessous, les messages de git sont en général assez parlant. Dans notre cas, la solution nous est donnée. Enfin presque. Je vous dit tout dans un instant.

À ce stade, si vous vous entêtez, lors de votre premier commit, votre dossier « PowerShell » sera purement et simplement ignoré par Git.

Pourtant, le commit se passe bien, sans erreur.

 

Sauf que voilà : j’ai beau effectuer des modifications dans mon dossier PowerShell, git est censé les détecter, et m’afficher les changements lorsque j’utilise les commandes suivantes :

git diff

git status

Or, dans mon cas, Git me retourne un message m'indiquant qu'il n'y a eu aucun changement, et qu'il n'y a donc aucun intérêt à réaliser un commit : "nothing to commit, working tree clean".

nothing to commit, working tree clean

Et côté repository distant, sur Gitlab, je me retrouve avec un dossier PowerShell inaccessible alors que je devrais pouvoir le parcourir et avoir accès à tous mes scripts.

Vraiment, la loose !

Il y a une manière très simple de vérifier si vous avez bien la même erreur que moi. Essayez de rajouter le dossier ou le fichier dans les éléments trackés par Git :

git add ./PowerShell/*

Vous devriez alors obtenir l'erreur "fatal: Pathspec is in submodule".

fatal: Pathspec is in submodule

 

Et voilà : l’explication, c’est que mon dossier PowerShell contenait une configuration git existante. Donc lorsque j’ai initialisé git pour mon nouveau dossier Scripts, le dossier PowerShell, qui était déjà tracké, s’est automatiquement configuré en sous-module. Git considère alors que ce dossier PowerShell étant déjà suivi et ayant déjà des commit, il n'a aucun intérêt à le suivre une seconde fois, d'où le message d'erreur, et d'où le fait que mes modifications ne sont absolument pas détectées lorsque je fais un commit git.

IV. Comment corriger cette erreur ?

Maintenant, comment corriger cette erreur ? C’est très simple et ça ne vous prendra pas plus de 30 secondes.

Pour commencer, supprimez le dossier .git de votre dossier « PowerShell » s’il est encore présent.

Ensuite, vous allez faire oublier à Git le tracking de votre dossier en mode « submodule », en forçant git à supprimer son cache :

git rm --cached <nom-du-dossier>

 

NOTE : Si git est récalcitrant, vous pouvez utiliser le paramètre -f pour le forcer à supprimer son cache.

git rm --cached <nom-du-dossier> -f

 

Vous pouvez alors à nouveau ajouter le tracking git de votre dossier, et vérifier que les fichiers sont cette fois bien reconnus :

git add ./PowerShell/*

git status

Cette fois, on peut bien voir les modifications que j'ai apportées au contenu du dossier PowerShell : en vert les fichiers ajoutés (du point de vue de Git, par rapport au dernier commit).

Il ne vous reste plus qu’à faire votre git push pour envoyer vos données sur votre repository distant, et le tour est joué. ?

V. Conclusion

La prochaine fois que vous voudrez réorganiser vos repository Git, n’oubliez pas de vérifier la configuration Git du repository en question, afin d’éviter de créer par inadvertance des sous-modules là où il n’y en a pas besoin.

Pensez également à bien vérifier que tous les dossiers et fichiers qui vous intéressent sont bien intégrés à la liste des éléments trackés par Git, via la commande :

git status

Et si votre commit coince, votre premier réflexe est d’aller voir l’état de votre repository sur votre serveur distant, et également de regarder la configuration de votre repository Git local dans votre dossier .git.

The post Git : Comment résoudre l’erreur « fatal : pathspec is in submodule » first appeared on IT-Connect.

Microsoft PowerToys v0.37.0 nécessite au minimum Windows 10 v1903

lundi 3 mai 2021 à 08:36

Microsoft a publié la version 0.37.0 de PowerToys avec quelques légères améliorations et surtout un changement important au niveau des prérequis : il faut utiliser au minimum Windows 10 version 1903 pour en profiter.

Introduits dans Windows 95 par Microsoft, puis retirés après Windows XP, les PowerToys ont fait leur retour sur Windows 10. Derrière les PowerToys, se cachent des petits outils développés par Microsoft pour améliorer l'utilisation du système d'exploitation, comme FancyZones pour personnaliser l'organisation des fenêtres.

À ce jour, PowerToys intègre plusieurs outils, parmi lesquels : Color Picker, FancyZones, Image Resizer, Keyboard Manager, ou encore PowerRename.

Clint Rutkas, responsable de PowerToys, a publié le message suivant sur Twitter : "Hello #PowerToys 0.37.0. Big efforts are keyboard manager is now an independent exe, small new PowerRename feature, bug fixes. We did increase min version of Win10 to 1903 until we can adopt WinUI 3".

Concrètement, la version 0.37.0 apporte des changements au sein de deux PowerToys : Keyboard Manager et PowerRename. L'outil Keyboard Manager s'exécute désormais dans un exécutable indépendant (processus indépendant), tandis que d'autres correctifs mineurs sont inclus pour les autres PowerToys. Le changelog sur Github pourra vous donner plus de précision.

➡ Github - PowerToys

Si Microsoft a modifié la version majeure de Windows 10 nécessaire pour faire tourner PowerToys, c'est pour une raison simple : la firme de Redmond souhaite que PowerToys s'appuie sur la nouvelle librairie Windows UI 3 (WINUI 3). Ce que l'on retiendra de cette nouvelle version de PowerToys, c'est qu'il faut au minimum Windows 10 v1903 pour en profiter.

Utilisez-vous les PowerToys ?

Source

The post Microsoft PowerToys v0.37.0 nécessite au minimum Windows 10 v1903 first appeared on IT-Connect.

Guide ANSSI : focus sur les mécanismes de sécurité des navigateurs

lundi 3 mai 2021 à 07:59

L'ANSSI a publié le 28 Avril 2021 un nouveau guide portant sur la sécurité des sites web, intitulé Recommandations pour la mise en œuvre d'un site web: maîtriser les standards de sécurité côté navigateur.

Les recommandations de ce guide concernent la sécurité des contenus présentés par un navigateur web aux utilisateurs. Il existe de nombreux standards du Web qui concernent des mécanismes de sécurité activables par les serveurs web au niveau des navigateurs. En intégrant différents en-têtes (headers) au niveau de leur réponse, les serveurs vont en effet pouvoir demander aux navigateurs de leurs utilisateurs d'activer des mécanismes de protection divers afin de rendre la navigation plus sûre. En faisant le tour de ces différents mécanismes, un développeur ou un administrateur système peut donc protéger ses utilisateurs de certaines attaques, autrement qu'en intervenant directement sur le code source de l'application utilisée.

Il faut tout de même garder en tête que ces mécanismes de sécurité côté navigateur sont là pour limiter l'impact ou les possibilités d'exploitation d'une vulnérabilité, mais constituent rarement un correctif efficace à eux seuls. Ils doivent donc venir renforcer la sécurité d'une application web en utilisant tous les outils possibles au niveau du navigateur de l'utilisateur, et non se substituer à la sécurité de l'application web elle-même.

Dans ce guide est notamment rappelée la contrainte de Same Origin Policy (SOP) et son mécanisme de relâchement Cross Origin Resource Sharing (CORS). Le guide aborde ensuite certaines pratiques de protection contre le Cross Site Scripting (XSS) telles que SubResource Integrity (SRI), puis la communication inter-contextes en général, en détaillant notamment les standards Content Security Policy (CSP), Referrer-Policy, et les pratiques relatives au cloisonnement telles que le choix et le paramétrage des moyens de stockage côté client (ex. : cookies, Web Storage) et des moyens d’isolation des ressources actives (ex. : iframes, Web Workers).

Nous avons d'ailleurs publié très récemment sur IT-Connect un article sur le mécanisme du SRI : Contrôle d’intégrité des ressources web externes, mentionné dans ce guide.

Un dehors des mesures purement techniques, le chapitre 2. Menaces et types d'attaques est intéressant pour les gestionnaires de site web qui souhaitent mieux comprendre l'intérêt de s'occuper de la sécurité de leurs applications. Différents exemples de menaces et objectifs des attaquants y sont donnés (par exemple le vol de données ou l'interruption de service) ainsi que des exemples d'attaques concrètes (XSS, CSRF, SQLi, etc.), utiles pour mieux comprendre la suite du guide. Le chapitre 3. Rappel des règles d'hygiène  fait lui un rapide survol des principes de sécurité qui doivent être intégrés au niveau de l'application web elle-même.

Ce guide contient 63 recommandations qui couvrent un ensemble assez large de mesures, y sont également fournis des exemples de code HTML ou JavaScript permettant de mieux comprendre la mise en place de certaines mesures.

En complément de ce guide, je vous conseille d'étudier l'OWASP Testing Guide, qui vient lui détailler les bonnes pratiques de développement et d'audit d'une application web : OWASP Web Security Testing Guide

Si vous souhaitez consulter ce nouveau guide de l'ANSSI, c'est part ici : Recommandations pour la mise en œuvre d'un site web: maîtriser les standards de sécurité côté navigateur

Bonne lecture 🙂

The post Guide ANSSI : focus sur les mécanismes de sécurité des navigateurs first appeared on IT-Connect.