آخرین بدافزار پوششی اندروید از طریق فیشینگِ اسمسی در اروپا توزیع می‌شود

مقدمه

در آوریل 2016، هنگام بررسیِ یک کمپین فیشینگِ اسمسی به نام RuMMS که هدف‌هایی از اروپا با سیستم عامل اندروید را هدف قرار می‌داد، متوجه سه کمپینِ فیشینگِ اسمسیِ دیگر شدیم که بنا به گزارش‌ها در دانمارک(فوریه ۲۰۱۶)، در ایتالیا(فوریه ۲۰۱۶) و در ایتالیا و دانمارک(آوریل ۲۰۱۶) پخش می‌شدند.

برخلاف کمپین RuMMS، این سه کمپین در اروپا از تکنیک‌های view overlay(همان تکنیک‌هایی که در بدافزار SlemBunk استفاده شده بودند و توصیف کردیم) استفاده کردند تا ورودی‌هایی مشابه با برنامه‌های گوشی برای اطلاعات ورود به نمایش بگذارند، و در ادامه کاربرانی که در جریان نبودند را گول بزنند تا اطلاعات بانکی خود را در اختیارشان قرار دهند.

شکل۱ پروسه‌ی این‌که چطور این بدافزارهای پوششی توسط فیشینگِ اسمسی پخش می‌شدند و کاربران اندروید را آلوده می‌کردند را نشان می‌دهد.

شکل۱. نمای کلی

عاملان تهدید معمولاً ابتدا سرورهای دستور و کنترل(C2) و سایت‌های میزبانیِ بدافزار را پیکربندی می‌کنند، سپس بدافزارها را بر روی سایت‌های میزبانی قرار می‌دهند و لینکی که به بدافزار هدایت می‌کند را از طریق اسمس برای قربانی می‌فرستند. پس از نصب‌شدن روی دستگاه، بدافزار یک پروسه را برای مانیتور کردن این‌که کدام برنامه در حال اجرا روی صفحه‌ی کاربر(foreground) است، راه‌اندازی می‌کند. وقتی کاربر یک برنامه‌ی آشنا را روی صفحه اجرا می‌کند که بدافزار برای هدف‌قرار دادنِ آن برنامه طراحی شده است(مثلاً اپلیکیشن بانک)، بدافزار یک view برای فیشینگ در روی آن برنامه به صورت overlay(پوششی) به نمایش در می‌آورد. کاربری که در جریان این حمله نیست، با فرض این‌که از برنامه‌ی معتبری استفاده می‌کند، ورودی‌های مورد نیاز(اطلاعات کارت بانکی) را وارد می‌کند؛ که این اطلاعات به سرور C2 که توسط گردانندگان این ویروس کنترل می‌شود ارسال می‌شوند.

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

• ·         از فوریه‌ی 2016 تا ژوئن 2016، ما 55 برنامه‌ی مخرب که در سری‌های فیشینگ اسمسی در اروپا به کار رفته بودند را یافته‌ایم. همه‌ی نمونه‌بدافزارها از تکنیک viewی پوششیِ مشابهی برای سرقت اطلاعات بانکی استفاده می‌کنند و همه‌ی آن‌ها از پروتکل روش اشتراک‌گذاریِ C2 مشابهی بهره می‌برند. در کنار سه کمپینی که به صورت عمومی در دانمارک و ایتالیا مشخص شدند، ما بدافزار مشابهی را در آلمان در مارس 2016 و در اتریش در آوریل 2016 تا مِی 2016 مشاهده کردیم. در ژوئن 2016، ما هنوز نمونه‌های جدیدی در حال ظهور و استفاده شدن در دانمارک؛ و چند کشور اروپایی می‌بینیم که کاربران را هدف قرار داده‌اند.
• ·         کاربرد کلیدی این نمونه‌ها همه یکسان است؛ با این وجود، طی زمان متوجه شدیم که نمونه‌ها در چند شاخه‌ی مختلف در حال تحول و توسعه هستند. برای مثال، کمپین‌های اخیر، برنامه‌های شناخته شده تری را نسبت به کمپین‌های اولیه هدف قرار داده‌اند، به عنوان مثال با تمرکزِ خاصی روی برنامه‌های پیام‌رسان، در مقابل برنامه‌های بانکی. همین‌طور، اپلیکیشن‌های مخربی که در کمپین‌های اخیر استفاده شده اند به دلیل استفاده از تکنیک‌های obfuscation به نسبت سخت‌تر از قبلی‌ها آنالیز می‌شوند. به علاوه، برخی کاربردهای بیشتری به آن‌ها اضافه شده است؛ به طور خاص ما متوجه این شدیم که نسخه‌های جدیدتر، از تکنیک reflection برای دور زدن سرویس App Ops که روی نوشتن SMS محدودیت می‌گذارد(معرفی شده در اندروید نسخه‌ی 4.3) استفاده می‌کنند. همه‌ی این‌ها این معنی را می‌رسانند که عاملان این تهدید به صورت فعالانه در حال توسعه‌ی کدِ بدافزارشان هستند.
• ·         برخلاف کمپین RuMMS، که به طور کلی از سرویس‌های هاستینگِ shared برای پخشِ بدافزار استفاده می‌کرد، کمپین‌های فیشینگِ اسمسیِ اروپایی تنوعِ بیشتری در زیرساخت‌های استفاده شده، برای مثال استفاده از دامنه‌های شخصی، سایت‌های هک‌شده، و سرویس‌های کوتاه‌کردن URL، نشان می‌دهند. از فوریه‌ی 2016، ما ۲۷ لینک bit.ly را مشاهده کردیم که در بدافزار و پخش آن استفاده شده‌بودند. در ژوئن ۲۰۱۶، ما متوجه سه سرویس کوتاه‌کردن URL دیگر شدیم که عبارت بودند از tr.im, jar.mar و is.gd و در کمپین آخری استفاده شده بودند. این مسئله آن معنی را می‌رساند که گردانندگان این تهدید سعی دارند با استفاده از تنوع کوتاه‌کننده‌های URL، از تشخیص داده شدن جلوگیری کنند.
• ·         در مجموع، ما ۱۲ سرورِ C2 را که در ۵ کشور مختلف قرار داشتند و در این کمپین‌ها استفاده می‌شدند را شناسایی کردیم. بین آن‌ها، آی‌پی آدرسِ 85.93.5.109 توسط 24 برنامه‌ی مخرب در دو کمپین و 85.93.5.139 توسط 8 برنامه‌ی مخرب استفاده شده بود. ما همچنین ۴ سرورِ C2 را مشاهده کردیم که همگی در رنج آیپی 85.93.5.0/24 بودند. همه‌ی این‌ها نشانگر آن است که گردانندگان تهدید دسترسی بر منابع شبکه‌ی ارتباطی قابل توجهی دارند.
• ·         سرویس‌های کوتاه‌کردن URL معمولاً سرویس‌های آنالیز بازدید ارائه می‌کنند؛ که ما را در یافتن این‌که چه تعداد کاربر (از چه کشور‌هایی) در چه زمانی روی لینک کوتاهمون کلیک کرده اند، کمک می‌کند. با استفاده از این سرویس‌ها، ما متوجه شدیم که حداقل 161349 کلیک بر روی ۳۰ لینک کوتاهی که به بدافزار پوششی منتقل می‌شدند، انجام شده است که هر یک می‌توانسته است موجب آلودگیِ یک دستگاه اندرویدی شود. اطلاعات زمانی مشخص کرد که بیشترین کلیک‌ها در چند روز ابتدایی ساخته‌شدن لینک انجام شده است.

پنج کمپینِ فیشینگِ اروپایی

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

این کمپین‌ها از طریق اسمسِ فیشینگی که به گوشی کاربر ارسال می‌شده شروع می‌شده‌اند. یک پیام متنی برای مثال در شکل۱ آمده است. پیام به سختی به «ما نتوانستیم سفارش شما را تحویل دهیم. لطفا اطلاعات باربری خود را در لینک ... بررسی کنید» ترجمه می‌شود. کاربران دانمارکی و ایتالیایی از اهداف اولیه‌ی این سه کمپین گزارش شده‌اند.

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

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

(*: در ابتدا توسط محققان FireEye عمومی شد)

لینک‌های کوتاه به صورت مشترک در همه‌ی این پنج کمپین استفاده شده بودند. در مجموع ما ۳۰ لینک کوتاه‌شده یافتیم. برخی سایت‌های کوتاه‌کردن آدرس، سرویس آنالیز ارائه می‌کنند؛ که از طریق آن هر کس می‌تواند ببیند که چند نفر روی لینک کلیک کرده‌اند و این کلیک‌ها از چه کشورهای نشأت می‌گرفته‌اند. برای مثال، تصویر۲ نشان می‌دهد که ۱۳۵ کلیک از آلمان بر روی یکی از نمونه‌های Whats-Germany، و 1633 کلیک از اتریش روی یکی از نمونه‌های Post-Austria انجام شده است.

تصویر۲. صفحه‌ی آنالیز نمونه‌های Whats-Germany و post-Austria

تکامل کد

در کمپین‌های فیشینگ اسمسی فوق، ما مشاهده کردیم که کد بدافزار با گذر زمان در حال تحول است. سازنده‌های بدافزار به نظر با پشتکار در حال تلاش برای بهبود کد هستند؛ برای مثال با اضافه کردن برنامه‌های هدفِ جدید، obfuscate کردن کد برای جلوگیری از تشخیص‌داده‌شدن، و تلاش برای دور زدن محدودیت‌های App Ops.

اضافه‌کردن برنامه‌های هدفِ جدید

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

آنالیز کد بدافزار نشان می‌دهد که این وظیفه با استفاده از یک متد در سرویس اصلی، به نام initInjTask (در اکثر موارد) اجرا می‌شود. شکل۳ کد initInjTask را در یکی از اولین نمونه‌های کمپین MPayDenmark نمایش می‌دهد که در آن یک برنامه‌ی محلی به نام MobilePay مورد هدف قرار گرفته بود.

شکل۳. کلاس MobileBank قرار است اجرا شود تا پوششی باشد برای برنامه‌ای با نام dk.danskebank.mobilepay

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: 49dac3b35afb2e8d3605c72d0d83f631)

شکل۴ کد initInjTask را در یک نمونه‌ی Whats-Italy نمایش می‌دهد؛ که در آن هدف به یک برنامه با کاربرد گسترده‌تر تغییر کرده بود: مسنجر WhatsApp.

شکل4. کلاس Cards قرار است اجرا شود تا پوششی باشد برای برنامه‌ی com.whatsapp

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: 97c2d04aa0f3c3b446fc228c1dbc4837)

شکل5 کد initInjTask را در یک نمونه‌ی Whats-Germany نمایش می‌دهد؛ که در آن هدف به دو برنامه‌ی WhatsApp و Google Play Store تغییر کرده بود.

شکل5. کلاس Cards قرار است اجرا شود تا پوششی باشد برای برنامه‌های WhatsApp و Play Store

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: 9e9d9a3717eed4d558a3f5eddb260901)

شکل6 کد initInjTask را در یک نمونه‌ی Post-Austria نمایش می‌دهد(در این مورد، کد برنامه‌ی مخرب obfuscate شده بود؛ کد از فایل jar افتاده استخراج شده است). در مجموع، هشت برنامه‌ی محبوب جهانی، من‌جمله Uber و WeChat در رادار آن بودند.

شکل6. کلاس cqkwjqjtoz قرار است اجرا شود تا پوششی باشد برای هشت برنامه‌ی محبوب

(کد از برنامه‌ای با کد MD5 روبرو به دست آمده: d70296d3dc4937dedd44f93bb3b74034)

Obfuscateکردنِ کد

در کمپین‌های اولیه، من‌جمله MPay-Denmak, Whats-Italy و Whats-Germany، بیشتر برنامه‌های مخرب به صورت obfuscate نشده بودند و مهندسان معکوسِ با تجربه به سادگی می‌توانستند با کد disassembled شده کار کنند.

شکل7 کد manifest و ساختار کد نمونه‌های ابتدایی را نشان می‌دهد. با این دو بخش از اطلاعات می‌بینیم که سه receiver برای اهداف مختلفی رجیستر شده‌اند: برای مدیریت SMSهای دریافتی؛ برای درخواست برای دسترسی admin؛ و برای شروع برنامه در هنگام بوت شدن و مدیریت دو رویداد مرتبط به اپلیکیشن. همین‌طور دو سرویس وجود دارند که برای اجرا در پس‌زمینه ساخته شده‌اند و چهار activity که برای تعامل با کاربر هستند. با اطلاعات کلی‌ای که در دست داریم، آنالیزورهای بدافزار ماهر می‌توانند به سادگی بفهمند که هر قسمت از کد چه نقشی دارد و در ادامه متوجه شوند که چطور این قسمت‌ها با یکدیگر کار می‌کنند تا به نتیجه‌ی بدافزار برسند.

شکل7. ساختار کد و فایل manifest از یک کد اولیه و obfuscate نشده

از آوریل 2016، مشاهده کردیم که همه‌ی نمونه‌های دیتابیس ما از تکنیک‌های obfuscation استفاده کرده‌اند. با obfuscation، فایل manifest به نسبت برای خواندن سخت‌تر شد و ساختار کد به طور کامل متفاوت شد.

شکل8 یک نمونه را نشان می‌دهد که در کمپین PostDanmark است. ساختار کد در سمت چپ نشان می‌دهد که چهار class به نام‌های a,b,c,d و mrtbeig با نام پکیج مشترک com.atrdectn.ioitsrc وجود دارند. در سمت راست، فایل manifest نشان می‌دهد که چهار receiver وجود دارد؛ هفت سرویس و چهار activity؛ البته با نام پکیج متفاوتِ com.lpygioep.tjzcverotl. خوب پس کدِ این کلاس‌های تعریف شده کجاست؟ هدفِ این کلاس‌هایی که در چپ نام‌گذاری شده‌اند چیست؟ این‌جا کد برای آنالیز شدیداً پیچیده‌تر شده است.

شکل8. ساختار کد و فایل manifest از کد obfuscate شده

تحقیقات عمیق‌تر نشان داد که این کلاس‌ها که در سمت چپ تعریف شده‌اند payload واقعی را می‌سازند و view فیشینگ را روی هشت برنامه‌ی شناخته‌شده‌ی معروف نمایش می‌دهند. کد آن‌ها در واقع در فایل assetای به نام mptxip.dat ذخیره شده است که به صورت خاصی encode شده است.

کلاس‌های سمت چپ در واقع کد را unpack می‌کنند تا فایل asset را دیکد کنند، تا payload واقعی را در زمان اجرا بارگذاری کنند و از reflection برای اجرای کد مخرب در payload استفاده کنند. این پروسه به نسبت پیچیده‌تر است و ابتدا یک سری آنالیز کد استاتیک نیاز دارد تا مشخص شود چه چیزی در کد موجود است، سپس آنالیزهای دینامیک(زمان اجرا) تا payload واقعی را به دست آید؛ و سپس هر دو آنالیز برای فهمِ payload واقعی. سازنده‌های آنتی‌ویروس‌ها همواره در شناسایی این‌گونه تهدیدها دچار مشکل هستند. به طوری‌که در 8 ژوئن 2016، تنها 6 آنتی‌ویروس از 54تا، توانستند این نمونه‌ها را به عنوان ویروس تشخیص دهند.

دورزدن محدودیت App Ops

اندروید از permissionها برای اپلیکیشن‌ها استفاده می‌کند تا مشخص کند که یک برنامه چه رفتارهای حساسی می‌تواند انجام دهد. در نسخه‌های قبلیِ سیستم‌عامل اندروید، وقتی یک برنامه نصب می‌شد، از کاربر خواسته می‌شد تا دسترسی‌هایی که برنامه درخواست می‌کند را تایید کند. اگر کاربر با این دسترسی‌ها مخالفت می‌کرد، برنامه نصب نمی‌شد؛ که مفهومش «همه یا هیچ» است(یا برنامه نصب می‌شود یا کلاً نصب نمی‌شود، حد وسطی نداریم). App Ops یک سرویس است که در اندروید 4.3 برای اولین بار به کار رفت، و کارش آن است که اجازه می‌دهد دسترسی‌های یک برنامه در زمان اجرا تغییر کند. با استفاده از App Ops، کاربر می‌تواند بعضی دسترسی‌های برنامه را در زمان اجرا تایید یا رد کند. به طور جالبی مشاهده کردیم که از کمپین What-Italy به بعد، بدافزارهای پوششی شروع به اضافه کردن کدهایی کردند که سعی داشت این محدودیت را دور بزند.

شکل۱۰ قطعه‌کدی را در کلاسِ MainService نشان می‌دهد که در زمان شروع اپلیکیشن توسط launcher activity اجرا می‌کردد. این قطعه‌کد بررسی می‌کند که آیا build version این دستگاه 19 (یعنی اندروید 4.4) هست یا نه؛ و این‌که آیا App Ops دسترسیِ WRITE_SMS را محدود کرده یا نه. اگه هر دو شرط صحیح باشند، بدافزار تابع setWriteEnabled را از کلاسِ SmsWriteOpUtil(در خط 93) صدا می‌کند تا دوباره دسترسیِ نوشتنِ SMS را فعال کند.

شکل9. کدی برای چک کردن و فعال‌سازی دوباره‌ی دسترسیِ نوشتن SMS

شکل۱۰ کد اصلیِ SmsWriteOpUtil را برای فعال‌سازی دوباره‌ی دسترسی نوشتن SMS نشان می‌دهد. در خط 60، یک handle به سرویس سیستمیِ App Ops وصل شده است. در خط 61، reflection برای گرفتن دسترسی به کلاسِ خاص استفاده شده است. در خط 64 . 65، متدهای reflection، یعنی getMethod و invoke برای صدا زدنِ یک متد به نام setMode استفاده شده‌اند. این متدهای API معمولاً برای استفاده توسط کد فریم‌ورک‌های دیگر و یا اپلیکیشن‌های از پیش نصب شده ساخته می‌شوند. هر چند در این کیسِ خاص، گردانندگان تهدید از reflection برای دور زدن محدودیت App Ops استفاده می‌کنند.

شکل10. کدی که از reflection برای صدا کردن سرویس App Ops استفاده می‌کند تا دسترسی نوشتن SMS را فعال کند.

سایت‌های میزبانی

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

دامنه‌های شخصی

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

برای این‌که کاربران قربانی فریب بخورند و روی این لینک‌ها کلیک کنند، دامنه‌ها هر کدام صرفاً برای یک کمپین بهینه‌سازی نامی شده بودند. برای مثال، در کمپین اولیه‌ی MPay-Denmark، گردانندگان تهدید از سرویس Danish postal service به عنوان یک نمایه استفاده کرده بودند و پیام دریافت شده عبارت بود از «شما یک MMS از XXX دریافت کرده‌اید. لینک ... را دنبال کنید تا این پیام را مشاهده نمایید». در نتیجه بسیاری از دامنه‌ها حاوی کلمه‌ی mms، و you بودند؛ مانند mmsforyou.pw، mmsservice.pw و mmstildig.net (til dig در زبان دانمارکی به معنای «برای شما» است).

در کمپین بعدی PostDanmark، پیام فیشینگ اسمسی به صورت «بسته‌ی شما برای دریافت آماده است. لینک ... را دنبال کنید تا همه‌ی اطلاعات بسته‌تان را مشاهده کنید» بود. در نتیجه بسیاری از آدرس دامنه‌ها عبارت‌هایی مانند post، و یا danmark را دارا بودند؛ مانند postdanmark.net، postdanmark.online، postdanmark.menu و postdanmarks.com. دقت کنید که آدرس سایت رسمیِ پستِ دانمارک، www.postdanmark.dk است. در نتیجه همه‌ی این آدرس‌های فیشینگ در واقع قصد تقلیدِ دامنه‌ی پست دانمارک اصلی را داشته‌اند.

لینک‌های کوتاه‌شده

یک صفحه نمایش با اندازه‌ی کوچک، لینک‌های کوتاه‌شده را برای دستگاه‌های تلفن بی‌نقص می‌سازد. گردانندگان تهدید به ظاهر این واقعیت را می‌دانسته‌اند، و از آن استفاده کرده‌اند تا به مقصود خود برسند. زمانی که این پنج کمپین را در اروپا مانیتور می‌کردیم، متوجه شدیم که لینک‌های کوتاه‌شده‌ی مشاهده‌شده به تعداد زیاد استفاده می‌شده‌اند. در مجموع، ما چهار سرویس کوتاه‌سازی لینک را مشاهده کردیم که هر کدام حداقل یک بار استفاده شده بودند، من‌جمله bit.ly, tr.im, is.gd و jar.ma.

از این چهارتا، bit.ly از همه بیشتر مورد استفاده قرار گرفته بود. در مجموع ما ۲۷ لینک bit.ly را که از فوریه‌ی 2016 تا ژوئن 2016 استفاده شده بودند، شناسایی کردیم. سه سرویس کوتاه‌سازی لینک دیگر تا ژوئن 2016 مشاهده نشده بودند، و فقط یکی از آن‌ها برای هر سرویس استفاده شده بود. تنوع‌دهی به سرویس‌های کوتاه‌سازی لینک به ما این امر را نشان می‌دهد که گردانندگان این تهدید سعی دارند از شناسایی شدن فرار کنند.

سایت‌های هک‌شده

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

در زمان مانیتور کردن این پنج کمپین فیشینگ اسمسی، ما مشاهده کردیم که سایت‌های هک‌شده به کرات استفاده می‌شدند. برای مثال، لینکِ آنالیز برای لینک کوتاه‌شده‌ی hxxps://bitly[.]com/1qRey7a+ به ما نشان می‌دهد که در ۱۳آوریل ۲۰۱۶، وب‌سایتِ kgiexport.com یک برنامه‌ی اندروید با نام post.apk را میزبانی می‌کرده است.

چند کلیک؟

دوتا از سرویس‌های کوتاه‌سازیِ لینک، یعنی bit.ly و tr.im صفحات آنالیز برای لینک‌های کوچک‌شده‌ای که می‌سازند ارائه می‌کنند. شکل۲ صفحه‌ی آنالیزی که برای لینکی از bit.ly است را نشان می‌دهد. شکل۱۳ یک اسکرین‌شات از صفحه‌ی آنالیزی که توسط tr.im ارائه شده است را نشان می‌دهد. برای این صفحات، ما می‌توانیم اطلاعاتی در مورد این‌که چند نفر روی لینک کوتاه‌شده در زمانی خاص کلیک کرده‌اند، و همچنین کشور مبدا این کلیک‌ها به دست آوریم.

شکل11. صفحه‌ی آنالیزی که توسط tr.im ارائه شده است.

جدول۲ اطلاعاتی را مرتبط با 28 لینک کوتاه‌شده‌ای که مانیتور شده‌اند به دست می‌دهد.

جدول۲. تعداد کلیک‌ها روی هر لینک کوتاه شده

در مجموع ۲۸ لینک کوتاه‌شده، ۱۶۱۳۴۹ بار کلیک شده اند. از این کلیک‌ها، ۱۳۰۶۳۶ تای آن‌ها از کمپین PostDanmark آمده‌اند، که نشان می‌دهد پیام‌های فیشینگی که ادعا شوند از اداره پست آمده‌اند موفق‌تر خواهند بود(!). ما همچنین متوجه این شدیم که تعداد کلیک‌ها چند روز بعد از ساخت این لینک‌ها افت کردند. برای مثال 96631 کلیک(67.06٪) کلیک‌ها در روز اول ساخته شدن لینک‌های کوتاه انجام شده‌اند و 30749 کلیک (21.33٪) در روز دوم ساخته‌شدن انجام شده‌اند. این کلیک‌ها به صورت عمده از دو کشور می‌آمده‌اند: دانمارک(88.66٪) و اتریش(5.30٪). یک سری کشورهای دیگر نیز ممکن است مورد هدف قرار گرفته باشند؛ من جمله آلمان، لوکزامبورگ، اسپانیا، سوئد، نروژ، بریتانیا، هلند، ایتالیا، یونان و ترکیه.

سرور C2

همه‌ی بدافزارهایی که آنالیز کردیم با یک سرور پیکربندی‌شده‌ی C2 برای ارسال اطلاعات مرتبط با دستگاه و گرفتن دستورات مرتبط بودند. آدرسی که برای ارتباط با سرور استفاده می‌شد به فرم http://$C2.$SERVER.$IP/?action=command بود. در مجموع ما ۱۲ سرور C2 که در پنج کشور مختلف میزبانی می‌شدند را پیدا کردیم که در این کمپین‌ها مورد استفاده قرار گرفته بودند. جدول۳ اطلاعاتی را مرتبط با این سرورهای C2 ارائه می‌کند.

جدول3. اطلاعات مرتبط با سرورهای C2

به طور خاص، آدرس آیپیِ 85.93.5.109 توسط 24 بدافزار در کمپین‌های PostDanmark و post-Austria استفاده شده بود. آدرس آیپیِ 85.93.5.139 توسط 8 بدافزار در کمپین PostDanmark استفاده شده بود. دقت کنید که چهار سرور اول C2 در رنج آیپی مشابه 85.93.5.0/24 هستند. در مجموع ما 38 نمونه بدافزار پیدا کردیم که با این چهار سرور C2 از مارس 2016 تا ژوئن 2016 در ارتباط بودند.

آیا این بدافزارها قسمت کوچکی از یک چیز بزرگتر هستند؟

وقتی اطلاعات ثبت این دامنه‌های شخصی را بررسی می‌کردیم، یک چیز جالب پیدا کردیم: در مارس 2016، یک ایمیل(l[REDACTED][e-mail]) به تنهایی سه دامنه‌را، من‌جمله postdanmark.org, postdanmark.menu و mmstildig.info را برای دوتا از پنج کمپین ثبت کرده است. با استفاده از reverse lookup، ما چهار دامنه‌ی مشابه را پیدا کردیم که با ایمیل آدرس مشابهی در مارس 2016 ثبت شده بودند. جدول 4 اطلاعاتی را در رابطه با این دامنه‌ها ارائه می‌کند.

جدول4. دامنه‌هایی که توسط گرداننده‌ی تهدید احتمالی(l[REDACTED][e-mail]) ثبت شده‌اند.

سه دامنه‌ی اول برای میزبانیِ بدافزار کمپین‌های MPay-Denmark و PostDanmark استفاده شده بودند. ما هیچ شواهدی مبنی بر این‌که چهار دامنه‌ی بعدی برای کمپین‌های مشابه استفاده بشوند پیدا نکردیم؛ اما ایمیل آدرس ثبت‌کننده‌ی مشابه و نام‌گذاری مشابه آن‌ها این مفهوم را منتقل می‌کند که احتمالاً آن‌ها هم برای قصد مشابهی ساخته شده‌اند.

جمع‌بندی

فیشینگ اسمسی یک الگوی جدید برای آلوده‌کردن کاربران موبایل ارائه می‌کند. کمپین‌های فیشینگ اسمسی بعدی که در اروپا پخش شدند نشان می‌دهد که هنوز فیشینگ اسمسی یک ابزار محبوب در بین گردانندگان تهدیدها برای پخش کردن بدافزارشان است. به علاوه گردانندگان تهدید از آدرس‌های میزبانی متنوع و سرورهای C2 متفاوتی استفاده می‌کنند و به طور مداوم در حال بهبود دادن کد مخرب خود برای آلوده‌کردن تعداد کاربران بیشتر و فرار از شناسایی شدن هستند.

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

برای پیدا کردن و دفاع در برابر این حملات، ما از مشتریان خود می‌خواهیم تا برنامه‌ی FireEye MTP/MSM که برای امنیت موبایل است را نصب کنند. این به مشتریانمان کمک می‌کند تا تهدید‌های مشابه را در حوزه‌ی کاربری خود ببینند و همچنین آن‌ها را قادر می‌سازد تا به سادگی دستگاه‌هایی که ممکن است هک شده باشند را پیدا کنند. به علاوه ما مشتریان خود را به استفاده از لوازم NX توصیه می‌کنیم تا با اسکن شبکه‌ی Wi-Fi خود توسط آن، دسترسی کامل‌تری به دستگاه‌ها موبایل برسانند.

ضمیمه: نمونه‌ها

df53b59e354462cd0e704b7b21a750f7

6eb92667ebbbcb2c7ddf6230462222fd

3841abcef2b1b37aa7e2d47c535ca80e

265d37013e1ea39b868515cce157dfeb

49dac3b35afb2e8d3605c72d0d83f631

ffe98d97e7d827aa19abb968a528f3fe

f4b8d64af0a53472901b50621f19d6bf

e1d79608b649c22004ad7cc1cd049528

ef5c9b15755719597481c501f6b603ce

6a300ded487671ef39388b8d28927a83

d33b718737de5aa685672a2004e0fa3c

d83d833092a4fa5ecc436d4246c2f7ce

97c2d04aa0f3c3b446fc228c1dbc4837

82b1006a5f45a6d2baf69544414ada81

9e9d9a3717eed4d558a3f5eddb260901

82d89319fabd998328cc6d4efc4db863

228a4b723bf3d8adc53a69dd0f36c746

e911df33f1d156b3309a4ac220c52070

2b90fca41272bec8b8ffefbb2456c001

40449a2ec48c3e630b2eb8c8089828cf

8d0a03981daa93210e184e7fff02883c

fbdde37d41d12f21c049c570c9bda3de

a18818cb3fb6f189560991cef6d1f929

bf7b72dbb2a9155dabc4eda31d273b92

9762441d52bdec725eff6f2f65e721e9

dba6b4bbf61e054fb978acaf70c3d849

93922ee5fbd149f31b0161deca76df77

035d1f3b7fb532a33de7a8445f9fa325

3f2017a5acb3e57801e2771341287001

06e74df867e9cb5c1bafc98165c6c248

20f4cd2baa09e0bd5e12dab50c0898cd

af7a8d32865e8caf51a99c52834d4422

82d89319fabd998328cc6d4efc4db863

bee3746684b072867a5b202bfc5527dd

a18818cb3fb6f189560991cef6d1f929

8959513f65bcca6f16faef59ad2d152f

cfa92cbcb0674429cc9ce216cc008902

d73d54f6f86c58030477cc9a96eedb85

2f4d81ef1b10bf72d0dba0fdf354527f

701d57504444344b8d5e79bcabcd3dca

fcb4ef63f1d8a3a044ac6f8a7c262546

05131969af2ae6cbfddf789512f02aa2

6e93a7f7911b3e9b522be4b8f950cca4

542f8f77e101d4e8e5d1ef34a3f0df1c

d0a6ba40e05047dc2cff12935c4cf4fb

23988abad7c7b2ecdda23ae7194b7a0d

2c055d7b5199604cd5cf3441073b36b3

a72aa534973eeaf0782a246d502107a3

f1c8a3337cbd56e01e478774f5d55278

da222d4b7993a62665b9eaef10c1846f

152f626eb92676f940ada4b7077acf16

7a99b60349703aed3ab28f498320f247

1b9e1cd2c7f8e227b2ae5fb5bc735536

d84ff5a7e7c0c33dcfa237299869bc34

d70296d3dc4937dedd44f93bb3b74034

88b23b6a5c1b72aeff2fc42e05c173a7

036258e2c51e21c140b5838ce9bfb4f8

رمزنگاری/6-تقسیم‌بندی الگوریتم‌های رمزنگاری

پست قبلی: الگوریتم های سزار و اِنیگما

در پست های قبلی این مجموعه، ابتدا با الگوریتم‌های درهم‌نگاری(Hash) و الگوریتم‌های Encoding/Decoding آشنا شدیم، تفاوت آن‌ها را با الگوریتم های رمزنگاری (Encryption/Decryption) بررسی کردیم و در نهایت پس از بررسی مقدمات توسعه‌ی رمزنگاری و علل نیاز به آن، در این پست قرار است به تقسیم‌بندی های الگورتیم های رمزنگاری امروزی بپردازیم.

واژگان رمزنگاری:

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

• Plain Text: متن رمز نشده ای که قرار است برای رمزشدن به تابع Encryption وارد شود و همچنین متن رمزنشده ای از تابع Decryption بازگردانده می‌شود.
• Cipher Text: متن رمز شده ای که از تابع Encryption بازگردانده می‌شود و همچنین متن رمزشده ای که برای خارج شدن از رمز به تابع Decryption وارد می‌شود. 
• Cipher: الگوریتمی که برای Encrypt یا Decrypt استفاده می‌شود. با این تعریف، در بعضی موارد از Encipher و Decipher به ترتیب به جای Encoding و Decoding استفاده می‌شود.
• Key: یک اطلاعات محرمانه که فقط و فقط فرستنده و گیرنده‌ی پیام رمز شده از آن اطلاع دارند. Cipher از این کلید، برای انجام عملیات Encrypt و/یا Decrypt استفاده می‌کند.
•  Cryptanalysis: به مطالعات و فعالیت هایی که روی یک الگوریتم رمزنگاری یا داده‌های آن انجام می‌شود تا به واسطه‌ی آنها امکان استخراج کلید رمزنگاری از داده های در دسترس یا امکان استخراج داده‌های رمزنشده بدون داشتن کلید، بررسی شود. نام دیگر این فیلد Codebreaking می‌باشد.
• Salt, Nonce, Initial Vector: در پست‌های بعدی!

و اما تقسیم بندی:

 الگوریتم‌های رمزنگاری را می‌توان از چند بُعد تقسیم‌بندی کرد که مهمترین این ابعاد یکی تعداد کلیدهای لازم برای یکبار رمزکردن و خارج کردن از رمز و دیگری نوع پردازش شدن Plaintext در تابع Encrypt است.  

• تقسیم بر اساس تعداد کلیدهای لازم:

فرایند رمزکردن یک Plaintext و خارج کردن آن از رمز، روندی طبق شکل زیر دارد:

حال، با توجه به ماهیت الگوریتم، ممکن از مقدار  Encryption Key با مقدار Decryption Key برابر باشد یا متفاوت از همدیگر باشند. الگوریتم‌هایی که مقدار این دو کلید با همدیگر یکسان است را Secret Key Algorithm یا Symmetric Algorithm یا Single Key Algorithm یا Conventional Algorithm الگوریتم‌های متقارن می‌نامیم و الگوریتم‌هایی که در آن‌ها مقدار کلیدها از همدیگر متمایز است را Public Key Algorithm یا Asymmetric Algorithm یا Two Key Algorithm یا الگوریتم های نامتقارن می‌نامیم. (از آنجا که روند کار الگوریتم‌های نامتقارن ممکن است [به خاطر تفاوت کلیدها] در ذهن غیرممکن به نظر برسد، در پست‌های بعدی احتمالا نمونه ای از این الگوریتم‌ها را با هم به صورت جزیی‌تر بررسی خواهیم کرد).

• تقسیم‌ بر اساس نوع پردازش Plaintext:

در بعضی از الگوریتم‌های رمزنگاری، طول پیامی که قرار است رمزشود، حتما باید مضرب صحیحی از یک عدد طبیعی خاص بزرگتر از یک باشد. به عنوان مثال طول پیام ورودی باید مضربی از 16 بایت باشد. به این نوع الگوریتم‌های رمزنگاری، Block Cipher می‌گویند و آن عدد طبیعی خاص بزرگتر از یک Block Size نامیده می‌شود. مشخصا هنگامی که قرار است با استفاده از این نوع الگوریتمها پیامی را رمز کنیم که طول آن مضرب صحیحی از طول Block نیست، ناچاریم که تا رسیدن به طول لازم به آن داده اضافه کنیم. مکان و نوع داده‌ای که به پیام اضافه می‌شود می‌تواند دلخواه باشد، لیکن، برای سهولت امر و برای این که گیرنده‌ی Ciphertext بتواند به سادگی پیام را از داده‌ی اضافه شده تمییز دهد، استانداردهای مختلفی ارائه شده است که خود به خود به انتهای پیام، مقداری را اضافه می‌کنند. به عمل اضافه کردن داده‌ به پیام تا رسیدن به طول طول مجاز، Padding می‌گویند. در مقابل این نوع الگوریتم‌ها، نوع دیگری از الگورتیم‌های رمزنگاری را داریم که طول پیام هر‌ مقدار دلخواهی می‌تواند باشد، به این نوع الگوریتم‌ها که در اقلیت هستند، Stream Cipher می‌گویند.

مقایسه الگوریتم‌های متقارن و نامتقارن:

ممکن این سوال برای خواننده پیش بیاید که کاربرد هر کدام از این دو نوع الگوریتم در چه مواقعی است و آیا مزیتی از نظر امنیتی به یکدیگر دارند؟

در پاسخ به این سوال ابتدا روند استفاده از الگوریتم‌های نامتقارن را بررسی می‌کنیم. گفتیم که در الگوریتم های نامتقارن،  Encryption Key  و Decryption Key با هم متفاوتند. نام این کلیدها Public Key و Private Key است. پیامی که با یکی از این دو کلید رمزشود، فقط و فقط با کلید دیگر از رمز خارج می‌شود و استفاده از مقدار دیگری جز کلید دوم، منجر به دریافت داده‌های چرند(:دی!) می‌شود. با توجه به این ساختار، هر موجودیتی باید یک جفت کلید برای خودش تولید کند و یکی را محرمانه نزد خود نگه دارد (Private Key) و دیگری را به شخصی که قصد دارد با اون ارتباط برقرار کند ارسال کند(Public Key). 

برای روشن شدن فرآیند، تصویر زیر را مشاهده کنید:

همانطور که در تصویر فوق می‌بینید، Alice در مرحله‌ی 1، یک جفت کلید تولید می‌کند و در مرحله‌ی 2، کلید عمومی خود را به Bob می‌دهد. سپس در مرحله‌ی 3، یک پیام که با کلید خصوصی خودش رمز شده است به باب ارسال می‌کند. از آنجا که این پیام با کلید خصوصی Alice رمز شده است، فقط و فقط با کلید عمومی او قابل رمزگشایی است[کلید عمومی را هر کسی می‌تواند با درخواست از Alice دریافت کند، بنابرین هر کسی می‌تواند این پیام را رمزگشایی کند]. Bob که کلید عمومی Alice را دارد، پیام او را از رمز خارج می کند، و در جواب به او، مجدد پیام خود را در مرحله‌ی 4 با کلید عمومی Alice رمز می‌کند. بدیهتا، از آنجا که پیام Bob با کلید عمومی Alice رمز شده است، تنها با کلید خصوصی Alice از رمز خارج می‌شود[و از آنجا که Alice کلید خصوصی اش را به هیچ کسی نمی‌دهد، فقط و فقط خودش قادر به رمزگشایی پیام Bob است]. در مرحله‌ی 6 هم Alice پیام Bob را با کلید خصوصی خودش از رمز خارج می‌کند.

دو نکته ای که باید متوجه آن شده باشید:

1. برای این که یک ارتباط دو طرفه‌ی کاملا امن بین Alice و Bob برقرار باشد، Bob هم باید یک جفت کلید تولید کند و کلید عمومی خودش را به Alice بدهد تا Alice به جای استفاده از کلید خصوصی خودش در مرحله‌ی 2، از کلید عمومی Bob استفاده کند(تا هیچکسی جز Bob قادر به رمزگشایی آن نباشد).
2. برخلاف الگوریتم‌های متقارن که در آنها لازم بود گیرنده و فرستنده از قبل به صورت مخفیانه با هم یک کلید را به اشتراک بگذارند، در الگوریتم‌های نامتقارن، برای این که Alice و Bob بتوانند یک پیام محرمانه به همدیگر ارسال کنید، نیازی به اشتراک گذاشتن کلید به صورت مخفیانه نیست، بلکه به صورت کاملا واضح، کلیدهای عمومی خود را به همدیگر ارسال میکنند و کسی با استفاده از آنها نمی‌تواند به داده های رمزشده دست پیدا کند، زیرا در یک ساختار صحیح از Public Key تنها برای رمزکردن (Encrypt) و از Private Key تنها برای رمزگشایی (Decrypt) استفاده می‌شود.

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

سوال: نهایتا کدام یک استفاده می‌شوند؟

جواب: هر دو! گذشته از این که ممکن است یک سیستم کلا استفاده از یکی را بر دیگری ترجیح دهد، روند متداول این است که ترکیبی از این دو استفاده می‌شود. به این صورت که در ابتدای ارتباط، از طریق الگوریتم‌های نامتقارن یک کلید متقارن(Secret Key) را یکی به دیگری ارسال می‌کند و پس از ارسال این کلید، روند رمزنگاری ارتباط به الگورتیم‌های متقارن Switch می‌کند. در واقع بعد از ارسال کلید متقارن که با رمزنگاری نامتقارن رمز شده است، مابقی ارتباط به صورت متقارن رمز می‌شود.

سوال: آیا صحیح است بگوییم الگوریتم‌های نامتقارن از الگوریتم‌های متقارن امنیت بیشتری دارند؟

جواب: خیر، امنیت یک الگوریتم رمزنگاری را ساختار الگورتیم آن (مشخص کننده ی زمان و تعداد کلیدهایی که باید امتحان شوند تا کلید رمزنگاری بدست آید)، طول کلید آن و نبود خطای منطقی(باگ) در الگوریتم آن تعیین می‌کنند. در واقع در صورتی که در ساختار یک الگوریتم متقارن و یک الگوریتم نامتقارن باگ وجود نداشته باشد، الگوریتمی امنیت بالاتری دارد که طول کلید آن بزرگتر باشد. از نگاه دیگر، همانقدر که محرمانه نگه داشتن Secret Key در الگوریتم متقارن اهمیت دارد، محرمانه نگه داشتن Private Key هم در الگوریتم نامتقارن اهمیت دارد.  در این مورد در پست های بعدی توضیحات کاملتری خواهیم داشت.

اصولی در مورد الگوریتم‌های رمزنگاری:

با گذشت زمان و پیدا شدن نقاط ضعف الگورتیم‌های اولیه، رفته رفته اصولی برای الگوریتم‌های رمزنگاری تدوین شد که در زیر به دو مورد اصلی آن‌ها اشاره می‌کنیم:

1. طول خروجی باید با طول ورودی الگوریتم برابر باشد (بر طبق اصل لانه‌ی کبوتری، خروجی نمی‌تواند از ورودی کوتاه تر باشد. بلندتر بودن خروجی هم مزیتی ندارد و لازم نیست)
2. فاش شدن الگوریتم نباید موجب شود Attacker بتواند داده‌های رمز شده را رمزگشایی کند؛ و به عبارت دیگر باید تنها مبتنی بر محرمانه نگه داشتن کلید باشد. (یکی از اصول کرکهافس).

سوال: Security via Obscurity چیست؟ 

جواب: به مخفی نگه داشتن الگوریتم رمزنگاری به منظور افزایش امنیت (مثلا با کاهش احتمال پیدا شدن ایراد منطقی در الگوریتم)، Security by Obscurity گفته می‌شود.

الگوریتم‌های رمزنگاری مشهور:

در زیر به چند مورد از الگوریتم‌های رمزنگاری متقارن و نامتقارن مشهور اشاره شده است. لازم به ذکر است که کدام از این‌ الگوریتم‌ها می‌توانند بر اساس طول کلید به زیر مجموعه‌هایی تقسیم شوند. به عنوان مثال برای الگوریتم RSA زیر مجموعه های RSA-512, RSA-1024 .... RSA-4096 مرسوم هستند و برای الگوریتم AES سه زیر مجموعه‌ی AES-192, AES-128و AES-256 را داریم (اندازه‌ی بلاک در هر سه مورد 128 بیت است). 

نامتقارن:

• RSA یا Rivest-Shamir-Adleman
• ECC یا Elliptic Curve Cryptography
• DH یا Diffie–Hellman
• ElGamal 

متقارن:

• DES یا Data Encryption Standard
• TDES یا 3DES یا Triple DES
• AES یا Advanced Encryption Standrad

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

قسمت بعدی: کاربرد و روند استفاده از امضای دیجیتال (به زودی)

---

بی مهری انسان معاصر در توست

تنهایی انسان نخستین در من ...

#میلاد_عرفان_پور

دنیای من برای دیدنِ دوباره‌ی یه دوست خیلی بزرگ و دست نیافتنی هست ولی برای دیدن دوباره‌ی آدم‌های نچسب، خیلی خیلی کوچیک ...

رمزنگاری/5-الگوریتم های Caesar و Enigma (سِزار و اِنیگما)

قسمت قبلی: معیارهای امنیت

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

الگوریتم سزار:

"باب" جلسه ای دو نفره و محرمانه با "آلیس" تشکیل داد و با او در مورد نحوه‌ی ارسال نامه ها مشورت کرد. چیزی که در ابتدا باب می‌خواست این بود که هیچ کسی جز آلیس قادر به فهمیدن محتوای نامه و دستورات نباشد. در این جلسه تصمیم باب و آلیس بر این شد که در متن نامه به جای هر حرف، حرف سه جایگاه قبل تر را جایگزین کنند. به این صورت که به جای A حرف X، به جای B حرف Y و ... 

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

[پایان داستان باب و آلیس!!!/به علت زیاد بودن مطالب]

شکل: نسبت تکرار حروف مختلف در یک متن انگلیسی

نکته: در دنیای رمزنگاری، الگوریتم فوق به نام الگوریتم سزار معروف است، زیرا برای اولین بار ژولیوس سزار پادشاه رومی برای ارتباط با فرماندهانش استفاده شد. از نام های دیگر آن می‌توان به Shift Cipher، Caesar Code و Caesar shift اشاره کرد.

ماشین Enigma:

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

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

قسمت بعدی: بررسی تقسیم بندی الگوریتم‌های رمزنگاری

---

دیدار تو گر صبح ابد هم دَهَدَم دست

من سرخوشم از لذتِِ این چشم به راهی ...

#فریدون_مشیری

رمزنگاری/4-معیارهای امنیت

قسمت قبلی: مشکلات مربوط به Encoding

تا پیش از این با Hash کردن و Encoding و Decoding آشنا شدیم و دانستیم که Hashing استفاده از تابعی است که یک طرفه می‌باشد و پس از Hash کردن داده ها قابلیت بازیابی مجدد آن‌ها را نداریم، و در مقابل دانستیم که Encoding و Decoding تابع هایی دو طرفه برای تغییر Form داده ها هستند؛ که برای استفاده از آن‌ها نیاز به چیزی تحت عنوان کلید یا رمز نیست و هر فردی که از الگوریتم مطلع باشد می‌تواند داده های Encode شده را با استفاده از تابع Decode به داده های اصلی تبدیل کند.(لازم به ذکر است که ماهیت Public بودن قریب به اتفاق الگوریتم های Encoding/Decoding باعث می‌شود همه بتوانند از آن‌ها استفاده کنند).

معیارهای امنیت:

 در این قسمت ابتدا یک سناریو تعریف می‌کنیم و سپس بر اساس آن، علت نیاز به الگوریتم‌هایی فراتر از الگوریتم‌های Hash و Encoding/Decoding را متوجه خواهیم شد و در خلال قسمت های بعدی روند توسعه‌ی این الگوریتم‌های مورد نیاز را توضیح می‌دهیم.

در این سناریو شما فرمانده ی یک سپاه جنگی هستید و به سبب لزوم نظارت بر اتفاقات خط نبردِ نیروهایتان و نیز مدیریت کارهای مملکتی، ناچارید که مدام بین میدان کارزار و مقرّ فرماندهی آمد و شد کنید(بگذارید حداقل در این داستان سناریو را طوری تعریف کنیم که گویا نعلین فرماندهان نیز گَرد خطوط نبرد را به شیارهای خود دیده است!). بنابرین شما نیاز دارید که گاهی از این مقر، به یکی از سربازان عالی‌رتبه‌ی خود که وِی را به عنوان جانشین بر مسند فرماندهی گمارده‌اید نامه ای ارسال کنید و او را در جریان کارهایی که باید انجام دهد قرار دهید. همچنین، فرمانده ی مذکور، باید گزارشاتی از عملکرد خودش و اوضاع به شما ارسال کند. پیش از این که ادامه‌ی داستان را تعریف کنیم، یک نام برای شما، و یک نام برای آن افسر عالی‌رتبه انتخاب می‌کنیم. نام شما Bob است، و نام آن افسر Alice (چرا تعجب کردید؟ یک افسر عالی‌رتبه نمی‌تواند خانم باشد؟).

سوال: چرا Bob و چرا Alice؟ 

پاسخ: آلیس و باب در واقع دو عضو از یک خانواده‌ی بزرگ هستند تحت عنوان خانواده‌ی کاراکترهای رمزنگاری! به صورت واضح تر، در سال 1978 یکی از اساتید دانشگاه MIT به نام رونالد ریوست، در مقاله ای که برای ارائه‌ی الگوریتم رمزنگاری RSA آماده کرده بود، از این اسامی برای مثال‌های خود به عنوان فرستنده و گیرنده‌ی پیام استفاده کرد. بعدها در دیگر سناریوهایی که طراحی شد، این اسامی شهرت یافتند و کم کم کاراکترهای دیگری هم به جمع آن‌ها پیوستند. برای رعایت این رسم، ما نیز در سناریوی خود همین کاراکترها را به کار می‌بریم. به عنوان یک مطلب اضافه، حرف R در الگوریتم RSA، از فامیل آقای Rivest گرفته شده است. دو حرف دیگر هم از نام دو طرِاح دیگر الگوریتم آمده اند.

دکتر ریوست (نفر وسط)

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

اما بیایید پیش از آنکه اتفاقات و راهکارهایی که "باب" و "آلیس" استفاده کردند را بیان کنیم، خودمان بررسی کنیم و ببینیم که چه مسائلی باید در نظر می‌گرفتند؟ [بعدها خواهیم دید این مسائل مبنای امنیت یک خط ارتباطی را تشکیل می‌دهند]:

1. "باب" و "آلیس" باید به نحوی در نامه هایشان، خود را به گونه‌ای به یکدیگر معرفی کنند که هر کدام هنگام دریافت نامه‌ی دیگری بتواند مطمئن شود که نامه از جانب همان شخصی آمده است که باید بیاید. حتی در صورتی که نیروهای دشمن رونوشتی را که هفته‌ی پیش در کاروان‌سرای بین راه از نامه‌ی قاصد تهیه کردند جایگزین نامه‌ی امروز قاصد کنند، دریافت کننده باید متوجه معتبر نبودن آن بشود. [بعد ها این بند را با نام Authenticity خواهید شناخت]
2. در صورتی که نیروهای دشمن در میانه‌ی مسیر قاصد را تطمیع کردند یا به قتل رساندند و به دستوراتِ "باب" یا گزارشِ "آلیس" دست یافتند، نباید از آن چیزی متوجه شوند! [بعد ها این بند را با نام Confidentiality خواهید شناخت]
3. در صورتی که نیروهای دشمن در کاروان سراهای میان راه کمین کردند و نامه‌ اصلیِ قاصد را دزدیدند و محتوای آن را عوض کردند یا نامه‌ی جدیدی که خودشان نوشته اند جایگزین آن کردند، دریافت کننده‌ی نامه‌ی جدید باید متوجه جعلی بودن آن بشود. [بعد ها این بند را با نام Integrity خواهید شناخت]
4. چنانچه "باب" دستوری به آلیس فرستاد و مثلا به وی فرمانِ "حمله" داد و آلیس بعد از خواندن دستور، به خاطر ترس یا ... به آن عمل نکرد، بعدها نباید بتواند ادعا کند که نامه را دریافت نکرده است! همینطور اگر "باب" در موقیعت مشابهی، مثلا در حالت مستی، تصمیم اشتباهی گرفت و فرمانی صادر کرد و به آلیس فرستاد و اجرای آن تصمیمِ اشتباه منجر به اتفاق بدی شد که آبروی "باب" را به خطر می‌انداخت، وی نباید قادر به این باشد که ارسال آن دستور را انکار کند. [بعد ها این بند را با نام Non-Repdiation خواهید شناخت]
5. قاصد و اسب پر انرژی اش همیشه باید در دسترس "باب" و آلیس باشد. [بعد ها این بند را با نام Availability خواهید شناخت]

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

قسمت بعدی: الگوریتم‌های سزار/Caesar و اِنیگما/Enigma

---

To be yourself in a world that is constantly trying to make you something else is the greatest accomplishment.

Ralph Waldo Emerson

رمزنگاری-مقدمه/3-حل مشکلات مرتبط با Encoding

قسمت قبلی: انکدینگ و دیکدینگ

طبق قرار پیشین، به عنوانِ ادامه‌ی مبحث اِنکدینگ و دیکدینگ (پیش زمینه ای بر مباحث رمزنگاری)، در این پست دو مشکلی را بررسی می‌کنیم که با احتمال زیاد تابحال حداقل یکبار با آن‌ها مواجه شده اید و با Encoding ارتباط مستقیم دارند:

مشکل اول: زیرنویس های خرچنگ قورباغه و ناخوانا

 گاها، بعد از دانلود کردن زیرنویس فارسی یک فیلم و افزودن آن به Player، به جای حروف فارسی، با تصویری مشابه زیر مواجه می‌شویم:

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

راهکار اول: (موقتی)

نرم افزار Microsoft Office Word را باز کنید و از منوی File و سپس Open فایل زیرنویس دانلود شده را داخل آن Import کنید. بلافاصله بعد از کلیک کردن روی دکمه ی Open برای باز شدن فایل در نرم افزار Word پنجره ای مشابه زیر باز خواهد شد که باید از منوی سمت راست گزینه ی Unicode  UTF-8 را انتخاب کنید (معمولا به صورت اتوماتیک این کار انجام شده است و شما در کادر بزرگ پایین، متن فارسی را به صورت درست مشاهده می‌کنید؛ در ایصورت حتی اگر Encoding چیزی مغایر با آنچه که گفتیم بود، به آن دست نزنید) و کلید OK را بزنید:

پس از کلیک روی OK محتوای زیرنویس به صورت خوانا داخل Microsoft Word باز می‌شود. کاری که لازم است در این مرحله انجام دهید این است که از منوی File گزینه‌ی Save As را انتخاب کنید و سپس این محتوا را به صورت یک فایل با پسوند txt. ذخیره کنید. در نهایت، فایل جدید را با موس به داخل Player بکشید تا تصویری مشابه زیر داشته باشید:

راهکار دوم: (موقتی)

در این روش که مشابه روش پیشین است، به جای استفاده از نرم افزار Microsoft Word از نرم افزاری به نام ++Notepad [دانلود کنید] استفاده میکنیم.

برای این منظور، ابتدا زیرنویس را در این محیط باز می‌کنیم. در این مرحله محتویات آن را به همان صورت ناخوانا می‌بینیم. از منوی Encoding به صورت زیر، Windows-256 را انتخاب می‌کنیم تا متن فارسی به صورت خوانا ظاهر شود:

و سپس، باز از منوی File گزینه‌س Save As را انتخاب کرده و محتویات را به صورت یک فایل txt. ذخیره می‌کنیم و فایل جدید را به عنوان زیرنویس استفاده می‌کنیم.

راهکار سوم: (دائمی)

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

از منوی Start روی Control Panel کلیک کنید و سپس در پنجره ی باز شده روی  Clock, Language and Region (در ویندوز XP روی Region and Language) انتخاب کنید. در پنجره ی باز شده، ابتدا در تَبِ Format، از قسمت کشویی، Persian را انتخاب کنید و سپس به تَبِ Administrative رفته و با کلیک روی Change System Locale مجددا مشابه تصویر زیر Persian را انتخاب کرده و با زدن OK سیستم خود را Restart کنید:

از این به بعد، زیرنویس های دانلود شده، بدون مشکل ناخوانا شدن داخل Player باز می‌شوند. 

مشکل دوم: صفحات وب و ایمیل های خرچنگ قورباغه و ناخوانا

خوشبختانه منشاء این مشکل نیز همان مسئله‌ی انکدینگ است. برای رفع این مسئله چنانچه با یک ایمیل فارسی ناخانوا مواجه هستیم، می‌توانیم با Copy & Paste کردن محتوای آن در یک فایل متنی و انجام مراحل ذکر شده در راهکار اول و راهکار دوم برای زیرنویس ها، متن آن را بخوانیم؛ و چنانچه یا با یک صفحه ی وب فارسی مواجه هستیم، یا تمایلی به Copy & Paste کردن محتوای ایمیل نداریم، می‌توانیم تنظیمات Encoding مرورگر وب خود را به صورت زیر تغییر دهیم (هر بار یکی از گزینه های مشخص شده انتخاب می‌کنیم) تا نتیجه‌ی مطلوب را مشاهده کنیم:

برای مرورگر Google Chrome:

برای مرورگر Fire Fox:

Sorry, I don't like it :D use dear Google Chrome, or Google "How to change encoding in fire fox?" and follow the above steps!

قسمت بعدی: معیارهای امنیت

---

Well you only need the light when it's burning low

Only miss the sun when it starts to snow

Only know you love her when you let her go ...