برخی از سرورهای دارای nginx در برابر تکنیک Nginx Alias Traversal که در کنفرانس Blackhat در سال 2018 پیشنهاد شد آسیبپذیر هستند و امکان دسترسی به فایلها و دایرکتوریهای واقع در خارج از دایرکتوری ریشه مشخص شده در دستورالعمل "نام مستعار" را فراهم میکند. مشکل فقط در پیکربندی هایی ظاهر می شود که یک دستورالعمل "نام مستعار" در داخل بلوک "مکان" قرار داده شده است، که پارامتر آن با کاراکتر "/" ختم نمی شود، در حالی که "نام مستعار" با "/" خاتمه می یابد.
ماهیت مشکل این است که فایلهای بلوکهای دارای دستور مستعار با پیوست کردن مسیر درخواستی، پس از تطبیق آن با ماسک از دستورالعمل مکان و برش بخشی از مسیر مشخص شده در این ماسک، داده میشوند. برای مثال یک پیکربندی آسیبپذیر که در بالا نشان داده شده است، یک مهاجم میتواند فایل «/img../test.txt» را درخواست کند و این درخواست با ماسک مشخصشده در مکان «/img» مطابقت دارد، پس از آن، دم باقیمانده «../ test.txt به مسیری از دستور مستعار "/var/images/" پیوست می شود و در نتیجه فایل "/var/images/../test.txt" درخواست می شود. بنابراین، مهاجمان می توانند به هر فایلی در دایرکتوری "/var" دسترسی داشته باشند، و نه فقط فایل های موجود در "/var/images/"، برای مثال، برای دانلود nginx log، می توانید درخواست "/img../log/ را ارسال کنید. nginx/ access.log".
در پیکربندی هایی که مقدار دستور مستعار به کاراکتر "/" ختم نمی شود (به عنوان مثال، "نام مستعار /var/images;")، مهاجم نمی تواند به دایرکتوری والد تغییر کند، اما می تواند دایرکتوری دیگری را در /var درخواست کند. که نام آن با مشخص شده در پیکربندی شروع می شود. برای مثال، با درخواست "/img.old/test.txt" می توانید به دایرکتوری "var/images.old/test.txt" دسترسی داشته باشید.
تجزیه و تحلیل مخازن در GitHub نشان داد که خطاهایی در پیکربندی nginx که منجر به این مشکل می شود هنوز در پروژه های واقعی یافت می شود. به عنوان مثال، وجود یک مشکل در بکاند مدیریت رمز عبور Bitwarden شناسایی شد و میتوان از آن برای دسترسی به همه فایلهای موجود در فهرست /etc/bitwarden استفاده کرد (درخواستهای /attachments از /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