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

 

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

 

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

 

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

 

האירוע הראשון התרחש ב-25 לדצמבר, שנת 1998. בעת פרסום הגליון ה-54 של Phrack, תחת הכותרת הדי סתמית: "NT Web Technology Vulnerabilities", כמאמר שפורסם ע"י Jeff Forristal (המוכר יותר בכינויו: "Rain Forest Puppy"). המאמר הנ"ל הינו התעוד הכתוב הראשון של אחת מהחולשות הקריטיות ביותר שנמצאו היום בשרתי WEB: SQL Injection. עברו כמעט 20 שנה ועדיין, המתקפה הזו נמצאת כל שנה ב-TOP3 של OWASP. עד המאמר הנ"ל לא היו שום מתקפות על Database-ים באופן ישיר ואף מפתח או גוף הגנה לא ראה במשאב הזה משהו שצריך להגן עליו מעבר ל-לא לאפשר גישה ישירה אליו ולהגן עליו עם סיסמה.

 

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

 

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

 

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

 

האירוע השני, אשר גם הוא שינה את פני החוקים בעולם מתקפות ההאקינג, וגם הוא קשור ל-Phrack, התרחש בנובמבר שנת 1996 כמאמר שפרסם כחלק מהגליון ה-49 ונכתב ע"י בחור בשם Aleph One. המאמר פורסם תחת הכותרת האלמותית: "Smashing The Stack For Fun And Profit", ובעצם היווה את ההסבר הפומבי הראשון על מתקפות Buffer Overflow: כיצד הן פועלות, כיצד ניתן למצוא אותן, וכיצד ניתן לנצלן לטובת חדירה למערכות השונות.

 

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

 

פחות או יותר, עד פרסום המאמר, מלבד בודדים מאוד, אף אחד לא חשב כי בעזרת קלט שמגיע מהמשתמש, ניתן לשנות את Flow ריצת התוכנית. אם התוכנית מצפה לקבל ולפעול ע"פ אחד מ-3 קלטים שונים, אין שום סיכוי או סיבה בעולם שהיא תבצע פעולה שהיא לא אחת משלושת הפעולות שנקבעו לה. להצליח לגרום לתוכנית שאמורה לרכז קבצי לוג ליזום Socket לכתובת IP של תוקף חיצוני ובכך לאפשר לו גישת Shell על השרת? אפילו לא בחלומות הכי הזויים של התוכניתן. לגרום לתוכנה שאמורה לטפל במיילים להאזין בפורט מקומי ולהדפיס לכל מי שמתחבר את קובץ ה-/etc/shadow? אין שום סיכוי, זה הרי לא כתוב לה בקוד. ואם על מנת להתחבר לתהליך מסויים יש צורך בסיסמה - אז אם הגדרנו סיסמה חזקה, אין שום סיכוי שמישהו שלא מכיר את הסיסמה יצליח להכנס. אף אחד לא יכל לדמיין או להעלות על דעתו כי כל הנ"ל אפשרי, פשוט צריך להכניס את הקלט הנכון שיגרום לדריסת זיכרון במקום הנכון.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

• מבוא ל Web 3.0-וסקירה של חולשות ותקיפות חוזים חכמים מעל הבלוקצ'יין - נכתב ע"י גיא ברשפ
  תחום הבלוקצ'יין והאפליקציות המבוזרות מסתמן כאחת ההבטחות החמות של השנים הקרובות. מדובר במהפכה של ממש באופן שבו האינטרנט העתידי עשוי להתקיים (0.Web 3), כאשר הכיוון הוא להחזיר את האינטרנט למצב מבוזר שאינו ריכוזי. זאת לעומת המצב כיום, אשר רוב התעבורה והשירותים ניתנים ע"י מס' מצומצם של חברות ענקיות כגון: גוגל, פייסבוק וכד'. יחד עם זאת, בדומה לכל טכנולוגיה שמביאה עמה הזדמנויות רבות, היא גם טומנת בחובה לא מעט סיכונים ואיומים. נוסיף את כמות הכסף הרב המושקע בטכנולוגיה הזו, ובקלות נוכל להבין מדוע כלל העיסוק בבלוקצ'יין הינו "פארק שעשועים להאקרים" . במסגרת מאמר זה, מציג גיא ברשפ את הרעיונות והמקורות הטכניים ללימוד נושא הבלוקצ'יין ומהפכת Web 3.0 וכן מבצע סריקה של מגוון סוגי החולשות הידועות בתחום. 

• One push too far - Exploiting Web Push Notifications - נכתב ע"י זהר שחר
  Push Notifications אינה טכנולוגיה חדשה. למעשה, אנו מכירים את הנושא היטב בהקשר של טלפונים ניידים, כאשר כמעט כל אפליקציה מייצרת עבורנו התראות. עם זאת, בשנים האחרונות היכולת לשלוח התראות בדחיפה התווספה גם אל עולם ה-Web ,ועתה ניתן לקבל התראות ישירות אל הדפדפן. במאמר זה, זהר מציג מחקר שביצע, הבוחן את המנגנון בהיבטי אבטחת מידע כדי לנסות ולהבין אילו הרשאות ניתנות לאתרים המשתמשים בהתראות, ואילו סיכונים מנגנון זה חושף (רמז: לא מעט!)

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