作者QQ:654268465 Tel:18092015108 sky 模拟了下Oracle的SQL注入操作过程、出现的错误及对应的应急修复措施(利于国庆长假期间没有小孩打扰可以静下心将批量恢复脚本完善了下，整个过程大概持续了半个月修复了一些Bug)。如果数据库比较核心不允许有数据丢失的话，或用备份恢复后的数据查、缺、补漏都都有参考意义，毕竟数据无价。
1. Oracle SQL 注入过程
注入方式
从网上下载感染病毒的介质，在数据库实例创建时SQL
注入脚本被执行并创建了相应的触发器和加密存储过程。这种注入方式由于在数据库实例创建时用SYS
账号运行了被感染的脚本文件因此不需要依赖数据库中的DBA
权限的用户。这种注入方式通过在$ORACLE_HOME/rdbms/admin
下的prvtsupp.plb
文件中添加一个加密的过程和一个触发器的创建脚本，在用户创建实例时会执行prvtsupp.plb
该文件从而达到入侵的目的。通过对prvtsupp.plb
文件中的过程进行解密后的内容如下：
另外一种注入方式就是网上下载了被病毒感染的PL/SQL 或Toad 客户端工具，如果用户登陆这些工具时使用具有dba 权限的用户，则工具会在后台执行执行相应的病毒脚本并创建上面的过程和触发器。
注入行为
该触发器在每次数据库重启后执行存储过程，而存储过程执行时会判断当前时间距数据库创建时间是否大于指定的天数 ( 我这次遇到的是300 天) ，如果大于指定的天数则在数据库重启后将数据库字典基表TAB$ 备份后并清空。
在TAB$
表被清空后如果数据库不再重启的话，数据库后台alert
日志在报一系列ORA-00600
后会一直会报错ORA-00604
和ORA-00957
2. Oracle SQL 注入过程模拟
模拟直接执行原加密的存储过程，如下：
执行存储过程后关闭数据库再次启动发现报错ORA-00600 提示bootstrap 核心对象损坏。
3. 应急修复过程测试
本次模拟修复采用shell 脚本调用bbed 批量修改tab$ 表对应的块，来恢复tab$ 表删除的记录。由于只修改了tab$ 对应的簇表块并没有修复索引( 索引可以禁用，不建议修复) 。所以在修复后只能通过exp 将用户数据导出后进行重建数据库来恢复数据。
将受损的基表对应的SYSTEM 表空间数据文件上传到linux 平台执行相应的恢复脚本进行恢复如下：
修复完成后将文件拷贝回windows 平台，然后启动数据库( 建议以read only 方式打开数据库，我这里是测试环境懒的执行了)
导出对应的用户数据
4. 日常预检查、处理
对于生产库建议定期进行病毒特征排查，如何及时发现并且数据库没有重启且select * form tab$ 查询不为空，则可以通过手动drop 对应的存储过程和触发器( 通过以下语句来检查数据库是否已感染相应的SQL 注入病毒)。
select 'drop ' || object_type || ' ' || owner || '.' || object_name || ';'
from dba_objects
where object_name in ('DBMS_SUPPORT_DBMONITOR', 'DBMS_SUPPORT_DBMONITORP');
其次可以对用同版本数据库正常的prvtsupp.plb 文件来替换$ORACLE_HOME/rdbms/admin/prvtsupp.plb 感染病毒的文件，防止后续数据库新建议实例时再次感染病毒。
5. 后记
最近工作中遇到好几起windows下Oracle被SQL注入攻击的事，随之有了此文。也好长时间没有写博文了，一方面年龄大了，有小孩事情较多没有太多的时间，另一方面确实没有太多的精力静下心来去完成某件事。 原本打算通过手动通过bbed修复(修复一个启动数据库做trace跟踪定位有问题的块再手动修复)，无奈在手动修复完第5个块后果断放弃了，事实告诉你这是一个不可能通过手工操作完成的事。最后从网上找一些脚本，发现没有一个完善的处理过程且根本看不懂，最后硬着头皮自己写了一个。在这里做个测试，也算给有兴趣研究的人做个参考吧。 整个修复过程需要对堆表及簇表数据块结构有比较清楚的理解，建议可以参考Oracle DSI及自己dump块和bbed查看来了解。
