“Les admins Windows veulent un accès HTTP en plus de HTTPS pour leur WSUS alors que c’est interdit par l’entreprise”. C’est par cette demande que je me suis replongé dans le monde “windowsien” et la manière dont Microsoft distribue ses mises à jours.

Dans cet article je vous propose de découvrir comment Microsoft distribue ses kb et assure leur intégrité. Ce sera également l’occasion de faire quelques rappels sur le fonctionnement du role Windows Server Update Services (WSUS).

Prêt à démarrer ? c’est parti!

Rappels sur WSUS

Dans les entreprises, il est courant de mettre en place des serveurs de mises à jours WSUS plutôt que de laisser chaque client télécharger directement les mises à jours depuis Microsoft. Il s’agit d’un rôle Windows server ayant pour but de télécharger les mises à jours depuis Windows update et de les mettre à disposition des clients internes de l’entreprise (laptop, serveurs,…).

WSUS apporte de nombreux avantages. Premièrement la mise en cache en un ou plusieurs points, ce qui permet d’économiser de la bande passante internet, notamment pour les sites qui disposent d’une mauvaise connectivité. Ensuite, WSUS permet de contrôler quelles mises à jours peuvent être téléchargées par quel(s) client(s). En créant des groupes, il est possible d’appliquer des politiques de mises à disposition différenciées. Par exemple, pour les serveurs, on peut privilégier une mise à disposition rapide des mises à jours de sécurité critiques, tandis que les moins critiques ou les features updates seront temporisées le temps de faire des tests de non regressions. Enfin, WSUS permet d’avoir un statut des mises à jours installées par les clients qui s’y connecte. C’est particulièrement utile lorsque vous souhaitez par exemple connaitre votre degré d’exposition à une vulnérabilité dont un correctif a été mis à dispostion récemment.

Il est parfaitement possible d’avoir un seul serveur WSUS. Il est également possible de construire une architecture avec plusieurs WSUS qui se synchronisent entre eux selon une hiérarchie établie avec un serveur principal et des serveurs secondaires. Cela permet d’assurer une résilience, et de distribuer les mises à jours au plus prêt des clients. Cela permet également, lorsque les serveurs secondaires sont configurés en mode replica d’assurer une gouvernance centralisée sur la mise à disposition des mises à jours. Le schéma ci-dessous présente un exemple d’architecture:

Comme le montre le schéma, les flux entre les clients et le serveurs WSUS, ainsi que les flux entre WSUS sont configurable en HTTPS only. Pour cela, il suffit de configurer le serveur IIS de WSUS avec un certificat, issue d’une autorité de certification interne par exemple. En revanche, le WSUS qui télécharge les mises à jours depuis Windows Update nécessite à la fois HTTP et HTTPS.

De manière générale, sur le plan sécurité, on préfère avoir recours à HTTPS plutôt qu’HTTP. En effet, bien que l’aspect chiffrement peut pour certains paraitre comme de la “sur-qualité” dans certains contextes, HTTPS apporte également des moyens de contrôler l’authenticité du serveur (et du client en mTLS) et de l’intégrité des données échangées.

Alors pourquoi Microsoft conserve des flux HTTP ?

Distribution des mises à jours par microsoft

Utilisation de contents delivery Networks

Difficile de trouver des chiffres précis et fiables sur le nombre de serveurs et postes clients utilisant Windows. Une chose est sûr, il sont très grand; des dizaines voir des centaines de millions. Microsoft a donc dù optimiser son service de distribution des mises à jours pour éviter les saturations. Ainsi, il s’appuie sur des Content Delivery Network (CDN), dont le but est de mettre en cache du contenu sur des serveurs intermédiaires au plus proche du client. Ces CDN peuvent appartenir à Microsoft ou à des tiers. Dans tous les cas, ces serveurs intermédiaires entre les serveurs d’origines et le client sont en dehors du périmètre de sécurité de la supply chain de Microsoft. Si un individu compromet l’un de ces serveurs intermédiaires, il serait en capacité de remplacer la mise à jour initiale par une contenant du code malveillant. HTPS n’y changerait rien, puisque la terminaison TLS avec le client se situerait au niveau de ces serveurs intermédiaires (et non les serveurs initiaux de microsoft), un téléchargement en HTTPS permettrait uniquement de s’assurer que le fichier présent sur le serveur intermédiaire n’a pas été altéré pendant le transfert vers le client, mais pas entre le serveur intermédiaire et Microsoft. De plus, les certificats utilisées appartiendraient aux CDN. Dès lors, Microsoft ne peut s’appuyer dessus pour faire son contrôle d’intégrité.

Microsoft a donc décidé de rester en HTTP. Mais alors, comment l’intégrité des mises à jours téléchargées est elle assurée ?

Métadonnées et contrôle d’intégrité à la destination

En réalité, une mise à jour, ou “Kb” n’est pas constitué uniquement d’un binaire. Chacune dispose de métadonnées dans lesquelles se trouve un hash du binaire, signé par Microsoft. Ces métadonnées, bien moins volumineuse que le binaire, sont téléchargées séparéments, en HTTPS, sans passer par les CDN (i.e. directement depuis les serveurs de microsoft). Ainsi le téléchargement directe en HTTPS, en utilisant des certificats de confiance pour Microsoft (puisqu’ils lui appartiennent) permet d’assurer l’intégrité des métadonnées (et de la signature qu’elles contiennent).

Après avoir récupéré le binaire et les métadonnées, le client réalise avant l’installation une vérification de l’intégrité. Pour cela il calcule le hash du binaire téléchargé et le compare à celui des métadonnées. Si le binaire a été altéré sur un serveur intermédiaire, le hash sera différent et le binaire sera rejeté.

Une petite expérience simple pour montrer que les binaires et les métaonnées sont téléchargés par des canaux distincts.Déployer une vm en ne lui autorisant que HTTPS. Vous verrez que le client windows update sera capable de récupérer la liste des Kb, mais sera incapable de les télécharger.

Un dernier mot concernant WSUS

Microsoft a annoncé en septembre 2024 la dépréciation de WSUS. Si le produit reste maintenu pour le moment, aucune nouvelle fonctionnalité ne sera produite. Les solutions alternatives proposées microsoft ont toutes à minima un plan de contrôle dans le cloud, comme Microsoft connected Cache, Microsoft Connected Cache for Internet Service Providers (en preview) ou encore Azure Update manager. A date, Rien ne semble prévu pour les infrastructures qui ne peuvent dépendre du Cloud.

*Image d’illustration générée via Firefly