Vulnérabilitées Next Cloud Server 19+

Vulnérabilitées Next Cloud Server 19+

À ce jour - 02/12/2020 - 7 CVE de divers niveaux de sévérités touchent Next Cloud Server 19 et plus.

Regardons-les une par une.

CVE-2020-8259 - Protection Insuffisante des clés de chiffrement coté serveur

Lien CVE
Fixed in Next Cloud 20

  • Sévérité: haute selon HackerOne (7,4)

Il n’y a pas de vérification de l’intégrité des clés de chiffrement coté serveur, n’importe qui possédant un accès aux fichiers stockés sur le serveur peut les substituer par de nouvelles clés. Tous les fichiers créés ou modifiés après cette substitution seront donc lisibles par l’attaquant.

Mitigation: Un fix est présent à partir de la version 20. La mitigation consiste à stocker un objet JSON chiffré contenant la clé et un UID qui lui est associé en base de données. Cela permet ensuite de comparer cet objet à la clé stockée en dur pour s’assurer de son intégrité.

Cette faille permet, par exemple, à un fournisseur de serveurs de stockage de lire des fichiers chiffrés dans ses infrastructures, une bonne raison de stocker ses données à la maison.

CVE-2020-8152 - Protection insuffisante des clés de chiffrement coté serveur

Lien CVE
Fixed in Next Cloud 20

  • Sévérité: medium selon HackerOne (5,3)

Très similaire à la CVE-2020-8259 décrite ci-dessus, le soucis ne vient pas de l’intégrité des clés mais de leur confidentialité.
Les clés publiques sont lisibles en cas d’accès aux fichiers présents sur le serveur, le serveur étant incapable de différencier une clé chiffrée par lui-même ou par un tiers, il est possible de:

  • Chiffrer une clé avec toutes les clés publiques en clair sur le serveur
  • Remplacer la clé présente sur le serveur par celle de l’attaquant
  • Créer un fichier de taille identique à celui que l’on souhaite remplacer
  • Signer ce fichier avec la nouvelle clé
  • Remplacer le fichier sur le serveur

On pourra donc par exemple remplacer un fichier exécutable par du code malicieux.

Mitigation: Identique à la CVE-2020-8259

CVE-2020-8236 - Le PIN pour l’authentification web sans mot de passe est demandé mais n’est pas vérifié

Lien CVE
Fixed in 19.0.2

  • Sévérité: medium selon HackerOne (4,3)

Next Cloud Server propose une solution d’authentification sans mots de passe avec une clé FIDO2 qui contient les informations d’authentification. Pendant la configuration de ce service la création d’un PIN est proposée, cependant ce PIN n’est jamais vérifié.

Mitigation: L’authentification avec clé physique n’est pas pour l’instant un remplacement pour le 2FA, en attendant cette feature Next Cloud Server déconseille l’utilisation de l’authentification sans mots de passe et sans 2FA.

CVE-2020-8223 - Le partage d’un fichier en lecture seule permet d’augmenter ses privilèges

Lien CVE
Fixed in 19.0.1

  • Sévérité: medium selon HackerOne (5,5)

Le repartage d’un fichier en lecture seule permet d’autoriser l’écriture.
Par exemple, un utilisateur A partage un fichier en lecture seule avec un utilisateur B, les droits sont bien appliqués: B ne peut pas modifier le fichier. En revanche, B peut repartager le fichier avec un utilisateur C avec les droits en écriture.

Mitigation: Les permissions pour un repartage ont pour maximum les droits de l’utilisateur qui effectue le repartage et non celui de l’utilisateur initial.

CVE-2020-8183 - Mot de passe en clair dans la base de donnée

Lien CVE
Fixed in 19.0.1

  • Sévérité: basse selon HackerOne

Le mot de passe d’un dossier partagé est stocké non hashé dans la base de donnée s’il est fourni à la création du dossier et qu’il n’est pas autogénéré.

Mitigation: Pas de PR associée mais noté comme réglé.

CVE-2020-8150 - Possibilité de rétrograder le niveau de chiffrement afin de briser l’intégrité des fichiers chiffrés

Lien CVE
Fixed in 19.0.2

  • Sévérité: medium selon HackerOne (5,3)

Le mode d’opération de chiffrement à été modifié vers un mode CFB avec signature, cependant une option de rétrocompatibilité est disponible pour les fichiers antérieurs en CTR.
En enlevant la signature et en changeant l’en-tête d’un fichier CFB vers celle d’un fichier CTR, on peut faire déchiffrer les 16 premiers octets du fichier par le serveur. Cela est possible car la première passe est identique en CFB et CTR.
Si l’on connait ces 16 octets on peut donc effectuer une attaque cryptographique à texte clair connu. On peut facilement deviner ces 16 octets pour les fichiers avec un shebang (bash, python) ou en déduisant le header d’un fichier ELF. Cette attaque permet donc de récupérer la clé de chiffrement et de, par exemple, remplacer le fichier par du code malicieux.

Mitigation: La mitigation se fait en plusieurs étapes.

  • Le mode de rétrocompatibilité est désactivé par défaut pour les installations récentes.
  • Un scanner sera lancé sur les installations plus anciennes, si aucun fichier est en chiffrement non signé, le mode de rétrocompatibilité sera désactivé.
  • Itérer sur l’intégralité des fichiers dans l’ancien mode de chiffrement et les rechiffrer avec signature, puis désactiver le mode de rétrocompatibilité.

CVE-2020-8133 - Possibilité de modifier des blocs d’un ficher sans briser la signature

Lien CVE
Fixed in 19.0.2

  • Sévérité: low selon HackerOne (1,8)

Il n’y a pas, dans la signature d’un bloc, de séparation entre le numéro de version et l’index du bloc. Par exemple, la version 1 du bloc 10 aura 110 dans sa signature et la version 11 du block 0 aura aussi 110. Cela permet de modifier un fichier sans invalider la signature.

Il est donc possible de remplacer certains blocs d’un ficher avec des blocs d’une version précédente. Cela permet, à condition de pouvoir lire et écrire sur le serveur, de corrompre des fichiers chiffrés.

Mitigation: Rajouter un ‘_’ entre la version et l’index du bloc dans la signature.
Fix présent de la version 17 à la version 20

Wazuh

Reste à voir si Wazuh détecte ces CVE.

1 Like

This is very informative, thank you :slight_smile: It would be great if you could add, next to the CVE link, the Nextcloud version in which the CVE is fixed. For instance CVE-2020-8223 is fixed in Nextcloud >= 19.0.1

And indeed, the next step would be to verify that Wazuh successfully verifies the presence of a vulnerability. It can however only do so if provided with a reproducer. Do any of the vulnerabilities above include such a program ? If the code in question requires modifications to the Nextcloud server, it would not be advisable to run it in production :scream: However it can be run in a test environment and this can be done in an automated way with Enough.

1 Like