oracle rootkits第二式——“躲猫猫”-凯发k8游戏

前言

各位小伙伴们，今天咱们接着聊oracle rootkits的话题。这是oracle rootkits系列文章的第三篇。相信大部分小伙伴已经对数据库后门和rootkits技术有了一定的认识。上次给大家介绍了oracle rootkits第一式“裸奔”，（插入链接）文中主要介绍了三种入侵者常用的手法，以及破解方式。第一式主要在存储过程、触发器组成的oracle rootkits中使用广泛。目标就是穷尽一切办法隐藏不法分子在数据库中创建的恶意存储过程、函数、触发器等。这种方式多用于针对数据库的勒索软件中。

数据库后门除了藏在存储过程、函数、触发器之中，更常见的是，在数据库中埋入一组dba用户。不法分子可以利用这组dba用户随时“合法”夺取数据库中的敏感数据。要在数据库中隐藏一个dba用户，通常就会用到数据库级的rootkit技术，我们称其为oracle rootkits的第二式“躲猫猫”。

“躲猫猫”主要解决两个核心问题：

1.躲谁？

2怎么躲？

咱们以隐藏一组dba用户hacker躲避小王（dba）检查为例。（这种方法还可以隐藏存储过程、函数、进程等）小王利用dba检查脚本对数据库dba用户进行统计，防止dba用户数量和内容发生变化。检查dba的脚本获取dba用户信息主要来自视图dba_users或all_users。为了简化描述，我们就假定访问的是视图all_users。至此第一个问题有了答案，为了防止小王发现黑客加入的新dba用户hacker，黑客就要想办法防止all_users查询出hacker用户。

接下来，我们需要解决第二个问题，首先要找出all_users的结构中哪部分是薄弱点，并可能被黑客所利用。all_users视图的内容如下图：

整个视图就是以基表sys.user$和sys.ts$为基础，在一定条件下进行语句查询。黑客多从where的判断条件入手，这样对all_users影响最小，也较难被发现。于是沿着修改where判断条件的思路：黑客主要采取两种办法：

1. 偷天换日—假冒all_users

2. 假道伐虞—修改判断条件

偷天换日

这种思路的核心是在原来where条件的基础上添加更多的限制条件，使黑客建立的hacker用户满足限制条件，从而不被查询出来。例如在判断条件中添加 and u.name != ‘hacker’防止查询读出hacker用户。

具体过程需要黑客利用拿到的数据库权限，重建视图all_users，并删除或关闭审计记录。这种偷天换日的方法，可以让黑客悄无声息的将自己改造过的all_users替换掉系统真正的all_users，且该方式在足够权限的支持下操作起来简单、便捷，对技术要求较低，但同时被发现的几率也略高，即便黑客将操作记录删除净尽，也可能会被具备查询木马能力的数据库安全扫描产品揪出其中的问题。all_users的内容和大小的改变会有多种方式发现all_users变化和问题，于是很多黑客就采用更隐蔽的手法——假道伐虞。

假道伐虞

这种思路本质也是在where条件上动手脚，但方向和“偷天换日”截然不同。 “假道伐虞”是在不改变all_users的前提下，通过破坏where判断条件，来防止hacker被查询出来。all_users的查询条件有三条，如果hacker不满足三个条件中的任意一条就不可能被查询出来。

where u.datats# = dts.ts# 

  and u.tempts# = tts.ts#

  and u.type# = 1;

all_users中列出的用户需要满足 sys.user$.datats = sys.ts$.ts#。如果该等式不成立，那hacker就显示不出来。datats#中的数值一般在0-4之间，使用update语句对hacker用户进行调整，将其datats#改为1337，超出0-4的范围内，使得sys.user$.datats = sys.ts$.ts#等式无法成立，从而查询不到hacker，但hacker依旧存在。下图红线部分明显显示，虽然hacker已经查询不到，但依旧可以用hacker进行登录。

注意上图在执行“update sys.user$ set datats#=1337 where name = 'hacker' ”之后，再通过all_users已经无法发现hacker用户了，但如果此时登录，hacker用户依旧可以用来登录，并且还是dba用户权限。这种方式比第一种“偷天换日”要隐蔽得多。即便有审计记录，如果对数据库不是很熟悉，也未必会把修改数据和有用户隐藏联系起来。借着sys.user$的道巧妙的破坏了all_users的查询条件，帮助hacker用户实现隐身。

凯发k8游戏的解决方案

验证自家数据库被入侵与否，先别着急去挨个数据库翻all_users， oracle中类似all_users的视图有不少，例如v$session, gv_$session, flow_sessions, v_$process等都存在类似的风险，并且第二种方式压根没有修改视图，翻也翻不出东西。下面安华金和数据库攻防实验室的专家给大家支招，告诉你如何检查自家数据库是否已经被这种方式所入侵。

第一种方式检查的关键是变化。可以通过前后hash值比对来发现哪些视图、存储过程、触发器等hash值发生了变化。在排除黑客改动后，建议建立一组关键视图、存储过程、触发器的hash值列表，一旦hash值发生变化，就要提高警惕，很可能是黑客所为。

第二种方式的检查原理是发现异常用户。在不同的基表、视图中去查询用户，经过相互对比，如果有的用户在有些表中存在，而有些表中不存在，那么，这类用户很可能就是使用第二种方式隐藏的用户。面对异常用户，可以用如下语句检查：

select username from v$pwfile_users where username not in ('internal')

 minus 

select name from sys.user$ where type# > 0

寻找数据库中潜伏的后门是一种比较复杂的工作，而且很多部分需要根据目标和环境采用不同的方式，所以，建议把这项工作交给专业的公司，使用专业的产品。在破解上述两种后门方面，安华金和的数据库漏洞扫描产品有过不少实践，帮助破解后门使用的上述隐身技术，通过多种独有技术揪出潜伏在数据库中的安全威胁。