ב-ProjectSend בגרסאות שלפני r1720, מי ששלח פניות HTTP בנויות במיוחד אל הקובץ options.php יכול היה לשנות את הגדרות היישום בלי להזדהות כלל. הציון הוא 9.8 מתוך 10. לפי הרשומה, משם הדרך פתוחה לפתוח חשבונות, להעלות webshell ולהטמיע JavaScript זדוני.

מה החולשה?

options.php הוא המסלול שבו נשמרות הגדרות היישום. מסלול כזה הוא מהדברים הרגישים ביותר בכל יישום web, והכלל לגביו פשוט: לפני שמשנים הגדרה, היישום בודק שמי שמבקש הוא מנהל שהזדהה. כאן הבדיקה הזאת לא התקיימה, ופנייה שהגיעה מהרשת שינתה הגדרות כאילו באה ממנהל. ברשומה זה מסומן CWE-306, היעדר אימות לפעולה קריטית.

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

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

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

מי מושפע?

כל מי שמריץ ProjectSend בגרסה שלפני r1720. מדובר בתוכנה שמותקנת על שרת של המשתמש עצמו, והקוד שלה מתוחזק בפומבי ב-GitHub, שם נמצא גם העדכון שסוגר את החולשה.

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

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

האם מנוצלת בפועל?

כן. ב-3 בדצמבר 2024 נכנסה החולשה לקטלוג ה-KEV של סוכנות הסייבר האמריקאית CISA, שמרכז את החולשות שידוע כי תוקפים משתמשים בהן, עם מועד יעד לטיפול בגופים הפדרליים ב-24 בדצמבר 2024.

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

מה עושים?

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

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

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

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