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

פרסומת

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

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

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

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

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

גילוי מלא לעומת אחראי

ישנן שתי דרכים פופולריות לחשוף פגיעויות לספקי תוכנה.

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

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

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

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

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

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

מסתבר, ישנם כמה טיעונים משכנעים לשני הצדדים.

הטיעונים לטובת הגילוי האחראי

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

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

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

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

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

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

היו מספר מוצרי DNS מרכזיים שהושפעו, כולל מוצרים שנבנו על ידי אלקטל-לוסנט, BlueCoat Technologies, אפל וסיסקו. הנושא השפיע גם על מספר יישומי DNS שנשלחו עם כמה הפצות לינוקס / BSD פופולריות, כולל אלה עבור Debian, Arch, Gentoo ו- FreeBSD.

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

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

פגיעות ה- DNS של קמינסקי מסכמת בסופו של דבר את עיקר הוויכוח לטובת גילוי נאות ואחראי. כמה פגיעויות - כמו פגיעויות באפס יום מהי פגיעות של יום אפס? [MakeUseOf מסביר] קרא עוד - הם כה משמעותיים, עד ששחרורם בפומבי יגרום נזק משמעותי.

אבל יש גם טיעון משכנע בעד אי התראה מראש.

המקרה לגילוי מלא

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

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

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

מה רוצים ספקים?

הספקים ממש לא אוהבים את הגילוי המלא.

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

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

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