Atako al antaŭ-finaj-malantaŭaj sistemoj, kiu ebligas al ni kojni en triaj petoj

Rivelita detaloj de nova atako al retejoj, kiuj uzas modelon de antaŭa finaĵo, kiel tiuj, kiuj trairas enhavajn liverajn retojn, ŝarĝbalancilojn aŭ prokurojn. La atako permesas, sendante iujn petojn, kojni en la enhavon de aliaj petoj procesitaj en la sama fadeno inter la fasado kaj backend. La proponita metodo estis sukcese uzata por organizi atakon, kiu ebligis interkapti la aŭtentikajn parametrojn de uzantoj de la PayPal-servo, kiu pagis esploristojn ĉirkaŭ 40 mil dolarojn kiel parto de programo por informi pri la ĉeesto de neflakitaj vundeblecoj. La atako ankaŭ aplikeblas al retejoj uzantaj la enhavan liveran reton de Akamai.

La kerno de la problemo estas, ke fasadoj kaj backends ofte provizas malsamajn nivelojn de subteno por la HTTP-protokolo, sed samtempe enkapsuligas petojn de malsamaj uzantoj en komunan kanalon. Por ligi la interfacajn ricevajn petojn kaj la backend-pretigajn petojn, estas establita longdaŭra TCP-konekto, per kiu uzantpetoj estas transdonitaj, transdonitaj laŭ la ĉeno unu post alia, apartigitaj per la HTTP-protokolo. Por apartigi petojn, la kaplinioj "Enhavo-Daŭro" (determinas la totalan grandecon de la datumoj en la peto) kaj "Translokigo-Kodigo: disigita"(permesas al vi transdoni datumojn en partoj, specifante blokojn de malsamaj grandecoj en la formato "{grandeco}\r\n{bloko}\r\n{grandeco}\r\n{bloko}\r\n0").

La problemo ekestas se la fasado nur subtenas "Enhavo-longo" sed ignoras "Transigo-Kodigado: disigita" (ekzemple, Akamai CDN faris tion) aŭ inverse. Se Transfer-Encoding: chunked estas subtenata ambaŭflanke, la efektivigtrajtoj de HTTP-kapa analizilo povas esti uzataj por atako (ekzemple, kiam la fronto ignoras liniojn kiel "Transfer-Kodigado: xchunked", "Translokigo-kodado: chunked". ”, “Translokigo-kodigo :[langeto]ŝranĉita", "X: X[\n]Translokigo-kodigo: disigita", "Translokigo-kodigo[\n]: disigita" aŭ "Translokigo-kodado: disigita", kaj la backend sukcese prilaboras ilin).

En ĉi tiu kazo, atakanto povas sendi peton, kiu enhavas kaj la titolojn "Content-Length" kaj "Transfer-Encoding: chunked", sed la grandeco en "Content-Length" ne korespondas al la grandeco de la chunked ĉeno, kiu estas pli malgranda ol la reala valoro. Se la fasado procesas kaj plusendas la peton laŭ "Content-Length" kaj la backend atendas ke la bloko kompletiĝos surbaze de "Transfer-Kodigo: disigita", tiam la fino de la datumoj bazitaj sur "Translokigo-Kodigo: disigita" estos. esti determinita pli frue kaj la restanta vosto de la peto la atakanto estos komence de la sekva peto, t.e. la atakanto povos alkroĉi arbitrajn datumojn al la komenco de la peto de iu alia transdonita poste.

Atako al antaŭ-finaj-malantaŭaj sistemoj, kiu ebligas al ni kojni en triaj petoj

Por determini la problemon en la kombinaĵo frontend-backend, kiun vi uzas, vi povas sendi peton kiel ĉi tion per la fasado:

POST /pri HTTP/1.1
Gastiganto: example.com
Translokigo-Kodigo: disigita
Longa enhavo: 4

1
Z
Q

La problemo ĉeestas se la backend ne tuj prilaboras la peton kaj atendas la alvenon de la fina nul-lima bloko de pecetaj datumoj. Por pli kompleta kontrolo preparita speciala ilo, kiu ankaŭ testas eblajn metodojn por kaŝi la kaplinion "Transferkodigo: disigita" de la fasado.

Fari veran atakon dependas de la kapabloj de la atakita retejo, ekzemple, kiam oni atakas la TTT-aplikaĵon Trello, oni povas anstataŭigi la komencon de la peto (anstataŭigi datumojn kiel "PUT /1/members/1234... x=x&csrf). =1234&username=testzzz&bio=cake”) kaj sendu mesaĝon inkluzive de la originala peto de tria uzanto kaj la aŭtentikiga Kuketo specifita en ĝi. Por atako ĉe saas-app.com, montriĝis eble anstataŭigi JavaScript-kodon en la respondo anstataŭigante ĝin en unu el la petaj parametroj. Por la atako sur redhat.com, interna prizorganto estis uzata por redirekti al la retejo de la atakanto (peto de la formo "POST /search?dest=../assets/idx?redir=//[retpoŝte protektita]/ HTTP/1.1").

Uzante la metodon por enhav-liveraj retoj ebligis simple anstataŭigi la petitan retejon anstataŭigante la kaplinion "Gastiganto:". La atako ankaŭ povas esti uzata por veneni la enhavon de enhavaj kaŝmemorsistemoj kaj ĉerpi konservitajn konfidencajn datumojn. La pinto de la metodo estis la organizo de atako kontraŭ PayPal, kiu ebligis kapti pasvortojn senditajn de uzantoj dum aŭtentigo (la iframe-peto estis modifita por ekzekuti JavaScript en la kunteksto de la paĝo paypal.com/us/gifts, por kiu CSP (Politiko pri Sekureco de Enhavo) ne estis aplikata).

Interese, en 2005 ekzistis proponita esence simila peta falsadotekniko, kiu ebligas al vi falsigi datumojn en kaŝmemorprokuriloj (Tomcat, squid, mod_proxy) aŭ preteriri fajroŝirmilon per specifado de pluraj "GET" aŭ "POST" petoj ene de unu HTTP-sesio.

fonto: opennet.ru

Aldoni komenton