کشف یک باگ امنیتی در سیستم اینترنتی بانک ملت؛ تشریح دلایل فنی و شیوه های پیشگیری

امنیت در فضای مجازی همیشه از اهمیت زیادی بهره مند بوده. هممون تلاش می کنیم با رعایت راه و چاه هایی خاص از حریم شخصی خود مراقبت کنیم و اجازه ندیم تا اطلاعاتمون به دست آدمایی سود جو بیفته.

این وسط بانکا، به عنوان نهادایی که با موضوعی حساس مثل تراکنشای مالی سر و کار دارن، باید موضوع امنیت رو بسیار جدی گرفته و تموم تلاش خود رو جهت مراقبت از اطلاعات کاربران، به کار بندند.

در چند ساعت گذشته اینترنت فارسی پر شده از توییتایی در مورد بانک ملت و یه اشکال امنیتی که در سیستم این مجموعه کشف شده.

در همین رابطه، جادی میرمیرانی، مشاور امنیت و IT، توضیحاتی رو در مورد این باگ و دلایل بروز اون به رشته تحریر درآورده و همراه با راه حلای خود، ضعف امنیتی بانک ملت رو مورد بررسی قرار داده.

در ادامه با سایت ما همراه باشین.

در فرآیندای اینترنت بانک ملت، لینکی تولید می شه که در انتهای اون اینجور عبارتی هست: SaleOrderId=1333683 . این لینک شامل اطلاعات مربوط به تراکنش مالیه و مواردی مثل مبلغ انتقال یافته و نام کاربر رو به نمایش در می آرود.

معمولا مشاهده اینجور لینکایی لازمه ورود به حساب کاربریه، اما در بانک ملت، هر کاربری در اینترنت با داشتن لینک نامبرده، می تونه اطلاعات تراکنش شما رو مشاهده کنه.

اما مشکل اصلی جایی دیگه س. هر کاربر با تعویض عددای پایانی عبارت نامبرده، می تونه به لینکی جدید دست پیدا کنه و از این روش اطلاعات تراکنش دیگه کاربران رو هم مشاهده کنه.

با اینحال باگ، تنها یه اسکریپت بسه تا اطلاعات هزاران کاربر به شکل لیستی بلند بالا منتشر شه. اسکریپت نامبرده فقط کافیه اعداد ۱ تا ۹۹۹۹۹۹۹۹ رو در آخر لینک نامبرده، جای گذاری کنه.

اما این عدد در آخر لینک تراکنش به چه منظور ایجاد شده؟ میدونیم که تقریبا تموم برنامه ها با متغیرا سر و کار دارن و جهت ایجاد رابطه بین کاربر و صفحات جور واجور نیازه تا اینجور عددایی رد و بدل شه.

مثلا اگه کاربر تراکنش شماره ۱۳۳۳۶۸۳ رو انجام داده باشه و بانک بخواد امکان چاپ سند رو در اختیار اون بذاره، باید به سیستم اعلام کنه که تراکنش شماره ۱۳۳۳۶۸۳ رو واسه چاپ آماده سازه.

در نتیجه اینجور فرآیندی، باگ نامبرده به وجود میاد. اما چیجوری میشه از بروز این ضعف امنیتی، جلوگیری کرد؟

امنیت از راه نامفهومی

بعضی وقتا برنامه نویس یا طراح، تلاش می کنه امنیت رو اینجور تأمین کنه: «انشاءالله کسی پیداش نمی کنه !»

این موضوع خیلی غریب نیس و در موارد بسیاری اتفاق میفته. در مورد بانک ملت هم میشه گفت که روند امنیتی ماجرا تا حد زیادی بدین شکل جلو رفته. در واقع برنامه نویس بانک ملت امیدوار بوده کسی نسبت به تعویض اعداد و تغییر آدرسا، اقدام نکنه.

باحال اینکه حتی با این سطح از خوشبینی، بازم اعمال پروتکلی سخت تر، ممکن بود. مثلا برنامه نویس می تونست ترتیبی دهد تا اعداد تک به تک بالا نرن و بدین شکل امکان دسترسی به لینکا، تا این حد آسون نشه.

به کار گیری شماره های تصادفی رو در کارتای بانکی می تونین ببینین. با به کار گیری این فوت وفن، تقریبا محاله که با تغییر بخشی از شماره یه کارت، بتونین به صورت اتفاقی به شماره کارت فردی دیگه، دست پیدا کنین.

اگه علاقه مند به مطالعه بیشتر در این مورد هستین، پیشنهاد می کنیم عبارت Parity Check رو در اینترنت جستجو کنین.

به کار گیری Post به جای Get

قدم بعدی در مخفی کردن اطلاعات و ایجاد امنیت از این روش، به کار گیری متدهای پست به جای متدهای گته.

در دنیای اینترنت واسه انتقال اطلاعات به صفحات دو روش جور واجور داریم؛ Get و Post.

در متدای گت انتقال اطلاعات در انتهای URL شکل میگیره. موضوعی که در بانک ملت هم اجرا شده و با به کار گیری اون کاربر خیلی راحت می تونه URL دریافتی رو عوض کنه.

اما در متدهای Post اطلاعات در انتهای نشانی نمیشه دیدشون و اطلاعات «داخل» درخواست شما به یه صفحه وب، منتقل می گردن.

باید دقت کنیم که به کار گیری Post تنها و فقط از به نمایش درآمدن روشن اطلاعات جلوگیری می کنه و در آخر کسی که کمی با وب آشنا باشه، می تونه نسبت به تغییرشون اقدام کنه.

بخشایی مثل Developer Tools و Inspect Elements در مرورگرای جور واجور، اطلاعات خوبی در این مورد رو در اختیار کاربر قرار میدن و در لینوکس هم برنامه هایی مثل curl راحتی می تونن فرما رو با روش پست، بفرسته.

هش کردن اطلاعات

واسه ایجاد ابهام بیشتر واسه هکرا، تقریبا تموم اطلاعات باید به صورت هش شده ارائه شن. هش کردن اطلاعات معنیش اینه که با به کار گیری یه الگوریتم یه طرفه، متنی تبدیل به متنی دیگه شه. در این روش کوچیکترین تغییری در متن اول، باید باعث تغییراتی بزرگ در متن دوم شه.

حوادث گذشته در وبسایتای ایرونی نشون داده که این اصل اول نگهداری از اطلاعات حساس، هیچوقت رعایت نمی شه. بر همین پایه لازم می بینیم که توضیحات بیشتری رو در این رابطه، ارائه بدیم.

فرض کنین که ما مسئول نگه داری از پسورد شما هستیم. اگه این رمز عبور به شکل Password نگهداری شه، هر کسی که به دیتابیس دسترسی داشته باشه (چه یه هکر و چه یه مسئول بی اخلاق)، می تونه نگاهی به اطلاعات انداخته و فهمیده باشه که عبارت Password، رمز عبور شما هستش.

اما اگه از الگوریتمی مانند md5 جهت هش کردن استفاده شه، عبارت Password تبدیل می شه به گزینه ای مثل ۲۹f33cab54c2a8858885b95d8fbb7ff1 .

نکته باحال در کارکرد الگوریتم md5، اینه که اگه رمز عبور شما به جای P بزرگ، دارای p کوچیک باشه، گزینه نامبرده به اینجور شکلی تبدیل می شه : ۲۸۶۷۵۵fad04869ca523320acce0dc6a4

در واقع همونطور که مشاهده می کنین، یه تغییر کوچیک در رمز عبور، عبارت رو به کل تغییر داده.

حالا شما قصد ورود به سایت رو دارین و پسورد خود رو وارد می کنین. ما باید چک کنیم و ببینیم که عبارت وارد شده همون رمز عبوریه که از شما داریم یا خیر. در دیتابیس عبارت ۲۹f33cab54c2a8858885b95d8fbb7ff1 به عنوان رمز عبور شما ثبت شده و از اونجایی که نمی شه هش رو برعکس کرد، ما نمی دونیم که دقیقا رمز عبور شما چیه.

راه حل اینه که از راه همون الگوریتم، هربار رمز عبور شما هش شه و اگه با عبارت ذخیره شده در دیتابیس مطابقت داشت، اجازه ورود براتون صادر شه.

همونطور که اشاره کردیم، کوچیکترین تغییری در پسورد وارد شده باعث می شه عبارت مورد نظر ما تغییراتی اساسی کنه و اینجوری امکان لاگین در اختیار شما قرار نگیره. ببینین:

اما ! اما چه اتفاقی میفته اگه ما تموم پسوردای هفت رقمی رو به الگوریتم md5 بدیم و همه هشای ممکن رو استخراج کنیم؟ در واقع بدین شکل با دیدن یه هش می تونیم خیلی راحت رمز عبور رو تشخیص بدیم.

واسه این موضوع راه حلی به نام Salt هست. با به کار گیری این فوت وفن، ما به الگوریتم یه عبارت مخصوص می دیم که از اون به عنوان نمک در بین هش کردن، استفاده کنه. در نتیجه اگه کسی بخواد به همون مزه مورد نظر ما برسه، باید دقیقا بدونه که چقدر نمک رو باید اضافه کنه.

اما برگردیم به سراغ بانک ملت. شاید تا حالا فهمیدین که برنامه نویس این مجموعه واسه جلوگیری از موضوع پیش اومده باید چیکار می کرده، اما محض اطمینان، دوباره توضیح می دیم.

برنامه نویس بانک ملت به جای پاس کردن دقیق عدد ۱۳۳۳۶۸۳، باید اونو با مقداری نمک، که تنها خودش از اون اطلاع داشت، هش می کرد و بعد اونو در دیتابیس ذخیره می کرد.

سیستم لاگین سنتی

حالا که از رمزای عبور سخن گفتیم، اجازه بدین در مورد لاگین هم صحبت کنیم. برداشت هممون از قدم اول امنیت،لاگین کردنه و در ماجرای بانک ملت، لاگین دست کم موضوعی بود که باید رعایت می شد.

همونطور که در اول مطلب هم اشاره کردیم، URL تراکنش بانک ملت، واسه تموم کاربران اینترنت قابل مشاهده است. اینجا سیستم اینترنتی بانک ملت باید لاگین بودن کاربران رو چک می کرد و اجازه نمی داد تا دیگه کاربران، اطلاعات URL نامبرده رو ببینن.

به نظر می رسه در سیستم الان رفتن به صفحه ای با اسم PaymentMassagePreview.aspx، باعث می شه تا یه برنامه دات نتی، متغیری به اسم SaleOrderId رو بخونه و با گشتن در داخل دیتابیس، اطلاعات مربوط به اون تراکنش رو نشون بده.

این در صورتیه که هر برنامه ای قبل از هر چیز باید مشخصات صدا زننده برنامه رو چک کنه و فقط اگه دسترسیای لازم وجود داشت، مجوزای لازم رو واسه ادامه کار صادر کنه.

لاگین پیشرفته OAuth

اما پله ای بالاتر هم هست. روشای امروزی معمولا براساس OAuth هستن.

در این فوت وفن یه جور ژتون ساخته می شه که با به کار گیری اون برنامه مرکزی می تونه دسترسیای جور واجور رو کنترل کنه. با این روش برنامه امنیتی مرکزی بانک، می تونه به اسکریپا اطلاع دهد که کاربر x حق انجام عملیات نامبرده رو داره یا خیر.

با این روش ضمن کاهش خطر شنود رمزهای عبور، سیستم کنترل حق دسترسی اپلیکیشنای جور واجور هم به شکلی واحد در میاد. تو یه معماری ایده آل، این اتفاق حتی واسه اجزای داخلی برنامه هم اتفاق می افته.

محدود کردن دسترسی در سیستم عامل

تو یه سیستم خوب، مدیر سیستم هم به عنوان فردی که سیستم عامل رو در کنترل خود داره، از اهمیتی بالایی برخورداره.

به نظر می رسه سیستم بانک ملت هم مثل بقیه شرکتای ایرونی، با asp نوشته شده باشه. سرور به احتمال زیاد ویندوزیه، اما بد نیس بدونین که در اینجور موارد حساسی در جهان، سرورای لینوکسی استفاده میشن تا امکان به کار گیری قابلیتای متعددشان جهت جلوگیری از حملات، در اختیار مدیر سیستم باشه.

در آزمایشای به عمل اومده، مشخص شده که سرور بانک ملت تا جایی که در توان داشته باشه، به درخواست هر کسی جواب مثبت میده. این موضوع در دنیای سرورا، خیلی موضوع مثبتی به حساب نمی ره.

نیازه تا واسه سرور بانک ملت، محدودیتایی جهت انجام دستورات تو یه دقیقه وضع شه. واقعیت اینه که هیچ کاربری درخواست چاپ بیشتر از ده تراکنش در دقیقه رو نمی ده.

باید گفت که علاوه بر برنامه نویس و طراح برنامه، مدیران سیستم هم موظف هستن در مقابله با اینجور مواردی آماده باشن.

جادی مشار IT، هکر، برنامه نویس، گیک و نویسنده تکنولوژیه. نوشته های دیگه اون در مورد باگ بانک ملت و نقشای یه پروژه که می تونستن جلوی مشکل بگیرن رو در وبلاگ اون می تونین، بخونین. 

Author: edame

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *