22 ოქტომბერი, 20264 წთ საკითხავიავტორი: LLM.GE რედაქცია

LiteLLM ღია კოდის პოპულარული ბიბლიოთეკა და პროქსი-სერვერია, რომლის საშუალებითაც დეველოპერები ერთი ინტერფეისით 100-ზე მეტ ენობრივ მოდელს უკავშირდებიან. სწორედ ამ ინსტრუმენტზე მოხდა მიწოდების ჯაჭვის (supply chain) სერიოზული შეტევა. LiteLLM-ის გუნდის ინციდენტის ანგარიშის მიხედვით, თავდამსხმელებმა რელიზის პროცესი ხელში ჩაიგდეს და PyPI-სა და Docker-ის რეესტრებში ვერსია 1.107.0 გამოაქვეყნეს, რომელშიც პაროლებისა და გასაღებების მომპარავი მავნე კოდი იყო ჩადებული.

რა მოხდა LiteLLM 1.107.0-ში

თავდამსხმელებმა სამი დეველოპერის GitHub ანგარიში გამოიყენეს, სავარაუდოდ მოპარული GitHub CLI OAuth ტოკენებით. ერთი ანგარიშით მათ რელიზის პროცესი შეცვალეს და გაუშვეს, მეორით ეს გამოშვება დაადასტურეს, მესამით კი სამუშაო პროცესის ჩანაწერები წაშალეს, რამაც გამოძიება გაართულა. მნიშვნელოვანია, რომ GitHub-ზე არსებული ოფიციალური v1.107.0 კოდი სუფთაა. მავნე პაკეტები თავდამსხმელის კონტროლქვეშ მყოფი რეპოზიტორიიდან აიწყო.

სარჩევი

რა მოხდა LiteLLM 1.107.0-ში
როგორ მუშაობდა მავნე კოდი
რატომ არის LiteLLM-ის შეტევა ასეთი საშიში
რა უნდა გააკეთოს დეველოპერმა
შეჯამება
სხვა თემები

დაზიანებული ვერსიები შეზღუდულ დროს იყო ხელმისაწვდომი (დრო UTC-ით, 21 ოქტომბერი):

PyPI: litellm==1.107.0-ის შვიდივე wheel ფაილი, 11:39-დან 13:23-მდე;
Docker Hub: v1.107.0, latest, main-latest და main-stable ტეგები, 11:46-დან 14:20-მდე;
GHCR: იგივე ტეგები, 11:46-დან 13:51-მდე.

კომპანიის თქმით, მისი კერძო საწარმოო (enterprise) რეესტრი ამ შეტევას არ შეხებია, ხოლო ყველა წინა ვერსია უსაფრთხოა.

ინციდენტზე რეაგირებისას გუნდმა შეტევაში გამოყენებული ყველა ტოკენი გააუქმა, GitHub-ის ორგანიზაციიდან კი დროებით ყველა მომხმარებელი ამოიღო, ერთი დაუზიანებელი ანგარიშის გარდა. გარდა ამისა, PyPI-სა და სხვა რეესტრებში GitHub-თან სანდო კავშირი გაითიშა, რომ თავდამსხმელმა ახალი პაკეტი ვეღარ გამოაქვეყნოს. გუნდი აღიარებს, რომ ტოკენების მოპარვის გზა ჯერ დადგენილი არ არის, ამიტომ გამოძიება ჯერ კიდევ გრძელდება და დამატებითი დეტალები მოგვიანებით გამოქვეყნდება.

LiteLLM PyPI Package Compromised: Wiz-ის საფრთხის განახლების ილუსტრაცია — Wiz-მა LiteLLM-ის ინციდენტზე ცალკე ანალიზი გამოაქვეყნა. წყარო: Wiz Research

როგორ მუშაობდა მავნე კოდი

უსაფრთხოების კომპანია AISLE-ის ანალიზის თანახმად, მავნე wheel ფაილები Python-ის site-packages საქაღალდეში სამ დამატებით ფაილს ტოვებდა: cook.pth, cook.py და sitecustomize.py. Python ასეთ ფაილებს ყოველი გაშვებისას ავტომატურად ასრულებს. ანუ მავნე კოდი მუშაობდა მაშინაც კი, თუ პროგრამა ბიბლიოთეკას საერთოდ არ იძახებდა, ხოლო ბიბლიოთეკის წაშლა მას ავტომატურად არ შლიდა.

პირველი ნაწილი ერთჯერადად აგროვებდა ბრაუზერში შენახულ პაროლებს, SSH და GPG გასაღებებს, AWS-ის, Google Cloud-ისა და Azure-ის მონაცემებს, Kubernetes-ის ტოკენებს, გარემოს ცვლადებს და OpenAI-ის, Anthropic-ისა და სხვა AI სერვისების API გასაღებებს. მონაცემებს შიფრავდა და ყალბ დომენზე, litellm.dev-ზე აგზავნიდა (ნამდვილი დომენი litellm.ai-ა). მეორე ნაწილი ფონურ პროცესს უშვებდა, რომელიც ყოველ საათში ამოწმებდა, ხომ არ გამოაქვეყნა თავდამსხმელმა ახალი ბრძანება, და მის დისტანციურად შესრულებას ახერხებდა.

LiteLLM 1.107.0-ის მავნე კოდის მუშაობის სქემა: ინსტალაცია, მონაცემების მოპარვა და დისტანციური კოდის შესრულება — მავნე კოდი ორ ნაწილად მუშაობდა: მონაცემების ერთჯერადი მოპარვა და ფონური „უკანა კარი“. წყარო: Wiz Research

Wiz-ის მკვლევრების ცნობით, დისტანციური კოდის შესრულების ნაწილი აქტიური ჯერ არ შენიშნულა, თუმცა თავდამსხმელს მისი ჩართვა ნებისმიერ დროს შეეძლო. AISLE-ის სისტემამ კი პირველი მავნე ფაილი გამოქვეყნებიდან სულ რაღაც 3 წუთსა და 14 წამში დააფიქსირა.

რატომ არის LiteLLM-ის შეტევა ასეთი საშიში

ამ ბიბლიოთეკას ხშირად იყენებენ როგორც კომპანიის „AI კარიბჭეს“: ერთ ადგილას ინახება სხვადასხვა პროვაიდერის გასაღებები, რომლებითაც აპლიკაციები და AI აგენტები დიდ ენობრივ მოდელებს მიმართავენ. ამიტომ ერთი დაზიანებული სერვერი თავდამსხმელს შეიძლება ბევრ სერვისზე ერთდროულად აძლევდეს წვდომას. ეს შემთხვევა ჰგავს სხვა შეტევებს პოპულარულ ბიბლიოთეკებზე, რის გამოც OpenAI-მ macOS აპლიკაციები სავალდებულოდ განაახლა.

რა უნდა გააკეთოს დეველოპერმა

LiteLLM-ის გუნდის რეკომენდაციით, თუ pip install ზემოთ მითითებულ დროს დაუფიქსირებელი ვერსიით გაუშვით, ან Docker-ის დაზიანებული ტეგით კონტეინერი ჩართეთ, გარემო კომპრომეტირებულად ჩათვალეთ:

ჯერ pip არ გაუშვათ: ნებისმიერი Python პროცესი მავნე კოდს ხელახლა ასრულებს. ბრძანების ხაზიდან წაშალეთ cook.pth, cook.py, sitecustomize.py და მათი .pyc ფაილები;
გათიშეთ ფონური პროცესი, რომელიც /tmp/remote_code_loader.lock ფაილს იკავებს;
LiteLLM ხელახლა დააყენეთ ვერსიით 1.106.2, უმჯობესია გარემო და Docker-ის იმიჯი ნულიდან ააწყოთ;
შეცვალეთ ყველა გასაღები, რაზეც ამ სერვერს წვდომა ჰქონდა: AI პროვაიდერების გასაღებები, პროქსის master და ვირტუალური გასაღებები, მონაცემთა ბაზის პაროლი და ღრუბლოვანი როლები.

ზოგადი გაკვეთილიც მარტივია: წარმოებაში ვერსიები ზუსტად დააფიქსირეთ და latest ტეგებს ნუ ენდობით. ამ თემაზე AI-ის როლი კიბერუსაფრთხოებაში დეტალურად AI კიბერტესტების სტატიაში განვიხილეთ.

შეჯამება

LiteLLM-ის 1.107.0 ვერსია, რომელიც PyPI-სა და Docker-ის რეესტრებში რამდენიმე საათის განმავლობაში იყო ხელმისაწვდომი, პაროლებისა და AI გასაღებების მომპარავ კოდს შეიცავდა. დაზიანებული პაკეტები უკვე წაშლილია, მაგრამ ვინც ამ ვერსიას იყენებდა, სისტემა უნდა გაასუფთაოს და ყველა საიდუმლო გასაღები შეცვალოს.

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