פרצת אבטחה ב-PHP מסכנת מיליוני אתרים: איך תדעו אם גם השרת שלכם חשוף ומה עושים עכשיו?

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

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

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

לדברי קיריל גלפנד, אוונגליסט AI ואדריכל פתרונות אבטחה בכיר ב-TrendAI, חומרת האירוע באה לידי ביטוי גם בתגובת הרשויות בעולם. בהולנד הושבתו שירותים ממשלתיים, בפינלנד הורדו שירותים ממשלתיים מהרשת, וה-FBI פרסם אזהרה דחופה. גם מערך הסייבר הלאומי בישראל המליץ לארגונים לבדוק את המערכות ולעדכן אותן, ובמקרים מסוימים לשקול ניתוק שרתים מהאינטרנט.

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

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

הגרסאות המתוקנות הן 8.2.35, 8.3.36, 8.4.27  ו-8.5.12. גרסאות ישנות יותר דורשות בדיקה, ובמיוחד PHP 8.1  ומטה, שכבר אינן מקבלות עדכוני אבטחה רשמיים. עם זאת, בחלק ממערכות ההפעלה התיקון עשוי להיכלל גם בגרסה שמספרה לא השתנה, ולכן חשוב לוודא מול הספק שהמערכת מוגנת.

מה ארגונים צריכים לעשות עכשיו? גלפנד ממליץ על כמה צעדים מרכזיים:

1. לאתר את כל המערכות המשתמשות ב-PHP, לרבות אתרי אינטרנט, מערכות פנימיות, סביבות פיתוח ומוצרים של ספקים חיצוניים.
2. לתעדף מערכות החשופות לאינטרנט, במיוחד כאלה המכילות מידע על לקוחות, פרטי תשלום או ממשקי ניהול.
3. להתקין את עדכוני האבטחה ולוודא שהשרתים והשירותים הופעלו מחדש כדי שהתיקון ייכנס לתוקף.
4. לבדוק מול ספקים. אם המערכת מנוהלת בידי ספק אחסון או שירות חיצוני, יש לקבל אישור מפורש שהתיקון הותקן.
5. לבודד מערכות שלא ניתן לעדכן ולהגביל את הגישה אליהן ובמידת הצורך לנתק אותן מהאינטרנט, עד למציאת פתרון.
6. לבדוק אם כבר התרחשה חדירה – לחפש פעילות חריגה, קבצים חשודים ושינויים בלתי מוסברים במערכות.

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

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

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

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