MSMQ QueueJumper (ثغرة في RCE): تحليل فني متعمق

عالجت التحديثات الأمنية التي أصدرتها Microsoft في 11 أبريل 2023 أكثر من 90 نقطة ضعف فردية. وتجدر الإشارة بشكل خاص إلى CVE-2023-221554، التي يطلق عليها اسم QueueJUMP، وهي ثغرة أمنية لتنفيذ التعليمات البرمجية عن بُعد وتؤثر في خدمة Microsoft Message Queueing (MSMQ) MSMQ هو مكون اختياري لنظام Windows يمكن التطبيقات من تبادل الرسائل عبر قوائم انتظار رسائل يمكن الوصول إليها محلياً وعن بعد. تم إجراء هذا التحليل بالتعاون مع فريقي Randori وX-Force Adversary Services، بواسطة Valentina Palmiotti وFabius Watson وAaron Portnoy.

جذبت الصفات التالية لـ CVE-2023-21554 الانتباه الأولي:

• نظرا لتفاوت استخدام قوائم انتظار MSMQ من قبل التطبيقات التابعة لجهات خارجية، هناك تحديات في تحديد مدى تأثير الثغرات بين البيئات وعبرها.
• وصفت التقارير الأولية 360000 مضيف يمكن الوصول إليه عبر الإنترنت مع تعرض خدمة MSMQ للخطر. عرضت شركة Consulting Shodan في ذلك الوقت 250 دولارًا فقط. وقد أدى هذا التناقض إلى جعل مدى التعرض المحتمل أقل وضوحًا.
• يتم تصنيف الثغرة الأمنية على أنها تنفيذ تعليمة برمجية عن بُعد لا يتطلب مصادقة ويؤثر ذلك أيضًا على مجموعة واسعة من منصات Windows.
• المطلب الواضح الوحيد هو أن يمكن الوصول إلى الخدمة على منفذ TCP 1801.

لتحديد كيفية اكتشاف وجود MSMQ، تم تكوين نظام اختبار مع العنصر في بيئة معملية. عند الاتصال بنقطة نهاية MSMQ على المنفذ 1801، لم يستجب الخادم بأية بيانات. يمكن افتراض أن الخادم لن يرد دون تلقي بيانات تم تكوينها بشكل معقول. لفهم كيفية إجراء محادثة مع نقطة النهاية، كان يجب إجراء فحص أعمق للتعليمات البرمجية الأساسية.

ومن الاستشارة، لم يتضح على الفور أي ثنائي تم تصحيحه. كانت الخطوة الأولى لتحديد الرمز الذي تم تغييره هي تنزيل ملف التحديث. وقد تحقق ذلك من خلال البحث عن KB5025224 في كتالوج Microsoft Update.

نتائج البحث في كتالوج تحديثات Microsoft لـ KB5025224

وعلى وجه التحديد، ملف التحديث التراكمي 

windows10.0-kb5025224-x64_3522b1b562ed44bc949541dd1c7d08e1e967d925.msu 

لنظام التشغيل Windows 11 للأنظمة المستندة إلى x86 تم استرجاعه.

تم استخدام أداة استخراج 7-Zip لفك ضغط محتويات ملف MSU وملفات CAB التي يحتوي عليها. أسفر البحث عن السلسلة "msmq" عبر جميع الملفات في المجلدات الناتجة عن ملف فهرس الحاوية، 

Windows11.0-KB5025239-x64/express.psf.cix.xml,

والتي تضمنت الإدخال التالي:

<File id = "21296" name = "amd64_mic Microsoft-Windows-MSmq-queuEMANAGER-core_31bf3856ad364e35_10.0.22621.1555_none_5f975f8fdb349517 \ f \ mqqm.dll" length="34811" time="133245266510000000" attr="128">

يشير هذا الإدخال إلى MQQM.dll ، وقد تم تحديده هدفًا لمزيد من التحليل.

لتحديد التغييرات بين الإصدار المصحح وغير المصحح من الملف MQQM.dll، استُخدمت أداة BinDiff من Zynamics. تظهر الصورة التالية الدوال المتطابقة ذات درجة التشابه أقل من1.00 :

نتائج BinDiff بين ملفات MQQM.dll المصححة وغير المصححة 

وكشف تحليل هذه الدوال باستخدام Hex-Rays Decompiler عن رموز للنسخة المصححة تحتوي على أسماء دوال مطولة يبدو أنها تشير إلى معرّفات الثغرات الأمنية لمركز البحث الأمني لشركة Microsoft (MSRC):

رموز علامات الميزات داخل MQQM.DLL

بعد الفحص الدقيق، تتوافق الرموز التي تحتوي على أرقام حالات MSRC مع علامات ميزات للإصلاحات. علامات الميزات هي عنصر من نظام Windows يقوم بتبديل الوظائف والتجارب المختلفة. هنا، "الميزة" المكتشفة هي في الواقع تصحيح لثغرة. إذا تم تفعيل الميزة، يتم تنفيذ مسار الرمز الآمن والمصحح. وإلا، يتم تنفيذ مسار الرمز الأصلي غير المصحح.

مقتطف من التعليمات البرمجية تم فك تشفيره يعرض علامة ميزة لإصلاح الثغرات الأمنية

كان هناك فحص للميزة لكل ثغرة تشكل CVE-2023-21554 في كل من مكونات المستخدم و مكونات النواة. كشف تحليل الملفات الثنائية المتبقية الموجودة في حزمة تحديث الأمان أن علامات الميزات تم إدخالها أيضا لمعظم أو جميع الثغرات التي تم إصلاحها في تحديث أبريل 2023 يوم الثلاثاء.

ساعدتنا الإشارة المرجعية إلى هذه العلامات على تحديد مواقع التعليمات البرمجية المصححة بسرعة. وعلى وجه الخصوص، بدت التغييرات داخل CQmPacket::CQmPacket المتعلقة بعلم MSRC76146_MSMQ_OOBRWF ixes الأكثر أهمية.

يتم إجراء فحص لعلامة الميزة هذه ثماني مرات داخل الوظيفة. نوضح أدناه أحد هذه الفحوصات:

مقتطف من الرمز البرمجي مفكك التجميع يُظهر إصلاح الثغرة الأمنية 

في مقتطف التعليمات البرمجية المفككة الموضحة أعلاه، يحصل مسار التعليمات البرمجية المصححة على المؤشر إلى القسم التالي من رسالة MSMQ عبر استدعاء GetNextSectionPtrSafe. أما في المسار غير المصحَّح، فيُستخرج المؤشر ببساطة بإضافة حجم القسم من دون أي فحوصات. تتحقق الدالة الجديدة GetNextSectionPtrSafe  من أن المؤشر المحسوب إلى القسم التالي من الحزمة لا يتجاوز طول الحزمة نفسها.

مقتطف فك التجميع لوظيفة GetNextSectionPtrSafe

بعد فحص جميع تكرارات علامة الميزة هذه وغيرها، تم تحديد أن CVE-2023-21554 تتكون من عدة أخطاء لا تتحقق بشكل كافٍ من حجم مختلف أنواع أقسام رسائل MSMQ. وتتيح هذه الثغرات الأمنية زيادة المؤشر إلى نهاية رسالة MSMQ بإزاحة عشوائية مكونة من 32 بت إلى خارج حدود المخزن المؤقت المخصص في الأصل.

بعد معالجة الحزمة، تقوم الخطوة الأخيرة في  CQmPacket::CQmPacket بإلحاق OnDiskExtensionHeader بنهاية مخزن البيانات المؤقت. وبسبب الثغرات المذكورة أعلاه، قد يشير المؤشر المحسوب لنهاية الرسالة إلى موقع خارج النطاق. وبالتالي، قد يؤدي إلحاق OnDiskExtensionHeader إلى عدة عمليات كتابة خارج النطاق. توضح التعليمات البرمجية المفككة التي تم فك تشفيرها أدناه فحصًا مصححًا لمؤشر نهاية الرسالة المعرّض للثغرة قبل حدوث عمليات الكتابة خارج النطاق:

التحقق من وصول الذاكرة خارج الحدود لنهاية الرسالة

أثناء تقييم قابلية استغلال الثغرات، تم تحديد ثغرات إضافية في برنامج تشغيل النواة المقابل لخدمة MSMQ، وهو mqac.sys . وتمت الإشارة إلى الثغرات مرة أخرى عبر رموز علم ميزات، وتشير هذه الرموز أيضًا إلى حالة MSRC رقم 76146 كما لوحظ في MQQM.dll .

رموز علامات الميزات داخل mqac.sys

كشف تحليل علم الميزات (Feature Flag)KernelVariants أن الثغرات المقابلة تماثل الثغرات الموجودة في مكوّن مساحة المستخدم. يشارك مكون النواةmqac.sys  في العمليات المختلفة لخدمة MSMQ مثل إعادة توجيه الرسائل إلى قوائم الحروف الميتة، وإرسال رسائل التأكيد، وإدارة الذاكرة لمخازن حزم MSMQ.

لأداء العمليات المرتبطة، يقوم العنصر بتحليل أقسام مختلفة من مخزن الحزم في MSMQ. تم تصوير حالتين من هذه الحالات أدناه:

مقتطف الرمز البرمجي المفكك يعرض علامة ميزة لإصلاح الثغرات في برنامج تشغيل النواة mqac.sys

كما هو موضح في مقتطف التعليمات البرمجية المُفككة أعلاه، إذا تم تفعيل أعلام الميزات، يتم استدعاء الدوال "الآمنة" CPacketBuffer::MsgDeadletterHeaderSafe  و CPacketBuffer::MsgOnDiskExtensionHeaderSafe  لاسترداد الترويسة المقابلة من مخزن الحزمة. وإذا لم يكن مفعّلًا، يتم استدعاء الدوال "غير الآمنة" التي لا تتضمن فحوصات كافية لحجم القسم.

توجد غالبية التعليمات البرمجية المتعلقة بتحليل البروتوكول داخل مكتبة MQQM.dll التي يتم تحميلها من خلال العمليةmqsvc.exe . للوصول إلى التعليمات البرمجية المشار إليها بواسطة MSRC76146_MSMQ_OOBRWFixes يجب إرسال طلب MSMQ صالح من العميل. مواصفة رسائل MSMQ والبروتوكول واسعة ومعقدة. في البداية، عُثر على تعليمات برمجية متاحة علنًا لفحص خوادم MSMQ ضمن GitHub gist، وقد شكّلت أساسًا لاستكشاف أعمق لمعالجة الحزم. إضافة إلى ذلك، كانت وثائق Microsoft مفيدة لفهم تنسيق رسائل MSMQ.

تقبل التعليمات البرمجية الموجودة داخل DLL البيانات من خلال المنفذ 1801 باستخدام استدعاء وظيفة WSARecv، كما هو موضح في جلسة تصحيح الأخطاء أدناه:

0:020> bp ws2_32!wsarecv ; g

نقطة توقف 0 ضربة

WS2_32!WSARecv:

00007ffd`651115c0 48895c2408      mov     qword ptr [rsp+8],rbx ss:000000aa`f07fef30=0000000000000006

0:019> k

# موقع مكالمات Child-SP Retaddr

00 000000aa`f07fef28 00007ffd`57ba9cb0     WS2_32!WSARecv

01 000000aa`f07fef30 00007ffd`57b9683d    

MQQM!NoReceivePartialBuffer+0x38

02 000000aa`f07fefb0 00007ffd`57b2078e     MQQM!CWinsockConnection::ReceivePartialBuffer+0x7d

03 000000aa`f07ff010 00007ffd`57b25b28    

MQQM!CSockTransport::BeginReceive+0xe6

04 000000aa`f07ff060 00007ffd`57b2d40b    

MQQM!CSockTransport::NewSession+0x194

05 000000aa`f07ff3f0 00007ffd`57b2d367     MQQM!CSessionMgr::AcceptSockSession+0x6f

06 000000aa`f07ff430 00007ffd`645e26bd     MQQM!AcceptIPThread+0x6a7

07 000000aa`f07ff7d0 00007ffd`6650a9f8    

KERNEL32!BaseThreadInitThunk+0x1d

08 000000aa`f07ff800 00000000`00000000     ntdll!RtlUserThreadStart+0x28

0:019> r @$t0=@rdx

0:019> pt

WS2_32!WSARecv+0x19f:

00007ffd`6511175f c3              ret

0:019> dc poi(@$t0+8) LC

000001b5`880ff490  62f06110 524f494c 00000070 5a5a5a5a  .a.bLIORp…ZZZZ

000001b5`880ff4a0  0073006e 00610074 0063006e 00200065  n.s.t.a.n.c.e. .

000001b5`880ff4b0  00440049 00000000 00000000 00000000 معرف………….

0:019> ba r1 poi(@$t0+8) ; g

Breakpoint 1 hit

MQQM!CBaseHeader::SectionIsValid+0x154:

00007ffd`57b53450 7462            je     

MQQM!CBaseHeader::SectionIsValid+0x1b8 (00007ffd`57b534b4) [br=1]
 

الدالة CBaseHeader::SectionIsValid مسؤولة عن تحليل بداية رسالة جديدة، والتي تبدأ ببنية BaseHeader على الصورة التالية:

بنية كائن BaseHeader

يتم التحقق من صحة حقول الرسالة الواردة بواسطة SectionIsValid قبل أن يرسل الخادم استجابة:

تعليمات فك التجميع لدالة SectionIsValid ضمن MQQM.dll 

بعد التحقق الأولي ، يحدث معظم تحليل البروتوكول داخل دالة المنشئCQmPacket:: CQmPacket . لاستغلال ثغرة CVE-2023-21554، يمكن إرسال رسالة MSMQ تتضمن عنوان قسم مُشوّهًا يجري التعامل معه على نحو غير صحيح. يوضح المثال التالي تفاصيل استغلال ثغرة أمنية باستخدام EodHeader لقسم Eod (exactly-once-delivery).

فك الترجمة (decompilation) يبيّن ثغرة في التعامل مع EodHeader

يوضح فك الترجمة أعلاه أن المسار المصحح يستدعي الدالّة المسماةCEodHeader::GetNextSectionSafe. T . أما المسار غير المصحح فيكتفي بعملية جمع مؤشرات مستخدمًا القيم الموجودة داخل ترويسة، لحساب بداية القسم التالي.

لم يتم توثيق بنيةEodHeader  ؛ تم تحديد بت العلم (flag bit) الذي يشير إلى وجودEodHeader فيUserHeader على أنه موصوف في وثائق Microsoft بأنه “محجوز” (reserved)، وتنص الوثائق على أن بت العلم يجب ألا يتم تعيينه عند الإرسال. إلقاء نظرة على فك التجميع قد يعطي رؤى حول بنية الترويسة:

تعليمات فك التجميع التي تحسب الحجم الإجمالي لقسم EodHeader

في عملية التفكيك أعلاه، يشير المؤشر إلى بداية EodHeader يتم تحميلها في المسجل rdx . يمكن افتراض أن الحقلين الأول والثاني من الترويسة يصفان أحجام أعداد صحيحة (حجم الترويسة وحجم البيانات، أو ما يشبه ذلك). يشير مجموع هذين الحجمين مع 0xF  إلى الحجم الإجمالي لقسم Eod بالبايتات. من خلال إرسال رسالة تحتوي على EodHeader تُضبط حقول الحجم المقابلة فيها على قيم كبيرة، يتم استثارة كتابة خارج النطاق. هذا يسبب انتهاكا في الوصول عند كتابة OnDiskExtensionHeader  إلى ما يعتقد البرنامج أنه نهاية الرسالة:

جلسة WinDbg تُظهر انتهاك وصول عند الكتابة في نهاية رسالة MSMQ مُشوّهة

ولتقييم مدى قوة الكتابة خارج الحدود الناتجة عن هذه الثغرات، بدأنا أولًا بدراسة كيفية تخصيص الذاكرة الأساسية وإدارتها.

قبل معالجة حزمة رسائل MSMQ تُنسخ محتوياتها إلى مخزن مؤقت يُخصَّص داخل الدالة QmAcAllocatePacket . تستدعي هذه الدالة mqac.sys برنامج تشغيل النواة عبرNtDeviceIoControl.

فك الترجمة لدالة تخصيص المخزن المؤقت للحزم

يعيد مكوّن النواة مخزنًا مؤقتًا مُقتطعًا من عرض مُعيّن (mapped view) لملف على القرص، مخزَّنًا في الدليلC:\Windows\System32\msmq\storage  وبامتداد.mq  . يمكن لكل ملف استيعاب ما يصل إلى 4MB، وقد يتضمن رسائل من قوائم انتظار متعددة.

تخطيط ذاكرة ProcessHacker لعملية MQSVC الذي يعرض ذاكرة المخزن المؤقت للحزم عبارة عن تعيين للملفات

يُعاد إلى مساحة المستخدم عنوان مخزن الحزمة المؤقت، إلى جانب مُعرّف حزمة عشوائي، بعد تنفيذ طلب التخصيص عبر IOCTL. ويستخدم برنامج التشغيل هذا المُعرّف لحساب عنوان مخزن الحزمة المؤقت عند معالجة الطلبات الواردة من مساحة المستخدم.

تقع الذاكرة الداعمة للمخازن المؤقتة المعرضة للثغرة داخل ملف مُعيّن (mapped file)، وبالتالي لا تكون ضمن heap الخاصة بالعملية. كما أن الذاكرة المتأثرة لا تخزّن أي كائنات. لا يتضمن تعيين الملف سوى محتوى رسائل MSMQ، إلى جانب بيانات وصفية مخزنة في OnDiskExtension.

وعلاوة على ذلك، من دون معرفة مسبقة بتخطيط الذاكرة، لا يمكن تحديد الموضع النسبي لتعيين الملف ضمن heap الخاصة بالعملية، وبالتالي لا يمكن الاعتماد على الكتابة فوق مؤشرات الكائنات. لذلك، ولتحقيق تنفيذ تعليمات برمجية عن بُعد بصورة عملية، نحتاج إلى طريقة لتشكيل الذاكرة بحيث تصبح في موضع يمكن التنبؤ به.

بعد تجربة إرسال رسائل MSMQ صحيحة إلى النظام المستهدف، تبيّن أنه يمكن فرض تخصيص بنية heap جديدة بمحاذاة تعيين ملف .mq عبر إغراق النظام بعدد كبير من الرسائل. تُكتب الرسائل في الذاكرة بالتتابع عند استلامها، وباستخدام خاصية رسالة MSMQ TimeToBeReceived يمكن ضبط توقيت تحرير رسائل محددة بدقة.

تخطيط الذاكرة لعملية MQSVC يوضح تخصيص heap جديدة بمحاذاة تعيين ملف MQ.

ومع ذلك، يتطلب هذا أن يمتلك المهاجم صلاحية إرسال رسائل إلى قائمة انتظار واحدة على الأقل على النظام المستهدف؛ وإلا فسيتم تجاهل الرسائل والكتابة فوقها، وبالتالي لن تشغل ذاكرة الحزم بشكل دائم.

وخلال التجارب البحثية، تبيّن أنه يمكن لمستخدم بلا امتيازات إنشاء قائمة انتظار تسمح لأي شخص بإرسال رسائل إليها عن بُعد افتراضيًا. وتظل قائمة الانتظار موجودة على النظام إلى أجل غير مسمى. ورغم أن معظم استخدامات MSMQ الحديثة تأتي في صورة مكونات ومحولات اختيارية، فإن مورّدين مثل Oracle وVeritas وXerox يقدمون برمجيات مؤسسية تعتمد على MSMQ كاعتمادية أساسية. لذلك، فإن سيناريو الهجوم ليس مستبعدًا.

تُدخل ثغرة الوصول إلى الذاكرة خارج الحدود ركيزة للاستغلال تتيح
لعميل ضارّ أن يكتبOnDiskExtensionHeader خارج حدود الذاكرة
المخصصة للحزمة.

عند تقييم ثغرة تسمح بكتابة قيم عند إزاحة معيّنm،
يجب مراعاة بعض الخصائص:

• هل يمكن التحكم في التعويض
• هل يمكن التحكم في القيم التي تتم كتابتها

في حالة ثغرات QueueJumper، يمكن التحكم في الإزاحة بين المخزن المؤقت المخصّص وكتابة OOB، لأن هذه الإزاحة تُحسب باستخدام بيانات يتحكم فيها المهاجم. ومع ذلك ، فإن محتويات OOB الكتابة لها تحكم محدود.

وهنا، يمثلAddress المؤشر التالف إلى نهاية رسالة الحزمة حيث ستُكتب ترويسة الرسالة OnDiskExtension . سلسلة العمليات التي تحدث هي كما يلي:

• تُكتب القيمة 0x000000000000000C فيAddress
• تُكتب القيمة0x00000000 فيAddress+0x2
• تُكتب القيمة0x0000000000000000 فيAddress+0x12
• تُكتب القيمة 0x0000000000000000 في Address+0x1A
• تُكتب القيمة 0x00000094 في Address+0xE
• القيمة0x0000 مكتوبةAddress+0x22
• تُكتب القيمة 0x0000 في Address+0x62
• memcpy(Address+0xA6, Source, Source->AddressLength+0x08)

يشيرSource المستخدم في استدعاءmemcpy إلى كائن TA_ADDRESS. تحدد البنية TA_ADDRESS عنوان نقل واحدًا من نوع محدد (مثل NetBIOS). التعريف كما يلي:

typedef struct _TA_ADDRESS {

    USHORT AddressLength;;

    USHort AddressT type؛ معلومات؛

    UCHAR Address[1];;

} TA_ADDRESS, *PTA_ADDRESS;

AddressLength

يحدد عدد وحدات البايت في عنوان من النوع المحدد AddressType.

AddressType

يحدد نوع عنوان النقل.

Address

يحدد مصفوفة متغيرة الحجم تحتوي على عنوان النقل.

في جلسة تصحيح الأخطاء أدناه، يحتويTA_ADDRESS على بيانات متأثرة بالمخترق في شكل عنوان IP:

rax=0000014e1d110180 rbx=0000014e1d110180 rcx=0000014e1d110184

rdx=0000014e1ce86b10 rsi=0000014e1d110001 rdi=0000000545d7fa50

rip=00007ff843208074 rsp=0000000545d7f940 rbp=0000000545d7f980

r8=000000000000000c  r9=0000000000000002 r10=0000000000000000

r11=00000000545d7f938 r12=0000000000000002 r13=0000000000001000

r14=0000014e1ce86b10 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206

MQQM!CQmPacket::CQmPacket+0x89c:

00007ff8`43208074 e8a5780a00      call    MQQM!memcpy (00007ff8`432af91e)

0:017> dc rcx

0000014e`1d110184  00010004 00000000 8620a8c0 00000000  ………. …..
 

أعلاه، يبلغ طول الكائنTA_ADDRESS قيمة 4 ونوعه1 ، وقيمته 0x8620a8c0 . عند تحويل كل بايت إلى ثماني بتات IPv4 ينتج العنوان 192.168.32.134 وهو عنوان مصدر IPv4 للعميل.

يتيح هذا السيناريو كتابة بيانات يتحكم فيها المهاجم من خلال عنوان المصدر إلى إزاحة محكومة انطلاقًا من موضع تخصيص الحزمة في الذاكرة. ورغم أن ذلك شديد التقييد وقد يكون غير عملي، فإنه من الناحية النظرية قد يُستخدم للتحكم بدقة في القيم المكتوبة في الذاكرة عبر إرسال طلبات متعددة من عناوين مصدر مختلفة، مع خفض إزاحات الحزم تدريجيًا.

ونظرًا لكثرة القيود التي واجهناها لتحقيق تنفيذ تعليمات برمجية عن بُعد دون رؤية، جرى بحث سيناريوهات هجومية بديلة مثل تسرب المعلومات.

ومن السيناريوهات التي جرى النظر فيها إفساد المؤشر الخاص بقسم محدد من الرسالة بحيث يشير إلى ذاكرة خارج الحدود، ثم استرجاع الرسالة لاحقًا لقراءة الذاكرة المجاورة.

ومع ذلك، فإن بداية عملية تحليل كل قسم تتضمن فحصًا لموقع القسم الحالي؛ ومن ثَمَّ لا يمكننا خداع منطق التحليل لجعله يعالج قسمًا من البيانات يقع خارج الحدود.

وسيناريو آخر محتمل هو الكتابة فوق OnDiskExtensionHeader لرسالة أخرى لخداع مستلم الرسالة بشأن مصدر الرسالة المستلمة. وبالمثل، قد يكون من الممكن الكتابة فوق محتويات رسائل موجهة إلى قوائم انتظار لا يمتلك المخترق صلاحية الوصول إليها. وتتطلب الكتابة فوق محتوى محدد في رسالة ما أن تتوفر لدى المخترق معلومات عن الرسالة، مثل حجمها.

يوجد قسم اختياري باسم SoapHeader وهو عُرضة لعملية وصول للبيانات خارج الحدود، بالتنسيق التالي:

تنسيق حزمة SoapHeader

لوحظ أن الذاكرة المستخدمة لتخزين بيانات حزم MSMQ لا تُصفَّر بصورة صحيحة عند تحرير المخزن المؤقت. ونتيجة لذلك، يؤدي إرسال حزمة MSMQ أصغر من الحزمة السابقة إلى تخطيط ذاكرة يضم بيانات الحزمة الحالية، تليها بيانات من حزم MSMQ تمت معالجتها سابقًا.

تبيّن أنه يمكن استخدام  SoapHeader لاستغلال هذه الخاصية للكشف عن بيانات من حزم تمت معالجتها سابقًا أو رسائل مخزنة مجاورة. قد يحدد المخترق BodyDataLength بشكل تعسفي ويستبعد قسم Body بالكامل. يؤدي ذلك إلى رسالة MSMQ تتضمن بيانات حساسة محتملة من حزم MSMQ تمت معالجتها سابقًا بوصفها Body ضمن SoapHeader الخاص بالمخترق . يمنع مسار التعليمات البرمجية المصحح هذا السيناريو، لأنه يتحقق من أن بيانات Body تقع ضمن حدود بيانات حزمة MSMQ.

وقد شكّلت محدودية التحكم في محتوى الكتابة—إلى جانب كتابات إضافية غير قابلة للتحكم تُفسد الذاكرة المجاورة، ومعرفة محدودة بتخطيط الرسالة—عائقًا كبيرًا أمام الاستغلال.

وقت التحليل، جرى تقييم الثغرات الأمنية في مساحة المستخدم المرتبطة بالمعالجة الأولية لحزمة رسائل MSMQ فقط من حيث قابلية الاستغلال. قد يكشف تحليل ثغرات متغير نواة عن مسارات إضافية للاستغلال. على سبيل المثال، قد يؤدي تضمين ترويسة مشوّهة إلى الحصول على primitive للكتابة ضمن تعيين ذاكرة نواة لملف .mq. في بعض الحالات، تمنع عمليات التحقق ضمن معالجة مساحة المستخدم نواة من تنفيذ بعض عمليات ما بعد المعالجة.

إضافة إلى ذلك، في متغيرات نواة يمتلك المهاجم تحكمًا مباشرًا أقل في محتوى الرسائل، كما أنه يعمل على تعيين الملف نفسه المستخدم في مساحة المستخدم، وليس ضمن kernel pool (heap). كما تشكل آليات التخفيف مثل KASLR عقبات يصعب تجاوزها عند الاستغلال عن بُعد.

نظرًا لتنفيذ التعليمات البرمجية المصححة، يمكن لعميل بعيد تحديد ما إذا كان النظام قد طبّق التحديث بصورة آمنة. ويمكن القيام بذلك عبر إرسال رسالة MSMQ تستغل الثغرة، لكنها لا تتسبب فعليًا في وصول خارج النطاق، وبذلك لا تتسبب في تعطيل عملية الخدمة. إذا تم تعيين علم HTTP في UserHeader للرسالة، فمن المتوقع وجود SRMPEnvelopeHeader. في التصحيح، يُجرى فحص لتجاوز عدد صحيح على الحقل DataLength بعد ضربه في 2. ويمكن ضبط هذا الطول بحيث يفيض ناتج الضرب إلى رقم صغير يساوي الحجم الفعلي للبيانات.

مقتطف من التعليمات البرمجية المُفككة يُظهر فحص تجاوز عدد صحيح على SRMPEnvelopeHeader DataLength

إذا كان النظام المستهدف مطبقًا عليه التصحيح، تتسبب الثغرة في إطلاق استثناء، فيوقف الخادم معالجة الرسالة، وبذلك لا تُرسل أي استجابة إلى العميل. أما إذا لم يكن مطبقًا عليه التصحيح، فسيعالج الخادم الرسالة بصورة طبيعية ويرسل استجابة.

نظرًا لموضع الذاكرة الداعمة للمخازن المؤقتة المعرّضة للثغرة، يبدو تنفيذ تعليمات برمجية عن بُعد أكثر قابلية للتحقق لمخترق يستطيع إرسال رسائل إلى أي قائمة انتظار على النظام المستهدف. في هذا السيناريو، يمكن تهيئة الكومة بحيث يتم تخصيص بنية heap مجاورة. يشكل التحكم المحدود للغاية في محتوى الكتابة تحديات أمام الاستغلال عن بُعد. بسبب آليات التخفيف مثل ASLR، يجب أيضًا الحصول على تسرب معلومات. قد تحقق عملية كتابة واحدة لثابت (0xC, 0x0 تم الحصول عليه باستخدام الركيزة) إلى كائن ذلك، لكن يجب أن يحتوي الكائن على حقل مفيد بحيث تتحمل الحقول المجاورة التلف الناتج عن عمليات الكتابة الأخرى. إضافة إلى ذلك، يجب أن يستطيع المخترق تخصيص الكائن بصورة يمكن التنبؤ بها، وأن يمتد عمر الكائن طوال مدة الاستغلال، وأن يكون لدى المخترق ما يتيح استثارة إجراء ما من الكائن. خلال هذا البحث، لم يتم العثور على كائنات مناسبة من هذا النوع.

وفي النهاية، نستنتج أنه رغم أن استغلال QueueJumper عن بُعد قد لا يكون مستحيلًا، فإن المتطلبات المذكورة أعلاه تجعل تحقيقه صعبًا. هذا المنشور لا يتناول سوى جانب محدود من مواصفة رسائل وخدمة وبروتوكول شديدة التعقيد. وتستلزم الحاجة إجراء مزيد من أبحاث الثغرات على عمليات كل من مكوّن مساحة المستخدم ومكوّن نواة.