ភាពងាយរងគ្រោះក្នុងការកំណត់រចនាសម្ព័ន្ធ Nginx ជាមួយនឹងការកំណត់ប្លុកឈ្មោះក្លែងក្លាយមិនត្រឹមត្រូវ

ម៉ាស៊ីនមេមួយចំនួនដែលមាន nginx នៅតែងាយរងគ្រោះទៅនឹងបច្ចេកទេស Nginx Alias ​​Traversal ដែលត្រូវបានស្នើឡើងនៅក្នុងសន្និសីទ Blackhat ត្រឡប់មកវិញក្នុងឆ្នាំ 2018 និងអនុញ្ញាតឱ្យចូលប្រើឯកសារ និងថតឯកសារដែលមានទីតាំងនៅខាងក្រៅថត root ដែលបានបញ្ជាក់នៅក្នុងការណែនាំ "ឈ្មោះក្លែងក្លាយ" ។ បញ្ហាលេចឡើងតែនៅក្នុងការកំណត់ដែលមានការណែនាំ "ឈ្មោះក្លែងក្លាយ" ដែលដាក់នៅខាងក្នុងប្លុក "ទីតាំង" ប៉ារ៉ាម៉ែត្រដែលមិនបញ្ចប់ដោយតួអក្សរ "/" ខណៈពេលដែល "ឈ្មោះក្លែងក្លាយ" បញ្ចប់ដោយ "/" ។

ខ្លឹមសារនៃបញ្ហាគឺថាឯកសារសម្រាប់ប្លុកដែលមានការណែនាំឈ្មោះក្លែងក្លាយត្រូវបានផ្តល់ឱ្យដោយភ្ជាប់ផ្លូវដែលបានស្នើសុំ បន្ទាប់ពីផ្គូផ្គងវាជាមួយរបាំងពីការណែនាំអំពីទីតាំង និងកាត់ផ្នែកនៃផ្លូវដែលបានបញ្ជាក់នៅក្នុងរបាំងនេះ។ សម្រាប់ឧទាហរណ៍នៃការកំណត់រចនាសម្ព័ន្ធដែលងាយរងគ្រោះដែលបានបង្ហាញខាងលើ អ្នកវាយប្រហារអាចស្នើសុំឯកសារ "/img../test.txt" ហើយសំណើនេះនឹងផ្គូផ្គងរបាំងដែលបានបញ្ជាក់នៅក្នុងទីតាំង "/img" បន្ទាប់មកកន្ទុយដែលនៅសល់ "../ test.txt" នឹងត្រូវបានភ្ជាប់ទៅផ្លូវពីការណែនាំឈ្មោះក្លែងក្លាយ "/var/images/" ហើយជាលទ្ធផល ឯកសារ "/var/images/../test.txt" នឹងត្រូវបានស្នើសុំ។ ដូច្នេះ អ្នកវាយប្រហារអាចចូលប្រើឯកសារណាមួយនៅក្នុងថត "/var" ហើយមិនត្រឹមតែឯកសារនៅក្នុង "/var/images/" ឧទាហរណ៍ ដើម្បីទាញយកកំណត់ហេតុ nginx អ្នកអាចផ្ញើសំណើ "/img../log/ nginx/access.log"។

នៅក្នុងការកំណត់រចនាសម្ព័ន្ធដែលតម្លៃនៃការណែនាំឈ្មោះក្លែងក្លាយមិនបញ្ចប់ដោយតួអក្សរ "/" (ឧទាហរណ៍ "alias /var/images;") អ្នកវាយប្រហារមិនអាចប្តូរទៅថតមេបានទេប៉ុន្តែអាចស្នើសុំថតផ្សេងទៀតនៅក្នុង /var ឈ្មោះដែលចាប់ផ្តើមដោយបញ្ជាក់នៅក្នុងការកំណត់។ ឧទាហរណ៍ ដោយស្នើសុំ "/img.old/test.txt" អ្នកអាចចូលទៅកាន់ថត "var/images.old/test.txt" ។

ការវិភាគនៃឃ្លាំងនៅលើ GitHub បានបង្ហាញថាកំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធ nginx ដែលនាំឱ្យមានបញ្ហានៅតែត្រូវបានរកឃើញនៅក្នុងគម្រោងពិត។ ឧទាហរណ៍ វត្តមាននៃបញ្ហាត្រូវបានកំណត់នៅក្នុងផ្នែកខាងក្រោយនៃកម្មវិធីគ្រប់គ្រងពាក្យសម្ងាត់ Bitwarden ហើយអាចត្រូវបានប្រើដើម្បីចូលប្រើឯកសារទាំងអស់នៅក្នុងថត /etc/bitwarden (សំណើសម្រាប់ /ឯកសារភ្ជាប់ត្រូវបានចេញមកពី /etc/bitwarden/attachments/), រួមទាំងមូលដ្ឋានទិន្នន័យដែលបានរក្សាទុកនៅទីនោះជាមួយនឹងពាក្យសម្ងាត់ “vault. db” វិញ្ញាបនបត្រ និងកំណត់ហេតុ ដែលវាគ្រប់គ្រាន់ក្នុងការផ្ញើសំណើ “/attachments../vault.db”, “/attachments../identity.pfx”, “/attachments ../logs/api.log” ។ល។

វិធីសាស្ត្រនេះក៏ដំណើរការជាមួយ Google HPC Toolkit ដែលសំណើ /static ត្រូវបានបញ្ជូនបន្តទៅកាន់ថត "../hpc-toolkit/community/front-end/website/static/" ។ ដើម្បីទទួលបានមូលដ្ឋានទិន្នន័យដែលមានសោឯកជន និងព័ត៌មានសម្ងាត់ អ្នកវាយប្រហារអាចផ្ញើសំណួរ "/static../.secret_key" និង "/static../db.sqlite3" ។

ប្រភព: opennet.ru