ברירת מחדל של AWS Organizations ואפשרויות תקיפה
באבטחת מידע, תצורת ברירת מחדל עלולה להיות כשל אבטחתי ולהוביל לבעיות, פערים וחשיפות אבטחה קריטיות. לעיתים, מדובר על תצורה שאין לנו מודעות אליה, ובפרט לרמת הקריטיות שלה.
החלק המעניין הוא שישנם עדיין כלי אבטחה שאינם מזהים פערים ובעיות אבטחה בתצורות ברירת מחדל, למשל, כלים בקטגוריה של נראות, בקרה והגנה על הענן, כלים המוכרים בקטגוריה של CSCM/CWPP/CNAPP.
חשוב להדגיש כי תצורת ברירת מחדל אינה מיסקונפיגורציה, אלא תצורה שפותחה ונבנתה ע”י הוונדור באופן מסוים וללא ראיית אבטחה. ספקי ענן ובפרט ספקי אבטחה עדיין ממשיכים להוציא כלים, אפשרויות ותכונות עם ברירת מחדל שמכילות פערים ובעיות אבטחה.
המאמר הינו חלק מסדרת מאמרים של איך לתקוף את הענן, האפשרויות המגוונות בשלבי התקיפה, דרכי כניסה, כלים, תובנות וטיפים מהיומיום. חלק מהמאמרים בסדרה הינם מאמרים קצרים, וחלקם צוללים אל שרשרת התקיפה ומאפשרים להבין איך לתקוף, להגן, לתחקר ולחקור את בעיות האבטחה בענן. המאמר הנוכחי מתמקד בתצורת ברירת המחדל של AWS Organizations ובסיכון של חשבון מנוהל.
הקדמה
סביבות AWS רבות בין אם זה סביבות קטנות או גדלות במיוחד מתבססות על ארכיטקטורה של ריבוי חשבונות (Multi-Account). תצורה ומימוש של ריבוי חשבונות מציעה מספר יתרונות, ובמקרים מסוימים אף נחשבת לשיטת עבודה ותצורה מומלצת. בכדי לסייע בבניית ארכיטקטורה נכונה ובניהול חשבונות מציעה AWS את האפשרות של AWS Organizations.
AWS Organizations הוא שירות ניהול חשבונות המאפשר לאחד חשבונות AWS מרובים ומשם מאפשר ניהול מרוכז (יצירה, ביזור ועוד). AWS Organizations כולל ניהול חשבונות המאפשרות מענה על דרישות של תשתית, פיתוח ואבטחה. עוד על What is AWS Organizations?.
תכונות ויתרונות
- ניהול מרכזי של כל חשבונות AWS
- ניהול היררכי של החשבונות באמצעות יחידות OU
- מדיניות ושליטה בשירותי AWS ובפעולות API שכל חשבון יכול לגשת אליהן
- מדיניות תגיות בכל המשאבים בחשבונות
- מדיניות לשליטה באופן שבו שירותי AI ולמידת מכונה יכולים לאסוף ולאחסן נתונים
- מדיניות גיבויים אוטומטיים עבור המשאבים בחשבונות
- תמיכה עבור ניהול זהויות וגישה (IAM)
- הפעלת משימות ושירותי AWS
טיפ: בשל מיקומם של סביבות AWS, חשוב שבודקי אבטחה וצוותים אדומים יכירו את תצורת ברירת המחדל של AWS Organizations.
כאשר יוצרים חשבון AWS נוצר אובייקט ניהול של החשבון ומשוייך אל AWS Organization, באותו רגע הוא הופך להיות חשבון הניהול באותו Organization. באופן כללי בכל Organization יש לפחות חשבון ניהול אחד, וחשבון זה למעשה הבעלים.
חשבונות ותפקידים
כאשר נוצר חשבון ב AWS Organizations הוא מקבל Memebership ומתויג כ member account. כחלק מתהליך יצירת חשבון זה, AWS Organization מקושר לתפקיד (Role) שנקראה OrganizationAccountAccessRole ולאחר מכן משתייך לאותו אובייקט.
התפקיד הזה נוצר כ member accounts. כאשר יוצרים חשבון, בנוסף למשתמש הבסיס, AWS Organization משייך את האובייקט באופן אוטומטי לתפקיד IAM שהוא ברירת מחדל. אנו יכולים לציין שם פריט אחר בעת יצירתו, עם זאת, מומלץ לתת לו שם באופן עקבי בכל החשבונות.
כברירת מחדל, OrganizationAccountAccessRole מכיל AdministratorAccess עם מדיניות המצורפת אליו, ולכן מעניקה לתפקיד שליטה מלאה על member accounts. בנוסף, מדיניות האמון המוגדרת כברירת מחדל בתפקיד היא כפי שמוצג להלן, כאשר מזהה 000000000000 הוא Account ID של החשבון המנוהל.
מהו AWS account ID? אובייקט בן 12 ספרות, כגון 164456289012, המזהה באופן ייחודי חשבון AWS. משאבי ורכיבי AWS כוללים את מזהה החשבון באובייקט ARN. השימוש בל account ID יכול להיעשות בין משאבים בחשבונות שונים.
משמעות הדברים היא שאם תוקף מסכן/פורץ את חשבון הניהול המדובר, אופן הפעולה המוגדר כברירת מחדל של AWS Organization מספק נתיב לפגיעה בכל חשבון בארגון כמנהל מערכת. עבור אבטחה התקפית, זיהוי נתיבים לחשבון מהסוג הנ”ל ולחשובן הזה בפרט ההנהלה יכול להיות לגרום להפרת אבטחה ולהביא למצב של Account Take Over.
עבור הצוותים הכחולים, האפשרויות להפחתת סיכונים הם לוודא שלא תיפרס תשתית בחשבון הניהול בצורה דיפולטית וללא השגחה בכדי להפחית את שטח התקיפה. בנוסף, שליטה קפדנית במי שיש לו גישה לחשבון הניהול וניטור גישה מסייעים גם הם להפחית את הסיכון.
במציאות ישנם מקרים רבים בהם עובדים עם חשבון הניהול וכן ההרשאה של OrganizationAccountAccessRole, למשל, כאשר בונים ופורסים תשתית ב AWS באמצעות Terraform ומיישמים תשתית כקוד, במצבים בהם זה ממש נמצא כחלק מהתהליך הפיתוח ובמצבים בהם יוצרים חשבונות מרובים – בסיטואתיות רבות החשבונות האלה אינם מתוחזקים.
במטריצה המצורפת של MITRE אפשר לקבל תמונה על נקודות תקיפה לפי הפריימוורק המוכר, החל משלב הגישה הראשונית ועד כניסה והוצאת מידע. החלק של אנומרציה בענן עושה עבודה קשה לצוות הכחולים בגלל שהאפשרויות לזיהוי פעולות אנומצריה מול רכיב חיצוני הן מזעריות.
גילוי חשבון account ID
אנומרציה וסריקות – כאשר תוקפים את הענן אנו מתחילים בשלב של האנומרציה כאשר אנו מגלים, סורקים ובודקים את מצב הסביבה, אנו עושים זאת במצב של Outsider עם כלים מגוונים שנותנים ראייה רחבה או מסויימת על הנכסים הציבוריים והחיצונים של הענן.
מצב Outsider בענן הוא מצב ללא הרשאה, ללא אובייקט ידוע וללא היכרות עם הסביבה, בפרט הסביבה הפנימית, מעין בדיקת Blackbox.
ישנם דרכים רבות לגלות בצורה חיצונית מיהו אותו חשבון שמוגדר כחשבון Account ID, בין אם זה מתוך סריקות חיצוניות של EC2, או Bucket וכל שירות חיצוני אחר שמונגש לרשת החיצונית – תמיד יהיה שירות כזה ולכן בשלב האנומרציה תמיד נוכל להגיע למצב וודאי של זיהוי Account ID.
ברגע שיש זיהוי על שם השחבון אנו נתחיל בשלב של ביצוע תקיפת Identity, כלומר כל הפעולות המוכרות של Brute-force, ניחוש סיסמאות וכן הלאה. שלב שיכול לקחת זמן, ואולי להיות מזוהה במערכות הבקרה.
ישנם דרכים מגוונות לגלות בסריקה חיצונית חשבון account ID. למשל, ע”י ניצול הערך באובייקט או תנאי המדיניות של s3:ResourceAccount והשיוך מול האובייקט הציבורי של S3 Bucket. איך הדבר אפשרי? ישנו שיוך בגלל התמיכה בתווים כלליים, בפרט wildcard.
האתר המוכר של Grayhat Warfare’s מפשט את הפעולה הראשונית ע”י חיפוש S3 ציבוריים ומשם אפשר להמשיך אל הכלי הנוסף שיבצע את הגילוי של account ID אל מול אותו S3 ציבורי שמצאנו (המיועד לחיפוש).
הקטע המעניין שהוא שבאמצעות wildcard אנו יכולים לבצע חיפושים רוחביים, אבל עדיין נצטרך חשבון AWS עצמאי להריץ פעולות (לא של הנתקף) עם הרשאות s3:getObject או s3:ListBucket בכדי להריץ פעולות חיפוש.
לאחר התקנה של הכלי נוכל להריץ חיפוש מול Bucket ייעודי באמצעות arn + role + S3 bucket name.
משאבים נוספים
- כלי לחיפוש S3 Account Search (github.com)
שיטות עבודה מומלצות
- Best practices for the management account – AWS Organizations (amazon.com)
- Manually add the required IAM role to an existing AWS account and enroll it – AWS Control Tower (amazon.com)
- Track which users are accessing your S3 buckets and objects (amazon.com)
דרכים לזיהוי באמצעות Microsoft Sentinel
בעיות נפצות של AWS
