التصيد الاحتيالي لرمز جهاز OAuth: مقارنة بين Azure وGoogle

كتبه مات كيلي، الباحث الأمني ​​الرئيسي في Huntress

تعال معي في رحلة بينما نتعمق في الجنون المتردد لهجمات الهوية. اليوم، أقدم دراسة حالة حول كيف يمكن أن يكون للتطبيقات المختلفة لـ OAuth 2.0، وهو مخطط المصادقة الأساسي المستخدم في معظم موفري الهوية، أسطح هجوم مختلفة جذريًا.

موضوعات دراسة الحالة اليوم هما متجران تكنولوجيان ناشئان متناقضان يقعان مباشرة خارج وادي السيليكون: مايكروسوفت و جوجل. ربما سمعت عنهم؟

دعونا نلقي نظرة على كيفية تكديس إحدى هجمات الهوية المفضلة لدي، وهي التصيد الاحتيالي لرمز الجهاز، بين موفري الهوية هذين. بحلول نهاية هذه المدونة، ستقدر عزيزي القارئ كيف يقارن تطبيق OAuth 2.0 بين موفري الهوية هذين وكيف يسهل ذلك أو ينفي نطاق الانفجار لهذا الهجوم المفرط القوة بشكل مباشر.

على استعداد للحصول على نردي معها؟ دعونا الحصول على نردي معها.

تلبية تدفق رمز الجهاز

قبل أن نفهم التصيد الاحتيالي لرمز الجهاز، نحتاج إلى فهم الميزة التي تسمح بوجود هذا الهجوم في المقام الأول. لنبدأ بتحليل مستقل للتنفيذ للميزة المعنية وكيفية استغلالها. الوقت للقاء تدفق رمز الجهاز، ويعرف أيضا باسم منح ترخيص الجهاز!

قرأت”https://datatracker.ietf.org/doc/html/rfc8628″ rel=”nofollow noopener”> آر إف سي لذلك ليس عليك القيام بذلك. على الرغم من أنني أوصي به إذا كنت تبحث عن أداة مساعدة للنوم.

يتم استخدام منحة ترخيص الجهاز في السيناريوهات التي يرغب فيها الشخص في مصادقة جهاز متصل بالإنترنت يفتقر إلى آلية إدخال تقليدية مثل لوحة المفاتيح أو متصفح الويب أو ما شابه. يستدعي RFC هذه أجهزة مقيدة الإدخال. لنتخيل أن لديك طابعة إنترنت الأشياء المتوسطة، أو التلفزيون الذكي، أو محمصة الخبز المزودة بتقنية wifi مع شاشة تعمل باللمس، أو أي نوع آخر من الأجهزة المتصلة بالإنترنت ولكنها تفتقر إلى واجهة مستخدم كاملة الميزات.

إذا كنت ترغب في مصادقة محمصة الخبز التي تدعم تقنية wifi في المستأجر السحابي الخاص بك (وفي الحقيقة، من الذي لا يريد إثارة القيام بذلك؟)، فلديك مشكلة بين يديك. لا يمكنك تصفح صفحة تسجيل الدخول الخاصة بالمستأجر من محمصة الخبز وإدخال اسم المستخدم وكلمة المرور الخاصة بك. ولكن دعونا نتخيل في هذا السيناريو أن محمصة الخبز الخاصة بك تحتوي على شاشة تعمل باللمس حيث يمكنك إدخال رمز مكون من ستة أرقام. لا يمكنك تصفح صفحة تسجيل الدخول وكتابة اسم المستخدم وكلمة المرور الخاصة بك، فكيف يمكنك التحقق من محمصة الخبز؟

يسمح لك تدفق رمز الجهاز بما يلي:

• ابدأ عملية المصادقة من المحمصة عن طريق طلب أ رمز الجهاز
• انتقل إلى جهاز كمبيوتر باستخدام لوحة المفاتيح ومتصفح الويب
• استخدم متصفح الويب لإدخال رمز الجهاز مع بيانات الاعتماد الخاصة بك لإكمال عملية المصادقة، ثم…
• ارجع إلى المحمصة واحصل على رمز الوصول الذي قمت بإنشائه عن طريق تسجيل الدخول.

يؤدي هذا إلى حل مشكلة مصادقة الأجهزة ذات المدخلات المقيدة بشكل فعال. الحوزة! الآن يمكنك ضم محمصة الخبز الخاصة بك إلى المستأجر الخاص بك.

إذا كان هذا يبدو متخصصًا للغاية، فهذا لأنه كذلك. تتميز ميزة OAuth هذه بتطبيق ضيق ولا يتم استخدامها إلا في عدد قليل من السيناريوهات بواسطة أنواع معينة من المستخدمين. ببساطة، من المحتمل ألا يحتاج المستخدم العادي في الشركات الصغيرة والمتوسطة إلى معرفة تدفق رمز الجهاز.

إذا كان المتسللون جيدين في أي شيء، فهو العثور على ميزات متخصصة مثل تدفق رمز الجهاز وتحويل طريقة المصادقة لمرة واحدة هذه إلى ناقل للوصول الأولي. لذلك دعونا نتحدث عن التصيد الاحتيالي باستخدام رموز الجهاز!

التصيد الاحتيالي لرمز الجهاز في M365

إن التصيد الاحتيالي عن طريق استغلال تدفق رمز الجهاز ليس بالأمر الجديد. لقد كتب بالفعل بعض الباحثين العظماء في مجال الهوية في عصرنا حول هذا الموضوع، بما في ذلك”https://aadinternals.com/post/phishing/” rel=”nofollow noopener”> د. نيستوري سينما,”https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/” rel=”nofollow noopener”>ديرك جان موليما، و”https://www.inversecos.com/2022/12/how-to-detect-malicious-oauth-device.html” rel=”nofollow noopener”> لينا لاو (@inversecos). من خلال تطبيق بعض براعة الهندسة الاجتماعية، يمكن اختيار تدفق رمز الجهاز واستخدامه بشكل ضار لإنشاء رمز وصول إلى بعض الموارد التي يمكن للمهاجم استعادتها بعد ذلك.

وإليكم كيف تسير الأمور:

• يطلب المهاجم رمز الجهاز من واجهة برمجة تطبيقات رمز الجهاز الخاصة بموفر الهوية. لا يتطلب طلب الرمز المصادقة ويستخدم واجهة برمجة التطبيقات المشروعة تمامًا للقيام بذلك.
• يقوم المهاجم بإنشاء بريد إلكتروني مقنع ويرسله إلى الضحية، مما يجبر الضحية على الانتقال إلى صفحة تسجيل الدخول إلى رمز الجهاز وإدخال الرمز.
• يلتزم الضحية وينتقل إلى صفحة تسجيل الدخول إلى رمز الجهاز المشروعة تمامًا حيث يقوم بإدخال رمز الجهاز واسم المستخدم وكلمة المرور ورمز MFA الخاص به. وبعد ذلك… لا يحدث شيء، على الأقل من وجهة نظر الضحية…
• …ولكن المهاجم كان يراقب واجهة برمجة تطبيقات رمز الجهاز طوال الوقت ويسأل كل 10 ثوانٍ “هل تمت مصادقتهم بعد؟” بمجرد قيام المستخدم بإكمال المصادقة، تقوم واجهة برمجة التطبيقات (API) لمصادقة رمز الجهاز بإنشاء مجموعة من رموز الوصول المميزة للضحية.
• يطلب المهاجم مجموعة الرموز المميزة، والتي يقوم بتحويلها إلى الوصول الأولي.

دعونا نلقي نظرة على مثال ملموس حيث يتم استخدام تدفق التعليمات البرمجية لجهاز Azure لتنفيذ هذا الهجوم.

أولاً، يطلب المهاجم رمز الجهاز. يعد هذا أمرًا بسيطًا مثل تجعيد واجهة برمجة تطبيقات تدفق التعليمات البرمجية لجهاز Azure. تذكر: كمهاجم، يمكنني القيام بذلك. لست بحاجة إلى المصادقة أو إثبات هويتي. وطالما قمت ببناء الطلب بشكل صحيح، فسوف تقوم واجهة برمجة التطبيقات (API) بتسليم رمز الجهاز لبدء العملية. سيبدو طلب cURL هكذا…

حليقة -X مشاركة "https://login.microsoftonline.com/common/oauth2/devicecode?api-version=1.0"  -ح "Content-Type: application/x-www-form-urlencoded"  -د "client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c&resource=https://graph.microsoft.com"

…أين:

• عنوان URL المطلوب هو نقطة نهاية API لمصادقة رمز الجهاز الشائعة في Azure.
• المعلمةclient_id هي المعرف الفريد العمومي (GUID) للعميل الطالب (انتبه لهذا؛ سيكون مهمًا لاحقًا).
• معلمة المورد هي المورد المطلوب. في هذه الحالة، نطلب من واجهة برمجة التطبيقات (API) إنشاء مجموعة من الرموز المميزة التي يمكنها مصادقة جهاز باستخدام Graph API.

إذا تم تنسيق طلب cURL بشكل صحيح، فستستجيب واجهة برمجة التطبيقات بكائن JSON ثنائي كبير الحجم يحتوي على رمز الجهاز، ورمز المستخدم، وبعض الإرشادات المفيدة حول كيفية استخدامها:

في هذه المرحلة، في سيناريو مصادقة رمز الجهاز الشرعي، سينتقل المستخدم من هذا الجهاز المقيد بالإدخال إلى جهاز كمبيوتر مزود بمتصفح ويب، ويتصفح للوصول إلى”https://microsoft.com/devicelogin” rel=”nofollow noopener”>https://microsoft.com/devicelogin، وقم بتسجيل الدخول باستخدام متصفح الويب الخاص بهم. ولكن في سيناريو الهجوم، يقوم المهاجم بصياغة عملية تصيد مقنعة توجه المستخدم للانتقال إلى نفس صفحة تسجيل الدخول إلى رمز الجهاز، وتسجيل الدخول، وانتظار المزيد من التعليمات.

لنفترض أن المهاجم قد أرسل هذا التصيد بحجة مقنعة، لذلك يتصفح الضحية”https://microsoft.com/devicelogin” rel=”nofollow noopener”>https://microsoft.com/devicelogin وإدخال الرمز المقدم، متجاهلاً التحذير بشأن إدخال رموز من مصادر غير موثوقة…

ثم تطالب الصفحة الضحية باسم المستخدم وكلمة المرور …

… وينتقل إلى شيك وزارة الخارجية، الذي يلزم الضحية…

تعرض الصفحة بعد ذلك سؤالًا أخيرًا يسألك عما إذا كانت الضحية تحاول تسجيل الدخول إلى Microsoft Office، والذي يفترض المستخدم أنه أمر روتيني وينقر على “متابعة”…

وأخيرًا، يرى الضحية هذا (الشكل 9):

وهذا بالطبع أمر محير للغاية إذا كنت أنت من وقع ضحية لهذا الهجوم.

وفي الوقت نفسه، في مكان آخر، يقوم المهاجم بإنشاء أمر cURL آخر لاستقصاء واجهة برمجة تطبيقات مصادقة Azure:

curl   --data client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c   --data resource=https://graph.microsoft.com   --data grant_type=urn:ietf:params:oauth:grant-type:device_code   --data code=EAQABIQ......[snip]..... "https://login.microsoftonline.com/Common/oauth2/token?api-version=1.0

…أين:

• معلمات Client_id وResource هي نفس الطلب الأولي
• يحدد Grant_type أن طريقة المصادقة المستخدمة لهذا الرمز المميز هي تدفق رمز الجهاز
• معلمة الكود هي رمز الجهاز الذي تم إرجاعه من الطلب الأولي
• عنوان URL هنا هو نقطة نهاية الرمز المميز لـ Azure OAuth، والتي تتعامل مع الطلب والاستجابة لإنشاء الرموز المميزة للمصادقة.

بمجرد وقوع المستخدم ضحية للتصيد الاحتيالي، تولد المصادقة الخاصة به مجموعة من الرموز المميزة الموجودة الآن في نقطة نهاية واجهة برمجة تطبيقات رمز OAuth ويمكن استردادها من خلال توفير رمز الجهاز الصحيح. يعرف المهاجم بالطبع رمز الجهاز لأنه تم إنشاؤه بواسطة طلب cURL الأولي إلى واجهة برمجة تطبيقات تسجيل الدخول إلى رمز الجهاز. وعلى الرغم من أن هذا الرمز عديم الفائدة في حد ذاته، بمجرد خداع الضحية للمصادقة، فإن الرموز المميزة الناتجة تنتمي الآن إلى أي شخص يعرف رمز الجهاز الذي تم استخدامه في الطلب الأصلي.

يؤدي الهجوم الناجح إلى حصول المهاجم على رمز الوصول و أ رمز التحديث والتي تكون فعالة للضحية المخادعة. تكون الرموز المميزة فعالة بالنسبة للمورد المطلوب (في هذه الحالة، Graph API) وتمتد إلى مجموعة من أذونات OAuth التي تسمح للمهاجم بالوصول إلى الموارد كما لو كان ضحية التصيد الاحتيالي. اكتمل الهجوم، وتم اكتساب الوصول الأولي، ومجرم الإنترنت سعيد!

هناك بعض الأشياء التي تجعل هذا الهجوم خبيثًا.

أولاً، يستخدم هذا الهجوم تدفق المصادقة المشروعة بدلاً من استغلال بعض الثغرات الأمنية أو الأخطاء. يظل سياق التصيد الاحتيالي بأكمله قيد التشغيل البنية التحتية الشرعية لمايكروسوفت، استخدام واجهات برمجة تطبيقات Microsoft المشروعة، لأداء شرعي (إذا لم يكن كذلك مختطف) تدفق مصادقة رمز الجهاز. لا يوجد استغلال حقيقي يحدث أثناء هذا الهجوم بخلاف خداع شخص ما لاستخدام تدفق رمز الجهاز عندما لا ينبغي له ذلك.

ثانيًا، نظرًا للنقطة السابقة المتعلقة باستخدام وظيفة المصادقة الشرعية، يستطيع المهاجم استخدام عناوين URL الشرعية أثناء جزء التصيد الاحتيالي. قد يعرف المستخدم الذي خضع للتدريب على التوعية الأمنية أنه يشك في الأمر بحق الروابط، ولكن قد يخذلون حذرهم عندما يرون”https://microsoft.com/devicelogin” rel=”nofollow noopener”>https://microsoft.com/devicelogin كعنوان URL. لا أقوم بإلغاء تحديد عنوان URL هذا في نص هذه المدونة لسبب ما – فزيارة هذا الموقع مشروعة تمامًا وحميدة وآمنة بنسبة 100%. من خلال المثال الموثق أعلاه، لم أضطر مطلقًا إلى إرسال الضحية إلى موقع غير واضح وأطلب منهم إدخال بيانات اعتمادهم. لذا تخيل مدى قوة الأمر عندما تتمكن، بصفتك المهاجم، من استخدام عنوان URL شرعي من Microsoft لهجوم التصيد الاحتيالي.

وأخيرًا (والأهم من ذلك)، يتحكم المهاجم في نوع معين من الموارد والرموز المميزة التي يتم إنشاؤها نتيجة لهذا الهجوم. في المثال أعلاه، يقوم المهاجم بإنشاء رمز جهاز يتم تحديد نطاقه لـ Graph API ويحدد معرف العميل. هل تتذكر كيف قلت لك أن تتذكر معرف العميل لأنه سيكون مهمًا لاحقًا؟ حسنًا…

معرف العميل في المثال أعلاه ليس سلسلة عشوائية من الأحرف. في الواقع، يتضمن تطبيق OAuth من Microsoft مجموعة غير موثقة من معرفات العملاء المتوفرة مجانًا لأي شخص لاستخدامها أثناء تدفقات المصادقة. وهذا ما يسمى”https://github.com/secureworks/family-of-client-ids-research?tab=readme-ov-file#which-client-applications-are-compatible-with-each-other” rel=”nofollow noopener”> عائلة معرفات العملاء وتم اكتشافها مؤخرًا من قبل باحثي Secureworks. هذا الموضوع معقد للغاية، ولكن لتلخيصه بإيجاز: يؤدي الجمع بين معرف العميل والمورد المطلوب إلى إنشاء رمز مميز يمكن نطاقه لأشياء مختلفة.

على سبيل المثال، معرف العميل المستخدم في المثال أعلاه يتوافق مع عميل Microsoft Office. عندما يتم إنشاء الرمز المميز لـ Graph API، يمكن استخدام الرمز المميز الناتج للاتصال بـ Graph API وقراءة رسائل البريد الإلكتروني للمستخدم، والاطلاع على تقويمه، وقراءة ملفاته، والعديد من الأشياء الأخرى كما هو محدد في نطاق الرمز المميز:

"scp": "AuditLog.Create AuditLog.Read.All Calendar.ReadWrite Calendars.Read.Shared Calendars.ReadWrite Contacts.ReadWrite DataLossPreventionPolicy.Evaluate Directory.AccessAsUser.All Directory.Read.All Files.Read Files.Read.All Files.ReadWrite.All Group.Read.All Group.ReadWrite.All InformationProtectionPolicy.Read Mail.ReadWrite Mail.Send Notes.Create Organization.Read.All People.Read People.Read.All Printer.Read.All PrinterShare.ReadBasic.All PrintJob.ReadWriteBasic SensitiveInfoType.Detect SensitiveInfoType.Read.All SensitivityLabel.Evaluate Tasks.ReadWrite TeamMember.ReadWrite.All TeamsTab.ReadWriteForChat User.Read.All User.ReadBasic.All User.ReadWrite Users.Read",

على الرغم من أن مجموعة معرفات العملاء رائعة، إلا أنها تقع إلى حد كبير خارج نطاق منشور المدونة هذا. لكن الوجبات الرئيسية اثنين هي:

• يحدد المهاجم المورد المطلوب ومعرف العميل في الطلب الأصلي، مما سيؤثر على قوة الرمز المميز الذي تم إنشاؤه
• لدى Microsoft مجموعة من معرفات العملاء المتاحة للجمهور والمعترف بها عالميًا والتي تؤثر على نطاق الرمز المميز الناتج.

لتوضيح قوة السماح للمهاجم بالتحكم في المورد ومعرف العميل أثناء المصادقة، لا تنظر إلى أبعد من ذلك”https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/” rel=”nofollow noopener”>مدونة Dirk-jan حول التصيد الاحتيالي لرموز التحديث الأساسية، حيث يوضح كيف يمكن للمهاجم الاستفادة من التصيد الاحتيالي لرمز الجهاز لإنشاء رمز التحديث الأساسي وسرقته للوصول الأولي. والجدير بالذكر أن هذا ممكن لأن المهاجم يمكنه تعيين مورد طلب رمز الجهاز كـ https://enrollment.manage.microsoft.com/ ومعرف العميل إلى وسيط مصادقة Microsoft (29d9ed98-a469-4536-ade2-f981bc1d605e). الرمز المميز الناتج عن التصيد الاحتيالي الناجح للضحية باستخدام هذه المعلمات هو أقوى نوع من الرموز المميزة في مخطط الرمز المميز لـ Azure OAuth.

يمكن استخدام هذا الرمز المميز، من بين أشياء أخرى، لتسجيل الدخول إلى موارد الويب، وربط الأجهزة المارقة بالمستأجر، وإنشاء تسجيلات مصادقة متعددة العوامل، وغير ذلك الكثير. إنه أقوى رمز مميز على مسافة ميل واحد وهو مجرد رمز جهاز صغير يتم تصيده بعيدًا عن سيطرة المهاجم!

(جانبًا، إذا كنت مهتمًا بأبحاث الهوية والفريق الأحمر، اقرأ كل مدونة نشرها ديرك جان. لن تشعر بخيبة أمل.)

هل يكون الأمر هكذا؟

لقد أوضحنا كيفية تنفيذ التصيد الاحتيالي لرمز الجهاز في Azure وأنه فعال للغاية. يتحكم المهاجم في نوع معين من الموارد ونطاق الرموز المميزة الناتجة. إنه هجوم يعيش بالكامل داخل النظام البيئي لشركة Microsoft. وفي أسوأ الأحوال، يمكن استخدامه لسرقة أقوى نوع من الرموز الموجودة.

لكن تذكر أن تدفق مصادقة رمز الجهاز ليس آلية خاصة بـ Azure. بدلاً من ذلك، يقوم Azure بتنفيذ تدفق تعليمات برمجية للجهاز كوسيلة للمصادقة. تأتي مواصفات تدفق رمز الجهاز من OAuth 2.0 RFC. Azure ليس موفر الهوية الوحيد الذي ينفذ تدفق تعليمات برمجية للجهاز. لذلك لم يسعني إلا أن أتساءل…

هل هذا يعني أنه بغض النظر عن موفر الهوية الذي تستخدمه، فإن التصيد الاحتيالي لرمز الجهاز لا يقل خطورة؟ هل يكون الأمر هكذا فحسب؟

تنبيه المفسد! الجواب هو، من المدهش، لا. وليس علينا أن ننظر إلى ما هو أبعد من جوجل لرؤية مثال حيث يكون لتفاصيل التنفيذ تأثير هائل على مقدار الضرر الذي يمكن أن تحدثه هذه التقنية.

جوجل: Nerfed مباشرة خارج الصندوق

لنفترض أننا نشارك في مشاركة الفريق الأحمر ضد عميل يستخدم Google كموفر هوية أساسي له. دعنا نحاول إعادة إنشاء هجوم التصيد الاحتيالي لرمز الجهاز باستخدام Google Workspace / Google Cloud APIs. كما هو الحال دائمًا، فإن المكان الرائع للبدء هو”https://developers.google.com/identity/protocols/oauth2/limited-input-device” rel=”nofollow noopener”> وثائق المطور. وعلى الفور، يصبح من الواضح أننا سنخوض معركة شاقة:

تنص الوثائق بوضوح على أنه ليست كل النطاقات مدعومة بتدفق رمز الجهاز. لكن المتسللين لا يفقدون الأمل أبدًا، لذلك دعونا نفحص النطاقات المدعومة:

إذا كنت على دراية بنطاقات OAuth 2.0 وإمكانية إساءة استخدامها بشكل عام من قبل المهاجمين، فربما تكون قد سقطت للتو من مقعدك. إذا لم تكن مألوفًا، فيمكنني تلخيص الأمر بهذه الطريقة – النطاقات الثلاثة الأولى عالمية عبر جميع تطبيقات OAuth 2.0 وOpenID Connect (OIDC) وتسمح باستغلال محدود، إن وجد. النطاقات المدعومة المتبقية ضيقة للغاية عندما نبحث عن أساسيات الاستغلال.

مثل، كن صادقًا معي الآن – في Azure، يمكنك إعداد هجوم تصيد احتيالي لرمز الجهاز حيث تسمح لك الرموز المميزة الناتجة بأن تصبح المستخدم الضحية بشكل أساسي، والانضمام إلى جهاز مارق للمستأجر الضحية، وتسجيل الدخول إلى بريده الإلكتروني والموارد الأخرى، وغيرها من أنواع الوصول القوية بشكل لا يصدق. وفي Google، يمكننا استخدام نطاق إذن ملف GDrive من أجل… – التحقق من الملاحظات – “رؤية وتحرير وإنشاء وحذف ملفات Google Drive المحددة التي تستخدمها مع هذا التطبيق فقط”.

حتى قبل أن نبدأ الهجوم، أدى تنفيذ Google لتدفق رمز الجهاز إلى تحييد احتمالات الهجوم بشكل فعال. إذا أراد أي من أعضاء الفريق الأحمر الذين قرأوا هذا إخباري بكيفية تحويل نطاق youtube.readonly إلى عملية استحواذ على الحساب، فأنا كلي آذان صاغية (لا أمزح، اضربني: matt.kiely)[at]huntresslabs.com وأود أن أتحدث). لكنني لا أحبس أنفاسي.

لكن الأمل ينبثق إلى الأبد، لذلك دعونا نحاول تنفيذ الهجوم على أي حال. بقدر ما أستطيع أن أقول، لا توجد معرفات عملاء عامة لـ Google كما هو الحال في Azure. لذا، إذا أردنا تنفيذ الهجوم، فنحن بحاجة إلى معرف العميل. الطريقة الموصى بها للحصول على معرف العميل هي”https://support.google.com/cloud/answer/6158849?hl=en” rel=”nofollow noopener”> أنشئ تطبيق Google Workspace وقم بتكوينه لاستخدام OAuth 2.0. لذا، إذا كنت تأمل في الحصول على بعض مظاهر عدم الكشف عن هويتك أثناء تنفيذ الهجوم، فيمكنك التخلص من ذلك.

حتى إذا كنت تواجه مشكلة إنشاء تطبيق OAuth داخل Google، فلا تزال هناك ضوابط ووسائل حماية أخرى مطبقة. على سبيل المثال، إذا كان تطبيقك يتطلب عددًا كبيرًا جدًا من الأذونات القوية، فيجب نشره والتحقق منه قبل أن يتمكن أي شخص من استخدامه:

ولكن هذا لن يكون مشكلة بالنسبة لنا، تذكر؟ نحن مقيدون بأربعة نطاقات من الأذونات: اثنان لـ GDrive واثنان لموقع YouTube. نحن لا نعمل بالضبط مع أدوات الاستغلال القوية هنا.

الخطوات الفنية لطلب رمز الجهاز من Google هي نفسها إلى حد كبير كما هو الحال مع Azure. من أجل التنوع، سنستخدم بايثون للقيام بالطلب الأولي واستقصاء نقطة النهاية حتى تكتمل المصادقة:

طلبات الاستيراد وقت الاستيراد # استبدلها بمعرف عميل Google OAuth الخاص بك. وأفضل ما يمكنني قوله هو أنه لا توجد معرفات عملاء عامة في Google، لذا فأنت وحدك من يمكنه شراء واحدة. CLIENT_ID="[YOUR APPLICATION'S CLIENT ID]"CLIENT_SECRET="[YOUR APPLICATION'S CLIENT SECRET]"DEVICE_AUTH_URL='https://oauth2.googleapis.com/device/code' TOKEN_URL='https://oauth2.googleapis.com/token' SCOPE='https://www.googleapis.com/auth/drive.file ملف تعريف البريد الإلكتروني المفتوح' def get_device_code(): data={ 'client_id': CLIENT_ID, 'scope': SCOPE } استجابة=طلبات.post(DEVICE_AUTH_URL, بيانات=بيانات) استجابة.raise_for_status() إرجاع استجابة.json() def poll_for_token(device_code,فاصل زمني): بينما True: data={ 'client_id': CLIENT_ID، 'client_secret': CLIENT_SECRET، 'device_code': رمز_الجهاز، 'grant_type': 'urn:ietf:params:oauth:grant-type:device_code' } Response=request.post(TOKEN_URL, data=data) if Response.status_code==200: return Response.json() elif Response.status_code==428: print("Authorization pending... waiting.") إليف Response.status_code==403: طباعة ("Access denied. Exiting.") استراحة أخرى: طباعة ("An error occurred:"، Response.json()) وقت القطع.sleep(interval) def main(): Device_data=get_device_code() print("Visit this URL to authorize the application:"بيانات_الجهاز['verification_url'])     مطبعة("Enter this code:"بيانات_الجهاز['user_code']) token_data=poll_for_token(device_data['device_code']بيانات_الجهاز['interval']) إذا token_data: طباعة ("Access token received:"token_data['access_token'])         مطبعة("Refresh token:"، token_data.get('refresh_token', 'None')) إذا __name__=='__main__': main()

عندما نقوم بتشغيل البرنامج النصي، فإنه يعطينا رمز الجهاز. نحن ظاهريًا نقوم بالتصيد الاحتيالي للمستخدم ونطلب منه المصادقة تمامًا كما هو الحال مع هجوم التصيد الاحتيالي لرمز جهاز Azure:

بمجرد قيام الضحية بإدخال بيانات الاعتماد الخاصة به، نحصل على رمز الوصول ورمز التحديث! لكن حظًا سعيدًا في استخدام أي منهما للحصول على وصول أولي نظرًا للنطاق المحدود.

ملاحظة هامة: لقد قمت بالفعل بخدش سطح الهجوم باستخدام Google مقارنةً بـ Azure. قد تكون هناك معرفات عملاء غير موثقة، ونطاقات غير موثقة متاحة للاستغلال، والعديد من نواقل الهجوم المحتملة الأخرى غير المعروفة لي و/أو للمجتمع. ولكن أعتقد أنه من الواضح بالفعل أن نواقل الهجوم في جوجل تعد السحابة محدودة بشكل ملحوظ مقارنة بنظيراتها في Azure.

التحليل والاستنتاج

فرق كبير بين مقدمي الهوية!

إذا كان بإمكاني تلخيص الوجبات الرئيسية هنا، فهي كما يلي: تدرك Google أن تدفق رمز الجهاز متخصص ولا يُستخدم إلا في سيناريوهات معينة ويحد من النطاقات المتاحة لتدفق رمز الجهاز وفقًا لذلك. مايكروسوفت لا تضع مثل هذه القيود.

يمكنك أن تتخيل سبب اختيار Google لتنفيذه بهذه الطريقة. تتعلق مجموعتا الأذونات بـ GDrive وYouTube. تدرك Google أن أنواع الأجهزة العميلة التي من المحتمل أن تستخدم تدفق مصادقة رمز الجهاز هي أجهزة التلفاز الذكية (حتى أن الوثائق تحدد ذلك في العنوان! “OAuth 2.0 لتطبيقات التلفزيون وأجهزة الإدخال المحدودة”). ليس من الصعب أن نتخيل أن أنواع الوصول التي يحتاجها التلفزيون تتمحور حول الترفيه – “مرحبًا أيها التلفزيون الذكي، من فضلك قم بتشغيل مقطع الفيديو المفضل لدي على YouTube!”

لكن خذ لحظة لتقدير حقيقة أن تطبيقين لنفس ميزة OAuth لهما أسطح هجوم مختلفة جذريًا مرتبطة بكل منهما. أدى افتقار Azure إلى القيود على النطاقات والموارد المطلوبة بالفعل إلى قيام الباحثين بتحديد أساسيات الهجوم القوية للغاية لهجمات التصيد الاحتيالي لرمز الجهاز. لكن تطبيق Google يضع قيودًا صارمة على نفس النوع من الهجمات.

على الرغم من أنه من غير الواضح ما إذا كانت هجمات الهوية الأخرى (هجمات منح الموافقة، والانضمام إلى الأجهزة المارقة، وما إلى ذلك) فعالة في Google كما هي الحال في Azure، يمكننا أن نستنتج بأمان أن التصيد الاحتيالي لرمز الجهاز أقل فعالية بشكل كبير في Google Cloud منه في Azure.

نفس الميزة. نفس التصميم. تطبيقات مختلفة. أسطح هجوم مختلفة جذريًا! يظهر لك: على الرغم من أن جميع تطبيقات OAuth 2.0 متساوية، فقد تبين أن بعضها أكثر مساواة قليلاً من غيرها.

الاختراق المباشر: كسر تقنيات هجوم Microsoft 365

انضم إلى الرئيس التنفيذي لشركة Huntress والعميل السابق في وكالة الأمن القومي كايل هانسلوفان”http://www.huntress.com/upcoming-webinars/live-hack-microsoft-365?utm_source=bleepingcomputer&utm_medium=article&utm_campaign=cy25-q4-1113-web-multi-na-prospect-all-x-demo-live_hacking_into_m365″ الهدف=”_blank” rel=”nofollow noopener”> عرض القرصنة الحية. شاهد كيف يقوم المتسللون بسرقة بيانات الاعتماد وتجاوز MFA واختراق الأنظمة في دقائق. تعرف على أهم التهديدات لعام 2026: الهندسة الاجتماعية، وسرقة بيانات اعتماد المتصفح، وهجمات الأنظمة المترابطة.

يحصل الحاضرون على وصول مجاني إلى تقييم أمان الهوية الخاص بنا لـ Microsoft 365، والكشف عن نقاط الضعف وتوفير إرشادات الإعداد لعرض القرصنة الخاص بك.

لا تفوت هذه الفرصة لتقوية دفاعاتك والتغلب على مجرمي الإنترنت المعاصرين. تعال وكن مظللاً وتعلم واستعد لتحدي الحرف التجارية اليوم!

سجل في Live Hack

برعاية وكتابة”http://www.huntress.com/?utm_source=bleepingcomputer&utm_medium=article&utm_campaign=cy25-q4-1113-web-multi-na-prospect-all-x-demo-live_hacking_into_m365″ الهدف=”_blank” rel=”sponsored noopener”> مختبرات الصيادة.