Archiv für das Monat: Dezember, 2016

Die Anbindung von LDAP-Verzeichnis und SSL-PKI an die Oracle Datenbank waren bereits Thema in diesem Blog. Im folgenden Artikel geht es um eine Projektstudie, in der wir für einen Kunden die dort verwendeten Authentifikationsverfahren (Passwörter, Wallets) sowie einige neue (Kerberos, PKI) analysiert und bewertet haben.

Passwörter und deren Hashes in der Datenbank

Wie Passwörter von direkten Benutzern in der Oracle Datenbank geändert werden, ist jedem DBA bekannt: Über ALTER USER IDENTIFIED BY wird direkt in SQL ein neues Passwort gesetzt.

Oracle erzeugt aus dem Klartext-Passwort eine kryptographische Quersumme, einen sogenannten Hash, der im Allgemeinen möglichst die Eigenschaft haben soll, kollisionsfrei zu sein, also zu gewährleisten, das keine zwei unterschiedlichen Passwörter zu einem gleichen Hash führen. Außerdem darf es natürlich nicht möglich sein, aus dem Hash auf das verwendete Passwort zurückzuschliessen.

Es wurden im Laufe der Versionshistorie der Oracle Datenbank verschiedene Algorithmen verwendet:

Die Datenbank legt die Hashes in der Tabelle SYS.USER$, in der Spalte SPARE4 ab. Ein Datenbankbenutzer mit Lese-Rechten auf diese Spalte kann sie auslesen und entweder direkt für die Authentifikation verwenden oder versuchen, das Original-Passwort herauszufinden.

Führt das gleiche Passwort stets zum gleichen Hash-Wert, ist es mit Hilfe von Abbildungslisten, sogenannten Rainbow Tables, möglich, aus einem bekannten Hash rückwärts auf das Original-Passwort zu schließen. Um dies zu verhindern, kann ein sogenanntes Salt verwendet werden, ein möglichst zufälliger Wert, der dem Passwort vor dem Ermitteln des Hash-Wertes zugeführt wird.

DES

Der Algorithmus DES wurde in den Versionen 6 bis 10gR2 verwendet. Er stammt von Bob Baldwin, der auch die Windows NT und VMS Algorithmen entworfen hat, und wurde 1993 veröffentlicht. Er lautet:

Passwörter in Oracle Wallets

Übersicht

Oracle bietet mit den Wallets einen PKCS#12-basierten Container an, in dem neben Passwörtern auch SSL-Zertifikate hinterlegt werden können. Hat ein Anwender oder ein Skript Lese-Zugriff auf die Wallet-Datei und gegebenenfalls das Wallet-Passwort, kann er das Zertifikat auslesen und sich damit an der Datenbank anlegen. Eine weitere Passwort-Abfrage ist nicht mehr nötig.

Um auch automatisiert mit Wallets arbeiten zu können, gibt es die Auto-Login-Funktion. Wird diese aktiviert, wird eine zusätzliche Datei im Wallet erzeugt, die sogenannte Single Sign On Datei (.sso). Diese ist ebenfalls verschlüsselt, aber nicht mit einem benutzerdefinierten Passwort, sondern mit einem Standard-Passwort. Auto-Login-Wallets werden in der Regel verwendet, um eine automatisierte Anmeldung an der Datenbank durchführen zu können, ohne dass ein Passwort im Klartext in Skripten, Konfigurationsdateien oder Umgebungsvariablen abgelegt werden muss.

Damit es nicht möglich ist, ein Wallet einfach zu kopieren und von einem anderen Rechner aus zu verwenden, gibt es die Auto-Login-Local-Funktion. Wird diese für ein Wallet eingestellt, so kann das Auto Login Wallet nur auf dem Rechner verwendet werden, auf dem es erzeugt wurde.

Sicherheit und Einführungsvorraussetzungen

Leider hat die Auto Login Funktion den Nachteil, das das Passwort, mit dem die SSO-Datei verschlüsselt ist, ja irgendwo herkommen muss. Entweder ist es immer gleich, oder…. es ist irgendwo in den Wallet-Dateien versteckt.

Tatsächlich ist es einfach im Header der cwallet.sso-Datei selbst abgelegt:

0x00 - 0x4C     Header:
    0x00 - 0x02     First 3 bytes are always A1 F8 4E (wallet recognition?)
    0x03            Type = SSO: 36; LSSO: 38
    0x04 - 0x06     00 00 00
    0x07            Version (10g: 05; 11g:  06)
    0x08 - 0x0A     00 00 00
    0x0B - 0x0C     11g: always the same (41 35)
    0x0D - 0x1C     DES key
    0x1D - 0x4C     DES secret (DES -> CBC -> PKCS7 padding) which contains the PKCS#12 password
    0x4D - EOF      PKCS#12 data (ASN.1 block)

Das Auslesen des internen Schlüssels eines Oracle AutoLogin Wallets ist mit einfachen Mitteln möglich, beispielsweise mit dem Tool ssoDecrypt. Danach kann ein neues, vollständiges Wallet (.p12-Datei) erzeugt und mit dem erhaltenen Schlüssel geöffnet werden. Auch der Kopierschutz ist nun nicht mehr wirksam.

$ ./ssoDecrypt.sh ../PX-Linux11/cwallet.sso 
sso key: c29XXXXXXXXXX96
sso secret: 71c61e1XXXXXXXXXX99c77d747fa0f53e79ccd170409964b
p12 password (hex): 1e482XXXXXXXXXX1f1f0b296f6178021c

Auto-Login-Local-Wallets funktionieren über einen String, der mit HMAC SHA1 gehashed wird, um das PKCS#12-Passwort zu erhalten. Der String besteht aus dem Benutzernamen und dem Servernamen des Rechners, auf dem das Wallet erstellt wurde.

Die Wallets müssen auf den Datenbanken und allen teilnehmenden Clients verteilt werden, was einen beträchtlichen administrativen Aufwand erfordert (siehe unten).

LDAP

Nutzung von individuellen Datenbank-Anmeldungen

Grundvoraussetzung für den Einsatz von Verzeichnisservern, sowohl für LDAP, Kerberos der SSL, ist die Einführung von individuellen Datenbank-Anmeldungen für jeden Anwender, Administrator und (Applikations-)Server, soweit noch nicht geschehen. Der Vorteil ist, dass Zugriffe innerhalb der Datenbank klar identifiziert und Rechte feingranular auf Benutzerebene erteilt werden können. Werden Sammel-Konten verwendet, beispielsweise, indem sich alle Administratoren als SYSTEM anmelden, kann nur über Umwege oder gar nicht ermittelt werden kann, welche Person sich hinter der jeweiligen Anmeldung verbirgt. Die so erteilten Berechtigungen lassen sich später nicht mehr auf individueller Basis entziehen, denn jeder Anwender kann sich die Passwörter gemerkt haben. Das Passwort eines solchen geteilten Kontos muss also nach jeder Änderung im Personalstamm geändert werden, was wiederum zu erheblichem Aufwand führt, ohne das Grundproblem zu beheben.

Eine bessere Methode ist das Einführen individueller Konten für jeden zugreifenden Applikationsserver und jeden Benutzer in der Datenbank. Diese können entweder als lokaler Datenbank-Benutzer oder über Enterprise User Security (EUS) in einem Verzeichnis angelegt werden. Die mit dem bisherigen Sammelkonto verbundenen Rechte für den Zugriff auf Datenbankobjekte (Beispielsweise Tabellen, Views oder Packages) werden nun durch entsprechende Berechtigungen (grants) innerhalb der Datenbank erteilt. Zur Vereinfachung werden hier Rollen verwendet. Dies geschieht nach dem Grundsatz, dass die Tabellen selbst möglichst immer einem Schema-Owner gehören, der selbst möglichst kein Anmelderecht (CONNECT) besitzt. Alle Zugriffe erfolgen durch entsprechende Rechte (SELECT, UPDATE, INSERT…) an die entsprechende Rolle (etwa Entwickler, Administrator, Anwender) und darüber an den Benutzer selbst. Die Rechte-Einschränkung funktioniert nur, wenn der Schema-Owner kein Anmelderecht mehr besitzt, da die Rechte auf Objekte, die einem Konto gehören, in der Oracle Datenbank generell nicht eingeschränkt werden können. Die Software-Installation, also das massenweise Verändern der Datenbankobjekte des Schema-Owners, kann über ein Mitglied der DBA-Rolle erfolgen. Dieses kann, falls es erforderlich ist, das Schema-Owner-Konto auch temporär für die direkte Anmeldung freischalten (den Account entsperren). Im Rahmen dieser Änderung werden zu verwendende Objekte zukünftig vollständig angegeben („select * from scott.emp“). Sollte eine bestehende Anwendung die Objekte zwingend im gleichen Schema erwarten, kann dies über öffentliche Synonyme behandelt werden. Diese ermöglichen es jedem Konto, die Objekte, für die Synonyme eingerichtet sind, weiterhin mit relativen Namen anzusprechen („select * from emp“).

Transportverschlüsselung über SSL

Um den Sicherheitsgewinn der Auslagerung der Authentifikation aus der Datenbank ausschöpfen zu können, sollte die  Verbindung zwischen Client und Datenbank über das Netzwerk verschlüsselt werden. Hierfür wird SSL verwendet. Für die Datenbank und die Oracle-Clients werden Zertifikate erstellt, entweder selbstsigniert oder mit der unternehmensweiten PKI.

Die Transportverschlüsselung schützt gegen unerlaubtes Mitschneiden des Datenflusses zwischen Anwender-PC bzw. Applikationsserver und der Datenbank und wäre als Grundschutz-Maßnahme auch ohne die Umsetzung der hier beschriebenen Konzepte auch alleinstehend sinnvoll. Die Verwaltung der Zertifikate erfolgt mit Hilfe von Oracle-Wallets, die auf dem Client bereits vorhanden sind. War früher die Advanced Security Option (ASO) als Oracle-Lizenz erforderlich, ist dies mittlerweile nicht mehr erforderlich.

Einrichtung

Die Anbindung der Datenbank an AD als LDAP-Server wirft das Problem auf, wo die Passwort Hashes für die Oracle Datenbank gespeichert werden sollen. Ein AD-Server erzeugt ersteinmal nur seine eigenen (NTLM) Passwort-Hashes. Die Oracle-Hashes können im AD abgelegt werden, dazu muss das AD-LDAP-Schema allerdings erweitert und auf dem AD-Server eine zusätzliche Software-Komponente installiert werden. Dies ist in der Regel im Unternehmen schwierig durchzusetzen. Alternativ kann ein weiterer Verzeichnisserver neben den AD-Server gestellt werden, der die Schema-Erweiterungen für Oracle, den sogennten OracleContext, verwaltet. Hierfür wird in der Regel das Produkt Oracle Universal Directory (OUD) verwendet. Auch die Enterprise User Security Informationen können hier abgelegt werden.

Für Details zu dieser Installation in WebLogic und 12c siehe: Configure EUS with OUD, AD and DB12c.

Die wesentlichen Schritte für die Registrierung der Oracle Datenbank an einem LDAP-Server lassen sich im Datenbank-Konfigurationsassistent DBCA vornehmen. Zusätzlich muss die TNS- und SQLNet-Konfiguration der Datenbank geändert werden. Die Kommunikation zwischen Datenbank und LDAP-Server sollte wie die zwischen Datenbank und Clients SSL-verschlüsselt werden.

Anwendung

Danach kann sich ein Benutzer anmelden, dessen Anmeldeverfahren als GLOBAL oder EXTERNAL im LDAP-Namensraum eingerichtet worden ist.

Eine noch zentralere Struktur wird durch Enterprise User Security (EUS) erreicht. Hier werden in der Datenbank globale Rollen definiert, die mit einem Gruppen-Element im Verzeichnis korrespondieren. Ein im LDAP angelegter Benutzer kann sich in einer EUS-Umgebung direkt mit seinen LDAP-Credentials an der Datenbank anmelden und ist dort als ein bestimmer, der Verzeichnisgruppe zugewiesener globaler Benutzer eingeloggt. Dieses Verfahren kommt mit einer minimalen Konfiguration in der Datenbank selbst aus, lediglich die globalen Rollen müssen einmalig angelegt werden. Über den einzelnen Benutzer selbst muss in der Datenbank keine Information konfiguriert werden.

Einrichtungsaufwand in der Praxis

Ist ein Oracle-kompatibler LDAP-Server bereits vorhanden und ein OracleContext bereits vorhanden, ist das Einbinden einer weiteren Datenbank eine Sache von unter einer Stunde. Hinzu kommt das Einrichten der globalen oder externen Benutzer, bzw. das Ändern von lokalen Benutzern auf eine externe Authentifikation. In größeren Umgebungen mit vielen ähnlichen Datenbanken lassen sich diese Aufgaben gegebenenfalls skripten.

Das Einbinden einer weiteren Datenbank in eine bereits existierende Umgebung mit LDAP-Infrastuktur (OUD) und Enterprise User Security (EUS) sowie entsprechenden globalen Rollen kann mit einem einzelnen Skriptaufruf in Minuten passieren.

Muss die gesamte LDAP- und EUS-Struktur erst aufgebaut werden, erreicht das Projekt je nach Redunganzanforderungen an die Directory-Server leicht eine Laufzeit von Wochen und Monaten – insbesondere, wenn die Verzeichnisserver hoch verfügbar und mit einer gegenseitigen Replikation aufgebaut werden sollen. Wird (ausschließlich) EUS mit globalen Rollen verwendet, kann sich kein Anwender mehr anmelden, wenn die Verzeichnisserver nicht erreichbar sind.

Angriffsvektoren

Wird die SSL-Transportverschlüsselung verwendet, sind keine erfolgreichen Angriffsmethoden über das Netzwerk mehr bekannt. Ein Angriff, der das Auslesen und Knacken der Passwort Hashes zum Ziel hat, ist ebenfalls sinnlos, da sich keine Passwort Hashes mehr in der Datenbank befinden.

Ohne Transportverschlüsselung ist ein Angriff auf die Session Keys möglich, wenn im LDAP-Verzeichnis SHA1-Passwörter abgelegt sind.

Kerberos

Funktionsweise

Die Anmeldung für die einzelnen Benutzer ist mit im Active Directory vorhandenen Konten möglich. Hierzu werden die Datenbankserver in die Active-Directory-Domäne aufgenommen. Die Authentifikation der einzelnen Benutzer erfolgt über vom AD-Server gestellte Kerberos-Tickets. Die Datenbank-Konten werden „externally“ authentifiziert angelegt.

Vorbedingung für die Lösung ist, das sämtliche Anwender, aber auch sämtliche Datenbanken, Datenbank-Server, Applikations-Server in das Active Directory Verzeichnis eingetragen werden. Auch für alle Skripte oder Programme, die sich an der Datenbank anmelden sollen, müssen entsprechende technische Benutzerprofile im Verzeichnis angelegt werden.

Einrichtung

Zunächst muss im Active Directory ein SPN/Benutzer für die Datenbank eingerichtet werden:

Als nächstes wird eine Service Key Table für den Datenbank-Server angelegt:

PS C:\Users\Administrator> ktpass.exe -princ oracle/ioaotow01.tested.lcl@TESTED.LCL -mapuser ioaotow01 -crypto RC4-HMAC-NT -pass XXX -out c:\ioaotow-hmac2.keytab -ptype KRB5_NT_PRINCIPAL

Für die Nutzung zur Datenbank-Anmeldung müssen einige Parameter in der TNS-Konfiguration der Datenbank selbst angepasst werden:

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = /app/db1
SQLNET.KERBEROS5_KEYTAB=/app/kerberos/keytab
SQLNET.KERBEROS5_CONF=/app/kerberos/krb5.conf
SQLNET.KERBEROS5_CONF_MIT=TRUE
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=oracle
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)

Dann muss eine Kerberos-Konfigurationsdatei krb5.conf angelegt werden:

[libdefaults]
default_realm = PKILAB
[realms]
PKILAB = {
kdc = ad.loopback.org:88
}
[domain_realm]
.pkilab = PKILAB
pkilab = PKILAB

Nach diesen Änderungen werden die Listener durchgestartet.
Es ist nun möglich, einen Datenbank-Benutzer anzulegen, der über Kerberos authentifiziert wird:

[oracle~]$ sqlplus "/ AS SYSDBA"

SQL > create user "TEST" identified externally as 'TEST@LOOPBACK.ORG'; 
SQL > grant CONNECT TO TEST;

Nun kann getestet werden, ob wir über ein Kerberos Ticket verfügen und uns anmelden können:

[oracle~]$ okinit test Kerberos Utilities for Linux: Version 11.2.0.4.0 - Production Copyright (c) 1996, 2013 Oracle.  All rights reserved.
Password for test@LOOPBACK.ORG: ...
[oracle~]$ oklist Kerberos Utilities for Linux: Version 11.2.0.4.0 - Production Copyright (c) 1996, 2013 Oracle.  
All rights reserved. 
Ticket cache: /tmp/krb5cc_501 
Default principal: test@LOOPBACK.ORG    
Valid Starting           Expires            Principal 
22-Aug-2015 11:24:27  22-Aug-2015 19:17:27  krbtgt/LOOPBACK.ORG@LOOPBACK.ORG 
[oracle~]$ sqlplus / SQL >show user USER is TEST

Damit ist die Datenbank für AD-Benutzer an der Datenbank ermöglicht. Für Details zur Konfiguration von Kerberos in der Datenbank 12c siehe: Neuer Kerberos Stack: AD Authentifikation für Datenbank 12c.

Die Datenbank-Clients müssen entsprechend konfiguriert werden.

Anwendung

Die Datenbank-Anmeldung über Kerberos ist eine für die Datenbank externe Authentifizierung über das Betriebssystem. Meldet sich der ein Benutzer an seinem Arbeitsplatz (-PC) an, erhält er ein Kerberos-Ticket, das eine passwortlose Anmeldung an entsprechend eingerichteten Datenbanken ermöglicht. Für im Hintergrund laufende Prozesse, etwa auf Applikationsservern, ist es notwendig, das das Kerberos-Ticket vom Betriebssystem zur Verfügung gestellt (also vom AD-Server geholt) und aktuell gehalten wird. Außerdem müssen, wie oben beschrieben, entsprechende technische Konten im AD angelegt werden, die den Betriebssystem-Konten (Unix-Useraccounts) entsprechen, unter denen die Applikationen laufen.

Einrichtungsaufwand

Die Einbindung einer Datenbank an eine bestehenden Kerberos-Infrastruktur mit Windows Active Directory Servern selbst ist zwar etwas „tricky“, wenn das Verfahren aber einmal entwickelt worden ist, in wenigen Stunden erledigt.

Der Aufbau der AD-Infrastruktur und die Einbindung der Windows Arbeitsplätze in die Domäne ist sicherlich nicht für ein Datenbank-Sicherheits-Projekt planbar. die Kerberos-Anbindung lohnt sich nur, wenn diese bereits vollständig vorhanden ist.

Soll EUS verwendet werden, gilt das im Abschnitt LDAP geschriebene: Je nach Redundanz-Anforderungen ist sicherlich eine mehrwöchige Aufbauphase einzuplanen. Statt EUS können auch Skripte zum Einsatz kommen, die periodisch für jeden im Verzeichnis eingetragenen Benutzer extern authentifizierte Datenbank-Benutzer anlegen. Diese können mit Linux-Bordmitteln (Puppet) ausgerollt werden.

Der Aufbau eines Proof Of Concept in einem Linux-Labor mit Red Hat FreeIPA als Kerberos-Server, Windows-PCs und Linux-Workstations als Arbeitsplätze und Linux DB12c Datenbank hat ohne Vorbereitung eine Woche gedauert.

Angriffsvektoren

Angriffe auf Datenbank Hashes und Sesion Keys sind gegenstandslos, da sich keine Hashes in der Datenbank befinden. Die oben erwähnten Angriffe auf Session Keys funktionieren ebenfalls nicht, da keine Session Keys verwendet werden, sondern Kerberos-Tokens, die im Client-Betriebssystem vorhanden sind und an die Datenbank weitergereicht werden.

Für einen erfolgreichen Angriff muss das Kerberos-Ticketsystem angegriffen werden. Auf Kerberos 5 im Allgemeinen und die Windows-Implementation im Besonderen sind eine Reihe von Angriffen bekannt:

• Mimikatz Golden Ticket Attack
• Pass the Hash / Pass the Ticket
• CVE-2014-6324 (Hash Vulnerability)
• Time Stamp Replay Attack

Die Sicherheit der Datenbank-Anmeldungen liegt hier aber im Betriebssystem bzw. wird durch die Domänen-Sicherheit verantwortet und muss nicht separat vom Sicherheits-Team im Datenbank-Team betrachtet werden – alles dies stellt in der Praxis vieler Unternehmen einen beträchtlichen organisatorischen Vorteil dar.

SSL-PKI

Die Authentifikation über Active Directory hat den Nachteil, das jeder Anwender zwar nur noch ein Passwort hat, dieses auch an einer zentralen Stelle verwaltet wird, aber eben immer noch eingegeben werden muss. Eine ganz andere, auch ergänzend einsetzbare Möglichkeit, Authentifizierung aus der Datenbank selbst auszulagern, besteht in der Nutzung einer Public Key Infrastruktur (PKI). Hierfür müssen Benutzerzertifikate erstellt und verteilt werden, die von einer zentralen Autorität als gültig erklärt und signiert worden sind.

Architektur

Eine Public Key Infrastructure (PKI) regelt die Verteilung von Vertrauen in einer Organisation. Eine zentrale Stelle, die sogenannte Certification Authority (CA), beglaubigt die Identitäten von Mitarbeitern, Maschinen oder auch die Authentizität von Dokumenten, indem sie diese digital unterschreibt (signiert). Die CA besteht aus einem Handling-Mechanismus beziehungsweise damit betrauten Mitarbeitern sowie einem öffentlichen Wurzel-Zertifikat und einem geheimen Schlüssel. Mit diesem Schlüssel signiert sie die Zertifikate der zu beglaubigenden Dokumente. Mit Hilfe des öffentlichen Wurzelzertifikates (Root-CA Zertifikat) kann die Echtheit der Unterzertifikate von allen beteiligten Parteien geprüft und bestätigt werden. Ihre Autorität kann die CA auch delegieren, um zum Beispiel das Ausstellen von Zertifikaten für einen Unterbereich der Organisation von einer untergeordneten CA durchführen zu lassen. Hierzu erhält diese Sub-CA ein Zwischenzertifikat der Root-CA.

Dieser Mechanismus ist durch SSL bekannt und wird im Internet als Standard für die allgemeine Authentizitätsprüfung von Webseiten und Emails verwendet. Hier ist allerdings das Problem, das es keine allgemein anerkannte Instanz gibt, die überhaupt genügend allgemeines Vertrauen besitzt, um die Identität der beteiligten Parteien glaubhaft zu bestätigen. Der Aufbau des Internet sieht keine Legitimation im Rahmen von beispielsweise Domain-Vergabe (NIC) oder Domain Name System (DNS) vor. Es gibt daher in Desktop-Betriebssystemen und Web-Browsern eine stattliche Liste von staatlichen oder auch privaten CAs, denen diese vertrauen. Wie die Praxis gezeigt hat, ist dieses Vertrauen oft nicht gerechtfertigt gewesen, daher ist das ganze System von SSL-Zertifikaten öffentlich in Verruf geraten und in weiten Teilen nutzlos geworden. Eventuell existiert im Unternehmen allerdings bereits eine CA, die die notwendige Autorität besitzt.

Die Mitarbeiter können ein eigenes Zertifikat, das von der CA unterschrieben wird, erhalten. Genauer gesagt erstellen sie einen Antrag auf Zertifizierung (Certification Request), der als Datei erstellt wird. Dieser wird von der CA signiert und in Form des individuellen Zertifikates an den Benutzer ausgegeben. In der Regel wird dieser Prozess im Format X.509 implementiert, einem ITU-Standard für eine Public-Key-Infrastruktur zum Erstellen digitaler Zertifikate. X.509 beinhaltet außerdem einen Standard für die Handhabung von widerrufenen Zertifikaten über Rückruflisten (Revocation Lists). X.509-Zertifikate werden verbreitet im PKCS#12-Format als Datei gespeichert oder im PKCS#11-Format auf Token oder Smartcards aufgebracht. Die PKCS-Familie ist ein RSA-Standard und definiert eine Reihe von Methoden für den Umgang mit digitalen Zertifikaten.

Es existieren eine Reihe von Software-Produkten für die Implementation einer PKI. Ebenso ist es möglich, den Prozess mit Hilfe von OpenSSL komplett ohne kommerzielle Software abzubilden. Außerdem existieren mehrere Open Source PKI Lösungen. Oft ist die CA bereits durch die AD Domänen Administration vorhanden und in Betrieb.

SSL-PKI Anmeldung an der Datenbank mit Wallets

Oracle bietet mit den Wallets einen PKCS#12-basierten Container an, in dem neben Passwörtern auch SSL-Zertifikate hinterlegt werden können. Hat ein Anwender oder ein Skript Lese-Zugriff auf die Wallet-Datei und gegebenenfalls das Wallet-Passwort, kann er das Zertifikat auslesen und sich damit an der Datenbank anlegen. Eine weitere Passwort-Abfrage ist nicht mehr nötig.

Für eine zertifikatsbasierte Anmeldung muss zunächst auf dem Datenbank-Server ein Wallet angelegt werden:

$ orapki wallet create -wallet $ORACLE_BASE/admin/loopds/pki -auto_login -pwd XXX

Nun muss ein Request erstellt und exportiert werden:

$ orapki wallet add -wallet $ORACLE_BASE/admin/loopds/pki -dn 'CN=db12c' -keysize 2048 -pwd XXX

$ orapki wallet export -wallet $ORACLE_BASE/admin/loopds/pki -dn 'CN=db12c' -request ~/db12c.csr

Nach dem Signieren des Requests durch die CA wird das gelieferte User Certificate zusammen mit der Root-CA, dem sogenannten Trusted Certificate, importiert:

$ orapki wallet add -wallet $ORACLE_BASE/admin/loopds/pki -cert myca.pem –trusted_cert –pwd XXX

$ orapki wallet add -wallet $ORACLE_BASE/admin/loopds/pki -cert db12c.pem –user_cert –pwd XXX

Als nächstes werden auf dem Datenbank-Client (PC oder Applikationsserver) ebenfalls ein Wallet und ein Request erzeugt und exportiert:

$ orapki wallet create -wallet $ORACLE_HOME/owm/wallets/client -auto_login -pwd XXX

$ orapki wallet add -wallet $ORACLE_HOME/owm/wallets/client -dn 'CN=jans' -keysize 2048 -pwd XXX

$ orapki wallet export -wallet $ORACLE_HOME/owm/wallets/client -dn 'CN=jans' -request ~/jans.csr

Nachdem die CA den Request signiert hat, können User und Trusted Certificate auch hier importiert werden:

$ orapki wallet add -wallet $ORACLE_HOME/owm/wallets/client \ -cert myca.pem –trusted_cert –pwd XXX

$ orapki wallet add -wallet $ORACLE_HOME/owm/wallets/client \ -cert jans.pem –user_cert –pwd XXX

Nun muss das Wallet zur Benutzung noch in der TNS-Konfiguration von Datenbank und Client eingetragen werden:

SSL_CLIENT_AUTHENTICATION = TRUE
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = $ORACLE_BASE/admin/loopds/pki)
)

Außerdem sind einige weitere Einstellungen in sqlnet.ora, tnsnames.ora und listener.ora erforderlich:

SQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)
NAMES.DIRECTORY_PATH= (TNSNAMES, HOSTNAME)

SSL_VERSION = 0
SSL_SERVER_DN_MATCH = Yes
(SECURITY =
(SSL_SERVER_CERT_DN="CN=db12c"))

Für Details zu dieser Konfiguration siehe: Enterprise Security mit LDAP und PKI

Benutzer müssen als EXTERNAL oder GLOBAL angelegt werden, um sich anmelden zu können:

SQL> create user JANS identified externally as 'CN=jans';
SQL> grant create session to JANS;

Nun kann sich der User, der Zugriff auf das oben angelegte Client Wallet besitzt, direkt anmelden:

$ sqlplus /@DB12C
Connected.
SQL>

Die Verbindung zur Datenbank kann mit sqlplus, OCI oder JDBC erfolgen. Die Konfiguration des SQL Developer mit SSL-Wallets ist in MOS Note: 401251 beschrieben.

Wallet- und Zertifikats-Verteilung

Die SSL Zertifikate für Transportverschlüsselung und SSL-Authentifikation (PKI) werden in Wallets abgelegt. Diese Wallets müssen ausgerollt und gewartet werden. Für SSL-Transportverschlüsselung und Server-Authentifikation muss mit der Installation einmalig ein Wallet eingerichtet werden, dass den Server authentifiziert. Für die Benutzer-Authentifikation muss ein individuelles Zertifikat vorhanden sein, wenn der Anwender, beispielsweise der Entwickler, sich an der Datenbank anmelden möchte.

Wallet-Installation auf Client und Server

Die pro Rechner notwendigen Oracle Wallets werden mit der Installation der Oracle-Software zusammen angelegt. Sie sind statisch und bleiben über die Lebensdauer der Oracle-Software-Installation gleich.

Zertifikate für die Oracle-Installation

Sie beinhalten den Request (und damit den Schlüssel) für die Identität des Rechners, auf dem sie installiert sind, und das von der CA ausgestellte Zertifikat. Der Prozess der Zertifikatsanforderung wird nach der Installation der Oracle Software wie oben beschrieben durchgeführt. Die notwendigen ORAPKI-Aufrufe können als ein Skript bereitgestellt werden.

Zertifikate für Anwender

Individuelle Zertifikate für Entwickler und Administratoren werden von der CA bereitgestellt. Es ist unter Umständen möglich, sie in den Oracle Wallets zu referenzieren. Hierzu wird im Wallet ein Pseudo-Eintrag hinterlegt, der auf das im Betriebssystem vorhandene Zertifikat verweist. Im Fall eines PKCS#11-Zertifikates funktioniert dies beispielsweise so:

orapki wallet p11_add -wallet . -p11_lib "c:\Windows\System32\opensc-pkcs11.dll" -pwd Oracle1234

Domänen-Windows-Clients bekommen bei der Anmeldung an der AD-Domäne automatisch Zertifikate zugewiesen. Diese sind im Windows-Zertifikatsstore zu finden. Für die Benutzer werden zur Zeit noch keine Zertifikate verteilt. Dies ist aber technisch möglich und kann in der AD-Konfiguration eingeschaltet werden. Zum Erlangen eines Zertifikates muss es im Windows Certificate Manager des Clients entsprechend angefordert werden. Der Prozess kann so eigerichtet werden, das er ohne Verwaltungstätigkeit des AD-Teams funktioniert. In der AD CA kann auch konfiguriert werden, das ein Benutzerzertifikat automatisch erstellt wird (Autoenrollment). Für die Linux-Clients in der Entwickler-Cloud funktioniert das AutoEnrollment an der PKI zur Zeit nicht. Hier muss eine separate Lösung gefunden werden. Eventuell eignet sich ein Ansatz über das Linux Identity Management System mit Hilfe der DogTag CA als Subsidiary der PKI CA.

Neuverteilung von Wallets und Credentials

Im Fall einer Neuverteilung von Wallets oder Zertifikaten können vonhandene Werkzeuge zum Rollout verwendet werden. Hier bieten sich Puppet und Cloud Control (Enterprise Manager) an.

Aufwand für die Installation

Die Einrichtung der SSL-Infrastruktur, der CA in allen Arbeitsplätzen ist erheblich. An jedem Arbeitsplatz muss ein Oracle-Wallet installiert werden, in dem die Zertifikate der CA importiert werden, sowie ein Zertifikat erstellt werden, das den Benutzer ausweist. Dieses muss von der CA signiert werden. Wir haben im vorgestellten Projekt keine Softwareverteilungs-Lösung gefunden, die das in Windows ausrollen kann. Der Weg, die CA von Active Directory selbst zu verwenden, war am praxistauglichsten. Hier müssen die entsprechenden Regeln zum Erstellen von Benutzer-Zertifikaten eingestellt werden.

Die Einrichtung der Wallet-Infrastruktur in den Datenbanken lässt sich in wenigen Schritten durchführen oder auch automatisiert skripten. Die Zertifikate im Datenbank-Wallet müssen ja nach Ablauffrist erneuert werden. Auch dies lässt sich beispielsweise mit Puppet automatisieren.

Angriffsvektoren

Angriffe auf Hashes und Session Keys sind hier ebenfalls gegenstandslos.

Möglich ist ein Angriff auf das Database Wallet. Ist dieses nicht gegen Veränderung auf Dateisystem-Ebene gesichert, kann die komplette CA ausgetauscht werden, indem ein neues Wallet implantiert wird. Danach kann sich der Angrifer mit selbst ausgestellten Credentials (Schlüsseln) der gefälschten CA anmelden. Um dies zu verhindern, können Hardware-Sciherungsmodule (HSMs) eingesetzt werden, die den Zugriff auf das Wallet phisikalisch erschweren. Dies geschieht in der Regel über SmartCards.

SmartCards

Smartcards können verschiedene Informationen auf einem Medium speichern, das möglichst nicht direkt ausgelesen werden kann. Damit lassen sich die oben beschriebenen SSL-Zertifikate besonders schützen. Interessant ist eine SmartCard-basierte Oracle-Anmeldung vor allem, wenn ein SmartCard-basierter Mitarbeiterausweis im Unternehmen bereits eingeführt ist. Ist dies nicht der Fall, wird alleine die Anmeldung an den Datenbanken in den wenigsten Fällen die Einführung von SmartCards für deren Anwender und/oder Administratoren rechtfertigen können.

Aufwand

Leider sind die Treiber für SmartCards, die sogenannte Middleware, durch jeden Hersteller unterschiedlich implementiert und daher ist die Installation im PC-Betriebssystem nicht ganz einfach. Wird über eine SmartCard-Einführung nachgedacht, ist es auf jeden Fall zielführend, zu untersuchen, ob nicht die Mehrzahl der in der Organisation vorhandenen Anwendungen auf einer Karte vereint werden können – beispielsweise Zugangskontrolle für das Gebäude, Zugriff zum (Virtual-) Desktop, Windows/Linux-Anmeldung und (SSL-)Schlüsselbund.

Der Installationsaufwand für das Einrichten der Oracle-Authentifikation in einer bereits bestehenden Smart-Card-Umgebung mit bereits auf den Karten vorhandenen Zertifikaten zur Anmeldung in Windows entspricht der der oben beschriebenen SSL-Einrichtung plus der Anbindung der Windows-Treiber.

Sicherheit & Angriffsvektoren

Smartcard-basiertes SSL verbindet die Vorteile von passwortlosen Authentifizierungsverfahren (keine Hashes und Session Keys) mit einer physikalischen Sicherungsschicht auf die CA und bietet die höchste Sicherheit der hier vorgestellten Verfahren.

Fazit

Die vorgegebenen Einstellung für das Erzeugen von Passwort-Hashes in der Oracle Datenbank sind nicht immer glücklich gewählt. Gelingt es einem Angreifer, die Hashes der Passwörter, die nicht besonders geschützt in der Datenbank liegen, auszulesen, ist es in der Regel möglich, die Original-Passwörter zu errechnen. Noch verheerender wirken sich Angriffe auf den Verbindungsaufbau zur Datenbank aus.

Auch in Oracle Passwort Wallets oder anderen Passwort-Managern sind Passwörter nicht sicher aufgehoben.

Eine zusätzliche Gefahr ergibt sich aus der mehrfachen Nutzung gleicher Passwörter für verschiedene Zugänge, die unter Umständen für unterschiedliche Sicherheitsklassen funktionieren. Das Management von verschiedenen Zugangskennungen pro Person ist hier komplex und hochproblematisch.

Eine Alternative bieten zentrale Identitätsverwaltungs-Systeme. In der hier vorgenommenen Analyse wurden ActiveDirectory/LDAP, Kerberos und SSL/Smartcards in der Anwendbarkeit für Entwickler-Zugriffe und die Authentifikation von maschinellen Zugriffen verglichen. Für den Entwicklerzugriff hat die Identifikation über Kerberos/Active Directory die besten Ergebnisse erzielt, für die Absicherung der maschinellen Zugriffe haben sich SSL-Zertifikate als am interessantesten herausgestellt. Ihr gesamtes Potenzial entfalten diese Systeme allerdings erst zusammen mit der zentralen Verwaltung von Rechten und Rollen mit Oracle Enterprise User Security.

Für die Sicherheit von Anmeldungen ist eine SSL-PKI auf SmartCards erste Wahl. Aber auch mit Kerberos in Active Directory lassen sich sehr gute Lösungen aufbauen – mit deutlich weniger Aufwand, aber etwas größerer Angriffsoberfläche im Betriebssystem. Für maschinelle Anwendungen sind SSL-Zertifikate in Datenbank-Wallets gut geeignet, da kein Passwort eingegeben werden muss.

Soll kein Microsoft Active Directory Kerberos verwendet werden, ist FreeIPA in Linux eine gute Alternative.

Weiterführende Literatur

• Trustwave: Changes in Oracle Database 12c password hashes
• Oracle: Oracle Advanced Security Technical White Paper
• Esteban Martínez Fayó: Cryptographic flaws in Oracle Database authentication protocol
• Pete Finnigan: Oracle Database Password Security 
• SkullSecurity: Padding oracle attacks: in depth
• Marcel Lambrechts: Cryptographic flaws in Oracle Database authentication protocol
• Oracle Database 11g stealth password cracking vulnerability in logon protocol (CVE-2012-3137)
• Oracle: Oracle DB 11.2 Database Security Guide
• Jan Schreiber: Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken, DOAG Konferenz 2015
• Oracle Database Security: Wie viel darf es denn sein?, Stefan Oehrli 2012
• Oracle: Technology Global Price List
• Oracle: Unified Directory Overview
• Oracle Enterprise User Security mit Active Directory, Jürgen Kühn 2009
• Oracle DB Security: Enterprise User Security für DBAs (EUS4DBAS), Carsten Mützlitz 2014
• RFC#5280, X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, 2008
• Defending Against Pass-the-Hash Attacks, Microsoft Security Intelligence Report
• Why Crack When You Can Pass the Hash,
• Abusing Microsoft Kerberos – Sorry you guys don’t get it
• Protection from Kerberos Golden Ticket
• Red vs. Blue: Modern Active Directory Attacks, Detection, and Protection Whitepaper
• Wikipedia: PKCS
• PKCS #11: Cryptographic Token Interface Standard, RSA 2009
• SSL With Oracle JDBC Thin Driver, An Oracle Technical White Paper, April 2010
• USING THE ORACLE ODBC DRIVER WITH SSL (Doc ID 1064404.1)
• Oracle Wallets hacken, Loopback Blog, Jan Schreiber 2015
• Automatic Renewal of Kerberos Tickets (LinuxQuestions)
• Kerberos für die Datenbank – Dr. Günter Unbescheid
• A-Team: Configuring your Oracle Database for Kerberos authentication
• Kerberos – Single Sign On ganz einfach, Trivadis, Jürgen Kühn 2011
• Loopback Wiki: Oracle Database 12c Kerberos Configuration
• Loopback Blog: Neuer Kerberos Stack: AD Authentifikation für Datenbank 12c
• Loopback Wiki: Configure EUS with OUD, AD and DB12c
• https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

---

Dieser Artikel erschien zuvor im Rahmen der DOAG Konferenz 2016.

Folien der DOAG Präsentation