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

[saba mn 20993]

[h=1]

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

[/h]

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

به گزارش

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

؛ در چند ساعت اخیر اینترنت فارسی پر شده از توییت‌هایی در مورد بانک ملت و یک اشکال امنیتی که در سیستم این مجموعه کشف شده است. در همین رابطه، جادی میرمیرانی، مشاور امنیت و 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 نوشته شده باشد. سرور به احتمال زیاد ویندوزی است، اما بد نیست بدانید که در چنین موارد حساسی در جهان، سرورهای لینوکسی مورد استفاده قرار می‌گیرند تا امکان استفاده از قابلیت‌های متعددشان جهت جلوگیری از حملات، در اختیار مدیر سیستم باشد.

 

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