19 جولائی 2019 کو، Capital One کو یہ پیغام موصول ہوا کہ ہر جدید کمپنی کو خوف ہے — ڈیٹا کی خلاف ورزی ہوئی ہے۔ اس سے 106 ملین سے زیادہ لوگ متاثر ہوئے۔ 140 امریکی سوشل سیکیورٹی نمبرز، 000 لاکھ کینیڈین سوشل سیکیورٹی نمبر۔ 80 بینک اکاؤنٹس۔ ناخوشگوار، کیا آپ متفق نہیں ہیں؟
بدقسمتی سے، ہیک 19 جولائی کو نہیں ہوا۔ جیسا کہ یہ پتہ چلتا ہے، Paige Thompson، a.k.a. غلطی، 22 مارچ اور 23 مارچ 2019 کے درمیان اس کا ارتکاب کیا۔ یہ ہے کہ تقریبا چار مہینے پہلے. درحقیقت، یہ صرف بیرونی کنسلٹنٹس کی مدد سے ہی تھا کہ کیپٹل ون یہ دریافت کرنے میں کامیاب ہوا کہ کچھ ہوا ہے۔
ایمیزون کے ایک سابق ملازم کو گرفتار کر لیا گیا اور اسے $250 جرمانے اور پانچ سال قید کا سامنا کرنا پڑا... لیکن ابھی بھی بہت ساری منفی باتیں باقی ہیں۔ کیوں؟ کیونکہ بہت سی کمپنیاں جو ہیکس کا شکار ہوئی ہیں سائبر کرائم میں اضافے کے درمیان اپنے بنیادی ڈھانچے اور ایپلیکیشنز کو مضبوط بنانے کی ذمہ داری سے کنارہ کشی کرنے کی کوشش کر رہی ہیں۔
ویسے بھی آپ اس کہانی کو آسانی سے گوگل کر سکتے ہیں۔ ہم ڈرامے میں نہیں جائیں گے بلکہ بات کریں گے۔ تکنیکی معاملے کا پہلو.
سب سے پہلے، کیا ہوا؟
کیپیٹل ون میں تقریباً 700 S3 بالٹیاں چل رہی تھیں، جنہیں Paige Thompson نے کاپی کر کے نکال دیا۔
دوم، کیا یہ غلط کنفیگر شدہ S3 بالٹی پالیسی کا ایک اور معاملہ ہے؟
نہیں، اس بار نہیں۔ یہاں اس نے غلط طریقے سے کنفیگر شدہ فائر وال والے سرور تک رسائی حاصل کی اور وہاں سے پورا آپریشن کیا۔
رکو، یہ کیسے ممکن ہے؟
ٹھیک ہے، آئیے سرور میں لاگ ان کرکے شروعات کرتے ہیں، حالانکہ ہمارے پاس زیادہ تفصیلات نہیں ہیں۔ ہمیں صرف یہ بتایا گیا کہ یہ ایک "غلط کنفیگرڈ فائر وال" کے ذریعے ہوا ہے۔ لہذا، غلط سیکورٹی گروپ کی ترتیبات یا ویب ایپلیکیشن فائر وال (Imperva) یا نیٹ ورک فائر وال (iptables، ufw، shorewall، وغیرہ) کی ترتیب جیسی آسان چیز۔ کیپٹل ون نے صرف اپنے جرم کا اعتراف کیا اور کہا کہ اس نے سوراخ بند کر دیا ہے۔
سٹون نے کہا کہ کیپٹل ون نے ابتدائی طور پر فائر وال کی کمزوری کو محسوس نہیں کیا لیکن ایک بار اس کے علم میں آنے کے بعد فوری طور پر کام کیا۔ یہ یقینی طور پر اس حقیقت سے مدد ملی کہ ہیکر نے مبینہ طور پر اہم شناختی معلومات عوامی ڈومین میں چھوڑ دی، اسٹون نے کہا۔
اگر آپ سوچ رہے ہیں کہ ہم اس حصے کی گہرائی میں کیوں نہیں جا رہے ہیں، تو براہ کرم سمجھیں کہ محدود معلومات کی وجہ سے ہم صرف قیاس آرائیاں کر سکتے ہیں۔ اس سے کوئی مطلب نہیں ہے کہ ہیک کا انحصار کیپٹل ون کے چھوڑے ہوئے سوراخ پر تھا۔ اور جب تک وہ ہمیں مزید نہیں بتاتے، ہم صرف ان تمام ممکنہ طریقوں کی فہرست بنائیں گے جن کی وجہ سے Capital One نے اپنے سرور کو کھلا چھوڑ دیا تھا اور ان تمام ممکنہ طریقوں کے ساتھ جو کوئی ان مختلف اختیارات میں سے کسی ایک کو استعمال کر سکتا ہے۔ یہ خامیاں اور تکنیکیں انتہائی احمقانہ نگرانی سے لے کر ناقابل یقین حد تک پیچیدہ نمونوں تک ہوسکتی ہیں۔ امکانات کی حد کو دیکھتے ہوئے، یہ ایک طویل کہانی بن جائے گی جس کا کوئی حقیقی نتیجہ نہیں نکلے گا۔ لہذا، آئیے اس حصے کا تجزیہ کرنے پر توجہ مرکوز کریں جہاں ہمارے پاس حقائق ہیں۔
تو پہلا راستہ یہ ہے کہ: جانیں کہ آپ کے فائر وال کس چیز کی اجازت دیتے ہیں۔
اس بات کو یقینی بنانے کے لیے ایک پالیسی یا مناسب عمل قائم کریں کہ صرف وہی کھولا جائے جسے کھولنے کی ضرورت ہے۔ اگر آپ سیکیورٹی گروپس یا نیٹ ورک ACLs جیسے AWS وسائل استعمال کر رہے ہیں، تو ظاہر ہے آڈٹ کے لیے چیک لسٹ لمبی ہو سکتی ہے... لیکن جس طرح بہت سے وسائل خود بخود بن جاتے ہیں (یعنی کلاؤڈ فارمیشن)، ان کے آڈٹ کو خودکار کرنا بھی ممکن ہے۔ چاہے وہ گھریلو اسکرپٹ ہو جو خامیوں کے لیے نئی اشیاء کو اسکین کرتا ہے، یا CI/CD کے عمل میں سیکیورٹی آڈٹ جیسا کچھ... اس سے بچنے کے لیے بہت سے آسان آپشنز موجود ہیں۔
کہانی کا "مضحکہ خیز" حصہ یہ ہے کہ اگر کیپٹل ون نے پہلے سوراخ کو پلگ کیا ہوتا تو ... کچھ بھی نہ ہوتا۔ اور اس طرح، واضح طور پر، یہ دیکھنا ہمیشہ حیران کن ہوتا ہے کہ واقعی کچھ کیسے ہوتا ہے۔ بہت آسان کمپنی کے ہیک ہونے کی واحد وجہ بن جاتی ہے۔ خاص طور پر کیپٹل ون جتنا بڑا۔
تو، اندر ہیکر - آگے کیا ہوا؟
ٹھیک ہے، EC2 مثال کو توڑنے کے بعد... بہت کچھ غلط ہو سکتا ہے۔ اگر آپ کسی کو اتنی دور جانے دیتے ہیں تو آپ عملی طور پر چاقو کی دھار پر چل رہے ہیں۔ لیکن یہ S3 بالٹیوں میں کیسے آیا؟ اس کو سمجھنے کے لیے آئیے آئی اے ایم کے کردار پر بات کرتے ہیں۔
لہذا، AWS خدمات تک رسائی کا ایک طریقہ صارف بننا ہے۔ ٹھیک ہے، یہ ایک بہت واضح ہے. لیکن کیا ہوگا اگر آپ دیگر AWS خدمات، جیسے کہ آپ کے ایپلیکیشن سرورز، اپنی S3 بالٹی تک رسائی دینا چاہتے ہیں؟ IAM کے کردار اسی کے لیے ہیں۔ وہ دو اجزاء پر مشتمل ہیں:
- ٹرسٹ پالیسی - کون سی خدمات یا لوگ اس کردار کو استعمال کر سکتے ہیں؟
- اجازتوں کی پالیسی - یہ کردار کس چیز کی اجازت دیتا ہے؟
مثال کے طور پر، آپ ایک IAM کردار بنانا چاہتے ہیں جو EC2 مثالوں کو S3 بالٹی تک رسائی کی اجازت دے گا: سب سے پہلے، اس کردار میں ایک ٹرسٹ پالیسی رکھی گئی ہے جو EC2 (پوری سروس) یا مخصوص مثالیں اس کردار کو "حاصل" کر سکتی ہیں۔ کسی کردار کو قبول کرنے کا مطلب ہے کہ وہ اعمال انجام دینے کے لیے کردار کی اجازتوں کا استعمال کر سکتے ہیں۔ دوم، اجازتوں کی پالیسی اس سروس/شخص/وسائل کو اجازت دیتی ہے جس نے S3 پر کچھ بھی کرنے کا "کردار ادا کیا ہے"، چاہے وہ ایک مخصوص بالٹی تک رسائی ہو... یا 700 سے زیادہ، جیسا کہ کیپٹل ون کے معاملے میں ہے۔
ایک بار جب آپ IAM کردار کے ساتھ EC2 مثال میں آجاتے ہیں، تو آپ کئی طریقوں سے اسناد حاصل کر سکتے ہیں:
- آپ پر مثال کے میٹا ڈیٹا کی درخواست کر سکتے ہیں۔
http://169.254.169.254/latest/meta-dataدیگر چیزوں کے علاوہ، آپ اس ایڈریس پر رسائی کی کسی بھی کلید کے ساتھ IAM کا کردار تلاش کر سکتے ہیں۔ یقینا، صرف اس صورت میں جب آپ کسی مثال میں ہوں۔
- AWS CLI استعمال کریں...
اگر AWS CLI انسٹال ہے، اگر موجود ہو تو یہ IAM کرداروں سے اسناد کے ساتھ بھری ہوئی ہے۔ جو کچھ باقی ہے وہ مثال کے ذریعے کام کرنا ہے۔ بلاشبہ، اگر ان کی ٹرسٹ پالیسی کھلی تھی، Paige سب کچھ براہ راست کر سکتا تھا۔
لہذا IAM کرداروں کا خلاصہ یہ ہے کہ وہ کچھ وسائل کو دوسرے وسائل پر آپ کی طرف سے کام کرنے کی اجازت دیتے ہیں۔
اب جب کہ آپ IAM کے کردار کو سمجھ گئے ہیں، ہم اس بارے میں بات کر سکتے ہیں کہ Paige Thompson نے کیا کیا:
- اس نے فائر وال میں سوراخ کے ذریعے سرور (EC2 مثال) تک رسائی حاصل کی۔
چاہے یہ سیکیورٹی گروپس/ACLs ہوں یا ان کی اپنی ویب ایپلیکیشن فائر والز، ہول کو پلگ کرنا شاید کافی آسان تھا، جیسا کہ سرکاری ریکارڈ میں بتایا گیا ہے۔
- ایک بار سرور پر، وہ "گویا" کام کرنے کے قابل تھی کہ وہ خود سرور تھیں۔
- چونکہ IAM سرور کے کردار نے S3 کو ان 700+ بالٹیوں تک رسائی کی اجازت دی، اس لیے یہ ان تک رسائی حاصل کرنے کے قابل تھا۔
اس لمحے سے، اسے صرف کمانڈ چلانا تھا۔ List Bucketsاور پھر حکم Sync AWS CLI سے...
. اس طرح کے نقصان کو روکنے کے لیے کمپنیاں کلاؤڈ انفراسٹرکچر پروٹیکشن، DevOps اور سیکیورٹی ماہرین میں اتنی زیادہ سرمایہ کاری کیوں کرتی ہیں۔ اور بادل کی طرف بڑھنا کتنا قیمتی اور سرمایہ کاری مؤثر ہے؟ اتنا زیادہ کہ سائبرسیکیوریٹی کے زیادہ سے زیادہ چیلنجز کا سامنا کرتے ہوئے بھی !
کہانی کا اخلاق: اپنی حفاظت کی جانچ کریں۔ باقاعدہ آڈٹ کروائیں؛ سیکیورٹی پالیسیوں کے لیے کم سے کم استحقاق کے اصول کا احترام کریں۔
( آپ مکمل قانونی رپورٹ دیکھ سکتے ہیں)۔
ماخذ: www.habr.com