Case Study: מציון MobSF של 48/100 ל-124 תיקוני אבטחה במעקב בתשעה שבועות
כך שחזרנו את ציון ה-MobSF של בנק קמעונאי, ביצענו אודיט לאפליקציית ה-Android שלו מול OWASP Mobile Top 10 (2024), דירגנו 48 פערים לפי CVSS והפכנו אותם ל-124 משימות.
רוב חברות הפיתוח מוכרות אבטחה כתואר שם. ה-case study הזה הוא תיעוד מסודר: בנק קמעונאי אמיתי, ציון סורק אמיתי, 48 פערים מדורגים, 124 משימות ורשימה כנה של מה שעדיין פתוח.
אפליקציית ה-Android של הבנק בנויה על SDK בנקאי מסוג white-label. כשהסריקה של הבנק עצמו החזירה ציון אבטחה של 48 מתוך 100 ב-MobSF, השאלה לא הייתה רק איך להעלות את המספר. השאלה הייתה מה המספר באמת אומר, אילו פערים אמיתיים, ואיך לתקן אותם בצורה שצוות האבטחה של הבנק יוכל לבדוק.
במאמר הזה נעבור על האופן שבו בוצע האודיט, מה כלל התיקון, איך התיקונים אומתו, ומה עדיין פתוח.
נקודת המוצא
ציון של 48/100 נשמע מדאיג, אבל ציון גולמי אומר מעט בפני עצמו. לפני כל תיקון, היינו צריכים לענות על שלוש שאלות:
-
האם אפשר לשחזר את הציון? אם לא נצליח לקבל את אותה תוצאה, לא נוכל להוכיח שיפור בהמשך.
-
אילו ממצאים אמיתיים? סורקים מערבבים חולשות אמיתיות עם רעש של קונפיגורציית build ועם false positives.
-
מה הסורק מפספס? כלים אוטומטיים רואים את הקובץ הבינארי, לא את הלוגיקה. תהליכי אימות, ניהול מפתחות ואחסון מידע דורשים סקירה אנושית.
📌 תובנה מרכזית:
ציון של סורק הוא המקום שבו אודיט מתחיל, לא המקום שבו הוא נגמר. התוצר השימושי הוא רשימה של פערים אמיתיים ומדורגים שלכל אחד מהם יש אחראי.
איך בוצע האודיט
שלב 1: שחזור ציון הסורק
בנינו מחדש את הסריקה ושחזרנו את התוצאה של הבנק. אחר כך חילקנו כל נקודה שהאפליקציה איבדה לקטגוריות. הממצא שהפתיע את הבנק יותר מכול: 6–7 מתוך 52 הנקודות החסרות נבעו רק מסוג ה-build — הסריקה הורצה על build של debug ולא על ה-build של release שהמשתמשים באמת מתקינים. ושתי בדיקות שהסורק סימן כמאובטחות התבררו כ-false positives.
שלב 2: אודיט ידני מול OWASP Mobile Top 10 (2024)
סקרנו את האפליקציה קטגוריה אחר קטגוריה מול OWASP Mobile Top 10 (2024), משימוש לא תקין בפרטי הזדהות (M1) ואבטחת שרשרת האספקה (M2) ועד אחסון מידע לא מאובטח (M9) וקריפטוגרפיה לא מספקת (M10). כל פער קיבל ציון CVSS, כך שהבנק יכול היה לתעדף לפי חומרה ולא לפי כמה מדאיג ממצא נשמע.
התוצאה: 48 פערים מדורגים לפי CVSS.
שלב 3: תוכנית תיקון עם הערכת עלויות
48 הפערים פורקו ל-124 משימות במעקב. כל שינוי לווה במסמך קצר וכתוב של איום והחלטה: מה הסיכון, איזו אפשרות בחרנו, מה דחינו ולמה. במקומות שבהם הבנק החליט לקבל סיכון במקום לתקן אותו, גם ההחלטה הזו תועדה.
שלב 4: תיקון והקשחה
לצד תיקון הממצאים, בנינו ובדקנו סט של מנגנוני הגנה בזמן ריצה ונגד ניצול לרעה, ובהם:
-
הגנה מפני overlay בשלוש שכבות, ובנוסף מסווג (classifier) לזיהוי ניצול לרעה של accessibility services.
-
התחברות ביומטרית שקשורה ל-CryptoObject, כך ש-callback שעבר hooking לא יכול לזייף התחברות מוצלחת.
-
זיהוי root, Frida ואמולטורים, עם 35 טסטים לזיהוי אמולטורים לפי ערכים מדויקים ובלי false positives על Chromebooks.
-
הגנה מפני repackaging באמצעות בדיקת תעודת החתימה ובדיקת ה-installer.
-
ניקוי ה-clipboard אחרי 60 שניות עבור ערכים רגישים שהועתקו.
-
TLS 1.3 בלבד לתעבורת הרשת.
-
Envelope Encryption למידע מקומי במקום SQLCipher, שחסכה 6.5 MB של קוד native בעלות של כ-1 ms לכל מסך.
איך התיקונים אומתו
תיקונים שרק המפתח בדק הם טענות, לא ראיות. האימות התבצע בשתי שכבות.
חבילת בדיקות אבטחה עצמאית של QA
צוות ה-QA בנה חבילת אימות אבטחה של 79 בדיקות סקריפטיות שמכסות 45 טיקטים של אבטחה. כל בדיקה מאשרת שמנגנון ספציפי עובד על build אמיתי.
לבדוק את הבדיקות
אחר כך בדקנו את חבילת ה-QA עצמה באמצעות mutation testing: שבירה מכוונת של מנגנוני אבטחה ב-builds של בדיקה ווידוא שהבדיקות תופסות כל שבירה. ה-runner תפס את כל המוטנטים. ולא פחות חשוב, 13 מהמוטנטים האלה שרדו את הטסטים של המפתחים עצמם — בדיוק הפערים שבדיקה עצמאית נועדה למצוא.
ראיות לשרשרת האספקה ב-CI
כל גרסה יוצאת היום עם CycloneDX SBOM, והתלויות נסרקות עם OWASP Dependency-Check. הסריקה הראשונה הפיקה 1,388 התאמות CVE גולמיות. כל אחת מהן עברה triage וסומנה כ-suppressed עם נימוק כתוב ומתוארך, ואף אחת לא התבררה כחולשה אמיתית ב-APK של ה-release.
התוצאות במבט אחד
| פריט | תוצאה |
| ציון MobSF התחלתי | 48/100, משוחזר |
| נקודות שמוסברות בסוג ה-build בלבד | 6–7 מתוך 52 |
| סימוני "מאובטח" של הסורק שהתבררו כשגויים | 2 |
| פערים מדורגים לפי CVSS | 48 |
| משימות תיקון במעקב | 124 |
| בדיקות אבטחה של QA | 79 בדיקות על פני 45 טיקטים |
| התאמות CVE גולמיות שעברו triage | 1,388 → 0 אמיתיות |
| משך | כתשעה שבועות |
מה עדיין פתוח
אנחנו מפרסמים את הפערים יחד עם התוצאות, כי זה מה שהופך את השאר לאמין:
-
עדיין אין ציון סופי מחדש או pentest חיצוני. אנחנו לא טוענים לציון MobSF סופי, למבדק חדירות שעבר בהצלחה או לעמידה מלאה ב-OWASP MASVS.
-
Certificate pinning מוכן ומחכה למדיניות החלפת המפתחות של הבנק לפני שיופעל.
-
סריקת התלויות מדווחת, אבל עדיין לא חוסמת גרסאות בגלל ממצאים בחומרה גבוהה.
ה-Mobile Security Teardown של Mobian
הפרויקט הזה הפך לתבנית של ה-Mobile Security Teardown שלנו: שבועיים, מחיר קבוע. אנחנו משחזרים את ציון הסורק שלכם, מבצעים אודיט ידני מול OWASP Mobile Top 10 (2024), מדרגים כל פער לפי CVSS ומוסרים תוכנית תיקון עם הערכת עלויות שהצוות שלכם — או שלנו — יכול לבצע.
ב-Mobian, אנחנו לא חברת compliance ולא נגיד לכם שאודיט הופך אתכם לעומדים בדרישות. מה שאנחנו מספקים הוא ראיות שהמבקר שלכם יכול לעקוב אחריהן, עד רמת הקובץ והשורה.
סיכום
ציון MobSF של 48/100 אמר לבנק שמשהו לא בסדר, אבל לא מה. שחזור הציון, אודיט ידני מול OWASP, דירוג כל פער ואימות כל תיקון הפכו מספר מדאיג אחד ל-124 משימות עם אחראים, שאפשר לעקוב אחריהן. אם מישהו — בנק שותף, מבקר, רגולטור — כבר מצא בעיה באפליקציית המובייל שלכם, זה המקום להתחיל.
שאלות נפוצות
מה כלל אודיט האבטחה?
ארבעה דברים: שחזור של סריקת ה-MobSF של הבנק עצמו, אודיט ידני של אפליקציית ה-Android מול כל עשר הקטגוריות של OWASP Mobile Top 10 (2024), ציון CVSS לכל פער שנמצא, ותוכנית תיקון עם הערכת עלויות. התיקון ואימות QA עצמאי בוצעו בהמשך, באותו פרויקט.
האם האפליקציה עברה מבדק חדירות אחרי התיקונים?
אנחנו לא טוענים את זה. עדיין לא בוצעו מבדק חדירות חיצוני או סריקת MobSF סופית מחדש. מה שאנחנו יכולים להראות הוא תיעוד מתוארך וממוספר: 48 פערים מדורגים, 124 משימות במעקב, וחבילת QA שמאמתת את התיקונים ושנבדקה בעצמה מול builds שבורים בכוונה.
האם ציון MobSF מספיק כדי לשפוט את האבטחה של אפליקציה?
לא. בפרויקט הזה, 6–7 מתוך 52 הנקודות החסרות נבעו רק מסריקה של build של debug במקום build של release, ושתי בדיקות שהסורק סימן כמאובטחות התבררו כ-false positives. ציון הוא נקודת התחלה לאודיט ידני, לא פסק דין.
האם העבודה הזו הופכת אפליקציה לעומדת ב-DORA או ברגולציות אחרות?
Mobian היא לא חברת compliance, ואודיט לבדו לא הופך אפליקציה לעומדת בדרישות. מה שהוא מייצר הוא ראיות שמבקר יכול לעקוב אחריהן: ממצאים מדורגים, החלטה כתובה לכל שינוי, תיקון ברמת הקובץ ותוצאות QA עצמאיות. צוותי ה-compliance והמשפטית שלכם מחליטים מה הראיות האלה מכסות.
האם אותם מנגנונים יכולים להגן על אפליקציות קריפטו או גיימינג?
רבים מהם, כן. הגנה מפני overlay, זיהוי ניצול לרעה של accessibility, זיהוי hooking ואמולטורים, ובדיקות נגד repackaging מכוונים לדפוסי ניצול שנראים אותו דבר בכל אפליקציות הכסף. לא בנינו פיצ'רים ייעודיים לנישה, כמו key custody או מיקום גאוגרפי מאושר, ואנחנו אומרים את זה מראש.