לא פרצו לנו, רק דלף לנו – לקחים טכניים מפרשת אלקטור

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

מה קרה שם?

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

שני פרקים בפודקאסט סייברסייבר עסקו בכך – פרק 30 ופרק 31.

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

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

אני רוצה להתמקד יותר בלקחים הטכניים שהם לאו דווקא הכשלים המזעזעים שהיו באלקטור (ססמאות ושמות משתמש ב-HTML!!!) אלא יותר בדברים אוניברסליים.

ההבדל בין פריצה לדליפה הופך לסמנטיקה בלבד

כשאנחנו כותבים פריצה – למשל ״חשד לפריצה לאתר״ יש כאלו שיחשבו על תוקפים שהצליחו להכניס קוד משלהם למערכת, הצליחו לנצל חולשה כדי למשל לעשות RCE (פוסט פשוט שלי על RCE למי שלא מכיר) או SQL Injection שבמסגרתו מורידים את כל מסד הנתונים. אבל לא מעט פעמים, תוקפים לאו דווקא חודרים למערכת באופן הזה אלא משתמשים בחולשות אחרות שאינן ממש פריצה. למשל IDOR. אם תוקף למשל מצליח לגשת ל api/get-user/1 ובמקום 1 לרוץ על כל המספרים ולקחת אותם זו בהחלט תקלה שהתוצאה שלה היא השגת כל המידע של המערכת – די דומה ל SQL Injection. נכון, מהבחינה המקצועית גרידא זה שונה ויש הבדל בין שגיאת קוד שמאפשרת הרצת קוד על השרת שהיא יותר חמורה משגיאת קוד שמאפשרת שתייה של המידע.

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

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

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

ביעור הנתונים

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

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

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

מה פרוטוקול ביעור נתונים כולל?

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

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

אישור חתום: אחרי בדיקה של המיפוי, שיטת המחיקה והבקרות.

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

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

Retention Policy

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

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

חוסר בלוגים, ניתוח אנומליה ובעיות אחרות

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

הרשות להגנת הפרטיות חיפשה "אינדיקציה טכנולוגית לחדירה". בעולם ה-IT, זה לרוב אומר חיפוש ב-System Logs אחר ניסיונות Brute Force, התחברות ממדינות עוינות, או שינוי בקבצי מערכת ושאר ירקות, אבל אם הגישה למידע בוצעה דרך נתיב "לגיטימי" (כמו API פתוח או שאילתת URL שלא נחסמה), שרתי ה-Web וה-OS יתעדו זאת כבקשת HTTP 200 תקינה לחלוטין. הפריצה הראשונה של אלקטור היתה באמצעות שימוש פשוט של ססמאות ושמות משתמש תקינים, בלוגים זה נראה כמו פעילות לגיטימית.

מבחינה טכנית, הלקח הוא להסתכל גם על Application logs, כלומר הלוגים של האפליקציה ולא רק על System logs. למשל לתעד פעולות עסקיות. במקום לכתוב בלוג "User 123 accessed /api/v1/voters", הלוג צריך לכלול: "User 123 (Authenticated as Admin-X) retrieved 5,000 records of 'Voters in Tel Aviv'".

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

לסיכום

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