夜已深
销售老魏的电话突然响起
铃声仿佛比往日急促
是曾经拜访过的一家客户，对方是运维主管
老魏赶紧接起来
未来得及问候和寒暄
对方第一句话是
“我们的数据库启动不了了！！！，我们被AfterConnection数据库病毒感染了”
数次重启后仍然无法正常工作
问题一直解决不了，我们的业务访问受到很大影响……
这个，能找专家帮忙解决吗？
挂了电话，老魏马上拨通了攻防实验室的电话
当晚，安全专家远程接入用户现场
尝试进行技术还原，找到事件原因
用户现场报错如下
综合用户10046 event跟踪的结果和从system表空间数据文件抽取tab$表的结果
可以初步判断客户数据库无法启动是由于tab$中数据被清空导致
通常，数据库在启动阶段会做一致性检查
其中会去tab$中找寻obj$指定的对象
一旦找不到会导致一致性检查中的语句执行错误
最后展现出数据库启动失败
根据对obj$记录的研究发现
客户数据库中存在3个恶意存储过程和2个恶意触发器
恶意触发器中存在startup型触发器
只要启动数据库就会执行指定的存储过程，执行恶意命令
从而对数据库进行破坏
启动中观察到tab$数据被清空就是其中一个恶意存储过程所为
整个恶意攻击过程还原后
攻防实验室建议用户三种解决方案：
方案一：
用dul工具将Oracle数据文件中的应用数据导出
新建库
再将数据导入
方案二：
四步走
第一步，恢复tab$数据启动数据库成功。
第二步，删除数据库中存在的恶意存储过程和触发器。
第三步，破解加密的恶意存储过程，从中找出还有哪些破坏数据库的地方予以修复。
第四步，有针对性的部署安全设备防止类似事件再次发生。
进过激烈的讨论，方案二虽然更为迅速，但方案一更为保险，用方案一吧
深夜，渐渐过去。。。
清晨7点，用户数据终于恢复正常，哈8点上班前，可以正常开工了、
结束？
NO！
现场应急虽然结束，危险还在隐藏，但安全人的天责，让我们还要继续，休息2小时，继续。。。。
兵分两路
A队：攻防实验室安全专家
任务：对恶意程序进行更深入的脚本分析，形成详细材料
B队：技术工程师
任务：出发前往用户现场，详细了解用户系统结构及安全风险点
A、B两队实时信息对称、进行事件复盘
事情发生第三天
用户收到来自安华金和数据库攻防实验室全方位技术分析，
包括整个事件的技术还原及防范此类攻击的解决方案
经过安华金和数据库安全专家分析，此次攻击属于数据库恶意注入攻击，我们看到的很多数据库勒索事件正是利用了这种方式。
黑客在数据库工具或数据库安装包/升级包中加入恶意代码。数据库管理员不慎使用感染了恶意代码的客户端工具或升级包，来操作或升级数据库，恶意代码就会被夹带进入数据库中。这些恶意代码往往是存储过程+触发器的组合形式，当权限足够，它们会产生阻止正常用户访问数据库、删除转移关键数据等恶劣行为。比较恶劣的行径是，黑客以用户数据或恢复数据库为交换条件，威胁用户支付赎金，达到勒索目的，这类恶意注入也就是我们所说的勒索病毒攻击了。但本次没有人要求赎金，应该属于非利益诉求的恶意攻击。
针对这种病毒攻击的感染源，我们继续展开分析：
恶意攻击行为的分类
从攻击行为和攻击路径不同，可以将恶意攻击行为分为两类。从攻击行为来看，又可以分为阻止数据库正常使用和删除转移关键表信息两大类。
1）第一类：阻止数据库正常使用
常见方法有二：1、直接破坏数据库系统表，导致数据库无法正常启动。遭遇该情形，数据将彻底无法启动，给用户带来巨大影响。就大部分样例来看，即使是勒索目的，支付赎金后勒索者也很可能没办法真正恢复。建议用户遇到这种情况不要轻信对方。2、调用死循环存储过程无限弹出窗体，阻止用户正常登录数据库。这种方式主要在数据库图形化界面客户端上使用，并且一般只能阻碍低权限用户登录；DBA等高权限用户可以强行登录成功，因此只要高权限用户登录后删除触发器即可破解。
2）第二类：删除和转移关键表信息
常见的也有两类。1、对表内信息进行转存后清空表。查找新建的、名字怪异的表就可能找到被攻击者清除的数据，把数据导回即可。2、直接清空表，并未存储。如果是这种情况的勒索攻击，即便用户支付了赎金，勒索者也无法将数据还给用户。
现实中，攻击者往往多种手法共用。大多情况是先出现一个问题，用户贸然切成SYS用户登录数据库处理，结果虽然解决了一部分恶意触发器和存储过程，但同时也激活了更多更危险的恶意触发器和存储过程。因此，用户如果遭遇此类数据库恶意攻击或勒索事件，请先备份数据表空间文件，再尝试进行处理，防止扩大对数据库造成的损害。
上面是从攻击行为来区分，从攻击路径来看，还可分为远程攻击和本地攻击。
1）第一类：远程攻击
其中，远程攻击的比例比本地攻击更多。远程攻击主要来自于各种数据库工具中的自动执行脚本。例如plsql dev中的login.sql和afterconnect.sql ;toad中的toad.ini；sqlplus 中的glogin.sql和login.sql等。建议一定使用来自官方的工具，且使用前检查上述脚本文件的内容。
2）第二类：本地攻击
本地攻击则多是由于数据库系统的安装包或升级包被植入了恶意代码。在数据库安装或升级过程中，恶意存储过程或触发器已被带入数据库。所以，建议安装包和升级包务必从数据库厂商官网下载。
本次原因事件分析：
而本次事件，根据用户的追查，尚未在多台运维设备上发现有远程攻击注入脚本；对于安装包和升级包是否存在问题，尚未明确，需要进一步观察。由于无数据库审计产品，也无法明确攻击来源了路径。
至此，该事件还需要进一步的了解与观察，由于近年来，以数据库为目标的攻击事件明显增加，且越来越多的以勒索财产为主要目的，这种事件呈现越来越广泛的趋势。因此我们将对这些攻击的行为阶段和所能采取的防护措施进行进一步的分析，以帮助DBA们和用户迎接这种挑战，减少数据资产的损失。
数据库病毒攻击和发作的三个阶段
从阶段划分，数据库恶意攻击会经历三个阶段：感染期、潜伏期和发作期。如果能够提前进行数据库安全防护的建设，能够较好的应对此类攻击事件，有效降低企业面临的恶性影响。
在感染期，首先是感染源的接触，在这个阶段病毒会利用网上的免费维护工具或安装包或升级包，潜伏在这些免费产品中，用户将数据库通过这些免费产品进行访问或暗转或升级，将感染上数据库病毒。
潜伏期：待数据库被感染后，病毒通过触发器等隐藏在数据库内部，然后依据数据库运行事件或时间，进行病毒危害触发。
发作期：一旦爆发，会利用触发器和存储过程对数据库的关键位置进行破坏。
1）感染期
数据库被感染恶意程序主要通过两种途径：数据库客户端和数据库升级包。数据库升级包在官网有标注的MD5值。请用户一定计算MD5值，防止使用带有恶意代码的升级包，升级数据库。数据库客户端由于配置文件的复杂性和后期DBA的二次开发，虽然可以依赖MD5值，但往往效果不好。用户可以在网络中对数据库包中的内容和特征进行甄别，阻断具有恶意注入特征的数据包即可阻断此处的攻击。
恶意攻击的最佳防护时机是阻断感染路径，在潜伏期消除恶意程序的影响，如果拖到发作后，虽然有解决办法，但很可能已经造成数据资产损失。
解决方案：数据库防火墙+数据库审计
通过部署数据库防火墙发现和切断感染路径，经过对多样本特征的分析，以及样本格式的理解，我们建议用户使用具备能读懂sql和能解密加密数据库两项能力的数据库防火墙。其中，能解密、加密数据库即可以对如Oracle采用的密文存储过程进行解密操作，另外，如果第三方工具向数据库发送大量加密包形式的数据，也只有准确破解加密包才能为语法分析做好准备。如果不能解决解密问题，最终只能对加密的恶意存储过程进行指纹比对，这种方法误报率和漏报率都很高。
另一方面，能读懂sql语句是指基于sql语法解析，联系上下文理解存储过程或包中是否存在恶意行为。在unwrap的支撑下数据库防火墙能把所有去向数据库的加密存储过程明文化，再通过sql语法分析器对明文进行恶意行为的匹配。数据库防火墙不是单纯的就单句sql进行行为分析，而是根据上下文环境的sql行为对整个sql语句包进行分析。当其中存在命中安全规则的多个必要点时，可以判断该语句包存在恶意行为，语句包会被阻断，并向相关人员进行告警。
数据库防火墙拦截下恶意数据包后，再通过数据库审计系统记录的详细数据包流向信息，定位出恶意数据包来自哪里，帮助用户在海量设备中快速定位安全问题发生点，为用户能找到勒索病毒源头，彻底修复安全问题提供依据。此外，数据库审计系统能够提供同样的恶意程序识别，区别于数据库防火墙的是，旁路部署的审计系统是在发现病毒后，以实时告警的方式提醒用户注意，那么，至于防火墙还是审计更合适，需要依据用户的业务系统要求来选择。
2）潜伏期
恶意程序感染数据库后会计算数据库运行时间，通过时间来判断自己继续潜伏还是爆发。常见的数据库攻击样本潜伏期为1-4年。这期间数据库虽然已被感染，但并不会受其影响。所以该阶段是清除病毒的好时机。建议用户加强数据库上存储过程和触发器的检查，及时清除潜在的恶意隐患。
解决方案：数据库漏扫+技术服务
当用户错过了在感染路径上阻断恶勒索病毒的机会，建议用户定期使用有检测数据库勒索病毒功能的数据库漏扫工具，对数据库进行定期检查，争取在潜伏期彻底消灭勒索病毒。原理是用户给扫描工具sysdba权限，扫描工具深入基表，利用特征库中的特征对触发器、存储过程、包等进行逐项检测，一旦发现异常会在最终的报告中生成详细的描述以及具体的修复建议，在这个过程中，可寻求专业的数据库安全企业提供咨询服务，帮助排查病毒，以及提供相应的安全服务，清楚恶意程序。
3）发作期
一旦时机成熟（满足恶意程序发作的条件），被注入的病毒将开始对数据库展开攻击：阻止数据库正常使用、删除有价值数据、阻碍合法用户正常登录。此阶段相对最难处理，可惜大部分用户直到这个阶段才发现数据库被感染，倒也不是没办法补救，可以通过数据库文件进行问题定位，尝试恢复用户数据和清除恶意触发器和存储过程。虽然防范大于治疗，但由于种种原因大部分用户是在勒索病毒爆发后才发现。爆发后由于不同勒索病毒对数据库的影响以及触发的条件各不相同，没法给出统一解决方案。但建议用户，第一时间备份数据库文件；尽量不要尝试变更登录方式或对数据库进行操作，避免触发更多的恶意触发器和调用更多的恶意存储过程，对数据库造成二次、三次伤害。
解决方案：寻求技术服务
发作后，为了将损失降到最低，需要及时寻找安全咨询及服务团队，最短时间内排查问题、清除病毒、进行数据库恢复，并提出有效的安全加固方案。
综上，我们建议用户建设有效的安全防护体系来抵御恶意攻击，同时，多种技术手段的组合也能够形成良好的协同配合效果。
数据库漏扫+数据库防火墙/数据库审计
数据库漏扫可基于授权检测方式针对数据库中异常包、存储过程、触发器、各项参数以及后门的检测语句，对已知威胁进行检查，及时排除数据库隐患。
数据库防火墙利用解密技术和sql分析技术，依托上下文sql语境，动态抓出存在恶意行为的语句包，进行实施拦截。
数据库漏扫侧重已知隐患扫描，数据库防火墙侧重特征隐患拦截和告警，双方既是相互独立的也是相互联动的。数据库防火墙拦截到一个新型隐患，数据库漏扫则根据这个新型的特征更新扫描检测项；数据库漏扫发现安全隐患，则数据库防火墙根据隐患特征更新防护策略，优化已有安全策略，进一步降低误报率。
五、一些可行的安全建议
除了建设安全防护体系，数据库管理人员在日常运维中也需要谨慎操作。保守来说，如果做到以下几点，你可以避免至少50%的数据库恶意攻击，：
1.不要在非官方途径下载数据库相关工具，如数据库安装和升级包；
2.经常检查数据库链接工具的脚本是否正常；
3.使用最小权限原则，尽可能降低给Oracle用户的权限，如限制创建存储过程或触发器等。
PS：针对本次数据库恶意攻击事件，为防止其他用户中招，安华金和能够提供攻击验证脚本和检查脚本，用户可及时自查防范。
下载地址：http://dbsec.cn/upload/prvtsupp.zip
产品咨询：4000 258 365 
