פירצת ViewState Deserialization ב-KnowledgeDeliver: הדרך לשליטה מרחוק
פתיחה
נדמיין לרגע שאתם שוכרים דירה, ומקבלים מפתח כניסה. עכשיו דמיינו שקבוצת חברים שלכם, ששכרו דירות אחרות באותו בניין, גילו שכולם קיבלו העתק של אותו מפתח “מאסטר” שיכול לפתוח את כל הדירות בבניין. נשמע כמו סיוט אבטחתי, נכון? בדיוק תרחיש כזה, ורבים אחרים, מתרחש כאשר ארגונים משתמשים במערכות עם סודות משותפים – וכפי שחשף לאחרונה מחקר של Mandiant ו-Google, זה בדיוק מה שקרה עם פירצת Zero-Day חמורה במערכת ניהול הלמידה KnowledgeDeliver, המנוצלת באופן פעיל.
רקע
מערכת KnowledgeDeliver, פתרון Learning Management System (LMS) שפותח על ידי Digital Knowledge ופופולרי ביפן, הפכה לאחרונה למטרה למתקפות Remote Code Execution (RCE) קריטיות. פירצה זו, המזוהה כ-CVE-2026-5426, נוצלה כ-Zero-Day, כלומר, עוד לפני שהיצרן או הקהילה היו מודעים לקיומה.
לב ליבה של הפירצה טמון בשימוש שגוי במנגנון ה-ViewState של ASP.NET ובאופן שבו הוא מאובטח. למי שלא מכיר, ASP.NET ViewState הוא מנגנון שמאפשר ליישום אינטרנט לשמור את מצב (State) הדף בין בקשות HTTP שונות (Postbacks) מהלקוח לשרת. זהו קובץ נסתר המוטבע בתוך טופס ה-HTML. כדי להבטיח את שלמותו וסודיותו, ה-ViewState בדרך כלל מוצפן ונחתם באמצעות מפתח קריפטוגרפי ייחודי המכונה machineKey. ה-machineKey הוא סוד שרת קריטי המשמש את מסגרת ה-ASP.NET להצפנה ואימות של נתונים, כולל כמובן את ה-ViewState.
הבעיה במקרה של KnowledgeDeliver הייתה קונפיגורציה לקויה: התקנות רבות של המערכת, שבוצעו לפני 24 בפברואר 2026, השתמשו בקובץ web.config סטנדרטי שסופק על ידי הספק, אשר הכיל ערכי machineKey קודשים (hardcoded) וזהים בכל ההתקנות. כתוצאה מכך, ברגע שתוקף השיג את ה-machineKey מהתקנה אחת (או על ידי הינדוס לאחור של הקוד), הוא יכול לנצל אותו כדי לפרוץ לכל התקנה אחרת של KnowledgeDeliver החשופה לאינטרנט.
עומק טכני
כיצד מתבצע הניצול? כאשר ה-machineKey ידוע, תוקף יכול לבנות באופן זדוני מטען (payload) עבור ה-ViewState. מטען זה מכיל קוד שברצוננו שהשרת יריץ. כשהשרת מקבל בקשת HTTP עם פרמטר __VIEWSTATE המכיל את המטען הזדוני, הוא מנסה לבצע לו Deserialization (שחזור אובייקט מהזרם הבינארי שלו). מכיוון שלתוקף יש את ה-machineKey הנכון, השרת מאמת בהצלחה את חתימת ה-ViewState (מבלי לדעת שהוא זדוני), ומנסה לבצע Deserialization של האובייקט. אם המטען הזדוני בנוי כהלכה, תהליך ה-Deserialization יכול להוביל להרצת קוד מרחוק (RCE) על השרת.
זוהי טכניקה ידועה היטב, שדווחה בעבר במערכות ASP.NET אחרות, כולל Sitecore. לאחר ה-RCE הראשוני, התוקפים במקרה זה השתמשו בטכניקות נוספות כדי לבסס את שליטתם:
- פריסת Web Shell בזיכרון (In-Memory Web Shell): התוקפים פרסו כלי בשם BLUEBEAM (הידוע גם כ-Godzilla), שהוא Web Shell מבוסס .NET הפועל כולו בזיכרון תהליך ה-IIS Worker Process (w3wp.exe). מכיוון שאין לו קבצים פיזיים על הדיסק, הוא קשה מאוד לזיהוי באמצעות סריקות מסורתיות. Web Shell זה מאפשר לתוקפים להריץ פקודות נוספות ולטעון מטענים על ידי שליחת נתונים מוצפנים בבקשות HTTP POST.
- שינוי קבצים: התוקפים שינו הרשאות קבצים (באמצעות
icacls) והוסיפו קוד זדוני לקבצי JavaScript של האפליקציה. קוד זה יצר התראות אבטחה מזויפות במטרה לגרום למשתמשים להוריד ולהתקין “תוסף אימות אבטחה” (security authentication plugin) וטען סקריפטים זדוניים מרחוק. - הדבקת תחנות קצה עם Cobalt Strike: הסקריפט הזדוני הפיץ התקנה מזויפת שהובילה להדבקת תחנות קצה של משתמשים ב-Cobalt Strike BEACON. זהו כלי פוסט-אקספלויטציה נפוץ המאפשר שליטה מלאה בתחנת הקצה הנגועה. המטען היה מוצפן במפתח ספציפי לארגון המותקף, מה שמעיד על מתקפה ממוקדת.
דוגמאות / קוד
למרות שלא נפרסם קוד ניצול מלא מטעמים אתיים, נציג דוגמה תיאורטית לקובץ web.config פגיע וכיצד נראה פרמטר __VIEWSTATE במצב רגיל מול מצב פוטנציאלי לניצול.
קובץ web.config פגיע היה נראה כך:
<configuration>
<system.web>
<machineKey decryptionKey="YOUR_HARDCODED_DECRYPTION_KEY_HERE"
validationKey="YOUR_HARDCODED_VALIDATION_KEY_HERE" />
<!-- ... other configurations ... -->
</system.web>
</configuration>
הנוכחות של machineKey עם ערכים קודשים (במקום שיוצרו באופן דינמי וייחודי) היא שורש הבעיה.
דוגמה לפרמטר __VIEWSTATE בבקשת HTTP רגילה:
POST /default.aspx HTTP/1.1
Host: vulnerable-lms.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 1234
__VIEWSTATE=LONG_BASE64_ENCODED_VIEWSTATE_DATA&__EVENTVALIDATION=...&username=test&password=password
תוקף יכול להחליף את LONG_BASE64_ENCODED_VIEWSTATE_DATA במטען זדוני שנוצר באמצעות ה-machineKey הידוע, ובכך להריץ קוד על השרת. קיימים כלים כמו ysoserial.net המאפשרים יצירת מטעני Deserialization עבור סביבות .NET.
יצירת machineKey חדש באמצעות PowerShell
ניתן ליצור machineKey חדש באמצעות PowerShell:
[System.Web.Security.MachineKey]::GenerateValidationKey([System.Web.Security.MachineKeyValidation].[SHA1], 64)
[System.Web.Security.MachineKey]::GenerateDecryptionKey([System.Web.Security.EncryptionMethod].[AES], 32)
ולעדכן את web.config עם הערכים שיוצרו:
<machineKey validationKey="[תוצאה מקודם]" decryptionKey="[תוצאה מקודם]" />
המלצות ומסקנות
פירצת KnowledgeDeliver היא תזכורת חדה לחשיבות האבטחה היסודית וניהול סודות נכון:
- החלפת מפתחות
machineKey: באופן מיידי, יש לוודא שכל התקנת KnowledgeDeliver (וכל יישום ASP.NET אחר) משתמשת ב-machineKeyייחודי וחזק מבחינה קריפטוגרפית. ניתן ליצור מפתחות אלו באופן אקראי ולהכניסם לקובץweb.configאו לאבטח אותם באמצעות מערכת ניהול מפתחות מתאימה. זו הדרך היחידה לבטל את תוקף הסוד המשותף. - הגבלת גישה: במידת האפשר, הגבילו את הגישה למערכות LMS לטווחי כתובות IP ידועים של הארגון בלבד. זה מקטין את שטח התקיפה.
- ניטור ובדיקות:
- יומני אירועים של היישום: נטרו את יומני אירועי Windows (Event ID 1316) עבור אירועים מהמקור
ASP.NET 4.0.30319.0(או דומה), במיוחד כאלה המצביעים עלViewstate verification failed(עם “Integrity Failure” או “Viewstate was invalid” לאחר מעבר בדיקת Integrity). - פעילות תהליכים חשודה: נטרו תהליכי ילד חריגים המופעלים על ידי
w3wp.exe(תהליך ה-IIS). חפשו פקודות כמוcmd.exe /c ...,whoami,powershell.exe. - ניטור שלמות קבצים (File Integrity Monitoring - FIM): יש לנטר שינויים בלתי מורשים בקבצי
.js,.aspxאו.configבספריית השורש של היישום (web root). - מחרוזות User-Agent אנומליות: חפשו ביומני גישת ה-Web מחרוזות User-Agent חריגות, כפי שתוארו במחקר של Mandiant, המורכבות ממזהים משורשרים.
- יומני אירועים של היישום: נטרו את יומני אירועי Windows (Event ID 1316) עבור אירועים מהמקור
- עדכון תוכנה: ודאו שכל מערכות KnowledgeDeliver מעודכנות לגרסאות המתוקנות, שבהן מפתחות ה-
machineKeyנוצרים באופן ייחודי.
ניצול פרצות כמו ViewState Deserialization מדגיש את החשיבות הקריטית של אבטחת קונפיגורציה וניהול סודות נכון. בעולם מורכב של מערכות מקושרות, טעות קטנה אחת יכולה להפוך לשער פתוח עבור תוקפים.
משאבים
- CVE-2026-5426: ניתן למצוא פרטים נוספים במאגרי CVE הרשמיים.
- Mandiant / Google Blog Post: לניתוח המלא של Mandiant ו-Google, חפשו את הבלוג שלהם.
תגובות