Le navigateur par défaut pour accéder à l’intranet étant Internet Explorer², j’ai donc passé la matinée à fabriquer une réplique de la fenêtre de connexion Windows.
Il faut jouer sur la naïveté de l’utilisateur : pour certaines applications, l’authentification utilisateur de l’AD de sa machine Windows ne suffit pas pour se connecter. Normalement, une nouvelle fenêtre d’identification ne devrait pas trop le surprendre.

Le fait d’imiter la fenêtre de connexion ne suffit pas : il faut amener l’utilisateur à se rendre sur l’intranet sur une URL particulière, et le mieux, qu’il ne se rende pas compte que ses identifiants ont été dérobés. Une faille en cours de résolution sur le réseau interne est que le serveur d’envoi des mails ne vérifie pas vraiment l’identité. Il est donc possible d’envoyer un mail à plusieurs personnes en se faisant passer pour un autre. Il ne reste plus qu’à susciter l’intérêt de l’agent pour qu’il clique sur le lien : un message concernant une intervention du maire, un fiche de recommandation sur je ne sais quel sujet, …

Pour mettre en place cette récupération d’identifiants, je souhaitais que l’URL incluse ressemble à quelque chose d’officiel. J’ai opté pour auth.ville.local, sachant que le suffixe DNS des connexions filaires est ville.local. De plus, il est existe réellement un serveur auth.ville.fr, mais seulement accessible depuis l’extérieur. La ressemblance est relativement bonne, surtout pour un utilisateur naïf !
J’ai donc mis en place une machine virtuelle sous Ubuntu serveur, en y configurant un serveur Web, ainsi que son nom « auth », qui une fois sur le réseau, est devenue auth.ville.local. Parfait

Cette démarche a mis en évidence un autre problème du réseau interne : toute machine se connectant en filaire sur le réseau à l’intérieur de la DSIT³ obtient le suffixe DNS « ville.local ». Donc toute personne ayant renommée intelligemment sa machine peut tenter « d’usurper » l’identité d’une autre machine. C’est ce que P. a fait : il a nommé sa machine sous Linux du même nom que celle de A., et oh magie, lorsque je tentais un ping vers le nom de machine de A., c’est en fait la machine de P. qui répondait.
P. aurait souhaité prendre le nom d’un serveur, pour voir comment le réseau réagirait, mais cela ne lui a pas été possible⁴.

Le problème a été remonté mais n’est pour l’instant pas une priorité absolue. Il s’agit du réseau interne, et n’importe qui ne peut pas entré ni tombé sur une prise Ethernet active. L’extérieur de réseau est lui mieux sécurisé, et c’est là dessus que l’on souhaite se concentrer pour l’instant.

1. Site web de la collectivité, accessible uniquement en interne, présentant les services internes, l’annuaire, etc), je me suis aperçu en affichant le webmail que l’intranet incluait directement la page grâce à une URL fournie en paramètre. Le webail étant hébergé en local rien de très choquant ((Même si la technologie utilisée est obsolète : le iFrame :( ↩

2. Oui je sais… ↩

3. Il faut déjà réussir à le faier, le bâtiment régulant toutes les entrées. ↩

4. Et on comprend bien, il aurait fallu un réseau test à côté pour le faire. ↩

D’autant plus que j’ai continué à rechercher des solutions de scripts pour analyser du code PHP. J’ai fait un rapide bilan écrit (un peu plus complet et détaillé que celui d’hier, notamment avec des captures d’écrans) des solutions trouvées jusqu’à présent.
Sans grande surprise, je n’ai toujours pas trouvé les sources de Pixy.

Mais surtout, j’ai tenté de faire fonctionner SonarQube. Sur Windows évidemment. Alors après quelques cafouillages, des configurations bancales qui ont tout de même le mérite de ne pas tout faire planter, impossible de faire des tests pour PHP. Soit j’ai mal fait quelque chose dans les installations des différents plugins et applications nécessaires (voire j’en ai oublié un :/), soit ce n’était pas mon jour… Alors imaginez avec une chaleur pas possible.

Mon problème n’était pas le serveur central SonarQube, sorte de « dashboard ». Ce qui m’a d’abord posé problème, c’était le Sonar Runner qui permet de lancer des tests sans devoir passer par Maven ou Ant. Mais c’était trop peu pour me faire peur. Car après quelques sueurs froides chaudes, c’est l’installation de PHP qui a flanché. Et là, j’ai perdu tout espoir en Windows.

J’ai donc opté pour une machine virtuelle sous Ubuntu (j’ai d’ailleurs trouvé un tutoriel qui semble bien expliqué pour auditer du code PHP), qui j’espère sera prête d’ici demain matin. Et normalement, merveille des merveilles, je découvrirais le rapport d’audit de Sonar

La suite du programme a été de tester une application web¹ permettant de gérer le recyclage de gros déchets.
P. s’est rapidement aperçu que les champs des formulaires n’étaient aucunement contrôlés : bonjour les failles XSS. D’autre part, l’envoi de fichiers n’était pas non plus sécurisé : nous avons pu envoyer un fichier PHP et l’exécuter. Et enfin les commandes systèmes exec, shell_exec et system n’étaient pas désactivées, ce qui nous a permis d’avoir la main mise sur le serveur…L’après-midi a été consacré à la recherche des lignes problématiques dans le code source que B. a pu nous fournir. Les développeurs ont utilisés le framework Zend pour leur application. Le problème, c’est que Zend n’échappe les caractères par défaut lors de réception de données². Il faut donc qu’à chaque ligne où la méthode de Zend pour récupérer une requête est utilisée échapper les caractères avec la fonction htmlspecialchars³.
Sublime Text a su me fournir rapidement toutes les lignes à corriger. Reste maintenant à pouvoir modifier le code source du projet en intégration…

1. Encore en développement, sur un serveur d’intégration ↩

2. Données reçues en GET ou en POST ↩

3. L’application est en effet codée en PHP ↩

Nous avons procédé par étapes pour vérifier la robustesse du serveur. Deux ordinateurs lançait conjointement la simulation, répétée jusqu’à un arrêt manuel, chargeant les pages suivantes : page d’accueil ; galerie photos ; galerie vidéos ; recherche du mot « marchés ».
Les simulations étaient les suivantes :

1. Simulation de 10 utilisateurs faisant 4 requêtes¹ à la seconde
   (10×4×2 = 80 requêtes à la seconde)
2. Simulation de 30 utilisateurs faisant 4 requêtes à la seconde
   (20×4×2 = 160 requêtes à la seconde)
3. Simulation de 50 utilisateurs faisant 4 requêtes à la seconde et de 20 utilisateurs faisant 2 requêtes à la seconde
   (50×4×2+20×2×2 = 480 requêtes à la seconde)

Le serveur a tenu la charge pour les deux premières simulations (lors de la deuxième simulation, le temps de réponse est monté jusqu’à une quarantaine de secondes…). Par contre, la troisième simulation a fait tomber la base de données au bout d’une dizaine de secondes.
Relancer le service a suffit pour retrouver un site opérationnel (la simulation étant arrêtée).

Après une matinée bien chargée, l’après-midi a été consacré au document de recommandations pour la sécurité des applications web. Je sais quels points je veux aborder, mais il reste maintenant à organiser ça et à rendre ça digeste pour tout développeur…

La fin de journée a été consacrée à la résolution d’un petit problème pour D., stagiaire de B. migrant un ancien Joomla sur la dernière version. Il lui était impossible d’accéder à l’administration de Joomla, une requête SQL d’un utilisateur et de son mot de passe² a permis de résoudre le problème.

1. Notons qu’une requête correspond au chargement de la page demandée, en chargeant aussi tous les éléments (fichiers CSS, javascript, images, …), ce qui en réalité représente plusieurs requêtes… ↩

2. Hashé dans la BDD, mais connu au préalable ↩

P. m’a ensuite montré plus en détail les différents outils qu’il a pu utilisé pour faire ses tests de vulnérabilité. J’ai notamment été bufflé par deux outils :

1. Nessus qui permet de lancer une batterie de tests sur une IP et de générer un rapport très complet³. On peut ainsi récupérer les ports ouverts, l’OS de la machine, les différentes versions de logiciels utilisés, les failles connues à partir de ses éléments, la découverte du réseau, etc ;
2. Social-Engineer Toolkit qui permet, entre autre, de copier une page web pour récupérer les identifiants envoyés par un utilisateur. L’exemple que P. m’a montré est assez puissant je trouve : en une petite commande, la page d’accueil du site de Facebook était copiée au pixel près ! Le formulaire envoyait de manière transparente les données au serveur pirate, puis renvoyait vers le vrai site Facebook : un utilisateur lambda n’y verrait que du feu, et aurait pourtant compromis son compte  J’essayerais de reproduire l’exemple ici.

J’ai pu découvrir de nombreux autres outils, certains plus spécialisés que d’autres.

Nous sommes ensuite allés manger ensemble dans un restaurant chinois pas très loin. Le buffet à volonté ne fut pas mauvais du tout !

L’après-midi a commencé par une réunion avec B. et sa stagiaire D. concernant les actions communes que nous pouvions mettre en place. B. s’occupe du développement de nombreuses applications web, et sa stagiaire D. doit faire évoluer deux anciens sites existants sur de nouvelles plateformes. Il est à noter que D. a pour formation initiale une formation beaucoup plus réseau que développement web.
J’ai ainsi pu aider D. à configurer son logiciel Wamp pour faire fonctionner un des anciens sites qui était sous Joomla 1.5. Il a aussi fallu importer une base de données SQL par l’intermédiaire de phpMyAdmin. Je crois que ces petites configurations lui ont rendu un grand service pour qu’elle puisse continuer à avancer dans son projet.

En fin de journée, nous avons dû nous pencher activement sur une partie du futur site Internet de la ville — qui doit être mis en production en fin de semaine. En effet sur le site actuel, il est possible par l’intermédiaire d’un formulaire de demander des papiers officiels pour l’état civil. Le nouveau site ne permettant pas cette fonctionnalité, il faut absolument qu’elle y soit présente. Nous devons donc déterminer si la fonctionnalité développée précédemment présente des risques majeurs, car l’idée serait de greffer ce formulaire sur le nouveau site⁴. Évidemment, autant en profiter pour vérifier que tout va bien !

Voilà comment s’achève cette deuxième journée, tout aussi intéressante que la première !

1. Vous remarquerez que le document a été écrit en LaTeX  ↩

2. J’y vois pour l’instant les rubriques « pendant le développement » et « avant la mise en production » ↩

3. J’en ai profité pour faire un test  complet sur mon Raspberry Pi. J’avais oublié que Fail2Ban était installé, l’IP attaquante a donc été vite bannie, ce qui m’a permis de m’en sortir de bons résultats ! ↩

4. Le site doit être opérationnel en fin de semaine, et avec cette fonctionnalité, et à quoi bon réinventer la roue ? ↩