Wednesday, January 21, 2009

A New MSN Phishing ( Identity Theft ) Worm - ENG

[ A Rewrite of this post in english , due to the importance ]

 

A few days back , I received a nice gift via my Msn IM account, i got the following link :

http://myparties.piclooks.com/?<user> ( where <user> is the infected sender ). in that case i got it through MSN , so i dont tknow if any other IM is compromised.

when clicking on that link you would get the following web window -

SNAG-0044

That screen immediately raised my suspicion that there is something wrong here. an unknown site is asking for my MSN / Hotmail credentials in order to provide me a service which natively could be provided via a normal API... so i started checking.

Viewing the client side source code was very nice , cause it shows a very simple - almost child-like html code that is generated via simple tools.

An IP address (  64.34.154.82 ) was embedded in, which is not something that you would expect from a service, very unusual.

When disecting the URL to its basics and just going to piclooks.com , you would get the following output ( meaning , there is no actual homepage behind this application )

piclooks-com

The summary is very simple , this is most probably a phising site , and not a very sophisticated one , which its whole purpose is to steal the online identities of those who are naive enough to play along.

be careful of this hoax.

Labels: , , , , , , , ,

Monday, January 19, 2009

A New MSN Phishing ( Identity Theft ) Attack

קיבלתי היום מתנה חדשה דרך הIM שלי , את הקישור הבא :

http://myparties.piclooks.com/?<user> link , כאשר <user> מייצג את שם המשתמש של מי ששלח לי את ההודעה במקור דרך תוכנת הIM , במקרה הזה MSN.

המסך שהתקבל היה :

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

יתרה מכך , ישנה כתובת IP שהיא - 64.34.154.82 - מוטמעת בקוד המקור , דבר מאוד חריג.

פירוק הURL כדי לגשת ישירות לpiclooks.com הניב את התוצאה הבאה ( כלומר, אין כל Homepage מאחורי האפליקציה )

piclooks-com

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

Labels: , , ,

Thursday, December 18, 2008

Your Partner Or Your Problem

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

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

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

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

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

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

האם פתרון OTP מיושם אצלכם ? וגם אם כן , האם גם שם המשתמש ( Something You Know ) הוא אקראי ? כנראה שלא.

Labels: , , , ,

Saturday, August 30, 2008

משתמשים מגנים על משתמשים

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

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

facebook-comm זה הופך להיות מעניין , כאשר משתמשים מצליחים להגן על משתמשים. ואולי בעצם מישהו צריך להקים Taskforce כזה או אחר שמנטר מקומות כמו Facebook וכמו MySpace על מנת לאתר איומים כאלו ולהתריע עליהם בזמן... מישהו מרים את הכפפה ? סימנטק ? מקפי ? טרנד ? מעניין ...

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

Labels: , , , ,

Monday, August 11, 2008

הגנת IPS כנגד SQL Injection , לא ממש...

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

אחד הדברים שתמיד הפתיעו אותי הוא התפיסה הרווחת ( והמוטעית ) אשר אומרת שניתן לחסום SQL Injection במערכות IPS או מערכות FW מתקדמות עם מנגנוני חתימות. ואני כמובן מוחה.

התפיסה היא שעל ידי חיפוש של מחרוזות גנריות בתוך שאילתות HTTP למיניהן , ניתן לאתר את כל\רוב סוגי התקפות הSQL השונות. אך האם כך הדבר ?

משפט SQL הוא משפט אשר עובר Parsing מסויים ולבסוף מעובד על ידי מנגנוני קלט אשר בודקים את תקינותו מבחינת Syntax וקישורו לאובייקטים קיימים בDB , על אותה רגל - משפט SQL Injection יהיה לעולם משפט אשר מנסה לקיים תנאי TRUE. על ידי כך במידה ויש התאמה לתנאי , השאילתה אשר מפיק משפט הSQL תרוץ על השרת...

ואם מדובר במשפטי TRUE ... אז משפט כמו 1=1 הוא נכון , וגם a=a הוא נכון , וגם 100<999 הוא נכון וכן הלאה ... כלומר במילים אחרות --> לא ניתן לייצר חתימה אשר תתפוס כל SQL Injection אלא את הבסיסיים בלבד.

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

Labels: , , , , ,

Friday, March 21, 2008

חג פורים ו Social Engineering , סיכון ?

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

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

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

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

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

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

שווה מחשבה...

Labels: , , ,

Thursday, March 13, 2008

פרסום BGP ( או כתובות אחוריות ) לא גורם סיכון לנתב !

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

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

אבל, BGP ... אוי BGP ... ולאו דווקא בגלל שהוא BGP ...

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

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

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

אני רוצה להציג בפניכם שרטוטון :

BGPATTACK

עכשיו :

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

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

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

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

בכל אופן , הכתוב פה הוא דעתי.

Labels: , ,

Saturday, March 08, 2008

כיצד מתמודדים עם וירוסים וDLP בFaceBook ?

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

בוקר טוב בארי,

קראתי את הפוסט שלך לגבי הוירוס שהתגלה בפייסבוק ויש לי שאלה בנושא.

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

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

האם תוכל להפנות אותי למידע רלוונטי בנושא?

תודה מראש על העזרה ועל הזמן שלך,

יעקב

לשאלת אותם מנהלי IT , אכן יש צורך להגדיר "הגנות מיוחדות" שכאלו. את רובן ניתן ליישם באמצעות מערכות IPS ומערכות Network AV אשר יחסמו את ההתקפה לפני שהיא מגיעה לתחנה , וזו גם הדרך הנכונה ביותר לתקוף את הבעיה הזו כרגע ( למרות שלדעתי , יש צורך לחסום את השירות באופן מלא בארגון כי אין שום סיבה להשתמש בFB מתוך רשת ארגונית - פרט לבזבוז משאבים וזמן ).

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

1. משתמשים שמוציאים מידע החוצה.

2. אפליקציות זדוניות שמושכות מידע.

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

לגבי 1, לא תהיה ברירה - יש צורך להטמיע מערכת DLP , שכמובן הדרך המומלצת היא ההטמעה הרשתית של פתרון ( כגון PortAuthority ) ולארגונים עם פחות משאבים - Onigma שכעת הינו חלק מMcAfee. למיטב הבנתי יש אפילו פתרון לSymantec אבל אני לא מכיר אותו , ולכן לא יכול להעיד לגבי טיבו.

חשוב לי לציין , שאת הוירוס הראשון בFacebook תפס מרכז הFortiGuard של חברת Fortinet.

Labels: , , ,

Sunday, February 10, 2008

מחשבות לגבי OpenID

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

אחת הדרכים המרתקות יותר שתופסות יותר ויותר כותרות לאחרונה היא OpenID.

מדובר בעצם בתשתית הומוגנית מקוונת אשר אמורה לאחד את כל השירותים אליהם אנחנו ניגשים , כגון חשבון הדואר האלקטרוני שלנו , חשבון הFacebook שלנו, חשבון הDIGG , וממשיכה לכיוון חשבון הבנק שלנו וכדומה.

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

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

אני אישית , רואה פה בעיה חמורה.

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

אני מחפש את האלמנט הנוסף . האם ייתכן שיחול מהפך של Full Disclosure על מידע פרטי ?

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

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

החברה החדשה בקרן OpenID והמשמעותית ביותר בעיני היא VERISIGN אשר מהווה את אחד הCA החשובים והמרכזיים היום בעולם. האם אוכל עכשיו לזייף הזדהות חכמה בעקבות כך שהתעודה המונפקת לי מוצמדת לOpenID ? האם עכשיו כאשר יאבדו או יגנבו פרטי זהות , תיפתח גם התעודה של אותו משתמש ?

יותר מידי שאלות...

Labels: , , ,

Saturday, January 12, 2008

מהי התקפת Buffer Overflow ?

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

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

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

זה קורה באופן הבא [ בפישוט ] :

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

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

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

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

Labels: , , ,

Wednesday, January 09, 2008

נבואה ראשונה מתקיימת השנה - Facebook Attack

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

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

הראשונים לנתח ולתפוס את ההתקפה היו חברת Fortinet אשר מראים בקישור הבא את מבנה ההתקפה והתחושה למשתמש.

בגדול - הופצה אפליקציה אשר גורמת למשתמש להבין שכדאי לו להתקין אותה בעמוד הFB שלו , בכדי לגלות אנשים אשר "דלוקים" על אותו משתמש. כאשר המשתמש מתקין את האפליקציה , מגיע אליו לינק על גבי IFRame אשר סוחב עימו את הוירוס Zango.

לא רע ... וגם די אפקטיבי.

Labels: , , , , ,

Friday, January 04, 2008

לסרוק ולא לנקות - Online AV Scanners

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

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

מדוע לא ניתן לנקות אלא רק לסרוק ?

כאשר אנו עובדים במוד של Remote Service , אין דרך טבעית לאפליקציה לעבוד מול סביבת הI/O של מערכת ההפעלה . זאת בשל הגבלות ההגנה בשכבות של מבנה מע' ההפעלה , ובנוסף הבידוד בין סביבת מערכות הFileSystem מסביבות הActiveX השונות.

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

Labels: , , ,

Tuesday, October 30, 2007

Stateful Inspection Is Dead

ואחרי כותרת מפוצצת שכזו וכמובן אחרי שתפסתי את תשומת הלב שחיפשתי - אפשר להתחיל לדבר.

בתקופה האחרונה יצא לי לחקור רבות אודות טכנולוגיות FW שונות ומוטציות שהן עברו מאז שהומצא מנגנון הStateful Inspection ( נסמן כ "SI" כשנדרש ) וכמובן הטכנולוגיות הללו התפתחו ולקחו את עולם הNetwork Firewall לעולמות רחוקים ומתקדמים יותר , שהופכים את הטכנולוגיות

ראשית, מהו Stateful Inspection :

באופן מאוד מאוד כללי , מדובר בטכנולוגיה אשר מתבססת על טבלאות הנקראות State Tables אשר מכילות את פרטים אודות כל TCP Stream שעובר דרך המערכת. למעשה , עבור כל SESSION נשמרים פרטים מזהים אודות חלון הTCP והפרטים השונים לגבי המשך הSESSION , ולכן כל פאקט חדש שיגיע יבדק אל מול הטבלה למציאת שייכות , אם שייך - יועבר למנוע הROUTING , אם לא - יבדק אל מול הRULEBASE של אותה מערכת FW. המאפיין הכללי כמובן הוא מקור , יעד , ופורט. הומצאה במקור על ידי CheckPoint

ובכן לפני מספר שנים בודדות , עם עליית טכנולוגיות הUTM , התווספו מספר מנגנונים לעולם הSI שעיקרם הוא הDPI או בפירוט - Deep Packet Inspection. הרעיון מאחורי הקונספט הוא - להשתמש במנגנוני Content Inspection כאלו או אחרים , על מנת לוודא שהPACKET אכן תקין ונקי ממזיקים , ולשמש כשכבה נוספת במנגנון ההחלטה לגבי הכנסה לState Table. במקרה של DPI אגב , הסריקה ממשיכה להתבצע לכל אורך התהליך בכדי לשמור על תעבורה נקיה ככל האפשר. מה שכבר הופך את טכנולוגיית הSI כריקה ולא משמעותית , כי ההסתכלות צריכה להיות מעבר לLayer 4 ויותר לכיוון Layer 7. ולשם צריך לכוון.

עד היום למעשה כל FW עדיין מבסס חוקים על פי Source/Dest/Service מבלי באמת להסתכל לתוך אותו הService. וכאן בעצם הבעיה , למרות שהקונספט עובד ועובד טוב, הוא כבר לא מספיק מעמיק בשביל להתמודד עם התקפות מתפתחות שעוברות מוטציות בין שכבות שונות במודל OSI.

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

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

מה באמת רץ לנו ברשת ?

הBUZZWORD שמתפתח מעולם זה הוא בעצם יצירת דור חדש ( דור 6 ? ) של מערכות FW אשר מוסיף תווך נוסף למערכת ובעצם מהווה האבולוציה האמיתית של עולם ה FW וגורם לSI לקבל את התגית Obsolete. ולמה בעצם - דור חדש של מערכות FW עולה וצף , Application Aware Firewall או בשם אחר Application Categorized Rule Based Security . והכוונה מאוד מעניינת ( ובעלת המון טכנולוגיה מאחוריה ) הקונספט הוא כזה שבו כל STREAM של אפליקציה ניתן לזהות לפי מבנה הPACKETS או מבנה של מספר PACKETS ולהשוות למול DB כזה או אחר , ובכך בעצם לתת משמעות לעמודת הService בחוקי הFW. כלומר - מידע יעבור מעתה לפי 4 שדות שונים - source/destination/port/APPLICATION .

אגב , ברור שפתרונות מסוג זה לא ניתן לבצע בתוכנה בלבד, יש צורך במעבדים מיוחדים ובחומרה שנבנתה במיוחד למטרה זו . קחו למשל אינטגרציה בין סביבת PGP לסביבה שכזו - המערכת צריכה להיות מקושרת עם הKeyring הארגוני , בשביל לפתוח את ההצפנות השונות שעוברות ברשת ולבצע ניתוח למידע המוצפן.    - הOverhead ברשת הוא מטורף, הLatency בלתי נסבל - ולכן הפלטפורמה תמיד מבוססת ASIC ואפיקי BUS אדירים.

גישה מעניינת היא האם יש צורך בהפעלת PROXY LAYER במערכות אלו , או לעבוד בSTREAM מבחינת עומסים , ובעצם עד כמה עמוק אנחנו צריכים לסרוק את התעבורה , אם אנחנו כבר יודעים שזו אכן האפליקציה שלנו , ויתרה מכך - שהיא מתנהגת כפי שרצינו. השקיפות פה נפלאה - כי אני יכול לדעת בעצם כל אפליקציה שעובדת ברמה רשתית אצלי בארגון , ולקבוע מדיניות בLEVEL אחר לגמרי.

Labels: , , , , , ,

Friday, October 19, 2007

סקריפט קידי משחק = 20K לרשויות , 18 שנה בפנים.

אתם מוזמנים לקרוא את המאמר הבא שפורסם בThemarker.com ונמצא בקישור הבא, המספר אודות האקר צעיר בן 19 , אשר באמצעות כלים די פשוטים גרם לימ"מ של מחוז Orange County בארה"ב לפרוש פשיטה על בית של זוג , על ידי שיחה עם CALLER ID מזוייף בה הוא "הודה" ברצח .

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

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

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

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

Labels: , , , ,

Saturday, October 13, 2007

XML Security - קצת מחשבות בנושא

פרילוג

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

מה זה XML

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

אני ממליץ לקרוא את המדריך הבא למי שהעולם הזה חדש עבורו.

SOAP

לשפה זו מצטרף פרוטוקול הSOAP אשר נבנה לצורך יצירת תווך של העברת ידע ופקודות בין מערכות שונות ( בד"כ תוך שימוש בפרוטוקול HTTP כשכבת תקשורת ) . למי שלא מכיר - SOAP עובד בשיטה של מעטפות מידע ופקודות אשר עוברות בין שני אלמנטים שונים ( אפליקציות \ שרתים \ טלפונים IP וכדומה ). לאותן מעטפות ישנה הגדרת מידע ומבנה אשר נקרא פשוט - סיכמת הSOAP , והוא ממוקם בקובץ WSDL אשר פירושו - Web Services Descripton Language. ומכיל את המידע הרלוונטי בכדי לאפשר לשני הצדדים להבין אחד את השני. חשוב להבין שSOAP יכול ואמור לכיל פרצדורות ופונקציות כמו בכל שפת תכנות אשר עוזרות לצד השני להבין את המידע המועבר ( ומאפשרות גם עיבוד נתונים בSERVER-SIDE ).

מדריך מצויין למתחילים עם SOAP ניתן לקרוא כאן.

שימושים נפוצים

השימושים הנפוצים ביותר לXML היום הם : העברת מידע בין מסדי נתונים ובין שירותי אתרי אינטרנט , העברת מידע בין מודלים של מידע ובין פלטפורמות שונות , RSS , הגדרות לציוד ( כמו למשל קונפיגורציה של נתבי Juniper ודומיהם ) ולאט לאט כמעט כל תקשורת המכילה נתונים מידיים ומובנים עוברת למודל זה. אפילו עולם הMobile עובד בתצורה זו. נכון להיום , ישנם מוצרים רבים אשר בעבר הוגדרו על ידי SNMP או קבצי קונפיגורציה שהורדו ועבר קומפילציה על המכונה , והיום עוברים בXML. למשל טלפוניית הIP של סיסקו.

תקשורת הSOAP

הרעיון הכללי לתקשורת בXML באמצעות SOAP הוא : לכל צד אפליקטיבי אשר מבקש להעביר או לקבל נתונים יש PARSER מובנה אשר חותך את מבנה הXML ומייצג אותו בפני האפליקציה , וכמו כן יודע לקחת את נתוני האפליקציה ( וזה כבר מותאם אישית לכל אפליקציה ) ומפיק ממנה XML וגם DTD ( סכימת המבנה בXML ) את הXML עצמו מעביר פרוטקול SOAP למעטפות ושולח על גבי IP לצד השני . בצד השני מקיים התהליך ההפוך של פתיחת הפמעטפת , REPARSING והמרת המידע למבנה המבוקש.

סכימת המבנה של שימוש בSOAP בHIGH-LEVEL ( תהליך ממוספר ) :

soap_h4

התקפות

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

  • SQL Injection , כן - אותה התקפה המוכרת לנו כלכך מעולם הSQL ועולם האפליקציה , מקבלת פנים חדשות לחלוטין. תחשבו על זה לרגע , למרות שתווך העברת הנתונים אינו SQL אלא XML , ישנו PARSER אשר הופך את המידע משאילתת SQL לXML ובחזרה . זה אומר בעצם שאם הייתי גורם לנתונים בתוך הXML להכיל את אותו "גרש" וסקריפ אחריו בתוך שדה נתונים - הPARSER בצד השני ימיר את ההתקפה בחזרה לSQL וההתקפה תעבוד. למרות כל ההגנה שהשקענו עד היום.
  • Recursive Payloads – התקפה המתבצעת על הPARSER אשר אמור לטפל בבקשות מסויימות , מתבצעת רקורסיה ארוכה , אשר גורמת לDOS. התקפה קלה מאוד לביצוע שכן הPARSER תמיד מנסה להבין את מבנה הנתונים ולענות לבקשות פעולה בקוד המעטפה.
  • WSDL Scanning – זליגת מידע על ידי סריקת מבנה התשתית של מעטפות הSOAP על ידי למידת מבנה מסד הנתונים המוצג בתבנית הWSDL. ברוב המקרים - במידה וכבר בחרו להצפין את תווך הSOAP או אפילו לבצע IP FILTERING כדי שהתווך יהיה רק בין שני גורמים , המעטפת תמיד נמשכת ממקור צד שלישי, שאולי אינו מוגן. כאשר אני קורא את הסכימה , אני יכול להסיק על כל מבנה הנתונים המוצג בשאילתות , ללמוד את מבנה מסד הנתונים, ולחסוך זמן בעבודת הפריצה וגניבת המידע.
  • Schema Poisoning - שינוי מעטפת הXML על מנת לשנות את מבנה הנתונים והמידע המופק ממנו , בעצם אני משנה את הצורה שבה אמור להיקרא המידע על ידי הצד השני על ידי שיבוש הסכימה, והמידע מגיע משובש לצד השני. ( MITM עובד כאן יופי יופי ).
  • SOAP Routing Detours - על ידי שתילת תגיות נוספות למעטפה , ניתן לגרום למעטפה לעבור דרך גורם שלישי בדרך , לבצע MITM ולשבש ואף לגנוב מידע מבלי שיורגש.

וירולוגיה

אין לשכוח עולם שלם של וירולוגיה ממוחשבת אשר עוברת דרך SOAP וXML. תחשבו על זה רגע ... נכון להיום כל מערכות האנטיוירוס סורקות רק נתונים מסויימים , ורק סוגי תעבורה ופרוטוקולים מסויימים. אם אני מפרק וירוס לתוך מעטפות SOAP , הוא יופעל על ידי האפליקציה שביצעה PARSING והרכיבה את הוירוס מחדש , ואותה אפליקציה , באופן לא מפתיע - מורשית לרוץ על המערכת , ולכן מערכות HOST-IPS ורוב הAV פשוט לא יתייחסו ( ברור לחלוטין גם מול הUAC של ויסטה ).

סיכום

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

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

Labels: , , , , , ,

Tuesday, September 25, 2007

פרצת אבטחה במנוע החיפוש החדש של תפוז

היום קיבלתי משני האקרים חביבים העונים לכינויים GOURANGA , Shed0\Tomer40 - מייל המתאר פרצת אבטחה שהם מצאו במנוע החיפוש החדש של תפוז. כמובן שהכנתי לכם מייד סרטון שמראה POC לפרצת האבטחה, ובמקביל שלחתי אימייל למערכת תפוז , בנוגע למנוע החיפוש ולבעיה שנמצאה. כך שייתכן שעד לזמן הפרסום , תיחסם הפרצה.

לא בדקתי אם מדובר באפשרות ליצור Persistant XSS , אבל בהחלט ניתן לגנוב עוגיות מהדפדפן של המשתמש המותקף ולשלוח אותן לאן שאנחנו רק רוצים.

הקוד לביצוע הXSS:

http://www.tapuz.co.il/search/search.asp?q=%3C%2Ftitle%3E%3Cbody+onload%3D%22alert%28document.cookie%29%22%3E%3C%2Fbody%3E%3Chead%3E%3Ctitle%3Ewanksta&tapuzGoogleSelection=1

תודה ל Shed0\Tomer40 ול GOURANGA על העבודה הטובה של מציאת הפרצה, וכמובן שיתוף המידע. 

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

Labels: , , , ,

Wednesday, September 19, 2007

XSS באתר hadassah.ac.il

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

 
בכל אופן , זה כאן . אני בכל מקרה Whitehat ולכן , אין לי כל סיבה או רצון להמשיך לחפור ולבדוק לאן עוד ניתן להגיע , אבל ברור שאפשר. לצערי , למרות שאני נוהג בד"כ להודיע לגוף שבו מצאתי בעיית אבטחה , למכללת הדסה אין נקודת פניה גלויה לציבור הגולשים. שלחתי הודעה לכתובת הכללית ליצירת קשר.
 
POC :
1. יש להיכנס לאתר www.hadassah.ac.il
2. יש להקיש בחלון החיפוש בצד ימין - <script>alert("xss");</script>
3. הXSS להוכחת פגיעות יפעיל חלון שבו יהיה כתוב XSS כמובן.
 
אגב , נושא הXSS פוקד אותי לאחרונה למחקרים עמוקים אודות כדאיות ושימושיות מערכות Application-Layer-Firewall אשר מגינות בדיוק כנגד בעיות כאלו , וכמובן יכולת ועומק הטיפול בבעיות משתנה ככל שהמוצרים מתפתחים.
 

Labels: , , , , ,

XSS באתר information.com

למי שלא מכיר , אתר information.com הוא אתר אשר חלק ניכר מהפעילות שלו הוא לזרוק פרסומות מוכוונות עבור דומיינים לא קיימים , זא בשל הסכם תמלוגים עם NETSOL ועוד מספר חברות. מה שקורה הוא שברגע שאתה מכניס דומיין שלא קיים , נגיד לצורך העניין "jihad.com" לכתובת הדפדפן , NETSOL מפנים אליך את מילת המיון הזו ( שאין לה עדיין דומיין ולכן NETSOL בונים ZONE זמני בDNS, או שINFORMATION.COM קנו את הדומיין בעלויות של 2$ לדומיין ).

השתמש נכנס והוא מפונה למידע לינקים הקשורים למילת החיפוש שלו , ולכן הפרסום ממוקד לא רע , והחברה מרוויחה לא רע. כמובן שיש שדה חיפוש באתר שלהם. עבור חיפוש משני ממוקד גם הוא. ושם צץ לי רעיון לבדוק פגיעות XSS או בתרגום - Cross Site Scripting.

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


בשנים האחרונות , השוק מוכיח שרובו ( לדעתי מעל 80% מהאתרים ) חשוף לבעיות XSS שונות באתרים שלהם והמודעות משום מה לא עולה בקצב מתאים. מה שיוצר מצב עדין בין החברת אשר כבר מודעות ומגינות בדרים שונות כנגד SQL Injection אבל שוכחות התקפות יעילות ופשוטות ליישום כמו הXSS.

Labels: , , , ,

Saturday, December 16, 2006

Blended Threats

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

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

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

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

ומה הבעיה בכלל ? הרי יש לי אנטיוירוס ואנטיספאם ואנטי אנטי אנטי ... ובכן תתפלאו , הם לא יתפסו התקפות כאלה במעל 80% מהמקרים. וזאת מפני שכל מנוע שכזה עובד לבד , אנטיוירוס חותם לבד שקובץ נקי , וגם מערכת האנטיספאם , הIPS יעבוד באותה צורה וכן הלאה. ולמעשה כל פתרון UTM שלא יהיה , לא יפתור את הבעיה מאחר והיא מחולקת על יותר מידי שכבות , כאשר באף שכבה אי אפשר לומר במדויק "כן , זו התקפה !". אולי חברה אחת או שתיים פנו לתת מענה אמיתי לבעיה זו ( על ידי כתיבת כל המנגנונים בעצמך , אתה מסוגל לבצע קונסילידציה של החלטות על סמך ניתוח משותף של כל המנועים , ורק כך תוכל לגלות את ההתקפה ).

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


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

בנוסף למאמר שלי בנושא UTM שפורסם באנגלית בבלוג הזה : גילשו למאמר

Labels: , , ,


About

    My Name is Barry Shteiman, im a devoted tech junkie, and this is my blog.
    E: barry.shteiman -at- gmail.com
    Twitter : bshteiman

Tags & Categories

Mailing List & RSS

Stay Updated  
Add to Technorati Favorites