کمزوری اسکیننگ اور محفوظ ترقی۔ حصہ 1

اپنی پیشہ ورانہ سرگرمیوں کے ایک حصے کے طور پر، ڈویلپرز، پینٹسٹرز، اور سیکورٹی ماہرین کو Vulnerability Management (VM)، (Secure) SDLC جیسے عمل سے نمٹنا پڑتا ہے۔
ان فقروں کے نیچے مختلف طریقوں اور ٹولز کا استعمال کیا جاتا ہے جو آپس میں جڑے ہوئے ہیں، حالانکہ ان کے استعمال کنندگان مختلف ہیں۔

تکنیکی پیشرفت ابھی تک اس مقام تک نہیں پہنچی ہے جہاں انفراسٹرکچر اور سافٹ ویئر کی سیکیورٹی کا تجزیہ کرنے کے لیے ایک ٹول کسی شخص کی جگہ لے سکتا ہے۔
یہ سمجھنا دلچسپ ہے کہ ایسا کیوں ہے اور کن مسائل کا سامنا ہے۔

پروسیسنگ

کمزوری کے انتظام کے عمل کو بنیادی ڈھانچے کی حفاظت اور پیچ کے انتظام کی مسلسل نگرانی کے لیے ڈیزائن کیا گیا ہے۔
سیکیور ایس ڈی ایل سی عمل ("سیکیور ڈیولپمنٹ سائیکل") کو ڈیولپمنٹ اور آپریشن کے دوران ایپلیکیشن سیکیورٹی کو برقرار رکھنے کے لیے ڈیزائن کیا گیا ہے۔

ان پراسیسز کا ایک ایسا ہی حصہ Vulnerability Assessment Process ہے - Vulnerability Assessment، Vulnerability Scanning۔
VM اور SDLC اسکیننگ کے درمیان بنیادی فرق یہ ہے کہ پہلی صورت میں مقصد تھرڈ پارٹی سافٹ ویئر یا کنفیگریشن میں معلوم کمزوریوں کا پتہ لگانا ہے۔ مثال کے طور پر، ونڈوز کا پرانا ورژن یا SNMP کے لیے ڈیفالٹ کمیونٹی سٹرنگ۔
دوسری صورت میں، مقصد نہ صرف فریق ثالث کے اجزاء (انحصار) بلکہ بنیادی طور پر نئی مصنوعات کے کوڈ میں کمزوریوں کا پتہ لگانا ہے۔

یہ آلات اور نقطہ نظر میں فرق پیدا کرتا ہے۔ میری رائے میں، ایپلی کیشن میں نئی ​​کمزوریوں کو تلاش کرنے کا کام بہت زیادہ دلچسپ ہے، کیونکہ یہ فنگر پرنٹنگ ورژن، بینرز کو اکٹھا کرنے، زبردستی پاس ورڈز وغیرہ تک نہیں آتا ہے۔
ایپلیکیشن کی کمزوریوں کی اعلیٰ معیار کی خودکار اسکیننگ کے لیے، الگورتھم کی ضرورت ہوتی ہے جو ایپلیکیشن کے الفاظ، اس کے مقصد اور مخصوص خطرات کو مدنظر رکھتے ہوں۔

ایک انفراسٹرکچر سکینر کو اکثر ٹائمر سے تبدیل کیا جا سکتا ہے، جیسا کہ میں نے کہا ہے۔ avleonov. بات یہ ہے کہ، خالصتاً اعدادوشمار کے مطابق، اگر آپ نے ایک ماہ کے لیے، کہہ لیں، اپ ڈیٹ نہیں کیا ہے تو آپ اپنے انفراسٹرکچر کو کمزور سمجھ سکتے ہیں۔

فورم کے اوزار

سکیننگ، جیسے سیکورٹی تجزیہ، بلیک باکس یا وائٹ باکس کا استعمال کرتے ہوئے انجام دیا جا سکتا ہے۔

بلیک باکس

بلیک باکس اسکیننگ کے وقت، ٹول کو سروس کے ساتھ انہی انٹرفیسز کے ذریعے کام کرنے کے قابل ہونا چاہیے جن کے ذریعے صارف اس کے ساتھ کام کرتے ہیں۔

انفراسٹرکچر اسکینرز (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, وغیرہ) کھلے نیٹ ورک پورٹس کو تلاش کرتے ہیں، "بینرز" جمع کرتے ہیں، انسٹال کردہ سافٹ ویئر کے ورژنز کا تعین کرتے ہیں، اور ان ورژنز میں کمزوریوں کے بارے میں معلومات کے لیے ان کے علم کی بنیاد تلاش کرتے ہیں۔ وہ کنفیگریشن کی غلطیوں کا بھی پتہ لگانے کی کوشش کرتے ہیں جیسے ڈیفالٹ پاس ورڈز یا اوپن ڈیٹا تک رسائی، کمزور SSL سائفرز وغیرہ۔

ویب ایپلیکیشن سکینر (Acunetix WVS، Netsparker، Burp Suite، OWASP ZAP، وغیرہ) بھی معلوم اجزاء اور ان کے ورژن (مثال کے طور پر، CMS، فریم ورک، JS لائبریریوں) کی شناخت کر سکتے ہیں۔ اسکینر کے اہم مراحل رینگنا اور دھندلا ہونا ہے۔
رینگنے کے دوران، سکینر موجودہ ایپلیکیشن انٹرفیس اور HTTP پیرامیٹرز کے بارے میں معلومات اکٹھا کرتا ہے۔ دھندلاہٹ کے دوران، تبدیل شدہ یا تیار کردہ ڈیٹا کو تمام کھوئے گئے پیرامیٹرز میں داخل کیا جاتا ہے تاکہ غلطی کو ہوا دی جا سکے اور کسی خطرے کا پتہ لگایا جا سکے۔

اس طرح کے ایپلیکیشن اسکینرز کا تعلق بالترتیب DAST اور IAST کلاسز - ڈائنامک اور انٹرایکٹو ایپلیکیشن سیکیورٹی ٹیسٹنگ سے ہے۔

وائٹ باکس

وائٹ باکس اسکیننگ کے ساتھ مزید اختلافات ہیں۔
VM کے عمل کے حصے کے طور پر، اسکینرز (Vulners, Incecurity Couch, Vuls, Tenable Nessus, etc.) کو اکثر تصدیق شدہ اسکین کرکے سسٹم تک رسائی دی جاتی ہے۔ اس طرح، سکینر انسٹال شدہ پیکیج ورژن اور کنفیگریشن پیرامیٹرز کو نیٹ ورک سروس بینرز سے اندازہ لگائے بغیر براہ راست سسٹم سے ڈاؤن لوڈ کر سکتا ہے۔
اسکین زیادہ درست اور مکمل ہے۔

اگر ہم ایپلی کیشنز کی وائٹ باکس اسکیننگ (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs وغیرہ) کے بارے میں بات کرتے ہیں، تو ہم عام طور پر SAST کلاس کے مناسب ٹولز کے استعمال کے بارے میں بات کر رہے ہیں - Static Application Security Testing۔

مسائل

سکیننگ کے ساتھ بہت سے مسائل ہیں! مجھے ان میں سے اکثر کے ساتھ ذاتی طور پر سکیننگ اور محفوظ ترقی کے عمل کی تعمیر کے لیے سروس فراہم کرنے کے ساتھ ساتھ سیکیورٹی کے تجزیے کا کام کرتے وقت بھی نمٹنا پڑتا ہے۔

میں مسائل کے 3 اہم گروپوں کو اجاگر کروں گا، جن کی تصدیق مختلف کمپنیوں میں انجینئرز اور انفارمیشن سیکیورٹی سروسز کے سربراہوں کے ساتھ بات چیت سے ہوتی ہے۔

ویب ایپلیکیشن اسکیننگ کے مسائل

1. عمل درآمد میں دشواری۔ اسکینرز کو ہر ایپلیکیشن کے لیے تعینات، ترتیب دینے، اپنی مرضی کے مطابق بنانے، اسکینوں کے لیے ایک ٹیسٹ ماحول مختص کرنے اور اسے موثر بنانے کے لیے CI/CD کے عمل میں لاگو کرنے کی ضرورت ہے۔ دوسری صورت میں، یہ ایک بیکار رسمی طریقہ کار ہو گا جو صرف غلط مثبت پیدا کرے گا
2. اسکین کا دورانیہ۔ 2019 میں بھی، اسکینرز انٹرفیس کو ڈپلیکیٹ کرنے کا ناقص کام کرتے ہیں اور ہر ایک پر 10 پیرامیٹرز کے ساتھ ہزار صفحات کو اسکین کرنے میں دن گزار سکتے ہیں، ان کو مختلف سمجھتے ہوئے، حالانکہ ایک ہی کوڈ ان کے لیے ذمہ دار ہے۔ ایک ہی وقت میں، ترقی کے چکر کے اندر پیداوار میں تعیناتی کا فیصلہ جلد کیا جانا چاہیے۔
3. ناقص سفارشات۔ اسکینرز کافی عمومی سفارشات دیتے ہیں، اور ڈویلپر ان سے ہمیشہ یہ نہیں سمجھ سکتا کہ خطرے کی سطح کو کیسے کم کیا جائے، اور سب سے اہم بات یہ ہے کہ اسے ابھی کرنے کی ضرورت ہے، یا یہ ابھی تک خوفناک نہیں ہے۔
4. درخواست پر تباہ کن اثر۔ سکینرز کسی ایپلیکیشن پر DoS حملہ اچھی طرح سے انجام دے سکتے ہیں، اور بڑی تعداد میں ہستیوں کو بھی بنا سکتے ہیں یا موجودہ کو تبدیل کر سکتے ہیں (مثال کے طور پر، ایک بلاگ پر دسیوں ہزار تبصرے تخلیق کریں)، اس لیے آپ کو بغیر سوچے سمجھے پروڈکشن میں سکین شروع نہیں کرنا چاہیے۔
5. کمزوری کا پتہ لگانے کا کم معیار۔ اسکینرز عام طور پر پے لوڈز کی ایک مقررہ صف کا استعمال کرتے ہیں اور آسانی سے ایسی کمزوری کو کھو سکتے ہیں جو ایپلیکیشن کے معروف رویے کے منظر نامے میں فٹ نہیں ہوتا ہے۔
6. اسکینر ایپلیکیشن کے افعال کو نہیں سمجھتا ہے۔ سکینر خود نہیں جانتے کہ "انٹرنیٹ بینکنگ"، "ادائیگی"، "تبصرہ" کیا ہیں۔ ان کے لیے صرف روابط اور پیرامیٹرز ہیں، اس لیے ممکنہ کاروباری منطقی کمزوریوں کی ایک بڑی پرت پوری طرح سے بے نقاب رہتی ہے؛ وہ ڈبل رائٹ آف کرنے، ID کے ذریعے کسی اور کے ڈیٹا کی جاسوسی، یا راؤنڈنگ کے ذریعے بیلنس بڑھانے کے بارے میں نہیں سوچیں گے۔
7. سکینر صفحات کے الفاظ کو نہیں سمجھتا۔ اسکینرز اکثر پوچھے گئے سوالات کو نہیں پڑھ سکتے، کیپچز کو نہیں پہچان سکتے، اور وہ خود یہ نہیں جان پائیں گے کہ کیسے رجسٹر ہوں اور پھر دوبارہ لاگ ان کریں، کہ آپ "لاگ آؤٹ" پر کلک نہیں کر سکتے اور پیرامیٹر تبدیل کرتے وقت درخواستوں پر دستخط کیسے کریں اقدار نتیجے کے طور پر، ہو سکتا ہے کہ زیادہ تر ایپلیکیشن بالکل بھی سکین نہ ہوں۔

سورس کوڈ کو اسکین کرنے میں دشواری

1. غلط مثبت۔ جامد تجزیہ ایک پیچیدہ کام ہے جس میں بہت سے تجارتی معاملات شامل ہیں۔ درستگی کو اکثر قربان کرنا پڑتا ہے، اور یہاں تک کہ مہنگے انٹرپرائز اسکینرز بھی بڑی تعداد میں غلط مثبت پیدا کرتے ہیں
2. عمل درآمد میں دشواری۔ جامد تجزیہ کی درستگی اور مکمل ہونے کے لیے، اسکیننگ کے اصولوں کو بہتر کرنا ضروری ہے، اور ان اصولوں کو لکھنا بہت زیادہ محنت طلب ہوسکتا ہے۔ بعض اوقات ایسے معاملات کا پتہ لگانے کے لیے کوئی اصول لکھنے کے بجائے کوڈ میں موجود تمام جگہوں کو کسی قسم کے بگ کے ساتھ تلاش کرنا اور انہیں ٹھیک کرنا آسان ہوتا ہے۔
3. انحصار کی حمایت کا فقدان۔ بڑے منصوبوں کا انحصار بڑی تعداد میں لائبریریوں اور فریم ورک پر ہوتا ہے جو پروگرامنگ زبان کی صلاحیتوں کو بڑھاتے ہیں۔ اگر اسکینر کے نالج بیس میں ان فریم ورکس میں موجود "ڈوبنے" کے بارے میں معلومات نہیں ہیں، تو یہ ایک اندھا دھبہ بن جائے گا اور اسکینر صرف کوڈ کو بھی نہیں سمجھ پائے گا۔
4. اسکین کا دورانیہ۔ کوڈ میں کمزوریوں کو تلاش کرنا الگورتھم کے لحاظ سے ایک پیچیدہ کام ہے۔ لہذا، اس عمل میں کافی وقت لگ سکتا ہے اور اس میں کمپیوٹنگ کے اہم وسائل درکار ہوتے ہیں۔
5. کم کوریج۔ وسائل کی کھپت اور اسکیننگ کے وقت کے باوجود، SAST ٹول ڈویلپرز کو اب بھی سمجھوتہ کرنا ہوگا اور ان تمام ریاستوں کا تجزیہ نہیں کرنا ہوگا جن میں پروگرام ہوسکتا ہے۔
6. نتائج کی تولیدی صلاحیت۔ مخصوص لائن اور کال اسٹیک کی طرف اشارہ کرنا جو خطرے کا باعث بنتا ہے بہت اچھا ہے، لیکن حقیقت میں، اکثر اسکینر اتنی معلومات فراہم نہیں کرتا ہے کہ باہر سے کسی خطرے کی موجودگی کی جانچ کر سکے۔ آخر کار، خرابی ڈیڈ کوڈ میں بھی ہو سکتی ہے، جو حملہ آور کے لیے ناقابل رسائی ہے۔

انفراسٹرکچر اسکیننگ کے مسائل

1. ناکافی انوینٹری۔ بڑے انفراسٹرکچر میں، خاص طور پر جو جغرافیائی طور پر الگ ہوتے ہیں، یہ جاننا اکثر مشکل ہوتا ہے کہ کون سے میزبانوں کو اسکین کرنا ہے۔ دوسرے الفاظ میں، سکیننگ کا کام اثاثہ جات کے انتظام کے کام سے گہرا تعلق رکھتا ہے۔
2. ناقص ترجیح۔ نیٹ ورک سکینر اکثر خامیوں کے ساتھ بہت سے نتائج پیش کرتے ہیں جن کا عملی طور پر فائدہ نہیں اٹھایا جا سکتا، لیکن رسمی طور پر ان کے خطرے کی سطح زیادہ ہوتی ہے۔ صارف کو ایک رپورٹ موصول ہوتی ہے جس کی تشریح کرنا مشکل ہے، اور یہ واضح نہیں ہے کہ پہلے کس چیز کو درست کرنے کی ضرورت ہے۔
3. ناقص سفارشات۔ اسکینر کے علم کی بنیاد اکثر کمزوری اور اسے ٹھیک کرنے کے طریقہ کے بارے میں صرف بہت عام معلومات پر مشتمل ہوتی ہے، اس لیے منتظمین کو خود کو گوگل کے ساتھ منسلک کرنا ہوگا۔ وائٹ باکس اسکینرز کے ساتھ صورتحال تھوڑی بہتر ہے، جو ٹھیک کرنے کے لیے ایک مخصوص کمانڈ جاری کر سکتی ہے۔
4. ہاتھ سے تیار کردہ۔ انفراسٹرکچر میں بہت سے نوڈس ہو سکتے ہیں، جس کا مطلب ہے ممکنہ طور پر بہت سی خامیاں، جن پر رپورٹس کو ہر تکرار پر دستی طور پر پارس اور تجزیہ کیا جانا چاہیے۔
5. ناقص کوریج۔ بنیادی ڈھانچے کی اسکیننگ کا معیار براہ راست کمزوریوں اور سافٹ ویئر ورژن کے بارے میں علم کی بنیاد کے سائز پر منحصر ہے۔ جس میں، یہ ثابت ہوتا ہے، یہاں تک کہ مارکیٹ کے رہنماؤں کے پاس بھی ایک جامع علمی بنیاد نہیں ہے، اور مفت حل کے ڈیٹا بیس میں بہت ساری معلومات ہوتی ہیں جو رہنماؤں کے پاس نہیں ہوتی ہیں۔
6. پیچ کے ساتھ مسائل. اکثر، بنیادی ڈھانچے کی کمزوریوں کو پیچ کرنے میں پیکج کو اپ ڈیٹ کرنا یا کنفیگریشن فائل کو تبدیل کرنا شامل ہوتا ہے۔ یہاں بڑا مسئلہ یہ ہے کہ ایک نظام، خاص طور پر میراثی، اپ ڈیٹ کے نتیجے میں غیر متوقع طور پر برتاؤ کر سکتا ہے۔ بنیادی طور پر، آپ کو پیداوار میں لائیو انفراسٹرکچر پر انضمام کے ٹیسٹ کروانے ہوں گے۔

نقطہ نظر

ть ° Рє же Р ± С ‹С‚СЊ؟
میں آپ کو مثالوں کے بارے میں مزید بتاؤں گا اور درج ذیل حصوں میں درج کئی مسائل سے کیسے نمٹنا ہے، لیکن فی الحال میں ان اہم سمتوں کی نشاندہی کروں گا جن میں آپ کام کر سکتے ہیں:

1. مختلف اسکیننگ ٹولز کا مجموعہ۔ متعدد اسکینرز کے درست استعمال سے، آپ علم کی بنیاد اور پتہ لگانے کے معیار میں نمایاں اضافہ حاصل کر سکتے ہیں۔ آپ کو الگ الگ لانچ کیے گئے تمام اسکینرز کی مجموعی تعداد سے بھی زیادہ کمزوریاں مل سکتی ہیں، جب کہ آپ خطرے کی سطح کا زیادہ درست اندازہ لگا سکتے ہیں اور مزید سفارشات کر سکتے ہیں۔
2. SAST اور DAST کا انضمام۔ ان کے درمیان معلومات کا تبادلہ کرکے DAST کی کوریج اور SAST کی درستگی کو بڑھانا ممکن ہے۔ ذرائع سے آپ موجودہ راستوں کے بارے میں معلومات حاصل کر سکتے ہیں، اور DAST کا استعمال کرتے ہوئے آپ چیک کر سکتے ہیں کہ آیا کمزوری باہر سے دکھائی دے رہی ہے۔
3. مشین لرننگ™۔ 2015 میں I بتایا (اور مزیدسکینرز کو ہیکر کی بصیرت دینے اور ان کی رفتار بڑھانے کے لیے اعدادوشمار کے استعمال کے بارے میں۔ یہ یقینی طور پر مستقبل میں خودکار سیکیورٹی تجزیہ کی ترقی کے لیے چارہ ہے۔
4. آٹوٹیسٹ اور اوپن اے پی آئی کے ساتھ IAST کا انضمام۔ CI/CD پائپ لائن کے اندر، ایسے ٹولز کی بنیاد پر سکیننگ کا عمل بنانا ممکن ہے جو HTTP پراکسی اور فنکشنل ٹیسٹ کے طور پر کام کرتے ہیں جو HTTP پر کام کرتے ہیں۔ OpenAPI/Swagger ٹیسٹ اور معاہدے اسکینر کو ڈیٹا کے بہاؤ کے بارے میں گمشدہ معلومات فراہم کریں گے اور مختلف ریاستوں میں درخواست کو اسکین کرنا ممکن بنائیں گے۔
5. درست ترتیب۔ ہر ایپلیکیشن اور انفراسٹرکچر کے لیے، آپ کو انٹرفیس کی تعداد اور نوعیت اور استعمال کی جانے والی ٹیکنالوجیز کو مدنظر رکھتے ہوئے ایک مناسب اسکیننگ پروفائل بنانے کی ضرورت ہے۔
6. اسکینر حسب ضرورت۔ اکثر اسکینر میں ترمیم کیے بغیر ایپلیکیشن کو اسکین نہیں کیا جاسکتا۔ ایک مثال ادائیگی کا گیٹ وے ہے، جس میں ہر درخواست پر دستخط کرنا ضروری ہے۔ گیٹ وے پروٹوکول میں کنیکٹر لکھے بغیر، اسکینرز غلط دستخط کے ساتھ درخواستوں پر بلاوجہ بمباری کریں گے۔ مخصوص قسم کے عیب کے لیے خصوصی سکینر لکھنا بھی ضروری ہے، جیسے غیر محفوظ براہ راست آبجیکٹ حوالہ
7. رسک مینجمنٹ. مختلف اسکینرز کا استعمال اور اثاثہ جات کے انتظام اور خطرے کے انتظام جیسے بیرونی نظاموں کے ساتھ انضمام خطرے کی سطح کا اندازہ لگانے کے لیے بہت سے پیرامیٹرز کے استعمال کی اجازت دے گا، تاکہ انتظامیہ ترقی یا انفراسٹرکچر کی موجودہ سیکیورٹی حالت کی مناسب تصویر حاصل کر سکے۔

دیکھتے رہیں اور آئیے خطرے کی اسکیننگ میں خلل ڈالیں!

ماخذ: www.habr.com