چند روز پیش ، گروه هکری گنجشک درنده، دومین حمله ی خودش رو به زیرساخت های سوخت کشور انجام داد و منجر به اختلال در ارائه خدمات در جایگاههای سوخت شدن.
این گروه در سال 1400/2021 هم ، حمله ای به زیرساخت های سوخت ایران انجام داده بودن. اون زمان ، آقای حمید کشفی بهمراه J. A. Guerrero-Saade ، رو این حادثه کار کردن و یه گزارشی در خصوص این حادثه تهیه کردن. اما بدلیل اینکه سیستم های آسیب پذیر هنوز در معرض دید بودن، گزارش رو منتشر نکردن. اما بعد از دو سال که این حادثه دوباره رخ داده، این گزارش رو بصورت عمومی منتشر کردن.
در این سری از پستها، این گزارش رو در قالب 4 قسمت منتشر کردیم:
- قسمت اول: معماری سیستم هوشمند سوخت
- قسمت دوم : بردارهای حمله ی بالقوه
- قسمت سوم : بررسی حادثه
- قسمت چهارم: OSINT و ردپای اولیه
این گزارش توسط حمید کشفی ، Juan Andrés ، Silas Cutler و یسری محقق دیگه که ترجیح دادن ناشناس بمونن ، تهیه شده. برای دانلود این گزارش به زبان انگلیسی میتونید از این لینک، یا کانال تلگرامی ما استفاده کنید.
بلافاصله بعد از انتشار اخبار، محققا سعی کردن بردارهای احتمالی حمله رو شناسایی کنن. برای این منظور محققا باید اولش یه درک درستی از نحوه ی اجرای سیستم بدست می آوردن ، یعنی چه کسی و چی سیستم رو اجرا میکنه. در قدم اول رفتن سراغ حل معمای چه کسی.
شرکت پخش فرآورده های نفتی ایران (NIOPDC) هر از گاهی برای برون سپاری تعمیرات و نگهداری و خرید و فروش عمده اقدام به انتشار آگهی مناقصه میکنه. این مناقصات از الزامات قانونی هست و باید در روزنامه های رسمی چاپ بشن و البته بصورت آنلاین هم آرشیو شدن.
وب سایت PARS NAMAD DATA یکی از این آرشیوهای آنلاینه که محققا با استفاده از چند کلمه کلیدی تونستن نتایجی جالبی برای چه کسی و چی پیدا کنن. بنابراین میشه فهمید که محصولات Ingenico در جایگاههای سوخت مورد استفاده قرار میگیرن. مثلا در یه آگهی Ingenico 19400 درج شده که البته درستش i9400 هستش.
این یافته همچنین با برخی از اطلاعات منتشر شده آنلاین در همون زمان در توییتر مطابقت داره. با این حال، تصاویر ارسال شده فاقد هرگونه جزئیات قابل استفاده مانند شماره FCC یا شماره سریال هستن. تنها اطلاعات قابل مشاهده و مفید، نام تجاری و شکل ظاهری بورد بود. محققا تونستن با جستجوی مدل‌های مرتبط، دفترچه راهنمای کاربر، و حتی جزئیات ظاهری بورد، از FCCهای مربوطه که توسط Ingenico ثبت شدن، درباره معماری محصولات Ingenico چیزای زیادی یاد بگیرن.
محققا با بررسی آگهی های مناقصه به یه شرکت از زیرمجموعه بانک ملت رسیدن که مسئول رسیدگی به سرویس های VSAT هستش. از این روش (جستجوی مناقصه ها) میشه تقریبا همه ی تامین کنندگان سیستم هوشمند سوخت رو شناسایی کرد.
محققا همچنین احتمال میدن که اولین کسایی که به این رخداد پاسخ دادن، مهندسای NIOPDC بودن. برای افرادی که بطور حرفه ای آموزش فارنزیک ندیدن، ظبیعیه که ندونن ، نباید شواهد حادثه رو ، روی سرویس هایی مانند VirusTotal آپلود کنن. بنابراین محققا اومدن آپلودهای اخیر به این سرویسها از ایران و همچنین از CIDRهای IPv4 شناخته شده و ثبت شده برای NIOC و NIOPDC فیلتر کردن. در ابتدا نتایجی نداشته براشون اما مایوس نشدن و دوباره این کار کردن با این تفاوت که نهادهای بیشتری رو در این فیلتر اعمال کردن از جمله شرکتهایی که درگیر واردات و پشتیبانی در خصوص محصولات Ingenico هستن. در نتیجه به شرکت ایده نگار رسیدن که ادعا کرده ، محصولاتی مبتنی بر محصولات Ingenico برای سیستم پرداخت و مدیریت جایگاههای سوخت توسعه داده.
محققا چه (مدل های Ingenico) و چه کسی (ایده نگار) رو داشتن. بنابراین شروع به جستجو، در داده های آپلود شده در VirusTotal کردن.
محققا این جستجو رو براساس رشته و متادیتا و باینری تکرار کردن تا در نهایت به شناسایی سه خوشه اصلی و آپلود کننده رسیدن که دو موردش از دو نقطه جغرافیایی مختلف بودن که اغلب Memory Dump ها رو آپلود کردن و یه موردش هم یسری شل اسکریپت و باینری ویندوزی رو آپلود کردن که اغلبشون به حملات قبلی علیه ایران اختصاص داره.
مجموعه لیک ها :
محققا گفتن که اولش ، دنباله نمونه های بدافزاری بودن، اما کم کم مسئله براشون جالبتر شده. با افزایش تعداد و حجم آپلودها، محققا عمدتا روی رشته ها و درک باینری ها کار کردن. در این فرایند محققا نتونستن برخی از این باینری ها رو بعنوان فایل های استاندارد ELF و PE در معماری ARM یا X86 تجزیه و مهندسی معکوس کنن. در حقیقت محققا متوجه شدن که افراد ، شرکت ، یا نهاد دولتی مسئول پاسخ به رخداد ، در حقیقت داره ، Memory Dump های مرتبط با سرورهای عملیاتی سوخت در حادثه رو آپلود میکنه. این مثله اینه که یه نوشابه کوکاکولا بخوایید، اما فرمول تهیه اون رو دریافت کنید.
کار فارنزیک اصولا بصورت بسته و در یه محیط کنترل شده انجام میشه. وقتی زیرساخت های حساس یا نهاد دولتی ایران هک میشن، معمولا دولت علاقه ای به انتشار IOCها یا TTP حمله نداره. این یه روش رایج در ایرانه و بدلیل حفاظت از مالکیت معنوی و داده های حساس انجام میشه. اما در این رخداد محققا شاهد داده هایی بودن که از تیم های فارنزیک ارسال میشد.
محققا افتا رو بعنوان نهاد دولتی که مسئول این رخداد و رخدادهای مشابه هست و یه شرکت خصوصی که مسئول فارنزیک در این رخداد بود رو شناسایی کردن و سعی کردن باهاشون ارتباط بگیرن تا روند آنالیز و شناسایی رو با بدست آوردن نمونه های بیشتر سریعتر کنن. هر دو نهاد در ابتدا از اضهارنظر خودداری کردن و حتی دخالت خودشون رو هم رد کردن. محققا در ادامه یسری نمونه براشون ارسال کردن که منجر به عدم ارتباط مجدد شده و محققا هم از ادامه منصرف شدن. اما نکته جالب این بوده که همچنان داده ها آپلود میشدن. با این تفاسیر محققا به منبع اطلاعاتشون شک میکنن.
با توجه به شدت این اشتباه و نشت Dumpها ، محققا احتمال اینکه این نشت بصورت عمدی توسط مهاجمین یا شخص ثالث ناشناسی که داده هارو از مبدا ایران و فرانسه به سرویس هایی مانند VT آپلود میکنه رو هم رد نکردن. اگه اینجوری باشه، این اولین باری نیست که به بازیگر تهدید روی عملیات یه گروه دیگه ای سوار میشه و حتی از زیرساخت های اونا برای افشای اطلاعات تحت کاراکتر یا هویت جعلی استفاده میکنه. به نظر میاد ، بازیگر تهدیدی که مسئول این حمله هست، پشت شخصیت های یکبار مصرف مخفی شدن. براساس اکانت شبکه های اجتماعی که فعالیت هاشون رو از اونا منتشر کردن، حداقل دو مجموعه اکانت وجود داره. بدلایل نامعلومی، اگه اونا بازیگران تهدید یکسانی هستن، چرا از همون اکانت توییتری که قبلا داشتن، خبر حمله به جایگاههای سوخت رو منتشر نکردن. این موضوع در این حمله ی جدیدشون هم قابل مشاهده هستش.
تنها نکته ای که محققا با اطمینان تاییدش کردن اینه که، این گروهی که پشت حمله به جایگاه های سوخت هستن، چون بصورت خصوصی یسری جزییات فنی و شواهد در خصوص حادثه رو در اختیار محققا قرار دادن، پشت این حمله هستن ، چون گروه قبلی که بنام گنجشک درنده توییت میزنه، دسترسی به چنین اطلاعاتی نداره. تایید اینکه این گروه گنجشک درنده، همون گروه گنجشک درنده اولیه هست، برای محققا چالش برانگیز هست.
دامپ های بدست اومده دارای ویژگی جالب و مشکوکی هم هستن. در حالیکه تاریخ نمونه های آپلود شده، با خط زمانی حمله مطابقت دارن، اما هیچ کدوم از مهرهای زمانی و تاریخ های بازسازی شده از برنامه وب و پاسخ های HTTP ، به زمان نزدیک به حمله یا پس از حمله اشاره نمیکنن.
اگه فرض کنیم که این شواهد فارنزیکی ، بلافاصله بعد از حادثه بدست اومدن، بنابراین رشته های تاریخ و مهرهای زمانی فایلها باید با زمان حادثه مطابقت داشته باشن. اما در نمونه های محققین، آخرین تاریخ برای یه درخواست HTTP داخلی ، برای 18-06-2021 / 28 خرداد 1400 هستش. این تاریخ حدودا به چهار ماه قبل از حادثه اشاره میکنه.
این امر رو میشه اینجوری توجیه کرد که زمان و تاریخ سرورهایی که دامپ ها بدست اومدن، اشتباه تنظیم شدن. این میتونه در یه کامپیوتر ایزوله و آفلاین اتفاق بیافته و طبیعیه. اما وقتی یه شبکه بزرگ و بهم پیوسته رو در نظر بگیریم ، این تاریخ و ساعت اشتباه منجر به مشکلاتی از جمله در TLS/SSL یا VPN handshake میشه. از طرفی با توجه به اینکه ، این سیستم متکی به داده های مالی و سوابق تراکنش ها هستش، تصور اینکه تاریخ کل شبکه یا NTP بدرستی تنظیم نشده باشه، بعیده. این موارد دلیل دیگه ای هستش که محققا مطمئن نیستن، این آپلودها توسط تیم فارنزیک انجام شده.
یه توجیه دیگه که محققا برای این اتفاق بیان کردن اینه که ، شواهد آپلود شده ممکنه حاوی آخرین لاگ ها و شواهد نیست. بررسی و بازسازی بیشتر داده ها و محتوای حافظه پروسس در دامپ ها مورد نیازه و ممکنه تناقضات بیشتری رو هم نشون بده. انتساب ها سخته ، حالا اینکه شما با شواهد فارنزیکی ناسازگار هم روبرو بشید، دیگه سختتر هم میشه.
بررسی دامپ ها :
صرف نظر از مبدا دامپ های آپلود شده، نیت و دلیلشون، همچنان میشه اونارو بررسی کرد. محققا یه مجموعه کوچیکی از این دامپ هارو انتخاب و آنالیز و مهندسی معکوس و بازسازی کردن. محققا چیزهای زیادی در مورد پیاده سازی سیستم، نحوه عملکردش، و از همه جالبتر، نحوه حمله به این سیستم یاد گرفتن. در حالیکه مهاجمین روش حمله اشون رو افشاء نکردن و همچنین یه گزارش رسمی فارنزیک منتشر نشده، اما محققین تونستن بطور مستقل چندین بردار حمله و آسیب پذیری کشف کنن، که امکان به خطر انداختن بخش های مختلف سیستم، دسترسی با امتیاز بالا به سرورها یا حتی به خطر انداختن اتصالات VPN از طریق اکسپلویت کردن اونا رو میده. محققا اعتبارنامه های مختلف رمزگذاری شده و clear-text هم در طول این فرآیند بدست آوردن، که برخی از اونها بطور موثر ، سطح دسترسی به شبکه داخلی رو بعنوان یه سرور IPC ، فراهم میکنن.
گزارش تحلیلی مدبران:
محققا در کنار این نشتها، یسری سرنخ هم از افراد یا پستهای منتشر شده در شبکه های اجتماعی و گروه های گفتگو بدست آوردن. نکته جالب برای محققا این بوده که یه شرکت خصوصی بنام مدبران، یه گزارش 104 صفحه ای در خصوص این رخداد منتشر کرد.
این گزارش بصورت رسمی از کانالهای رسمی این شرکت منتشر نشد، اما دارای برچسب خصوصی هم نیست و برای فرد یا نهاد خاصی هم ارسال نشده، و بطور کلی اینجوری منتشر شده که برای انتشار عمومی محدود هست. اما این گزارش بصورت عمومی بین گروه های ایرانی منتشر و پخش شد. محققا به یسری نکات در خصوص این گزارش هم اشاره کردن.
این گزارش برخلاف عنوان اون، یه گزارش فارنزیکی نبود و عمدتا براساس تجربه و دانش قبلی این شرکت در خصوص سیستم هوشمند سوخت نوشته شده. همچنین این شرکت اعلام کرده که دخالتی در بررسی این حادثه نداشته. با توجه به محتوای گزارش، عدم دخالت یا دسترسی اونا به داده های فارنزیکی یا حتی سیستم های عملیاتی، نیت اونا در انتشار این گزارش رو محققا کنار گذاشتن.
گزارش در 95 صفحه، به طراحی سیستم و نحوه ی سازماندهی و مدیریت زیرساخت پرداخته. گزارش شامل مجموعه ای رنگارنگ از اسکرین شاتها، تصاویر سخت افزارها و جزییاتی هستش که اصولا باید خصوصی باشن مگه اینکه دخالت اونارو در این حادثه ، بررسی بشه.
در ادامه گزارش، در دو صفحه، این شرکت گمانه زنی هایی در خصوص بردارهای حمله داشته که برخیشون واقعی نیستن، اما برخیشون با نتایجی که محققا بدست آوردن مطابقت داره.
یکی از بردارهای حمله ای که این شرکت اشاره کرده، حمله به یه راه حل مدیریت راه دور مانند iLO هستش. همونطور که اشاره شد، امن پرداز یه گزارشی در خصوص یه روت کیت منتشر کرده بود که در شبکه های ایرانی بود و iLO رو آلوده و بکدوری میکرد. البته این شرکت در گزارششون بارها اعلام کرده که اینا در حد حدس و گمانه زنی هستش.
این گزارش در نهایت با ارائه یسری پیشنهاد برای بهبود امنیت زیرساخت، تموم میشه. برخی از این پیشنهادات دارای اشتباهات فنی قابل توجهی هستش که نشون دهنده عدم درک کامل راه حلهای پیشهادی هستش. بطور کلی، بنظر میرسه این گزارش تلاشی برای پاسخگویی مبهم به برخی سؤالات، انتشار غیرضروری برخی جزئیات فنی (عمدتاً ترجمه اسناد Ingenico و استانداردهای امنیتی) و شاید تلاشی برای استفاده از فرصت برای تبلیغ شرکت بوده.