Dyrk

Bonjour à tous,

J'espère qu'avec le retour du soleil vous retrouvez la joie d'aller travailler, ou ... de me lire sous une ombrelle en terrasse !

Un peu de légèreté aujourd'hui, sur un sujet qui n'est pas non plus tout neuf, mais qui pourrait très certainement être une découverte pour une partie d'entre vous, et un complément d'informations sur ce sujet pour d'autres.

Les WAF

Tout d'abord redéfinissons ce qu'est un WAF (Web Application Firewall). Il s'agit là d'une sorte de solution anti-virus plutôt destiné à protéger un serveur Web, de cybers attaques.

Il peut par exemple apporter une protection contre les attaques de deny de service, lorsque des personnes malveillantes utilisent une armée de machine pour bourriner votre serveur.
Ce dernier va détecter un comportement anormal, avec des machines qui font des requêtes trop rapprochées en temps, et automatiquement les bloquer.

Autre exemple, il va détecter certains motifs dans des urls :"https://siteinternet.com/article?id=1 UNION SELECT ...." (ci-contre une injection sql).
Dès lors qu'il identifiera ce motif dans une requête, il appliquera soit un blocage immédiat, soit un blocage au bout de (n) requêtes contenant ce type de motif.

Configuration réseau

Au delà de l'utilisation d'un WAF, un serveur peut également créer des configurations particulières pour "sécuriser" son serveur WEB.
En autorisant, ou bien en interdisant des connexions sur ledit serveur, et de façon encore plus "granulaire", en créant des règles liés à des arborescences.
Toujours dans l'univers des beaux exemples, nous pourrions imaginer que vous disposez d'un site internet, avec une administration.

Par principe de sécurité, pour éviter qu'une personne mal intentionnée ne puisse compromettre ton site internet via cette administration, tu as la possibilité d'interdire ou d'autoriser de se connecter sur ton administration depuis telle ou telle adresse IP.
Ce genre de situation est relativement fréquente en entreprise, pour n'autoriser que les utilisateurs connecté sur le réseau de l'entreprise à accéder à certaines ressources  sensibles.

Web & Encodage des caractères

Dans la vie il y a les caractères alphanumériques, et les caractères spéciaux de bases liés à la ponctuation que tout le monde connait...

Qu'on pourrait résumer ainsi :

• Minuscule : a, b, c .... z
• Majuscule : A, B, C .... Z
• Numérique : 0, 1,2, 3, .... 9
• Spéciaux : . : // , ; & ? # ! () [] @ - _ %

Et le reste ... ceux qui sont vraiment très très spéciaux, tellement spéciaux qu'ils peuvent rapidement ...
En passant de ton navigateur ...
En transitant par le réseau ... 
En arrivant sur une machine (WAF, Load Balancer, API Manager, ... autant de machine pouvant disposer de configurations  et d'encodages différents)

En étant redirigé à nouveau sur une autre machine qui à son tour, va .... 

Bref tu comprends cette mécanique sans fin... pour finir par arriver sur le serveur cible en ayant traversé de larges contrées sauvages et affrontés les sauvag.... les problèmes d'encodage.
Pour finir avec une bouillie ressemblant à cela : 

Pour les personnes de culture francophone:
Je pense qu'on pourrait ici utiliser l'expression "téléphone arabe", le principe étant que plus le message est compliqué et plus le nombre de personne relais le message est important, plus la chance d'avoir le conserver message diminue.

Pour palier aux différents types de caractères qui existent et qui sont pris en charge, la plupart des requêtes WEB vont appliquer  ce qu'on appelle de l'url encode  (On prends tous les caractères non alphanumérique + quelques caractères spéciaux, et on les envois converti en hexadécimale et préfixé par un '%')

Ainsi, on peut transmettre des caractères basiques sans risque de problème d'encodage entre ce qui est est échangé de l'utilisateur au serveur (et inversement).

Le serveur recevra les données encodées et pourra très facilement les décoder.

Règles & Motifs

Le dénominateur commun des 2 rubriques précédentes c'est l'application de "règles".
L'inscription dans le marbre d'un ensemble d'instructions strictes à respecter.
Celles-ci sont soient définie par défaut ... soit personnalisées en fonction de vos besoins.
Dans tous les cas, que ça soit la détection d'un motif d'attaque comme l'énumération de ressources sensibles :

• .git
• .SVN
• .CVS
• .DS_Store
• dump.sql
• .... etc ....

Que ce soit les restrictions d'accès pour certains espaces sécurisés (backoffice, intranet, ....).

Chacun de ces motifs, saisi par défaut ou manuellement est donc renseigné dans un fichier de configuration.

Il faut donc être très vigilants sur la façon dont sont renseignés ces "motifs".

Par exemple, selon le type de serveur, il existe ou non une sensibilité la casse ... 
Linux est sensible à la casse, vous pouvez avoir dans un même dossier, des fichiers ou des dossiers ayant un même nom mais avec des différences sur les majuscules  et les minuscule.

Mais pour un serveur Windows un nom de répertoire, il n'y a pas de sensibilité à la casse : "dossier" est pareil que "DoSsier", qui est pareil que "DossIER", ...
Si vous êtes sur Windows, il est très simple de vérifier cette théorie, amusez vous à créer, côte à côte, des dossiers portant le même nom, mais en alternant sur chacun des minuscules et des majuscules (Spoiler : vous ne réussirez pas).

Ainsi, dans ce dernier cas, interdire l'accès à "admin" en mettant un filtre sur le mot "admin", ne signifie pas pour autant une interdiction  de l'utilisation de "Admin".
Il faut être vraiment très précis.

Ci-dessous un exemple avec une regex qui va détecter de façon précise et sensible à la casse, le terme "admin".

Dans un cas l'expression "admin" est détectée, et pourrait donc être "bloqué" ... 
Mais lorsque je remplace "admin" par "Admin", ce n'est plus detecté.

Ci-dessous, je précise que je souhaite que le mot "admin" soit détecté peut importe s'il contient ou nom des lettres en majuscule ou en minuscule (le /i est là pour dire que ça ne doit pas être sensible à la casse).

Encodage de caractère ET contournement des filtres

Comme je le disais plus haut :
Afin d'éviter certains problèmes d'encodage des caractères, tout ce qui n'est pas alphanumérique et certains caractères spéciaux ... est automatiquement convertie (dans la requête) en valeurs hexadécimale ...

"Attr@p€M0iSiTÜPeux" : "Attr@p%E2%82%ACM0iSiT%C3%9CPeux"

Sauf QUE :

Le serveur ne sera pas discriminant, il est parfaitement possible de convertir également des caractères alphanumériques en hexa.

Les fonctions de conversion "automatique" ne le feront pas ...

Mais rien ne vous interdit de le faire vous même : 

"admin".split('').map(c=>'%'.concat(c.charCodeAt(0).toString(16))).join('')

Code JS à exécuter dans la console de votre navigateur.

De même qu'il est également "possible" de faire un "DOUBLE" encodage .... 
Grosso merdo, vous remplacez, tous les "%" en "%25".

Votre serveur est normalement capable de faire la conversion automatiquement à la volée.

Une règle de sécurité visant à détecter ET prévenir l'accès à l'arborescence : /admin/
Même en imaginant qu'elle gère la "casse" ...
Ne filtrerait pas les conversions hexa ... (il vous faut donc penser à gérer ces cas là).Un mauvais "filtrage" encore trop fréquent

Clairement j'ai pu le constater en milieu pro, j'ai également pu le voir au sein d'autres administrations.

Dernièrement dans un CHU ...

En consultant le /robots.txt (un fichier qui est là pour dire aux moteurs de recherche ce que l'on souhaite qu'ils références ou pas).
On constate la présence ... d'un répertoire "administrateur" ...

Hop déjà un mauvais point ... le robots.txt est un fichier publique, donc accessible à tous qui n'est là que pour fournir une information aux différents moteurs de recherche.

Ce n'est pas un fichier "sécurisé" ... ne mettez jamais d'informations sensibles à l'intérieur ... 
Le répertoire administrateur, aurait, quant à lui, pu être directement protégé d'un référencement par une configuration (Apage, NGinx, ou tout autre serveur d'application utilisé).

Bref, je sens que vous êtes motivés pour aller encore plus loin, on essaye d'accéder au répertoire ?

Oh mince ! C'est bloqué ....

Mais .... tiens tiens, peut-être bien qu'après mes explications ... vous vous dites qu'il existe une règle de filtrage sur le terme "adminsite" ... et que si j'y applique ma technique hexadécimale, sur un, plusieurs, voir tous les caractères peut-être pourrais je contourner ce blocage ?

Eh bien oui !!!

Conclusion

Lorsque vous mettez en place des solutions de filtrage ... pensez à plusieurs choses.
Certains systèmes sont tolérants à la casse ... tenez en compte pour éviter des tentatives d'accès simplement en jouant sur les majuscules, minuscules.

L'encodage d'URL doit également être prévu dans vos règles de filtrage ...
Cet article ne cible pas un WAF plutôt qu'un autre, je ne peux donc m'étendre davantage sur les possibilités / réglages qui existent, et sont offertes par chacun, mais gardez en tête les contournements possibles lié à l'encodage.

Et enfin ... n'oubliez pas que le robots.txt ne présent pas de garantie de sécurité .... 

Pas plus qu'un panneau indiquant à des piétons qu'une voie est privée.