Nginx კონფიგურაციის დაუცველობა არასწორი ალიასის ბლოკის პარამეტრებით

ზოგიერთი სერვერი nginx-ით დაუცველი რჩება Nginx Alias ​​​​Traversal ტექნიკის მიმართ, რომელიც შემოთავაზებული იქნა Blackhat კონფერენციაზე ჯერ კიდევ 2018 წელს და საშუალებას აძლევს წვდომას ფაილებსა და დირექტორიაში, რომელიც მდებარეობს "alias" დირექტივაში მითითებულ root დირექტორიას გარეთ. პრობლემა ჩნდება მხოლოდ კონფიგურაციებში, სადაც განთავსებულია „ლოკაციის“ ბლოკში განთავსებული „ალიას“ დირექტივა, რომლის პარამეტრი არ მთავრდება „/“ სიმბოლოთი, ხოლო „ალიას“ მთავრდება „/-ით“.

პრობლემის არსი იმაში მდგომარეობს, რომ ალიას დირექტივის მქონე ბლოკების ფაილები მოცემულია მოთხოვნილი ბილიკის მიმაგრებით, მდებარეობის დირექტივის ნიღბთან დაკავშირების შემდეგ და ამ ნიღბში მითითებული ბილიკის ნაწილის ამოკვეთის შემდეგ. ზემოთ ნაჩვენები დაუცველი კონფიგურაციის მაგალითისთვის, თავდამსხმელს შეუძლია მოითხოვოს ფაილი "/img../test.txt" და ეს მოთხოვნა დაემთხვევა "/img"-ში მითითებულ ნიღბს, რის შემდეგაც დარჩენილი კუდი "../test.txt" დაერთვება გზას მეტსახელის დირექტივიდან "/var/images/" და, როგორც შედეგი, იქნება ტესტირება. ამრიგად, თავდამსხმელებს შეუძლიათ წვდომა ნებისმიერ ფაილზე "/var" დირექტორიაში და არა მხოლოდ ფაილებში "/var/images/", მაგალითად, nginx log-ის ჩამოსატვირთად შეგიძლიათ გაგზავნოთ მოთხოვნა "/img../log/nginx/access.log".

კონფიგურაციებში, რომლებშიც alias-ის დირექტივის მნიშვნელობა არ მთავრდება "/" სიმბოლოთი (მაგალითად, "alias /var/images;"), თავდამსხმელს არ შეუძლია შეცვალოს მშობელი დირექტორია, მაგრამ შეუძლია მოითხოვოს სხვა დირექტორია /var-ში, რომლის სახელი იწყება კონფიგურაციაში მითითებულის მიხედვით. მაგალითად, "/img.old/test.txt"-ის მოთხოვნით შეგიძლიათ შეხვიდეთ დირექტორიაში "var/images.old/test.txt".

GitHub-ის საცავების ანალიზმა აჩვენა, რომ შეცდომები nginx-ის კონფიგურაციაში, რომლებიც პრობლემამდე მიგვიყვანს, კვლავ გვხვდება რეალურ პროექტებში. მაგალითად, პრობლემის არსებობა დაფიქსირდა Bitwarden პაროლის მენეჯერის უკანა ნაწილში და შეიძლება გამოყენებულ იქნას ყველა ფაილზე წვდომისათვის /etc/bitwarden დირექტორიაში (/tachments-ის მოთხოვნები გაიცა /etc/bitwarden/attachments/-დან), მათ შორის მონაცემთა ბაზაში შენახული პაროლებით “vault.db”, სერთიფიკატი და ჟურნალები გაგზავნა, რისთვისაც საკმარისი იყო ach requests./attult. ./identity.pfx", "/atta chments../logs/api.log" და ა.შ.

მეთოდი ასევე მუშაობდა Google HPC Toolkit-თან, სადაც /static მოთხოვნები გადამისამართებული იყო "../hpc-toolkit/community/front-end/website/static/" დირექტორიაში. მონაცემთა ბაზის მისაღებად პირადი გასაღებით და რწმუნებათა სიგელებით, თავდამსხმელს შეეძლო გამოაგზავნოს მოთხოვნები "/static../.secret_key" და "/static../db.sqlite3".

წყარო: opennet.ru