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

1. תקלות תפעול

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

ברירת המחדל של MongoDB היתה לא להשתמש בסיסמא או כל מנגנון בקרת גישה אחר. כשמתכנתים בחברת AI Type התקינו את מונגו הם פספסו את הבעיה התפעולית והשאירו את בסיס הנתונים המלא שלהם ללא סיסמא:

https://9to5google.com/2017/12/05/ai-type-data-leak/

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

https://internet-israel.com/חדשות-אינטרנט/רשלנות-משמעותית-במשרד-הפנים-חושפת-את-פ/

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

https://www.calcalist.co.il/internet/articles/0,7340,L-3713044,00.html

2. הגורם האנושי

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

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

https://www.washingtontimes.com/news/2016/oct/27/celebgate-hacker-ryan-collins-sentenced-18-months-/

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

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

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

3. מוקשים מהעבר

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

כך לדוגמא חברת D-Link השתילה בראוטרים מדגם מסוים דלת אחורית שתאפשר לה להשתלט מרחוק על כל הנתבים מדגם DIR-620. אפילו אחרי שחוקרים גילו את זה החברה נמנעה ממחיקת המנגנון ושיחרור עדכון קושחה (לא שמישהו מתקין עדכוני קושחה ממילא). הם טוענים שהנתב ישן מדי.

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

https://arstechnica.com/information-technology/2015/05/https-crippling-attack-threatens-tens-of-thousands-of-web-and-mail-servers/

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

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

4. האויב שבפנים

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

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

https://www.zdnet.com/article/the-dyn-report-what-we-know-so-far-about-the-worlds-biggest-ddos-attack/

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

5. שימוש לא נכון בכלים

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

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

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

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

6. רעיונות נוספים?

סוגי מתקפות שפספסתי? סיפורים מעניינים שלכם שאתם רוצים לשתף? אשמח לשמוע בתגובות.