Il est important de noter que le «jeu» de l'attaque et de la défense, auquel se livrent les hackers et les propriétaires de systèmes informatiques, est un jeu malhonnête. Il suffit que l'attaquant pénètre dans le système, pour gagner une seule fois. Et ceux qui défendent ne peuvent gagner qu'en gagnant toujours. La principale difficulté ici est de savoir à quoi vous devez prêter attention. Mais une fois que le défenseur sait quel type de «portes» virtuelles un hacker peut entrer dans son système, ces «portes» peuvent être protégées en utilisant des mécanismes assez simples. Je pense que la simplicité de ces mécanismes diminue parfois leur importance et c'est la raison pour laquelle de nombreux défenseurs des systèmes informatiques négligent ces mécanismes.
Voici les règles de base pour la protection des systèmes que je vais divulguer dans cet article. Ils sont simples, mais cela ne signifie pas que vous pouvez les oublier en toute impunité:
- (multi-factor authentication, MFA) , . Google GitHub, , VPN-. MFA — .
- , .
- , . .
- . , .
En ce qui concerne la prévention des fuites d'informations classifiées et la prévention de l'apparition de «trous» dans les systèmes de sécurité, le principe de Pareto fonctionne , selon lequel 20% des efforts donnent 80% du résultat.
Comment fonctionnent les pirates lorsqu'ils trouvent des mots de passe et des clés secrètes? Quels outils utilisent-ils?
Les pirates trouvent des données secrètes dans des fichiers JavaScript
Les clés API sont dispersées sur Internet. Tout le monde peut les utiliser. C'est un fait. Il n'y a souvent aucune raison particulière pour que les clés soient accessibles au public. Les développeurs les oublient simplement partout. Par exemple, les clés entrent dans le code pour les raisons suivantes:
- À des fins de débogage.
- À des fins de développement local.
- Sous forme de commentaires destinés à ceux qui soutiendront le projet ultérieurement.
Des blocs de code semblables aux suivants peuvent être trouvés assez souvent sur Internet:
// DEBUG ONLY
// TODO: remove -->
API_KEY=t0psecr3tkey00237948
Bien que de nombreux pirates lisent eux-mêmes les fichiers JavaScript, ils recherchent principalement ces fichiers à l'aide d'outils tels que meg , puis vérifient ce qu'ils trouvent pour trouver des modèles correspondants.
Comment font-ils? Après avoir utilisé le scanner,
megils semblent rechercher dans les fichiers trouvés des chaînes correspondant à différents modèles. Celui qui a créé meg, a écrit un autre excellent programme, qui est destiné à cela. Il s'appelle gf et est une version améliorée grep. Dans ce cas, l'utilisation de l' gfoption au démarrage truffleHogou, dans une autre variante de son écriture trufflehog, permet à l'outil de trouver des chaînes à haute entropie qui sont des clés de l'API. Il en va de même pour la recherche de chaînesAPI_KEY... Les résultats de recherche pour une telle chaîne sont souvent (trop souvent) réussis.
Il y a souvent des raisons tout à fait normales pour le fait que des clés apparaissent dans le code, mais ces clés ne sont pas protégées des étrangers. Laisse moi te donner un exemple. Un client avec lequel j'ai travaillé a utilisé un service d'information cartographique externe. Cela se fait dans de nombreux projets. Afin de télécharger et de travailler avec les informations cartographiques, il était nécessaire de passer des appels à l'API correspondante à l'aide d'une clé. Mais mon client a oublié de configurer le service qu'il utilisait pour restreindre les sources à partir desquelles le service pouvait recevoir des demandes en utilisant cette clé particulière. Il n'est pas difficile d'imaginer une attaque simple, qui consiste à épuiser le quota d'utilisation des ressources d'un service de carte en lui envoyant de nombreuses requêtes. Cela peut coûter beaucoup d'argent à l'utilisateur d'un tel service. Ou,encore «mieux» (du point de vue de l'attaquant), une telle attaque peut conduire au fait que les parties du projet du client qui sont liées aux cartes, «tombent» simplement.
Les fichiers JS sont utilisés par les pirates pour plus que la simple recherche de données secrètes. Après tout, ces fichiers sont le code de votre application, qui peut être vu par toute personne intéressée par ce code. Un bon hacker peut, après avoir lu attentivement le code, comprendre l'approche de la dénomination des entités qui y est utilisée, trouver les chemins vers l'API et trouver des commentaires précieux. Les recherches comme celles-ci sont formatées sous la forme d'une liste de mots envoyés aux scanners automatiques. C'est ce qu'on appelle un "scan automatisé intelligent", où un pirate informatique combine des outils automatisés et les informations qu'ils ont collectées sur un projet spécifique.
Voici un vrai commentaire de la page d'accueil d'un projet, qui parle en clair sur les API non sécurisées à partir desquelles n'importe qui peut obtenir des données:
/* Debug ->
domain.com/api/v3 not yet in production
and therefore not using auth guards yet
use only for debugging purposes until approved */
▍ Que faire?
- . . , , .
- API. , . , .
- , , . , , , , , , . , .
- , . . , .
grepgf. . , , . - -. , - . 100% . - — .
, -
Les archives Internet (également connues sous le nom de «Wayback Machine») stockent des instantanés périodiques de sites Web. Ce projet vous permet de voir à quoi ressemblait Internet il y a de nombreuses années. Les données d'archives sont d'un intérêt considérable pour les pirates informatiques qui ont besoin de collecter des informations sur un certain projet. Vous pouvez analyser les fichiers pour les anciennes variantes de sites Web à l'aide d'outils tels que waybackurls (basé sur waybackurls.py ). Cela signifie que même si vous avez trouvé une clé dans le code du site et que vous l'avez supprimée de là, mais que vous n'avez pas fait pivoter les clés, les pirates peuvent trouver cette clé dans l'ancienne version du site et utiliser cette clé pour pirater le système.
Voici ce qu'il faut faire si vous trouvez une clé là où elle ne devrait pas être:
- Créez une clé conçue pour remplacer la clé compromise.
- Publiez une nouvelle version du code qui utilise la nouvelle clé. Ce code doit être réécrit de manière à ne pas contenir de lignes facilitant l'identification de la clé.
- Retirez ou désactivez l'ancienne clé.
▍ Les archives Internet ne sont pas le seul endroit pour trouver des clés
L'ancien code donne aux attaquants une grande variété d'informations qui les intéressent.
- Chemins secrets de l'API. Nous parlons de points de terminaison d'API non sécurisés que le développeur pensait ne jamais partager. Bien que les chemins qu'un hacker découvre ne leur soient pas utiles, ces chemins peuvent aider à comprendre la conception de l'API d'un projet et ses conventions d'API. Une fois le code du site entré en production, le développeur n'a aucun moyen de cacher ce code aux regards indiscrets. Il est très important de s'en souvenir.
- -. , API, . , . , , . , -. , , . , , . ,
shttps.
GitHub
GitHub est une mine d'or pour les hackers. Si vous savez où chercher, vous pouvez trouver beaucoup de choses intéressantes en utilisant des outils de recherche simples. Si le compte GitHub de votre organisation n'est pas protégé par l'authentification multifacteur, alors tous les employés de l'organisation, sans exception, sont confrontés à des failles de sécurité. Il est fort possible que certains des employés utilisent le même mot de passe partout et que ce mot de passe leur ait déjà été volé par un autre système. Un pirate qui s'intéresse à une certaine organisation peut facilement automatiser la recherche de mots de passe compromis, mais que puis-je dire, il peut trouver ces mots de passe manuellement.
La liste des employés d'une organisation peut être créée à l'aide de techniques d'intelligence open source (OSINT). LinkedIn ou une liste publique d'employés de l'entreprise de GitHub peut aider l'attaquant à cet égard.
Si, par exemple, quelqu'un décide de pirater Tesla, il peut bien commencer à étudier l'entreprise à partir de cette page:
https://api.github.com/orgs/teslamotors/members
Et même si une entreprise n'utilise pas GitHub comme plateforme git, il y a encore quelque chose de précieux à trouver sur GitHub. Il suffit qu'au moins un des salariés de l'entreprise utilise cette plateforme, par exemple, pour un projet domestique. Si quelque chose de secret sur une entreprise apparaît dans le code de ce projet (ou dans l'histoire de git), cela suffira à pénétrer les systèmes de cette entreprise.
Garder une trace de l'historique complet des modifications apportées à chaque projet est la nature de git. À la lumière des problèmes de sécurité, ce fait joue un rôle énorme. En d'autres termes, chaque modification apportée au code par quiconque a accès à l'un des systèmes d'une organisation met cette organisation en danger.
▍Pourquoi cela se produit-il?
- Les entreprises ne vérifient pas les vulnérabilités de leurs systèmes.
- , , .
- , , ( , , 1%), ( — git, , , ).
- , . .
▍ GitHub
Il existe des "dorks" - des requêtes de recherche spéciales qui utilisent différentes capacités des moteurs de recherche pour trouver ce qui est lié à certaines données. Voici une liste intéressante de recherches similaires pour Google par exploit-db.com.
Si vous souhaitez approfondir ce sujet, et je vous recommande de le faire, avant de vous donner une courte liste des chaînes utilisées pour trouver des clés et des mots de passe sur GitHub, je vous suggère de lire ce matériel précieux, écrit par un chercheur talentueux en sécurité des systèmes. Il explique comment, quoi et où rechercher sur GitHub, comment utiliser dorks et décrit en détail le processus manuel de recherche de données secrètes.
Les routes utilisées sur GitHub ne sont pas aussi complexes que celles utilisées sur Google. Le point ici est que GitHub n'offre tout simplement pas à l'utilisateur les mêmes capacités de recherche avancées que Google. Quoi qu'il en soit, une recherche appropriée dans les référentiels GitHub peut faire des merveilles. Essayez de rechercher dans le référentiel qui vous intéresse les lignes suivantes:
password
dbpassword
dbuser
access_key
secret_access_key
bucket_password
redis_password
root_password
Et si vous essayez de rechercher des fichiers spécifiques à l'aide de requêtes telles que
filename:.npmrc _authou filename:.htpasswd, vous pouvez filtrer les résultats de la recherche par types de fuites de données. Voici un autre bon article sur ce sujet.
▍Mesures d'atténuation des risques liées à GitHub
- Intégrez l'analyse de votre code à la recherche de vulnérabilités dans le processus CI. L'excellent outil GitRob peut vous aider .
- . GitRob . ,
no-expand-orgs. - . GitRob, , 500 , ,
-commit-depth <#number>. - GitHub !
- , , , , . G Suite Active Directory. , .
Après la publication de ce matériel, certains de ses lecteurs ont fait de précieux commentaires concernant la complexité des mots de passe et leur rotation, ainsi que l'utilisation de la protection matérielle des informations.
Voici les commentaires de @ codemouse92 :
Utilisez des mots de passe complexes et uniques partout où la connexion par mot de passe est utilisée. Mais gardez à l'esprit qu'un mot de passe complexe n'est pas nécessairement un mélange mystérieux de lettres, de chiffres et de caractères spéciaux. La meilleure stratégie consiste maintenant à utiliser de longues phrases comme mots de passe. Je voudrais faire une remarque sur les gestionnaires de mots de passe. Même s'il vaut vraiment la peine d'utiliser de tels programmes, il est toujours préférable d'utiliser des mots de passe, qui sont des phrases dont les utilisateurs se souviennent et peuvent entrer eux-mêmes.
Voici ce que dit l'utilisateur @corymcdonald :
Là où je travaille, tout le monde reçoit du matériel d'authentification multifacteur. Chacun a 2 appareils YubiKey. De plus, chaque équipe utilise le gestionnaire de mots de passe 1Password et chaque équipe possède son propre coffre-fort de mots de passe. Lorsqu'un employé quitte l'entreprise, l'équipe d'assistance effectue une rotation des mots de passe dans chaque coffre-fort auquel l'employé a accès. Personnellement, j'ai, par exemple, commis une erreur impardonnable en publiant les clés pour accéder à AWS sur GitHub. Il est recommandé de vérifier les matériaux à l'aide de git-secrets avant de valider . Cela empêchera le partage de ce qui ressemble à des informations classifiées.
Les pirates utilisent Google
Maintenant que nous avons une compréhension de base des dorks, nous pouvons parler de l'utilisation de requêtes de recherche spécifiques sur Google. Ici, vous pouvez trouver des choses incroyables avec leur aide. Google est un moteur de recherche puissant qui vous permet de créer des requêtes décrivant des chaînes qui devraient et ne devraient pas être présentes dans les données que vous recherchez. Google, entre autres, vous permet de rechercher des fichiers avec certaines extensions, peut rechercher des domaines spécifiques, des URL. Jetez un œil à la chaîne de recherche suivante:
"MySQL_ROOT_PASSWORD:" "docker-compose" ext:yml
Cette chaîne est conçue pour rechercher des fichiers avec l'extension.De
ymlplus, il doit s'agir de fichiers docker-composedans lesquels les développeurs stockent souvent des mots de passe. Pas de mots de passe particulièrement uniques. Essayez d'exécuter une recherche Google pour cette chaîne. Vous serez surpris par ce que vous trouverez.
D'autres chaînes de recherche intéressantes peuvent rechercher des clés RSA ou des informations d'identification AWS. Voici un autre exemple:
"-----BEGIN RSA PRIVATE KEY-----" ext:key
Ici, des possibilités infinies s'ouvrent devant nous. La qualité de la recherche dépend uniquement du niveau de créativité du chercheur et de sa connaissance des différents systèmes. Voici une longue liste de Google Dorks si vous souhaitez expérimenter.
Les hackers scrutent les systèmes qui les intéressent
Lorsqu'un chercheur en sécurité (ou un hacker motivé) est très intéressé par un certain système, il commence à étudier le système en profondeur. Il apprend à la connaître de près. Il s'intéresse aux terminaux d'API, aux conventions de dénomination des entités, aux particularités d'interaction des parties internes des systèmes, à la disponibilité d'accès aux différentes versions du système si différentes versions de celui-ci sont utilisées simultanément.
Une approche moins bonne pour sécuriser les API consiste à compliquer les chemins d'accès, à les masquer en utilisant quelque chose comme un générateur de caractères aléatoires. Cela ne remplace pas de véritables mécanismes de sécurité. Les chercheurs en sécurité tentent de trouver des chemins d'accès non sécurisés aux systèmes, aux points de terminaison d'API, par exemple, en utilisant des outils de recherche «floue» de vulnérabilités. Ces outils utilisent des listes de mots, construisent des chemins à partir d'eux et valident ces chemins en analysant les réponses qu'ils reçoivent lorsqu'ils tentent d'y accéder. Un tel scanner ne trouvera pas de point de terminaison, dont le chemin est représenté par un jeu de caractères complètement aléatoire. Mais ces outils sont parfaits pour identifier des modèles et trouver des points de terminaison que les propriétaires du système ont oubliés ou ignorés.
N'oubliez pas que «la sécurité par l'obscurité» n'est pas la meilleure façon de protéger les systèmes (bien que vous ne devriez pas l'ignorer complètement).
C'est là que les dorks GitHub, dont nous avons parlé plus haut, viennent en aide aux attaquants. Savoir quelles règles sont utilisées lors de la construction de chemins vers les points de terminaison du système (par exemple, quelque chose comme
api.mydomain.com/v1/payments/...) peut être d'une immense aide pour un pirate informatique. La recherche de chaînes liées à l'API dans le référentiel GitHub de l'entreprise (et dans les référentiels de ses employés) trouvera souvent des chemins contenant des caractères aléatoires.
Mais les "chaînes aléatoires" ont néanmoins leur place dans les systèmes. Leur utilisation est toujours meilleure que l'utilisation de séquences à partir d'identificateurs de ressources, de chaînes similaires
userset dans les chemins d'accès à l'API orders.
Voici le formidable référentiel SecLists, qui contient de nombreuses chaînes utilisées lors de la dénomination des entités. Il est utilisé par presque tout le monde dans l'industrie de la protection des données. Souvent, ces matériaux sont modifiés pour un système spécifique. Un autre outil qui peut être utilisé pour trouver des chemins «chiffrés» est FFuf , un programme de logique floue extrêmement rapide écrit en Go.
Résultat
Les problèmes de sécurité sont souvent négligés dans les startups. Les programmeurs et les responsables accordent généralement la priorité à la vitesse de développement et à la fréquence des versions de produits, sacrifiant la qualité et la sécurité. Ici, nous voyons l'inclusion d'informations secrètes dans le code qui entre dans les référentiels, l'utilisation des mêmes clés à différents endroits du système, l'utilisation de clés d'accès où vous pouvez utiliser autre chose. Parfois, il peut sembler que quelque chose comme cela vous permet d'accélérer le travail sur le projet, mais, avec le temps, cela peut entraîner de très mauvaises conséquences.
Dans cet article, j'ai essayé de vous montrer comment les chaînes qui semblent être protégées en étant stockées dans un référentiel privé peuvent facilement devenir publiques. Il en va de même pour un clone du référentiel, réalisé par un employé bien intentionné et non destiné aux regards indiscrets, mais qui s'est avéré public. Mais vous pouvez créer une base pour un fonctionnement sécurisé en utilisant un outil de partage de mot de passe sécurisé, en utilisant un référentiel centralisé de secrets, en configurant des stratégies de sécurité de mot de passe et une authentification multifacteur. Cela permettra, sans ignorer la sécurité, de ne pas ralentir la vitesse de travail sur le projet.
Lorsqu'il s'agit de protéger les informations, l'idée que la vitesse est la chose la plus importante ne fonctionne pas très bien ici.
Acquérir des connaissances sur le fonctionnement des pirates est généralement une très bonne première étape pour comprendre ce qu'est la sécurité de l'information. C'est la première étape vers la sécurisation des systèmes. Lors de la sécurisation des systèmes, tenez compte des méthodes ci-dessus pour les pénétrer et du fait que les pirates utilisent un ensemble assez limité de telles méthodes. Il est recommandé de considérer du point de vue de la sécurité absolument tout ce qui, d'une manière ou d'une autre, est lié à un certain système, qu'il s'agisse de mécanismes externes ou internes.
La sécurité du système peut parfois être perçue comme peu importante, mais chronophage et mouvementée. Mais rassurez-vous, les étapes simples que vous prenez pour sécuriser vos systèmes peuvent vous éviter beaucoup de problèmes.
Comment protégez-vous vos systèmes?
