Journal d'investigation en ligne et d'information‑hacking
par gordon

La sécurité, c’est les autres

Mettons que vous gérez une SSII. Vous développez un service, vous le sécurisez convenablement, et prenez garde à ce qu’il reste sûr dans la durée. Vous vendez votre service, vos clients sont contents, et au fur et à mesure, votre activité s’étend. Au bout d’un moment, vos clients demanderont à ce que votre service puisse discuter avec celui d’une autre SSII, spécialisée dans un autre domaine. Et là, c’est le drame.

Mettons que vous gérez une SSII. Vous développez un service, vous le sécurisez convenablement, et prenez garde à ce qu’il reste sûr dans la durée. Vous vendez votre service, vos clients sont contents, et au fur et à mesure, votre activité s’étend. Au bout d’un moment, vos clients demanderont à ce que votre service puisse discuter avec celui d’une autre SSII, spécialisée dans un autre domaine. Et là, c’est le drame.

Posons les bases : le futur partenaire dispose d’une API sous la forme d’un service web. Si on s’en tient là, il n’y a rien de choquant à noter. Jusqu’à ce que vous receviez la documentation technique de ladite API. Là commence la longue descente aux enfers. Parce que si vous avez le professionnalisme de traiter la sécurité comme une partie intégrante de votre infrastructure, vous vous apercevez que c’est loin d’être le cas pour les gus d’en face.

Il faut les comprendre, aussi. Se mettre dans la peau d’un gérant qui construit une entreprise autour d’un service qu’il souhaite performant. Sans y être initié, la sécurité est une simple étape barbante et non rentable. C’est vrai, quoi, la disponibilité des développeurs et administrateurs n’est pas infinie,et il est plus important de faire évoluer le service. Et puis c’est pas grave s’il y a des failles, de toutes façons, qui irait vérifier, ou encore les exploiter ? Au pire, si ça arrive, ça ne se verra quasiment pas…

Si vous me permettez une comparaison douteuse, ça reviendrait à dire « je ne vais pas mettre ma ceinture en voiture, ce serait perdre du temps et il faut que j’arrive à destination le plus vite possible. De toutes façons, les accidents ça n’arrive qu’aux autres. ». Et le jour où il s’avère qu’on est « l’autre », on n’est pas prêt d’arriver à l’heure à destination. Alors on peut se demander si la seconde et demie nécessaire à attacher sa ceinture avant le départ est rentable face aux chances d’avoir un accident, mais il y a un autre point de vue à adopter : si on ne prend pas cette seconde et demie à chaque fois, le jour où on se fait percuter par une batmobile, on étalera sagement une grande partie de son visage sur le bitume. Et tout ça sera fini. C’est pareil pour la sécurité d’une société : se faire compromettre les données que l’on gère, c’est bien souvent perdre toute crédibilité auprès des clients, et mettre la clé sous la porte.

Alors en lisant la doc technique, vous vous apercevez qu’il est question d’un service web accessible en HTTP seul (la couche de chiffrement SSL, c’est pour les faibles), par une requête dont un des paramètres est un mot de passe, lui aussi envoyé en clair. Et vous perdez subitement foi en l’humanité.

Pour ceux dont ce n’est pas le métier, expliquons rapidement le problème qui se pose ici : nous devons envoyer au prestataire des requêtes, par exemple en langage humain « Je voudrais savoir combien de SMS j’ai envoyés ce mois-ci grâce à ton service », et celui-ci nous répond. Dans cet exemple, il répondra « T’es qui, couillon ? ». Parce qu’évidemment, le service gère plusieurs clients, et il convient donc de se présenter. Mais il est évident que dire « je suis Fo0 Bar » n’est pas suffisant, car il est facile de prétendre être quelqu’un d’autre. Alors on s’authentifie de façon un peu plus sérieuse. Par exemple en prouvant au prestataire qu’on connaît un mot de passe secret précédemment défini. Il y a également le problème de s’assurer que le message arrive entier, et à la bonne personne. Pour cela, c’est pas sorcier, on utilise la cryptographie. Notamment la couche SSL (qui produit le joli « https:// »), reconnue dans l’industrie. Cela permet d’éviter que les nœuds du réseau par lesquels passe le message ne puissent les lire. Sans cela, envoyer le mot de passe en paramètre de la requête est une faille béante. Car n’importe qui en mesure d’intercepter ce qui passe pourra récupérer le mot de passe, et forger des requêtes en se faisant passer pour vous, et donc l’authentification ne vaut plus rien.

Mais il y a également le cas où la sécurité est prise (un peu, faut pas exagérer non plus) au sérieux. Où on vous soumet des spécifications, mais qui sont, par ignorance, complètement trouées. Et là, c’est le drame (bis).

Par exemple, en lieu et place des spécifications précédentes, vous en recevez qui sont qualifiées de « sécurisées ». Mais là, au lieu d’avoir opté pour les standards de l’industrie, c’est un chiffrement « maison » des données qui a été décidé. Et il n’a de toute évidence pas été conçu par un cryptographe. Du moins le partenaire pense-t-il l’avoir conçu, en vous envoyant son exemple d’implémentation. Car il s’agit en fait du Chiffre de Vigenère, une antique méthode, cassée depuis 150 ans, et ne présentant aujourd’hui plus aucune sécurité.

Intégrer une telle solution au sein de votre service vous met en danger. Car vous aurez à échanger des données privées, critiques ou confidentielles avec ce partenaire, qui de toute évidence ne cerne pas la problématique. Et comme vous le savez, en sécurité, si un chaînon est faible, c’est la sécurité de l’ensemble qui est compromise.

Mais attendez donc, ce n'est pas fini. Le monde serait bien beau si les mauvaises habitudes des pseudo professionnels s’arrêtaient là. Car dans le cadre de votre partenariat avec un service tiers, il n’y a pas que des appels API. Par exemple, vous pouvez logiquement avoir besoin d’un compte de test sur le SI du prestataire. Et qu’advient-il, si le mot de passe dudit compte est l’un des premiers présents sur tout dictionnaire de bruteforce qui se respecte ? Cela rend absolument inefficace la sécurité de votre compte. Vous connaissez notre amour pour les « comptes de test », en voici un. Mais quel pourrait être l’intérêt de sécuriser un compte de test, vous rétorquerait le prestataire. Tout d’abord, on ne génère pas de tels mots de passe, un point c’est tout. C’est une question de principe, et même pour un accès qui n’a strictement rien de confidentiel, et hormis pour les accès RTC à disposition de résistants dans un pays ensanglanté, Ensuite, et étant donné que le login représente le nom de votre entreprise, il sera aisé de vérifier si vos concurrents sont également partenaires de cette société, et, le cas échéant, de vous connecter sur leur espace client (ce qui est bien entendu illégal) en supposant que le mot de passe sera vraisemblablement le même. Partant de là, vous aurez accès à leurs données de test, qui pourront, si votre concurrent n’est pas très futé, être basées sur de vraies données clients.

Une dernière, pour finir ? Imaginez un prestataire dont le business serait de se placer en tiers de confiance, et de « certifier » votre service. Il vous permet donc, pour rassurer vos clients, d’insérer un bout de code sur votre site. S’il devait faire les choses bien, ledit bout de code appellerait un script hébergé sur le serveur du tiers, et vérifierait avant tout que c’est le bon site qui appelle (par exemple, tout bêtement en vérifiant la concordance du nom de domaine). Sans quoi, n’importe qui serait capable, sans la moindre connaissance technique, de récupérer le bout de code pour afficher le joli petit certificat qui brille sur son propre site. C’est pas du boulot très propre, et la supercherie se verra pour quiconque jette un œil attentif, mais pour beaucoup de clients, ça donnera l’impression que le site est bel et bien certifié. Et vu la qualité des phishings d’aujourd’hui, ce n’est probablement pas un détail comme celui-ci qui les arrêterait. Pire, il pourrait légitimer l’identité d’un site qui chercherait à en usurper un autre.

Ho, et tant qu’on y est, pourquoi ne pas carrément pousser le bouchon plus loin ? Imaginez qu’au lieu de fournir un appel à un script situé sur son serveur, le prestataire vous donne du code HTML à embarquer directement ? Un joli code contenant une note de certification, que vous pourriez à loisir modifier avant d’insérer sur votre site, pour falsifier à loisir votre certification ? Cela ne peut pas être, n’est-ce pas ? Si seulement vous aviez raison… Vous imaginez si tout ça avait été l’œuvre d’une seule et même société ?

0 Commentaires
Une info, un document ? Contactez-nous de façon sécurisée