Jour 23 • Veille et cahier des charges

Publié le par

Ce matin, j’ai profité de peu de chose à faire pour faire un peu de veille technologique. J’ai par exemple appris qu’une société a été condamnée par la CNIL pour une politique de mot de passe trop faible. À la base, la CNIL était venue pour un système de vidéo-surveillance mis en place de façon pas nette, et dans son investigation a aussi sanctionné ce détail.

J’en ai aussi profité pour parcourir bon nombres de page du Monde informatique, que je connaissais pas encore  :

L’après-midi a été consacré à la lecture/relecture de du cahier des charges de l’offre publique concernant la gestion de hébergement et de la DMZ publique de la collectivité local.
À la différence d’une entreprise, chaque marché doit faire l’objet d’un appel d’offre public. Il faut donc rédiger le document de telle manière à exprimer les souhaites et attentes pour le projet, tout en ne délimitant pas trop le cahier des charges, car dans ce cas aucune entreprise ne répondrait. Il faut jongler intelligemment, car c’est ce document qui fera office de contrat par la suite.

Et il faut avouer que ce n’est pas facile. Car il faut en plus coordonner chaque partie ou sous-partie avec la personne responsable du service pour que ses contraintes soient respectées…

Jour 22 • Le souci du détail

Publié le par

Ce matin, j’ai continué à me pencher sur la copie de la fenêtre de connexion Windows. Mon poste de travail étant sous Windows 7 et la majorité du parc informatique aussi, je me suis dit que c’était la bonne version de l’OS à choisir. De même la majorité des utilisateurs utilisent Internet Explorer1 qui utilise la fenêtre habituelle de connexion Windows.
La fenêtre a donc été « optimisée » pour être la plus ressemblante à celle de Windows 7 ouverte depuis IE. Au final, voici un petit comparatif.

Windows weblogin comparaison

Pour rendre la fenêtre encore plus réaliste, j’ai ajouté un peu de JavaScript pour rendre la fenêtre déplaçable. Seul bémol, la fenêtre ne peut pas sortir du cadre d’Internet Explorer, alors que la vraie fenêtre oui. La copie n’est qu’une image, mais les champs ainsi que les boutons sont codés en HTML.

La fin de matinée a été consacrée à une réunion de synthèse avec X.2 sur le travail effectué depuis le début du mois de juillet. A., P. et moi étions présents.
Il a été donc rappelé tout le travail par chacun, et pour a part j’ai pu refaire une synthèse de ce que j’ai pu voir et faire au sein du stage :

  • Recherche et mise en place d’un outil de test de montée de charge (avec rédactions de documents)
  • Analyse du code source d’un application web vulnérable avec explications des solutions et corrections à mettre en place
  • Recherche d’un outil d’analyse de code source « statique » pour répérer dès le développement certaines failles
  • Rédaction d’un document de recommandations des bonnes pratiques de codage lors de développement d’applications web
  • Recherche d’utilisation de la vulnérabilité de l’intranet pour daire du hameçonnage3

Le midi, malgré le temps peu accueillant, nous avons pu nous régaler avec un barbecue

L’après-midi a été un peu plus calme, j’ai pu terminer la fausse fenêtre d’authentification, que je ai mise en ligne.
N’oubliez pas qu’elle est destinée à être ouverte dans une iFrame sur l’intranet de la collectivité, dans un environnement Windows 7 avec Internet Explorer, et qui s’appuie sur la naïveté des utilisateurs

Je vais tout de même lister les petits détails qui devraient mettre la puce à oreille aux utilisateurs :

  • Normalement, la session Windows de l’utilisateur connecté l’identifie par défaut sur l’intranet.
  • L’URL incluse est auth.ville.local, alors que le serveur est auth.ville.fr4
  • La fenêtre n’est pas déplaçable en dehors du navigateur, seul la barre de titre permet en réalité de la déplacer
  • Lorsqu’un champ est sélectionné, la bordure est bleue et ne reste pas grise
  • La touche « échap » ne permet pas de quitter la fenêtre, chose possible sur la vraie fenêtre
  • Le fond bleu change de couleur lors du survol des deux champs, et non pas de la fenêtre

  1. Version 9 tout de même ! ↩

  2. Responsable de notre branche, directeur-adjoint de la DSIT… ↩

  3. Ou Phishing en anglais. ↩

  4. d’ailleurs les champs grisés affichaient auth.ville.fr et VILLE ↩

Jour 21 • Récupération de mot de passe

Publié le par

Ce matin en accédant à l’intranet1. Ce qui l’est plus c’est qu’aucune vérification du lien reçu n’est effectué : il m’a été possible de faire afficher un site internet extérieur.
Il m’est alors venu de faire afficher une page d’authentification pirate, me permettant ainsi de récupérer nom d’utilisateurs et mots de passe…

Le navigateur par défaut pour accéder à l’intranet étant Internet Explorer2, 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 DSIT3 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é possible4.

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. ↩

Jour 20 • Bilan

Publié le par

Dernière journée de cette semaine. Quelle surprise quand en se levant il pleuvait et tonnait ! Une bonne grosse averse et des orages à partir de quatre heures du matin, qui ont duré au moins jusque 10 heures.
Conséquence : barbecue annulé et reporté à mardi de la semaine prochaine. En espérant qu’il fasse beau.

La matinée a achevé mes recherches sur des outils pour auditer du code source d’applications web. J’ai préparé un joli PowerPoint de présentation et de comparatif des solutions trouvées durant la semaine.
Les outils qui ont vraiment retenus mon attentions sont RIPS, Graudit et SonarQube1. Pour le reste, soit je n’ai pu pu les tester2, soit les résultats étaient plus que médiocres, soit encore les applications ne répondaient pas au problème…

Le barbecue annulé nous a permis de faire une petite session de Left4Dead à quatre. Après cette longue pause, nous avons présenté notre travail à A. Et pris dans les discussions, il était déjà l’heure du weekend

Sinon j’ai compté, il ne me reste plus que 13 jours ouvrés de stage…

  1. Même si SonarQube est un outil de mesure de qualité de code, il permet de trouver des variables non utilisées et des portions de code dupliquées. ↩

  2. Impossibilité des les télécharger ou impossibilité de les exécuter, malgré tout le mal que je me suis donné :/ ↩

Jour 19 • Maitrise

Publié le par

Aujourd’hui A. était en déplacement sur Paris pour le marché d’hébergements. Ce qui ne nous a pas empêche de travailler !

Après une installation réussie hier de l’outil SonarQube, j’ai pu tester différents sites avec différents types de configurations (tests basiques, sur tels critères, etc). L’outil est vraiment complet pour la qualité de code, mais absolument rien concernant la sécurité… Or le but de mes recherches est de trouver des applications capables de déceler dans le code source des vulnérabilités. Donc malgré l’intérêt que j’ai pour cet outil, il ne convient malheureusement pas…
Néanmoins, j’ai appris à lancer ces différents tests, jongler avec cet outil parfois capricieux. J’ai enfin pris ma revanche

J’ai donc continué ma recherche, et je suis tombé sur un petit logiciel pour Windows capable de scanner du code statique, et aussi dynamiquement1 : PHP Vulnerability Hunter.
Je reste assez septique. Le logiciel n’a trouvé qu’une seule petite faille mineur sur le code testé, et dont un essai sur deux de scan se solde par une sorte de plantage. Peut-être faut-il un nombre restreint de fichiers à tester ?

Demain matin, P. a demandé à A. s’il pouvait l’accompagner pour une réunion concernant le marché d’hébergement pour voir comment ça se déroule. Je pense finir ma présentation des outils trouvés jusqu’à présent, car après le barbecue, petite réunion de synthèse.

  1. Dans ce cas, un serveur web sur lequel le code est exécuté est nécessaire ↩