سیکیورٹی میں یہ ہفتہ: گٹ ڈیپ ڈائیو، میلچیمپ، اور ایس پی ایف

سب سے پہلے، git کا آڈٹ کیا گیا ہے۔. یہ اوپن سورس ٹیکنالوجی امپروومنٹ فنڈ (OSTIF) کے ذریعے سپانسر کی گئی ایک کوشش تھی، جو اوپن سورس پروجیکٹس کی سیکیورٹی کو بہتر بنانے کے لیے کام کرنے والا ایک غیر منافع بخش ادارہ ہے۔ آڈٹ خود X41 اور GitLab کے محققین نے کیا تھا، اور دو اہم کمزوریاں پائی گئیں۔, دونوں ایک ہی بری کوڈنگ عادت کی وجہ سے ہوتے ہیں — ایک کا استعمال کرتے ہوئے int بفر کی لمبائی کو پکڑنے کے لئے.

جدید نظاموں پر، a size_t ہمیشہ غیر دستخط شدہ ہوتا ہے، اور فن تعمیر کی بٹ چوڑائی کے برابر لمبائی ہوتی ہے۔ یہ سٹرنگ اور بفر کی لمبائی کے لیے مناسب ڈیٹا کی قسم ہے، کیونکہ سسٹم پر زیادہ سے زیادہ ایڈریس ایبل میموری تک لمبائی کو ہینڈل کرتے وقت اس کی اوور فلو نہ ہونے کی ضمانت ہے۔ دوسری طرف، ایک int عام طور پر چار بائٹس لمبا اور دستخط شدہ ہوتا ہے، جس کی زیادہ سے زیادہ قیمت 2^31-1، یا 2147483647 — تقریباً 2 GB ہوتی ہے۔ ایک بڑا بفر، لیکن ڈیٹا کی ایک غیر سننے والی مقدار نہیں۔ گٹ پر کوئی بڑی چیز پھینک دیں، اور یہ غیر متوقع طریقوں سے ٹوٹ جائے گا۔

ہماری پہلی مثال CVE-2022-23521 ہے، ایک حد سے باہر لکھنے کی وجہ سے int منفی کی طرف بہہ رہا ہے۔ اے .gitattributes فائل کو ایک ترمیم شدہ گٹ کلائنٹ کے ساتھ ذخیرہ کرنے کا پابند کیا جاسکتا ہے، اور پھر اس ذخیرہ کو چیک کرنے سے num_attrs اوور فلو کے لیے متغیر۔ اوور فلو کو چاروں طرف سے ایک چھوٹی منفی تعداد کی طرف دھکیلیں ، اور گٹ اس کے بعد اوصاف کے بفر کو بڑے پیمانے پر کم مختص کرے گا ، اور اس تمام ڈیٹا کو مختص کردہ بفر کے آخر میں لکھے گا۔

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، جہاں اوپر کوڈ ہر پیڈنگ مثال کے لئے چلتا ہے (The %>(#) بلاکس) فارمیٹ میں پائے جاتے ہیں۔ اس کوڈ کے ذریعے پہلی بار آؤٹ پٹ سٹرنگ کے سامنے (2^31)-1 اسپیس شامل کرتا ہے۔ یہ نمبر صرف چار بائٹ کے دستخط شدہ عدد کی زیادہ سے زیادہ قیمت بنتا ہے۔ لیکن اوپر کا کوڈ بلاک ایک بار پھر چلتا ہے، اور ایک بار اور متن بفر میں شامل کیا جاتا ہے، اس کی لمبائی کو زیادہ سے زیادہ عددی قدر سے زیادہ دھکیلتا ہے۔ اس بلاک کی پہلی لائن ایک مضمر کاسٹ کرتی ہے۔ size_t کرنے کے لئے int، ترتیب sb_len منفی قدر کی طرف۔

پھر میں 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)

آؤٹ پٹ کی پہلی چوتھائی سیٹ اپ ہے، پیڈنگ کے ساتھ لاگ لائن کو زیادہ سے زیادہ int لمبا کرنے کے لیے پرائمنگ کرتا ہے۔ دوسری چوکڑی بفر اووررن ہے، جہاں sb_len منفی پر سیٹ کیا جاتا ہے، اور پھر ہمیں بفر کے آغاز کے بائیں جانب 56 بائٹس کا مقام دینے کے لیے آفسیٹ میں شامل کیا جاتا ہے۔ اس جگہ پر پرنٹ ہونے والا مواد اس صورت میں ہے۔ %s، جو کمٹ کی سبجیکٹ لائن سے بدل جاتا ہے — 44 بائٹس لمبی۔ مصنفین تجویز کرتے ہیں کہ اسے "گٹ فورج"، AKA GitHub اور GitLab کے خلاف ہتھیار بنایا جا سکتا ہے، کیونکہ وہ سافٹ ویئر سوئٹ گٹ آرکائیو کمانڈ چلاتے ہیں، جو صارف کے زیر کنٹرول خوبصورت سٹرنگ کو استعمال کر سکتی ہے۔

فکسز کو 8 دسمبر کو گٹ سورس کوڈ پر واپس دھکیل دیا گیا تھا، لیکن ان اصلاحات پر مشتمل نئی ریلیز ابھی دستیاب ہیں۔ خام کے تقریباً 2200 واقعات ہیں۔ int مسئلہ، اور ان کو صاف کرنے میں کچھ وقت لگے گا، یہاں تک کہ کچھ تفریحی ہیکس جیسے cast_size_t_to_int()، ایک ان لائن فنکشن جو پروگرام کو ختم کر دیتا ہے اگر 2 GB+ size_t سنبھالا جاتا ہے. تو اپ ڈیٹ کریں!

میلچیمپ - دوبارہ

ایسا لگتا ہے کہ میلچیمپ کے لوگ وقفہ نہیں پکڑ سکتے، جیسا کہ حملہ آوروں نے ان کے داخلی انتظامی آلات تک ایک بار پھر رسائی حاصل کی۔, جس کے نتیجے میں 133 کسٹمر اکاؤنٹس بشمول WooCommerce کے سامنے آئے۔ یہ تیسرا موقع ہے جب میل چیمپ پچھلے سال میں کسی سوشل انجینئرنگ یا فشنگ حملے کا شکار ہوا ہے، اور ہر بار اس کے نتیجے میں اختتامی صارفین کو بھیجی جانے والی سپیئر فشنگ ای میلز کا سامنا کرنا پڑا ہے۔ لہذا اگر آپ میل چیمپ کی میلنگ لسٹ میں ہیں، تو اگلی بار متعلقہ ای میل آنے پر اس خلاف ورزی کو ذہن میں رکھیں۔ (ایڈیٹر کا نوٹ: Hackaday کے دو نیوز لیٹر میلچیمپ کا استعمال کرتے ہیں، اور ہمیں مطلع نہیں کیا گیا تھا، لہذا ہمیں یقین ہے کہ ہم اچھے ہیں۔)

رائل میل رینسم ویئر

ایک ایسی کہانی میں جس کے کچھ بڑے نتائج ہو سکتے ہیں۔ برطانیہ کے رائل میل کو رینسم ویئر کے حملے کا سامنا کرنا پڑا ہے۔ بین الاقوامی میل کو سنبھالنے کے لیے ان کے سسٹم پر۔ حملے میں Lockbit ransomware کا استعمال کیا گیا ہے، ایک گروپ جس پر شبہ ہے کہ یہ روسی بولنے والا ransomware گینگ ہے۔ یہ اہم ہو سکتا ہے، کیونکہ ایک حقیقی سرکاری ایجنسی پر حملہ کاروبار پر حملے سے کہیں زیادہ سنگین ہے۔ چونکہ Lockbit ransomware-as-a-service کے طور پر چلتا ہے، اس لیے یہ تعین کرنا بہت مشکل ہو گا کہ اصل میں حملہ کس نے کیا تھا۔ ابھی کے لیے، سفارش آسان ہے: کوئی بین الاقوامی میل نہ بھیجیں۔ افف

ایس پی ایف ریکارڈز کو اسکین کرنا

[Sebastian Salla] کے پاس ایک عجیب مشغلہ سمجھا جا سکتا ہے، جس کی شکل میں عجیب غلط کنفیگریشنز کے لیے SPF ریکارڈز کو اسکین کرنا. اس کے تازہ ترین ایڈونچر میں، وہ اسکین ٹاپ 3 ملین سب سے زیادہ دیکھے جانے والے ڈومینز تھے۔ اور غلط ترتیب پائی گئی۔

لیکن ٹھہرو، SPF کیا ہے اور ہمیں اس کی پرواہ کیوں ہے؟ بھیجنے والا پالیسی فریم ورک ایک txt ریکارڈ ہے جو ڈومین کے DNS ریکارڈز کا حصہ ہے۔ اور یہ بتاتا ہے کہ کون سے IP پتے اصل میں اس ڈومین کے لیے ای میل بھیجنے کے لیے مجاز ہیں۔ لہذا اگر کوئی آنے والی ای میل درست SPF ریکارڈ والے ڈومین سے ہونے کا دعوی کرتی ہے، اور بھیجنے والا IP پتہ اس ریکارڈ میں نہیں ہے، تو یہ واضح طور پر دعوی کردہ ڈومین سے نہیں ہے۔

اور آپ کے ڈومین کی ای میلز کو SPF کے مسئلے کی وجہ سے مسترد کر دیا جانا اس بات کو پکڑنے کے یقینی طریقوں میں سے ایک ہے۔ اس لیے یہ SPF ریکارڈ کو تھوڑا سا زیادہ … *لبرل* بنانے کے لیے پرکشش ہے جتنا کہ اسے ہونا چاہیے۔ اور اس کا سب سے زیادہ تکرار صرف تھپڑ مارنا ہے۔ +all اپنے SPF ریکارڈ پر اور اس کے ساتھ کیا جائے۔ یقینی طور پر، یہ دنیا کو بتاتا ہے کہ ہر اسپامر جو کہیں بھی آپ کا ڈومین استعمال کرتا ہے وہ اصل میں حقیقی ای میلز بھیج رہا ہوتا ہے، لیکن کم از کم اسے باس کی باہر جانے والی ای میلز دوبارہ کام کرنے لگتی ہیں۔ ایک ہزار سے زیادہ ڈومینز کے ساتھ SPF پر سیٹ ہے۔ +all، بظاہر یہ متوقع سے زیادہ عام غلطی ہے۔

واقعی دلچسپ بات یہ ہے کہ ان غلط کنفیگرڈ ڈومینز میں سے کون ہے، جیسے متعدد امریکی سرکاری ایجنسیاں، دنیا بھر کے دیگر سرکاری ڈومینز، اور متعدد یونیورسٹیاں۔ سب سے زیادہ دلچسپ یوکرین کی وزارت دفاع کا تھا، جہاں SPF ریکارڈ کو ایک سے تراش لیا گیا تھا۔ -all کرنے کے لئے +all تقریبا 4 مہینے پہلے.

بٹس اور بائٹس

ٹیل اسکیل نے ایک ممکنہ طور پر سنگین مسئلہ دریافت کیا، جہاں کسی دوسرے کلائنٹ کی نوڈ آئی ڈی جاننے سے حملہ آور کو اپنے ٹیل نیٹ میں نوڈ شامل کرنے کی اجازت ہوگی۔ اس سے آپ کے VPN کے اندر حملہ آور ہو جاتا، یقیناً ایک برا منظر۔ لیکن اس سے پہلے کہ آپ اپنے پچ فورک حاصل کر لیں، کمزور کوڈ کو ٹھیک ہونے سے پہلے چار ماہ سے بھی کم عرصے کے لیے تعینات کیا گیا تھا۔ یہ اس مہینے کی 11 تاریخ کو نجی طور پر رپورٹ کیا گیا تھا، اور 12 تاریخ کو طے کیا گیا تھا۔ اور بوٹ کرنے کے لیے، حملہ ایک لاگ دستخط چھوڑتا ہے جسے ٹیل اسکیل اسکین کرنے کے قابل تھا، اور یہ نتیجہ اخذ کیا کہ یہ تصور کے ثبوت کی جانچ سے الگ تھلگ تھا۔ آپ تصدیق کے لیے ان کے اپنے ٹیل نیٹ سے اشتراک کردہ کسی بھی نوڈس کے لیے اپنا ڈیش بورڈ چیک کر سکتے ہیں۔ اور جب کہ یہ ایک گندی کمزوری ہے، اس کا انکشاف کرنے کے لیے Tailscale کے لیے اچھا ہے۔ بہت سے دکاندار اس پر بیٹھے ہوں گے اور اسے کبھی عام نہیں کیا ہوگا۔

۔ لینکس کرنل میں بفر اوور فلو تھا۔ اس کے نیٹ فلٹر کوڈ میں، جہاں بفر اوور فلو کے نتیجے میں ڈیٹا لیکیج اور کوڈ پر عمل درآمد ہو سکتا ہے۔ دور دراز کے استحصال کا کوئی راستہ نہیں ہے، لیکن اوپر لنک کردہ ای میل میں مقامی استحقاق میں اضافے کے لیے مکمل PoC موجود ہے۔ اور اگر کرنل کا استحصال آپ کی چیز ہے تو گوگل کے پروجیکٹ زیرو کے پاس ہے۔ اس موضوع پر ایک نئی تحریر, تمام null dereferencing کے بارے میں۔

اور اگر آپ Zoho سے ManageEngine استعمال کرتے ہیں، تو آج آپ کے بالوں میں آگ لگ سکتی ہے، اگر آپ نے CVE-2022-47966 کو ٹھیک کرنے والی ریلیز کو اپ ڈیٹ نہیں کیا ہے۔ پر محققین Horizon3 نے پیچ کو ریورس انجینئر کیا ہے۔، اور اس RCE پر پھلیاں پھینک دیں۔ یہ ایک مسئلہ ہے کہ SAML سنگل سائن آن کو کس طرح لاگو کیا جاتا ہے، جس کی وجہ پروڈکٹ کے حصے کے طور پر پیک کی گئی ایک انتہائی پرانی لائبریری ہے۔ یہ ایک بہت ہی آسان استحصال ہے، لہذا ان انسٹالز کو دوبارہ چیک کرنے کا وقت ہے!

• SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
• پلیٹو بلاک چین۔ Web3 Metaverse Intelligence. علم میں اضافہ۔ یہاں تک رسائی حاصل کریں۔
• ماخذ: https://hackaday.com/2023/01/20/this-week-in-security-git-deep-dive-mailchimp-and-spf/