რატომ დაგცინიან Pentester-ები ანუ რა უნდა ვიცოდეთ Windows-სისტემების Name resolution თავისებურებების შესახებ?

როგორც სათაურიდან ჩანს, ამ სტატიაში ვისაუბრებთ Name Resolution-ზე Windows სისტემებში. თუ რატომაა მნიშვნელოვანი ეს ყველაფერი და როგორ აგვარიდებს სტატიიდან მიღებული ცოდნა წარმატებულ შეტევებს ჩვენს Active Directory-ინფრასტრუქტურის წინააღმდეგ, გავიგებთ შემდგომი ტექსტიდან...

დავიწყოთ საფუძვლებიდან. Windows ოპერაციულ სისტემებში Name Resolution რექვესტები მუშავდება შემდეგი პრიორიტეტიზაციით:

1. hosts ფაილი (%SYSTEMROOT%\System32\drivers\etc\hosts)
2. DNS სერვერი
3. LLMNR - იშიფრება როგორც Link-Local Multicast Name Resolution
4. NBNS/WINS - NetBIOS Name Service ასევე ცნობილია როგორც Windows Internet Name Service

პირველი ორი პუნქტი თუ ყველა IT-სპეციალისტისთვის ცნობილია, მესამე და მეოთხე პუნქტების შესახებ ბევრს არც კი სმენია. სამართლიანობისთვის უნდა ითქვას, რომ "how to"-ების ეპოქისთვის ტიპიური მოვლენაა სიღრმეებში არჩასვლა.

მაშ ასე, LLMNR ეს არის Name Resolution პროტოკოლი IPv4 და IPv6-ისთვის, რომელიც გაჩნდა Windows Vista და Windows Server 2008-ში და ამ პროტოკოლის თანახმად ჰოსტები აკეთებენ multicast-მიკითხვებს (queries) და პასუხობენ (responses) unicast-ით  UDP 5355 პორტზე. თვალსაჩინოებისთვის Command Prompt-ში შეგიძლიათ აკრიფოთ შემდეგი ბრძანება:

netstat -ano | findstr :5355

და რადგან LLMNR პროტოკოლი დეფოლტად ჩართულია Windows-სისტემებში, ხოლო თქვენ ის არ გაგითიშავთ, დაინახავთ, რომ dns client-ის სერვისი უსმენს UDP 5355 პორტს ყველა IPv4 და IPv6 მისამართიდან (IPv6-იც გათიშეთ რა! უბრალოდ გათიშეთ, დამიჯერეთ! 😇).

რაც შეეხება NBNS/WINS პროტოკოლს, ის საკმაოდ ძველი პროტოკოლია და მუშაობს მხოლოდ ipv4-ით, Destination IP მისამართი არის ქსელის IPv4 Broadcast მისამართი, იყენებს UDP 137 პორტს.

LLMNR და NBNS/WINS პროტოკოლები ორივე დეფოლტად ჩართულია Windows-სისტემებში და თამაშში შემოდიან მაშინ, როცა სტანდარტული DNS სერვისი მიუწვდომელია. ამ შემთხვევაში გვაქვს შემდეგი პროცესი:

• LLMNR და NBNS/WINS პროტოკოლების მეშვეობით კლიენტი უგზავნის multicast (LMNR) ან broadcast (NBNS/WINS) მესიჯებს და ეკითხება  მთლიან ქსელს იმ რესურსის შესახებ, რომელიც აინტერესებს. პროტოკოლები თავშივე ითვალისწინებენ, რომ კლიენტი ენდობა მთლიან შიდა ქსელს და ღებულობს პასუხს ნებისმიერი შიდა ქსელში მოპასუხე რესურსიდან, როგორც სანდოს.
• რომელიღაც ჰოსტი შიდა ქსელიდან (მაგალითად, შემტევის ჰოსტი) პასუხობს ჩვენს რექვესტს და გვეუბნება ჩვენს მიერ მოთხოვნილი ჰოსტის Destinatin IP-მისამართს

1. მსხვერპლი უკავშირდება File Share სისტემას სახელად fileserver, რომლის სახელის დაწერისას შეცდომა დაუშვა და დაწერა fileservwr.
2.  DNS-სერვერმა ვერ იპოვა თავისთან fileservwr ჩანაწერი, რის შესახებაც ამცნობა მომთხოვნ კომპიუტერს (სურათზე Victim).
3. კომპიუტერმა რადგან ვერ მიიღო პასუხი, აგზავნის LLMNR, NetBIOS-NS query-ის.
4. შემტევი უსმენს ქსელის ტრაფიკს (სურათზე Attacker) და პასუხობს მსხვერპლის კომპიუტერს, რომ ის არის fileservwr-ი.

შემტევი კომპიუტერი უსმენს Broadcast-ს და პასუხობს ყველა LLMNR, NetBIOS-NS query-ის, რათა მოიპოვოს მომხმარებლის სახელი და პაროლის hash-ი. ამ ოპერაციის განსახორციელებლად არსებობს ბევრი ხელსაწყო და ერთ-ერთი მათგანია SpiderLabs-ის Responder-ი.

შემტევი თავის კომპიუტერზე უშვებს Responder-ს შემდეგი ბრძანებით:

responder -I eth0

(eth0 ამ შემთხვევაში არის ინტერფეისი, რომელიც უსმენს Broadcast-ში LLMNR, NetBIOS-NS query-ებს):

მსხვერპლის კომპიუტერზე მივაკითხოთ file share-ს fileserwr:

მსხვერპლის ოპერაციულ სისტემაზე ამოხტება Windows Security Prompt-ი:

და როდესაც მსხვერპლი შეიყვანს ლეგიტიმურ მომხმარებელს და პაროლს (ჩვენს შემთხვევაში მომხმარებელია superadmin), რა თქმა უნდა, superadmin-ის მომხმარებელი და პაროლის NTLMv2 ჰეშის მნიშვნლობა მოხვდება შემტევის კომპიუტერზე, როგორც ქვემოთ მოცემულ სურათზეა:

ჰეშის მნიშვნელობის მაგივრად, რომ ღია ტექსტად ნახოს მსხვერპლის მიერ შეყვანილი superadmin-ის პაროლი, შემტევი გამოიყენებს მაგალითად, HashCat-ს.

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

LLMNR პროტოკოლის გათიშვა

LLMNR-ის გათიშვა შესაძლებელია ჯგუფური პოლიტიკებიდან:

1. ვხსნით GPMC.msc ჯგუფური პოლიტიკების კონსოლს;
2. გადავდივართ Computer Configuration -> Administrative Templates -> Network -> DNS Client ჩანართზე;
3. Turn Off Multicast Name Resolution პარამეტრს ვაყენებთ Enabled მდგომარეობაში

NBNS/WINS პროტოკოლის გათიშვა

1. ncpa.cpl -ით ვხვდებით Control Panel\All Control Panel Items\Network Connections -ში
2. ვირჩევთ ქსელის ადაპტერის TCP/IPv4 Properties
3. ვაჭერთ ღილაკს Advanced, ვირჩევთ ჩანართ WINS-ს და ვირჩევთ Disable NetBIOS over TCP ოპციას და OK

საქმეს ართულებს ის გარემოება, რომ NBNS/WINS პროტოკოლი ცალ-ცალკე უნდა გათიშოთ ყველა ინტერფეისისთვის.

საბედნიეროდ, შესაძლებელია Powershell-ის მეშვეობით, გავაკეთოთ აღნიშნული ოპერაცია ყველა ინტერფეისისთვის ერთდროულად:

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
  Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" '
  -Name NetbiosOptions -Value 2 -Verbose}

შევინახოთ აღნიშნული სკრიპტი disableNetbios.ps1 სახელით, ხოლო ჯგუფურ პოლიტიკებში ეს სკრიპტი Startup Script-ებში ჩავსვათ:

Computer Configuration -> Policies -> Windows Settings ->Scripts ->Startup->PowerShell Scripts

... და IPv6 გათიშეთ. დიდი ბიჭები ხართ უკვე 😋

Passwordless Authentication - გზა თავისუფლებისკენ, თუ გზა ტყვეობისკენ?

რა არის passwordless autentication (უპაროლო აუტენტიფიკაცია) და რატომ გაჩნდა მასზე მოთხოვნა? 

ბევრ თქვენგანს, შესაძლოა, ერთი და იგივე პაროლი გაქვთ სხვადასხვა რესურსებზე, როგორებიცაა Facebook, Linkedin, Gmail, Live.com... და ასევე იგივე პაროლს იყენებთ კორპორატიულ კომპიუტერზე აუტენტიფიკაციისას ან/და კორპორატიულ რესურსებზე წვდომის მისაღებად. ერთის მხრივ, ერთი პაროლის დამახსოვრება ადვილია, მაგრამ მეორეს მხრივ, საკმარისია ბოროტმოქმედმა მოიპოვოს თქვენი რომელიმე ერთი ექაუნთის პაროლი და ის შეძლებს დანარჩენ ექაუნთებზე წვდომის მოპოვებასაც.

ექსკურსი ისტორიაში

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

აუტენტიფიკაციის სისტემის ელემენტები 

მიუხედავად იმისა, აუტენტიფიკაციის სისტემა არის კომპიუტერული თუ არა, მასში მონაწილეობენ: 

1. ადამიანი ან ადამიანთა ჯგუფი, ვინც უნდა გაიაროს აუტენტიფიკაცია. ნებისმიერი, ვინც იცის პაროლი.
2. ასევე გვჭირდება განმასხვავებელი ნიშან-თვისება, რომელიც გამოარჩევს ამ ადამიანს ან ადამიანთა ჯგუფს სხვებისგან. სხვა სიტყვებით - აუტენტიფიკატორი. ზემოთხსენებულ ზღაპარში ესაა სიტყვები "სეზამ გაიღე".
3. პატრონი, რომელიც არის პასუხისმგებელი აუტენტიფიკაციის სისტემის ფუნქციონირებაზე. ზღაპარში  - 40 ყაჩაღი.
4. აუტენტიფიკაციის მექანიზმი. ზღაპარში  ჯადოსნური მექანიზმი, რომელიც რეაგირებს სიტყვებზე. კომპიუტერულ სისტემებში ესაა პროგრამული უზრუნველყოფა, რომელიც ამოწმებს პაროლის ან ციფრული სერტიფიკატის ნამდვილობას.
5. დაშვების მართვის მექანიზმი. ზღაპარში ესაა მექანიზმი, რომელიც აჩოჩებს გამოქვაბულის შესასვლელის წინ მდებარე ლოდს სწორი პაროლის წარმოთქმისას. მაგალითად, ონლაინ გადახდის სისტემებში ესაა მექანიზმი, რომელიც გასრულებინებთ ტრანზაქციას.

რის გამო დავიწყეთ ამბის მოყოლა?

დღევანდელი ამბავი ეხება ჩვენს მიერ განხილული აუტენტიფიკაციის სისტემის ელემენტებიდან მეორეს - აუტენტიფიკატორს. რატომ არის პაროლი კარგი/ცუდი აუტენტიფიკატორი კომპიუტერული სისტემებისთვის? ამ კითხვას რომ გავცეთ პასუხი, უნდა ვიცოდეთ, თუ როგორ ინახება კომპიუტერულ სისტემაში ჩვენს მიერ დარეგისტრირებული პაროლი.

არც თუ ისე შორეულ წარსულში, პაროლები სისტემაში ინახებოდა ღიად (დაუფარავად) ერთ-ერთ ფაილში, დავარქვათ მას პაროლების ფაილი. როდესაც შემტევებმა დაიწყეს ადვილად ამ პაროლების ფაილზე წვდომის მოპოვება, დაცვის მხარემ მოიგონა პაროლების ამ ფაილში არა ღიად შენახვა, არამედ ჰეშირებულად (Password Hash). hash-ფუნქცია არის ისეთი მათემატიკური ოპერაცია, რომელიც სხვადასხვა ზომის შემომავალ ინფორმაციას გარდაქმნის ყოველთვის ერთნაირი ზომის hash-მნიშვნელობად. მაგალითად, გამოვიყენოთ ეს საიტი, და ვნახავთ, რომ სიტყვა Pa$$w0rd -ის SHA256  ჰეშის მნიშნელობა ყოველთის იქნება: 97c94ebe5d767a353b77f3c0ce2d429741f2e8c99473c3c150e2faa3d14c9da6 ჰეშირების უპირატესობა ისიცაა, რომ ის ერთმიმართულებიანია ანუ ჰეშიდან პაროლი ღია ტექსტად (Plain text) ვერ უნდა მიიღოთ. თუმცა შესაძლებელია წინასწარ დავჰეშოთ პაროლების დიდი მოცულობა და მივუსადაგოთ მათ შესაბამისი ჰეშ მნიშვნელობები (ვისაც გაინტერესებთ მოიძიეთ ინფორმაცია Rainbow Tables-ის შესახებ). აქვე გაფრთხილებთ, რომ ზემოთხსენებულ საიტზე არ შეიყვანოთ თქვენი რომელიმე მოქმედი პაროლი, რადგან ის დიდი ალბათობით ამ საიტის მეპატრონის Rainbow table-ში შეინახება 😉.

 ჰეშირებული პაროლების წინააღმდეგ შემტევმა მხარემ მოიგონა კლავიატურის ლოგერები (keylogger). კლავიატურის ლოგერის საწინააღმდეგოდ დაცვის მხარემ მოიგონა ოპერატიული მეხსიერების დაცვა. შემტევებმა დაიწყეს ქსელში ტრაფიკის მონიტორინგი მომხმარებელი/პაროლის დასაჭერად... ქვემოთ მოვიყვან მომხმარებლის Credentials-ებზე შეტევისა და დაცვის ევოლუციას ერთ სურათად (რა თქმა უნდა, არა ყოვლისმომცველს):

        

პაროლის სიგრძის შესახებ რეკომენდაციები შეგვიძლია წავიკითხოთ, მაგალითად NIST (National Institute of Standards and Technology)-ის საიტზე. ბოლო განახლება არის დათარიღებული 03-02-2020 -ით. იქ ვკითხულობთ: "NIST now recommends a password policy that requires all user-created passwords to be at least 8 characters in length..." რაც ნიშნავს, რომ მომხმარებლის მიერ შექმნილი პაროლი უნდა შედგებოდეს მინიმუმ 8 სიმბოლოსგან. შესაბამისად, 8-სიმბოლოიანი პაროლი აკმაყოფილებს NIST-ის რეკომენდაციებს. თუ რამდენად შორსაა 8-სიმბოლოიანი პაროლით დაცვა რეალური დაცვისგან, მივხვდებით მაშინ, როდესაც შემდეგ სტატიას წავიკითხავთ. სტატიაში ნათქვამია, რომ 8-სიმბოლოიანი (რთული) პაროლის გადარჩევით (Brut-force) თანამედროვე 8 ვიდეობარათისგან შემდგარ კლასტერს შეუძლია 48 წთ.-ში პაროლის ღია ტექსტით გამოტანა. კერძოდ, Nvidia RTX 4090 გრაფიკულ ბარათებზეა საუბარი. ამიტომ, იმ პიროვნებას, ვინც ორგანიზაციაში პასუხისმგებელია ინფორმაციულ და კიბერუსაფრთხოებაზე ჭირდება არა მხოლოდ სტანდარტების ცოდნა, არამედ სიახლეებსაც უნდა ადევნებდეს თვალყურს...

ზემოთ ვახსენეთ, რომ ყველა სისტემაზე ერთი და იგივე პაროლის გამოყენება არ ვარგა. საშუალო ინტერნეტ-მომხმარებელი ათეულობით სისტემაშია რეგისტრირებული და ამას ემატება კორპორატიულ სისტემებშიც პაროლების შეცვლაზე ზრუნვა... ადამიანის მეხსიერება არ არის გათვლილი იმაზე, რომ ამდენი გასხვავებული პაროლი დავიმახსოვროთ. გამოსავალი შეიძლება იყოს პროგრამების ისეთი კლასის გამოყენებაში, როგორიცაა პაროლების მენეჯერები (Keepass, Enpass, Lastpass, 1password, Google Password Manager და ა.შ.). ამ პროგრამების მუშაობის პრინციპი შემდეგია: თქვენ აყენებთ პროგრამაში შესასვლელ რთულ პაროლს (Secret-ს) და მხოლოდ ამ პაროლის დამახსოვრება გიწევთ, ხოლო სხვა დანარჩენ პაროლებს ეს სისტემა ინახავს თავის ბაზაში (თქვენს მიერ დაყენებული პროგრამაში შესასვლელი პაროლის მეშვეობით) დაშიფრულად. თუ ანალოგია გნებავთ ეს იგივეა, რაც გასაღების ჩამკეტიანი სეიფი, რომელშიც საიდუმლო დოკუმენტებს ინახავთ. სეიფი ეს არის პაროლების მენეჯერი, საიდუმლო დოკუმენტები - თქვენი სხვადასხვა ექაუნთების პაროლები, ხოლო გასაღები - პროგრამაში შესასვლელი პაროლი.

სხვა გზა, რომელიც ჩვენი მომხმარებლის 100%-თან მიახლოებულ დაცვას გვაძლევს ეს არის Multifactor Authentication (MFA). MFA მოიაზრებს შემდეგ ფაქტორებს:

• იმას, რაც მხოლოდ ჩვენ უნდა ვიცოდეთ ანუ პაროლს;
• იმას, რაც გაგვაჩნია (ტელეფონი, კომპიუტერი, ფიზიკური თოქენი, პროგრამული უზრუნველყოფა, როგორიცაა Microsoft Authenicator, Google Authenticator და მრავალის სხვა);
• იმას, რანიც ვართ ანუ ბიომეტრიულ მონაცემებს (თითის ანაბეჭდი,  თვალის, სახის ამოცნობა...);

MFA-თი მომხმარებლის დაცვის საშუალებას დღეს გვაძლევს ყველა მნიშვნელოვანი ინტერნეტ-სერვისი.

... და მივუახლოვდით დღევანდელი სტატიის თემას, რომელსაც უპაროლო აუტენტიფიკაცია ქვია. პაროლების სათანადოდ და დაცულად შენახვა, საკმაოდ რთული ამოცანაა. ისტორიაში ცნობილია უამრავი შემთხვევა, როდესაც ცნობილი კორპორაციების მომხმარებელთა და მათი პაროლების მონაცემებმა გაჟონა (Facebook, Linkedin...). მომხმარებლების პაროლების დაცვაზე საზრუნავად 2012 წლის ივლისში ცნობილმა კორპორაციებმა (PayPal, Lenovo, Nok Nok Labs, Validity Sensors, Infineon, და Agnitio) შექმნეს ალიანსი, რომლის სახელია FIDO Alliance და ამ ალიანსს შეუერთდნენ მრავალი სხვა კომპანიებიც, როგორიცაა Google, Microsoft, Apple... FIDO ეს არის ღია სტანდარტი, რომელიც დაფუძნებულია ასინქრონულ კრიპტოგრაფიაზე და მთავარი არსი მდგომარეობს იმაში, რომ აუტენტიფიკაცია ხდებოდეს არა სადღაც სერვერზე ცენტრალიზებულად, არამედ უშუალოდ მომხმარებლის მოწყობილობაზე. 2016 წლის თებერვალში სტანდარტმა ჰპოვა განვითარება და ცნობილია, როგორც FIDO2 სტანდარტი.

დღეს FIDO2 სტანდარტით სერტიფიცირებული და სტანდარტის საკუთარი იმპლემენტაციის მქონე შემდეგი პროდუქტებია ცნობილი:  Microsoft-ის Windows Hello, Windows Business Hello, Apple Face ID, Apple ID, Google-ის Login Service, Passkeys-ის Apple-ის და Google-ის იმპლემენტაცია, კომპანია Yubico-ს პროდუქტები...

უდავოდ, Passwordless აუტენტიფიკაციას აქვს დიდი უპირატესობები, არ გვიწევს პაროლების დამახსოვრება და აუტენტიფიკატორად გამოიყენება ჩვენს მფლობელობაში არსებული მოწყობილობა ან მასზე გაშვებული პროგრამული უზრუნველყოფა, თუმცა არ უნდა დაგვავიწყდეს, რომ ჩვენს მფლობელობაში არსებულ მოწყობილობას ყავს მწარმოებელი, ხოლო პროგრამულ უზრუნველყოფას - დეველოპერი. ეს ნიშნავს, რომ პაროლზე უარის თქმით თქვენ ნდობას უცხადებთ მწარმოებელს ან/და დეველოპერს... ზოგიერთი თქვეგანი იტყვის, რომ ურჩევნია ისევ და ისევ გამოიყენოს პაროლების მენეჯერი და ქონდეს გააქტიურებული სხვადასხვა სერვისებზე MFA, რაც თანაბრად ანაწილებს Credentials-ების შენახვაზე პასუხისმგებლობას მომხმარებელსა და სერვისის მომწოდებელს შორის... მაგრამ ანაწილებს კი? განვიხილოთ მაგალითი: Microsoft-ის ან Google-ის ონლაინ ექაუნთის შექმნისას პაროლი ინახება სერვისის მომწოდებლის სერვერებზე, ხოლო Microsoft ან Google Authenticator-ის მწარმოებელიც სერვისის მომწოდებელია. აკონტროლებთ რამეს? 😉

თუ როგორ ინახავდა მომხმარებლების პაროლებს (და ღმერთმა იცის როგორ ინახავს ეხლა) კომპანია Facebook-ი იგივე Meta, ამ სტატიიდან გაიგებთ... 2012 წელს ფეისბუქის 200-დან 600 მლნ. მომხმარებლის პაროლი ღია ტექსტად იყო ხელმისაწვდომი ამავე კოპანიის 20 ათასამდე თანამშრომლისთვის 😨

ვფიქრობ, რომ Passwordless Authentication-ი MFA-ს უფრო მარტივი ალტერნატივაა იუზერის გადმოსახედიდან თუ ვიმსჯელებთ. მაშ, Passwordless Authentication  - გზა თავისუფლებისკენ, თუ გზა ტყვეობისკენ? 😉

თქვენ როგორ ფიქრობთ?