Arnaud Jumelet

Blog - Consultant - Sécurité - Identité

  • Arnaud Jumelet

    Administration à l’aide de Windows Remote Shell : WinRS

    • 0 Comments

    Pour administrer à distance, en ligne de commande, un serveur Windows 2003 R2 et supérieur, il est possible d’utiliser Windows Remote Shell (WRS).

    Windows Remote Shell utilise Windows Remote Management (WinRM) qui est l’implémentation de WS-Management.
    Les services WS-Management (Web Services for Management) permettent l'exécution de commandes et de scripts à distance. Les communications sont chiffrées et authentifiées, limitant ainsi les risques en matière de sécurité.

    Les administrateurs peuvent utiliser l'outil de ligne de commande Windows Remote Shell pour obtenir des données de gestion (des informations, par exemple, sur des objets tels que les disques, les adaptateurs réseau, les services ou les processus) auprès d'ordinateurs locaux et distants.
    Si l'ordinateur exécute une version du système d'exploitation Windows qui inclut Windows Remote Management, les données de gestion sont fournies par Windows Management Instrumentation (WMI).

    L’administrateur à l’aide de Windows Remote Shell ouvre un interpréteur en ligne de commandes, puis exécute des requêtes WMI à l’aide de l’outil wmic.exe.

    1. Afin d’utiliser Windows Remote Shell à distance, il est nécessaire de créer un « écouteur » sur l’ordinateur à administrer à l’aide de la commande suivante :

    winrm quickconfig

    2. Le texte suivant s’affiche :

    WinRM n'est pas configuré pour la gestion à distance de cet ordinateur.

    Les modifications suivantes doivent être effectuées :

    Créez un écouteur WinRM sur HTTP://* pour accepter les demandes de la gestion des services Web sur toutes les adresses IP de cet ordinateur.

    Activez l'exception de pare-feu WinRM.

    Effectuer ces modifications [o/n] ?

    3. Taper la lettre o, pour terminer, le texte suivant s’affiche:

    WinRM a été mis à jour pour la gestion à distance.

    Écouteur WinRM créé sur HTTP://* pour accepter les demandes de la gestion des services Web sur toutes les adresses IP de cet ordinateur.

    Exception de pare-feu WinRM activée.

    4. WinRM est correctement configuré et en attente de connexion distante.

    5. Sur un poste Windows 7, par exemple, il faut ajouter l’adresse IP de l’ordinateur à administrer en tant qu’hôte de confiance :

    winrm set winrm/config/client @{TrustedHosts="10.0.0.2"}

    6. Il est alors de se connecter à l’ordinateur distant et de lancer un interpréteur de commandes :

    winrs -r:http://<FQDN Serveur CORE> cmd

    Note : dans cet exemple, les commandes ainsi que les résultats sont transmis en clair sur le réseau.

    Lorsque WinRS est utilisé pour administrer un serveur distant, les limitations suivantes doivent être prises en compte :

    • Les commandes WinRS ne peuvent être exécutées qu’à partir d’un ordinateur sous Windows Vista ou supérieur.
    • Les commandes produisant des messages comme «  Press any key to continue » ne sont pas supportés.
    • Pour des raisons de sécurité, veillez à utiliser uniquement WinRM avec un écouteur HTTPS.
  • Arnaud Jumelet

    FEP 2010 et moteur Anti-malware de Microsoft “Malware Protection”

    • 0 Comments

    La solution FEP 2010 est une solution de protection contre les logiciels malveillants, dont la console de gestion s’intègre nativement dans une infrastructure SCCM 2007 existante. En effet, FEP 2010 ne nécessite pas de déployer des serveurs supplémentaires, mais s’intègre nativement dans la solution de gestion des postes de travail SCCM 2007.

    Le moteur anti-malware, dont le nom est Malware Protection,  couvre à la fois les virus, chevaux de Troie, spywares ainsi que les rootkits.
    Les technologies de protection sont multiples : Analyse à base de signature, détection comportementale et protection contre les exploits réseaux.

    Lorsqu’un malware est détecté, plusieurs actions sont disponibles (conformément à la politique définie par l’administrateur FEP 2010) : nettoyage du système (avec ou sans redémarrage nécessaire), mise en quarantaine, suppression du fichier.

    A noter que le laboratoire Microsoft MMPC (Microsoft Malware Protection Center) publie en moyenne une mise à jour des signatures trois fois par jour. Le moteur reçoit une mise à jour mensuelle applicable sans avoir à redémarrer l’ordinateur.

    Le document « Understanding Anti-Malware Research and Response at Microsoft » est une introduction à la technologie anti-malware et l’organisation du laboratoire MMPC :
    http://download.microsoft.com/download/0/c/0/0c040c8f-2109-4760-a750-96443fd14ef2/Understanding%20Malware%20Research%20and%20Response%20at%20Microsoft.pdf


    Analyse de forme statique et émulation

    D’après Éric Filiol : L’analyse de forme consiste à analyser un code hors de tout contexte d’exécution. Il s’agit de rechercher des structures d’octets correspondant à une signature de code malveillant connu ou générique (famille de code malveillant).

    Généralement, les créateurs de virus cherchent à échapper à l’analyse de forme et de ce fait ajoute une couche de protection (obfuscation, chiffrement, compression) qui disparait à l’exécution.
    C’est pourquoi, le moteur Malware Protection dispose d’une fine machine virtuelle (Dynamic Translation) émulant l’API Win32. Ainsi, le binaire à analyser est exécuté dans une machine virtuelle afin de supprimer les éventuelles couches de protection, rendant ainsi de nouveau opérationnelle l’analyse de forme. De plus, et de façon plus traditionnelle, le moteur Malware Protection prend en charge de nombreux formats de compression ainsi qu’un large éventail de « packers ».

    Enfin, lors des analyses du système, le moteur prend en charge l’analyse directe du système de fichiers permettant l'identification et la suppression des programmes malveillants qui seraient autrement cachés par un rootkit qui détournerait le fonctionnement de certaines API liés au système de fichiers.

    Détection comportementale (Protection dynamique)

    D’après Éric Filiol : La détection comportementale consiste à déterminer, au moment où le code est exécuté – par émulation de code ou à l’accès – si certains comportements s’apparentent à du logiciel malveillant ou non.

    Pour cela, le moteur Malware Protection utilise des signatures heuristiques pour rechercher les signes d'un comportement suspect, matérialisés par un ensemble de caractéristiques imputables à des logiciels malveillants connus. Ces signatures heuristiques sont utilisées avant que le binaire ne s’exécute sur le système lors de la phase d’émulation de code qui s'appuie sur la technologie de traduction dynamique de Microsoft.

    Le moteur Malware Protection définit un point d’ancrage sur le navigateur Internet Explorer afin d’être à même d’analyser et de bloquer l’exécution de script malveillant. Pour ce faire, le contenu de la mémoire est analysé avant qu’un traitement soit effectué par le navigateur Internet Explorer.

    Après le démarrage d'un processus, le moteur anti-malware surveille les appels système portant sur les fichiers, base de registre, réseau et le noyau afin d’identifier un comportement suspect. Un comportement douteux déclenche alors une requête vers le service de signature dynamique pour savoir si le programme doit être bloqué ou soumis pour analyse. Cette protection porte également sur les fichiers de contenu (pdf,docx..)

    Concernant le système d’exploitation, le comportement du noyau est supervisé en temps-réel. La technologie acquise en 2008 à la société Komoku Inc. (http://www.microsoft.com/security/portal/komoku/) a été complètement intégrée au moteur Malware Protection qui surveille maintenant l'intégrité des structures du noyau. Cette brique technologique est fondamentalement un KIDS (Kernel Intrusion Detection System) Si le noyau semble avoir été compromis alors des demandes de télémétrie et de mise à jour sont envoyées au service signature dynamique.

    HIPS (Host-Based Intrusion Prevention System)

    D’après Thierry Evangelista : Un HIPS est un agent logiciel que l’on installe sur l’hôte à protéger et qui analyse en temps réel les flux relatifs à cette machine.

    Microsoft Research a développé la technologie NIS (Network Inspection System - http://research.microsoft.com/apps/pubs/default.aspx?id=70223) qui est intégrée dans FEP 2010.

    Un HIDS possède un avantage considérable sur un pare-feu de segment réseau, en ce qui concerne les flux chiffrés. En effet, l’agent NIS étant installé à l’extrémité de la chaine de communication, il est alors possible d’analyser le flux en clair.

    NIS est un HIPS basé sur la détection de formes, disposant d’un moteur et de signatures régulièrement mises à jour. NIS permet de se protéger contre les flux réseaux cherchant à exploiter les vulnérabilités des produits Microsoft dont les correctifs ne seraient pas déployés. Lorsque le correctif est appliqué, alors les signatures sont déchargées du moteur NIS. Si le correctif est désinstallé, alors les signatures en relation sont de nouveaux actives. La protection de NIS porte sur les flux entrants et sortants.

  • Arnaud Jumelet

    Ensemble de ressources sur la technologie de chiffrement EFS

    • 0 Comments

    Dans le graphique ci-dessous, j’ai consolidé l’ensemble des fiches de référence sur EFS disponible sur le site de microsoft.com
    Chaque graphique est cliquable.

    jpg_1 /> Events and ErrorsMisleading Autoenrollment Settings in Group Policy Management...Troubleshooting Certificate EnrollmentTroubleshooting autoenrollmentNT BACKUP?POUR WINDOWS7NT BACKUP?POUR WINDOWS Vista[MS-EFSR] Encrypting File System Remote[MS-GPEF]: ?Group Policy: Encrypting File System ExtensionInside the Windows Vista Kernel[MS-BKRP]: ?BackupKey Remote Protocol SpecificationTechnet?Deploying EFS: Part 2Technet?Deploying EFS: Part 1Windows 7?Changes in EFSData Encryption Toolkit for Mobile PCsEFS with SYSKEYSupport (XP SP3) et QFE for XP SP2 You cannot access EFS files...Support (XP SP3) et QFE for XP SP2?Encrypting File System (EFS)...FIPS 140 EvaluationProcedures?Protecting Data by Using EFS to Encrypt Hard DrivesEncrypting File System in Windows XP and Windows Server 2003Encrypting File System Tools and SettingsHow Encrypting File System WorksThe Windows Server 2003 Family Encrypting File SystemData Encryption ToolkitWindows Vistza Security Guide?Chaptitre 3 : Protect Sensitive...EFS IN VISTA

  • Arnaud Jumelet

    SharePoint 2010 : Une application claim-aware avec son propre STS

    • 0 Comments

    SharePoint 2010 propose un mode d’authentification, appelé authentification par revendication (Claim Based Authentication).

    AuthenticationProvider

    L’authentification par revendication de SharePoint 2010 s’appuie sur un STS local développé à l’aide de WIF (Windows Identity Foundation).
    WIF est un ensemble de classes .NET Framework qui permettent de créer des applications prenant en charge les revendications.
    Pour rappel, une application prenant en charge les revendications créée avec WIF peut traiter des demandes d’authentification basées sur les protocoles WS-Federation et WS-Trust.  Il faut savoir que WS-Federation prend en charge différent type de jeton de sécurité, dont les jetons SAML 1.1

    image

     

    • Le STS local (SP-STS) est développé à l’aide du framework WIF et de ce fait supporte uniquement les protocoles de fédération suivants :
      WS-Federation, WS-TRUST
    • Le SP-STS ne consomme, en entrée, que des jetons de sécurité SAML au format SAML 1.1

    Il est légitime de se demander, s’il est possible de fédérer SharePoint 2010 avec un serveur d’identité ne prenant en charge que le protocole SAMLv2.
    La réponse est oui : il est possible de fédérer (indirectement) SharePoint 2010 avec un serveur d’identité compatible uniquement avec le protocole SAMLv2. L’implémentation passe par un serveur de fédération disposant d’une double pile protocolaire : WS-Federation et SAMLV2.
    Le logiciel ADFS 2.0 répond parfaitement à cette exigence.
     image

  • Arnaud Jumelet

    Domain Controller Locator : In depth

    • 0 Comments

    When a client computer needs to contact a domain controller for a specific domain, NetLogon service running at the client computer tries to search the nearest Domain Controller by querying the local computer registry for DynamicSiteName.

      Note
    If the domain being located is the same as the domain to which the computer is joined and the computer has not physically moved to a different site since the last query, the dynamically determined site name in the registry is the actual site in which the computer is located.

    On the other hand, if the site name in the registry is not the current site of the computer (for example, if the computer is portable), the domain controller location process serves to update the site information in the registry.

    DC Locator Service uses this DynamicSiteName entry to query DNS Server to find the domain controllers in that site. It appends the site name to the DNS query (SRV Record) and sends it to the DNS Server which in turns sends a response.
    DNS must return a list of IP addresses that are sorted by priority and weight.

    Client inspects the SRV record and attempts to choose the domain controller with the lowest priority. If servers have the same priority, client randomly chooses SRV records with probability proportional to the weight. The algorithm is defined in RFC 2782.

    The client (Netlogon service) sends a datagram to the domain controller chosen in the step before. The datagram is implemented as an LDAP User Datagram Protocol (UDP) search.

    The domain controller receives the query, which contains the IP address of the client, and passes it to NetLogon on the domain controller. NetLogon looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client IP address and then returns the following information:

    • The name of the site in which the current domain controller is located.
    • The name of the site in which the client is located, or the site that most closely matches the client IP address.
    • A bit that indicates whether the found domain controller is located (bit is set) or not located (bit is not set) in the site closest to the client.
    • Other pieces of information that describe the domain controller.


      Note
    The site information for the forest is stored in the configuration directory partition in Active Directory, and this information is replicated to all domain controllers in the forest. Included with the configuration information is a list of IP subnets that are associated with a particular site.


    The domain controller returns the information to the client.
    The client inspects the information to determine whether to try to find a beter domain controller. The decision is made as follows:

    • If the returned domain controller is in the closest site (the returned bit is set), the client uses that domain controller.
    • If the client has already tried to find a domain controller in the site in which the domain controller claims the client is located, the client uses that domain controller.
    • If the domain controller is not in the closest site, the client updates its site information and sends a new DNS query to find a new domain controller in the site. If the second query is successful, the client uses the new domain controller. If the second query fails, the client uses the original domain controller.
    • If the domain that is being queried by a computer is the same as the domain to which the computer is joined, the site in which the computer resides (as reported by a domain controller) is stored in the computer registry. The client stores this site name in the DynamicSiteName registry entry in HKLM\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters. Therefore, the DsGetSiteName API returns the site in which the computer is located.

    To override the dynamic site name value returned, you can fix the SiteName entry.
    When a value is present for the SiteName entry, the DynamicSiteName entry is ignored.

    REG_SZ

    HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\SiteName

    Range :
    String


    Searching a domain controller at a specific site

    If no other site is specified, a locator searches for a domain controller in the Active Directory site at which the client is located, or was last found. If the Active Directory site of the client is not known to the locator when the search begins, it asks a DNS server for the general entries of the domain controllers in the specified domain. It then turns to one of the domain controllers found to determine the Active Directory site which the client belongs to. If the addressed domain controller is not in the same Active Directory site, the locator repeats the DNS request specifying the Active Directory site of the client in order to find a domain controller in its Active Directory site.

    If the client does not receive a response from the domain controller of its Active Directory site, or if no domain controller is available at this site, the client returns again to the general list of domain controllers. In this case, the client receives a pseudorandom domain controller in return to its general request.

     

    Client with no apparent site

    If the client pings a domain controller 2000/2003 and the client IP address cannot be found in the subnet-to-site mapping table, then in this case, the domain controller returns a NULL site name, and the client uses the returned domain controller.

    Important
    The behavior on Windows Server 2008 domain is not the same.
    If a domain member has an IP address that is not linked to a specific site, that computer will be placed in the Default-First-Site-Name site. Every computer that is part of a Windows Server 2008 domain must belong to a site.

  • Arnaud Jumelet

    Domain Controller Locator : an overview

    • 3 Comments

    When an application requests access to Active Directory, a domain controller is located by a mechanism called the Domain Controller Locator.
    The process of location is to use DNS to identify a set of candidate domain controllers from a list, based on SRV records.
    Then, the servers on the list are queried to test if they are alive.

    The client is initialized with DomainName.FQDN being set to the Domain Name System (DNS) name of the domain to locate, for example mockup1.contoso.com

    The general process is shown in the following diagram:

    clip_image002

    The first step is to perform the DNS discovery.
    The client issues a DNS request for _ldap._tcp.dc._msdcs.mockup1.contoso. com
    The DNS server returns a list of SRV records that match this request. If no records are available, then the domain location fails.
    The DNS exchange is done as specified in the DNS protocols (RFC 1769 and related RFCs).
    If target hosts have the same priority, the client select a return SRV record according to weighted pseudorandom order (see RFC2052).

    The client then resolves the SRV record to an address, again as specified in the DNS protocols.

    Once the address is known, the client sends an LDAP “Ping,” as a way of detecting that the domain controller is in fact handling requests and determining the characteristics of this domain controller. The LDAP “Ping” also known as connectionless LDAP is sent over UDP

    After each packet is sent, the client waits for a response, and if no response is received, it sends a packet to the next domain controller. The client continues this process until it receives a valid response that specifies the requested services or has tried all of the domain controllers.

    When a client tries to locate a domain controller after it has received the IP address from DNS, it varies the time it waits for a response based on the number of domain controllers it has already pinged. For the first five domain controllers, it waits for 0.4 seconds, and for next five domain controllers, it waits for 0.2 seconds. After 10 domain controllers have been pinged, the client uses a 0.1 second wait for the remaining requests.

    The LDAP “Ping” is an LDAP rootDSE search to the domain controller, looking for an attribute called “NetLogon.”

    The domain controller server inspects the query and returns the NetLogon result.
    The response is typically returned in a NETLOGON_SAM_LOGON_RESPONSE_EX.

    Upon receipt of the LDAP SearchResultEntry, the client validates the capabilities returned by the domain controller.

    If the capabilities returned by the domain controller are incompatible with the requirements specified by the invoker of the locator algorithm on entry, the client must select another candidate domain controller from the list of domain controller SRV records returned above.

    Incompatibility in this case can arise because the client requested a Kerberos KDC, but the domain controller did not indicate that a KDC was present, or the client requested a domain controller that could accept writes, but this domain controller is read-only.

    These sorts of negative results are cached by the client; however, they are purged promptly (on the order of minutes).

    Because the LDAP “Ping” returns a snapshot of the current state of the domain controller at the moment of the query, services such as a time server, may not be running at the moment, but may be available once the server has completely started.

    If all the responses in the SRV records have been checked, and each SRV record points to a server that is either not available or does not match the requirements, then the location operation has failed.

    Upon successful response from the domain controller, the location portion completes.
    The DomainController element is set to the name and address of the domain controller that was selected.

  • Arnaud Jumelet

    BitLocker : Registres PCR d’une puce TPM

    • 0 Comments

    La mesure de l’intégrité de la séquence de démarrage s’appuie sur les registres de configuration de la plateforme (Platform Configuration Registers ou PCR) qui sont des portions de mémoire volatiles de 160 bits (pour stocker des condensats SHA-1) permettant de stocker l'état d'une plateforme. La spécification impose que les PCRs soient, au minimum, au nombre de 16 (numérotés de 0 à 15). Les registres 0 à 7 sont utilisés par la puce TPM et le BIOS TCG, ceux de 8 à 15 peuvent être utilisés par une application pour y placer des mesures d’intégrité portant sur des composants spécifiques.

    Sur le schéma ci-dessous, est représenté en bleu, les mesures d’intégrité prises en compte par la solution de chiffrement BitLocker sous Windows 7. Le comportement est configurable par stratégie de groupe. A noter que la table des partitions est prise en compte lors de la mesure d’intégrité de la séquence de démarrage.

     PCR

  • Arnaud Jumelet

    BitLocker : Etats d’une puce TPM

    • 0 Comments

    Il existe 8 modes opérationnels pour une puce TPM, définis à travers trois variables : enabled, activated et owned. Ces booléens représentent respectivement le fait que la puce est inactive et sans possibilité d’en devenir propriétaire, le fait que la puce est inactive mais que l’on peut effectuer l’opération de prise de possession (TakeOwnership) et enfin le fait que la puce ait été initialisée par un propriétaire via l’opération takeownership.

    tpm

    L’outil tpm.msc (inclus dans Windows 7) permet d’effectuer des actions sur la puce TPM afin de modifier son état. Ainsi, il est possible d’arriver à l’état 0, 6 ou 7 comme illustré sur le schéma précédent et la capture d’écran ci-dessous :

     image

    Le changement d'état de la puce TPM nécessite l'autorisation du propriétaire de la puce (via l'utilisation du mot de passe de propriétaire) ou bien un consentement via une démonstration de la présence physique. Ainsi, le fait de modifier l’état d’une puce TPM n’ayant encore aucun propriétaire définit impose de redémarrer l’ordinateur et d’appuyer physiquement sur une touche pour valider le changement de configuration.

    Par défaut, la prise de possession de la puce TPM s’effectue en trois étapes, nécessite deux redémarrages et impose la présence physique d’un opérateur. Lors de la prise de possession de la puce TPM, le mot de passe du propriétaire est définit et la puce va créer la clef SRK (Storage Root Key).

    Pour automatiser la prise de possession de la puce TPM, il faut que la puce se trouve dans état correct pour la prise de possession, c'est-à-dire dans l’état enabled et activated. Il est dans ce cas nécessaire de flasher le BIOS et la mémoire CMOS contenant la configuration du BIOS.

    Note : Le fait de réinitialiser (Clear TPM) une puce TPM efface la SRK et toutes les clefs cryptographiques dérivées. Si BitLocker est activé avec un protecteur de type TPM, alors au prochain démarrage BitLocker entre alors en mode de récupération.

Page 2 of 5 (36 items) 12345