事件過程

2012年10月19日上午，同事在日常巡檢時發(fā)現(xiàn)一套對外服務(wù)的電子商務(wù)系統(tǒng)后臺Oracle數(shù)據(jù)庫中出現(xiàn)了一個名為zwell的用戶，并且，該用戶具有DBA權(quán)限。

按照管理規(guī)定，所有的Oracle數(shù)據(jù)庫均有DDL觸發(fā)器，查看觸發(fā)器發(fā)現(xiàn)：

1CREATE ZWELL CREATE USER zwell IDENTIFIED BY ******* WD_WEB 2012/9/7 13:53:59 11028547 FALSE SYSTEM 5 WD_WEB 57 ptserver8 10.x.x.x tcp DATABASE

1WD_WEB 12200617 ROLE PRIVILEGE GRANT 2012/10/9 15:38:20 10.0.8.10 grant dba to zwell

此用戶在2012/9/7 13:53:59，通過CREATE USER zwell IDENTIFIED BY ******* SQL語句創(chuàng)建，發(fā)出此SQL的服務(wù)器為WEB服務(wù)器集群第8臺(ptserver8)，IP地址為WEB集群F5接口地址(10.x.x.x)。并且，在2012/10/9 15:38:20，通過grant dba to zwell SQL語句，將zwell用戶提升為DBA權(quán)限。

此用戶已建立了1個多月，例行檢查只檢查擁有DBA權(quán)限的用戶，導致此用戶被建立很長時間后才被發(fā)現(xiàn)。

通過對WEB服務(wù)器的apache日志進行檢查，在2012/9/7 13:53:59秒前后有大量的SQL注入行為，發(fā)出SQL注入入侵的源IP(113.71.184.32)屬于廣東省佛山市電信(如圖1所示)

圖1

但由于apache日志記錄時間順序問題，導致當時并未找到SQL注入的對應(yīng)日志。

10月19日下午，緊急對此電子商務(wù)網(wǎng)站進行應(yīng)用漏洞掃描，發(fā)現(xiàn)高危漏洞。

10月19日夜間， 鑒于短時間內(nèi)無法確認被入侵途徑及目的，經(jīng)多方商議，建議先進行如下處理：

1.應(yīng)用系統(tǒng)數(shù)據(jù)庫用戶存在IMP_FULL_DATABASE權(quán)限，而此權(quán)限應(yīng)為過度授權(quán)，擁有此權(quán)限則可創(chuàng)建用戶。進行權(quán)限收回。

2.盡快修改數(shù)據(jù)庫賬戶密碼，以及相關(guān)操作系統(tǒng)密碼。

3.將數(shù)據(jù)庫版本由10.2.0.1升級至10.2.0.5。

4.對數(shù)據(jù)庫內(nèi)關(guān)鍵信息進行審計。

10月20日早晨，對apache日志進行仔細檢查后，確認此次入侵為SQL方式入侵，入侵入口為/service/service.do盲注方式，發(fā)出SQL注入入侵的源IP(119.57.81.78)屬于北京市東四IDC機房。

2012年10月20日下午，再次檢查發(fā)出創(chuàng)建用戶SQL的ptserver8服務(wù)器的apache日志，發(fā)現(xiàn)了與創(chuàng)建用戶對應(yīng)的日志信息(如圖2所示)。

圖2

圖3

創(chuàng)建用戶操作也是通過/service/service.do進行SQL注入，至此，整個入侵流程均已查清。

事件分析

在此次安全事件中，黑客使用WEB頁面的盲注漏洞，采用SQL注入的方式創(chuàng)建了zwell用戶，并且利用了Oracle 10.2.0.1的提權(quán)漏洞，賦予zwell用戶DBA權(quán)限。

經(jīng)驗教訓

1.WEB應(yīng)用應(yīng)進行完善的代碼檢查，避免SQL注入漏洞

有很多方法可以避免SQL注入漏洞，比如，最常見的，使用綁定變量，但由于此應(yīng)用程序為外包開發(fā)方式，供應(yīng)商之前已開發(fā)了一套基礎(chǔ)版本，此版本為基礎(chǔ)版本的升級版本，因此，基礎(chǔ)版本存在的問題也一并帶入了生產(chǎn)環(huán)境，導致此漏洞的存在。

2.未進行完善的代碼安全檢查

目前有很多工具可以對應(yīng)用進行安全檢查，類似的SQL注入型漏洞一般都可以檢查出來，但由于倉促上線，經(jīng)驗也不夠豐富，因此，導致應(yīng)用帶著漏洞上線。

3.數(shù)據(jù)庫版本未升級

這是一個典型的問題。數(shù)據(jù)庫版本過低導致存在提權(quán)漏洞，如果數(shù)據(jù)庫打了補丁，至少不會導致zwell用戶被提升權(quán)限。

4.日常檢查不夠全面

只對擁有DBA權(quán)限的用戶進行檢查，導致被攻擊后很長時間才發(fā)現(xiàn)攻擊行為。

5.保留日志

對于WEB應(yīng)用，日志是很有必要進行保留的，如果日志沒有被改動，基本都可以從日志中重現(xiàn)整個安全事件的完整過程。

6.即使能夠查到來源IP，此IP往往也是肉機IP，比如，在此次事件中，兩次行為應(yīng)是同一人完成，但創(chuàng)建用戶的來源IP為廣東省佛山市電信，提權(quán)IP為北京市東四IDC機房。

啟明星辰公司數(shù)據(jù)庫審計專家點評

數(shù)據(jù)庫的風險主要來源于兩個方面，一個是外部攻擊，另一個是內(nèi)部人員(有權(quán)限人員)的違規(guī)操作(故意或者無意)，本文案例就是外部人員攻擊的一個典型過程。具體步驟是：通過應(yīng)用系統(tǒng)漏洞進行攻擊，建立賬戶，再利用本地漏洞提權(quán)，然后利用高權(quán)限用戶進行系列違法操作。

從上面的案例可以看到，要保證數(shù)據(jù)庫安全，除了數(shù)據(jù)庫系統(tǒng)自身安全之外，應(yīng)用系統(tǒng)的安全也需要一并考慮。不僅要對數(shù)據(jù)庫系統(tǒng)進行安全加固和嚴格的權(quán)限控制，對于應(yīng)用系統(tǒng)也要進行代碼漏洞檢查、入侵防護，建議在安全建設(shè)時，除了要進行數(shù)據(jù)庫的權(quán)限控制、數(shù)據(jù)加密、安全審計之外，對于應(yīng)用服務(wù)器的代碼檢查、入侵防御等措施也要考慮，可適當部署一些常用的安全產(chǎn)品，包括：數(shù)據(jù)庫加密、數(shù)據(jù)庫審計、WEB應(yīng)用防火墻、入侵檢測等。