ملخص

  • كشفت Retool أنها أبلغت 27 عميلًا سحابيًا في 29 أغسطس 2023 عن وصول غير مصرح به إلى حساباتهم بعد هجوم هندسة اجتماعية موجه في 27 أغسطس ضد موظف في Retool.
  • من كان له السيطرة الفعلية على التحقق من قناة دعم الموظفين، وتسجيل MFA وعناصر التحكم في الاسترداد، والاعتماد على حساب Google، وعزل بيئة العميل، والكشف، والإفصاح، وإثبات أن سير عمل الدعم لا يمكنه تجاوز ضمانات الهوية؟
  • قضية المساءلة هي أن منصات أتمتة المؤسسات يمكنها أن ترث مخاطر الهندسة الاجتماعية من قنوات دعم الموظفين عندما تسمح مسارات الدعم أو الاسترداد بتجاوز افتراضات المصادقة القوية عمليًا.
  • عملاء Retool والمستخدمون الداخليون وفرق الدعم وموفرو الهوية وسير عمل العملات المشفرة والتكنولوجيا المالية والمدققون وفرق أمان المؤسسات بحاجة إلى دليل على أن ثقة قناة الدعم قد تم تقليصها إلى عملية استثناء خاضعة للرقابة.
  • تتعامل هذه المقالة مع تقرير ما بعد الحادث من Retool باعتباره السجل العام الأساسي. يتم استخدام وثائق Retool ووثائق Google وFIDO وCISA وNIST وOkta وسجلات مختارة من النظام البيئي لتقييم أنماط التحكم وحدود الأدلة.

لماذا تنتمي هذه القضية إلى ملف المخاطر والمساءلة

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

السجل الأساسي هو مشاركة مدونة Retool في 13 سبتمبر 2023، "عندما لا يكون MFA هو MFA فعليًا"، علىhttps://retool.com/blog/mfa-isnt-mfa. قالت Retool إنها أبلغت 27 عميلًا سحابيًا في 29 أغسطس بأنه كان هناك وصول غير مصرح به إلى حساباتهم. وقالت إنه لم يكن هناك وصول إلى الحسابات المحلية أو المدارة. ووصفت هجوم تصيد احتيالي موجه في 27 أغسطس تلقى فيه الموظفون رسائل نصية مستهدفة حول مشكلة حساب مرتبطة بالتسجيل المفتوح والهجرة الأخيرة إلى Okta. قام أحد الموظفين بتسجيل الدخول إلى بوابة مزيفة تضمنت نموذج MFA. قالت Retool إن المهاجم اتصل بعد ذلك بالموظف، وادعى أنه عضو في فريق تكنولوجيا المعلومات، واستخدم صوتًا مألوفًا مزيفًا عميقًا وسياقًا داخليًا، وحصل على رمز MFA إضافي واحد.

ثم انتقل الحادث من هوية الموظف إلى تأثير العميل. قالت Retool إن الوصول إلى حساب Google الخاص بالموظف أعطى المهاجم إمكانية الوصول إلى رموز MFA المخزنة في Google Authenticator من خلال المزامنة السحابية. بهذه الرموز وجلسة Okta، تمكن المهاجم من الوصول إلى VPN الخاص بـ Retool وأنظمة الإدارة الداخلية. قالت Retool إن ذلك سمح للمهاجم بتنفيذ هجوم استيلاء على الحساب لمجموعة محددة من العملاء في صناعة العملات المشفرة عن طريق تغيير عناوين البريد الإلكتروني للمستخدمين وإعادة تعيين كلمات المرور.

قالت Retool إنها ألغت جلسات المصادقة الداخلية، وأغلقت الحسابات المتأثرة، وأبلغت العملاء المتأثرين، واستعادت الحسابات إلى حالتها الأصلية، وتراجعت عن عمليات الاستيلاء على الحسابات البالغ عددها 27.

هذه الحقائق تجعل الحادث أكثر من مجرد قصة تصيد. عبر المسار الرسائل النصية القصيرة، وهجرة الهوية، وثقة أسلوب مكتب المساعدة، والهندسة الاجتماعية الصوتية، وحضانة رمز المصادقة، والوصول إلى VPN، ومثال دعم داخلي لـ Retool، وإدارة العملاء السحابية، واسترداد حساب العميل. كان لكل رابط مالك مختلف. تحكم المهاجم في الخداع. تحكمت Retool في عمليات دعم الموظفين، وتصميم الوصول الداخلي، والأدوات الإدارية، والاستجابة للحوادث، وإخطار العملاء. تحكمت Google في تصميم مزامنة Authenticator وأمان حساب Google. قدمت Okta البنية التحتية للهوية.

تحكم العملاء في تصميم تطبيق Retool الخاص بهم، وأذونات المستخدم، وضمانات المعاملات النهائية، والاختيار بين النشر السحابي والمدار والمستضاف ذاتيًا.

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

استغل الهجوم ثقة قناة الدعم، وليس فقط مطالبات المصادقة

تقرير ما بعد الحادث من Retool مفيد لأنه يصف تسلسل الهندسة الاجتماعية بدلاً من نقرة واحدة. تم توقيت الرسالة النصية حول مزايا الموظفين وهجرة Okta. تم إخفاء عنوان URL المزيف كبوابة هوية داخلية. جمعت البوابة المزيفة بيانات تسجيل الدخول و MFA. ثم اتصل المهاجم بالموظف واستخدم السياق التنظيمي. قالت Retool إن الموظف أصبح مشبوهًا أثناء المحادثة لكنه لا يزال يقدم رمز MFA إضافيًا واحدًا. هذا هو الدرس الحقيقي لقناة الدعم: يمكن أن تنجح الهجمات من خلال الجمع بين الشرعية الجزئية والتوقيت والإلحاح والمفردات الداخلية والألفة الصوتية وطلب يبدو كخطوة دعم أو استرداد.

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

وصف تقرير Retool ما بعد الحادث مثال الدعم الداخلي لـ Retool كالطريق الذي تم من خلاله تنفيذ عمليات الاستيلاء على حسابات العملاء. تضمنت المصادقة على هذا المثال الداخلي VPN و SSO ونظام MFA نهائيًا. قالت Retool إن جلسة Google Workspace الصالحة وحدها لم تكن كافية. هذه التفاصيل مهمة لأنها تظهر أن Retool كان لديها طبقات متعددة. لم يكن الفشل غياب MFA؛ كان انهيار الانفصال عندما سمح التحكم في حساب واحد وأسرار المصادقة المتزامنة للمهاجم بتجاوز الطبقات الإضافية.

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

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

غيرت الرموز لمرة واحدة المتزامنة سحابيًا نموذج تهديد MFA

الاستنتاج الأكثر إثارة للجدل في Retool تضمن مزامنة Google Authenticator. أعلنت Google في 24 أبريل 2023 أن Google Authenticator سيدعم مزامنة حساب Google للرموز لمرة واحدة علىhttps://security.googleblog.com/2023/04/google-authenticator-now-supports.html. تشرح صفحة دعم Google علىhttps://support.google.com/accounts/answer/1066447أن المستخدمين يمكنهم مزامنة رموز التحقق عبر الأجهزة عن طريق تسجيل الدخول إلى حساب Google. تعالج الميزة مشكلة قابلية استخدام حقيقية: يفقد المستخدمون هواتفهم ويغيرون الأجهزة ويتم إغلاقهم عندما تكون بذور الرمز لمرة واحدة محلية فقط. الراحة واضحة.

جادل تقرير Retool ما بعد الحادث بأن هذه الراحة خلقت مسار هجوم جديد في بيئته. قالت Retool إن الوصول إلى حساب Google الخاص بالموظف أعطى إمكانية الوصول إلى جميع رموز MFA المحفوظة داخل هذا الحساب، وكان هذا هو السبب الرئيسي الذي جعل المهاجم يتمكن من دخول الأنظمة الداخلية. وصفت Retool التغيير بأنه جعل ما كان مصادقة متعددة العوامل يصبح بصمت مصادقة أحادية العامل للمسؤولين، لأن التحكم في حساب Okta أدى إلى التحكم في حساب Google، مما أدى إلى التحكم في OTPs المتزامنة. هذا هو ادعاء Retool حول بيئته، ومن المناسب التعامل معه كتفسير الحادث من الشركة وليس كنتيجة تنظيمية ضد Google.

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

صحيفة حقائق CISA حول MFA المقاوم للتصيد علىhttps://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf، و NIST SP 800-63B علىhttps://pages.nist.gov/800-63-4/sp800-63b.html، ومواد FIDO Alliance علىhttps://fidoalliance.org/fido2/وhttps://fidoalliance.org/passkeys/تدعم جميعها التمييز بين العوامل القائمة على الرمز وطرق المفتاح العام المقاومة للتصيد. أوصت Retool نفسها بمفاتيح الأمان الأجهزة باستخدام FIDO2 في تقريرها ما بعد الحادث. الدرس ليس أن كل مؤسسة يجب أن ترفض كل منتج مصادق متزامن. إنه أن المسؤولين يجب أن يفهموا أين يتم تخزين بذور المصادق، ومن يمكنه مزامنتها، وما إذا كانت سياسة المؤسسة يمكنها تعطيل المزامنة، وما إذا كانت الأنظمة الإدارية عالية المخاطر تعتمد على رموز قابلة للتصيد أو الترحيل.

توجيه عملاء Okta الخاص مناسب لأن الهجوم حدث أثناء هجرة تسجيل الدخول إلى Okta. توفر وثائق Okta حول المصادقات وسياسة المصادقة علىhttps://help.okta.com/oie/en-us/content/topics/identity-engine/authenticators/about-authenticators.htmوhttps://help.okta.com/oie/en-us/content/topics/identity-engine/policies/about-authentication-policies.htmأدوات للمؤسسات لطلب عوامل أقوى للتطبيقات الحساسة. هذه المستندات ليست نتائج حوادث. إنها دليل على أن المؤسسات لديها خيارات تكوين. يجب أن تكون لوحة إدارة الدعم و VPN ونظام إدارة حسابات العملاء من بين التطبيقات الأولى التي تتطلب مصادقة مقاومة للتصيد أو مرتبطة بالجهاز أو عالية الضمان بطريقة أخرى.

يمكن للأدوات الإدارية الداخلية أن تصبح مستويات تحكم مواجهة للعميل

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

تصف صفحة ممارسات أمان Retool علىhttps://docs.retool.com/legal/securityمسؤوليات الأمان للمستضاف والمستضاف ذاتيًا على مستوى عالٍ. دليل سجل التدقيق لـ Retool علىhttps://docs.retool.com/org-users/guides/monitoring/audit-logsومرجع الأحداث المسجلة علىhttps://docs.retool.com/org-users/reference/logged-eventsيظهران أن قابلية التدقيق جزء من توقع المنتج. إرشادات أمان Retool جيدة الهندسة علىhttps://docs.retool.com/education/coe/well-architected/securityتؤكد على الأذونات والموارد والأسرار والتشفير والمراقبة. هذه المستندات ذات صلة لأنها تظهر أن نفس المبادئ التي يحتاجها العملاء لتطبيقاتهم الخاصة تنطبق أيضًا على تطبيقات الدعم الداخلي لـ Retool.

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

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

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

يحتاج العملاء أيضًا إلى ضوابطهم الخاصة. تشير وثائق Retool حول توفير SCIM علىhttps://docs.retool.com/sso/guides/scim-user-provisioning، وسجلات التدقيق، وتعزيز الأمان للنشر المستضاف ذاتيًا علىhttps://docs.retool.com/self-hosted/self-managed/concepts/best-practices/security-hardeningنحو حوكمة جانب العميل: إدارة المستخدمين مركزيًا، وإلغاء وصول المستخدمين المغادرين، ومراقبة الأحداث الحساسة، وتعزيز إعدادات النشر، وتجنب إعطاء أي حساب Retool واحد قوة تشغيلية لا رجعة فيها دون ضوابط تعويضية. يجب أن يتسبب حادث المنصة في قيام العملاء بمراجعة مستخدمي Retool الذين يمكنهم تشغيل استعلامات عالية المخاطر، أو تغيير السجلات، أو الموافقة على السحوبات، أو تشغيل إجراءات خارجية.

الحدود بين السحابي والمدار والمستضاف ذاتيًا كانت مهمة

الحدود العامة لـ Retool بين الحسابات السحابية والمدارة والمحلية مهمة. قالت Retool إن الحادث أثر على مجموعة فرعية صغيرة من العملاء السحابيين وأنه لم يتم الوصول إلى أي حسابات محلية أو مدارة. وقالت أيضًا إن Retool المحلي يعمل في بيئة ثقة صفرية، ولا يثق في سحابة Retool، وهو مكتفٍ ذاتيًا تمامًا، ولا يحمل أي شيء من البيئة السحابية. توثق وثائق الاستضافة الذاتية لـ Retool علىhttps://docs.retool.com/self-hostedخيارات الاستضافة الذاتية والمدارة من Retool، بما في ذلك النشر حيث يحتفظ العملاء بالملكية والتحكم في البيانات ومفاتيح التشفير والوصول في بنيتهم التحتية الخاصة.

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

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

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

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

يعتمد ضرر العميل على سير العمل المبني فوق المنصة

قال تقرير Retool ما بعد الحادث إن المهاجم نفذ عمليات استيلاء على الحسابات ضد عملاء في صناعة العملات المشفرة، وغير عناوين البريد الإلكتروني، وأعاد تعيين كلمات المرور، وتجول في بعض تطبيقات Retool. ولم يذكر أسماء العملاء المتأثرين في المنشور. تقارير طرف ثالث، بما في ذلك CoinDesk علىhttps://www.coindesk.com/business/2023/09/13/phishing-attack-on-cloud-provider-with-fortune-203750644.htmlواستجابة Fireblocks علىhttps://www.fireblocks.com/blog/in-response-to-the-fortress-trust-hack-dated-september-12-2023، ربطت الحلقة الأوسع بـ Fortress Trust ومزاعم خسائر العملات المشفرة. هذه السجلات مفيدة كسياق، لكن المقالة لا ينبغي أن تتعامل مع كل ادعاء طرف ثالث كحقيقة مؤكدة من Retool. الحقائق المؤكدة من Retool نفسها هي عمليات الاستيلاء على 27 حسابًا سحابيًا للعملاء والحدود السحابية فقط.

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

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

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

خطوة استعادة الحساب في الحادث مهمة أيضًا. قالت Retool إنها استعادت الحسابات المتأثرة إلى عناوين البريد الإلكتروني الأصلية وتراجعت عن عمليات الاستيلاء البالغ عددها 27. الاستعادة تغلق طبقة واحدة من الحادث. لا تثبت بالضرورة أن كل إجراء من جانب العميل تمت محاولته خلال الفترة كان غير ضار. هذا الإثبات يعتمد على سجلات تدقيق العميل وتصميم التطبيق وأذونات الموارد وأدلة النظام النهائي. أقر تقرير Retool ما بعد الحادث بأن العملاء الذين لديهم تطبيقات آمنة كانوا فعالين في صد الهجوم، مما يعني أن ضمانات مستوى التطبيق كانت جوهرية.

يجب تصميم ضوابط التدخل البشري ضد الهندسة الاجتماعية

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

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

يمكن لموفري الهوية المساعدة بالسياسة، لكنهم لا يستطيعون استبدال تصميم سير العمل بالكامل. يمكن لموفري مثل Okta و Google فرض مصادقة أقوى وثقة الجهاز وسياسات الجلسة وسجلات. تظهر سجلات تدقيق Google Cloud علىhttps://cloud.google.com/logging/docs/auditالقيمة العامة لسجلات النشاط الإداري في البيئات السحابية. لكن إذا سُمح لعملية الدعم بالتوجيه حول الهوية عن طريق تغيير سجلات المستخدم، فقد يرى موفر الهوية فقط تسجيل الدخول النهائي. يحتاج الموفر والعميل إلى سجلات عملية الأعمال أيضًا.

إرشادات CISA للتصميم الآمن علىhttps://www.cisa.gov/securebydesignومبادئ الأمان الافتراضي ذات صلة هنا لأن المنتج الأكثر أمانًا يجب أن يجعل إجراءات الدعم الخطرة أكثر صعوبة افتراضيًا. يوفر إطار عمل NIST للأمن السيبراني علىhttps://www.nist.gov/cyberframeworkبنية التحديد والحماية والكشف والاستجابة والاستعادة: تحديد إجراءات الدعم عالية المخاطر، وحمايتها بموافقة ومصادقة قويين، واكتشاف أنماط الاستيلاء غير العادية، والاستجابة عن طريق قفل الحسابات وإلغاء الجلسات، والاستعادة عن طريق استعادة الحسابات والتحقق من النشاط النهائي. هذه ليست تسميات امتثال مجردة؛ إنها تتطابق مباشرة مع مسار حادث Retool.

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

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

يجب أن يطلب الشراء والاستجابة للحوادث دليل سير العمل

يغير حادث Retool أيضًا ما يجب أن يسأله شراء المؤسسات من بائعي الأدوات الداخلية وأتمتة. قد يسأل استبيان أمان عام ما إذا كان البائع يدعم SAML و MFA و SCIM وسجلات التدقيق والتشفير. هذه الأسئلة مفيدة، لكنها لا تصل إلى مشكلة سير عمل الدعم. السؤال الأكثر أهمية هو ما إذا كان موظفو البائع يمكنهم تنفيذ إجراءات حسابية تؤثر على العميل، وتحت أي ظروف، وبأي موافقات، ومع أي سجلات مرئية للعميل. يمكن لمنصة أن يكون لديها SAML و MFA لمستخدمي العملاء بينما لا تزال تعرض العملاء لإجراءات دعم جانب البائع التي تغير التحكم في الحساب.

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

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

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

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

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

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

حدود الأدلة والمجهولات

تدعم الأدلة العامة عدة استنتاجات واضحة. كشفت Retool عن حادث تصيد وهندسة اجتماعية في 27 أغسطس 2023. قالت إن 27 عميلًا سحابيًا تم إخطارهم في 29 أغسطس بوصول غير مصرح به إلى الحسابات. قالت إن الحسابات المحلية والمدارة لم يتم الوصول إليها. قالت إن المهاجم استخدم إغراء رسالة نصية قصيرة وبوابة هوية مزيفة ومكالمة هاتفية وصوتًا مألوفًا مزيفًا عميقًا ورمز MFA إضافيًا واحدًا. قالت إن الوصول إلى حساب Google الخاص بالموظف كشف رموز المصادقة المتزامنة، مما مكّن من الوصول إلى VPN والإدارة الداخلية. قالت إن المهاجم غير عناوين البريد الإلكتروني وأعاد تعيين كلمات المرور وتجول في بعض تطبيقات Retool.

قالت إن Retool ألغت الجلسات وأغلقت الحسابات وأبلغت العملاء واستعادت الحسابات وعملت مع إنفاذ القانون وشركة طب شرعي طرف ثالث.

لا تدعم الأدلة العامة ادعاءات أوسع دون تحفظ. لا تحدد كل عميل متأثر في منشور Retool نفسه. لا تثبت أن جميع عملاء Retool السحابيين تأثروا. لا تظهر أن الحسابات المحلية أو المدارة تم الوصول إليها. لا تقدم تقرير الطب الشرعي الكامل. لا تثبت كل إجراء أو خسارة نهائية للعميل. لا تثبت نتيجة تنظيمية ضد Google أو Okta أو Retool. لا تظهر كل تغيير تحكم داخلي نفذته Retool بعد الحادث. يجب تسمية هذه المجهولات بدلاً من ملئها بالتخمين.

هناك فجوات أدلة مهمة للمشترين من المؤسسات. هل أزالت Retool OTP القائم على الرمز من جميع الأنظمة الداخلية المميزة؟ ما هي إجراءات الدعم التي تتطلب الآن خطوة مدعومة بالأجهزة أو موافقة مزدوجة؟ هل يمكن لعملاء المؤسسات فرض سياسات موافقة دعم مخصصة؟ ما هي أحداث سجل التدقيق التي تظهر إجراءات دعم Retool في بيئات العملاء؟ كيف يتم منع مهندسي الدعم من تغيير حقول البريد الإلكتروني أو كلمة المرور للعملاء عالي المخاطر دون تأكيد ممسوك من قبل العميل؟ كيف يتم تشغيل إخطارات العميل للتغييرات الإدارية؟ كيف تتحقق Retool من أن بذور المصادقة المتزامنة سحابيًا لا تستخدم للوصول الداخلي المميز؟ تجيب الوثائق العامة على جزء فقط من هذا.

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

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

لماذا لا يزال هذا مهمًا في 2026

يبقى حادث Retool مهمًا في 2026 لأن منصات أتمتة المؤسسات أصبحت أكثر مركزية للعمليات. تسمح منصات low-code والأدوات الداخلية للفرق بالبناء بشكل أسرع، وربط المزيد من الأنظمة، ونقل سير عمل الأعمال من جداول البيانات والبرامج النصية المخصصة. هذا قيم. يعني أيضًا أن إدارة الحساب وأدوات الدعم واسترداد الهوية يمكن أن تصبح مستويات تحكم لسير عمل المالية والعملات المشفرة والرعاية الصحية والخدمات اللوجستية والدعم والامتثال. يمكن أن يصبح اختراق قناة الدعم اختراقًا لعملية الأعمال.

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

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

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

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

نتيجة المساءلة النهائية قائمة على الأدلة ومحدودة. أكدت Retool علنًا أن هجوم الهندسة الاجتماعية ساهم في الوصول غير المصرح به الذي أثر على 27 حساب سحابي للعملاء وأن الحسابات المحلية والمدارة لم يتم الوصول إليها. لا تبرر الأدلة العامة الادعاء باختراق كل عميل أو كل نشر لـ Retool. تبرر الأدلة العامة التعامل مع الحادث كاختبار لسير عمل الدعم ومساءلة MFA. تظهر القضية أن ثقة أتمتة المؤسسات لا تعتمد فقط على ميزات التطبيق، ولكن أيضًا على عمليات الدعم والهوية التي يمكنها تغيير من يتحكم في تلك التطبيقات.

سجل المصادر