מאמר בנושא LG Account Takeover

בתקופה האחרונה ניתן לראות יותר ויותר מוצרי IOT, אך מה זה בעצם מוצר IOT?

מוצר IOT הוא כל מוצר אלקטרוני רגיל אשר:

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

אפליקציה זו מאפשרת למשתמשיה של LG לנהל את המוצרים מרחוק דרך האפליקציה בצורה קלה ונוחה, באפליקציה ניתן למצוא:

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

• מייבש כביסה חכם
• מקרר חכם
• מיקרוגל חכם
• מדיח כלים חכם
• שואב אבק חכם
• ועוד...

לאחר שהסתכלנו על רשימת המוצרים החכמים המרשימה של LG החלטנו לבחון מהו המוצר הנמכר ביותר בתשתית המוצרים החכמים שלה.

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

פיצ'ר זה נקרא home guard, כך בעצם בחרנו בשואב האבק של LG כמטרת המחקר שלנו.

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

---

part 1

בתחילת המחקר חיפשנו דרך להתחבר לשואב האבק של LG ולקבל עליו מסוף (Terminal) כדי לבחון את המערכת ולחפש ליקוי אבטחה.

בחנו את כל החיבורים על הלוח של LG ואיתרנו חיבור Jtag בחלק העליון של המוצר ליד המצלמה והתחברנו עליו פיזית:

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

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

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

---

part 2

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

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

הפונקציות a ו-b מבצעות בדיקה בסיסית האם הטלפון הוא rooted כגון בדיקת המצאות הקובץ su כו'.

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

כך בעצם עקפנו את הגנת ה-root detection של האפליקציה והצלחנו לגרום לה להיפתח.

---

part 3

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

זאת מכיוון ש-LG הטמיעו מנגנון הגנה נוסף הנקרא SSL Pinning אשר לא מוציא חבילות מידע במידה והתעודה הדיגיטלית השתנתה.

עברנו על קוד המקור של האפליקציה על מנת לאתר את המימוש של LG למנגנון ובכך מצאנו את הקוד הבא:

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

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

לאחר ביצוע שלב זה עקפנו גם את מנגנון הSSL Pinning של האפליקציה.

---

part 4

לאחר שהצלחנו לעקוף את מנגנון ה-root detection של האפליקציה וגם את מנגנון ה-SSL Pinning של האפליקציה, כל מה שנשאר לנו לעשות הוא למצוא ליקוי אבטחה קריטי המאפשר לנו להשתלט על חשבונות משתמשים.

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

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

זהו תהליך OAuth2 מסוג Grant Type Password שנראה כך:

• 1. תחילה ה-Client (הטלפון) שולח בקשה לקבלת שם המשתמש והסיסמא מהResource owner (המשתמש שנרשם למערכת).
• 2. לאחר מכן ה-Client לוקח את הנתונים שקיבל מהמשתמש ומעביר אותם ל-Authorization Server אשר מוודא האם הפרטים נכונים ומחזיר לנו token, הפרטים ששולח ה-Client הם בדרך כלל:

• Username

• Password

• Client_id

• Grant_Type=password

• Scope

• 3. במידה והפרטים נכונים ה-Authorization Server מחזיר ל-Client את ה-Access Token שאיתו אנו יכולים לבקש את המשאבים שניתנו לנו מה-Resource Server בהתאם ל-scope (הרשאות). משום שביקשנו Grant_type=password אז ה-Resource Server יקנה לנו token גישה לחשבון לצורך התחברות מאובטחת.
• 4. ה-Client משתמש ב-Access Token ומבקש מה-Resource Server משאב כלשהו כגון token להתחברות לחשבון.
• 5. במידה וה-Access Token הינו נכון ה-Resource Server מחזיר לנו את המידע שביקשנו וכך אנו בעצם מתחברים לחשבון.

לאחר שהבנו כיצד אמור להתבצע התהליך, נסתכל כיצד LG ממשו את התהליך היחסית מורכב הזה:

• 1. האפליקציה שולחת בקשה לשם משתמש וסיסמא מה-Resource Owner ואנו רואים את ה-grant_type=password, וה-client_id:

• 2. אנו מזינים שם משתמש וסיסמא, יש לשים לב שהסיסמא נשלחת חזרה ב-sha256:

• 3. נשלחת בקשה לקבלת ה-Access token מה-Authorization server שמכילה username, client_id ועוד פרמטרים ש-LG הוסיפו לבקשה:

• 4. ה-Authorization Server מחזיר לנו Access Token שאותו אנו שולחים בהמשך ל-Resource Server.

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

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

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

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