चुकीच्या उर्फ ​​ब्लॉक सेटिंग्जसह Nginx कॉन्फिगरेशन भेद्यता

काही Nginx सर्व्हर Nginx उर्फ ​​ट्रॅव्हर्सल तंत्रासाठी असुरक्षित राहतात, जे 2018 मध्ये ब्लॅकहॅट कॉन्फरन्समध्ये प्रस्तावित केले गेले होते आणि "उर्फ" निर्देशामध्ये निर्दिष्ट केलेल्या रूट निर्देशिकेच्या बाहेर असलेल्या फायली आणि निर्देशिकांमध्ये प्रवेश करण्यास अनुमती देते. समस्या फक्त "स्थान" ब्लॉकमध्ये ठेवलेल्या "उर्फ" निर्देशासह कॉन्फिगरेशनमध्ये दिसते ज्याचे पॅरामीटर "/" वर्णाने संपत नाही, तर "उर्फ" "/" ने समाप्त होते.

समस्येचे सार हे आहे की उपनाम निर्देशासह ब्लॉक्ससाठी फायली विनंती केलेला मार्ग संलग्न करून, स्थान निर्देशातील मुखवटाशी तुलना केल्यानंतर आणि या मास्कमध्ये निर्दिष्ट केलेल्या मार्गाचा भाग कापून दिल्या जातात. वर दर्शविलेल्या असुरक्षित कॉन्फिगरेशनच्या उदाहरणासाठी, आक्रमणकर्ता "/img../test.txt" फाइलची विनंती करू शकतो आणि ही विनंती स्थानामध्ये निर्दिष्ट केलेल्या "/img" मास्क अंतर्गत येईल, त्यानंतर उर्वरित शेपटी ".. /test.txt" उपनाव निर्देश "/var/images/" मधील मार्गाशी संलग्न केले जाईल आणि शेवटी "/var/images/../test.txt" फाइलची विनंती करेल. अशा प्रकारे, आक्रमणकर्ते “/var” निर्देशिकेतील कोणत्याही फायलींमध्ये प्रवेश करू शकतात, आणि फक्त “/var/images/” मधील फायलीच नाही, उदाहरणार्थ, nginx लॉग डाउनलोड करण्यासाठी, तुम्ही विनंती पाठवू शकता “/img../log/ nginx/ access.log ".

ज्या कॉन्फिगरेशनमध्ये उर्फ ​​निर्देशाचे मूल्य "/" वर्णाने समाप्त होत नाही (उदाहरणार्थ, "उर्फ /var/images;"), आक्रमणकर्ता मूळ निर्देशिकेत बदलू शकत नाही, परंतु /var मध्ये दुसर्‍या निर्देशिकेची विनंती करू शकतो. ज्याचे नाव कॉन्फिगरेशनमध्ये निर्दिष्ट केलेल्या समान नावाने सुरू होते. उदाहरणार्थ, "/img.old/test.txt" ची विनंती करून तुम्ही "var/images.old/test.txt" निर्देशिकेत प्रवेश करू शकता.

GitHub वरील रेपॉजिटरीजच्या विश्लेषणात असे दिसून आले आहे की nginx कॉन्फिगरेशनमधील त्रुटी ज्यामुळे समस्या उद्भवतात त्या अजूनही वास्तविक प्रकल्पांमध्ये आढळतात. उदाहरणार्थ, बिटवर्डन पासवर्ड मॅनेजरच्या बॅकएंडमध्ये समस्या ओळखली गेली आणि ती /etc/bitwarden निर्देशिकेतील सर्व फायलींमध्ये प्रवेश करण्यासाठी वापरली जाऊ शकते (/etc/bitwarden/attachments/ वरून / संलग्नक विनंत्या जारी केल्या गेल्या होत्या), "vault" सह. . db", प्रमाणपत्र आणि लॉग, जे प्राप्त करण्यासाठी विनंत्या पाठवणे पुरेसे होते "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log ", इ. पी.

या पद्धतीने Google HPC टूलकिटसह देखील कार्य केले, ज्याने /static विनंत्या "../hpc-toolkit/community/front-end/website/static/" निर्देशिकेवर पुनर्निर्देशित केल्या. खाजगी की आणि क्रेडेन्शियलसह डेटाबेस प्राप्त करण्यासाठी, आक्रमणकर्ता “/static../.secret_key” आणि “/static../db.sqlite3” विनंत्या पाठवू शकतो.

स्त्रोत: opennet.ru