arrow-right-square Created with Sketch Beta.
کد خبر: ۱۹۵۹۶۵
تاریخ انتشار: ۲۲ : ۱۹ - ۰۵ فروردين ۱۳۹۴

کشف یک باگ امنیتی در سیستم اینترنتی بانک ملت

پایگاه خبری تحلیلی انتخاب (Entekhab.ir) :
امنيت در فضاي مجازي همواره از اهميت بسياري برخوردار بوده است. همه ما تلاش مي کنيم با رعايت دستورالعمل هايي خاص از حريم شخصي خود محافظت نماييم و اجازه ندهيم تا اطلاعاتمان به دست افرادي سود جو بيفتد.

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

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

در همين رابطه، جادي ميرميراني، مشاور امنيت و 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 به عنوان رمز عبور شما ثبت شده است و از آنجايي که نمي شود هش را معکوس کرد، ما نميدانيم که دقيقا رمز عبور شما چيست.

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

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

Screenshot from 2015-03-25 14_45_52

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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