برخی‌اوقات خیلی راحت، تنها با چک کردنِ فیلدِ From می‌توان ایمیل‌های فیشینگ را شناسایی کرد. با این حال، همیشه هم شرایط به همین آسانی نخواهد بود؛ ساخت ایمیلی تقلبی طوری که هیچ جوره نتوان آن را از نسخه‌ی واقعی‌اش تشخیص داد بسیار بسیار محتمل است. اگر مهاجم بداند چطور این کار را کند، آنوقت سازمان مورد هدف حسابی به دردسر خواهد افتاد.
به گزارش روابط عمومی شرکت ایدکو (توزیع کننده محصولات کسپرسکی در ایران)؛ اکثر افراد پیش از کلیک روی لینک یا فایل آلوده که در ایمیل‌شان دریافت می‌کنند (ظاهراً از جانب رئیس‌شان و یا کلاینتی رده‌بالا فرستاده شده است) حتی یک ثانیه هم فکر نمی‌کنند و خوب البته نمی‌شود آنها را مقصر دانست، خصوصاً اینکه هیچ راهی هم برای تشخیص فرق میان نسخه‌ی واقعی و جعلی وجود ندارد.
اما سوال اینجاست چرا باید امکان ساخت ایمیلی جعلی آن هم به این ظرافت و دقت وجود داشته باشد؟ سخنرانی اندرو کنستانتینف در باب احراز هویت ایمیل برای تست‌کنندگان نفوذپذیری در سی و ششمین کنگره‌ی ارتباطات آشوب پاسخ درخوری به این سوال می‌دهد. گفته‌های کنستانتینف بینش جدیدی را در خصوص اثربخشی حفاظت در برابر کلاهبرداری ایمیل ارائه می‌دهد.
مشکل 1: ایمیل باید جاری و به روز باشد
ایمیل، روش ارتباطیِ اصلی در جهان مدرن به حساب می‌آید و هر سازمانی در عملیات‌های روزانه‌ی خود به شدت بدان متکی است. گرچه وقتی همه‌چیز راحت و روان پیش می‌رود چندان هم به این تکنولوژی فکر نمی‌کنیم با این حال اگر ناگهان بلایی سر ایمیل‌ها بیاید مطمئن باشید همه حواسشان سمت آن می‌رود. بنابراین، قابلیت اطمنیان اولویت اول هر ادمین سرور ایمیل است. صرف نظر از هر چیز دیگر، ایمیل فقط و فقط باید ارسال شده و به دست گیرنده برسد. منظور اینجا این است که سرور ایمیل هر سازمانی باید تا حد امکان با هر چیز دیگر در جهان سازگاری داشته باشد. و خوب اینجا یک مشکل وجود دارد: استانداردهای ایمیل به شدت تاریخ‌گذشته است.
مشکل 2: پروتکل ایمیل بدون هیچ احراز هویتی
پروتکل اصلی به‌کار رفته در دو ارتباطات ایمیلیِ کلاینت به سرور و سرور به سرور SMTP است. این پروتکل اولین بار در سال 1982 معرفی شد و آخرین بار در سال 2008 بروزرسانی گردید- بیش از یک دهه پیش. و درست مانند بسیاری استانداردهای دیگر، SMTP هم یک کابوس امنیتی است.
ابتدا بیایید نگاهی داشته باشیم بر اجزای تشکیل‌دهنده‌ی یک پیام ایمیل (به طور معمول):
پاکت SMTP. این بخش برای ارتباطات سرور به سرور استفاده می‌شود و هیچگاه در رایانامه‌خوان نشان داده نمی‌شود. کار آن تعیین آدرس‌های فرستنده و گیرنده است.
رایانامه‌خوان این بخش را نشان می‌دهد. اینجا همان جایی است که فیلدهای آشنای From، To، Date و Subject را که هر ایمیلی دارد پیدا خواهید کرد.
مشکل اصلی اینجاست که این استاندارد هیچ ابزار احراز هویتی ارائه نمی‌دهد. مسئولیت فیلد آدرس فرستنده (هم در پاکت SMTP و هم در هدر) تماماً بر گردن سرور فرستنده است. بدتر اینکه، آدرس فرستنده در پاکت SMTP حتماً نباید با آنی که در هدر است تطابق داشته باشد (و کاربر فقط دومی را مشاهده می‌کند). همچنین، گرچه این استاندارد به ازای هر ایمیل یک هدر را تعیین می‌کند اما SMTP در واقع محدودیتی اعمال نمی‌کند. اگر پیامی حاوی چیزی بیش از یک هدر باشد، آنوقت رایانامه‌خوان براحتی یکی را برای نمایش به کاربر انتخاب می‌کند. خیلی هم نباید هکر حرفه‌ای‌ای بود تا این ترفندها را پیاده کرد.
پروتکل ایمیل هیچ ابزاری برای تضمین اینکه ایمیل در واقع از جانب فرستنده‌ی نشان‌داده‌شده آمده وجود ندارد.
مشکل 3: فرستنده و گیرنده هر دو در بخش جعل ایمیل مهمند
برای پیچیده‌تر کردن بیشتر شرایط، هر ارتباط ایمیل شامل دو طرف می‌شود؛ بنابراین مشکل عدم احراز هویت در واقع خود را در قالب و مشکل زیرمجموعه نشان می‌دهد.
از طرفی، شما قطعاً دوست دارید مطمئن شوید هر ایمیلی که دریافت می‌کنید واقعاً از سوی آدرس نشان‌داده‌شده فرستاده شده است. از طرفی دیگر هم شاید بخواهید جلوی ارسال ایمیل‌هایی که ظاهراً به آدرس شما هستند توسط افراد دیگر را بگیرید. متأسفانه این استاندارد نمی‌تواند هیچیک از این مشکلات را حل کند.
هیچ تعجبی نیست که پروتکل SMTP آنقدر به کرّات مورد سوءاستفاده قرار گرفته بود که افراد شروع کردند به ابداع فناوری‌های جدید برای رفع نقایص مذکور.
حل مشکل 1: فریم‌ورک خط‌مشی فرستنده (SPF)
ایده‌ی پشتِ Sender Policy Framework بسیار ساده است: سرور دریافت‌کننده باید بتواند چک کند آیا آدرس سروری که در اصل ایمیل را فرستاده است با آدرس میل سرور واقعی (مرتبط با دامنه) مطابقت دارد یا خیر. متأسفانه به گفتن آسان است اما به عمل بسی دشوار. استاندارد SMTP ابزاری برای چنین چک کردنی ندارد، بنابراین هر روش احراز هویتی باید به موارد از پیش‌موجود افزوده شود. دریافت چنین فناوری تا مرز «استانداردی پیشنهادشده» یک دهه طول کشید. امروزه تنها حدود 55 درصد از یک میلیون سرور برتر از SPF استفاده نموده و بیشترشان نیز خط‌مشی‌های کاملاً راحت را انتخاب می‌کنند.
SPF اینجا با همچنین با کلی مشکلات دیگر مواجه می‌شود، از جمله‌ی آن می‌توان به معماری آشفته‌ای اشاره کرد که دستکاری در تنظیمات را آسان می‌کند و اجازه می‌دهد افراد مهاجم با استفاده از سایر سرورهای میزبانی‌شده روی همان آدرس راه‌هایی برای دور زدن انتخاب کنند (و کلی مشکلات دیگر که از حوصله‌ی متن خارج است). اما نقص مهلک SPF این است که تنها آدرس نشان‌داده‌شده در پاکت SMTP را چک می‌کند و فیلد From در هدر را پاک نادیده می‌گیرد- همانی که در واقع کاربر قادر به دیدنش است.
نتیجه:
• SPF کمک می‌کند چک کنید ببینید ایمیلی از سرور اصلی و واقعی آمده است یا خیر.
• آدرس قابل‌مشاهده برای کاربر می‌تواند تقلبی باشد.
حل مشکل 2: DKIM
DomainKeys Identified Mail به طور متفاوتی به ایت مشکل نزدیک شده است. DKIM از حیث کریپتوگرافی با استفاده از کلیدی خصوصی که بواسطه‌ی آن امضا می‌تواند به کمک کلیدی عمومی (منتشرشده در سیستم نام دامنه) اعتبارسنجی شود، هدر پیام و بخشی از بدنه‌ی آن را امضا می‌کند.
با این حال، شایان ذکر است که DKIM قرار نیست کل متن را رمزگذاری کند. در عوض، بدان یک ضمیمه‌ی امضاشده (به طور کریپتوگرافیک‌شده‌ای) اضافه می‌کند. مشکل همینجاست. بخش رمزگذاری را سخت می‌توان اصلاح کرد اما حذف کامل امضا و ساخت پیامی تقلبی در عوض بسیار آسان خواهد بود- نتیجه‌ی کار نیز غیرقابل‌شناسایی باقی خواهد ماند.
DKIM را سخت می‌توان پیاده‌سازی کرد زیرا صدور و مدیریت کلیدهای رمزنگاری‌شده را دربردارد. همچنین، DKIM که تنظیمات اشتباه دارد می‌تواند به مهاجم این توانایی را دهد تا امضای اصلی DKIM را در پیام نگه داشته و در عین حال به طور کامل هدر و بدنه‌ی آن را تغییر دهد.
نتیجه:
• DKIM به شما اجازه می‌دهد با اطمینان‌دهی به سرور دریافتی -که پیام از طریق آن برای شما آمده است- به طور دیجیتالی پیام‌ها را امضا کنید.
• سخت می‌توان آن را پیاده‌سازی کرد زیرا مدیریت کلید رمزنگاری‌شده را در بردارد.
• جعل‌کنندگان براحتی می‌توانند همینطور که دارند به نام شما ایمیلی تقلبی می‌سازند امضا را نیز پاک کنند.
• برخی اشتباهات در تنظیمات می‌تواند در نهایت به پیام‌های تقلبی حاوی امضاهای واقعی DKIM بیانجامد.
حل مشکل 3: احراز هویت پیام مبتنی بر دامنه، گزارش و مطابقت (DMARC)
با وجود نام نسبتاً طولانی‌ای که دارد (Domain-based Message Authentication)، فهم پروتکل گزارش و مطابقت (Reporting and Conformance) به مراتب از فهم SPF یا DKIM آسانتر است. در واقع افزونه‌ای از هر دو است که فاحش‌ترین غفلت‌های آنها را پوشش‌دهی می‌کند.
نخست اینکه DMARC به ادمین دامنه در تعیین اینکه سرور دارد از کدام مکانیزم محافظتی (SPF، DKIM یا هر دو) استفاده می‌کند یاری می‌رساند. دوم اینکه، مشکلات SPF را نیز برطرف نموده و علاوه بر چک کردن آدرس مشخص‌شده در فیلد From هدر را (همانی که کاربر می‌تواند مشاهده‌اش کند) آدرس فرستنده در پاک SMTP را نیز مورد بازبینی قرار می‌دهد.
عیب کار اینجاست که پروتکل DMARC نسبتاً جدید است و هنوز استاندارد مناسبی به حساب نمی‌آید (RFC 7489 آن را استاندارد و یا حتی استاندارد پیشنهادی نمی‌خواند، بلکه تنها بدان لقب «اطلاعاتی» داده است) و آنطور که باید کاربرد گسترده پیدا نکرده است. بر طبق بررسی که روی 20 هزار دامنه انجام شد، تنها 20 درصد تا سال 2019 این پروتکل را اتخذ کرده بودند و 8.4 درصد نیز خط‌مشی‌های سختگیرانه‌ای داشتند.
نتیجه:
• مهمترین مشکلات مربوط به SPF و DKIM را حل می‌کند.
• چون هنوز به طور گسترده‌ای کاربرد ندارد آنطور که باید از اثربخشی مفیدی برخوردار نیست.
راه‌های جلوگیری از ایمیل‌های جعلی
خلاصه بگوییم: ایمیل‌های تقلبی هنوز هم احتمال دارد وجود داشته باشند زیرا پروتکل SMTP با مختصات امنیتی در ذهن طراحی نشده بود؛ بنابراین مهاجم می‌تواند هر آدرسی از فرستنده را در ایمیل جعلی خود درج کند. در طی چند دهه‌ی اخیر، یک سری مکانیزم‌های حفاظتی پدید آمدند- از جمله آنها می‌توان به SPF، DKIM و DMARC اشاره کرد. با این حال، برای اثربخش بودن این مکانیزم‌ها باید تا حد امکان توسط میل سرورها به کار روند (و به درستی پیاده‌سازی شوند). در حالت ایده‌آل، باید روی هر میل‌سرور موجود در اینترنت پیاده‌سازی شوند.
افزون بر این، به این نکته نیز توجه داشته باشید که برخی mail relay serverها ممکن است به دلیل خطاهای تنظیمات شروع کنند به افزودن چیزی به کلمات و همین می‌تواند چک DKIM را به طور اتوماتیک از کار بیاندازد. همچنین یادتان نرود که این فناوری‌ها کمک می‌کنند تا بشود با توده‌ی تهدیدات دست و پنجه نرم کرد اما به منظور محافظت کسب و کار خود در برابر حملات پیچیده‌ی ایمیل باید همچنان از راه‌حل‌های محافظتی هم در سطح ایستگاه‌های کار و هم در سطح میل‌سرور استفاده نمایید.
راهکارها:
ü دست‌کم SPF را دریافت کنید. مطمئن شوید بدرستی تنظیم شده باشد. همچنین در نظر داشته باشید مهاجمین زیرک می‌توانند SPF را دور بزنند.
ü برای محافظتی بهتر DKIM را اجرا کنید. شاید کمی سخت‌تر باشد ولی ارزشش را دارد. و دوباره بگوییم، مطمئن شوید بدرستی تنظیم شده باشد.
ü در حالت ایده‌آل، DMARC را دریافت کنید زیرا بیترِ نقایص قابل اکسپلویت در SPF و DKIM را پوشش می‌دهد.
ü تنظیمات بخش ایمیل‌های دریافتی را نیز بررسی فرمایید.
ü از راهکارهای امنیتی که از مکانیزم‌های احراز هویت مدرن پشتیبانی می‌کنند استفاده نمایید. توصیه‌ی ما به شما Kaspersky Security for Mail Servers یا Kaspersky Security for Microsoft Office 365 است.
