love wife & love life —Roger 的Oracle技术博客

Phone:18180207355 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务

比特币攻击案例重现江湖

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客

本文链接地址: 比特币攻击案例重现江湖

今天凌晨4:50节点公司400转过来的求助电话,来自广西某个医院的客户;电话中说数据库被攻击了,业务完全停止,言谈之中表现的时分地迫切和着急。

首先我们来看看数据库的日志是什么?

大家不难看出,很明显跟2016年11月份爆发的比特币攻击案例如出一辙。这又是sql rush Team干的好事。很显然,我们去年大力宣传的比特币攻击事件,仍然被很多企业客户所忽视,最终出现了今天的悲剧。言归正转,如何处理这个问题呢?

这里通过日志,直接查询最近有过ddl操作的对象,发现果然跟alert log完全一样。如下所说:

 

我们不难看出,上述6个对象,可能是问题的关键。那么我们就来看看上面6个对象的内容是什么。首先我们来看下trigger:

很明显,这是hacker创建的恶意trigger。遗憾的看上去名字是这样,具体查不到内容?既然如此,我们先来看看存储过程,发现3个存储过程都是加密的。通过解密之后,发现代码如下:

我们可以看出,SQL rush Team还是很熟悉Oracle的,对于dbms包的利用,比我们都熟悉呀!

通过看上述解密之后的代码,才恍然大悟,Hacker居然是在Trigger和存储过程名称后面加了9个空格;注意是9个空格,一个都不能少。

我们再仔细阅读前面2段代码,可以看出这是比较坑爹一个Heacker。通过轮寻会不断产生truncate table 的Job,而且做这些操作之前会通过表的分析时间来判断数据库的运行时间,如果超过1200天,则爆发这个勒索行为(因为长时间运行,说明数据库是有价值的)。

最后一个存储过程会限制程序等连接,导致客户业务无法访问数据库。

了解了上述3个存储过程之后,解决方法就不难了,大致如下:

1、alter system set job_queue_process=0 scope=both ;并重启db(为什么要重启呢?因为此时数据库肯定已经产生了大量的library cache lock,无法操作)。

2、drop上述trigger 和存储过程:

3、删除Hacker创建的大量Job

经过检查发现客户的业务用户portal_his下面被创建了14万个Job。由于内容实在是太多了,因此简单拼一个SQL来删除有问题的Job。

4、确认被truncate的表。

最后恢复之后,客户反映业务基本上正常,但是仍然有部分业务数据看不到,详查之下发现有部分表的数据看不到了?但是客户也说不上来,到底哪些表有问题?那么怎么判断呢?

其实很简单,通过dba_objects.last_ddl_Time来判断该业务用户下最近被ddl操作的表有哪些即可,最后发现有68个表。通过ODU恢复这部分被truncate的表数据即可。

 

请大家仔细检查你的环境,不要再出现类似的问题,为自己或公司造成损失!如果遇到此类问题,请联系我们,获取专业技术支持!

    分享到:
18180207355
加Q咨询