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

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

- פרץ לבדיקת כתובות כדי לראות אם ניתן לקרוא אותן
- פריצה לבדיקה של כתובות לצורך כתיבה
- פריצה לניתוב מחדש של זרימת בקרה
- מה שלושת הפריצות המפורטות לעיל נותנות לנבל?
- איך הנבל משתמש בפריצות אלה כדי ליצור רנזומווארי

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

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

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

פרץ לבדיקת כתובות כדי לראות אם ניתן לקרוא אותן

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

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

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

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

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

הנבל משתמש בפריצה שתוארה למעלה כדי לחפש בקוד היישום המארח גאדג'טים המתאימים ליצירת שרשרת ROP. יחד עם זאת, הוא לא צריך לחקור כל כתובת. מספיק לחקור כתובת אחת מכל עמוד של מרחב הכתובות הווירטואלי. בדיקה של כל 16 הגיגה-בייט של הזיכרון נמשכת כ-45 דקות (ב-Intel i7-6700K). כתוצאה מכך, הנבל מקבל רשימה של דפי הפעלה המתאימים לבניית שרשרת ROP.

פריצה לבדיקת כתובות לצורך כתיבה

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

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

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

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

פריצה כדי להפנות מחדש את זרימת הבקרה

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

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

מה שלושת הפריצות המפורטות לעיל נותנות לנבל?

(1) ראשית, המובלעת הזדונית דרך לפרוץ לבדיקת כתובות כדי לראות אם ניתן לקרוא אותן, – מחפש ביישום המארח אחר גאדג'טים ROP הניתנים לרעה.

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

(3) לאחר מכן, המובלעת יוצרת שרשרת ROP מהגאדג'טים שהתגלו בשלב (1) ומזריקה את השרשרת הזו לערימת היישום המארח.

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

איך נבל משתמש בפריצות אלה כדי ליצור רנזווארי

לאחר שהאפליקציה המארח מעבירה את השליטה למובלעת דרך אחד ה-ECALLs (מבלי לחשוד שהמובלעת הזו זדונית), המובלעת הזדונית מחפשת מקום פנוי בזיכרון של האפליקציה המארח להזרקת קוד (לוקח כחללים פנויים את רצפי התאים האלה שמלא באפסים). ואז דרך לפרוץ לבדיקת כתובות כדי לראות אם ניתן לקרוא אותן, – המובלעת מחפשת דפי הפעלה באפליקציית המארח ומייצרת שרשרת ROP שיוצרת קובץ חדש בשם "RANSOM" בספרייה הנוכחית (במתקפה אמיתית, המובלעת מצפינה קבצי משתמש קיימים) ומציגה הודעת כופר. יחד עם זאת, האפליקציה המארח מאמינה בתמימות שהמובלעת פשוט מוסיפה שני מספרים. איך זה נראה בקוד?

כדי להקל על התפיסה, הבה נציג כמה מנימוניות דרך ההגדרות:

אנו שומרים את הערכים המקוריים של אוגרי RSP ו-RBP על מנת לשחזר את הפעולה הרגילה של היישום המארח לאחר ביצוע המטען:

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

מציאת גאדג'טים ROP מתאימים:

מציאת מקום להזריק את המטען:

אנו בונים שרשרת ROP:

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

מקור: www.habr.com