თავდამსხმელებმა Qubole-ს სანდო AWS წვდომით მომხმარებელთა ანგარიშები გატეხეს და მონაცემები მოიპარეს

თავდამსხმელებმა Qubole-ს სანდო AWS ანგარიში გამოიყენეს, რათა 14 ოქტომბრიდან 26 ოქტომბრამდე მომხმარებელთა IAM როლები მიეღოთ, და მოიპარეს საიდუმლოებები და მონაცემები რამდენიმე ღრუბლოვანი სერვისიდან.

თავდასხმის დეტალები

შეჭრისას თავდამსხმელებმა გამოიყენეს Qubole-ს პლატფორმის ანგარიშის იდენტიფიკატორი 805246085872. ყოველი AssumeRole მოთხოვნა შეიცავდა external ID-ს, რომელსაც AWS არასაიდუმლოდ მიიჩნევს და რომელიც CloudTrail-ის ლოგებში ჩანს. თავდამსხმელებმა მიიღეს წვდომა Lambda-ის გარემოს ცვლადებზე, Secrets Manager-ზე და SSM Parameter Store-ზე, შემდეგ კი TruffleHog-ით შეამოწმეს მოპოვებული გასაღებები. მონაცემები დააკოპირეს ნებისმიერი S3 bucket-იდან, რომლის წაკითხვის უფლებაც აღებულ როლს ჰქონდა, ზოგჯერ კი მთელი bucket-ები ერთ სესიაში ჩამოტვირთეს. ცალკე კამპანიაში, 8 ოქტომბრიდან 11 ოქტომბრამდე, თავდამსხმელებმა გამოიყენეს მომხმარებლების საკუთარი AWS წვდომის გასაღებები, რომლებიც Qubole-სთვის იყო კონფიგურირებული, და რამდენიმე გარემო კომპრომეტირდა.

გამოვლენის რეკომენდაციები

ორგანიზაციებმა უნდა მოძებნონ CloudTrail-ის მართვის მოვლენები 1 ოქტომბრიდან მოყოლებული AssumeRole გამოძახებებში, სადაც მოთხოვნის გამომგზავნი ანგარიშის ID არის 805246085872, ხოლო წყაროს IP მისამართი AWS-ის მისამართი არ არის. ძირითადი ინდიკატორებია IAM principal ID-ები AIDA3W7DIFLYOLTK63SFS და AIDAJYRRH5Y3A7AAJM2HW, როცა წყარო გარეა, IP მისამართები 57.129.54.120, 2001:41d0:70d:7800::, 45.83.220.211, 185.209.199.73, 89.37.63.175, quiam- პრეფიქსით დაწყებული სესიის სახელები და TruffleHog-ის user agent-ი GetCallerIdentity გამოძახებებზე. გადახედეთ ყველა მოქმედებას, რომელიც შესრულდა რომელიმე საეჭვო სესიის შემდეგ, განსაკუთრებით Secrets Manager-ში, SSM Parameter Store-ში, Lambda-ში და S3-ში. ჩართეთ S3-ის მონაცემთა მოვლენები ან სერვერის წვდომის ლოგები, რათა დააფიქსიროთ ობიექტების დონეზე წაკითხვები.

რისკის შესამცირებელი ნაბიჯები

Qubole-ს როლის აღების შემთხვევაში, როტაცია გაუკეთეთ ყველა საიდუმლოს, პარამეტრსა და Lambda-ის გარემოს ცვლადს, რომლებზეც როლს წვდომა ჰქონდა, და გააუქმეთ აქტიური სესიები. წაშალეთ გამოუყენებელი Qubole-ს როლები ან როლის ნდობის პოლიტიკიდან ამოიღეთ Qubole-ს ანგარიში. სადაც შესაძლებელია, ნდობის პოლიტიკაში ანგარიშის მასშტაბის root principal შეცვალეთ კონკრეტული IAM principal-ით, რომელსაც Qubole იყენებს, და დაამატეთ aws:SourceIp ან aws:SourceVpce პირობა, რომელიც AssumeRole-ს Qubole-ს დოკუმენტირებულ ქსელურ დიაპაზონებზე შეზღუდავს. ინციდენტის შემდეგ შეცვალეთ external ID-ები და, სადაც შესაძლებელია, თითოეული როლისთვის ცალკე მნიშვნელობა გამოიყენეთ. შეამოწმეთ მომწოდებლის როლებზე მინიჭებული უფლებები, რომლებიც ხშირად მოიცავს S3-ის ფართო წაკითხვას, Lambda-ზე, Secrets Manager-ზე და SSM-ზე წვდომას. დააყენეთ გაფრთხილებები AssumeRole მოთხოვნებზე, რომლებიც მოდის VPN-იდან ან ჰოსტინგის პროვაიდერებისგან, რომლებსაც მომწოდებელი არ იყენებს, და უზრუნველყავით ორგანიზაციის მასშტაბის CloudTrail-ის ლოგირება S3-ის მონაცემთა მოვლენებით მგრძნობიარე bucket-ებისთვის.

წყაროები: The Hacker News · The Register