IIS 6 Parsing Directory Vulnerability
ב-25 לחודש פרסם חוקר אבטחה איראני בשם Pouya Daneshmand חולשה שגילה באחד ממנגנוני ה-Parsing של שרתי
IIS6, שמאפשרת לגרום לשרת ה-IIS להתייחס לקבצים בעלי סיומות "תמימות" כאל קבצי ASP ובשל כך לגרום להרצת קוד
בצד השרת.
החולשה דווחה לראשונה לפני כחצי שנה (06/18/2010) ב-sebug.net, לפי מה שפורסם עדיין אין טלאי לחולשה הזאת.
אז מה הסיפור?
Pouya גילה שכאשר יוצרים תיקיה עם הסיומת: "asp.", לדוגמא: Images.asp וניגשים אליה, השרת יחזיר 404 (במקום להעביר
את המקרה לרכיב ה-Virtual Directory והצגת ה-Directory Listing / הצגת ההודעה "Directory Listing Denied" וכו'. ככל
הנראה (לא חקרתי את המקרה לעומק) הדבר נובע מכך שהשרת מנסה לגשת לקובץ בשם הזה ולא לתיקיה בשם הזה, גם אם
נשלח את הבקשה באופן הבא:
https://iis6server/folder/folder.asp/
השרת ינסה לשלוף את הקובץ "folder.asp" שנמצא תחת התיקיה "folder".
בנוסף, אותו חוקר גילה כי במידה ונאחסן קובץ עם כל סיומת שהיא על אותה התיקיה- השרת יתייחס אליו כאל קובץ Active
Server Page וינסה לפרש את התוכן שלו תחת מנוע ה-ASP בשרת ויציג למשתמש את התוכן, ממש כאילו מדובר בקובץ
ASP רגיל.
לדוגמא, אם ניצור קובץ בשם image.jpg, נפתח אותו בעורך טקסט, נשמור בו את הקוד הבא:
<% Response.Write("Hello World!") %>
ונעלה אותו לשרת IIS6 תחת תיקיה ששמה מסתיים ב-"asp.", ונגלוש אליה בעזרת הדפדפן- נקבל את התוצאה:
Hello World!
אישית בדקתי את החולשה רק בשרתי IIS6, אך לפי הפרסום שרתי IIS 5.1 ו-IIS7 אינם חשופים.
למרות שמדובר בחולשה יפה מאוד, בכדי לנצל אותה צריך: א'- גישה ליצור תיקיות על השרת. ב'- גישה להעלות קבצים לשרת.
אני יכול לחשוב על מערכות מסויימות להעלאת תמונות שמאחסנות את הקבצים תחת תיקיות לפי שמות משתמשים, ואז, בכדי
להריץ קוד על השרת יש להרשם עם שם כמו: "user.asp".
הפתרון המומלץ ביותר הוא לעדכן לשרת חדש יותר, אבל גם פעולות כמו: לא לאפשר למשתמשים להעלות קבצים לשרת
שלכם, או לבטל הרשאות הרצה מכלל התיקיות חוץ מהתיקיות המוגדרות לכך. וכמובן- לכתוב את המערכת שלכם בתוכנה
נכונה, לדוגמא: המיקום שבו המערכת מאחסנת את קבצי המשתמש אינו נקבע או מתבסס על שום קלט שמגיע מצד הלקוח,
את אופי וסוג הקבצים מקטלגים ומגדירים על פי תוכן הקובץ ולא רק לפי הסיומת שלו וכו' וכו'.
אגב, לי אישית הבאג מזכיר מאוד את ה-Semi-Colon Bug מ-2009 שפרסם חוקר האבטחה Soroush Dalili שגם היה ב-IIS,
(CVE-2009-4444 / CVE-2009-4445 ), למי שלא זוכר:
תגובות על 'IIS 6 Parsing Directory Vulnerability':
#1 |
 |
Dw4rf (אורח): מגניב! באג נחמד אבל כמו שהצגת אותו- הוא באמת רחוק מלהיות ברמת ״קריטיקל״, אגב, סיפי, ידוע לך אם הבאג הזה הוא באותו מנגנון פירסור כמו של 2009-4444? 28.01.2011 20:11:21 |
#2 |
|
Dw4rf (אורח): ועוד שאלה, איך אני יכול לדעת באיזה דרך הם תיקנו את הבאג? (אני מדבר על 4444) או בעצם כל באג שהם מתקנים? יש איזה מקום שהם כותבים בו את זה? 28.01.2011 20:12:38 |
#3 |
|
cp77fk4r: האמת היא שאין לי מושג אם הבאג הוא באותו המנגנון, מה שכן הוא שאני יודע שהבאג לא קיים ב-ASP.DLL אלא עוד במנגנונים הרבה לפני. בקרוב תהיה התייחסות מהספק ואני בטוח שיהיו יותר פרטים. בקשר ללדעת איך הם תיקנו באג מסויים- הם לא באמת יגלו לך ויכתבו את זה איפשהו, אבל אם אתה יודע באיזה מנגנון כשל האבטחה נמצא, תוכל פשוט להריץ במקביל את המנגנון לפני העדכון ואת המנגנון לאחר העדכון תחת דיבאגים ולבדוק מה בדיוק ההבדל. 28.01.2011 21:01:40 |
#4 |
|
Dm12 (אורח): נחמד ביותר! יש מערכות פורומים שבנויות בצורה שדיברת עליה- מעניין עד כמה הן פגיעות. @Dw4rf אני הבנתי שניתן לבצע DIFF על הקובץ המקורי ועל הקובץ לאחר העדכון ומשם להבין איפה מתבצע ההבדל. 29.01.2011 03:31:09 |
#5 |
|
Dw4rf (אורח): אני מאמין שברב המקרים לא מדובר בשינוי של קובץ אחד, ככה שלבצע DIFF לא באמת יעזור. לא? 29.01.2011 13:21:11 |
#6 |
|
גיא (אורח): סיקור מעניין, תודה רבה! 29.01.2011 21:50:22 |
#7 |
|
אורח (אורח): מישהו בדק לגבי aspx? 05.02.2011 00:06:11 |
#8 |
|
cp77fk4r: בהחלט. א'- כמו שאני מאמין, בחור שגילה את הבאג ישר בדק לגבי ASPX. ב'- אני בדקתי, רק כדי להיות בטוח ;) ג'- אתה מוזמן תמיד לבדוק בעצמך. יכול להיות שקודמך פספסו משהו. 05.02.2011 01:09:57 |
#9 |
|
cp77fk4r: עוד דבר, בקשר לתגובה של Dm12: זה נכון שיש מקרים שבהם תיקון של באג מסויים לא מתבצע רק בקובץ אחד, אבל ב(רב?)הרבה מאוד מקרים זה כן, תיקון של באג מסויים בדרך כלל מתבצע על ידי עדכון של הפונקציה שאחראית על פרסור המידע, או במספר פונקציות בודדות שאחראיות על Flow מסויים בתהליך, אם זה באג שבגללו צריך לשכתב ספריה שלמה- צריך לפטר את המפתח. בכל אופן, במקרים כאלה, ניתן להשתמש בכלי להשוואה בין שני קבצים בינארים שנועד לעשות בדיוק את העבודה הנ״ל בשם: BinDiff, הוא מאוד נח לשימוש ומגיע כפלאגין ל-IDA Pro. 07.02.2011 07:04:06 |
הוסף את תגובתך:
