J'ai découvert un logiciel de gestion locative qui exposait les données des locataires sans authentification

Tout a commencé par un petit service

Je discutais récemment avec un ami. Il m'a dit qu'il n'arrivait pas à télécharger son relevé de loyer depuis le portail de son gestionnaire. Quelque chose ne se chargeait pas correctement.

« Je peux jeter un œil ? », lui ai-je demandé. Il m'a envoyé un lien.

J'ai cliqué. Pas d'écran de connexion. Pas de demande d'authentification. Pas de page « saisissez votre mot de passe ».

Juste son nom complet, son numéro de téléphone, le numéro de son logement et tous les loyers qu'il a payés depuis janvier 2023. Six pages d'historique financier. Accessibles à quiconque possède l'URL.

Pas de jeton de session. Pas de vérification de cookie. Rien entre ces données et l'Internet ouvert.

Ce que signifie le mode débogage en production

J'ai moi-même ouvert l'URL de base pour voir ce qui était encore exposé. Ce que j'ai trouvé était pire.

Le système tournait en mode débogage sur un serveur de production. Si vous n'êtes pas développeur, voici ce que cela signifie en langage courant :

Le mode débogage est une option que les développeurs activent pendant le développement pour trouver les bugs. Il affiche des messages d'erreur détaillés, les chemins des fichiers, les numéros de ligne du code et la configuration du serveur. Il ne doit jamais rester activé quand de vrais utilisateurs accèdent au système.

Ce qui était exposé :

• Les chemins complets des fichiers du serveur : l'emplacement exact du code de l'application sur le serveur
• La version du framework et ses dépendances : de quoi indiquer aux attaquants exactement quels logiciels tournent
• La logique interne des contrôleurs, avec les numéros de ligne : une carte du fonctionnement de l'application
• Les données d'environnement du serveur : des détails de configuration censés rester secrets
• Les informations de cookies et de session : des données qui pourraient servir à usurper l'identité des utilisateurs

C'est comme si une banque affichait sur sa porte d'entrée les plans de sa chambre forte, les codes de l'alarme et le planning des vigiles.

Des CVE connues : des failles documentées publiquement

Une fois la version du framework visible, je l'ai comparée à la base de données CVE (Common Vulnerabilities and Exposures). C'est un registre public où les chercheurs en sécurité documentent les failles connues des logiciels.

La version qui tournait sur ce système présentait plusieurs failles connues. Pas des risques théoriques. Des failles documentées, avec des instructions pas à pas disponibles en ligne.

Un attaquant n'a besoin ni d'imagination ni de compétences. Il lui suffit de :

1. Consulter la page d'erreur (accessible publiquement)
2. Lire la version du framework
3. Chercher cette version dans la base de données CVE
4. Suivre le guide d'exploitation publié

Ce n'est pas du piratage comme au cinéma. C'est lire une documentation publique et suivre des instructions. Un étudiant pourrait le faire en un après-midi.

Le risque M-Pesa Daraja

C'est là que cela devient vraiment dangereux.

Ce système encaisse les loyers par M-Pesa Paybill. Cela veut dire que quelque part dans le code se trouve une intégration de l'API Daraja : consumer keys, consumer secrets, URL de callback et logique de traitement des transactions.

Avec le niveau d'exposition que je constatais (mode débogage, aucun contrôle d'accès, dépendances obsolètes), un attaquant patient pourrait :

• Accéder aux identifiants API : la consumer key et le consumer secret qui servent à s'authentifier auprès de Safaricom
• Intercepter les URL de callback : rediriger les confirmations de paiement vers son propre serveur
• Manipuler les enregistrements de transactions : marquer comme reçus des paiements qui ne l'ont pas été, ou détourner des fonds
• Récolter des numéros de téléphone : M-Pesa est lié aux numéros de téléphone, eux-mêmes liés à de l'argent

L'API M-Pesa Daraja elle-même est sûre. Safaricom l'a bien conçue. Mais si le logiciel qui s'y connecte est aussi exposé, la sécurité de l'API ne sert plus à rien. C'est comme faire livrer des fonds par un fourgon blindé à un bâtiment sans portes.

Pourquoi j'ai choisi l'éthique plutôt que l'occasion

Je vais être honnête. En regardant ce système, je voyais plusieurs façons de l'exploiter. L'absence d'authentification suffisait à rendre les dossiers des locataires accessibles. Le mode débogage exposé rendait l'architecture du serveur lisible. Les dépendances obsolètes rendaient applicables des failles connues.

Je ne vais pas prétendre que l'idée ne m'a pas traversé l'esprit. Le système était pour ainsi dire grand ouvert.

Mais ce n'est pas moi. J'ai fermé les onglets.

À la place, j'ai écrit un e-mail à l'entreprise pour expliquer précisément ce que j'avais trouvé et comment le corriger. Je leur ai donné des étapes concrètes :

• Désactiver immédiatement le mode débogage
• Exiger une authentification sur toutes les URL destinées aux locataires
• Mettre à jour le framework pour corriger les CVE connues
• Auditer le stockage de leurs identifiants API Daraja
• Mettre en place un accès par rôle

J'espère qu'ils corrigeront le problème.

Sinon, mon prochain e-mail ira à l'Office of the Data Protection Commissioner (ODPC), l'autorité kényane de protection des données. Parce qu'il ne s'agit pas seulement de mauvaise ingénierie : c'est une violation du Kenya Data Protection Act, 2019 (la loi kényane sur la protection des données).

Ce que dit la loi : l'exemple du KDPA 2019 au Kenya

De nombreux pays africains disposent désormais de lois sur la protection des données, et le détail varie d'un pays à l'autre. Celle du Kenya est celle que ce système enfreignait : le Kenya Data Protection Act (2019) impose à toute personne qui collecte des données personnelles de :

• Mettre en place des mesures de sécurité appropriées pour protéger les données personnelles (article 41)
• Informer le Commissaire dans les 72 heures suivant la découverte d'une violation (article 43)
• Veiller à ce que les données ne soient pas accessibles à des personnes non autorisées (article 42)

Un système qui expose le nom, le numéro de téléphone et l'historique de paiement des locataires sans aucune authentification est clairement en infraction. L'ODPC a le pouvoir d'émettre des mises en demeure et d'infliger des amendes allant jusqu'à KES 5 millions ou 1 % du chiffre d'affaires annuel.

Si vous êtes propriétaire au Kenya et que vous utilisez un logiciel qui traite des données de locataires, c'est vous, au regard de la loi, le responsable du traitement. La négligence de votre éditeur engage votre responsabilité. Où que se trouve votre bien, vérifiez comment la loi de votre pays traite les propriétaires qui détiennent des données de locataires.

Comment auditer votre logiciel de gestion locative actuel

Que vous ayez développé votre système, que vous l'ayez acheté ou que vous utilisiez une plateforme SaaS, posez ces questions :

1. L'authentification

• Peut-on accéder aux données des locataires sans se connecter ?
• Les URL des relevés des locataires sont-elles devinables ou séquentielles ?
• L'authentification à plusieurs facteurs est-elle proposée ?

2. La gestion des erreurs

• Que se passe-t-il quand vous ouvrez une mauvaise URL sur le système ?
• La page d'erreur affiche-t-elle des détails techniques, des chemins de fichiers ou du code ?
• Si elle affiche une page d'erreur « propre », tout va probablement bien. Si elle affiche du code : signal d'alerte.

3. Les mises à jour logicielles

• À quand remonte la dernière mise à jour de sécurité ?
• Le système est-il activement maintenu ?
• Demandez à votre éditeur : « Quelle version de framework utilisez-vous ? »

4. Le contrôle d'accès

• Votre gardien peut-il voir des données financières qui ne le concernent pas ?
• Un locataire peut-il voir les informations d'un autre locataire ?
• Existe-t-il un journal d'audit indiquant qui a consulté quoi ?

5. La sécurité des paiements

• Comment les identifiants des API de paiement (M-Pesa, PesaPal, votre banque) sont-ils stockés ?
• Les URL de callback sont-elles validées ?
• Les données de paiement sont-elles chiffrées au repos ?

Comment HomeManager gère la sécurité

Quand j'ai conçu HomeManager, la sécurité n'était ni un détail ni une fonctionnalité à ajouter plus tard. C'était un principe de conception dès le premier jour. Parce que j'ai vu ce qui se passe quand ce n'est pas le cas.

Mesure de sécurité	Ce que cela signifie
Aucun accès sans authentification	Chaque URL, chaque point d'accès, chaque donnée exige une session de connexion valide. Sans exception.
Chiffrement AES-256 au repos	Toutes les données stockées dans la base sont chiffrées. Même en s'emparant du disque dur, personne ne pourrait les lire.
TLS 1.3 en transit	Toutes les données qui circulent entre votre navigateur et nos serveurs sont chiffrées avec le protocole de transport le plus récent.
Accès par rôle (25 autorisations)	Propriétaires, gestionnaires, comptables, gardiens et personnel de maintenance ne voient chacun que ce dont ils ont besoin.
Journal d'audit complet	Chaque action est enregistrée : qui a fait quoi, quand, depuis quelle adresse IP. Un registre inaltérable.
Correctifs continus des dépendances	Aucune CVE connue dans notre pile technique. Dépendances surveillées et mises à jour régulièrement.
Intégration M-Pesa sécurisée de bout en bout	Identifiants API chiffrés, URL de callback validées, données de transaction jamais exposées dans les journaux.
Infrastructure AWS	Hébergé sur Amazon Web Services, avec sauvegardes automatiques, montée en charge automatique et 99,9 % de disponibilité.
Conforme au KDPA 2019	Conçu dès le départ en conformité avec la loi kényane sur la protection des données (Data Protection Act).

En résumé

Vos locataires vous confient leurs données personnelles : nom, numéro de téléphone, numéro de pièce d'identité, historique de paiement, détails du bail. Dans de plus en plus de pays africains, cette confiance porte un nom juridique : une loi sur la protection des données. Au Kenya, c'est le Data Protection Act 2019.

Si le logiciel qui traite ces données ne sait pas répondre aux questions de sécurité de base, vous n'avez pas un problème technique. Vous avez un problème de responsabilité.

Demandez à votre éditeur actuel : « Que se passe-t-il quand quelqu'un tape une mauvaise URL ? »

Si la réponse ne vous plaît pas, ou s'il n'en a pas, il est peut-être temps de passer à un outil conçu avec la sécurité pour fondation, et non comme simple fonctionnalité.