关于比特币攻击Oracle数据库揭秘与防范.docVIP

关于比特币攻击Oracle数据库揭秘与防范 　　风险从来都不是臆想和草木皆兵，就在你不经意的时刻，可能风险就突然降临到我们的身边。 　　2016年年底，国内很多用户的 Oracle 数据库遭遇突如其来的比特币攻击事件，大家种种猜测、揣摩、重试，引发了一次小小的数据恐慌。直至今日，还有用户爆发出该问题。现在我们再次回顾与总结，与中国的数据库用户们共为警醒。 　　我们知道，几乎绝大多数数据库的客户端工具，在访问数据库时，都可以通过脚本进行一定的功能定义，而这些脚本往往就是安全问题的漏洞之一，黑客通过 JOB、触发器、存储过程对数据库进行修改和破坏，手段非常初级，但是也非常巧妙。 　　问题症状 　　很多用户在录数据库时发现该问题，数据库应用弹出“锁死”提示，并且威胁说需要向黑客发送5个比特币方可获得解锁。 　　在客户端，可能获得类似的提示信息： 　　除了这些警示和勒索信息，真正的攻击是在数据库中创建了大量的攻击程序。 　　若攻击的核心代码包含以下语句，则会 Truncate 数据表：STAT：=truncate table ||USER||.||I.TABLE_NAME。 　　我们对事件进行了深入分析，找到问题的根本原因是用户从互联网上下载的盗版PL/SQL Developer 工具（尤其是各种绿色版、破解版），在使用工具的?^程中用户的权限自然被附体地进行了入侵。 　　受感染文件 　　在该软件的安装目录有一个脚本文件 AfterConnect.sql， 正版软件的这个文件为空，此时 AfterConnect.sql 开头被伪装成一个 login.sql 的脚本内容，有清晰的注释代码： 　　实质内容被加密，用户只能通过 unwrap 进行解密（要留意解密程序也可能存在恶意代码）： 　　无疑，黑客是非常了解 Oracle 数据库的，其脚本代码的核心部分，解密后如下（做了删减）： 　　同时，黑客非常专业，在程序的开端做了以下判断： 　　也就是，判断数据库创建时间大于1200天，才开始动作（这个判断相当有见地，小库和新库，数据少不重要，先放长线钓大鱼），如果你的数据库还没有爆发，那可能是因为时间还没有到。 　　如何应对 　　如果数据库遭遇到这个问题，可以将 JOB 参数 job_queue_processes 设置为 0 ，屏蔽掉 JOB 的执行，然后重启数据库。可以清除注入对象，这些对象可能包括以下同名触发器和存储过程： 　　数据安全的十六条军规 　　安全防范 请从今日开始 　　这次数据库安全事故，因为受害者众多，引发了企业的普遍关注。有的企业甚至要求停用PL/SQL Developer这一工具。但是我们知道数据库类似的门如此之多，如何能够从根本上提升数据库管理的安全，减少数据运维风险呢？ 　　我曾在《数据安全警示录》一书中总结了种种数据安全风险，提出了很多预防措施和手段，在此整理其中一些建议供大家参考。 　　数据安全可以基于五个纬度来梳理：软件安全、备份安全、访问安全、防护安全、管理安全。并据此建立相应的安全防护措施。 　　在这五大方向中，可能出现两种性质的安全问题，第一，由于内部管理不善而导致的数据安全问题；第二，由于外部恶意攻击入侵所带来的安全问题。通常我们把安全问题狭义化为后者，这实际上是片面的，在数据安全问题上，前者造成的数据损失、数据损毁，其发生率和影响度都远远超过后者。 　　在企业数据安全中，这五大方面是相辅相成、互有交叉、共同存在的，其中软件安全是数据库安全的基础，而备份安全是最重要却最容易被忽略的方面。有效备份才能在故障之后获得及时的恢复和挽救。很多历史事件表明，备份安全问题导致的企业伤害可能远远大于黑客攻击。 　　针对本次的比特币勒索事件，我抽取书中的观点，总结提升数据库安全的“16条军规”供大家参考。 　　■备份重于一切：我曾经在总结的DBA四大守则的第一条就指出，备份重于一切。对于重要的生产环境，适当建立备库进行数据保护，查询分担，会减少生产库的风险；而在故障发生时，有效备份可以保证系统获得及时的恢复和挽救； 　　如果有什么会让DBA们从梦中惊醒，那就是没有备份！ 所以对于数据库运维来说，第一重要的是做好备份，有备方能无患； 　　■严格管控权限：在进行用户授权时一定要遵循最小权限授予原则，避免因为过度授权而带来的安全风险。本次安全风险，如果用户不具备DDL权限，那么也不会遭到风险； 　　■明确用户职责：明确不同的数据库用户能够用于的工作范围，职权相称，最大限度避免错误，降低风险。 即便是拥有管理员职责的用户，也应当遵循以不同身份执行不同任务的习惯； 　　■密码策略强化：毫无疑问，数据库用户应当使用强化的密码规则，确保弱口令带来的安全风险，很多数据泄露问