简析基于本地的Oracle安全扫描(转）

就像任何一个大的软件包，Oracle的默认安装不能让大多数安全的系统即装即用。默认安装的一些方面确实是明显不安全的。这就很大程度上依赖数据库管理人员来确定系统是正确配置的，从而避免这些不安全问题。

这篇文章将会探究安装Oracle关系型数据库管理系统的扫描，通过做这样的扫描，将会发现一些普通的安全隐患。当然一篇短短的文章不可能覆盖Oracle安装的所有安全隐患，本文围绕一个简单的脚本而写，读者可以从这里下载：.

这篇文章并不想取代一个完整的Oracle安全性审查，或是Oracle精进测试；此外，对于基于这篇文章的脚本是否可以被描述成一个搜索器也存在争议。文章的意图其实是说明要想检查出一些普通问题是多么简单，简单的安装弱点可以引起安全问题。脚本是使用Oracle标准内部语言PL/SQL编写，以便实用方便。针对文章的目的，脚本只适用于关系型数据库管理系统（RDBMS），并且只覆盖有限的测试集。

检查

这篇文章讨论了一个脚本以及一些它所执行的简单测试用例，脚本是围绕每一个测试而构造的。每一个测试检查以下每一段所描述的问题。

默认用户－检查已知的密码

最容易访问数据库的方法是利用默认帐户（default accounts）。那些默认帐户中的大部分都有大家都已知的默认密码。默认帐户在大多数数据库上不被安装，但是也有少量关键的会作为用户已经安装的例子和附加功能的一部分而一起被安装。

脚本的第一部分很难编码所有的默认用户，密码和它们的哈西表（hashes）。作为检查，只是简单地比较存储在数据库中的哈西表和脚本中提供的那些，如果存在一个匹配，那么默认用户的密码就保持不变。

很明显，这个问题的解决是改变密码或是删除不需要的用户。如果有些默认用户的密码被修改了，就要考虑其他问题了。如用户“dbsnmp”是由一个智能代理使用，作为Oracle企业管理器（OEM）来执行来自远程控制台的任务。如果密码被改变了，而且OEM正在运行，那么密码同样需要在文件 $ORACLE_HOME/network/admin/snmp_rw.ora file. 中修改

检查那些容易被猜出来的用户密码

提供的脚本不包含这项检查，因为这可以很容易从脚本中推导出来。读者检查正常用户密码可以到达的深度取决于读者自己。最简单的检查是查看用户是否设置密码和用户名一样，你还可以使用一个简单的字典，根据这个字典来做检查。从视图ALL_USERS中选择所有用户，然后产生另一个SQL脚本是相对比较简单的。例如可以是：

SQL> set head off

SQL> set feed off

SQL> set verify off

SQL> set termout off

SQL> set pages 0

SQL> spool check.sql

SQL> select 'connect '||username||'/'||username||';'

2 from all_users;
connect SYS/SYS;

connect SYSTEM/SYSTEM;

connect OUTLN/OUTLN;

connect DBSNMP/DBSNMP;

connect MTSSYS/MTSSYS;

connect PETE/PETE;

connect RAJK/RAJK;

SQL> spool off

然后运行输出脚本检查是否任何一个用户有和用户名相同的密码。其他“检查”脚本可以用同样的方法生成，通过使用一个或者从文件读入，或者存储在数据库表中的字典。

内在的用户(INTERNAL)连接

内在的用户名“INTERNAL”，Oracle 8i不赞成使用，同时被Oracle 9i删除了。作为替代语句“connect sys/sys as sysdba”被使用。对于Oracle8i，用户名“INTERNAL”有一个默认密码“ORACLE”。如果用户“SYS”没有改变它的密码，那么尝试作为内部连接可以使用密码“oracle”。

检查有“DBA”（数据库管理员）权限的用户

这项检查脚本中也不包含，纯粹是因为简单。在Oracle8i中存在大量系统权限和具有强大权限的默认角色。所有可用的系统权限都可见，用户“SYS”可以通过运行下面的选择语句得到，或者一个访问过这个对象并且预先知道用户名的用户也可以。

SQL> select * from system_privilege_map;

一个目的不纯的黑客可以使用任何数量的系统权限。在这个脚本中检查了两种系统权限。对于找出哪个用户被授权为角色“dba”的规律也是很有帮助的。当然，这并不能抵御滥用特殊权限的特殊用户；但是，一般情况下，黑客都是授权自己为“dba”或者使用一个有这种权限的帐号，这就很容易被发现。下面的SQL代码指出如何实现：

SQL> select grantee

2 from dba_role_privs

3 where granted_role='DBA';
GRANTEE

------------------------------

CTXSYS

SYS

SYSTEM
SQL>

不要忘记，角色可以被角色授予权限，所以要找到这些用户，需要递归查询。

检查权限包含“ANY”的用户和角色

如果一个用户或是角色具有包含单词“ANY”的权限，这对黑客来说就是很有用的。一个较好的例子就是权限“SELECT ANY TABLE”，黑客可能想看到其他用户的表中的数据，但是可能没有那个用户的访问权限或者不能看到用户的表。因为表可能是私有的（private），不开放给其他任何用户访问。但是如果黑客能够找到有“SELECT ANY TABLE”权限的其他用户，那么他就仍然能得到他想要的，例如：

SQL> connect dbsnmp/dbsnmp

Connected.

SQL> select name,password from sys.user$;

select name,password from sys.user$

*

ERROR at line 1:

ORA-01031: insufficient privileges


SQL> connect sys/change_on_install

Connected.

SQL> grant select any table to dbsnmp;
Grant succeeded.
SQL> connect dbsnmp/dbsnmp

Connected.

SQL> select name,password from sys.user$;
NAME PASSWORD

------------------------------ ------------------------------

SYS D4C5016086B2DC6A

SYSTEM D4DF7931AB130E37
2 rows selected.
SQL>

在这个例子中，用户“dbsnmp”不能看到“sys”的私有表“user$”，但是在授权“SELECT ANY TABLE”给“dbsnmp”后，表“user$”就可以被选择查询了。

检查具有“with admin”或者“with grant”特权的用户

这两个权力可以在给对象授权的时候添加。对象权限被授予给用户或者角色，让他们可以访问或更改对象。添加“with grant”选项意味着被授权的用户能将被授予的权限授权给其他用户。这意味着某一个用户可以将管理特定对象的权限传给没被授权可以访问整个架构的用户。

第二个权力“with admin”，可以在授予系统权限的时候授予。对象权限允许一个用户改变数据，系统权限允许用户改变架构，建立和改变对象。“with admin”与“with grant”相似，主要是允许有“with admin”的系统授权的接受者授予这种权限给其他用户。

这部分脚本输出任何被授予这两种权力的权限。这些权限，以及被授予这些权限的用户，使得黑客很容易找到一个取得对象和数据的方法，如果他们可以猜到一个用户的密码，而不必获取访问权限，或者成为“dba”用户，或者更高级别的用户。

检查外部用户（EXTERNAL）

外部用户是说允许一个应用程序用户通过操作登陆，并且由操作系统自己验证访问数据库的权限而不需要Oracle验证。这个特性非常有用，如果你想要运行批量工作或者更多工作，同时不想在脚本中艰难地编制用户名和密码，或者不想在命令行敲入用户名和密码，那么有了这个特性，用户名和密码就可以通过使用一条操作系统命令 ps -ef | grep sqlplus来获得。

这部分脚本定义一些由操作系统管理的数据库帐户。这些帐户的密码在SYS.USER$中被显示为EXTERNAL以说明他们是由操作系统验证的。使用这些帐户来避免密码在命令行可见，或密码被编码在脚本中，对系统安全来说是很好的方法。因为当黑客发现一个外部用户并获得了到它一个访问后，将会同时获得到数据库的一个访问。所以应当慎用或考虑不使用外部帐号。

除了这种方法，还有很多方法可以用来识别由操作系统验证的用户。如用户名前缀是POS$，它就可能是外部用户。一些安装文件参数也用来控制外部用户，它们是：remote_os_authent 和os_authent_prefix。讨论这些参数和其他形式的外部变量识别超出了本文章的讨论范围。对于本文来说，找出一些外部变量，并且提示黑客可能会不怀好意地使用它们已经足够了。

系统权限－ALTER SYSTEM and CREATE LIBRARY

在Oracle数据库中有很多系统权限。这些系统权限可以直接被授予给一个用户或角色。从系统视图中查询出它们，就可以看到可用的权限。这样的视图可以由以下的SQL语句产生：

SQL> select * from system_privilege_map;
PRIVILEGE NAME PROPERTY

--------- ---------------------------------------- ---------

-3 ALTER SYSTEM 0

-4 AUDIT SYSTEM 0

-5 CREATE SESSION 0

-6 ALTER SESSION 0

…

-225 ALTER ANY OUTLINE 0

-226 DROP ANY OUTLINE 0

-227 ADMINISTER RESOURCE MANAGER 1

-228 ADMINISTER DATABASE TRIGGER 0
126 rows selected.
SQL>

查看哪个系统权限被授权给了一个用户或是一个角色，使用下面的SQL语句：

SQL> select * from dba_sys_privs;
GRANTEE PRIVILEGE ADM

------------------------------ ---------------------------------------- ---

AQ_ADMINISTRATOR_ROLE DEQUEUE ANY QUEUE YES

AQ_ADMINISTRATOR_ROLE ENQUEUE ANY QUEUE YES

…

CONNECT CREATE TABLE NO

CONNECT CREATE VIEW NO

CTXSYS ADMINISTER DATABASE TRIGGER NO

CTXSYS ADMINISTER RESOURCE MANAGER NO

CTXSYS ALTER ANY CLUSTER NO

…

TIMESERIES_DEVELOPER CREATE VIEW NO
505 rows selected.
SQL>

本文选择了最显著的两个系统权限最为例子，是：“ALTER SYSTEM” 和 “CREATE LIBRARY”。第一个可能会允许黑客改变系统参数或更多，第二个权限，“CREATE LIBRARY”允许用户建一个库。这个权限非常危险，因为它可能导致权限的扩大。

utl_file_dir 位置

有很多Oracle数据库早期使用的参数，它们中的很少能被分析出来，这从安全角度考虑是很危险的。控制数据库包UTL_FILE读写目录的参数就是一个很好的例子。如果这个参数被设为“*”（不包括引号），那么UTL_FILE包就可以被读写到机器上Oracle安装用户（通常是用户（ORACLE）访问的任何目录。一个有“ALTER SESSION”权限的用户就可能会复制库缓存（library cathe）到一个跟踪文件，然后通过UTL_FILE读取文件的任何内容。如果添加任何用户或修改密码，那么清晰的文本密码都仍然会被看到（只要它不被从缓存中清除）。

下一项检查就是通过把这些参数列出来（这只针对信息），来发现这些参数都在哪儿。 这部分的最后一项检查是检查主要跟踪路径：如果utl_file_dir和user_dump_dest相同，那么你可能有和上面描述类似的问题。如果上面的情况都不满足，那就不值得找utl_file_dir了。可能某个人已经把它放到了一个路径下。

具有清晰文本密码的数据库连接

数据库连接允许用户很容易地访问其他数据库的数据。这些连接甚至可以通过使用同义字而隐藏起来，使得SQL不指示真实数据的地址。一个简单的数据库连接可以像下面这样定义：

Create database link test_link

Connect to scott identified by tiger

Using ‘oids’;

“using”字句支持或者是一个完整的连接字符串，或者是在tnsnames.ora中定义的一个服务器名称。从其他数据库重新得到数据可以使用下面的例子：

SQL> select * from scott.emp@test_link;

有两种数据库连接：共有（public）和私有（private）。Public数据库连接允许任何包含PL/SQL代码的用户通过连接访问远程数据库。Private数据库连接提供更好的安全保障，远程数据库只允许那些拥有连接帐号的用户或是PL/SQL代码访问。

很可能建立一个数据库连接，作为普通用户而不是专门用户连接到远程数据库。样本脚本中的测试允许你观察分配给连接到这个数据库的任何数据库连接的用户名和密码，同时还有权威用户和密码

数据库连接对黑客来说是一个好方法，可以从一个不安全的数据库访问一个安全数据库。黑客可以访问一个防御较弱的数据库，找到一个安全的数据库的用户的用户名和密码。然后他就可以通过连接或直接登陆来访问数据了。

总结

从脚本的输出也可以收集到其他信息，或者可以很容易地改变脚本来提供其他没有覆盖到的细节。使用样本脚本作为一个开始，再添加或修改脚本来覆盖其他问题，这样相对来说比较简单。脚本允许添加附加检查来使数据库的规范检查更自动化。

一个这样的检查可以是检查有多少用户有角色“dba”。如果任何用户的密码难度不够大，这个角色都将是危险的。检查你的数据库中的每个用户都能做什么，哪个对象是可执行的或可访问的，是被谁执行和访问的，这些检查都是重要的。

监测Oracle数据库中已知的使用和已经被发现的漏洞也是很有用的。监测运行数据库的操作系统的安全，监测数据库连接的网络的安全也是很重要的。同样值得检查数据库中对象的状态和PL/SQL代码，来确定没有任何用户改变任何事情或为了将来的使用添加任何对象。

Oracle同时提供执行权限被授予为public的很多包和对象，这就是说，每个用户都可以访问它们。黑客可以不怀好意地使用用一些如UTL_FILE，UTL_HTTP和UTL_TCP的包。这一点是要说很多public包是很容易被访问的，而可能是不应该被访问的。评估什么访问是被授权的同时废除所有的也是不需要的。