Temps de lecture : 7 minutes

Qu’est-ce que CVE-2021-21974 ?

VMware a initialement décrit CVE-2021-21974 (CVSS 8.8) dans son  avis VMSA-2021-0002 de février 2021 comme laissant un “acteur malveillant résidant dans le même segment de réseau qu’ESXi qui a accès au port 427 peut être en mesure de déclencher le tas- problème de débordement dans le service OpenSLP entraînant l’exécution de code à distance.

Lucas Leong, le chercheur en sécurité qui a initialement signalé la vulnérabilité via le ZDI, avait publié un court blog en mars 2021 avec un aperçu de la façon d’exploiter la vulnérabilité, notant que “Service Location Protocol ( SLP ) est un service réseau qui écoute sur TCP et le port UDP 427 sur les installations par défaut de VMware ESXi. L’implémentation utilisée par VMware est basée sur OpenSLP 1.0.1. VMware maintient sa propre version et y a ajouté quelques durcissements. Le service analyse l’entrée réseau sans authentification et s’exécute en tant que root, de sorte qu’une vulnérabilité dans le service ESXi SLP peut conduire à l’exécution de code à distance de pré-authentification en tant que root. Ce vecteur pourrait également être utilisé comme échappement de machine virtuelle, puisque par défaut un invité peut accéder au service SLP sur l’hôte… »

(Il n’était pas immédiatement clair pourquoi il a fallu autant de temps pour monétiser CVE-2021-21974 étant donné que des exploits de preuve de concept ont circulé depuis au moins mai 2021, mais il se peut que quelqu’un vient juste d’automatiser un script.)

Un chercheur en sécurité, Habib Karataş , a également suggéré que l’attaque avait des failles, affirmant que dans au moins un cas, “ces amis super intelligents n’ont chiffré que les fichiers de configuration sur le système et ont empêché le système de voir les disques. Voici la solution », a-t-il suggéré.

“1- Supprimez les fichiers de configuration cryptés. 2- créer une machine virtuelle vide. 3- Ouvrez le fichier de configuration sur la nouvelle machine et mettez-le dans le répertoire de vos machines chiffrées. – Remplacez les informations du fichier de configuration par les noms de machine chiffrés. 5- Allez sur l’écran Vmware et “register VM” et continuez votre chemin.

(Cela ne semble pas être le cas pour tous les utilisateurs ESXi concernés…) 

Le CERT-FR a affirmé le 3 février que « ces campagnes d’attaques semblent exploiter la vulnérabilité CVE-2021-21974, pour laquelle un correctif est disponible depuis le 23 février 2021 »…

Les utilisateurs doivent également revoir le Guide de sécurité vSphere de VMware pour évaluer et prendre des mesures sur les hôtes ESXi ainsi que le centre de ressources Ransomware existant de VMware qui fournit des conseils aux organisations pour « rester résilientes aux attaques de ransomware grâce à des approches pratiques, un renforcement du système et des améliorations de processus ».

Des vulnérabilités OpenSLP ont été révélées qui affectent ESXi. Ces vulnérabilités et leur impact sur les produits VMware sont documentés dans les avis de sécurité VMware (VMSA) suivants.

https://www.vmware.com/security/advisories/VMSA-2021-0002.html

Exploitation de la faille et ALERTE ANSI

Les chercheurs en sécurité signalent une explosion de la compromission des hyperviseurs VMware ESXi avec plus de 500 machines touchées par un ransomware ce week-end – avec les attaques automatisées exploitant CVE-2021-21974.

Comme l’a publié The Stack , quelque 20 machines ESXi auraient été rançonnées toutes les heures, les données de Shodan montrant que la majorité étaient hébergées par OVHcloud, mais que le rayon d’explosion s’étendait rapidement.

Les clients en France semblaient initialement être les plus touchés et le CERT-FR du pays parmi les premiers à publier un avis . Les attaques semi-automatisées peuvent cibler des instances non corrigées et exposées à Internet à l’aide de CVE-2021–21974 , un VMware ESXi OpenSLP HeapOverflow menant à RCE, a suggéré le CERT-FR.

Alors que l’avis initial de VMware en 2021 pour la vulnérabilité indiquait qu’elle affectait les versions 7.0, 6.7 et 6.5 d’ESXi, les attaques semblent également toucher les versions de construction antérieures ; un débat se poursuit également quant à savoir si CVE-2021-21974 est le seul mécanisme par lequel l’exploitation se produit.

Les administrateurs doivent s’assurer que les serveurs ESXi non corrigés sont protégés par un pare-feu, sans aucun port exposé à interne ( Préconisation VMWARE )

https://kb.vmware.com/s/article/76372https://kb.vmware.com/s/article/76372

L’atténuation précédente de VMware pour la vulnérabilité invitait les utilisateurs à 1 : se connecter aux hôtes ESXi à l’aide d’une session SSH (telle que putty) ; 2 : Arrêtez le service SLP sur l’hôte ESXi avec cette commande : /etc/init.d/slpd stop (nb Le service SLP ne peut être arrêté que lorsque le service n’est pas utilisé ; les utilisateurs peuvent vérifier l’état opérationnel du démon SLP : esxcli system slp stats get 3 : exécutez cette commande pour désactiver le service : esxcli network firewall ruleset set -r CIMSLP -e 0

SCRIPT DE VERIFICATION et DE DESACTIVATION+ARRET du SERVICE SLP CIEM


#SCRIPT DE VERIFICATION ET DESACTIVATION DE POLICY CIEM SERVER
#OpenSLP vulnerabilities have been disclosed that affect ESXi. These vulnerabilities
# and their impact on VMware products are documented in the following VMware Security Advisories (VMSAs)
# , please review these before continuing as there may be considerations outside the scope of this document:
#https://kb.vmware.com/s/article/76372
#How to Disable/Enable the SLP Service on VMware ESXi (76372)

# Connect 1 or Multiple Vcenters  
$VCServersList = Read-Host -Prompt "Please enter the vCenter Server names, separated by commas. Example: 'vcenter1.example.com,vcenter2.example.com'"

$VCServers = @($VCServersList.Split(','))
$VCServers
$connected = $false

$pathCSV = Read-Host -Prompt "Please enter the path to save the export CSV. Example: C:\temp\xxx.csv"

foreach ($VCServer in $VCServers)
{
Write-Host "Connected to $VCServer .....- Enter you credential Admin" -ForegroundColor red
    try {
    
    Connect-VIServer -Server $VCServer -ErrorAction Stop
    Write-Host "Connected to $VCServer" -ForegroundColor Green
    $connected = $true
    }
catch {
Write-Host "Unable to connect to $VCServer. Trying next..."
    }
    }


if ($connected -eq $false) {
$VCServer = Read-Host -Prompt "Please enter the vCenter Server name or IP address"
Connect-VIServer -Server $VCServer
}


$vmhost=get-vmhost
$results = @()
foreach ($entry in $vmhost) 
{
  $DisplayName = $entry.name
  $VErsion = $entry.Version
  $VMHost = get-vmhost $DisplayName | select Version,Build
  $SLP=(Get-vmhostservice -VMHost $DisplayName | where {$_.label -eq "CIM Server"})

  $result = [PSCustomObject]@{
    DisplayName = $DisplayName
    Version = $VErsion
    Build = $VMHost.Build
    SLP_Key = $SLP.Key
    SLP_Label = $SLP.Label
    SLP_Policy = $SLP.Policy
    SLP_Running = $SLP.Running
    SLP_Required = $SLP.Required
    SLP_VMHost = $SLP.VMHost
    
    Service_Status =if ($SLP.running -eq $true)
        { 
        $SLP | stop-VMHostService -Confirm:$false  > $null
        $SLP |  Set-VMHostService -Policy off > $null
       echo "NOK Service Running GO==> STOP and DISABLED SERVICE "
        }
        elseif ($SLP.Policy -eq "on")
                {
                $SLP |  Set-VMHostService -Policy off > $null
                echo "NOK Service Not Running But policy ON GO ==> SET policy off" 
                
                }
        else 
        {
        echo "OK ALL SERVICE STOPPED"

        }
       
    }
 $results += $result
  }
 
 
 
# Output results to the console in table format
$results | Format-Table | Out-Host

# Export results to a CSV file
$results | Export-Csv -Path $pathCSV -NoTypeInformation

Résultat du SCRIPT

Si le script retourner une erreur de timeout, réexécuter le, également pour vérifier le status

Relancer le script afin d’être dans le VERT

OVHcloud a déclaré le 3 février : « Une vague d’attaques vise actuellement les serveurs ESXi. Aucun service managé OVHcloud n’est impacté par cette attaque cependant, comme beaucoup de clients utilisent ce système d’exploitation sur leurs propres serveurs, nous fournissons ce post comme référence en support pour les aider dans leur remédiation.

“Pour les clients Bare Metal utilisant ESXi, nous recommandons fortement en cas d’urgence :

  • pour désactiver le service OpenSLP sur le serveur ou pour restreindre l’accès aux seules adresses IP de confiance ( https://kb.vmware.com/s/article/76372 )
  • pour mettre à jour votre ESXi avec le dernier correctif de sécurité

« Dans un second temps, assurez-vous :

  • vos données sont sauvegardées
  • seuls les services nécessaires sont actifs et filtrés avec ACL sur une adresse IP de confiance uniquement
  • surveiller votre système pour tout comportement anormal.

« Nos clients utilisant VMware Private Cloud ne sont pas impactés. De par sa conception, la passerelle SSL empêche cette typologie d’attaque en bloquant l’accès externe à ce port (OpenSLP 427) », a ajouté le fournisseur de cloud.