التشغيل: إساءة استخدام Power Apps لاختراق الخوادم المحلية

توفر خدمات Microsoft Power Platform منصة منخفضة الكود/دون كود (LCNC) تشمل تحليلات البيانات (Power BI)، وتطوير المواقع الإلكترونية (Power Pages)، والمساعدين الافتراضيين (Power Virtual Agent)، ونوعًا من تطوير "التطبيقات الكاملة" (Power Apps). يمكن لهذه المنصات أن تمنح مستخدمي الأعمال الأقل خبرة من الناحية التقنية القدرة على إنشاء حلول تتطلب تقليديًا مطورًا تقنيًا أكثر خبرة في البرمجة.

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

في منشور المدونة هذا، سنستعرض كيف قام فريق محاكاة الخصوم في X-Force Red في عام 2022 بدمج تكوين خاطئ شائع في ذلك الوقت مع ثغرة تجاوز أمني لا تزال موجودة في منصة Microsoft Power Apps. مكَّن هذا فريق X-Force Red من اختراق محيط خارجي محصَّن وتنفيذ التعليمات البرمجية على خادم SQL محلي، ما أدى في النهاية إلى اختراق كامل لنظام Active Directory.

في عام 2022، كان السلوك الافتراضي لمنصة Power Apps يعني أنه عند مشاركة تطبيق Power Apps مع المستخدمين، تتم أيضًا مشاركة أي اتصالات مرتبطة به. وهذا جعل من السهل جدًا على المستخدمين مشاركة الاتصالات عن طريق الخطأ مع جميع مستخدمي المؤسسة، بينما قد يكون قصدهم فقط مشاركة واجهة التطبيق الأمامية. وفقًا لما أعلنت عنه Microsoft، تم تغيير هذا السلوك في يناير 2024، ما يقلل بشكل كبير من احتمالية قيام المستخدمين بمشاركة الاتصالات عن طريق الخطأ.

في عام 2022، رصد فريق X-Force Red اتصال SQL باستخدام "بوابة البيانات المحلية" (On-Premises Data Gateway) للاتصال بخادم SQL محلي، والذي تمت مشاركته على نطاق واسع بهذه الطريقة. رغم أن استعلامات SQL الأصلية غير مدعومة على خوادم SQL المحلية في تدفقات Power Apps، اكتشَف X-Force Red أن إجراء "تحويل البيانات باستخدام Power Query" يمكن استخدامه لتنفيذ استعلامات SQL أصلية على الخوادم المحلية. مكَّن هذا فريق X-Force Red من التحوُّل إلى خادم SQL المحلي وتحقيق جميع أهداف المهمة في النهاية.

تم الإبلاغ عن هذا الخطأ مؤخرًا إلى مركز Microsoft Security Response Center (MSRC)، وقد صنّفوه على أنه منخفض الخطورة، لذا ننشر الآن التفاصيل.

تُتيح Power Apps للمستخدمين إنشاء "تطبيقات" و"تدفقات" باستخدام واجهة سحب وإفلات رسومية، وهي الطريقة النموذجية لمنصات LCNC. يمكن استخدام التطبيقات لإنشاء تطبيقات الواجهة الأمامية التي تُستخدم بشكل عام لسحب البيانات من مكان ما وعرضها للمستخدم. وفيما يلي تطبيق تجريبي "Budget Tracker" مقدَّم من Microsoft، والذي يجمع بيانات من جدول بيانات Excel ويعرضها للمستخدم.

الجانب الآخر من Power Apps، وهو Flows، سيكون مألوفًا لأي شخص سبق له استخدام خدمة LCNC أخرى مثل Azure Logic Apps. تُتيح Flows للمستخدمين إنشاء برنامج يشبه المخطط الانسيابي، وعادةً ما تُستخدم لسحب البيانات ومعالجتها ثم إرسالها إلى مكان ما. فيما يلي تدفق بسيط جدًا يقوم بإجراء طلب HTTP ثم تحليل JSON الناتج.

تحتوي Power Apps على مجموعة من "الموصِّلات" التي تُتيح للمستخدمين تنفيذ مهام مثل استيراد البيانات أو إرسال البريد الإلكتروني، دون الحاجة إلى استخدام العديد من إجراءات طلبات HTTP. العديد من هذه الموصِّلات هي مكتبات جاهزة لطلبات HTTP، لكنها تخفي جميع التفاصيل التقنية عن المستخدم. بدلًا من الاضطرار إلى إنشاء طلب HTTP إلى Graph API للحصول على معلومات حول مستخدم Entra ID، يمكنك ببساطة توصيل موصِّل Entra ID واستخدام إجراء "الحصول على المستخدم".

توفِّر Power Apps موصِّلات للعديد من الخدمات الشهيرة، بما في ذلك خدمات Microsoft وخدمات الجهات الخارجية. يمكنك جلب الملفات من SharePoint، أو تحويل المستند إلى PDF باستخدام Adobe PDF Services، أو إعادة تشغيل الأجهزة الافتراضية في Azure، على سبيل المثال لا الحصر. عند إنشاء اتصال، ستتم مطالبتك بتقديم مواد المصادقة بناءً على الخدمة التي تتصل بها. بالنسبة لمعظم الأمور المتعلقة بـ Microsoft، يمكنك ببساطة تسجيل الدخول باستخدام حساب O365 الخاص بك.

ملاحظة: في بقية هذا المقال، سأستخدم مصطلح "موصِّل" للإشارة إلى مكتبة الإجراءات في Power Apps (مثل موصِّل Entra ID)، و"اتصال" للإشارة إلى الموصِّل الذي قام المستخدم بإنشائه والمصادقة عليه (مثل اتصال Entra ID المصادق عليه باسم john.smith@contoso.com) والذي يمكن استخدامه لإنشاء إجراءات جديدة.

ما دام هذا الاتصال موجودًا، ستظل المصادقة الخاصة بك مرتبطة به. أي مستخدم لديه حق الوصول إلى هذا الاتصال يمكنه إنشاء إجراءات جديدة تستخدم المصادقة الخاصة بك. على سبيل المثال، إذا أنشأت اتصال Entra ID، فقد يقوم مستخدم آخر لديه حق الوصول إلى هذا الاتصال بإنشاء إجراء "إضافة مستخدم إلى مجموعة"، والذي سيستخدم المصادقة الخاصة بك، حتى لو لم يكن لدى ذلك المستخدم الصلاحيات اللازمة في Entra ID لإضافة مستخدم إلى مجموعة. سبق أن كتبتُ عن استغلال هذا الأمر في Azure Logic Apps، ووجدتُ ثغرة عملية لرفع الامتيازات في Azure Logic Apps اعتمدت على إساءة استخدام هذه الوظيفة.

حتى عام 2024، كان هذا النوع من الهجمات أكثر احتمالًا لحدوثه في Power Apps. كان من المعتاد أنه عند مشاركة تطبيق يستخدم اتصالًا معيّنًا، تتم أيضًا مشاركة الاتصال المرتبط به. يمكنك الاطِّلاع على توثيق ذلك في هذه الصفحة من Microsoft، والتي لم يتم تحديثها منذ عام 2022. ومع ذلك، وفقًا لهذه الصفحة من عام 2024، لم يَعُد هذا الأمر صحيحًا. الآن، ستحتاج إلى أن تتم مشاركة الاتصال مع حسابك، وهو خطأ في التكوين أقل احتمالًا بكثير. قد يكون ذلك نتيجة لمحاضرة BlackHat 2023 بعنوان "All You Need Is Guest" بواسطة Michael Bargury، وهي محاضرة ممتازة تناولت أيضًا كيفية تعداد واستخراج المعلومات من Power Apps.

ماذا لو كنت بحاجة إلى الوصول إلى بيانات غير متوفرة على الإنترنت؟ ماذا لو كنت بحاجة إلى الوصول إلى البيانات من خادم SQL المحلي؟ فكَّرت Microsoft في هذا الأمر بالفعل وأنشأت بوابات بيانات محلية. يتم تثبيت البوابات على مضيف محلي وتعمل بشكل أساسي كوكيل يسمح لموصِّلات Power Apps بالتواصل مع الموارد المحلية. للوصول إلى خادم SQL محلي، يمكنك ببساطة تثبيت بوابة على خادم SQL (أو على خادم آخر، أو حتى على جهازك الشخصي إذا كان لديك ذكاء اصطناعي ظلي) ثم استخدام موصِّل SQL لتنفيذ الاستعلامات على الخادم.

هناك ستة أنواع مصادقة مدعومة للاتصال بخادم SQL، على الرغم من أن ليس جميعها تعمل مع خوادم SQL المحلية. بالنسبة للخوادم المحلية، من المحتمل أن تستخدم مصادقة SQL Server أو مصادقة Windows، باستخدام بيانات اعتماد Active Directory الخاصة بك أو بيانات اعتماد SQL المحلية.

بمجرد إنشاء الاتصال الخاص بك أو الحصول على حق الوصول إلى اتصال مشترك، يمكنك تنفيذ مجموعة واسعة من الإجراءات على خادم SQL. ما سيجذب انتباه معظم القراء هو "Execute a SQL query (V2".

إذا لم تكن على دراية بالآثار المترتبة على القدرة على تنفيذ استعلامات SQL الأصلية، فإنني أقترح عليك قراءة هذه المدونة من زميلي في الفريق، Sanjiv Kawa، حول أداة SQL Query الخاصة به. من الواضح أنه إذا كان بإمكانك تنفيذ استعلامات SQL Query على خادم، فيمكنك تفريغ جميع البيانات التي لديك صلاحيات للوصول إليها، وقد يكون هذا مقلقًا إذا كانت البيانات الحساسة مخزَّنة في قاعدة البيانات. ومع ذلك، إذا كان لديك امتياز الوصول إلى خادم SQL، فيمكنك تنفيذ التعليمات البرمجية على نظام التشغيل الأساسي. إليك بعض الطرق التي يمكنك من خلالها فعل ذلك:

• إجراء xp_cmdshell المخزَّن
• إجراءات OLE Automation
• تنفيذ تجميعات .NET CLR
• مهام SQL Agent

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

ومع ذلك، كل هذا يصبح بلا معنى في النهاية، إذ إن إجراء "Execute a SQL query (V2)" غير مدعوم للبوابات.

إجراءات أخرى، مثل "Get rows (V2)" التي تستخرج الصفوف من جدول محدد، تعمل بشكل جيد. لا يمكننا ببساطة تنفيذ استعلامات عشوائية على الخادم. أفترض أن السبب في ذلك هو أن Microsoft أخذت احتمال الاستغلال في الاعتبار وقررت أن كشف ثغرات خوادم SQL المحلية لمستخدمي O365 الخارجيين أمر غير آمن.

إذا استعرضت جميع الإجراءات المتاحة لموصِّل SQL، ستلاحظ إجراء "تحويل البيانات باستخدام Power Query". على الرغم من الاسم، فإن Power Query ليس عضوًا في عائلة خدمات Power Platform. بل هو محرك تحويل بيانات يمكنك العثور عليه داخل خدمات/تطبيقات أخرى، مثل Excel. باعتباره محرك تحويل بيانات، تم تصميم Power Query لأخذ البيانات وتحويلها دون تعديل البيانات المصدر.

بعد إنشاء إجراء "تحويل البيانات باستخدام Power Query" باستخدام اتصال صالح، سيُظهر قائمة تعرض جميع الجداول في أي قاعدة بيانات متصل بها. في خادم SQL الخاص بي، هناك جدول فارغ فقط يُسمَّى "الأشخاص".

اختيار "Transform data" سينقلنا إلى الشاشة التالية، وهي محرر Power Query. يستخدم Power Query لغة التنسيقات M، وهي لغة تحويل البيانات التي طورتها Microsoft. توثق مستندات مرجعية لغة M "وظائف الوصول إلى البيانات"، وهي قائمة بالوظائف التي يمكن استخدامها لاستيراد البيانات إلى Power Query. عند فتح محرر Power Query على الاستعلام الافتراضي، نلاحظ أن الدالة "Sql.Databases" تُستخدم لجلب المعلومات من قاعدة البيانات المتصلة.

بعد تصفّح لنسخة PDF من لغة M التي تتكون من 1,394 صفحة، لاحظت أن الدالة "Sql.Database" (لاحِظ الفرق في عدم وجود "S") تحتوي على مَعلمة اختيارية باسم "Query". يتم وصف هذه المعلمة بأنها "استعلام SQL أصلي يُستخدم لاسترداد البيانات".

إذا أدخلت الكود التالي في محرر Power Query، فسيظهر تحذير يفيد بأن "الاستعلامات الأصلية قد تكون غير آمنة وقد تغيّر قاعدة البيانات".

حسنًا، "تغيير قاعدة البيانات" هو اسمي الأوسط، لذا بعد الضغط على "متابعة"، نحصل على نتائج استعلام SQL أصلي.

فقط للتلخيص، إليك كيف يمكن استغلال هذا الأسلوب لاختراق خادم SQL محلي باستخدام صلاحية الوصول إلى رخصة Power Apps فقط:

1. يُنشئ المستخدم تطبيقًا يعتمد على اتصال بخادم SQL داخل الشركة ثم يشاركه مع الجميع، سواءً عن قصد أم عن غير قصد.
2. يُنشئ المهاجم تدفقًا جديدًا ويضيف إجراء "تحويل البيانات باستخدام Power Query" باستخدام اتصال SQL الحالي.
3. إذا كان المستخدم المتصل مسؤول SQL أو لديه امتيازات انتحال الهوية، أو كانت هناك أي روابط SQL مميزة أو بيانات اعتماد نصية واضحة في قواعد البيانات، أو حصلت على بيانات اعتماد نصية واضحة مميزة أخرى، فيمكنك الآن الانتقال إلى خادم SQL محلي.

وفقًا لوثائق Microsoft هذه التي تم تحديثها آخر مرة في عام 2022، إذا شاركت تطبيقًا يستخدم بيانات من بوابة، فستتم مشاركة البوابة أيضًا. من خلال الاختبار في حسابي المستأجر، يبدو أن هذا لم يَعُد هو الحال. ومع ذلك، إذا كانت لديك إمكانية الوصول إلى بوابة، فيمكنك إنشاء اتصالات جديدة من خلالها، ما يعني أنك لم تَعُد مقيدًا بالاتصالات الحالية. هذا يعني أنك بحاجة إلى بيانات اعتماد نصية عادية مخترقة لحسابات AD أو SQL ومعرفة أسماء مضيفي خوادم SQL، على الرغم من أنه ليس من غير المألوف العثور على هذه المعلومات في SharePoint/Confluence.

يمكنك أيضًا الاستفادة من الموصِّلات الأخرى التي تستخدم البوابات، مثل إجراء "File System". ويتطلب هذا منك أيضًا أن تكون لديك بيانات اعتماد وأسماء مضيفين صالحة، ولكنه يعني أنه يمكنك قراءة/كتابة الملفات على المضيفين الداخليين.

إذا كان لديك حق الوصول إلى حساب مع إمكانية الوصول إلى Power Apps، فستحتاج إلى التحقق من جميع البيئات التي يمكنك الوصول إليها. يمكنك رؤية ذلك عن طريق تحديد القائمة المنسدلة "Environment" في الزاوية العلوية اليمنى. في كل بيئة، ستريد تحديد "... More" ثم "Discover All". سينقلك هذا إلى صفحة يمكنك من خلالها التنقل إلى كل شيء في Power Apps.

ومن هناك ، يمكنك تحديد "Connections" لرؤية أي اتصالات لديك وصول إليها، و"Gateways" لرؤية أي بوابات يمكنك الوصول إليها. يمكنك أيضًا معرفة من يملك الاتصالات، حتى تتمكن من التحقق مما إذا كان المستخدم يتمتع بامتيازات أم لا.

بالإضافة إلى ذلك، على الجانب الأيسر من الشاشة توجد أزرار "Flows" و"Apps". ستحتاج إلى فتح قسم "Shared with me" لرؤية كل شيء، ثم البدء بالبحث عن بيانات اعتماد نصيّة أو معلومات حساسة. تُعَد إجراءات تدفق HTTP مناسبة بشكل خاص للعثور على كلمات المرور ومفاتيح واجهة برمجة التطبيقات.

ينبغي على المسؤولين النظر في تحديد المستخدمين الذين يمكنهم تثبيت البوابات أو تعطيلها بالكامل إذا لم يكن هناك سبب عملي لاستخدامها. يمكن القيام بذلك بالدخول إلى منصة إدارة Power Apps، اختيار "Data"، وضع علامة على مربع "Tenant Administration"، ثم اختيار "Manage gateway installers". من هناك، يمكنك تفعيل خيار "Restrict users in your organization from installing gateways" وإضافة المستخدمين الذين يحتاجون فعليًا إلى تثبيت البوابات. راجِع وثائق Microsoft للمزيد من المعلومات.

يُنصح بتقييم الاتصالات في بيئتك بشكل دوري والتأكد من أن المستخدمين لا يشاركون الاتصالات الحساسة على نطاق واسع.

في هذه المدونة، استعرضنا كيف يمكن لمستخدم يمتلك حق الوصول إلى موصِّل خادم SQL عبر بوابة بيانات محلية تنفيذ استعلامات SQL أصلية على الخادم، وربما الانتقال من O365 إلى الموارد المحلية. وقد تم تغيير السلوك الذي جعل هذا خطأ شائعًا في التكوين في عام 2024، ولكن مع الوصول الصحيح، قد يجد المهاجم نفسه في وضع يسمح له باستغلال هذا الأمر. مع صدور هذه المدونة، نأمل أن يراجع المتخصصون في الأمن بيئتهم لتحديد البوابات والموصِّلات المشاركة بشكل مفرط، لمنع الهجمات المستقبلية التي تستهدف Power Apps.

2 أكتوبر 2025: تم تقديم الحالة الأصلية لـ MSRC.

2 نوفمبر 2025: تنص MSRC على أن هذه مسألة تتعلق بالهندسة الاجتماعية، وتغلق الملف.

2 ديسمبر 2025: تم تقديم الحالة الثانية لـ MSRC.

24 ديسمبر 2025: تقييم MSRC للثغرة الأمنية واعتبارها منخفضة الخطورة.