تحديث 1-22-2020

يوجد الآن أداة من FireEye ستساعد في فحص هذه العناصر أدناه. المفتاح هنا هو أنك تحتاج إلى سجلات كافية تعود إلى 1-9-2020 لتتمكن من رؤية ما تم القيام به بعد تشغيل الاستغلال. إذا وجدت ملفات حمولة .XML فأنت بحاجة إلى استخدام المعلومات أدناه لاتخاذ قرار بشأن الإجراء الذي يجب اتخاذه. https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html

تنزيل الأداة

https://github.com/citrix/ioc-scanner-CVE-2019-19781 https://github.com/fireeye/ioc-scanner-CVE-2019-19781/

اكتشاف الاستغلال

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

إذا كنت تشغل Nessus، فيمكنك استخدام ملف .YAR أدناه لإجراء فحص مميز للبحث عن طرق الكشف الشائعة. https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

تدقيق الاستغلال

روابط رائعة حول عملية التدقيق هذه. https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

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

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

قائمة الفحص السريع للاستغلال v1

• 1. تحقق من ترخيصك، لقد سمعت عن البعض الذين أعادوا تشغيل أجهزتهم وكان لديهم بالفعل ترخيص منتهي.
• 2. احصل على ملف الدعم المعروف أيضاً باسم النسخ الاحتياطي: النظام -> التشخيص -> الحصول على ملف الدعم واحفظ هذا الملف.
• 3. جميع الأوامر أدناه في NSCLI وإذا اتصلت عبر SSH بالجهاز واستخدمت Shell فيمكنك إسقاط بادئة Shell.
• 4. تحقق من التاريخ على الجهاز للمساعدة في ربط نتائج السجلات
  • a. shell date
• 5. تحقق من تاريخ تغيير التكوين الخاص بك
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. ما هو تاريخ ملف netscaler.conf الخاص بك؟
    • ii. هل يبدو ذلك صحيحاً؟ ابحث عن روابط ملفات إلى أماكن أخرى.
• 6. تحقق من ملف كلمات مرور الحسابات المحلية
  • a. Shell ls -lh /etc/passwd
    • i. تحقق لمعرفة متى تم تعديل الملف. إذا كان ذلك بعد الاستغلال ولم تكن أنت، فأنت بحاجة إلى تغيير كلمة المرور هذه في أقرب وقت ممكن.
    • ii. أوصي بتغيير كلمة مرور nsroot أو أي حسابات محلية إذا تم اكتشاف أي استغلالات. في كثير من الحالات
  • b. Shell cat /etc/passwd
    • i. انظر لترى الحسابات الموجودة هناك.
    • ii. Root وnsroot وdaemon وoperator وbin وnobody وsshd وnsmonitor هي الافتراضية.
• 7. تحقق من سجلاتك
  • a. shell ls -lh /var/logfile
    • i. هل الملفات موجودة هناك؟ هل هي صغيرة جداً؟
    • ii. https://support.citrix.com/article/CTX121898
• 8. فحص الملفات الخبيثة
  • a. إذا كان أي من هذه الملفات أكثر أو أقل من 8-9 أحرف واسم ملف عشوائي، فهذه علامة على مهاجم أكثر تقدماً غيّر الاستغلال القياسي. إذا رأيت هذا، فأنت بحاجة إلى تعديل إجراءات المعالجة وفقاً لذلك. Pwnpzi1337.xml هو اسم ملف استغلال Project India
  • b. shell ls /netscaler/portal/templates/*.xml
    • i. يجب ألا تكون هناك ملفات XML هنا.
    • ii. إذا كان مصاباً فانظر إلى تواريخ الملفات هنا.
    • iii.shell ls -lh /netscaler/portal/templates/
  • c. shell ls /var/tmp/netscaler/portal/templates
    • i. يجب ألا يكون هذا الدليل موجوداً.
    • ii. إذا كان مصاباً فانظر إلى تواريخ الملفات هنا.
    • iii.shell ls -lh /var/tmp/netscaler/portal/templates

إذا تم الاستغلال

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

ما هي الهيئات التنظيمية التي تغطي أعمالك؟ التمويل\الخدمات المصرفية، SOX، PCI، HIPPA، قوانين الولاية\المحلية والحكومية.

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

فيما يلي روابط لهذين الدليلين المعروفين لعمليات الاستجابة للحوادث https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

أحد الأشياء التي نعرفها حتى الآن هو أنه في حوالي 10-1-20 تم إصدار أول استغلال عام وهناك بعض التقارير عن إصابات في التاسع لأن ذلك كان عندما ظهر بالضبط. في معظم الحالات، يكون الخطر أقل بكثير إذا قمت بتحديث نظامك قبل 2020 مقارنة بما بعده في هذا الشهر.

منحنى تصاعد خطر التهديد التقديري لـ CVE-2019-19781

17 ديسمبر - 31 ديسمبر: أدنى خطر للاستغلال 1-8 يناير: خطر أقل للاستغلال 9-13 يناير – خطر أعلى للاستغلال 14 يناير - حتى الآن – أعلى خطر للاستغلال

يجب أن يدخل هذا في عمليتك لخطواتك التالية.

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

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

ستتغير نصيحتي التالية خلال الأسبوعين المقبلين.

نماذج مسارات الاستجابة للحوادث

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

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

تعريف الاستجابات والأفكار

• بناء جديد وترحيل – ابدأ عملية الاستجابة للحوادث ثم يمكنك بدء هذه العملية https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html. هذا سهل نسبياً لعملاء VPX وSDX بسبب الطبيعة الافتراضية ومرونة منصة التكوين. ترحيلات MPX قصة مختلفة بسبب كيفية عمل إعادة ضبط المصنع وكيفية الحفاظ على الصورة الأساسية، وقد يكون هناك خطر منخفض جداً إذا كان المهاجم متقدماً للاستمرار عبر ترقية البرنامج الثابت أو إعادة ضبط المصنع. الاحتمالية قد تكون أقل، لكنها لا تزال ممكنة (مثل أي شيء في عالم الإنترنت).
• إعادة ضبط المصنع – ابدأ عملية الاستجابة للحوادث وقم بإزالة ملفات .xml وأي شيء آخر تم اكتشافه وأعد التشغيل وتحقق من الاستمرارية مرة أخرى. ثم ابدأ عملية إعادة ضبط المصنع. هناك برامج نصية يمكن الحصول عليها من Citrix ستقوم بهذه العملية. سيؤدي هذا إلى مسح النظام إلى أدنى مستوى قبل إعادة تحميل نظام التشغيل، ولكن الجميع سيثق بهذه الطريقة حتى الآن بناءً على مشهد التهديدات لديهم وقد يريدون المزيد.
  • الطريقة الأكثر جذرية هي إرجاع الأجهزة (RMA) لإعادة تحميل الأقراص، وقد تكون هذه فكرة جيدة أو سيئة بناءً على دورة حياتك ومنصتك وخطة التكرار لديك أيضاً. سأقترح هذا فقط إذا رأيت تقنيات متقدمة مستخدمة وأكدت حركة جانبية بناءً على تقنياتهم لربما السير في هذا المسار. أعلم أن Citrix تعمل على خيارات "ماذا لو" و
• المعالجة – ابدأ عملية الاستجابة للحوادث وقم بإزالة ملفات .xml وأي شيء آخر تم اكتشافه وأعد التشغيل وتحقق من الاستمرارية مرة أخرى. إذا كان لديك سجلات جيدة فستعرف ما إذا تم فعل أي شيء، وإذا لم يكن الأمر كذلك، فسأنظر إلى مشهد التهديدات لديك وما إذا كان لديك تسجيل على أهداف الطبقة الأولى أو أي شيء آخر لمعرفة ما إذا كنت بحاجة إلى اعتبار الأمر بحاجة إلى إعادة ضبط المصنع و/أو ما إذا كنت بحاجة إلى بناء جديد وترحيل.

مستويات التسجيل

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

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

خطوات متابعة جيدة أخرى

هناك شيئان رئيسيان تحتاج إلى اتخاذ قرار بشأنهما إذا كانت هناك أي آثار للاستغلال.

• 1. تغيير كلمة مرور NSROOT
  • a. أوصي بالقيام بذلك بغض النظر عما تجده أو ما هي السجلات لديك. هذه فرصة لإدخال nsroot في دورة تغيير كلمات المرور. يجب ربط إدارة ADC بـ LDAP ويجب استخدام NSROOT فقط في حالات الطوارئ.
• 2. تغيير حساب خدمة LDAP (أو خدمة مصادقة أخرى)
  • a. غيّر كلمة المرور هذه، كما أوصي بالتغيير إلى حساب آخر إن أمكن بحيث يكون لديك SID مختلف أيضاً. يمكن أن يكون هذا تغييراً سلبياً دون أن يلاحظه أحد إذا تم اختباره قبل التنفيذ.
• 3. تغيير مفاتيح SSL
  • a. تسجيل جيد
    • i. ربما تكون بخير إذا كنت متأكداً 100% أنه جيد.
    • ii. لا يزال هناك جزء مني يريد أن يقول أعد توليد مفاتيح كل الأشياء، لكنني أعرف مقدار العمل الذي يمكن أن يكون في بيئة كبيرة.
  • b. لا يوجد تسجيل
    • i. أعتقد أنه يتعين عليك إعادة توليد مفاتيح كل شيء هناك. هناك حماية PEM وPFX، لكنني رأيت الكثير من الأماكن التي تستخدم كلمات مرور بسيطة جداً لتلك ويمكن اختراقها بالقوة الغاشمة دون اتصال. وبما أننا لا نعرف، نحتاج إلى حماية الشركة.

أفكار حول كلمات المرور

أوصي بتغيير كلمات المرور لجميع حساباتك المحلية على الجهاز إذا كان هناك أي مؤشر على استغلال ناجح. امضِ قدماً وقم بتغييرها لأنه في العديد من عمليات النشر ربما لم يتم تغييرها منذ نشرها الأصلي قبل 4-7 سنوات. إذا رأيت علامات وصول سطر الأوامر و/أو العبث، فمن المحتمل جداً أن المهاجم قادر على كسر كلمة المرور: في البرامج الثابتة قبل الإصدار 11.0 كانت AES256 وفي الإصدارات الأحدث تستخدم AES512 والتي يمكن أن تكون عرضة للكسر أيضاً. تأكد من ربطه بـ LDAP بشكل آمن أيضاً وأن لديك تنبيهات مضبوطة لتسجيلات دخول NSROOT.

أفكار حول LDAP

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

أفكار حول الشهادات

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

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

• فريق Citrix – العمل على نشر المعلومات بالإضافة إلى العمل على هذه البرامج الثابتة الجديدة. يضطرون إلى العمل على 5 تصحيحات في وقت واحد بسبب الاختلافات بين عائلات الأكواد مما يجعل الأمر أكثر صعوبة.
• Daniel Weppeler @_DanielWe – تسجيل سياسة Responder لكشف الاستطلاعات\الهجمات
• Florian Roth @cyb3rops – ملف Nessus YAR لكشف الاستغلال
• CTP Anton van Pelt @AntonvanPelt و CTA Mads Petersen @mbp_netscaler و Jan Tytgat @jantytgat – عمل مستمر مع فرق CTP\CTA وسيتريكس للعمل على عدة جبهات.
• KevTheHermit @KevTheHermit – الكشف عن ثغرة كلمة مرور مثيل AWS بالإضافة إلى CVE
• تقرير Bad Packets @bad_packets – فريق Bad Packets بأكمله https://badpackets.net
• Kevin Beaumont @GossiTheDog – قدر كبير من الترويج للمشاكل التي شوهدت مع بعض التفاصيل حول honeypot الخاص به وما رآه.
• Mpgn @mpgn_x64 – تفاصيل حول الاستغلال والاختلافات في الاستغلالات
• Nick Carr @ItsReallyNick – تفاصيل حول الاستغلال ونصائح الاستجابة للحوادث.
• Digi Cat u/digicat – مستخدم ريديت، مدونة أخبار جارية مذهلة.
• Ben Sadeghipour @NahamSec – فيديو DFIR على يوتيوب ومساهمات أخرى
• فريق SANs – مقالات وفيديوهات DFIR والغوص العميق
• Craig Dods @0xCraig – الآثار المترتبة على كلمات المرور والأبحاث
• Manuel Kolloff @manuelkolloff – شروحات خطوة بخطوة لمرحلة ما بعد الاستغلال.
• فريق FireEye وMandient – شكرًا لريك كول على إنشاء أول تغطية كشف لدينا، وفريق مستجيبو حوادث Mandiant على مساهماتهم في هذه المدونة—خاصة أوستن بيكر وبراندان شوندورفر وجون برييتو—ولجميع المستشارين الذين يستجيبون لبيئات عملائهم أو يؤمّنونها ضد هذه الثغرة. كما نشكر نيكولاس لودتكي من فريق استخبارات الثغرات لدينا على مساعدته في تحسين الجدول الزمني للإفصاح والأدوات في هذه المدونة.