יומן אבטחה

1. כאשר משתמש מבצע יציאה מסודרת (logout) יש לבטל את מזהה ה-session שלו, כך שכל המשתמשים הרוכבים על אותו מזהה ה-session ינותקו. לשם כך המשתמשים צריכים לבצע יציאה מסודרת (מה שנהיה פחות נפוץ לאור הופעת הטאבים והנטיה של הדפדפנים היום לשמר מצב בעת סגירת דפדפן). כמובן שלשם כך צריך שמזהה ה-session יוגרל בכל כניסה מחדש ולא ייעשה שימוש במזהה סטאטי. זה לא ימנע את גניבת החשבון, אך ימנע שימוש יתר בזכויות המתקבלות.
2. אפשר לבצע גם ניתוק יזום לאחר פרק זמן של חוסר פעילות (או לפחות נעילה של החשבון).
   
3. אפשר לנסות (אני לא בטוח כמה זה פשוט) להצליב כתובת IP שמתקבלת בעת ביצוע ה-login עם מקור הגלישה בכל גישה לאתר, כך שגישה מכתובת IP שונה מזו ממנה בוצע ה-login תיחסם.
   

בזמן האחרון יוצא לי להשתמש לפעמים ברכיב SSL-VPN של Juniper, באמצעות רכיב One Time Password. למי שלא מכיר, רכיבים מסוג זה נועדו לאפשר גישה מאובטחת לתוך הארגון, מכל מקום, תוך שמירה על רמת אבטחה גבוהה (בין היתר, שימוש ב-SSL, אך בעיקר בדיקה של רמת האבטחה בתחנת הקצה המתחברת).

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

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

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

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

על פי חברת אבטחה מאטלנטה, 70% ממתקפות ה-Web בדצמבר מבוססות על ערכת פריצה יחידה, העונה לשם "Q406 Roll-up". אני מזכיר שלאחרונה התברר כי קיימת ערכה לבנייה של מתקפות פישינג בשיטת Man-In-The-Middle, המאפשרת לעקוף מנגנוני הזדהות מסוג One Time Password. בנוסף, לפני כחצי שנה הודיעו במקאפי כי נראה שהאקרים פונים לשיטות פיתוח של תנועת הקוד הפתוח כבסיס לייצור רושעות (malware). המונח Script Kiddies מתאר האקרים חסרי יכולת מקצועית אמיתית. כאלה שיכולים רק להריץ כלים מוכנים מראש וחסרי יצירתיות. אני תוהה אם אנחנו לא מתחילים להתקל במין יצורי כלאיים חדשים. משתי קבוצות של האקרים, המומחים המעטים והבינוניים הרבים, אנו עוברים לשלוש קבוצות. המומחים המעטים, הכמעט מומחים (העושים שימוש בכלים שפיתחו מומחים ושמאפשרים להגיע לרמת מתקפות גבוהה) והבינוניים.

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

ידיעה קצרה ב-CheckPoint User Group מספרת סיפור שלם. שני האקרים חביבים (באמת חביבים), רוני בכר וניר גולדשלאגר הצליחו לעקוף את מנגנון האבטחה ב-Connectra. זה המנגנון שבודק כי תחנה המתחברת לרשת הארגון אכן מאובטחת. ה-Connectra הוא חלק ממשפחת מוצרי אבטחה המכונים End-Point Security (אבטחת התקני קצה). זהו אחד התחומים החמים כיום באבטחת מידע.. המטרה של אבטחת התקני קצה היא לשלוט ברמת האבטחה של כל רכיב ברשת הארגונית. זה יכול להיות חיבור מרחוק (מחוץ לרשת הארגון, דרך VPN או דרך האינטרנט) או סתם חיבור של תחנות מתוך הארגון. זה יכול להיות תחנות Stand Alone. המטרה המרכזית היא להרחיב את האבטחה עד לקצה גבול התשתית הטכנולוגית הארגונית.

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

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

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

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

ומשהו קטן על הנדסה חברתית שימחיש אבטחה בצד שרת ובצד לקוח. כשאתם הולכים לקנות משהו בחנות, המוכר מנסה לשכנע אתכם בטיעונים מטיעונים שונים. אם אתם מקבלים החלטה בחנות, זו אבטחה בצד הלקוח (אתם ה"שרת" והוא ה"לקוח"). אתם חשופים למניפולציות והטעיות (ואגב, זו בדיוק הסיבה בגללה תמיד יגידו לכם שהמבצע הולך להגמר, כדי למנוע מכם לצאת מטווח המניפולציה). אם אתם מחליטים לאסוף את הנתונים ולשבת עליהם בשקט בבית לפני קבלת ההחלטה זו אבטחה בצד השרת. ברור מה יותר מאובטח/שקול. אך כמו בתוכנה, גם בחיים (כן, אני יודע שזה אמור להיות הפוך) לפעמים זה נכון לקבל החלטות בצד הלקוח ולפעמים בצד השרת, הכל בהתאם לסיטואציה ולסיכונים. לעתים עצם המודעות למשמעות של מיקום קבלת ההחלטה עושה את כל ההבדל.

בסיפור של הפריצה לכספומט כתבתי על כך שמיקום ממשקי הניהול בעמדה הנגישה לכולם היא לא הדבר הכי נבון. RSnake מדווח על כך ש-x90 איתר את ממשק הניהול של MySpace ואף את ממשק ה-OutlookWebAccess.

ממשקי ניהול יש לכל מערכת. הבעיה איתם היא שהם מאפשרים לעשות כל דבר במערכת. עוד בעיה קטנה היא שהרבה פעמים (תמיד?) אין אפשרות לנעול את המשתמש כיוון שמדובר במנהל המערכת ומישהו הרי צריך להיות זמין תמיד לשחרר את כל אלה שננעלו. לכן מיקום של ממשקי ניהול פתוחים לכל דכפין באינטרטנט זה לא הדבר הכי טוב שאני יכול לחשוב עליו, כיוון שהם חשופים למתקפת עוצמה פראית (brute force בתרגום ציורי) שתאפשר גישה לכל זב חוטם.

אבל אותי דווקא מטרידה יותר מגמת ה-OutlookWebAccess. אני כותב מגמה, כי האפשרות לגשת מרחוק לדואר ארגוני היא אפשרות שהופכת להיות יותר ויותר נפוצה. הבעיה המרכזית שלה היא שבהרבה המקרים מדובר על אותו שם משתמש וסיסמא פנים ארגוניים ומישהו שרוצה לפגוע בארגון יכול להריץ script שפשוט ינחש את שמות וסיסמאות כל המשתמשים במערכת. הוא כמובן יכול לעצור עבור כל שם משתמש בחמישה נסיונות (שיובילו לנעילת סיסמא). התוצאה תהיה שבבוקר כל הארגון יהיה חסום. גם זה סוג של Denial Of Service. החלופה היא כמובן לאפשר גישה רק עם הזדהות חזקה ולוותר על מרכיב הנעילה.

דבר נוסף בהקשר זה הוא האפשרות שמשתמש המתחבר לארגון מרחוק ישמש מקור להדלפת מידע בלא ידיעתו (אך זו כבר אופרה אחרת).

שכחתי. הפורץ הנוצץ עשוי גם לנחש איזו סיסמא אחת ולהכנס לארגון...

הידיעה בנרג' בקושי לכדה את תשומת לבי. מצאו פרצה ב-Acrobat. לא באמת חדש וגם לא בטוח כמה זה מעניין. אלא שקריאה אצל RSnake ו-Jeremiah Grossman לימדה אותי אחרת. לכאורה מדובר בפרצה בקבצי PDF שמאפשרת להריץ מתקפות Cross Site Scripting. איך זה עובד (באדיבות הרשימה של Grossman)?

1. מאתרים אתר המכיל קובץ PDF (וכאלה יש בלי סוף).
2. בונים קישור לקובץ ובסופו מוסיפים סקריפט זדוני.
3. שולחים את הקישור למישהו ואם הוא מריץ את הגרסה המתאימה של Acrobat/דפדפן, הוא נפגע.

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

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

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

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

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

לקריאה נוספת: האתר של RFIDVirus, האתר של RFIDGuardian, כיצד ניתן לעקוב אחריכם עם RFID (באדיבות סדקים)

שתי רשימות בלוגים שקראתי לאחרונה שוות התייחסות. הראשונה שייכת ל-Jeremiah Grossman, בחור די חביב עם בלוג די טוב בנושא אבטחת יישומים. ברשימה שפרסם שכותרתה "האם אנו סומכים על אבטחה בצד הלקוח?" הוא טוען כי הכלל הידוע של המנעות משימוש במנגנוני אבטחה בצד הלקוח נשבר זה מכבר ולמעשה צריך להבין כי אנחנו כל הזמן מיישמים אבטחה בצד הלקוח. כדוגמא הוא מביא את המפגעים שהתגלו בשנתיים האחרונות בדפדפנים, מתקפות XSS ו-CSRF וכדומה. אלא שגרוסמן טועה. העובדה שישנם מפגעים בצד הלקוח אינה קשורה לתכנון האבטחה ואינה אומרת שאנו חייבים להסתמך על אבטחה בצד הלקוח. הוא כן מעלה (מבלי משים) נקודה נכונה ובה אני רוצה להתמקד. כאשר אנחנו מיישמים אבטחה במערכות Web, כמעט תמיד אנו מגדירים את מחשב המשתמש מחוץ לגבולות מערכת האבטחה שלנו. זה שיקול נכון ברוב המקרים, אך חשוב לזכור כי כשאנחנו בוחרים שלא להתמודד עם סיכונים מסוימים זה לא מעלים אותם. כמעט תמיד, כשנשב לבצע תכנון אבטחה למערכת, יהיה זה נכון להגדיר מספר הנחות יסוד. על בסיס מה אנחנו מחליטים לתכנן את האבטחה. הנחות אלה יתייחסו להיבטים פונקציונאליים (שימושיות המערכת), טכנולוגיים וכדומה. אחת ההנחות צריכה להתייחס לגבולות המערכת, את מה אנו מאבטחים ואת מה לא. לגבי מה שאנו לא מאבטחים, צריך להעריך את הסיכון הצפוי. המשמעות המעשית היא שניתוח הסיכונים צריך ברוב המקרים להיות נרחב יותר מתכנון האבטחה בפועל.

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

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