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