PHP2Shell: שתי פרצות קריטיות ב-PHP דלפו לפני שהתיקון יצא – והן יושבות בלב האתר שלכם

הקדמה: כשהסוד יוצא לפני הפלסטר

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

הפעם זה לא עבד. ב-20 באוקטובר הופיע בפורום Hacker News פוסט (שנמחק מאז) שחשף ששתי פרצות RCE קריטיות ב-PHP עומדות להתפרסם. תוך שעות חברת המחקר watchTowr אישרה בפומבי שהפרצות אמיתיות, ובמקביל הסתובב ברשת צילום מסך של כלי תקיפה בשם PHP2Shell. התוצאה: כולם יודעים שיש בעיה, אבל אין עדיין תיקון.

אז מה זה אומר עליכם, ומה עושים עכשיו? בואו נעשה סדר.

מה בדיוק קרה? ציר הזמן

• 20 באוקטובר, אחר הצהריים: פוסט ב-Hacker News מדווח על שתי פרצות RCE ב-PHP, עם מזהי CVE ודירוג 10.0, שאמורות להתפרסם ב-22 באוקטובר.
• 20 באוקטובר: watchTowr מאשרת שהפרצות אמיתיות ומדווחת שהצליחה לשחזר את אחת מהן. היא לא משחררת פרטים טכניים עד שיהיה תיקון.
• 20 באוקטובר: צוות האבטחה של PHP מפרסם הודעה מוקדמת על עדכון אבטחה קריטי, ומשאיר לעצמו את הזכות לשחרר אותו מוקדם יותר אם הפרטים ידלפו או אם יתגלה ניצול בשטח.
• 21 באוקטובר, 14:00 UTC (17:00 בישראל): מועד שחרור העדכון הרשמי, יחד עם הפרטים הטכניים ורשימת הגרסאות המושפעות והמתוקנות.

מה ידוע, ומה עדיין לא

בימים כאלה מסתובבים ברשת הרבה מספרים ושמועות. חשוב להפריד בין מה שאושר רשמית למה שרק דווח:

מי בסיכון?

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

• וורדפרס, כולל אתרים שבנויים באלמנטור
• חנויות WooCommerce
• חנויות Magento ו-Adobe Commerce
• Joomla, Drupal, Laravel ומערכות PHP אחרות
• אתרים ומערכות שנכתבו בהתאמה אישית ב-PHP

החלק הפחות נעים: אתרים שעדיין רצים על גרסאות PHP ישנות (8.1, 8.0, 7.4 ומטה) כנראה לא יקבלו תיקון רשמי בכלל, כי הגרסאות האלה כבר מחוץ לתמיכה של צוות PHP. אצלם הפתרון האמיתי הוא שדרוג גרסת PHP, או תיקון שחברת האחסון או ספק מערכת ההפעלה יחילו בעצמם (Backport).

למה כל שעה חשובה כאן

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

במילים אחרות: המרוץ מתחיל ב-17:00. מי שמעדכן מהר נשאר מחוץ לתמונה. מי שמחכה לסוף השבוע עלול לגלות שמישהו כבר הספיק לשתול קוד באתר שלו.

מה עושים עכשיו? מדריך לבעלי אתרים

1. בדקו על איזו גרסת PHP האתר שלכם רץ. בוורדפרס: כלים ← בריאות האתר ← מידע ← שרת. אם אתם רואים גרסה נמוכה מ-8.2, זה הזמן לתכנן שדרוג.
2. ודאו שהתוספים והתבנית תומכים בגרסה חדשה. לפני מעבר גרסת PHP, עדכנו את וורדפרס, את התוספים ואת התבנית, ובדקו שהם תומכים בגרסה החדשה. מומלץ לבדוק קודם על אתר Staging.
3. שאלו את חברת האחסון מה התוכנית. השאלות הנכונות: מתי יותקן התיקון על השרתים? האם יש תיקון גם לגרסאות PHP ישנות? האם יש WAF שחוסם ניסיונות ניצול בזמן הביניים?
4. ודאו שיש לכם גיבוי עדכני. גיבוי שנשמר מחוץ לשרת, ושבדקתם שאפשר לשחזר ממנו.
5. שימו לב לסימני פריצה בימים הקרובים. קבצים חדשים שלא העליתם, משתמשי מנהל לא מוכרים, הפניות מוזרות או אזהרות מגוגל. כתבנו על זה בהרחבה במאמר "7 סימנים שהאתר שלכם נפרץ (בלי שידעתם)".

ולמנהלי שרתים: הצ'קליסט הטכני

1. מיפוי לפני השחרור. בשרתי אחסון משותף רצות בדרך כלל כמה גרסאות PHP במקביל (alt-php ב-CloudLinux, ea-php ב-cPanel, CustomBuild ב-DirectAdmin). צריך למפות את כולן, לא רק את ברירת המחדל:

# כל גרסאות ה-PHP המותקנות בשרת
ls -d /opt/alt/php*/ /opt/cpanel/ea-php*/ /usr/local/php*/ 2>/dev/null
rpm -qa | grep -Ei '^(alt-php|ea-php|php)[0-9]*-(cli|common)' | sort

# גרסת ברירת המחדל
php -v

2. מקור העדכון. ברוב השרתים התיקון יגיע דרך חבילות של הספק (CloudLinux, cPanel, DirectAdmin, AppStream או Remi בהפצות RHEL), ולא ישירות מ-php.net. עקבו אחרי ערוצי העדכונים של כל ספק.

3. אחרי ההתקנה: לאתחל את השירותים. עדכון חבילה לא מחליף קוד שכבר טעון בזיכרון. יש לאתחל PHP-FPM, LSAPI או את שרת הווב, ולוודא את הגרסה דרך php -v וגם דרך דף phpinfo() שמוגש מהשרת עצמו.

4. צמצום חשיפה בזמן הביניים. CERT-EU ממליץ לבודד אפליקציות PHP שחשופות לאינטרנט במקרים שבהם אי אפשר לעדכן מיד. חוקי WAF (למשל ב-Cloudflare) יכולים לעזור, אבל הם לא תחליף לעדכון עצמו.

5. ציד אחרי העדכון. חפשו קבצי PHP חדשים או שהשתנו בתיקיות העלאה ובתיקיות שניתנות לכתיבה, תהליכים חריגים שרצים תחת משתמשי האחסון, וחיבורים יוצאים לא צפויים. במיוחד בשרתים של חנויות Magento ו-WooCommerce, שצפויות להיות בין המטרות הראשונות.

מה אנחנו עושים ב-SPD

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

לקוחות שהאתר שלהם רץ על PHP 8.1 ומטה יקבלו מאיתנו פנייה ישירה. אם יש לכם שאלה או שאתם רוצים שנבדוק את האתר שלכם עכשיו, דברו עם התמיכה שלנו.

לסיכום

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