CTF - Capture the Flag: Die Machen das mit “Links”!
Die ORDIX AG nimmt auch in diesem Jahr an der DOAG-Konferenz teil – einem der wichtigsten Treffpunkte der deutschen Oracle Community. Doch dieses Mal wollen wir nicht "nur" wie gewohnt Fachvorträge halten, sondern etwas Neues machen: Eine interaktive Vortragsreihe mit dem Fokus auf Datenbank-Security! In diesem Artikel geht es um das Thema Datenbanklinks.
Passwörter von Links sind häufig eine kritische Hürde bei Migrationen von Datenbanken; gerade bei der Anpassung der hinterlegten Zielinformationen. Diese sind erforderlich, um die Datenbankverbindungen korrekt zu rekonstruieren. Doch häufig sind gerade Passwörter der Zielbenutzer nicht verfügbar. Aus Sicherheitsgründen werden diese nicht abgelegt oder nicht dokumentiert. Diese Situation kann den Migrationsprozess erheblich verkomplizieren und den Aufwand für die Administration steigern. In diesem Artikel beleuchten wir, warum dieses Problem auftritt und welche Lösungsansätze es gibt, um diese Herausforderung zu meistern.
Das Problem
Generell wird in vier verschiedene Arten von Datenbanklinks unterschieden. Das erste Unterscheidungsmerkmal ist, ob der Link als "Public" definiert ist oder lediglich für einen dedizierten Benutzer verwendbar ist. Für die Migrationsstrategie spielt dieser Unterschied keine Rolle. Aus sicherheitsrelevanten Gründen wird jedoch empfohlen, auf die Verwendung von öffentlichen Links zu verzichten.
Von entscheidender Bedeutung für die Verlagerung von Datenbanken oder Datenbankschemata ist die Unterscheidung, ob die Links auf den aktuellen Benutzer verweisen oder einen zentralen, in der Zieldatenbank zu definierenden Benutzer ansprechen. IIm ersten Fall muss der Ausgangsbenutzer dem Zielschema im Namen als auch im Passwort entsprechen. In der Praxis wird dieses Konstrukt selten verwendet, ist aber technisch valide. Die zweite Option, den Link auf einen zentralen Benutzer auf der Remoteseite zu definieren, erfordert das Passwort der Gegenseite.
Ein weiterer entscheidender Aspekt, der sich auf die Migrationsstrategie von Datenbanklinks auswirkt, ist die Definition des Zielservers. Der Angabe eines TNSNAMES-Alias steht der Möglichkeit, die Verbindungsinformationen fest in der Linkdefinition zu übergeben, gegenüber.
-- Verbindung über TNSALIAS
-- a) tnsnames.ora
remotedb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = remotedb.ordix.de)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = ORCL))
)
-- Linkerzeugung
CREATE DATABASE LINK remotedb
CONNECT TO ordix IDENTIFIED BY <password>
USING 'REMOTEDB';
-- Direkte Verbindungsdetails
CREATE DATABASE LINK remotedb
CONNECT TO ordix IDENTIFIED BY <password>
USING '(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = remotedb.ordix.de)(PORT = 1521))(CONNECT_DATA = (SERVICE_NAME = ORCL)))';
Gibt es nun eine Möglichkeit, die Links, ohne eine Passwortänderung des Zielschemas zu erstellen?
Die Lösung
Ja, es ist möglich. Die Passwörter und die "Salts" mit denen sie erweitert werden, sind in der Datenbank hinterlegt. Eine Prozedur zum Entschlüsseln der Datenbank-Link Passwörter findet man unter
https://github.com/hatem-mahmoud/scripts/blob/master/db_link_password_decrypt.sql .
- Wert der Spalte value$ für NO_USER_ID_SALT der Tabelle sys.props$
- Wert der Spalte Passwordx für den entsprechenden Databaselink Namen der Tabelle sys.link$
Beides sind Tabellen der internen Schicht des Data Dictionary. Die Porperties-Tabelle (props$) liefert Datenbankgrundeinstellungen, wie in diesem Falle den Salt, mit dem die Link-Passwörter erweitert werden. Die Link-Tabelle (link$) speichert die Metadaten der gespeicherten Linkobjekte, wie unter anderem auch Namen und Passwort.
SQL> select value$ from sys.props$ where name='NO_USERID_VERIFIER_SALT'; VALUE$ ----------------------------------------------------------- B1C8F128459F84EA6068906C6368712F select PASSWORDX from sys.link$ where name like 'REMOTEDB'; PASSWORDX ---------------------------------------------------- 07857A5CDEB439CF3DE2B1D142<langer String gekürzt>
Mit den zwei ermittelten Werten kann die Prozedur ausgeführt werden und man erhält das entschlüsselte Passwort des Zielbenutzers der Ferndatenbank. Links können jetzt mit diesen Informationen nach erfolgter Migration der Datenbank entsprechend neu aufgebaut werden, auch wenn die Dokumentation dieser Passwörter nicht erfolgt ist.
exec
DB_LINK_PASSWORD_DECRYPT('B1C8F128459F84EA6068906C6368712F','07857A5CDEB439CF3DE2B1D142<langer String gekürzt>');
----------Decrypting DB Link password--------------
Initialization_vector :
01010300000100010002000001000001
---------------------------------------------------
Ciphertext :
7AED9E5CF9D728574AE1354886461FCC0A3E3586C4F8150FD2C2FCF58B239D4B
---------------------------------------------------
Encryption key part 1 :
2A5865CFF71B9BE721C81F553BE7FD6F827089EE62D2F869C2E8E33EA05DEC0F
Encryption key part 2 :
D25C85CFCEE9D93EA8D6C4894BAC732CC8944D1A504DD99EF5A9147B16001D5B
---------------------------------------------------
Encryption key (Part 1 XOR Part 2) :
F804E00039F242D9891EDBDC704B8E434AE4C4F4329F21F73741F745B65DF154
---------------------------------------------------
Decrypted string: Password!Link09
Decrypted string: 124F72636C5F4C696E6B5F313132345F67426661D083ADD7059CA9DB7F5E9E94
PL/SQL procedure successfully completed.
Fazit
Ist es nötig Datenbanklinks auf der Ausgangsseite des Links anzupassen, müssen diese in der Datenbank neu erstellt werden. Die Definition mit den Passwort Hashes ist syntaktisch wie bei Benutzern (identified by values) nicht möglich. Sollten sich Namenskonventionen oder Zieldatenbanknamen ändern, ist es nicht sauber, wenn Standards aufgebrochen werden. Alle nötigen Informationen werden in der Datenbank vorgehalten. Die beschriebene Lösung hilft die Hindernisse der Linkmigration aufzuweichen und zu einer erfolgreichen Migrationsstrategie beizusteuern.
Senior Chief Consultant bei ORDIX.
Bei Updates im Blog, informieren wir per E-Mail.
Kommentare