- Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
Depuis sa création en 2008, l'utilisation du framework [Symfony](https://symfony.com) a été de plus en plus utilisée dans les applications basées sur PHP. Il est maintenant un composant central de nombreux CMS bien connus, tels que [Drupal](https://www.drupal.org), [Joomla!](https://www.joomla.org), [eZPlatform](https://ezplatform.com) (anciennement eZPublish) ou [Bolt](https://bolt.cm), et est souvent utilisé pour construire des sites web personnalisés.
L'une des fonctionnalités intégrées de Symfony, conçue pour gérer les [ESI (Edge-Side Includes)](https://en.wikipedia.org/wiki/Edge\_Side\_Includes), est la classe [`FragmentListener`](https://github.com/symfony/symfony/blob/5.1/src/Symfony/Component/HttpKernel/EventListener/FragmentListener.php). Essentiellement, lorsqu'une personne émet une demande à `/_fragment`, cet auditeur définit les attributs de la demande à partir des paramètres GET donnés. Comme cela permet d'exécuter du code PHP arbitraire (_plus d'informations à ce sujet plus tard_), la demande doit être signée à l'aide d'une valeur HMAC. La clé cryptographique secrète de ce HMAC est stockée sous une valeur de configuration Symfony nommée `secret`.
Cette valeur de configuration, `secret`, est également utilisée, par exemple, pour construire des jetons CSRF et des jetons de rappel. Étant donné son importance, cette valeur doit évidemment être très aléatoire.
Malheureusement, nous avons découvert que souvent, le secret a soit une **valeur par défaut**, soit il existe des **moyens d'obtenir la valeur, de la bruteforcer hors ligne, ou de simplement contourner la vérification de sécurité à laquelle elle est associée**. Cela affecte notamment Bolt, eZPlatform et eZPublish.
Bien que cela puisse sembler être un problème de configuration bénin, nous avons constaté que des valeurs par défaut, bruteforçables ou devinables sont **très, très souvent présentes** dans les CMS mentionnés ainsi que dans les applications personnalisées. Cela est principalement dû au fait de ne pas mettre suffisamment l'accent sur son importance dans la documentation ou les guides d'installation.
De plus, un attaquant peut escalader des vulnérabilités moins impactantes pour lire le `secret` (par le biais d'une divulgation de fichier), contourner le processus de signature `/_fragment` (en utilisant un SSRF) et même le divulguer via `phpinfo()` !
Dans ce billet de blog, nous décrirons comment le secret peut être obtenu dans divers CMS et sur le framework de base, et comment obtenir l'exécution de code à l'aide de ce secret.
Étant un framework moderne, Symfony a dû gérer la génération de sous-parties d'une demande depuis sa création jusqu'à nos jours. Avant `/_fragment`, il y avait `/_internal` et `/_proxy`, qui faisaient essentiellement la même chose. Cela a produit de nombreuses vulnérabilités au fil des ans : [CVE-2012-6432](https://symfony.com/blog/security-release-symfony-2-0-20-and-2-1-5-released#cve-2012-6432-code-execution-vulnerability-via-the-internal-routes), [CVE-2014-5245](https://symfony.com/blog/cve-2014-5245-direct-access-of-esi-urls-behind-a-trusted-proxy) et [CVE-2015-4050](https://symfony.com/blog/cve-2015-4050-esi-unauthorized-access), par exemple.
Depuis Symfony 4, le secret est généré à l'installation et la page `/_fragment` est désactivée par défaut. On pourrait donc penser que la conjonction d'avoir à la fois une valeur `secret` faible et `/_fragment` activé serait rare. Ce n'est pas le cas : de nombreux frameworks s'appuient sur d'anciennes versions de Symfony (même la version 2.x est encore très présente), et implémentent soit une valeur `secret` statique, soit la génèrent mal. De plus, de nombreux frameworks s'appuient sur ESI et activent donc la page `/_fragment`. De plus, comme nous le verrons, d'autres vulnérabilités de moindre impact peuvent permettre de récupérer le secret, même s'il a été généré de manière sécurisée.
Nous allons d'abord démontrer comment un attaquant, ayant connaissance de la valeur de configuration `secret`, peut obtenir l'exécution de code. Cela est fait pour la dernière version de `symfony/http-kernel`, mais est similaire pour d'autres versions.
### Utilisation de `/_fragment` pour exécuter du code arbitraire <a href="#using-_fragment-to-run-arbitrary-code" id="using-_fragment-to-run-arbitrary-code"></a>
`FragmentListener:onKernelRequest` sera exécuté à chaque requête : si le chemin de la requête est `/_fragment` \[1], la méthode vérifiera d'abord que la requête est valide (_c.-à-d._ correctement signée), et lèvera une exception sinon \[2]. Si les vérifications de sécurité réussissent, elle analysera le paramètre `_path` encodé en URL et définira les attributs `$request` en conséquence.
Les attributs de requête ne doivent pas être confondus avec les paramètres de requête HTTP : ce sont des valeurs internes, maintenues par Symfony, qui ne peuvent généralement pas être spécifiées par un utilisateur. L'un de ces attributs de requête est `_controller`, qui spécifie quel contrôleur Symfony (un tuple _(classe, méthode)_ ou simplement une _fonction_) doit être appelé. Les attributs dont le nom ne commence pas par `_` sont des arguments qui seront transmis au contrôleur. Par exemple, si nous voulions appeler cette méthode :
Essentiellement, cela permet d'appeler n'importe quelle fonction ou méthode de n'importe quelle classe, avec n'importe quel paramètre. Étant donné la pléthore de classes que Symfony possède, **l'obtention d'une exécution de code est triviale**. Nous pouvons, par exemple, appeler `system()` :
_Appeler system ne fonctionnera pas à chaque fois : reportez-vous à la section Exploitation pour plus de détails sur les subtilités de l'exploitation._
En bref, Symfony extrait le paramètre GET `_hash`, puis reconstruit l'URL complète, par exemple `https://symfony-site.com/_fragment?_path=controller%3d...%26argument1=test%26...`, calcule un HMAC à partir de cette URL en utilisant la `secret` comme clé \[1], et le compare à la valeur de hachage donnée \[2]. S'ils ne correspondent pas, une exception `AccessDeniedHttpException` est levée \[3], ce qui entraîne une erreur `403`.
En vérifiant `http://localhost:8000/_fragment?_hash=lNweS5nNP8QCtMqyqrW8HIl4j9JXIfscGeRm%2FcmFOh8%3D`, nous avons maintenant un code d'état `404`. La signature était correcte, mais nous n'avons spécifié aucun attribut de requête, donc Symfony ne trouve pas notre contrôleur.
Puisque nous pouvons appeler n'importe quelle méthode, avec n'importe quel argument, nous pouvons par exemple choisir `system($command, $return_value)`, et fournir une charge utile comme ceci:
Encore une fois : tout cela n'aurait pas d'importance si les secrets n'étaient pas obtenables. Souvent, ils le sont. Nous décrirons plusieurs façons d'obtenir l'exécution de code sans aucune connaissance préalable.
Sur les versions récentes de Symfony (3.x), `secret` est stocké dans `.env` en tant que `APP_SECRET`. Comme il est ensuite importé en tant que variable d'environnement, ils peuvent être vus via une page `phpinfo()`.
Le code derrière `FragmentListener` a évolué au fil des ans : jusqu'à la version _2.5.3_, lorsque la demande provenait d'un proxy de confiance (c'est-à-dire `localhost`), elle était considérée comme sûre, et donc le hachage ne serait pas vérifié. Un SSRF, par exemple, peut permettre d'exécuter immédiatement du code, indépendamment de la possession de `secret` ou non. Cela affecte notamment eZPublish jusqu'à 2014.7.
Lors de la configuration d'un site web Symfony, la première étape consiste à installer le squelette [symfony-standard](https://github.com/symfony/symfony-standard). Lors de l'installation, une invite demande certaines valeurs de configuration. Par défaut, la clé est `ThisTokenIsNotSoSecretChangeIt`.
[ezPlatform](https://ezplatform.com), le successeur de [ezPublish](https://en.wikipedia.org/wiki/EZ\_Publish), utilise toujours Symfony. Le 10 juin 2019, un [commit](https://github.com/ezsystems/ezplatform/commit/974f2a70d9d0507ba7ca17226693b1a4967f23cf#diff-f579cccc964135c7d644c7b2d3b0d3ecR59) a défini la clé par défaut à `ff6dc61a329dc96652bb092ec58981f7`. Les versions vulnérables vont de 3.0-alpha1 à 3.1.1 (actuelle).
Bien que la [documentation](https://doc.ezplatform.com/en/latest/getting\_started/install\_ez\_platform/#change-installation-parameters) indique que la clé secrète doit être modifiée, cela n'est pas obligatoire.
Comme le squelette de Symfony, une invite vous demandera d'entrer une clé secrète lors de l'installation. La valeur par défaut est `ThisEzPlatformTokenIsNotSoSecret_PleaseChangeIt`.
[Bolt CMS](https://bolt.cm) utilise [Silex](https://github.com/silexphp/Silex), un micro-framework obsolète basé sur Symfony. Il configure la clé secrète en utilisant ce calcul :
Comme le secret est souvent défini manuellement (par opposition à une valeur aléatoire générée), les gens utilisent souvent une phrase secrète au lieu d'une valeur aléatoire sécurisée, ce qui la rend brute-forçable si nous avons un hachage pour la brute-forcer. Évidemment, une URL `/_fragment` valide, telle que celle générée par Symfony, nous fournirait un tuple message-hachage valide pour brute-forcer le secret.
Au début de ce billet de blog, nous avons dit que le secret de Symfony avait plusieurs utilisations. L'une de ces utilisations est qu'il est également utilisé pour générer des jetons CSRF. Une autre utilisation de `secret` est de signer les cookies de rappel. Dans certains cas, un attaquant peut utiliser son propre jeton CSRF ou cookie de rappel pour brute-forcer la valeur de `secret`.
À titre d'exemple de la façon dont les secrets peuvent être brute-forcés afin d'obtenir une exécution de code, nous verrons comment nous pouvons découvrir le secret d'eZPublish 2014.07.
Pour construire ce jeton, eZP utilise deux valeurs que nous connaissons, ainsi que le secret : `getIntention()` est l'action que l'utilisateur tente de réaliser (`authentifier`, par exemple), `session_id()` est l'identifiant de session PHP, et `getSecret()`, eh bien, c'est le `secret` de Symfony.
Malheureusement, ezPublish a incorporé un bundle de sensiolabs, [sensio/distribution-bundle](https://packagist.org/packages/sensio/distribution-bundle). Ce package s'assure que la clé secrète est aléatoire. Il la génère ainsi, lors de l'installation :
Cela semble vraiment difficile à bruteforcer : `mt_rand()` peut produire 231 valeurs différentes, et `uniqid()` est construit à partir de l'horodatage actuel (avec des microsecondes).
Heureusement, nous savons que ce secret est généré à la dernière étape de l'installation, juste après la mise en place du site web. Cela signifie que nous pouvons probablement divulguer l'horodatage utilisé pour générer ce hash.
Une façon de le faire est d'utiliser les journaux (_par exemple_ `/var/log/storage.log`); on peut divulguer la première fois qu'une entrée de cache a été créée. L'entrée de cache est créée juste après l'appel de `generateRandomSecret()`.
Si les journaux ne sont pas disponibles, on peut utiliser le moteur de recherche très puissant d'eZPublish pour trouver l'heure de création du tout premier élément du site web. En effet, lors de la création du site, de nombreux horodatages sont mis dans la base de données. Cela signifie que l'horodatage des données initiales du site eZPublish est le même que celui utilisé pour calculer `uniqid()`. Nous pouvons chercher le _ContentObject_`landing_page` et découvrir son horodatage.
Cela nous laisse un total de 231 \* 106 possibilités. Cela semble faisable avec [hashcat](https://hashcat.net) et un bon ensemble de GPU, mais hashcat ne fournit pas de noyau `sha1(sha1($pass).$salt)`. Heureusement, nous l'avons implémenté ! Vous pouvez trouver [la demande de tirage ici](https://github.com/hashcat/hashcat/pull/2536).
Symfony est maintenant un composant central de nombreuses applications PHP. En tant que tel, tout risque de sécurité qui affecte le framework affecte de nombreux sites web. Comme le démontre cet article, une clé secrète faible ou une vulnérabilité moins importante permet aux attaquants d'obtenir une **exécution de code à distance**.
En tant que membre de l'équipe de sécurité, vous devriez examiner tous vos sites web dépendant de Symfony. Un logiciel à jour ne peut être exclu pour les vulnérabilités, car la clé secrète est générée lors de la première installation du produit. Ainsi, si vous avez créé un site web basé sur Symfony 3.x il y a quelques années et que vous l'avez maintenu à jour tout au long du processus, il y a de fortes chances que la clé secrète soit toujours celle par défaut.
* L'HMAC est calculé en utilisant l'**URL complète**. Si le site web est derrière un proxy inverse, nous devons utiliser l'URL interne du service au lieu de celle à laquelle nous envoyons notre charge utile. Par exemple, l'URL interne pourrait être en HTTP au lieu de HTTPS.
* L'algorithme HMAC a changé au fil des ans : il était **SHA-1** avant, et est maintenant **SHA-256**.
* Comme Symfony supprime le paramètre `_hash` de la requête, puis génère à nouveau l'URL, nous devons calculer le hash sur la même URL qu'elle.
* De nombreux secrets peuvent être utilisés, nous devons donc tous les vérifier.
* Sur certaines versions de PHP, nous ne pouvons pas appeler des fonctions qui ont des paramètres "par référence", comme `system($command, &$return_value)`.
* Sur certaines versions de Symfony, `_controller` ne peut pas être une fonction, il doit s'agir d'une méthode. Nous devons trouver une méthode Symfony qui nous permet d'exécuter du code.
* URL interne : cela pourrait être `https://target.com/_fragment`, ou peut-être `http://target.com/_fragment`, ou quelque chose de complètement différent (_par exemple_ `http://target.website.internal`), que nous ne pouvons pas deviner
* Clé secrète : nous avons une liste de clés secrètes habituelles, telles que `ThisTokenIsNotSoSecretChangeIt`, `ThisEzPlatformTokenIsNotSoSecret_PleaseChangeIt`, etc.
Nous n'avons pas besoin de nous soucier de la charge utile effective (le contenu de `_path`) pour l'instant, car une URL correctement signée ne donnera pas lieu à une `AccessDeniedHttpException`, et ne donnera donc pas lieu à un `403`. L'exploit va donc essayer chaque combinaison `(algorithme, URL, secret)`, générer une URL et vérifier si elle ne renvoie pas un code d'état `403`.
À ce stade, nous pouvons signer n'importe quelle URL `/_fragment`, ce qui signifie qu'il s'agit d'une RCE garantie. Il s'agit simplement de savoir quoi appeler.
Ensuite, nous devons savoir si nous pouvons appeler une fonction directement, ou si nous devons utiliser une méthode de classe. Nous pouvons d'abord essayer la première méthode la plus simple, en utilisant une fonction telle que `phpinfo ([ int $what = INFO_ALL ] )` ([documentation](https://www.php.net/manual/en/function.phpinfo.php)). Le paramètre GET `_path` ressemblerait à cela :
Sinon, cela signifie que nous devrons utiliser une méthode de classe à la place. Un bon candidat pour cela est `Symfony\Component\Yaml\Inline::parse`, qui est une classe Symfony intégrée, et en tant que telle est présente sur les sites Symfony.
Évidemment, cette méthode analyse une chaîne d'entrée YAML. Le parseur YAML de Symfony prend en charge la balise `php/object`, qui convertira une chaîne d'entrée sérialisée en un objet en utilisant `unserialize()`. Cela nous permet d'utiliser notre outil PHP préféré, [PHPGGC](https://github.com/ambionics/phpggc) !
Au lieu de construire `_path` pour chacun de ces éléments, nous pouvons profiter du fait que si nous donnons un argument dont le nom ne correspond pas au prototype de la méthode, il sera ignoré. Nous pouvons donc ajouter tous les arguments possibles à la méthode, sans nous soucier du prototype réel.
L'exploit va donc parcourir toutes les combinaisons de variables possibles, puis essayer les deux méthodes d'exploitation. Le code est disponible sur [notre GitHub](https://github.com/ambionics/symfony-exploits).
Comme vous pouvez le voir sur la capture d'écran ci-dessus, il y a un logo `sf` en bas à droite de la page. Ce logo est affiché lorsque Symfony est en mode débogage. Il y a des cas où ce logo ne s'affiche pas, alors essayez d'accéder à `/_profiler` et vous verrez la page comme indiqué ci-dessous.
Cette fonctionnalité s'appelle Symfony Profiler, et il n'y a pas beaucoup d'informations à ce sujet sur Internet. L'intention de cette fonctionnalité est très claire ; elle vous aide à déboguer lorsqu'il y a une erreur ou un bogue. Bien sûr, cette fonctionnalité ne peut être utilisée que lorsque le mode débogage est activé.
Le framework Symfony lui-même est très sécurisé, mais l'activation du mode débogage rendra ce framework extrêmement vulnérable. Par exemple, Profiler a une fonctionnalité appelée Profile Search, comme le montre la capture d'écran suivante.
Comme vous pouvez le voir sur la capture d'écran ci-dessus, vous pouvez accéder à toutes les demandes envoyées au serveur. En cliquant sur les hachages dans le jeton, vous verrez que tous les paramètres POST peuvent être lus, comme on le voit sur la capture d'écran suivante. Avec cette fonctionnalité, nous pouvons pirater les identifiants du compte de l'administrateur et de l'utilisateur.
- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
