Dur dur d'être pentester et de ne pas planter un système durant des tests. Difficile également de ne pas bloquer des comptes. Voilà donc quelques petits retours d'expérience qui résument bien les diverses problèmatiques auxquelles nous sommes confrontés. J'y ai rajouté quelques conseils (à prendre ou pas ;-) )

  • Envoi de 4000 mails au support d'une application

Les scanners applicatifs sont bien pratiques pour déblayer le terrain et se faire rapidement une idée des vulnérabilités que l'on peut trouver sur un site Web (mouais je suis sympa là...). Ils ne font cependant pas dans la finesse, loin de là.

Prenons par exemple IBM Rational Appscan. Avec ce fameux scanneur appli, les paramètres de chaque page seront testés sous toutes leurs coutures : injection SQL comme ceci, XSS comme ça, tentative d'injection par ici, tentative d'injection par là ... Les pages qui possédent de nombreux paramètres peuvent donc être appelées et testées des centaines de fois.

Si vous auditez maintenant un site qui contient plusieurs formulaires d'envoi de mails, vous tapez le pompon. Imaginez que vous testiez 300 ou 400 fois une dizaine de pages qui envoyent des mails ... Game Over ... vous pouvez envoyer 4000 emails au support, à la RH ou à un tiers. Certes c'est pas bien méchant en général, mais le client n'aime pas trop ;)

Il est en plus assez fréquent d'auditer ce genre de site (envoi de CV, envoi d'un lien à un ami, envoi d'un commentaire, question à poser ...).

Moralité : Avant de lancer votre scanner applicatif dès le démarrage comme un gros porc, il est préferrable de connaître un minimum le site que vous auditez et de réperer les pages sensibles. Dans la mesure du possible, excluez ses pages des outils automatiques (authentification, envoi de données à un tiers ...), elles peuvent vous causer des problèmes. Bien entendu, il faudra les tester manuellement, comme toutes les autres pages ; les scanners applis sont loins de faire des audits applicatifs complets et poussés. Notre savoir faire ne peut pas s'automatiser (Wouah elle est belle cette phrase ;) )

  • Le DoS à 100 caractères

Cette fois ci, c'est le coup classique de l'audit d'un serveur en C. On se connecte au serveur avec telnet et on envoie allez 100, 200, 300 caractères aléatoires ou pas. On voit apparaitre un joli "Connection closed by remote host". On a planté le service avec un buffer overflow ridicule ... On croit que c'est une blague mais pas du tout, c'est sérieux. Vous venez de planter une application ultra sensible qui voit passer des dizaines de millions d'euros par jour ...

Moralité : C'est fou comme les développeurs ne sont pas du tout sensibilisés aux problèmatiques de la sécurité applicative. Un effort messieurs. Je vous propose une superbe formation à 1000 euros la journée, contactez moi :-)

  • Blocage de comptes Oracle quand tu nous tiens ...

Lors d'un test d'intrusion de client lourd, le pentester audite généralement la base de données qui contient l'ensemble des informations métiers. Il ne se prive donc pas pour tester la présence de comptes faibles (par défaut, triviaux, ...) sur la base.

Il est souvent bien plus facile d'accéder aux données en passant par une base trouée avec un client SQL générique que de se faire chier à modifier le comportement du client lourd et de son interface graphique.

Pour tester la robustesse des comptes, le pentester ne s'embête donc vraiment pas et sort du tout cuit. Sur Oracle par exemple, l'outil oscanner est sexy, on ne se prive donc pas de l'utiliser.

Il faut cependant un minimum de précaution avant de lancer l'outil. Ne pas le configurer est purement suicidaire. Sur Oracle, il est en effet possible de mettre en place une politique de blocage des comptes (blocage au bout de 3 essais ou de 5 essais erronés). Il se peut donc qu'un pentester locke (bloque) des comptes pendant les scans.

Il est déjà arrivé à plusieurs pentesters de bloquer des dizaines voire des centaines de comptes Oracle tout simplement car l'outil n'avait pas été correctement configuré. Pas mal d'auditeurs zappent le fait qu'il est possible de bloquer des comptes sur des bases de données ...

Dans tous les cas, même en prenant des précautions et même en étant aguerri il est possible de bloquer quelques comptes (Ex : plusieurs mots de passes erronés ont été saisis avant que vous ne commenciez l'audit). Il est donc important de les noter et de les donner à votre contact privilégié pour qu'il les débloque rapidement (Cover your ass).

Un seul compte bloqué peut rendre l'application indisponible. il suffit par exemple de bloquer le compte Oracle propriétaire des schémas de l'application. Les utilisateurs applicatifs ne pourront plus se connecter à l'application. (Bon ok, le design de l'appli est pourri et elle va se faire massacrer, mais ça arrive beaucoup plus souvent qu'il n'y parait lors d'audit de clients lourds).

Moralité : Il faut connaitre ses outils ... et les configurer un minimum. L'art de la cliquouille brainless sur des softs de sécu doit être banni durant des tests d'intrusion. Dès que l'on tente un bruteforce, il faut y aller tranquillou en faisant attention à la politique de blocage. Dès qu'un compte est bloqué, le remonter rapidement ... Enfin on ne le dira jamais assez, sur des applications sensibles, les tests ne doivent être réalisés que sur des environnements de production (lorsque c'est possible ...).

  • Les sites Web qui ne tiennent pas le choc

En lançant une dizaine de requêtes HTTP en parallèle, il nous arrive parfois d'écrouler un serveur Web ou un machine intrusée.

Celà nous arrive souvent lors de scans applicatifs ou lors de recherche de répertoires / fichiers (avec Appscan ou des softs comme DirBuster). Ces scans qui sont parfois un peu gourmand (mouais ce ne sont que 4 à 10 requêtes en parallèle) peuvent rendre indisponible l'application en quelques secondes.

On retrouve souvent ce genre de problèmes lorsque l'on audite des applications développées par des prestataires ou lorsque les plannings des développeurs sont serrés. Quand on regarde le code de certaines applications Web on pleure ... Aucune optimisation, du code illisible, de la requête SQL à gogo pour faire une pauvre action ; votre base et votre serveur prennent chers. Plusieurs requêtes font s'envoler le CPU du serveur et la base de données ne comprend pas ce qui lui arrive.

C'est affligeant de voir que bien des sites Web ne tiennent pas une charge potable. Ce type d'incident est parmi les plus fréquents que nous rencontrons. Au mieux on stoppe les tests et ça revient dans les 10 minutes, au pire on téléphone au client. Dans tous les cas on doit prendre des précautions et ne lancer qu'une tâche en parallèle.

Moralité : Les applications qui sont développées à l'arrache et qui font le café, ça le fait jamais. Par expérience, plus une boîte sous traite ses développements, plus le niveau est mauvais. Les bons développeurs c'est bien rare, faut dire au prix où ils sont payés pour le taff que ça demande ... ;-)

  • Blocage de comptes client avec de l'injection SQL

Prenons un cas concret : l'audit du portail Web d'un courtier en ligne. Un audit Web somme toute classique comme on en a quasiment tous les jours. Pas de grandes difficulté à priori.

Le pentester, toujours très taquin, essaye des tentatives d'injections SQL sur l'authentification du site Web (C'est toujours sexy de s'authentifier sans compte avec une bête injection de débutant). Après une 20aine de tests, il faut se rendre à l'évidence, il n'est à priori pas possible de contourner l'authentification. Le consultant s'acharne alors sur les quelques comptes qu'on lui a donné. Rien ne passe. Qui plus est, au bout de la 4ème tentative d'injection sur un même compte... le compte applicatif est bloqué. Merci au client de ne pas avoir précisé qu'au bout de 3 tentatives d'authentification infructueuses, le compte est bloqué. Il faut lui téléphoner pour qu'il le déverouille.

Pourtant avant que vous n'aillez pu saisir votre combiné, le téléphone sonne, le client affolé demande ce qu'on a fait sur son p.....n de site Web...L'ensemble des comptes client sont bloqués à l'heure de pointe. Tout penaud vous lui devez des explications improvisées. Préparez la corde : votre vie de pentester prend fin aujourd'hui. ;-)

Pris au dépourvu, pas évident de se justifier face au client qui vous traite d'incapable. Pourtant la solution est simple, il y'a bien de l'injection SQL, elle se trouve dans la fonction de blocage des comptes. A la troisième tentative d'authentification il ne fallait pas rajouter le classique plop' or 1=1 -- dans le champs identifiant. Avec cette condition toujours vraie, vous venez de faire sauter une condition et vous mettez un flag de blocage à votre compte mais aussi à ceux des autres ;)

Moralité : Alalala injections SQL vicieuses, parfois ce sont les risques du métier. Bien fait pour le client.

  • Maman, j'ai bloqué 5000 comptes sur le domaine

Lors de tests d'intrusions internes (capture the flag / tests du stagiaire), il nous arrive fréquemment d'intruser de l'Active Directory.

Sympa de péter un AD, de récupérer les credentials des utilisateurs puis de les cracker la nuit sous la couette pour charier le client le lendemain ... (C'est pas tous qui apprécient). Comme souvent, le pentester est à la recherche du Saint Graal : le mot de passe bidon qui fout en l'air toute la sécurité du système d'informations.

Grosso modo pour passer administrateur de domaine, il suffit (bien souvent) de trouver un compte faible sur le domaine, de lister les utilisateurs privilégiés et de lancer sur leurs comptes des attaques par dictionnaire (généralement d'une à trois tentatives). Pas besoin d'être une grosse brutasse pour réaliser ce genre d'attaques qui je dois le dire fonctionnent à merveille (Sur une 10 aine d'AD intrusés, seul 1 ou 2 ne devraient pas tomber sous votre charme ...).

La réelle difficulté dans ce genre de tests, c'est tout bêtement de ne pas bloquer les comptes des utilisateurs en effectuant trop de tentatives d'authentification infructueuses. Il est en effet possible de spécifier une politique de blocage de comptes sur le domaine, et pour le coup elle est quasiment toujours spécifiée (Souvent 3, 5, 10 essais autorisés).

Comme les AD audités sont quasiment tout le temps en production ; pensez donc aux pauvres utilisateurs qui n'ont rien fait, qui veulent travailler 'plus' pour gagner 'plus', et que vous pouvez priver de boulot toute une matinée parce qu'ils n'arrivent plus à s'authentifier.

- Comment faire pour ne pas faire de boulette?

- Vous débutez dans le pentest et vous ne voulez pas bloquer les 5000 comptes d'un grand groupe comme votre collègue la semaine dernière?

Ben... c'est pas très dur ... Il suffit juste de récupérer la politique de blocage des comptes de l'Active Directory avant de commencer ses attaques. Y'en a là dedans ... Reste ensuite à configurer son soft de prédilection et de lui spécifier le maximum de tentatives qu'il pourra effectuer.

Ca parait tout con, mais combien de pentesters en herbe (ou pas) se sont cassés les dents là dessus et ont bloqué une quantité phénoménale de comptes. ;)

Moralité : Tout ça pour vous dire les mêmes choses que précédemment... malgré l'excitation, ne lancez pas vos outils sans connaître un minimum votre environnement (politique de blocage sur le domaine, politique de mots de passe, relations de confiance entre les diverses forêts d'AD, ...). Bref, ne faites pas le gros porcos, vous pourriez vite le regretter. Mais bon les incidents forment la jeunesse et permettent de virer les plus mauvais pentesters!

  • Les Nmap qui vallaient des millions

Parfois un simple scan de ports avec nmap peut planter et désynchroniser un vieux cluster AIX. Parfois un simple Nmap entraine la mort lente d'un vieux Solaris. Banal et dur à éviter lors d'un pentest. Ce sont les risques du métier.

Pourtant si vous saviez la suite de ces histoires. Si vous saviez l'importance et les conséquences que peuvent avoir deux pauvres scans de ports ... Je vous laisse imaginer ... ;-)