סיכום כנס OWASP 2008

נכתב ע"י גיא מזרחי בתאריך 25 בספטמבר 2008 | נושאים כללי | 5 תגובות »

לא מזמן היה את כנס OWASP2008.

הכנס היה מרשים, היו לדעתי סדר גודל של 150 איש, אולי יותר.

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

המטרה של OWASP היא להציג את הבעיה ואת הפתרונות האפשריים.

ההרצאה הראשונה שראיתי היתה של עמיחי שולמן:

application security and search engine

ראשי תיבות:

גוגל האקינג על סטרואידים

malware

masking

Search of death

Google for security

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

בהתחלה היה: sql injection. קל לחסום כי יש כאן האקר שמנסה לחדור אז אפשר לחסום את הIP שלו או לבצע DROP לשאילתות שלו וכ"ו.

בהמשך הופיעה CSRF שבעצם נועדה לניצול ההרשאות של המשתמש התמים ושליחה של ATTACK VECTOR בשם התוקף.

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

האיום החדש: מנועי חיפוש.

אני חייב לציין שלדעתי אין חדש בזה. ג'וני (ihackstuff.com) מדבר על זה כבר שנים ומתחזק גם את רשימת השאילתות באתר שלו.

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

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

GOOGLE HACKING:

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

מה חדש (שוב, לדעתי האישית זה ישן)?

לקחת את זה ולעשות לזה אוטומציה.

כלים כמו Goolag scanner ו- gooscan.

כתבתי בבלוג פה על goolag scanner לפני המון זמן.

עמיחי מראה כמה שאילתות חשובות: מספרי SOCIAL SECURITY NUMBERS.. זה בהחלט מעניין J

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

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

לדעתי זו קצת בורות בידע או בהבנה של "איך האקר עובד".

האקר מקבל כסף על הצלחות ולא על נסיונות. לא מעניין אף אחד כמה זמן לקח לו.

ברור שלהגדיל את הזמן זה דבר רע – אפשר לעשות פחות עבודה.

זה לא ממש פתרון – יש דרכים יותר יצירתיות כגון Captcha redirection וכ"ו.

נושא מעניין מאוד שעמיחי מזכיר הוא Google worm:

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

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

איך מגינים?

מניעת כיסוי של דברים רגישים במנועי חיפוש.

איך מפיצים מלוור דרך גוגל?

Search injection – אתרים שמאנדקסים חיפושים עליהם.

נקרא script injection.

Search of death:

האם אני יכול לגרום לגוגל להתקיף אתר בשבילי?

שאילתות של גוגל שמייצרות sql injection.

ההרצאה על Modprofiler.

הגנה על WA קשה כי הם שונים ומתנהגים אחרת.

אסטרטגיה של WAF:

לבדוק מה לא נכון או לבדוק מה היא פניה נכונה אל אפליקציה.

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

Positive security log: יראה רק דבר אחד – שדה הקלט ויוודא שהקלט שם באמת נכון ולא מתחכם.

Modprofiler: בנו לוגיקה גבוהה. ניתן להריך כ-GW או כ-EMBEDED.

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

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

דברים בסיסיים קל מאוד לעשות, דברים מסובכים אפשריים.

איך בונים מודול?

לנתר את התעבורה, לשבור את השאילתות ולהבין מה צריך לאפשר.

ידני, איטי, קשה..

המודול בנוי:

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

מסקנה עיקרית מההרצאה – קשה להגדיר את המוצרים האלה..

Trends in web hacking – whats hot in 2008?

עפר שיזף מסכם בצורה מעניינת מה חם ב-2008.

האתגר של ניתוח סיכונים. מהו הסיכון?

ההגדרה: Risk=threat X vulnerability X impact

אנו מניחים מראש שהאפליקציות פגיעות.

ככל שהאפליקציות מסתבכות – הסיכון גודל והפגיעויות רבות יותר.

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

עפר נותן דוגמה:

חברת Card systems – חברת סליקת כרטיסי אשראי גדולה בארה"ב.

ב-2005 התגלתה אצלהם פרצה גדולה במערכת PROCCESSING וכ-40M פרטים של לקוחות נגנבו. הם לא גילו את הבעיה.

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

רק שנתיים אח"כ התפרסם שזה היה SQL INJECTION.

הסטטיסטיקות מעוותות.

מצד אחד, יש חוקים שדורשים לדווח על גניבת מידע אישי.

DEFACEMENT – מדווח כי רואים את זה.

יתר הדברים פשוט לא מדווחים.

TRENDS:

ב-2007:

CSRF נחשבת התקפה חדשה יחסית (שנתיים) אבל משתמשים בה הרבה פחות.

XSS – פחות בעייתי בשל אופי ההתקפות שנוצרות.

SQL INJECTION – מספר אחת בשנת 2007.

מה הנזק?

גניבת מידע אישי ו-DEFACEMENT.

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

סיפור על גניבת DOMAIN דרך CSRF שהיה ב-GMAIL. מדובר בבלוגר מאוד מפורסם עם אתר על עיצוב אתרים שמרוויח מהבלוג ומהעיצובים בו כסף.

גנבו לו את הדומיין ובסוף מנכ"ל חברת GODADDY טיפל בזה כדי להחזיר לו את הדומיין.

אותה פרצה בדיוק גם נוצלה כדי לתקוף את הבלוג שלי בעבר.

2008:

הדרך הטובה ביותר לנצל כלכלית את האינטרנט – ע"י WEB vulnerabilities.

SQL INJECION CRAWLERS. החדרה של קוד זדוני לכמה שיותר אתרים בעזרת ניצול אוטומטי של SQL INJECTION.

הלוגיקה של התולעת:

חיפוש VULNERABILITY דרך GOOGLE.

עובר על כל הטבלאות והשדות ב-DB והוא מוסיף בהם קוד זדוני.

קל לגלות וקל לחסום.

בנוסף לקרוא על:

Web site bots herding – זה המינוח המתאים לאתר שהוזרק לו קוד זדוני המאפשר להסב אותו ל-BOT איכותי במיוחד.

התקשורת עם ה-BOT מתבצעת באמצעות HTTP וזה קל ויעיל לעבוד מול כזה BOT.

Hacking service providers – מתברר שיש דיבורים על כך שדווקא ISP יותר פגיעים לבעיות אבטה בשל כוח אדם בעייתי (לא מיומן) הנובע מתקציבים נמוכים ומתח רווחים נמוך.

TESTING THE TESTER:

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

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

הבעיה: איך לדעת שבדיקת אבטחה מספיקה? איך לדעת שצריך להוציא כסף על מוצר A ולא על B?

עפר מחלק את הבדיקות לשני חלקים:

False positives

False negatives

שני המקרים בעייתיים:

False negatives חושף את הארגון לפרצות ואילו False positives גורם לעודף עבודה ודחייה של מועדי השקה של מוצרים.

כיסוי הבדיקה:

יכול להיות Vulnerability שלא נבדק או Variant של חולשה שלא נבדקה.

כיסוי החלקים של הקומפוננטות:

חלק מה-URL לא נבדקים או חלק מהקוד של האתר לא נבדק.

תוספת שלי:

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

http://www.schneier.com/blog/archives/2007/04/a_security_mark.html

בעיית איכות הבודק.

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

CRAWLER אוטומטי נותן פתרון לכיסוי מסויים אבל גם מהווה בעיית כיסוי.

בבדיקות מסחריות יכולות להיות בעיות כיסוי בשל יחסי B2B בעייתיים וחוסר אישור לבדוק חלק מהתהליכים.

כיסוי בדיקה:

Vulnerability not tested או variant not tested.

או כי זה בלתי אפשרי או כי עלול לפגוע בשירות.

כמה איום מהווה בעיית אבטחה?

צריך להתחשב בעניין של מה האיום המהווה הבעיה שהתגלתה.

אבטחה זה דבר יקר.

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

False Positives יכולים להיות בשל:

הבדיקה לא הוגדרה כראוי.

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

VALIDATION:

כמה בעייה מהווהVulnerability שגילינו?

צריך לנסות לבנות התקפה ולא רק למצוא בעיית אבטחה.

איך מדרגים את הסכנה של Vulnerability?

אין לזה תשובה אמיתית. זה תלוי בסיטואציה.

.net rootkit:

הרצאה מדהימה של ארז מטולה.

ניתן לשנות את הFRAMEWORK ולא את הקוד שהמפתח כותב.

שלבים:

1. לזהות איפה ה-DLL יושב (GAC)

2. Decompile עם ildasm

3. שינוי הקוד הרצוי

4. Recompile

5. עקיפה של GAC

6. Deploy

הכלים בשימוש:

Filemon

Reflector

Ilasm-compiling

Ildasm- decompiling

Text editor

Ngen – native compiler

כשמריצים את התוכנה FILEMON חושף את ה-DLL שעובד.

עושים decompile ואז מקבלים את הקוד.

משנים את הקוד.

מקמפלים את ה-DLL מחדש.

השלב הבא – דחיפה שלו לתוך ה-FRAMEWORK. הבעיה היא ש-GACUTIL יצעק שה-DLL עם חתימה שונה.

הבדיקה מתבצעת ברמת FILESYSTEM ולא על הקובץ עצמו!

ז"א שאם נדחוף את הקובץ לתיקייה הנכונה – הוא נחשב בסדר.. J

הבעיה – ה-FRAMEWORK עדיין משתמש ב-DLL המקורי.

צריך לבצע UNINSTALL ל-DLL הזה ואז החדש שלנו יעבוד.

Ngen uninstall

ארז הראה:

Reverse shell, authentication details send

XSS, קיבוע מפתחות הצפנה, DOWNGRADE וכ"ו.