域名預(yù)訂/競(jìng)價(jià),好“米”不錯(cuò)過(guò)
在眾多滲透測(cè)試中客戶(hù)想要了解攻擊溯源查找問(wèn)題,我們Sine安全在日常網(wǎng)站安全檢測(cè)過(guò)程中了解知道黑客是如何攻擊和上傳木馬并進(jìn)行篡改,以及如何查找日志分析攻擊者是通過(guò)哪些腳本入口文件進(jìn)行入侵的,那么本節(jié)由我們資深的滲透測(cè)試主管技術(shù)來(lái)為大家講解。
6.9.1.1. 基于日志的溯源
使用路由器、主機(jī)等設(shè)備記錄網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)流中的關(guān)鍵信息(時(shí)間、源地址、目的地址),追蹤時(shí)基于日志查詢(xún)做反向追蹤。 這種方式的優(yōu)點(diǎn)在于兼容性強(qiáng)、支持事后追溯、網(wǎng)絡(luò)開(kāi)銷(xiāo)較小。但是同時(shí)該方法也受性能、空間和隱私保護(hù)等的限制,考慮到以上的因素,可以限制記錄的數(shù)據(jù)特征和數(shù)據(jù)數(shù)量。另外可以使用流量鏡像等技術(shù)來(lái)減小對(duì)網(wǎng)絡(luò)性能的影響。
6.9.1.2. 路由輸入調(diào)試技術(shù)
在攻擊持續(xù)發(fā)送數(shù)據(jù),且特性較為穩(wěn)定的場(chǎng)景下,可以使用路由器的輸入調(diào)試技術(shù),在匹配到攻擊流量時(shí)動(dòng)態(tài)的向上追蹤。這種方式在DDoS攻擊追溯中比較有效,且網(wǎng)絡(luò)開(kāi)銷(xiāo)較小。
6.9.1.3. 可控洪泛技術(shù)
追蹤時(shí)向潛在的上游路由器進(jìn)行洪泛攻擊,如果發(fā)現(xiàn)收到的攻擊流量變少則攻擊流量會(huì)流經(jīng)相應(yīng)的路由。這種方式的優(yōu)點(diǎn)在于不需要預(yù)先部署,對(duì)協(xié)同的需求比較少。但是這種方式本身是一種攻擊,會(huì)對(duì)網(wǎng)絡(luò)有所影響。
6.9.1.4. 基于包數(shù)據(jù)修改追溯技術(shù)
這種溯源方式直接對(duì)數(shù)據(jù)包進(jìn)行修改,加入編碼或者標(biāo)記信息,在接收端對(duì)傳輸路徑進(jìn)行重構(gòu)。這種方式人力投入較少,支持事后分析,但是對(duì)某些協(xié)議的支持性不太好。 基于這種方式衍生出了隨機(jī)標(biāo)記技術(shù),各路由以一定概率對(duì)數(shù)據(jù)包進(jìn)行標(biāo)識(shí),接收端收集到多個(gè)包后進(jìn)行重構(gòu)。
6.9.2. 分析模型
6.9.2.1. 殺傷鏈(Kill Kain)模型
殺傷鏈這個(gè)概念源自軍事領(lǐng)域,它是一個(gè)描述攻擊環(huán)節(jié)的模型。一般殺傷鏈有認(rèn)為偵查跟蹤(Reconnaissance)、武器構(gòu)建(Weaponization)、載荷投遞(Delivery)、漏洞利用(Exploitation)、安裝植入(Installation)、通信控制(Command&Control)、達(dá)成目標(biāo)(Actions on Objective)等幾個(gè)階段。
在越早的殺傷鏈環(huán)節(jié)阻止攻擊,防護(hù)效果就越好,因此殺傷鏈的概念也可以用來(lái)反制攻擊。
在跟蹤階段,攻擊者通常會(huì)采用掃描和搜索等方式來(lái)尋找可能的目標(biāo)信息并評(píng)估攻擊成本。在這個(gè)階段可以通過(guò)日志分析、郵件分析等方式來(lái)發(fā)現(xiàn),這階段也可以采用威脅情報(bào)等方式來(lái)獲取攻擊信息。
武器構(gòu)建階段攻擊者通常已經(jīng)準(zhǔn)備好了攻擊工具,并進(jìn)行嘗試性的攻擊,在這個(gè)階段IDS中可能有攻擊記錄,外網(wǎng)應(yīng)用、郵箱等帳號(hào)可能有密碼爆破的記錄。有一些攻擊者會(huì)使用公開(kāi)攻擊工具,會(huì)帶有一定的已知特征。
載荷投遞階段攻擊者通常會(huì)采用網(wǎng)絡(luò)漏洞、魚(yú)叉、水坑、網(wǎng)絡(luò)劫持、U盤(pán)等方式投送惡意代碼。此階段已經(jīng)有人員在對(duì)應(yīng)的途徑收到了攻擊載荷,對(duì)人員進(jìn)行充分的安全培訓(xùn)可以做到一定程度的防御。
突防利用階段攻擊者會(huì)執(zhí)行惡意代碼來(lái)獲取系統(tǒng)控制權(quán)限,此時(shí)木馬程序已經(jīng)執(zhí)行,此階段可以依靠殺毒軟件、異常行為告警等方式來(lái)找到相應(yīng)的攻擊。
安裝植入階段攻擊者通常會(huì)在web服務(wù)器上安裝Webshell或植入后門(mén)、rootkit等來(lái)實(shí)現(xiàn)對(duì)服務(wù)器的持久化控制??梢酝ㄟ^(guò)對(duì)樣本進(jìn)行逆向工程來(lái)找到這些植入。
通信控制階段攻擊者已經(jīng)實(shí)現(xiàn)了遠(yuǎn)程通信控制,木馬會(huì)通過(guò)Web三方網(wǎng)站、DNS隧道、郵件等方式和控制服務(wù)器進(jìn)行通信。此時(shí)可以通過(guò)對(duì)日志進(jìn)行分析來(lái)找到木馬的痕跡。
達(dá)成目標(biāo)階段時(shí),攻擊者開(kāi)始完成自己的目的,可能是破壞系統(tǒng)正常運(yùn)行、竊取目標(biāo)數(shù)據(jù)、敲詐勒索、橫向移動(dòng)等。此時(shí)受控機(jī)器中可能已經(jīng)有攻擊者的上傳的攻擊利用工具,此階段可以使用蜜罐等方式來(lái)發(fā)現(xiàn)。
6.9.2.2. 鉆石(Diamond)模型
鉆石模型由網(wǎng)絡(luò)情報(bào)分析與威脅研究中心(The Center for Cyber Intelligence Anaysis and Threat Research,CCIATR)機(jī)構(gòu)的Sergio Catagirone等人在2013年提出。
該模型把所有的安全事件(Event)分為四個(gè)核心元素,即敵手(Adversary),能力(Capability),基礎(chǔ)設(shè)施(Infrastructure)和受害者(Victim),以菱形連線(xiàn)代表它們之間的關(guān)系,因而命名為“鉆石模型”。
殺傷鏈模型的特點(diǎn)是可說(shuō)明攻擊線(xiàn)路和攻擊的進(jìn)程,而鉆石模型的特點(diǎn)是可說(shuō)明攻擊者在單個(gè)事件中的攻擊目的和所使用攻擊手法。
在使用鉆石模型分析時(shí),通常使用支點(diǎn)分析的方式。支點(diǎn)(Pivoting)指提取一個(gè)元素,并利用該元素與數(shù)據(jù)源相結(jié)合以發(fā)現(xiàn)相關(guān)元素的分析技術(shù)。分析中可以隨時(shí)變換支點(diǎn),四個(gè)核心特征以及兩個(gè)擴(kuò)展特征(社會(huì)政治、技術(shù))都可能成為當(dāng)時(shí)的分析支點(diǎn)。
6.9.3. 關(guān)聯(lián)分析方法
關(guān)聯(lián)分析用于把多個(gè)不同的攻擊樣本結(jié)合起來(lái)。
6.9.3.1. 文檔類(lèi)
hash
ssdeep
版本信息(公司/作者/最后修改作者/創(chuàng)建時(shí)間/最后修改時(shí)間)
6.9.3.2. 行為分析
基于網(wǎng)絡(luò)行為
類(lèi)似的交互方式
6.9.3.3. 可執(zhí)行文件相似性分析
特殊端口
特殊字符串/密鑰
PDB文件路徑
相似的文件夾
代碼復(fù)用
相似的代碼片段
6.9.4. 清除日志方式
kill不會(huì)存儲(chǔ)
set +o history 不寫(xiě)入歷史記錄
unset HISTFILE 清除歷史記錄的環(huán)境變量
OAuth
7.1.1. 簡(jiǎn)介
OAuth是一個(gè)關(guān)于授權(quán)(authorization)的開(kāi)放網(wǎng)絡(luò)標(biāo)準(zhǔn),在全世界得到廣泛應(yīng)用,目前的版本是2.0版。
OAuth在客戶(hù)端與服務(wù)端之間,設(shè)置了一個(gè)授權(quán)層(authorization layer)??蛻?hù)端不能直接登錄服務(wù)端,只能登錄授權(quán)層,以此將用戶(hù)與客戶(hù)端區(qū)分開(kāi)來(lái)??蛻?hù)端登錄授權(quán)層所用的令牌(token),與用戶(hù)的密碼不同。用戶(hù)可以在登錄的時(shí)候,指定授權(quán)層令牌的權(quán)限范圍和有效期。
客戶(hù)端登錄授權(quán)層以后,服務(wù)端根據(jù)令牌的權(quán)限范圍和有效期,向客戶(hù)端開(kāi)放用戶(hù)儲(chǔ)存的資料。
OAuth 2.0定義了四種授權(quán)方式:授權(quán)碼模式(authorization code)、簡(jiǎn)化模式(implicit)、密碼模式(resource owner password credentials)和客戶(hù)端模式(client credentials)。
7.1.2. 流程
用戶(hù)打開(kāi)客戶(hù)端以后,客戶(hù)端要求用戶(hù)給予授權(quán)
用戶(hù)同意給予客戶(hù)端授權(quán)
客戶(hù)端使用上一步獲得的授權(quán),向認(rèn)證服務(wù)器申請(qǐng)令牌
認(rèn)證服務(wù)器對(duì)客戶(hù)端進(jìn)行認(rèn)證以后,確認(rèn)無(wú)誤,同意發(fā)放令牌
客戶(hù)端使用令牌,向資源服務(wù)器申請(qǐng)獲取資源
資源服務(wù)器確認(rèn)令牌無(wú)誤,同意向客戶(hù)端開(kāi)放資源
7.1.3. 授權(quán)碼模式
授權(quán)碼模式(authorization code)是功能最完整、流程最嚴(yán)密的授權(quán)模式。它的特點(diǎn)就是通過(guò)客戶(hù)端的后臺(tái)服務(wù)器,與服務(wù)端的認(rèn)證服務(wù)器進(jìn)行互動(dòng)。
其流程為:
用戶(hù)訪(fǎng)問(wèn)客戶(hù)端,后者將前者導(dǎo)向認(rèn)證服務(wù)器
用戶(hù)選擇是否給予客戶(hù)端授權(quán)
假設(shè)用戶(hù)給予授權(quán),認(rèn)證服務(wù)器將用戶(hù)導(dǎo)向客戶(hù)端事先指定的"重定向URI"(redirection URI) ,同時(shí)附上一個(gè)授權(quán)碼
客戶(hù)端收到授權(quán)碼,附上早先的"重定向URI",向認(rèn)證服務(wù)器申請(qǐng)令牌
認(rèn)證服務(wù)器核對(duì)了授權(quán)碼和重定向URI,確認(rèn)無(wú)誤后,向客戶(hù)端發(fā)送訪(fǎng)問(wèn)令牌(access token)和更新令牌(refresh token)
A步驟中,客戶(hù)端申請(qǐng)認(rèn)證的URI,包含以下參數(shù):
response_type:表示授權(quán)類(lèi)型,必選項(xiàng),此處的值固定為 code
client_id:表示客戶(hù)端的ID,必選項(xiàng)
redirect_uri:表示重定向URI,可選項(xiàng)
scope:表示申請(qǐng)的權(quán)限范圍,可選項(xiàng)
state:表示客戶(hù)端的當(dāng)前狀態(tài),需動(dòng)態(tài)指定,防止CSRF
C步驟中,服務(wù)器回應(yīng)客戶(hù)端的URI,包含以下參數(shù):
code:表示授權(quán)碼,必選項(xiàng)。該碼的有效期應(yīng)該很短且客戶(hù)端只能使用該碼一次,否則會(huì)被授權(quán)服務(wù)器拒絕。該碼與客戶(hù)端ID和重定向URI,是一一對(duì)應(yīng)關(guān)系。
state:如果客戶(hù)端的請(qǐng)求中包含這個(gè)參數(shù),認(rèn)證服務(wù)器回應(yīng)與請(qǐng)求時(shí)相同的參數(shù)
D步驟中,客戶(hù)端向認(rèn)證服務(wù)器申請(qǐng)令牌的HTTP請(qǐng)求,包含以下參數(shù):
grant_type:表示使用的授權(quán)模式,必選項(xiàng),此處的值固定為 authorization_code
code:表示上一步獲得的授權(quán)碼,必選項(xiàng)
redirect_uri:表示重定向URI,必選項(xiàng),且必須與A步驟中的該參數(shù)值保持一致
client_id:表示客戶(hù)端ID
E步驟中,認(rèn)證服務(wù)器發(fā)送的HTTP回復(fù),包含以下參數(shù):
access_token:表示訪(fǎng)問(wèn)令牌,必選項(xiàng)
token_type:表示令牌類(lèi)型,該值大小寫(xiě)不敏感,必選項(xiàng),可以是 bearer 類(lèi)型或 mac 類(lèi)型
expires_in:表示過(guò)期時(shí)間,單位為秒。如果省略該參數(shù),必須其他方式設(shè)置過(guò)期時(shí)間
refresh_token:表示更新令牌,用來(lái)獲取下一次的訪(fǎng)問(wèn)令牌,可選項(xiàng)
scope:表示權(quán)限范圍,如果與客戶(hù)端申請(qǐng)的范圍一致,此項(xiàng)可省略
7.1.4. 簡(jiǎn)化模式
簡(jiǎn)化模式(implicit grant type)不通過(guò)第三方應(yīng)用程序的服務(wù)器,直接在瀏覽器中向認(rèn)證服務(wù)器申請(qǐng)令牌,跳過(guò)了授權(quán)碼這個(gè)步驟,因此得名。所有步驟在瀏覽器中完成,令牌對(duì)訪(fǎng)問(wèn)者是可見(jiàn)的,且客戶(hù)端不需要認(rèn)證。
其步驟為:
客戶(hù)端將用戶(hù)導(dǎo)向認(rèn)證服務(wù)器
用戶(hù)決定是否給于客戶(hù)端授權(quán)
假設(shè)用戶(hù)給予授權(quán),認(rèn)證服務(wù)器將用戶(hù)導(dǎo)向客戶(hù)端指定的重定向URI,并在URI的Hash部分包含了訪(fǎng)問(wèn)令牌
瀏覽器向資源服務(wù)器發(fā)出請(qǐng)求,其中不包括上一步收到的Hash值
資源服務(wù)器返回一個(gè)網(wǎng)頁(yè),其中包含的代碼可以獲取Hash值中的令牌
瀏覽器執(zhí)行上一步獲得的腳本,提取出令牌
瀏覽器將令牌發(fā)給客戶(hù)端
A步驟中,客戶(hù)端發(fā)出的HTTP請(qǐng)求,包含以下參數(shù):
response_type:表示授權(quán)類(lèi)型,此處的值固定為 token ,必選項(xiàng)
client_id:表示客戶(hù)端的ID,必選項(xiàng)
redirect_uri:表示重定向的URI,可選項(xiàng)
scope:表示權(quán)限范圍,可選項(xiàng)
state:表示客戶(hù)端的當(dāng)前狀態(tài),需動(dòng)態(tài)指定,防止CSRF
C步驟中,認(rèn)證服務(wù)器回應(yīng)客戶(hù)端的URI,包含以下參數(shù):
access_token:表示訪(fǎng)問(wèn)令牌,必選項(xiàng)
token_type:表示令牌類(lèi)型,該值大小寫(xiě)不敏感,必選項(xiàng)
expires_in:表示過(guò)期時(shí)間,單位為秒。如果省略該參數(shù),必須其他方式設(shè)置過(guò)期時(shí)間
scope:表示權(quán)限范圍,如果與客戶(hù)端申請(qǐng)的范圍一致,此項(xiàng)可省略
state:如果客戶(hù)端的請(qǐng)求中包含這個(gè)參數(shù),認(rèn)證服務(wù)器回應(yīng)與請(qǐng)求時(shí)相同的參數(shù)
在上面的例子中,認(rèn)證服務(wù)器用HTTP頭信息的Location欄,指定瀏覽器重定向的網(wǎng)址。注意,在這個(gè)網(wǎng)址的Hash部分包含了令牌。
根據(jù)上面的D步驟,下一步瀏覽器會(huì)訪(fǎng)問(wèn)Location指定的網(wǎng)址,但是Hash部分不會(huì)發(fā)送。接下來(lái)的E步驟,服務(wù)提供商的資源服務(wù)器發(fā)送過(guò)來(lái)的代碼,會(huì)提取出Hash中的令牌。
7.1.5. 密碼模式
密碼模式(Resource Owner Password Credentials Grant)中,用戶(hù)向客戶(hù)端提供自己的用戶(hù)名和密碼??蛻?hù)端使用這些信息,向"服務(wù)商提供商"索要授權(quán)。
在這種模式中,用戶(hù)必須把自己的密碼給客戶(hù)端,但是客戶(hù)端不得儲(chǔ)存密碼。
其步驟如下:
用戶(hù)向客戶(hù)端提供用戶(hù)名和密碼
客戶(hù)端將用戶(hù)名和密碼發(fā)給認(rèn)證服務(wù)器,向后者請(qǐng)求令牌
認(rèn)證服務(wù)器確認(rèn)無(wú)誤后,向客戶(hù)端提供訪(fǎng)問(wèn)令牌
B步驟中,客戶(hù)端發(fā)出的HTTP請(qǐng)求,包含以下參數(shù):
grant_type:表示授權(quán)類(lèi)型,此處的值固定為 password ,必選項(xiàng)
username:表示用戶(hù)名,必選項(xiàng)
password:表示用戶(hù)的密碼,必選項(xiàng)
scope:表示權(quán)限范圍
7.1.6. 客戶(hù)端模式
客戶(hù)端模式(Client Credentials Grant)指客戶(hù)端以自己的名義,而不是以用戶(hù)的名義,向服務(wù)端進(jìn)行認(rèn)證。
其步驟如下:
客戶(hù)端向認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證,并要求一個(gè)訪(fǎng)問(wèn)令牌
認(rèn)證服務(wù)器確認(rèn)無(wú)誤后,向客戶(hù)端提供訪(fǎng)問(wèn)令牌
A步驟中,客戶(hù)端發(fā)出的HTTP請(qǐng)求,包含以下參數(shù):
granttype:表示授權(quán)類(lèi)型,此處的值固定為 clientcredentials ,必選項(xiàng)
scope:表示權(quán)限范圍,可選項(xiàng)
B步驟中,認(rèn)證服務(wù)器向客戶(hù)端發(fā)送訪(fǎng)問(wèn)令牌,滲透測(cè)試中包含的授權(quán)模式都要詳細(xì)的審計(jì)和檢測(cè),如果對(duì)此有更多的想要了解,可以聯(lián)系專(zhuān)業(yè)的網(wǎng)站安全公司來(lái)處理,國(guó)內(nèi)做的比較大的推薦Sinesafe,綠盟,啟明星辰,深信服等等都是比較不錯(cuò)的滲透測(cè)試公司。
申請(qǐng)創(chuàng)業(yè)報(bào)道,分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處,共同探討創(chuàng)業(yè)新機(jī)遇!