יום שלישי, מאי 12, 2009

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

בזמן אני יושב ועובד על מודול הפרל שמטפל בנושא Rashim (יש עוד מודול שמטפל בHighLearn ) ונתקלתי בנקודה מאוד מסוכנת.

בעוד כולנו רגילים לעובדה שביצוע עיסקאות חיוב צריך להתבצע בצורה מוצפנת (TLS , SSH וכו' ) או אפילו בשימוש ב PKI בסיסי מתברר שכמה אנשי IT שכחו מזה.


בעוד מרבית אפשרויות הסליקה ממליצות בחום שימוש בצורה מאובטחת (אומנם ב ubercart אומרים כי ייתכן ועדיף כי כל האתר יהיה מוצפן ולא רק חלקים ממנו) במספר מוסדות אקדמים אנשים בחרו להתעלם מההמלצה החמה (של להשתמש בסוג כל שהוא של הצפנה בעת ביצוע מעברים כספים) והרימו את כל המערכות בצורה בלתי מאובטחת (חלק מהסעיפים לא כולם) :
  • ללא שינוי הגדרת ברירת המחדל בשרת בסיס הנתונים.
  • אפשרות של התחברות שלא מהרשת הפנימית ללא שימוש במפתחות הצפנה בהתחברות למערכת:
    לעובדים בעלי הרשאות יתר (מנהלי מערכות , אופרטורים , מרצים , מזכירות ) מומלץ בחום רב ללמוד על מפתח פרטי וציבורי והצפנה אסינכרונית וכן במידע ויש VPN הוא חייב להיות מוצפן אחרת כל ילד בן 12 יעשה במערכת מה שהוא רוצה.
  1. משום מה מניחים כי יש אנשים שצריכים לקבל את כל הנתונים מבסיסי המערכת - "נו הוא מנהל אגודת הסטודנטים הוא צריך את ההרשאות " או המזכירה צריכה יכולת קריאה של כל המיילים של מנהל המחלקה.
  2. משתמשים מבקשים להיות Super adminstrators (מושג שמאוד הפתיע אותי האמת) או בכלל בהרשאות בשביל סמל סטטוס.
  3. הרשאות root לפקידים או למהנדסי מערכת (שאין שום סיבה שיהיה להם הרשאות כאלה).
  • לא קיימת נעילת משתמש לאחר מספר ניסיונות התחברות לבסיס הנתונים.
  • בסיסי הנתונים (לאו בהכרח של המערכות הכספיות ) לא מאובטחים ומאפשרים לבצע שאילתות לאנשים לא מורשים.
  • לא קיים שרת Syslog מרוחק ומאובטח בו יאוכסנו כל הלוגים של המערכת.
  • ללא שימוש בהגנה מהתקפות Man in the middle.
  • מערכות ששולחות VB למשתמשים (קוד צד לקוח) דורשות מהמשתמש לקרוא את הקוד ולהבין מה לא בסדר באתר בשביל שגם הוא יוכל להשתמש בו (מהסיבה ש VB לא עובד על מרבית המערכות) או להתקין תוכנות צד שלישי בשביל שהאתר יעבוד אצלו לדוגמה תסריט greace monkey .
  • שימוש בסיסמאות פשוטות.
  • שימוש בשמות משתמש מרונדרים (כלומר שניתן להבין מה יהיה שם המשתמש לפי השם פרטי ושם המשפחה).
  • שליחת השגיאה המדוייקת למשתמש (אם זה שאליתת SQL לא נכונה לדוגמה).
  • שימוש בשירותי TelNet במקום ssh.
  • העברת מידע כלכלי ב plain text XML במקום במוצפן (בן עם באמצעות מפתח ציבורי של משתמש או אפילו שימוש ב SSL).
  • חוסר הפרדה פיזית (ולא שימוש בחוקי iptables זה לא הפרדה פיזית) בן הרשתות.
  • אתרים שכתובים בניגוד לתקני W3C אלה בצמוד לדפדפן כלשהוא (IE6 לדוגמה) ומסתמכים על טוב ליבם של המשתמשים (מכיוון שהאתר לא עובד בדפדפנים בעלי התוכנה מניחים שהלקוחות לא ינסו להשתמש במשהוא שיגרום לאתר לעבוד).
  • שימוש בדואל שלא עבר חתימה (GPG) מאפשר זיוף של דואל בשמם של האנשים.
צריך לזכור שכמעט כל החברות שמתעסקות בגביה דורשות שימוש בהצפנה - וכמו שהוגב בבלוג שלי ע"י עובד חברת ראשים הפעלת אבטחה היא החלטה של המוסד ולא של החברה.

אמנם קיימות חברות שלא יאפשרו שימוש במוצריהם ללא שימוש בהצפנה (לפחות ע"פ הכתוב באתרי החברה).

כל אדם בעל ידע בסיסי במחשבים ידע להשתמש בתוכנת האזנה (WireShark) בשביל להאזין לרשת ועם ידע בסיסי בתקשורת (Wi-Fi ) יוכל להתחבר במרחקים שלא יאפשרו את זיהוי.
הוא אינו צריך את כל המידע בשביל לקבל גישה גם חלק ארי מהמידע יעזור.
אפילו אם ניקח NTLM ונשתמש בו וסיסמת המשתמש קצרה יחסית (פחות מ6 תווים) תוך מספר שעות (~45) על cluster של 16 מחשבים סטרנדרטים הסיסמה נפרצת.
גם הצפנה של התעבורה לא מונעת את הבעייה מהסיבה הפשוטה שאם המידע מאוכסן שלא בצורה מאובטחת (מוצפן לדוגמה) אז אין שום בעייה לקבל את הנתונים.

זיהוי פיזי של החודר -

הוכחתי ב2005 שבתנאי עיר ניתן להתחבר במרחק של 1.2 ק"מ ב 2006 באחד הקיבוצים בדרום התחברו למרחק של 12 ק"מ.

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

כל הנקודות הן כאשר יש LOS פנוי.

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

ברמת התוכנה -

בגלל שכמה מערכות יכולת להיות מותקנות על מערכות הללו מתעוררת בעיה רצינית :

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

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

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

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

אני כבר לא מדבר על SQL Injection שיאפשר לקבל את כל המעברים הכספים שכבר נעשו .
כאשר מתבצעת שימוש ב 3D-secure יש שרתים ששומרים את המידע על כל הטרנזקציות שאי פעם היו כלומר אם אתר כלשהוא משתמש בשירות סליקה "מאובטח" אין הדבר מצביע בצורה כל שהיא על אבטחת המידע של השרת המארח.
שימוש ב SSL או TLS או כל סוג של הגנה מ MITM לא מצביעה בשום צורה על אבטחת השרתים.

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

צריך לזכור שכל עוד אין הפרדה פיזית בן הרשתות הפנים אירגוניות תמיד יהיה אפשר להגיע למידע:

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

חשוב לזכור שמרבית גנבות האשראי אינם מהאזנה אלה מאבטחה לקוייה של השרתים המארחים.

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

מערכות אחרות מניחות שאף אחד לא ירצה להתחבר בתור משתמש אחר ומשאירות פתח לSQL injections.

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

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

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

טוב אז מי צריך לדאוג בנושא ?

כאשר יש מערכת חיוב אלקטרונית במערכת שאיננה מאובטחת ו :

סטודנטים שמוסדות שלהם מותקנת מערכת מכלול 2000 (מכלול-נט) ואין שימוש ב SSL (וזה ההתחלה).
סטודנטים שבמוסדותיהם מותקנות מערכות סל"ע (HighLearn ) כאשר אין שימוש ב SSL.

3 תגובות:

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

    תודה,
    עודד ירון

    odedya AT gmail.com

    השבמחק
  2. רוצה לדבר על מוסדות אקדמיים וממשלתיים שקבצי ה-passwd/shadow נתונים לכל דורש ומשאירים את המערכת פרוצה לגמרי ?

    למערכת לא אכפת. אני, בכל, אופן - נזהר.

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

    השבמחק