למה תעבורת ניפוי אלחוטי אינה הוכחה לדליפת VPN
הפעלת ADB מותאמת דרך Wi-Fi מוכיחה יחסי ניפוי, לא נתיב יציאה לאינטרנט. זה מה שהתצפית הזו באמת מכסה.
הפעלתם ניפוי אלחוטי, חיברתם מחשב נייד, וההפעלה המשיכה לעבוד בזמן שה-VPN היה פעיל. זה נראה כאילו משהו חמק מן המנהרה. כמעט בוודאות לא. הפעלת ניפוי ובקשה של אפליקציה לאתר הם יחסי רשת שונים, ורק אחד מהם אמור לחצות את המנהרה.
נתקלתי בקריאה השגויה הזו פעמיים: פעם אחת כשהטלפון והמחשב הנייד היו על אותו Wi-Fi, ופעם אחת לאחר אתחול כשההתאמה שרדה. בשני המקרים ה-VPN עשה בדיוק את מה שהוגדר לעשות.
תנו שם לתצפית לפני שאתם נותנים שם לבאג
שלושה אירועים יכולים להקדים טענת דליפה, והם אינם ניתנים להחלפה. כלי יכול לגלות שירות, המכשיר יכול לאשר תחנת עבודה, או הפעלה מורשית יכולה בפועל להעביר פקודות ובתים. רשמו איזה מהם ראיתם, כי כל אחד מוכיח פחות ממה שאנשים מניחים.
הגילוי הוא בדרך כלל mDNS או סריקת פורטים. ההתאמה היא החלטת רישום שמתקבלת בטלפון, ומאושרת בקוד שהמשתמש מקליד. הפעלה חיה פירושה שתעבורה עברה בין שני נקודות קצה מותאמות. שום דבר מזה לא מתאר לאן הולכת בקשת ה-HTTPS של אפליקציה.
הצמידו את היעד, הממשק, משפחת הכתובות, חותמת הזמן ופרופיל המשתמש לאירוע. בלי הפרטים האלה לא ניתן להשוות את התצפית למדיניות הרשת המקומית המיועדת, או לגרסת ה-VPN שרצה אז.
למה שני הנתיבים לא נפגשים לעולם
ניפוי אלחוטי הוא חיבור נכנס אל המכשיר. adbd מאזין בפורט שמקושר לממשק ה-Wi-Fi, ותחנת העבודה מתחברת אליו לאחר ההתאמה. הכיוון חשוב: המחשב הנייד שלכם מגיע אל תוך הטלפון, ולא להפך. זה ההפך מדליפת יציאה.
תעבורת האינטרנט של אפליקציה יוצאת דרך ממשק המנהרה ש-VpnService מתקין, בהתאמה לפי UID וכללי ניתוב. adbd הוא דמון מערכת שרץ כמשתמש shell, לא אפליקציה בתוך מערך הניתוב הזה. הוא נשאר על קישור ה-Wi-Fi הבסיסי גם כשכל אפליקציה מוצמדת למנהרה.
מצב נעילה אוכף את המנהרה על אפליקציות מכוסות. הוא לא הופך שקע מאזין לנתיב יציאה.
לכן הפעלת ADB עובדת ומתג הרג עובד מתקיימים זה לצד זה בלי סתירה. כדי להוכיח דליפה, עליכם לצפות בכיוון שאמור להיות חסום.
איך נראית בדיקת יציאה באמת
בדקו את האפליקציה המכוסה, לא את ערוץ הניפוי. הקימו את תנאי הכשל במכוון, ואז שלחו בקשה חדשה אחת ותעדו מה קרה.
- ודאו שה-VPN הוא הנתיב היחיד: הפעילו VPN תמיד-פעיל עם חסימת חיבורים ללא VPN.
- עצרו את ה-VPN בדרך הנתמכת וודאו שהאפליקציה מדווחת שאין קישוריות.
- שלחו בקשה לא מזיקה אחת מאותה אפליקציה ורשמו אם היא נכשלת או מצליחה.
- חזרו על כך עם ניפוי אלחוטי פעיל ואחר כך כבוי, כדי לבודד את המשתנה.
בקשה חסומה בתנאים האלה היא ראיה. הפעלת ADB מוצלחת אינה, וגם לא פינג אחד מאפליקציית מסוף.
אם הבקשה אכן מצליחה כשמצב הנעילה פעיל, תעדו את ה-UID של האפליקציה ואת הרשאת ה-VPN שלה, את הרשת הפעילה ואת גרסת הלקוח. השילוב הזה הוא ממצא אמיתי.
ההתאמה שורדת את ההפעלה
ההתאמה היא מצב מתמשך, לא לחיצת יד ששוכחים אחרי בדיקת הכבל. תיעוד הניפוי של Android מתאר את זרימת העבודה האלחוטית ומציין שהקשר נמשך עד ששוכחים אותו במפורש או שההרשאות מבוטלות.
בדקו מה עדיין מורשה לפני שאתם מאשימים את המנהרה. פתחו ניפוי אלחוטי, הסתכלו על מכשירים מותאמים, ושכחו כל מה שאינכם מזהים עוד. הריצו adb devices מתחנת העבודה כדי לראות אילו רשומות עדיין עונות, ו-adb disconnect כדי להפיל רשומה מיושנת. כיבוי ניפוי אלחוטי סוגר את פורט ההאזנה לחלוטין.
ברשת משותפת או לא מהימנה, השאירו אותו כבוי. הרשאה מתמשכת ברשת שאינכם שולטים בה היא בעיה גדולה יותר מעקיפת TUN היפותטית.
לפני שתדווחו על הבאג הזה
דוח שימושי נוקב בגבול המדויק שנכשל. כללו את דגם המכשיר וגרסת Android, לקוח ה-VPN והגרסה, אם מצב הנעילה היה פעיל, חבילת האפליקציה וה-UID, והרשת שבה היה הטלפון. הוסיפו את הפקודה או הבקשה שהפיקה את התצפית, וגם את הזמן שבו זה קרה. בלי זה, איש לא יכול לשחזר את הגבול שאתם טוענים שנשבר.
אל תבטלו את האכיפה ואל תחשיפו ניפוי ברשת לא מהימנה כדי שהבדיקה תיראה דרמטית יותר. זה משנה את המערכת שאתם מודדים ומשאיר ראיות שאיש לא יכול לחזור עליהן.
אם הראיה היחידה שלכם היא ש-ADB התחבר בזמן שה-VPN פעל, מדדתם את הנתיב הלא נכון. הריצו קודם שוב את הבדיקה ברמת האפליקציה; התשובה בדרך כלל מגיעה שם.