هذا الأسبوع في الأمان: Git Deep Dive و Mailchimp و SPF

أول ما يصل ، تم تدقيق بوابة. كان هذا جهدًا رعته مؤسسة Open Source Technology Improvement Fund (OSTIF) ، وهي منظمة غير ربحية تعمل على تحسين أمان مشاريع المصادر المفتوحة. تم إجراء التدقيق نفسه بواسطة باحثين من X41 و GitLab و تم العثور على اثنين من نقاط الضعف الحرجة، كلاهما ناتج عن نفس عادة التشفير السيئة - باستخدام امتداد int لعقد أطوال العازلة.

في الأنظمة الحديثة ، أ size_t دائمًا بدون إشارة ، وبنفس طول البت مثل عرض بت العمارة. هذا هو نوع البيانات المناسب لأطوال السلسلة والمخزن المؤقت ، حيث يضمن عدم تجاوزه عند التعامل مع أطوال تصل إلى الحد الأقصى للذاكرة القابلة للعنونة على النظام. من ناحية أخرى ، فإن ملف int عادةً ما يكون طوله أربعة بايت وموقع ، بحد أقصى 2 ^ 31-1 ، أو 2147483647 - حوالي 2 جيجابايت. مخزن مؤقت كبير ، ولكن ليس كمية غير معروفة من البيانات. قم برمي شيء بهذا الحجم في git ، وسوف ينكسر بطرق غير متوقعة.

مثالنا الأول هو CVE-2022-23521 ، وهي كتابة خارج الحدود ناتجة عن ملف int يفيض إلى سلبي. أ .gitattributes يمكن ربط الملف بمستودع مع عميل git معدل ، ومن ثم فإن التحقق من هذا المستودع سيؤدي إلى ظهور ملف num_attrs متغير لتجاوز. ادفع الفائض على طول الطريق إلى رقم سلبي صغير ، وسيقوم git بعد ذلك بتقليل تخصيص المخزن المؤقت للسمات بشكل كبير ، وكتابة كل تلك البيانات بعد نهاية المخزن المؤقت المخصص.

CVE-2022-41903 هو تجاوز آخر لعدد صحيح موقّع ، هذه المرة عندما يتم إساءة استخدام تنسيق طباعة جميل لفعل شيء غير متوقع. ألق نظرة على هذا الجزء من التعليمات البرمجية:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

سيبدو شكل الاستغلال شيئًا مثل %>(2147483647)%a%>(2147483646)%x41، حيث يتم تشغيل الكود أعلاه لكل مثيل حشو (ملف %>(#) كتل) الموجودة بالتنسيق. تضيف المرة الأولى من خلال هذا الرمز (2 ^ 31) -1 مسافات إلى مقدمة سلسلة الإخراج. يصادف أن يكون هذا الرقم هو القيمة القصوى لعدد صحيح مكون من أربعة بايت. ولكن يتم تشغيل كتلة التعليمات البرمجية أعلاه مرة أخرى ، ومرة ​​أخرى تتم إضافة نص إلى المخزن المؤقت ، مما يؤدي إلى زيادة طوله فوق قيمة العدد الصحيح القصوى. السطر الأول من تلك الكتلة يلقي ضمنيًا من size_t إلى int، ضبط sb_len to a negative value.

ثم في memcpy() مكالمة، sb->buf هو مؤشر لبداية المخزن المؤقت ، و sb_len هو رقمنا السالب الكبير الفائض ، وستكون الإزاحة قيمة يتحكم فيها المستخدم. هذا يعني موقع الوجهة المرسلة إلى memcpy() يمكن تعيينها عن غير قصد إلى موقع ذاكرة أقل من بداية المخزن المؤقت المقصود. يتحكم المهاجم في الكتابة. لقد أضفت بعض عبارات تصحيح الأخطاء printf () إلى كتلة النص هذه ، وقمت بتشغيل حالة اختبار:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

الرباعية الأولى من النواتج هناك هي الإعداد ، وتهيئة سطر السجل بالحشو ليكون أقصى طول. الرباعية الثانية هي تجاوز المخزن المؤقت ، حيث sb_len يتم تعيينه إلى سالب ، ثم يضاف إلى الإزاحة ليعطينا موقعًا يبلغ 56 بايت على يسار بداية المخزن المؤقت. المحتوى الذي يتم طباعته إلى هذا الموقع هو في هذه الحالة %s، والذي يتم استبداله بسطر موضوع الالتزام - بطول 44 بايت. يقترح المؤلفون أنه يمكن تسليح هذا ضد "git forge" و AKA GitHub و GitLab ، حيث تقوم مجموعات البرامج هذه بتشغيل أمر أرشيف git ، والذي يمكن أن يستدعي سلسلة جميلة يتحكم فيها المستخدم.

تم دفع الإصلاحات إلى كود مصدر git مرة أخرى في الثامن من ديسمبر ، ولكن الإصدارات الجديدة التي تحتوي على تلك الإصلاحات متاحة الآن. هناك ما يقرب من 8 حالة من الخام int المشكلة ، وسيستغرق تنظيفها بعض الوقت ، حتى مع بعض الاختراقات الممتعة مثل cast_size_t_to_int()، وظيفة مضمنة تقتل البرنامج فقط إذا كان 2 غيغابايت + size_t تتم معالجة. لذا اذهب للتحديث!

Mailchimp - مرة أخرى

يبدو أن الأشخاص في Mailchimp لا يمكنهم الحصول على قسط من الراحة ، مثل تم الوصول إلى أدوات الإدارة الداخلية الخاصة بهم مرة أخرى من قبل المهاجمين، مما أدى إلى تعرض 133 حساب عميل ، بما في ذلك WooCommerce. هذه هي المرة الثالثة التي يقع فيها Mailchimp في هجوم الهندسة الاجتماعية أو التصيد الاحتيالي في العام الماضي ، وفي كل مرة يتم إرسال رسائل بريد إلكتروني تصيد بالرمح إلى المستخدمين النهائيين. لذلك إذا كنت في أي قوائم بريدية في Mailchimp ، فضع هذا الخرق في الاعتبار في المرة القادمة التي تصل فيها رسالة بريد إلكتروني ذات صلة. (ملاحظة المحرر: النشرة الإخبارية من Hackaday تستخدمان Mailchimp ، ولم يتم إخطارنا ، لذلك نعتقد أننا جيدون).

برنامج Royal Mail Ransomware

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

مسح سجلات SPF

[سيباستيان سالا] لديه ما يمكن اعتباره هواية غريبة ، في شكل مسح سجلات نظام التعرف على هوية المرسل (SPF) بحثًا عن التكوينات الخاطئة الفردية. في مغامرته الأخيرة ، كان هذا المسح هو أكثر 3 ملايين نطاق زيارة. وتم العثور على تكوين خاطئ.

لكن انتظر ، ما هو عامل الحماية من الشمس (SPF) ولماذا نهتم به؟ إطار عمل سياسة المرسل هو سجل txt وهو جزء من سجلات DNS الخاصة بالمجال. ويحدد عناوين IP المصرح لها بالفعل بإرسال بريد إلكتروني لهذا المجال. لذلك إذا ادعى بريد إلكتروني وارد أنه من مجال به سجل صالح لنظام التعرف على هوية المرسل (SPF) ، ولم يكن عنوان IP للإرسال موجودًا في هذا السجل ، فمن الواضح أنه ليس من النطاق المطالب به حقًا.

ورفض رسائل البريد الإلكتروني الخاصة بنطاقك بسبب مشكلة SPF هي واحدة من أكثر الطرق المضمونة للقبض على flak. لذلك من المغري جعل سجل SPF أكثر ... * ليبراليًا * مما ينبغي أن يكون. وأكبر تكرار لهذا هو مجرد صفع أ +all في سجل نظام التعرف على هوية المرسل (SPF) الخاص بك وانتهى منه. بالتأكيد ، يخبر العالم أن كل مرسل بريد عشوائي في أي مكان يستخدم نطاقك يرسل بالفعل رسائل بريد إلكتروني حقيقية ، ولكنه على الأقل يجعل رسائل البريد الإلكتروني الصادرة لرئيسك تعمل مرة أخرى. مع تعيين أكثر من ألف مجال على SPF +all، يبدو أن هذا خطأ شائع أكثر مما كان متوقعًا.

الشيء المثير للاهتمام حقًا هو تحديد هوية تلك المجالات التي تم تكوينها بشكل خاطئ ، مثل العديد من الوكالات الحكومية الأمريكية ، والمجالات الحكومية الأخرى حول العالم ، والجامعات المتعددة. كانت وزارة الدفاع الأوكرانية الأكثر إثارة للاهتمام ، حيث تم قطع سجل SPF من a -all إلى +all منذ حوالي 4 أشهر.

بت وبايت

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

• نواة لينكس لديها تجاوز سعة المخزن المؤقت في كود Netfilter الخاص به ، حيث يمكن أن يؤدي تجاوز سعة المخزن المؤقت إلى تسرب البيانات وتنفيذ التعليمات البرمجية. لا يوجد مسار للاستغلال عن بُعد ، لكن البريد الإلكتروني المرتبط أعلاه يحتوي على PoC كامل لتصعيد الامتياز المحلي. وإذا كان استغلال Kernel هو الشيء الذي تفضله ، فإن Project Zero من Google يمتلكه كتابة جديدة حول هذا الموضوع، كل شيء عن الإسناد الفارغ.

وإذا كنت تستخدم ManageEngine من Zoho ، فقد يكون شعرك مشتعلًا اليوم ، إذا لم تقم بالتحديث إلى الإصدار الذي يعمل على إصلاح CVE-2022-47966. الباحثون في Horizon3 لهندسة عكسية التصحيح، وسكب الفول على هذا RCE. إنها مشكلة تتعلق بكيفية تنفيذ تسجيل الدخول الأحادي SAML ، ويرجع ذلك جزئيًا إلى مكتبة قديمة للغاية تم تجميعها كجزء من المنتج. إنها استغلال سهل للغاية ، لذا حان الوقت للتحقق مرة أخرى من هذه التثبيتات!

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. الوصول هنا.
• المصدر https://hackaday.com/2023/01/20/this-week-in-security-git-deep-dive-mailchimp-and-spf/