הקדמה
רוב מתקפות הסייבר שאנחנו רואים מגיעות מבחוץ – סריקות אוטומטיות, ניצול פגיעויות, העלאת קבצים זדוניים.
ה-WAF עוצר, ה-ModSecurity רושם, אנחנו מזהים ומטפלים.
אבל יש סוג אחר של מתקפה שלא עושה כלום מהדברים האלה. היא לא סורקת פורטים.
היא לא מעלה webshell. היא לא מפעילה שום חתימה ב-IDS.
היא פשוט משתמשת בכלים הלגיטימיים שלכם – כמו שמנהל אתר רגיל היה משתמש בהם.
מה זה ManageWP?
ManageWP הוא כלי ניהול WordPress מרכזי פופולרי מאוד – במיוחד בקרב סוכנויות ומפתחים שמנהלים עשרות או מאות אתרים.
הוא מאפשר עדכון plugins, גיבוי, ניטור ביצועים, והתקנת קוד – הכל ממסך ניהול אחד, בלי להיכנס ל-wp-admin של כל אתר בנפרד.
זה כלי לגיטימי. מדובר בשירות מוכר ומשמש אלפי מפתחים ברחבי העולם.
וזה בדיוק מה שהופך אותו למטרה.
הסיפור: כשה-API עובד בשבילם
יום 1 – כניסה דרך הדלת הראשית
בחינה של לוגי מודולי האבטחה חשפה פעילות חריגה: חשבון ManageWP לגיטימי של מפתח התחיל לבצע פעולות חריגות –
התקנת packages ממקור לא מוכר, עם הפעלה מיידית ורשת verification calls לאחר מכן.
לא היה שום ניסיון כניסה כושל. לא היה brute force. הכניסה הייתה עם credentials תקינים לחלוטין –
כנראה גנובים מחוץ לסביבה שלנו, דרך phishing או data breach.
ימים 1-4 – פריסה שיטתית
לאחר הכניסה, התוקף לא מיהר. הוא פרס 9 packages זדוניים לאורך כמעט 4 ימים – כל אחד עם שם שנראה כמו plugin לגיטימי,
כל אחד מופעל מיד אחרי ההתקנה, כל אחד נשלף מ-S3 bucket חיצוני שנבנה מראש.
הפעולות נרשמו בלוגים כ-ManageWP API calls רגילים. אין קובץ זדוני שהועלה ישירות. אין HTTP request חשוד.
רק API calls שנראים זהים לכל פעילות ניהול לגיטימית אחרת.
יום 18 – password reset שלא עצר כלום
כשהמפתח שינה סיסמת admin, ציפינו שהפעילות תיפסק. היא לא נפסקה.
3 packages נוספים הותקנו תוך 18 שעות מה-reset.
הסיבה: backdoors שהותקנו בשלב הראשון היו עצמאיים לחלוטין מסיסמת ה-WordPress admin.
גישת ManageWP למתקפה לא הייתה תלויה בסיסמה – היא הייתה תלויה ב-Worker plugin שהותקן על האתר,
ו-token חיבור שנשאר תקף.
זיהוי ובלימה
הגילוי הגיע דרך ניתוח דפוסי תנועה חריגים – לא חתימת malware, לא rule של WAF.
זיהינו שפעולות API מסוימות מגיעות מ-IP של AWS שלא תאם את פעילות ה-ManageWP הרגילה של החשבון,
ושה-packages שהותקנו לא הופיעו ב-WordPress.org.
הבלימה דרשה:
- ניתוק מלא של חיבור ManageWP מהאתר
- הסרה של ה-Worker plugin
- זיהוי והסרה של כל 9 ה-packages הזדוניים
- סריקה מלאה של ה-DB וה-filesystem לאיתור persistence נוסף
- רוטציה של כל credentials הקשורים לחשבון
איך SPD מזהה מתקפות מהסוג הזה
אין לנו כלי ראשי אחד נגד הכל – מדובר ב-echosystem שלנו נגד מתקפות כאלה –
Imunify360 לקוד זדוני, Crowdstrike לזיהו התנהגויות ושינויים, modsec להגבה נגד חולשות
והתנהגויות חשודות, Cloudflare כשומר ראשי בשער, ועוד ועוד.
אנחנו מנטרים כל האתרים שלנו ברציפות לאיתור anomalies בדפוסי פעילות:
- IP ranges שביצעו API calls שלא תואמים את ה-baseline הרגיל של החשבון,
- burst של פעולות ניהול ממיקומים חריגים,
- ו-verification calls לדומיינים חיצוניים שלא הופיעו בעבר בפעילות האתר.
- Defacement של דפים ראשיים של אתרים,
ועוד אינספור מדדים – כל אירוע חדש מסוגו, נגמר בהוספה של חוקים חדשים –
מה שנכון עבור הגנה של לקוח אחד, משוכפל עבור כלל לקוחות החברה, מדף של טכנאי עצמאי,
עד מותג אופנה של מאות אלפי לקוחות ביום.
במקרה שתואר כאן, השילוב של מקור IP חדש + packages ממקור לא מוכר + verification traffic חיצוני הוא מה שהצית את ה-alert – לא שום חתימה ידועה.
מה קורה אחרי שמזהים
כשמתגלה פעילות חשודה, הצעד הראשון הוא בידוד – לא מחיקה. אנחנו מנתקים את ה-Worker plugin
ואת חיבור ה-ManageWP לפני שנוגעים בשום דבר אחר, כדי שהתוקף לא יוכל להגיב בזמן אמת ולהסתיר עקבות.
רק אחרי הבידוד מתחיל תחקיר מלא: מיפוי כל ה-packages שהותקנו, בדיקת ה-DB לאיתור persistence נוסף,
ורוטציה של כל ה-credentials הרלוונטיים – כולל ה-connection token של ManageWP, שהוא נפרד לחלוטין מסיסמת ה-WordPress.
כשאתר אחד מגלה – כל הצי מרוויח
אחד היתרונות של ניהול Infruscrture בקנה מידה הוא שכל גילוי הופך למידע.
כשזיהינו את הדפוס הזה באתר אחד, העברנו את ה-IOCs – כתובות ה-IP, שמות ה-packages, ה-S3 bucket,
לבדיקה ממוקדת על שאר הצי. מתקפה שמצליחה "להכנס מתחת לרדאר" באתר אחד לא יכולה לשכפל את עצמה לאחרים בלי שנזהה את הדפוס.
למה זה עובד כל כך טוב מנקודת מבט של תוקף
הכל נראה לגיטימי
ManageWP Worker plugin מורשה לבצע כמעט כל פעולה על האתר – זה בדיוק מה שהוא נועד לעשות.
כשהוא מתקין plugin, זה נראה כמו התקנת plugin. כשהוא מפעיל קוד, זה נראה כמו הפעלת קוד.
אין "חתימת תקיפה" שאפשר לזהות – כי הפעולות עצמן תקינות.
החלון ארוך
בניגוד למתקפת RCE שחייבת להשיג את מה שהיא צריכה מהר לפני שמזהים אותה,
מתקפה דרך ManageWP יכולה לפעול לאט ושיטתית. 4 ימים של פריסה מדורגת – עם הפסקות בין packages –
זה pattern שמיועד לעקוף מערכות ניטור שמחפשות burst פעילות.
password reset לא מספיק
זו הנקודה הכי חשובה. ברגע שהותקנו backdoors, הסיסמה הפכה לבלתי רלוונטית.
מנהלי אתרים רבים חושבים ש-"שיניתי סיסמה" = "סגרתי את הפרצה." במקרה הזה זה לא היה נכון.
מה אפשר לעשות
לבעלי אתרים שמשתמשים ב-ManageWP
הגבילו הרשאות. ManageWP מאפשר להגדיר אילו פעולות מותרות לכל חיבור –
לא כל אתר צריך הרשאות התקנת plugins מרחוק. הגבילו לפי מה שאתם בפועל משתמשים בו.
הפעילו Two-Factor Authentication על חשבון ManageWP עצמו – לא רק על ה-WordPress. זה הchoke point.
נטרו IP-ים. ManageWP מגיע מ-IP ranges מוכרים. כניסה מ-IP אחר היא red flag.
בדקו את ה-Worker plugin. אם אתם לא משתמשים ב-ManageWP באופן פעיל, הסירו את ה-Worker plugin.
הוא לא צריך להיות מותקן על אתרים שלא נמצאים תחת ניהול פעיל.
לסוכנויות ומפתחים שמנהלים אתרי לקוחות
חשבון ManageWP אחד = attack surface עבור כל האתרים תחתיו. אם החשבון נפרץ, כל האתרים שמחוברים אליו נמצאים בסיכון.
כדאי לשקול הפרדה בין לקוחות, לא לצבור הכל תחת credentials אחד.
רוטציה תקופתית של connection tokens. ה-token שמקשר בין ManageWP ל-Worker plugin הוא נפרד מסיסמת ה-WordPress –
רוטציה שלו מנתקת גישה שנפרצה גם אם הסיסמה כבר שונתה.
הלקח הרחב יותר
ManageWP הוא דוגמה אחת לקטגוריה שלמה: trusted tools as attack vectors.
כלי ניהול, גיבוי, ניטור – כולם מקבלים הרשאות גבוהות כי זה מה שהם צריכים כדי לעשות את עבודתם.
וכולם הופכים לווקטור תקיפה ברגע שה-credentials שלהם נפרצים.
ה-WAF לא יעצור את זה. ה-IDS לא יזהה את זה. ModSecurity לא יחסום API call לגיטימי.
מה שעוצר את זה הוא שילוב של: הרשאות מינימליות, MFA על כל כלי ניהול, ניטור שמחפש דפוסי התנהגות חריגים – לא רק חתימות ידועות –
ומי שיודע לזהות את ההבדל בין פעילות ניהול לגיטימית לבין אחת שנראית לגיטימית אבל לא.
צוות אבטחת המידע – SPD Hostingsecurity@spd.co.il
