ביקורת אבטחה של פלטפורמת הענן MCS

SkyShip Dusk מאת SeerLight

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

המאמר עוסק בתצוגה הפשוטה ביותר הזו של מומחים חיצוניים שעזרו לצוות פתרונות הענן של Mail.ru (MCS) לבדוק את שירות הענן, ולגבי מה הם מצאו. כ"כוח חיצוני", MCS בחרה בחברת Digital Security, הידועה במומחיות הגבוהה שלה בחוגי אבטחת מידע. ובמאמר זה ננתח כמה נקודות תורפה מעניינות שנמצאו במסגרת ביקורת חיצונית - כך שתימנע מאותה גריפה כשאתה יוצר שירות ענן משלך.

Описание продукта

Mail.ru Cloud Solutions (MCS) היא פלטפורמה לבניית תשתית וירטואלית בענן. הוא כולל IaaS, PaaS ושוק של תמונות אפליקציות מוכנות למפתחים. בהתחשב בארכיטקטורת MCS, היה צורך לבדוק את בטיחות המוצר בתחומים הבאים:

• הגנה על תשתית סביבת הוירטואליזציה: היפרוויזורים, ניתוב, חומות אש;
• הגנה על תשתית וירטואלית של לקוחות: בידוד זה מזה, כולל רשת, רשתות פרטיות ב-SDN;
• OpenStack והרכיבים הפתוחים שלו;
• S3 של עיצוב משלנו;
• IAM: פרויקטים מרובי דיירים עם מודל לחיקוי;
• Vision (ראייה ממוחשבת): ממשקי API ופגיעויות בעבודה עם תמונות;
• ממשק אינטרנט והתקפות אינטרנט קלאסיות;
• פגיעויות של רכיבי PaaS;
• API של כל הרכיבים.

אולי זה כל מה שחיוני להמשך ההיסטוריה.

איזה סוג של עבודה בוצעה ומדוע היה צורך בכך?

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

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

1. ניתוח אימות בשירות. פגיעויות ברכיב זה יעזרו להיכנס מיד לחשבונות של אנשים אחרים.
2. לימוד המודל לחיקוי ובקרת גישה בין חשבונות שונים. עבור תוקף, היכולת לקבל גישה למכונה הוירטואלית של מישהו אחר היא מטרה רצויה.
3. פגיעויות בצד הלקוח. XSS/CSRF/CRLF/וכו'. האם ניתן לתקוף משתמשים אחרים באמצעות קישורים זדוניים?
4. נקודות תורפה בצד השרת: RCE וכל מיני הזרקות (SQL/XXE/SSRF וכן הלאה). בדרך כלל קשה יותר למצוא פגיעויות שרת, אך הן מובילות לפשרה של משתמשים רבים בבת אחת.
5. ניתוח בידוד מקטעי משתמשים ברמת הרשת. עבור תוקף, חוסר הבידוד מגדיל מאוד את משטח ההתקפה נגד משתמשים אחרים.
6. ניתוח היגיון עסקי. האם אפשר לרמות עסקים וליצור מכונות וירטואליות בחינם?

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

נמצאו פגיעויות

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

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

IDOR

פגיעויות IDOR (Insecure Direct Object Reference) הן אחת הפגיעות הנפוצות ביותר בלוגיקה עסקית, המאפשרת לאחד או אחר לקבל גישה לאובייקטים שהגישה אליהם למעשה אינה מותרת. פרצות IDOR יוצרות אפשרות לקבל מידע על משתמש בדרגות קריטיות שונות.

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

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

זיוף בקשות צד שרת (SSRF)

הדבר הטוב במוצרי OpenSource הוא שיש להם מספר עצום של פורומים עם תיאורים טכניים מפורטים של הבעיות שצצות ואם יתמזל מזלכם, תיאור הפתרון. אבל למטבע הזה יש צד הפוך: גם נקודות תורפה ידועות מתוארות בפירוט. לדוגמה, יש תיאורים נפלאים של נקודות תורפה בפורום OpenStack [XSS] и [SSRF], שמשום מה אף אחד לא ממהר לתקן.

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

פגיעויות SSRF יכולות לקדם מאוד את התפתחותה של התקפה. תוקף יכול לקבל:

• גישה מוגבלת לרשת המקומית המותקפת, למשל, רק דרך מקטעי רשת מסוימים ושימוש בפרוטוקול מסוים;
• גישה מלאה לרשת המקומית, אם מתאפשרת שדרוג לאחור מרמת האפליקציה לרמת התחבורה וכתוצאה מכך ניהול עומסים מלא ברמת האפליקציה;
• גישה לקריאת קבצים מקומיים בשרת (אם סכימת file:/// נתמכת);
• ועוד הרבה יותר.

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

זו לא הפעם הראשונה שמתגלה פגיעות SSRF ב-OpenStack. בעבר ניתן היה להוריד תמונות VM ISO מקישור ישיר, מה שגם הוביל להשלכות דומות. תכונה זו הוסרה כעת מ-OpenStack. ככל הנראה, הקהילה ראתה בכך את הפתרון הפשוט והאמין ביותר לבעיה.

וב זה דוח זמין לציבור משירות HackerOne (h1), ניצול של SSRF שכבר לא עיוור עם היכולת לקרוא מטא נתונים של מופעים מוביל לגישה ל-Root לכל תשתית Shopify.

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

XSS במקום טעינת קונכיות

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

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

לצוות התוקף (מיוצג על ידי Digital Security) היה מזל. בסדר, ב-MCS בצד השרת נבדק תוכן הקבצים שהורדת, רק תמונות הורשו. אבל SVG הוא גם תמונה. איך תמונות SVG יכולות להיות מסוכנות? כי אתה יכול להטמיע בתוכם קטעי JavaScript!

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

דוגמה להתקפת XSS על טופס התחברות דיוג

דוגמאות לניצול מתקפת XSS:

• מדוע לנסות לגנוב הפעלה (במיוחד מכיוון שכעת עוגיות HTTP בלבד נמצאות בכל מקום, מוגנות מפני גניבה באמצעות סקריפטים של js), אם הסקריפט הנטען יכול לגשת מיד ל-API של המשאב? במקרה זה, המטען יכול להשתמש בבקשות XHR כדי לשנות את תצורת השרת, לדוגמה, להוסיף את מפתח ה-SSH הציבורי של התוקף ולקבל גישת SSH לשרת.
• אם מדיניות ה-CSP (מדיניות הגנת תוכן) אוסרת על הזרקת JavaScript, תוקף יכול להסתדר בלעדיה. באמצעות HTML טהור, צרו טופס התחברות מזויף לאתר וגנובו את סיסמת המנהל באמצעות התחזות המתקדמת הזו: דף ההתחזות של המשתמש מגיע לאותה כתובת URL, וקשה יותר למשתמש לזהות אותו.
• לבסוף, התוקף יכול לארגן DoS של הלקוח - הגדר קובצי Cookie בגודל של יותר מ-4 KB. המשתמש צריך לפתוח את הקישור רק פעם אחת, והאתר כולו הופך לבלתי נגיש עד שהמשתמש חושב לנקות ספציפית את הדפדפן: ברוב המוחלט של המקרים, שרת האינטרנט יסרב לקבל לקוח כזה.

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

כלומר, התרחיש התברר כדלקמן: תוקף יוצר כלל חומת אש עם "טעינה" בשם, המנהל מבחין בכך לאחר זמן מה ומתחיל את תהליך המחיקה. וכאן פועל ה-JS הזדוני.

למפתחי MCS, כדי להגן מפני XSS בתמונות SVG שהורדו (אם לא ניתן לנטוש אותן), צוות האבטחה הדיגיטלית המליץ:

• מקם קבצים שהועלו על ידי משתמשים בדומיין נפרד שאין לו שום קשר ל"עוגיות". הסקריפט יבוצע בהקשר של תחום אחר ולא יהווה איום על MCS.
• בתגובת HTTP של השרת, שלח את הכותרת "Content-disposition: attachment". לאחר מכן הקבצים יורדו על ידי הדפדפן ולא יבוצעו.

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

• באמצעות הדגל "HTTP Only", אתה יכול להפוך את כותרות "Cookies" של ההפעלה ללא נגישות ל-JavaScript זדוני;
• מדיניות CSP מיושמת כהלכה יקשה הרבה יותר על תוקף לנצל את XSS;
• מנועי תבנית מודרניים כגון Angular או React מחטאים אוטומטית את נתוני המשתמש לפני שהם מוציאים אותם לדפדפן של המשתמש.

נקודות תורפה של אימות דו-גורמי

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

אבל האם שימוש בגורם אימות שני תמיד מבטיח את בטיחות החשבון? ישנן בעיות האבטחה הבאות ביישום 2FA:

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

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

MCS 2FA נמצא בשימוש במספר מקומות:

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

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

תהליך בחירת OTP להשבית 2FA באמצעות הכלי "Burp: Intruder".

תוצאה

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

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

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

• לערוך באופן קבוע ביקורות על ידי חברות חיצוניות;
• לתמוך ולפתח השתתפות בתוכנית Mail.ru Group Bug Bounty;
• לעסוק באבטחה. 🙂

מקור: www.habr.com