Comment perdre l'accès au système en direct en tâtonnant simplement le code source

La sécurité avec des exemples réels est toujours plus intéressante.

Une fois qu'un client est venu avec une demande de test de pénétration. Il avait de nombreuses raisons de s'inquiéter, entre autres, une a été entendue: «Il y a quelques mois, un nouveau développeur est venu chez nous, a eu accès au code source, à la documentation, à un serveur de test, a disparu deux jours plus tard et ne répond toujours pas. Comment cela peut-il me menacer? L'accès au système en direct ne lui a pas été accordé. »

Nous ne parlerons pas des erreurs des développeurs, qui peuvent devenir de sérieux trous dans le système live. Tout est beaucoup plus simple - le code source lui-même peut contenir des instructions et des accès directs.

Parmi les différents projets que nous avons testés pour la sécurité, je donnerai de vrais exemples où, avec seulement le code source, nous pourrions pénétrer le système lui-même. Tous ces problèmes ont été corrigés et toute information supplémentaire dans les captures d'écran est masquée.

Système 1.
Le code cloné de gita n'est pas seulement la dernière version, mais aussi l'historique de toutes les modifications. Nous exécutons généralement le code source des informations sensibles à l'aide de gittyleaks .

Dans ce projet, nous avons trouvé une clé de chiffrement privée qui a été supprimée du code, mais qui était toujours utilisée dans le système en direct. Cette clé a été utilisée pour l'authentification, et connaissant le mécanisme, nous pouvions générer n'importe quel cookie d'authentification pour n'importe quel utilisateur, y compris l'administrateur.


Image 1. Sortie: gittyleaks --find-everything


Système 2.
Vous pouvez utiliser l' utilitaire git et lui demander d'afficher tous les fichiers supprimés. Dans ce système, nous avons trouvé un fichier deployer.pem qui était à la racine du projet et qui a été utilisé pour déployer automatiquement le projet sur les serveurs via le canal SSH. Le port SSH du système en direct a été ouvert. Pourquoi est-il ouvert? Les développeurs ont répondu que leur machine de construction se trouvait derrière une adresse IP dynamique et ils ont décidé de ne pas fermer le port - «de toute façon, personne ne récupérera la clé SSH». Gee-gee ...


Image 2. Sortie: git log --diff-filter = D --summary

Système 3.
Avec ce système, tout était encore plus simple. Il peut être utile d'entrer dans les scripts de la base de données et de voir comment les utilisateurs sont créés par défaut. Habituellement, le premier utilisateur à créer un administrateur avec les autorisations les plus élevées. Dans les scripts, nous avons trouvé un code qui a généré un hachage à partir de vrais mots de passe et l'avons écrit dans la base de données. Étonnamment, 5 utilisateurs ont été créés, mais le mot de passe de l'administrateur le plus important, à notre grand étonnement, est passé par le système en direct. Et ce code n'est pas la première année, d'ailleurs, et personne n'a travaillé avec lui.


Image 3. Comment trouver de vrais mots de passe dans les scripts de base de données

La promesse.

1. Si votre projet se trouve sur une gita, ouvrez-le et exécutez quelques commandes à partir du dossier racine:

installer pip gittyleaks
gittyleaks --trouver-n'importe quoi

git log --diff-filter = D --summary

2. Une règle d'or. Un système en direct doit toujours avoir des clés uniques, des mots de passe utilisateur uniques et tout ce qu'il contient doit être fermé au maximum.

Les informations ci-dessus sont fournies uniquement à des fins éducatives et éducatives, comment faire leurs systèmes n'est pas nécessaire.

Denis Koloshko