jeudi 23 juillet 2009

La faille SMB-RELAY qui a provoqué la crise mondiale !

le CERTA a publié l'avis CERTA-2008-AVI-549 suite au bulletin de sécurité Microsoft MS08-068. Celui-ci corrige une attaque nommée SMB Relay qui profite d'une erreur dans la mise en oeuvre de l'authentification par SMB/NTLM (NT LAN Manager). Le principe est le suivant :

  • le client SMB est amené à se connecter à un service SMB distant contrôlé par une personne malveillante. Cet accès peut être forcé en incitant la victime à accéder à une ressource distante par exemple. Il est possible d'imaginer une page Web lue par Internet Explorer ou un message électronique au format HTML visualisé dans Outlook avec une ligne du type suivant dans le code :
          
  • le serveur SMB distant accepte les sessions authentifiées. Il peut forcer le client à le faire en rejetant sa session anonyme (NULL). Dans ce cas, le client transmet son nom d'usage, le domaine et le mot de passe de l'utilisateur connecté via les procédures NTLM ;
  • durant la phase d'authentification, le serveur envoie une valeur aléatoire, un « challenge ». Le mot de passe qui est transmis par le client sous forme de condensat (hash) au serveur est donc en principe unique pour un mot de passe et une valeur de « challenge » donnée. Le client envoie en revanche son nom et le domaine en clair ;
  • le serveur malveillant qui utilise le même « challenge » systématiquement peut effectuer une attaque par recherche exhaustive ou par table précalculée sur le condensat du mot de passe ;
  • le serveur malveillant peut également utiliser ces mêmes informations d'authentification pour essayer de se connecter sur le poste client : le « challenge » que va demander le poste client peut également être celui que le serveur propose au client qui cherche involontairement à se connecter. En d'autres termes, le serveur demande au client ce que le client exige pour se connecter à lui. Il obtient cette information et peut alors se connecter et exécuter du code.

Cette forme d'attaque est aussi dite réflexive.

Le correctif de Microsoft mentionné dans MS08-068 protège du dernier point en vérifiant que le « challenge » reçu par un serveur SMB ne correspond pas à l'un de ceux que la machine vient de fournir.

Le correctif n'apporte cependant pas de mesure pour limiter les risques d'un relais SMB illégitime qui redirige correctement le trafic vers un serveur fonctionnel. Il reste donc envisageable de dérouter une phase d'authentification vers une autre machine locale et d'abuser d'un service autorisant NTLM comme authentification. Ce scénario reste possible quand des services s'appuient sur la suite Integrated Windows Authentication dans une zone de confiance.

Plusieurs mesures s'appliquent pour éviter ce genre de problèmes :

  • mettre à jour les postes Windows avec le correctif décrit dans MS08-068 ;
  • désactiver le partage de fichiers et d'imprimantes s'il n'est pas utile ;
  • filtrer les ports 139 et 445 par une politique rigoureuse ;
  • ne pas utiliser de comptes administrateur par défaut (bloquer les droits d'écriture dans ADMIN$ et les permissions pour manipuler les services Windows) ;
  • avoir des mots de passe de comptes utilisateur robustes ;
  • mettre en place des solutions de sécurité complémentaires (IPsec, signature SMB, etc.).
  • DEMONSTRATION: EN ANGLAIS :depuis skullsecurity.org

And here’s the scenario (see the image at the right for a diagram):

  1. Attacker tricks the victim into connecting to him; this is easy, I’ll explain how later
  2. Attacker establishes connection to the target, receives the 8-byte challenge
  3. Attacker sends the 8-byte challenge to victim
  4. Victim responds to the attacker with the password hash
  5. Attacker responds to the target’s challenge with the victim’s hash
  6. Target grants access to attacker

In the case of Metasploit, the attacker goes on to upload and execute shellcode, but that process isn’t important, and it’s discussed on the Metasploit blog posting.

Now, as an attacker, we have two problems: the victim needs to initiate a connection to the attacker, and the victim needs to have access to the target.

The first problem is easy to solve — to initiate a session, send the user a link that goes to the attacker’s machine. For example, send them to a Web site containing the following code:

Their browser will attempt to connect to a share on the attacker called “SHARE”, during which a session will be established. The victim’s machine will automatically send the current credentials, hashed with whatever challenge is sent by the attacker (naturally, for the attack, this is the target’s challenge). This can be delivered to them through an email link, through a stored cross-site scripting attack, by vandalizing a site they frequent, redirecting them with DNS poisoning, ARP spoofing, NetBIOS poisoning, and any number of other ways. Suffice to say, it’s pretty easy to trick the victim into connecting to the attacker.

The second problem is that the victim needs to have access to the target. This one is slightly more difficult, but it can happen in a number of ways:

  • In a domain scenario, the user’s domain account may have access to multiple machines, including the target
  • In other scenarios, users are well known to synchronize their password between machines. The target may have the same password as the victim, which would make the attack work
  • The target may be the same physical machine as the victim

That third point is the interesting one — this can be used to exploit the computer itself! So, in that scenario, here are the modified steps (see the image at the right, although I think it’s probably more confusing :) ):

  1. Attacker tricks the victim into connecting to him
  2. Attacker establishes connection back to the victim, receives the 8-byte challenge
  3. Attacker sends the victim’s 8-byte back
  4. Victim responds to the attacker with the password hash that’ll give the attacker access to the victim’s own computer
  5. Attacker responds to the victim’s challenge with the victim’s hash
  6. Victim grants access to attacker

Hopefully that isn’t too confusing. What it essentially means is that the victim will grant access to the attacker using its own credentials.

And this particular attack is what ms08-068 patches!

To put it another way: ms08-068 patches an attack (discovered in 2001) where a victim is tricked into giving an attacker access to connect to itself.

Mitigation

I talked a lot about vulnerabilities in the SMB protocol. Unfortunately, ms08-068 only fixes one of them. The issue is that the others are design flaws and can’t be fixed without breaking clients. That being said, even though Microsoft can’t fix them, you can fix them yourself, more or less, at the cost of potentially breaking clients (these can be done with local/domain security policies or registry hacks; search for them to find information):

  • Enable (and require) NTLMv2 authentication — this will prevent pre-computed attacks, because the client provides part of the randomness
  • Enable (and require) message signing for both clients and servers — this will prevent relay attacks
  • Install ms08-068 — this will prevent a specific subset of relay attacks, where it’s relayed back to itself .

Aucun commentaire:

Enregistrer un commentaire