اینڈرائیڈ پلیٹ فارم (CVE-2022-20465) میں ایک کمزوری کی نشاندہی کی گئی ہے، جو آپ کو سم کارڈ کو دوبارہ ترتیب دے کر اور PUK کوڈ داخل کرکے اسکرین لاک کو غیر فعال کرنے کی اجازت دیتا ہے۔ لاک کو غیر فعال کرنے کی صلاحیت کا مظاہرہ گوگل پکسل ڈیوائسز پر کیا گیا ہے، لیکن چونکہ یہ فکس مرکزی اینڈرائیڈ کوڈ بیس کو متاثر کرتا ہے، اس لیے امکان ہے کہ یہ مسئلہ دوسرے مینوفیکچررز کے فرم ویئر کو متاثر کرتا ہے۔ نومبر کے اینڈرائیڈ سیکیورٹی پیچ رول آؤٹ میں اس مسئلے کو حل کیا گیا ہے۔ اس مسئلے کی طرف توجہ دلانے والے محقق کو گوگل کی جانب سے 70 ہزار ڈالر کا انعام ملا۔
مسئلہ PUK کوڈ (پرسنل ان بلاک کرنے کی کلید) داخل کرنے کے بعد ان لاک کرنے کی غلط پروسیسنگ کی وجہ سے ہوتا ہے، جس کا استعمال ایک ایسے سم کارڈ کے آپریشن کو دوبارہ شروع کرنے کے لیے کیا جاتا ہے جسے بار بار PIN کوڈ کو غلط طریقے سے داخل کرنے کے بعد بلاک کیا گیا ہے۔ اسکرین لاک کو غیر فعال کرنے کے لیے، بس اپنے فون میں اپنا سم کارڈ انسٹال کریں، جس میں پن کوڈ کا تحفظ ہے۔ PIN کوڈ کے ذریعے محفوظ سم کارڈ کو تبدیل کرنے کے بعد، سب سے پہلے ایک PIN کوڈ کی درخواست اسکرین پر ظاہر ہوتی ہے۔ اگر آپ تین بار غلط طریقے سے پن کوڈ درج کرتے ہیں، تو سم کارڈ بلاک ہو جائے گا، جس کے بعد آپ کو اسے ان لاک کرنے کے لیے PUK کوڈ داخل کرنے کا موقع دیا جائے گا۔ یہ پتہ چلا کہ PUK کوڈ کو صحیح طریقے سے درج کرنے سے نہ صرف سم کارڈ کھل جاتا ہے، بلکہ مرکزی پاس ورڈ یا پیٹرن کا استعمال کرتے ہوئے رسائی کی تصدیق کیے بغیر، اسکرین سیور کو نظرانداز کرتے ہوئے، مرکزی انٹرفیس میں منتقلی کا باعث بنتا ہے۔
یہ خطرہ KeyguardSimPukViewController ہینڈلر میں PUK کوڈز چیک کرنے کی منطق میں خرابی کی وجہ سے ہے، جو اضافی تصدیقی اسکرین کو ظاہر کرنے کا ذمہ دار ہے۔ اینڈروئیڈ کئی قسم کی توثیق کرنے والی اسکرینوں کا استعمال کرتا ہے (PIN، PUK، پاس ورڈ، پیٹرن، بائیو میٹرک تصدیق کے لیے) اور ان اسکرینوں کو ترتیب وار کہا جاتا ہے جب ایک سے زیادہ چیک کرنے کی ضرورت ہوتی ہے، مثال کے طور پر، جب PIN اور پیٹرن کی ضرورت ہوتی ہے۔
اگر آپ PIN کوڈ صحیح طریقے سے درج کرتے ہیں، تو تصدیق کا دوسرا مرحلہ شروع ہو جاتا ہے، جس کے لیے آپ کو مرکزی انلاک کوڈ درج کرنے کی ضرورت ہوتی ہے، لیکن جب آپ PUK کوڈ داخل کرتے ہیں، تو یہ مرحلہ چھوڑ دیا جاتا ہے اور مرکزی پاس ورڈ یا پیٹرن کلید کے پوچھے بغیر رسائی دی جاتی ہے۔ . اگلا کھولنے کا مرحلہ مسترد کر دیا جاتا ہے کیونکہ KeyguardSecurityContainerController#dismiss() کو کال کرتے وقت متوقع اور منظور شدہ تصدیقی طریقوں کے درمیان کوئی موازنہ نہیں ہوتا، یعنی پروسیسر کا خیال ہے کہ تصدیق کا طریقہ تبدیل نہیں ہوا ہے اور PUK کوڈ کی تصدیق کا مکمل ہونا اتھارٹی کی کامیاب تصدیق کی نشاندہی کرتا ہے۔
کمزوری کا پتہ حادثاتی طور پر پایا گیا - صارف کا فون ڈیڈ تھا اور اسے چارج کرنے اور آن کرنے کے بعد اس نے پن کوڈ ڈالتے وقت کئی بار غلطی کی جس کے بعد اس نے اسے PUK کوڈ سے ان لاک کیا اور حیران رہ گیا کہ سسٹم نے پوچھا ہی نہیں۔ ڈیٹا کو ڈکرپٹ کرنے کے لیے استعمال ہونے والے مرکزی پاس ورڈ کے لیے، جس کے بعد یہ پیغام "پکسل شروع ہو رہا ہے..." کے ساتھ منجمد ہو گیا۔ صارف محتاط نکلا، اس نے یہ جاننے کا فیصلہ کیا کہ کیا ہو رہا ہے اور اس نے مختلف طریقوں سے PIN اور PUK کوڈز داخل کرنے کا تجربہ کرنا شروع کر دیا، یہاں تک کہ وہ غلطی سے سم کارڈ تبدیل کرنے کے بعد ڈیوائس کو دوبارہ شروع کرنا بھول گیا اور اس کے بجائے ماحول تک رسائی حاصل کر لی۔ منجمد
خاص دلچسپی یہ ہے کہ خطرے کے اعلان پر گوگل کا ردعمل ہے۔ اس مسئلے کے بارے میں معلومات جون میں بھیجی گئی تھیں، لیکن ستمبر تک محقق ابھی تک کوئی واضح جواب حاصل کرنے سے قاصر تھا۔ اس کا خیال تھا کہ اس رویے کی وضاحت اس حقیقت سے ہوئی ہے کہ وہ اس غلطی کی اطلاع دینے والے پہلے فرد نہیں تھے۔ شکوک و شبہات کہ کچھ غلط ہو رہا ہے ستمبر میں پیدا ہوا، جب 90 دن بعد جاری کردہ فرم ویئر اپ ڈیٹ انسٹال کرنے کے بعد مسئلہ درست نہیں ہوا، جب بیان نہ کرنے کی مدت پہلے ہی ختم ہو چکی تھی۔
چونکہ اس مسئلے کے بارے میں بھیجے گئے پیغام کی حیثیت جاننے کی تمام کوششیں صرف خودکار اور ٹیمپلیٹ جوابات کا باعث بنی، اس لیے محقق نے گوگل کے ملازمین سے ذاتی طور پر رابطہ کرنے کی کوشش کی تاکہ حل کی تیاری کے ساتھ صورتحال کو واضح کیا جا سکے اور یہاں تک کہ گوگل کے لندن آفس میں خطرے کا مظاہرہ کیا۔ . اس کے بعد ہی کمزوری کو ختم کرنے کے لیے کام آگے بڑھا۔ تجزیہ کے دوران، یہ پتہ چلا کہ کسی نے پہلے ہی مسئلہ کی اطلاع دی تھی، لیکن گوگل نے ایک استثناء کرنے کا فیصلہ کیا اور مسئلہ کو دوبارہ رپورٹ کرنے پر انعام ادا کیا، کیونکہ یہ صرف اس کے مصنف کی ثابت قدمی کی بدولت تھا کہ مسئلہ محسوس کیا گیا تھا.
ماخذ: opennet.ru