Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Oracle 8i compromise questions

From: Kevin Reardon (Kevin.Reardonoracle.com)
Date: Fri Aug 19 2005 - 18:34:15 CDT

They should password protect their listener. This is a very old problem
that has been fixed ages ago by patches. They should apply the latest
Critical Patch Update that is available for download through:


Jack Donovan wrote:

>Hello all,
>A client of mine reported a compromise of an outdated Oracle 8i
>(8.174) database server running on Windows 2000, which they wanted me
>to try and figure out the root cause of. The compromise was very
>generic, and allowed the attackers OS access which they used to
>install some standard backdoor stuff and grab the password hashes for
>the system which they broke overnight offline (presumably via
>RainbowCrack). We know this because the usernames and passwords were
>attempted against other systems belonging to the client, albeit
>unsuccessfully. My knowledge of Oracle is limited, but I assumed it
>would be easy to spot the initial event, since the attacker's
>themselves were not very careful.
>After a quick analysis of the system and network data, the earliest
>action I can find appears to be a PWD<database_name>.ORA file that was
>overwritten, which is the ORACLE Remote Password File allowing folks
>remote access as SYSDBA. Shortly after the timestamp on the ORA file,
>there was a successful login entry in the application log to the
>Oracle as as the sys user, as follows:
>trail: ACTION : 'connect sys' OSPRIV : DBA CLIENT USER:
><attacker_login_name_presumably> CLIENT TERMINAL: <attacker_host>
>From what I understand, any user found in the PWD<db>.ORA file will
>show up in the logs as 'connect sys', so this makes sense. There was
>a similar login attempt that failed roughly 10 minutes before this,
>though Oracle didn't keep track of the attacker host in the failed
>attempt. Within roughly 1 minute of the successfull Oracle login, the
>attacker's toolkit was uploaded (based on the timestamps I've got).
>The questions I have are:
>1) What is the most common attack method used for an Oracle database
>that would result in this file being overwritten? Is it likely this
>was the attack vector, or a backup access method with some other
>method being used to initially break the system?
>2) If the overwritten authentication and subsequent login to the
>database was the method of entry, how did the attackers get local
>filesystem access? I know how to do this in MSSQL etc., and I know
>there's the PL/SQL stuff in Oracle, but it seems nontrivial to me how
>one would go about using that for this purpose.
>My assumption is these are somewhat basic questions, but my searching
>around Google hasn't turned up anything concrete yet. I found a
>number of listener vulnerabilities for doing things like arbitrarily
>assigning the log file and overwriting, but most of them seem to be
>circa 2000, and I'm fairly certain the system had been patched since
>then (though the exact patch status of the system was unknown).
>It's possible there is some buffer overflow at work, but the service
>itself didn't die, and there was no error in the system , security, or
>application logs that would imply such an attack. My initial thought
>when the compromise was reported was brute-force password attack,
>because the password used was terrible. But the overwritten PWD file
>seems counter to that theory.
>The attacker's did not appear terribly subtle (nice bright shiny FTP
>banners), so the simplest solution here is probably the most likely.
>Any thoughts on what that solution might be, or pointers to where I
>should be looking, would be much appreciated.