Les bases de données modernes stockent toutes sortes de données. Du trivial au très sensible. Les restaurants que nous fréquentons, nos emplacements sur carte, nos informations d'identification (par exemple, numéros de sécurité sociale, adresses, dossiers médicaux, informations bancaires, etc.), et tout le reste sont plus que probablement stockés dans une base de données quelque part. Pas étonnant que les données soient si précieuses.
Les technologies de base de données progressent à un rythme effréné. L'innovation, la progression, l'intégrité et les améliorations sont au premier plan, résultat direct du travail d'ingénieurs, de développeurs et de communautés intelligentes et dévouées qui soutiennent ces fournisseurs.
Pourtant, il y a un autre revers à la médaille. Cela, malheureusement, coexiste dans ce monde axé sur les données sous la forme de logiciels malveillants, de virus et d'exploits à une échelle massive et sans précédent.
Les données sont également précieuses pour les parties de ce côté de l'opération. Mais pour des raisons différentes. N'importe lequel d'entre eux pourrait être, mais sans s'y limiter, le pouvoir, le chantage, le gain financier et l'accès, le contrôle, le plaisir, les farces, la malveillance, le vol, la vengeance... Vous voyez l'idée. La liste est interminable.
Hélas, nous devons fonctionner avec un état d'esprit de sécurité. Sans cet état d'esprit, nous laissons nos systèmes vulnérables à ces types d'attaques. PostgreSQL est tout aussi sensible à la compromission, à l'utilisation abusive, au vol, à l'accès/au contrôle non autorisé que d'autres formes de logiciels.
Alors, quelles mesures pouvons-nous prendre pour atténuer le nombre de risques liés à nos installations PostgreSQL ?
Je suis convaincu que la promotion de la sensibilisation aux menaces connues est un bon point de départ. La connaissance est le pouvoir et nous devons utiliser tout ce qui est à notre disposition. De plus, comment pouvons-nous surveiller ce dont nous ne sommes même pas conscients afin de renforcer la sécurité sur ces instances PostgreSQL et de protéger les données qui y résident ?
J'ai récemment recherché des "préoccupations" et des "menaces" de sécurité connues, ciblant l'environnement PostgreSQL. Ma recherche a englobé des rapports, des articles et des articles de blog récents au cours du premier trimestre de 2018. En plus de cette période spécifique, j'ai exploré des problèmes de longue date bien connus qui sont encore des menaces viables aujourd'hui (à savoir l'injection SQL), bien qu'ils ne soient pas polis. ou brandi comme 'découvert récemment '.
Une séance photo
Une plongée profonde dans les attaques de bases de données [Partie III] :pourquoi la photo de Scarlett Johansson a permis à ma base de données Postgres de commencer à exploiter Monero
La nouvelle de cette attaque malveillante astucieuse a renvoyé le plus de "coups" de mes résultats de recherche objectifs.
Nous visiterons l'un des nombreux articles de blog et un aperçu de son contenu. J'ai également inclus des articles de blog supplémentaires vers la fin de cette section, alors assurez-vous de visiter ceux qui détaillent également cette intrusion.
Observations
Les informations d'Imperva rapportent que leur base de données honeypot (StickyDB) a découvert une attaque de malware sur l'un de leurs serveurs PostgreSQL. Le filet de pot de miel, comme Imperva nomme le système, est conçu pour inciter les attaquants à attaquer la base de données afin qu'ils (Imperva) puissent en savoir plus et devenir plus sécurisés. Dans ce cas particulier, la charge utile est un logiciel malveillant qui cryptomine Monero, intégré dans une photo de Scarlett Johansson.
La charge utile est vidée sur le disque au moment de l'exécution avec la fonction lo_export. Mais apparemment, cela se produit parce que lo_export est une entrée dans pg_proc par rapport à un appel normalement direct (lo_export).
Détails intéressants directement du billet de blog ici pour une clarté extrême (voir l'article cité),
Désormais, l'attaquant est capable d'exécuter des commandes système locales à l'aide d'une fonction simple :fun6440002537. Cette fonction SQL est un wrapper pour appeler une fonction en langage C, "sys_eval", une petite fonction exportée dans "tmp406001440" (un binaire basé sur sqlmapproject), qui agit essentiellement comme proxy pour invoquer des commandes shell à partir du client SQL.
Quelles seront donc les prochaines étapes de l'attaque ? Quelques reconnaissances. Il a donc commencé par obtenir les détails du GPU en exécutant lshw -c video et a continué à cat /proc/cpuinfo afin d'obtenir les détails du CPU (Figures 3-4). Bien que cela semble étrange au début, cela prend tout son sens lorsque votre objectif final est d'exploiter davantage votre crypto-monnaie préférée, n'est-ce pas ?
Avec une combinaison d'accès à la base de données et la possibilité d'exécuter du code à distance, tout en "volant sous le radar ' des solutions de surveillance, l'intrus télécharge ensuite la charge utile via une photo de Scarlett Johansson.
(Remarque :la photo a depuis été supprimée de son emplacement d'hébergement. Voir l'article de lien pour la mention.)
Selon le rapport, la charge utile est au format binaire. Ce code binaire a été ajouté à la photo afin de passer pour une photo réelle lors du téléchargement, permettant une image visible.
Voir la figure 6 de la publication pour le SQL responsable de l'utilisation de wget, dd et de l'exécution de chmod pour les autorisations sur le fichier téléchargé. Ce fichier téléchargé crée ensuite un autre exécutable qui est responsable de l'extraction du Monero. Bien sûr, le ménage et le nettoyage sont nécessaires après tout ce travail infâme.
La figure 7 illustre le SQL en cours d'exécution.
Imperva recommande de surveiller cette liste de zones de violation potentielles dans la section de clôture :
- Méfiez-vous des appels PostgreSQL directs à lo_export ou des appels indirects via des entrées dans pg_proc.
- Méfiez-vous des fonctions PostgreSQL appelant des binaires en langage C.
- Utilisez un pare-feu pour bloquer le trafic réseau sortant de votre base de données vers Internet.
- Assurez-vous que votre base de données n'est pas associée à une adresse IP publique. Si c'est le cas, limitez l'accès uniquement aux hôtes qui interagissent avec lui (serveur d'application ou clients appartenant à des administrateurs de base de données).
Imperva a également effectué divers tests antivirus ainsi que des détails sur la façon dont les attaquants peuvent potentiellement localiser les serveurs PostgreSQL vulnérables. Bien que je ne les ai pas inclus ici par souci de brièveté, consultez l'article pour plus de détails sur leurs conclusions.
Lecture recommandée
- Imperva a 2 articles précédents qui accompagnent la partie 3 (celui dont il est question ici). Bien que ceux-ci ne ciblent pas fortement PostgreSQL comme ce que nous venons de passer sous silence, ce sont des lectures très informatives :
- Partie 1
- Partie 2
- L'attaque du logiciel malveillant Scarlett Johansson PostgreSQL
- Les pirates ciblent les bases de données PostgreSQL avec Coinminer caché dans l'image de Scarlett Johannsson
- Un fil Hacker News sur l'exploit.
Détails, rapport et vulnérabilités CVE
J'ai visité ce site, qui publie les dernières menaces de sécurité par fournisseur et a découvert 4 vulnérabilités au premier trimestre de 2018. La page d'informations sur la sécurité de PostgreSQL les répertorie également, alors n'hésitez pas à consulter cette ressource.
Bien que la plupart d'entre eux aient été abordés, j'ai estimé qu'il était important de les inclure dans cet article pour sensibiliser les lecteurs qui ne les connaissaient peut-être pas. Je sens que nous pouvons apprendre de chacun d'eux. Notamment dans les différentes manières de découvrir les vulnérabilités.
Ils sont listés ci-dessous par ordre de date de publication :
Je. CVE-2018-1052 date de publication 2018-02-09 :Date de mise à jour 3/10/2018
Présentation :
Une vulnérabilité de divulgation de mémoire dans le partitionnement de table a été trouvée dans PostgreSQL 10.x avant 10.2, permettant à un attaquant authentifié de lire des octets arbitraires de la mémoire du serveur via une insertion spécialement conçue dans une table partitionnée.
Cette vulnérabilité a été corrigée avec la sortie de PostgreSQL 10.2 confirmée ici. Les anciennes versions 9.x également corrigées sont également mentionnées, alors visitez ce lien pour vérifier votre version spécifique.
II. CVE-2018-1053 publié le 09/02/2018 :Date de mise à jour 15/03/2018
Présentation :
Dans PostgreSQL 9.3.x avant 9.3.21, 9.4.x avant 9.4.16, 9.5.x avant 9.5.11, 9.6.x avant 9.6.7 et 10.x avant 10.2, pg_upgrade crée un fichier dans le répertoire de travail actuel contenant la sortie de `pg_dumpall -g` sous umask qui était en vigueur lorsque l'utilisateur a invoqué pg_upgrade, et non sous 0077 qui est normalement utilisé pour d'autres fichiers temporaires. Cela peut permettre à un attaquant authentifié de lire ou de modifier le fichier unique, qui peut contenir des mots de passe de base de données chiffrés ou non chiffrés. L'attaque est irréalisable si un mode répertoire bloque l'attaquant qui recherche dans le répertoire de travail actuel ou si le umask dominant bloque l'attaquant ouvrant le fichier.
Comme avec la précédente CVE-2018-1052, PostgreSQL 10.2 a corrigé cette partie de la vulnérabilité :
Assurez-vous que tous les fichiers temporaires créés avec "pg_upgrade" ne sont pas lisibles par le monde
De nombreuses anciennes versions de PostgreSQL sont affectées par cette vulnérabilité. Assurez-vous de visiter le lien fourni pour toutes ces versions répertoriées.
III. CVE-2017-14798 date de publication 01/03/2018 :Date de mise à jour 26/03/2018
Présentation :
Une condition de concurrence dans le script d'initialisation de PostgreSQL pourrait être utilisée par des attaquants capables d'accéder au compte PostgreSQL pour élever leurs privilèges à root.
Bien que je n'ai trouvé nulle part sur la page de liaison la mention de la version 10 de PostgreSQL, de nombreuses versions plus anciennes le sont, alors visitez ce lien si vous utilisez des versions plus anciennes.
Les utilisateurs de Suse Linux Enterprise Server peuvent être intéressés par 2 articles liés ici et ici où cette vulnérabilité a été corrigée pour le script d'initialisation de la version 9.4.
IV. CVE-2018-1058 date de publication 02/03/2018 :Date de mise à jour 22/03/2018
Présentation :
Une faille a été trouvée dans la manière dont PostgreSQL permettait à un utilisateur de modifier le comportement d'une requête pour d'autres utilisateurs. Un attaquant disposant d'un compte utilisateur pourrait utiliser cette faille pour exécuter du code avec les permissions du superutilisateur dans la base de données. Les versions 9.3 à 10 sont concernées.
Cette version de mise à jour mentionne cette vulnérabilité avec un document lié intéressant que tous les utilisateurs devraient visiter.
L'article fournit un guide fantastique de la communauté intitulé A Guide to CVE-2018-1058 :Protect Your Search Path qui contient une quantité incroyable d'informations concernant la vulnérabilité, les risques et les meilleures pratiques pour la combattre.
Je ferai de mon mieux pour résumer, mais visitez le guide pour votre propre bénéfice, compréhension et compréhension.
Présentation :
Avec l'avènement de PostgreSQL version 7.3, les schémas ont été introduits dans l'écosystème. Cette amélioration permet aux utilisateurs de créer des objets dans des espaces de noms distincts. Par défaut, lorsqu'un utilisateur crée une base de données, PostgreSQL crée également un schéma public dans lequel tous les nouveaux objets sont créés. Les utilisateurs qui peuvent se connecter à une base de données peuvent également créer des objets dans le schéma public de cette base de données.
Cette section directement issue du guide est très importante (voir l'article cité) :
Les schémas permettent aux utilisateurs d'espacer les noms des objets, de sorte que des objets du même nom peuvent exister dans différents schémas de la même base de données. S'il existe des objets portant le même nom dans différents schémas et que la paire schéma/objet spécifique n'est pas spécifiée (c'est-à-dire schéma.objet), PostgreSQL™ décide quel objet utiliser en fonction du paramètre search_path. Le paramètre search_path spécifie l'ordre dans lequel les schémas sont recherchés lors de la recherche d'un objet. La valeur par défaut de search_path est $user,public où $user fait référence au nom de l'utilisateur connecté (qui peut être déterminé en exécutant SELECT SESSION_USER;).
Un autre point clé est ici :
Le problème décrit dans CVE-2018-1058 concerne le schéma "public" par défaut et la manière dont PostgreSQL utilise le paramètre search_path. La possibilité de créer des objets avec les mêmes noms dans différents schémas, combinée à la façon dont PostgreSQL recherche des objets dans les schémas, offre à un utilisateur la possibilité de modifier le comportement d'une requête pour d'autres utilisateurs.
Vous trouverez ci-dessous une liste de haut niveau que le guide recommande d'appliquer à ces pratiques comme stipulé pour réduire le risque de cette vulnérabilité :
- Ne pas autoriser les utilisateurs à créer de nouveaux objets dans le schéma public
- Définir le search_path par défaut pour les utilisateurs de la base de données
- Définir le search_path par défaut dans le fichier de configuration PostgreSQL (postgresql.conf)
Injection SQL
Tout 'sur le thème de la sécurité ' Le billet ou l'article de blog SQL ne peut pas se qualifier comme tel sans mentionner l'injection SQL. Bien que cette méthode d'attaque ne soit pas un effort d'imagination 'le petit nouveau sur le bloc ', il doit être inclus.
L'injection SQL est toujours une menace et peut-être encore plus dans l'espace des applications Web. Toute base de données SQL, y compris PostgreSQL, y est potentiellement vulnérable.
Bien que je n'aie pas une base de connaissances approfondie sur l'injection SQL - également connue sous le nom de SQLi - je ferai de mon mieux pour fournir un bref résumé, comment cela peut potentiellement affecter votre serveur PostgreSQL, et finalement comment réduire les risques de tomber en proie à elle.
Reportez-vous aux liens fournis vers la fin de cette section, qui contiennent tous une mine d'informations, d'explications et d'exemples dans les domaines que je ne peux pas communiquer de manière adéquate.
Malheureusement, plusieurs types d'injections SQL existent et ils partagent tous l'objectif commun d'insérer du SQL offensant dans les requêtes à exécuter dans la base de données, peut-être pas initialement prévu ni conçu par le développeur.
Une entrée utilisateur non filtrée, une vérification de type mal conçue ou inexistante (validation AKA), ainsi qu'une entrée utilisateur non échappée, peuvent potentiellement laisser la porte grande ouverte aux attaquants potentiels. De nombreuses API de programmation Web offrent une certaine protection contre SQLi :par exemple, les ORM (Object Relational Mapper), les requêtes paramétrées, la vérification de type, etc. Cependant, il est de la responsabilité du développeur de faire tout son possible et de réduire les principaux scénarios d'injection SQL en implémentant ces diversions et mécanismes à leur disposition.
Voici des suggestions notables pour réduire le risque d'injection SQL à partir de l'OWASP SQL Injection Prevention Cheat Sheet. Assurez-vous de le visiter pour obtenir des exemples détaillés complets d'utilisations dans la pratique (voir l'article cité).
Défenses primaires :
- Option 1 :Utilisation d'instructions préparées (avec requêtes paramétrées)
- Option 2 :Utilisation de procédures stockées
- Option 3 :Validation des entrées de la liste blanche
- Option 4 :Échapper à toutes les entrées fournies par l'utilisateur
Défenses supplémentaires :
- Aussi :Application du moindre privilège
- Aussi :Validation des entrées de la liste blanche en tant que défense secondaire
Lecture recommandée :
J'ai inclus des articles supplémentaires avec une charge d'informations pour une étude plus approfondie et une sensibilisation :
- Qu'est-ce que l'injection SQL ? Ce vieux bonbon peut faire mal à vos applications Web
- Injection SQL (Wikipédia)
- Injection SQL (CLOUDFLARE)
- Injection SQL (w3schools.com)
- Aide-mémoire sur la prévention des injections SQL
- Test d'injection SQL
- Vulnérabilités d'injection SQL et comment les prévenir
- Aide-mémoire sur l'injection SQL
Privilèges de rôle Postgres
Nous avons un dicton pour quelque chose du genre "Nous sommes notre pire ennemi ."
Nous pouvons certainement l'appliquer au travail dans l'environnement PostgreSQL. La négligence, l'incompréhension ou le manque de diligence sont tout autant une opportunité d'attaques et d'utilisations non autorisées que celles lancées délibérément.
Peut-être plus encore, en permettant par inadvertance un accès, des itinéraires et des canaux plus faciles pour les parties fautives.
Je mentionnerai un domaine qui a toujours besoin d'être réévalué ou réévalué de temps en temps.
Privilèges de rôle injustifiés ou superflus.
- SUPERUTILISATEUR
- CRÉATROLE
- CREATEDDB
- Subvention
Cet amalgame de privilèges vaut vraiment le détour. SUPERUSER et CREATROLE sont des commandes extrêmement puissantes et seraient mieux servies entre les mains d'un DBA plutôt que d'un analyste ou d'un développeur, n'est-ce pas ?
Le rôle a-t-il vraiment besoin de l'attribut CREATEDB ? Qu'en est-il de GRANT ? Cet attribut peut être utilisé à mauvais escient entre de mauvaises mains.
Évaluez attentivement toutes les options avant d'autoriser les rôles à ces attributs dans votre environnement.
Stratégies, meilleures pratiques et renforcement
Vous trouverez ci-dessous une liste d'articles de blog, d'articles, de listes de contrôle et de guides utiles qui sont revenus pour une «année en arrière» (au moment de la rédaction de cet article) de résultats de recherche. Ils ne sont pas classés par ordre d'importance et chacun offre des suggestions intéressantes.
- Méthodes simples pour protéger vos serveurs Postgres d'un vecteur d'attaque improbable :une image malveillante de Scarlett Johansson
- Aide à sécuriser votre base de données PostgreSQL
- Ne soyez pas têtu... Renforcez votre base de données PostgreSQL pour garantir la sécurité
- Comment sécuriser votre base de données PostgreSQL – 10 astuces
- Sécuriser PostgreSQL contre les attaques externes
- Privilèges et sécurité PostgreSQL – Verrouillage du schéma public
Conclusion
Dans ce blog, nous avons passé en revue les problèmes de sécurité qui préoccupent les administrateurs PostgreSQL du monde entier :ceux-ci incluent l'injection SQL qui est le Saint Graal de tous les incidents de sécurité, les dérapages dans les approches de base de la gestion des données en toute sécurité, par exemple en ne resserrant pas correctement les autorisations sur votre infrastructure, ainsi que certains problèmes de sécurité moins connus qui pourraient être négligés. En ce qui concerne la sécurité de nos données, il est essentiel que nous prenions et appliquions les conseils de parties de confiance telles qu'Imperva et autres, qui nous fournissent des moyens de nous protéger à la fois des attaques de base et des 0-days (exploits qui n'ont pas encore été connus auparavant), car des conseils réputés sont synonymes d'un bon avenir pour nos bases de données et notre infrastructure dans son ensemble.
Gardez à l'esprit que les mesures de sécurité que nous devons prendre dépendront fortement des vulnérabilités que nous voulons repousser, mais en général, connaître toutes les défenses nécessaires pour repousser l'injection SQL, utiliser correctement privilèges, et toujours essayer de réduire notre niveau de risque lié aux vulnérabilités est crucial. Rester au courant de ce qui se passe dans l'espace de sécurité PostgreSQL nous fera également des merveilles :nous ne pouvons bien défendre nos serveurs (et, par conséquent, nos données) que si nous savons ce que les attaquants pourraient rechercher.
Si vous recherchez d'autres bonnes pratiques pour améliorer la sécurité ou les performances de vos installations PostgreSQL, tournez-vous vers ClusterControl :comme l'outil est développé par des experts de base de données de premier ordre du monde entier, il fera chanter vos bases de données en un rien de temps. Le produit est également livré avec un essai gratuit de 30 jours, alors assurez-vous de ne pas manquer d'essayer toutes les fonctionnalités que ClusterControl peut offrir à votre entreprise et essayez-le dès aujourd'hui.
Pour plus de contenu sur la manière de sécuriser vos instances de base de données PostgreSQL, rendez-vous sur le blog de Manynines pour obtenir des conseils :apprendre à automatiser les audits de sécurité pour PostgreSQL sera certainement un pas dans la bonne direction. Assurez-vous de nous suivre sur Twitter, LinkedIn et abonnez-vous à notre flux RSS pour plus de mises à jour, et nous vous verrons dans la prochaine.
