Top-Datenbankbedrohungen

Nachfolgend eine Liste der häufigsten Bedrohungen denen Datenbanksysteme heute ausgesetzt sind:

    • Missbrauch legitimer Berechtigungen (Insider Angriffe) – Jeder berechtigte Benutzer kann auch legitime Datenbankberechtigungen für nicht autorisierte Zwecke missbrauchen. Hier gibt es zwei Risiken, die in Betracht zu ziehen sind. Das erste Risiko ist ein böswilliger Benutzer, der Datensätze vielleicht verkaufen möchte. Das zweite sogar häufigere Risiko ist ein fahrlässiger Benutzer, der große Datenmengen aus der Datenbank abruft, auf seinem Client-Gerät zu Arbeitszwecken speichert und die Daten damit Bedrohungen wie Trojanern, Laptopdiebstahl usw. aussetzt.
    • Missbrauch übermäßiger Berechtigungen (Nicht autorisierte Aktionen privilegierter User) – Anwendern bzw. Anwendungen denen Datenbankzugriffberechtigungen erteilt werden, die ihren Aufgabenbereich übersteigen, können diese Berechtigungen u.U. zu böswilligen Zwecken missbrauchen. Z.B. sind Datenbankadministratoren (DBA), die grundsätzlich über erweiterte Rechte zur Erfüllung ihrer Aufgaben verfügen, in der Lage unerkannt Aktivitäten auf der Datenbank durchzuführen, die nicht zur Erfüllung ihren Aufgaben gehören. Häufig werden Datenbankbenutzern auch nur übermäßige Berechtigungen erteilt, weil die Datenbankadministratoren nicht genügend Zeit haben, abgestufte Kontrollmechanismen für die Zugriffsberechtigungen einzelner Benutzer zu definieren und auf dem neuesten Stand zu halten. Die Folge ist, dass allen Benutzern oder großen Benutzergruppen allgemeine Standardzugriffsberechtigungen erteilt werden, die weit über die Anforderungen ihrer Aufgaben hinausgehen.
    • Missbräuchliche Berechtigungserweiterung (Privilegien Eskalation) – Erlangung von umfassenden Zugriffsrechten (z.B. Administrationsberechtigungen) durch einen normalen Benutzer indem Datenbank Schwachstellen ausgenutzt werden (abhängig vom DBMS). Solche Schwachstellen können in gespeicherten Prozedu-ren, integrierten Funktionen, Protokollimplementierungen und sogar in SQL-Statements auftreten. Mit diesen Berechtigungen könnte der böswillige Benutzer anschließend Prüfmechanismen umgehen, Daten manipulieren oder stehlen, unerlaubte Transaktionen durchführen etc.
    • Ausnutzen von Schwachstellen fehlerhaft konfigurierter Datenbanken – In der Praxis finden sich sehr häufig Datenbanken mit nicht gepatchten Schwachstellen und solche mit Standardkonten und Konfigurationsparameter. Angreifer werden Systeme typischerweise auf diese Schwachstellen hin prüfen, sodass hier die Gefahr einer Sicherheitsverletzung gegeben ist. Zudem ist während der Zeit, in der ein Datenbankanbieter einen Patch für eine bestimmte Schwachstelle entwickelt, die Datenbank einer Organisation nicht gegen Angreifer geschützt. Und selbst wenn ein Patch freigegeben worden ist, steht dieser u.U. noch nicht sofort zur Verfügung. Grundsätzlich sind beim Patchen einer Datenbank verschiedene Aspekte in Betracht zu ziehen. Zunächst muß eine Organisation den Patchvorgang für das System für diesen bestimmten Patch bewerten und verstehen, welche Auswirkungen sich auf das System ergeben. Der Patch könnte evtl. bereits vorhandenen Code beeinträchtigt oder eine Work-Around-Möglichkeit eröffnen. Zudem verursacht ein Patchvorgang immer Ausfallzeiten, in denen der Datenbankserver nicht für die Benutzer zur Verfügung steht. Große Unternehmen mit einer großen Anzahl von Datenbanken müssen eine zeitliche Abfolge für das Patching festlegen und Datenbanken eine Priorität zur Behebung der Schwachstelle zuordnen. Daher ist es üblich, dass sich Patching-Vorgänge in vielen Organisationen über Monate hinziehen – typischerweise werden zwischen 6 und 9 Monate benötigt (basierend auf von der Independent Oracle User Group – IOUG* durchgeführten Studien). Beim Patching-Vorgang spielen DBAs, System- und IT-Admins, Entwickler eine Rolle. Aus diesen Gründen bleiben Server oft noch Monate nach der Freigabe eines Patches angreifbar und können von einem Angreifer über Standardkonten und Konfigurationsparameter, die aus einer produktiv genutzten Datenbank nicht ent-fernt worden sind, ausgenutzt werden. Ein Angreifer könnte z.B. versuchen, über ein Standardkonto Zugriff auf die Datenbank zu erlangen. Schwache Audit-Parameter erläuben es einem Angreifer, Audit-Kontrollen zu umgehen oder Spuren seiner Aktivitäten zu verwischen. Schwache Authentifizierungsschemata ermöglichen es Angreifern, die Identität legitimer Datenbankbenutzer anzunehmen, indem Anmeldeinformationen gestohlen oder anderweitig erhalten werden, Nutzung eines Exploits, um Zugang zur OS Shell zu erhalten. Darüber kann dann der Code von Services/Daemons in der Art geändert werden, dass die zugreifenden Controls, Auditing oder Authentication Mechanismen deaktiviert werden. (abhängig vom DBMS)
    • SQL Injection – Bei einem SQL-Injection-Angriff werden typischerweise nicht autorisierte Datenbank-Statements in einen angreifbaren SQL-Datenkanal wie gespeicherte Prozeduren und Eingabeparameter von Web-Applikationen eingeleitet. Diese eingefügten Statements werden anschließend zur Datenbank weitergegeben und dort ausgeführt, wodurch Angreifer uneingeschränkten Zugriff zur gesamten Datenbank erlangen können.
    • Unzureichender Audit-Trail – Elementarer Bestandteil jeder Datenbankimplementierung sollte sein, alle vertraulichen und/oder ungewöhnlichen Datenbanktransaktionen automatisch aufzuzeichnen. Schwache Datenbank-Audit-Richtlinien stellen auf vielen Ebenen ein ernsthaftes organisatorisches Risiko dar.
      • Regulatorisches Risiko – Organisationen mit schwachen oder fehlenden Datenbank-Audit-Mechanismen werden zunehmend feststellen, dass sie behördlichen Regulierungsanforderungen nicht entsprechen.
      • Abschreckung –Datenbank-Audit-Mechanismen dienen dazu, Angreifer abzuschrecken, weil sie wissen, dass Datenbank-Audit-Aufzeichnungen Ermittlern Beweismaterialien liefern, um Eindringlin-gen eine Straftat nachzuweisen.
      • Erkennung und Wiederherstellung –Sicherheitsverletzungen können nach ihrem Auftreten durch Audit-Daten identifiziert werden und dienen der Zuordung zu bestimmten Anwendern und/oder Reparatur des Systems.
    • Schwachstellen in grundlegenden Audit-Merkmalen – Datenbanksoftware-Plattformen verfügen in der Regel über grundlegende Audit-Merkmale, welche allerdings häufig mehrere Schwachstellen aufweisen, die ihre Implementierung einschränken oder ausschließen.
      • Fehlende Benutzerüberwachung – Wenn Anwender über Web-Applikationen auf Datenbanken zugreifen, lassen sich spezifische Benutzeridentitäten mit nativen Auditmechanismen nicht identifizieren, da die Benutzeraktivitäten dem Web-Applikatios-Account zugeordnet werden. Missbräuchliche Datenbanktransaktionen in nativen Audit Logs lassen sich somit nicht auf den verantwortlichen Anwender zurückverfolgen.
      • Leistungseinbußen – Native Datenbank-Audit-Mechanismen belegen häufig erhebliche CPU- und Festplattenressourcen, weswegen viele Organisationen wegen der auftretenden Leistungseinbußen Audit-Funktionen zurücknehmen oder vollständig deaktivieren.
      • Pflichtentrennung – Anwender mit Administrationsrechten für den Datenbankserver können Audit- Funktionen einfach abschalten, um missbräuchliche Aktivitäten zu verschleiern. Daher sollten Audit-Pflichten idealerweise zwischen Datenbankadministratoren und der Datenbank-Server-Plattform getrennt sein.
      • Begrenzte Granularität –Native Audit-Mechanismen zeichnen häufig nicht alle erforderlichen Details, um Angriffe zu erkennen, den forensischen Nachweis zu führen sowie Systeme wiederherzustellen. Datenbank-Client-Anwendung, Quell-IP-Adressen, Query-Response-Attribute und fehlgeschlagene Abfragen als wichtiger Indikator für Ausspähungen vor einem Angriff werden z. B. von vielen nativen Mechanismen nicht aufgezeichnet.
      • Proprietäre Formate – Da sich Audit-Mechanismen und Logs einzelner Datenbankserver-Plattformen z.T. erheblich voneinander unterscheiden, ist es für Organisationen mit gemischten Datenbankumgebungen nahezu unmöglich, einheitliche, skalierbare Audit-Prozesse über das gesamte Unternehmen hinweg zu implementieren.
    • Denial of Service (DoS) – Dies bezeichnet eine allgemeine Angriffskategorie, in der Angriffe dazu führen, dass berechtigten Anwendern der Zugriff auf Netzwerk-Applikationen und Daten verweigert wird. Denial of Service (DoS)-Zustände lassen sich über zahlreiche verschiedene Techniken hervorrufen, wobei viele dieser Techniken die bereits erwähnten Schwachstellen ausnutzen. Ein DoS lässt sich z. B. verursachen, indem Schwachstellen der Datenbankplattform genutzt werden, um einen Server zum Absturz zu bringen (z.B. Initiierung von Buffer Overflows). Weitere verbreitete DoS-Techniken sind die Kompromittierung von Daten, eine Überflutung des Netzwerks mit Netzwerkverkehr und eine Überlastung von Serverressourcen (Speicher, CPU usw.). Ressourcenüberlastungen treten besonders häufig in Datenbankumgebungen auf. Die Motivationen, die hinter DoS-Angriffen stecken, sind ähnlich vielfältig. DoS-Angriffe kommen häufig in Zusammenhang mit Erpressungsversuchen vor, in denen ein Remote-Angriffs-Server die Datenbank wiederholt zum Absturz bringt, bis das Opfer Gelder auf ein internationales Bankkonto überweist. In anderen Fällen lassen sich DoS-Zustände auf eine Wurm-Infektion zurückführen. Unabhängig von der Ursache stellen DoS-Angriffe für viele Organisationen eine ernsthafte Bedrohung dar.
    • Schwachstellen im Datenbankkommunikationsprotokoll – In Datenbankkommunikationsprotokollen aller Datenbankanbieter werden immer mehr Sicherheitsschwachstellen entdeckt, wobei in den jeweiligen nativen Audit-Trails keine Aufzeichnungen dieser Aktivitäten vorhanden sind, weil sie Protokolloperationen nicht abdecken. Missbräuchliche Aktivitäten, die auf diese Schwachstellen abzielen, reichen von nicht autorisierten Zugriffen auf Daten bis zu Datenkompromittierungen und DoS-Angriffen.
    • Nicht autorisierte Kopien vertraulicher Daten – Häufig werden nicht alle Datenbanken ordnungsgemäß erfasst und gewartet. Neue Datenbanken werden erstellt ohne dass das Sicherheitsteam Kenntnis von diesen Datenbanken weiß. Werden nun vertrauliche Daten wie Transaktions-, Kunden- und Mitarbeiterdetails in diese Datenbanken kopiert werden, sind diese einem Sicherheitsrisiko ausgesetzt, sofern die erforderlichen Kontrollen nicht implementiert werden. Ein weiteres Beispiel sind alte Datenbanken, die vergessen und nicht in die Bewertung einbezogen wurden.
    • Unzureichend geschützte Backup-Daten – Oft sind Speichermedien mit Datenbank-Backups völlig ungeschützt. In der Vergangenheit wurden immer wieder Fälle bekannt, in denen Bänder und Festplatten von Datenbank-Backups gestohlen worden sind, was zu ernsthaften Sicherheitsverletzungen geführt hat.
    • Angriffe per Web Applikation – Applikationen, die mit einer Datenbank im Hintergrund arbeiten, können kompromittiert werden, um Zugriffsrechte zu erweitern und damit umfassenden Zugriff auf die Datenbankresourcen zu erlangen (z. B. per SQL Injection). Hier ist es notwendig, dass die Database Activity Monitoring Lösung statt dem Applikationsaccounts auch Zugriff auf den wirklichen Verursacher der Aktion hat.
    • Zugriff auf OS Ressourcen per Datenbankangriff – z.B. ermöglicht die Änderung des UTL_FILE_DIR Parameters bei Oracle der Prozedur SYS.UTL_FILE wichtige Files auf dem Betriebssystem zu überschreiben oder Daten zu extrahieren.
    • Password Angriffe („BruteForce-Attacken“) – Hier wird versucht Passworte zu erraten, indem zahlreiche Zei-chenkombinationen per Skript am DBMS ausprobiert werden oder DB Schwachstellen werden ausgenutzt.
    • Cross Site Scripting (XSS) – Zugriff auf die Datenbank durch Diebstahl von Logoninformationen von legitimen Benutzern einer Webapplikation indem Userdaten in der Datenbank gespeichert werden und später anderen Usern auf der Website unverschlüsselt angezeigt werden.

Obwohl Datenbankinformationen somit vielen verschiedenen Angriffen ausgesetzt sind, ist es dennoch möglich, Risiken durch eine Konzentration auf die wichtigsten Bedrohungen, erheblich zu reduzieren. Wenn es Organisationen gelingt, den oben beschriebenen wichtigsten Bedrohungen mittels geeigneten Maßnahmen wie gelebten Berechtigungskonzepten, Erfüllung der Anforderungen an sichere Datenbanksysteme, dem Einsatz von Database Activity Monitoring Lösungen etc.  zu begegnen, erfüllen sie damit globale Compliance-Anforderungen und bewährte Industriestandards bezüglich Datenschutz und Risikominimierung.

Schreibe einen Kommentar