چه‌شده؟ و چه باید کرد؟

مروری بر چند موضوع به بهانه نفوذ به سامانه بانکی ۱۴۰۳

مقدمه

هکرها ۲۰ بانک ایرانی را هک کردند و برای منتشر نکردن اطلاعات مشتریان بانک‌ها، سه میلیون دلار باج گرفتند!

  • پولتیکو به نقل از منابع مطلع گزارش داده که حمله سایبری ماه گذشته که تهدیدی برای ثبات سیستم بانکداری ایران بود موجب شد که شرکت تامین کننده خدمات الکترونیکی برای بانک‌های ایران (شرکت توسن) به هکرها میلیون‌ها دلار باج پرداخت کند.
  • براساس این  گزارش ، این شرکت ایرانی تحت فشار دولت دست‌کم سه میلیون دلار به عنوان باج پرداخت کرد تا از انتشار داده‌های ۲۰ بانک ایران و اطلاعات حساب میلیون‌ها ایرانی جلوگیری کند.
  • به گزارش پولتیکو، این بدترین حمله سایبری به بانک‌های ایران به‌شمار می‌رود و گروهی تحت عنوان «آی‌آر‌لیکس» (IRLeaks) که سابقه هک بانک‌های ایران را دارد، احتمالا پشت این حمله قرار دارد. این گروه هکری در ماه دسامبر نیز اطلاعات بیش از ۲۰ شرکت بیمه و اسنپ فود را هک کرده بود.
  • مقامات می‌گویند هکرها در این ماجرا هم از شرکت‌ها پول گرفتند اما این مبالغ بسیار کمتر از باجی بود که بابت هک سیستم بانکی دریافت کردند.
  • هکرها تهدید کرده بودند اگر ۱۰ میلیون دلار رمزارز دریافت نکنند داده‌ها، شامل اطلاعات حساب و کارت اعتباری میلیون‌ها ایرانی را در دارک وب به فروش می‌گذارند. براساس این گزارش، در نهایت توافق بر سر میزان کمتری باج به هکرها به نتیجه می‌رسد.
  • این گروه هکری از طریق شرکتی تحت عنوان «توسن» که به بخش مالی ایران خدمات دیجیتال ارایه می‌کند، وارد سرورهای بانک‌ها شدند. آنها توسن را به عنوان اسب تراوا (Trojan horse) استفاده کردند و اطلاعات بانک‌های خصوصی و دولتی را استخراج کردند. از ۲۹ موسسه مالی فعال، ۲۰ بانک هدف حمله قرار گرفتند. در بین این بانک‌ها نام بانک توسعه و معادن، بانک مهر، پست‌بانک ایران، بانک ایران زمین، بانک سرمایه، بانک ایران ونزوئلا، بانک دی، بانک شهر، اقتصاد نوین، بانک سامان و شعبه‌هایی در ایتالیا و آلمان به چشم می‌خورد.

پی‌نوشت مقدمه:

  1. در منبع خبر اشاره شده است که این حمله از نوع اسب تراوا بوده است درحالیکه این حمله اگر حقیقت داشته باشد در رده حملات زنجیره تأمین قرار می‌گیرد.
  2. مقامات مسئول و شرکت توسن هنوز هیچ واکنش رسمی در تایید یا تکذیب این خبر نشان نداده اند.
  3. احتمال اینکه این حمله از طریق محصول Exchange Server انجام شده باشد بسیار محتمل است ؛ محصولی سرشار از مشکلات امنیتی حل ناشدنی که حتی فاجعه CrowdStrike را برای خود مالک آن یعنی مایکروسافت ، رقم زد.

آشنایی سریع با حمله‌های زنجیره تأمین (Supply Chain Attacks)

  • فرض کنید یک هکر بخواهد سازمان شما را هک کند اما معماری امنیتی سازمان شما بگونه ایست که نفوذ مستقیم به آن بسیار سخت و تقریبا غیرممکن است. در اینجا هکر ناامید نشده و یکی از تامین کنندگان نرم افزاری شما را شناسایی و هک می کند. سپس کدهای مخرب و Backdoor را در محصولات نرم افزاری آن شرکت جاسازی می کند. وقتی که نسخه جدید نرم افزاری را که خریداری کرده اید در سازمان نصب می کنید در پشتی( Backdoor ) به سادگی در سازمان شما نصب شده و درها بر روی هکر باز می شود.

نمونه‌های معروف حملات زنجیره تأمین:

  • حمله SolarWinds: یکی از معروف‌ترین حملات زنجیره تأمین بود که در آن کد مخرب به‌روزرسانی نرم‌افزار مدیریت شبکه SolarWinds اضافه شد. این حمله به بسیاری از سازمان‌های بزرگ و دولتی دسترسی غیرمجاز داد و خسارات گسترده‌ای به بار آورد.
  • حمله NotPetya: این حمله با استفاده از نرم‌افزار حسابداری اوکراینی M.E.Doc منتشر شد و به سرعت به بسیاری از شرکت‌های بین‌المللی نفوذ کرد و خسارات مالی بزرگی ایجاد کرد.
  • در ادعای حمله اخیر صورت گرفته به بانکهای کشور سناریو به این صورت می تواند باشد که شرکت توسن به عنوان یک شرکت تامین کننده نرم افزار بانکی توسط هکرها شناسایی می شود. چارچوبهای امنیتی شرکتهای تامین کننده غالبا به اندازه بانک ها نیست و نفوذ به آنها به مراتب ساده تر است. هکرها به شرکت تامین کننده نفوذ می کنند و در پشتی را نصب کرده و سپس به طعمه های اصلی (بانک ها و سازمانهای بزرگ تر) نفوذ می کنند.
  • متاسفانه حملات زنجیره تأمین به دلیل استفاده از تأمین‌کنندگان معتبر و مورد اعتماد، معمولاً در سازمانهای قربانی بسیار دیر شناسایی می‌شوند.
  • ارزیابی و انتخاب دقیق تأمین‌کنندگان و نظارت بر زنجیره تأمین و ایجاد فرایندهایی برای اعتبارسنجی به‌روزرسانی‌ها می تواند تا حد زیادی این نوع حملات را کاهش دهد.
  • متاسفانه در اغلب بانکهای کشور، نرم افزارهای مرکزی بانکداری بطور کامل به تعداد محدودی شرکت برون سپاری شده‌اند درحالیکه تیم فناوری اطلاعت و امنیت بانک هیچگونه دخل و تصرف و حتی نظارت مناسبی بر مسائل امنیتی محصولات ندارند در حالیکه روئسای این سازمان‌ها مسئول مستقیم رویداد ها را دو گروه اشاره شده می‌دانند.

میدانستیم؟

  • بیش از دو سال است که متخصصان حوزه امنیت در رسانه‌های شخصی خود فریاد میزنند که Exchange Serverهای آسیب پذیر یک Post-exploitation framework بنام IceApple کشف شده که ساختاری پیمانه‌ای ( Modular Design ) دارد و در طراحی خود از 18 پیمانه مختلف بهره می برد. هریک از پیمانه‌های این Toolset یک وظیفه اصلی را برعهده دارند. (مثلا لیست کردن فایلها و فولدرها، سرقت رمزعبورها، دسترسی به اکتیو دایرکتوری و انتقال اطلاعات به بیرون و… )
  • هکرها با نفوذ به Exchange بلافاصله شروع به سوء استفاده نمی کنند بلکه ابتدا Hacktoolهای موردنظر خود (مثل IceApple) را نصب می‌کنند تا حتی بعد از نصب وصله‌های Exchange هم بتوانند ارتباط خود را با سیستم قربانی حفظ کنند.
  • همان موقع لیست Exchange Serverهای آسیب پذیر در ایران نشان می داد که سازمانهای مهم زیادی آسیب پذیری دارند از جمله یک بانک و یک شرکت‌ تولید کننده نرم افزارهای بانکی! (بخوانید توسن)
  • حمله زنجیره تأمین اخیر می توانسته از یک آسیب پذیری مثل این صورت گرفته باشد. درحالیکه ما تمام توانمان را برای اعمال محدودیتهای فراوان در واردات و استفاده از تجهیزات خارجی منعطف کرده ایم و درگیر مجوزهای لیست سیاه و لیست سفید شده ایم همزمان داریم از نقطه‌ای ضربات سنگینی را می خوریم که به فرایندها و رویه‌های جاری غلط و ضعف نیروی انسانی در حوزه امنیت مرتبط است و ربطی به تجهیزات ندارد.

چه کردیم؟

تکذیب یا سکوت! رویه رایج مسئولان در مواجهه با حملات سایبری

  • از سال ۱۳۹۹ تا به امروز بیش از ۷۰ مورد حمله سایبری و نشت اطلاعات گسترده در کشور گزارش شده است که از این تعداد ۱۹ مورد به طور کلی تکذیب و ۳۱ مورد با خودداری نهاد مسئول از اظهارنظر و واکنش همراه بوده است؛ رقمی که در مجموع حدود ۷۰ درصد از موارد انتشار اخبار مربوط به هک و سرقت اطلاعات را در بر می‌گیرد./ منبع
  • آن ۳۰ درصد باقی مانده هم اغلب هک هایی بوده اند که قابل انکار نبوده اند و مردم بطور مستقیم متوجه آن شده اند. (مثل هک شبکه سوخت کشور و راه آهن و شهرداری تهران و…)
  • در ماجرای هک بانک‌های کشور درحالیکه مسئولان و حتی شرکت توسن سیاست سکوت و یا تکذیب را در پیش گرفته اند رسانه های برون‌مرزی و معاند درحال ارائه تحلیل‌های مختلف و گاهی غلط از این ماجرا هستند. سکوت و عدم اطلاع رسانی به موقع دستگاه های مسئول در چنین مواردی زمینه ساز گسترش شایعات و باز کردن فضا برای جولان دادن رسانه‌ها خواهد شد.
  • هک شدن ننگ نیست و برای هر سازمانی با بالاترین استانداردهای امنیتی هم اتفاق می افتد. درصورت وقوع حمله سایبری بصورت پیش دستانه اطلاع رسانی کنیم تا امکان سوء استفاده کمتر شود. در شأن کشور نیست که مردم خبر یک نفوذ به این گستردگی را از یک نشریه برون‌مرزی ، بعد از چند هفته بشنوند.

چه باید کرد؟

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

دیگران چه میکنند؟

 نگاه سریع به قانون حفاظت از داده‌های عمومی اروپا (GDPR)

  • اگر یک بانک در اروپا هک شود و اطلاعات مشتریانش به دست هکرها بیفتد، این بانک باید بر اساس قانون حفاظت از داده‌های عمومی (GDPR) اقدامات زیر را انجام دهد:
  1. اطلاع‌رسانی به مقام‌های نظارتی: بر اساس ماده 33 قانون GDPR بانک موظف است طی 72 ساعت پس از آگاهی از نشت داده‌ها، موضوع را به مقام نظارتی مربوطه (مانند DPA) اطلاع دهد. اگر تاخیر بیشتری وجود داشته باشد، باید دلایل آن توجیه شود.
  2. اطلاع‌رسانی به افراد متأثر: اگر نقض داده‌ها ممکن است منجر به خطر جدی برای حقوق و آزادی‌های افراد شود (مانند افشای اطلاعات حساس)، بانک باید مشتریان آسیب‌دیده را در اسرع وقت مطلع کند (ماده 34). اطلاع‌رسانی باید به شیوه‌ای واضح و بدون ابهام باشد و شامل اطلاعاتی در مورد ماهیت داده‌های فاش شده و اقداماتی باشد که افراد می‌توانند برای محافظت از خود انجام دهند.
  3. اقدامات اصلاحی و محافظتی: بانک باید بلافاصله اقدامات لازم برای کاهش اثرات هک و جلوگیری از نقض‌های مشابه را انجام دهد. این اقدامات می‌تواند شامل افزایش امنیت سیستم‌ها، اصلاح حفره‌های امنیتی و همکاری با مقامات برای بررسی و رفع مشکلات باشد.
  4. مستندسازی و گزارش‌دهی: بر اساس GDPR، بانک باید تمام نقض‌های امنیتی را مستند کند، حتی اگر نیازی به اطلاع‌رسانی به افراد متأثر نباشد. این مستندات باید دلایل، تأثیرات و اقدامات اصلاحی انجام شده را شامل شود.
  • عدم رعایت این الزامات می‌تواند منجر به جریمه‌های سنگینی بر اساس GDPR شود، که ممکن است تا 20 میلیون یورو یا 4 درصد از درآمد جهانی سالانه بانک باشد، هرکدام که بیشتر باشد.

این مطلب گردآوری شده از نظرات متخصصین مختلف بخصوص علی کیایی‌فر و با دخل و تصرف منتشر شده. محمد میرشکار - تابستان ۱۴۰۳

پایان یادداشت/