שער ה-VPN שלכם נפרץ: מה באמת נחשף
שער VPN שנפרץ רואה בתוך המנהרה שלו, אבל זה לא שליטה בכל הפעלה. הפרידו בין תעבורה, טווח נגישות וסודות מאוחסנים לפני השחזור.
שער VPN נמצא בקצה המנהרה שהוא מגן עליה, כלומר הוא מסיים את ההצפנה הזו במקום להעביר אותה הלאה. אם תוקף שולט במארח, המנהרה ממשיכה להיראות תקינה מבחוץ בעוד המכונה שבאמצע אינה אמינה עוד. השאלה השימושית אינה אם הכול מפוענח. היא מה המארח הזה יכול היה לראות, לאן הוא יכול היה להגיע ואילו סודות היו באמת מאוחסנים עליו. שלוש התשובות שונות מאוד, והתגובה שונה יחד איתן.
השער מסיים את המנהרה, ולכן רואה לתוכה
הצפנה ב-VPN עובדת קפיצה אחר קפיצה, והשער הוא הקפיצה. הוא מסיר את השכבה החיצונית, מחיל מדיניות ומעביר את החבילה הפנימית, כך שכל חבילה מועברת קיימת בצורה קריאה בזיכרון של אותו מארח בשלב כלשהו. זהו התכנון ולא פגם. זו גם הסיבה שפריצת השער היא אירוע שונה מפריצת ההצפנה של המנהרה.
מה שהתוקף מרוויח קודם הוא עמדה: היכולת לצפות בתעבורה מועברת, לשנות העברה או להשיב במקום שרת קצה. מה שהוא מרוויח אחר כך תלוי במארח, וכאן אנשים מגזימים. גישה לשער לבדה אינה מוסרת את מפתחות הפעלה של TLS של הדפדפן, כי הם מעולם לא היו על השער.
שלושה חשיפות שאינן באותו גודל
חלקו את השאלה לתעבורה מועברת, למערכות נגישות ולסודות מאוחסנים, ואז השיבו לכל אחת בנפרד.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
השורה האמצעית היא זו שמדלגים עליה. לשער יש בדרך כלל מסלול אל רשתות פרטיות וכתובת מקור ששרתי הקצה כבר סומכים עליה, ולכן השאלה המעניינת היא מה אותם שרתי קצה מתירים מאותה כתובת. מדיניות גישה מצומצמת ללקוחות היא בקרה טובה, אבל תוקף על המארח אינו מוגבל לממשק שלקוח רגיל היה משתמש בו.
השורה התחתונה קובעת כמה זמן יימשך האירוע. למפתח שרת ולמפתח CA רדיוסי השפעה שונים לחלוטין, וכך גם לחשבון מנהל מקומי ולאסימון ניטור לקריאה בלבד.
HTTPS בתוך המנהרה נשאר HTTPS
ה-TLS של היישום מסתיים ביישום, לא בשער ה-VPN, ולכן שער שנפרץ רואה טקסט מוצפן עבור הזרימות האלה. זו מגבלה אמיתית על מה שהתוקף משיג, וכדאי לומר אותה בבירור, כי הטענה ההפוכה מפיצה בהלה והחלטות גרועות. שני תנאים שוברים אותה. אם ברכיב בדיקה עם תעודה מהימנה נמצא בנתיב, השער עשוי לראות טקסט גלוי לפי התכנון. אם נקודת הקצה של היישום עצמה נפרצה, המנהרה אינה רלוונטית.
לכן התשובה לשאלה מה הם ראו מותנית, ויש לתעד אותה כתנאים ולא להכריז עליה כפסק דין.
מה חייב להשתנות לפני שתבטחו בו שוב
בנייה מחדש של המארח הכרחית ולעיתים רחוקות מספיקה. תוקף שעדיין מחזיק בחשבון ניהול, באישור פריסה או במפתח חתימה יכול להחזיר את המארח לקדמותו כרצונו. השחזור חייב להתחיל בנתיב ניהול שאינו תלוי במכונה שנפרצה.
ערכו מלאי של מה שהיה עליו לפני שהחליטו מה לסובב. מפתחות, חשבונות שירות, אסימוני API, משתמשים מקומיים, משימות מתוזמנות, יחסי אמון וצינור הפריסה כולם מועמדים, ולכל אחד יש בעלים שאמור לאשר אותו.
ss -lntup
getent passwd
crontab -l
ip route show table allהרשימה הזו היא הדרך המהירה ביותר לראות מה המארח הציע ולאן יכול היה להגיע. שמרו קודם את הראיות, לפי התהליך של בעל התגובה, כי בנייה מחדש הורסת בדיוק את מה שחקירה זקוקה לו. NIST SP 800-61 מהדורה 3 מתייחס להכנה, זיהוי, תגובה ושחזור כחלקים מתהליך סיכון אחד ולא כהוראת אתחול.
גבולות שעושים את הבא לזול יותר
כדאי לבנות ארבעה גבולות לפני שתזדקקו להם. שמרו נתיב שחזור עצמאי שאינו מאמת דרך השער. שמרו את סמכות החתימה בנפרד מהמארח שמגיש תעבורה. הגבילו לאן השער יכול להגיע, כך ששער שנפרץ לא יהיה אוטומטית רשת ניהול שנפרצה. ותעדו למי שייך כל אישור, כך שסיבוב יהיה שיחת טלפון ולא פרויקט ארכיאולוגי.
אף אחד מאלה אינו מונע פריצה. הם תוחמים אותה, ועושים את ההבדל בין שבוע רע לרבעון רע.