OpenSSH-ისა და musl libc-ის ხარვეზები Alpine Linux-სა და სხვა დისტრიბუციებში შესვლის საშუალებას იძლევა

ინტერნეტი ჯერ კიდევ PHP-ის ძრავში აღმოჩენილი ხარვეზისა და ბოლო კვირებში გამოვლენილი სხვა უსაფრთხოების პრობლემების გამო შოკშია, მაგრამ ეს ყველაფერი არ არის. დღევანდელი ამბავი განსაკუთრებით საყურადღებოა: OpenSSH-ისა და musl libc-ის ერთობლივი ხარვეზის წყალობით, Alpine-ში, OpenWRT-სა და Linux-ის სხვა დისტრიბუციებში პაროლის გარეშე შესვლაა შესაძლებელი. პაროლის მოთხოვნისას საკმარისია 256 სიმბოლოზე მეტი ნებისმიერი ტექსტის შეყვანა და SSH-ით სისტემაში შეხვალთ.

ეს მუშაობს იმ შემთხვევაში, თუ სისტემურ მომხმარებლებს ცარიელი პაროლი აქვთ დაყენებული. რამდენიმე დისტრიბუციაში ეს ნაგულისხმევი პარამეტრია. ხარვეზი გვხვდება Buildroot-ში, Yocto-სა და Void Linux-ში, თუმცა ის აუცილებლად ჩართული არ არის. OpenWRT ავთენტიფიკაციისთვის ნაგულისხმევად Dropbear-ს იყენებს, მაგრამ მომხმარებლებს შეუძლიათ მის ნაცვლად OpenSSH დააყენონ.

ყველაზე დიდი შეშფოთების მიზეზი Alpine-ია. ის, სავარაუდოდ, მილიონობით ინსტალაციის ნაგულისხმევი არჩევანია. მათ შორისაა Docker-ის, Kubernetes-ისა და Proxmox-ის კონტეინერები და მათზე დამოკიდებული უამრავი სისტემა, სერვერები, ღრუბლოვანი ვირტუალური მანქანები და ჩაშენებული მოწყობილობები. Alpine-ს საჭირო პირობები უკვე დაყენებული აქვს და პაროლით ავთენტიფიკაცია ნაგულისხმევად ჩართულია. ამიტომ სისტემის დაუყოვნებლივ განახლებაა საჭირო.

ზოგადად, ხარვეზის გამოსაყენებლად საჭიროა OpenSSH, musl, პაროლით ავთენტიფიკაციის ჩართვა, PAM-ის გამოუყენებლობა და სულ მცირე ერთი მომხმარებელი დაყენებული პაროლით, რომელიც SHA-512/256 ჰეშს იყენებს. პროექტის უსაფრთხოების შეტყობინების თანახმად, სისტემები დაუყოვნებლივ განაახლეთ. მანამდე ყველაზე მარტივი დაცვა OpenSSH-ის კონფიგურაციის ფაილში „PasswordAuthentication“ პარამეტრის „no“-ზე დაყენება და სერვისის ხელახლა გაშვებაა.

პრაქტიკაში Alpine-ისა და მსგავსი სისტემების უმრავლესობა ინტერნეტიდან მიუწვდომელია. თუმცა, ქსელში მყოფ ნებისმიერ თავდამსხმელს შეუძლია სისტემაში შესვლა, მათ შორის კორპორაციულ ქსელებში, სახლის ლაბორატორიებში, ღრუბლოვან ქსელებსა და VPN-ებში. თავდამსხმელს მხოლოდ ერთი მოქმედი მომხმარებლის ანგარიში სჭირდება. საკმარისად დიდ კორპორაციულ გარემოში ასეთი ანგარიშის მოპოვება რთული არ არის, რის შემდეგაც თავდამსხმელი ქსელში აღმოჩნდება. ხარვეზის აღმოჩენა და შემოწმებაც ძალიან მარტივია.

OpenSSH-მა უკვე გამოაქვეყნა შესწორება და უსაფრთხოების შეტყობინება. იგივე გააკეთა musl-ის ავტორმა, რიჩ ფელკერმა. ორივე მხარე, როგორც ჩანს, მეორეს ადანაშაულებს, თუმცა გარედან თუ შევხედავთ, პასუხისმგებლობა ორივეს ეკისრება.

თუ ოდესმე /etc/passwd ან /etc/shadow ფაილები გინახავთ, შესაძლოა, პაროლის ჰეშის ნაცვლად ერთი ვარსკვლავი შეგემჩნიათ იმ ანგარიშებთან, რომლებსაც პაროლი არ აქვთ. ეს ნიშნავს, რომ „პაროლი არ უნდა მუშაობდეს“. SSHhole-ის ვებსაიტზე ყველა დეტალია მოცემული. პრობლემა ორ რამეს უკავშირდება: musl-ის crypt() ფუნქცია შეცდომის შემთხვევაში null-ის ნაცვლად „*“-ს აბრუნებს, ჩვეულებრივი წესის საწინააღმდეგოდ. შემდეგ კი OpenSSH ამ მნიშვნელობას პაროლის ჰეშთან შესადარებლად იყენებს, თუმცა ასე არ უნდა იქცეოდეს. ზედმეტად გრძელი შეყვანა შეცდომების ამ ჯაჭვს ააქტიურებს.