Beiträge

Datenbank-Link Passwörter sind jetzt noch unsicherer

, ,

Die Passwörter von Oracle Datenbank Links waren Thema des diesjährigen Vortrags „Best of Oracle Security 2017“ von Alexander Kornbrust auf der diesjährigen DOAG Konferenz in Nürnberg.

Es ist dank der Arbeit von Mahmoud Hatem mittlerweile möglich, die verschlüsselt abgelegten Passwörter der Datenbank-Links relativ aufwandslos mit Hilfe eines kleinen PL/SQL-Skriptes zu entschlüsseln. Das Skript selbst lässt sich bei  GitHub herunterladen. Das ist ein bisschen schade, aber auch fast vorhersehbar, denn wie auch bei Wallets ist es sehr schwierig, ein symmetrisches Passwort geheim zu halten. Zumal, wenn es automatisch, also ohne Interaktion mit dem Benutzer, verwendet werden soll. In einer ausgelieferten Software finden sich selten sichere „Verstecke“ für ein hart-kodiertes Passwort.

Oracle hat offensichtlich versucht, das verwendete Passwort an zwei Stellen zu verbergen – in der Data Dictionary View SYS.PROP$ und im oracle-Binary selbst als Variable „ztcshpl_v6“. Diese ist dort natürlich immer gleich belegt. Vielleicht wäre es besser gewesen, saubere Hash-Werte der Passwörter zu verwenden, als einen solchen „Security through obscurity“-Weg zu gehen.

Jedenfalls ist es nun, Zugriff auf die Data Dictionary Views SYS.LINK$ und SYS.PROPS$ vorausgesetzt, möglich, die Klartext-Passwörter der Datenbank-Links einfach zu ermitteln.

Die Datenbank-Link-Passwörter und deren Geschichte in den Oracle Versionen waren auch hier im Blog bereits Thema, wenn auch fälschlicherweise von Hashes statt verschlüsselten Werten die Rede war. Dennoch hat unser Blog Post es als Quelle auf die Vortragsfolien geschafft, worüber ich mich sehr freue, denn dieser Vortrag von Alexander Kornbrust gehört traditionell zu den Highlights der DOAG Konferenz.

Oracle Security 2017 Slides

(c) Red-Database-Security GmbH

/von

DB 12.2: Neue Security Features

,

Oracle hat die Dokumentation für die Datenbank Version 12.2 veröffentlicht. Es sind eine Reihe neuer Security Features enthalten, insbesondere im Bereich TDE (Transparent Data Encryption). Wir bereits vermutet wurde, wird der Krypto-Algorithmus GOST unterstützt. Auch in der Kerberos-Implementierung soll sich einiges verbessert haben: Kerberos kann nun auch für Direct NFS genutzt werden und die Client-Konfiguration wird einfacher.

Eine kurze Übersicht über die neuen (12.2) Security Features gibt der New Features Guide12c Release 2:

Encryption

  • TDE Tablespace Live Conversion
  • Fully Encrypted Database
  • Support for ARIA, SEED, and GOST Encryption Algorithms in TDE
  • TDE Tablespace Offline Conversion

Enforcing Application Security in the Database

  • RAS Session Privilege Scoping
  • RAS Column Privilege Enhancements
  • RAS Schema Level Policy Administration
  • RAS Integration with OLS

Improving Security Manageability, Administration, and Integration

  • Oracle Virtual Private Database Predicate Audit
  • Oracle Database Vault Policy
  • Oracle Database Vault Simulation Mode Protection
  • Oracle Database Vault Common Realms and Command Rules for Oracle Multitenant
  • Privilege Analysis Enhancements
  • Privilege Analysis Results Comparison
  • Redaction: Different Data Redaction Policy Expressions
  • Redaction: New Functions Allowed in Data Redaction Policy Expressions
  • Redaction: Additional Data Redaction Transformations
  • Automatic KDC Discovery When Configuring OCI Clients
  • Automatic Provisioning of Kerberos Keytab for Oracle Databases
  • Role-Based Conditional Auditing
  • Inherit Remote Privileges

Improving Security Posture of the Database

  • SYSRAC – Separation of Duty for Administering Real Application Clusters
  • Transparent Sensitive Data Protection Feature Integration
  • Requiring Strong Password Verifiers by Default

Improving User Authentication and Management

  • Automatic Locking of Inactive User Accounts

Modernizing Network Authentication and Encryption

  • Kerberos-Based Authentication for Direct NFS

Der New Features Guide schreibt hierzu: „This feature solves the problem of authentication, message integrity, and optional encryption over unsecured networks for data exchange between Oracle Database and NFS servers using Direct NFS protocols.“

/von

DOAG SIG Security Mannheim 2016

,

Anbei die Folien vom DOAG Security Day 2016. Ich habe dort einen Vortrag zum Thema „Enterprise Security Reloaded – Oracle Wallets: Praktische PKI Authentifizierung für die ganze Datenbank“ gehalten.

/von

Neuer Kerberos Stack: AD Authentifikation für Datenbank 12c

,

Wir haben in diesem Blog des öfteren die Empfehlung ausgesprochen, eine zentrale Benutzerverwaltung statt lokaler Benutzerkonten für den Zugang zu Oracle Datenbanken zu verwenden. Für Umgebungen mit bestehender Active Directory Infrastruktur bietet sich hierfür in erster Linie die AD-Anbindung über LDAP und Kerberos an.

Die Kerberos-Unterstützung ist bereits seit Version 7 der Oracle Datenbank vorhanden und gut dokumentiert. Für die Anbindung an Active Directory wird in der Regel ein Oracle LDAP-Server (OID oder OUD) verwendet, um die Oracle-spezifischen Einstellungen nicht im Active Directory Verzeichnis speichern zu müssen. Die Einrichtung dieser Komponenten mit der Datenbank 11gR2, dem Oracle Internet Directory als LDAP-Server und Microsoft Windows Server 2008 haben wir bereits in diesem Blog und in unserem Wiki beschrieben.

Für einen Kunden haben wir die zentrale Authentifikation mit Kerberos, AD, OUD und EUS gerade mit den aktuellen Software-Versionen (Datenbank 12.1, Windows Server 2012 und Java 8) aufgebaut und sind dabei auf eine Reihe von Besonderheiten gestossen, die bei der Einrichtung beachtet werden sollten. Ansonsten sieht man sich schnell mit einer Reihe von Inkompatibilitäten konfrontiert, die verhindern, das die Komponenten miteinander funktionieren. Die alten Anleitungen funktionieren nicht mehr. Das liegt vor allem daran, das Oracle den Kerberos Stack in der Datenbank 12c komplett überarbeitet oder sogar neu geschrieben hat.

Beachtet werden muß im Einzelnen:

Für Oracle Universal Directory (OUD):

  • Der Network Configuration Assistant funktioniert nicht mit Active Directory. Die LDAP-Konfiguration muss per Hand angelegt werden.
  • Das EUSM-Tool zum Einrichten der Zuordnung zwischen AD- und Datenbank-Benutzern (EUS Mappings) ist von mehreren Bugs betroffen und funktioniert nicht mehr. Abhilfe schafft:
    • Installation von Patch 20529805 im OUD (Hintergrund: Bug: 20529805 – SUPPORT FOR EUSM 12C AUTHENTICATION SCHEME IN OUD IS MISSING: Falsche DN-Syntax durch neue SASL-Implementation in  OUD)
    • Verwendung von AES-Hashes für OUD-Passwörter ist für EUS obligatorisch, um OUD aber nicht standardmässig aktiviert, daher muss das OUD „Default Passwort Storage Scheme“ verändert werden
  • Die Datenbank möchte unbedingt eine SSLv3-Verbindung zum LDAP-Server aufbauen, SSLv3 ist aber in Java 8 nach der Poodle Attacke abgeschaltet. Es gibt einen Oracle-Patch, der aber nicht öffentlich ist. Alternativ kann SSLv3 im Java des OUD-Servers wieder eingeschaltet werden

Für Kerberos:

  • Für die Datenbank 12c müssen Kerberos-Keytab-Dateien auf dem AD-Server Windows 2012 unter Umständen mit der Option „-crypto RC4-HMAC-NT“ erzeugt werden. In einigen Fällen erzeugt der AD Keytab-Dateien mit DES statt AES, wenn die RC4-HMAC-Option nicht explizit angefordert wurde. In diesen Fällen sollte die AD-Konfiguration überprüft werden. DES ist natürlich keine aktuelle Option mehr, aber RC4-HMAC eigentlich auch nicht.
  • In einigen Fällen ist es notwendig, Kerberos Pre-Authentication-Support in der SQL-Net Konfiguration einzuschalten, oder Pre-Authentication im AD auszuschalten.

Wir haben die gesamte Konfiguration in zwei Wiki-Artikeln zu jeweils EUS/OUD und Kerberos beispielhaft und mit allen Fehlerbehandlungen beschrieben.

/von

Oracle Wallets hacken

, , ,

Oracle Wallets werden benutzt, um SSL Zertifikate, die dazugehörigen Schlüssel, aber auch Klartext-Passwörter (Secure Enterprise Password Store) abzulegen. Sie werden normalerweise durch ein Wallet-Passwort geschützt, das bei jedem Öffnen oder Auslesen eingegeben werden muß.

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.

Weiterlesen

/von

Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken

, , ,

Einleitung

Direkte Benutzerkonten und Passwörter in der Datenbank sind eine Sicherheits-Schwachstelle, da in der Regel keine eindeutige Zuordnung von natürlichen Personen zu Benutzerkonten möglich ist, keine unternehmenseinheitliche Sicherheitsregel durchgesetzt werden kann und ausgeschiedene Mitarbeiter nicht sicher und sofort aus sämtlichen Systemen ausgeschlossen werden können.

In diesem Artikel werden die verschiedenen Möglichkeiten aufgezeigt, Enterprise Single Sign On und Public Key Infrastructure (PKI) zu nutzen, um Datenbankbenutzer zu authentifizieren. Anhand von Projekterfahrungen aus der Praxis wird die Integration der Oracle Datenbank mit LDAP-Verzeichnissen (OID, OUD) und Microsoft ActiveDirectory mit und ohne Oracle Virtual Directory (OVD) erklärt sowie die Einführung von SmartCard-basierter PKI als Alternative vorgestellt. Weiterlesen

/von

Passwörter wiederherstellen in Oracle 11g

,

In der Datenbank Version 11gR1 hat Oracle bekanntlich case-sensitive Passwörter und einen neuen Passwort-Algorithmus eingeführt. In der Datenbank werden nicht die Klartext-Passwörter, sondern nur deren Hashes abgelegt, und der Algorithmus, mit dem diese Hashes berechnet werden, war bei 10g 3DES, und ist seit 11g SHA1. Im 10g-Hashverfahren fliesst der Username als Salt in den Hash mit ein, während ab 11g ein zufälliges Salt verwendet wird. Ab 11g können die Hashes also zwischen verschiedenen Benutzern geteilt werden.

Will man das Passwort eines Benutzers sichern, um es beispielsweise in einer anderen Datenbank wieder einzuspielen, kann man sich den Hash im Data Dictionary suchen (der 10g Hash steht in SYS.USER$.PASSWORD, der 11g Hash in SYS.USER$.SPARE4), und dessen Wert mit Hilfe der „BY VALUES“ Klausel beim Anlegen eines neuen Users angeben:

CREATE USER AKIRA IDENTIFIED BY VALUES ‚DA3A39221404DD55‘; –10g hash

ALTER USER AKIRA IDENTIFIED BY VALUES ‚S:3CAFD1F43D6958FD4F67C2EDD91B3FF54913344723750F6AE48C802D37E4‘ –11g hash

Oracle erkennt hier selbstständig aus dem verwendeten Wert, ob es sich im einen 10g oder um einen 11g Hash handelt. Wird ein 11g Hash angegeben, löscht die Datenbank allerdings den 10g Hash aus dem Dictionary – und umgekehrt. Normalerweise kann man mit dieser Syntax also nur entweder einen alten oder einen neuen Hash setzen, aber nicht beide, wie man es zur vollständigen Wiederherstellung eines bisherigen Zustandes in einigen Fällen bräuchte.

In der MOS Note (Doc ID 1051962.101) hat Oracle beschrieben, wie man beide Hashes mit der „BY VALUES“ Syntax eintragen kann:

alter user TEST identified by values
‚7A0F2B316C212D67;S:F3F4BA77C0E960A5973095AF787988CBE52410CB2EA53F6AF008AD99179B‘;

Indem man beide Hashes mit einem Semikolon getrennt zusammen angibt.

Bei der Authentifikation ab 11g existiert eine erschreckende Sicherheitslücke im O5LOGON Protokoll, das es einem Angreifer ermöglicht, den Session Key und das Salt auszulesen, ohne Spuren zu hinterlassen. Um sie zu schließen, haben einige Datenbankadminstratoren die 11g-Authentifizierung ganz ausgeschaltet, indem sie den Parameter „SEC_CASE_SENSITIVE_LOGON=FALSE“ gesetzt oder alle 11g-Hashes aus dem Dictionary gelöscht haben.

In dieser Kombination kann es zu dem Effekt kommen, dass Passwörter zum Beispiel beim Aufbau einer Testumgebung mittels der BY VALUE Methode mit einem gespeicherten 11g-Hash zurückgesetzt werden, sich aber danach kein Anwender anmelden kann, weil in der Quell-Datenbank noch der 10g-Hash verwendet wurde, dieser aber durch das Neu-Setzen des 11g-Hashes überschrieben wurde, und die Anmeldung nur mit einem 11g-Hash nicht funktioniert. Hier hilft dann die oben beschriebene Methode, beide Hashes anzugeben, so man sie denn gesichert hatte.

Siehe auch zum Thema:
  • Marcels Blog Post zum Thema Hashes in 11g. Hier wird auch der verwendete Algorithmus vollständig beschrieben.
  • „Cryptographic flaws in Oracle Database authentication protocol“, Esteban Martínez Fayó
/von

DB Link Passwörter Metadaten in 11.2.0.4

, ,

Seit der Datenbank Version 11.2.0.4 funktioniert das Auslesen der Beschreibungen für Datenbank-Links über DBMS_METADATA.GET_DDL nicht mehr. Statt des Passwort Hashes wird nun eine Bind Variable angezeigt.

Die Passwörter von Datenbank-Links wurden früher in der PASSWORD-Spalte der Tabelle SYS.LINK$ im Klartext abgelegt und waren einfach lesbar. In Version 10gR1 wurde der Zugriff auf diese Tabelle aus der Rolle SELECT ANY DICTIONARY entfernt, mit 10gR2 wurde die Spalte PASSWORDX eingeführt, die nun nur noch den Hash speichert.  Mit der Sicherheit dieses Hashes steht es allerdings auch nicht zum Besten.

Während es in älteren Versionen möglich war, die komplette Link-Beschreibung inklusive der Passwort-Hashes in einer „BY VALUES“-Klausel auszulesen, sieht das Ergebnis in 11.2.0.4 so aus:

SQL> SELECT OWNER, DB_LINK, DBMS_METADATA.GET_DDL('DB_LINK',DB_LINK,OWNER) as DDL FROM DBA_DB_LINKS;
OWNER          DB_LINK      DDL
-------------- ------------ ----------------------------------------------------------
SYS            TEST_LINK    CREATE DATABASE LINK "TEST_LINK"
                            CONNECT TO "DBLINK_ACCOUNT" IDENTIFIED BY VALUES ':1'
                            USING 'TNSALIAS'

Der für den Link notwendige Hash steht allerdings immer noch in der PASSWORDX-Spalte der SYS.LINK$-Tabelle, und kann mit Hilfe von DBMS_CRYPTO recht einfach ausgelesen werden:

SQL> select 
 name, 
 userid, 
 utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)), 
  4353, (substr(passwordx,3,16)))) 
from sys.link$;

NAME       USERID         UTL_RAW.CAST_TO_VARCHAR2(DBMS_CRYPTO.DECRYPT
                          ((SUBSTR(PASSWORDX,19)),4353,(SUBSTR(PASSWORDX,3,16))))
---------- ---------      -------------------------------------------------------
TEST_LINK  DBLINK_ACCOUNT GEHEIMESPASSWORT

Oft wird eine solche Möglichkeit benötigt, um Skripte zu erstellen, die Objekte wie Links zusammensuchen, um sie zu paketieren und für Deployment bereitzustellen.

Dieser Bug in der Datenbank Version 11.2.0.4 ist bei Oracle klassifiziert unter: Bug 18461318. Der Status dieses Bus steht allerdings auf „44 – Not Feasible to fix, to Filer„, was nicht sehr vielversprechend klingt.

Update 23.11.2017: Es findet eine Verschlüsselung, keine Hash-Wert-Berechnung, des Link-Passwortes statt, und diese lässt sich brechen.

/3 Kommentare/von

Portfolio Einträge