En août dernier, nous avions écrit à propos d’un correctif de sécurité pour routeur Mikrotik, qui avait fait l’objet d’une ingénierie inverse et avait été transformé en exploit.
En effet, les correctifs qui corrigent des vulnérabilités de sécurité finissent souvent par donner assez de précisions sur la vulnérabilité pour que des personnes, bien ou mal intentionnées, puissent l’utiliser en partant de ses principes de base, le tout sans avoir à connaitre précisément la vulnérabilité au départ.
Dans le cas du mois d’août 2018, dénommé CVE-2018-14847, un cybercriminel pouvait duper un routeur Microtik non patché afin qu’il fournisse le contenu de n’importe quel fichier de l’équipement en question, y compris le fichier de mot de passe.
Pire encore, le fichier de mot de passe incluait des mots de passe en clair, sans salage, hachage ni stretching, signifiant ainsi qu’un bug de contournement au niveau de la sécurité pouvait mettre en danger des identifiants.
Cependant, contrairement à l’exploit “zero-day” tant redouté, qui fait son apparition avant qu’un patch ne soit disponible, laissant donc “zéro” jour pour prendre une petite longueur d’avance, un exploit qui apparaît uniquement à cause d’un patch est, du moins en théorie, facilement évitable.
Si vous avez patché rapidement votre routeur Mikrotik, la preuve de concept du type “mais où avais-je donc la tête” concernant l’exploit en question, imaginé par des chercheurs connus sous les noms @n0p et @yalpanian, aurait été sans danger pour votre appareil.
Les dangers de la correction tardive
Ce que nous ne savions pas à l’époque, c’est que les chercheurs en sécurité de Tenable avaient divulgué de manière responsable un autre ensemble de bugs au niveau du routeur Mikrotik à peu près au même moment.
Ces bugs étaient sérieux : l’un d’entre eux permettait en effet à un attaquant de lancer le programme de son choix, en envoyant simplement une requête web au routeur.
Ce type de faille est appelé, pour des raisons plutôt évidentes, RCE (abréviation de Remote Code Execution).
Les bugs de Tenable, cependant, étaient ce qu’on appelle des “vulnérabilités authentifiées”, signifiant ainsi que vous deviez être connecté, au départ, pour pouvoir les exploiter.
Les failles de sécurité qui requièrent une pré-authentification peuvent sembler anodines à première vue, après tout, si vous avez déjà un nom d’utilisateur et un mot de passe, ou un jeton d’accès qui vous donne un accès au système …
… alors, vous êtes déjà dedans, donc tenter de pénétrer à nouveau semble être plutôt inapproprié !
Mais même les vulnérabilités réservées aux utilisateurs authentifiés peuvent être très sérieuses, et ce pour les raisons suivantes :
- Elles peuvent souvent être utilisées pour obtenir une élévation de privilèges, transformant des comptes de faible niveau, en lecture seule ou de type invité, en comptes de type super-utilisateur ou administrateur, avec les pleins pouvoirs.
- Elles peuvent souvent être associées avec des vulnérabilités non authentifiées pour obtenir cet accès de faible niveau, en lecture seule ou en tant qu’invité.
La bonne nouvelle est que Mikrotik a déjà corrigé les bugs maintenant divulgués par Tenable, appelés CVE-2018-1156, -1157, -1158 et -1159.
Assurez-vous de disposer des dernières mises à jour du firmware Mikrotik, qui sont : 6.40.9, 6.42.7 ou 6.43, selon que vous utilisez la version actuelle, antérieure ou celle encore antérieure à cette dernière.
Si vous êtes un utilisateur de Mikrotik, le fait d’omettre le dernier correctif vous expose à des risques, mais si vous n’installez toujours pas le correctif précédent, vous êtes doublement en danger !
Avec les deux correctifs manquants, vous êtes exposé à un bug de divulgation de mot de passe non authentifié qui pourrait ensuite être associé au bug d’exécution de code à distance authentifié.
En d’autres termes, au lieu de permettre à quiconque d’obtenir un accès ou à certaines personnes seulement d’obtenir un accès complet, nous nous retrouvons dans une configuration où tout le monde pourrait obtenir un accès complet en faisant pivoter CVE-2018-14847 vers CVE-2018-1156, la faille RCE !
Un rappel aux programmeurs
A propos, la faille RCE trouvée par Tenable impliquait l’utilisation abusive d’une fonction C appelée sprintf(), prononcée par ESS-PRINT-EFF et l’abréviation de “Formatted PRINT into a String”.
Le mot string est le jargon utilisé pour désigner un tampon de mémoire utilisé pour stocker du texte, tel que des invites, des messages log, des noms d’utilisateur, des descriptions d’erreur, etc.
Le problème avec sprintf() est qu’il suppose que la mémoire tampon, dans laquelle vous écrivez, dispose de suffisamment d’espace pour le message que la fonction va créer.
Considérons un fragment de C comme ceci :
char *name; // Une mémoire tampon qui contient déjà la variable "name", par exemple "DUCK" char buff[16]; // De l'espace mémoire réservé pour le message contenant "name" sprintf(buff, "Hello %s", name);
Cette séquence prend la chaîne de texte référencée par la variable name et l’insère au point désigné par les caractères marqueurs spéciaux %s dans la deuxième chaîne (d’autres marqueurs, tels que %d et %f, peuvent être utilisés pour obtenir de parfaits nombres entiers [integer Digits numbers] et nombres en virgule flottante [Floating point number], également appelés décimaux).
Vous pouvez voir ici le problème : seuls 16 caractères sont alloués à buff. Ainsi, quiconque insère un nom de plus de neuf caractères fera déborder la mémoire tampon.
NB : Comptez cinq caractères pour Hello, plus un espace, plus neuf caractères pour name, plus l’octet zéro (le caractère ASCII NUL) que C ajoute automatiquement pour indiquer la fin d’une chaîne, et vous disposez de 16 octets. C’est déjà suffisant pour remplir la mémoire tampon de 16 octets. Par conséquent, si la variable name contient plus de neuf caractères, un dépassement de mémoire est provoqué.
Si vous êtes un programmeur C, vous ne devriez plus utiliser sprintf(), utilisez uniquement des fonctions string qui vous permettent de spécifier un nombre maximal d’octets à copier.
Ces fonctions ont généralement, à un endroit dans leur nom, un -n-, un raccourci pour “copier au moins N octets même s’il reste des caractères non copiés ou non imprimés”, ou un -l- qui signifie “Limiter la Longueur de la chaîne résultante”.
Par exemple :
char *name; // Une mémoire tampon qui contient déjà la variable "name", par exemple "DUCK" char buff[16]; // De l'espace mémoire réservé pour le message contenant "name" snprintf(buff, sizeof buff, "Hello %s",name)
L’opérateur C, sizeof, répond à vos attentes et détermine automatiquement la quantité d’espace mémoire disponible dans buff.
NB : La fonction snprintf() ci-dessus copie au maximum (sizeof buff)-1 octets dans buff, en gardant toujours un octet à la fin, où elle place le caractère NUL qui termine la chaîne, de sorte que vous ne vous retrouvez jamais avec du texte non terminé. Dans le cas particulier où la taille donnée à snprintf() est zéro, aucun octet n’est écrit dans buff, la fonction ne fait tout simplement rien.
En passant, même si vous pouvez contrôler la quantité de données copiées, et ainsi éviter les débordements de mémoire tampon, utiliser des fonctions de “comptage de chaînes” telles que snprintf() ne constitue pas une sécurité suffisante.
Comme le disent les pages du manuel Unix :
La chaîne tronquée peut être un problème de sécurité […] La chaîne tronquée ne sera pas aussi longue que l’originale, [ainsi] elle peut faire référence à une ressource complètement différente et l’utilisation de cette ressource tronquée peut entraîner un comportement réellement incorrect.
S’en remettre aveuglément à un nom de fichier à partir duquel l’extension a été définie, par exemple, pourrait avoir toutes sortes de conséquences inattendues.
Vérifiez toujours les opérations de chaîne incorrectes ou incomplètes et faites de votre mieux pour éviter les dépassements de mémoire tampon.
Il n’est pas utile de supprimer un bug si vous en introduisez un autre !
Quoi faire ?
- Patchez tôt, patchez souvent. Un patch manquant est dangereux, deux correctifs manquants sont bien pires encore et risquent de transformer deux vulnérabilités à risque limité en une faille de sécurité combinée, offrant ainsi aux cybercriminels un exploit tout-puissant et sans limite.
- N’utilisez pas de fonctions C connues comme mauvaises dans votre code. La plupart des compilateurs C vous préviendront des fonctions dangereuses et dépréciées lorsque vous construirez votre programme : tenez compte de leurs conseils !
Billet inspiré de Unpatched routers bad, doubly unpatched routers worse – much, much worse!, sur Sophos nakedsecurity.
