המלחמה בין רוסיה לאוקראינה

סייבר כמכה מקדימה

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

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

משחקים בתודעה

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

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

OWASP Top 10 2021

לפני כמה שבועות בוצע עדכון לעשרת החולשות הנפוצות במערכות מבוססות Web של OWASP.

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

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

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

עשרת הקטגוריות החדשות

הערה: תרגמתי בעצמי (אלא אם היה משהו שהסכמתי איתו בוויקיפדיה העברית או בתרגום העברי לרשימה של 2017).

  1. בקרה גישה שבורה: עלתה ממקום 5. מתייחסת למקרים שבהם התוכנה לא בודקת האם למשתמש יש מספיק הרשאות כדי לגשת לרכיב מסויים או שהגישה אינה מאובטחת דיה (כמו במקרה שבו רמת ההרשאה מועברת ב-POST ללא קידוד).
  2. כשלי הצפנה: עלתה ממקום 3. מתייחסת למידע רגיש לא מוצפן. למשל פרטים מזהים שלפי תקנות הגנת הפרטיות צריכים להיות מוצפנים, נשמרים כטקסט.
  3. הזרקות: איחוד של מקום 1 ו-7. מתייחסת להזרקות קוד למיניהן. בין אם סוגי ה- XSS ובין אם SQL.
    כדי לטפל בהזרקות נוודא שכל מידע שמגיע מהמשתמש עובר סינון כך שלא יכלול תווים שלא אמורים להימצא שם (למשל פקודות בשדה שאמור להכיל טקסט).
  4. עיצוב לא מאובטח: קטגוריה חדשה. מתייחסת לעיצוב תוכנה לא מאובטחת. אם בעת אפיון המערכת לא מתייחסים לאבטחת מידע, יהיו בעיות בתוצר הסופי.
    מומלץ לממש Shift left בתהליך הפיתוח. כלומר נבצע בדיקות אבטחת סטטיות ודינמיות תוך כדי הפיתוח ולא נמתין למבדק החדירה שנעשה לפני העלייה לסביבת ייצור. המונח Shift left מתייחס להעברה של תהליך האבטחה שמאלה בתרשים פיתוח התוכנה (התרשים מתחיל מצד שמאל בלעז).
    מונחים מקצועיים: בדיקות סטטיות – SAST, בדיקות דינאמיות – DAST. לעיתים הכלים תלויים בשפת התכנות בה משתמשים.
    פרויקט SAMM של OWASP מתייחס לאבטחת תהליכי פיתוח.
  1. טעויות הגדרה: עלתה ממקום 6. חולשות XXE אוחדו לתוך קטגוריה זו. מתייחסת לכל אותם מקרים שבהם המערכת לא הוקשחה כהלכה, בין אם כתוצאה מטעות או מחוסר מודעות לקיומה של אפשרות כזו. יש כלים אוטומטיים שבודקים הגדרות ולכל הפחות מבדק חדירה אמור להתייחס לנושא הזה (כתלות בתכולה המבדק).
  2. רכיבים לא מעודכנים: עלתה ממקום 9. מתייחסת לשימוש ברכיבי תוכנה או חומרה לא מעודכנים או כאלו שידוע שיש בהן חולשות שלא טופלו. למשל: גרסת PHP לא מעודכנת או כזו שכבר לא מקבלת תיקונים. כדי להתמודד עם קטגורייה זו, אני מציע לכם לתעד את כל רכיבי התוכנה והחומרה בהם אתם משתמשים (שרתים, מערכות הפעלה, מסדי נתונים, תשתיות אפליקטיביות, שרתי Web, ספריות וכו') ולנסות להבין אם הם עדיין מקבלים עדכונים. אם לא, אנחנו בדיוק בתחילת נובמבר וזה אחלה זמן להתחיל להיערך לכתיבת תוכנית עבודה ל-2022.
    המצב מסתבך עוד יותר כשמשתמשים בספריות תוכנה שלהן רכיבים משלהן. המונח המקצועי הוא SCA – Software Composition Analysis ויש מערכות שמבצעות את הסריקה הזו אוטומטית. מתישהו ב-2022 אני מתכנן לעשות את זה בעבודה ואז אני אכתוב גם פוסט בנושא.
  3. הזדהות שבורה: ירדה ממקום 2. מתייחסת לכל אותם מצבים שבהם ההתחברות למערכת אינה מאובטחת דייה. למשל: סיסמאות שקל לנחש, אין הגבלה על מספר החיבורים השגויים לפני נעילה (זמנית או קבועה), סיסמאות שנשמרות כטקסט, אין הזדהות רב שלבית וכו'.
  1. כשלים בבדיקת אמינות המידע: מאחדת מספר 8 עם קטגוריה חדשה. מתייחסת למשבר שחווינו בשנה האחרונה בתחום ה- CI/CD. למשל הפריצה הידועה לשרתי Solar Winds שבה הוזרק קוד לתוכנה לפני האריזה לייצור בשרשרת ה- CI/CD בעוד בדיקות האבטחה נעשו על הקוד לפני תהליך האריזה.
    קטגוריה 8 לשעבר עסקה בנושא של סִדרות – serialization ו- deserialization. כלומר במקרים שבהם התוכנה לא בדקה האם הנתונים הגיעו ממקור אמין או אם הם מכילים מידע שלא אמור להימצא שם.
  2. ניטור חסר: עלתה ממספר 10 והתווספו אליה תכנים מהסקר האחרון. מתייחסת לחסרונו של ניטור. הדרך היחידה לבדוק אם הניטור תקין היא לבצע בדיקת חדירות או בדיקות דינאמיות (DAST) ולראות האם קופצות התראות במערכות הניטור. בנוסף כדאי לוודא שצוות הניטור מוכשר להבדיל בין אירועים לגיטימיים לתקיפות. כלומר שניתן לבצע אבחנה מבדלת.
    נשים לב שמהירות התגובה לאירועים חשובה גם היא. אין משמעות להתראה שמגיעה לצוות הרלוונטי יומיים אחרי האירוע. אם קרה משהו בזמן הזה, סביר להניח שהארגון כבר קיבל את בקשת הכופר מהתוקף.
    הניטור חשוב גם לתחקור אירועים ולכן יש לוודא ששומרים יומני תיעוד של כל מה שצריך לתחקור.
    יש לשים לב למצב שבו צוות הניטור מקבל יותר מדי התראות ומפתח אדישות להתראות.
    ישנן מערכות שמשתמשות בבינה מלאכותית כדי לסנן התראות או לקשר בין אירועים או לנסות להבין מהי פעולה תקינה של המערכות ומה לא. תחום הניטור הוא תחום מקצועי בפני עצמו.
  3. זיוף בקשות צד שרת (SSRF): קטגוריה חדשה שהגיעה מהסקר האחרון. מתייחסת למצב שבו תוקף יכול לאלץ את המערכת לשלוף מידע או להריץ קוד שנמצא בשרת פנימי של החברה (וכביכול מוגן כי הוא לא נגיש מבחוץ) או משרת חיצוני. בצורה כזו התוקף יכול להריץ קוד זדוני על המערכת או לשלוף נתונים שאמורים להיות מוגנים.
    ניתן למנוע על ידי בדיקה של קלט מהמשתמש או קלט שמגיע משיטות כמו POST.

העברת מערכת הפעלה וירטואלית לפיזית (V2P)

הקדמה

מת לי כונן ה- SSD במחשב בעבודה. משמע צריך להתקין מחדש. לא דאגתי לגיבויים כי כל המסמכים שלי מגובים לדרייב אז מה זה משנה? חוץ מזה, מה הסיכויים ש- SSD ימות? הרי יש לי אחד כזה במחשב בבית שמתפקד כבר 10 שנים. אבל הוא מת והייתי צריך להתקין מחדש.
אי אפשר להשתמש בטכנאי של החברה כי אני עובד עם לינוקס. אז אני צריך להתקין בעצמי. אבל זה אומר שאני לא יכול לעשות כלום תוך כדי התקנה. אז כדי שאני לפחות אוכל להשתתף בדיונים תוך כדי החלטתי להתקין מהבית (אצלינו אסור לעבוד מהבית). לפחות בבית ההתקנה תזוז מהר יותר כי המחשבים בעבודה די ישנים (Core i דור 6 זה שיא הטכנולוגיה אבל יותר סביר לקבל דור 3 או 4) וגם די איטיים: ערכת שבבים B85 בערך שזה אומר רוחב פס של 2-4GB שמשותף גם לכרטיס רשת, USB, שמע וכו'. 2-4GB בהנחה שהיצרן מימש את כל הנתיבים של DMI ולפי הביצועים שאני מקבל, הוא לא. אז העדפתי להתקין בבית.

מה צריך להכין?

  1. Virtualbox או כל hypervisor אחר.
  2. ISO של clonezilla או כל דיסק שמכיל את dd.
  3. אם משתמשים ב- Virtualbox צריך גם דיסק ביניים בחיבור USB או לחבר את כונן היעד עם כבל SATA ל- USB.
clonezilla
מסך האתחול של clonezilla: בלעדיו הייתי צריך להשתמש ב- dd ולקוות שאני לא דורס משהו בטעות

תהליך ההתקנה

  1. התקנה רגילה על מכונה וירטואלית. אני השתמשתי ב- Virtualbox.
    נא לא להתקין דרייברים של חומרה ספיציפית (פרט ל- virtualbox guest utils כדי לקבל גישה לתיקיות משותפות).
  2. גיבוי הכונן עם clonezilla (או dd למשוגעים) עם האפשרות device to image. צריך כונן חיצוני גדול יותר מהכונן עצמו. מה שאומר שכדאי להתקין על מחיצה קטנה גם אם בכונן היעד יש יותר מקום. הכונן צריך להיות בחיבור USB.
  3. שחזור עם clonezilla לכונן היעד.
  4. חיבור כונן היעד למחשב היעד והדלקה.
  5. עכשיו כדאי להתקין את כל אותם דרייברים. מומלץ גם להתקין מחדש את ה- boot loader (כי חלקם לא מבצעים התקנה מלאה כשמדובר על מכונה וירטואלית) וליצור מחדש את הליבה עם mkinitcpio (זה לא בדיוק מה ש- mkinitcpio עושה אבל זה מספיק קרוב).
    לא צריך chroot בשביל זה, לפחות אני לא הייתי צריך. המעבר שאני ביצעתי הוא ממכונה וירטואלית על AMD Ryzen 3 ל- Core i7-3xxx (מחשב דומה למה שיש לי בעבודה).

איך זה אפשרי

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

דילוג לתוכן