რატომ დაგცინიან 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 გათიშეთ. დიდი ბიჭები ხართ უკვე 😋