Archiv der Kategorie: Sicherheit

Oracle Security Reporting Tool – DBSAT

Da ich selbst schon länger nichts mehr hier veröffentlicht habe, reproduziere ich doch einfach mal einen Artikel meines Kollegen Simon Hahn. ;-)

The Cattle Crew Blog

Hallo Community,

aus gegebenen Anlass möchte ich ein paar Worte über Oracle DBSAT – Database Security Assessment Tool verlieren. Ein kleines, kostenloses aber sehr mächtiges Security Reporting Tool für Oracle Datenbanken.

Wir hatten die Möglichkeit das Tool auf der Inspire IT in Frankfurt einigen Kunden vorzustellen.
Sowohl die Verprobung des Tools an sich wie auch die Veranstaltung hat uns sehr viel Spaß bereitet.

Grundsätzlich ist das nichts Neues – Security und Datenschutz sind wichtig und auch teuer, sollten dennoch immer im Unternehmen gelebt werden. Spätestens dann, wenn Firmendaten im Internet für jeden ungewollt einsehbar sind, wurde etwas gänzlich falsch gemacht und nicht selten wird das Unternehmen einen riesigen Imageschaden über Jahre hinweg davontragen.

–> Security und Datenschutz nicht ernst zu nehmen, kann demnach sehr, sehr nachhaltig und gnadenlos sein. Daher lieber vorsorgen. :-)

Im Zuge der neuen EU-weiten Datenschutzverordnungen (GDPR und DSGVO) zum Stichtag 25.5.2018 sollten Datenbanken entsprechend vielleicht doch…

Ursprünglichen Post anzeigen 661 weitere Wörter

Advertisements

Enterprise Manager: Ungültiges Zertifikat kann in Firefox nicht mehr akzeptiert werden

Vor einigen Tagen hat Mozilla den Firefox-Browser auf die Version 31 angehoben.
Seither ging bei mir die Verbindung zum Grid Control mit Firefox nicht mehr, Mit Chrom[e|ium] hingegen schon. Zumindest ist es in Chrome noch möglich, die Warnung vor dem nicht vertrauenswürdigen Zertifikat zu überspringen.

Mein deutschsprachiger Firefox meldet folgenden Fehler:

Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit xxxxxxxxxxxx aufgetreten.

Das Aussteller-Zertifikat ist ungültig.

(Fehlercode: sec_error_ca_cert_invalid)

Da bislang im Netz noch wenig Ergebnisse hierzu zu finden sind (jedenfalls bei den Suchbegriffen, die mir spontan einfielen), beschreibe ich hier kurz eine mögliche Lösung, wie sie auch in der Oracle Note 1912289.1 zu finden ist:

Edit vom 29.01.2015: Der Bug ist mittlerweile behoben. Es reicht also, Firefox zu aktualisieren.

Dieser Workaround funktioniert ab Firefox 33.1 nicht mehr! Siehe Kommentar weiter unten.

  1. In der Adressleiste „about:config“ eingeben.
  2. Die Warnung mit dem Button akzeptieren.
  3. In der Suchleiste „security.use_mozillapkix_verification“ eingeben.
  4. Doppelklick auf die Ergebniszeile stellt den Wert dieses Parameters von „true“ auf „false“ um.
  5. Enterprise Manager erneut aufrufen.

Hintergrund

Mozilla hat mit Firefox 31 die neue Library „mozilla::pkix“ zum Check der SSL-Zertifikate eingeführt. Diese Library stuft aber offensichtlich alle selbst signierten Zertifikate als „nicht vertrauenswürdig“ ein und gestattet kein manuelles Übergehen. Dies ist als Bug 1042889 bei Mozilla in Bearbeitung.

Normalerweise wird bei der Installation des OEM ein SSL-Zertifikat automatisch generiert und eben auch selbst (durch den Installer) signiert. Genau das bereitet der neuen Library aber derzeit Probleme.

Das Abschalten der neuen Library ist natürlich keine schöne Lösung und sollte wieder rückgängig gemacht werden, wenn der Bug behoben ist. Alternativ könnte man auch ein Zertifikat einer vertrauenswürdigen CA (kaufen und) importieren. Wie das geht, ist in der Oracle Note 1367988.1 beschrieben.

PL/SQL Injection in Oracle 12c

David Litchfield, der bereits andere Injection-Lücken in Oracle gefunden hatte (s. meine anderen Artikel der Kategorie „Sicherheit“), hat wieder zugeschlagen und eine Injection-Methode unter 12c aufgedeckt:
http://www.davidlitchfield.com/Exploiting_PLSQL_Injection_on_Oracle_12c.pdf

Sehr kurze Zusammenfassung des Dokuments:

  • Ein User mit Execute-Recht auf DBMS_SQL und DBMS_JAVA_TEST kann damit SQL Injections durchführen.
  • Der Entzug von Execute auf DBMS_JAVA_TEST und DBMS_JAVA wirkt dem entgegen.
  • Wenn Java in der DB nicht benötigt wird, sollten diese Packages gleich ganz deinstalliert werden, um die Angriffsfläche zu verringern.

Security Fix verhindert Recovery

Im „Security Alert Advisory for CVE-2012-3132“ wird vor einer Bedrohung gewarnt, die wieder einmal von David Litchfield entdeckt wurde. Dabei kann mithilfe von Anführungszeichen in Objektnamen SQL-Code eingeschleust und mit SYS-Rechten ausgeführt werden, wenn man

  1. einen autorisierten Zugang zur DB hat,
  2. dieser User CREATE TABLE und CREATE PROCEDURE-Privilegien hat und
  3. dieser User DBMS_STATS ausführen darf.

Im Juli 2012 wurde ein Fix veröffentlicht, jedoch gibt es auch eine Empfehlung von Oracle, wie der Gefahr ohne Einspielung eines Patches zu begegnen ist. Diese Empfehlung hat jedoch Folgen für Recovery oder Klone einer derart behandelten DB:

Weiterlesen

Lateral SQL Injection: Neue Erkenntnisse

SQL Injection ist ein Verfahren, über eine Anwendung, die den Zugriff auf die Datenbank bereitstellt, eigene Datenbankbefehle einzuschleusen. Jeder Entwickler, der sicherheitsrelevante DB-Anwendungen schreibt und dabei dynamisch generiertes SQL einsetzt, sollte mit diesem Angriffsszenario und den Gegenmaßnahmen vertraut sein.

David Litchfield von databasesecurity.com hat bereits 2008 eine spezielle Form von SQL Injection in Oracle demonstriert, die er „Lateral Injection“ nannte. Das Verfahren hat es ermöglicht, in PL/SQL-Prozeduren trotz korrekt typisierter Parameter mit Hilfe von NLS_DATE_FORMAT schadhaften Code in dynamisches SQL einzuschleusen. Diese Woche nun wies er auf ein neues Whitepaper hin, das aufzeigt, daß auch NUMBER-Parameter mit Hilfe von NLS_NUMERIC_CHARACTERS dergestalt manipuliert werden können, daß die Ausführung fremder Funktionen möglich wird. Weiterlesen

Proxy-User

In mehrschichtigen Architekturen ist es gängig, dass ein Application Server mehrere Verbindungen zur Datenbank auf Vorrat aufbaut (ein sog. Connection Pool). Häufig geschieht das mit einem einzigen Benutzerkonto, was den Nachteil hat, dass

  • diesem Benutzerkonto alle möglichen Rechte für verschiedene Anwendungsteile zugeteilt werden müssen und
  • dadurch einzelne Anwendungsteile sämtliche dieser Rechte in der Datenbank wahrnehmen können, was ein Sicherheitsrisiko bedeuten kann;
  • bei der Fehlerdiagnose oder bei Sicherheits-Audits Datenbank-seitig nicht nachvollzogen werden kann, welcher Benutzer welche Aktion durchgeführt hat, da immer nur das eine Benutzerkonto des Servers verwendet wird.

Ursächlich ist dafür leider oft einfach nur fehlendes Wissen über die vielfältigen, ausgereiften Möglichkeiten, die die Oracle-Datenbank in puncto Sicherheit zu bieten hat. Und so wird das Rad immer wieder aufs Neue erfunden, indem etliche Sicherheitsfunktionen neu – und damit potentiell fehlerhaft – in eine Anwendung hinein programmiert werden und die Anwendung sich dann vielleicht auch noch mit einem Benutzer zur Datenbank verbindet, der jegliche Tabelle lesen und jegliche Prozedur ausführen darf! Da ist der nächste Skandal um Datendiebstahl buchstäblich vorprogrammiert. Weiterlesen