lundi 20 avril 2009

[Pentesting] [Messaging] Lotus hacking

Nous continuons sur les posts techniques en nous attaquant cette fois à un autre type de serveur : le serveur de messagerie. Et plus exactement, l'attaque portera sur un serveur LOTUS. Nous verrons que l'attaquant peut encore une fois frapper très fort par cette voie.


1 - Briefing: Lotus

Le post est à but purement éducatif et ne devra en aucun cas être testé sur un réseau qui ne vous appartient pas, en tout cas, sans autorisation.
Il s'agit ici de donner une démonstration tiré d'un article paru dans le HS n°1 de MISC. Se référer à celui-ci pour plus d'information.
Nous agissons ici de l'extérieur puisque nous nous focalisons sur la partie webmail de la messagerie.


2 - Repérage de la cible

Trouver la messagerie de la compagnie auditée n'est pas difficile. Il y a la méthode que j'appelerai "intuitive" qui consiste à deviner le nom. Par exemple : mail.compagny.com, webmail.compagny.com, mx.compagny.com, etc...
Et il y a la méthode plus intelligente ;) Il suffit d'exécuter une requête DNS sur le champ MX :

dig MX compagny.com

Notre cible utilise du Lotus ? Alors à l'attaque !


3 - Des informations bien utiles ...

3.1/ Récupération d'informations intéressantes

Nous allons regarder dans une premier temps si nous avons accès aux fiches des utilisateurs. Pour cela, essayer d'ouvrir le fichier names.nsf. Par exemple, à l'adresse : http://mail.compagny.com/names.nsf. Vous devriez avoir les listes des utilisateurs ! Cliquer sur ceux qui ont un icône "terre" et qui ont donc un accès webmail. Vous devriez trouver facilement ... le login ! ça commence plutôt pas mal, non ?

3.2/ Récupération des comptes adminitrateur

Obtenir le compte d'un adminitrateur nous permettrait une compromission encore plus importante dans le sens où cela nous permettrait d'obtenir des accès sur le système hôte. Comment connaître l'identité de l'administrateur de la messagerie ? Deux manière au moins :
  • Regarder les mailing-lists. L'une d'elles pourraient s'appeler mail_adminitrator ou quelque chose du genre. Sinon, toutes les listes d'administration pourrait être intéressante pour connaître les utilisateurs-clé ;)
  • Regarder la configuration du serveur Lotus si celle-ci est accessible en lecture au moins. Le ou les nom(s) des adminitrateurs de la messagerie devraient vous être fournis sur un plateau ...

3.3/ Récupération des hashes

Et c'est à partir de maintenant que ça fait peur ! Mal configuré - comme souvent - il est possible de connaitre le hash du mot de passe des utilisateurs depuis Internet. ça ne peut pas être si simple me direz-vous ? En effet, c'est encore plus simple que ce que vous pouvez penser !

  • Sélectionner la fiche de votre utilisateur cible ;
  • Faire un clic droit sur sa fiche et choisir "Ce cadre" puis "Code source de ce cadre" (éventuellement en anglais) ;
  • Dans le code source, faire une recherche sur la chaîne HTTPPassword ;
  • Récupérer la valeur dans le champ "value" sans les guillemets mais avec les parenthèses ;
  • C'est tout !
Il existe deux formats de hash que nous pouvons récupérer (éventuellement sur le même serveur) :
  • le format plus ancien :
  • le format plus récent basé sur du MD5 + sel :


4 - Juste une histoire de mot de passe

Nous avons donc obtenu un hash et en bon agent que vous êtes, ce n'est certainement pas la première fois que vous avez un hash à déchiffrer. Ici, notre arme de choix est le célèbre casseur de mot de passe, nommé John ! John the Ripper [1] !
Néanmoins, nous aurons besoin d'utiliser une version avec les patches qui vont bien. Perso, j'utilise john-banquise [2] qui contient les patches pour Domino dont nous avons besoin.
Ensuite, nous avons besoin de lancer John avec le format approprié :

  • pour les hashes de format ancien :
john --wordlist=dictionary.txt --rules --format=lotus5 liste_hashes.txt
  • pour les hashes de format récent :
john --wordlist=dictionary.txt --rules --format=DOMINOSEC liste_hashes.txt

Le fichier liste_hashes.txt doit être de la forme suivante :
prenom1Nom1:(hash1)
prenom2Nom2:(hash2)
prenom3Nom3:(hash3)
...

5 - Conclusion

Nous avons vu comment avoir accès à la messagerie d'un utilisateur sans difficulté particulière (sauf si le mot de passe était complexe). Cependant, nous n'avons pas tout vu.
En externe, il faut savoir qu'une fois le compte adminitrateur de la messagerie en notre possession, il est possible d'exécuter des commandes arbitraires sur le système hôte !
En interne, d'autres attaques, différentes, peuvent être jouées. Notamment, elles tournent autour du fichier id.


Et n'oubliez pas, have fun! :)

dimanche 19 avril 2009

[PENTESTING] [Database] MS-SQL Audit

Après notre aventure théorique sur l'OWASP, je reviens sur le blog pour un post technique. Et pour ce "comeback", je vous propose dans un premier temps de nous attaquer à un élément du S.I très sensible : les bases de données ! En effet, c'est ici que nous trouverons souvent les données les plus confidentielles ... Plus précisément, nous allons prendre pour exemple les bases de type MS-SQL.


1 - Mission: MS-SQL

Le post présente une technique qui n'est pas supposée être la meilleure, ni être exhaustive. Le but ici est de voir une façon de faire. Au risque de me répéter, mais c'est très important, ce qui est présenté ci-dessous ne peut être réalisé qu'au sein de son propre réseau ou dans un cadre légal (avec autorisation de la compagnie auditée).

Avant d'entrer dans le sujet, il faut savoir que ce type de tests est plus approprié aux tests d'intrusion internes. Si jamais une telle base était accessible depuis Internet, je vous laisse imaginer la criticité du problème !

Pour terminer, le client OSQL, utilisé dans la suite, est fourni gratuitement sur le site de Microsoft dans le package MSDE. La connexion vers la serveur se fait ainsi :

osql.exe /S ip_serveur|nom_serveur /U nom_utilisateur /P mot_de_passe



2 - Repérage de notre cible

2.1/ Trouver les serveurs MS-SQL

Par défaut, les bases MS-SQL utilisent les ports :
  • TCP/1433
  • UDP/1434
NMAP peut donc nous permettre de trouver les serveurs MS-SQL présents sur le réseau audité (par exemple, sur le réseau 172.16.XXX.XXX) :
nmap -v -sV -sS -p 1433 -oN NMAP_MS-SQL.txt 172.16.0.0/16

Ou mieux :

nmap -sV -sS -p 1433 172.16.0.0/16 | grep "open" -B 3 > nmap_mssql_list.txt

Cette méthode simple est tout de même limitée car si l'administrateur n'utilise pas le port par défaut, nous passons à côté de notre cible !

2.2/ Prise d'information sur les serveurs MS-SQL

Il existe plusieurs outils pour obtenir des informations sur les serveurs MS-SQL audités. Nous montrons ici l'exemple de SQLRecon :


Le but est de connaître les numéros de version notamment pour éventuellement jouer un exploit si le serveur de base de données n'est pas maintenu à jour.


3 - Compromission de la cible


3.1/ Juste une question de compte ...

Une base de données MS-SQL a un compte administrateur appelé par défaut sa. Ce compte doit donc être protégé spécifiquement. Cependant, il arrive qu'il soit configuré avec le mot de passe ... vide ou sa ! Les credentials par défaut peuvent donc très simplement fournir un accès total à la base de données.

Si les comptes par défaut ne donnent pas de résultats positifs, nous pouvons tenter une attaque par dictionnaire. Pour cela, il existe l'outil SQLPing3cl :


Nous avons auparavant :
  • rempli le fichier user.txt avec les noms de compte possible (ex : sa) ;
  • rempli le fichier pass.txt avec la liste de mots de passe (sinon, il existe des tonnes de fichiers préconçus sur le Net contenant les mots du dictionnaire ;).
Un de nos serveurs a le mot de passe sa (extrait de l'output) ...

172.XXX.XXX.XXX,1433,NOM_Serveur,MSSQLSERVER,8.00.194,8.0.766,8.00.760,,No,(UDP)ServerName;NOM_Serveur;InstanceName;MSSQLSERVER;IsClustered;No;Version;8.00.194;tcp;1433;np;\\Nom_Serveur\pipe\sql\query;; (SA)Server present but blank SA login failed (BruteForce)**** Brute force attempt successful! User:sa Pass:sa ****,UDP TCP SA BruteForce

3.2/ Regarder les vulnérabilités !

Si malgré tous vos efforts vous n'obtenez pas le mot de passe du compte sa, il faut se retourner vers un site de veille sécurité pour trouver une faille exploitable selon la version trouvée (cf. point 2.2/).


4 - Système touché !

Il faut savoir qu'une base de données tourne par défaut avec les droits Local System. Alors imaginez que la base de données est compromise et que vous puissiez exécuter des commandes arbitraires ... ce serait avec les droits NT AUTHORITY/SYSTEM !

Or, par défaut, MS-SQL bénéficie de ce qu'on appelle des procédures stockées. Ces dernières permettent d'augmenter significativement la puissance d'une base de données. En effet, cela permet de nombreuses actions prédéfinies très utiles pour l'administrateur ... ou pour l'attaquant. La procédure qui nous intéresse ici est xp_cmdshell.

4.1/ Activer une procédure stockée

Il est possible que la procédure que nous souhaitons - xp_cmdshell - ne soit pas activée. Pour le savoir, tenter une connexion vers la base et essayer de lancer la procédure stockée de la manière suivante :

> xp_cmdshell 'ipconfig'
> go

Si vous n'avez pas d'erreur, comme sur l'image suivante, passez tout de suite à l'étape 4.2/


Sinon, suivez les instructions ci-dessous permettent l'activation de la procédure :


4.2/ Lancement de commandes

Nous allons poursuivre notre attaque en créant un compte sur le système hôte :

> xp_cmdshell 'net user jer001 M1ssion_pass /add'
> go

Nous vérifions avec les commandes suivantes :

> xp_cmdshell 'net user'
> go
Notre compte est ajouté !


5 - Aller plus loin

Arrivé à ce stade, nous avons été suffisamment loin dans la compromission du serveur. Cependant, il est nécessaire d'être exhaustif dans le cadre d'un pentest. Un serveur qui a pu être compromis de la sorte n'a pas bénéficié du hardening adéquat et par conséquent, souffre certainement de nombreuses vulnérabilités. Cela peut se vérifier par des tests complémentaires. Notamment, nous pouvons nous aider du script SQL SQLVulscan. Voici une liste non exhaustive de vulnérabilités qu'il permet de trouver :

  • Privilège du compte de service ;
  • Méthode d'authentification ;
  • Liste des procédure stockées ;
  • Présence des bases de données par défaut ;
  • Présence des accès "invité" ;
  • Présence de comptes sans mot de passe ;
  • etc.

Pour le lancer, utiliser la commande suivante :

c:\>osql.exe /S 192.168.0.12 /U sa /P BDD_PASS /i SQLvulscan.sql


Et comme toujours, have fun!
Locations of visitors to this page