ברוכים הבאים לגיליון יוני! הגיליון ה-42 של Digital Whisper!

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

 

האם, איך, ומתי יש לפרסם חולשה שנמצאה

  

בדיוק כאן נכנס הנושא של "Vulnerability Disclosure" 

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

 

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

 

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

 

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

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

 

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

 

בדיקות חדירות היא אקט שלדעתי חובה לבצע בכל שלבי הפיתוח (אף בשלב האיפיון, על מנת לבחון את המוצר עוד בשלבים המוקדמים שלו, ולנסות לעלות על כשלים שבהמשך יהיה קשה ויקר מאוד להתמודד איתם), אך תמיד ימצאו כשלי אבטחה כאשר המוצר יהיה בשטח. וזה בסדר גמור, אין מפתח מושלם (אני לפחות עוד לא פגשתי אחד כזה, ואם אתם מכירים - תפנו אותו אלי, יש לי משרה להציע לו), וגם אם יהיה אחד כזה - מה שנתפש בזמן הפיתוח כבטוח, מחר יכול להחשב כטעות קריטית ואיומה מבחינת אבטחת מידע (תנסו לחשוב על היום שלפני פרסום גיליון ה-49 של Phark, שבו Aleph One הציג את המאמר האגדי "Smashing The Stack For Fun And Profit" והכיר לעולם את ה-Buffer Overflows, או יום לפני ש-Rain Forest Puppy פרסם את המאמר "How i hacked Packetstorm" ב-1998 והביא לעולם את בשורת ה-"SQL Injection"). 

 

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

 

ישנן כיום מספר חברות וארגונים (כגון Facebook ,Mozilla ,Google ,PayPal) אשר לקחו את הנושא צעד אחד קדימה ויזמו תוכניות מסוג "Bug Bounty", תוכניות שבמסגרתן הן מזמינות חוקרי אבטחה והאקרים לחפש חולשות וכשלי אבטחה במוצריהן עבור כסף ופרסום - זה כאילו שהן מעסיקות את קהילת ההאקינג העולמית (או לפחות את מי שמעוניין מאותה קהילה), 24 שעות ביממה, 7 ימים בשבוע, עבור שירותי PenTesting. כל חברה מפרסמת מדיניות משלה, חלקן מאפשרות לפרסם את ממצאי ופרטי הכשל לאחר תיקונו, וחלקן לא, אך כמעט בכל המקרים - התגמול הכספי שווה את זה. לא פעם קורה שהאקרים קוראים לחברות שונות לפתוח בתוכניות מסוג זה, כמו למשל הפוסט האחרון של חוקרי האבטחה Nils Jünemann.

 

בסופו של דבר, תוכניות Bug Bounty, פרסומים ב-Full Disclosure, BugTraq או Defcon - האקרים וחוקרי אבטחה מכל העולם ימשיכו לחקור ולפרסם כשלי אבטחה, ולדאוג (כל אחד בדרכו שלו וכל אחד עם המניעים שלו) לכך שנוכל להמשיך להשתמש באינטרנט ולהתנהל אינטרנטית עם כמה שפחות דאגות.

 

ומי כמונו יודע כמה יש... 

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

 

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

              או DarkLeech או Chapro (תלוי באיזה בלוגים אתם קוראים...). נכון לכתיבת שורות אלו, המחקר, שמובילים אותו צוות

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

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

              כה.

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

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

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

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

              כיצד, ואילו דברים לא מומלץ לבצע.

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

             כמו שאנו מחלקים את הכונן במחשב למחיצות, אך הכונן הוא מקשה פיזית אחת, כך גם אנו יכולים לחלק מתג (Switch)  

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

             קורה כאשר אנו רוצים לשלוט בתקשורת בין תחנות הנמצאות באותה ה-VLAN? אנו מעוניים להשאיר את התחנות באותו

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

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

             וכיצד ליישמו.