Các đồng nghiệp sử dụng phiên bản Exim 4.87...4.91 trên máy chủ thư của họ - khẩn trương cập nhật lên phiên bản 4.92, trước đó đã dừng Exim để tránh bị hack thông qua CVE-2019-10149.
Hàng triệu máy chủ trên khắp thế giới có khả năng bị tấn công, lỗ hổng này được đánh giá là nghiêm trọng (điểm cơ bản CVSS 3.0 = 9.8/10). Những kẻ tấn công có thể chạy các lệnh tùy ý trên máy chủ của bạn, trong nhiều trường hợp là từ root.
Hãy đảm bảo rằng bạn đang sử dụng phiên bản cố định (4.92) hoặc phiên bản đã được vá.
Hoặc vá cái hiện có, xem chủ đề .
Cập nhật cho xu 6:cm. — đối với centos 7, nó cũng hoạt động, nếu nó chưa được gửi trực tiếp từ epel.
CẬP NHẬT: Ubuntu bị ảnh hưởng 18.04 và 18.10, một bản cập nhật đã được phát hành cho họ. Phiên bản 16.04 và 19.04 không bị ảnh hưởng trừ khi các tùy chọn tùy chỉnh được cài đặt trên chúng. Thêm chi tiết .
Bây giờ, vấn đề được mô tả là đang được tích cực khai thác (có lẽ là bởi bot), tôi nhận thấy sự lây nhiễm trên một số máy chủ (chạy trên 4.91).
Việc đọc thêm chỉ phù hợp với những người đã “hiểu được” - bạn cần chuyển mọi thứ sang VPS sạch bằng phần mềm mới hoặc tìm kiếm giải pháp. Chúng ta thử nhé? Viết nếu có ai có thể vượt qua phần mềm độc hại này.
Nếu bạn là người dùng Exim và đang đọc nội dung này mà vẫn chưa cập nhật (chưa chắc chắn rằng có phiên bản 4.92 hoặc phiên bản vá lỗi), vui lòng dừng lại và chạy để cập nhật.
Đối với những người đã đến đó, hãy tiếp tục...
UPD: và đưa ra lời khuyên đúng đắn:
Có thể có rất nhiều loại phần mềm độc hại. Bằng cách tung ra thuốc sai và xóa hàng đợi, người dùng sẽ không được chữa khỏi và có thể không biết mình cần được điều trị bệnh gì.
Sự lây nhiễm có thể nhận thấy rõ ràng như thế này: [kthrotlds] tải bộ xử lý; trên VDS yếu là 100%, trên máy chủ thì yếu hơn nhưng đáng chú ý.
Sau khi lây nhiễm, phần mềm độc hại sẽ xóa các mục cron, chỉ đăng ký chính nó ở đó để chạy 4 phút một lần, đồng thời làm cho tệp crontab không thể thay đổi. Crontab -e không thể lưu các thay đổi, báo lỗi.
Bất biến có thể được loại bỏ, ví dụ, như thế này, sau đó xóa dòng lệnh (1.5kb):
chattr -i /var/spool/cron/root
crontab -e
Tiếp theo, trong trình chỉnh sửa crontab (vim), xóa dòng này và lưu:dd
:wq
Tuy nhiên, một số quy trình đang hoạt động lại bị ghi đè, tôi đang tìm hiểu.
Đồng thời, có một loạt wget (hoặc lọn tóc) đang hoạt động treo trên các địa chỉ từ tập lệnh cài đặt (xem bên dưới), hiện tại tôi đang loại bỏ chúng như thế này, nhưng chúng lại bắt đầu lại:
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}'`
Tôi đã tìm thấy tập lệnh cài đặt Trojan tại đây (centos): /usr/local/bin/nptd... Tôi không đăng nó để tránh điều đó, nhưng nếu ai bị nhiễm và hiểu các tập lệnh shell, vui lòng nghiên cứu kỹ hơn.
Tôi sẽ bổ sung khi thông tin được cập nhật.
CẬP NHẬT 1: Xóa các tệp (với chattr -i sơ bộ) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root không giúp được gì, cũng như không dừng dịch vụ - tôi phải làm vậy crontab hoàn toàn bây giờ hãy xé nó ra (đổi tên file bin).
CẬP NHẬT 2: Trình cài đặt Trojan đôi khi cũng nằm rải rác ở những nơi khác, việc tìm kiếm theo kích thước đã giúp:
tìm / -size 19825c
CẬP NHẬT 3: Cảnh báo! Ngoài việc vô hiệu hóa selinux, Trojan còn thêm tính năng riêng của nó Khóa SSH bằng ${sshdir}/authorized_keys! Và kích hoạt các trường sau trong /etc/ssh/sshd_config, nếu chúng chưa được đặt thành CÓ:
PermitRootLogin có
RSAXác thực có
PubkeyAuthentication có
echo Sử dụngPAM có
PasswordAuthentication có
CẬP NHẬT 4: Tóm lại bây giờ: tắt Exim, cron (có root), khẩn cấp gỡ bỏ key Trojan khỏi ssh và chỉnh sửa cấu hình sshd, khởi động lại sshd! Và vẫn chưa rõ liệu điều này có hữu ích hay không, nhưng nếu không có nó thì sẽ có vấn đề.
Tôi đã chuyển thông tin quan trọng từ phần nhận xét về các bản vá/cập nhật lên đầu ghi chú để người đọc bắt đầu với nó.
CẬP NHẬT 5: rằng phần mềm độc hại đã thay đổi mật khẩu trong WordPress.
CẬP NHẬT 6: , cùng kiểm tra nào! Sau khi khởi động lại hoặc tắt máy, thuốc dường như biến mất, nhưng ít nhất hiện tại là như vậy.
Bạn nào đưa ra (hoặc tìm ra) giải pháp ổn định thì viết nhé, bạn sẽ giúp được nhiều người.
CẬP NHẬT 7: viết:
Nếu bạn chưa nói rằng virus đã sống lại nhờ một lá thư chưa gửi được trong Exim, khi bạn cố gắng gửi lại lá thư, nó sẽ được khôi phục, hãy xem trong /var/spool/exim4
Bạn có thể xóa toàn bộ hàng đợi Exim như thế này:
xuất hiện -i | xargs exim -Mrm
Kiểm tra số lượng mục trong hàng đợi:
exim -bpc
CẬP NHẬT 8: Một lần nữa : FirstVDS cung cấp phiên bản kịch bản điều trị của họ, hãy thử nghiệm nó!
CẬP NHẬT 9: Có vẻ như công trình, cảm ơn cho kịch bản!
Điều chính là đừng quên rằng máy chủ đã bị xâm phạm và những kẻ tấn công có thể đã cố gắng tạo ra một số thứ khó chịu không điển hình hơn (không được liệt kê trong ống nhỏ giọt).
Vì vậy, tốt hơn hết bạn nên chuyển sang một máy chủ (vds) đã được cài đặt hoàn chỉnh, hoặc ít nhất là tiếp tục theo dõi chủ đề - nếu có gì mới, hãy viết bình luận tại đây, bởi vì rõ ràng là không phải ai cũng sẽ chuyển sang bản cài đặt mới...
CẬP NHẬT 10: Cảm ơn một lần nữa : nó nhắc nhở rằng không chỉ máy chủ bị nhiễm mà còn cả Raspberry Pivà tất cả các loại máy ảo... Vì vậy, sau khi lưu máy chủ, đừng quên lưu bảng điều khiển video, robot, v.v.
CẬP NHẬT 11: Từ Lưu ý quan trọng dành cho người chữa bệnh bằng tay:
(sau khi sử dụng phương pháp này hoặc phương pháp khác để chống lại phần mềm độc hại này)
Bạn chắc chắn cần phải khởi động lại - phần mềm độc hại nằm ở đâu đó trong các quy trình đang mở và theo đó, trong bộ nhớ và tự ghi một phần mềm mới vào cron cứ sau 30 giây
CẬP NHẬT 12: Exim có một phần mềm độc hại(?) khác trong hàng đợi của nó và khuyên bạn trước tiên nên nghiên cứu vấn đề cụ thể của mình trước khi bắt đầu điều trị.
CẬP NHẬT 13: đúng hơn, hãy chuyển sang một hệ thống sạch và truyền tệp cực kỳ cẩn thận, bởi vì Phần mềm độc hại đã được công khai và có thể được sử dụng theo những cách khác, ít rõ ràng hơn và nguy hiểm hơn.
CẬP NHẬT 14: tự trấn an bản thân rằng những người thông minh không chạy từ gốc - một điều nữa :
Ngay cả khi nó không hoạt động từ root, hack vẫn xảy ra... Tôi có debian jessie CẬP NHẬT: kéo dài trên OrangePi của tôi, Exim đang chạy từ Debian-exim và vẫn xảy ra hack, mất vương miện, v.v.
CẬP NHẬT 15: khi chuyển sang máy chủ sạch từ máy chủ bị xâm nhập, đừng quên vệ sinh, :
Khi truyền dữ liệu, không chỉ chú ý đến các tệp thực thi hoặc tệp cấu hình mà còn chú ý đến bất kỳ thứ gì có thể chứa các lệnh độc hại (ví dụ: trong MySQL, điều này có thể là TẠO TRIGGER hoặc TẠO SỰ KIỆN). Ngoài ra, đừng quên .html, .js, .php, .py và các tệp công khai khác (lý tưởng nhất là các tệp này, giống như các dữ liệu khác, phải được khôi phục từ bộ nhớ cục bộ hoặc bộ lưu trữ đáng tin cậy khác).
CẬP NHẬT 16: и : hệ thống đã cài đặt một phiên bản Exim trong các cổng, nhưng thực tế nó đang chạy một phiên bản khác.
Nên tất cả mọi người sau khi cập nhật bạn nên chắc chắn rằng bạn đang sử dụng phiên bản mới!
exim --versionChúng tôi cùng nhau giải quyết tình huống cụ thể của họ.
Máy chủ đã sử dụng DirectAdmin và gói da_exim cũ (phiên bản cũ, không có lỗ hổng).
Đồng thời, với sự trợ giúp của trình quản lý gói custombuild của DirectAdmin, trên thực tế, một phiên bản Exim mới hơn đã được cài đặt và phiên bản này vốn đã dễ bị tấn công.
Trong tình huống cụ thể này, việc cập nhật qua custombuild cũng có ích.
Đừng quên tạo bản sao lưu trước các thử nghiệm như vậy và cũng đảm bảo rằng trước/sau khi cập nhật, tất cả các quy trình Exim đều thuộc phiên bản cũ và không bị “mắc kẹt” trong trí nhớ.
Nguồn: www.habr.com