Stagefright: הניצול ששינה את אנדרואיד

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

ב-Google I/O 2014, גוגל נתנה את הדחיפה הראשונה שלה לעבר מערכת אקולוגית בטוחה וידידותית יותר לארגונים עם השקת ה- תוכנית Android For Work. Android For Work אימצה גישת פרופיל כפול לצרכים ארגוניים, לפיה מנהלי IT יכולים ליצור א פרופילי משתמש מובהקים לעובדים - אחד ממוקד בעבודה, השארת פרופילים אחרים לפרטיים של העובדים להשתמש. באמצעות שימוש בהצפנה מבוססת חומרה ובמדיניות מנוהלת על ידי מנהל, העבודה והנתונים האישיים נותרו ברורים ובטוחים. לאחר מכן, Android For Work קיבלה יותר תשומת לב בחודשים המאוחרים יותר, כאשר התמקדות גדולה הייתה באבטחת המכשיר מפני תוכנות זדוניות. גם גוגל תכננה לעשות זאת

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

הדחיפה לאנדרואיד מאובטחת היא לא לגמרי העבודה של גוגל, שכן סמסונג מילאה תפקיד די משמעותי בכך באמצעותה תרומות KNOX ל-AOSP, אשר בסופו של דבר חיזק את Android For Work. עם זאת, ניצולי אבטחה ופגיעויות אחרונות באנדרואיד מצביעים על משימה עלייה בכל הנוגע לפופולריות לאימוץ ארגוני. דוגמה לכך היא הפגיעות האחרונה של Stagefright.

תוכן:

• מה זה Stagefright?
• עד כמה סטייפרייט רציני?
• מה מייחד את Stagefright מ"פגיעות מסיביות" אחרות?
• דילמת העדכון
• אנדרואיד, Post-Stagefright
• הערות סיום

מה זה Stagefright?

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

פנינו למומחה הביתי שלנו, מפתח מוכר בכיר ב-XDA ומנהל מפתח pulser_g2 כדי לספק הסבר מפורט יותר.

"בזמן שאני כותב את זה, ניצול [Stagefright] היה אמור להיות מוסבר ב-BlackHat [קישור], למרות שעדיין אין שקופיות או פרטי נייר לבן זמינים.

לכן אני נותן את ההסבר הזה יותר כרעיון גס של מה שקורה, במקום כהסבר מעמיק מאוד עם דיוק מלא וכו'.

ישנם מספר באגים שונים המרכיבים את Stagefright, ולאלה יש CVE משלהם [פגיעויות וחשיפות נפוצות] מספרים למעקב:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

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

1. [CVE-2015-1538]

בקוד הטיפול MPEG4, קוד הטיפול ב-3GPP (החומר שמתאר את הפורמט ומידע נוסף, כאשר סרטון וידאו הוא בפורמט 3GPP) הוא באג. הוא לא דחה מטא נתונים, שבהם הנתונים היו גדולים מדי, אלא רק בדק אם הם קטנים מדי. פירוש הדבר היה שניתן לתוקף ליצור קובץ "משונה" או "פגום", שיהיה לו חלק מטא-נתונים ארוך יותר ממה שצריך.

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

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

(ת"פ: אומנירום חריט)

2. [CVE-2015-1539]

ה"גודל" הקצר ביותר האפשרי של המטא-נתונים צריך להיות 6 בתים, בגלל היותו מחרוזת UTF-16. הקוד לוקח את גודל הערך השלם, ומפחית ממנו 6. אם הערך הזה היה פחות מ-6, החיסור היה "מתחדד" ומתעטף, והיינו מקבלים מספר גדול מאוד. תאר לעצמך שאתה יכול לספור רק מ-0 עד 65535, למשל. אם אתה לוקח את המספר 4, ומחסיר 6, אתה לא יכול לרדת מתחת לאפס. אז אתה חוזר ל-65535 וסופר משם. זה מה שקורה כאן!

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

(ת"פ: אומנירום חריט)

3. [CVE-2015-3824]

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

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

(ת"פ: אומנירום חריט)

4. [CVE-2015-3826]

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

(ת"פ: אומנירום חריט)

5. [CVE-2015-3827]

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

(ת"פ: אומנירום חריט)

ישנם גם כמה תיקונים הקשורים (פוטנציאליים) שנראים כאילו נכנסו גם ל-[אנדרואיד] 5.1.

(ת"פ: אומנירום חריט)

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

(ת"פ: אומנירום חריט)

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

(ת"פ: אומנירום חריט)

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

(ת"פ: אומנירום חריט)"

עד כמה סטייפרייט רציני?

לפי ה פוסט בבלוג שפורסם על ידי חברת האם החוקרת, Zimperium Research Labs, מנצל ה-Stagefright חושף פוטנציאל 95% ממכשירי אנדרואיד - בערך 950 מיליון - פגיעות זו מכיוון שהיא משפיעה על מכשירים עם אנדרואיד 2.2 ו לְמַעלָה. כדי להחמיר את המצב, מכשירים שלפני Jelly Bean 4.3 נמצאים ב"סיכון הגרוע ביותר" מכיוון שהם אינם מכילים אמצעי מניעה נאותים נגד ניצול זה.

בקשר לנזק ש-Stagefright יכולה לגרום, pulser_g2 העיר:

[blockquote author="pulser_g2"]"בעצמה, Stagefright תיתן גישה למשתמש המערכת בטלפון. עם זאת, תצטרך לעקוף את ASLR (אקראי פריסת מרחב כתובות) כדי להשתמש בו לרעה. לא ידוע כרגע אם זה הושג או לא. ניצול זה מאפשר להריץ "קוד שרירותי" במכשיר שלך בתור משתמש המערכת או המדיה. לאלה יש גישה לאודיו ולמצלמה במכשיר, ומשתמש המערכת הוא מקום מצוין להשיק ממנו ניצול שורש. זוכרים את כל מנצלי השורש המדהימים שבהם השתמשתם כדי לשורש את הטלפון שלכם?

אלה עשויים לשמש בשקט כדי להשיג שורש במכשיר שלך! מי שיש לו שורש הוא הבעלים של הטלפון. הם יצטרכו לעקוף את SELinux, אבל TowelRoot הצליחה את זה, וגם PingPong הצליח. ברגע שהם מקבלים שורש, הכל בטלפון שלך פתוח בפניהם. הודעות, מפתחות וכו'."[/blockquote]אם מדברים על תרחישים גרועים ביותר, יש צורך רק ב-MMS כדי לספק קוד ולהפעיל את הניצול הזה. המשתמש אפילו לא צריך לפתוח את ההודעה מכיוון שהרבה אפליקציות להעברת הודעות מעבדות מראש MMS לפני שהמשתמש מתקשר איתו. זה שונה ממתקפות דיוג בחנית מכיוון שהמשתמש עלול להיות מודע לחלוטין להתקפה מוצלחת, ולסכן את כל הנתונים הנוכחיים והעתידיים בטלפון.

מה מייחד את Stagefright מ"פגיעות מסיביות" אחרות?

"כל הפגיעויות מהוות סיכון מסוים למשתמשים. זה מסוכן במיוחד, שכן אם מישהו ימצא דרך לתקוף אותו מרחוק (כלומר אפשרי, אם נמצאה דרך לעקוף את ה-ASLR), זה יכול להיות מופעל עוד לפני שאתה מבין שאתה תחת לִתְקוֹף"

ניצולים ישנים יותר כמו חטיפת Android Installer, FakeID וכן ניצול שורש כמו TowelRoot ו-PingPong דורשים אינטראקציה של משתמשים בשלב מסוים על מנת שיבוצעו. למרות שהם עדיין "מנצלים" בעובדה שהרבה נזק יכול לנבוע אם משתמשים בהם בזדון, העובדה נשארת ש-Stagefright תיאורטית זקוק רק למספר הנייד של הקורבן כדי להפוך את הטלפון שלו לסוס טרויאני, ולכן הוא מקבל כל כך הרבה תשומת לב לאחרונה ימים.

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

[blockquote author="Adrian Ludwig"]"יש הנחה נפוצה ומוטעית שניתן להפוך כל באג תוכנה לניצול אבטחה. למעשה, רוב הבאגים אינם ניתנים לניצול ויש הרבה דברים ש-Android עשתה כדי לשפר את הסיכויים האלה...

רשימה של כמה מאותן טכנולוגיות שהוצגו מאז Ice Cream Sandwich (אנדרואיד 4.0) מופיעות ברשימה כאן. הידוע מביניהם נקרא Address Space Layout Randomization (ASLR), שהושלם במלואו ב-Android 4.1 עם תמיכה ב-PIE (Position Independent Executables) והוא נמצא כעת בלמעלה מ-85% מאנדרואיד מכשירים. טכנולוגיה זו מקשה על התוקף לנחש את מיקומו של הקוד, שנדרש לו כדי לבנות ניצול מוצלח...

לא הפסקנו עם ASLR, הוספנו גם NX, FortifySource, Read-Only-Relocations, Stack Canaries ועוד."[/blockquote]

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

דילמת העדכון

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

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

יצרני OEM אחרים שמצטרפים לחבילה כוללים את LG שתצטרף עדכוני אבטחה חודשיים. מוטורולה גם הכריזה על רשימת המכשירים שיעודכנו עם תיקוני Stagefright, והרשימה כוללת כמעט את כל המכשירים שהחברה יצרה מאז 2013. גם סוני אמרה את זה המכשירים שלה יקבלו בקרוב את התיקונים גַם.

פעם אחת, גם ספקים מגיעים עם עדכונים. לספרינט יש הוציא הצהרה שחלק מהמכשירים כבר קיבלו את התיקון של Stagefright, כאשר מכשירים נוספים מתוכננים לעדכון. גם AT&T הלכה בעקבותיה על ידי הנפקת התיקון לחלק מהמכשירים. Verizon הוציאה גם תיקונים, אם כי מדובר בהשקה איטית שמתעדפת סמארטפונים מתקדמים כמו Galaxy S6 Edge ו-Note 4. ה-T-Mobile Note 4 קיבל גם עדכון תיקון של Stagefright.

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

בתור משתמש כוח XDA, אתה יכול גם בצע עריכות באביזר הבנייה שלך כדי להשבית את Stagefright. זו לא דרך שלמה ובטוחה להציל את עצמך מ-Stagefright, אבל אתה יכול לקחת את הסיכויים שלך כדי להפחית את הסבירות להתקפה מוצלחת אם אתה תקוע במבנה אנדרואיד ישן יותר. ישנם גם פתרונות ROM מותאמים אישית, שרובם מסנכרנים מקורות עם AOSP על בסיס קבוע ולכן, ישולבו תיקוני Stagefright. אם אתה מפעיל רום מבוסס AOSP, מומלץ מאוד לעדכן למהדורה חדשה יותר של ה-ROM המשלבת את התיקונים של Stagefright. אתה יכול להשתמש האפליקציה הזאת כדי לבדוק אם הנהג היומי הנוכחי שלך מושפע מ-Stafright.

אנדרואיד, Post-Stagefright

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

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

עם אנדרואיד M שמתקרב לשחרור בשוק, לא יהיה מפתיע אם גוגל תבחר לפרק עוד ועוד רכיבים של AOSP לטובת חבילת שירותי ה-Play שלה. אחרי הכל, זה תחום אחד שגוגל עדיין שומרת עליו שליטה מלאה אם ​​מכשיר יישלח עם חנות Google Play. זֶה יש חסרונות משלו בצורה של החלפת שטחים עם מקורות פתוחים בקירות מקוריים קרובים.

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

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

הערות סיום

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

האם הטלפון שלך פגיע ל-Stagefright? האם אתה חושב שהטלפון שלך יקבל אי פעם תיקון של Stagefright? ספר לנו בתגובות למטה!