در حمله‌ای که به‌عنوان یک فیشینگ بسیار پیچیده توصیف شده، مهاجمان فیشینگ، از روشی غیرمعمول بهره برده‌اند که امکان ارسال ایمیل‌های جعلی از طریق زیرساخت گوگل را فراهم کرده و گیرندگان را به وب‌سایت‌های جعلی هدایت می‌کند و به تبع آن اطلاعات ورود آن‌ها را سرقت می‌کنند.
نیک جانسون، توسعه‌دهنده ارشد سرویس Ethereum Name Service (ENS)، در مجموعه‌ای از پست‌های پلتفرم X اعلام کرد که این ایمیل‌ها واقعاً از آدرس “no-reply@google.com” ارسال شده و به دلیل امضای معتبر DKIM، بدون هیچ هشداری در جیمیل نمایش داده می‌شوند، حتی در کنار پیام‌های امنیتی قانونی قرار می‌گیرند.
محتوای ایمیل‌های فیشینگ و صفحات جعلی
ایمیل‌های جعلی به گیرندگان اطلاع می‌دهند که احضاریه‌ای از یک نهاد قضایی دریافت کرده‌اند که خواستار بررسی محتوای نامشخصی از حساب گوگل آن‌هاست و از آن‌ها می‌خواهند روی لینکی از دامنه “sites.google.com” کلیک کنند تا محتوای پرونده را بررسی کرده یا اعتراض خود را ثبت کنند.
این لینک به صفحه‌ای جعلی در Google Sites منتهی می‌شود که با شباهت بسیار به صفحه پشتیبانی رسمی گوگل طراحی شده و دکمه‌هایی برای «آپلود اسناد تکمیلی» یا «مشاهده پرونده» ارائه می‌دهد. کلیک روی این دکمه‌ها کاربران را به فرم ورود جعلی هدایت می‌کند که روی همان دامنه Google Sites میزبانی شده و اطلاعات کاربری آن‌ها را سرقت می‌کند.
جانسون توضیح داد که Google Sites، به‌عنوان سرویسی قدیمی، به کاربران امکان می‌دهد محتوای دلخواه خود را روی زیردامنه google.com میزبانی کنند و از اسکریپت‌ها و Embedهای سفارشی پشتیبانی می‌کند. این ویژگی ساخت صفحات فیشینگ را بسیار آسان می‌سازد، به‌ویژه که مهاجمان با بارگذاری نسخه‌های جدید این صفحات، از حذف آن‌ها توسط تیم بررسی سوءاستفاده گوگل پیشی می‌گیرند. نبود گزینه‌ای برای گزارش مستقیم سوءاستفاده در رابط کاربری Google Sites نیز به مهاجمان کمک می‌کند.
فرآیند فنی حمله بازپخش DKIM
مهاجمان ابتدا حساب گوگل جدیدی برای دامنه‌ای تازه، مانند (“me@<domain>”) ایجاد می‌کنند. سپس یک اپلیکیشن OAuth ایجاد می‌کنند و نام آن را به‌گونه‌ای تنظیم می‌کنند که حاوی محتوای پیام فیشینگ، مانند عبارات مرتبط با هشدار امنیتی یا احضاریه، باشد. این فعالیت مخرب به‌عنوان حمله بازپخش DKIM (DKIM Replay) شناخته می‌شود. جانسون افزود که با اعطای دسترسی این اپلیکیشن به حساب گوگل، پیام هشدار امنیتی از گوگل تولید می‌شود که به دلیل امضای معتبر DKIM، از تمام بررسی‌های امنیتی عبور می‌کند.
مرحله اول:
مهاجم ابتدا یک ایمیل واقعی از گوگل دریافت کرده که از آدرس no-reply@accounts.google.com ارسال شده است. این ایمیل شامل یک امضای معتبر DKIM است:
DKIM-Signature: d=accounts.google.com; s=20230601; bh=a+1bch/…
مهاجم سپس این ایمیل را به‌صورت دقیق، شامل هدرها و بدنه، استخراج و ذخیره می‌کند، بدون اینکه هیچ بخشی از اطلاعاتی که توسط DKIM امضا شده، تغییر کند.
مرحله دوم:
DKIM (DomainKeys Identified Mail) به این صورت کار می‌کند که هنگام ارسال اولیه، یک امضای دیجیتال به هدرهای خاص و بدنه ایمیل اعمال می‌شود. این امضا با استفاده از کلید خصوصی فرستنده تولید شده و به‌صورت یک هدر در خود ایمیل درج می‌گردد.
وقتی ایمیل بعدا فوروارد می‌شود، امضای اصلی DKIM معمولا بدون تغییر باقی می‌ماند؛ به‌شرطی که محتوا و هدرهای پوشش‌داده‌شده توسط امضا دست‌نخورده باقی بمانند. از آنجا که سرویس‌های فورواردینگ معمولا پیام اصلی را بدون تغییر ارسال می‌کنند، امضای DKIM همچنان معتبر مانده و می‌تواند از طریق رکورد DNS عمومی فرستنده، تأیید شود.
مرحله سوم:
مهاجم از یک حساب Outlook به آدرس x186997@outlook.com برای ارسال پیام جعلی استفاده کرده است.
هاپ خروجی (Outbound hop):
- سرور: LO3P265CU004.outbound.protection.outlook.com
- آدرس IP: 40.93.67.3
مرحله چهارم:
مایکروسافت سپس این پیام را به یک سرویس SMTP سفارشی منتقل می‌کند:
- Relay: asp-relay-pe.jellyfish.systems
- IP: 162.255.118.7
این سیستم به‌عنوان یک رله میانی (middle relay) عمل کرده و پیام جعلی را یک مرحله دیگر از گوگل دور می‌کند. این سرویس هیچ ارتباطی با Namecheap یا PrivateEmail ندارد.
مرحله پنجم:
پیام سپس توسط زیرساخت ایمیل Namecheap یعنی PrivateEmail دریافت شده که خدمات فوروارد ایمیل ارائه می‌دهد.
سیستم‌های درگیر:
- mta-02.privateemail.com
- DIR-08
- fwd-04.fwd.privateemail.com
- fwd-04-1.fwd.privateemail.com
در این مرحله یک امضای DKIM جدید به ایمیل افزوده می‌شود:
DKIM-Signature: d=fwd.privateemail.com; l=52331;
بدنه‌ای که حجمش بیش از ۵۲ کیلوبایت باشد، امضا نمی‌شود و این DKIM با دامنه هم‌راستا نیست، بنابراین برای DMARC لحاظ نمی‌شود. SPF به دلیل بازنویسی Return-Path تأیید می‌شود اما آن‌هم هم‌راستا نیست. با این حال، چون امضای اصلی گوگل بدون تغییر و هم‌راستا با google.com باقی مانده، DMARC تأیید می‌شود.
مرحله ششم:
تحویل نهایی توسط این سیستم انجام می‌شود:
- Sender: fwd-04-1.fwd.privateemail.com
- IP: 66.29.159.58
- Recipient (MX): mx.google.com
در این مرحله، ایمیل به اینباکس قربانی می‌رسد در حالی‌که کاملا شبیه یک پیام معتبر از گوگل است و تمام بررسی‌های احراز هویت، شامل SPF (به واسطه فورواردکننده)، DKIM (از سوی گوگل) و DMARC (بر اساس DKIM گوگل)، موفق نشان داده می‌شوند.
جنبه‌های هوشمندانه حمله
یکی از جنبه‌های هوشمندانه این حمله، تنظیم هدر «Signed by» ایمیل روی accounts.google.com است، در حالی که هدر «Mailed by» به دامنه‌ای نامرتبط (fwd-04-1.fwd.privateemail.com) اشاره می‌کند. جانسون تأکید کرد که چون حساب با نام me@ ساخته شده، جیمیل پیام را طوری نمایش می‌دهد که انگار از خود کاربر ارسال شده، که نشانه‌ای کلیدی برای تشخیص فیشینگ را از بین می‌برد. به گفته EasyDMARC، مهاجمان این پیام را از حساب Outlook فوروارد می‌کنند، در حالی که امضای DKIM را دست‌نخورده نگه می‌دارند. این ایمیل‌ها از طریق سرویسی مانند Jellyfish و زیرساخت PrivateEmail شرکت Namecheap به جیمیل قربانی فوروارد می‌شوند.
واکنش گوگل
گوگل در واکنش به این حملات اعلام کرد که اصلاحاتی برای مسدودسازی این مسیر سوءاستفاده اعمال کرده و تأکید کرد که گوگل هرگز اطلاعات ورود مانند رمزعبور یا کدهای یک‌بارمصرف را درخواست نمی‌کند و با کاربران تماس مستقیم نمی‌گیرد. سخنگوی گوگل افزود که این شرکت از این حملات هدفمند آگاه بوده و محافظت‌هایی را پیاده‌سازی کرده است و به کاربران توصیه کرد از احراز هویت دومرحله‌ای و کلیدهای عبور استفاده کنند، تا محافظتی قوی در برابر این حملات فراهم می‌آورد.
