הגליון הארבעים ושניים של Digital Whisper שוחרר!

ברוכים הבאים לגיליון יוני! הגיליון ה-42 של Digital Whisper!
כמו בכל חודש, גם החודש אין לי דבר חכם מדי להגיד (ולמרות זאת, אתם לא לומדים לקח - וחוזרים לקרוא את זה בכל פעם מחדש), אך הפעם חשבתי לנצל את הבמה לדבר על הנושא האתי שהחודש עלה לא פעם, במספר מקומות באינטרנט - הדיון על "Vulnerability Disclosure Policy", או אם תרצו:
 
האם, איך, ומתי יש לפרסם חולשה שנמצאה
לפני שאגש לדיון עצמו, אתן רקע קצר: לדעתי, האקרים כיום, מהווים את אחת הפונקציות המרכזיות המרכיבות את רשת האינטרנט שלנו והם המאפשרים פעילות תקינה בה. יש לכך, לדעתי, סיבות רבות. אך בכל הקשור לנושא, המצב הוא כך: כאשר חברה, ספק תוכנה או ספק שירות כלשהו באינטרנט מפתח מוצר, לנו הצרכנים, כמעט ואין דרך לשלוט במוצר העצמו מבחינת אבטחה, מלבד כמובן, דרך ממשקי הקונפיגורציה אותם יצר הספק. אם אני משתמש בחשבון GMail למשל, אני יכול להגדיר "סיסמה חזקה" או להחיל מנגנון דו-שלבי לאימות. כנ"ל אם אני משתמש בכל תוכנה אחרת, כגון תוכנה למסרים מיידים, תוכנה לצפייה / עריכת מסמכים, מערכת הפעלה מסויימת, תוכנת דפדפן, שרת אינטרנט או מערכת בלוגים - בכל התוכנות הנ"ל, אני יכול לקבוע את רמת אבטחת המידע בעזרת הממשקים אותם הכינו לי מראש מפתחי המוצר.
 
אך מה קורה, כאשר מתגלים כשלי אבטחה באיזורים מחוץ לסקופ שמאפשר לי השימוש בממשקי הקונפיגורציה? אם משהו בארכיטקטורה עצמה אינו מאובטח - ממש ברמה הלוגית של המוצר, או כמו שאנחנו רואים לא פעם - ברמת הקוד עצמו - לא משנה מה יהיה אורך הסיסמה שלי, כמה שלבים כולל תהליך ההזדהות לחשבון שלי או האם לא אפשרתי שימוש בפיצ'רים ניסיוניים, כל עוד השאילתות אל מול מסד הנתונים מתבצעות ללא סינון קלט, כל תוקף יוכל להתחבר לי לחשבון מבלי למצמץ
 
בשלב הזה, למשתמש הפשוט אין יותר מדי מה לעשות מלבד לחכות לעירנות ספקי התוכנה או השירות, ולהתפלל שלא יבוא גורם זר וימחוק / יגנוב לו את כלל הנתונים בחשבון.
 
זה לא סוד כי רובן המוחלט של ספקיות התוכנה לא ששות לתקן כשלי אבטחה, וכל עוד לא הוכח נזק, או פוטנציאל לנזק - יהיה קשה מאוד, בתור המשתמש הפשוט, ללחוץ עליהן ולגרום להן לעצור את כלל תוכנית עבודת הפיתוח של הריבעון הנוכחי ולתקן את אותו הכשל. יצא לי לא פעם למצוא ולדווח על כשלי אבטחה במוצרים בסדר גודל עולמי, ולא פעם נתקלתי בתשובה כי "ההודעה עברה לגורם הרלוונטי" - ומאז לא נראו עקבותיה או יותר גרוע בחוסר תשובה כלל. במקרה כזה - מה עוד אני יכול לעשות?  
  
בדיוק כאן נכנס הנושא של "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? - (נכתב ע"י אפיק קסטיאל / cp77fk4r):
              מי שעוקב אחרי בלוגים של חברות אנטי-וירוס יכול לראות מגמה עולה של דיווחים אודות קמפיין זדוני חדש בשם CDorked
              או DarkLeech או Chapro (תלוי באיזה בלוגים אתם קוראים...). נכון לכתיבת שורות אלו, המחקר, שמובילים אותו צוות
              רציני ב-ESET, עדיין בעיצומו, ולמרות שחלקים רבים מהקמפיין נחשפו ישנן עדיין שאלות רבות שטרם מצאו להן תשובות.
              במאמר הבא נביא את סיפורו של המחקר, נציג את הממצאים ואת ניתוח הקמפיין ואת המסקנות שהחוקרים הגיעו אליהן עד
              כה.
 
  • Malwares 2.0, ודרכי התמודדות בארגון  - (נכתב ע"י אריק יונאי):
              כולנו מבינים את חשיבותו של אנטי-וירוס בארגון. סטטיסטית, רוב האנטי-וירוסים (ה-"מסורתיים") של רוב היצרנים, יזהו את
              רוב ה-Malwares הנפוצים בארגון. אך בדיוק כאן מתחילה הבעיה - אם נסתכל על "מחזור החיים של וירוס ממוצע", נראה
              כי תוכנות אנטי-וירוס אינן רלוונטיות (ברב הפעמים), כאשר מדובר במתקפה של וירוס חדש או כאשר מדובר במתקפה
              ממוקדת. במאמר זה מציג אריק כיצד ניתן למזער באופן משמעותי את הבעיה, באילו טכנולוגיות עדיף ומומלץ להשתמש,
              כיצד, ואילו דברים לא מומלץ לבצע.
  
  • אנטומיה של בוט - ההגנה הטובה ביותר היא התקפה - (נכתב ע"י לאוניד יזרסקי):
             כאשר אנו מעוניינים להתגונן מפני מתקפות האקרים על הארגון שלנו, או כפרטיים, סביר להניח שנשתמש בכלים הסטנדרטים
             שמציע השוק. כלים אלו בדרך כלל  יספקו הגנה סבירה כנגד רב האיומים, אך המשותף לרב הגדול של הפתרונות כיום הוא
             שהם מבצעים הגנה פאסיבית. במאמר זה, מציג לאוניד, למה שיטות ההגנה תמיד נשארות צד אחד מאחורי התוקפים,
             ובמקביל מציע דרכים האקטיביות לטובת הגנה מפני התוקפים.
   
  • על VLANS ועל Private VLANS - (נכתב ע"י רון הרניק):
             הרעיון של VLAN לא רעיון שונה מכל סוג אחר של וירטואליזציה. אנו מבצעים חלוקה לוגית של תשתית פיזית כלשהי.
             כמו שאנו מחלקים את הכונן במחשב למחיצות, אך הכונן הוא מקשה פיזית אחת, כך גם אנו יכולים לחלק מתג (Switch)  
             לרשתות שונות. שימוש ב-VLAN מספק לנו מידור, חוסך תנועה מיותרת, מידה מסויימת של אבטחה וחסכון בציוד. אך מה
             קורה כאשר אנו רוצים לשלוט בתקשורת בין תחנות הנמצאות באותה ה-VLAN? אנו מעוניים להשאיר את התחנות באותו
             טווח כתובות IP, אך אנו רוצים שחלק מהתחנות לא יהיו מסוגלות לתקשר אחת עם השניה וחלקן כן. במידה ומצאתם את
             עצמכם במצב המאוד ספציפי הזה, Private VLAN הוא פתרון אפשרי. במאמר זה מציג רון את עולם ה-Private VLAN
             וכיצד ליישמו.

   
                                                                                                                  
 
 



תגובות על 'הגליון הארבעים ושניים של Digital Whisper שוחרר!':



#1 

שמיל (אורח):
1!

תודה רבה חברים! נראה גיליון מעולה! כל הכבוד על ההתמדה!
31.05.2013 19:53:49

#2 

יקיר ויצמן (אורח):
כמו תמיד - מעולה :).
31.05.2013 20:03:00

#3 

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

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

האקרים היום תוקפים ומתקנים בעיות גם בעולמות אחרים (תחבורה-תעופה,כלים יבשתיים. רפואה וכו׳)
31.05.2013 23:37:45

#4 

cp77fk4r:
תודה רבה. וכן, אני מסכים איתך בהחלט, כיום האקרים פועלים במספר רב של מישורים הרבה מעבר לרשת האינטרנט, אך עדיין, מדובר באותה הנקודה שאני דיברתי עליה. תודה על החידוד.
31.05.2013 23:56:41

#5 

דייב (אורח):
פתיחה מעולה ומנוסחת היטב. תודה רבה על עוד גיליון נהדר!
01.06.2013 00:22:05

#6 

(אורח):
אחלה גליון :)
אגב אם כבר דובר על phrack לא היה אמור לצאת כבר מספר 69?
01.06.2013 21:27:16

#7 

hfm (אורח):
איזה כיף....
עכשיו יהיה לי מה לקרוא במילואים.
01.06.2013 21:51:15

#8 

cp77fk4r:
כיף לשמוע :), ו-TCLH אף פעם לא היו ידועים בתור חבר'ה שעומדים בלוחות זמנים ;)
01.06.2013 23:05:41

#9 

Dm12 (אורח):
תודה רבה! גיליון מעולה! גם אני רוצה להצטרף ולהגיד - הקדמה מצוינת!
02.06.2013 08:50:55

#10 

גיל (אורח):
שמע, ממש פתחת לי את העיינים עם ההקדמה הזאת! אף פעם לא חשבתי על זה ככה וזה כל כך נכון... פתיחה ומאמרים איכותיים ביותר! תודה רבה לכם!
03.06.2013 07:13:29

#11 

גיל (אורח):
ומי זה TCLH?
03.06.2013 07:14:19

#12 

cp77fk4r:
The Circle of Lost Hackers העורכים האחרונים של Phrack
03.06.2013 18:18:07

#13 

כסיף דקל (אורח):
מגניב, טנקס =]
06.06.2013 13:47:41

#14 

גידי (אורח):
חברים המון תודה! אין ספק האינטרנט נהיה מקום קצת מפחיד לחיות בו. כששרתים של חברות ענק נמצאים תחת שליטה של האקרים - כנראה שאנחנן לא בעמדה טובה.
06.06.2013 21:10:21

#15 

שמיל (אורח):
לפעמים, כשהשרתים נמצאים בידי החברה עצמה - זה עוד יותר גרוע (עם כל המידע שיש להם עלינו...) :)
07.06.2013 10:52:41

#16 

Fnk (אורח):
תודה רבה! המאמרים מעולים! מאוד אהבתי את המאמר על ה-vlans, עושה רושם שהכותב ממש חי את זה! תמשיכו ככה!
07.06.2013 17:24:09

#17 

r3D-D3vil (אורח):
תודה רבה לכל הכותבים!
08.06.2013 23:44:11

#18 

natinet (אורח):
תודה רבה!
13.06.2013 18:09:19

#19 

גרין (אורח):
תודה רבה! מעניין בטירוף!
14.06.2013 23:41:33



הוסף את תגובתך:
כינוי:
תגובה:
קוד אבטחה:
העתק לכאן את הקוד:
 
Digital Whisper © 2009 - 2017 - כל הזכויות שמורות ל-אפיק קסטיאל ול-ניר אדר.