- 10.2.0.4 (1)
- 11g (5)
- Allgemein (27)
- Auditing (1)
- Backdoor (2)
- Bücher (1)
- checkpwd (2)
- CPUApr2007 (1)
- CPUApr2008 (1)
- CPUJan2008 (3)
- CPUJul2007 (3)
- CPUJul2008 (1)
- CPUOct2007 (3)
- Database Vault (3)
- DOAG (2)
- Exploit (4)
- Forensik (1)
- Hedgehog (3)
- Inguma (1)
- Oracle (3)
- Oracle Security (25)
- Präsentation (3)
- rootkit (1)
- Security (6)
- Sentrigo (4)
- software (4)
- 18 Nov 2011: DOAG 2011 Präsentation "Best of Oracle Security 2011"
- 13 Apr 2011: Blackhat Training "Hacking and Securing Oracle (2 days)"
- 23 Mrz 2011: McAfee übernimmt Sentrigo
- 9 Apr 2010: DOAG Berliner Expertenseminare: Oracle Hardening & Patching / Auditing & Co.
- 1 Mrz 2010: Sentrigo stellt den neuen Security Scanner Repscan 3.0 vor
- 21 Jan 2009: Webinar - Best Practices for Database Security
- 15 Jan 2009: Buchvorstellung: Oracle Survival Guide
- 24 Dez 2008: Frohe Weihnachten & ein gutes neues Jahr
- 14 Dez 2008: Datenklau bei Berliner Landesbank
- 3 Dez 2008: DOAG 2008
SYSDBA Backdoor
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”.
Antwort schreiben
Sie müssen als angemeldet sein, um einen Kommentar schreiben zu können.