Serangan ing sistem ngarep-mburi-mburi-mburi sing ngidini kita nggawe panjalukan pihak katelu

Dicethakaké rincian serangan anyar ing situs sing nggunakake model ngarep-mburi-mburi, kayata sing mlaku liwat jaringan pangiriman isi, load balancers utawa proxy. Serangan kasebut ngidini, kanthi ngirim panjalukan tartamtu, kanggo nggabung menyang isi panjalukan liyane sing diproses ing benang sing padha ing antarane frontend lan backend. Cara sing diusulake wis kasil digunakake kanggo ngatur serangan sing bisa nyegat paramèter otentikasi pangguna layanan PayPal, sing mbayar peneliti babagan 40 ewu dolar minangka bagéan saka program kanggo ngandhani babagan anané kerentanan sing ora ditambal. Serangan kasebut uga ditrapake kanggo situs sing nggunakake jaringan pangiriman konten Akamai.

Inti masalah yaiku frontends lan backends asring nyedhiyakake tingkat dhukungan sing beda kanggo protokol HTTP, nanging ing wektu sing padha, panjaluk saka pangguna sing beda menyang saluran umum. Kanggo nyambungake panjalukan panampa frontend lan panjalukan pangolahan backend, sambungan TCP sing wis suwe digawe, liwat panjaluk pangguna sing ditularake, ditularake ing sadawane rantai siji-sijine, dipisahake kanthi protokol HTTP. Kanggo misahake panjalukan, header "Content-Length" (nemtokake ukuran total data ing panyuwunan) lan "Transfer-Encoding: chunked"(ngidini sampeyan nransfer data ing bagean, nemtokake blok kanthi ukuran sing beda ing format "{ukuran}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Masalah muncul yen frontend mung ndhukung "Konten-Length" nanging ora nggatekake "Transfer-Encoding: chunked" (contone, Akamai CDN nindakake iki) utawa kosok balene. Yen Transfer-Encoding: chunked didhukung ing loro-lorone, fitur implementasi parser header HTTP bisa digunakake kanggo serangan (contone, nalika mburi ngarep ora nggatekake garis kaya "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked ”, “Transfer-Encoding” :[tab]chunked”, "X: X[\n]Transfer-Encoding: chunked", "Transfer-encoding[\n]: chunked" or "Transfer-encoding : chunked", lan backend kasil ngolah mau).

Ing kasus iki, panyerang bisa ngirim panjalukan sing ngemot header "Length-Konten" lan "Transfer-Encoding: chunked", nanging ukuran ing "Length-Konten" ora cocog karo ukuran rantai sing dipotong, sing luwih cilik tinimbang nilai nyata. Yen frontend ngolah lan nerusake panjalukan miturut "Konten-Length" lan backend ngenteni pemblokiran rampung adhedhasar "Transfer-Encoding: chunked", banjur pungkasan data adhedhasar "Transfer-Encoding: chunked" bakal ditemtokake sadurungé lan buntut isih saka panjalukan panyerang bakal ing wiwitan panjalukan sabanjuré, i.e. panyerang bakal bisa kanggo masang data kasepakatan kanggo wiwitan panjalukan wong liya ditularaké sabanjuré.

Serangan ing sistem ngarep-mburi-mburi-mburi sing ngidini kita nggawe panjalukan pihak katelu

Kanggo nemtokake masalah ing kombinasi frontend-backend sing digunakake, sampeyan bisa ngirim panjalukan kaya iki liwat frontend:

POST / babagan HTTP / 1.1
Host: example.com
Transfer-Encoding: chunked
Panjang Konten: 4

1
Z
Q

Masalah kasebut ana yen backend ora langsung ngolah panjaluk kasebut lan ngenteni tekane blok wates nol pungkasan saka data chunked. Kanggo mriksa luwih lengkap disiapake sarana khusus sing uga nyoba cara bisa kanggo ndhelikake "Transfer-Encoding: chunked" header saka frontend.

Nindakake serangan nyata gumantung marang kemampuan situs sing diserang, contone, nalika nyerang aplikasi web Trello, sampeyan bisa ngganti wiwitan panjalukan (data pengganti kaya "PUT / 1 / anggota / 1234 ... x = x & csrf = 1234&username=testzzz&bio=cake”) lan ngirim pesen kalebu panjalukan asli pangguna pihak katelu lan Cookie otentikasi sing ditemtokake ing. Kanggo serangan ing saas-app.com, ternyata bisa ngganti kode JavaScript ing respon kanthi ngganti salah sawijining parameter panyuwunan. Kanggo serangan ing redhat.com, panangan internal digunakake kanggo ngarahake menyang situs web penyerang (panyuwunan formulir "POST /search?dest=../assets/idx?redir=//[email dilindhungi]/ HTTP / 1.1 ").

Nggunakake metode kanggo jaringan pangiriman konten, sampeyan mung bisa ngganti situs sing dijaluk kanthi ngganti header "Host:". Serangan kasebut uga bisa digunakake kanggo ngracuni isi sistem caching konten lan ngekstrak data rahasia sing di-cache. Puncak saka metode kasebut yaiku organisasi serangan ing PayPal, sing ndadekake bisa nyegat sandhi sing dikirim dening pangguna sajrone otentikasi (panyuwunan iframe diowahi kanggo nglakokake JavaScript ing konteks kaca paypal.com/us/gifts, kanggo sing CSP (Content Security Policy) ora ditrapake).

Apike, ing 2005 ana disaranake technique spoofing panjalukan ateges padha sing ngijini sampeyan kanggo spoof data ing proxy caching (Tomcat, cumi, mod_proxy) utawa bypass pamblokiran firewall kanthi nemtokake sawetara panjalukan "GET" utawa "POST" ing siji sesi HTTP.

Source: opennet.ru

Add a comment