דרך התקיפה: רכיבי קוד פתוח בתוכנה
תוכנה מסחרית מכילה בממוצע קוד פתוח בשיעור של כ70% , את התוכנה המסחרית בונים (Build) משילוב של קוד מקור הנכתב על ידי המפתחים בחברה וגם עם אבני בניין (Artifacts) של חלקי תוכנה מוכנים המשתלבים בהליך בניית התוכנה לפי הצורך. חלק מאותן אבני בניין נמצא במאגר נתונים פנימי (Local Repository) וחלקים של אותן אבני בניין נמצאים במאגרי נתונים ציבוריים (Public Repository) ונקראים אל תהליך הבניה לפי צורך. הצורך לרוב הוא תלות (Dependency) של אבן בניין מהמאגר הפנימי בשל עדכון רכיב תוכנה.
המוטיבציה: פרסים כספיים בשווי עשרות אלפי דולרים (היה יכול להיות גם אחרת)
לכל חברה יש את נהלי אבטחת המידע שלה וכן כללים ובדיקות קוד כדי לוודא פיתוח מאובטח. חברות גדולות אף מגדילות לעשות ומפרסמות תחרות נושאת פרסים למי שמצליח לפרוץ את התוכנה שלהם. המונח נקרא באג-באונטי (Bug Bounty), האקרים לבנים (כאלה הפועלים ממניעים טובים בלבד) מנסים למצוא חולשות בתוכנה, במידה ומצאו הם מדווחים לחברה על החולשה שמצאו ודורשים את הפרס. זה משתלם לשני הצדדים כיוון שהחברה מונעת לעצמה מבוכה וסוגרת פרצה שיכולה הייתה לסכן את פעילותה ואת נתוני החברה, ולהאקר זו הכנסה נאה.
השיטה:
לפני כחודש וקצת האקר לבן בשם אלכס בירסן קיבל פרסי באג-באונטי בשווי 130 אלף דולר לאחר שהצליח לעקוף את כל מעגלי האבטחה של חברות, מהמובילות בתעשיית התוכנה בעולם, חברות כמו אפל, מייקרוסופט, פייפאל ועוד כמה גדולות ומפורסמות. הכל התחיל מקובץ חבילת התקנה (package manager) של פייפאל שהתגלגל לידיו והכיל בתוכו רשימת אבני בניין ממאגרים פנימיים של פייפאל וכן כמה ממאגרים חיצוניים. הוא בדק במאגרים החיצוניים האם יש שמות חבילות זהות לאותם רכיבים הנמשכים מהמאגר הפנימי, משגילה שאין חבילה שכזו במאגר החיצוני הוא “יצר” חבילה כזו בעלת שם זהה ואף קבע לה ערך גרסה גבוה יותר מהחבילה הפנימית. בקוד של החבילה הוא הכניס הוראות ליצירת קשר עימו כהוכחה לזכאותו לפרס.
הוא ניסה את השיטה גם במאגרי חבילות התקנה אחרים עם שפות תכנות שונות והצליח גם שם. לחולשת האבטחה החדשה שגילה הוא קרא בשם “בלבול תלויות” ( Dependency Confusion)
יש לציין כי מדובר בעקרון שהיה ידוע, הבעיה אינה חדשה, פשוט לא עשו בה שימוש לצורכי באג באונטי.
האם הסכנה חלפה?
בין החברות שנחשפו לחולשה היו שסירבו לשלם פרסים עבור הגילוי אולם גם הן מופיעות במאמר שפורסם בנושא ואשר חשף כעת לעולם את החולשה ואת השיטה. החיקויים לא איחרו להגיע, כ7000 חבילות מזויפות נוצרו בימים שלאחר הפרסום על ידי האקרים לבנים שונים כדי לנסות ולגרוף פרסים מחברות נוספות. ללא צל של ספק גם האקרים שאינם אתיים (אפורים ושחורים) מנסים את מזלם בדיוק באותה שיטה כדי להחדיר קוד זדוני לארגון.
העובדה שחולשה זו נחשפה בחבילות התקנה בשפות תכנות בודדות אינה שוללת חולשה דומה בשפות תכנות אחרות ובשיטות בניית תוכנה אחרות כגון DOCKER הפופולארית. הרי גם לקונטיינרים יש תלויות וחברות משתמשות בשילוב של מאגרים פנימיים וחיצוניים. נכון לכתיבת שורות אלה חולשה דומה בDOCKER טרם נבדקה.
אז מה אפשר לעשות כדי לצמצם את החשיפה לשיטה הזו של "בלבול התלויות" ?
קודם כל, פשוט לא להשתמש במודל היברידי של חבילות התקנה המערבות חבילות ממאגרים פנימיים וחיצוניים.
בנוסף מומלץ לשלוט ברשימת ההזנה של כל חבילות התוכנה תוך ידיעה ברורה היכן היא מאוחסנת ושאין לה כפילות חיצונית שאינה רצויה.
חברת הסייבר הישראלית דוסטיקו שיחררה פתרון חינמי מבוסס קוד פתוח לבעיה.
לינק לתוכנה : https://github.com/dustico/dusti-lock
האם אפשר בכלל לנהל את כל אבני הבניין בתוכנה בצורה ידנית?
התשובה היא חד משמעית – לא! זו פרקטיקה שאינה נכונה ובעיקר חסרה. הפער בין ניהול ידני לניהול באמצעות כלי אוטומציה המבקר ובוחן את בניית המוצר יכול להגיע עד לפי 20. תוכנה ממוצעת מכילה כ450 ספריות שונות של קוד פתוח.
