侯方杰, 王 雷, 王 嵩, 盛 捷

(中國科學(xué)技術(shù)大學(xué) 信息技術(shù)學(xué)院 自動(dòng)化系, 合肥 230001)

1 概述

數(shù)據(jù)庫作為各類信息系統(tǒng)的核心部分, 其安全性在整個(gè)安全體系結(jié)構(gòu)中舉足輕重. 根據(jù)Verizon 2016數(shù)據(jù)泄露調(diào)查報(bào)告[1], 分析已確認(rèn)的 2260 起數(shù)據(jù)泄露事件中, 泄露源 7 成以上和數(shù)據(jù)庫相關(guān). 且由內(nèi)部違規(guī), 即公司內(nèi)部人員的操作失誤和權(quán)限誤用造成的數(shù)據(jù)泄露事件占總事件的20%. 在外部攻擊方面,2016年數(shù)據(jù)庫漏洞中, 80%以上都屬于SQL 層入侵范疇, 主要是利用數(shù)據(jù)庫系統(tǒng)SQL語言漏洞[2]. 諸多的安全隱患也催生了大批數(shù)據(jù)庫安全審計(jì)軟件, 在事中發(fā)現(xiàn)并阻斷違規(guī)和入侵語句, 在事后審計(jì)和分析, 對(duì)泄密行為追根溯源, 保證數(shù)據(jù)庫的安全. 而Oracle數(shù)據(jù)庫作為最流行的數(shù)據(jù)庫產(chǎn)品之一[3], 在各種數(shù)據(jù)庫安全軟件中均被廣泛支持.

將網(wǎng)絡(luò)數(shù)據(jù)報(bào)文轉(zhuǎn)化為數(shù)據(jù)庫會(huì)話是數(shù)據(jù)庫安全審計(jì)中必不可少的一部分. 由于Oracle公司并未公布數(shù)據(jù)庫通信細(xì)節(jié), 當(dāng)前的安全審計(jì)重點(diǎn)針對(duì)Oracle數(shù)據(jù)庫的通信協(xié)議TNS(Transparent Network SubStrate Protocol)進(jìn)行分析. 文獻(xiàn)[4,5]都基于TNS協(xié)議設(shè)計(jì)與實(shí)現(xiàn)了Oracle審計(jì)系統(tǒng), 并進(jìn)行了性能評(píng)價(jià). 文獻(xiàn)中給出了TNS數(shù)據(jù)包頭的格式、數(shù)據(jù)包分類及會(huì)話流程,但對(duì)于數(shù)據(jù)包的內(nèi)部格式細(xì)節(jié)卻沒有太多說明, 并且僅覆蓋一兩個(gè)協(xié)議版本. 文獻(xiàn)[6]則通過WireShark抓包工具研究數(shù)據(jù)包的結(jié)構(gòu)來對(duì)TNS協(xié)議進(jìn)行解析, 對(duì)客戶端與服務(wù)器建立連接的過程進(jìn)行了細(xì)致的分析,并給出了網(wǎng)絡(luò)選項(xiàng)協(xié)商、類型編組、認(rèn)證過程, 分析了TNS協(xié)議中的5種數(shù)據(jù)包結(jié)構(gòu). 但該文獻(xiàn)并未給出抓包測試的操作系統(tǒng)、服務(wù)器、客戶端以及TNS協(xié)議版本, 并且對(duì)于關(guān)鍵的Data類型數(shù)據(jù)包中的請求與響應(yīng)報(bào)文的結(jié)構(gòu)并沒有更深入的分析, 難以從中提取出SQL以及響應(yīng)的內(nèi)容.

當(dāng)前公開的TNS協(xié)議解析總的來說有3個(gè)問題.一是重點(diǎn)放在安全軟件的系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)上, 對(duì)于TNS協(xié)議的分析較為簡略;二是對(duì)TNS協(xié)議分析的層次不夠深入, 難以還原出用戶的操作和數(shù)據(jù)庫的響應(yīng);三是覆蓋的數(shù)據(jù)庫服務(wù)器、客戶端、操作系統(tǒng)和協(xié)議版本不夠全面, 只適用于特定的協(xié)議版本、服務(wù)器, 甚至是特定的連接.

本文針對(duì)市場上多種常用的TNS協(xié)議版本、數(shù)據(jù)庫服務(wù)器與客戶端, 分析其TNS數(shù)據(jù)包尤其是請求數(shù)據(jù)包的格式細(xì)節(jié). 使用Wireshark抓包工具, 獲取數(shù)據(jù)包樣本;通過人工分析, 初步獲取報(bào)文規(guī)則;通過數(shù)據(jù)挖掘的方法, 確定報(bào)文中的關(guān)鍵字節(jié), 及其與SQL的偏移量的關(guān)系, 生成匹配規(guī)則;設(shè)計(jì)實(shí)驗(yàn), 使用匹配規(guī)則提取數(shù)據(jù)包中的SQL語句做驗(yàn)證;分析匹配失敗的用例, 配合后期校正規(guī)則, 提高測試通過率.

2 TNS協(xié)議概述

TNS協(xié)議是Oracle數(shù)據(jù)庫遠(yuǎn)程通信協(xié)議. 根據(jù)數(shù)據(jù)庫服務(wù)器和客戶端的選擇, TNS可以使用Plain TCP、SSL TCP、命名管道、IPC傳輸. 其中命名管道是進(jìn)程間通信, IPC是本地通信, Plain TCP明文傳輸,SSL TCP是加密傳輸. 考慮到絕大多數(shù)遠(yuǎn)程客戶端連接用的是Plain TCP和SSL TCP, 本文僅分析Plain TCP下的TNS協(xié)議. 理論上獲得SSL秘鑰后對(duì)SSL TCP解密得到的報(bào)文, 也適用于本文的分析.

Oracle通信的流程在文獻(xiàn)[4–6]中都有詳細(xì)的說明, 并且和本文請求報(bào)文解析的關(guān)系不大, 在此略過.本節(jié)重點(diǎn)介紹對(duì)分析過程至關(guān)重要的TNS報(bào)文頭部結(jié)構(gòu).

TNS報(bào)文通用首部格式如圖1所示, 共8個(gè)字節(jié),包括數(shù)據(jù)包長度、數(shù)據(jù)包校驗(yàn)和、數(shù)據(jù)包類型、保留位、數(shù)據(jù)包頭部校驗(yàn)和. 需要注意的是, 最新的315版本TNS協(xié)議中, 數(shù)據(jù)包長度和校驗(yàn)和位置進(jìn)行了對(duì)調(diào).目前數(shù)據(jù)包校驗(yàn)和、保留位、數(shù)據(jù)包頭部校驗(yàn)和均以0填充. 數(shù)據(jù)包類型的取值與含義見表1. 其中, 類型為0x06的是Data類型數(shù)據(jù)包. 在連接建立完成之后, 客戶端的請求、服務(wù)器的響應(yīng)都是Data類型, 因此本文分析的對(duì)象主要也是該類型數(shù)據(jù)包.

圖1 TNS通用首部格式

表1 TNS通用頭部中類型的取值與含義

Data類型第一個(gè)問題是協(xié)議中數(shù)據(jù)包格式包括8個(gè)字節(jié)的TNS通用首部位置和格式不固定. 對(duì)于提取協(xié)議請求內(nèi)容來說, 后面依次重要的是DATA

FLAG、ID、SUB知道內(nèi)容在報(bào)文中的偏移量. ID和但這個(gè)偏移量會(huì)根據(jù)數(shù)據(jù)部分. 其中DATA FLAG一般填充0庫服務(wù)器、客戶端版本不同而變化, ID還會(huì)受到協(xié)議版本號(hào)、SUB ID和數(shù)據(jù)部分可能會(huì)重復(fù)出現(xiàn),類型、長度等影響. 如圖2因此需要根據(jù)報(bào)文中所示. ID和SUB ID可以唯一關(guān)鍵詞來確定后續(xù)數(shù)據(jù)部分的具體類型偏移量.

圖2 TNS協(xié)議Data類型數(shù)據(jù)包格式

3 TNS請求解析方案

本節(jié)將從樣本獲取、人工初步分析兩方面介紹TNS請求解析方案的設(shè)計(jì)依據(jù).

3.1 樣本獲取

根據(jù)對(duì)市場上常用的TNS協(xié)議版本、數(shù)據(jù)庫服務(wù)器、客戶端的調(diào)研, 以及在某電信集團(tuán)數(shù)據(jù)中心機(jī)房采集到的數(shù)據(jù)流量顯示, 常用的TNS協(xié)議版本包括308、310、312、313、314、315. 為了保證通用性, 本文解析支持TNS308到31的5全版本. 在數(shù)據(jù)庫服務(wù)器方面配置了Windows和Linux下的Oracle8i、9i、10g、11g、12c, 而客戶端采用了java連接(包括classes12、ojdbc14、ojdbc5、ojdbc6、ojdbc7的JAR包)、Navicat(主版本號(hào)包括 10、11、12)、PL/SQL Developer(主版本號(hào)包括6、7、8、9、10、11)、Oracle SQL Developer(主版本號(hào)包括2、3、4)和PowerDesigner, 使用到的動(dòng)態(tài)連接庫包括instant client 10.2、11.2和12.2的oci.dll.

3.2 人工初步分析

對(duì)于采集到的數(shù)據(jù)包, 根據(jù)請求者的IP和數(shù)據(jù)包中ASCII碼是否包含連續(xù)的英文字母, 將請求報(bào)文單獨(dú)提取了出來. 統(tǒng)計(jì)了請求報(bào)文數(shù)據(jù)類型的ID和subID, 并結(jié)合前面一章的分析得到了請求報(bào)文的一個(gè)簡單結(jié)構(gòu), 如圖3所示. 初步分析揭示了TNS協(xié)議解析的兩個(gè)主要問題.

圖3 請求報(bào)文格式

第一個(gè)問題是協(xié)議中數(shù)據(jù)的位置和格式不固定.對(duì)于提取協(xié)議請求內(nèi)容來說, 重要的是知道內(nèi)容在報(bào)文中的偏移量. 但這個(gè)偏移量會(huì)根據(jù)數(shù)據(jù)庫服務(wù)器、客戶端版本不同而變化, 還會(huì)受到協(xié)議版本號(hào)、數(shù)據(jù)類型、長度等影響. 因此需要根據(jù)報(bào)文中關(guān)鍵詞來確定偏移量.

第二個(gè)問題是協(xié)議解析涉及的范圍廣, 數(shù)據(jù)量大,人工分析的方式耗時(shí)耗力, 并且無法精確定位偏移量.需要一個(gè)系統(tǒng)的分析方法. 而諸多協(xié)議逆向的方法[7–9]在不依賴先驗(yàn)知識(shí)的情況下對(duì)協(xié)議格式進(jìn)行分析, 對(duì)包含負(fù)載的報(bào)文格式解析效果并不好.

本文通過數(shù)據(jù)挖掘的方法, 提取基于位置的關(guān)鍵詞, 建立關(guān)鍵詞與偏移量的關(guān)系. 依次對(duì)不同TNS協(xié)議的版本獲取偏移量規(guī)則, 以提高工作效率. 之所以用協(xié)議版本作為樣本劃分, 是因?yàn)橄鄬?duì)于操作系統(tǒng)、服務(wù)器、客戶端版本, 相同協(xié)議版本的報(bào)文顯示出更強(qiáng)的規(guī)律性.

4 關(guān)聯(lián)挖掘獲取偏移量

本節(jié)采用關(guān)聯(lián)挖掘的思想, 確定字段值與偏移量的關(guān)系. 關(guān)聯(lián)挖掘最早應(yīng)用于顧客交易數(shù)據(jù)庫中項(xiàng)集的關(guān)聯(lián)規(guī)則[10], 隨后關(guān)聯(lián)規(guī)則的挖掘被廣泛研究. 在關(guān)聯(lián)挖掘中, 首先獲得頻繁集, 再從頻繁集中通過預(yù)設(shè)的置信度獲取關(guān)聯(lián)規(guī)則. 在確定關(guān)鍵詞與偏移量關(guān)系時(shí),可以先找到特定偏移量的頻繁關(guān)鍵詞, 再從中獲取規(guī)則.

4.1 關(guān)聯(lián)挖掘的數(shù)據(jù)格式

假設(shè)第k個(gè)報(bào)文偏移量為s, 則它的SQL前面存在s個(gè)字節(jié). 將第i個(gè)字節(jié)的偏移量與值組為2元組, 記為

并且有

也就是說僅當(dāng)偏移量和值都相同時(shí), 才認(rèn)為兩個(gè)報(bào)文上的某個(gè)字節(jié)是相同的. 記F為字節(jié)與偏移量的映射關(guān)系, 則有

由于這個(gè)映射關(guān)系和某個(gè)具體的報(bào)文無關(guān), 因此可以略去k, 即

報(bào)文中對(duì)結(jié)構(gòu)有關(guān)鍵影響的字節(jié)只占少數(shù). 也就是說, 只需部分關(guān)鍵字節(jié)的值, 就可以確定報(bào)文偏移量.轉(zhuǎn)化為數(shù)學(xué)語言, 即

滿足

使得

式(8)是一個(gè)關(guān)聯(lián)規(guī)則的形式. 在關(guān)聯(lián)挖掘中, 以ai和s的取值范圍作為項(xiàng)集, 將數(shù)據(jù)格式定為

并從樣本中獲取數(shù)據(jù)集, 使用Apriori算法, 可以挖掘出形如式(8)的關(guān)聯(lián)規(guī)則. 由于式(8)是針對(duì)偏移量的關(guān)聯(lián)規(guī)則, 可以將樣本數(shù)據(jù)先按照偏移量的不同劃分為若干個(gè)組, 對(duì)每個(gè)組分別求頻繁集. 每個(gè)組內(nèi)偏移量是定值, 因此偏移量s一定在頻繁集中. 在求關(guān)聯(lián)規(guī)則時(shí), 再將各組頻繁集匯總. 依據(jù)偏移量的不同進(jìn)行劃分, 可以有效的降低計(jì)算量.

4.2 樣本數(shù)據(jù)提取

樣本數(shù)據(jù)提取指的是從初始網(wǎng)絡(luò)數(shù)據(jù)包中提取出a1,a2,···,ai,···,as和偏移s. 本文將SQL語句限制為select、insert、create、drop、delete等單詞開頭的常用語句. 然后采用字符串匹配的方式,即可確定SQL語句的起始位置, 以及從開頭到SQL的每一個(gè)字節(jié), 從而自動(dòng)而快速地生成樣本數(shù)據(jù)集.

4.3 算法描述

關(guān)聯(lián)挖掘采用的是Apriori算法[11], 具體描述如下:

上述算法將置信度設(shè)置得接近于1是因?yàn)? 對(duì)于一個(gè)特定的字段組合, 其對(duì)應(yīng)的偏移量也是通常固定的. 第5)步中, 僅搜索和偏移量相關(guān)的規(guī)則.

在挖掘的過程中發(fā)現(xiàn), 小樣本集Di中數(shù)據(jù)報(bào)文存在著不少字節(jié), 它們的偏移和值是完全固定的, 所以一定會(huì)出現(xiàn)在頻繁集中. 但是這部分字節(jié)并不會(huì)在計(jì)算時(shí)被忽略, 反而是出現(xiàn)在每一次頻繁集的迭代中. 為了減少計(jì)算量, 第2)步將這些偏移和值固定的字節(jié)在挖掘之前從樣本集中移除, 在第4)步挖掘結(jié)束后重新添入頻繁集.

5 實(shí)驗(yàn)分析

本節(jié)首先用前述的挖掘算法, 獲取挖掘結(jié)果, 并對(duì)其含義做解釋. 然后在實(shí)際系統(tǒng)工作環(huán)境下, 使用挖掘得到的規(guī)則對(duì)請求報(bào)文做解析. 同時(shí)對(duì)規(guī)則的準(zhǔn)確度做評(píng)價(jià).

實(shí)驗(yàn)環(huán)境采用3.1節(jié)描述的所有客戶端和服務(wù)器,分別在Windows和Linux環(huán)境下, 兩兩連接, 運(yùn)行SQL腳本采集數(shù)據(jù). 將采集數(shù)據(jù)按照TNS協(xié)議版本進(jìn)行劃分, 再分別使用關(guān)聯(lián)挖掘的方法獲取偏移量的規(guī)則.

5.1 最大最小規(guī)則

挖掘結(jié)果顯示, 對(duì)于同一個(gè)偏移量, 得到規(guī)則不止一個(gè). 記偏移量為s的集合為

定義最小規(guī)則rmin→s為:

定義最小規(guī)則rmax→s為

若rmin?rmax, 則rmin和rmax構(gòu)成一對(duì)最大最小規(guī)則. 很明顯, 除非R為空集,rmin和rmax總是存在. 并且,對(duì)于一個(gè)偏移量s, 可能存在不止一對(duì)最大最小規(guī)則.

在規(guī)則集中, 最大最小規(guī)則有很多用處. 最小規(guī)則因?yàn)榘淖止?jié)數(shù)量最小, 沒有冗余, 適合直接用于請求報(bào)文SQL的提取. 而最大規(guī)則由于包含了更多的信息量, 適合對(duì)報(bào)文結(jié)構(gòu)作進(jìn)一步的分析. 對(duì)TNS315協(xié)議, 035e報(bào)文頭部到SQL的一對(duì)最大最小規(guī)則如圖4(a)和4(b)所示. 圖中最大規(guī)則因?yàn)槠? 省去了字節(jié)值前面的0x.

圖4 偏移量為40的最小規(guī)則及最大規(guī)則

5.2 細(xì)化協(xié)議格式

通過對(duì)各種最大規(guī)則的分析對(duì)比, 得到了請求報(bào)文的一個(gè)更詳細(xì)的格式. 圖5中是TNS315版本請求報(bào)文的部分格式. 圖中的Magic1、Magic2、Magic3為定長字段. 圖中的變長字段, 如SQL_LEN、VarD1、VarD2等, 均滿足len+data的結(jié)構(gòu). Len為1個(gè)字節(jié),data長度為len個(gè)字節(jié). 圖中的VarS1為變長字段, 一般為2個(gè)、4個(gè)或8個(gè)字節(jié)的填充字段. 實(shí)驗(yàn)結(jié)果說明, 數(shù)據(jù)挖掘方法對(duì)獲取變長結(jié)構(gòu)的關(guān)聯(lián)字段和報(bào)文中的定值字段非常有效.

5.3 規(guī)則解析效果測試

本文使用最小規(guī)則來解析并提取報(bào)文中SQL語句. 圖6顯示了各個(gè)TNS協(xié)議版本挖掘出的最小規(guī)則的數(shù)量. TNS 310版本支持的服務(wù)器和客戶端版本最多, 其格式最復(fù)雜, 挖掘出的規(guī)則數(shù)量也最多. 而TNS 314版本的格式則相對(duì)比較簡單.

本文根據(jù)挖掘出的最小規(guī)則, 進(jìn)行Oracle報(bào)文解析的實(shí)際測試. 通過上海某電信集團(tuán)機(jī)房的專業(yè)數(shù)據(jù)庫操作人員為期2個(gè)月的采集和測試, 初期的測試通過率僅為71%, 如圖7所示. 發(fā)現(xiàn)問題包括:部分報(bào)文結(jié)構(gòu)的缺失、部分變長字段發(fā)現(xiàn)了新結(jié)構(gòu). 主要原因在于樣本集不夠全面, 無法覆蓋所有報(bào)文格式. 本文通過使用異常樣例擴(kuò)充樣本集, 重新挖掘來完善規(guī)則, 提高測試通過率.

圖5 更詳細(xì)的報(bào)文格式

圖6 不同TNS協(xié)議版本的規(guī)則數(shù)量

在這之后, 本文一邊實(shí)地運(yùn)行解析系統(tǒng), 一邊更新解析系統(tǒng)的規(guī)則集. 采集到的數(shù)據(jù)包如果解析異常, 就會(huì)被添加進(jìn)樣本集中, 重新進(jìn)行挖掘. 挖掘出的新規(guī)則會(huì)被添加進(jìn)正在運(yùn)行的解析系統(tǒng)規(guī)則集中. 到目前為止, 解析系統(tǒng)已運(yùn)作9個(gè)月. 除了開頭2個(gè)月有個(gè)別異常, 之后均能正常解析.

6 結(jié)論與展望

本文針對(duì)Oracle數(shù)據(jù)庫TNS協(xié)議的請求報(bào)文, 提出了一個(gè)解決方案, 適用于多種常用操作系統(tǒng)、服務(wù)器、客戶端和協(xié)議版本. 采用數(shù)據(jù)挖掘的方法來處理字節(jié)數(shù)多、意義不明的報(bào)文, 獲取對(duì)報(bào)文結(jié)構(gòu)有重要影響的字段. 由于初期樣本采集覆蓋范圍不夠廣, 挖掘的結(jié)果對(duì)于樣本中出現(xiàn)頻率少的報(bào)文類型并不友好.后期校正使用解析過程中的異常樣例擴(kuò)充樣本集, 反復(fù)挖掘, 提高對(duì)所有類型報(bào)文的適用性. 實(shí)地采集數(shù)據(jù)進(jìn)行解析, 可以有效提取出請求報(bào)文中的SQL語句,數(shù)據(jù)挖掘的方法可以有效地從大量數(shù)據(jù)中提取出規(guī)則,省時(shí)省力. 下一步計(jì)劃采用現(xiàn)有方法繼續(xù)研究響應(yīng)報(bào)文中的內(nèi)容.

圖7 不同TNS協(xié)議版本的測試通過率