Archive for the 'Phishing-Pharming' Category

25
יונ
14

התגוננות בפני התקפות סייבר Cyber Defense

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

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

התפיסה שיושמה ונוסתה, כוללת את המרכיבים הבאים (רשימה חלקית וראשונית).
הפרדת רשתות: הרגולציה בתחום אבטחת מידע בגופים פיננסיים בארץ, הינה מהמתקדמות בעולם. אחת הדרישות הכי חשובות במספר רגולציות (בנקים, ביטוח) מחייבת הפרדה או חציצה בין רשתות ארגוניות פנימיות לבין רשתות ציבוריות/אינטרנט. החציצה מונעת תקשורת החוצה. (לכל היצרנים/ספקים, מוצר פרוקסי אינו נחשב פתרון כזה.) בשפה תקשורתית, ניסיון ליצור צינור תקשורת החוצה בכל מיני פורטים (80, 443, 22, 21 ועוד) ייחסם ע"י ה – Firewall.
גלישה לאינטרנט תיעשה ע"י פתרונות גלישה מאובטחת. העברת קבצים ע"י פתרונות כספות. וכך הלאה. בטכנולוגיה של היום, הפגיעה בחוויית המשתמש אינה גדולה (חוץ מתלונות מפונקות ע"י עובדים שלא מעניין אותם שהארגון יישאר פרוץ). החריגה היחידה שציינתי בעבר נוגעת לשימוש במייל, שבמקרה זה הפגיעה במשתמשים גדולה ולא מספקת פתרון מקובל מבחינת עלות תועלת.

מעטפת/רכיבי הגנה חיצוניים: כל אותם רכיבים שהיו נהוגים בתפיסת אבטחת המידע הכוללת, רלוונטיים גם כאן. מערכת IPS להגנה מפני התקפות חיצוניות על הרשת, שרת WAF להגנה על אתרי אינטרנט, מערכת סינון תכנים (Content Filtering) ואנטי ספאם, מערכת הגנה נגד APT, הגנה מפני DDoS.
מהיכרות שלי עם ארגונים, ובעיקר עם מנהלי מערכות מידע ומנהלי תשתיות, הם חוטאים בכל קשור לרכיבי האבטחה. במקום לנצל 100% מיכולות החסימה של המוצרים האלה, הרבה הגדרות (לפעמים 50%) אינן מופעלות מהחשש לפגוע בשירות או מכך שזה יביא לעבודה מיותרת בעיניהם. החטא הזה מוביל לכך שפורצים מצליחים ע"י כך לנצל פרצות במעטפת החיצונית. אקווריום אטום "למעט" שני חורים זה עדיין אקווריום דולף. חייבים לחסום הכל, בלי פשרות. מנהלים, תעבדו יותר קשה.

חסימת SPF: לכאורה, זוהי הגדרה שלא הייתי אמור לפרט בנפרד, אלא תחת הסעיף מעטפת/ רכיבי הגנה חיצוניים. הסיבה שאני מקדיש לכך סעיף נפרד היא שניסיון Phishing מתוחכם יכלול שליחת מייל הכוללת כתובת מקור (Sender) המתחזה לדומיין הפנימי/ארגוני. כלומר, המייל ייראה לעובד כאילו הוא נשלח ע"י עובד אחר בתוך החברה. במקרה כזה, גם עובד ערני ימהר ללחוץ על לינק זדוני (למשל סקר שביעות רצון או פעילות רווחה) בגוף המייל ולא יחשוד שמדובר בתרמית.
SPF זוהי הגדרה שנועדה לחסום קבלת מיילים מבחוץ הכוללים בכתובת דומיין פנימי/ארגוני (שכן מיילים פנימיים לא מגיעים משרת חיצוני אלא משרת Exchange פנימי).

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

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

  • צרו רשימת כתובות חשודות. לרשימה זו הכניסו כתובות שביצעו Port Scanning, שלחו מיילים חשודים שהכילו נסיונות Phishing או כתובות שה – WAF זיהה כמקור לתקיפה לאתר החברה.
  • הגדירו חוק המתריע על פתיחת תקשורת (מה – Firewall) לכתובת המצויה ברשימת הכתובות החשודות.
  • חוק המתריע על Port Scanning.
  • חוק המתריע על נסיונות תקיפה (מה – WAF) על האתר. אפשר לעדן את החוק ע"י סינון סוגי מתקפות מסויימים/רלוונטיים או רמת קריטיות של התקפות.
  • חוק המתריע על נסיונות DoS/DDoS (מה – IPS).
  • חוק המתריע על שליחת מייל למעל X נמענים (ממערכת האנטי ספאם). אפשר להוסיף חוק דומה המזהה שליחת מיילים לעובדים רגישים העשויים להיות מושא לנסיונות Phishing (מנהלי רשת, מנהלים בכירים, עובדים בעלי הרשאות רגישות).
  • חוק המתריע על מספר תחנות הנגועות בוירוס או מתקפת APT.
  • חוק המתריע על תקשורת לכתובות הידועות כשרתי Command & Control.

מערך ניטור SOC: חיברתם את כל המערכות והשרתים ל – SIEM וראיתם שמתקבלים חיווים טובים ויש התראות על אירועים חשודים. מה עושים עם כל זה?
כדי להתגונן באופן יעיל מפני התקפות סייבר, יש חשיבות גבוהה להקים מוקד SOC אשר יטפל בהתראות השונות שקופצות במערכת בתוך פרק זמן קצר. במוקדי SOC טובים, המוקדנים יידעו לטפל גם באופן אקטיבי באירועים. למשל, לחסום כתובות IP חשודות ב – Firewall, ב – WAF או ב – IPS, למחוק משרת הדוא"ל מיילים שזוהו כהתקפות Phishing, ואפילו לנתק מהרשת או להעביר לסגמנט רשת מבודד תחנות קצה חשודות.
חשוב להגדיר, בכתב, נהלי טיפול באירועים לכל סוג אירוע שהוגדר לו חוק ב – SIEM, וגם לתרחישים נוספים שאין להם חוקי SIEM. הנהלים יגדירו למי מדווחים, מתי פועלים אקטיבית וכיצד.

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

  • נסיונות חדירה ע"י מייל Phishing המכילים לינקים לאתרים זדוניים והמכילים צרופות המכילות סוסים טרויאניים שעשויים לאפשר מתקפות APT.
  • נסיונות חדירה לרכיבי תשתית ברשת הארגונית.
  • נסיונות חדירה אפליקטיביים ותשתיתיים לאתר האינטרנט.
  • נסיונות חדירה למערכת ה – VPN לגישה מרחוק.
  • נסיונות חדירה ל – IVR.

 

מודעות פרסומת
13
פבר
11

ניסיון Phishing

כמעט נפלתי עכשיו בתרמית Phishing.
קיבלתי את המסר הבא:

לרגע חשבתי שזה אמיתי. לחצתי על הלינק והסתכלתי טוב על ה – URL. מיד הבנתי.

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



29
מרץ
09

utube – עוד דומיין עם שם דומה

בהמשך לפוסט הזה, רציתי לגלוש לאתר youtube.com.
הקלדתי utube.com בלי לחשוב יותר מידי.
הנה התוצאה:

utube1.JPG

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

utube2.JPG

22
מרץ
09

הש.ג. בגלגלצ נרדם בשמירה

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

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

glgltz.JPG 

זה מקרה עלול היה להתפרש כניסיון התחזות – Phishing.

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

glgltz-whois.JPG

כנראה שה-ש.ג. בתחנת הרדיו נרדם בשמירה (תרתי משמע… ) ולא טרח לרשום את הדומיין.

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

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

כבר כתבתי על כך כאן.

10
מרץ
08

טרנדים באבטחת מידע

בינואר 2008, חברת IBM פרסמה, באמצעות ISS שנרכשה על-ידה, ניתוח מעניין על מגמות אבטחת מידע. קבוצת ה – X-Force ניתחה פרמטרים רבים. את התוצאה ניתן לקרוא בדוח בן מעל 50 עמודים. מצאתי לנכון להאיר מספר נקודות מעניינות מהדוח. את הדוח המלא ניתן לראות כאן.

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

לפי X-Force, פגיעות (Vulnerability) עשויה להוביל להחלשה או שבירה מוחלטת של רמת החשאיות, שלמות וזמינות של מערכת מידע.

פגיעות בחומרה גבוהה מתייחסת לפגיעות המאפשרת גישה מיידית מרחוק (או מתוך הרשת) או הרצת קוד או פקודות ללא הרשאת מתאימות באופן מיידי.

כללי:

  1. בשנת 2007, מספר הפגיעויות בחומרה גבוהה גדל ב – 28% ביחס לשנת 2006.

  2. חמש החברות עם הכי הרבה פגיעויות הן: Microsoft, Apple, Oracle, IBM, Cisco.

  3. חמש החברות אחריות למעל 13% מכלל הפגיעויות.

  4. כמעט 90% מהפגיעויות ניתנות לניצול מרחוק.

  5. בשנים האחרונות ישנה ירידה באחוז הפגיעויות מרמת חומרה גבוהה, למעט ב – 2007 בה חלה עלייה קטנה ל – 22% מכלל הפגיעויות. האם זה נובע ממערכות מאובטחות יותר Out-of-the-Box או בזכות Patches? אולי גם בגלל מודעות גבוהה יותר לפיתוח מאובטח של קוד.

  6. מעל 89% מהפגיעויות מאפשרות ניצול מרחוק בעוד שמעל 10% מתוך הרשת/מערכת.

  7. ניתן לחלק את התוצאות של ניצול פרצות למספר קבוצות, כגון השגת הרשאות גישה (לא מאושרות) למערכת, מניעת שירות DoS, מניפולציה לנתונים ולקבצים ועוד. מעל 50% מהפגיעויות מאפשרות השגת גישה לא מאושרת למערכת.

  8. חברת מיקרוסופט (IE) שחררה 28 Patches לפגיעויות קריטיות (מספר דומה לשנת 2006). חברת מוזילה (FireFox) שחררה 36 Patches לפגיעויות קריטיות (ירידה משמעותית מ – 64 בשנת 2006).

קוד זדוני Malware:

  1. X-Force אספו וניתחו כמעט 410,000 קודים זדוניים (Malware), כמעט שליש יותר משנת 2006.

  2. סוסים טרויאניים מייצגים את הקטגוריה העיקרית של קודים זדוניים – כמעט 110,000 וריאציות של סוסים טרויאניים מהווים 26% מכל הקודים הזדוניים.

  3. הסוס הטרויאני הכי נפוץ: Trojan.W32.Agent (מקווה שהבריטים לא רצים להמר עליו…) 

פישינג Phishing:

  1. 19 מתוך 20 הארגונים שהיוו יעד להתקפות פישינג (Phishing) הן מתחום הבנקאות!

  2. המדינה ממנה נשלחו הכי הרבה הודעות מייל המכילות ניסיון פישינג Phishing הנה ספרד (כמעט 15% מההודעות). ישראל, דרך אגב, במקום הרביעי עם 8.4%, וארה"ב במקום השביעי עם 5% מההודעות.

  3. ברשימת המדינות המאחסנות (Hosting) כתובות URL של פישינג, ארה"ב מובילה עם מעל 29%. ישראל לא ברשימת המובילות (לשמחתנו).

  4. שורת הנושא הפופולרית בהודעת פישינג הינה שורה ריקה – מעל 22% מההודעות. 

ועוד קצת טריוויה:

  1. גודל הודעת ספאם ממוצעת נעה בסביבות 6KB.

  2. שורת הנושא הפופולרית בהודעת ספאם הינה:  'Re:          '  (כלומר ללא טקסט כתוב) – כ – 7% מסך ההודעות.

31
ינו
08

פישינג בתוך Phishing Toolkit

כותרת משנה: הגונב מגנב פטור?

בכדי לגנוב (מידע) צריך לעבוד קשה. או שאולי כבר לא.

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

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

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

26
דצמ
07

עוד דומיין נחטף, הפעם בגלל פירצה ב- Gmail

הפואנטה בפוסט היא לא הפירצה שהתגלתה ב – Gmail, אלא אובדן הדומיין.

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

CISO

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




יוני 2018
א ב ג ד ה ו ש
« מאי    
 12
3456789
10111213141516
17181920212223
24252627282930
מודעות פרסומת