RASP שלא נועל בחוץ לקוחות אמיתיים
הגנת runtime עוצרת כלי hooking, אמולטורים ואפליקציות שעברו repackaging, אבל זיהוי גרוע חוסם משתמשים אמיתיים. כך בנינו RASP עם מעט false positives ו-kill-switch.
הגנת runtime, או RASP, היא היום דבר מצופה באפליקציות בנקאות ובאפליקציות כסף אחרות. בנקים שותפים, מבקרים וצוותי מניעת הונאות מבקשים זיהוי root, זיהוי hooking ובדיקות anti-tampering.
החלק הקשה הוא לא לזהות איומים. החלק הקשה הוא לזהות אותם בלי לחסום לקוחות אמיתיים. בדיקה שנועלת בחוץ משתמש אמיתי במכשיר לא שגרתי היא קריאת תמיכה, ביקורת גרועה ולפעמים לקוח שהלך.
במאמר הזה נעבור על האופן שבו בנינו ואימתנו הגנת runtime לאפליקציית ה-Android של בנק קמעונאי, ועל החלטות התכנון ששמרו על מעט false positives.
מה האפליקציה הייתה צריכה לזהות
-
frameworks של hooking כמו Frida, שיכולים לשנות את התנהגות האפליקציה בזמן ריצה.
-
מכשירים עם root, שבהם מנגנוני ההגנה של מערכת ההפעלה כבר לא תקפים.
-
אמולטורים, שמשמשים לעיתים קרובות לניצול אוטומטי בקנה מידה גדול.
-
אפליקציות שעברו repackaging, שעברו שינוי והופצו מחדש מחוץ לחנות הרשמית.
-
ניצול לרעה של overlay ושל accessibility, טכניקה נפוצה של נוזקות בנקאות.
📌 תובנה מרכזית:
לכל מנגנון זיהוי יש שני מצבי כשל: לפספס מתקפה, ולסמן משתמש תמים. רוב הדיונים על RASP מדברים רק על הראשון.
החלטות תכנון ששמרו על מעט false positives
1. ערכים מדויקים, לא היוריסטיקות רופפות
הרבה בדיקות אמולטור מחפשות מילים חשודות במאפייני המכשיר. זה תופס גם חומרה אמיתית עם שמות לא שגרתיים. עברנו לזיהוי אמולטורים לפי ערכים מדויקים, שמכוסה ב-35 טסטים, ווידאנו שאין אף false positive על Chromebooks, שמריצים אפליקציות Android ולעיתים קרובות מכשילים בדיקות נאיביות.
2. מסווגים שנבדקו על אפליקציות אמיתיות
לזיהוי autoclickers בנינו מסווג (classifier) ובדקנו אותו מול אפליקציות אמיתיות, לא רק מול דוגמאות מעבדה. ההתנהגות על תוכנה אמיתית היא המקום שבו מסווג או זוכה באמון, או מתחיל לחסום משתמשים תמימים.
3. בדיקות זהות שלא תלויות במכשיר
ההגנה מפני repackaging משתמשת בבדיקת תעודת החתימה ובבדיקת ה-installer. שתיהן בודקות את האפליקציה עצמה, ולכן מתנהגות אותו דבר בכל טלפון.
4. kill-switch לכל מנגנון זיהוי
הזיהוי בזמן ריצה יושב מאחורי kill-switch מרחוק. אם דגם טלפון חדש מתחיל להפעיל בדיקה, הצוות לא צריך לחכות לשחרור גרסה בחנות כדי להפסיק לנעול אנשים בחוץ.
איך אימתנו את זה
מטריצת האימות הריצה כל תרחיש על builds של בדיקה:
| תרחיש | תוצאה צפויה |
| Frida מחובר לאפליקציה | מסך חסימה תוך 5 שניות |
| האפליקציה הופעלה על אמולטור | נחסמת |
| האפליקציה הופעלה על טלפון אמיתי | עובדת כרגיל |
בדיקת השורות של "צריך לעבור" חשובה בדיוק כמו בדיקת השורות של "צריך לחסום". שם נתפסים false positives לפני שהלקוחות מגלים אותם.
מה RASP לא עושה
-
הוא לא הופך אפליקציה לבלתי שבירה. תוקף נחוש יכול לעקוף בדיקות בצד הלקוח אם יש לו מספיק זמן.
-
הוא לא מחליף מנגנוני הגנה בצד השרת, כמו אימות session ודירוג סיכוני הונאה.
-
הוא לא מכסה דרישות ספציפיות לתעשייה, כמו מיקום גאוגרפי מאושר לאפליקציות הימורים.
מה שהוא עושה טוב: מעלה את המחיר של מתקפות נפוצות, עוצר כלים מהמדף וניצול אוטומטי, ונותן ל-backend סיגנלים לפעול לפיהם.
איך Mobian עוזרת
ב-Mobian, מנגנוני ה-runtime האלה היו חלק מתיקון ממצאי אבטחה עבור בנק קמעונאי, שהתחיל מציון MobSF של 48/100 והניב 124 תיקונים במעקב. אנחנו מתכננים את מנגנוני הזיהוי עבור המשתמשים שיש לכם, לא רק עבור התוקפים שאתם חוששים מהם — עם טסטים לשני הצדדים, ועם דרך לכבות בדיקה אם היא מתנהגת לא כמו שצריך.
סיכום
RASP טוב נמדד משני הצדדים: כמה מהר הוא עוצר כלי hooking, וכמה לעיתים רחוקות הוא מפריע ללקוח אמיתי. בדיקות לפי ערכים מדויקים, מסווגים שנבדקו על אפליקציות לגיטימיות, בדיקות זהות שלא תלויות במכשיר ו-kill-switch מרחוק מאפשרים לחסום את Frida תוך שניות, בזמן שלקוח עם Chromebook לא מרגיש בכלום.
שאלות נפוצות
מה זה RASP באפליקציית מובייל?
Runtime Application Self-Protection (RASP) הוא סט של בדיקות שאפליקציה מריצה על עצמה בזמן השימוש: זיהוי root, כלי hooking כמו Frida, אמולטורים, debuggers וגרסאות של האפליקציה שעברו repackaging. כשבדיקה מזהה משהו, האפליקציה יכולה לחסום, להגביל פיצ'רים או לדווח לשרת.
למה בדיקות RASP גורמות ל-false positives?
הרבה מנגנוני זיהוי נשענים על היוריסטיקות רופפות, כמו חיפוש מילים שמזוהות עם אמולטורים במאפייני המכשיר. גם מכשירים אמיתיים, כולל Chromebooks שמריצים אפליקציות Android, יכולים להתאים לדפוסים האלה. false positive נועל לקוח משלם מחוץ לחשבון שלו עצמו.
מה זה kill-switch ל-RASP?
הגדרה מרחוק שמאפשרת לצוות לנטרל או להקל מנגנון זיהוי ספציפי בלי לשחרר גרסה חדשה של האפליקציה. אם בדיקה מתחילה לחסום משתמשים אמיתיים במכשיר מסוים, הצוות יכול לכבות אותה תוך דקות בזמן שמכינים תיקון.
האם RASP יכול לעצור תוקף נחוש?
לא. תוקף מיומן עם מספיק זמן יכול לעקוף בדיקות בצד הלקוח. RASP מעלה את המחיר של מתקפות, עוצר כלים נפוצים וניצול אוטומטי, ונותן לשרת סיגנלים לפעול לפיהם. הוא משלים תכנון מאובטח ומנגנוני הגנה בצד השרת; הוא לא מחליף אותם.
האם RASP שימושי גם מחוץ לעולם הבנקאות?
כן. חוות אמולטורים, autoclickers ואפליקציות שעברו repackaging מניעים ניצול לרעה של בונוסים במשחקים והונאות באפליקציות קריפטו. אותם מנגנוני זיהוי רלוונטיים, אם כי לכל תעשייה יש גם דרישות ספציפיות, כמו מיקום גאוגרפי מאושר, ש-RASP לא מכסה.