一、背景

最近接到一客戶電話，客戶反饋：“單位A服務器數據庫信息被修改，原本字段的內容被修改爲其它”。同時我收到一張字段被修改的照片，原本該數據爲數字，現在被替換爲了nv0K7x4u。

得到上述信息後開始瞭解該系統情況（故作淡定）：

1、服務器是否對互聯網提供應用？
2、是否庫站分離；
3、是否映射3389端口到互聯網；
……

通過對上述信息進行溝通後得到以下信息：

1、A服務器有對互聯網提供X應用；
2、庫站未分離；
3、3389端口可以訪問，但未映射到互聯網上。

二、應急響應思路

通過對網絡環境進行了解，結合有可能發生字段被篡改的情況和常見應急響應思路，我確認了3種情況，分別如下：

1、確認是否是由於運維人員誤操作導致；
2、確認是否是通過遠程登錄系統，在系統中做非法操作導致；
3、確認是否是由於官網存在漏洞，在漏洞利用過程中導致。

確認響應思路後，便開始進行分析。

三、應急思路排查

3.1確認是否爲誤操作

針對是否爲誤操作問題，主要是通過和運維人員進行溝通，瞭解是否有做其他操作，導致數據被篡改，通過溝通，未發現存在誤操作現象。

在對系統應用日誌進行分析發現在客戶反饋出現異常的時間段存在數據備份操作，有點懷疑是否是數據備份的過程中會導致數據紊亂，從而造成數據被篡改現象，這裏保持疑問，進行其他項分析。

3.2確認是否存在遠程登錄

對系統安全日誌和遠程登錄日誌進行分析，未發現存在遠程登錄情況（日誌的默認大小爲68kb，因此無數據）。

3.3確認是否存在web應用漏洞

首先查看web應用日誌，在web訪問日誌中發現大量SQL注入攻擊日誌。

另外存在5個小時日誌空缺，只記錄了當天上午9：47：41之前的數據，後面的數據則未空：

看到大量sql注入日誌，因此暫時懷疑X系統存SQL注入漏洞，黑客在執行SQL注入時導致的數據篡改或者黑客獲取數據庫權限後進行的惡意數據篡改。到這裏也僅僅是懷疑。

3.4定位分析

這裏可以暫時定位爲數據篡改是由於X系統存在SQL注入漏洞導致，下一步分析即針對該系統進行漏洞驗證，檢測是否存在SQL注入漏洞，從而驗證我們的猜想。通過對X系統進行漏洞檢測時發現該系統登錄框處存在SQL注入漏洞。

通過對X系統進行漏洞驗證，發現該系統真實存在SQL注入漏洞；由於數據庫信息已通過被恢復，查找不到相關數據庫操作記錄，結合web訪問日誌中存在200狀態碼返回值和缺少5小時web日誌進行綜合分析，推斷本次事件分析結果爲：黑客在執行SQL注入時注入語句導致數據篡改或者黑客獲取數據庫權限後進行的惡意數據篡改。

到此完成應急工作。

四、總結

遇到安全事件時，可根據安全事件的表現現象進行根因分析，提出最有可能導致該現象的幾種假設，並針對假設進行逐一分析、排查，最終確認最有可能的原因。

*本文作者：bbbbbbig，轉載請註明來自FreeBuf.COM