פיתוח אפליקציות2 דקות קריאה

התחברות ביומטרית ש-callback מזויף לא יכול לעקוף

אפליקציות Android רבות סומכות על callback של הצלחה ביומטרית, שכלי hooking יכול להפעיל. כך קישור הביומטריה למפתח ב-CryptoObject סוגר את הפרצה.

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

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


החולשה הנפוצה: לסמוך על ה-callback

ה-BiometricPrompt של Android מדווח על תוצאת הבדיקה דרך callback. המימוש הפשוט ביותר נראה מבחינה לוגית כך:

  1. מציגים את חלון האימות הביומטרי.

  2. מחכים ל-onAuthenticationSucceeded.

  3. פותחים את ה-session.

הבעיה היא בשלב 3. במכשיר פרוץ, כלי hooking כמו Frida יכול לקרוא ל-callback ההצלחה ישירות. לאפליקציה אין שום דרך להבדיל בין התאמה ביומטרית אמיתית לבין קריאה מזויפת למתודה.

📌 תובנה מרכזית:

callback אומר "משהו דיווח על הצלחה". מפתח קריפטוגרפי שרק המערכת יכולה לשחרר אומר "התבצעה בדיקה ביומטרית אמיתית".


הפתרון: לקשור את הביומטריה למפתח

במקום לסמוך על ה-callback, האפליקציה קושרת את ההתחברות לפעולה קריפטוגרפית:

  1. יוצרים מפתח ב-Android Keystore שדורש אימות משתמש לפני כל שימוש.

  2. עוטפים Cipher או Signature שמשתמשים במפתח הזה בתוך CryptoObject ומעבירים אותו ל-BiometricPrompt.

  3. רק אחרי התאמה ביומטרית אמיתית המערכת משחררת את המפתח עבור הפעולה הזו.

  4. משתמשים ב-cipher המשוחרר כדי לפענח סוד של ה-session או לחתום על challenge מהשרת. ההתחברות ממשיכה רק אם הפעולה הזו מצליחה.

אם תוקף מזייף את ה-callback, ה-cipher מעולם לא שוחרר. הפענוח או החתימה נכשלים, ואיתם נכשלת גם ההתחברות.


החלטות תכנון שחשובות

1. לפענח או לחתום על משהו אמיתי

ה-CryptoObject חייב להגן על משהו שההתחברות באמת תלויה בו — סוד של ה-session או חתימה שהשרת מאמת. הפעלת ה-cipher על מידע דמה והתעלמות מהתוצאה מחזירות את החולשה ישר למקום.

2. להחליט מה קורה כשהביומטריה משתנה

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

3. לשמור על fallback

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

4. לשלב עם מנגנוני הגנה נוספים

קישור ל-CryptoObject סוגר פרצה אחת. זיהוי root ו-hooking, אימות session בצד השרת ו-rate limiting סוגרים אחרות.


ביומטריה מבוססת callback מול ביומטריה שקשורה ל-CryptoObject

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

איך Mobian עוזרת

ב-Mobian, ביומטריה שקשורה ל-CryptoObject הייתה אחד ממנגנוני ההגנה בתוכנית תיקון של 124 משימות לאפליקציית ה-Android של בנק קמעונאי, לצד הגנה מפני overlay, זיהוי hooking ואמולטורים, ובדיקות נגד repackaging. כל מנגנון אומת על ידי חבילת בדיקות אבטחה עצמאית של QA, ולא רק על ידי המפתח שבנה אותו.

סיכום

התחברות ביומטרית שסומכת על callback חזקה רק כמו המכשיר שעליו היא רצה. קישור ההתחברות למפתח ב-Keystore שהמערכת משחררת רק אחרי התאמה אמיתית אומר ש-callback מזויף לא משיג לתוקף כלום. חוויית המשתמש נשארת זהה; ההבדל מתגלה רק כשמישהו מנסה לרמות.

שאלות נפוצות

מה הבעיה בבדיקה של callback ההצלחה הביומטרי בלבד?

אם אפליקציה פותחת session ברגע ש-onAuthenticationSucceeded נקרא, תוקף עם כלי hooking כמו Frida על מכשיר פרוץ יכול לקרוא למתודה הזו ישירות. האפליקציה רואה הצלחה בלי שטביעת אצבע או פנים נבדקו אי פעם.

מה זה CryptoObject בביומטריה של Android?

CryptoObject עוטף פעולה קריפטוגרפית, כמו Cipher או Signature, שמשתמשת במפתח מה-Android Keystore. כשהמפתח נוצר כך שהוא דורש אימות משתמש, הפעולה עובדת רק אחרי בדיקה ביומטרית אמיתית של המערכת. callback מזויף נותן לתוקף cipher שאי אפשר להשתמש בו.

האם ביומטריה שקשורה ל-CryptoObject מגינה מפני כל מתקפה?

לא. היא סוגרת את הפרצה של callback מזויף, אבל צריך לשלב אותה עם מנגנוני הגנה נוספים, כמו זיהוי root ו-hooking, בדיקות session בצד השרת ו-fallback ל-PIN או לסיסמה. אין מנגנון יחיד שהופך אפליקציה למאובטחת.

מה קורה כשמשתמש רושם טביעת אצבע חדשה?

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

לאיזו קטגוריה של OWASP זה נותן מענה?

בעיקר ל-M3: Insecure Authentication/Authorization ב-OWASP Mobile Top 10 (2024). קישור המפתח לביומטריה תומך גם בפרקטיקה טובה ב-M10, Insufficient Cryptography.

הערכה ללא עלות · ללא התחייבות

מתכננים פיתוח על ה-stack הזה?

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

  • 1אנחנו עוברים על המוצר, ה-stack ומפת הדרכים שלכם
  • 2אנחנו מצביעים על הסיכונים שראינו בפרויקטים דומים
  • 3תוך 48 שעות מקבלים הרכב צוות ולוח זמנים משוער

ספרו לנו על הפרויקט

מעדיפים לדבר קודם? קבעו שיחה של 30 דקות