Schlagwort-Archive: Security

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.

sqlplus, ezconnect, ORA-12504 und kein Passwort

Aus der Kategorie „Heute dazugelernt“: Beim Versuch, mittels EZCONNECT (s. „Easy Connect Naming Method„) unter Verwendung eines Wallets eine Verbindung aufzubauen (um kein Passwort auf der Kommandozeile/im Script zu hinterlassen), wurde das stets mit einem „ORA-12504“ quittiert.

[oracle@myorabox bin]$ sqlplus scott@localhost/orcl

SQL*Plus: Release 11.2.0.3.0 Production on Mon Feb 24 16:19:14 2014

Copyright (c) 1982, 2011, Oracle. All rights reserved.

ERROR:
ORA-12504: TNS:listener was not given the SERVICE_NAME in CONNECT_DATA

Seltsam — der Service „orcl“ ist doch angegeben?! Werfen wir mal einen Blick ins listener.log:

(CONNECT_DATA=(SERVICE_NAME=)(CID=(PROGRAM=sqlplus)(HOST=myorabox)(USER=oracle))) * establish * 12504

Tatsache — der „SERVICE_NAME“ ist leer.

Interessanterweise findet sich bei MOS nichts dazu, aber Mark Williams hat das Problem schon mal gelöst und netterweise gebloggt! Offenbar „verheddert“ sich SQL*Plus am fehlenden „/“ vor dem nicht übergebenen Passwort; Wird der Connect String jedoch in Anführungszeichen gesetzt, dann geht’s!

sqlplus scott@\"localhost/orcl\"

SQL*Plus: Release 11.2.0.3.0 Production on Mon Feb 24 16:31:38 2014

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

 

JDBC, Linux und reiner Zufall

Read this article in English →

Manche Probleme — besonders die, die nur sporadisch auftreten — sind nicht so leicht zu diagnostizieren und erfordern einen tieferen Einstieg in die Materie. In diesem Praxisbeispiel bedeutet das: SQL*Net Tracing und Verständnis für die Funktionsweise des Betriebssystems, speziell die Generierung von Zufallszahlen.

Der vorliegende Fall eignet sich daher sehr gut, um eine Vorgehensweise beim Troubleshooting von Verbindungen zur Datenbank exemplarisch darzulegen.
Weiterlesen

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

DBMS_SESSION: Anwender und Sessions mehrschichtiger Anwendungen in der DB identifizieren

„Wer war das“!?

In mehrschichtigen Softwarearchitekturen (also einem Großteil der Web-Anwendungen) wird die Verbindung zur Datenbank meist über wiederverwendbare Verbindungen, sog. Connection Pools, aufgebaut (siehe dazu auch meinen Artikel über Proxy-User). Wenn die Benutzerverwaltung nicht in der Datenbank sondern in der Anwendung stattfindet, verbindet sich dabei der Application Server üblicherweise mit einem einzigen, „technischen User“ mit der Datenbank.

Dem Vorteil der dadurch eingesparten Zeit für einen Verbindungsaufbau bei jeder DB-Abfrage steht damit aber der Nachteil gegenüber, daß auf der DB-Seite nicht mehr nachvollzogen werden kann, welcher Anwender und welche (oder welcher Teil der) Anwendung in einer bestimmten Session läuft. Das ist zwar im Normalbetrieb nicht so wichtig, wenn es aber zu Problemen kommt, dann kann diese fehlende Information die Fehlersuche schwer beeinträchtigen. Drei häufige Szenarien seien hier genannt:

  • Der DB-Server ist plötzlich überlastet. Die Ursache kann zwar bis zu einer bestimmten Session in der Datenbank verfolgt werden, aber nun ist noch nicht klar, wer diese Session besitzt und welche Aufgabe er gerade ausführen will.
  • Ein Anwender beklagt sich über zu lange Antwortzeiten in einem bestimmten Anwendungsteil. Von den 500 offenen Sessions auf der DB kann aber nicht identifiziert werden, in welcher dieser Sessions der Anwender aktiv ist, und daher kann keine gezielte Fehlerverfolgung (z.B. mittels Tracing) durchgeführt werden.
  • Zur Erfüllung von Sicherheitsrichtlinien sollen Informationen über die Aktivitäten von Anwendern in der Datenbank gesammelt werden (Auditing). Das Oracle RDBMS kann das zwar von Haus aus, wenn aber die Verbindung nur über einen einzigen Useraccount läuft, fehlen wesentliche Informationen.

Softwareentwickler sollten daher schon im eigenen Interesse Ihre Anwendungen von Anfang an so instrumentieren, daß ein DBA bei Problemen auf der Datenbank gezielt Informationen sammeln kann.

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