الزملاء الذين يستخدمون إصدارات Exim 4.87 ... 4.91 على خوادم البريد الخاصة بهم - التحديث إلى الإصدار 4.92 بشكل عاجل ، بعد إيقاف Exim نفسه لتجنب القرصنة عبر CVE-2019-10149.
من المحتمل أن تكون عدة ملايين من الخوادم حول العالم عرضة للخطر ، وتم تصنيف الثغرة الأمنية على أنها حرجة (الدرجة الأساسية لـ CVSS 3.0 = 9.8 / 10). يمكن للمهاجمين تشغيل أوامر عشوائية على الخادم الخاص بك ، في كثير من الحالات كجذر.
يرجى التأكد من أنك تستخدم الإصدار المصحح (4.92) أو الإصدار المصحح.
أو تصحيح القائمة الموجودة ، انظر الموضوع .
تحديث ل CentOS 6: سم. - بالنسبة لـ centos 7 ، فإنها تعمل أيضًا إذا لم يتم نقلها مباشرة من epel.
محدث: تأثر أوبونتو 18.04 و18.10، تم إصدار تحديث لهم. لا يتأثر الإصداران 16.04 و 19.04 ، ما لم يتم تثبيت إصدارات مخصصة عليهما. أكثر .
الآن يتم استغلال المشكلة الموصوفة هناك بنشاط (من قبل الروبوت ، على الأرجح) ، لاحظت وجود إصابة في بعض الخوادم (تعمل على 4.91).
القراءة الإضافية مناسبة فقط لأولئك الذين "ضربوا" بالفعل - تحتاج إما إلى نقل كل شيء إلى خادم VPS نظيف مع برنامج جديد ، أو البحث عن حل. سنحاول؟ اكتب ما إذا كان شخص ما يمكنه التغلب على هذه البرامج الضارة.
إذا كنت ، بصفتك أحد مستخدمي Exim وتقرأ هذا ، ما زلت غير محدث (غير مقتنع بتوفر 4.92 أو إصدار مصحح) ، يرجى التوقف والتشغيل للترقية.
بالنسبة لأولئك الموجودين هناك بالفعل ، فلنواصل ...
UPD: ويعطي النصيحة الصحيحة:
يمكن أن تكون البرامج الضارة متنوعة بشكل كبير. من خلال إطلاق الدواء للشيء الخطأ وتنظيف قائمة الانتظار ، لن يتم علاج المستخدم وقد لا يعرف ما يحتاج إلى العلاج منه.
العدوى ملحوظة مثل هذا: [kthrotlds] يحمّل المعالج ؛ على VDS ضعيف بنسبة 100٪ ، على الخوادم أضعف ولكن ملحوظة.
بعد الإصابة ، يحذف البرنامج الضار المدخلات في cron ، ويصف نفسه فقط كل 4 دقائق ، بينما يجعل ملف crontab غير قابل للتغيير. كرونتاب -e لا يمكن حفظ التغييرات ، يرمي خطأ.
يمكن إزالة غير قابل للتغيير على سبيل المثال مثل هذا ، ثم حذف سطر الأوامر (1.5 كيلو بايت):
chattr -i /var/spool/cron/root
crontab -e
بعد ذلك ، في محرر crontab (vim) ، احذف السطر واحفظ:dd
:wq
ومع ذلك ، فإن إحدى العمليات النشطة يتم استبدالها مرة أخرى ، كما أفهم.
في الوقت نفسه ، هناك مجموعة من الأدوات النشطة (أو الضفائر) معلقة على العناوين من البرنامج النصي للمثبت (انظر أدناه) ، ما زلت أطرحها هكذا ، لكنها تبدأ مرة أخرى:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
لقد عثرت على نص مثبت حصان طروادة هنا (centos): / usr / local / bin / nptd ... لا أنشره لتجنبه ، ولكن إذا أصيب شخص ما وفهم نصوص shell ، يرجى الدراسة بعناية.
سوف تضيف كما يتم تحديث المعلومات.
UPD 1: هدم الملفات (مع chattr -i الأولي) /etc/cron.d/root ، / etc / crontab ، rm -Rf / var / spool / cron / root لم يساعد ، بالإضافة إلى إيقاف الخدمة - اضطررت إلى إزالة crontab تمامًا في الوقت الحالي (إعادة تسمية ملف bin).
UPD 2: كان مثبّت طروادة في بعض الأحيان مستلقيًا أيضًا في أماكن أخرى ، ساعد البحث حسب الحجم:
اعثر على / الحجم 19825c
محدث 3: تحذير! بالإضافة إلى تعطيل selinux ، يضيف حصان طروادة أيضًا خاصته مفتاح SSH في $ {sshdir} / author_keys! وينشط الحقول التالية في / etc / ssh / sshd_config ، إذا لم تكن قد تم ضبطها بالفعل على YES:
PermitRootLogin نعم
RSAAuthentication نعم
PubkeyAuthentication نعم
صدى UsePAM نعم
المصادقة نعم
UPD 4: للتلخيص في الوقت الحالي: تعطيل exim و cron (مع الجذور) وإزالة مفتاح طروادة بشكل عاجل من ssh وتحرير تكوين sshd وإعادة تشغيل sshd! وبعد ذلك ، لن يكون هذا بالضبط ما سيساعده ، ولكن بدونه يكون الأمر كارثيًا بشكل عام.
لقد نقلت معلومات مهمة من التعليقات حول التصحيحات / التحديثات إلى بداية الملاحظة حتى يبدأ القراء منها.
محدث 5: أن البرامج الضارة قد غيرت كلمات المرور في WordPress.
محدث 6: ، اختبارات! بعد إعادة تشغيل الدواء أو إيقاف تشغيله ، يبدو أنه يطير ، ولكن حتى الآن على الأقل.
من سيصنع (أو يجد) حلاً مستقرًا ، يرجى الكتابة ، وسوف تساعد الكثيرين.
محدث 7: يكتب:
إذا لم تكن قد ذكرت بالفعل أن الفيروس قد تم إحيائه بفضل رسالة لم يتم إرسالها في Exim ، عندما تحاول إرسال رسالة مرة أخرى ، يتم استعادتها ، ابحث في / var / spool / exim4
يمكنك مسح قائمة انتظار Exim بالكامل كما يلي:
اكسبيك -i | xargs exim -Mrm
التحقق من عدد الإدخالات في قائمة الانتظار:
exim-bpc
محدث 8: مرة أخرى : عرض FirstVDS نسختهم الخاصة من البرنامج النصي للعلاج ، فلنختبره!
محدث 9: يبدو أعمال، شكرا لك للنص!
الشيء الرئيسي هو عدم نسيان أن الخادم قد تم اختراقه بالفعل وأن المهاجمين قد تمكنوا من زرع بعض الأشياء السيئة غير النمطية (غير مسجلة في القطارة).
لذلك ، من الأفضل الانتقال إلى خادم مثبت تمامًا (vds) ، أو على الأقل متابعة تتبع الموضوع - إذا كان هناك شيء جديد ، فاكتب في التعليقات هنا ، لأن من الواضح أنه لن ينتقل الجميع إلى تثبيت جديد ...
UPD 10: شكرًا مرة أخرى : يذكر أن ليس فقط الخوادم مصابة ، ولكن أيضًا فطيرة التوت، وجميع أنواع الأجهزة الافتراضية ... لذلك بعد حفظ الخوادم ، لا تنس حفظ وحدات تحكم الفيديو ، والروبوتات ، وما إلى ذلك.
محدث 11: من ملاحظة مهمة حول "المعالجون اليدويون":
(بعد تطبيق طريقة أو أخرى لمكافحة هذه البرامج الضارة)
أنت بالتأكيد بحاجة إلى إعادة التشغيل - البرامج الضارة موجودة في مكان ما في عمليات مفتوحة ، وبالتالي ، في الذاكرة ، وتكتب نفسها جديدة على cron كل 30 ثانية
محدث 12: هناك برنامج ضار آخر (؟) في قائمة انتظار Exim وينصحك بدراسة مشكلتك المحددة أولاً ، قبل بدء العلاج.
محدث 13: بدلاً من ذلك ، الانتقال إلى نظام نظيف ، ونقل الملفات بعناية شديدة ، لأن. البرامج الضارة موجودة بالفعل في المجال العام ويمكن استخدامها بطرق أخرى أقل وضوحًا وأكثر خطورة.
تحديث 14: طمأنة أنفسهم بحقيقة أنهم ، مثل الأشخاص الأذكياء ، لا يبدأون من الجذر - واحد آخر :
حتى لو لم يعمل من الجذر ، يحدث اختراق ... لدي debian jessie على OrangePi UPD: stretch ، exim قيد التشغيل من Debian-exim وما زال يحدث القرصنة ، فقد كرون وما إلى ذلك.
التحديث 15: عند الانتقال إلى خادم نظيف من خادم مخترق ، لا تنسى النظافة ، :
عند ترحيل البيانات ، انتبه ليس فقط إلى الملفات القابلة للتنفيذ أو ملفات التكوين ، ولكن أيضًا لكل ما قد يحتوي على أوامر ضارة (على سبيل المثال ، في MySQL يمكن أن يكون هذا إنشاء TRIGGER أو إنشاء حدث). أيضًا ، لا تنسَ ملفات .html و .js و .php و .py والملفات العامة الأخرى (من الناحية المثالية ، يجب استعادة هذه الملفات ، مثل البيانات الأخرى ، من التخزين المحلي أو غيره من وحدات التخزين الموثوقة).
محدث 16: и : كان هناك إصدار واحد من Exim في المنافذ في النظام ، ولكن في الواقع كان هناك إصدار آخر قيد التشغيل.
لذلك الجميع تأكد بعد التحديث أنك تستخدم الإصدار الجديد!
exim --versionعلى وجه التحديد ، تعاملنا مع وضعهم معًا.
استخدم الخادم DirectAdmin وكان لديه حزمة da_exim القديمة (الإصدار القديم ، بدون ثغرة أمنية).
في الوقت نفسه ، بمساعدة مدير الحزم المخصص لـ DirectAdmin ، في الواقع ، تم تثبيت إصدار أحدث من Exim ، وهو عرضة للخطر بالفعل ، في وقت لاحق.
على وجه التحديد ، في هذه الحالة ، ساعد التحديث من خلال custombuild أيضًا.
لا تنس عمل نسخ احتياطية قبل مثل هذه التجارب ، وتأكد أيضًا من أنه قبل / بعد الترقية جميع عمليات Exim للإصدار القديم وليس "عالقًا" في الذاكرة.
المصدر: www.habr.com