הצדדים השליליים של VPN

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

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

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

הזמן הוא יום שישי בבוקר (שבוע שעבר).
המקום הוא משרדי הלקוח.
הסיבה שאני יודע על זה היא שנשלחו שם מיילים על מה שקרה לכולם.

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

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

נבוכים, ולא מעט חוששים, הם שולחים מייל לכולם שאומר "המדפסת התחילה להדפיס בעצמה. האם יש לנו וירוס? כולם להזהר" וכו'.

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

שולח מנכ"ל החברה מייל:
"הבנתי הכל חוץ מדבר אחד. יאסר ערפאת?????"

ועל זה נאמר: "On the internet, no one knows you do metal mockups of Yasser Arrafat"

שחר

"כשל אבטחה חמור התגלה בלינוקס", או שלא כל כך חמור

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

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

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

מה עושים? משתמשים ב"מקורות אקראיות". מדידה של מליוניות שניה של תזמוני לחיצה על מקשים, פעילות דיסק, וכו'. הקרנל של לינוקס עושה את זה כל הזמן, ומייצר מאגר של נתונים אקראיים. תוכנית שרצה בלינוקס יכולה לבקש לקבל את המאגר הזה, ולהשתמש בו.

ומה קורה אם המאגר נגמר?

בלינוקס יש שתי אופציות. הראשונה היא לחכות עד שיגיע עוד מידע אקראי. השניה היא להשתמש בפונקציות "כמעט אקראיות" (Pseudo random number generators) כדי לקבל רצף של מספרים.

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

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

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

התחומים הם הצפנה (קריפטוגרפיה) ואבטחת מידע.

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

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

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

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

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

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

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

לא נכון.

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

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

לסיכום:
בעיה שצריך לפתור? כן.
בעית אבטחה חמורה? לא.

שחר

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

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

חדשות לגבי בעיות האבטחה של ישראבלוג

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

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

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

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

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

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

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

שחר

עוד חור בישראבלוג?

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

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

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

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

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

הסטטוס שלכם: לא ידוע

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

כמובן שסיפרתי ליריב על העובדה שדווקא כן ניתן לגשת לעוגיות. התגובה שלו היתה קצת מאכזבת:

I know, but instead of chasing cookie stealers, I made it impossible to use other people's cookies.

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

עדכון: כנראה שה-Session עכשיו קשור ל-IP. אני חושש שזה פותר את הבעיה רק באופן חלקי. יש אנשים שגולשים דרך Proxy, מה שגורם להם לשתף IP עם לא מעט משתמשים אחרים. מצד שני, יש אנשים שה-IP שלהם משתנה תוך כדי עבודה, מה שימנע מהם להשתמש בישראבלוג בכלל עכשיו. קשירה של IP ל-Session נחשבת לא בריאה בתכנות HTML.

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

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

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

כמו שכתבתי כבר בסיכום הפריצה, קצת קשה לי להאמין שהמערכת תשתפר .

בברכת יום נפלא,

שחר

קצת הערות על הפריצה לישראבלוג

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

נתחיל מהשורה התחתונה: יהיו עוד חורים כאלו!

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

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

אז מה בעצם קרה בפריצה של אתמול? הפורץ החדיר קוד אל תוך הבלוג של מי שנפרץ עם javascript שדואג לכך שהדפדפן ישלח את ה-cookies שיש לו לאתר של הפורץ. ה-cookies הנ"ל מאפשרים לפורץ להתחזות לדפדפן של הקורא בבלוג. אם הקורא בבלוג מחובר באותו הרגע גם במצב עריכה לבלוג שלו עצמו, הרי שלפורץ יש את כל המידע שהוא צריך כדי להתחבר בתור הקורא, ולשלוח את הפוסט הזה לעוד בלוג. הפורץ הפעם לא רצה להיות מתוחכם במיוחד, אבל הפורץ הבא בהחלט היה יכול לבצע את התהליך הזה באופן אוטומטי, מה שהיה מדביק, להערכתי, כ-80% מהבלוגים בישראבלוג.

איך אפשר להתגונן?

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

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

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

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

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

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

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

אתמול התגלה לנו שהתוקף מצא וקטור שלישי.

הסיכויים שקיים גם רביעי וחמישי הם כמעט וודאיים.

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

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

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

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

האם זה אומר שזו לא אשמתו של הפורץ?

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

האם יש משהו לעשות נגד השנות מקרים כאלו?

כן.

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

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

ל-cookies יש אפשרות שהם יהיו תקפים רק באזור מסויים בתוך האתר. אם יריב יגדיר את ה-cookies של ה-session כך שהם יהיו מוגדרים רק באיזור של העריכה, ולא באיזור של קריאת הבלוגים, קוד javascript שרץ באזור הקריאה לא יוכל לגנוב אותם. זה שינוי שלא משנה את חווית השימוש באתר, והוא יכול להכניס אותו יחסית בקלות.

בואו נקווה שהוא גם יעשה את זה.

שחר

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

זה היה חייב לקרות

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

עדכוני תוכנה זה מלכוד 22 קלאסי למנהלי רשת ולחברות – You're damn if you do and you're damn if you don't.

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

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

בגלל דברים כאלו נתתי כבר בעבר נבואות זעם.

שחר

ACLים לא בטוחים

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

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

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

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

שחר

נ.ב.
כמה קל להגיד "אמרתי לכם"?

על מרכזיית Avaya

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

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

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

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

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

אם התמדתם עד כאן, אתם יכולים לטעון, במידה רבה של צדק, שהבעיה היא בחברה שנותנת את השירות בארץ, ולא ב-Avaya עצמם.

בסוף אמרתי לו פשוט לשים את התוכנה על מחשב אחד, ועקבתי אחרי השימוש שלו. הנה מה שהסתבר לי:
כאשר מתקשרים ב-UDP או ב-TCP, יש מספרי "port". תחשבו על זה ככה. אם כתובת ה-IP משולה למספר טלפון, מספר ה-Port משול למספר שלוחה. למרות שאין ב-UDP כל דרישה מפורשת כזו, נהוג שתקשורת שיוצאת מפורט א' לפורט ב' תענה ע"י תקשורת מפורט ב' לפורט א'. רוב הפיירוולים יודעים את העובדה הזו, ומאפשרים לתקשורת לחזור באותו מסלול.

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

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

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

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

שחר

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