SMBGhost भेद्यता (CVE-2020-0796) में, मैंने एक तकनीक के बारे में बात की थी जो पूर्णांक अतिप्रवाह बग के उपयोग के माध्यम से write-what-where प्रिमिटिव है, जिसमें Alloc.Userbuffer पॉइंटर को बदलकर उस पते पर इंगित किया जाता है जो हम चाहते हैं और उसमें मनमाना डेटा लिखा जाता है। SMB Ghost के समान, यह भेद्यता भी srv2.sys में Srv2DecompressData फ़ंक्शन में मौजूद है। आइए फिर से Srv2DecompressData फ़ंक्शन को देखें जो SMBGhost भेद्यता (CVE-2020-0796) से संबंधित है और Zecops द्वारा सरलीकृत किया गया है।``` c typedef struct _COMPRESSION_TRANSFORM_HEADER { ULONG ProtocolId; ULONG OriginalCompressedSegmentSize; USHORT CompressionAlgorithm; USHORT Flags; ULONG Offset; } COMPRESSION_TRANSFORM_HEADER, *PCOMPRESSION_TRANSFORM_HEADER;

typedef struct _ALLOCATION_HEADER { // ... PVOID UserBuffer; // ... } ALLOCATION_HEADER, *PALLOCATION_HEADER;

NTSTATUS Srv2DecompressData(PCOMPRESSION_TRANSFORM_HEADER Header, SIZE_T TotalSize) { PALLOCATION_HEADER Alloc = SrvNetAllocateBuffer( (ULONG)(Header->OriginalCompressedSegmentSize + Header->Offset), NULL); If (!Alloc) { return STATUS_INSUFFICIENT_RESOURCES; }

ULONG FinalCompressedSize = 0;


NTSTATUS Status = SmbCompressionDecompress(
    Header->CompressionAlgorithm,
    (PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER) + Header->Offset,
    (ULONG)(TotalSize - sizeof(COMPRESSION_TRANSFORM_HEADER) - Header->Offset),
    (PUCHAR)Alloc->UserBuffer + Header->Offset,
    Header->OriginalCompressedSegmentSize,
    &FinalCompressedSize);
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
    SrvNetFreeBuffer(Alloc);
    return STATUS_BAD_DATA;
}


if (Header->Offset > 0) {
    memcpy(
        Alloc->UserBuffer,
        (PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER),
        Header->Offset);
}


Srv2ReplaceReceiveBuffer(some_session_handle, Alloc);
return STATUS_SUCCESS;

}

Hàm Srv2DecompressData एक क्लाइंट द्वारा भेजे गए संपीड़ित संदेश को प्राप्त करता है और आवश्यक मेमोरी क्षेत्र आवंटित करता है, उसमें संदेश को डीकंप्रेस करता है। फिर, यदि Offset फ़ील्ड शून्य नहीं है, तो यह आवंटित मेमोरी की शुरुआत में संपीड़ित डेटा से पहले के डेटा (RawData) को कॉपी करता है।

![](https://assets.kitploit.com/production/public/readmes/24502/a5bf8b5059336fb3677162343bace0d0b45085f2eb89e42d85f81e032fe233dc.png)

SMBGhost त्रुटि इस तथ्य में निहित है कि फ़ंक्शन integer overflow की जाँच नहीं करता है, जिससे गलत आकार आवंटन होता है और buffer overflow होता है। Microsoft द्वारा SMBGhost को पैच करने के तीन महीने बाद, CVE-2020-1206 (SMBleed - जैसा कि [Zecops Blog](https://blog.zecops.com/) द्वारा नामित) भेद्यता पाई गई। यह भेद्यता हमें दूसरे मशीन के पते को लीक करने की अनुमति देती है, और यदि SMBGhost के साथ संयुक्त किया जाए, तो हम RCE प्राप्त कर सकते हैं। Srv2DecompressData फ़ंक्शन के बारे में सरल दृष्टिकोण के लिए, हम इस फ़ंक्शन का उपयोग SMBGhost पैच से पहले करेंगे और मान लेंगे कि इसे पैच किया गया है।

# OriginalCompressedSegmentSize को धोखा देना
SMBGhost की तरह, इस बार हम OriginalCompressedSegmentSize को हमारे द्वारा भेजे गए डीकंप्रेस्ड डेटा से थोड़ी बड़ी संख्या के साथ धोखा देंगे। उदाहरण के लिए, हम x बाइट आकार के डेटा को संपीड़ित करते हैं, OriginalCompressedSegmentSize फ़ील्ड में x रखने के बजाय, हम इसे x + 0x1000 पर सेट करेंगे, निम्नलिखित चित्र से यह स्पष्ट होगा:

![](https://assets.kitploit.com/production/public/readmes/24502/687d3bdc67e4b2f5bb3cecbe41ea52be98a5c904a8688b325a69acb0a854ca75.png)

Uninitialized kernel data को संदेश के एक भाग के रूप में माना जाएगा।

जैसा कि मैंने [CVE-2020-0796](https://github.com/datntsec/CVE-2020-0796) के विश्लेषण में कहा था, Srv2DecompressData अभी भी SmbCompressionDecompress फ़ंक्शन के बाद जाँच चरण को छोड़ देगा यदि डीकंप्रेसन सफलतापूर्वक होता है:``` c
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
    SrvNetFreeBuffer(Alloc);
    return STATUS_BAD_DATA;
}

हालांकि OriginalCompressedSegmentSize फ़ील्ड को x के बजाय x + 0x1000 पर सेट किया गया है, लेकिन सफल डीकंप्रेसन के बाद, FinalCompressedSize वेरिएबल में x मान नहीं होगा, बल्कि x + 0x1000 मान होगा:```c NTSTATUS SmbCompressionDecompress( USHORT CompressionAlgorithm, PUCHAR UncompressedBuffer, ULONG UncompressedBufferSize, PUCHAR CompressedBuffer, ULONG CompressedBufferSize, PULONG FinalCompressedSize) { // ...

NTSTATUS Status = RtlDecompressBufferEx2(
    ...,
    FinalUncompressedSize,
    ...);
if (status >= 0) {
    *FinalCompressedSize = CompressedBufferSize;
}

// ...

return Status;

}

क्योंकि सफल डीकंप्रेसन के बाद, FinalCompressedSize को CompressedBufferSize (जो SmbCompressionDecompress फ़ंक्शन को पास किए गए OriginalCompressedSegmentSize के अनुरूप है) मान रखने के लिए अपडेट किया जाता है। उसके बाद का अपडेट और जाँच लगभग अनावश्यक है, जो कुछ अप्रत्याशित त्रुटियों का कारण बन सकता है।

# बुनियादी स्तर पर शोषण

Zecops द्वारा भेद्यता प्रदर्शित करने के लिए उपयोग किया गया संदेश संरचना [SMB2 WRITE संदेश](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8) है। इस संरचना में लिखे जा सकने वाले बाइट्स की संख्या, फ्लैग, आदि जैसे फ़ील्ड शामिल हैं, जिसके बाद एक मनमानी लंबाई का बफर होता है। यह भेद्यता का शोषण करने के लिए काफी उपयुक्त है, क्योंकि हम एक संदेश बना सकते हैं और हेडर निर्दिष्ट कर सकते हैं, जिसमें एक बफर हो जिसमें अप्रारंभित डेटा हो।

माइक्रोसॉफ्ट के WindowsProtocolTestSuites रिपॉजिटरी पर [Zecops](https://blog.zecops.com/) के POC के आधार पर, इस पर बेहतर समझ पाने के लिए, हम कंप्रेशन फ़ंक्शन में यह छोटा सा जोड़ जोड़ेंगे:``` c
// HACK: fake size
if (((Smb2SinglePacket)packet).Header.Command == Smb2Command.WRITE)
{
    ((Smb2WriteRequestPacket)packet).PayLoad.Length += 0x1000;
    compressedPacket.Header.OriginalCompressedSegmentSize += 0x1000;
}

ध्यान दें कि यह POC प्रमाणीकरण और लेखन अनुमति साझा करने की आवश्यकता है, जो अक्सर कई मामलों में उपलब्ध होता है। हालांकि, त्रुटि रिटर्न सभी संदेशों पर लागू होगी (प्रमाणीकरण के साथ या बिना प्रमाणीकरण वाले संदेश सहित), इसलिए संभावना है कि हम बिना प्रमाणीकरण के भी शोषण कर सकते हैं। एक और बात यह है कि हम जो मेमोरी लीक करेंगे वह NonPagedPoolNx में पिछले आवंटन से है और क्योंकि हम आवंटन आकार को नियंत्रित कर सकते हैं, हम कुछ हद तक उस डेटा को नियंत्रित कर सकते हैं जिसे हम लीक करेंगे।

SMBleed POC Source Code

तो यदि प्रमाणीकरण जानकारी नहीं है तो क्या कर्नेल पता लीक किया जा सकता है? इस प्रश्न का उत्तर देने के लिए, आइए SMB का और गहराई से विश्लेषण करें।

SMB में गहराई से

जब प्रमाणीकरण जानकारी प्रमाणित होती है, तो क्लाइंट निम्नलिखित संदेश भेजता है:

SMB2 NEGOTIATE → SMB2 SESSION_SETUP → SMB2 SESSION_SETUP

यदि प्रमाणीकरण जानकारी गलत है, तो दूसरे SMB2 SESSION_SETUP पैकेट के बाद सत्र समाप्त हो जाएगा:

मान लीजिए कि हमारे पास प्रमाणीकरण जानकारी नहीं है, हम जांच करेंगे कि क्या कोई ऐसा कमांड है जिसे बिना प्रमाणीकरण के भेजा जा सकता है। खोज करने पर, हम पाते हैं:

पहला कमांड जो भेजा जाना चाहिए वह SMB2 NEGOTIATE है और यह एक सत्र में एकमात्र SMB2 NEGOTIATE कमांड है।
अगले कमांड, जब तक सफल प्रमाणीकरण नहीं हो जाता, SMB2 SESSION_SETUP होना चाहिए।

इसमें SMB2 NEGOTIATE संदेश संपीड़ित नहीं होगा। बग डीकंप्रेसन फ़ंक्शन में है, इसलिए हम इस पर विचार नहीं करेंगे बल्कि केवल SMB2 SESSION_SETUP संदेशों पर विचार करेंगे।

CVE-2020-1206

सबसे लोकप्रिय

SMB में गहराई से