Possible de faire un scan dns légalement ?

Hello,

Je viens vers vous aujourd’hui car on a une couille avec un client et on le suspecte de faire des trucs pas net

Imaginons une société Bidule, qui fournit une application SaaS à un client. C’est la société qui héberge l’application, sur son nom de domaine bidule.com.

Il y a notamment un service qui tourne sur un sous sous domaine : xxx.yyy.bidule.com

C’est un service censé être privé. Donc non référencé nulle part sur internet (pas sur google). Il y a notamment sur ce service des données confidentielles que le client en question n’a pas le droit de voir.

La société Bidule à des preuves que le client a réussi à accéder à ce sous-sous-domaine (et pas simplement à faire un ping dessus).

Est ce qu’il existe un moyen technique légal de trouver ce sous-sous nom de domaine ? Une sorte de scan dns peut être ?

Merci pour votre aide

Salut,

Les zones DNS sont publiques, donc oui il est possible de connaître les sous-domaines s’ils sont renseignés explicitement dans la zone.

Tu peux tester avec ce site par exemple.

Si une adresse expose des données sensibles, le minimum serait quand même d’implémenter une forme d’authentification si vous voulez pas qu’elles se retrouvent dans la nature

Déjà, est-ce que ça n’est pas tout simplement le serveur DNS qui s’est contenté de répondre à une requête AXFR ? Le cas échéant, ça peut être trivial même avec des outils en ligne.

D’autre part :

1. Je ne sais pas s’il y a quelque chose qui interdit quelque part de trouver un nom de domaine quelconque.
2. Je vais être méchant, mais si votre seule protection des données confidentielles que le client n’a pas le droit de voir c’était « espérer qu’il ne trouve jamais le nom de domaine », vous avez bien cherché les ennuis.

Vous avez complètement raison sur l’authentification. L’adresse cachée ne constitue aucune forme de sécurisation. Malheureusement ce service s’est retrouvé accidentellement mal sécurisé pendant une certaine période

Cependant nous essayons de comprendre comment le client a accédé à ce service, afin justement de voir si nous n’avons pas d’autres failles plus profondes (archi etc).

Je comprends bien que rien n’empêche quelqu’un de trouver un nom de domaine quelconque, mais on ne trouve pas un motif aléatoire complexe par hasard. Par simple curiosité j’aimerai donc bien réussir à reproduire la procédure.

J’ai l’impression que cet outil ne donne que les records DNS du domaine que tu renseignes, et non les sous-domaines.

Il n’est donc pas possible de trouver le motif "xxx.yyy" avec cet outil ?

Il me semble que pour effectuer une requête AXFR, il faut que le NS l’autorise. Hors cela ne semble pas être le cas du NS en question (Route53 d’AWS).

L’outil en ligne que tu mentionnes ne me donne aucun résultat non plus (ie pas de sous-domaines).

Bien vu pour le certificat. Je pense que c’est comme ça que le Client a procédé.

Bien qu’un tel système soit mal sécurisé, est-ce que cela ne constitue pas une intrusion dans un système informatique ? (sanctionnée donc par le code pénal (loi Godfrain)).

Surtout s’il y a un maintien dans le système en question en plus de la simple intrusion.

Il me semble qu’il y a de la jurisprudence qui condamne des intrusions dans des systèmes non sécurisés, à partir du moment où il est explicite que l’auteur de ce système ne souhaite pas que quelqu’un y accède.

Avez-vous des informations sur ça ?

Merci beaucoup pour vos réponses.

La situation est très ambiguë à vraie dire. Nous savons qu’il ne s’agit pas d’un acte de malveillance. En fait il s’agit plutôt d’une sorte de pentest réalisé par le client.

Nous n’avons aucune intention de nuire ou attaquer ce client. Nous avons corrigé très rapidement cette faille de sécurité et mis en place des choses pour que cela ne se reproduise plus, et le service en question exposait très peu de données (elles même peu confidentielles) de ce client justement.

Notre problème c’est que la "partie adverse" est un grand groupe français, et nous n’avons donc pas les mêmes moyens juridiques à notre disposition

Nous avons très peu de visibilité sur ce que met en place le client suite à cet incident. Ce ne serait à priori qu’une "simple formalité", mais pour l’instant nous n’en savons pas plus.

Nous avons cependant des preuves avérées d’un maintien de leur part dans notre système (plusieurs requêtes / recherches effectuées), et il me semble que cela tombe entièrement dans la loi Godfrain.

Je me demande s’ils peuvent utiliser une raison de "cyberdéfense de leurs données" pour justifier ce maintien ?

Ça me semblerait assez limite : "Je vous hack (au sens de la loi) pour vérifier que mes données sont bien sécurisées".

Tout dépend. Vous travaillez pour eux. Si le site est mutualisé, c’est un piratage mais si le site "appartient" au client (j’entends par là : développé pour le client), c’est légal et tout à fait normal qu’ils puissent simuler des intrusions. Dans ce domaine, on peut donner un scope - c’est à dire une définition claire des endroits à pirater. Si votre site est hébergé avec d’autres sites internet, un DDoS est illégal mais une attaque frontale sur leur site internet ne l’ait pas.

Enfin, le mieux reste (il me semble) d’échanger avec le client pour mettre les points sur les i. Y’a pas de secret. Car même si vous engagez une procédure judiciaire, les avocats échangeront ensemble sur les modalités d’ententes avant de porter l’affaire devant les tribunaux.

D’un autre côté, si vous les attaquez pour intrusion, ils peuvent aussi vous attaquer pour ne pas avoir respecté vos conditions de prestation de service, qui doivent probablement inclure de sécuriser un minimum leurs données.

Par ailleurs, qui accède normalement à ce sous-domaine ? Est-ce que la connexion est faite manuellement ou est-ce qu’il y a des requêtes qui peuvent être faites par d’autres éléments de vos services ?

Un échange avec leur département cybersécurité est prévu très prochainement. Notre objectif est bien entendu de trouver une entente.

Il s’agit cependant d’un site mutualisé, d’où nos préoccupations au delà du simple incident avec ce client.

La connexion à ce service est faite manuellement.

Mais effectivement ils peuvent nous attaquer sur certains points. C’est pour cela que nous souhaitons trouver un arrangement et s’assurer que cet incident ne survienne plus.

Je dirais qu’en auditant ce qui est lié directement à leur système d’information, ils remplissent probablement leurs propres obligations de sécurité et que les attaquer est malvenu, tout le monde serait perdant. Un juge n’est pas qu’une machine à appliquer des directives, il cherche également à savoir s’il y a quelque chose d’immoral à effectuer une action (ici la loi lui en laisse la latitude). Quant à vous, vous avez eu un audit gratuit.

Ce que dit mon VDD est tout à fait correct. D’autant plus qu’en terme d’image, si vous introduisez une action en justice, vous allez en prendre un sérieux coup. Sans oublier que votre faute est très probablement un motif suffisant pour une rupture unilatérale du contrat pour faute (+ pénalité si c’est prévu par le contrat).

Je ne suis pas tout à fait d’accord avec ces deux points :

• le client ne vous prévient pas de sa manœuvre (si c’est bien ce qu’il a fait) : c’est mal ;
• le test est un peu plus profond que nécessaire : c’est mal.

Pour le premier, parce que l’intérêt d’un test de sécurité (en général) peut être justement de vérifier ce qu’il y a réellement comme sécurité si on ne prévient pas. Pour un exemple plus proche de la vie courante, je pense aux exercices incendies qui se passent bien quand tout le monde est prévu, et qui tournent au bordel dès que c’est imprévu.

Par contre si c’est bien un test de la part du client, il aurais au moins dû vous avertir une fois le test fini, ou juste au moment de le démarrer.

Pour le second, parce que tu peux difficilement dire d’avance « ce qui est nécessaire » quand tu fais une analyse, surtout quand le but c’est de savoir ce que des attaquants pourraient récupérer comme informations ou faire comme dégâts.

Certains vont très loin conceptuellement dans ce genre de test : j’ai croisé une entreprise où ils ont pris un gars au hasard, lui ont dit « OK, on fait un test, tu es arrivé à t’introduire dans cette salle serveur, tu peux tout faire »¹. L’idée c’était que les serveurs là-dedans étaient redondés, ou au moins ondulés, et protégés par des armoires fermées à clé, donc que même une intrusion de ce genre ne pourrait pas faire de vrai dégâts.

@SpaceFox : si tu inclues tes fournisseurs dans le scope de ton test sans qu’ils soient d’accord (et donc a fortiori sans les prévenir), c’est juste une intrusion pure et dure, pas un test.

Et donc dans ce cas-là, tu peux t’arrêter à "oups, c’est pas sécurisé, on va leur dire".

L’analogie étant que si tu veux voir si des cambrioleurs peuvent passer par le jardin de ton voisin pour venir chez toi, tu vas peut-être voir s’ils verrouillent leur portail, mais tu te promènes pas chez eux en fouillant dans les tiroirs.

Et je trouve l’analogie avec les exercices d’évacuation mauvaise, puisque il s’agit d’un entraînement en conditions réalistes et pas d’un contrôle impromptu.

@Aabu tout dépend du contrat, en fait, en particulier qui a la responsabilité et qui a la charge de l’hébergement (et ça peut être franchement tordu).

Cela dit, si c’est du SaaS classique type grand public… le client n’a tout simplement pas à faire de test dessus sans l’accord explicite de l’éditeur.