פרטים טכניים של פריצת Capital One ב-AWS

ב-19 ביולי 2019, קפיטל וואן קיבלה את ההודעה שכל חברה מודרנית חוששת - התרחשה פרצת נתונים. זה השפיע על יותר מ-106 מיליון אנשים. 140 מספרי ביטוח לאומי בארה"ב, מיליון מספרי ביטוח לאומי קנדיים. 000 חשבונות בנק. לא נעים, אתה לא מסכים?

לרוע המזל, הפריצה לא התרחשה ב-19 ביולי. כפי שמתברר, פייג' תומפסון, א.ק.א. בִּלתִי יָצִיב, ביצע את זה בין 22 במרץ ל-23 במרץ 2019. זה לפני כמעט ארבעה חודשים. למעשה, רק בעזרת יועצים חיצוניים הצליחה Capital One לגלות שמשהו קרה.

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

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

קודם כל מה קרה?

ל-Capital One פעלו כ-700 דליים מסוג S3, אותם העתיקה פייג' תומפסון וסינקה אותם.

שנית, האם זהו מקרה נוסף של מדיניות דלי S3 שהוגדרה בצורה שגויה?

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

רגע, איך זה אפשרי?

ובכן, בואו נתחיל בכניסה לשרת, למרות שאין לנו הרבה פרטים. נאמר לנו רק שזה קרה דרך "חומת אש לא מוגדרת". אז משהו פשוט כמו הגדרות שגויות של קבוצת אבטחה או תצורה של חומת האש של יישום האינטרנט (Imperva), או חומת האש של הרשת (iptables, ufw, shorewall וכו'). Capital One רק הודתה באשמה ואמרה שהיא סגרה את החור.

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

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

אז הפתרון הראשון הוא: דע מה חומות האש שלך מאפשרות.

קבע מדיניות או תהליך נכון כדי להבטיח שרק מה שצריך לפתוח ייפתח. אם אתה משתמש במשאבי AWS כמו קבוצות אבטחה או ACLs ברשת, ברור שרשימת הביקורת לביקורת יכולה להיות ארוכה... אבל בדיוק כמו משאבים רבים נוצרים באופן אוטומטי (כלומר CloudFormation), אפשר גם להפוך את הביקורת שלהם לאוטומטית. בין אם זה סקריפט תוצרת בית שסורק אובייקטים חדשים לאיתור פגמים, או משהו כמו ביקורת אבטחה בתהליך CI/CD... יש הרבה אפשרויות קלות להימנע מכך.

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

אז, האקר בפנים - מה קרה אחר כך?

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

לכן, דרך אחת לגשת לשירותי AWS היא להיות משתמש. אוקיי, זה די ברור. אבל מה אם אתה רוצה לתת לשירותי AWS אחרים, כמו שרתי היישומים שלך, גישה לדלי S3 שלך? בשביל זה נועדו תפקידי IAM. הם מורכבים משני מרכיבים:

1. מדיניות אמון - אילו שירותים או אנשים יכולים להשתמש בתפקיד זה?
2. מדיניות הרשאות - מה התפקיד הזה מאפשר?

לדוגמה, ברצונך ליצור תפקיד IAM שיאפשר למופעי EC2 לגשת לדלי S3: ראשית, לתפקיד מוגדר מדיניות אמון ש-EC2 (השירות כולו) או מופעים ספציפיים יכולים "להשתלט" על התפקיד. קבלת תפקיד פירושה שהם יכולים להשתמש בהרשאות התפקיד כדי לבצע פעולות. שנית, מדיניות ההרשאות מאפשרת לשירות/אדם/משאב ש"לקח את התפקיד" לעשות כל דבר ב-S3, בין אם זה גישה לדלי ספציפי אחד... או מעל 700, כמו במקרה של Capital One.

ברגע שאתה נמצא במופע EC2 עם תפקיד IAM, אתה יכול להשיג אישורים בכמה דרכים:

1. אתה יכול לבקש מטא נתונים של מופע בכתובת http://169.254.169.254/latest/meta-data

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

2. השתמש ב-AWS CLI...

   אם ה-AWS CLI מותקן, הוא נטען עם אישורים מתפקידי IAM, אם קיימים. כל מה שנותר הוא לעבוד דרך המופע. כמובן, אם מדיניות האמון שלהם הייתה פתוחה, פייג' יכולה לעשות הכל ישירות.

אז המהות של תפקידי IAM היא שהם מאפשרים למשאבים מסוימים לפעול בשמך במשאבים אחרים.

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

1. היא השיגה גישה לשרת (מופע EC2) דרך חור בחומת האש

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

2. פעם אחת על השרת, היא הייתה מסוגלת להתנהג "כאילו" היא השרת בעצמה
3. מכיוון שתפקיד שרת IAM אפשר ל-S3 גישה ל-700+ דליים אלה, הוא היה מסוגל לגשת אליהם

מאותו רגע, כל מה שהיה עליה לעשות זה להפעיל את הפקודה List Bucketsואז הפקודה Sync מ-AWS CLI...

Capital One Bank מעריך את הנזק מהפריצה בין 100 ל-150 מיליון דולר. מניעת נזק כזה היא הסיבה שחברות משקיעות כל כך הרבה בהגנה על תשתית ענן, ב-DevOps ובמומחי אבטחה. ועד כמה המעבר לענן בעל ערך וחסכוני? עד כדי כך שגם מול עוד ועוד אתגרי אבטחת סייבר שוק הענן הציבורי הכולל צמח ב-42% ברבעון הראשון של 2019!

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

(כאן ניתן לצפות בדו"ח המשפטי המלא).

מקור: www.habr.com