I. Présentation

Depuis Windows 2008 R2, Windows intègre une nouvelle fonctionnalité nommée “BranchCache“. Elle permet d’optimiser l’accès aux ressources partagées hébergées sur des serveurs de fichiers, voir même des serveurs Web internes de type SharePoint, pour les clients qui se situent sur des sites distants.

La logique de fonctionnement repose sur la mise en cache des éléments partagés. En fait, imaginez une entreprise ayant un site principal et un site annexe, sur le site principal se trouve un serveur de fichiers qui partage les données à l’intégralité des collaborateurs (y compris ceux sur le site annexe). A chaque fois qu’un client du site annexe accède à un fichier celui-ci doit être téléchargé par la liaison WAN inter-site, potentiellement une liaison lente (comparée à la vitesse d’une liaison LAN).

Sur le long terme, notamment si les fichiers sont conséquents et si nombreux sont les collaborateurs sur le site annexe, une telle pratique peut devenir problématique.

C’est là qu’intervient le BranchCache…

Lors de la récupération d’un document, ce dernier ne passe qu’une seule fois par la liaison lente. Une fois le fichier arrivé sur le site distant, il sera mit en cache sur le site distant (nous verrons comment où plus tard). Pour tous les autres clients de ce site, quand ils voudront accéder à ce même document, ils récupérerons le document depuis l’endroit où il est stocké en cache. Cependant, avant que le fichier soit transmis, le gestionnaire du cache effectue une vérification des droits et de la non-modification du document sur le serveur principal où sont centralisées les données (sur le site principal).

Avec BranchCache, l’économie est réalisée sur la bande passante de la liaison, mais aussi sur les temps d’accès aux documents puisque l’on se rapproche très fortement des performances d’un accès local.

II. Mise en cache des données

La mise en cache des données peut être effectuée de deux façons :

- Un serveur stocke et distribue le cache : Les clients récupérerons les données depuis ce serveur situé sur le site annexe afin de bénéficier des avantages du cache. Ce mode est conseillé et peut être réalisé facilement si vous disposez d’un serveur sur place. De plus, le serveur reste généralement en fonctionnement en continue, ce qui n’est pas forcément le cas des machines clientes (concernées par la deuxième manière de mise en cache). Ce mode requiert l’utilisation d’un certificat SSL afin de sécuriser les échanges clients/serveurs. On parlera de cache hébergé.

- Distribution du cache entre les clients : Chaque poste client du LAN peut stocker des données en cache, ensuite, les clients se partageront les fichiers en cache entre eux. Ils s’occupent de distribuer le cache et en même temps de récupérer les fichiers en cache qu’ils ne possèdent pas sur les autres postes clients. On parlera de cache distribué.

Le serveur de fichiers du site principal reçoit la demande de fichier de la part du client, et si le fichier a déjà été demandé par un client du site annexe, le serveur de fichiers va envoyer un ensemble d’instructions de hachage aux clients afin de lui indiquer sur quel poste client il doit récupérer le fichier.

Par contre, si une différence est détectée entre la version du serveur de fichiers et la version en cache, des hachages différents seront attribués à ses deux fichiers afin d’éviter l’utilisation de fichiers obsolètes.

Dans ce tutoriel, le serveur de fichiers principal se nomme “SRV01” et le serveur de cache se nomme “SRV02“. Le tout sous Window Server 2012 R2.

III. Mise en place du serveur BranchCache

Nous allons installer la fonctionnalité BranchCache dans un premier temps, puis, nous configurerons BranchCache dans les stratégies de groupe pour ce serveur, dans un second temps.

A. Installation des fonctionnalités

L’installation du serveur BranchCache doit être effectuée sur tous les serveurs qui hébergent des données dans un premier temps, pour ma part il s’agit uniquement du serveur SRV01. En plus d’être un serveur de fichiers classique, il va devenir un serveur BranchCache.

Pour gagner du temps, nous utiliserons une commande PowerShell :

Install-WindowsFeature -Name BranchCache,FS-BranchCache

Cette commande installe “BranchCache pour fichiers réseau” qui peut être également installée via la procédure habituelle en interface graphique. Elle se trouvera alors sous “Services de fichiers et de stockage“.

Il n’existe pas d’outil d’administration RSAT pour BranchCache, la configuration doit être effectué via les stratégies de groupe et les paramètres des données partagées.

B. Configuration de BranchCache

La configuration s’effectue par l’intermédiaire des stratégies de groupe, local ou gérée au niveau de domaine. La seconde option est recommandée surtout si vous devez configurer plusieurs serveurs.

L’objectif de la configuration est d’activer sur le serveur la publication de hachage concernant les données partagées. Ces résultats de hachage seront utilisées par la suite dans le processus BranchCache, dans le but d’identifier de façon unique un document et de détecter les modifications effectuées sur un document. Le moindre changement au sein d’un document changera le résultat de la fonction de hachage.

Dans la console de gestion de stratégie de groupe, créez une nouvelle stratégie ou ajoutez ce paramétrage à une GPO existante qui s’applique déjà au(x) serveur(s) concerné(s) par le BranchCache. Parcourez l’arborescence comme ceci :

Configuration ordinateur, Stratégie, Modèles d’administration, Réseau, Serveur Lanman

Le paramètre qui nous intéresses se nomme “Publication de hachages pour BranchCache“, activez-le et précisez une action de la publication de hachages. Vous avez le choix entre activer la publication de hachages pour tous les dossiers partagés, l’activer uniquement pour ceux dans lesquels BranchCache est activé, ou alors ne pas autoriser la publication de hachage sur les partages.

Nous choisirons l’option “Autoriser la publication de hachages uniquement pour les dossiers partagés dans lesquels BranchCache est activé“.

Il suffit de valider la configuration du paramètre. Ensuite, pensez à actualiser la stratégie de groupe sur le(s) serveur(s).

C. Activer BranchCache sur un partage

Grâce à la stratégie de groupe, nous avons autorisé la publication de hachages pour les dossiers partagés où BranchCache est actif. Il est donc nécessaire d’activer BranchCache sur le partage concerné. Effectuez un clic droit sur le dossier partagé concerné puis “Propriétés“, onglet “Partage” et “Partage avancé“.

Cliquez sur le bouton “Mise en cache” et dans les “Paramètres hors connexion“, cochez “Seuls les fichiers et les programmes spécifiés par les utilisateur sont disponibles hors connexion” et cochez la case enfant “Activer BranchCache“.

La configuration côté serveur est désormais terminée, passons à la mise en place de la stratégie des postes clients.

IV. Configuration des clients BranchCache

Sur les ordinateurs clients, BranchCache est désactivé par défaut. Ce qui est logique afin d’éviter de faire tourner un service inutilement.

Deux méthodes sont possibles pour l’activation : Via les stratégies de groupe ou via une commande netsh. La première solution sera nettement plus intéressant dans le cas de nombreux postes et de l’utilisation d’un domaine Microsoft. Je vous donnerais quand même les commandes netsh, cela peut toujours être utile.

La configuration des clients requiert la modification de plusieurs paramètres.

A. Activer BranchCache

Ouvrez la console de gestion des stratégies de groupe, créez/éditez une stratégie de groupe et parcourez là comme ceci :

Configuration Ordinateur, Stratégies, Modèles d’administration, Réseau, BranchCache

Activez le paramètre “Activer BranchCache” disponible dans la liste du volet de droite.

Note : L’ensemble des paramètres dédiés à la configuration BranchCache des clients se trouve à cet endroit.

B. Définir le mode BranchCache

Il va maintenant falloir indiquer si l’on souhaite configurer les clients en mode distribué ou en mode hébergé. Pour ma part, j’opte pour le mode hébergé. Toujours au même endroit dans la GPO… vous trouverez deux paramètres (un pour chaque mode). Activez celui qui correspond au mode désiré.

- Définir le mode de cache distribué de BranchCache

- Définir le mode de cache hébergé de BranchCache : Ce paramètre nécessite également que l’on précise le serveur de cache.

C. BranchCache pour les fichiers réseau (SMB)

Il est nécessaire de configurer également le BranchCache pour les fichiers réseau afin que cela fonctionne pour le protocole SMB. Vous devrez également préciser une valeur de temps de réponse maximale aller-retour autorisée avant de déclencher la mise en cache.

Activez le paramètre “Configurer BranchCache pour les fichiers réseau“. La valeur de latence par défaut est 80 ms, si vous indiquez 0 la mise en cache sera effectuée pour tous les fichiers.

D. L’activation de BranchCache via netsh

La commande netsh à exécuter en tant qu’administrateur est la suivante :

- Pour le mode distribué :

netsh branchcache set service mode=DISTRIBUTED

- Pour le mode hébergé :

netsh branchcache set service mode=HOSTEDCLIENT LOCATION=<nom-serveur-cache>

 V. Configurer le serveur de cache hébergé

Nous avons configuré le serveur de fichiers, mit en place la stratégie de groupe pour la configuration des postes clients, il reste la configuration du serveur de cache hébergé, situé sur le site distant/annexe.

A. Installer les fonctionnalités

On commence par installer la fonctionnalité BranchCache et celle dédiée aux fichiers pour le SMB :

Install-WindowsFeature -Name BranchCache,FS-BranchCache

Une fois l’installation terminée, vous pouvez passer à l’étape suivante.

B. Créer un certificat

La création d’un certificat étant quelque chose de différent de la mise en place de BranchCache, je vous invite à consulter ce tutoriel TechNet concernant la création : TechNet Microsoft

La procédure s’appuie sur IIS pour la génération ce qui est logique comme BranchCache fonctionne aussi pour le HTTP.

Note : En mode distribué il n’est pas nécessaire de créer un certificat SSL comme le cache est distribué entre les différents clients. Le fonctionnement est différent.

Une fois le certificat créé, ouvrez une console MMC sur le serveur de cache et ajoutez le composant “Certificat” à partir du menu “Fichier” et “Ajouter/supprimer un composant logiciel enfichable“. Lors de l’ajout du composant sélectionnez “Un compte d’ordinateur” car le certificat doit être ajouté au niveau du compte ordinateur directement.

Ensuite, sous “Certificats (Ordinateur local)” et “Personnel“, faites un clic droit “Toutes les tâches” et “Importer” dans le but d’importer le certificat fraîchement créé.

Lorsque l’importation est terminée, double-cliquez sur le certificat pour afficher ses propriétés. Accédez au volet “Détails” puis sélectionnez le champ “Empreinte numérique“. Copiez la valeur de ce champ, elle sera utile dans la prochaine étape.

C. Lier le certificat au serveur BranchCache

Désormais, il faut lier le certificat au service BranchCache. Pour cela, nous allons utiliser la commande netsh. Très utilisée cette commande netsh dans le cas d’une mise en place de BranchCache.

Ouvrez une invite de commande en tant qu’administrateur sur le serveur (qui héberge le cache, qui contient le certificat) et saisissez la commande suivante :

NETSH HTTP ADD SSLCERT IPPORT=0.0.0.0:443 CERTHASH=<valeur-empreinte-numérique> APPID={d673f5ee-a714-454d-8de2-492e4c1bd8f8}

Dans la commande, remplacez uniquement “<valeur-empreinte-numérique>” par la valeur copiée précédemment.

D. Modifier la taille allouée pour le cache

Pour changer la taille allouée au cache vous pouvez utiliser une ligne de commande ou les GPO. Si l’on utilise la ligne de commande cela voici ce que l’on utilisera (exemple pour 40%) :

netsh branchcache set cachesize size=40 percent=TRUE

Il est à noter que par défaut 5% de l’espace disque est alloué pour le cache.

Si vous souhaitez le faire directement via GPO – ce qui peut être intéressant si plusieurs serveurs sont à configurer – vous devez configurer le paramètre “Définir le pourcentage d’espace disque utilisé pour la mémoire cache de l’ordinateur client” qui se trouve sous :

Configuration Ordinateur, Stratégies, Modèles d’administration, Réseau, BranchCache

VI. Paramètres supplémentaires avec Windows 8 – 8.1

L’arrivée de Windows 8 et plus récemment Windows 8.1 a amenée quelques paramètres supplémentaires dans les GPO concernant BranchCache. Vous les trouverez au même endroit que les autres paramètres.

Voici plus de détails :

- Activer la découverte automatique du cache hébergé par le point de connexion de service : Permet au client de rechercher directement le serveur hébergé correspondant au site auquel il est connecté, cela vous évitera une configuration site par site.

- Définir l’âge des segments dans le cache de données : Définit la durée de conservation des éléments du cache qui sont considérés comme valide. La valeur par défaut est de 28 jours.

- Configurer la prise en charge de la version BranchCache du client : Permet une rétrocompatibilité entre le client Windows 8/8.1 et les anciennes versions de BranchCache. Il est fortement conseillé d’utiliser ce mode si vous utilisez différentes versions d’OS afin d’assurer la compatibilité.

VII. Visualiser l’état de BranchCache

Deux commandes basées sur netsh sont utiles pour suivre facilement l’état de BranchCache.

- État général de BranchCache

netsh branchcache show status

- État du cache BranchCache

netsh branchcache show localcache

Vous remarquerez que l’emplacement du cache est également indiqué (copie d’écran ci-dessus).

Ce tutoriel touche à sa fin, si vous avez apprécié la lecture de cet article, merci de le partager sur les réseaux sociaux.

I. Présentation

Le fait qu’une machine virtuelle possède des captures instantanées signifie que le disque dur virtuel, ayant l’extension .vhd ou .vhdx, sera accompagné d’autant de fichiers ayant l’extension .avhd ou .avhdx que de captures instantanées. Par voie de conséquence, l’utilisation du seul fichier de disque virtuel (VHD ou VHDX) sur une machine virtuelle nouvellement créée pourrait fonctionner mais pas avec la version la plus récente de l’état de la machine virtuelle (laquelle est contenue dans un fichier AVHD ou AVHDX).

Pour disposer à nouveau d’un disque dur virtuel composé d’un seul et unique fichier VHD, il sera nécessaire de fusionner manuellement toutes les captures instantanées au sein du fichier original.

À la différence des captures instantanées de Windows Server 2008 R2, le processus de fusion des captures instantanées supprimées est réalisé directement « en live ». De cette manière, l’espace disque libérable lors de la fusion est récupéré au plus tôt. En effet, l’opération de fusion des disques en environnement Hyper-V sous Windows Server 2008 R2 n’était réalisée qu’à l’arrêt de la machine virtuelle. Le choix fait par Microsoft avec Windows Server 2012 de fusionner à chaud les disques .vhdx (disques durs virtuels) et .avhdx (fichiers de capture instantanée) a l’avantage de solutionner les problèmes d’espace disque. Notez cependant que l’administrateur devra prendre garde à la surcharge en E/S lors de la suppression d’une ou de multiples captures instantanées.

Note : Les fichiers AVHDX sont des disques de différenciation contenant un chemin absolu et un chemin relatif vers le disque parent. Ces pointeurs sont utilisés lorsqu’une opération de fusion est réalisée. Attention, l’opération de fusion modifie le fichier parent original.

II. Procédure

La procédure ci-dessous vous permettra de réaliser cette opération :

• À partir de la machine hôte Hyper-V, arrêtez la machine virtuelle originale.

• Copiez le fichier VHDX et les fichiers AVHDX correspondant aux différentes captures instantanées.

• Renommez les fichiers ayant l’extension AVHDX en VHDX.

• Repérez l’ordre des fichiers VHDX du plus ancien au plus récent, le plus ancien étant le VHDX original de départ. Cette opération peut être réalisée en contrôlant la date de la dernière modification sur les fichiers originaux AVHDX.

• Finalement, à l’aide de la console de gestion Gestionnaire Hyper-V, lancez l’Assistant Modification de disque dur virtuel via le menu Actions – Modifier le disque.

Assistant Modifier le disque

Mise en garde lors de la sélection du disque de capture

Sélection de l’option Fusionner

À l’issue de l’opération, les modifications stockées dans le disque de capture instantanée AVHDX seront fusionnées sur le disque parent.

Cette procédure permet à l’administrateur de fusionner manuellement des fichiers de captures instantanées AVHDX ou AVHD au sein d’un fichier parent lorsque la machine virtuelle ne peut pas être démarrée ou si l’un des fichiers était corrompu. Dans tous les autres cas, Windows Server 2012 Hyper-V permet la fusion en dynamique des fichiers de capture.

Le Webmail de la messagerie électronique fournie par Microsoft et appelée “Outlook.com“, introduit 3 nouvelles fonctionnalités ainsi que la possibilité de créer des règles avancées. Ceci dans le but de vous aider à garder votre boîte de réception aussi organisée que possible. Faisons le point.

• Les règles avancées

Avec les règles avancées, vous avez plus de contrôle sur l’organisation de vos mails notamment au niveau du tri. Il est désormais possible de créer des règles multi-conditions et multi-actions afin que votre boîte de réception s’organise automatiquement.

Inutile de recréer vos règles existantes, vous pouvez les modifier pour bénéficier des nouveaux réglages avancés.

Au niveau des conditions, il y a notamment la contrainte de temps, la vérification de lu/non lu, vérifier si l’émetteur est un contact connu ou non, etc.

Voici un exemple de règle :

Si un mail non lu est plus vieux que 3 jours et qu’il provient d’un de mes contacts, catégorisez-le comme important et assurez le suivi.

Cela permettra de positionner les mails non-lus de personnes connues dans le haut de la boîte de réception.

• L’annulation

Pour vous protéger contre les déplacements accidentels ou même, encore pire, une suppression accidentelle, Microsoft a intégré une fonctionnalité d’annulation (retour arrière). Il suffit de cliquer sur le bouton d’annulation ou d’utiliser la combinaison de touche habituelle, à savoir Ctrl+Z.

• Réponse In-Line

Avec ce nouveau mode de réponse, vous pouvez directement répondre à un e-mail sans charger une nouvelle vue. Ainsi, vous gagnerez du temps lors de l’utilisation et cela permettra de suivre plus facilement plusieurs conversations.

• Amélioration de la messagerie chat

L’expérience utilisateur pour démarrer une session de chat avec des amis est améliorée, cela grâce à plusieurs améliorations :

- Trouver les conversations récentes et les autres contacts avec lesquels le chat est disponible. Pour cela, il suffit de visualiser le bas à gauche de la fenêtre de la boîte de réception. Un seul clic suffira pour démarrer une conversation avec l’un d’entre eux.

- Si vous discutez avec un ami sur un service, mais que vous souhaitez continuer en utilisant un autre service, vous pouvez désormais commuter entre les différents services. Par exemple, vous discutez sur Skype avec une personne et désirez passer sur Facebook, vous pourrez changer rapidement et simplement.

- Parcourir la liste de vos amis et filtrer la liste selon le type de service qu’ils sont entrain d’utiliser actuellement. Des icônes apparaissent également pour indiquer qui est actuellement disponible, si c’est uniquement par chat, en vidéo ou en appel vocal.

L’ensemble des ces améliorations seront disponible du côté utilisateur dans les semaines à venir. Restez connecté !

Source

I. Présentation

Aujourd’hui nous allons nous pencher sur un CTF qui se nomme Drunk Admin Challenge, vous pourrez le trouver sur Vulnhub comme la plupart des CTF dont je parle ici. Il s’agit d’une VM que je fait tourner sur VMware Workstation 10 et ma machine d’attaque sera une KaliLinux virtualisée.

Note : Je vous invite à ne lire cette solution uniquement si vous êtes réellement bloqué, le fait de chercher longtemps pour une solution est le meilleur moyen de comprendre ce qu’il faut faire.

II. C’est partie !

On commence par le traditionnel netdiscover, outils de scan via le protocole ARP dont j’ai déjà parlé sur ce site :

netdiscover -r 192.168.1.0/24

On repère ici plusieurs IP, en trichant un peu on voit donc ma cible qui est virtualisée donc avec une carte réseau VMware, il s’agit de l’IP 192.168.1.15 :

On peut ensuite faire une scan de port sur cette cible afin de voir ce qui tourne sur celle-ci, on utilise pour cela nmap :

nmap -A -T4 192.168.1.15

On ne voit pas grand chose mis à part le port SSH qui semble fermé, l’option A ne fait un scan uniquement sur les “well known port“, qui sont les ports de 0 à 1024 :

Étendons un peu notre recherche sur les ports supérieur :

nmap -A -T4 -p 0-1000 192.168.1.15

On voit a présent un service HTTP qui semble tourner sur le port 8880, ce qui est peut commun. On peut essayer de s’y rendre via un navigateur pour voir ce qu’il s’y passe :

On remarque donc un formulaire d’upload d’image. En faisant quelque teste, on remarque que seule les images au format png, jpeg ou gif. Si le fichier uploadé n’a pas ces format pour extension, On obtient le message suivant :

De même , si le fichier dépasse une certain taille, on obtient un “You have exceeded the size limit !“. Ce que l’on essaye de faire généralement lorsque l’on a un formulaire d’upload de fichier, c’est d’uploader un fichier … mais de préférence un script (php) qui pourrait nous permettre d’exécuter des actions sur le serveur directement. Si l’on fait un fichier au format .php, on obitent un “Invalid file extension”, même chose avec phtml, php5, etc. Je n’ai en tête que deux méthodes pour vérifier le format d’un fichier. La première est via son nom, c’est à dire la vérification de son format via des expressions régulières (est-ce que le fichier fini par .png ?), la seconde est via le champ Content-Type qui permet de spécifier le format du fichier uploadé comme précisé dans le RFC1867.

Il existe néanmoins probablement quantité d’autres méthodes, commençons par tester celles que nous connaissons. On va essayer d’uploader un fichier au format pngABC pour voir si cela gène le formulaire, et surprise ! Ça semble fonctionner, on a pas de message d’erreur concernant l’extension de notre fichier mais notre image n’est pas affichée, ce qui n’est pas plus gênant que cela. On peut ensuite essayer d’écrire un script PHP qui se nommera panda.png.php et voir si on arrive à l’uploader, voici ce que nous allons mettre dans notre script pour commencer :

<?php echo "SUCCES"; ?>

Uploadons le fichier pour voir ce qu’il se passe. On voit que le fichier (le script) est bien uploadé, on peut alors supposer (et seulement supposer) un regex du type “\.png” qui validerais le format d’un fichier, ce qui fait qu’un champ (.png.machin) serait accepter car il n’y a pas de vérification que le nom du fichier fini par “.png”. Cependant, on ne retrouves pas notre fichier sur le serveur web et il ne semble pas exécuté lors de l’affichage de l’image. Si on tente de joindre “http://cible/panda.jpg.php”, cela ne mène à rien. Il faut donc que l’on chercher à savoir ou et comment sont stockée nos images. On revient donc en arrière en uploadant à nouveau une image valide et correcte, j’upload le fichier “image.png”  :

On voit donc que notre image s’upload dans le dossier “images/” et est renommée en ce qui ressemble à un hash. On va essayer de dé-hashé la chaine obtenu pour voir si on peut y retrouver une logique nous permettant d’atteindre notre précédent script. Il existe quantité de service en ligne permettant de dé-hasher a partir de rainbow table.

Donc nous avons bien confirmation que les images sont renommées et portent le noms de leur hash complet (nom+extension) après ce renommage. Il nous reste donc plus qu’à obtenir le hash MD5 de “script.png.php” puis d’aller sur http://cible/images/hash pour voir notre script, c’est parti !

Note : Lorsque PHP est installée sur un serveur web, celui-ci ajoute automatiquement “.php” à la fin d’une requête sans extension.

Et voila ! On a réussi à avoir uploader un script PHP sur notre serveur. On est donc en tant que www-data sur notre cible. Voyons ce que l’on peut découvrir avec cela. On peut à tout moment changer le contenu de notre fichier panda.png.php pour mettre de nouvelle commande PHP mais le plus simple est d’avoir ce que l’on appel un shell PHP dans lequel on enverra un commande PHP et le contenu ne sera retourné. Je met donc dans mon script la ligne suivante :

<?php echo exec($_REQUEST['cmd']); ?>

On upload à nouveau notre script dans le formulaire puis on se rend sur l’URL de celui-ci. On y ajoute le contenu de notre variable “cmd” qui sera la commande que nous souhaitons passer à notre script :

Cela rend la navigation sur le serveur beaucoup plus simple et beaucoup plus rapide. En explorant un peu plus le serveur, j’obtiens quelque chose en envoyant la requête “ls -al ../ > ls.txt”. Je vais ensuite lire mon fichier ls.txt :

Le fichier .proof peut être intéressant, on voit la volonté de cacher le fichier car il commence par un “.”, bien que cela soit peu malin car il se situe dans un répertoire web. Le nom “proof” ne m’évoque pas grand chose (pas comme un .htaccess..), voyons ce qu’il y a dedans. J’envoie un commande qui affichera le contenu de “.proof” dans un fichier “.txt”, puis je l’affiche (la lecture directe de /.proof semble bloquée) :

Ça semble intéressant, on récupère quelque chose qui ressemble à une conversation entre Bob et “…” ainsi qu’un “Secret Code”. On sait maintenant que l’utilisateur “bob” existe. On peut également le vérifier en affichant le contenu du “/etc/passwd”. Allons faire un tour dans son /home en envoyant le contenu de la commande “ls -al /home/bob” dans un fichier.txt :

Le “public_html” nous indique que le contenu de ce dossier peut être joint via ~bob. C’est une manière de mettre sur le serveur web une partie d’un home d’un utilisateur. On peut donc se rendre sur notre serveur web via http://cible:8880/~bob et voir ce qu’il s”y passe :

Une demande de secret.. Je saisi le “secret Code” récupéré tout à l’heure mais cela ne donne rien de lisible. Il ne s’agit ici par d’un mot de passe mais d’une clé servant à déchiffrer le message d’après (le secret..). Après avoir quelque peu chercher je me rend compte que TGglMUxecjJDSDclN1Ej ressemble fortement à un encodage Base64. Si je l’encodre j’obtiens “Lh%1L^r2CH7%7Q#“. Je rentre alors ce code en tant que secret et bingo :

Vu le sens de la phrase, la suite de chiffre ne peut être qu’une situation géographique, je rentre ces informations sur Google Maps  :

Et voila notre Flag =) Mission Accomplie !

 

 

 

Microsoft confirme qu’il ne supporte plus Windows XP, le Patch Tuesday du mois de Mai sortit aujourd’hui ne contient aucun correctif pour l’ancêtre Windows XP. Venons en contenu de ce patch, il contient 8 mises à jour dont deux qui sont considérées comme critique.

Les deux bulletins critiques corrigent des vulnérabilités rencontrées au sein d’Internet Explorer 8 à 11 ainsi que pour SharePoint Server 2007, 2010 et 2013. Quant aux Office Web Apps version 2010 et 2013, elles sont également concernées et prises en charge par ces deux correctifs.

Pour le reste, c’est à dire les 6 autres bulletins, ils concernent aussi Office 2007 à 2013 que Windows 7, Windows 8 et Windows 8.1 ainsi que les versions Windows Server 2008 R2 et 2012.

Microsoft recommande l’installation de ces mises à jour, je vous le recommande aussi d’ailleurs. Allez, à vos Windows Update !

Détails des bulletins