במחקר האחרון שלנו, מצאנו 3 פגיעויות שונות ב TinyCheck, כלי קוד פתוח שפותח ופורסם על ידי Félix Aimé, אחד המומחים הגדולים של קספרסקי. לכל אחת מהפגיעות יש חומרה גבוהה בפני עצמה. לאחר שילובו לשרשרת, תוקף מרוחק יכול לנצל אותו כדי לקבל RCE (ביצוע קוד מרחוק) במחשב ה-TinyCheck המרוחק.
בקיצור, השתמשנו ב- אישורי ברירת מחדל של TinyCheck כדי לערוך שני חלקים בקובץ תצורה:
- בראשון, הוספנו מטען זדוני, שיבוצע מאוחר יותר באמצעות הזרקת פקודה פגיעות.
- בשני, הוספנו כתובת URL לרשימה שתגרום SSRF, שבהמשך יפעיל את המטען הזדוני מהסעיף הראשון.
מה זה TinyCheck
TinyCheck מאפשרת למשתמש לנתח רשת של מכשיר. המשתמש יכול לחבר את המכשיר שלו ל-proxy WiFi של TinyCheck, שילכוד את פעילות הרשת. ניתן לנתח פעילות זו עבור תעבורה זדונית שעוברת דרך הרשת.
מאז יש לנו ניסיון עם פרוקסי באנדרואיד, ידענו שפרוקסי פשוט לא אמור להתקשות יותר מדי בטיפול בתעבורה שעלולה להיות זדונית. אבל TinyCheck עשיר יותר בתכונות, ומציע יכולת רחרוח טובה יותר מאשר סקריפט פרוקסי פשוט. קוד המקור זמין ב- GitHub מה שאפשר לבחון אותו.
ל-TinyCheck יש 3 שירותים רלוונטיים:
- "Backend" – שרת Flask הפתוח לעולם ומוגן באמצעות שם משתמש/סיסמה (אישור בסיסי). השרת מתמקד בעיקר בעריכת תצורה.
- "Frontend" - שרת Flask שפועל על localhost, אין לו סיסמה והתפקיד העיקרי שלו הוא להתחיל/להפסיק/לנהל לכידת רשת.
- "Watchers" - שירות כלב שמירה שיחזור על רשימת כתובות URL ויבצע בקשת HTTP GET לאלה.
פגיעות מס' 1 - אישורי ברירת מחדל
זוהי הפגיעות הפשוטה ביותר מבין 3, אך חיונית לכל המתקפה. כברירת מחדל, TinyCheck מגיע עם אישורי ברירת המחדל של "tinycheck" בתור שם המשתמש והסיסמה.
קבלת אישורי ברירת מחדל כאלה מבלי לדרוש מהמשתמש לשנות אותם בשימוש הראשון, מהווה סיכון מיותר.
על ידי שימוש באישורי ברירת המחדל, הייתה לנו גישה למגוון נקודות קצה בשרת ה-"backend", מה שהעניק לנו משטח התקפה רחב יותר.
נקודת הסיום החשובה שבה נשתמש בהמשך הייתה זו שעורכת את קובץ התצורה של YAML.
https://tinycheck.local/config/edit/CATEGORY/KEY/VALUE
עוד על איך השתמשנו בו למטה.
פגיעות מס' 2 - SSRF
שכח בקשת צד שרת (SSRF) תמיד מרגש ופעמים רבות מתעלמים מהמפתחים או חוקרי האבטחה. על ידי ניצול הפגיעות הזו, הצלחנו לאלץ את השרת לבצע בקשת HTTP. זה שימושי עבור עקיפת חומת אש או עבור גישה לרשת הפנימית, שלא הייתה נגישה קודם לכן.
מצאנו שלשרת יש רשימה של כתובות URL המאוחסנות בקובץ התצורה של YAML מתחת watchers/iocs:
באמצעות הפגיעות הראשונה, הצלחנו לשכתב את הרשימה ולשנות אותה לכתובות האתרים שלנו:
מעניין שעכשיו הצלחנו לגרום לשירות "צופים" לבצע בקשת HTTP GET לכל כתובת אתר שנבחר. והכי חשוב, נוכל לפגוע בשרת "החזית" בזמן שהוא פועל פנימה localhost ברגע ששירות "הצופים" נטען מחדש.
שוב, זה נתן לנו משטח התקפה רחב יותר כדי להגיע ליותר נקודות קצה ויותר היגיון שנוכל לנצל.
פגיעות מס' 3 - הזרקת פקודה
התחלנו לחקור את שרת ה"חזית". אל תתבלבלו מהשם, זהו שרת Flask, לא רק שרת חזיתי של JS.
עם עולם חדש לגמרי של נקודות קצה מפגיעות SSRF, בדקנו את מחלקות השירות, הפונקציות וכלי השירות שעשויים להיות ניתנים לניצול.
לאחר שקראנו את קוד המקור ונכנסנו עמוק לתוך מחסנית קריאת הפונקציות, נתקלנו בקוד הזה:
Popen("tshark -i {}".format(self.iface), shell=True)Popen היא הדרך לקרוא לתהליך משנה ב-Python. ה shell=True ו format הם החלקים הניתנים לניצול, כלומר הפקודה שתפעל תתפרש כמחרוזת. בעוד שהכוונה המקורית כאן כן עובדת אם self.iface הוא רק מחרוזת כמו "eth0", הבנו שאם נוכל להחדיר מחרוזת בעלת מבנה זדוני, נוכל להריץ קוד שרירותי.
למזלנו, ה self.iface למעשה נקרא מקובץ התצורה תחת network/in סעיף, הערך המקורי שלו נניח להצביע על ממשק רשת.
self.iface = read_config("network/in")כמו פגיעות SSRF, הזרמנו את המטען שלנו באמצעות אותה נקודת קצה לעריכת תצורה.
ההזרקה עצמה הייתה פשוטה:
; whoami>/tmp/exploit.outזה אומר שעם המטען שלנו, הפקודה המקורית תעוצב כך:
Popen("tshark -i ; whoami>/tmp/exploit.out", shell=True)אכן, הקובץ הכיל את המילה root, מה שאומר שנוכל להשתלט על המערכת, מכיוון שהשרת פועל כ-root ולא כמשתמש ייעודי בעל הרשאות נמוכות.
אבל היינו צריכים להפעיל את הקוד הזה. כרגע, המטען שלנו הופעל בדיוק כשהמשתמש מתחיל ללכוד פעילות רשת דרך ממשק המשתמש.
שרשרת הניצול המלאה
כדי לקשר הכל יחד, היינו צריכים דרך להפעיל את המטען שלנו.
עשינו זאת על ידי מינוף ה-SSRF כדי לקרוא לאחת מנקודות הקצה המקומיות "החזיתיות", שמתחילה את פונקציית לכידת הרשת כך שלא נצטרך לחכות שהמשתמש יעשה זאת.
זה קרא לקוד הפגיע משירות "הצופים" ולביצוע הזרקת הפקודה עם המטען הזדוני שלנו.
חשיפה לצוות האבטחה של קספרסקי
חשיפת הפגיעות לצוות האבטחה של קספרסקי הייתה חוויה טובה להפליא עבורנו. סגור עבורם על שחזרו אלינו מהר מאוד והשיגו את ההובלה למוצר, פליקס איימה, מעורב שפתר את כל הפגיעות תוך יום או יומיים.
ציר זמן לחשיפה
- 2020-12-14: דוח מפורט נשלח אל [מוגן בדוא"ל]
- 2020-12-15: תגובה ראשונה מצוות אבטחת המוצר של קספרסקי
- 2020-12-18: כל הפגיעויות תוקן + ייעוץ כדי לשדרג לגרסה המתוקנת
- 2021-01-22: הונפקו CVEs
- 2021-02-11: פוסט בבלוג פורסם
רוצה לשמוע עוד?
כולל פגישת ייעוץ חינם.
