RE: Breakable

["bugtraq () t-swat com" <bugtraq () t-swat com>]

Jonathan-

Just a couple of points:

To clarify, the "host" command is client-based.  For instance, when I 
SQLPLUS into a remote database, and I use the host command, it breaks me 
out into the directory of the local machine, not the server you're 
connected into.  Same goes for any local shell commands.  I don't see that 
as being a security risk.

As to the System and Sys accounts having defaulted passwords, the last time 
I installed 9i it made me change them at the time of install.  The accounts 
were also locked, and not accessible, until I went in as INTERNAL and 
modified them.  I find this to be somewhat acceptable behaviour.

As to the other accounts (SCOTT/TIGER, etc.), that is a good point, but 
covered quite clearly in the "how to secure your database" documentation.


I think it comes right down to the fact that Oracle is an extremely 
complex, yet powerful database, and anyone that is going to do any kind of 
professional development with it or use it in a "public" environment (as in 
exposed to the world) should understand how to use auditing, and lock out 
or remove unwanted accounts, and how to architect applications, systems, 
and security appropriately.  When you currently perform a default install 
of Oracle, it is in a "relatively" secure, yet "easy" to use config that 
allows people to explore and learn about it without having to figure out 
how to unlock it first.

I think that anyone who is not familiar with Oracle and yet implements it 
in a vulnerable place without taking the appropriate cautions is almost 
deserving to be hacked.  (This ain't your fathers Access database!)


$0.02


...jeff



At 10:47 AM 17/01/2002, Jonathan A. Zdziarski wrote:
> Considering Oracle's client by default allows connected users to run
> arbitrary shell commands, it doesn't surprise me that vulnerabilities
> such as this exist.  In fact, Oracle's RDBMS has some very odd default
> installation quirks:
>
> 1. The SYSTEM and SYS passwords are defaulted (manager and
> change_on_install, respectively)
> 2. The database comes with a handfull of pre-existing "demo" accounts
> with preset passwords (e.g. SCOTT/TIGER, and a few others).
>
> To find them, do a
>
> SELECT USERNAME FROM DBA_USERS;
>
> And look for any names that look like "people" then delete them using
> DROP USER.
>
> 3. Shell commands can by default be executed by a connected sqlplus
> user, without any
> particularly special privileges.  For example:
>
> SQL> !pwd
> /export/home/jonz
>
> SQL> host
> $
>
> I would be curious to know if this shellcode is built into one of the
> server-side client libraries or just sqlplus.  The fact that the
> behavior of the product is kept in the database is very suspicious.
>
> To disable this by the way, run $ORACLE_HOME/sqlplus/admin/pupbld.sql
> Then run this SQL Statement as DBA:
>
> INSERT INTO PRODUCT_USER_PROFILE
>   VALUES('SQL*Plus','%','HOST',NULL,NULL,'DISABLED',NULL,NULL)
> /
>
> 4. Auditing is turned off by default
>
> Combining this with a very proprietary protocol, Oracle's perverted
> naming service (TNS), and support for sacreligous rituals such as
> supporting plain-text passwords for linking databases together, it's
> no surprise that it should be relatively easy to hack someone's Oracle
> box.
>
> I think, however, most other DBAs also see these shortcomings which is
> why the average Oracle box is locked down pretty tight. Even though
> the vulnerabilities exist, finding a way to get your 0's and 1's to
> the average production database shouldn't be a trivial task.