Confessions Of A Dangerous Mind

[ 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 -

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 )

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: english, passwords, privacy, sbn, script, spam, threats, virus, vulnerability

Posted by barry at 7:26 AM | Link | Comments

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

אני מקבל לא מעט שאלות לגבי עוגיות מאוד ספציפיות -עוגיות ה utm שמופיעות תמיד כ :

__utma , __utmb , __utmc , __utmv , __utmz

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

בכדי להבין את משמעות העוגיות הללו , אפרט את תפקידיהן :

utma

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

utmb + utmc

עוגיות אלו עובדות במשותף בכדי לדגום זמן שהיה באתר - כאשר utmb לוקחת SIMESTAMP של זמן הכניסה , וutmc מקבלת TIMESTAMP של זמן סיום הSESSION , או EXPIRATION. ולמעשה משמשות לשם אותן פונקציות ניתוח.

utmv

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

utmz

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

 

נעבור לסיכונים

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

יש להבין שהמידע בעוגיות אלו יכול להשפיע אם מישהו יבצע TAMPERING או INJECTION על מנגנון הURCHIN של גוגל , ובעצם הנזק הפוטנציאלי הקיים למנגנון ניתוח האתר יכול לעלות לנו בכסף. כי אם למשל אני מזריק לUTMC ערך הגדול ב10 ימים מUTMB , וכמו כן מכניס לUTMZ קישורים לגוגל עם מילות חיפוש לא נכונת .. ואני מבצע זאת על ידי מניפולציה על גבי מספר רב של מחשבים - אפשר פוטנציאלית לפגוע באמינות המידע שאנו מקבלים מהמערכת ולגרום לבעל האתר להשקיע משאבים וכסף במקום לא רלוונטי.

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

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

דרך שניה, על ידי COOKIE SIGNING ניתן לוודא שאכן העוגיה מכילה מה שהSETTER התכוון כאשר בנה אותה , ולא שובשו ערכים ( יעיל יותר מANTI-TAMPERING למיניהם , לפי דעתי ).

 

עוד מידע לגבי מנגנון הGoogle Analytics ניתן לקרוא בספרות הבאה :

Advanced Web Metrics With Google Analytics - Bryan Clifton

Google Analytics 2.0 - Jerri L. Ledford and Mary E. Tyler

Google Analytics Shortcuts - Justin Cutroni

Labels: architecture, code, cookies, imperva, privacy

Posted by barry at 1:15 PM | Link | Comments

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

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

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

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

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

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

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

Labels: concepts, privacy, service, social, threats

Posted by barry at 9:36 AM | Link | Comments

למי שלא מכיר - מערכת הCA ( ר"ת Certificate Authority ) , היא אותה מערכת אשר מנהלת ומחוללת סרטיפיקטים עבור הארגון , לכל מטרה שהיא - ובעיקר לשם אימות ועבודה מוצפנת מול מערכות שונות. לדוגמא - אחת הדרכים המקובלות כיום לעבוד בתשתית PKI , או להתחבר בVPN , הם באמצעות סרטיפיקט המופק על ידי מערכות הארגון.

בין המערכות שמרכיבות את הCA , תמיד קיים הCRL ( ר"ת Certificate Revocation List ) אשר מולו בעצם מתבצעת הבדיקה - האם הסרטיפיקט קיים וValid , או האם הוא Revoked או פג תוקף מסיבה כלשהי. כמובן שמערכת זו צריכה להיות זמינה לכל הגורמים הרלוונטיים.

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

אחד הדברים החשובים ביותר בארגון שלנו מבחינת תשתית PKI , הוא הPrivate Key שלנו. אותו מפתח מנוהל על גבי שרת הCA. מסיבה זו בדיוק - הופך שרת הCA לאחד הגורמים החשובים ביותר ברשת שלנו ודורש הגנה מקסימלית. שכן ברגע שנגנב הPRIVATE KEY שלנו , אפשר ללכת הביתה ...

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

ראשית , יש ליצור Subordinate CA , בעצם שרת CA משני אשר נגיש מבחינת המערכות השונות , ואז יש לבצע העברה של שרת הMaster CA לסגמנט משל עצמו ! לא VLAN ולא שום אמצעי לוגי -אלא רגל בFW. לאחר מכן יש למקם אכן את הCRL באיזור DMZ , אך אם הסרטיפיקטים הם לשימוש פנימי ארגוני - למקם אותו באיזור הSDMZ ( ר"ת Secured DMZ ) שמשמעותו שזהו חיץ שאינו נגיש מהאינטרנט או לספקים חיצוניים - אך נגיש לכל המשאבים בארגון. בשלב האחרון , יש לכבות את שרת הCA. אין שום סיבה שהוא יהיה נגיש , שכן המפתח הפרטי המוחזק על ידו לא צריך להיות זמין , ותפקודו של הSCA יהיה פונקציונלי לחלוטין , תוך סיכון פחות של משאבי הרשת.

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

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

Labels: architecture, consulting, encryption, managment, privacy

Posted by barry at 6:03 AM | Link | Comments

מזה מספר שנים ( מאז תחילת הBuzz עם ICQ ) אנו חווים עליה משמעותית בשימוש בIM כאשר אני חושב שבארץ - הנפוצים מכולם הם MSN Messanger והSkype. כשאני אומר נפוצים מכולם אני מתכוון בשוק העסקי. זאת מכיוון שכלי הIM כבר מזמן הפכו לכלי עבודה לכל דבר . לקוחות ונותני שירותים עובדים אחד מול השני בדרך זו , עבודה מול גורמים בארצות אחרות וכדומה.

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

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

הפיתרון יכול להיות פשוט - חברת Secway הצרפתית מפתחת מוצר בשם Simp אשר מתלבש על תוכנות הIM שלנו , ומצפין את המידע בהן על גבי פרוטוקול הצפנה RSA. ובכך בעצם יוצר כמו VPCN ( המצאתי עכשיו - Virtual Private Chatting Network ) בין שני הצדדים ( או ריבוי הצדדים ) כמובן שמדובר בהצפנה אסטימטרית , אז אין צורך בהחלפת מפתחות ידנית אלא שימוש באלגוריתם Diffie Helman או דומים לו, לצורך החלפת המפתח. כמובן שבכדי להצפין שיחה כזו יש צורך שלשני הצדדים יהיה מותקן הSimp ( אשר קיים גם בגרסאת חינם ).

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

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

Labels: encryption, privacy

Posted by barry at 7:43 PM | Link | Comments