חקירת בטיחות WebSocket

תמליל

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

2 1 תוכן עניינים הקדמה... 2 מושגים... 7 מטרות... 9 כלים שלב 1: הקמת תשתית שלב 2: מימוש התקפות ידועות Cross-site WebSocket Hijacking שלב התקפות DoS פשוטות : מימוש התקפות חדשות WebSocket באמצעות HTTP CSRF 21 התקפות DoS מורכבות Header Manipulation מסקנות מקורות... 27

3 2 הקדמה פרוטוקול RFC WebSocket WebSocket הוא פרוטוקול המספק תקשורת דו-כיוונית communication( )full-duplex מעל חיבור TCP בודד. מטרת פרוטוקול זה היא לספק תקשורת דו-כיוונית בין אפליקציות דפדפן לבין שרתים, ובכך לחסוך יצירת מס' רב של בקשות HTTP ולמנוע.HTTP Polling כיום שרתי אינטרנט מתקשרים עם הלקוח בעזרת פרוטוקול,HTTP המספק תקשורת חד-צדדית, ולכן על מנת לקבל מידע מהשרת יש לבצע בכל פעם בקשת HTTP חדשה. כל בקשת HTTP עטופה בHeader גדול יחסית אשר מכיל הרבה מידע שכבר אינו רלוונטי לאחר ההתחברות הראשונית. מסיבה זו, ורבות אחרות, הlatency של חיבורי HTTP הוא יחסית גדול ובכך נפגעים הביצועים של שרתים אלו. פרוטוקול WebSocket הומצא על מנת לפתור בעיות חיבוריות אלו, כפי שניתן לראות באיור: הפרוטוקול נועד לאפליקציות real-time אשר מעדכנות את המשתמש במידע עדכני בקצב מהיר, והוא מאפשר, לאחר הקמת הקשר, לשרת וללקוח לדבר מעל אותו פרוטוקול דו-צדדי וליזום שליחת הודעות אחד לשני )להבדיל מrequest-response (. לדוגמא: אפליקציות של צ'אט, חדשות, מניות ומז"א, משחקי רשת,)MMO( שיתוף מסכים, עריכת מסמכים שיתופית והרשימה עוד ארוכה. הפרוטוקול Websocket הינו עצמאי, עובד מעל,TCP כאשר הקשר היחידי שלו עם פרוטוקול HTTP הוא הקמת הקשר.

4 2 להלן דוגמה של הקמת קשר WebSocket סטנדרטי לאתר ws://echo.websocket.org כפי שנצפתה בWireShark : Request: WebSocket HTTP Handshake Response: נמחיש זאת בצורה ויזואלית יותר:

5 4 יש להשלים Handshake לפני פתיחת חיבור נוסף לאותו השרת. השלמת הHandshake בהצלחה מבטיחה ששני הצדדים מדברים,Websocket אך אינה מבטיחה אימות ו/או אמינות. כמה דברים לשים לב אליהם: Sec-WebSocket-Key: base64(16 random bytes) Sec-WebSocket-Accept: base64(sha1(challenge + GUID)) לחיצת היד מכילה את שדה הOrigin, אך נראה בהמשך שבפועל הוא אינו נבדק..Cookies גם הם עוברים בלחיצת היד, כגון Http שדות האימות של.WebSocket ניתן להרכיב פרוטוקולים אחרים מעל פרוטוקול מרגע השלמת לחיצת היד, גם השרת וגם הלקוח יכולים לשלוח הודעות )טקסטואליות או בינאריות( אחד לשני באופן חופשי, כאשר כל הודעה עטופה בHeader מינימלי שמגדיר הRFC. The WebSocket Header 0 F I N 1 R S V R R opcode M Payload Len Extended Payload length S S (4) A (7) (16 or 64 bits), if V V S Payload Len == 126 or K Extended Payload length continued.....if Payload Len == 127 Mask-key, when MASK == 1 Mask-key continued Payload... Payload continued... לפי ה Header ניתן להבחין במס' תכונות של הפרוטוקול: יעיל בתעבורה: אורך Header רגיל אינו עולה על 2 בתים! )1 בתים כאשר Mask הוא 1( ניתן להרחבה: אורך ההודעה אינו מוגבל ע"י הHeader, וניתן להגיע עד להודעות בגודל בתים.

6 1 OpCodes כרגע הפרוטוקול תומך בפעולות הבאות:.Text - הודעת 0x1-0x2 הודעה בינארית. - 0x8 הודעת סגירה..Ping - שליחת 0x9.Pong שליחת 0xA בפועל ישנם 11 אופציות לopcodeים, אך שאר האפשרויות שמורות עבור הרחבות עתידיות וWebSocket-extensions. FIN דגל הנועד למנגון הMulti-Frame מעל.WebSocket הדגל מאפשר לשלוח מסגרות חלקיות/לא שלמות עם.fin=0 ברצף. המסגרת האחרונה נשלחת עם fin=1 וכך מסומן לצד השני שזוהי המסגרת האחרונה Masking אם הדגל MASK דלוק, תוכן ההודעה מוסתר ע"י רצף בתים רנדומלי באורך 22 -ביט. ההסתרה מתבצעת ע"י XOR בין הMask-key לבין כל 4 בתים של תוכן ההודעה.)payload( בנוסף, ניתן להבחין שheader כזה הופך את הפרוטוקול לקשה למעקב: תוכן כל הודעה מוסתר ע"י mask-key המקבל ערך רנדומלי. לכן תוכנות מעקב דמויות IDS יצטרכו לשמור mask-key עבור כל הודעה על מנת לבחון את התוכן. להבדיל מ- HTTP, אמצעי הזיהוי עוברים רק בתחילת הפרוטוקול )בHandshake ( ואינם מופיעים בהמשכו, לכן קשה לזהות חיבורים קיימים ולשייך אותם לWebSocket. במקרה זה הם ייראו בתור קשר TCP רגיל, וכך להכנס מתחת ל"רדאר" של תוכנות.IDS לסיום, נציין שניתן לדבר בכל פרוטוקול אחר מעל פרוטוקול WebSocket כפי שניתן מעל TCP במודל השכבות, בהנחה ושני הצדדים תומכים בכך. השרת יבחר באיזה פרוטוקול ידברו ויודיע זאת בשדה Sec-Websocket-Protocol: אשר בלחיצת היד.

7 1 WebSocket API אחת מטרות הפרוטוקול הינה הצגת סטנדרט פשוט להקמת קשר דו-כיווני ושליחת הודעות. לכן יחד עם הצגת הפרוטוקול, אתר W3C הציג את הAPI ששני הצדדים )השרת והלקוח( צריכים לממש באופן סימטרי: פונק' הנקראת בעת הקמת חיבור חדש לאחר סיום לחיצת היד OnOpen- פונק' הנקראת בעת סגירת החיבור מכל סיבה שהיא - OnClose פונק' הנקראת בעת קבלת הודעה - OnMessage פונק' הנקראת כאשר מתרחשת שגיאה OnError- פונק' המאפשרת שליחה של הודעה - Send נתייחס בהרחבה במבנה של הAPI כפי שהוא ממומש ב- Javascript עבור דפדפנים כאשר נתאר את ההתקפות על צד הלקוח. הAPI כיום ממומש עבור צד לקוח וצד שרת במגוון שפות כגון: Ruby, JavaScript, Java, Python,,++C,Dojo והרשימה רק ממשיכה לגדול... אז למה בעצם WebSocket o o o זה מעניין? פרוטוקול חדש יחסית, אינו מוכר ע"י כל תוכנות האבטחה: o לא הרבה מומחים מתעסקים בו, ולכן יכול להיות שהוא עדיין פגיע. כאשר אפליקציות אבטחה קיימות,IDS( )WAF נתקלות בפרוטוקולים לא ידועים, הן מעדיפות להעביר את המידע מאשר לחסום על מנת לא לפגוע באינטרס של הלקוח, לכן תעבורת WebSocket זדונית עלולה לעבור IDS ללא בדיקה. הHeader קטן ואינו מספק פרטי זיהוי מספיקים, דבר המקשה על תוכנות ניטור לעקוב אחר תעבורת.WebSocket כאמור, המסגרות עוברות.Masking זה המקשה על תוכנות ניטור לעקוב אחר תעבורת.WebSocket פרוטוקול איכותי ויעיל עבור אפליקציות,real-time ולכן סביר מאוד שישתמשו בו. כל פרוטוקול דו-צדדי גורר הקצאת משאבים אצל השרת ולכן סביר יותר שיהיה פתוח להתקפות.DoS בגלל שהHandshake הוא מעל,HTTP סביר שהתקפות על HTTP )גם כאלה שכבר יודעים להתמודד איתן( יעבדו על.WebSocket

8 7 מושגים להלן הסבר על המושגים בהם נשתמש בהמשך: HTTP פרוטוקול תקשורת ברשת שנועד להעברת דפי HTML ואובייקטים שונים שהדפים מכילים )כמו תמונות, קבצי קול, סרטונים וכו'(, הפרוטוקול עובד מעל פרוטוקול,TCP בדרך כלל דרך פורט 01. שרתי התוכן המרכזיים באינטרנט הם שרתי HTTP והתוכנות הנפוצות ביותר לעבודה של צד-לקוח עם פרוטוקול זה, הן הדפדפנים השונים Explorer( Google Chrome, Mozilla FireFox, Internet וכו'(. התקשורת בין השרת ללקוח נעשית באמצעות בקשות שהלקוח שולח לשרת, לאחר קבלת הבקשה, השרת יפענח אותה, ישלח ללקוח תשובה מתאימה ולרוב גם ינתק את החיבור עם הלקוח לאחר שליחת התשובה. התשובה שישלח השרת ללקוח תכיל הודעת סטטוס שתתאר את התוצאה של נסיון ביצוע הבקשה ששלח הלקוח. הסטטוס מורכב ממספר תלת-ספרתי והסבר קצר על משמעותו. GET בקשת הבקשה הנפוצה ביותר ברשת. מטרתה - קבלת אובייקט מסויים הנמצא אצל השרת, כאשר כתובתו תימצא בתחילת הבקשה. Switching Protocols הודעת סטטוס מסוג 111 שהשרת שולח ללקוח. משמעותה שהלקוח ביקש מהשרת להחליף פרוטוקול והשרת מאשר את החלפת הפרוטוקול. Denial-of-service attack (DoS) משפחה של תקיפות שמטרתן היא ליצור עומס חריג על משאבים של מערכת מחשבים כלשהי ובכך להשביתה. למשל, בהתקפת הצפת SYN התוקף שולח למחשב המותקף הרבה חבילות SYN ובכך מאלץ את המותקף לפתוח מספר גדול של חיבורים עד שלמעשה לא נותרים לו משאבים לקבל חיבורים חדשים, כתוצאה מכך לא יוכל לפתוח חיבור עם משתמשים אחרים ובעצם ימנע ממנו לספק שירות. תוצאות תקיפה כזו יכולות לנוע בין פגיעה בביצועי המערכת המותקפת ועד מניעה מוחלטת של גישת לקוחות לגיטימיים למשאבי המערכת.

9 0 SlowLoris תוכנה שפותחה ע"י רוברט הנסן Hansen( )Robert בעזרתה יכול מחשב אחד "להפיל" שרת רשת של מכונה אחרת תוך שימוש במינימום רוחב פס ועומס על המחשב התוקף ]7[. הרעיון מאחורי תוכנה זו היא שליחה לשרת המותקף רק HTTP Header של בקשה כלשהי ולאחר מכן לשלוח את תוכן ההודעה בחלקים מאוד קטנים, כאשר בין שליחות שני חלקים יש פערי זמן. כתוצאה מכך השרת ישאיר חיבורים כאלה פתוחים על חשבון חיבורים של לקוחות לגיטימיים, כאשר התוקף משקיע מאמץ קטן בהרבה מאשר בהתקפת DoS רגילה, משום שלאחר ששלח את הHeader הוא יוכל לשלוח byte אחד כל פעם, במקום הודעה שלמה. Cross-site request forgery (CSRF) מתקפה שכופה על משתמש לבצע פעולות שאין בכוונתו לבצע, על אפליקציית רשת בה הוא כבר מאומת, תוך ניצול האמון של אפליקציית הרשת בדפדפן של המשתמש המותקף. התוקף יכניס אל דף האינטרנט אליו גולש המשתמש לינק או סקריפט שייבצעו גישה )ללא ידיעת המשתמש( לדף אינטרנט אחר המוגן על ידי סיסמא בו המשתמש כבר מאומת )על ידי cookies למשל(. למשל, התוקף ישלח בצ'אט הודעה למשתמש ובה תמונה שכתובת המקור שלה מצויה באתר הבנק של המשתמש. הדפדפן ישתמש בcookies השמורים על מחשב המשתמש על מנת לאמת את זהותו מול הבנק וכך ישיג את התמונה בהצלחה. התוקף יכול לגרום למשתמש לבצע גם פעולות אחרות ומסוכנות יותר: רכישות לא מורשות, שינוי סיסמא למשתמש, קריאת מידע מוגן או כל פעולה אחרת אותה מאפשר אתר הבנק. Same-origin policy מדיניות שפותחה בדפדפני אינטרנט שמטרתה למנוע התקפות.CSRF במסגרת מדיניות זו, במסגרת מדיניות זו, קוד שנשלח על ידי שרת אינטרנט יכול היה לגשת רק למידע שמקורו באתרים מאותו שם תחום ועל גבי אותו פרוטוקול. למשל, בקשות (XMLHttpRequest) XHR יבוצעו בהצלחה רק אם הן מיועדות לאותו שרת )origin( אליו שייך דף האינטרנט ממנו נשלחה הבקשה. אם נסתכל שוב על הדוגמא של הבנק בהסבר על,CSRF בעזרת מדיניות זו הדפדפן ימנע מלגשת לאתר הבנק בעת חיפוש התמונה - מכיוון שהבקשה לא נשלחה מאתר ששייך לבנק.

10 9 מטרות המטרה העיקרית של הפרויקט היא לחשוף נקודות תורפה בפרוטוקול WebSocket משני סוגים: בתכנון הפרוטוקול. במימושים נפוצים של הפרוטוקול - הן בצד שרת והן בצד לקוח. תתי שלבים בדרך להשגת המטרות: למידה של פרוטוקול,WebSocket תוך הבנת יתרונותיו, חסרונותיו, מבנה ההודעות השונות ותהליך הקמת הקשר בין הלקוח לשרת. הקמת תשתית:.WebSocket הקמת שרת מקומי )מימוש נפוץ( שעובד עם הגירסה העדכנית ביותר של o o עבודה עם דפדפנים נפוצים שעובדים עם פרוטוקול WebSocket ועם ספריות צד לקוח של WebSocket שנוכל לשנות בהתאם לצרכינו. למידה ומימוש של התקפות ידועות על פרוטוקול :WebSocket Denial of service o הקמת מספר גדול של חיבורים על מנת לפגוע בביצועי שרת הWebSocket. Lack of same origin policy o חקירת התנהגות של תוכנות צד-לקוח שלא נוהגים במדיניות same origin ומימוש התקפות Cross-site request forgery על תוכנות אלו. חקירה ומימוש של התקפות חדשות על פרוטוקול :WebSocket - Denial of service o חקירת התנהגויות מיוחדות של שרתים נפוצים שונים כנגד התקפות DoS שונות: מהי ההגבלה על כמות החיבורים? מהו הtimeout של חיבור מסוים? איזה מניפולציות ניתן לבצע כך שהתקפת DoS תהיה יעילה יותר ותחזוק החיבורים יקטן? - Lack of same origin policy o חקירת התנהגויות של שרתי HTTP כתגובה ליצירת קשר WebSocket שידוע לנו שאינו מוגן ע"י.same origin policy שהHeader WebSocket בדיקת התנהגות של שרת/לקוח כאשר נשלחת אליו הודעת o שלה עבר שינוי מינורי לא צפוי. o ביצוע UPGRADE לWebSocket באמצע HTTP session )ולא בתחילתו(..HTTPS session מתוך )SecuredWebSocket )ולא לWebSocket UPGRADE ביצוע o.websocket עם TCP בתוך אותו קשר HTTP שליחת הודעות o הסקת מסקנות כתוצאה מהניסויים וההתקפות שמימשנו. )1 )1 )2 )2 )4

11 11 כלים PyCharm סביבת עבודה בשפת Python בגרסא 2.7. השתמשנו בספרייה websocket-client שנמצאת בסביבת עבודה זו, על מנת להקים קשרי websocket עם שרתים ואף שינינו ספרייה זו בהתאם לצרכינו. Eclipse Java EE IDE Juno סביבת פיתוח לפרויקטים אינטרנטיים בשפת.Java השתמשנו בה כדי להקים את השרת. Wireshark כלי לניתוח פקטות שעוברות ברשת, עם אפשרות לסינון הודעות עם מאפיינים ספציפיים )למשל ממקור או בפרוטוקול מסויים(. השתמשנו בכלי זה על מנת לבחון את ההודעות שנשלחו או התקבלו על ידנו בזמן שעשינו ניסויים שונים. Apache Tomcat 7 שרת נפוץ בעל קוד פתוח שמממש צד שרת של פרוטוקול.Websocket בעזרת שרת זה בחנו התנהגויות שונות של שרת נפוץ אל מול התקפות שונות שמימשנו. Wamp + PHP Websocket server עוד שרת נפוץ שמממש צד שרת של פרוטוקול Websocket בו השתמשנו כדי לבחון התנהגויות שונות של שרתים כנגד התקפות שונות שמימשנו. Shodan מנוע חיפוש שמוצא מחשבים שונים באינטרנט )שרתים, נתבים וכו'( בהתאם לסינון מבוקש. השתמשנו בכלי זה על מנת למצוא שרתים שעובדים עם פרוטוקול Websocket ובעזרתם נוכל לבחון התנהגות של שרתים נפוצים אל מול התקפות שונות שמימשנו.

12 11 שלב 1: הקמת תשתית הקמת שרת מקומי בדקנו מס' שרתי Open source נפוצים בWindows : WAMP (Windows Apache MySql PHP) Apache Tomcat 7 Jetty היות והRFC של WebSocket משתנה כל הזמן, בחרנו לעבוד עם השרת Apache Tomcat 7 אשר מריץ את המימוש של הגירסה העדכנית ביותר. מעבר לכך, לאחר עבודה עם 2 השרתים, הדרך הכי נוחה להקים אתרים לצרכי בדיקות הייתה דרך Tomcat 7 בשפת,Java בה הAPI מלוטש כראוי. הקמת אפליקצית WebSocket ראשונית השתמשנו בדוגמת קוד שהגיעה יחד עם ה 7, Tomcat ובנינו אפליקציית Chat שעובדת מעל פרוטוקול.WebSocket לאחר הבניה, השתמשנו במימוש בסיסי זה והתאמנו אותו לצורך המחקר על התקפות.CSRF הקמת צד לקוח שאינו דפדפן מבין שפות התכנות בהן מימשו את הAPI python, WebSocket היא הנוחה ביותר לצרכינו כיוון שהיא גמישה, עשירה בספריות חיצוניות, ונוחה לכתיבה והרצה של תוכניות קצרות בשיטת.Q&D בחרנו בספריית websocket-client הכתובה בpython, המממשת באופן מינימלי את ה WebSocket API ואיפשרה לנו בצורה נוחה לשנות אותה בהתאם לצרכי המחקר. השתמשנו במימוש של ספרייה זו, ושינינו אותו לצורך מחקר על התקפות.DoS Debugging בחירת דפדפן בדקנו אילו דפדפנים תומכים בצורה מלאה בWebSockets, נפוצים ביותר ומספקים גם.Chrome, FireFox, IE10 ואלו הם:,Tools

13 12 שלב 2: מימוש התקפות ידועות Cross Site WebSocket Hijacking כיום, בכדי לקבל מידע מהשרת יש תחילה לשלוח Request השואל האם לשרת יש מידע חדש להביא. בפועל בקשות אלו נשלחות בצורת )XHR( XMLHttpRequest באמצעות סקריפט.JavaScript על מנת שבקשות אלו יהיו מזוהות עם המשתמש שגולש בדף ממנו נשלחה הבקשה לא יצטרך להזדהות מחדש כל פרטי האימות מוצמדות לREQUEST HTTP ע"י הדפדפן שמריץ את הסקריפט. אתר זדוני יכול לנצל יכולת זו ולבצע Request לאתר אחר אשר אליה יוצמדו פרטי האימות של וכך לקבל מידע פרטי. על מנת להתגבר על שליחת בקשות אלו, הדפדפנים אוכפים את הpolicy,same origin אשר קובעת שבקשות אלו יצליחו רק אם הם לאותו האתר )origin( כפי שצוין במבוא. כיוון שהקמת קשר WebSocket מתבצעת באמצעות הודעות,HTTP כל פרטי האימות cookies( וכדומה( נשלחים ע"י הדפדפן באותו אופן כפי שמתואר לעיל יחד עם הResponse.Handshake ]2,1[ כפי שכתוב ב 6455 :RFC This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication. בנוסף, בדיקות מראות ]1[ שדפדפנים עדכניים אינם אוכפים את same origin policy מסיבה כלשהיא, אף על פי ששדה הorigin אכן מופיע ב- header של הHandshake ]2[ )כפי שהראינו בהקדמה(. אנו נשתמש בשתי התכונות האלה של WebSocket ונתכנן תקיפה על אפליקצית WebSocket בסביבת העבודה שלנו. 1 התקפה תחילה ננצל את ה- policy lack of same origin ונתכנן תקיפה על אפליקציית הChat הקיימת שלנו, בה האתר הזדוני ערוץ מוסתר מאחורי הקלעים ודרכו יעביר מסרים מהצ'אט אל שרת זדוני. ההתקפה כוללת סקריפט js שנמצא בדף זדוני, אשר מתחבר אל אפליקציית הChat בצורה רגילה ובמקביל מחובר לאפליקציית Websocket שמעבירה את המידע המודלף הלאה. בעזרת שני החיבורים האלו, שניתנים ליצירה ללא בעיה כיוון שאין הגבלה על הorigin ואין צורך בזיהוי בעת התחברות לChat,

14 12 נוכל להזרים הודעות שנמצאות בצ'אט אל שרת זדוני. ההתקפה לא מועילה במיוחד כיוון שבכל מקרה התוקף היה יכול לגשת לצ'אט כרגיל, אלא נועדה רק כדי להראות יכולת. 2 התקפה כעת נתאר התקפת,CSRF או בשמה השני.CSWSH במערכת קיימת אפליקציית WebSocket המוגנת ע"י סיסמא אשר נשמרת בCookies לאחר ההתחברות הראשונית של המשתמש. הדף הזדוני: האתר המוסתר: האפליקצית WebSocket המוגנת: ws://secret.com/secret אפליקציית WebSocket הזדונית: ws://evil.com/rat כאשר משתמש גולש ומתחבר לאפליקציה המוגנת, נוצר עבורו cookie והוא נשמש בדפדפן. ברגע שהמשתמש גולש )בדרך זו או אחרת...( לאתר הזדוני, לאחר זמן מה, ברקע האתר ינסה ליצור עם האפליקציה המוגנת, וזו תקבל את פרטי המשתמש ולכן תסיים את הHandshake Websocket והחיבור יצליח. מאותו רגע, האפליקציה המוגנת תתחיל לשלוח את הפרטים הסודיים של המשתמש אל הדף הזדוני. במקביל, הדף הזדוני ייצור קשר WebSocket עם אפליקציה של התוקף אשר תקבל את המידע הסודי ותציג אותו לדף אחר הידוע רק לתוקף על קיומו. כך בעצם אנו מנצלים את תכונות WebSocket לצורך הדלפה של מידע רגיש לגורמים זדוניים. מבנה המערכת

15 14 מהלך התקיפה התוצאה מחשב המשתמש )victim( מחשב התוקף )attacker(

16 11 התקפות DoS היות ופרוטוקול WebSocket עובד מעל פרוטוקול,HTTP כדאי לבדוק אם התקפות מוצלחות על HTTP ינחלו הצלחה גם מול.WebSocket רוב המימושים של WebSocket מאפשרים מספר רב יותר של חיבורים מאשר בHTTP, לכן בעזרת WebSocket ניתן לנצל מספר רב יותר של משאבים אצל קורבן התקיפה. למשל, רוב הדפדפנים מגבילים את מספר החיבורים להיות בין 911 ל 2111 חיבורים, מלבד FireFox שמגביל ל 211 חיבורים ]1[. התקפה פשוטה בחרנו שרת מסוים וביצענו איתו מס' רב מאוד של Websocket Handshake מאותו המחשב בזמן קצר מאוד. סביבת הרצה: שהRFC אפליקציית צ'אט בWebSocket - שלה מומש ע"י החברה Cheyenne והAPI מומש ע"י Nenad Rakocevic הניסוי: התחברנו דרך שני מחשבים לצ'אט ודרך אחד מהם פתחנו מספר רב מאוד של חיבורים לצ'אט בעזרת סקריפט.python מרגע פתיחת החיבורים, לא ניתן היה לשלוח הודעות בצ'אט משני המחשבים, שניהם עברו למצב offline עד שלבסוף שניהם נותקו מהצ'אט והיה צורך להיכנס מחדש לצ'אט לאחר שעצרנו את הסקריפט שפותח חיבורים חדשים. התקפה דרך הדפדפן כתבנו סקריפט JavaScript שיוצר הרבה חיבורים לאותו השרת. ניתן להשתילו אצל משתמשים בעזרת XSS או Social Engineering וכך לבצע :Distributed Denial of Service כל משתמש שיריץ את הסקריפט ייצור הרבה חיבורים לשרת, כאלה שהדפדפן ידאג להחזיק פתוחים כל עוד המשתמש גולש בתוך הדף בו הסקריפט שלנו.

17 11 שלב 2: מימוש התקפות חדשות HTTP CSRF רעיון: באמצעות WebSocket כאשר יוצרים קשר,WebSocket תחילה שולחים בקשת HTTP GET "כמעט רגילה"! למעשה, היא מכילה את כל השדות של HTTP GET ובנוסף את השדות של,WebSocket כגון Connection: Upgrade )ראו רקע לדו"ח(. מה יעשו שרתי HTTP יקבלו את הבקשה הזו? ייזרקו אותה?..או שמא יתעלמו מהשדות המיותרים ויענו כרגיל? צפי: אנו צפינו שהשרתים אכן יענו כרגיל, והתשובות יגיעו לאחת המתודות של הClient OnError - או.OnClose בנוסף, נוכל לבצע בקשות לאתרים מתוך סקריפטים זדוניים שאינם נמצאים תחת אותו דומיין, וכך אם הResponse תגיע לאחת המתודות, נוכל להדליף את המידע כפי שראינו בהתקפות CSWSH קודמות. חקרנו את התנהגות שרתי HTTP וחיפשנו את התשובות לשאלות הללו. בדיקה 1: מתוך סקריפט JavaScript ניסינו להקים קשר websocket עם האתר.moodle.technion.ac.il תוצאות התוצאה הייתה שהשרת אכן החזיר את הדף המבוקש לדפדפן כפי שצפינו! אך כיוון שבהHeader של הResponse Handshake התקבל קוד 211 ולא קוד 111, אזי הHandshake לא הושלם, ולכן התקבלה שגיאה ונקראה הפונק' OnError עם השגיאה Handshake.Status 200

18 17 חקירת התוצאות: הן בChrome, בFireFox ו- IE10, OnError קיבלה את הEvent הבא: { } "cancelbubble":false,"returnvalue":true, "srcelement":{ "binarytype":"blob","extensions":"","protocol":"","bufferedamount":0,"readystate":0, "url":"ws://moodle.technion.ac.il/","url":"ws://moodle.technion.ac.il/" }, "defaultprevented":false,"timestamp": ,"cancelable":false,"bubbles":false,"eventphase":2, "currenttarget":{ "binarytype":"blob","extensions":"", "protocol":"","bufferedamount":0,"readystate":0, "url":"ws://moodle.technion.ac.il/","url":"ws://moodle.technion.ac.il/" }, "target":{ "binarytype":"blob","extensions":"", "protocol":"","bufferedamount":0, "readystate":0,"url":"ws://moodle.technion.ac.il/", "URL":"ws://moodle.technion.ac.il/" }, "type":"error" פרשנו אותו בעזרת JSON וקיבלנו שאלה כל הפרטים השמורים בו: כלומר התאכזבנו לגלות שהתשובה מהשרת אינה מגיעה בפועל לAPI WebSocket ולכן לא ניתן לקבל תשובה חזרה לסקריפט כדוגמת XHR בדרך זו. בדיקה 2: הרצנו פעם נוספת את הבדיקה הקודמת, אך כעת לפני ההרצה ביצענו login באתר,moodle וכך נשמר עבורינו.cookie בבדיקה זו אנו מוודאים האם אכן ניתן לקבל את הדף נחיתה המאובטח של.moodle תוצאות:

19 10 GET / HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: moodle.technion.ac.il Origin: Pragma: no-cache Cache-Control: no-cache Sec-WebSocket-Key: b2na6ls3oblxiwnxew1tdq== Sec-WebSocket-Version: 13 Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits, x-webkit-deflate-frame User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Cookie: TechAnamUser= ; MoodleSessiontechnion19=nfpcdulfucpilb61u6eechhub4; MOODLEID1_technion19=%2523%250B%25AA%25FB%25264%25DDr %25E6 HTTP/ OK Date: Tue, 25 Feb :15:10 GMT Server: Apache X-Powered-By: PHP/5.3.3 Expires: Mon, 20 Aug :23:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Content-Language: he Content-Script-Type: text/javascript Content-Style-Type: text/css X-Frame-Options: sameorigin Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 <!DOCTYPE html> <html dir="rtl" lang="he" xml:lang="he"> <head> <title>technion moodle</title> <link rel="shortcut icon" href=" /favicon" /> <meta name="description" content="moodle </a></li></ul></div></div><div class="coursebox clearfix odd"><div class="info"><h3 class="name"><a class="" href=" -</a></h3><div class="moreinfo"></div></div> <a class="" href=" כצפוי, התקבל ErrorEvent חסר תועלת כפי שהתקבל בבדיקה קודמת. אך אם נסתכל על התעבורה נוכל להבחין במספר דברים: :1 הCookie המתאים אכן נשלח יחד עם ה Handshake HTTP 200 OK.Request :2 השרת שולח בהנחה שהRequest הייתה GET רגילה. :2 וניתן לראות את הקורסים שיש לסטודנט הvictim ברשימת הקורסים בmoodle. ]מידע רגיש ביותר!..[

20 19 כל מה שנותר לעשות זה למצוא דרך לעקוף את המימוש של הAPI בדפדפן כך שיהיה ניתן לגשת לResponse. בדרך זו יהיה ניתן להדליף מידע רגיש בצורה מוסתרת מהמשתמש, ובלי להיות כפוף ל- same origin.http עבור CSRF מייצר חולשת WebSocket כלומר מימוש.policy השווינו תוצאות אלו להרצת אותן בדיקות עבור.XHR הבחנו שגם XHR נשלחו ע"י הדפדפן וקיבלו תגובת HTTP OK 200 מהשרת )אשר לאחר מכן נזרקה עקב )same origin policy אך לא הוצמדו.CSRF שאין בהן תועלת להתקפות כך ל- Request, cookies

21 21 התקפות DoS מורכבות נרצה לממש התקפה דומה לSlowLoris בWebSocket. כלומר, נרצה להחזיק חיבורים פתוחים כמה שיותר זמן תוך שימוש מינימלי במשאבים שלנו. לשם כך נרצה למצוא את הזמן המקסימלי שהשרת יהיה מוכן להשאיר את החיבור פתוח )timeout( בשני מקרים בין שתי הודעות שלמות ובין שתי הודעות שהן חלק מאותה הודעה.)Fragmentation( Non-Fragmentation timeout לשם מציאת הtimeout בין שתי הודעות שלמות של שרת כלשהו כתבנו סקריפט בpython שמבצע:.i=1 שלח לשרת הודעה שלמה Header + Data )התעלם מהודעות WebSocket שנשלחות חזרה(. i. אם החיבור נותק, החזר את a. b. אחרת, חכה i שניות..i = i*2 חזור ל מהלך הניסוי:

22 21 כלומר i הינו מרווח הזמן שנחכה בין שתי הודעות שנשלח והוא גדל בצורה אקספוננציאלית. כאשר נשלח הודעה ונקבל error כי החיבור נותק, נדע כי חיכינו יותר מדי זמן והשרת הפסיק את החיבור איתנו כתוצאה מtimeout. לכן נבחר את הערך של i שיימצא כאשר החיבור ינותק ונשתמש בו כמרווח הזמן בין שתי הודעות שלמות. Fragmentation timeout לשם מציאת הtimeout בין שתי הודעות מחולקות של שרת כלשהו כתבנו סקריפט בpython שמבצע:.j=1,i=1 שלח לשרת הודעה Data[0].Header + שלח לשרת הודעה Data[j] i. אם החיבור נותק, החזר את a. b. אחרת, חכה i שניות..j=j+1,i = i*2 חזור ל הערה: Data[j] יהיה הbyte הj מתוך הData שבהודעה המקורית. מהלך הניסוי:

23 22 כלומר, i הינו מרווח הזמן שנחכה בין שתי הודעות שנשלח והוא גדל בצורה אקספוננציאלית. כאשר נשלח הודעה ונקבל error כי החיבור נותק, נדע כי חיכינו יותר מדי זמן והשרת הפסיק את החיבור איתנו כתוצאה מtimeout. לכן נבחר את הערך של i שיימצא כאשר החיבור ינותק ונשתמש בו כמרווח הזמן בין שתי הודעות חלקיות. Server Name Local Apache Tomcat 7 Cox Enterprises ( ) Edra Group ( ) תוצאות שני הניסויים: Non-Fragmentation Timeout 1024 sec 256 sec 512 sec Fragmentation Timeout > 9 hours 0 sec 512 sec ניתוח התוצאות: נתוני השרת שלנו שהתקבלו הינם נתוני ברירת המחדל, ולכן סביר שיופיעו גם באינטרנט. שרת של החברה ) ( Cox Enterprises מונע פרגמנטציה של WebSocket מעל שכבת הTCP. לאחר מספר גדול של ניסויים עם פרגמנטציות שונות, כולן הראו את אותה התוצאה השרת למעשה מנתק את החיבור ברגע שהוא מזהה פרגמנטציה של.Websocket על מנת לוודא שהבעיתיות כאן קשורה לפרגמנטציה של Websocket שלחנו לשרת הודעות שגודלן גדול מהMTU של השרת מעל,Websocket כך ששכבת הIP הייתה חייבת לבצע פרגמנטציה סטנדרטית של מסגרות הTCP. ניסוי זה נחל הצלחה והשרת לא ניתק את הקשר, אלא קיבל את כל חלקי ההודעות והתנהג כרגיל. כלומר, כשהשרת הנ"ל מקבל הודעות שעברו פרגמנטיה של מסגרת הWebsocket בלבד, הוא מנתק את הקשר מיידית. מסקנה: מול שרת כזה עדיף לתקוף בעזרת DoS של הודעות שלמות ללא פרגמנטציה. ניתן לראות בשרת של Edra Group שהתקבל אותו timeout בשני הניסויים. ניתן להסיק מכך שכנראה יש הגדרה קולקטיבית לWebSockets או שפשוט זהו ה- timeout. TCP הערות: יש הרבה שרתים ששולחים הודעות עם מידע זבל, כמו,keep alive וזה יוצר עומס על התוקף )וגם על המותקף(. הניסוי שלנו כולל רק שרתים שאינם שולחים הודעות כאלו, ולכן ישנם מספר מועט של שרתים בניסוי. מתוך מעט השרתים שהתאימו לניסוי שלנו, לא היה אף שרת אחד שהצהיר על הסוג שלו בResponse,Handshake ולכן לא הצלחנו לסווג אותם לפי סוגי שרתים.

24 22 Handshake Header Header manipulation חקרנו את הכיוון של התחמקויות מIDS בעזרת שינוי כלשהו בHeader.Handshake לדעתנו IDSים מזהים תעבורת WebSocket בעזרת זיהוי הHandshake ובפרט השורה:.WebSocket מכיוון ששורה זו מיוחדת עבור לחיצת היד של,Upgrade: websocket בנוסף זוהי שורת חובה על מנת לבצע את המעבר לWebSocket ובנוסף היא אינה משתנה בין Handshake של אפליקציות שונות. כתוצאה מכך, שינינו את מימוש צד הלקוח שלנו כך שבRequest Get של הHandshake הוא ישלח מחרוזות שונות במקום השורה Upgrade: websocket כגון: Upgrade: websocket החסרת תווים..Upper-case הוספת תווי Upgrade: WEBSOCKET Websocket החסרת שם השדה. Upgrade websocket החסרת נקודתיים. Upgrade: - החסרת ערך השדה. ועוד מחרוזות עם שינויים כאלה ואחרים כדי למצוא מקרי קצה שלא טופלו בצד שרת של שרתים קיימים. התוצאות: קיבלנו שתי תגובות שונות - חלק מהשרתים אכן בדקו את המחרוזת שבשורה לעיל וניתקו את הקשר מיידית. חלק מהשרתים לא בדקו את השדות Upgrade, Connection אלא הסתמכו על השדה.Sec-Websocket-Key כלומר גם כששלחנו Get Request עם ערכים שונים מהצפוי, השרת התייחס להודעות אלה כRequest.Websocket Handshake אך כששינינו בנוסף גם את השדה Sec-Websocket-Key השרת ניתק את הקשר..1.2 Websocket Header חקרנו את הכיוון של שינוי הLen,Payload שמשמעותו היא גודל הPayload בהודעה, ורצינו לבדוק איך שרתים מגיבים כאשר אנו שולחים להם הודעה קצרה/ארוכה מערך השדה. אורך ההודעה < Len Payload כאשר ההודעה הייתה קצרה מערך השדה, האפליקציות חיכו עד לקבלת מס' הבתים הרשום ב-.Payload Len שליחת הודעות נוספות הצטרפו יחדיו למסגרת אחת, הכוללת את הheader של ההודעה הראשונה, ואת שאר ההודעות כולל הheader שלהם בתור ה- payload.

25 24 ניתן לנצל תכונה זאת של WebSocket כדי לבצע התקפת DoS זהה להתקפת דמוית SlowLoris כפי שהראנו לעיל. בעצם מקרה זה שקול לשיטת הפרגמנטציה שלנו, שכן אנחנו שולחים פחות מכמות הבתים שאנו מצהירים עליהם. אורך ההודעה > Len Payload כאשר ההודעה הייתה ארוכה מערך השדה, ההודעה הראשונה התקבלה בהצלחה והקשר זוהה כקשר,Websocket אך ההודעה שאחריה נכשלה וגרמה לסגירת הקשר, זאת מכיוון שרק כמות הבתים שנרשמה בהודעה הראשונה כערך אורך הPayload נחשבה כהודעה הראשונה והשאר גלשו לתחילת ההודעה הבאה וכתוצאה מכך שיבשו את הHeader של ההודעה השנייה. תיאור ויזואלי למשל שליחת הודעה באורך 1 עם ערך Len=4 - Payload המסגרת הראשונה מגיעה בצורה חלקית, אך מתקבלת בצד השני כמו שצריך )ראו הקלטות מצורפות(. המסגרת השניה כוללת גם את הבתים שגלשו מההודעה הקודמת, וגם את הבתים של ההודעה השניה ולכן מחוברת יחדיו להיות [ e4 c4]. c5 8a 2e ac 00 4f הבתים הראשונים שגלשו הופכים להיות הHeader Websocket של המסגרת השניה, והיא תתקבל בצד השני בהצלחה רק במקרה שהם מהווים Header תקין. ברוב המקרים זה לא קרה וקיבלנו מיד Websocket Connection close מהשרת.

26 21 מסקנות מסקנות נקודתיות מהניסויים Cross-Site Request Forgery כפי שניתן לראות מההתקפות שביצענו, ניתן להגן על אפליקציית WebSocket מפני התקפת CSRF ב 2 דרכים לפחות: crosssite בדיקת שדה ה- origin : דפדפנים שרוצים להגן על המשתמשים שלהם מפני התקפות צריכים לאכוף את מדיניות הorigin same גם עבור WebSocket בעזרת שדה הorigin שמופיע בRequest.Handshake הוספת מפתחות אקראיים: שרתים שרוצים לוודא שמשתמשים מתחברים לאפלקציות הWebSocket שלהם רק מתוך אתר מורשה יכולים להוסיף ל- Request Handshake מפתחות המיוצרים בצורה רנדומלית ובלתי ניתנת לזיוף עבור כל,Session ולאחר מכן לוודא אותם בצד השרת. כך שום אתר זדוני לא יצליח לקיים קשר WebSocket ישיר עם השרת. אימות/זיהוי של המשתמש בתוך קשר :Websocket במקום להסתמך על שיטות אימות נפוצות של,HTTP מומלץ לשרתים שמאוד רוצים להגן על אפלקציות הWebSocket שלהם לממש אימות באופן עצמאי מעל WebSocket לאחר סיום הHandshake Denial of Service.1.2 פרוטוקולים רבים חשופים להתקפות,DoS ו- WebSocket הינו פשוט עוד פרוטוקול אחד כזה שמתווסף לאוסף. ההבדל הוא, שכמות המשאבים הנצרכת בWebSocket הינה גדולה יותר מהרגיל, בגלל אופיו הduplexי ולכן יחסית קל יותר לממש התקפות.DoS ניתן להגן על אפליקציות WebSocket מפני התקפות DoS בכמה דרכים: להגביל את מס' החיבורים מתוך הדפדפן: כאמור, רוב הדפדפנים )מלבד )FireFox מתירים למעל 211 חיבורים בו זמנית, דבר המאפשר לאתר זדוני לגרום ליצירת חיבורים רבים לאותה אפליקצית,WebSocket וכך לגזול משאבים הן מהמשתמש והן מהשרת, כפי שראינו. להגביל את הtimeout בין הודעה להודעה: מפתחי אפליקציה צריכים להפעיל שיקול דעת ולמזער את הזמן המקסימלי שניתן לחכות להודעה בהתאם לשימוש באפליקציה. מצד אחד, קביעת זמן קטן מדיי יכולה לגרום לאיבוד הודעות וכך לפגיעה בשימושיות. מצד שני, קביעת זמן גדול מדיי יכולה לפתוח פתח להתקפות כפי שראינו.

27 21 Handshake manipulation רוב השרתים בודקים את השדות הHandshake בצורה מלאה ובהקפדה )מלבד רווחים ו Upper.Sec-Websocket-key אולם יש כאלה שבודקים רק חלק מהשדות ובפרט את השדה,)Case היות ומטרת שדה זה היא לוודא ששני הצדדים אכן מדברים מעל,Websocket כל מימוש חייב לבדוק את קיום ונכונות שדה זה, ובאמצעותו לזהות את הקשר שנוצר בתור.WebSocket בכל מקרה, גם אם ניתן לשנות את השדות Upgrade, Connection בRequest, השרת יחזיר בResponse את השורה Upgrade: websocket שמסגירה מיד כי מדובר בקשר.Websocket לכן כתוקף מצד הלקוח, לא נוכל להסתיר את סוג התעבורה. כיוון נוסף שחשבנו עליו בעקבות מסקנה מס' 2 הוא לבצע מניפולציות על ה Handshake,Response כלומר לשנות את מימוש לחיצת היד אצל השרת..1.2

28 27 מקורות [1] BlackHat Hacking Websocket by Shekyan & Toukharian: 12/Briefings/Shekyan/BH_US_12_Shekyan_Toukharian_Hacking_Websocket_Slides.pdf [2] The Definitive Guide to HTML5 WebSocket by Vanessa Wang,Frank Salim and Peter Moskovitz [3] php-websocket-chat-application-2.0: [4] creating websocket chat with jetty: [5] The tiny mighty Waldo: [6] Cross Site WebSocket Hijacking: [7] Slow Loris: [8] The WebSocket API: W3C Candidate Recommendation. [9] WebSocket Security Analysis by Jussi-Pekka Erkkilä, Aalto University School of Science