დღეს მსურს შემოგთავაზოთ მოკლე პოსტი იმის შესახებ, თუ რამდენად მიაჩვია Microsoft-მა მომხმარებლები, რომ Default-კონფიგურაციით დაინსტალირებული Microsoft-ის ოპერაციული სისტემები, სერვისები, ყველაფერი... რაღაცნაირად და მუშაობს. ხოდა სწორედაც რომ ეს "რაღაცნაირად" მუშაობა არ ვარგა. უნდა გავერკვეთ სერვისში და დავაკონფიგურიროთ ისე, რომ სწორად იმუშაოს. არ აქვს მნიშვნელობა თუ რომელ ოპერაციულ სისტემას იყენებ. ყველაზე დაცული არის ის სისტემა, რომელიც იცი თუ როგორ უნდა დაიცვა.
ეხლა კი განვიხილოთ კონკრეტული 2 მაგალითი, როდესაც Microsoft-ის მიერ Default-ად შემოთავაზებული გზით ბრმად სიარული, იწვევს ისეთი მითების გავრცელებას, როგორიცაა "Windows-ი დაუცველი სისტემაა, ძმა, ლინუქსი დააყენე".
პირველი მაგალითი ეხება ყველას, ვისაც ოდესმე Windows-ოპერაციული სისტემა დაუინსტალირებია. როდესაც აინსტალირებთ Windows-სისტემას, პირველ მომხმარებელს აქვს პრივილეგირებული უფლებები (Administrators ჯგუფშია). ამ მომხმარებელს შეუძლია მაუსზე ორი კლიკის დაჭერით დააინსტალიროს არა მხოლოდ ჩვეულებრივი და ანტივირუსული, არამედ ვირუსული (😎) პროგრამული უზრუნველყოფაც 😉. მართალია, Windows Vista-ში და შემდგომ Microsoft-ის ოპერაციულ სისტემებში არის ისეთი დაცვის მექანიზმი, როგორიცაა User Account Control შემოკლებთ - UAC, რომლის მეშვეობით პროცესები ეშვება Users-ჯგუფის შესაბამისი უფლებებით, იმ შემთხვევაშიც კი, თუ მომხმარებელი Administrators ლოკალური ჯგუფის წევრია - ძალიან რომ გავამარტივოთ, ასეა. მექანიზმი გულისხმობს შემდეგს: Local Security Authority (LSA) სერვისი ქმნის პრივილეგირებული მომხმარებლისთვის ორ logon-სესიას სხვადასხვა წვდომის token-ით. პირველი Token-ი ასახავს მომხმარებლის ყველა ჯგუფის წევრობის პრივილეგიებს, ხოლო მეორე Token-ი ფილტრავს მომხმარებლის პრივილეგირებული ჯგუფების წევრობას და მომხმარებელი სტანდარტული User-ის მსგავი უფლებებითაა (მოკითხვა ყველას ვინც UAC-ს თიშავთ და XP-ის დროინდელ Security-ში ცხოვრობთ ✌). თუ საჭიროა პროცესის დასტარტვა მომხმარებლის სრული უფლებების Token-ით, საჭიროა UAC Elevation-ი, რომელსაც Application Information (Appinfo) სერვისი განაგებს. აქვე ვახსენებ ამ უსაფრთხოების მექანიზმიდან ერთ გამონაკლისს: UAC მექანიზმი არ ეხება builtin administrator მომხმარებელს (რომელიც default-ად Disabled არის ანუ ზოგჯერ Microsoft-ის Default კონფიგურაციაც არ ნიშნავს ცუდს 😉), builtin administrator-ის logon-სესიას მხოლოდ ერთი Token-ი აქვს და ყველა პროცესი უმაღლესი პრივილეგიებით ეშვება (ხსენებაში არ იყო SU-777-DO და RO-777-OT სახელმწიფო სერიის ნომრები, როცა ჩემი "შესტით" SID-500 ნომრით დავდიოდი და არავინ იყო ჩემი გამჩერებელი 😎🤣). ე.ი. Windows-ადმინებისთვის Runas Administrator არის დაახლოებით იგივე, რაც ლინუქსის ადმინებისთვის sudo.
საუბარი იქითკენ მიმყავს, რომ როდესაც Windows-ის ინსტალაციისას გააკეთებთ პირველ logon-ს პირველ ექაუნთში, შექმენით იქვე სტანდარტული მომხმარებელი და ამის შემდგომ სტანდარტული მოხმარებლიდან იმუშავეთ, ხოლო როდესაც დაგჭირდებათ ადმინის პრივილეგიებით პროცესის დასტარტვა, runas administrator და მიუთითეთ პირველად შექმნილი (member of local Administrators Group) მომხმარებლის Credentials-ი. ამ მარტივი წესის დაცვით 80% უბედურებას აიცილებთ თავიდან (პარეტოს პრინციპი).
ეხლა მაგალითი მეორე, რომელიც Domain Administrator-ებს დააინტერესებთ. ნოემბერში Microsoft-მა გამოუშვა უსაფრთხოების პატჩები CVE-2021-42287 და CVE-2021-42278 მოწყვლადობების დასახურად. ვისაც არ უყვარს ბევრი კითხვა და მზა რეცეპტებს ჯერდება: მთავარი არსი მდგომარეობს იმაში, რომ ამ ორი მოწყვლადობის კომბინირებით ჩვეულებრივ მომხმარებელს აქვს შესაძლებლობა "გავიდეს დამკაში" ანუ მოიპოვოს Domain-ზე სრული პრივილეგიები (impersonation of domain controller). ეს რომ არ მოხდეს, ADUC კონსოლში (dsa.msc) დომენის Properties-ში გადადიხართ Atribute Editor-ზე, ეძებთ ms-DS-MachineAccountQuota-ს და Microsoft-ის დეფოლტად მითითებული 10-იანის მაგივრად წერთ 0-ს ან/და აინსტალირებთ ყველა domain controller-ზე ნოემბრის უსაფრთხოების პატჩებს (KB5008102 და KB5008380).
ეხლა კი ოდნავ ვრცლად და წყაროების მითითებით:
ამა წლის 10 დეკემბერს კიბერუსაფრთხოების ენთუზიასტმა ჩარლი კლარკმა გამოაქვეყნა CVE-2021-42287 და CVE-2021-42278 მოწყვლადობების გამოყენების შესახებ კვლევა, რომლის თანახმად არაპრივილეგირებული მომხმარებლით მიიღო სრული წვდომა მთელ დომენზე.
CVE-2021-42278
მოგეხსენებათ, რომ Active Directory-ს სქემაში User-ის და Computer-ის sAMAccountName ატრიბუტი იმით განსხვავდება, რომ კომპიუტერის ატრიბუტი შეიცავს ბოლოში $-ის სიმბოლოს (Group Managed Service Account-ს დავანებოთ ამჯერად თავი 😉). ნოებრის პატჩამდე არ არსებობდა sAMAccountName ატრიბუტის შემოწმების არანაირი მექანიზმი იმისა, იყო თუ არა ბოლოში $-ის ნიშანი და default კონფიგურაციის თანახმად რიგით Domain User-ს აქვს პრივილეგია შეცვალოს 10 კომპიუტერის (ms-DS-MachineAccountQuota =10) ატრიბუტი და როგორც ამ მანქანების Owner-ს, შეუძლია ასევე sAMAccountName ატრიბუტის ცვლილებაც.
CVE-2021-42287
დომეინში Kerberos პროტოკოლით აუტნტიფიკაციისას, Key Distribution Center (KDC) სერვისიდან, რომელიც Domain Controller-ზეა, ხდება Ticket-Granting-Ticket (TGT) და შემდგომ Ticket-Granting-Service (TGS)-ის გამოთხოვა.
მაგალითად, თუ დომეინ კონტროლერის SAM account name-ია DC1$, CVE-2021-42278-ის თანახმად, Domain User-ს შეუძლია შექმნას ახალი machine account-ი და შემდეგ შეუცვალოს მას SAM account name-ი DC1-ზე ($ სიმბოლოს გარეშე ბოლოში). მოითხოვოს DC1-ით TGT, შემდეგ გადაარქვას სახელი machine account-ს და გამოითხოვოს TGS-ი, უკვე ხელთ არსებული TGT-თ.
TGS-ის გამოთხოვისას KDC სერვისი განახორციელებს DC1-ის ძებნას დომეინში და როდესაც ვერ იპოვის (რადგან გადავარქვით TGT-ის მიღების შემდეგ სახელი), განახორციელებს ხელახალ ძებნას, ოღონდ ბოლოში $ სიმბოლოს დამატებით ანუ DC1$-ით. რადგან ამ სახელით არსებობს დომეინ კონტროლერი, KDC-ი გასცემს TGS-ს DC1$-ის ანუ დომეინ კონტროლერის პრივილეგიებით. ამგვარად, ზემოთხსენებული მოწყვლადობების გამოყენებით რეგულარული Domain User-ით შესაძლებელია Domain Admin-ის პრივილეგიების მიღება.
პრაქტიკა ვისაც აინტერესებს, დაიჭით სტატია ჰაბრზე,
მორალი:
თუ არა გინდა, რომ დაგიძახონ:
"ბანძი ადმინი - შტერიძე გია",
მიეც დომეინში შენს მომხმარებლებს
ბევრად ნაკლები პრივილეგია!
Ⓒ - ჯუზეპე ადმინი
No comments
Post a Comment