עדכן בדחיפות את exim ל-4.92 - יש זיהום פעיל

עמיתים שמשתמשים בגרסאות Exim 4.87...4.91 בשרתי הדואר שלהם - עדכנו בדחיפות לגרסה 4.92, לאחר שבעבר עצרו את Exim עצמה כדי להימנע מפריצה דרך CVE-2019-10149.

כמה מיליוני שרתים ברחבי העולם עלולים להיות פגיעים, הפגיעות מדורגת כקריטית (ציון בסיס CVSS 3.0 = 9.8/10). תוקפים יכולים להריץ פקודות שרירותיות בשרת שלך, במקרים רבים מהשורש.

אנא ודא שאתה משתמש בגרסה קבועה (4.92) או בגרסה שכבר תוקנה.
או תיקון את הקיים, ראה שרשור הערה ללא רבב.

עדכון עבור 6: ס"מ. הערה של תיאודור - עבור centos 7 זה גם עובד, אם זה עדיין לא הגיע ישירות מ-epel.

UPD: אובונטו מושפעת 18.04 ו18.10, פורסם עבורם עדכון. גרסאות 16.04 ו-19.04 אינן מושפעות אלא אם הותקנו בהן אפשרויות מותאמות אישית. פרטים נוספים באתר הרשמי שלהם.

מידע על הבעיה ב-Opennet
מידע באתר אקסים

כעת הבעיה המתוארת שם מנוצלת באופן פעיל (על ידי בוט, ככל הנראה), הבחנתי בזיהום בשרתים מסוימים (פועל ב-4.91).

קריאה נוספת רלוונטית רק למי שכבר "השיג" - אתה צריך או להעביר הכל ל-VPS נקי עם תוכנה טרייה, או לחפש פתרון. ננסה? כתוב אם מישהו יכול להתגבר על התוכנה הזדונית הזו.

אם אתה, בהיותך משתמש Exim וקורא את זה, עדיין לא עדכנת (לא וידאת שגרסה 4.92 או גרסה מתוקנת זמינה), אנא עצור והפעל כדי לעדכן.

למי שכבר הגיע לשם, בואו נמשיך...

UPD: supersmile2009 מצא סוג אחר של תוכנות זדוניות ונותן את העצה הנכונה:

יכול להיות מגוון גדול של תוכנות זדוניות. על ידי השקת התרופה עבור הדבר הלא נכון וניקוי התור, המשתמש לא יתרפא ואולי לא יידע במה הוא צריך לטפל.

הזיהום מורגש כך: [kthrotlds] טוען את המעבד; ב-VDS חלש זה 100%, בשרתים זה חלש יותר אבל מורגש.

לאחר ההדבקה, התוכנה הזדונית מוחקת ערכי cron, רושמת רק את עצמה שם כדי לרוץ כל 4 דקות, תוך כדי הפיכת קובץ crontab לבלתי ניתן לשינוי. Crontab -e לא יכול לשמור שינויים, נותן שגיאה.

ניתן להסיר ללא שינוי, למשל, כך, ולאחר מכן למחוק את שורת הפקודה (1.5kb):

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

לאחר מכן, בעורך crontab (vim), מחק את השורה ושמור: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

UPD3: אזהרה! בנוסף להשבית של selinux, הטרויאני גם מוסיף משלו מפתח SSH ב-${sshdir}/authorized_keys! ומפעיל את השדות הבאים ב-/etc/ssh/sshd_config, אם הם עדיין לא הוגדרו ל-YES:
PermitRootLogin כן
RSAAאימות כן
Pubkey אימות כן
echo UsePAM כן
אימות סיסמה כן

UPD 4: לסיכום לעת עתה: השבת את Exim, cron (עם שורשים), הסר בדחיפות את המפתח הטרויאני מ-ssh וערוך את תצורת sshd, הפעל מחדש את sshd! ועדיין לא ברור שזה יעזור, אבל בלי זה יש בעיה.

העברתי מידע חשוב מההערות על תיקונים/עדכונים לתחילת ההערה, כדי שהקוראים יתחילו איתו.

UPD5: דני אחר כותב שהתוכנה הזדונית שינתה סיסמאות בוורדפרס.

UPD6: פולמן הכין תרופה זמנית, בואו נבחן! לאחר אתחול מחדש או כיבוי, נראה שהתרופה נעלמת, אבל בינתיים לפחות זהו.

כל מי שעושה (או מוצא) פתרון יציב, בבקשה תכתוב, אתה תעזור לרבים.

UPD7: משתמש clsv כותב:

אם עוד לא אמרת שהווירוס קם לתחייה בזכות מכתב שלא נשלח ב-Exim, כשאתה מנסה לשלוח את המכתב שוב, הוא משוחזר, חפש ב /var/spool/exim4

אתה יכול לנקות את כל תור ה-Exim כך:
exipic -i | xargs exim -מר
בדיקת מספר הכניסות בתור:
exim -bpc

UPD 8: שוב תודה על המידע AnotherDenny: FirstVDS הציעו את הגרסה שלהם לתסריט הטיפולי, בואו נבדוק אותה!

UPD 9: זה נראה כמו עובדתודה קיריל על התסריט!

העיקר לא לשכוח שהשרת כבר נפגע והתוקפים יכלו להצליח לשתול עוד כמה דברים מגעילים לא טיפוסיים (לא רשומים בטפטפת).

לכן, עדיף לעבור לשרת מותקן לחלוטין (vds), או לפחות להמשיך לעקוב אחר הנושא - אם יש משהו חדש, כתבו בתגובות כאן, כי ברור שלא כולם יעברו להתקנה חדשה...

UPD 10: שוב תודה clsv: זה מזכיר שלא רק שרתים נגועים, אלא גם פטל Pi, וכל מיני מכונות וירטואליות... אז לאחר שמירת השרתים, אל תשכח לשמור את קונסולות הווידאו, הרובוטים וכו'.

UPD 11: מאת מחבר תסריט הריפוי הערה חשובה למרפאים ידניים:
(לאחר שימוש בשיטה כזו או אחרת למלחמה בתוכנה זדונית זו)

אתה בהחלט צריך לאתחל - התוכנה הזדונית יושבת איפשהו בתהליכים פתוחים, ובהתאם, בזיכרון, וכותבת לעצמה אחת חדשה ל-cron כל 30 שניות

UPD12: supersmile2009 נמצא ל-Exim יש תוכנה זדונית נוספת(?) בתור וממליצה לך ללמוד תחילה את הבעיה הספציפית שלך לפני תחילת הטיפול.

UPD13: לורק מייעץ במקום זאת, לעבור למערכת נקייה ולהעביר קבצים בזהירות רבה, כי התוכנה הזדונית כבר זמינה לציבור וניתן להשתמש בה בדרכים אחרות, פחות ברורות ומסוכנות יותר.

UPD 14: להרגיע את עצמנו שאנשים חכמים לא בורחים מהשורש - עוד דבר הודעה דחופה מ-clsv:

גם אם זה לא עובד מה-root, פריצה מתרחשת... יש לי debian jessie UPD: מתח על OrangePi שלי, Exim פועל מדביאן-exim ועדיין התרחש פריצה, איבדו כתרים וכו'.

UPD 15: בעת מעבר לשרת נקי משרת שנפגע, אל תשכח את ההיגיינה, תזכורת שימושית מ-w0den:

בעת העברת נתונים, שימו לב לא רק לקבצי הפעלה או תצורה, אלא גם לכל דבר שעלול להכיל פקודות זדוניות (לדוגמה, ב-MySQL זה יכול להיות CREATE TRIGGER או CREATE EVENT). כמו כן, אל תשכח את .html, .js, .php, .py וקבצים ציבוריים אחרים (באופן אידיאלי יש לשחזר קבצים אלה, כמו נתונים אחרים, מאחסון מקומי או מהימן אחר).

UPD16: דייקין и פרא_אני נתקל בבעיה אחרת: למערכת הייתה גרסה אחת של Exim מותקנת ביציאות, אך בפועל היא הפעילה גרסה אחרת.

אז כולם לאחר העדכון כדאי לוודא שאתה משתמש בגרסה החדשה!

exim --version

סידרנו יחד את המצב הספציפי שלהם.

השרת השתמש ב-DirectAdmin ובחבילת da_exim הישנה שלו (גרסה ישנה, ​​ללא פגיעות).

במקביל, בעזרת מנהל החבילות Custombuild של DirectAdmin, למעשה, הותקנה אז גרסה חדשה יותר של Exim, שכבר הייתה פגיעה.

במצב הספציפי הזה, גם עדכון באמצעות Custombuild עזר.

אל תשכח לעשות גיבויים לפני ניסויים כאלה, וגם לוודא שלפני/אחרי העדכון כל תהליכי Exim הם מהגרסה הישנה נעצרו ולא "תקוע" בזיכרון.

מקור: www.habr.com