IPA SC, סתיו 2023, שאלה 2 אחר-הצהריים — קבצים שיוצאים מ-Wi-Fi לאורחים

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

ועדיין אפשר להוציא קבצים עסקיים.

שאלת אחר-הצהריים 2 בסתיו 2023 (Reiwa 5) של בחינת IPA SC (Registered Information Security Specialist, 情報処理安全確保支援士) בוחנת את החורים שעדיין נשארו בחברת הביגוד M, אחרי כל הטיפולים האלה.¹ המאמר הזה הוא השני בסדרה אחרי הפירוש לשאלה 1 (stored XSS), וההיקף עובר מאפליקציית web אל הרשת הפנימית ואימות קצה.

בעוד ששאלה 1 שאלה “איפה עקפו את הטיפולים שסודרו באפליקציית ה-web”, שאלה 2 שואלת “איזה היקף התכוון התכנון של הטיפולים להגן עליו”. אף אחד מטיפולי M אינו שגוי. אבל כשבודקים אחד-אחד את ציון ההיקף שאותו הם שומרים, מיד מחוץ לו נשאר פתוח.

מה מקבלים במאמר הם דוגמאות תשובה לכל סעיף ואת הבסיס שלהן, ועוד נקודות בדיקה שאפשר לקחת לשטח בשלושה תחומים: Wi-Fi, server certificate, והגבלת כתובת IP מקור. מי שקורא לקראת הבחינה יכול להתחיל בסעיפים לפי שאלה; מי שצריך רק את המבט המעשי יכול להתחיל מפרקים 11 ו-12 והרצף יישאר מובן.

1. קודם כל, המסקנות

• הפרצה הייתה חדר הישיבות. M אסרה הכנסת מחשבים אישיים, אבל האיסור היה על חדר העבודה בלבד, וחדר הישיבות היה מחוץ להיקף. בחדר הישיבות טסות גם Wi-Fi לעובדים וגם זו לאורחים
• לעובד יש שני נתיבי הוצאה. שיטה שמזייפת כתובת MAC ומתחברת ל-Wi-Fi לעובדים, ושיטה שפשוט מתחברים ל-Wi-Fi לאורחים. השנייה קלה בהרבה; כל מה שצריך הוא ה-pre-shared key שמחלקים לאורחים
• שירות האחסון בענן (שירות B) הוגבל ל-“כניסה רק מכתובת ה-IP הגלובלית של M”. אבל גם תעבורת Wi-Fi לאורחים מתורגמת באותו NAT לאותה כתובת גלובלית, ולכן ההגבלה עוברת. הגבלת כתובת IP מקור מתירה לא את המחשב אלא את כל מי שחולק את היציאה
• AP מזויף + אתר מזויף מצד תוקף חיצוני נעצרים באימות server certificate. מה שפועל הם “האם CA מהימנה הנפיקה” ו”האם שם השרת ב-certificate תואם את היעד”. לפי הערות הציון של IPA, שיעור התשובות הנכונות לשאלה שביקשה את שתי הנקודות האלה היה נמוך
• גם אם מקלידים בטעות http://, HSTS מחליף ל-HTTPS ואז מתחבר, ולכן שוב מתקבלת שגיאת certificate. ובמארח עם HSTS אסור להציג למשתמש אפשרות להתעלם מהאזהרה ולהמשיך
• גם פונקציית שיתוף הקבצים הלגיטימית הופכת לנתיב הוצאה. מספיק לציין את כתובת הדואר הפרטית ככתובת המשתף החיצוני. הייתה אישור ממונה, אבל היו ממונים שלא בדקו את היעד
• שלושת עמודי הטיפול: להעביר את Wi-Fi לעובדים ל-EAP-TLS ולאמת ב-client certificate לכל מחשב, ולשים את המפתח הפרטי ב-TPM כך שאי אפשר להוציא אותו ממחשב העבודה. לנתק את Wi-Fi לאורחים מרשת M (או להפריד את כתובת ה-IP הגלובלית ביציאה). ולמחוק VLAN, כללי סינון ו-SSID שאינם בשימוש

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 24, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. על החומר — המקור, ואיך המאמר מטפל בו

השאלה היא זו:

מקור: בחינת IPA SC (Registered Information Security Specialist), סתיו 2023 (Reiwa 5), אחר-הצהריים, שאלה 2

IPA קובעת שלגבי שאלות בחינה שפורסמו אין צורך באישור או בתשלום, אלא אם החוק קובע אחרת. אבל זכויות היוצרים לא ויתרו עליהן, ויש לציין את המקור בפורמט “שנה, מועד, סוג בחינה, חלוקת זמן, מספר שאלה וכו’”, ואם שינו חלק מהשאלה — לציין גם זאת.²

במאמר אין העתקה כמות שהיא של האיורים מהחוברת. במקום זאת יש איורים מקוצרים וסיכומים שכתבנו בהיקף הדרוש להסבר המנגנון. גם נוסח הסעיפים ודוגמאות התשובה מטופלים כסיכום. את חוברת השאלות, דוגמאות התשובה והערות הציון אפשר להוריד בחינם מאתר IPA, ומומלץ לקרוא עם המקור פתוח ליד.^{1 3 4}

התאמה בין הסעיפים למאמר

אפשר להתחיל מהסעיף שרוצים לפתור.

תיאור החוברת, ואיך המאמר מטפל בו

כדי שאפשר יהיה להצליב מול המקור, זה מה שנעשה בכל חלק.

3. זירת השאלה — מה M “כבר עשתה”

M היא חברת בת של L, חברת ביגוד עם 100 עובדים. בניין המשרד פונה לשדרה סואנת בטוקיו. המשפט הזה יחזור בהמשך.

בשנה הקודמת עובד של M שמר קובץ עיצוב מוצר סודי משרת הקבצים הפנימי על USB והביא אותו למתחרה. בעקבות הנחיית חברת האם L מתקדם עדכון אבטחה. שלושת השינויים שכבר בוצעו:

• במחשבי הנייד שמושאלים לעובדים (להלן מחשבי עבודה) הותקנה תוכנת מניעת דליפת מידע, והוגדרו: איסור חיבור מדיה חיצונית כמו USB, איסור שמירת קבצים לדיסק מקומי מלבד התקנת תוכנה, חסימת תעבורה לדואר אינטרנט ולאחסון ענן שהחברה לא אישרה, איסור התקנת תוכנה שהחברה לא אישרה, ואיסור צירוף קבצים בשליחת דואר
• מקום שמירת הקבצים העסקיים רוכז לאחסון הענן שהיה בשימוש קודם (להלן שירות B), וההגדרות עודכנו
• שרת הקבצים הפנימי בוטל

האירוע הקודם היה הנתיב “שרת קבצים פנימי” → “USB”, ולכן סגרו את שני הקצוות. ההיגיון מחזיק.

תצורת הרשת

בבניין יש חדר עבודה וחדר ישיבות. בחדר העבודה זמין Wi-Fi לעובדים; בחדר הישיבות זמינות גם לעובדים וגם לאורחים. את המקרן בחדר הישיבות מפעילים כשמחברים מחשב אורח (מחשב, טאבלט או טלפון שאורח מביא) או מחשב עבודה ל-Wi-Fi לאורחים.

בהיקף הדרוש להסבר, הצורה היא זו:

flowchart LR
    accTitle: תצורת הרשת של חברת M
    accDescr: Wi-Fi לאורחים, Wi-Fi לעובדים ורשת השרתים מומרות ב-NAT של אותו FW לכתובת IP גלובלית אחת ויוצאות לשירות B
    subgraph M["הרשת הפנימית של חברת M"]
        direction TB
        G["Wi-Fi לאורחים<br/>192.168.10.0/24<br/>(רק ה-AP בחדר הישיבות)"]
        E["Wi-Fi לעובדים<br/>192.168.20.0/24<br/>(חדר עבודה וחדר ישיבות)"]
        S["רשת שרתים<br/>192.168.30.0/24<br/>DHCP, DNS, directory"]
        FW["FW<br/>NAT ממיר את המקור<br/>לכתובת IP גלובלית<br/>אחת"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["שירות B<br/>(אחסון ענן)"]
    FW --> I["אינטרנט"]

איור 1: Wi-Fi לאורחים, Wi-Fi לעובדים ורשת השרתים יוצאות לאינטרנט ב-NAT של אותו FW ככתובת IP גלובלית אחת.

המפרט שחשוב לסעיפים:

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

שמתם לב שהכלל השני כותב “לחדר העבודה”? חדר הישיבות אינו כתוב.

איך השאלה מתקדמת

גב’ Y מצוות IT, בסיוע מר S — מומחה IPA SC בחברת האם L — בודקת אם הטיפול בהוצאת קבצים משירות B מספיק. השניים מפרידים בין הוצאה בידי תוקף חיצוני לבין הוצאה בידי עובד. סעיף 1 הוא הראשון, סעיף 2 השני, סעיף 3 הוא הצעת הטיפול.

4. Wi-Fi מזויף ואתר מזויף — סעיפים 1(1)(2)

גב’ Y מעלה תחילה תרחיש שבו אורח שהשתמש ב-Wi-Fi לאורחים מתחבר אליה כתוקף מקרבת M וניגש לשירות B.

התרחיש מתקיים כי שיטת האימות היא WPA2-PSK. PSK (Pre-Shared Key) הוא, כשמו, אופן שבו כולם חולקים אותו מפתח. ה-pre-shared key של רשת האורחים נועד להיאמר לאורחים. ברגע שאמרו אותו, אין דרך לבטל את זה שהאדם יידע אותו גם להבא (מלבד לשנות לכולם). ובניין המשרד פונה לשדרה סואנת, ולכן הגל מגיע גם מחוץ למבנה.

תשובת מר S ברורה. כדי להיכנס לשירות B נדרשים [a] מזהה משתמש ו-[b] סיסמה. זו דוגמת התשובה לסעיף 1(1) (סדר חופשי). חיבור ל-Wi-Fi עצמו אינו כניסה לשירות B.

AP מזויף ואתר מזויף

אז גב’ Y מעמיקה. מה לגבי שיטה שמכינים AP מזויף באותן הגדרות כמו ה-AP של רשת האורחים, ואתר מזויף באותו URL כמו שירות B, מזייפים DNS, וגונבים מזהה וסיסמה. אם שמים את ה-AP המזויף ליד M, עובד של M עלול לחבר בטעות את מחשב העבודה ל-AP המזויף, לנסות לגשת לשירות B, להגיע לאתר המזויף, ולהיכנס.

זה evil twin. אם מקימים AP באותו SSID ובאותו pre-shared key כמו רשת האורחים, מהמחשב אי אפשר להבדיל בינו לבין ה-AP הלגיטימי. ב-WPA2-PSK כל מה שהמחשב יכול לאשר על ה-AP הוא ש”הוא יודע את אותו pre-shared key”. AP שלא יודע את המפתח לא יכול לסיים את הליך החיבור, ולהפך — כל מי שיודע את המפתח יכול להיות “ה-AP האמיתי”. מפתח שמחלקים לאורחים צריך לראות כמפתח שמחולק גם לתוקף.

גם כאן תשובת מר S ברורה. כשעובד מנסה לגשת לאתר המזויף ב-HTTPS, יחד עם הודעת שגיאה שהחיבור אינו בטוח, הדפדפן מציג לפחות אחד מארבעת הסעיפים הבאים, לפי ה-server certificate שבו השתמשו באתר המזויף.

• ה-server certificate הזה אינו server certificate שהונפק על ידי CA מהימנה (משבצת c)
• שם השרת הרשום ב-server certificate הזה שונה משם השרת שאליו מתחברים (משבצת d)
• ה-server certificate הזה בוטל
• פג תוקף ה-server certificate הזה

שני התחתונים היו כתובים בחוברת מההתחלה, ואת שני העליונים (משבצות c ו-d, עד 40 תווים, סדר חופשי) עונים בסעיף 1(2).

sequenceDiagram
    accTitle: AP מזויף ואתר מזויף נעצרים באימות certificate
    accDescr: חיבור HTTPS של עובד דרך AP מזויף נכשל כי ה-certificate לא הונפק על ידי CA מהימנה או ששם השרת אינו תואם, ומסך הכניסה אינו מוצג
    autonumber
    participant U as מחשב העבודה של העובד
    participant F as AP מזויף ואתר מזויף<br/>(תוקף)
    participant B as שירות B (לגיטימי)

    Note over F: מקימים AP באותו SSID ובאותו<br/>pre-shared key כמו רשת האורחים
    U->>F: חיבור בטעות ל-AP המזויף
    Note over F: מזייפים DNS ומפנים את שם<br/>הדומיין של שירות B לאתר המזויף
    U->>F: חיבור ב-HTTPS ל-URL של שירות B
    F-->>U: server certificate של האתר המזויף
    Note over U: האימות נכשל<br/>· לא הונפק על ידי CA מהימנה<br/>· שם השרת ב-certificate שונה מהיעד
    Note over U: מציגים שגיאה שהחיבור אינו בטוח<br/>מסך הכניסה אינו מוצג
    Note over U,B: מלכתחילה אין תקשורת<br/>עם שירות B הלגיטימי

איור 2: גישת HTTPS דרך AP מזויף נכשלת באימות server certificate; מסך הכניסה אינו מוצג.

מה אימות ה-certificate בודק

הערות הציון כותבות על הסעיף הזה כך:

בסעיף 1(2) שיעור התשובות הנכונות היה נמוך. גם אם תוקף מכין אתר מזויף, כל עוד הגישה היא ב-HTTPS אימות server certificate ייכשל. אימות server certificate הוא ידע בסיסי להבטחת בטיחות התקשורת, ולכן רוצים שיבינו גם אילו פריטים בודקים בפועל.

גם מי שיודע ש”מופיעה שגיאת certificate” התקשה לפרק מה נבדק ולמה זה נכשל לארבעה סעיפים. אם מסדרים את ארבעת הסעיפים באיור 2 לפי “לשם מה הבדיקה”:

מבחינת התוקף, שני העליונים הם חומה שאי אפשר לעבור. Certificate self-signed נופל בראשון; גם certificate חינמי לגיטימי לדומיין שלו (למשל b-service.example.net) נופל בשני, כי היעד הוא דומיין שירות B. Certificate לשם הדומיין של שירות B אפשר להשיג רק אם מנהלים את הדומיין של שירות B. הצירוף של שתי הנקודות האלה הוא ליבת מנגנון ה-certificates.

הליך אימות נתיב ה-certificate מוגדר ב-RFC 5280,⁵ והליך התאמת השם ב-certificate לשם היעד ב-RFC 6125.⁶

ארבעת הסעיפים אינם פועלים באותו חוזק

כאן מפרידים בין תשובת הבחינה להתנהגות דפדפן אמיתית. ארבעת הסעיפים הם מה שאיור 2 בשאלה מונה כ-“פירוט שגיאה שעשוי להיות מוצג”; אסור לקרוא שכל דפדפן בודק את הארבעה באותה ודאות.

מנפיק, שם שרת ותוקף נקבעים מהמידע שביד ברגע קבלת ה-certificate, ולכן תמיד מאומתים. גם מה שעוצר את התקיפה בשאלה הם השלושה האלה.

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

• Chrome בדרך כלל אינו מבצע בדיקת OCSP או CRL מקוונת. במקום זה הוא מפיץ CRLSet — רשימה מוגבלת שמטרתה העיקרית לחסום certificates במהירות בחירום — ורק חלק מרשימות ה-revocation של CAs נכנס לכל מהדורה⁷
• גם במימושים ששואלים OCSP נפוצה תצורה שעוברת את החיבור כשאין תשובה (soft-fail)

לכן אל תהפכו את “אם המפתח דלף, נבטל” לעמוד הטיפול. Revocation הוא דבר שצריך לעשות, אבל אינו מנגנון שבוודאות פועל בכל דפדפן של כל משתמש. קיצור תקופת התוקף של certificates בשנים האחרונות הוא גם תשובת הענף לכך שאי אפשר לסמוך על revocation. כשחושדים בדליפת מפתח בארגון, במקביל לבקשת ה-revocation צריך להחליף certificate ולבטל גם את מה שהמפתח הגן עליו (sessions, מפתחות API וכו’).

מלכודת בשטח — מי מחליט מי היא “CA מהימנה”

מכאן והלאה זה מחוץ לנוסח השאלה. הסעיף הראשון בטבלה תלוי בבמה אותו מחשב סומך. רשימת האמון נמצאת בדפדפן או במערכת ההפעלה; ב-Windows זה Trusted Root Certification Authorities ב-Certificate Store.

כלומר במצבים האלה הבדיקה הראשונה תעבור:

• מפיצים למחשבי העבודה את ה-root certificate של CA פנימית (private CA). המפתח הפרטי של אותה CA, או הליך ההנפקה, נפל בידי תוקף
• Proxy או מוצר אבטחה שבודק תוכן תקשורת שם במחשב root certificate משלו כדי לסיים TLS. המוצר או התפעול נפלו בידי תוקף
• מישהו בעבר רשם חריג “כי מופיעה שגיאת certificate”, או הכניס certificate self-signed ל-trusted root

את השלישי רואים בשטח כל הזמן. משהו שהכניסו ידנית פעם אחת כדי להעלים שגיאת certificate במערכת פנימית נשאר בתמונה שעברה ממחשב של מי שעזב. תוכן Certificate Store של Trusted Root Certification Authorities הוא עצם ההצהרה במי המחשב מאמין, ולכן הוא יעד ל-inventory. את השיקול מה לשים באיזה store מסדר המדריך המעשי ל-Certificate Store ב-Windows.

לבדיקה השנייה (התאמת שם השרת) יש נקודת זהירות נפרדת בשטח. מול תקיפה שבה המשתמש מבלבל שם דומיין, ה-certificate חסר אונים. אם התוקף רוכש דומיין מבלבל כמו b-serv1ce.example.com ומשיג לו certificate לגיטימי, הדפדפן לא יציג שגיאה. מה שה-certificate מבטיח הוא “שם השרת ביעד תואם את שם השרת ב-certificate”, לא “שם השרת הזה הוא היעד שהמשתמש התכוון אליו”. את הצעד האחרון בלי להסתמך על עין המשתמש ממלאים שיטות כמו passkeys (WebAuthn) שבהן ה-authenticator בודק את ה-origin בעצמו. פירוט בלמה passkeys בטוחים.

5. למה זה נעצר גם כשמקלידים http:// — סעיף 1(3)

גב’ Y לא מוותרת. במצב מחובר ל-AP מזויף, אם העובד מקליד בטעות http:// בכתובת שירות B בדפדפן, אולי הודעת השגיאה לא תופיע?

שאלה סבירה. בחיבור HTTP server certificate כלל לא נכנס לתמונה. נראה שהאתר המזויף יוכל להציג מסך כניסה בלי שום שגיאה.

תשובת מר S: “זה בסדר. HSTS מופעל, ולכן גם אז תופיע אותה הודעת שגיאה כמו קודם”. סעיף 1(3) שואל את תנועת הדפדפן עד רגע לפני הצגת הודעת השגיאה, עד 60 תווים.

דוגמת התשובה: “מחליפים את הגישה ב-HTTP בגישה ב-HTTPS וניגשים. אחר כך מקבלים server certificate מהאתר המזויף”.

מה קורה בתוך הדפדפן

HSTS (HTTP Strict Transport Security) הוא מנגנון שבו האתר מכריז בכותרת Strict-Transport-Security “מכאן והלאה בואו לכאן רק ב-HTTPS”, והדפדפן זוכר זאת. זה מוגדר ב-RFC 6797.⁸

כשמנסים לגשת ב-http:// למארח שכבר זכור, הדפדפן פועל כך:

1. מחליף את סכימת ה-URL מ-http ל-https. אם צוין פורט 80, ממיר ל-443 (RFC 6797 סעיף 8.3)
2. מתחבר ב-HTTPS כתוצאה מכך. בנקודה זו DNS מזויף, ולכן היעד הוא האתר המזויף
3. מקבל server certificate מהאתר המזויף
4. האימות נכשל, ומתקבלת אותה שגיאה כמו בפרק 4

החשוב הוא שההחלפה ב-1 מסתיימת לפני היציאה לרשת. בקשת HTTP גלויה כלל אינה נשלחת. לכן לא נוצר המצב “התחברנו ב-HTTP ולכן אין certificate”.

אי אפשר ללחוץ על “התעלם והמשך”

ל-HSTS יש עוד תכונה גדולה מאוד בשטח. סעיף 8.4 ב-RFC 6797 דורש שבשגיאה במהלך הקמת ערוץ בטוח למארח עם HSTS, בין אזהרה ובין קטלנית, יש לנתק. וסעיף 12.1 מכנה את ההתנהגות “No User Recourse” וקובע שאסור להציג אפשרויות כמו “החיבור אינו בטוח, להמשיך?”.

בשגיאת certificate רגילה רוב הדפדפנים מציעים במסך האזהרה “Advanced” ו-“Continue”. בשטח לא נדיר שמשתמש שהתרגל לשגיאות certificate במערכות פנימיות לוחץ על זה ברפלקס. HSTS חוסם את הרפלקס הזה. כהגנה מאתר מזויף, “אי אפשר ללחוץ” עשוי להיות אפילו יעיל יותר מאימות ה-certificate עצמו.

הנחת HSTS — את הפעם הראשונה הוא לא מגן

אבל ל-HSTS יש הנחה. לפי סעיף 8.1 ב-RFC 6797, מארח הופך ל-“HSTS host ידוע” כשסוכן המשתמש מקבל כותרת Strict-Transport-Security מעל ערוץ בטוח. כלומר אותו דפדפן כבר היה צריך להגיע פעם אחת לאתר הלגיטימי ב-HTTPS.

לכן במקרים האלה אין הגנה:

• במחשב עבודה שזה עתה חולק, הגישה הראשונה מתבצעת מיד תחת AP מזויף
• יצרו מחדש פרופיל דפדפן, או מחקו נתוני גלישה וגם את רשומת HSTS
• פג תוקף הרשומה (max-age)

את בעיית הפעם הראשונה ממלאת רשימת ה-preload של HSTS. אם הדומיין ברשימה המובנית בדפדפן, כופים HTTPS גם בלי שביקרו מעולם.

אבל אם שוקלים רישום של אתר הארגון, בדקו קודם את התנאים. דרישות הרישום:⁹

• לספק certificate תקף
• אם מאזינים בפורט 80, להפנות מ-HTTP ל-HTTPS באותו מארח
• לספק את כל תת-הדומיינים ב-HTTPS (כולל www אם יש רשומת DNS)
• במארח הבסיס להחזיר כותרת Strict-Transport-Security עם max-age של 31536000 שניות (שנה) לפחות, ועם includeSubDomains ו-preload

מה שמשפיע הוא הצירוף של השלישית עם includeSubDomains. אם תת-דומיין פנימי ישן הוא HTTP בלבד, או שאין לו certificate, ברגע הרישום אי אפשר להגיע אליו. לפני רישום עושים inventory לכל תת-הדומיינים.

וביטול אינו קל. בקשות מחיקה מתקבלות בדרך כלל, אבל עד שהשינוי מגיע לדפדפני המשתמשים עוברים חודשים, ולגבי דפדפנים שאינם Chrome אין הבטחה.⁹ בטוח לגשת ל-preload כאל הגדרה ש”אם טעינו, נחזיר” — לא.

ולהפך, כמשתמשים, האם שירותי הענן שבשימוש עסקי תומכים ב-HSTS הוא שיקול ראוי בבחירה.

6. ברגע שהאישור מתרוקן, פונקציית השיתוף הופכת לנתיב הוצאה — סעיף 2(1)

מכאן עוברים לבחינת הוצאה בידי עובד.

מר S בודק תחילה את תפעול פונקציית שיתוף הקבצים. האם הממונה באמת בודק את כתובת היעד ואת הקובץ לפני שהוא מאשר. תשובת גב’ Y: “נראה שיש ממונים שלא מצליחים לבדוק”.

אז מר S מצביע על סעיף 2(1). עונים במפורש, עד 40 תווים, על שיטת ניצול פונקציית שיתוף הקבצים כדי לאפשר הורדה מחוץ ל-M.

דוגמת התשובה: “מציינים את כתובת הדואר הפרטית של עצמם ככתובת המשתף החיצוני”.

התכנון נכון, התפעול חסר

פונקציית שיתוף הקבצים של שירות B בנויה במחשבה.

• לשיתוף נדרש אישור ממונה
• קישור השיתוף החיצוני אינו מודע לעובד עצמו ולא לממונה. העובד עצמו לא יכול להעביר את הקישור ולהוציא
• הקישור כולל מחרוזת אקראית קשה לניחוש, ותוקף ליום אחד

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

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

תנאי התרוקנות האישור קבועים

כשאישור מתרוקן בשטח, הסיבה היא בדרך כלל אחת מאלה.

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

את התמונה הכללית מאיפה עסק קטן מתחיל מטפל מדריך ההליכה ב”מדריך אבטחת המידע לעסקים קטנים ובינוניים” של IPA, מהדורה 4.0.

7. הפרצה שנקראת חדר ישיבות — סעיף 2(2)

השאלה הבאה של מר S: “אפשר להכניס מחשב אישי לחדר הישיבות?”. תשובת גב’ Y: “הכנסה לחדר הישיבות אינה אסורה, אז אפשר”.

כאן עולות שיטה 1 ושיטה 2. בשתיהן העלילה היא להוריד קבצים משירות B במחשב אישי, ולקחת את המחשב האישי כולו. הגדרות תוכנת מניעת הדליפה במחשב העבודה לא חלות כלל על המחשב האישי.

שיטה 1 — זיוף כתובת MAC

שיטה 1 היא לשנות את [e] כתובת ה-MAC של ממשק ה-Wi-Fi במחשב האישי לכתובת ה-MAC של ממשק ה-Wi-Fi במחשב עבודה, ואז לחבר את המחשב האישי ל-Wi-Fi לעובדים. לענות על משבצת e זה סעיף 2(2).

את הכניסה ל-Wi-Fi לעובדים שמרו שני דברים: ה-pre-shared key של WPA2-PSK, ו-MAC filtering. את שניהם עובד יכול לעבור.

• ה-pre-shared key מוגדר במחשב העבודה, והעובד הוא המשתמש במחשב העבודה. בשיטה שבה כולם חולקים מפתח אחד, ההנחה היא ש”המשתמש יכול לדעת”
• כתובת MAC ניתנת לשינוי בצד המחשב. בדרך כלל משנים אותה בהגדרות מערכת ההפעלה או במאפייני ה-driver, בלי כלי מיוחד. בנוסף, כתובת ה-MAC שעל מסגרות ה-Wi-Fi אינה מוצפנת, ולכן קבלה בקרבת מקום חושפת גם כתובות MAC של מחשבי עבודה רשומים

MAC filtering והסתרת SSID יש להם ערך כסידור שמפחית חיבור בטעות. אבל הם אינם מנגנון אימות שעוצר מי שמנסה להיכנס במכוון. בדקו גם בתצורה שלכם אם הכנסתם את השניים האלה למניין “הטיפולים”.

שיטה 2 — פשוט להתחבר ל-Wi-Fi לאורחים

שיטה 2 פשוטה עוד יותר. מחברים מחשב אישי ל-Wi-Fi לאורחים, מורידים קבצים משירות B, ולוקחים את המחשב האישי. זה הכול.

אין צורך בזיוף כתובת MAC. כל מה שצריך הוא ה-pre-shared key של רשת האורחים, ואותו מחלקים לאורחים. אין סיבה שעובד לא יידע אותו.

כאן עולה באופן טבעי השאלה הבאה. שירות B הוגבל ל-“במזהה שניתן לעובד של M אפשר להיכנס רק מכתובת ה-IP הגלובלית של M” — לא?

מה באמת מתירה הגבלת כתובת IP מקור

קריאת הגדרות ה-Firewall בשאלה נותנת את התשובה. גם תעבורה מ-Wi-Fi לאורחים לאינטרנט וגם תעבורה מ-Wi-Fi לעובדים מתורגמות באותו NAT לאותה כתובת IP גלובלית אחת.

מבחינת שירות B אי אפשר להבדיל בין השלושה. ההגבלה לפי כתובת IP עוברת.

המבנה הזה חוזר גם מחוץ לבחינה. הגבלת כתובת IP מקור אינה אומרת “רק מהמחשב הזה”. היא אומרת “מכל מי שיוצא בכתובת הגלובלית הזו”. דוגמאות טיפוסיות לפער בין ההיקף שחשבתם שהתרתם לבין ההיקף שמותר בפועל:

זה לא אומר שהגבלת כתובת IP מקור חסרת ערך. זה אומר לא להשתמש בהגבלת שכבה אחת בלבד. אחרי צמצום לפי כתובת IP, רק כשמשלבים מנגנון שמזהה את המחשב עצמו (client certificate או device certificate) ומנגנון שמזהה את המשתמש (MFA) אפשר לבטא “האדם הזה, במחשב הזה”. גם הטיפול בשאלה הזו הולך בדיוק לשם.

8. לנעול את המחשב ב-certificate — סעיפים 3(1)-(4)

כטיפול לשיטה 1, M בוחרת EAP-TLS כשיטת האימות ב-Wi-Fi לעובדים, ומכינה שרת אימות.

סעיף 3(1) —‏ RADIUS

סעיף 3(1) שואל את הפרוטוקול מעל UDP שהשרת המאמת משתמש בו ב-EAP. דוגמת התשובה: RADIUS.

אם מסדרים את המבנה, יש שלושה שחקנים.

בין מחשב העבודה ל-AP זה IEEE 802.1X (EAP over LAN), ובין ה-AP לשרת האימות זה RADIUS. RADIUS רץ מעל UDP.¹⁰ את הליך EAP-TLS עצמו מגדיר RFC 5216.¹¹ ב-Windows Server את תפקיד שרת האימות ממלא Network Policy Server (NPS).¹²

כדאי לתפוס מה משתנה במעבר מ-WPA2-PSK ל-EAP-TLS.

השורה האחרונה דורשת השלמה. ב-EAP-TLS הצד שהלקוח מאמת את ה-certificate שלו הוא שרת האימות, לא ה-AP. ה-AP הוא רק authenticator שמעביר את חילופי EAP, והלקוח אינו מאשר את זהות ה-AP עצמו.

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

אבל זה מותנה. אם בצד הלקוח לא מגדירים “איזה server certificate, מאיזו CA, באיזה שם, ראוי לאמון”, אי אפשר להבדיל כשהתוקף מביא שרת אימות משלו. תצורה שבה הכניסו EAP-TLS ובפרופיל הלקוח כיבו את אימות ה-server certificate קיימת בפועל. אחרי הטמעה בודקים גם עד לשם.

סעיף 3(2) — התשובות השגויות שהערות הציון ציינו

הסבר גב’ Y ממשיך. ה-client certificate מונפק בשרת CA חדש, והעובד אינו מתקין אותו בעצמו במחשב העבודה אלא מאחסנים אותו במחשב העבודה בפונקציית שרת ה-directory. ואת [f] שמתאים ל-client certificate מאחסנים ב-TPM של מחשב העבודה ומגנים עליו כדי [g].

סעיף 3(2) שואל את משבצת f. דוגמת התשובה: מפתח פרטי.

הערות הציון כותבות כך:

בסעיף 3(2) שיעור התשובות הנכונות היה גבוה יחסית, אבל נראו גם תשובות כמו “מפתח ציבורי” ו”server certificate”. PKI הוא טכנולוגיה בסיסית למגוון טכנולוגיות אבטחה, ולכן רוצים שיבינו באילו מצבים ואיך משתמשים בה.

המפתח הציבורי נמצא בתוך ה-certificate ומחולק לעולם. הוא אינו יעד להגנה. מה שצריך להגן עליו הוא המפתח הפרטי שאמור להיות רק אצל בעל ה-certificate. “אימות ב-client certificate” פירושו במדויק “להוכיח שמחזיקים במפתח הפרטי שמתאים למפתח הציבורי שב-certificate, על ידי חתימה באותו מפתח”. לכן אם אפשר לשכפל את המפתח הפרטי, האימות ב-certificate מאבד משמעות.

מה משתנה כשמכניסים ל-TPM — סעיף 3(3)

סעיף 3(3) שואל את משבצת g עד 20 תווים. דוגמת התשובה: “כדי שאי אפשר יהיה להוציא ממחשב העבודה”.

אם המפתח הפרטי יושב כקובץ במחשב, זה נתון שניתן להעתקה. מעתיקים למחשב אישי, והמחשב האישי עובר אימות כמחשב עבודה. חשבתם שסגרתם את שיטה 1 (זיוף כתובת MAC), ובמקומה באה “זיוף certificate”.

TPM יכול ליצור מפתח בתוכו ולהחזיק אותו במצב שאי אפשר להוציא החוצה. חישובים כמו חתימה רצים בתוך ה-TPM, והמפתח עצמו אינו מגיע ל-OS, לא לאפליקציה ולא ל-malware. התוצאה: המפתח הפרטי ננעל לרכיב הפיזי האחד הזה.

במימוש ב-Windows מציינים Microsoft Platform Crypto Provider כ-Key Storage Provider (KSP) בתבנית ה-certificate. הספק הזה מגן על מפתחות באמצעות TPM, ואי אפשר לבחור אותו אם בתבנית ה-certificate מסומן “Allow private key to be exported”.¹³ אם אפשר לייצא, אין טעם בהגנה — מגבלה מובנת מאליה.

את תפקיד הרכיב TPM עצמו מטפל המדריך המעשי ל-BitLocker בהקשר של הצפנת כונן. הרעיון “לא להוציא מפתח פרטי מחוץ למכשיר” הוא אותו רעיון כמו תכנון ה-authenticator שמוסבר בלמה passkeys בטוחים.

למה אפשר לומר ש”אין בעיה” — סעיף 3(4)

אחרי הסבר גב’ Y, מר S עונה “בשיטת האחסון הזו אני חושב שאין בעיה”. סעיף 3(4) שואל את הסיבה עד 40 תווים.

דוגמת התשובה: “כי את certificates האימות הנדרשים ל-EAP-TLS אפשר לאחסן רק במחשב העבודה”.

הזרימה היא זו:

1. ה-client certificate אינו מותקן בידי העובד עצמו, אלא מחולק למחשב העבודה בפונקציית שרת ה-directory. הוא לא עובר בידי העובד
2. המפתח הפרטי נמצא בתוך ה-TPM, ואי אפשר להוציא אותו ממחשב העבודה
3. לכן רק מחשב עבודה שהחברה חילקה יכול להתחבר ל-Wi-Fi לעובדים ב-EAP-TLS
4. מחשב אישי, גם אם מזייף כתובת MAC, לא יעבור אימות. שיטה 1 נחסמת

שימו לב לניסוח המותנה “בשיטת האחסון הזו”. אם המפתח הפרטי היה יושב כקובץ במחשב העבודה, מר S לא היה אומר שאין בעיה. גם באותו “אימות ב-client certificate”, היקף ההגנה משתנה לפי מקום המפתח הפרטי.

מה TPM לא מגן עליו

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

• כשמוציאים את המחשב עצמו. הוצאת מחשב העבודה היא הוצאת ה-TPM יחד איתו. בכללי M הוצאת מחשב עבודה מחוץ לחברה אסורה, אבל כלל וכפייה טכנית הם דבר שונה. נדרשים בנפרד הצפנת כונן (כולל אימות לפני הפעלה) ותפעול revocation של certificate באובדן
• התחזות למשתמש. TPM מזהה מחשב, אבל אינו מבטיח מי מפעיל אותו. אימות המשתמש נדרש בנפרד
• Malware שרצה במחשב. אי אפשר לקרוא את המפתח הפרטי, אבל קוד שרץ במחשב יכול “לבקש מה-TPM לחתום”. מונעים שכפול מפתח, אבל לא שימוש לרעה כל עוד המחשב נתון בשליטה

9. להפריד את כתובת ה-IP ביציאה — סעיף 3(5)

כטיפול לשיטה 2 (פשוט להתחבר ל-Wi-Fi לאורחים) M בוחנת שני רעיונות. לשנות את הגדרת ה-NAT ב-FW, ולהשתמש בשירות Wi-Fi (שירות D).

סעיף 3(5) שואל את תוכן השינוי בראשון עד 70 תווים. דוגמת התשובה היא ברוח “כשניגשים לאינטרנט מ-Wi-Fi לאורחים, לשים את כתובת ה-IP של המקור לכתובת IP אחרת מכתובת ה-IP הגלובלית שבשימוש כעת” (בשאלה כתובת ה-IP הגלובלית הזו מצוינת כ-a1.b1.c1.d1).

כפי שראינו בפרק 7, שיטה 2 מתקיימת כי תעבורת Wi-Fi לאורחים יוצאת באותה כתובת גלובלית כמו העובדים. אז מספיק לתרגם רק את Wi-Fi לאורחים לכתובת גלובלית אחרת. הגבלת ה-IP בצד שירות B לא משתנה, ורק הגישה מ-Wi-Fi לאורחים יוצאת ממנה.

זה מתקיים כי בצד ה-WAN של M מוקצות כמה כתובות IP גלובליות. בקריאת הגדרות הממשק של ה-FW בשאלה, מסכת תת-הרשת בצד WAN היא 255.255.255.248, כלומר /29, ואפשר לראות שיש יותר מכתובת אחת. זו הקדמה שקטה אבל בטוחה, שדורשת לקרוא את הטבלה בשאלה לפרטים.

האם אפשר לעשות את אותו דבר אצלכם תלוי אם בקו החוזה יש כמה כתובות IP גלובליות. אם יש רק אחת, הרעיון הזה לא זמין. אז עוברים לרעיון ההפרדה בפרק הבא.

10. הטיפול נגמר רק כשמוחקים הגדרות שאינן בשימוש — סעיפים 3(6)(7)

בסוף הבחינה M בוחרת להשתמש בשירות D.

• בחדר הישיבות מציבים נתב אלחוטי (נתב D) ששירות D משאיל
• בנתב D מפעילים פונקציית DHCP server ופונקציית DNS cache
• מחשבי אורחים מתחברים לאינטרנט בלי לעבור ברשת של M, באמצעות ה-SIM המובנה בנתב D
• את המקרן מחברים בכבל HDMI, בלי להשתמש ב-Wi-Fi לאורחים

flowchart LR
    accTitle: אחרי הטיפול מנתקים את רשת האורחים
    accDescr: רשת העובדים משתמשת ב-EAP-TLS וב-TPM, ומחשב שאורח מביא יוצא לאינטרנט ב-SIM של נתב D בלי לעבור ברשת של M
    subgraph M["הרשת הפנימית של חברת M (אחרי הטיפול)"]
        direction TB
        E["Wi-Fi לעובדים<br/>EAP-TLS + RADIUS<br/>המפתח הפרטי בתוך TPM"]
        S["רשת שרתים"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["חדר ישיבות"]
        T["מחשב שאורח מביא"]
        D["נתב D<br/>ישר לאינטרנט דרך SIM"]
        T --> D
    end
    FW --> B["שירות B"]
    D --> I["אינטרנט"]

איור 3: רשת האורחים נותקה מרשת חברת M פיזית וגם לוגית; היא גם אינה יוצאת עוד באותה כתובת IP גלובלית.

רשת האורחים נותקה מרשת M פיזית וגם לוגית. היא גם אינה יוצאת באותה כתובת גלובלית.

סעיף 3(6) — תעבורה שתהיה מיותרת

כשמחשבי אורחים מפסיקים להשתמש ברשת של M, התעבורה שהייתה נחוצה עד כה ל-DHCP server ולשרת [h] הופכת למיותרת. דוגמת התשובה למשבצת h: DNS.

לנתב D עצמו יש פונקציית DHCP server ופונקציית DNS cache, ולכן מחשבי אורחים אינם צריכים את DHCP server ו-DNS server ברשת השרתים של M. אם קוראים שוב את תיאור השאלה, זה כתוב כמו שהוא.

סעיף 3(7) — למנות את כל ההגדרות למחיקה

סעיף 3(7) מבקש לענות על כל מספרי הפריטים שיש למחוק מהגדרות ממשק ה-VLAN ומהגדרות הסינון של ה-FW, בעקבות השינוי.

התשובה: מהגדרות ממשק VLAN את VLAN של Wi-Fi לאורחים (פריט 1); מהגדרות הסינון את הכלל שמתיר HTTP/HTTPS מ-Wi-Fi לאורחים לאינטרנט (פריט 1) ואת הכלל שמתיר גישה מ-DNS ברשת השרתים מ-Wi-Fi לאורחים (פריט 4) — שניים. בנוסף מוחקים מהגדרות ה-AP את הגדרת SSID האורחים.

הערות הציון כותבות כך:

בסעיף 3(7) שיעור התשובות הנכונות היה גבוה. היה צריך להבין את כל הגדרות הסינון של ה-Firewall ואת ההשפעה של עדכון סביבת ה-Wi-Fi, והובן כראוי.

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

ה-Firewall בשאלה מעריך כללים מהפריט הקטן לגדול, ומחיל את הכלל הראשון שמתאים (זה כתוב במפורש בשאלה). בשיטה הזו, להשאיר allow rule שאינו בשימוש למעלה זה כמו להשאיר חור שמונע מהכלל הסופי של הסירוב להגיע.

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

בכל שיטה, עצם זה שמסוכן להשאיר allow שאינו בשימוש אינו משתנה. מה שמשתנה הוא “למה זה מסוכן” ו”איך מתקנים”. אחרי שמאשרים באיזו שיטה הציוד שלכם, מכניסים ל-inventory המחזורי את השיקול “האם המקור והיעד עדיין קיימים”.

את הצד של Firewall במחשב — איך מנהלים inbound rules שנחוצים לאפליקציה עסקית — מטפל Windows Firewall ואפליקציות עסקיות.

11. טיפולים שלא פעלו, וטיפולים שפעלו

אם מרכזים את השאלה לטבלה אחת, מתקבלת ההתאמה בין הטיפולים שהיו ל-M לבין איפה עברו אותם.

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

בהשוואה האופי מתבהר. הטיפולים שעברו הם ברובם איסור “אמצעי”, והטיפולים שפעלו והטיפולים שהוצעו משנים “נתיב” או “אופי האימות”. גם אם חוסמים USB, כל עוד נשאר נתיב לקובץ ההוצאה מתקיימת; גם אם מאריכים pre-shared key, הוא נשאר סוד משותף.

12. נקודות בדיקה לשטח

פריטי אישור כשמחילים את השאלה על התצורה שלכם.

1. האם אפשר לכתוב את מניעת ההוצאה בנתיבים ולא באמצעים. לא רשימת אמצעים כמו USB, צירוף למייל ודואר אינטרנט, אלא “רשימת המחשבים והרשתות שיכולים להגיע לקובץ העסקי”. אם יש ולו נתיב אחד שמחשב לא מנוהל מגיע בו, איסור האמצעי יעקוף
2. האם כללי הכנסה והוצאה אינם מצמצמים מקום. “איסור הכנסה לחדר העבודה” מתיר חדר ישיבות, קבלה ומרחב משותף. בודקים אם החלוקה הפיזית והחלוקה הרשתית חופפות
3. האם אפשר לומר מה באמת מתירה הגבלת כתובת IP מקור. סופרים הכול שיוצא בכתובת הגלובלית הזו. Wi-Fi לאורחים, רשת אורחים, VPN בין אתרים, שער מרוכז לעבודה מרחוק, סביבת בדיקה
4. האם אימות ה-Wi-Fi הוא לפי מחשב. Pre-shared key הוא סוד משותף אצל כולם; דליפה אצל אחד היא דליפה לכולם, ואי אפשר לעצור מחשב אחד מסוים
5. האם לא הכנסתם MAC filtering והסתרת SSID למניין הטיפולים. שניהם סידור שמפחית חיבור בטעות, לא אימות
6. האם המפתח הפרטי של ה-client certificate במצב שאי אפשר להוציא מהמחשב. מפתח פרטי כקובץ ניתן לשכפול. מציינים Key Storage Provider שמשתמש ב-TPM, ולא מתירים ייצוא
7. האם הלקוח שאליו הכניסו EAP-TLS מאמת את ה-certificate של שרת האימות. אם מכבים את זה, נעלמת העמידות מול שרת אימות מזויף
8. האם שגיאת server certificate אינה במצב שהמשתמש יכול לעבור ב-“Continue”. מגדירים HSTS לאתר הארגון. לא משאירים שגיאות certificate במערכות פנימיות, ולא מלמדים את המשתמש ש”שגיאה לוחצים וממשיכים”
9. האם עושים inventory לתוכן Trusted Root Certification Authorities. מה שנמצא שם הוא בדיוק הצד שהמחשב מכריז “certificate שה-CA הזו הנפיקה ייחשב אמיתי”
10. האם למאשר בזרימת האישור מגיע חומר שיפוט, והאם רואים אחר כך את תוצאת האישור. בודקים באופן קבוע ברשימה שיתופים לדומיינים חיצוניים ולדואר חינמי
11. האם מוחקים הגדרות של נתיב שבוטל. ממשק VLAN, כללי סינון, SSID, רשומות ברשימת allow. נותנים מועד גם לעבודת המחיקה, באותו יחס כמו “להכניס חדש”

לסיום — טיפול שלא כותב “היקף” אינו מגן

אם שאלה 1 שאלה “את איזה שלב, של איזו תקיפה, הטיפול הזה עוצר”, מה ששאלה 2 שואלת הוא “איזה היקף הטיפול הזה שומר”.

לכל אחד מטיפולי M היה היקף מובלע. היקף תוכנת מניעת הדליפה הוא עד מחשב העבודה. היקף איסור ההכנסה הוא עד חדר העבודה. היקף MAC filtering הוא עד “מי שאינו מזייף”. היקף הגבלת כתובת IP מקור הוא עד “כל מי שיוצא בכתובת הגלובלית הזו”. כל היקף פעל נכון; רק החיבור לשכן היה פתוח.

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

כדי למצוא רווח אין ברירה אלא לכתוב רשימת נתיבים, לא רשימת טיפולים. זה בדיוק מה שגב’ Y ומר S עשו בשאלה. מפרידים ל-“תוקף חיצוני” ו-“עובד”, וסוגרים לכל אחד נתיב הגעה אחד-אחד. “היכולת לשער איומים מזוויות שונות בסביבה שמשתמשת ב-Wi-Fi”, ש-IPA כתבה בכוונת השאלה, היא העבודה הזו.

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בסקירת תכנון על בסיס רשת ותצורת קצה קיימות, ובמימוש הפצת certificates והגנה על מפתחות בסביבת Windows.

• ייעוץ טכני וסקירת תכנון
• פיתוח אפליקציות Windows
• חקירת תקלות ואיתור גורמים
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

אסרו חיבור USB ואסרו שמירה לדיסק מקומי — איך בכל זאת מוציאים קבצים?

מה שנאסר הוא פונקציות של מחשב העבודה שהחברה השאילה, לא נתיב ההגעה למקום שבו הקבצים יושבים. בשאלה הזו העובד משתמש במחשב האישי שלו. בלי לגעת במחשב העבודה, הוא מחבר את המחשב האישי ל-Wi-Fi בחדר הישיבות, נכנס לשירות האחסון בענן (שירות B) עם מזהה המשתמש שלו, מוריד קבצים, ולוקח הביתה את המחשב האישי כולו. הגדרות תוכנת מניעת הדליפה במחשב העבודה לא חלות כלל על המחשב האישי. חברת M אסרה הכנסת מחשבים אישיים, אבל האיסור היה על חדר העבודה בלבד, וחדר הישיבות היה מחוץ להיקף. גם אם חוסמים אמצעים אחד-אחד (USB, צירוף למייל, דואר אינטרנט), כל עוד נשאר נתיב שמגיע לקובץ — ההוצאה מתקיימת.

שירות B הוגבל ל"כניסה רק מכתובת ה-IP הגלובלית של M". למה אפשר לעקוף מ-Wi-Fi לאורחים?

גם התעבורה של Wi-Fi לאורחים עוברת באותו NAT של אותו Firewall, ומתורגמת לאותה כתובת IP גלובלית לפני שהיא יוצאת לאינטרנט. מבחינת שירות B, גישה ממחשב עבודה פנימי וגישה ממחשב אישי שמחובר ל-Wi-Fi לאורחים בחדר הישיבות נראות כאותה כתובת מקור. אי אפשר להבדיל. הגבלת כתובת IP מקור אינה "רק מהמחשב הזה" אלא "כל מי שחולק את אותה יציאה". Wi-Fi לאורחים, VPN בין אתרים, ושער מרוכז לעבודה מרחוק — כל מה שיוצא באותה כתובת גלובלית נכנס להיתר.

על Wi-Fi לעובדים היה MAC filtering. זה לא נחשב לטיפול?

לא. אפשר לשכתב כתובת MAC בצד המחשב בחופשיות. שיטה 1 בשאלה הייתה לשנות את כתובת ה-MAC של ממשק ה-Wi-Fi במחשב האישי לכתובת ה-MAC של מחשב עבודה רשום, ואז להתחבר. כתובת ה-MAC במסגרות ה-Wi-Fi טסה בלי הצפנה, ולכן קבלה בקרבת מקום חושפת גם כתובות MAC רשומות. אותו דבר נכון גם להסתרת SSID. גם אם מכבים פרסום SSID, הוא מתגלה מהחילופים בזמן חיבור. MAC filtering והסתרת SSID מפחיתים חיבור בטעות, אבל הם אינם מנגנון אימות שעוצר חיבור מכוון.

גם אם מכינים AP מזויף ואתר מזויף, למה אפשר לומר שהעובדים לא יולכו שולל?

כי בחיבור HTTPS האתר המזויף לא יעבור את אימות ה-server certificate. איור 2 בשאלה מונה ארבעה פירוטי שגיאה אפשריים: לא הונפק על ידי CA מהימנה, שם השרת ב-certificate שונה משם השרת שאליו מתחברים, ה-certificate בוטל, פג תוקף. התוקף אינו יכול להשיג certificate לגיטימי לשם הדומיין של שירות B, ולכן certificate self-signed נופל בראשון, ו-certificate לגיטימי לדומיין שלו נופל בשני. לפי הערות הציון של IPA, שיעור התשובות הנכונות לשאלה על תוכן האימות הזה היה נמוך. ארבעת הסעיפים גם אינם פועלים באותו חוזק. מה שעוצר את התקיפה הם השניים הראשונים (מנפיק ושם) ותוקף — הדפדפן תמיד בודק אותם. בדיקת revocation תלויה במימוש ובהגדרה. Chrome למשל בדרך כלל אינו בודק OCSP או CRL מקוונים, ומשתמש ב-CRLSet — רשימה מוגבלת שמטרתה חסימה בחירום. אל תחשבו ש-revocation תמיד ידחה. ואם מפיצים למחשבי העבודה את ה-root certificate של CA פנימית, והמפתח הפרטי או הליך ההנפקה של אותה CA נפלו בידי תוקף, גם הבדיקה הראשונה תעבור.

מה קורה אם מקלידים בטעות "http://"? מה HSTS עושה?

הדפדפן מחליף HTTP ב-HTTPS ואז מתחבר, ולכן התוצאה היא שוב שגיאת server certificate. HSTS הוא מנגנון שבו הדפדפן זוכר את תוכן הכותרת שקיבל בחיבור HTTPS קודם לאותו אתר. RFC 6797 דורש שאם ב-URL ליעד יש סכימת http, סוכן המשתמש מחליף אותה ב-https, ואם צוין פורט 80 הוא מומר ל-443. כלומר בקשת HTTP גלויה נעלמת לפני שהיא יוצאת לרשת. חשוב עוד יותר: בחיבור למארח עם HSTS, אם אימות ה-certificate נכשל, בין אזהרה ובין שגיאה קטלנית — יש לנתק. מצוין במפורש שאסור להציג למשתמש "החיבור אינו בטוח, להמשיך?". אבל HSTS מניח שהדפדפן כבר הגיע פעם אחת לאתר הלגיטימי ב-HTTPS וקיבל את הכותרת. במחשב חדש לגמרי, אם הגישה הראשונה היא מיד לאתר מזויף, זה לא עוזר. את הפעם הראשונה ממלאת רשימת ה-preload המובנית בדפדפן.

מה משתנה כשמאחסנים את המפתח הפרטי של client certificate ב-TPM?

אי אפשר להוציא את המפתח הפרטי ממחשב העבודה. מפתח פרטי שיושב כקובץ במחשב אפשר להעתיק למחשב אישי, ואז אותו מחשב אישי יעבור אימות כמחשב עבודה. אם יוצרים את המפתח בתוך TPM במצב שאינו ניתן לייצוא, חישובים כמו חתימה רצים רק בתוך ה-TPM, והמפתח עצמו אינו מגיע ל-OS ולא ל-malware. התוצאה: רק מחשב עבודה שהחברה חילקה יכול לעבור EAP-TLS. זו הסיבה שמר S יכול היה לומר "בשיטת האחסון הזו אין בעיה". ב-Windows מציינים Microsoft Platform Crypto Provider כ-Key Storage Provider בתבנית ה-certificate, ולא מתירים ייצוא מפתח פרטי. אבל TPM מגן רק על "המפתח לא יועתק למחשב אחר"; מי שמחזיק את המחשב עדיין יכול להשתמש בו. מול אובדן וגניבה צריך בנפרד הצפנת כונן ו-revocation של certificate.

מה כדאי לקחת מהשאלה הזו לשטח?

ארבע נקודות. ראשית, לחשוב על מניעת הוצאה בנתיבים ולא באמצעים. גם אם חוסמים USB, צירוף למייל ודואר אינטרנט אחד-אחד, אם נשאר מחשב שמגיע לקובץ — אין בזה תועלת. שנית, לכתוב במפורש מה באמת מתירה הגבלת כתובת IP מקור. אם Wi-Fi לאורחים או VPN משתמשים באותה יציאה, גם הם בהיתר. שלישית, להפוך את אימות ה-Wi-Fi ל-certificates לפי מחשב. Pre-shared key הוא סוד משותף אצל כולם; דליפה אצל אחד היא דליפה לכולם. עם EAP-TLS ו-client certificate, ועם מפתח פרטי שאינו יוצא מה-TPM, ה-certificate ננעל למחשב. רביעית, למחוק הגדרות שאינן בשימוש. השאלה האחרונה ביקשה למנות את כל הגדרות ממשק ה-VLAN וכללי הסינון ב-Firewall שנשארים אחרי ביטול Wi-Fi לאורחים. לפי הערות הציון של IPA שיעור התשובות הנכונות היה גבוה, אבל מעט ארגונים מסיימים את זה בשטח.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.