I. Présentation

J'ai l'habitude de coder des scripts avec PowerShell ISE notamment quand je me trouve directement sur un serveur puisqu'il est intégré directement à Windows Server. Ceux qui connaissent cet éditeur de code savent qu'il est contraignant dans sa façon de gérer les variables et clairement, ça peut être gênant pour du debug.

En effet, lorsqu'un script est exécuté, PowerShell ISE va garder en mémoire les variables et leurs valeurs d'une exécution à l'autre. Autrement dit, une exécution du script peut, potentiellement, impacter la prochaine : de quoi ajouter une complexité supplémentaire lorsqu'il s'agit de faire un troubleshooting...

La solution : fermer PowerShell ISE et le rouvrir. Mouais, c'est un peu pénible car il faut rouvrir le script, voire mêmes les scripts... Pas très pratique. Il y a une autre solution : supprimer toutes les variables de la session PowerShell ISE en cours à l'aide d'une commande. Voyons ça ensemble...

II. Supprimer les variables dans PowerShell ISE

Au sein de la console de PowerShell ISE, nous allons exécuter la commande suivante :

Remove-Variable * -ErrorAction SilentlyContinue

Elle va tout simplement supprimer toutes les variables, et donc par extension, les valeurs associées. Manipulation simple mais radicale.

En fait, il y a deux autres choses que l'on peut purger au sein de la session PowerShell ISE : les erreurs et les modules chargés. Voyons comment faire également.

III. Purger les erreurs et les modules chargés dans PowerShell ISE

Pour aller plus loin supprimer également les modules chargés dans la session PowerShell ISE, nous pouvons exécuter la commande suivante :

Remove-Module * -ErrorAction SilentlyContinue

Enfin, pour se débarrasser de l'historique des erreurs de la session en cours, nous allons exécuter cette commande :

$error.Clear()

En résumé, vous pouvez repartir à blanc en exécutant les trois commandes suivantes sans fermer l'éditeur de code :

Remove-Variable * -ErrorAction SilentlyContinue
Remove-Module * -ErrorAction SilentlyContinue
$error.Clear()

Bon, maintenant il faut continuer le troubleshooting...

The post PowerShell ISE : purger les variables sans redémarrer first appeared on IT-Connect.

Il y a deux ans, Microsoft avait immergé un datacenter sous-marin à 35 mètres de profondeur au nord l'Ecosse avec 864 serveurs à l'intérieur dans le cadre du projet Natick. Le géant américain l'a remonté à la surface dans le but d'observer l'effet de l'environnement marin sur son datacenter.

Microsoft cherchait un moyen d'avoir un datacenter plus écoénergétique et plutôt que de refroidir les centres de données à partir de l'eau de mer, Microsoft a décidé en 2018 d'aller plus loin en plaçant directement des serveurs au fond de l'eau. Pour ce premier essai, l'entreprise avait intégrée à la capsule sous-marine 864 serveurs, pour un volume de données équivalent à 27,6 pétaoctets. Il y avait également un deuxième objectif : prouver que c'est plus fiable car sous l'eau les serveurs ne devraient pas souffrir de la corrosion liée à l'air ambiant, aux variations de températures et à l'humidité. En effet, sous l'eau, les conditions climatiques sont beaucoup plus stables.

Après avoir remonté son datacenter sous-marin, les premières impressions des ingénieurs de Microsoft sont bonnes : la coque extérieure est restée en très bon état après deux ans d'immersion. Pour rappel, c'est la société Naval Group qui a assemblée ce prototype à Brest.

D'un point de vue de la stabilité, le datacenter sous-marin a un taux de défaillance beaucoup plus intéressant qu'un datacenter terrestre. Concrètement, pour 8 serveurs défaillants au sein d'un datacenter terrestre, il y en a 1 défaillant au sein du datacenter sous-marin. D'un autre côté, il faut avouer que cette fiabilité est essentielle car les interventions au sein de la capsule sont très compliquées une fois qu'elle est plongée à 35 mètres de profondeur.

Puisque ce premier essai est encourageant et qu'il y a un réel gain en terme de fiabilité, la firme de Redmond veut aller plus loin avec son projet Natick. Il est envisagé de placer des datacenters sous-marins près des villes côtières dans le but d'améliorer les temps d'accès aux applications Cloud et aux données associées. Bien que ça fonctionne en Mer du Nord, ce n'est pas dit que ça fonctionne partout dans le monde mais j'imagine que Microsoft réalisera d'autres essais par la suite.

📌 Plus d'infos et de photos

The post Microsoft : son datacenter sous l'eau est une réussite ! first appeared on IT-Connect.

La faille CVE-2020-1472 surnommée Zerologon et patchée en août 2020 par Microsoft représente un vrai danger sur les serveurs contrôleurs de domaine qui ne bénéficient pas de ce correctif.

A l'intérieur du Patch Tuesday du mois d'août 2020, la correction de cette vulnérabilité est presque passée inaperçue au milieu de la centaine de failles corrigées malgré un score de criticité de 10 sur 10. La faille Zerologon s'avère très dangereuse : un attaquant qui parviendrait à l'exploiter pourrait prendre le contrôle de votre domaine Windows par l'intermédiaire du protocole Netlogon Remote Protocol (MS-NRPC) qui se présente sous la forme d'une interface RPC.

Le CERT-FR a d'ailleurs publié une note au sujet de cette faille où l'on apprend que toutes les versions de Windows Server sont touchées, de Windows Server 2008 R2 à Windows Server version 2004. Que ce soit sur une installation en mode graphique ou en tant que Server Core. Il est précisé ce qui suit sur la note du CERT-FR : "Cette vulnérabilité [...] concerne les différentes versions de Microsoft Windows Server où le rôle ADDS (Active Directory Domain Services) est installé et où le serveur joue le rôle de contrôleur de domaine. Cette vulnérabilité peut aisément être exploitée par un acteur mal intentionné ayant un accès aux ports TCP ouverts par le service Netlogon."

La société Secura de son côté indique que, grâce à la création d'un jeton d'authentification Netlogon spécifique, l'attaquant peut faire appel à une fonction qui va lui permettre de définir le mot de passe de l'objet ordinateur correspondant au contrôleur de domaine. Une fois l'opération réussie, l'attaquant peut alors prendre le contrôle sur le contrôleur de domaine et en profiter pour devenir Administrateur du domaine.

Cette faille est d'autant plus dangereuse que des codes d'exploitation sont disponibles sur Internet.

Vous pouvez dès à présent patcher vos contrôleurs de domaine en installant la mise à jour de sécurité correspondante à la version de votre système d'exploitation. Toutes les informations sont disponibles sur le site de Microsoft.

- Windows Server 2012 R2 : KB4571723 ou Monthly rollup (KB4571703)
- Windows Server 2016 : KB4571694
- Windows Server 2019 : KB4565349

En complément, pour ceux qui souhaitent, Secura met à disposition un script qui s'appuie sur Python afin de vérifier si votre contrôleur de domaine est vulnérable.

Quelques liens :

➡ CERT-FR

➡ Liste des KB Microsoft

➡ Livre Blanc Secura sur la faille Zerologon

The post Zerologon : la faille critique qui touche l'Active Directory first appeared on IT-Connect.

I. Présentation

Le navigateur de Google, à savoir Chrome, est le navigateur le plus utilisé au monde. Il est également utilisé en entreprise sur les postes clients et Google met notamment à disposition des administrateurs des fichiers ADMX Chrome pour les GPO.

Afin de définir Chrome comme navigateur par défaut sur vos postes clients, ou un serveur RDS, par exemple, il faut également procéder par GPO. Pour réaliser cette action, il est nécessaire de passer un fichier XML qui va permettre d'associer les extensions à un programme.

D'ailleurs, ce fichier XML généré à partir de DISM peut être utilisé pour effectuer des associations "extensions - programmes" pour toutes les extensions, ce qui permet d'associer les fichiers .docx à Word, par exemple. Nous avons déjà abordé ce sujet dans un précédent tutoriel (toujours valide à ce jour) : Association des extensions de fichiers par GPO

Tutoriel disponible au format vidéo :

II. Le fichier XML

Dans le cas où l'on veut seulement définir un navigateur par défaut sur les postes, on peut facilement constituer soi-même le fichier XML, d'autant plus que Google fournit le bout de code associé sur son site. La logique est assez simple, on indique l'extension et le programme que l'on veut associer.

Vous pouvez tout à fait compléter un fichier XML existant si vous en avez déjà un et que vous souhaitez ajouter la configuration du navigateur. Dans ce cas, il suffit d'ajouter à votre fichier les 4 lignes qui commencent par "Association Identifier". Dans notre cas, nous allons associer Google Chrome aux extensions suivantes : HTM / HTML / HTTP / HTTPS.

Si vous partez de zéro, créez un nouveau fichier .XML et ajoutez le contenu suivant :

<?xml version="1.0" encoding="UTF-8"?>
<DefaultAssociations>
<Association Identifier=".htm" ProgId="ChromeHTML" ApplicationName="Google Chrome" />
<Association Identifier=".html" ProgId="ChromeHTML" ApplicationName="Google Chrome" />
<Association Identifier="http" ProgId="ChromeHTML" ApplicationName="Google Chrome" />
<Association Identifier="https" ProgId="ChromeHTML" ApplicationName="Google Chrome" />
</DefaultAssociations>

Ce fichier doit être publié sur le réseau, au sein d'un partage ou directement dans les fichiers de votre GPO, ou éventuellement copié sur l'ensemble de vos postes. En effet, il doit être accessible en lecture pour que les PCs soient en mesure de récupérer les informations qu'il contient.

III. La GPO pour définir le navigateur par  défaut

Dans une nouvelle GPO (ou existante) qui s'applique sur vos postes ciblés, vous devez parcourir l'arborescence de cette façon :

📌 Configuration ordinateur > Stratégies > Modèles d'administration > Composants Windows > Explorateurs de fichiers

A l'intérieur, vous devez configurer le paramètre suivant :

📌 Définir un fichier de configuration des associations par défaut

Il est nécessaire de l'activer bien entendu, mais également d'ajouter le chemin vers le fichier .XML dans le champ "Fichier de configuration des associations par défaut". A titre d'exemple, cela pourrait être un chemin réseau sous la forme : \\mon-serveur\partage\chrome.xml

Il ne vous reste plus qu'à valider, à tester et à faire passer le message auprès de vos utilisateurs 😉

Remarque : si vous avez plusieurs navigateurs sur vos machines et qu'un utilisateur préfère définir un autre navigateur par défaut, il ne pourra pas. Puisque le choix est définit par GPO, Chrome sera redéfinit comme navigateur par défaut à chaque fois.

The post GPO : Définir Chrome comme navigateur par défaut first appeared on IT-Connect.

Un groupe de chercheurs en sécurité a dévoilé les détails sur une vulnérabilité dans les communications SSL/TLS qui permettrait à un attaquant de casser le chiffrement et lire des informations sensibles. Baptisée "Raccoon Attack", cette vulnérabilité est exploitable seulement sous certaines conditions.

Cette faille est vieille de plus de 20 ans, car elle réside dans le protocole d'échange de clés Diffie-Hellman (DH) utilisé depuis SSLv3 : disponible depuis 1996. Aujourd'hui, elle concerne également TLS 1.2, mais ne concerne pas TLS 1.3. Grâce à Diffie-Hellman, un secret commun est généré entre le client et le serveur afin de créer des clés de session SSL/TLS qui seront utilisées par les deux parties pour communiquer de façon sécurisée.

Le problème réside au sein de ce secret : parfois il commence par des zéros. Grâce à des mesures temporelles, les chercheurs arrivent à déterminer si le secret commence par un zéro ou non. Si l'on couple cela au fait que l'attaquant intercepte quelques trames lors de l'initialisation Diffie-Hellman, alors l'attaquant a suffisamment d'informations pour calculer le secret commun aux deux parties. S'il dispose du secret commun, il devient possible de déchiffrer les flux.

C'est très difficile d'exploiter cette attaque pour plusieurs raisons : il faut cibler un serveur avec une configuration spécifique puisqu'il doit utiliser Diffie-Hellman et ensuite il faut réaliser des mesures temporelles précises, tout en étant capable d'intercepter les trames entre le client et le serveur. De nos jours, les navigateurs Internet ne supportent plus Diffie-Hellman : Firefox était le dernier à le supporter, mais ce n'est plus le cas depuis juin 2020 et la sortie de Firefox 78.

Au niveau de Windows, Microsoft a également corrigé son OS vis-à-vis de cette faille. Faisant référence à la CVE-2020-1596, il y a différentes KB associées dont la KB4571756 pour Windows 10 v2004. De son côté, le paquet openssl a également résolu le problème depuis la version 1.0.2f en réponse à la faille CVE-2020-1968 tout en précisant que la version 1.1.1 n'est pas concernée par cette faille Raccoon Attack.

📌 portal.msrc.microsoft.com

📌 openssl.org

📌 raccoon-attack.com

The post Raccoon Attack : une faille dans SSL/TLS vieille de 20 ans first appeared on IT-Connect.