בודקים את וורדפרס? התחילו עם התוספים שלכם

סיכום

רוב ביקורות האבטחה של וורדפרס הפוכות: הן שמות דגש על עדכוני ליבה ודוחות סורק, בעוד שהפגיעויות שבאמת פוגעות נמצאות בתוספים. מאמר לבן של SANS מצא שיותר מ-96% מהפגיעויות במערכת האקולוגית מקורן בתוספים של צד שלישי, וכ-43% מהן אינן דורשות אימות. מאמר זה עובר על ביקורת ממוקדת תוספים עבור צוות שיווק פנים-ארגוני קטן, תוך שימוש בסיפור של אתר שנפרץ כי כולם סרקו את השכבה הלא נכונה. תלמדו למפות ולסווג כל תוסף, לבדוק משטחי תקיפה ללא אימות, לסקור ידנית משתמשים ולוגים, ולתרגם ממצאים לשפת סיכון שהבוס הלא-טכני מבין. התוצאה היא טקס טריאז' רבעוני במקום תרגיל של סימון וי.

רוב ביקורות האבטחה של וורדפרס הן תיאטרון. אתה מבלה אחר הצהריים בעדכון הליבה, החלפת סיסמת מנהל, והרצת סורק תוספים שמדווח בגאווה 'אין בעיות קריטיות'. בינתיים, התוסף שקיבל העלאות קבצים ועודכן לאחרונה לפני שלוש שנים יושב בשקט בתיקיית ההעלאות שלך, ומחכה למישהו שלא ברשימת האורחים.

המספרים תומכים בכך. מאמר לבן של SANS על סריקת תוספי וורדפרס מצא שיותר מ-96% מהפגיעויות במערכת האקולוגית של וורדפרס מקורן בתוספים של צד שלישי, עם ערכות נושא ב-4% והליבה מתחת ל-1%. כ-43% מהפגמים הללו ניתנים לניצול ללא כל אימות. אז כשהביקורת שלך משקיעה את רוב המאמצים בליבה, אתה בוחן את העצים בעוד שריפת יער מתחילה בתיקיית התוספים השכנה.

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

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

אתה נמצא בצוות שיווק קטן עם אתר וורדפרס שפועל מאז 2017. יש בו תוסף מותאם אישית לרישום לאירועים שפרילנסר בנה ב-2019, תוסף טופס יצירת קשר עם שדה העלאת קבצים, ותוסף סליידר שנמכר ואין לו עוד דף עדכונים ציבורי. זה לא מחסנית יוצאת דופן. כאן הביקורת שלך מתחילה.

---

מלאי התוספים הוא מדיניות האבטחה שלך

ערכו מלאי של כל תוסף וערכת נושא. רשמו את הגרסה, תאריך העדכון האחרון, האם הספק עדיין פעיל, והאם מישהו באמת משתמש בו. ואז סווגו כל אחד לדלי: מתוחזק ובשימוש, מתוחזק ולא בשימוש, נטוש אך בשימוש, נטוש ולא בשימוש. הסירו את אלו שאינם בשימוש מיד. התעלמו מההגנה 'זה רק 50 דולר לחודש' — תוסף שאינו בשימוש הוא התחייבות, לא תכונה. עבור אלו שנטושים אך בשימוש, החליטו: החליפו אותו, או קבלו את הסיכון וכתבו אותו ברשימת סיכונים שהבוס שלכם ראה.

תוסף רישום האירועים נכנס לדלי של נטוש אך בשימוש. הוא מקבל תשלומים ושולח אימיילי אישור, והחלפתו היא פרויקט, אז אתה שומר אותו לעת עתה. אבל אתה רושם הערה שאומרת, 'זהו המקור הסביר ביותר לפרצה עתידית', ומוסיף אותו לראש רשימת הבדיקות.

משטח תקיפה	אחוז מהפגיעויות הידועות של וורדפרס	עדיפות ביקורת
תוספים של צד שלישי	מעל 96%	גבוהה ביותר — מלאי, סריקה, בדיקה, החלפה
ערכות נושא	כ-4%	בינונית — רק אם מותאמת אישית או מיושנת
ליבת וורדפרס	מתחת ל-1%	נמוכה — שמרו מעודכן, המשיכו הלאה

כאשר SecurityWeek מנתה יותר מ-8,000 פגיעויות וורדפרס חדשות ב-2024, הרוב המכריע היה מהסוג הזה: בעיות תוספים, לא תיקוני ליבה. סורק יגיד לך על אלו שנחשפו וקיבלו CVE. הוא לא יגיד לך על קוד הפרילנסר המותאם אישית ללא CVE, כי אף אחד מעולם לא בדק אותו בקפידה. המבט הידני הזה הוא העבודה שלך. להדרכה מעמיקה יותר של בדיקות ספציפיות לתוספים, ראו את המדריך הזה לביקורת תוספי הוורדפרס שלכם לאיתור פגיעויות.

---

בדקו אותו כמו זר: ה-43% שלא צריכים סיסמה

הסורק שלך כבר אמר לך שהכל בסדר. עכשיו עשה מה שהוא לא יכול: חקור את האתר מבחוץ, ללא התחברות. התחל עם כל שדה העלאת קבצים, כל טופס שמעבד POST, כל נקודת קצה של admin-ajax. האם ההעלאה באמת בודקת את תוכן הקובץ, או רק את הסיומת? לאן נוחתים הקבצים שהועלו, והאם שרת האינטרנט יכול להריץ PHP בתיקייה ההיא? 43% מתקלות התוספים שאינן דורשות אימות יושבות בדרך כלל בדיוק במקומות האלה: XSS מאוחסן ללא אימות, העלאת קבצים שרירותית, והזרקת אובייקטים PHP.

תוסף טופס יצירת הקשר מאפשר למבקרים לצרף קובץ קורות חיים. הוא משנה את שם הקובץ לשם המקורי של המבקר, אז אתה מעלה 'resume.php' והוא נשמר בתיקיית /uploads/contact/ שכתיבה אליה מותרת בתכנון. אם השרת גם מאפשר להריץ PHP בתיקייה ההיא, התוקף קיבל webshell. Fastly תיעדה ניצול פעיל של XSS מאוחסן ללא אימות בתוספי וורדפרס — זה לא סיכון שולי של מצגת. הבדיקה שלך פשוטה: צור קובץ עם תוכן ידוע, העלה אותו, וראה אם הוא חוזר עם השם והסוג המקוריים. ואז נסה להעלות קובץ .php. אם הוא חוזר כ-.php, בדיוק מצאת חור שניתן לניצול.

כאן גם הטיעון 'אבל לתוסף האבטחה שלנו יש WAF' קורס. WAF יכול לחסום מטען ידוע, אבל כללי הנורמליזציה של נתיבים שעליהם הוא מסתמך מתפצלים לעתים קרובות ממה שהשרת בפועל עושה. מדריך הבדיקות לאבטחת אינטרנט של OWASP הוא התייחסות טובה יותר מכל לוח מחוונים: הוא מתאר כיצד לבדוק פגמי העלאת קבצים ו-XSS מאוחסן בצורה מתודית. ואם אתה מגלה שהתוסף נטוש, הגיע הזמן ליישם את פרוטוקול הניקוי: הסכנה הנסתרת של תוספי וורדפרס נטושים מסביר למה השארת תוסף מת במקום גרועה יותר מהסרתו והתאמת זרימת העבודה.

---

מה שהסורק לא רואה: משתמשים, לוגים וקוד ישן

בדיקות דינמיות תופסות את מה שחשוף כרגע. הבדיקה הידנית תופסת את מה שכבר נמצא בפנים. התחל עם חשבונות משתמש: פתח את רשימת המנהלים וחפש חשבונות שלא אתה יצרת. מנהל בשם 'support' עם כתובת דואר חינם וללא אדם מאחוריו הוא דלת אחורית, לא עמית. בדוק חותמות זמן של קבצים ב-wp-content/uploads עבור כל דבר ששונה לאחרונה שאינו התוכן שלך. בדוק את לוג הגישה של השרת עבור בקשות שנראות כמו פקודת curl של בוט ולא כמו דפדפן של אדם.

לתוסף האירועים יש העלאת 'תמונת דובר' שנשמרת בתיקיית uploads/event-headshots/. במהלך הבדיקה אתה מוצא קובץ שאינו שלך — קובץ PHP קטן עם שם אקראי למראה. זה ה-webshell שלך. הוא הגיע לשם דרך אותה פגיעות העלאה שבדקת לפני שבועיים, ועדיין סורק לא 'יראה' אותו כי זה לא פגיעות תוסף; זה עדות לאחת. הבדיקה הידנית מוצאת אותו, מוחקת אותו, ובודקת בלוג את כתובת ה-IP שהניחה אותו שם. Invicti ציינה שהזרקת אובייקטים PHP בתוספים נמצאת במגמת עלייה, וזה כמעט בלתי נראה לסריקות black-box כיוון שהאובייקט הזדוני מתממש רק בזמן ביצוע. הדרך היחידה לזהות אותו היא לקרוא קוד עבור תבניות מסוכנות כמו קריאה ל-unserialize() על קלט שמגיע מהמשתמש. קריאת כמה מאות שורות של התוסף המותאם אישית זולה יותר מתשלום עבור retainers של תגובה לאירוע.

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

---

לספר לבוס את האמת בלי לעורר פאניקה

הבוס שלך לא מתעניין בציוני CVSS או בהזרקת אובייקטים PHP. הוא מתעניין באתר שנופל, בחנות שלא מקבלת הזמנות, ובתקציב ה-IT. התרגום פשוט: 'לתוסף הזה יש פרצת ביצוע קוד מרחוק ללא אימות. זר יכול למחוק את תוכן האתר שלנו או להתקין דלת אחורית. אנחנו צריכים להחליף אותו ברבעון הזה.' ואז הצג את רשימת העדיפויות: החלף את תוסף האירועים, השבת את העלאת הקבצים של טופס יצירת הקשר עד שיאמת כראוי סוגי קבצים, סובב את כל פרטי הכניסה של המנהלים, ותזמן את הבדיקה הרבעונית הבאה.

יש לך גם יתרון שפה: CISA מנהלת את הקטלוג של פגיעויות מנוצלות ידועות, שאומר לך בדיוק אילו פרצות שפורסמו נמצאות בשימוש פעיל בשטח. אם אחד מהתוספים שלך מופיע שם, הטיעון כבר לא תיאורטי — קיים ניצול ידוע, והשעון מתקתק. אם לא, השתמש בו בכל מקרה כסטנדרט למה פירוש 'דחוף'. המעקב של CISA מקל עליך לשכנע בוס לא-טכני שזה לא אימייל פישינג; זה מאגר ציבורי של מה שתוקפים עושים כרגע. כשהרבעון מסתיים, תהיה לך זרימת עבודה לתיקון, לא תרגיל חד-פעמי של סימון וי. זרימת עבודה להפיכת פגיעויות למחזור תיקונים שומרת על ההרגל חי.

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