اے میں یہ تیسری قسط ہے۔ مضامین کا سلسلہ سب سے زیادہ مروجہ قسم کے سافٹ ویئر سپلائی چین حملوں کے بارے میں: وہ جو عوامی رجسٹری کا غلط استعمال کرتے ہیں۔ آزاد مصدر سافٹ ویئر کے اجزاء. پچھلی قسط میں تجزیہ کرنے کے بعدبدنیتی پر مبنی پیکیجز کی اناٹومی: رجحانات کیا ہیں؟"برے اداکار نئے یا موجودہ شائع شدہ اجزاء میں کس طرح بدنیتی پر مبنی رویہ ڈالتے ہیں، ہم اپنی فائر فائٹنگ جیکٹس پہننے کے لیے تیار ہیں اور اس بات کا جائزہ لینے کے لیے تیار ہیں کہ ہم اس طرح فراہم کیے جانے والے نقصان دہ سافٹ ویئر کو کس طرح کامیابی سے روک سکتے ہیں، یا متبادل طور پر، ممکنہ طور پر سنگین سائبر واقعے سے نمٹ سکتے ہیں کیونکہ ہم نے غلط طریقہ اختیار کیا۔
زیادہ تر سیکیورٹی سے آگاہ پیشہ ور افراد کے پاس اس خطرے سے نمٹنے کے طریقے کے بارے میں خیالات ہیں۔ ہم نے سیکیورٹی مینیجرز کو بغیر کسی ہچکچاہٹ کے یہ کہتے سنا ہے۔ SCA ٹولز پہلے ہی آپ کو بتاتے ہیں کہ پیکیج کا ورژن کب میلویئر ہے۔ یا یہ کہ ان کا انحصار معروف، انتہائی نظرثانی شدہ سافٹ ویئر کے اجزاء پر ہے، جہاں کسی بھی میلویئر کا فوری طور پر پتہ لگا کر اسے ہٹا دیا جائے گا۔ وہ خود بخود خطرے سے متعلق فکس حاصل کرنے کے لیے اوپن مائنر/پیچ ورژن استعمال کرتے ہیں، اور یہ اوپن سورس انحصار پر خطرے کو کم کرنے کا مناسب، تجویز کردہ طریقہ ہےجلدی پیچ، اکثر پیچ”اصول۔
اس ایپی سوڈ میں، ہم اس بات کا جائزہ لیں گے کہ یہ خیالات کیوں غلط ہیں، اور اس طرح کی غلط فہمیاں اس حملے کے طریقہ کار کی مقبولیت میں، اور تنظیموں کو لاحق خطرے میں کیسے مدد دے رہی ہیں۔ ہم اس بات کو ختم کریں گے کہ کیا کام کرتا ہے، اور کون سی کوشش اور وسائل شامل ہیں۔
عام غلط فہمیاں
سافٹ ویئر سیکورٹی کے ساتھ اپنے سفر کے دوران، ہم نے حملے کی تکنیکوں کو تیار ہوتے دیکھا اور سیکورٹی کے بارے میں شعور رکھنے والے لوگوں کے خیالات کی ایک وسیع رینج دیکھی۔ تنظیمیں اکثر غلط فہمی کا شکار ہوتی ہیں کہ اس خطرے کے خلاف کیا کام کرتا ہے، اس لیے پہلے ہم جائزہ لیں گے کہ کیا کام نہیں کرتا، مندرجہ ذیل میں گاڑھا، مکمل نہیں، غلط فہمیوں کی فہرست۔
غلط فہمی نمبر 1: SCA ٹولز پہلے ہی نقصان دہ اجزاء کی اطلاع دیتے ہیں۔
بے شک! لیکن حقیقت کے بعد… جب شاید بہت دیر ہو چکی ہو اگر عنصر کو سافٹ ویئر کی تعمیر میں استعمال کیا گیا ہو، اور برے اداکار پہلے ہی کسی ڈویلپر میں قدم جما چکے ہوں یا CI/CD میزبان ہو سکتا ہے کہ رازوں سے پردہ اٹھایا گیا ہو، اضافی میلویئر ڈاؤن لوڈ اور انسٹال کیا گیا ہو، اور شاید مخالف بعد میں منتقل ہو گیا ہو اور پہلے ہی کہیں اور رسائی حاصل کر لی ہو۔
سافٹ ویئر کمپوزیشن تجزیہ (SCA) ٹولز کو ممکنہ معلوم کمزوریوں کی نشاندہی کرنے کے لیے ڈیزائن کیا گیا تھا۔ جدید ٹولز سگنل شور کے تناسب کو بڑھا کر ایک بہت اچھا کام کرتے ہیں، اس بات کا تعین کرتے ہوئے کہ آیا کمزوری حقیقت میں قابل رسائی ہے یا فائدہ مند۔ لیکن وہ نئے میلویئر کے خلاف بیکار ہیں۔ کسی نقصان دہ جزو کو صفر دن کے خطرے کے طور پر سوچیں: صرف اس وقت جب اس کے بدنیتی پر مبنی رویے کا پتہ چل جاتا ہے، اس جزو کی اطلاع ہولڈنگ رجسٹری کو دی جاتی ہے، جس کی سیکیورٹی ٹیم کے جائزے کے بعد تصدیق کی جاتی ہے کہ اسے نقصان پہنچایا جاتا ہے اور اسے رجسٹری سے ہٹا دیا جاتا ہے۔ ہے [1].
اس وقت، دنیا (بشمول SCAs) جانتا ہے کہ جزو (یا کسی موجودہ جزو کا کچھ ورژن) انسٹال یا استعمال کرنا اچھی بات نہیں ہے۔ لیکن یہ تب ہوتا ہے جب رجسٹری سے جزو دستیاب نہیں ہوتا ہے۔. یہ جاننا کہ میرے پاس فریق ثالث کے اجزاء میں کمزوریاں ہیں، یا ان اجزاء کو بھی جو رجسٹری کے ذریعہ بدنیتی کے طور پر درجہ بندی کیا گیا ہے، اچھا ہے، لیکن بدقسمتی سے SCA یا عام آڈٹ ٹولز اس تناظر میں مدد نہیں کرتے۔ جب تک SCA/audit ٹول آپ کی تنظیم میں استعمال ہونے سے پہلے واقعی جان سکتا ہے کہ کوئی جزو بدنیتی پر مبنی ہے۔.
یاد رکھیں، نقصان دہ اوپن سورس اجزاء کے خلاف کسی بھی حل کو ان کا پتہ لگانا چاہیے۔ پرواز پرکے درمیان جب جزو رجسٹری میں شائع ہوتا ہے اور جب جزو (ورژن) آپ کی تنظیم میں پہلی بار استعمال ہوتا ہے۔ اور اس میں عبوری اجزاء شامل ہیں۔
غلط فہمی #2: تعمیراتی وقت پر انسٹالیشن اسکرپٹس کو کنٹرول کرنا اوپن سورس اجزاء سے بدنیتی پر مبنی رویے کو روکتا ہے
مختلف پیکیج مینیجرز اسکرپٹ کو چلانے کی صلاحیت پیش کرتے ہیں (جزو ٹربال میں شامل ہے۔ ہے [2]), جائز وجوہات کی بناء پر، جیسے کہ مختلف پلیٹ فارمز پر مطلوبہ آئٹمز مرتب کرنا، کوڈ بنانا، یا ٹیسٹ چلانا، اور ہم سب کو معلوم ہونا چاہیے کہ اگر ٹربال میں بدنیتی پر مبنی اسکرپٹس شامل ہیں، یا اگر حملہ آور اچھے کی بجائے خراب اسکرپٹ کو چلا سکتا ہے تو برے اداکار ان کے ساتھ زیادتی کر سکتے ہیں۔
یہ جان کر، ہم اسکرپٹ کو نظر انداز کرنے کے لیے پیکیج مینیجر کو ترتیب دے سکتے ہیں۔ مثال کے طور پر، NPM کے ساتھ -اسکرپٹس کو نظر انداز کریں۔ جھنڈا (یا کنفیگریشن پراپرٹی .npmrc فائل) انسٹالیشن کے دوران اسکرپٹ کو چھوڑ دیتا ہے۔ اس سے کچھ مسائل پیدا ہوسکتے ہیں کیونکہ بہت سے ماحولیاتی نظاموں میں اسکرپٹ کو چلانے میں عام بات ہے: کچھ پیکیج مینیجر اسکرپٹ پر عمل درآمد کو غیر فعال کرنے کی اجازت بھی نہیں دیتے ہیں (اشارہ: پرامپٹ "کون سے پیکج مینیجرز انسٹال اسکرپٹس پر عمل درآمد کو غیر فعال کرنے کی اجازت نہیں دیتے ہیں؟"آپ کے پسندیدہ AI میں)۔ لیکن یہ عام طور پر تحفظ نہیں دیتا ہے (ہمیں نافذ کرنے کی ضرورت ہے کہ اسکیپ ڈس ایبل کنفیگریشن ہر جگہ موجود ہے)۔
اور جب بدنیتی پر مبنی رویہ انسٹال اسکرپٹ میں نہیں ہوتا بلکہ رن ٹائم پر عمل کرنے کے لیے سافٹ ویئر میں ہوتا ہے، تو یہ آپشن ہی ہماری حفاظت نہیں کرتا ہے۔
غلط فہمی #3: ورژن پن کرنا نقصان دہ اجزاء کو انسٹال ہونے سے روکتا ہے۔
ابتدائی اور اکثر کے ساتھ پیچ کرنے کے درمیان ایک تجارت ہے کھلے ورژن (سیکیورٹی اصلاحات کے لیے دستیاب ہونے پر پیکج مینیجر کو خود بخود نئی اپ ڈیٹس انسٹال کرنے کی اجازت دینا) اور ورژن پننگ (ایک مقررہ ورژن پر سافٹ ویئر کے لیے تمام براہ راست اور عبوری انحصار)۔ حفاظتی اصول ضدی اور بعض اوقات متضاد ہوتے ہیں، جیسا کہ "پیچ جلدی، اکثر پیچ" اور "اپ گریڈنگ کو ہلکے سے نہیں لینا چاہئے". کچھ پیکیج مینیجرز تجویز کردہ طریقے سے سرور رینج کے ساتھ خودکار اپ ڈیٹس کرتے ہیں۔ بہت اچھا ہے اگر آپ بھی بدنیتی پر مبنی اپ ڈیٹس حاصل کرنا چاہتے ہیں! جی ہاں، حفاظتی اصلاحات حاصل کرنے کے لیے اجزاء کو اپ ڈیٹ کیا جانا چاہیے جو جلد از جلد کمزوریوں کو بند کر دیں، لیکن … کبھی بھی پیکیج مینیجر کو خود بخود ایسا نہ ہونے دیں۔
غلط فہمی #4: قابل اعتماد اجزاء کا استعمال محفوظ ہے۔ کوئی بھی بدنیتی پر مبنی ورژن فوری طور پر پایا جائے گا، ظاہر کیا جائے گا اور ہٹا دیا جائے گا۔
ایک جزو پر بھروسہ کیوں کیا جاتا ہے؟ ممکنہ طور پر اس لیے کہ یہ بہت مقبول ہے، بہت سے آنکھ کی گولیاں کمزوریوں کی تلاش میں ہیں، دیکھ بھال کے لیے تعاون کرنے والوں کی ایک بڑی تعداد، ایک سے زیادہ بنیادی دیکھ بھال کرنے والوں کے ساتھ جو تندہی سے سبھی کا جائزہ لیتے ہیں۔ pull requests. حقیقت بالکل مختلف ہے۔ کچھ ضروری اجزاء کو ایک واحد، بلا معاوضہ ڈویلپر کے ذریعہ برقرار رکھا جاتا ہے۔ وسیع پیمانے پر استعمال شدہ فریم ورک ہیں۔ چند باقاعدہ تعاون کرنے والےکی تیزی سے کم ہوتی ہوئی تعداد کے ساتھ commits فی مینٹینر (مقبول پروجیکٹس میں شراکت داروں کی لمبی دم ہوتی ہے جو کچھ ڈرائیو بائی انجام دیتے ہیں۔ commit اور کبھی واپس نہ آئیں)۔ اور ایک ہی مینٹینر کے ساتھ مقبول پروجیکٹس بہت زیادہ ہیں۔
اپنے آپ کو کہنے کا تصور کریں۔ "اوہ، ہم اسپرنگ بوٹ / اینگولر / ری ایکٹ / پائ ٹارچ / آفیشل بیس ڈوکر امیجز استعمال کر رہے ہیں، لہذا آپ جس خطرے کے بارے میں بات کر رہے ہیں وہ کافی کم ہے۔" شاید یہ سچ ہے، ہم سیکورٹی فروش ہر وقت خوفزدہ کرتے رہتے ہیں، اور قابل بحث خطرے کو کم کرنے کے لیے ترقیاتی ٹیموں کے ساتھ مداخلت کرنا بکواس ہے۔ آپ خطرے کی قبولیت کے پیراگراف (اگلے حصے میں) پر کودنے کا لالچ میں آ سکتے ہیں اور سب کچھ ہو گیا ہے۔ بدقسمتی سے، سب سے زیادہ مقبول اجزاء برے اداکاروں کے لیے ہدف ہیں، اور مثال کے طور پر، مقبول PyTorch لائبریری پر حملہ کیا گیا۔ ماضی میں.
"فوری طور پر پایا گیا، ظاہر کیا گیا اور ہٹا دیا گیا"۔ عوامی رجسٹری سے ایک نئے بدنیتی پر مبنی جزو کو ہٹانے میں دن لگتے ہیں۔ رجسٹریاں اچھے کے لیے، جزو کے ورژن کو ہٹانے کے بارے میں محتاط ہیں۔ ہمارا تجربہ یہ ہے کہ ایک بار ہماری طرف سے اطلاع ملنے پر، متاثرہ ورژن کو ہٹانے کے لیے رجسٹری کا درمیانی وقت 39 گھنٹے ہے، ڈیڑھ دن سے زیادہ۔ نقصان دہ اجزاء ہیں جو ہٹانے سے پہلے رجسٹری میں ہماری ابتدائی رپورٹنگ کے ایک ہفتہ بعد ہیں۔ اور بعض صورتوں میں، جزو کو صرف اس وقت ہٹا دیا جاتا ہے جب کسی متاثرہ یا واقعے کے جواب دینے والی کمپنی جزو میں شامل واقعے کی اطلاع دیتی ہے۔
نقصان دہ اجزاء کے خلاف کیا کام نہیں کرتا ہے۔
کوئی بھی غیر مخصوص نقطہ نظر بری طرح ناکام ہو جائے گا۔ یہ ایک یقینی بات ہے، آپ اس خطرے سے وابستہ خطرے کے لیے مؤثر انسدادی اقدامات فراہم نہیں کر رہے ہیں۔
روایتی SCA ٹولز آپ کو معلوم مالویئر کے بارے میں بتاتے ہیں لیکن ایک بڑی ایکسپوزر ونڈو ہوتی ہے۔ جب تک کہ وہ بدنیتی پر مبنی اجزاء کو مسدود کرنے کے ساتھ میلویئر کا پتہ لگانے کو فعال طور پر انجام نہیں دے رہے ہیں، وہ اس خطرے کے خلاف کام نہیں کرتے ہیں۔
انسٹالیشن اسکرپٹس کو غیر فعال کرنے سے مدد مل سکتی ہے لیکن اسے ہر جگہ نافذ کرنے کی ضرورت ہے جہاں کسی جزو کو انسٹال کرنے کی ضرورت ہے۔ ورژن پننگ کے ساتھ بھی، جیسا کہ ورژن کو ہمیشہ کے لیے محفوظ ابتدائی حالت سے پن نہیں کیا جا سکتا۔
یہ فرض کر لینا کہ مقبول اجزاء کو اتنی توجہ ملتی ہے کہ انہیں سپلائی چین حملے میں غیر ارادی رویے کے ساتھ انجکشن نہیں لگایا جا سکتا، بغیر کسی نقصان کو روکنے کے لیے تقریباً فوری پتہ لگائے جانے کے لیے یہ سادہ اور خطرناک ہے۔ آپ کنارے پر نہیں رہنا چاہتے، کیا آپ؟
اگر آپ اس مقام پر رک جائیں تو خطرے کی قبولیت صرف ایک ہی چیز ہے جو آپ کر سکتے ہیں: یہ ایک ڈی ہے۔cisآئن جس کو آپ کے خطرے کے ماڈل/خطرے کی تشخیص میں دستاویز کرنے کی ضرورت ہے، بشمول خطرے کو قبول کرنے کی دلیل اور اس کے ممکنہ مضمرات۔ انتظامیہ اور دیگر متعلقہ فریقوں تک اس کی اطلاع دے کر بیداری پیدا کریں۔ کچھ ہنگامی منصوبہ بندی اس وقت کی جا سکتی ہے جب آپ کے سافٹ ویئر میں کوئی نقصان دہ جزو انسٹال یا شامل ہو، لیکن یہ مشکل ہے کیونکہ حملہ آوروں کے پاس بہت سے راستے ہوتے ہیں۔ نقصان دہ جزو کے استعمال پر مبنی سپلائی چین حملے کی تفصیلات اس واقعے کے عوامی انکشاف کو یکسر تبدیل کر دے گی، جو شاید آپ کی تنظیم کے ریگولیٹری فریم ورک کے تحت لازمی ہے۔ آپ بھی خطاب کر سکتے ہیں۔ معاوضہ کنٹرولز or منتقلی کا خطرہ مثلاً انشورنس کے ساتھ۔
تاہم، ایسے کنٹرول موجود ہیں جو خطرے سے نمٹنے کے لیے ہیں اور اگر آپ خطرے کی قبولیت سے مطمئن نہیں ہیں تو ان پر غور کیا جانا چاہیے۔ براہ کرم پڑھیں۔
نقصان دہ اجزاء کا استعمال کرتے ہوئے حملوں کے خلاف کیا کام کرتا ہے۔
ٹھوس ورژن ہینڈلنگ
کنٹرول شدہ اور باخبر ورژن bumps کے ساتھ ورژن پن کرنا، میلویئر حاصل کیے بغیر کمزوریوں کو دور کرنے کی ضرورت کو متوازن کرنے کے لیے جانے کا راستہ ہے۔ لیکن غلط فہمی #3 یاد رکھیں: نئے ورژن سے آنے والے نقصان دہ کوڈ کو روکنے کے لیے صرف ورژن پن کرنا کافی نہیں ہے، کیونکہ آپ کو مستقبل میں کسی بھی براہ راست یا بالواسطہ انحصار میں ورژن کو اپ ڈیٹ کرنے کی ضرورت ہوگی۔ اس وقت آپ کو کافی مضبوط ثبوت کی ضرورت ہے کہ تمام ترمیم شدہ ورژن میلویئر پر مشتمل نہیں ہیں۔
ابتدائی انتباہ
بدنیتی پر مبنی اجزاء کے مسئلے کا ایک نقطہ نظر ابتدائی انتباہی نظام ہے (جس کا نام یہاں ہے۔ میلویئر کی ابتدائی وارننگ یا MEW)، جہاں شائع شدہ نئے ورژن (نئے یا موجودہ اجزاء کے لیے) کا تجزیہ ایک پتہ لگانے والے انجن کے ذریعے کیا جاتا ہے، جو کافی ثبوت ملنے پر نئے ورژن کو ممکنہ طور پر نقصان دہ قرار دے سکتا ہے۔
یہاں آٹومیشن ضروری ہے، کیونکہ موجودہ اشاعت کی شرح پر تمام نئے اجزاء کا دستی طور پر جائزہ لینا ناممکن ہے۔ لہذا پتہ لگانے والے انجن کو متعدد تکنیکوں کو یکجا کرنے کی ضرورت ہے، جس میں شاید جامد، متحرک، اور صلاحیت کا تجزیہ، صارف کی ساکھ، اور اجزاء کے میٹا ڈیٹا اور ٹربال کے مشمولات، یا ٹربال اور ماخذ ذخیرے کے درمیان تضادات سے آنے والے شواہد شامل ہیں جہاں سے جزو سمجھا جاتا ہے۔
ایک ہے تاریک زون اشاعت کے وقت اور انجن کے اجزاء کے مواد کا تجزیہ کرنے کے درمیان، لیکن یہ چند منٹ سے زیادہ نہیں ہونا چاہیے۔ اسکیم میں ترمیم کی جاسکتی ہے، مثال کے طور پر سافٹ ویئر کی تعمیر میں انسٹال کرنے اور استعمال کرنے کی اجازت دینے سے پہلے نئے اجزاء کا تجزیہ کرنے کا انتظار کرکے۔ pipelines، یا ضرورت پڑنے پر ان کا تجزیہ کریں۔ دیئے گئے ورژن میں ایک جزو ناقابل تغیر ہے۔ ہے [3]، لہذا اس کا صرف ایک بار تجزیہ کرنے کی ضرورت ہے۔
مکمل آٹومیشن ممکن نہیں ہے، اور ممکنہ طور پر بدنیتی پر مبنی اجزاء کے لیے حفاظتی جائزہ کی ضرورت ہے۔ ڈیجیٹل علاج کے حامیوں سے ہوشیار رہیں: AI اور مشین لرننگ اتنی ترقی یافتہ نہیں ہیں کہ جب یہ تصدیق کرنے کی بات کی جائے کہ آیا کسی مشتبہ جزو میں میلویئر ہے تو آخری لفظ لے سکتے ہیں۔ یقینی طور پر، پکڑے گئے خام شواہد سے ان پٹ جزو کی درجہ بندی کرنے میں مشین لرننگ کا پتہ لگانے والے انجن میں کلیدی کردار ہوتا ہے، لیکن ایک بار جزو کو "قرنطینہ" کرنے کے بعد حتمی لفظ نقصان دہ اجزاء میں تجربہ رکھنے والی سیکیورٹی ٹیم کے دستی جائزے پر ہوتا ہے۔ یہ کسی بھی ممکنہ میلویئر کی تصدیق کرتا ہے یا اسے محفوظ کے طور پر دوبارہ درجہ بندی کرتا ہے۔ اور وقت کی مدت گھنٹوں کی حد میں ہے۔
رجسٹری بدنیتی پر مبنی ورژن/اجزاء پر رپورٹ کرتی ہے۔ اس کے بعد رجسٹری تصدیق کرنے کے لیے اپنا جائزہ لیتی ہے اور عوامی انکشاف اور رجسٹری سے ہٹانے کے لیے آگے بڑھ جاتی ہے۔ کچھ رجسٹریاں سیکیورٹی ہولڈنگ پیکج رکھتی ہیں۔ یہاں وقت کی حد اشاعت کے بعد کے دنوں یا ہفتوں کی ہے، جو کہ 'رہو وقت'یا'نمائش ونڈو' زیادہ تر بدنیتی پر مبنی اجزاء کے لیے۔
کیا یہ جاننا ممکن ہے کہ آیا کوئی جزو ورژن بدنیتی پر مبنی ہے؟
لہذا ابتدائی انتباہ کے لیے، ہمیں اس سوال کا تسلی بخش جواب دینے کی ضرورت ہے: میں کیسے جان سکتا ہوں کہ لائبریری یا پیکیج (نہیں) بدنیتی پر مبنی ہے؟ بدنیتی پر مبنی رویے کے کافی ثبوت کیسے جمع کیے جائیں؟ ممکن ہے، لیکن مشکل، کیونکہ مخالفین پتہ لگانے سے بچنے کے لیے بہت آسانی کا استعمال کرتے ہیں۔ مختلف نقطہ نظر ہیں، ہر ایک کے فوائد اور نقصانات ہیں۔
جامد تجزیہ عمل درآمد کے تمام راستوں کی جانچ پڑتال کر سکتا ہے جو حملہ آوروں کے ذریعے استعمال کی جانے والی تکنیکوں کی جانچ پڑتال کر سکتے ہیں بغیر اجزاء کو چلائے، اور پری پروسیسنگ کے کاموں کو انجام دے سکتے ہیں جیسے ڈی-اوفسکیشن یا ڈسیفرنگ۔ جیسا کہ حملہ آور اپنی شرارتوں کو چھپانے کی کوشش کرتے ہیں، مبہم کوششیں درحقیقت میلویئر کا ثبوت ہیں (لیکن نوٹ کریں کہ قانونی اجزاء دانشورانہ املاک کے تحفظ کے لیے کوڈ کو مبہم کرتے ہیں، اس سے متصادم ہے"اوپن سورسصرف انتہائی نفیس حملوں میں سے صرف ایک اقلیت کو ہی سینڈ باکسنگ کی ضرورت ہوتی ہے، لیکن اس طرح کی مضبوط مبہمیت بدنیتی کی ایک واضح علامت ہے۔ براہ کرم نوٹ کریں کہ روایتی SAST ٹولز کو غیر ارادی کمزوریوں کے لیے ڈیزائن کیا گیا تھا، نہ کہ بیک ڈور جیسے بدنیتی پر مبنی ارادے کے لیے۔
متحرک تجزیہ جزو کو چلاتا ہے اور رن ٹائم کو آلہ بنا کر جواب کی جانچ کرتا ہے، عام طور پر سینڈ باکسڈ ماحول فراہم کر کے۔ بعض شرائط کے تحت متحرک ہونے والے بدنیتی پر مبنی رویے کا پتہ نہیں چل سکتا: براہ کرم نوٹ کریں کہ میلویئر چوری کی تکنیک استعمال کر سکتا ہے جیسے ورچوئلائزیشن/سینڈ باکس چوری صرف اس وقت چالو کرنا جب جانچ پڑتال کے تحت نہ ہو، اور کسی بھی جامد تجزیہ انجن کے لیے بدنیتی پر مبنی سرگرمی کی ایک واضح علامت۔
صلاحیتوں کا تجزیہ اس پر غور کرتا ہے کہ جزو کیا کرتا ہے: یہ کہاں سے جڑتا ہے، کن فائلوں تک رسائی حاصل کرتا ہے، کون سے کمانڈز یا پروگرام چلائے جاتے ہیں، ٹرمینل یا ڈیوائس I/O کیا جاتا ہے، یا کون سی سسٹم کالز کی جاتی ہیں۔ رویے کی اس فنگر پرنٹنگ کا موازنہ (موجودہ جزو کے لیے) تمام ورژنز میں کیا جا سکتا ہے، اس لیے جب غیر متوقع رویے کا پتہ چل جاتا ہے، تو اس ثبوت سے نئے ورژن میں انجکشن کی گئی ممکنہ بدنیتی پر مبنی سرگرمی کا شبہ پیدا ہو سکتا ہے۔ یہ نقطہ نظر ان ٹرائیج اقدامات کی پیروی کرتا ہے جن کی پیروی سیکیورٹی تجزیہ کار ممکنہ میلویئر کے ساتھ ہونے پر کرتے ہیں: استعمال کرتے ہوئے ایک معائنہ ڈور یا اسی طرح کے اوزار۔ یہ نقطہ نظر محرک حالات سے قطع نظر بدنیتی پر مبنی رویے کا پتہ لگاتا ہے اور اس وقت کام کرتا ہے جب کوئی سورس کوڈ دستیاب نہ ہو۔
سیاق و سباق کا تجزیہ اس بارے میں معلومات جمع کرتا ہے کہ جزو کیسے شائع ہوا اور کس کے ذریعے۔ خراب اداکاروں کی مہمات اکثر ایک نئے صارف اکاؤنٹ (اکاؤنٹس) کا استعمال کرتی ہیں جو کسی سخت جانچ کے عمل سے مشروط نہیں ہوتے ہیں۔ ماضی کی سرگرمی کا سراغ لگانے سے بنیادی صارف کو بصیرت مل سکتی ہے، زیادہ تر ایسی بے ضابطگیوں کے لیے جو ممکنہ سمجھوتے کی طرف اشارہ کر سکتے ہیں۔ شہرت کمانا بہت مشکل اور کھونا اتنا آسان! ماضی کی کوئی سرگرمی نہ کرنے والا صارف غیر جانبدار ہوتا ہے، لیکن کرما بدتمیزوں کا پیچھا کرتا ہے۔ ہیک ٹیوسٹ، یا عام صارفین جن کی اشاعت کی اسناد چوری ہو چکی ہیں، ان کا بغور جائزہ لیا جانا چاہیے۔
ایک اور سیاق و سباق کی معلومات ماخذ ذخیرے کے درمیان کوئی تضاد ہے جو سمجھا جاتا ہے کہ جزو ٹربال اور خود ٹربال کے مواد کو بنانے کے لیے استعمال کیا جاتا ہے۔ اور اچھے طریقوں کی بھی پیروی کرنا، جیسے عوامی رجسٹری میں شائع ہونے والے اجزاء کے ورژن سے مماثل ماخذ ذخیرے میں ٹیگ یا ریلیز بنانا۔ جب کسی خاص پر ذریعہ ذخیرہ commit ریلیز کے ساتھ ٹیگ کیا جاتا ہے، اور پھر اچانک ایک ورژن اس کی پیروی کرنے میں ناکام ہو جاتا ہے، یہ واحد اس بات کا مضبوط ثبوت ہے کہ جزو داغدار ہو سکتا ہے: خراب اداکار نے جزو کو شائع کرنے کے لیے استعمال کیے گئے اکاؤنٹ سے سمجھوتہ کیا ہو گا، لیکن اسے سورس کوڈ کے ذخیرے میں لکھنے کی اجازت نہیں ہے)۔ ان اصولوں کا استعمال کرتے ہوئے بہت سے حملوں کا باقاعدہ پتہ لگایا جاتا ہے: مثال کے طور پر، لیجر حملہ ان خطوط پر آسانی سے پتہ لگایا جا سکتا ہے۔ لہذا، سیاق و سباق کا تجزیہ اشاعت کے عمل میں ایسی بے ضابطگیوں کی نشاندہی کرتا ہے۔
انحصار فائر والنگ
ایک مختلف نقطہ نظر یہ ہے کہ آپ کے سافٹ ویئر میں استعمال ہونے والے تمام انحصاری گراف کے اجزاء کی ایک جامع وائٹ لسٹ ہو، لہذا کسی بھی تعمیر میں pipeline آپ کی تنظیم میں چلائیں صرف منظور شدہ اجزاء کے ورژن انسٹال اور استعمال کیے جاسکتے ہیں۔ "فائروال” ایک داخلی رجسٹری کا استعمال کرتے ہوئے نافذ کیا جاتا ہے جہاں اجازت شدہ اجزاء کے ورژن کے لیے ٹربالز پیش کیے جاتے ہیں (کیشڈ یا پراکسیڈ)۔ براہ کرم نوٹ کریں کہ کوئی بھی وائٹ لسٹ اس وقت تک کام نہیں کرے گی جب تک کہ آپ کے پاس کسی نئے ورژن کو معقول حد تک محفوظ کے طور پر درجہ بندی کرنے کی ٹیکنالوجی نہ ہو تاکہ اسے وائٹ لسٹ میں شامل کیا جا سکے۔
براہ کرم نوٹ کریں کہ ابتدائی وارننگ (نئے ورژن کی اشاعت کے بعد جلد از جلد پتہ لگانے) کو کسی ایسے طریقے کے ساتھ جوڑنے کی ضرورت ہے تاکہ اس معلومات کو فعال طور پر استعمال کیا جا سکے تاکہ تعمیر کو متاثر کرنے والے جزو کو روکا جا سکے۔ pipelines یا ڈویلپرز کی مشینیں۔ ہے [4]. ہم اسے کہتے ہیں "انحصار فائر والنگ”: بدنیتی پر مبنی پیکجوں سے خودکار تعمیرات کی حفاظت کے لیے قرنطینہ کا طریقہ کار۔ اندرونی پیکجز اور تصویری رجسٹریاں تنظیموں کو بیرونی برائیوں سے محفوظ رکھنے کے لیے اچھی ہیں، لیکن قرنطینہ کو موثر بنانے کے لیے کافی مضبوط ثبوت ضروری ہیں۔
رن ٹائم سینڈ باکسنگ
اشاعت کے وقت پتہ لگانے کے لیے ایک متبادل نقطہ نظر رن ٹائم پر رویے کا تجزیہ کرنا ہے۔ خیال یہ ہے کہ سافٹ ویئر سے متوقع رویے کو پکڑا جائے اور پائی جانے والی کسی بھی بے ضابطگیوں کا پتہ لگانا (یا بلاک) کرنا ہے۔ اس لائن آف ایکشن میں مانیٹرنگ یا بلاک کرنے کے لیے رن ٹائم کا آلہ بنانے کا مسئلہ ہے، اور یہ ایک امید افزا خیال ہے جسے نقصان دہ جزو کیڑوں کے خلاف تحفظ کے میکانزم کے ہتھیاروں میں شامل کیا جائے گا۔
ایک جامع حکمت عملی ترتیب دینا
تجویز کردہ حکمت عملی کو سافٹ ویئر ڈویلپمنٹ کے عمل میں مختلف تکنیکوں کو یکجا کرنے کی ضرورت ہے، آنے والے بدنیتی پر مبنی اجزاء کو روکنے کے لیے ورژن اپ ڈیٹس کو کنٹرول کرنا۔ ہمیں ورژن پننگ کو ایڈجسٹ کرنا چاہیے تاکہ ورژن کو اپ ڈیٹ کرنے کے ساتھ خودکار انفیکشن سے بچا جا سکے تاکہ اہم کمزوریوں کا ازالہ کیا جا سکے۔ ورژن اپ ڈیٹس کے دوران براہ راست اور بالواسطہ انحصار کا فوری اور موثر جائزہ تاکہ اس بات کا کافی ثبوت ہو کہ وہ میلویئر سے متاثرہ نہیں ہیں۔ ایسے سافٹ ویئر کی تعمیرات جو معلوم بدنیتی پر مبنی اجزاء پر منحصر ہیں کو مسدود کرنا ضروری ہے۔ اور سب پر عمل درآمد ہونا چاہیے۔
ورژن پننگ کا استعمال کریں، جب ممکن ہو، کیونکہ یہ تعمیرات کو زیادہ دوبارہ پیدا کرنے کے قابل بناتا ہے۔ کنٹرول شدہ، دستی طور پر منظور شدہ ورژن بمپس کے ساتھ ورژن پننگ، اور مددگار ٹیکنالوجی کی مدد سے، اس بات کا اندازہ لگانا چاہئے کہ آیا اپ ڈیٹ میلویئر لاتا ہے یا سافٹ ویئر کو توڑتا ہے، اور میلویئر انفیکشن سے بچنے کے ساتھ کمزوریوں کو ٹھیک کرنے کے لئے اپ ڈیٹ کرنے میں صلح کرنا چاہئے۔ ٹولنگ یہاں مدد کر سکتی ہے، (1) ترجیح دے کر کہ کون سی کمزوریاں واقعی اہم ہیں (قابل رسائی اور فائدہ اٹھانے کے قابل، حملہ آوروں کی طرف سے نشانہ بننے کے زیادہ خطرے کے ساتھ)، (2) ایسے ٹارگٹ ورژنز کا انتخاب کرنا جو موجودہ اجزاء کے استعمال کے ساتھ مطابقت رکھتے ہوں اور سافٹ ویئر کو نہ توڑتے ہوں، (3) ایسے ٹارگٹ ورژنز کو منتخب کر کے جن میں بدنیتی پر مشتمل نہ ہو، اور (4) ڈائریکٹ ورژن کو اپ ڈیٹ کرنے کے لیے براہ راست رویے پر منحصر ہوں۔ مینی فیسٹ فائلوں میں تبدیلیاں تجویز کرنا جو فوری طور پر منظور کی جا سکتی ہیں۔ مرحلہ (3) کو نقصان دہ اجزاء کے بارے میں خاص معلومات کی ضرورت ہے جتنا ممکن ہو ان کی اشاعت کے وقت کے قریب۔
انحصار کو اپ ڈیٹ کرنے کا یہ عمل ہونا چاہیے۔ نافذ کیا اور تصدیق تمام جگہوں پر. اس عمل کا دستاویزی ہونا ضروری ہے، اور اس میں شامل تمام فریقین کو تربیت دی جانی چاہیے، کیونکہ اکثر ترقی اور سافٹ ویئر کی تعمیر/تعینات کو بیرونی بنایا جاتا ہے۔ دی CI/CD pipelines میں اسی کے مطابق ترمیم کی جانی چاہئے، لہذا آٹومیشن نقصان دہ بالواسطہ انحصار کو تعمیر میں پھسلنے کی اجازت نہیں دیتا: guardrails اگر انحصار میں ممکنہ میلویئر کے کافی ثبوت موجود ہیں تو تعمیر کو روکنا تجویز کردہ طریقہ ہے۔
اگر آپ کی تنظیم کے پاس ایک داخلی رجسٹری ہے جو اجازت شدہ اجزاء کے ورژن کو رکھنے کے لیے سیکیورٹی پراکسی کے طور پر کام کرتی ہے، تو آپ کو الاؤنس کی فہرست میں شامل کرنے سے پہلے درخواست کردہ جزو کی جانچ کے لیے نقصان دہ اجزاء (دوسرے معیار کے علاوہ) پر انٹیلی جنس حاصل کرنا ہوگی۔
سیفٹی کے ساتھ اوپن سورس سافٹ ویئر کا استعمال آسان نہیں ہے، اور میلویئر فیکٹر کو مکمل طور پر دھیان میں رکھنا چاہیے، اسی طرح کی کوششوں کے ساتھ خطرے سے نمٹنے کے لیے بھی۔
ایک آخری نوٹ: ماخذ کی بنیاد, سافٹ ویئر کی تصدیق کی شکل میں، جو جزو کی تعمیر کے وقت پیدا ہوتا ہے، ماخذ کے ساتھ آرٹفیکٹ (اجزاء ٹربال) کو ٹریس کرنے اور اسے تیار کرنے والے عمل کو بنانے کی کوشش میں ایک اور اہم حصہ ہے۔ نوٹ کریں کہ سورس اسنیپ شاٹ + بلڈ ماحول اور متعلقہ سافٹ ویئر آرٹفیکٹ کے درمیان یہ ربط (قابل اعتماد بلڈ سسٹم کے ذریعے دستخط شدہ) اس بات کو نہیں روکتا کہ جزو میں بدنیتی پر مبنی رویہ نہیں ہے، لیکن برے لوگوں کے لیے مالویئر کا انجیکشن لگانا مشکل بنا دیتا ہے۔ اور اوپن سورس اجزاء کو استعمال کرنے کے لیے پرووینس کی توثیق کو ایک عام ضرورت بنانے میں کافی وقت لگے گا، اور صرف حال ہی میں NPM میں شامل کیا گیا۔. ان قابل اعتماد بلڈ اینڈ ڈیپلائے سسٹمز کو ٹمپر پروف بنانا، یا بلڈ میں کسی بھی چھیڑ چھاڑ کا پتہ لگانے کے قابل بنانا اس پوسٹ کے دائرہ کار سے باہر ایک الگ کہانی ہے۔
مزید پڑھنے
اگلی قسط اوپن سورس نقصان دہ پیکجز: Xygeni اپروچ اس حکمت عملی کو پیش کریں گے جس پر ہم Xygeni پر عمل پیرا ہیں۔ میلویئر کی ابتدائی وارننگ (MEW) سسٹم۔ عوامی پیکیج اور تصویری رجسٹریوں میں نئے پیکیج ورژن کو اسکین کیا جاتا ہے اور جامد، متحرک، صلاحیتوں، اور سیاق و سباق کے تجزیے کے امتزاج کا استعمال کرتے ہوئے ثبوت حاصل کیے جاتے ہیں۔ ثبوت، صارف کی ساکھ اور سورس کوڈ کے ذخیروں میں تبدیلیوں کی تاریخ کے ساتھ مل کر، کسی جزو کی اعلیٰ خطرے اور ممکنہ طور پر بدنیتی پر مبنی زمروں میں مکمل خودکار درجہ بندی کی اجازت دیتا ہے۔ سسٹم غلط مثبت کو کم سے کم کرنے کے لیے پیکجوں سے جمع کیے گئے ماضی کے شواہد سے سیکھتا ہے۔
سبسکرائب شدہ تنظیموں کو ان اجزاء کے لیے ایک انتباہی اطلاع موصول ہوتی ہے جو وہ استعمال کر رہے ہیں، براہ راست یا بالواسطہ، جب کسی نقصان دہ ورژن کی درجہ بندی کی جاتی ہے۔ پھر ہمارے تجزیہ کاروں کے ذریعہ ایک دستی تجزیہ کیا جاتا ہے، جو درجہ بندی کی تصدیق یا رد کرتا ہے۔ تصدیق شدہ میلویئر کے لیے، عوامی رجسٹری کو مطلع کیا جاتا ہے تاکہ وہ خود اپنا تجزیہ کر سکے اور عام طور پر نقصان دہ ورژن کو ہٹا سکے یا اضافی کارروائی کر سکے، جیسے کہ زیر بحث صارف اکاؤنٹ کو بلاک کرنا یا ہٹانا۔
ہم اس بات کی وضاحت کریں گے کہ ہم اوپن سورس ایکو سسٹم میں NPM، PyPI، GitHub، اور دیگر کلیدی انفراسٹرکچر کی مدد کیسے کر رہے ہیں تاکہ شائع ہونے والے نئے نقصان دہ جزو کے فعال رہنے کے وقت کو کم کیا جا سکے جب تک کہ میلویئر کی تصدیق نہیں ہو جاتی اور اسے رجسٹری سے ہٹا دیا جاتا ہے۔ اور کس طرح تنظیمیں MEW سسٹم سے فائدہ اٹھا سکتی ہیں تاکہ اوپن سورس اجزاء پر مشتمل سافٹ ویئر سپلائی چین حملوں کے خلاف بہتر تحفظ حاصل کیا جا سکے۔
- ہے [1] بہر حال، اجزاء کے استعمال کنندگان کو یہ چیک کرنے کی ضرورت ہے کہ آیا جزو ٹربال کہیں محفوظ ہے یا رجسٹرڈ ہے، مثال کے طور پر اندرونی رجسٹری میں، تاکہ بیماری ختم ہوجائے۔
- ہے [2] پیکیج شدہ اجزاء میں ایک مینی فیسٹ شامل ہوتا ہے جو اس کے مواد اور میٹا ڈیٹا، سورس یا مرتب شدہ کوڈ، انسٹالیشن اسکرپٹس، اور اضافی آئٹمز جیسے ٹیسٹ سویٹس کا اعلان کرتا ہے، پیکیجنگ فارمیٹ کے مطابق اور عام طور پر کمپریسڈ شکل میں۔ اسے "جزو ٹربال" کہا جاتا ہے۔
- ہے [3] یہاں تک کہ اگر بدنیتی پر مبنی اداکار رجسٹری میں ہی خلاف ورزی کی وجہ سے شائع شدہ جزو میں ترمیم کر سکتا ہے، تو ایک سادہ پرانا کرپٹوگرافک ڈائجسٹ تجزیہ کرنے کے بعد ٹربال میں کسی بھی تبدیلی کا پتہ لگا سکتا ہے۔
- ہے [4] یاد رکھیں کہ کچھ نقصان دہ اجزاء انسٹال کے وقت چلتے ہیں، لہذا یہ ڈویلپر نوڈس کو متاثر کر سکتا ہے جو نادانستہ طور پر "npm install X" کو X کے ساتھ ایک نقصان دہ جزو چلاتے ہیں۔
