Schlagwort-Archive: Sicherheit

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

Advertisements

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