安全滲透測試中日誌分析技術與授權機制

在眾多滲透測試中客戶想要了解攻擊溯源查詢問題,我們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,綠盟,啟明星辰,深信服等等都是比較不錯的滲透測試公司。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31542418/viewspace-2669805/，如需轉載，請註明出處，否則將追究法律責任。