The Web under @Hack

0x0ff | 16 February 2014 | Verbose | 3 Comments

Maman disait toujours, « Le Web, c’est comme une tranche d’emmental : plus il y a de fromage, plus il y a de trous et plus il y a de trous, moins il y a de fromage. »

Bien qu’il ait été démontré que mettre la charrue avant les bœufs n’était pas la meilleur solution pour labourer un champ, et que vendre la peau de l’ourse avant de l’avoir tué était un excellent moyen de se faire molester par un ursidé taciturne, puis par un acheteur insatisfait, il est un trait de caractère que l’on retrouve chez nombre d’aspirants dans toutes les disciplines du monde, l’improductive impatience.

Alors je vous entends déjà dire “Oh encore un de ces cons qui va nous expliquer qu’avant d’apprendre la sécurité informatique, il faudrait peut-être étudier à fond les protocoles, les systèmes, les langages de programmation, le réseau, et j’en passe…”. Je vous rassure, ici point de croisés en guerre contre les méchants scripts kiddies et autres newbies de l’InfoSec, 0x0ff.info c’est pas la Manif pour tous après tout, on est entre gens civilisés.

Non, je vous propose une alternative. Voici une petite synthèse des fondamentaux à intégrer pour saisir toute la subtilité de ce mot qui fait flipper grave : (WEB) HACKING ! – gros, gras, peur, brrrr… Je suis le monstre ! Grrr ! haaaa ! Courrez petits enfants innocents ! COURREZ !

Tout d’abord, un site c’est quoi ?

Un site est le contenu accessible à une adresse, lorsque l’on interroge un serveur avec le protocole HTTP ou HTTPS sur les ports adéquats.

Analysons maintenant cette affirmation péremptoire.

Une ressource

Pour vulgariser une ressource web est un fichier. Un type de fichier peut être ouvert par une application particulière. Lorsque votre navigateur connait l’extension du fichier (html, php, asp, etc…), il l’ouvre pour que vous puissiez le consulter. Lorsqu’il ne comprend pas le type de fichier, il vous propose de le télécharger (Par exemple une archive .zip). Lorsque votre navigateur tombe sur un format de fichier qu’il connaît, il cherche dans son contenu les objets liés à cette ressource puis les récupère. Ces objets sont généralement cosmétiques, images présentes sur la page et feuilles de style par exemple.

Une adresse

Cette information est dans certain cas une adresse IP, plus généralement c’est un nom de domaine. Pour comprendre la relation qu’il existe entre une adresse IP et un nom de domaine, référez vous à la parole à dieu Wikipedia : c’est quoi un DNS ?

Un protocole

En vrai aujourd’hui, le web c’est plein de protocoles qui sont utilisés dans plein de contextes différents (FTP, RPC x ou y, HTTP (S)…), mais faisons l’impasse sur tout autres protocole que HTTP(S). Le protocole HTTP, comme tous les protocoles est défini par un ensemble de règles que vous pouvez trouver dans les documents officiels RFC1945 pour la version 1.0 du protocole HTTP et RFC2616 pour la version 1.1. Ces règles permettent de comprendre et d’être compris, lorsque elles sont respectées la communication entre les deux parties est limpide et sans ambiguïté.

Un port

Si l’IP (ou le nom de domaine) correspond à l’adresse d’un serveur, le port correspond à l’adresse d’un service. La comparaison classique est de voir une adresse IP comme l’adresse d’un immeuble et de voir le numéro de port comme le numéro de porte de la personne à qui vous rendez visite. Traditionnellement le port 80 est utilisé pour communiquer en HTTP et 443 pour communiquer en HTTPS, mais rien de gravé dans le marbre.

Un site interactif c’est quoi ?

En fonction de ce que je suis et de ce que je lui demande, le site me fournis des informations différentes.

Soit deux notions complémentaires.

Ce que je suis

Qui suis-je sur internet ? Et bien sur internet ce qui identifie une connexion est le tuple adresse IP source+Adresse IP destination+Port source+Port destination, changez un élément et ce n’est plus la même connexion. Je suis donc ceci.

Pour une application, un utilisateur est représenté sous la forme d’un token de session que le client fournit à chaque requête, via les cookies ou via un paramètre. Je suis donc aussi cela.

Ce que je demande

Si l’on reste cantonné au protocole HTTP(S), mes petites exigences seront exprimées au travers ce que l’on appelle les paramètres. Sur un site interactif, les pages envoyées au client sont construites en fonction des demandes que l’utilisateur exprime. Par exemple je peux demander une page avec un paramètre GET page, ce qui donnerait http://www.monsiteweb.com/index.php?page=90. La page demandé est en réalité index.php, pourtant son contenu diffère en fonction de la valeur contenue dans la variable page.

C’est quoi ma relation avec le site ?

Il faudrait que je descende les couches du modèle OSI puis que je les remonte pour définir parfaitement la relation qu’un utilisateur entretient avec un serveur, soit 13 étapes rien que ça. Pardonnez au pauvre bougre que je suis de faire entorse à la tradition, nous utiliserons modestement un modèle de mon cru, plus adapté à la démonstration, le modèle 0x0ff.

Attention, les exemples de vulnérabilités donnés à chaque couche du modèle 0x0ff ne constituent pas une liste exhaustive.

L’utilisateur c’est vous derrière votre PC en train de surfer sur un site en vous grattant les… Hum, bref… C’est aussi l’information de session que vous possédez (cookie ou token de session passé via un paramètre).

L’utilisateur est sensible au phishing, social engineering, shoulder surfing.

Le navigateur est le programme qui vous permet d’interpréter les requêtes émisent par le serveur que vous recevez. C’est également le logiciel avec lequel vous “ouvrez” les fichiers Web qui portent les extensions html, php, asp, etc…

Le navigateur est sensible aux attaques visant les plugins non mis à jour (genre Java), aux failles XSS et plus généralement à toutes les attaques imputables à un bout de code interprété (attaques web locales) ou au format de la requête HTTP reçue (attaque du protocole).

Une fois n’est pas coutume, vulgarisons un peu. Le réseau c’est toute l’infrastructure entre votre carte ethernet jusqu’à celle du serveur (y compris les drivers et fonctions de votre système permettant d’utiliser ce matériel).

Le réseau est sensible aux attaques de type IP spoofing, MITM, attaque WIFI, etc…

Le serveur Web est le service qui interpréte les requêtes HTTP(S) émisent par les clients. J’inclue dans ma définition d’un serveur web l’interpréteur utilisé pour générer les pages du site. C’est également le programme qui porte l’application, et le seul de la chaîne que je suis en train de vous présenter à véritablement lire les fichiers portant les extensions que j’ai cité plus tôt : php, asp, mais aussi py, pl, c, et toutes extensions correspondant à un langage que le serveur est capable de comprendre (généralement grâce à l’ajout de modules). Le serveur envoie son interprétation au client ayant accédé à la ressource en question. Vous l’aurez compris, ce que le client prend pour un fichier php n’est en vérité qu’un simple fichier texte affublé d’un sufixe un peu pompeux. – Haha page web noob, .txt va !

Le serveur Web est vulnérable aux attaques utilisant des requêtes mal formatées, ou aux attaques exploitant une mauvaise configuration du serveur (toutes méthodes autorisés, .htaccess mal placé, authentification basique, etc…) et à une mauvaise attribution des droits d’accès aux fichier.

L’application est définie par son code écrit dans des fichiers portant les extensions que j’ai déjà listé trois fois.

L’application est sensible à toutes les attaques exploitant ses points d’entrée de façon non prévue. Mais nous verons tout ça un peu plus loin…

Les satellites sont tous les services tiers nécessaires au bon fonctionnement de l’application, une base de donnée par exemple.

La transversalité des attaques est la raison pour laquelle les satellites sont vulnérables (car finalement seul l’application dialogue avec eux, ce qui ne devrait pas poser de problème de sécurité sauf si vous employez des développeurs maso… Ou très très très mauvais). Vous connaissez sans doute très bien les vulnérabilités SQL. Et bien en vérité, une attaque SQL exploite moins une faille de la base de données qu’une faille de l’application autorisant l’utilisateur à réaliser cette attaque. Sur le même principe, une faille de type LFI visant à récupérer le fichier /etc/shadow, exploite autant une faille dans l’application qu’une mauvaise configuration du serveur et de son cloisonnement.

Juste comme ça

Il est assez marrant de constater que chaque maillon de la chaîne est sensible au DoS de manières différentes… Mais je vous laisse imaginer ce que pourrait être l’attaque dans chacun des cas.

Tu parlais de points d’entrée, tu m’expliques ?

Les points d’entrée d’une application sont toutes les variables que peut définir l’utilisateur et qui sont lus par le serveur.

Nous avons donc identifié quelques-uns de ces points d’entrée depuis le début de ce dossier : les paramètres GET et POST et les cookies. Mais en existe-t-il d’autres ?

La réponse est oui. Tous les champs Header d’une requête HTTP sont des points d’entrée en puissance. Une application peut vouloir regarder le champ User-Agent pour déterminer si il faut afficher la version mobile du site, le champ Accept-Language pour traduire la page selon la nationalité de l’utilisateur, ou le champ Content-Type pour vérifier le type de fichier que l’utilisateur tente d’uploader sur le serveur.

Comment identifier une faille de sécurité dans un point d’entrée ?

Trouver un point d’entrée vulnérable n’est pas une activité très compliquée, réussir à exploiter cette faille, voilà le véritable enjeu de tout ça. Mais commençons par le commencement.

Chaque point d’entrée existe dans un but précis et unique (normalement). Rappelez-vous mon petit exemple avec le paramètre GET page. De façon très intuitive, vous comprendrez aisément que cette variable n’est sensée contenir que des nombres.

A partir de là vous devriez vous poser quelques questions…

Quels mécanismes se trouvent derrière ce banal paramètre ? Il est peu probable que l’on rencontre une faille include (include “$page.php”) parce que… Et bien parce que personne ne nomme ses pages par avec des nombres.
Un site contenant 90 pages est à priori un site qui n’est que “moteur”, les données sont donc probablement ailleurs, dans une base de données par exemple…
Tiens, cette variable ne serait-elle pas utilisé pour générer une requête, au hasard SQL ? Probable…
Quels sont les caractères qui me permettrait de tester si il y a effectivement une faille ? #, ‘, –, ), ( peut-être.
Est-ce que je connais des mots clés me permettant d’effectuer les mêmes tests ? Des chaines de caractères tel que UNION, SELECT ou user(), méritent sans doute d’être tentées…
Etc… Vous avez saisi le concept car vous êtes futés.