ארון שרתים בחדר חשוך המסמל פגיעות בהרצת פקודות מרחוק
צילום: Tyler / Unsplash

CVE‑2026‑122193: דוגמת ההתקנה של AWS REX אפשרה לעקוף את ארגז החול

AWS פרסמה ב־6 בנובמבר 2026 התראת אבטחה בדרגת Important על CVE‑2026‑122193, פגיעות הזרקת פקודות בדוגמת ההתקנה של Trusted Remote Execution (REX). הפגיעות אינה נמצאת בארטיפקט תוכנה של REX שהופץ, אלא בסקריפט לדוגמה שהיה בתיעוד ההקמה ויצר מסמכי AWS Systems Manager בשם Rex-RO ו־Rex-RW.

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

מה השתבש?

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

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

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

מי מושפע?

לפי ההתראה הרשמית, כל מי שיצר את מסמכי Rex-RO או Rex-RW באמצעות דוגמת ההקמה הישנה נחשב מושפע. מי שלא הריץ את הדוגמה ולא יצר את המסמכים אינו מושפע מהבעיה המתוארת בהתראה.

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

צעדי תגובה מומלצים

  1. בצעו מלאי בכל הארגון: חפשו מסמכי SSM מותאמים אישית בשם Rex-RO ו־Rex-RW בכל החשבונות והאזורים, ולא רק בחשבון המרכזי.
  2. מחקו את המסמכים שנוצרו מהדוגמה: זהו צעד התיקון ש־AWS מפרסמת. ודאו שהמחיקה הצליחה בכל Region.
  3. בדקו מי יכול היה להפעיל אותם: עברו על מדיניות IAM, קבוצות והרשאות אוטומציה שהעניקו גישה למסמכים.
  4. סקרו היסטוריית הפעלה: חפשו ב־CloudTrail וביומני Systems Manager הפעלות של המסמכים, פרמטרים חריגים והתנהגות בלתי צפויה במופעים המנוהלים.
  5. בדקו את המופעים עצמם: אם נמצא שימוש חשוד, בחנו תהליכים, קבצים, משתמשים ושינויים בתצורה בהתאם לנוהל התגובה לאירועים של הארגון.
  6. אל תעתיקו מחדש את הדוגמה הישנה: אם יש צורך ב־REX, הסתמכו רק על התיעוד הנוכחי ובצעו סקירת אבטחה עצמאית למסמכי SSM ולבניית פקודות.

לקח רחב יותר: דוגמאות תיעוד הן קוד ייצור

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

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

מקורות

דילוג לתוכן