Confessions Of A Dangerous Mind

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

ביום חמישי הקרוב – 3 לספטמבר 2009 , במשרדי מיקרוסופט ישראל שברעננה , אעביר הרצאה בנושא TOP 10 DB Threats.

הרשמה לאירוע :

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032422463&culture=he-IL

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

Labels: conference, consulting, database, imperva, lecture, managment

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

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

הסיבה לבעיה נעוצה בעובדה ש Proxy ( או Load Balancer ), שובר את הTCP Stream ומייצג כתובות IP אחרות בחלק הפנימי שלו . לפי כך מערכות קלאסיות כמו IPS או דומות , אינן רואות את כתובות הIP האמיתיות אשר הגיעו מהעולם. לא ניתן לזהות את מקור ההתקפה בצורה קורלטיבית ומכך נגזר - שאי אפשר להגן בצורה יעילה כנגד התקפה על פי זיהוי מקור.

כאן בדיוק נכנס עולם ניתוח האפליקציה.

כאשר Proxy או כל TCP Terminator כלשהו ( כגון Load Balancer ) קיים , אחת התכונות שלו היא הוספה או עריכה של Headers - דוגמא טובה תהיה בHTTP Header. התוספת הרלוונטית במקרה של Proxy תהיה בצורת פרמטר X-Forwarded-For , אשר הינו פרמטר המכיל את הIP המקורי אשר קולף על ידי הProxy והוחלף בכתובת שלו עצמו.

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

כמובן רצוי לוודא שקיים Trust מסויים בין הProxy לבין אותה מערכת , כדי שהמערכת תדע שהHeader אכן שונה על ידי הProxy ולא על ידי אלמנט צד שלישי ,כגון האקר שרוצה לעקוף IP Filtering בצורה זו.

Labels: design, imperva, technology, waf

Posted by barry at 8:12 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

שלום לכולם,

אתם מוזמנים לקרוא את הפוסט האחרון שלי בבלוג ImperViews בקישור הבא :

http://blog.imperva.com/2008/12/the-interoperability-of-your-s.html

Labels: architecture, consulting, imperva, imperviews

Posted by barry at 9:38 PM | Link | Comments

Confessions Of A Dangerous Mind הוא בלוג שהתחלתי לכתוב בשלהי 2006 , שהתחיל בכלל באנגלית והוסב לעברית כשראיתי שמעטים הבלוגרים שנותנים תשומת לב לתעשייה הישראלית.

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

כתוצאה מכך, אתחיל לפצל את הכתיבה בין הבלוגים.

הזמן יגיד לאן ילך רוב הפוקוס.

בארי.

Confessions Of A Dangerous Mind is a blog ive been writing since the late 2006. This blog that started out as an English blog an later transferred in whole to a Hebrew one in order to pay attention to the Israeli industry.

Lately, I have joined Imperva's blogging team for the Security Blog - ImperViews, which is being written by different people at Imperva organization.

Following that decision, I will probably split my writing between this blog and the ImperViews Blog... Time will tell where I will put my focus.

- Barry.

Labels: blog, english, imperva, links, news

Posted by barry at 10:55 PM | Link | Comments

אני אוהב לדבר על מערכות ניתוח תעבורה , ניתוח השכבות ופירוק האפליקציה והפרוטוקולים לגורמים תמיד ריתקו אותי ונתנו לי נופך לעבודתי במרוצת השנים. ועם הכל די התמחיתי בכלי ניתוח התעבורה השונים אשר התחילו מבדיקות 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: code, consulting, hacking, imperva, sql, threats

Posted by barry at 11:24 PM | Link | Comments

אז מה ?

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

ולמה ?

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

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

ומי ?

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

ונוסיף.

בנימה אישית יותר - הדבר שהכי שיעשע אותי בחודש האחרון היה הספקולציות בין החברות השונות, בעוד FORTINET היו בטוחים שאני הולך לJUNIPER , ובצ'קפוינט היו בטוחים שאני הולך לFORTINET ובJUNIPER היו בטוחים שאני הולך לצ'קפוינט , ובבזק בינלאומי היו בטוחים שאני הולך לRSA עם אנשים בודדים שחשבו שאני מצטרף לVANADIUM או אולי לISS וחלקם אפילו לCROSBEAM , וCOMSEC הפצה עשו מה שהם עושים הכי טוב - הפצה ... היה מאוד משעשע ... במיוחד לגלות שאחרי שבועיים , כולם - אבל כולם , ידעו , ולא ממני... רק בישראל.

Labels: blog, changes, imperva, job, news, taldor

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