比特币攻击案例重现江湖
2017-05-05 14:35
344 查看
天凌晨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的表数据即可。
请大家仔细检查你的环境,不要再出现类似的问题,为自己或公司造成损失!如果遇到此类问题,请联系我们,获取专业技术支持!
首先我们来看看数据库的日志是什么?
?
这里通过日志,直接查询最近有过ddl操作的对象,发现果然跟alert log完全一样。如下所说:
我们不难看出,上述6个对象,可能是问题的关键。那么我们就来看看上面6个对象的内容是什么。首先我们来看下trigger:
很明显,这是hacker创建的恶意trigger。遗憾的看上去名字是这样,具体查不到内容?既然如此,我们先来看看存储过程,发现3个存储过程都是加密的。通过解密之后,发现代码如下:
?
通过看上述解密之后的代码,才恍然大悟,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 和存储过程:
?
经过检查发现客户的业务用户portal_his下面被创建了14万个Job。由于内容实在是太多了,因此简单拼一个SQL来删除有问题的Job。
?
最后恢复之后,客户反映业务基本上正常,但是仍然有部分业务数据看不到,详查之下发现有部分表的数据看不到了?但是客户也说不上来,到底哪些表有问题?那么怎么判断呢?
其实很简单,通过dba_objects.last_ddl_Time来判断该业务用户下最近被ddl操作的表有哪些即可,最后发现有68个表。通过ODU恢复这部分被truncate的表数据即可。
请大家仔细检查你的环境,不要再出现类似的问题,为自己或公司造成损失!如果遇到此类问题,请联系我们,获取专业技术支持!
相关文章推荐
- 首张“微信身份证”签发;阿里调查网络谣言攻击事件;比特币重返1.6万美元关口丨价值早报
- 讲述ssh服务攻击案例及事件分析
- Flink之CEP案例分析-网络攻击检测
- DNS 攻击方式及攻击案例
- Linux下分析SYN flood攻击案例
- 如何避免比特币等数字货币平台被攻击?极验已有成熟解决方案
- XSS蠕虫攻击案例学习
- DNS 攻击方式及攻击案例
- 讲述ssh服务攻击案例及事件分析
- OAuth 2.0攻击面与案例总结
- 致 BitClub 矿池,你们为什么要对比特币网络发动交易延展性攻击?
- 伊朗网军黑百度声名大噪 伊朗网络军重现江湖
- Linux下分析SYN flood攻击案例
- 讲述ssh服务攻击案例及事件分析
- Shell脚本防攻击案例
- 真实案例:网站遭遇DOS攻击
- 俄罗斯黑客攻击了我的服务器:我变成了一名比特币挖矿工
- VNC密码验证绕过漏洞攻击案例(2)
- 360MeshFire Team:CVE-2016-5696 TCP旁路攻击分析与重现
- 黑客演示网站挂马攻击案例