Moderne Datenbanken speichern alle Arten von Daten. Von trivial bis hochsensibel. Die Restaurants, die wir häufig besuchen, unsere Kartenstandorte, unsere Identitätsnachweise (z. B. Sozialversicherungsnummern, Adressen, Krankenakten, Bankinformationen usw.) und alles dazwischen wird höchstwahrscheinlich irgendwo in einer Datenbank gespeichert. Kein Wunder, dass Daten so wertvoll sind.
Datenbanktechnologien entwickeln sich in einem halsbrecherischen Tempo weiter. Innovation, Fortschritt, Integrität und zahlreiche Verbesserungen stehen an vorderster Front als direktes Ergebnis der Arbeit intelligenter und engagierter Ingenieure, Entwickler und robuster Gemeinschaften, die diese Anbieter unterstützen.
Doch es gibt noch eine andere Seite der Medaille. Das existiert leider in dieser datengesteuerten Welt in Form von Malware, Viren und Exploits in massivem, historischem Ausmaß.
Daten sind auch für die Parteien auf dieser Seite der Operation wertvoll. Aber aus anderen Gründen. Jeder von ihnen könnte sein, ist aber nicht beschränkt auf Macht, Erpressung, finanziellen Gewinn und Zugang, Kontrolle, Spaß, Streiche, Bosheit, Diebstahl, Rache ... Sie verstehen schon. Die Liste ist endlos.
Leider müssen wir mit einer Sicherheitsdenkweise arbeiten. Ohne diese Denkweise machen wir unsere Systeme anfällig für diese Art von Angriffen. PostgreSQL ist genauso anfällig für Kompromittierung, Missbrauch, Diebstahl, unbefugten Zugriff/Kontrolle wie andere Formen von Software.
Welche Maßnahmen können wir ergreifen, um die Anzahl der Risiken für unsere PostgreSQL-Installationen zu mindern?
Ich bin der festen Überzeugung, dass die Förderung des Bewusstseins für bekannte Bedrohungen ein ebenso guter Ausgangspunkt wie jeder andere ist. Wissen ist Macht und wir sollten alles nutzen, was uns zur Verfügung steht. Außerdem, wie können wir etwas überwachen, dessen wir uns nicht einmal bewusst sind, um die Sicherheit auf diesen PostgreSQL-Instanzen zu erhöhen und die dort gespeicherten Daten zu schützen?
Ich habe kürzlich nach bekannten „Sicherheitsbedenken“ und „Bedrohungen“ gesucht, die auf die PostgreSQL-Umgebung abzielen. Meine Suche umfasste aktuelle Berichte, Artikel und Blog-Beiträge aus dem ersten Quartal 2018. Zusätzlich zu diesem bestimmten Zeitrahmen habe ich bekannte, seit langem bestehende Bedenken untersucht, die auch heute noch tragfähige Bedrohungen darstellen (nämlich SQL Injection), wenn auch nicht ausgefeilt oder als 'kürzlich entdeckt geschwungen '.
Eine Gelegenheit zum Fotografieren
Ein tiefer Einblick in Datenbankangriffe [Teil III]:Warum Scarlett Johanssons Bild meine Postgres-Datenbank dazu brachte, mit dem Mining von Monero zu beginnen
Die Nachricht von diesem schlauen Malware-Angriff lieferte die meisten „Treffer“ aus meinen objektiven Suchergebnissen.
Wir besuchen einen von mehreren großartigen Blog-Beiträgen und einen Überblick über seinen Inhalt. Ich habe gegen Ende dieses Abschnitts auch zusätzliche Blog-Posts eingefügt, also besuchen Sie auch diese, in denen dieser Einbruch detailliert beschrieben wird.
Beobachtungen
Informationen von Imperva berichten, dass ihre Honeypot-Datenbank (StickyDB) einen Malware-Angriff auf einen ihrer PostgreSQL-Server entdeckt hat. Das Honeypot-Netz, wie Imperva das System nennt, soll Angreifer dazu verleiten, die Datenbank anzugreifen, damit sie (Imperva) davon erfahren und sicherer werden. In diesem speziellen Fall handelt es sich bei der Nutzlast um eine Malware, die Monero verschlüsselt, eingebettet in ein Foto von Scarlett Johansson.
Die Payload wird zur Laufzeit mit der Funktion lo_export auf die Festplatte ausgegeben. Aber anscheinend geschieht dies, weil lo_export ein Eintrag in pg_proc ist, im Gegensatz zum normalen direkten Aufruf (lo_export).
Interessante Details direkt aus dem Blogpost hier für extreme Klarheit (siehe zitierter Artikel),
Jetzt ist der Angreifer in der Lage, lokale Systembefehle mit einer einfachen Funktion auszuführen – fun6440002537. Diese SQL-Funktion ist ein Wrapper zum Aufrufen einer C-Funktion, „sys_eval“, eine kleine exportierte Funktion in „tmp406001440“ (eine auf sqlmapproject basierende Binärdatei), die im Grunde als Proxy fungiert, um Shell-Befehle vom SQL-Client aufzurufen.
Was werden also die nächsten Schritte des Angriffs sein? Etwas Aufklärung. Es begann also mit dem Abrufen der Details der GPU durch Ausführen von lshw -c video und ging weiter zu cat /proc/cpuinfo, um die CPU-Details abzurufen (Abbildungen 3-4). Auch wenn sich das zunächst seltsam anfühlt, macht es durchaus Sinn, wenn Ihr Endziel darin besteht, mehr von Ihrer Lieblingskryptowährung abzubauen, oder?
Mit einer Kombination aus Datenbankzugriff und der Möglichkeit, Code aus der Ferne auszuführen, während Sie unter dem Radar fliegen ' von Überwachungslösungen lädt der Unbefugte dann die Nutzdaten über ein Foto von Scarlett Johansson herunter.
(Anmerkung:Das Foto wurde inzwischen von seinem gehosteten Speicherort entfernt. Siehe verlinkten Artikel für die Erwähnung.)
Dem Bericht zufolge liegt die Nutzlast im Binärformat vor. Dieser Binärcode wurde an das Foto angehängt, um während des Hochladens als tatsächliches Foto durchzugehen und ein sichtbares Bild zu ermöglichen.
Siehe Abbildung 6 des Beitrags für die SQL, die für die Verwendung von wget, dd und die Ausführung von chmod für Berechtigungen für die heruntergeladene Datei verantwortlich ist. Diese heruntergeladene Datei erstellt dann eine weitere ausführbare Datei, die für das eigentliche Mining von Monero verantwortlich ist. Natürlich sind nach all dieser schändlichen Arbeit Haushalt und Aufräumen erforderlich.
Abbildung 7 zeigt die Ausführung von SQL.
Imperva empfiehlt, diese Liste potenzieller Verletzungsbereiche im abschließenden Abschnitt zu überwachen:
- Achten Sie auf direkte PostgreSQL-Aufrufe an lo_export oder indirekte Aufrufe durch Einträge in pg_proc.
- Vorsicht vor PostgreSQL-Funktionen, die Binärdateien der Sprache C aufrufen.
- Verwenden Sie eine Firewall, um ausgehenden Netzwerkverkehr von Ihrer Datenbank zum Internet zu blockieren.
- Stellen Sie sicher, dass Ihrer Datenbank keine öffentliche IP-Adresse zugewiesen ist. Wenn dies der Fall ist, beschränken Sie den Zugriff nur auf die Hosts, die damit interagieren (Anwendungsserver oder Clients im Besitz von DBAs).
Imperva führte auch verschiedene Antivirus-Tests durch, zusammen mit Einzelheiten darüber, wie Angreifer möglicherweise anfällige PostgreSQL-Server lokalisieren können. Obwohl ich sie der Kürze halber hier nicht aufgeführt habe, konsultieren Sie den Artikel für alle Details ihrer Ergebnisse.
Empfohlene Lektüre
- Imperva hat 2 vorhergehende Artikel, die Teil 3 begleiten (der hier besprochene). Diese zielen zwar nicht so stark auf PostgreSQL ab, wie wir es gerade beschönigt haben, aber sie sind sehr informative Lesevorgänge:
- Teil 1
- Teil 2
- Der Scarlett Johansson PostgreSQL-Malware-Angriff
- Hacker zielen auf PostgreSQL-DBs mit Coinminer ab, der in Scarlett Johannsson Image versteckt ist
- Ein Hacker News-Thread zum Exploit.
CVE-Details, Bericht und Schwachstellen
Ich habe diese Website besucht, auf der die neuesten Sicherheitsbedrohungen pro Anbieter veröffentlicht werden, und im ersten Quartal 2018 vier Sicherheitslücken entdeckt. Auf der Seite mit den PostgreSQL-Sicherheitsinformationen sind sie ebenfalls aufgeführt, also können Sie diese Ressource gerne konsultieren.
Obwohl die meisten von ihnen angesprochen wurden, hielt ich es für wichtig, diese in diesen Beitrag aufzunehmen, um Leser, die möglicherweise nichts davon wussten, darauf aufmerksam zu machen. Ich glaube, wir können von allen lernen. Vor allem in den unterschiedlichen Wegen entdeckter Schwachstellen.
Sie sind unten in der Reihenfolge des Veröffentlichungsdatums aufgelistet:
Ich. CVE-2018-1052 Veröffentlichungsdatum 09.02.2018 :Aktualisierungsdatum 10.03.2018
Übersicht:
In PostgreSQL 10.x vor 10.2 wurde eine Speicheroffenlegungs-Schwachstelle bei der Tabellenpartitionierung gefunden, die es einem authentifizierten Angreifer ermöglichte, beliebige Bytes des Serverspeichers über eine speziell erstellte Einfügung in eine partitionierte Tabelle zu lesen.
Diese Schwachstelle wurde mit der hier bestätigten Veröffentlichung von PostgreSQL 10.2 behoben. Ältere 9.x-Versionen, die ebenfalls behoben wurden, werden ebenfalls erwähnt, besuchen Sie also diesen Link, um Ihre spezifische Version zu überprüfen.
II. CVE-2018-1053 Veröffentlichungsdatum 09.02.2018 :Aktualisierungsdatum 15.03.2018
Übersicht:
In PostgreSQL 9.3.x vor 9.3.21, 9.4.x vor 9.4.16, 9.5.x vor 9.5.11, 9.6.x vor 9.6.7 und 10.x vor 10.2 erstellt pg_upgrade eine Datei im aktuellen Arbeitsverzeichnis, die die Ausgabe enthält von `pg_dumpall -g` unter umask, das wirksam war, als der Benutzer pg_upgrade aufrief, und nicht unter 0077, das normalerweise für andere temporäre Dateien verwendet wird. Dies kann es einem authentifizierten Angreifer ermöglichen, die eine Datei zu lesen oder zu ändern, die verschlüsselte oder unverschlüsselte Datenbankkennwörter enthalten kann. Der Angriff ist nicht durchführbar, wenn ein Verzeichnismodus den Angreifer daran hindert, das aktuelle Arbeitsverzeichnis zu durchsuchen, oder wenn die vorherrschende umask den Angreifer daran hindert, die Datei zu öffnen.
Wie beim vorherigen CVE-2018-1052 hat PostgreSQL 10.2 diesen Teil der Schwachstelle behoben:
Stellen Sie sicher, dass alle mit "pg_upgrade" erstellten temporären Dateien nicht weltweit lesbar sind
Viele ältere Versionen von PostgreSQL sind von dieser Schwachstelle betroffen. Besuchen Sie unbedingt den bereitgestellten Link für alle aufgeführten Versionen.
III. CVE-2017-14798 Veröffentlichungsdatum 01.03.2018 :Aktualisierungsdatum 26.03.2018
Übersicht:
Eine Race-Condition im PostgreSQL-Init-Skript könnte von Angreifern verwendet werden, die auf das PostgreSQL-Konto zugreifen können, um ihre Berechtigungen auf root auszudehnen.
Obwohl ich nirgendwo auf der verlinkten Seite finden konnte, dass PostgreSQL Version 10 erwähnt wurde, sind es viele ältere Versionen, also besuchen Sie diesen Link, wenn Sie ältere Versionen ausführen.
Benutzer von Suse Linux Enterprise Server könnten an 2 verlinkten Artikeln hier und hier interessiert sein, in denen diese Schwachstelle für das Init-Skript der Version 9.4 behoben wurde.
IV. CVE-2018-1058 Veröffentlichungsdatum 2018-03-02 :Aktualisierungsdatum 22.03.2018
Übersicht:
Es wurde ein Fehler in der Art und Weise gefunden, wie PostgreSQL es einem Benutzer ermöglichte, das Verhalten einer Abfrage für andere Benutzer zu ändern. Ein Angreifer mit einem Benutzerkonto könnte diesen Fehler ausnutzen, um Code mit den Berechtigungen eines Superusers in der Datenbank auszuführen. Betroffen sind die Versionen 9.3 bis 10.
Diese Update-Version erwähnt diese Schwachstelle mit einem interessanten verlinkten Dokument, das alle Benutzer besuchen sollten.
Der Artikel enthält einen fantastischen Leitfaden der Community mit dem Titel A Guide to CVE-2018-1058:Protect Your Search Path, der eine unglaubliche Menge an Informationen zu Schwachstellen, Risiken und Best Practices zu ihrer Bekämpfung enthält.
Ich werde mein Bestes tun, um zusammenzufassen, aber besuchen Sie den Leitfaden zu Ihrem eigenen Nutzen, Verständnis und Verständnis.
Übersicht:
Mit dem Aufkommen von PostgreSQL Version 7.3 wurden Schemas in das Ökosystem eingeführt. Diese Erweiterung ermöglicht es Benutzern, Objekte in separaten Namespaces zu erstellen. Wenn ein Benutzer eine Datenbank erstellt, erstellt PostgreSQL standardmäßig auch ein öffentliches Schema, in dem alle neuen Objekte erstellt werden. Benutzer, die eine Verbindung zu einer Datenbank herstellen können, können auch Objekte im öffentlichen Schema dieser Datenbank erstellen.
Dieser Abschnitt direkt aus dem Leitfaden ist sehr wichtig (siehe zitierter Artikel):
Schemas ermöglichen es Benutzern, Objekte zu benennen, sodass Objekte mit demselben Namen in verschiedenen Schemas in derselben Datenbank vorhanden sein können. Wenn es Objekte mit demselben Namen in verschiedenen Schemas gibt und das spezifische Schema/Objekt-Paar nicht angegeben ist (d. h. schema.object), entscheidet PostgreSQL, welches Objekt basierend auf der Einstellung search_path verwendet wird. Die Einstellung search_path gibt die Reihenfolge an, in der die Schemas durchsucht werden, wenn nach einem Objekt gesucht wird. Der Standardwert für search_path ist $user,public, wobei sich $user auf den Namen des verbundenen Benutzers bezieht (der durch Ausführen von SELECT SESSION_USER; ermittelt werden kann).
Ein weiterer wichtiger Punkt ist hier:
Das in CVE-2018-1058 beschriebene Problem dreht sich um das standardmäßige „öffentliche“ Schema und darum, wie PostgreSQL die search_path-Einstellung verwendet. Die Möglichkeit, Objekte mit denselben Namen in verschiedenen Schemas zu erstellen, bietet in Kombination mit der Art und Weise, wie PostgreSQL nach Objekten innerhalb von Schemas sucht, die Möglichkeit für einen Benutzer, das Verhalten einer Abfrage für andere Benutzer zu ändern.
Nachfolgend finden Sie eine allgemeine Liste, in der der Leitfaden die Anwendung dieser Praktiken wie vorgeschrieben empfiehlt, um das Risiko dieser Schwachstelle zu verringern:
- Erlauben Sie Benutzern nicht, neue Objekte im öffentlichen Schema zu erstellen
- Legen Sie den standardmäßigen Suchpfad für Datenbankbenutzer fest
- Legen Sie den Standardsuchpfad in der PostgreSQL-Konfigurationsdatei (postgresql.conf) fest
SQL-Injection
Alle 'sicherheitsbezogenen ' Ein SQL-Blogpost oder -Artikel kann sich ohne Erwähnung der SQL-Einschleusung nicht als solcher bezeichnen. Während diese Angriffsmethode keineswegs der Fantasie entspricht, ist „das neue Kind im Block ', muss eingefügt werden.
SQL Injection ist immer eine Bedrohung und vielleicht noch mehr im Bereich der Webanwendungen. Jede SQL-Datenbank – einschließlich PostgreSQL – ist potenziell anfällig dafür.
Ich habe zwar keine umfassende Wissensbasis zu SQL Injection – auch als SQLi bekannt –, aber ich werde mein Bestes tun, um eine kurze Zusammenfassung zu geben, wie sich dies möglicherweise auf Ihren PostgreSQL-Server auswirken kann und wie Sie letztendlich das Risiko verringern können, Opfer zu werden dazu.
Siehe die Links am Ende dieses Abschnitts, die alle eine Fülle von Informationen, Erklärungen und Beispielen in den Bereichen enthalten, die ich nicht angemessen kommunizieren kann.
Leider gibt es mehrere Arten von SQL-Injektionen, die alle das gemeinsame Ziel haben, anstößiges SQL in Abfragen zur Ausführung in der Datenbank einzufügen, die möglicherweise ursprünglich nicht vom Entwickler beabsichtigt oder entworfen wurden.
Nicht bereinigte Benutzereingaben, schlecht gestaltete oder nicht vorhandene Typüberprüfung (AKA-Validierung) sowie nicht maskierte Benutzereingaben können potenziellen Angreifern Tür und Tor öffnen. Viele APIs für die Webprogrammierung bieten einen gewissen Schutz gegen SQLi:z. B. ORMs (Object Relational Mapper), parametrisierte Abfragen, Typprüfung usw. Es liegt jedoch in der Verantwortung des Entwicklers, alle Anstrengungen zu unternehmen und Hauptszenarien für die SQL-Injektion durch Implementierung zu reduzieren diese Ablenkungen und Mechanismen, die ihnen zur Verfügung stehen.
Hier sind bemerkenswerte Vorschläge zur Verringerung des Risikos einer SQL-Injektion aus dem OWASP SQL Injection Prevention Cheat Sheet. Besuchen Sie es auf jeden Fall, um vollständige Beispiele für die Verwendung in der Praxis zu erhalten (siehe zitierter Artikel).
Primäre Verteidigung:
- Option 1:Verwendung vorbereiteter Anweisungen (mit parametrisierten Abfragen)
- Option 2:Verwendung gespeicherter Prozeduren
- Option 3:Eingabevalidierung für weiße Liste
- Option 4:Alle Benutzereingaben maskieren
Zusätzliche Verteidigung:
- Außerdem:Erzwingen der geringsten Berechtigung
- Außerdem:Durchführen der Whitelist-Eingabevalidierung als sekundäre Verteidigung
Empfohlene Lektüre:
Ich habe zusätzliche Artikel mit einer Menge Informationen zum weiteren Studium und zur Sensibilisierung hinzugefügt:
- Was ist SQL-Injection? Dieser Oldie, aber Goodie kann Ihre Webanwendungen beschädigen
- SQL-Injection (Wikipedia)
- SQL-Injection (CLOUDFLARE)
- SQL-Injection (w3schools.com)
- Spickzettel zur Verhinderung von SQL-Einschleusungen
- Testen auf SQL-Injection
- SQL-Injection-Schwachstellen und wie man sie verhindert
- SQL-Injection-Spickzettel
Postgres-Rollenberechtigungen
Wir haben ein Sprichwort für so etwas wie „Wir sind unser eigener schlimmster Feind ."
Wir können es definitiv auf die Arbeit in der PostgreSQL-Umgebung anwenden. Vernachlässigung, Missverständnisse oder mangelnde Sorgfalt sind ebenso eine Gelegenheit für Angriffe und unbefugte Nutzung wie absichtlich gestartete.
Vielleicht sogar noch mehr, indem sie unbeabsichtigt einfacheren Zugriff, Routen und Kanäle für beleidigende Parteien ermöglichen, auf die sie zugreifen können.
Ich erwähne einen Bereich, der von Zeit zu Zeit immer neu bewertet oder neu bewertet werden muss.
Ungerechtfertigte oder irrelevante Rollenberechtigungen.
- SUPERUSER
- CREATROLE
- CREATEDB
- GEWÄHRUNG
Diese Verschmelzung von Privilegien ist auf jeden Fall einen Blick wert. SUPERUSER und CREATROLE sind extrem mächtige Befehle und würden in den Händen eines DBA besser bedient werden als in den Händen eines Analysten oder Entwicklers, finden Sie nicht?
Benötigt die Rolle wirklich das CREATEDB-Attribut? Was ist mit GRANT? Dieses Attribut kann in den falschen Händen missbraucht werden.
Wägen Sie alle Optionen sorgfältig ab, bevor Sie Rollen diese Attribute in Ihrer Umgebung zulassen.
Strategien, Best Practices und Härtung
Unten finden Sie eine Liste nützlicher Blogbeiträge, Artikel, Checklisten und Leitfäden, die für ein „Jahr zurück“ (zum Zeitpunkt des Schreibens dieses Artikels) von Suchergebnissen zurückgegeben wurden. Sie sind nicht nach Wichtigkeit geordnet und bieten jeweils bemerkenswerte Vorschläge.
- Einfache Möglichkeiten, Ihre Postgres-Server vor einem unwahrscheinlichen Angriffsvektor zu schützen:Ein Schurkenbild von Scarlett Johansson
- Bei der Sicherung Ihrer PostgreSQL-Datenbank helfen
- Seien Sie nicht starrköpfig... Härten Sie Ihre PostgreSQL-Datenbank, um die Sicherheit zu gewährleisten
- So sichern Sie Ihre PostgreSQL-Datenbank – 10 Tipps
- Schutz von PostgreSQL vor externen Angriffen
- PostgreSQL-Berechtigungen und -Sicherheit – Sperren des öffentlichen Schemas
Schlussfolgerung
In diesem Blog sind wir die Sicherheitsprobleme durchgegangen, die PostgreSQL-Administratoren auf der ganzen Welt beschäftigen:Dazu gehören die SQL-Injektion, der heilige Gral aller Sicherheitsvorfälle, Ausrutscher bei grundlegenden Vorgehensweisen bei der Handhabung Daten sicher, wie z. B. das Versäumnis, Berechtigungen in Ihrer gesamten Infrastruktur ordnungsgemäß zu verschärfen, und auch einige weniger bekannte Sicherheitsprobleme, die möglicherweise übersehen werden. Wenn es um die Sicherheit unserer Daten geht, ist es wichtig, dass wir Ratschläge von vertrauenswürdigen Parteien wie Imperva und dergleichen annehmen und anwenden, die uns Möglichkeiten bieten, uns sowohl vor einfachen Angriffen als auch vor 0-Days (Exploits, die es noch nicht gegeben hat) zu schützen vorher bekannt) gleichermaßen, denn seriöse Beratung bedeutet eine gute Zukunft für unsere Datenbanken und Infrastruktur insgesamt.
Denken Sie daran, dass die Sicherheitsmaßnahmen, die wir ergreifen müssen, stark von den Schwachstellen abhängen, die wir abwehren wollen, aber im Allgemeinen sollten Sie alle notwendigen Abwehrmaßnahmen kennen, um die SQL-Injektion abzuwehren, und sie richtig einsetzen Privilegien und der ständige Versuch, unser Risikoniveau in Bezug auf Schwachstellen zu reduzieren, ist von entscheidender Bedeutung. Auf dem Laufenden zu bleiben, was im PostgreSQL-Sicherheitsbereich passiert, wird auch für uns Wunder bewirken:Wir können unsere Server (und folglich unsere Daten) nur dann gut verteidigen, wenn wir wissen, worauf die Angreifer hinaus wollen.
Sollten Sie nach weiteren Best Practices zur Verbesserung der Sicherheit oder Leistungsfähigkeit Ihrer PostgreSQL-Installationen suchen, wenden Sie sich an ClusterControl:Da das Tool von erstklassigen Datenbankexperten aus der ganzen Welt entwickelt wird, ist es das Richtige bringt Ihre Datenbanken im Handumdrehen zum Singen. Das Produkt wird auch mit einer kostenlosen 30-Tage-Testversion geliefert, also stellen Sie sicher, dass Sie es nicht verpassen, alle Funktionen auszuprobieren, die ClusterControl für Ihr Unternehmen bieten kann, und probieren Sie es noch heute aus.
Weitere Informationen dazu, wie Sie Ihre PostgreSQL-Datenbankinstanzen schützen sollten, finden Sie im Blog von Multiplenines:Zu lernen, wie Sicherheitsaudits für PostgreSQL automatisiert werden, ist sicherlich ein Schritt in die richtige Richtung. Folgen Sie uns auf Twitter, LinkedIn und abonnieren Sie unseren RSS-Feed für weitere Updates, und wir sehen uns im nächsten.
