滲透測試 網站日誌溯源技術與密碼受權機制

在衆多滲透測試中客戶想要了解攻擊溯源查找問題,咱們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 <bash process ID> 不會存儲
• 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,綠盟,啓明星辰,深信服等等都是比較不錯的滲透測試公司。