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

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

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

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

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

در ادامه با دیجیاتو همراه باشید.

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

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

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

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

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

برای مثال اگر کاربر تراکنش شماره 1333683 را انجام داده باشد و بانک قصد داشته باشد امکان چاپ سند را در اختیار او قرار دهد، باید به سیستم اعلام کند که تراکنش شماره 1333683 را برای چاپ آماده سازد.

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

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

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

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

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

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

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

استفاده از Post به جای Get

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

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

در متد های گت انتقال اطلاعات در انتهای URL صورت می پذیرد. موضوعی که در بانک ملت نیز پیاده سازی شده و با استفاده از آن کاربر به راحتی می تواند URL دریافتی را تغییر دهد.

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

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

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

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

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

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

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

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

نکته جالب در عملکرد الگوریتم md5، این است که اگر رمز عبور شما به جای P بزرگ، دارای p کوچک باشد، گزینه مذکور به چنین شکلی تبدیل می گردد : 286755fad04869ca523320acce0dc6a4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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