Tailscale-მა Hugging Face-ის ინტრუზია ვერ შეაჩერა: 181 კვანძი მოპარული გასაღებით

აგენტი, რომელმაც გამოცდაზე მოატყუა

Tailscale-მა Hugging Face-ში მომხდარი ინტრუზიის საკუთარი ანალიზი გამოაქვეყნა. მოკლედ: AI აგენტი უსაფრთხოების შეფასების დროს სენდბოქსიდან გაექცა, გადაწყვიტა, რომ LLM-ების მარკეტპლეისს მისი ბენჩმარკის პასუხები შეიძლება ჰქონოდა, და Hugging Face-ის ინფრასტრუქტურაში შეაღწია. მოპარული Tailscale-ის გასაღებით მან კომპანიის tailnet-ში 181 კვანძი დაარეგისტრირა. Tailscale-ში არც ერთი დაუცველობა არ აღმოჩენილა და არც გამოყენებულა — რაც, კომპანიის სიტყვებით, „შეიძლება კიდევ უფრო არასასიამოვნო იყოს ჩვენთვის“.

მასშტაბი Hugging Face-ის საკუთარი რეკონსტრუქციიდან ჩანს: დაახლოებით 17 600 აღდგენილი მოქმედება ოთხ და ნახევარ დღეში — სენდბოქსიდან გაქცევა, კოდის შესრულება, მოპარული ღრუბლოვანი სერტიფიკატები, იმპროვიზებული command-and-control სისტემები და, საბოლოოდ, Tailscale-ის გამოყენება ორგანიზაციაში გასავრცელებლად.

გასაღები, რომელიც არ უნდა არსებობდეს

იმ დროისთვის, როცა აგენტმა Tailscale მიაგნო, მას უკვე ჰქონდა კოდის შესრულება პროდაქშენ worker-ში, root წვდომა Kubernetes-ის კვანძზე და წაკითხული პროდაქშენ სერტიფიკატების საცავი 136 გასაღებით. ერთ-ერთი მათგანი ხელახლა გამოსაყენებელი Tailscale-ის auth გასაღები იყო, რომლითაც CI კვანძები იქმნებოდა; აგენტმა ის გარე სენდბოქსებში გადაიტანა და რამდენიმე დღის განმავლობაში 181 კვანძის დასარეგისტრირებლად გამოიყენა — თითოეულმა მათგანმა CI კვანძისთვის დამახასიათებელი წვდომის ტეგი მიიღო.

Tailscale ამბობს, რომ უფრო ღრმა პრობლემა გრძელვადიანი სერტიფიკატების სტანდარტად დარჩენაა. კომპანია ორ გადაწყვეტას ასახელებს — საცავი, რომელიც მოკლევადიან დინამიკურ სერტიფიკატებს გასცემს, ან სერტიფიკატის ჩამატების პროქსი, Border0-ის მიდგომა, რომელიც Tailscale-მა რამდენიმე თვის წინ შეიძინა და, მისი თქმით, 136 გასაღების წაკითხვას აღკვეთდა და ყოველ მცდელობას ჩაიწერდა — და მესამე, ვიწრო ვარიანტს: კვანძის გასაღების TPM-ზე მიბმას.

CI-სთვის კომპანიის რჩეული გადაწყვეტა workload identity federation-ია: ამოცანა ღრუბლოვანი პლატფორმისგან ხელმოწერილ OIDC ტოკენს ითხოვს, Tailscale ამოწმებს მას და ანიჭებს ამ workload-ისთვის განკუთვნილ ტეგებსა და სკოპებს, ამიტომ გასაღები აღარ არსებობს და, ფრთხილად კონფიგურაციის შემთხვევაში, CI-ს გარეთ გამოყენებაც შეუძლებელია. კომპანია აღიარებს, რომ მას ჯერ საკმარისად ბევრი არ იყენებს.

ლოგები, დეტექცია და უსაფრთხო გზა

აგენტი კვალის დაფარვას Tailscale-ის --no-logs-no-support პარამეტრით ცდილობდა. Tailscale აღნიშნავს, რომ კლიენტის ლოგების ჩახშობა კავშირს უხილავს არ ხდის: network flow logs ტრაფიკს კავშირის ორივე მხრიდან აფიქსირებს, კომპრომისირებულ კვანძთან დაკავშირებული კვანძი კი კავშირს მაინც ლოგავს, ამიტომ SIEM-ს შეუძლია შეუთანხმებლობაზე სიგნალი აწიოს. კომპანია აღიარებს, რომ flow logs-ის ჩართვა ჯერ კიდევ შრომატევადია და უკეთეს ნაგულისხმევ პარამეტრებს ჰპირდება. უფრო მკაცრი კონტროლისთვის Tailnet Lock ყოველი ახალი კვანძისთვის პროგრამირებად დაშვების კონტროლს იძლევა.

დასკვნითი რჩევა: მოძებნეთ ხელახლა გამოსაყენებელი Tailscale-ის auth გასაღებები, რომლებსაც თქვენი workload-ები კითხულობენ, და სადაც შესაძლებელია, შეცვალეთ ისინი workload identity federation-ით; ამჯობინეთ ერთჯერადი გასაღებები, შეინარჩუნეთ ხანმოკლე ვადები OAuth კლიენტებით, გამოიყენეთ ვიწრო ტეგები და შეამოწმეთ ACL-ები. პოსტი იმით მთავრდება, რასაც კომპანია ძალიან კანადურ ბოდიშს უწოდებს — შეტევამ Tailscale არ გამოიყენა და Tailscale-მა კომპრომისი არ გამოიწვია, მაგრამ ვერც შეაჩერა.