อัปเดต Exim เป็น 4.92 อย่างเร่งด่วน - มีการติดไวรัสที่ทำงานอยู่

เพื่อนร่วมงานที่ใช้ Exim เวอร์ชัน 4.87...4.91 บนเมลเซิร์ฟเวอร์ของตน - อัปเดตเป็นเวอร์ชัน 4.92 อย่างเร่งด่วน โดยต้องหยุด Exim เสียก่อนเพื่อหลีกเลี่ยงการแฮ็กผ่าน CVE-2019-10149

เซิร์ฟเวอร์หลายล้านเครื่องทั่วโลกมีความเสี่ยง ช่องโหว่นี้ได้รับการจัดอันดับว่าวิกฤติ (คะแนนฐาน CVSS 3.0 = 9.8/10) ผู้โจมตีสามารถเรียกใช้คำสั่งตามอำเภอใจบนเซิร์ฟเวอร์ของคุณได้ ในหลายกรณีจากรูท

โปรดตรวจสอบให้แน่ใจว่าคุณใช้เวอร์ชันที่แก้ไขแล้ว (4.92) หรือเวอร์ชันที่ได้รับแพตช์แล้ว
หรือแพตช์อันที่มีอยู่ดูที่เธรด ความคิดเห็นที่ไม่มีที่ติ.

อัปเดตสำหรับ centos 6: ซม. ความคิดเห็นโดย ธีโอดอร์ — สำหรับ centos 7 ก็ใช้งานได้เช่นกัน หากยังไม่ได้มาจาก epel โดยตรง

UPD: Ubuntu ได้รับผลกระทบ 18.04 และ 18.10มีการอัปเดตสำหรับพวกเขาแล้ว เวอร์ชัน 16.04 และ 19.04 จะไม่ได้รับผลกระทบเว้นแต่จะติดตั้งตัวเลือกแบบกำหนดเองไว้ รายละเอียดเพิ่มเติม บนเว็บไซต์ทางการของพวกเขา.

ข้อมูลเกี่ยวกับปัญหาบน Opennet
ข้อมูลบนเว็บไซต์ Exim

ตอนนี้ปัญหาที่อธิบายไว้ว่ากำลังถูกเอารัดเอาเปรียบ (โดยบอท) ฉันสังเกตเห็นการติดไวรัสบนเซิร์ฟเวอร์บางตัว (ทำงานบน 4.91)

อ่านเพิ่มเติมเกี่ยวข้องเฉพาะกับผู้ที่ "ได้รับ" แล้ว - คุณต้องขนส่งทุกอย่างไปยัง VPS ที่สะอาดด้วยซอฟต์แวร์ใหม่ หรือค้นหาวิธีแก้ไข เราจะลองไหม? เขียนว่าใครก็ตามสามารถเอาชนะมัลแวร์นี้ได้

หากคุณเป็นผู้ใช้ Exim และอ่านข้อความนี้อยู่ แต่ยังไม่ได้อัปเดต (ไม่แน่ใจว่ามีเวอร์ชัน 4.92 หรือเวอร์ชันแพตช์หรือไม่) โปรดหยุดและเรียกใช้เพื่ออัปเดต

สำหรับใครที่ไปแล้วไปต่อกันได้เลย...

ยูพีเอส: supersmile2009 พบมัลแวร์อีกประเภทหนึ่ง และให้คำแนะนำที่ถูกต้อง:

อาจมีมัลแวร์ได้หลากหลาย การเปิดยาผิดและเคลียร์คิวทำให้ผู้ใช้ไม่หายและอาจไม่รู้ว่าต้องรักษาเพื่ออะไร

การติดเชื้อจะสังเกตเห็นได้ชัดเจนดังนี้: [kthrotlds] โหลดโปรเซสเซอร์; บน VDS ที่อ่อนแอคือ 100% บนเซิร์ฟเวอร์จะอ่อนแอกว่าแต่สังเกตได้ชัดเจน

หลังจากการติดไวรัส มัลแวร์จะลบรายการ cron โดยจะบันทึกเฉพาะตัวมันเองเพื่อให้ทำงานทุกๆ 4 นาที ในขณะที่ทำให้ไฟล์ crontab ไม่เปลี่ยนรูป Crontab -e ไม่สามารถบันทึกการเปลี่ยนแปลงได้ เกิดข้อผิดพลาด

ไม่สามารถลบรูปแบบที่ไม่เปลี่ยนรูปได้เช่นนี้ จากนั้นจึงลบบรรทัดคำสั่ง (1.5kb):

chattr -i /var/spool/cron/root
crontab -e

ถัดไปในตัวแก้ไข crontab (กลุ่ม) ให้ลบบรรทัดและบันทึก:dd
:wq

อย่างไรก็ตาม กระบวนการที่ทำงานอยู่บางส่วนกำลังถูกเขียนทับอีกครั้ง ฉันกำลังหาคำตอบอยู่

ในเวลาเดียวกันมี wgets ที่ใช้งานอยู่จำนวนมาก (หรือหยิก) แขวนอยู่บนที่อยู่จากสคริปต์ตัวติดตั้ง (ดูด้านล่าง) ฉันกำลังทำให้พวกเขาล้มลงเช่นนี้ในตอนนี้ แต่พวกเขาเริ่มต้นใหม่อีกครั้ง:

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... ฉันไม่ได้โพสต์สคริปต์เพื่อหลีกเลี่ยง แต่ถ้าใครติดไวรัสและเข้าใจเชลล์สคริปต์ โปรดศึกษาให้ละเอียดยิ่งขึ้น

ฉันจะเพิ่มเมื่อมีการอัปเดตข้อมูล

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}/authorized_keys! และเปิดใช้งานฟิลด์ต่อไปนี้ใน /etc/ssh/sshd_config หากยังไม่ได้ตั้งค่าเป็น YES:
PermitRootLogin ใช่
RSAAuthentication ใช่
PubkeyAuthentication ใช่
สะท้อน UsePAM ใช่
การตรวจสอบรหัสผ่านใช่

UPD 4: เพื่อสรุปในตอนนี้: ปิดการใช้งาน Exim, cron (พร้อมรูท) ลบคีย์โทรจันออกจาก ssh อย่างเร่งด่วนและแก้ไขการกำหนดค่า sshd รีสตาร์ท sshd! และยังไม่ชัดเจนว่าสิ่งนี้จะช่วยได้ แต่ถ้าไม่มีก็มีปัญหา

ฉันย้ายข้อมูลสำคัญจากความคิดเห็นเกี่ยวกับแพตช์/อัปเดตไปยังจุดเริ่มต้นของบันทึก เพื่อให้ผู้อ่านได้เริ่มต้นใช้งาน

อัปเดต 5: อีกคนเดนนี่เขียน ว่ามัลแวร์เปลี่ยนรหัสผ่านใน WordPress

อัปเดต 6: พอลมันน์เตรียมการรักษาชั่วคราว, มาทดสอบกัน! หลังจากรีบูตหรือปิดเครื่อง ดูเหมือนว่ายาจะหายไป แต่อย่างน้อยก็แค่ตอนนี้เท่านั้น

ใครก็ตามที่สร้าง (หรือค้นหา) วิธีแก้ปัญหาที่มั่นคง โปรดเขียนมา คุณจะช่วยได้มากมาย

อัปเดต 7: ผู้ใช้ CLSV เขียน:

หากคุณยังไม่ได้บอกว่าไวรัสฟื้นคืนชีพแล้วด้วยจดหมายที่ยังไม่ได้ส่งใน Exim เมื่อคุณพยายามส่งจดหมายอีกครั้ง จดหมายนั้นจะถูกกู้คืน ให้ดูใน /var/spool/exim4

คุณสามารถล้างคิว Exim ทั้งหมดได้ดังนี้:
exipick -i | xargs exim -นาย
การตรวจสอบจำนวนรายการในคิว:
ส่งออก -bpc

UPD 8: อีกครั้ง ขอบคุณสำหรับข้อมูล AnotherDenny: FirstVDS เสนอสคริปต์การรักษาเวอร์ชันของพวกเขา มาทดสอบกัน!

UPD 9: ดูเหมือนว่า โรงงาน, ขอขอบคุณ คิริลล์ สำหรับสคริปต์!

สิ่งสำคัญคืออย่าลืมว่าเซิร์ฟเวอร์ถูกโจมตีแล้ว และผู้โจมตีสามารถจัดการเพื่อวางสิ่งที่น่ารังเกียจผิดปรกติได้ (ไม่อยู่ในรายการหยด)

ดังนั้นจึงเป็นการดีกว่าที่จะย้ายไปยังเซิร์ฟเวอร์ที่ติดตั้งอย่างสมบูรณ์ (vds) หรืออย่างน้อยก็ติดตามหัวข้อต่อไป - หากมีอะไรใหม่เขียนความคิดเห็นที่นี่เพราะ แน่นอนว่าไม่ใช่ทุกคนที่จะย้ายไปติดตั้งใหม่...

UPD 10: ขอบคุณอีกครั้ง คลาสวี: มันเตือนว่าไม่เพียงแต่เซิร์ฟเวอร์ที่ติดไวรัสเท่านั้น แต่ยังเตือนด้วย ราสเบอร์รี่ Piและเครื่องเสมือนทุกประเภท... ดังนั้นหลังจากบันทึกเซิร์ฟเวอร์แล้ว อย่าลืมบันทึกวิดีโอคอนโซล หุ่นยนต์ ฯลฯ ของคุณ

UPD 11: จาก ผู้เขียนบทการรักษา หมายเหตุสำคัญสำหรับผู้รักษาด้วยตนเอง:
(หลังจากใช้วิธีใดวิธีหนึ่งในการต่อสู้กับมัลแวร์นี้)

คุณต้องรีบูทอย่างแน่นอน - มัลแวร์อยู่ที่ไหนสักแห่งในกระบวนการเปิดและตามนั้นในหน่วยความจำและเขียนตัวใหม่เพื่อ cron ทุก ๆ 30 วินาที

อัปเดต 12: พบ supersmile2009 Exim มีมัลแวร์อื่น (?) อยู่ในคิว และแนะนำให้คุณศึกษาปัญหาเฉพาะของคุณก่อนเริ่มการรักษา

อัปเดต 13: ลอร์คให้คำแนะนำ แทนที่จะย้ายไปยังระบบที่สะอาดและถ่ายโอนไฟล์อย่างระมัดระวังเพราะว่า มัลแวร์นี้เผยแพร่สู่สาธารณะแล้วและสามารถนำไปใช้ในรูปแบบอื่นที่ไม่ชัดเจนและอันตรายกว่าได้

UPD 14: สร้างความมั่นใจให้กับตัวเองว่าคนฉลาดไม่ได้วิ่งหนีจากราก - อีกอย่างหนึ่ง ข้อความด่วนจาก clsv:

แม้ว่ามันจะไม่ทำงานจากรูท แต่การแฮ็กก็เกิดขึ้น ... ฉันมี debian jessie UPD: ยืด OrangePi ของฉัน, Exim กำลังเรียกใช้จาก Debian-exim และยังคงเกิดการแฮ็ก, ครอบฟันหายไป ฯลฯ

UPD 15: เมื่อย้ายไปยังเซิร์ฟเวอร์ที่สะอาดจากเซิร์ฟเวอร์ที่ถูกบุกรุกอย่าลืมเรื่องสุขอนามัย คำเตือนที่เป็นประโยชน์จาก w0den:

เมื่อถ่ายโอนข้อมูล ไม่เพียงแต่ต้องใส่ใจกับไฟล์ปฏิบัติการหรือไฟล์การกำหนดค่าเท่านั้น แต่ยังรวมถึงสิ่งใดก็ตามที่อาจมีคำสั่งที่เป็นอันตราย (เช่น ใน MySQL นี่อาจเป็น CREATE TRIGGER หรือ CREATE EVENT) นอกจากนี้ อย่าลืมเกี่ยวกับ .html, .js, .php, .py และไฟล์สาธารณะอื่นๆ (ตามหลักการแล้ว ไฟล์เหล่านี้ควรได้รับการกู้คืนจากที่เก็บข้อมูลในเครื่องหรือที่เก็บข้อมูลที่เชื่อถือได้อื่นๆ เช่นเดียวกับข้อมูลอื่นๆ)

อัปเดต 16: เดย์คิน и savage_me ประสบปัญหาอื่น: ระบบมี Exim เวอร์ชันหนึ่งติดตั้งอยู่ในพอร์ต แต่ในความเป็นจริงแล้วกำลังใช้งานเวอร์ชันอื่นอยู่

ดังนั้นทุกคน หลังจากการอัพเดตคุณควรตรวจสอบให้แน่ใจ ว่าคุณกำลังใช้เวอร์ชันใหม่อยู่!

exim --version

เราจัดการสถานการณ์เฉพาะของพวกเขาด้วยกัน

เซิร์ฟเวอร์ใช้ DirectAdmin และแพ็คเกจ da_exim เก่า (เวอร์ชันเก่าไม่มีช่องโหว่)

ในขณะเดียวกัน ด้วยการใช้ตัวจัดการแพ็คเกจแบบกำหนดเองของ DirectAdmin ทำให้ Exim เวอร์ชันใหม่ได้รับการติดตั้งซึ่งมีช่องโหว่อยู่แล้ว

ในสถานการณ์เฉพาะนี้ การอัปเดตผ่าน custombuild ก็ช่วยได้เช่นกัน

อย่าลืมสำรองข้อมูลก่อนการทดลองดังกล่าว และตรวจสอบให้แน่ใจว่าก่อน/หลังการอัปเดตกระบวนการ Exim ทั้งหมดเป็นเวอร์ชันเก่า ถูกหยุด และไม่ “ติด” อยู่ในความทรงจำ

ที่มา: will.com