لینک کوتاه مطلب : https://hsgar.com/?p=4591

حمله مجدد کد به طرح myGovID






بن فرنگلی (دانشجوی کارشناسی ارشد، دانشگاه ملبورن)
ونسا تیگ (مدیر عامل، Thinking Cybersecurity Pty Ltd و A/Prof (Adj.)، دانشگاه ملی استرالیا)

خلاصه

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

اگرچه این حمله برای یک کاربر هوشیار که پروتکل را می شناسد قابل مشاهده است، ما معتقدیم که لاگین اکثر کاربران عادی با موفقیت ربوده می شود. در سمت سرور، ورود به سیستم از ورود قانونی کاربر قابل تشخیص نیست، بنابراین شناسایی حمله غیرممکن است (به استثنای تشخیص مبتنی بر نظارت توسط اثر انگشت دستگاه، مکان ورود به سیستم و غیره).

این ویدیو به کاربران غیر فنی نشان می دهد که چگونه از خود محافظت کنند.

سناریوی حمله

فرض کنید آلیس می خواهد با استفاده از myGovID به nottrustworthy.com وارد شود. در زبان Trusted Digital Identity Framework، nottrustworthy.com طرف متکی (RP)، Alice کاربر است، ATO Identity Exchange (IdX) را فراهم می کند، و myGovID (تنها) Identity Provider (IP) است. سیستم myGovID از یک برنامه مشتری استفاده می کند که آلیس روی تلفن خود اجرا می کند. nottrustworthy.com نیازی به یک RP معتبر یکپارچه با myGovID ندارد. در عوض، فقط باید برای آلیس ظاهر شود که گویی می تواند با استفاده از myGovID وارد آن شود.

حریف nottrustworthy.com را کنترل می کند و مایل است به طور متقلبانه به عنوان Alice در سایت دیگری وارد شود که ما آن را AlicesTaxService.gov.au می نامیم. فرض کنید AlicesTaxService.gov.au یک RP معتبر در سیستم myGovID است، به طوری که کاربران می توانند از myGovID برای ورود به سیستم استفاده کنند.

ما فرض می کنیم که Alice قبلاً برنامه myGovID را نصب کرده است و تا حدودی با استفاده از آن آشنا است اما در مفروضات اعتماد خود متخصص نیست.

جزئیات حمله

حریف صفحه وب را در nottrustworthy.com ویرایش می کند تا یک دکمه جعلی ارائه دهد که از کاربران دعوت می کند تا با myGovID وارد شوند. (کپی کردن دکمه ای که کاملاً شبیه دکمه واقعی است آسان است.) به جای اینکه صادقانه کاربران را به mygovid.gov.au هدایت کند، یک فریم یا صفحه در وب سایت خود ایجاد می کند که شبیه به ورود myGovID است و از کاربر درخواست می کند. پست الکترونیک. باز هم، این می تواند سایت واقعی myGovID را کاملاً کپی کند و بگوید “برای ادامه با myGovID خود وارد شوید.” یک کاربر سخت‌کوش که این را می‌داند باید از https://mygovid.gov.au آمده باشد، می‌تواند آن را تشخیص دهد، اما مگر اینکه آلیس دقیقاً بداند پروتکل چگونه کار می‌کند، هیچ چیز مشکوکی در مورد درخواست آدرس ایمیل از وب‌سایتی که قصد داشت با آن تعامل داشته باشد وجود ندارد.

حمله به شرح زیر است.

  1. هنگامی که آلیس ایمیل خود را وارد می کند، مهاجم (به صورت دستی یا خودکار) به AlicesTaxService.gov.au می رود، روی “Log in with myGovID” کلیک می کند، منتظر تغییر مسیر (صادقانه) به mygovid.gov.au می شود، و آدرس ایمیل آلیس را وارد می کند.

  2. سیستم myGovID یک کد 4 رقمی را که برای آلیس در نظر گرفته شده است، در صفحه mygovid.gov.au نمایش می دهد که حریف در حال خواندن آن است.

  3. مهاجم کد را می‌خواند و آن را برای آلیس، در صفحه nottrustworthy.com که آلیس به آن نگاه می‌کند، پخش می‌کند، به گونه‌ای که به نظر می‌رسد یک کد قانونی از myGovID است.

  4. آلیس کد را می خواند و در صورت درخواست آن را در برنامه خود وارد می کند.

  5. مهاجم اکنون به عنوان Alice به AlicesTaxService.gov.au وارد می شود.

  6. به منظور پنهان کردن حمله به طور کامل از آلیس، مهاجم می تواند یک ورود موفق به آلیس را در nottrustworthy.com نشان دهد.

نقص مهم طراحی این است که وقتی برنامه myGovID آلیس یک درخواست مجوز دریافت می‌کند و از آلیس دعوت می‌کند تا کد 4 رقمی خود را وارد کند، چیزی در رابط کاربری برنامه وجود ندارد که نام نهاد (RP) را که به دنبال مجوز است، به او بگوید. آلیس فکر می کند که با ورود به nottrustworthy.com موافقت می کند. با این حال، سیستم myGovID (هم IdX و هم IP) درخواست مجوز مهاجم را از AlicesTaxService.gov.au منتقل می کند.

تجزیه و تحلیل تاثیر

این حمله توسط یک کاربر سخت کوش قابل تشخیص است که پروتکل را به اندازه کافی درک می کند و می داند که فقط باید کدهای 4 رقمی را از mygovid.gov.au بپذیرد (و می داند چگونه TLS را بررسی کند). با این حال، ما معتقدیم که کاربران بسیار کمی در این دسته وجود دارد، زیرا این یک پروتکل ضد شهودی است که برای معکوس کردن جریان اطلاعات نسبت به آنچه کاربران به آن عادت دارند طراحی شده است.

به طور کلی به کاربران (از مدرسه ابتدایی) گفته می شود که وقتی می خواهند اعتبار ورود خود را وارد کنند، همیشه به دقت بررسی کنند که از وب سایت مناسب بازدید می کنند. در عمل ممکن است آنها همیشه این کار را به خوبی انجام ندهند، و اکثر مردم نمی دانند چگونه TLS را بررسی کنند، اما مرورگرها در این مورد بهتر می شوند – برای مثال، Firefox و Chrome هر دو اکنون هنگام بازدید کاربر از یک not-TLS هشدار می دهند. سایت محافظت شده، یا زمانی که برای ورود به سیستم و رمز عبور به روشی که مشکوک به نظر می رسد درخواست می شود. کلاینت‌های ایمیل معمولی وقتی پیوندی در جایی که به نظر می‌رسد نمی‌رود، هشدار می‌دهند. بنابراین اکثر مرورگرها و مشتریان ایمیل تلاش معقولی برای خنثی کردن واضح ترین حملات به جریان اطلاعات مبتنی بر رمز عبور سنتی انجام می دهند. این ناقص است، اما حداقل اکثر افراد تحصیل کرده (از جمله کودکان دبستانی) تا حدودی از این مشکل آگاه هستند.

هدف سیستم myGovID کاهش این مشکل (فرض می‌کنیم) با معکوس کردن جریان اطلاعات است، بنابراین کاربران هرگز رمز عبور یا کد 4 رقمی خود را به جز برنامه خود وارد نمی‌کنند. این یک هدف نجیب است، اما اجرای آن مشکل مشابه دیگری را ایجاد می کند.

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

هیچ چیز مشکوکی در مورد دریافت کد 4 رقمی از وب‌سایتی که می‌خواستید به آن وارد شوید وجود ندارد، در حالی که این امر در فرآیند احراز هویت معمولی هنگام استفاده از myGovID استاندارد است. کاربر به برنامه اعتماد دارد، بنابراین دریافت اعلان از برنامه در مورد ورود ممکن است نگرانی آنها را کاهش دهد. یک کاربر آگاه به ویژه ممکن است متوجه شود که کد از https://mygovid.gov.au نمی آید، اما در غیر این صورت هیچ چیز مشکوکی وجود ندارد: نه اعلان و نه ورود کد در برنامه هیچ نشانه ای از اینکه کد برای کدام وب سایت اعمال می شود ارائه نمی دهد. .

حتی در شرایط عادی، پروتکل myGovID می تواند برای کاربر گیج کننده باشد – شروع یک فرآیند احراز هویت در یک RP، رها کردن آن در هنگام ورود کد، و شروع یک فرآیند احراز هویت جدید در همان RP (به عنوان مثال، با رفتن به صفحه ورود کد و سپس با کلیک بر روی دکمه لغو، سپس وارد کردن همان ایمیل) یک پنجره ورودی کد نامعتبر در برنامه ایجاد می شود، که پس از بسته شدن بلافاصله یک پنجره ورودی کد دیگر کاملاً غیرقابل تشخیص ظاهر می شود، که این بار معتبر است. در آن سناریو هر دو پنجره ورودی کد صادقانه هستند و با درخواست های ورود معتبر در یک RP ثبت شده و قابل اعتماد مطابقت دارند. با این حال، آنها کاملاً غیرقابل تشخیص هستند: هیچ چیز به کاربر نشان نمی دهد که از کدام RP هستند، زمانی که ورود به سیستم شروع شده است یا اینکه اولین پنجره ورودی کد دیگر معتبر نیست و یک پنجره بازشو دوم در انتظار توجه کاربر است. با وارد کردن کد از دومین تلاش برای ورود به سیستم در اولین بازشو ورود کد، یک پیام مرموز “مشکلی در کد وجود دارد. دوباره امتحان کنید” به دست می‌آید، بدون اینکه نشانی از خطا وجود داشته باشد و دلیلی وجود ندارد که کاربر انتظار خطا داشته باشد. روی دادن.

این نوع تجربه کاربری گیج کننده حتی به کاربران معمولی هوشیار می آموزد که چیزهایی را که در غیر این صورت عجیب به نظر می رسد نادیده بگیرند، و فقدان زمینه myGovID برای درخواست های ورود به سیستم این موضوع را تشدید می کند که این حمله را نگران کننده تر می کند.

کاهش و تاثیر آنها

کوتاه مدت – برای کاربران

به کاربران توصیه می شود تا زمانی که پروتکل وصله نشده است از سیستم myGovID استفاده نکنند.

اگر استفاده از سیستم myGovID اجتناب ناپذیر است، هر کاربر باید به دقت بررسی کند که کد 4 رقمی که می‌خواهد وارد کند از یک URL محافظت شده با TLS در https://mygovid.gov.au باشد. این بعید است که در عمل برای اکثر کاربران کار کند، زیرا برای شناسایی یک وب سایت امن با URL مناسب مشکل دارند.

کوتاه مدت – برای دولت

حتی اگر همه کاربران با دقت بررسی بالا را انجام دهند، باز هم می‌توان یک نسخه تصادفی از همان حمله را امتحان کرد: وب‌سایت مخرب به طور صادقانه (اما با کمی تاخیر) کاربر را به سایت ورود واقعی mygovid.gov.au ارسال می‌کند، در حالی که موارد دیگر به سرعت سعی می کنید به عنوان آن کاربر در جای دیگری وارد شوید. مگر اینکه محافظت های دقیقی وجود داشته باشد تا اطمینان حاصل شود که کدهای 4 رقمی هرگز یکسان نیستند، احتمال 1/10000 وجود دارد که کدها مطابقت داشته باشند، اگر فرصتی را برای چند حدس زدن فرض کنیم، بیشتر است. بدون مشاهده الگوریتم تولید کد، نمی‌توانیم بگوییم که آیا چنین کاهشی وجود دارد یا خیر، اما اگر نه، باید فوراً اضافه شود.

برنامه همچنین باید بلافاصله با کاهش ساده زیر به روز شود:

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

از نظر فنی، این با اهداف اعلام شده چارچوب شناسایی دیجیتال معتمد، که در آن تبادل هویت (ارائه شده توسط auth.ato.gov.au در مثال ما) هویت طرف متکی را پنهان می کند (در مثال ما nottrustworthy.com) ناسازگار است. از Identity Provider (در مثال ما myGovID). با این حال، ATO’s Identity Exchange هویت RP را از طریق هدر HTTP Referer به myGovID فاش می کند، بنابراین این اطلاعات از قبل در دسترس است و می تواند به عنوان یک کاهش استفاده شود. به نظر می رسد پنهان کردن هویت RP از برنامه در مقایسه با جلوگیری از ورودهای جعلی، یک هدف بسیار کم اولویت باشد.

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

دراز مدت

در درازمدت، TDIF و تمام پیاده‌سازی‌های فعلی آن باید منسوخ شده و با یک استاندارد باز مانند OpenID Connect یا پروتکلی با الگوبرداری از کشوری با زیرساخت کلید عمومی ایمن مانند بلژیک یا استونی جایگزین شوند. اسناد پیاده سازی و طراحی باید آشکارا در دسترس عموم استرالیا باشد تا امکان شناسایی و افشای مسئولانه سایر آسیب پذیری ها را فراهم کند.

ما هیچ دلیلی نداریم که باور کنیم این تنها یا بدترین آسیب پذیری در این سیستم است. ماهیت پیچیده آن و تمایل به پنهان کردن اطلاعات، اعمال و تأیید رفتار صحیح و ایمن را تقریباً غیرممکن می کند.

سابقه افشای مسئولانه

این مشکل در 19 آگوست 2020 به اداره سیگنال های استرالیا فاش شد، با انتظار یک دوره افشای 90 روزه. ASD آن را به ATO مخابره کرد. در جلسه ای در 18 سپتامبر 2020، ATO به ما گفت که آنها قصد تغییر پروتکل را ندارند، در این مرحله ما بلافاصله به آنها اطلاع دادیم که در روز دوشنبه 21 سپتامبر به کاربران هشدار می دهیم.

سپاسگزاریها

از راد تیگ و اندرو کانوی برای کمکشان تشکر می کنیم. همچنین از Yaakov Smith برای بررسی مفید این اثر تشکر می کنم.

استفاده و مخاطبین

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

تماس با ایمیل: bfrengley [at] student.unimelb.edu.au یا ونسا [at] thinkingcybersecurity.com

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.