טכנולוגיה ואבטחת מידע מזווית אחרת

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

רוב הציבור נוהג להסתכל על אבטחת מידע כדבר מאוד מונוטוני – כשאדם רגיל שומע שיש באתר "פירצת אבטחה" הוא מתחבא מתחת לשולחן, מנתק את המודם מהמקום וממלמל מתחת לשפם "שמע ישראל" בתקווה שההאקר המרושע לא ידפוק את המחשב. במציאות העניינים מתנהלים די אחרת: גם באתרים מקצועיים של אבטחת מידע, לרוב מדורגת הפירצה במדד מסויים (ראיתי כאלו שמדרגים אפילו בכמה מדדים נפרדים, מ1-3, וציון סופי של 1 עד 10 – OSVDB). ישנם פרמטרים שונים שמשפיעים על כמה הפירצה חמורה, והרבה פעמים ימצאו פירצות שיהיה די קשה לנצל אם שאר האתר מוגן כמו שצריך (דוגמה טובה לכך תהיה פירצה שמסוגלת לפלוט את שם המשתמש של מנהל האתר, אך הפאנל לניהול יהיה מוחבא היטב, ובו תהיה הגנת CAPTCHA והגנה מהתקפות כוח-גס).

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

ראשי התיבות של XSS הן Cross Site Scripting. אז למה לא CSS, ישאלו החכמולוגים שבינכם, ויקבלו את התשובה שישנו כבר קיצור נפוץ מאוד בשם CSS – כל כך נפוץ, כנראה, שלא ראו לנכון לבנות עליו ביטוי נוסף. לכל אותם חברה שאינם בעלי רקע גדול מדי באתרי אינטרנט ובאבטחת מידע, אוכל להגיד שחלק נרחב מהפרצות החבויות באתרי אינטרנט, הן בעצם פגיעוּת עקב חוסר בדיקה של קלט מהמשתמש. אדם שיכול להיות איש אבטחת מידע טוב, הוא זה שיגלוש לאתר הבנק, וכשישאלו אותו "כמה אתה רוצה להפקיד לחשבון של מר. קוסטנזה" הוא ירשום בשדה הקלט 5000$- (שימו לב לסימן המינוס). בעצם, נעשה פה ניסיון להערמה על מערכת המחשוב של האתר – האם במקום הפקדה של 5,000$ לחשבון, אוכל למשוך 5,000$ מחשבונו של אותו מר קוסטנזה? כאן בעצם בא לידי ביטוי תפקידו של מתכנת מערכות הבנק למנוע מצבים שכאלו, או באופן סציפי יותר – תפקידו לזכור לרשום את התנאי שעבור כל סכום להעברה הקטן מאפס תוצג למשתמש שגיאה, והפעולה לא תבוצע.

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

כל אתר בנוי מקוד מסוים, שניתן לחלק לשני "סוגים":

1. חלק שמעובד על המחשב שלנו, של המשתמשים, ולכן הוא נשלח אל המחשב שלנו ויכול להקרא במלואו על ידינו (תוכלו לראות את הקוד הזה בכל אתר על ידי קליק ימני -> הצג מקור). השפות שמשתמשות בקוד שכזה אינן שפות תכנות, והנפוצות ביותר הן HTML וJavaScript.
   
2. חלק שמעובד על השרת, והדבר היחידי שנשלח אלינו, המשתמשים, הוא התוצאה ("הפלט"). השפות שמשתמשות בקוד שכזה הן לרוב שפות תכנות, וניתן לראות בתחום זה שפות רבות כמו PHP, ASP ודומות רבות להן.
   

אם נפרק את התקפת הXSS למרכיביה, נקבל מעין תרשים זרימה:

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

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

נחלק את התקפת הXSS לשני חלקים (למרות שיש חלק שלישי, עליו לא נדון במאמר):

1. פרצה קבועה: השתלת קוד משלנו בתוך האתר (נניח, בפורומים או במערכות אתרים שמרשות לנו לנהל את הHTML שלנו).
   
2. פרצה "זמנית": באתרים שמציעים עמודים דינאמיים בעלי קלט שמתקבל מהמשתמש – נפרט מיד. הסוג הנפוץ יותר.
   

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

1. נכין דף מראש על השרת שלנו, שיחכה לקבל כפרמטר תוכן של עוגיה. נקרא לו OogiFletzet.php, ומטרתו: ברגע שהוא מקבל עוגיה, הוא מאחסן אותה על Ate.txt
   
2. בדף הפגיע שמצאנו באתר ההוא (זה שמאפשר להכניס בו קודים), נרשום סקריפט בJavaScript שישלוף את התוכן של העוגיות של מי שצופה בדף.
3. הסקריפט של הJavaScript ישלח לOogiFletzet.php את העוגיות שהוא שלף.
4. נשאר רק לחכות שמשתמש (קורבן) מסכן יכנס לדף שבו שתלנו את הסקריפט בשלב 2, ופרטי העוגיות שלו ישלחו אלינו.
5. לרוב, פרטי העוגיות מוצפנות. לכן, נוכל להזריק לעצמינו את העוגיות (לעזאזל, זה נשמע ממש רע) שנצברו בAte.txt ולהשתמש בהן כיאילו היו שלנו.
   

לקוד שכזה, כמו שהוצג בשלב 1, קוראים Cookie Stealer (תודו שזה משעשע ותמיד חלמתם על לגנוב עוגיות! פשוט אמא די מפחידה כשזה מגיע לשם…) בכל מקרה, פעמים רבות הקוד יסונן, אבל בצורה כושלת. ישנן דרכים רבות לעקוף אותו, אבל למען האמת, המדריך הזה בא לעסוק יותר בצד התיאורטי, ולכן לא אפרט פה שום דרך לגניבת עוגיות וכיו"ב (אנחנו בברנז'ה של הכובע הלבן, זוכרים?).

ניתן תרשים ויזואלי שאולי ימחיש קצת מה הולך כאן:

אבל אם להגיד את האמת, הסוג הזה של XSS נפוץ הרבה פחות. לכתוב הודעה באיזשהו פורום, לחכות שאנשים יכנסו ולקבל הרים של עוגיות זה חלומו הרטוב של כל האקר – אבל זה די נדיר. הפרצה הזמנית היא נפוצה הרבה יותר, ולא אתפלא אם במחקר ההוא שנערך ב2007, כ50% מתוך אותם 59.26% היו פרצות "זמניות". קצת קשה להסביר את שונותה של הפרצה הזמנית מזו של חברתה הקבועה, אבל נוכל לנסות ולנסח כלל שכזה: פרצה קבועה מוטמעת בתוך תוכן האתר, בעוד שפרצה זמנית נוצרת כל פעם מחדש. הטכניקה של גניבת העוגיות היא אותה טכניקה עם שינוי אחד קטן: אנחנו הופכים להיות יותר אקטיביים. אנחנו לא ממתינים שאנשים יכנסו לדף שבו השתלנו את פרצת האבטחה, אלא אנחנו פועלים ושולחים לאנשים פרצת אבטחה שיצרנו. כיצד זה עובד?

1. לרוב, את פרצת הXSS הזמנית אנחנו נראה בכתובות של אתרים, כאשר כתובתם דינאמית.
2. כתובת דינאמית תהיה, נניח, http://mysite.com/index.php&search=hello – בכתובת זו אנו עושים חיפוש אחר המחרוזת "hello", והיא משתמשת בשיטה בשם GET לשליחת הנתונים שלה, לפיה הפרמטרים מועברים דרך הכתובת (לדוגמה: search הוא פרמטר, שמציין לעמוד index.php באיזו מחרוזת להשתמש לצורך החיפוש. במקרה זה, המשתמש החליט לחפש hello).
3. אופציה למה שיוצג למשתמש לאחר חיפוש שכזה הוא: "חיפשת את המחרוזת hello, ולהלן התוצאות". אנו רואים שפלט הדף קשור באופן ברור למחרוזת שהזננו, ולכן נשחק מעט עם הכתובת.
4. נשנה את הכתובת ל<http://mysite.com/index.php&search=<script>alert("hello")</script . מה שהכנסתי בפרמטר החיפוש הוא בעצם סקריפט קצר בג'אווהסקריפט, שמטרתו הוא להקפיץ הודעה למשתמש.
5. נכנס לכתובת, ואם תוצג למשתמש הודעת שגיאה עם הכיתוב hello, נדע בוודאות שהאתר פגיע.

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

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

מקווה שהשכלתם,
ים מסיקה

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