# 九、應用邏輯漏洞 > 作者：Peter Yaworski > 譯者：[飛龍](https://github.com/) > 協議：[CC BY-NC-SA 4.0](http://creativecommons.org/licenses/by-nc-sa/4.0/) 應用邏輯漏洞不同于其他我們討論過的類型。雖然 HTML 注入、HTML 參數污染和 XSS 都涉及到提交一些類型的潛在惡意輸入，應用落地及漏洞實際上涉及到操縱場景和利用 Web APP 代碼中的 Bug。 這一類型攻擊的一個值得注意的例子是 Egor Homakov 對 Github 的滲透，Github 使用 RoR 編寫。如果你不熟悉 Rails，他是一個非常流行的 Web 框架，在開發 Web 站點時，它可以處理很多繁雜的東西。 在 2012 年 3 月，Egor 通知了 Rails 社區，通常，Rails 會接受所有提交給它的參數，并使用這些值來更新數據庫記錄（取決于開發者的實現。Rails 核心開發者的想法是，使用 Rails 的 Web 開發者應該負責填補它們的安全間隙，并定義那個值能夠由用戶提交來更新記錄。這個行為已經在社區內人人皆知了，但是 Github 上的線程展示了很少的人能夠鑒別出來它帶來的風險（`https://github.com/rails/rails/issues/5228`）。 當核心開發者不同意他的時候，Egor 繼續利用 Github 上的認證漏洞，通過猜測和提交參數值，它包含創建日期（如果你熟悉 Rails 并且知道多數數據庫記錄包含創建和更新日期列，它就不太困難）。因此，它在 Github 上傳了一個票據，年份是未來的某個日期。它也設法更新 SHH 訪問密鑰，這可以使他訪問 Github 官方的代碼倉庫。 之前提到了，這個滲透通過 Github 后端代碼實現，它并沒有合理驗證 Egor 所做的事情，這在隨后可用于更新數據庫記錄。這里，Egor 發現了叫做大量賦值漏洞的東西。 應用邏輯漏洞，即發現前面討論的這種類型的攻擊，更加有技巧性，因為它們依賴代碼判定的創造丁思渭，并且并不僅僅是提交潛在的惡意代碼，開發者沒有轉義它。（不要嘗試在這里簡化其它類型的漏洞，一些 XSS 攻擊也很復雜！） 使用 Github 的例子，Egor 知道了系統基于 Rails 以及 Rails 如何處理用戶輸入。在其他例子中，它涉及直接編程調用 API 來測試應用的行為，就像 Shopify 的管理員權限繞過那樣。或者，它涉及重復使用來自認證 API 調用的返回值，來進行后續的API 調用，本不應該允許你這么做。 ## 示例 ### 1\. Shopify 管理員權限繞過 難度：低 URL：`shop.myshopify.com/admin/mobile_devices.json ` 報告鏈接：`https://hackerone.com/reports/100938` 報告日期：2015.11.22 獎金：$500 描述： Shopify 是一個巨大并健壯的平臺，它包含 Web UI 以及受支持的 API。這個例子中，API 不驗證一些權限，而 Web UI 明顯會這么做。因此，商店的管理員，它們不被允許接受郵件提醒，可以通過操作 API 終端來繞過這個安全設置，在它們的 Apple 設備中收到提醒。 根據報告，黑客只需要： + 使用完全訪問權限的賬號登錄 Shopify 移動應用 + 攔截`POST /admin/mobile_devices.json`的請求 + 移除該賬號的所有權限 + 移除添加的移動端提醒 + 重放`POST /admin/mobile_devices.json`的請求 這樣做之后，用戶可以接收到所有商店處的訂單的移動端提醒，因此忽略了商店配置的安全設置。 > 重要結論 > 這里有兩個重要結論。首先，并不是所有東西都涉及代碼注入。始終記住使用代碼并觀察向站點傳遞了什么信息，并玩玩它看看什么會發生。這里，所有發生的事情是，移除 POST 參數來繞過安全檢查。其次，再說一遍，不是所有攻擊都基于 HTML 頁面。API 終端始終是一個潛在的漏洞區域，所以確保你考慮并測試了它們。 ### 2\. 星巴克競態條件 難度：中 URL：`Starbucks.com ` 報告鏈接：`http://sakurity.com/blog/2015/05/21/starbucks.html` 報告日期：2015.5.21 獎金：無 描述： 如果你不熟悉競態條件，本質上它是兩個潛在的進程彼此競爭來完成任務，基于一個廚師場景，它在請求被執行期間變得無效。換句話說，這是一個場景，其中你擁有兩個進程，它們本應該是互斥的，不應該同時完成，但是因為它們幾乎同時執行，它們被允許這么做了。 這里是一個例子： 1. 你在手機上登錄進了你的銀行站點，并請求將 $500 從你的一個僅僅擁有 $500 的賬戶轉到另一個賬戶。 2. 這個請求花費很長時間（但是仍然處理），所以你在你的筆記本上登錄，并且再次執行了相同請求。 3. 筆記本的請求幾乎立即完成了，但是你的手機也是這樣。 4. 你刷新了銀行賬戶，并發現你的賬戶里有 $1000。這意味著請求執行了兩次，這本不應被允許，因為你一開始只擁有 $500。 雖然這個很基礎，理念都是一樣的，一些條件存在于請求開始，在完成時，并不存在了。 所以，回到這個例子，Egor 測試了從一個星巴克的卡中轉賬，并且發現他成功觸發了競態條件。請求使用 CURL 程序幾乎同時創建。 > 重要結論 > 競態條件 是個有趣的攻擊向量，它有時存在于應用處理一些類型的余額的地方，例如金額、積分，以及其他。發現這些漏洞并不總是發生在第一次嘗試的時候，并且可能需要執行多次重復同時的請求。這里，Egor 在成功之前執行了 6 次請求。但是要記住在測試它的時候，要注意流量負荷，避免使用連續的測試請求危害到站點。 ### 3\. Binary.com 權限提升 難度：低 URL：`binary.com` 報告鏈接：`https://hackerone.com/reports/98247` 報告日期：2015.11.14 獎金：$300 描述： 這真是一個直接的漏洞，不需要過多解析。 本質上，在這個場景下，用戶能夠登錄任何賬戶，代表被黑的用戶賬戶，并查看敏感信息，或執行操作，并且一切只需要知道用戶的 UID。 在你滲透之前，如果你登錄了` Binary.com/cashier`，并查看了頁面的 HTML，你會注意到有個`<iframe>`標簽包含 PIN 參數。這個參數實際上就是你的賬戶 ID。 下面，如果你編輯了 HTML，并且插入了另一個 PIN，站點就會自動在新賬戶上執行操作，而不驗證密碼或者任何其他憑據。換句話說，站點會將你看做你所提供的賬戶的擁有者。 同樣，所需的一切就是知道某人的賬戶號碼。你甚至可以在出現在`iframe`中的時間修改為`PAYOUT`，來觸發另一個賬戶的付款操作。但是，`Bianry.com`表示，所有取款都需要手動人工復查，但是這并不是說，這就一定會被發現。 > 重要結論 > 如果你尋找基于漏洞的認證，要留意憑據傳遞給站點的地方。雖然這個漏洞通過查看頁面源碼來實現，你也可以在使用代理攔截器的時候，留意傳遞的信息。 > 如果你的確發現了被傳遞的一些類型的憑據，但他們看起來沒有加密時，要注意了，并且嘗試玩玩它們。這里，PIN 是`CRXXXXXX`而密碼是`0e552ae717a1d08cb134f132`。顯然 PIN 沒有解密，但是密碼加密了。未加密的值是一個非常好的地方，你可以從這里下手。 ### 4\. HackerOne 信號操作 難度：低 URL：`hackerone.com/reports/XXXXX` 報告鏈接：`https://hackerone.com/reports/106305` 報告日期：2015.12.21 獎金：$500 描述： 在 2015 年年末，HackerOne 向站點進入了新的功能，叫做信號。本質上，在這些報告關閉之后，它有助于識別黑客的之前漏洞報告的有效性。重要的是要注意，用戶可以關閉它們在 HackerOne 上的報告，這本應該對他們的聲譽和信號功能毫無影響。 所以，你可以猜到，在測試該功能的時候，一個黑客發現了這個功能的不合理實現，并且允許黑客向任何團隊創建報告，自己關閉報告，并從中受益。 這就是這里的情況了。 > 重要結論 通過一個簡短的描述，這里的結論不可能全部覆蓋。一定要留意新的功能！當站點實現了新的功能時，它對于黑客就像鮮肉一樣。新的功能展示了測試新代碼和搜索漏洞的機會。這就和 Shopify 和 Twitter 的 CSRF，以及 Facebook 的 XSS 漏洞一樣。為了最大利用它們，使你自己熟悉公司，并且訂閱公司的博客是個好主意，以便你在一些東西發布之后能夠收到提醒。之后測試它們。 ### 5\. Shopify S3 Bucket 開放 難度：中 URL：` cdn.shopify.com/assets ` 報告鏈接：`https://hackerone.com/reports/106305` 報告日期：2015.11.9 獎金：$1000 描述： Amazon 簡易存儲 S3，是一個服務，允許用戶在 Amazon 的云服務器上儲存和托管文件。Shopify 和許多站點都是用 S3 來儲存和托管靜態內容，例如圖片。 Amazon Web 服務的整個套件，AWS，是非常健壯的，并包含權限管理系統，允許管理員為每個服務定義權限，包含 S3。許可包含創建 S3 Bucket 的功能（Bucket 就像儲存器的文件夾），讀取和寫入 Bucket ，以及其他。 根據披露，Shopify 沒有合理配置它們的 S3 Bucket 權限，并且無意中允許任何認證過的 AWS 用戶讀取或寫入它們的 Bucket。這顯然是由問題的，因為你至少不希望惡意的黑帽子使用你的 S3 Bucket 來儲存和托管文件。 不幸的是，這個問題的細節沒有暴露，但是可能使用 AWS CLI 來發現，這是一個工具，允許你和 AWS 服務在你的共領航上交互。雖然你需要一個 AWS 賬戶來做這個事情，創建賬戶實際上也是免費的，因為你不需要任何服務。因此，使用 CLI 你就可以在 AWS 上認證你自己，并且隨后測試是否可以訪問（這也是我發現 HackerOne Bucket 的方式，它在下面列出）。 > 重要結論 > 當你偵查一個潛在的目標時，確保注意到所有不同的工具，包含 Web 服務，它們明顯可以使用。每個服務或軟件，OS，以及其他。你可以尋找或發現新的攻擊向量。此外，使你自己熟悉流行的 Web 工具，例如 AWS S3，Zendesk，Rails，以及其他是個好主意。許多站點都使用它們。 ### 6\. HackerOne S3 Bucket 開放 難度：中 URL：`[REDACTED].s3.amazonaws.com ` 報告鏈接：`https://hackerone.com/reports/128088` 報告日期：2016.4.3 獎金：$2500 描述： 我們打算講一些有些不同的東西。這是一個漏洞，我實際上發現了他，并且和上面描述的 Shopify 的問題有些不同，所以我打算詳細分享關于我如何發現他的任何事情。 所以，一開始，上面描述的漏洞就是，一個 Bucket 公開鏈接到了 Shopify。意思是，當你訪問這個想點時，你會看到 AWS 服務的調用，所以黑客就知道 Bucket 指向哪里。但是我并沒有 -- 我使用了一個很酷的腳本和一些工具來發現了 Bucket。 在 4 月 3 日的周末，我不知道為什么，但是我決定跳出思維定式，并嘗試攻擊 HackerOne。我一開始就玩了玩它們的站點，并且每次新漏洞發現時，都迫使我自己閱讀信息披露，想了解為什么我錯過了它。我想知道他們的 S3 Bucket 是否存在類似 Shopify 的漏洞。我也想知道，黑客如何訪問了 Shopify 的 Bucket。我了解到它是通過 Amazon 命令行工具來訪問的。 現在，通常我會使自己停下，因為 HackerOne 這個時候不可能還擁有漏洞。但是我突然有一個想法，它來源于我和 Ben Sadeghipour (@Nahamsec) 的訪談，就是不要懷疑自己，或者公司犯錯的可能。 所以我在 Google 上搜索一些細節，并碰到了兩個有意思的頁面： [There’s a Hole in 1,951 Amazon S3 Buckets](https://community.rapid7.com/community/infosec/blog/2013/03/27/1951-open-s3-buckets) [S3 Bucket Finder](https://digi.ninja/projects/bucket_finder.php) 第一個是個有趣的文章，來自 Rapid7，它是個安全公司，這篇文章關于如何發現公開可寫的 S3 Bucket ，并通過模糊測試，或者猜測 Bucket 名稱來實現。 第二個是個很酷的工具，它接受一個單詞列表，并調用 S3 來尋找 Bucket。但是，它沒有自帶列表。在 Rapid7 的文章中有一行關鍵字，“通過一個不同的列表來猜測名稱，列表包含 1000 強公司的名稱，以 .com, -backup, -media 排列。” 這就很有意思了。我很快為 HackerOne 創建了一列 Bucket 可能名稱，像這樣： ``` hackerone, hackerone.marketing, hackerone.attachments, hackerone.users, hackerone.files ``` 這些都不是真正的 Bucket。它們來自于報告。所以我覺得我肯定能夠發現它。我將其留作一個挑戰。 現在，使用 Ruby 腳本，我開始調用那些 Bucket。事情剛開始并不是那么好，我發現了幾個 Bucket 但是都拒絕訪問。很不幸，所以我先離開，看看 NetFlix。 但是這個想法還在提醒著我，所以在我睡覺之前，我決定再次使用更多組合來執行腳本。我再次發現了大量的 Bucket，它們看起來是 HackerOne 的，但是所有都拒絕訪問。我意識到，拒絕訪問起碼告訴我它們是存在的。 我打開了 Ruby 腳本，它在 Buckets調用了`ls`的等價函數。換句話說，我嘗試觀察它們是否公開可讀的。我想知道它，以及它們是否公開可寫的。 此外，現在 AWS 提供了命令行工具，aws-cli。我知道它，因為我之前用過，所以我在我的 VM 上快速執行`sudo apt-get aws-cli `，并準備好了。你可以在`docs.aws.amazon.com/cli/latest/userguide/installing.html`上找到這個東西的指南。 現在，命令`awss3help`會打開 S3 的幫助，并列出可用的命令。這些命令之一是`mv`，以` aws s3 mv [FILE] [s3://BUCKET]`的形式，所以我嘗試： ``` touch test.txt aws s3 mv test.txt s3://hackerone.marketing ``` 這是第一個 Bucket，我從中收到了拒絕訪問，并在調用`PutObject`操作時，我收到了`move failed: ./test.txt to s3://hackerone.marketing/test.txt A client error(Access Denied)`。 所以嘗試下一個，`aws s3 mv test.txt s3://hackerone.files `，并且成功了。我收到了這個消息，`move: ./test.txt to s3://hackerone.files/test.txt`。 真是神奇！現在我嘗試刪除文件：`aws s3 rm s3://hackerone.files/test.txt`，同樣成功了。 但是現在我還是懷疑自己。我快速登出了 HackerOne 來報告。并且在我鍵入時，我意識到我并沒有實際確認 Bucket 的所有權。AWS 允許任何人在全局名字空間下創建任何 Bucket。意思是，你，或者讀者都可能實際擁有我在測試的 Bucket。 我不確定是否應該不驗證就報告。我搜索了 Google 來看看我是否可以找到任何 Bucket 的引用。我沒有找到什么東西。我離開了電腦，來理清頭緒。我意識到，最壞的事情就是我得到了另一個無效報告，以及貢獻 -5。另一方面，我知道這至少值 $500，基于 Shopify 的漏洞也可能是 $1000。 我按下了提交，并去睡覺了。當我醒來的時候，HackerOne 回復了恭喜，并說它們已經修復了它和一些其他的存在漏洞的 Bucket。成功了！并且按照它們的條款，當他們授予獎勵的時候，它們會考慮潛在的安全性，包括我沒有發現但存在漏洞的其它 Bucket。 > 重要結論 > 有多個重要結論： > 1. 不要低估你的能力，以及開發者犯錯的可能性。HackerOne 是個優秀的團隊，擁有優秀的安全研究員。但是人們都會犯錯。挑戰你的假設吧。 > 2. 不要在首次嘗試之后就放棄。當我發現它的時候，瀏覽器每個 Bucket 都不可用，并且我幾乎離開了。但是之后我嘗試寫入文件，它成功了。 > 3. 所有的東西都在于只是。如果你知道存在了哪種漏洞，你就知道了要尋找以及測試什么。讀這本書就是一個良好的開始。 > 4. 我之前說過，又再說一遍，一個攻擊面要好于站點，它也是公司所使用的的服務。要跳出思維定式。 ### 7\. 繞過 Gitlab 的雙因素認證 難度：中 URL：無 報告鏈接：`https://hackerone.com/reports/128085` 報告日期：2016.4.3 獎金：無 描述： 4 月 3 日，Jobert Abma（HackerOne 的聯合創始人）向 Gitlab 報告稱，在雙因素認證開啟情況下，攻擊者能夠登錄受害者的賬戶，而不需知道受害者的密碼。 對于那些不熟悉的人，雙因素認證是兩個登錄步驟，通常用戶輸入它們的用戶名和面，之后站點會發送驗證碼，通常通過電子郵件或者 SMS，用戶需要輸入它來完成登錄過程。 這里，Jobert 注意到，在這個過程中，一旦攻擊者輸入了用戶名和密碼，會發送一個 Token 來結束登錄。在提交這個 Token 時，POST 調用為： ``` POST /users/sign_in HTTP/1.1 Host: 159.xxx.xxx.xxx ... ----------1881604860 Content-Disposition: form-data; name="user[otp_attempt]" 212421 ----------1881604860- ``` 如果攻擊者攔截了它并向調用添加了用戶名，例如： ``` POST /users/sign_in HTTP/1.1 Host: 159.xxx.xxx.xxx ... ----------1881604860 Content-Disposition: form-data; name="user[otp_attempt]" 212421 ----------1881604860 Content-Disposition: form-data; name="user[login]" john ----------1881604860- ``` 攻擊者就能夠登錄進 John 的賬戶，如果`otp_attempt `對 John 可用。換句話說，在兩步認證期間，如果攻擊者添加了`user[login]`參數，它們就能修改被登錄的賬戶。 現在，唯一的麻煩就是攻擊者需要擁有有效的 OTP Token，用于受害者。但是這就是爆破登場的時候了。如果站點管理員沒有實現速率限制，Jobert 就可以對服務器執行重復調用來猜測有效的 Token。攻擊成功的可能性取決于向服務器發送請求的傳輸時間，以及 Token 有效時間的長度，但是無論如何，這里的漏洞都很明顯。 > 重要結論 > 雙因素驗證是個機巧的系統，難以正確實現。當你注意到站點使用了它時，你需要完整測試所有功能，包括 Token 的生命周期，嘗試的最大次數，復用過期的 Token，猜測 Token 的可能性，以及其他。 ### 8\. 雅虎 PHP 信息泄露 難度：中 URL：`http://nc10.n9323.mail.ne1.yahoo.com/phpinfo.php` 報告鏈接：`https://blog.it-securityguard.com/bugbounty-yahoo-phpinfo-php-disclosure-2/` 報告日期；2014.10.16 獎金：無 描述： 雖然它并沒有巨額獎金，像是其他漏洞那樣（實際上沒有獎金，非常意外），但這是我最喜歡的報告之一，因為它教會了我網絡掃描和自動化的重要性。 在 2014 年 10 月，Patrik Fehrenbach（你應該從“Hacking Pro Tips Interview#2”中了解了他，很棒的一個家伙）發現了雅虎的服務器中存在可訪問的`phpinfo()`文件。如果你不熟悉`phpinfo()`，這是一個敏感的命令，它不應該在生產環境能夠訪問，以及公開訪問，因為它泄露了所有類型的服務器信息。 現在，你可能想知道 Patrik 如何找到了`http://nc10.n9323.mail.ne1.yahoo.com`，我保證。結果它 PING 了`yahoo.com`，它返回了` 98.138.253.109`。之后它將其傳給了 WHOIS，并發現雅虎實際上擁有下面這些東西： ``` NetRange: 98.136.0.0 - 98.139.255.255 CIDR: 98.136.0.0/14 OriginAS: NetName: A-YAHOO-US9 NetHandle: NET-98-136-0-0-1 Parent: NET-98-0-0-0-0 NetType: Direct Allocation RegDate: 2007-12-07 Updated: 2012-03-02 Ref: http://whois.arin.net/rest/net/NET-98-136-0-0-1 ``` 要注意第一行，雅虎擁有大量的 IP 地址，從` 98.136.0.0`到`98.139.255.255`，或者`98.136.0.0/14`，這是 260000 個獨立 IP 地址。這是大量的潛在目標。 Patrik 之后寫了個簡單的 bash 腳本來尋找可用的`phpinfo`文件： ```sh #!/bin/bash for ipa in 98.13{6..9}.{0..255}.{0..255}; do wget -t 1 -T 5 http://${ipa}/phpinfo.php; done & ``` 執行了這個，他在隨機的雅虎服務器上發現了它。 > 重要結論 > 在滲透的時候，考慮公司的整個設施，除非他們告訴你這超出范圍了。雖然這個報告沒有得到一分錢的獎金，我知道 Patrik 使用了相似的技巧來尋找一些重要的漏洞來獲得獎金。 > 此外，你會注意到，這里有 260000 個潛在的地址，他們不可能手動掃描。在執行這一類型的測試時，自動化非常重要，并且是應該使用的東西。 ### 9\. HackerOne Hacktivity 投票 難度：中 URL：`https://hackerone.com/hacktivity` 報告鏈接：`https://hackerone.com/reports/137503` 報告日期：2016.5.10 獎金：Swag 描述： 雖然嚴格來說，這里沒有真正的安全漏洞，這個報告是個跳出思維定式的良好示例。 2016 年 4 月到 5 月的一段時間，HackerOne 為黑客開發了一個新功能，來通過 Hacktivity 列表給報告投票。要知道功能是否可用，有個簡單的辦法，也有個難的辦法。通過簡單的辦法，登錄時`/current_user`的 GET 調用會包含`hacktivity_voting_enabled:false`。難的辦法有些有趣，其中存在漏洞，并且這就是我包含這篇報告的原因。 如果你訪問了 hacktivity 并且查看了頁面源碼，你會注意到非常稀疏，只是一些`div`，沒有真正的內容。  HackerOne Hacktivity 頁面源碼 現在，如果你不喜歡他們的平臺，并且沒有安裝類似于 wappalyzer 的插件，僅僅看這個頁面源碼也會告訴你，內容由 JavaScript 渲染。 所以，知道了之后，如果你打開 Chrome 或 Firefox 的開發者工具，你可以檢查 JavaScript 源碼（在 Chrome 中，你需要訪問`source`，左邊是` top>hackerone.com->assets->frontend-XXX.js`）。Chrome 的開發者工具自帶了花括號美化打印的按鈕，這會使最小化的 JavaScript 刻度。你也可以使用 Burp 來查看返回這個 JavaScript 文件的響應。 原因是這樣，如果你在 JavaScript 中搜索 POST，你會發現一些 HackerOne 所使用的 路徑，它們可能不是那么明顯，取決于你的權限，以及內容里有什么東西。其中之一是：  HackerOne 應用的 JavaScript POST 投票 你可以看到，我們有兩個用于投票功能的路徑。在寫這個報告的時候，你實際可以執行這些調用，并給報告投票。 現在，這是發現功能的一種方式 -- 在報告中，黑客使用了另一種，通過攔截 HackerOne 的響應（大概是使用類似 Burp 的工具）。它們將返回為假的屬性切換為真。這之后暴露了投票元素，在點擊時，執行了可用的 POST 或者 DELETE 調用。 我想你展示 JavaScript 的原因時，和 JSON 響應交互可能不會總是暴露新的 HTML 元素。因此，瀏覽 JavaScript 可能暴露其它“隱藏的”終端來交互。 > 重要結論 > JavaScript 源代碼想你提供了來自目標的實際源代碼，你可以瀏覽它們。這非常棒，因為你的測試從完全黑盒，對后端沒有任何想法，變成了白盒（雖然也不完全是），其中可以觀察代碼如何執行。這不意味你需要走查每一行代碼，這里的 POST 調用在 20570 行發現，只使用了一個簡單的 POST 搜索。 ## 10\. Pronhub Mamcache 未授權訪問 難度：中 URL：`stage.pornhub.com ` 報告鏈接：`https://hackerone.com/reports/119871` 報告日期：2016.3.1 獎金：$2500 描述： 在它們公開啟動之前，Pornhub 在 HackerOne 上開啟了一個私有漏洞獎勵計劃，`*.pornhub.com`域，帶有豐富的獎金，這對于多數黑客來說意思是所有 Pronhub 的子域都是一樣的。現在的問題是發現他們。 在他的博文中，Andy Gill（@ZephrFish）解釋了為什么這個非常好，它使用超過一百萬潛在名稱的列表，通過測試不同子域名稱是否存在，發現了越 90 個可能的漏洞目標。 現在，如果訪問所有這些站點來觀察什么是可用的，這會花費大量時間，所以它使用 Eyewitness 工具自動化了這個流程（在工具一章中包含），它從有效 HTTP/HTTPS 頁面中截了一些截圖，并提供了一個不錯的報告，其中站點監聽 80、443、8080 和 8443 端口（常見 HTTP 和 HTTPS 端口）。 根據他的 WriteUp，Andy 稍微切換了一些另見，并使用 Nmap 工具來深入挖掘` stage.pornhub.com`子域。當我問他原因時，它解釋道，以他的經驗，`stage`和開發服務器比起生產服務器更可能擁有錯誤配置的安全權限。所以，一開始，它使用了`nslookup`命令，得到了子域的 IP。 ``` nslookup stage.pornhub.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: stage.pornhub.com Address: 31.192.117.70 ``` 我也看到，這個可以通過命令`ping`來完成，但是無論哪種方法，它現在擁有了子域的 IP 地址，并使用命令`sudo namp -sSV -p- 31.192.117.70 -oA stage__ph -T4 &`，它得到了： ``` Starting Nmap 6.47 ( http://nmap.org ) at 2016-06-07 14:09 CEST Nmap scan report for 31.192.117.70 Host is up (0.017s latency). Not shown: 65532 closed ports PORT STATE SERVICE VERSION 80/tcp open http nginx 443/tcp open http nginx 60893/tcp open memcache Service detection performed.Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 22.73 seconds ``` 將命令拆解一下： + 標志`-sSV`定義了發送給服務器的封包類型，告訴 Nmap 嘗試和判斷任何開放端口上的服務。 + `-p-`告訴服務器要檢查所有 65535 個端口（默認只會檢查常用的 1000 個端口）。 + `31.192.117.70`是要掃描的 IP。 + `-oA stage__ph`告訴 Nmap 一次以三種主要格式輸出它的發現，使用文件名稱`stage__ph`。 + `-T4`定義了任務的時間（選項為 0 ~ 5，數字越大就越快）。 對于結果來說，要注意的關鍵就是端口 60893 是打開的，而且 Nmap 認為它運行 Memcache。對于那些不熟悉的人，Memcache 是一個緩存服務，它使用鍵值對來儲存任意數據。它通常通過更快地服務內容，用于提升網站的速度。類似的服務的 Redis。 發現這本身不是個漏洞，但是是個危險信號（雖然安裝指南推薦使其不可能公開訪問，作為一個安全措施）。測試之后，意外的是 Pornhub 并沒有開啟任何安全手段。Andy 能夠通過 netcat 連接服務，不需要用戶名和密碼。連接之后，它執行命令來獲取版本，狀態，以及其他，為了確認這個和漏洞。 但是，惡意攻擊者可以將其用于： + 造成拒絕服務，通過持續寫入和刪除緩存，因此使服務器保持繁忙（取決于站點的配置）。 + 通過用垃圾緩存數據填充服務，造成 DOS，同樣取決于站點配置。 + 執行跨站腳本攻擊，通過注入惡意 JS 載荷作為有效的緩存數據，來提供給用戶。 + 可能的話，執行 SQL 注入，如果 memcache 數據在數據庫中存儲的話。 > 總要結論 > 子域和更寬泛的網絡配置代表了用于滲透的極大潛能。如果你注意到程序在域中包含` *.SITE.com`，嘗試找到可能存在漏洞的子域，而不要去追求主站上的低懸的果實，因為人人都能搜索到它們。你也的值花費時間來使你自己熟悉一些工具，例如 Nmap、Eyewitness、KnockPy，以及其他。這有助于你獲得 Andy 的視角。 ## 總結 應用邏輯漏洞不一定總是涉及代碼。反之，利用它們通產更需要敏銳的觀察力，以及跳出思維定式。始終留意其它站點可能使用的工具和服務，因為它們代表了新的攻擊向量。這包括站點所使用的來渲染內容的 JavaScript 庫。 發現它們或多或少都需要代理攔截器，在將其發送到你所利用的站點之前，它能讓你玩轉一些值。嘗試修改任何值，只要它們和識別你的賬戶相關。這可能包含建立兩個不同的賬戶，以便你有兩套有效的憑據，這可能有幫助。同時尋找隱藏或不常用的終端，它可以用于利用無意中訪問的功能。 任何時候一些類型的事務發生時，你也應該留意。始終有一些機會，其中開發者沒有在數據庫級別處理競態條件（特別是 NoSQL）。也就是說，它們的代碼可能會阻止你，但是如果你讓代碼執行夠快，比如幾乎同時完成，你就能發現靜態條件。確保你多次測試了這個領域內的任何東西，因為每次嘗試不一定都發生，就像星巴克的案例那樣。 最后，要留意新的功能 -- 它通常為測試展示了新的區域。并且如果可能的話，自動化你的測試來更好利用你的時間。