第四章 漏洞發現

作者：Gilberto Najera-Gutierrez

譯者：飛龍

協議：CC BY-NC-SA 4.0

簡介

我們現在已經完成了滲透測試的偵查階段，并且識別了應用所使用的服務器和開發框架的類型，以及一些可能的弱點。現在是實際測試應用以及檢測它的漏洞的時候了。

這一章中，我們會涉及到檢測一些 Web 應用中常見漏洞的過程，以及允許我們發現和利用它們的工具。

我們也會用到 vulnerable_vm 中的應用，我們會使用 OWASP Mantra 作為瀏覽來執行這些測試。

4.1 使用 Hackbar 插件來簡化參數分析

在測試 Web 應用時，我們需要和瀏覽器的地址欄交互，添加或修改參數，以及修改 URL。一些服務器的相應會包含重定向，刷新以及參數修改。所有這些改動都會使對相同變量嘗試不同值的操作非常費時間。我們需要一些工具來使它們不那么混亂。

Hackbar 是 Firefox 插件，它的行為就像地址欄，但是不受由服務器響應造成的重定向或其它修改影響，這就是我們需要測試 Web 應用的原因。

這個秘籍中，我們會使用 Hackbar 來簡化相同請求的不同版本的發送工作。

準備

如果你沒有使用 OWASP Mantra，你需要在你的 Firefox 上安裝 Hackbar。

操作步驟

1. 訪問 DVWA 并且登錄。默認的用戶名/密碼組合是admin/admin。

2. 在左側的菜單上選擇SQL Injection（SQL 注入）。

3. 在User ID輸入框中輸入數字，并點擊Submit（提交）。

   現在我們可以按下F9或者點擊圖標來顯示 Hackbar。

   Hackbar 會賦值 URL 及其參數。我們也可以開啟修改 POST 請求和 Referer 參數的選項。后者告訴服務器頁面從哪里被請求。

4. 讓我們做個簡單的改動，將id參數值從1改成2，并點擊Execute（執行）或者使用Alt + X快捷鍵。

   我們可以看到，參數id對應頁面上的文本框，所以，我們可以使用 Hackbar 修改id來嘗試任何值，而不需要修改文本框中的User ID并提交它。在測試擁有許多輸入的表單，或者取決于輸入重定向到其它頁面的表單時，這非常便利。

5. 我們可以將一個有效值替換為另一個，但是如果我們輸入了一個無效值作為id，會發生什么呢？嘗試將單引號作為id：

   通過輸入應用非預期的字符，我們觸發了一個錯誤，這在之后測試一些漏洞的時候非常有用。

工作原理

Hackbar 是帶有一些實用特性的第二個地址欄，比如不受 URL 重定向影響，并且允許我們修改 POST 參數。

此外，Hackbar 可用于向我們的請求中添加 SQL 注入或跨站腳本代碼段，以及哈希、加密和編碼我們的輸入。我們會在這一章后面的秘籍中深入探索 SQL 注入、跨站腳本，以及其他漏洞。

4.2 使用 Tamper Data 插件攔截或修改請求

有時候，應用擁有客戶端的輸入校驗機制，它們通過 JavaScript，隱藏表單或者 POST 數據，并不能直接在地址欄中了解或看到。為了測試這些以及其它類型的變量，我們需要攔截瀏覽器發送的請求并且在它們到達服務器之前修改它們。這個秘籍中，我們會使用叫做 Tamper Data 的 Firefox 插件來攔截表單提交并且在它離開計算機之前修改一些值。

操作步驟

1. 從 Mantra 的菜單中訪問 Tools | Application Auditing | Tamper Data。

2. 會出現 Tamper Data 的窗口。現在，讓我們瀏覽 < http://192.168.56.102/dvwa/login.php>。我們可以在插件中看到請求會話。

   每個瀏覽器產生的請求都會在活動時經過 Tamper Data。

3. 為了攔截請求并修改它的值，我們需要通過點擊Start Tamper來啟動 Tamper。現在啟動 Tamper。

4. 輸入一些偽造的用戶名密碼組合。例如，test/password，之后點擊Login。

5. 在確認框中，取消勾選Continue Tampering?并點擊Tamper。Tamper Popup窗口會出現。

6. 在彈出窗口中，我們可以修改發送給服務器的信息，包括請求頭和 POST 參數。將username和password改為正確的（admin/admin），之后點擊OK。這應該在本書中使用，而不是 DVWA：

   在最后一步中，我們在表單中的值由瀏覽器發送給服務器之前修改了它們。因此，我們可以以正確的憑證而不是錯誤的憑證登錄服務器。

工作原理

Tamper Data 會在請求離開瀏覽器之前捕獲請求，并提供給我們時間來修改它包含的任何變量。但是，它也有一些限制，例如不能編輯 URL 或 GET 參數。

4.3 使用 ZAP 來查看和修改請求

雖然 Tamper Data 有助于測試過程，有時我們需要更靈活的方法來修改請求以及更多特性，例如修改用于發送它們的方法（即從 GET 改為 POST），或者使用其它工具為進一步的目的保存請求/響應對。

OWASP ZAP 不僅僅是 Web 代碼，它不僅僅能夠攔截流量，也擁有許多在上一章所使用的，類似于爬蟲的特性，還有漏洞掃描器，模糊測試器，爆破器，以及其它。它也擁有腳本引擎，可以用于自動化操作或者創建新的功能。

這個秘籍中，我們會開始將 OWASP ZAP 用作代理，攔截請求，并在修改一些值之后將它發送給服務器。

準備

啟動 ZAP 并配置瀏覽器在通過它發送信息。

操作步驟

1. 訪問 http://192.168.56.102/mutillidae/。

2. 現在，訪問菜單欄中的OWASP Top 10 | A1 – SQL Injection | SQLi – Extract Data | User Info。

3. 下一步是提升應用的安全等級。點擊Toggle Security。現在Security Level應該是1 (Arrogant)。

4. 將test'（包含單引號）作為Name，以及password'作為Password，并且點擊View Account Details。

   我們得到了警告消息，告訴我們輸入中的一些字符不合法。這里，單引號被檢測到了，并被應用的安全手段中止。

5. 點擊OK來關閉警告。

   如果我們在 ZAP 中檢查歷史，我們可以看到沒有發給服務器的請求，這是由于客戶端校驗機制。我們會使用請求攔截來繞過這個保護。

6. 現在我們開啟請求攔截（在 ZAP 叫做斷點），通過點擊"break on all requests（中斷所有請求）按鈕。

7. 下面，我們輸入了有效值Name和Password，就像test和password，并再次檢查細節。

   ZAP 會轉移焦點，并打開叫做Break的新標簽頁。這里是剛剛在頁面上產生的請求，我們可以看到一個 GET 請求，帶有在 URL 中發送的username和password參數。我們可以添加上一次嘗試中不允許的單引號。

8. 為了繼續而不會被 ZAP 打斷，我們通過點擊Unset Break按鈕來禁用斷點。

9. 通過播放按鈕來提交修改后的請求。

   我們可以看到，應用在頂部提供給我們錯誤信息，所以這是它的保護機制，它在客戶端檢查用戶輸入，但是在服務端并沒有準備好處理非預期的請求。

工作原理

這個秘籍中，我們使用 ZAP 代理來攔截有效的請求，將它修改為無效或而已請求，之后把它發給服務器并且觸發非預期的行為。

前三步用于開啟安全保護，便于應用可以將單引號檢測為無效字符。

之后，我們產生測試請求，并證實了會執行一些校驗。提示警告的時候，沒有請求通過代理，這告訴了我們檢驗是在客戶端進行的，可能使用 JavaScript。知道了這個之后，我們產生了合法的請求，并使用代理來攔截它，這讓我們能夠繞過客戶端的保護。我們將該請求轉換為惡意請求，并把它發給服務器，這使它不能被正確處理，并返回錯誤。

4.4 使用 Burp Suite 查看和修改請求

Burp Suite 和 OWASP ZAP 一樣，也不僅僅是個簡單的 Web 代理。它是功能完整的 Web 應用測試包。它擁有代理、請求重放器、請求自動化工具、字符串編碼器和解碼器，漏洞掃描器（Pro 版本中），以及其它實用的功能。

這個秘籍中，我們會執行上一個練習，但是這次使用 Burp Suite 的代理功能來攔截和修改請求。

準備

啟動 Burp Suite 并讓瀏覽器使用它的代理。

操作步驟

1. 瀏覽 http://192.168.56.102/mutillidae/。

2. 默認情況下，Burp 代理中的攔截器是開著的，所以他會捕獲第一個請求。我們需要打開 Burp Suite 并點擊Proxy標簽頁中的Intercept is on按鈕。

3. 瀏覽器會繼續加載頁面。當它完成時，我們通過Toggle Security將當前的應用安全級別設置為1 (Arrogant)。

4. 從菜單欄中訪問OWASP Top 10 | A1 – SQL Injection | SQLi – Extract Data | User Info。

5. 在Name輸入框中，對Username輸入user<>（包括符號）。在Password輸入框中，對Password輸入secret<>。之后點擊View Account Details。

   我們會得到警告，告訴我們我們可能向應用輸入了一些危險字
   符。

6. 現在我們直到這些符號在表單中并不允許，我們也知道了它是客戶端的校驗，因為代理的HTTP history標簽頁中沒有任何請求出現。讓我們嘗試繞過這個保護。通過點擊 Burp Suite 中的Intercept is off來開啟消息攔截。

7. 下一步是發送有效數據，例如user和secret。

8. 代理會攔截該請求。現在我們修改username和password的值，通過添加禁止的字符<>。

9. 我們可以發送編輯后的信息，并通過點擊Intercept is on來禁用攔截，或者我們可能發酸發送他并保持消息攔截，通過點擊Forward。對于這個練習，我們禁用攔截并檢查結果。

工作原理

就像在上個秘籍中看到的那樣，在請求經過由應用建立在客戶端的驗證機制之前，我們使用代理來捕獲請求，并通過添加一些在檢驗中不允許的字符，修改了它的內容。

能夠攔截和修改請求，對任何 Web 應用滲透測試來說都非常重要，不僅僅用于繞過一些客戶端檢驗，就像我們在當前和上一個秘籍中所做的那樣，也能夠用于了解發送了哪個信息，以及嘗試理解應用的內部原理。我們可能也需要基于我們的理解來添加、移除或替換一些值。

4.5 識別跨站腳本（XSS）漏洞

跨站腳本（XSS）是 Web 應用中最常見的漏洞之一。實際上，它位于 2013 年 OWASP Top 10 的第三名（<https://www.owasp.org/ index.php/Top_10_2013-Top_10>）。

這個秘籍中，我們會看到一些識別 Web 應用中跨站腳本漏洞的關鍵點。

操作步驟

1. 登錄 DVWA 并訪問反射型 XSS。

2. 測試漏洞的第一步是觀察應用的正常響應。在文本框中輸入名稱并點擊Submit按鈕。我們使用Bob。

3. 應用會使用我們提供的名稱來拼接代碼。如果我們不輸入有效名稱，而是輸入一些特殊字符或數字會怎么樣呢？讓我們嘗試<'this is the 1st test'>。

4. 現在我們可以看到，我們輸入在文本框匯總的任何東西都會反射到響應中，也就是說，它成為了響應中 HTML 頁面的一部分。讓我們檢查頁面源代碼來分析它如何展示信息，就像下面截圖中那樣：

   源碼表明了輸出中沒有對任何特殊字符做編碼。我們發送的特殊字符被反射回了頁面，沒有任何預處理。<和>符號適用于定義 HTML 標簽的符號，我們可能能夠在這里輸入一些腳本代碼。

5. 嘗試輸入一個名稱，后面帶有非常簡單的腳本代碼。

   Bob<script>alert('XSS')</script>
   

   頁面會執行腳本，并彈出提示框，表明這個頁面上存在跨站腳本漏洞。

6. 現在檢查源碼來觀察輸入中發生了什么。

   我們的輸入看起來作為 HTML 的一部分來處理。瀏覽器解釋了<script>標簽并執行了其中的代碼，彈出了我們設置的提示框。

工作原理

跨站腳本漏洞在服務端和客戶端中沒有輸入校驗，并且輸出沒有合理編碼時發生。這意味著應用允許我們輸入用于 HTML 代碼中的字符。一旦它被決定發送到頁面中，并沒有執行任何編碼措施（例如使用 HTML 轉義代碼&lt 和 >）來防止他們被解釋為源代碼。

這些漏洞可被攻擊者利用來改變客戶端的頁面行為，并欺騙用戶來執行它們不知道的操作，或偷取隱私信息。

為了發現 XSS 漏洞，我們需要遵循以下原則：

• 我們在輸入框中輸入的，準確來說是被發送的文本，用于形成在頁面中展示的信息，這是反射型漏洞。

• 特殊的字符沒有編碼或轉義。

• 源代碼表明，我們的輸入被集成到某個位置，其中它變成了 HTML 代碼的一部分，并且會被瀏覽器解釋。

更多

這個秘籍中，我們發現了反射型 XSS，也就是說這個腳本在每次我們發送請求時，并且服務器響應我們的惡意請求時都會執行。有另外一種 XSS 類型叫做“存儲型”。存儲型 XSS 可能會在輸入提交之后立即展示，也可能不會。但是這種輸入會儲存在服務器（也可能是數據庫）中，它會在用戶每次訪問儲存數據時執行。

4.6 基于錯誤的 SQL 注入識別

注入在 OWASP top 10 列表中位列第一。這包含，我們會在這個秘籍中測試的漏洞：SQL 注入（SQLI），以及其它。

多數現代 Web 應用實現了某種類型的數據庫，要么本地要么遠程。SQL 是最流行的語言，在 SQLI 攻擊中，攻擊者向表單輸入或請求中的其它參數注入 SQL 命令，使應用發送修改后的請求，來試圖不正當使用應用和數據庫通信。其中請求用于構建服務器中的 SQL 語句。

這個秘籍中，我們會測試 Web 應用的輸入，來觀察是否含有 SQL注入漏洞。

操作步驟

登錄 DWVA 并執行下列步驟：

1. 訪問SQL Injection。

2. 類似于上一章，我們通過輸入數字來測試應用的正常行為。將User ID設置為1，并點擊Submit。

   我們可以通過解釋結果來得出，應用首先查詢數據庫，是否有 ID 等于 1 的用戶，之后返回結果。

3. 下面，我們必須測試，如果我們發送一些應用的非預期結果，會發生什么。在輸入框中輸入1'并提交該 ID。

   這個錯誤信息告訴我們，我們修改了生成好的查詢。這并不意味著這里確實有 SQL 注入，但是我們可以更進一步。

4. 返回 DWVA/SQL 注入頁面。

5. 為了驗證是否有基于錯誤的 SQL 輸入，我們嘗試另一個輸入：1''（兩個單引號）。

6. 現在，我們要執行基本的 SQL 注入攻擊，在輸入框中輸入' or '1'='1并提交。

   看起來我們獲取了所有數據庫中的注冊用戶。

工作原理

SQL 注入發生在輸入在用于組成數據庫查詢之前沒有校驗的時候。讓我們假設服務端的代碼（PHP）拼裝了一個請求，例如：

$query = "SELECT * FROM users WHERE id='".$_GET['id']. "'";

這意味著，id參數中發送的數據會被集成進來，因為它在查詢里面。將參數的引用替換為它的值，我們能得到：

$query = "SELECT * FROM users WHERE id='"."1". "'";

所以，當我們發送惡意輸入，就像之前那樣，代碼行會由 PHP 解釋器讀取，就像：

$query = "SELECT * FROM users WHERE id='"."' or '1'='1"."'";

拼接為：

$query = "SELECT * FROM users WHERE id='' or '1'='1'";

這意味著“選擇users表中的任何條目，只要用戶id等于空或者 1 等于 1”。然而 1 永遠等于 1，這就意味著所有用戶都復合條件。我們發送的第一個引號閉合了原始代碼中的做引號，之后我們輸入了一些 SQL 代碼，不帶有閉合的單引號，而是使用已經在服務端代碼中該設置好的單引號。

更多

SQL 攻擊比起顯式應用的用戶名，可能導致更嚴重的破壞。通過利用這些漏洞，攻擊者可能會通過執行命令和提權來控制整個服務器。它也能夠提取數據庫中的所有信息，包括系統用戶名稱和密碼。取決于服務器和內部網絡的配置，SQL 注入漏洞可能是整個網絡和內部設施入侵的入口。

4.7 識別 SQL 盲注

我們已經看到了 SQL 注入漏洞如何工作。這個秘籍中，我們會涉及到相同類型漏洞的不同變體，它不顯式任何能夠引導我們利用的錯誤信息或提示。我們會學習如何識別 SQL 盲注。

操作步驟

1. 登錄 DVWA 并訪問SQL Injection (Blind)。

2. 它看起來像是我們上一章了解的 SQL 注入。在輸入框中輸入1并點擊Submit。

3. 現在我們首次測試1'。

   我們沒有得到任何錯誤信息，但是也沒有結果，這里可能會發生一些有趣的事情。

4. 我們第二次測試1''。

   ID=1的結果顯示了，這意味著上一個結果1'產生了錯誤，并被應用捕獲和處理掉了。很可能這里有個 SQL 注入漏洞，但是它是盲注，沒有顯示關于數據庫的信息，所以我們需要猜測。

5. 讓我們嘗試識別，當用戶注入永遠為假的代碼會發生什么。將1' and '1'='2設置為用戶的 ID。

   '1'永遠不會等于'2'，所以沒有任何記錄符合查詢中的條件，并且沒有人惡化結果。

6. 現在，嘗試當 ID 存在時永遠為真的請求：1' and '1'='1。

   這演示了頁面上的盲注。如果我們的永遠為假的 SQL 注入得到了不同的響應，并且永遠為真的結果得到了另一個響應，這里就存在漏洞，因為服務器會執行代碼，即使它不顯示在響應中。

工作原理

基于錯誤的 SQL 輸入和盲注都存在于服務端，也就是漏洞的那一段。應用在使用輸入生成數據庫查詢之前并不過濾輸入。二者的不同存在于檢測和利用上。

在基于錯誤的 SQL 注入中，我們使用由服務器發送的錯誤來識別查詢類型，表和列的名稱。

另一方面，當我們視圖利用盲注時，我們需要通過問問題來得到信息。例如，"' and name like 'a%"的意思是，“是否存在以'a'開頭的用戶？”如果我們得到了負面響應，我們會詢問是否有以'b'開頭的名稱。在得到正面結果之后，我們會就會移動到第二個字符："' and name like 'ba%"。所以我們會花費很多時間來檢測和利用。

另見

下面的信息可能有助于更好的了解 SQL 盲注：

• https://www.owasp.org/index.php/Blind_SQL_Injection
• https://www.exploit-db.com/papers/13696/
• https://www.sans.org/reading-room/whitepapers/securecode/sqlinjection-modes-attack-defence-matters-23

4.8 識別 Cookie 中的漏洞

Cookie 是從網站發送的小型數據片段，它儲存于用戶的瀏覽器中。它們包含有關于這種瀏覽器或一些特定 Web 應用用戶的信息。在現代 Web 應用匯總，Cookie 用于跟蹤用戶的會話。通過在服務端和客戶端保存 Session ID，服務器能夠同時識別由不同客戶端產生的不同請求。當任何請求發送到服務器的時候，瀏覽器添加 Cookie并之后發送請求，服務器可以基于這個 COokie 來識別會話。

這個秘籍中，我們會學到如何識別一些漏洞，它們允許攻擊者劫持有效用戶的會話。

操作步驟

1. 訪問 http://192.168.56.102/mutillidae/。

2. 打開 Cookie Manager+ 并且刪除所有 Cookie。這可以防止與之前的 Cookie 產生混亂。

3. 現在，在 Mutillidae II中，訪問OWASP Top 10 | A3 – Broken Authentication and Session Management | Cookies。

4. 在Cookies Manager+中，我們會看到出現了兩個新的 Cookie。PHPSESSID和showhints。選項前者并點擊Edit來查看所有參數。

   PHPSESSID是基于 PHP 的 Web 應用的會話默認名稱。通過查看 Cookie 中參數值，我們可以看到它可以經過安全和不安全的頻道（HTTP 和 HTTPS）發送。同樣，它可以被服務器讀取，以及被客戶端用過腳本代碼讀取，因為它并沒有開啟 HTTPOnly 標識。這就是說，這個應用的會話可以被劫持。

工作原理

這個秘籍中，我們檢查了 Cookie 的某些之，雖然并不像上一個那么明顯。在每次滲透測試中檢查 Cookie 的配置非常重要，不正確的會話 Cookie 設置會打開會話劫持攻擊的大門，以及錯誤使用受信任的用戶賬戶。

如果 Cookie 沒開啟HTTPOnly標識，他就可以被腳本讀取。因此，如果存在跨站腳本攻擊漏洞，攻擊者就能夠得到有效會話的 ID，并且使用它來模擬應用中的真實用戶。

Cookies Manager+ 中的安全屬性，或者Send For Encrypted Connections Only選項告訴瀏覽器只通過加密的頻道發送或接受該 Cookie（也就是說，只通過 HTTPS）。如果這個標志沒有設置，攻擊者可以執行中間人攻擊（MITM），并且通過 HTTP 來得到會話 Cookie，這會使它顯示為純文本，因為 HTTP 是個純文本的協議。這就再次產生了攻擊者能夠通過持有會話 ID 來模擬有效用戶的場景。

更多

就像PHPSESSID是 PHP 會話 Cookie 的默認名稱那樣，其它平臺也擁有名稱，例如：

• ASP.NET_SessionId是 ASP.NET 會話 Cookie 的名稱。

• JSESSIONID是 JSP 實現的會話 Cookie。

OWASP 有一篇非常透徹的文章，關于保護會話 ID 和會話 Cookie。

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

4.9 使用 SSLScan 獲取 SSL 和 TLS 信息

我們在某種程度上，假設當一個連接使用帶有 SSL 或 TLS 加密的 HTTPS 時，它是安全的，而且任何試圖攔截它的攻擊者都只會得到一些無意義的數字。但是，這并不絕對正確：HTTPS 服務器需要正確配置來提供有效的加密層，并保護用戶不受 MITM 攻擊或密碼分析。一些 SSL 協議的實現和設計上的漏洞已經被發現了，所以，我們在任何 Web 應用滲透測試中都要測試安全連接的強制性。

這個秘籍中，我們會使用 SSLScan，它是 Kali Linux 所包含的工具，基于服務器的安全通信來分析服務器的配置文件（從客戶端的角度）。

操作步驟

OWASP BWA 虛擬機已經配置好了 HTTPS 服務器，為了確保它正常工作，訪問 https://192.168.56.102/，如果頁面沒有正常加載，你可能需要在繼續之前檢查你的配置文件。

2. SSLScan 是個命令行工具（內建于 Kali），所以我們需要打開終端。

3. 基本的sslscan命令會提供給我們服務器的足夠信息。

   sslscan 192.168.56.102
   

   輸出的第一部分告訴我們服務器的配置，包含常見的安全錯誤配置：重協商、壓縮和 Heartbleed，它是最近在一些 TLS 實現中發現的漏洞。這里，一切看起來都很好。

   在第二部分中，SSLScan 會展示服務器接受的加密方式。正如我們看到的那樣，它支持 SSLv3 和一些例如 DES 的方式，它現在是不安全的。它們以紅色文字展示，黃色文字代表中等強度的加密。

   最后，我們看到了首選的加密方式，如果客戶端支持它，服務器會嘗試用于通信。最終，服務器會使用有關證書的信息。我們可以看到，它將中等強度的算法用于簽名，并使用 RSA 弱密鑰。密鑰是弱的，因為他只有 1024 位的長度，安全標準推薦至少 2048 位。

工作原理

SSLScan 通過創建多個到 HTTPS 的鏈接來工作，并嘗試不同的加密方式和客戶端配置來測試它接受什么。

當瀏覽器鏈接到使用 HTTPS 的服務器時，它們交換有關瀏覽器可以使用什么以及服務器支持什么的信息。之后它們在使用高度復雜的算法上達成一致。如果配置不當的 HTTPS 服務器上出現了 MITM 攻擊，攻擊者就可以通過聲稱客戶端值支持弱加密算法來欺騙服務器，假如是 SSLv2 上的 56 位 DES。之后攻擊者會攔截使用該算法加密的通信，通信可能會在幾天或幾小時之內使用現代計算機破解。

更多

就像我們之前提到的那樣，SSLScan 能夠檢測 Heartbleed，這是一個最近在 OpenSSL 實現中發現的有趣漏洞。

Heartbleed 在 2014 年四月被發現。它由一個緩沖區導致，多于允許的數據可以從內存中讀出，這是 OpenSSL TLS 中的情況。

實際上，Heartbleed 可以在任何未裝補丁的支持 TLS 的 OpenSSL （1.0.1 到 1.0.1f 之間）服務器上利用。它從服務器內存中讀取 64 KB 的純文本數據，這能夠重復執行，服務器上不會留下任何蹤跡或日志。這意味著攻擊者可以從服務器讀取純文本信息，包括服務器的的私鑰或者加密正是，會話 Cookie 或 HTTPS 請求會包含用戶的密碼或其它敏感信息。更多 Heartbleed 的信息請見維基百科：<https://en.wikipedia.org/wiki/ Heartbleed>。

另見

SSLScan 并不是唯一從 SSL/TLS 獲取加密信息的攻擊。Kali 中也有另一個工具叫做 SSLyze 可以用作替代，并且有時候會提供額外信息給攻擊者。

sslyze --regular www.example.com 

SSL/TLS 信息也可以通過 OpenSSL 命令獲得：

openssl s_client -connect www2.example.com:443

4.10 查找文件包含

文件包含漏洞出現在開發者使用請求參數的時候，在服務端的代碼中，參數可以被用戶修改來動態選擇加載或包含哪個頁面。如果服務器執行了所包含的文件，這種漏洞可能導致整個系統的淪陷。

這個秘籍中，我們會測試 Web 應用來發現是否含有文件包含漏洞。

操作步驟

1. 登錄 DVWA 并訪問File Inclusion。

2. 我們需要編輯 GET 參數來測試包含。讓我們嘗試index.php。

   看起來目錄中沒有index.php文件（或者它為空），也可能這意味著本地文件包含（LFI）可能出現。

3. 為了嘗試 LFI，我們需要了解本地真正存在的文件名稱。我們知道了 DVWA 根目錄下存在index.php，所以我們對文件包含嘗試目錄遍歷，將頁面遍歷設置為../../index.php。

   這樣我們就演示了 LFI 可能出現，并且路徑遍歷也可能出現（使用../../，我們就遍歷了目錄樹）。

4. 下一步是嘗試遠程文件包含，包括儲存在另一個服務器的我呢間，而不是本地文件，由于我們的測試虛擬機并沒有連接互聯網（或者它不應該聯網，出于安全因素）。我們嘗試帶有完整 URL 的本地文件，就像它來自另一個服務器那樣。我們也會嘗試包含 Vicnum 的主頁?page=http://192.168.56.102/vicnum/index.html，通過提供頁面的 URL 作為參數，就像下面這樣：

   我們能夠通過提供完整 URL 使應用加載頁面，這意味著我們可以包含遠程文件，因此，存在遠程文件包含（RFI）。如果被包含文件含有服務端可執行代碼（例如 PHP），這種代碼會被服務端執行。因此，攻擊者可以執行遠程命令，這樣的話，整個系統很可能淪陷。

工作原理

如果我們使用 DVWA 的View Source按鈕，我們可以看到服務端代碼是：

<?php 
$file = $_GET['page']; //The page we wish to display 
?>

這意味著page變量的值直接傳給了文件名稱，之后它被包含在代碼中。這樣，我們可以在服務端包含和執行任何我們想要的 PHP 或 HTML 文件，只要它可以通過互聯網訪問。存在 RFI 漏洞的情況下，服務器一定會在配置文件中打開allow_url_fopen和allow_url_include。否則它只能含有本地文件包含，如果文件包含漏洞存在的話。

更多

我們也可以使用本地文件包含來顯示主機操作系統的相關文件。例如，試著包含../../../../../../etc/passwd，之后你就會得到系統用戶和它們的主目錄，以及默認 shell 的列表。

4.11 識別 POODLE 漏洞

就像上一章提到的那樣，使用 SSLScan 獲得 HTTPS 參數在一些條件下是可能的，尤其是中間人攻擊者降級用于加密通信的安全協議和加密算法的時候。

POODLE 攻擊使用這種條件來將 TLS 通信降級為 SSLv3 并強制使用易于被攻破的加密算法（CBC）。

這個秘籍中，我們會使用 Nmap 腳本來檢測這種漏洞在測試服務器上是否存在。

準備

我們需要安裝 Nmap 并下載特定為檢測此漏洞而編寫的腳本。

1. 訪問http://nmap.org/nsedoc/scripts/ssl-poodle.html。

2. 下載ssl-poodle.nse文件。

3. 假設它下載到了你的 Kali 中的/root/Downloads中。下載打開終端并將它復制到 Nmap 的腳本目錄中：

   cp /root/Downloads/ssl-poodle.nse /usr/share/nmap/scripts/
   

操作步驟

一旦你安裝了腳本，執行下列步驟：

1. 打開終端并運行：

   nmap --script ssl-poodle -sV -p 443 192.168.56.102
   

   我們告訴了 Nmap 要掃描192.168.56.102（我們的 vulnerable_vm）的 443 端口，識別服務版本并在它上面執行 ssl-poodle 腳本。一次你，我們可以斷定，服務器有漏洞，因為它允許 使用TLS_RSA_WITH_ AES_128_CBC_SHA加密算法的 SSLv3 。

工作原理

我們下載的 Nmap 腳本和測試服務器建立了安全通信，并判斷他是否支持 SSLv3 上的 CBC 加密算法。如果支持，它就存在漏洞。漏洞會導致任何攔截的信息都能被攻擊者在很短的時間內解密。

另見

為了更好理解這個攻擊，你可以查看一些這個加密實現最基本的解釋。

• M?ller, Duong, and Kotowicz, This POODLE Bites: Exploiting the SSL 3.0 Fallback, https://www.openssl.org/~bodo/ssl-poodle.pdf
• https://en.wikipedia.org/wiki/Padding_oracle_attack
• https://en.wikipedia.org/wiki/Padding_%28cryptography%29#Block_cipher_mode_of_operation