איך עקבתי אחר הזרקה חמקמקה וחיזקתי את הסביבה
אתם מריצים סריקת נוזקות. אתם מחליפים קבצי ליבה. אתם מעדכנים תוספים ומשנים סיסמאות. האתר נראה נקי.
יומיים לאחר מכן, הלקוח מתקשר. חשבונות מנהל חדשים חזרו. מבקרים מועברים לאתרים זדוניים.
זהו הסיוט של התמדה (persistence).
תוספי אבטחה סטנדרטיים נכשלים לעיתים קרובות. תוקפים מתוחכמים לא רק מניחים payload אחד. הם בונים דלתות אחוריות (backdoors) מקוננות שמתחבאות בתוך קבצים לגיטימיים.
לאחרונה טיפלתי במקרה שבו שלושה ניסיונות ניקוי נכשלו. התסמינים היו ספציפיים:
• מנהלי רפאים (Ghost Admins): חשבונות חדשים עם שמות אקראיים הופיעו מדי 48 שעות. • הפניות מותנות (Conditional Redirects): רק מבקרים חדשים ממנועי חיפוש ראו את האתר הזדוני. מפתחים לא ראו דבר.
הצוות כבר החליף את קבצי הליבה של WordPress ועדכן תוספים. סורקים לא הראו דבר. הנוזקה התחדשה כמו הידרה.
לתוקף היה מנגנון התמדה (persistence mechanism) במסד הנתונים או ב-cron job. סורקים אוטומטיים פספסו זאת מכיוון שהקוד היה מותאם אישית.
השתמשתי בשורת הפקודה כדי למצוא את האמת.
ראשית, אימתתי את קבצי הליבה באמצעות checksums:
wp core verify-checksums
הליבה הייתה נקייה. הדלת האחורית התגוררה ב-wp-content או במסד הנתונים.
חיפשתי קבצים ששונו ב-7 הימים האחרונים:
find . -type f -mtime -7 -name "*.php"
לאחר מכן, חיפשתי פונקציות חשודות כמו eval() או base64_decode():
grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('
מצאתי קובץ קבור בתוסף פרימיום מיושן. אך מחיקת התוסף לא עצרה את ההדבקה.
התוקף השאיר טריגר בטבלת wp_options תחת האופציה cron. בכל פעם שה-WordPress cron רץ, הוא משך payload חדש. הוא הדביק מחדש את קבצי הליבה דקות לאחר שניקו אותם.
כדי לתקן זאת, עליכם לפעול לפי סדר קפדני:
- ניקוי מסד הנתונים (Database Scrubbing)
- חפשו ב-
wp_optionsאחר נתוני autoload זדוניים. - בדקו את
wp_cronאחר כתובות URL לא ידועות. - השתמשו ב-SQL כדי למחוק משתמשים לא מורשים ישירות.
- טיהור מערכת הקבצים (File System Purge)
- מחקו הכל למעט
wp-config.phpו-wp-content/uploads/. - החליפו הכל בקבצים טריים מהמאגר הרשמי (official repository).
- מחקו כל קובץ PHP בתוך תיקיית ה-uploads.
- החלפת פרטי גישה (Credential Rotation)
- ייצרו מחדש את כל ה-authentication salts ב-
wp-config.php. - אפסו את כל סיסמאות מסד הנתונים, ה-SSH והאירוח (hosting).
כמו כן, הטמעתי שלושה מנגנוני הגנה (guardrails) כדי למנוע הישנות:
• הגנת קצה: השתמשתי ב-Cloudflare WAF כדי לחסום בקשות POST חשודות לספריות רגישות. • הרשאות קבצים: נעולתי את מבנה התיקיות. תיקיות הפכו ל-755 וקבצים ל-644. הגדרתי את wp-config.php למצב קריאה בלבד. • ביטול עריכה: הוספתי את DISALLOW_FILE_EDIT ו-DISALLOW_FILE_MODS ל-wp-config.php. זה מונע מכל אחד לשנות קוד דרך לוח הבקרה.
אל תסמכו על סימן וי ירוק מתוסף. תניחו שפרצה אכן קרתה. הגנו על האתר שלכם מבפנים החוצה.
מקור: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm