La police allemande a mis fin aux activités du black market Hydra, un site de commerce illégal accessible par l'intermédiaire du réseau Tor et d'adresses en .onion.

Le black market Hydra était l'endroit idéal pour acheter de faux papiers, de la drogue, des produits illicites en tout genre, ou encore des données issues de piratages. Des personnes du monde entier utilisaient ce site, et il comptait tout de même 17 millions d'inscrits dans sa base, ainsi que plusieurs dizaines de milliers de vendeurs.

Accessible via le réseau Tor par l'intermédiaire d'adresses en .onion (propre à ce réseau), Hydra est un black market, et il n'a bien sûr rien à voir avec le célèbre site Back Market où l'on peut retrouver des produits high-tech reconditionnés. ;-). Aujourd'hui, le site ne répond plus.

Et pour cause, début avril, les autorités allemandes sont parvenues à localiser et saisir les serveurs Hydra, chez un hébergeur qui visiblement n'était pas au courant ou qui fermait les yeux. Grâce aux serveurs obtenus, la police a pu récupérer une belle somme : 453 bitcoins, ce qui correspond environ à 17 millions d'euros.

Concernant les personnes aux manettes de ce site, la police n'est pas parvenue à effectuer d'arrestation pour le moment. Il faut tout de même préciser qu'il y a beaucoup de personnes de Russie, de Biélorussie, etc... sur Hydra, et donc, que c'est un peu tendu on va dire compte tenu de la situation géopolitique actuelle.

D'ailleurs, comme le rapporte le site Zataz, la base de données de ce site est à vendre pour un montant de 6 000 dollars ! Visiblement, c'est un pirate fiable qui vend cette base de données où l'on peut retrouver des adresses e-mail, numéros de téléphone et des informations sur les clients de chaque vendeur. Si cette base de données est réelle, les autorités ont intérêt à mettre la main dessus, car c'est une mine d'informations très intéressante... À suivre.

The post Le black market Hydra fermé par les autorités allemandes ! first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons voir comment une simple commande PowerShell peut nous permettre d'obtenir l'état d'une VM Azure, afin de savoir si elle est en cours d'exécution, arrêtée, voire même arrêtée et libérée.

Pour obtenir l'état de la machine virtuelle, il faut interagir directement avec le tenant et la souscription Azure où se situe vos ressources Cloud.

II. Utilisation de Get-AzVM

A. Comment utiliser Get-AzVM ?

La commande Get-AzVM doit être utilisée pour obtenir l'état d'une machine virtuelle Azure en ligne de commande, à l'aide de PowerShell. Cette commande est accessible directement à partir d'Azure Cloud Shell (avec un navigateur sur le portail Azure, voire même depuis Windows Terminal), d'une console PowerShell ou de votre éditeur de code préféré.

Pour une utilisation en local, via une console Windows PowerShell par exemple, il faudra au préalable installer le module "Az.Compute" de PowerShell dont fait partie cette commande.

Install-Module -Name Az.Compute

Ensuite, il faut établir une connexion au tenant Azure et s'authentifier afin d'avoir accès aux différentes ressources. Plusieurs façons de faire, la plus simple étant de saisir les identifiants dans un navigateur :

Connect-AzAccount

Si vous souhaitez plus d'informations sur les différentes méthodes de connexion, vous pouvez lire ce tutoriel :

• Se connecter à Azure avec PowerShell et Connect-AzAccount

B. Récupérer le statut d'une VM avec Get-AzVM

Donc, une fois que la connexion est établie, on peut requêter notre tenant pour obtenir l'état de la machine virtuelle avec Get-AzVM. Nous pouvons essayer de récupérer l'état de la VM nommée "SRV-WSUS" présente sur mon tenant Azure. Pour obtenir l'information, il suffit de spécifier le nom de la VM et d'ajouter le paramètre -Status.

Get-AzVM -Name "SRV-WSUS" -Status

Ici, la commande retourne une colonne nommée "PowerState" avec la valeur "VM running". Nous pouvons en déduire que la VM est en cours d'exécution.

La valeur pourrait être différente :

• VM deallocated : signifie que la VM est arrêtée et libérée
• VM stopped : signifie que la VM est arrêtée (et non libérée)

Si l'on ne précise pas le nom d'une machine virtuelle, on peut obtenir le statut de toutes les VM :

Get-AzVM -Status

Il est également possible de filtrer par région Azure (ou par groupe de ressources), sans oublier à chaque fois le paramètre -Status afin d'avoir la colonne "PowerState" :

Get-AzVM -Location francecentral -Status

Je vais terminer cet article par un dernier exemple : comment obtenir la liste de toutes les VM Azure éteintes ? Tout simplement, en ajoutant un filtre sur la propriété PowerState, comme ceci :

Get-AzVM -Status | Where{ $_.PowerState -eq "VM Stopped" }

Bien sûr, vous pouvez modifier la valeur du filtre pour obtenir la liste des machines virtuelles arrêtées et libérées, par exemple. Vous n'oublierez pas de déconnecter la session Azure après avoir joué avec PowerShell :

Disconnect-AzAccount

Pour plus d'informations sur la commande Get-AzVM :

• Microsoft Docs - Get-AzVM

The post Comment obtenir l’état d’une VM Azure avec PowerShell ? first appeared on IT-Connect.

Le CERT-FR a publié un bulletin d'alerte pour une faille de sécurité qui touche l'implémentation du protocole RPC dans Windows et qui permet une exécution de code à distance. Faisons le point.

Cette semaine, Microsoft a mis en ligne son nouveau Patch Tuesday (avril 2022), avec à la clé 119 vulnérabilités corrigées, à laquelle s'ajoutent 2 zero-day et 26 vulnérabilités dans le navigateur Microsoft Edge. Jusque-là un grand classique, sauf que, comme à chaque fois on peut s'attendre à ce qu'une ou plusieurs failles de sécurité sortent du lot à cause d'un niveau de menace plus élevé.

Cette fois-ci, c'est la vulnérabilité CVE-2022-26809 (que j'ai moi-même mise en avant dans mon article) qui fait l'objet d'un bulletin d'alerte au niveau du CERT-FR.

Sachez que cette faille de sécurité touche l'ensemble des versions de Windows (desktop) et Windows Server, c'est-à-dire :

• De Windows 7 à Windows 11, en passant par Windows 10
• De Windows Server 2008 à Windows Server 2022, y compris pour les installations en mode "Core"

Le CERT-FR recommande d'appliquer le correctif de sécurité dès que possible, et de son côté, Microsoft lui a attribué un score CVSS 3.1 de 9,8 sur 10. En fait, dans le descriptif de Microsoft, on peut lire que c'est une vulnérabilité facile à exploiter, et qui ne nécessite pas de privilèges, ni d'interaction d'un utilisateur, car elle peut être exploitée à distance via le réseau.

Quant aux mesures de protection, le CERT-FR rappelle qu'il est indispensable de respecter les règles suivantes (de manière générale et pas spécialement pour cette vulnérabilité) :

• Interdire tout flux SMB sur les ports TCP/139 et TCP/445 en entrée et en sortie du Système d'Information ;
• Pour le cloisonnement interne : n'autoriser les flux SMB que lorsque cela est nécessaire (contrôleurs de domaine, serveurs de fichiers, etc.) et bloquer ce flux entre postes de travail ;
• Pour les postes nomades : interdire tous les flux SMB entrant et sortant et n'autoriser ces flux vers des serveurs SMB qu'au travers d'un VPN sécurisé

Le bulletin d'alerte est disponible à cette adresse : CVE-2022-26809.

The post Le CERT-FR publie une alerte pour une vulnérabilité dans Windows RPC first appeared on IT-Connect.

Il y a du nouveau dans Microsoft Teams puisque la solution de collaboration de Microsoft intègre un nouveau type de canal : le canal partagé. Il vient s'ajouter aux deux autres types de canaux existants : standard et privé.

Lorsque l'on crée une équipe dans Microsoft Teams, on peut créer des canaux à l'intérieur pour l'organiser. Par défaut, ces canaux sont de type "standard", c'est-à-dire qu'ils sont accessibles à tous les membres de l'équipe. En complément, on peut créer des canaux privés, qui sont accessibles à certains membres de l'équipe Teams uniquement. Désormais, il y a une nouvelle possibilité : les canaux partagés !

En bref, un canal partagé va être créé dans une équipe, au même titre que les autres canaux, à la différence qu'il peut-être accessible par des utilisateurs qui ne sont pas membres de l'équipe ! C'est particulièrement intéressant (et surement attendu par les utilisateurs) afin d'ouvrir l'accès à un canal à une personne, sans pour autant lui donner la possibilité d'accéder à tous les canaux standards (publics) de l'équipe Teams. Autrement dit, une personne peut accéder à un canal partagé d'une équipe sans pour autant avoir de visibilité sur le canal "Général" de cette même équipe.

Une personne de votre organisation peut-être ajoutée dans un canal partagé, mais également une personne en dehors de votre organisation, à condition que la politique de sécurité de Teams l'autorise (pour cela, rendez-vous dans le Centre d'administration Teams d'Office 365). En complément, il faut savoir que toutes les personnes membres de l'équipe auront un accès aux canaux partagés créés dans cette même équipe, contrairement aux canaux privés.

Cette nouveauté va rendre bien des services, mais il faut espérer qu'elle n'apporte pas trop de confusion dans la tête de certains utilisateurs. Quoi qu'il en soit, Microsoft Teams gère les canaux standards (publics), privés et partagés.

Plus d'informations sur le site de Microsoft : Microsoft Docs - Les canaux privés de Teams.

The post Nouveauté Microsoft Teams : le canal partagé ! first appeared on IT-Connect.

Toujours sur le sujet des mises à jour, Microsoft annonce que Windows Server supporte désormais les mises à jour automatiques de .NET Framework et .NET Core !

Cette fonctionnalité est liée à la mise en ligne de nouvelles versions des branches de .NET suivantes : .NET Core 3.1, .NET 5.0, et .NET 6.0. Microsoft, par la voix de Jamshed Damkewala, précise : "Nous sommes heureux d'annoncer qu'à partir d'avril 2022, les mises à jour mensuelles de la version moderne de .NET (.NET Core) seront disponibles pour les systèmes d'exploitation Windows Server via Microsoft Update (MU), sur la base d'une option de participation.".

En fait, il faut comprendre que l'activation des mises à jour automatique de .NET ne sera pas systématique, et que c'est aux administrateurs de choisir. Donc, cela ne change rien pour ceux qui ne souhaitent pas bénéficier des mises à jour automatiques. En fonction de l'environnement et des outils utilisés, l'approche peut être différente donc c'est probablement mieux ainsi.

Si vous souhaitez activer les mises à jour automatiques de .NET sur un serveur où l'installation est déjà effectuée, il va falloir ajuster la configuration de la machine. Comme l'explique Microsoft sur son site, il faut mettre à jour le Registre Windows de cette façon (en fonction de la version) :

.NET Version	Clé de Registre	Nom	Valeur
ALL	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET]	"AllowAUOnServerOS"	dword:00000001
.NET 6.0	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0]	"AllowAUOnServerOS"	dword:00000001
.NET 5.0	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\5.0]	"AllowAUOnServerOS"	dword:00000001
.NET 3.1	[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\3.1]	"AllowAUOnServerOS"	dword:00000001

S'il y a plusieurs serveurs à paramétrer, il conviendra d'utiliser une stratégie de groupe pour déployer la valeur de Registre à distance sur un ensemble de serveurs. Les mises à jour automatiques vont être disponibles directement dans WSUS pour les entreprises qui s'appuient sur ce service de distribution des mises à jour.

Pour conclure cet article, je vous rappelle que Microsoft a mis en ligne un Patch Tuesday d'avril 2022 relativement fourni avec 119 vulnérabilités corrigées et 2 zero-day : Patch Tuesday - Avril 2022. Dans le même temps, les mises à jour pour Windows 10 et Windows 11 ont également vu le jour :

- Windows 11 (KB5012592)

- Windows 10 (KB5012599 et KB5012591)

Source

The post Windows Server supporte les mises à jour automatiques de .NET ! first appeared on IT-Connect.