Zero-day ADV200006 – How to use GPOs to mitigate your Windows risks

What is the problem?

As you may know, a new zero-day vulnerability (ADV200006) was raised by the security community. This vulnerability targets Windows systems with Adobe Acrobat installed on it, so as you can imagine, it is a very large impact. The problem occurs if the user opens some infected PDF documents or if the user uses thumbnails in the preview pane to visualize a PDF document.

ADV200006 is using Adobe Type Manager which is managed by the atmfd.dll file. The atmfd.dll file is a kernel module provided by Windows. Using a specially infected document opened or view it in the Windows preview pane, an unauthenticated remote attacker may be able to execute additional code using this Adobe Type Manager Library with kernel privileges on a vulnerable system.

If you are using the sandbox feature on Windows 10, the impact of the attack is limited – but if you are using Windows 10 without sandbox feature activated or a previous version of Windows on your workstations, it will be a huge risk for your organization.

Unfortunately, Microsoft didn’t provided any fix (date is today 2020/03/28) for the moment – for sure it will – in the meantime you must deploy a workaround to change your workstations configuration and be able to wait for the Microsoft patch.

You can read more details about ADV200006 using this Microsoft link: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv200006

How to mitigate this in a corporate environment?

You can use different mitigation methods, but there are existing some variations depending which Windows versions you are using on your corporate network. So, I choose to describe a mitigation method which will work on your different operating systems from Vista to 10.

Create the first GPO with the user part of the mitigation settings

Open your GPMC console.

Right click on the « Group Policy Objects » folder and select the New option:

For example, name your GPO « GPO_SECU_zeroD_ADV2000068_U-settings ».

Right click on the new GPO and select the Edit… option:

Go to User Configuration | Policies | Administrative Templates | Windows Components – Select File Explorer section:

Set to Enabled these two GPO options: « Turn off display of thumbnails and only display icons » + « Turn off the display of thumbnails and only display icons on network folders« :

So, at the end you should have this:

Close you GPO and link this GPO with all the automation office user accounts in your organization (in a nutshell, all the user accounts which can be used on your workstation).

Create the second GPO with the computer part of the mitigation settings

Important: you must use the GPMC tool from a workstation, not from a server, because the service we will want to control doesn’t have the same name on a Windows Server operating system.

Open your GPMC console.

Right click on the « Group Policy Objects » folder and select the New option:

For example, name your GPO « GPO_SECU_zeroD_ADV2000068_C-settings ».

Right click on the new GPO and select the Edit… option:

Go to Computer Configuration | Policies | Windows Settings | Security Settings – Select System Services section:

Double click on the WebClient service in the right panel and select the following options:

So, at the end you should have this:

Close you GPO and link this GPO with all the workstation computer accounts in your organization.

What is next?

Now you must follow and check when Microsoft will release a patch for this zero-day vulnerability. Have a look on this link: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv200006 or follow the your habitual security gurus.

When you will get the patch from Microsoft, and after you will apply it, you will be able to revert these two GPOs.

Stay safe.

AD Hardening: Microsoft Security Compliance Manager & Microsoft Security Compliance Toolkit

Comme vous le savez, je travaille énormément sur les concepts de AD Hardening de manière à réaliser des re-design d’installation Active Directory afin que l’IT global des organisations soit le moins sensible possible aux attaques de malware (attaques indirectes) ou aux attaques directes.

Dans ce cadre, la recommandation de Microsoft est de segmenter l’environnement lié à l’annuaire Active Directory en trois tiers : Tier 0, Tier 1 et Tier 2 – le Tier 2 représentant globalement les workstations :

Globalement, l’effort de travail et d’investissement se fait bien évidement sur la couche Tier 0 (qui voudrait voir ses contrôleurs de domaine compromis ?) – cela est bien normal, car un re-design AD est un effort colossal pour la plupart des organisations, et elles mettent généralement le focus sur la sécurisation des contrôleurs de domaine. Néanmoins, attention, il ne faut pas oublier que les attaques proviennent à 90% de Tier 2 (voir la règle #2 d’un autre de mes post : https://www.identitycosmos.com/http:/www.identitycosmos.com/non-classe/the-good-old-arcade-games-teach-us-about-today-cybersecurity-rules).

Il est effectivement impossible de sécuriser à 100% la couche Tier 2, mais Microsoft nous fournit un ensemble d’outils permettant de nous faciliter le travail. Ces outils sont assez méconnus, car gratuits ! Je sais, cela parait curieux, mais quel intérêt aurait un commercial Microsoft à vous parler d’un outil gratuit ?

Microsoft Security Compliance Manager

Microsoft Security Compliance Manager (SCM de son petit nom) est un outil relativement ancien, je dirais qu’il existe depuis environ 6 ou 7 ans. D’abord en version 1, puis 2, puis 3 jusqu’à la dernière version en 4.0. Cet outil permet d’utiliser des modèles de sécurité prédéfinis et d’appliquer ces modèles sur les postes de travail ou même les serveurs membres soit par GPO, soit par System Center Configuration Manager (via la fonction DCM).

Plus d’informations sur l’outils en V4 [ ICI ]

La dernière version de l’outil intègre des modèles pour Windows 10 V.1511 et pour Windows Server 2016.

Même si cet outil est très intéressant, je ne passerai pas trop de temps dessus car il a été remplacé par un nouvel outil : Microsoft Security Compliance Toolkit

Microsoft Security Compliance Toolkit

Microsoft Security Compliance Toolkit est donc le remplaçant de Microsoft Security Compliance Manager, il est actuellement en version 1.0. Vous trouverez des informations générales sur l’outil sur cette page de Microsoft [ ICI ].

Le kit de base est disponible en téléchargement [ ICI ].

Un update de ce kit de base assurant la compatibilité avec Windows 10 V.1809 et Windows Server 2019 est disponible en téléchargement [ ICI ] – Cet update contient en fait les mises à jours des référentiels de sécurité fournis par l’outil, ce que l’on appelle les Baselines, mais nous en parlerons plus loin dans cet article. Des informations complémentaires sur le contenu de cet update sont disponibles sur [ CET ARTICLE ].

Lorsque vous téléchargez SCT 1.0, le ZIP contient plusieurs éléments :

Dans le répertoire « PolicyAnalyzer », vous trouverez les éléments suivants :

Le document PDF « Policy Analyzer.pdf » donne des explications sur l’outil Policy Analyzer (qui est présent en version 3.2 dans SCT 1.0), pour être honnête, la documentation est médiocre, il faut être bien concentré pour comprendre le fonctionnement ! Globalement, Policy Analyzer va pouvoir faire plusieurs choses :

  • Comparer les configurations appliquées sur les machines avec des Baselines fournies par Microsoft – c’est la fonction principale de cet outil
  • Détecter les paramètres redondants appliqués au travers de plusieurs GPOs
  • Comparer les paramètres de GPO de domaine avec les clés de registre effectivement paramétrées sur les machines, cela pouvant mettre en évidence des problèmes d’application de GPO,et donc des problèmes de conformité

Par exemple, sur ce screenshot, on peut voir une comparaison de valeurs entre la valeur locale du paramètre (registre), le paramètre présent dans la GPO qui devrait s’appliquer et le modèle de sécurité préconisé par Microsoft (Baseline) :

L’ensemble des informations peut être exporté dans Excel :

Dans le répertoire « LGPO », vous trouverez les éléments suivants :

Le document PDF « LGPO.pdf » donne des explications sur l’outil Local Group Policy Object (qui est présent en version 2.2 dans SCT 1.0), à nouveau la documentation n’est pas terrible, il va falloir que Microsoft fasse un effort sur le sujet. Globalement, Local Group Policy Object va pouvoir faire plusieurs choses :

  • Importer des paramètres depuis des fichiers .POL
  • Importer des paramètres depuis des fichiers de type Security Template
  • Exporter les GPOs vers un backup
  • Exporter les GPOs pour réaliser une comparaison dans le premier outil du kit (Policy Analyzer)

L’outil est uniquement en ligne de commande – il était déjà présent dans Microsoft Security Compliance Manager – Cette vidéo donne quelques exemples d’utilisation de l’outil : https://www.youtube.com/watch?v=Dv6dq1YllnU

L’outil propose aussi des fichiers de Baseline pour chaque population de système :

Avec un update pour les dernières versions d’OS disponibles en téléchargement [ ICI ]. Chaque fichier ZIP, lorsqu’il est décompressé possède la même structure, par exemple ici pour Windows 2012 R2 :

Le répertoire « Documentation » contient un fichier Excel avec les paramètres recommandés :

Le répertoire « GP Reports » contient les fichiers équivalents au format Excel mais au format Report HTML tel que prévu dans la GPMC (L’outil de gestion des stratégies de groupe dans Active Directory) :

Le répertoire « GPOs » contient les paramètres au format GPO (plus être précis, au format GPT de la GPO) :

Le répertoire « WMI Filters » contient des filtres WMI tout prêts à être importés – bon je ne suis pas super fan des filtres WMI pour plein de raisons différentes, mais ils sont présents si vous voulez les utiliser:

Vous trouverez [ ICI ] des informations générales sur la notion de Security Baseline chez Microsoft.

Je vous laisse maintenant explorer par vous-même ce kit – pour être honnête son usage est relativement consommateur de temps, mais c’est un outil parfait pour s’assurer de la configuration de sécurité des machines Windows dans une environnement Active Directory – je vais essayer de réaliser rapidement un tutoriel complet de la solution. Je vais notamment rentrer en contact avec l’équipe produit pour voir comment il serait possible d’améliorer la documentation présente sur docs.microsoft.com, car pour l’instant c’est plus que léger.

N’hésitez pas à laisser vos commentaires sur ce post.

Microsoft propose une mise à jour des fichiers ADMX pour Windows 10

 

La version RTM de Windows contient une version maintenant obsolète des fichiers ADMX dont on besoin les administrateurs pour gérer les stations Windows 10.

Sur ce lien, vous trouverez les nouvelles définition des fichiers ADMX pour Windows 10. Avec les éléments suivants:

  1. DeliveryOptimization.admx
  2. fileservervssagent.admx
  3. gamedvr.admx
  4. grouppolicypreferences.admx
  5. grouppolicy-server.admx
  6. mmcsnapins2.admx
  7. terminalserver-server.admx
  8. textinput.admx
  9. userdatabackup.admx
  10. windowsserver.admx

Sur ce lien, vous trouverez le fichier Excel décrivant les fonctions et paramètres (Group Policy Settings Reference for Windows and Windows Server)

Webinaire sur l’intégration des MacOS X dans Active Directory

J’ai dernièrement réalisé un webinaire sur la thématique de l’intégration des machines MacOS X dans Active Directory pour le compte de la société Cerberis. Nous avons pris en exemple l’intégration via les technologies Centrify avec le mode AutoZone de manière à simplifier l’intégration et l’accès des utilisateurs sur les systèmes. La fin du Webinaire comporte une démonstration avec des GPOs appliquées sur les MacOS, la relation entre les comptes AD et l’authentification sur les postes MacOS X et encore la migration des comptes locaux vers des comptes Active Directory afin de conserver l’environnement utilisateur d’un compte local après migration vers un compte AD.

Voici le webinaire:

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify

Installation de Centrify Workstation for Mac 2016 sur EL CAPITAN (MacOS X 10.11) [Part 2/4] – Installation de l’agent Centrify.

Lors de l’article précédent, nous avons préparé l’environnement, maintenant tout est prêt et le package DMG est sur le bureau d’un compte local MacOS X avec des pouvoirs d’administrateur :

clip_image002

La dernière des choses à vérifier est que le MacOS X n’est pas relié à Active Directory avec le plug-in Active Directory natif de MacOS X, ceci est très important. Pour vérifier, choisir l’option Utilisateurs & Groupes / Users & Groups dans les préférences systèmes :

clip_image004

Ici, il n’y pas de domaine joint, c’est donc parfait :

clip_image006

Passons maintenant au choses sérieuses…

[1] Vérification de l’environnement grâce à ADCheck

Le package DMG contient un outil de vérification de l’environnement avant installation de l’agent, il faut donc ouvrir l’image DMG:

clip_image008

Et choisir l’icône AD Check au lancement d’AD Check, l’assistant vous demande le nom de domaine du domaine que vous souhaitez rejoindre afin de faire les vérification, dans mon exemple, le nom de domaine est demo.local:

clip_image010

Puis cliquer sur le bouton bleu AD Check

clip_image012

clip_image014

Pour que la future installation se déroule sans encombre, il faut que vous n’ayez aucun "Failed" dans la liste des résultats aux tests – par exemple, ici, l’assistant AD Check m’indique que un des serveurs DNS que j’utilise sur ma machine ne gère pas le nom de domaine demo.local – nous allons donc l’enlever de la configuration DNS et refaire les test AD Check:

clip_image016

Ça y est, tout va bien !

[2] – Installation de l’agent et rejoindre le domaine AD

Lancer le package pour l’installation de l’agent Centrify:

clip_image018

Choisir "Continue":

clip_image020

Puis à nouveau sur "Continue":

clip_image022

Puis, après avoir lu le Software License Agreement, à nouveau sur "Continue":

clip_image024

Puis sur "Agree":

clip_image026

Puis sur "Install":

clip_image028

Indiquer le mot de passe de l’administrateur local (ici, le mot de passe pour Florent) et appuyer sur "Install Software":

clip_image030

Le processus d’installation de l’agent se poursuit alors :

clip_image032

A la fin du processus, choisir l’option "Launch centrify Join Assistant" (sélectionnée par défaut) et choisir "Continue":

clip_image034

La fenêtre de l’installateur indique que tout s’est bien déroulé :

clip_image036

Et une nouvelle fenêtre apparait pour lancer l’assistant AD JOIN, cliquer sur "Continue":

clip_image038

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

clip_image040

Indiquer alors le nom de domaine du domaine AD à rejoindre (ici demo.local), un compte administrateur AD qui a le droit d’écrire dans AD (à minima dans les UOs que vous avez créé dans l’article précèdent) ainsi que le mot de passe de ce compte d’administration AD, puis cliquer sur "Continue":

clip_image042

Indiquer les options pour rejoindre le domaine, vous pouvez garder toutes les options par défaut – pour des machines MacOS, je vous conseille de garder "Auto" pour le "Licensed Mode", cela vous permet de ne pas avoir à gérer les UIDs pour les comptes utilisateurs, par défaut dans ce mode, les UIDs générés dans la Zone Centrify seront un dérivé du SID utilisateur AD – vous pourrez ensuite aligner les UIDs générés dans cette zone avec les comptes utilisateurs existants au niveau de l’OS MacOS X via un outil fourni par centrify.

A noter que le premier ordinateur MacOS qui sera joint à AD avec le mode "Auto" va automatiquement créer la zone "Auto" au niveau de l’AD lui-même, contrairement aux systèmes Unix et Linux qui sont généralement joints dans des zones « standards », il n’y a pas besoin ici de créer la zone en amont de la première jointure au domaine.

Puis cliquer sur "Join"

clip_image044

Indiquer le mot de passe de l’administrateur local (ici, l’administrateur local est Florent) et cliquer sur OK:

clip_image045

L’assistant indique que la machine est en train de rejoindre le domaine AD:

clip_image047

Tout s’est bien déroulé, cliquer sur "Done":

clip_image049

Redémarrer le poste MacOS.

[3] – Première connexion avec un compte utilisateur AD

Sur la fenêtre de login du MacOS X, vosu trouverez par défaut les comptes locaux existants (ici Florent) – mais maintenant que vous avez joint la machine à AD, vous pourrez accéder à une liste d’utilisateurs provenant d’AD en cliquant sur "Other…"

clip_image051

Par exemple, nous avons un compte utilisateur existant dans AD qui est Luc:

clip_image053

Nous allons utiliser ce compte et son mot de passe AD pour nous connecter sur la machine MacOS X:

clip_image055

Un nouveau bureau pour Luc apparait :

clip_image057

Si nous utilisons une fenêtre de Terminal, et que l’on taper la commande ‘id’ on obtient les informations suivantes, l’UID a été automatiquement généré pour l’utilisateur :

clip_image059

Toujours dans le terminal, la commande ‘adinfo’ nous permet d’obtenir des informations sur la connectivité à AD:

clip_image061

Ça y est, c’est officiel, notre machine MacOS X EL CAPITAN a rejoint AD et peut utiliser tous les services AD.

Dans les prochains articles, nous allons explorer quelques pistes d’améliorations du paramétrage de base, utiliser quelques outils d’administration et nous allons explorer les GPOs applicables aux systèmes MacOS X.

Directory as a Service, c’est parti !

AzureADDoma1Ça y est ! Microsoft rend public Azure AD Domain Services (à ne pas confondre avec Azure AD ou avec le fait d’installer un DC sur la plateforme IAAS d’Azure… Bon, je sais, ca devient un peu compliqué) qui est la première brique d’une approche qui fait fantasmer énormément de monde: le Directory As A Service ou DaaS. Alors oui, vous allez me dire le DaaS c’est aussi le « Data as a Service », le « Desktop as a service », etc… bon d’accord, alors écrivons le comme cela: DIRaaS, cela sera plus clair…

Donc pour faire simple, Microsoft rend public un nouveau service Azure permettant de créer un service online « simulant » un Active Directory dans Azure (côté SaaS, pas côté IaaS): Azure AD Domain Services. Les objectifs de ce service sont multiples:

(1) Permettre aux entreprise qui possèdent des applications AD dépendantes dans l’IaaS d’Azure (donc des applications hébergées sur des machines virtuelles Azure pour faire simple) de consommer un service Active Directory standard (enfin presque…) sans être obligé d’installer et de maintenir des DCs sur des machines virtuelles Azure uniquement pour des besoins applicatifs

(2) Permettre à des petites entreprises de pouvoir TOUT consommer sous la forme de service d’infrastructure depuis la plateforme Azure – Mais attention, à ce stade il n’est possible que de joindre des machines qui sont des VMs dans Azure, donc ici, pas possible de joindre un domaine Azure AD Domain Services depuis par exemple une machine Windows 10 qui est « on premises » (alors que cette fonction existe avec AD Azure, oui je sais c’est un peu compliqué…)

(3) A terme, fournir un véritable DIRaaS pour les grandes entreprises. Sur ce point, oui, je sais,  j’extrapole, mais je sens bien les choses comme cela, et franchement c’est assez intéressant. Bien sur il y a encore pas mal de dev à faire, mais cela va venir, j’en suis persuadé…

Faire des tests !

En effet, dans le cadre de la gestion de VMs qui sont dans Azure et qui possèdent des applications dépendantes à AD, il faut voir globalement le service Azure AD Domain Services comme un service qui expose les protocoles Kerberos, NTLM, LDAP et GPOs – les VMs Azure peuvent donc joindre ce domaine. Mais attention, on est pas ici exactement comme un domaine AD, donc il est important de faire des tests pour valider que vos applications sont fonctionelles dans ce contexte technique et être certain qu’elles fonctionnent avec ce service – à ce jour, je ne suis pas sur qu’il existe un catalogue officiel d’applications certifiées pour le service, cela viendra certainement.

En bref.

Super intéressant, à tester. Plus d’informations [ ici ]