ერთხელ პენტესტი, ან როგორ დავამტვრიოთ ყველაფერი უროლოგისა და როსკომნადზორის დახმარებით

ეს სტატია დაიწერა ძალიან წარმატებულ პენტესტზე დაყრდნობით, რომელიც Group-IB-ის სპეციალისტებმა ჩაატარეს რამდენიმე წლის წინ: მოხდა ამბავი, რომლის ადაპტირებაც შესაძლებელი იყო ბოლივუდის ფილმისთვის. ახლა, ალბათ, მოჰყვება მკითხველის რეაქცია: „აუ, კიდევ ერთი პიარ სტატია, ისევ ასახულია ესენი, რა კარგია, არ დაგავიწყდეთ პენტესტის ყიდვა“. ისე, ერთი მხრივ, ასეა. თუმცა, არსებობს მრავალი სხვა მიზეზი, რის გამოც ეს სტატია გამოჩნდა. მინდოდა მეჩვენებინა, თუ რას აკეთებენ ზუსტად პენტესტერები, რამდენად საინტერესო და არატრივიალური შეიძლება იყოს ეს ნამუშევარი, რა სასაცილო გარემოებები შეიძლება წარმოიშვას პროექტებში და რაც მთავარია, ცოცხალი მასალის ჩვენება რეალური მაგალითებით.

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

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

მაშ ასე, მოდი, მოვიმარაგოთ პოპკორნი და კეთილი იყოს თქვენი მობრძანება დეტექტიურ ისტორიაში. სიტყვა - პაველ სუპრუნიუკიGroup-IB-ის ,,აუდიტი და კონსულტაციის“ დეპარტამენტის ტექნიკური მენეჯერი.

ნაწილი 1. პოჩკინის ექიმი

2018 წელი არის მომხმარებელი - მაღალტექნოლოგიური IT კომპანია, რომელიც თავად ემსახურება ბევრ კლიენტს. სურს მიიღოს პასუხი კითხვაზე: შესაძლებელია თუ არა, ყოველგვარი საწყისი ცოდნისა და წვდომის გარეშე, ინტერნეტით მუშაობისას, მოიპოვოს Active Directory დომენის ადმინისტრატორის უფლებები? მე არ მაინტერესებს სოციალური ინჟინერია (ოჰ, მაგრამ ამაოდ), ისინი არ აპირებენ სამუშაოში გამიზნულად ჩარევას, მაგრამ შეიძლება შემთხვევით - გადატვირთონ უცნაურად მომუშავე სერვერი, მაგალითად. დამატებითი მიზანია რაც შეიძლება მეტი შეტევის ვექტორის იდენტიფიცირება გარე პერიმეტრზე. კომპანია რეგულარულად ატარებს მსგავს ტესტებს და ახლა უკვე დადგა ახალი ტესტის ვადა. პირობები თითქმის ტიპიური, ადეკვატური, გასაგები. Დავიწყოთ.

არის მომხმარებლის სახელი - იყოს "კომპანია", მთავარი ვებსაიტით www.company.ru. რა თქმა უნდა, მომხმარებელს სხვანაირად უწოდებენ, მაგრამ ამ სტატიაში ყველაფერი უპიროვნო იქნება.
ვატარებ ქსელის დაზვერვას - გაირკვეს, რომელი მისამართები და დომენებია რეგისტრირებული მომხმარებელთან, ვხატავ ქსელის დიაგრამას, როგორ ნაწილდება სერვისები ამ მისამართებზე. მე მივიღებ შედეგს: 4000-ზე მეტი ცოცხალი IP მისამართი. მე ვუყურებ ამ ქსელების დომენებს: საბედნიეროდ, აბსოლუტური უმრავლესობა არის ქსელები, რომლებიც განკუთვნილია მომხმარებლის კლიენტებისთვის და ჩვენ ისინი ფორმალურად არ ვართ დაინტერესებული. მომხმარებელიც იგივეს ფიქრობს.

რჩება ერთი ქსელი 256 მისამართით, რისთვისაც ამ მომენტისთვის უკვე არის გააზრებული დომენების და ქვედომენების განაწილება IP მისამართებით, არის ინფორმაცია დასკანირებული პორტების შესახებ, რაც ნიშნავს, რომ შეგიძლიათ ნახოთ სერვისები საინტერესო. პარალელურად, ყველა სახის სკანერი იხსნება ხელმისაწვდომი IP მისამართებზე და ცალკე საიტებზე.

ბევრი მომსახურებაა. ჩვეულებრივ, ეს არის პენტესტერის სიხარული და სწრაფი გამარჯვების მოლოდინი, რადგან რაც უფრო მეტი სერვისია, მით უფრო დიდია თავდასხმის ველი და მით უფრო ადვილია არტეფაქტის პოვნა. ვებგვერდების სწრაფი დათვალიერებამ აჩვენა, რომ მათი უმეტესობა არის მსხვილი გლობალური კომპანიების ცნობილი პროდუქტების ვებ ინტერფეისები, რომლებიც, როგორც ჩანს, გეუბნებათ, რომ არ არის მისასალმებელი. ისინი ითხოვენ მომხმარებლის სახელს და პაროლს, არყევს ველს მეორე ფაქტორის შესაყვანად, ითხოვენ TLS კლიენტის სერთიფიკატს ან აგზავნიან მას Microsoft ADFS-ში. ზოგი უბრალოდ მიუწვდომელია ინტერნეტიდან. ზოგიერთისთვის, თქვენ აშკარად უნდა გქონდეთ სპეციალური ფასიანი კლიენტი სამი ხელფასისთვის ან იცოდეთ ზუსტი URL შესვლისთვის. მოდით გამოვტოვოთ ეტაპობრივი იმედგაცრუების კიდევ ერთი კვირა პროგრამული უზრუნველყოფის ვერსიების „გარღვევის“ მცდელობის პროცესში ცნობილი დაუცველობისთვის, ვებ-ბილიკებში ფარული შინაარსის ძიებასა და მესამე მხარის სერვისებიდან გაჟონილი ანგარიშების ძიებაში, ასევე მათი გამოყენებით პაროლების გამოცნობის მცდელობისას. როგორც დაუცველობის გათხრები თვითნაწერ ვებსაიტებში - სხვათა შორის, სტატისტიკის მიხედვით, დღეს ეს არის გარე შეტევის ყველაზე პერსპექტიული ვექტორი. მე მაშინვე აღვნიშნავ კინოიარაღს, რომელმაც შემდგომ გაისროლა.

ასე რომ, ჩვენ აღმოვაჩინეთ ორი საიტი, რომელიც გამოირჩეოდა ასობით სერვისიდან. ამ საიტებს ერთი რამ ჰქონდათ საერთო: თუ არ ჩაერთვებით ქსელის ზედმიწევნით დაზვერვაში დომენის მიხედვით, მაგრამ ეძებთ ღია პორტებს ან მიზნად ისახავთ დაუცველობის სკანერს ცნობილი IP დიაპაზონის გამოყენებით, მაშინ ეს საიტები გაურბიან სკანირებას და უბრალოდ არ იქნებიან. ჩანს DNS სახელის ცოდნის გარეშე. შესაძლოა, ისინი ადრე გამოტოვეს, ყოველ შემთხვევაში, და ჩვენმა ავტომატურმა ინსტრუმენტებმა მათთან არანაირი პრობლემა არ აღმოაჩინა, თუნდაც ისინი პირდაპირ რესურსზე გაგზავნეს.

სხვათა შორის, იმაზე, რაც ზოგადად იპოვეს ადრე გაშვებულმა სკანერებმა. შეგახსენებთ: ზოგიერთი ადამიანისთვის „პენტესტი“ „ავტომატური სკანირების“ ტოლფასია. მაგრამ ამ პროექტის სკანერებმა არაფერი თქვეს. ისე, მაქსიმუმი აჩვენა საშუალო დაუცველობამ (3-დან 5 სიმძიმის თვალსაზრისით): ზოგიერთ სერვისზე ცუდი TLS სერთიფიკატი ან მოძველებული დაშიფვრის ალგორითმები და უმეტეს საიტებზე Clickjacking. მაგრამ ეს არ მიგიყვანთ თქვენს მიზნამდე. შესაძლოა, სკანერები აქ უფრო გამოგადგებათ, მაგრამ შეგახსენებთ: მომხმარებელს თავად შეუძლია შეიძინოს ასეთი პროგრამები და გამოსცადოს საკუთარი თავი მათთან ერთად და, სავალალო შედეგებით თუ ვიმსჯელებთ, მან უკვე შეამოწმა.

დავუბრუნდეთ „ანომალიურ“ საიტებს. პირველი არის რაღაც ლოკალური ვიკი არასტანდარტულ მისამართზე, მაგრამ ამ სტატიაში ეს იყოს wiki.company[.]ru. მან ასევე დაუყოვნებლივ მოითხოვა შესვლა და პაროლი, მაგრამ ბრაუზერში NTLM-ის საშუალებით. მომხმარებლისთვის ეს ჰგავს ასკეტურ ფანჯარას, რომელიც ითხოვს მომხმარებლის სახელისა და პაროლის შეყვანას. და ეს ცუდი პრაქტიკაა.

პატარა შენიშვნა. NTLM პერიმეტრულ ვებსაიტებში ცუდია მრავალი მიზეზის გამო. პირველი მიზეზი არის Active Directory დომენის სახელის გამოვლენა. ჩვენს მაგალითში, ის ასევე აღმოჩნდა company.ru, ისევე როგორც "გარე" DNS სახელი. ამის ცოდნით, შეგიძლიათ ფრთხილად მოამზადოთ რაიმე მავნე ისე, რომ იგი შესრულდეს მხოლოდ ორგანიზაციის დომენის აპარატზე და არა ზოგიერთ ქვიშის ყუთში. მეორეც, ავთენტიფიკაცია უშუალოდ დომენის კონტროლერში გადის NTLM-ის საშუალებით (სიურპრიზი, არა?), ქსელის „შიდა“ პოლიტიკის ყველა მახასიათებლით, მათ შორის ანგარიშების დაბლოკვით პაროლის შეყვანის მცდელობების რაოდენობის გადამეტებისგან. თუ თავდამსხმელი აღმოაჩენს შესვლას, ის შეეცდება მათ პაროლებს. თუ თქვენ კონფიგურირებული გაქვთ ანგარიშების დაბლოკვა არასწორი პაროლების შეყვანისგან, ის იმუშავებს და ანგარიში დაიბლოკება. მესამე, შეუძლებელია ამ ავთენტიფიკაციას მეორე ფაქტორის დამატება. თუ რომელიმე მკითხველმა მაინც იცის როგორ, გთხოვთ შემატყობინოთ, ეს მართლაც საინტერესოა. მეოთხე, დაუცველობა პას-the-hash შეტევების მიმართ. ADFS გამოიგონეს, სხვა საკითხებთან ერთად, ამ ყველაფრისგან თავის დასაცავად.

Microsoft-ის პროდუქტების ერთი ცუდი თვისებაა: მაშინაც კი, თუ თქვენ კონკრეტულად არ გამოაქვეყნეთ ასეთი NTLM, ის ნაგულისხმევად დაინსტალირებული იქნება OWA-სა და Lync-ში, ყოველ შემთხვევაში.

სხვათა შორის, ამ სტატიის ავტორმა ერთხელ შემთხვევით დაბლოკა ერთი მსხვილი ბანკის თანამშრომლის დაახლოებით 1000 ანგარიში იმავე მეთოდით მხოლოდ ერთ საათში და შემდეგ გარკვეულწილად ფერმკრთალი ჩანდა. ბანკის IT სერვისებიც ფერმკრთალი იყო, მაგრამ ყველაფერი კარგად და ადეკვატურად დამთავრდა, ჩვენ კი შეგვაქეს იმით, რომ პირველებმა აღმოვაჩინეთ ეს პრობლემა და გამოვიწვიეთ სწრაფი და გადამწყვეტი გამოსწორება.

მეორე საიტს ჰქონდა მისამართი "აშკარად რაღაც გვარი.company.ru". ვიპოვე Google-ის საშუალებით, მსგავსი რამ მე-10 გვერდზე. დიზაინი იყო XNUMX-იანი წლების დასაწყისიდან შუა რიცხვებში და პატივცემული ადამიანი უყურებდა მას მთავარი გვერდიდან, დაახლოებით ასეთი:

აქ ავიღე კატინი "ძაღლის გულიდან", მაგრამ დამიჯერეთ, ბუნდოვნად მსგავსი იყო, ფერის დიზაინიც კი მსგავსი ტონალობის იყო. საიტს დაერქვას preobrazhensky.company.ru.

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

დაუცველობის თვალსაზრისით, თავად ვებსაიტი უსაფრთხო იყო. წინ რომ ვუყურებ, ვიტყვი, რომ ეს იყო სტატიკური ინფორმაციის ნაკრები - მარტივი html გვერდები თირკმელებისა და ბუშტების სახით ჩასმული ილუსტრაციებით. ასეთი საიტის „გატეხვა“ აზრი არ აქვს.

მაგრამ ვებ სერვერი ქვემოთ უფრო საინტერესო იყო. თუ ვიმსჯელებთ HTTP სერვერის სათაურით, მას ჰქონდა IIS 6.0, რაც ნიშნავს, რომ ის იყენებდა Windows 2003-ს, როგორც ოპერაციულ სისტემას. სკანერმა ადრე დაადგინა, რომ ეს კონკრეტული უროლოგის ვებსაიტი, იმავე ვებ სერვერზე არსებული სხვა ვირტუალური ჰოსტებისგან განსხვავებით, პასუხობდა PROPFIND ბრძანებას, რაც იმას ნიშნავს, რომ ის მუშაობდა WebDAV-ზე. სხვათა შორის, სკანერმა დააბრუნა ეს ინფორმაცია ნიშნით Info (სკანერის მოხსენებების ენაზე, ეს ყველაზე დაბალი საშიშროებაა) - ასეთი რამ ჩვეულებრივ უბრალოდ გამოტოვებულია. კომბინაციაში, ამან საინტერესო ეფექტი გამოავლინა, რომელიც გამოვლინდა მხოლოდ Google-ში მორიგი გათხრების შემდეგ: იშვიათი ბუფერული დაუცველობა, რომელიც დაკავშირებულია Shadow Brokers კომპლექტთან, კერძოდ, CVE-2017-7269, რომელსაც უკვე ჰქონდა მზა ექსპლოიტი. სხვა სიტყვებით რომ ვთქვათ, პრობლემები შეგექმნებათ, თუ გაქვთ Windows 2003 და WebDAV მუშაობს IIS-ზე. მიუხედავად იმისა, რომ Windows 2003-ის გაშვება 2018 წელს წარმოებაში თავისთავად პრობლემაა.

ექსპლოიტი დასრულდა Metasploit-ში და მაშინვე შემოწმდა დატვირთვით, რომელმაც გაგზავნა DNS მოთხოვნა კონტროლირებად სერვისზე - Burp Collaborator ტრადიციულად გამოიყენება DNS მოთხოვნების დასაჭერად. ჩემდა გასაკვირად, მან პირველად იმუშავა: მიღებული იქნა DNS ნოკაუტი. შემდეგი, იყო მცდელობა 80-ე პორტით (ანუ ქსელური კავშირი სერვერიდან თავდამსხმელთან, cmd.exe-ზე წვდომით დაზარალებულ ჰოსტზე), მაგრამ შემდეგ მოხდა ფიასკო. კავშირი არ შედგა და საიტის გამოყენების მესამე მცდელობის შემდეგ, ყველა საინტერესო სურათთან ერთად, სამუდამოდ გაქრა.

ჩვეულებრივ ამას მოჰყვება წერილი სტილში „მომხმარებელო, გაიღვიძე, ყველაფერი დავკარგეთ“. მაგრამ გვითხრეს, რომ საიტს არაფერი აქვს საერთო ბიზნეს პროცესებთან და მუშაობს იქ უმიზეზოდ, ისევე როგორც მთელი სერვერი, და რომ ჩვენ შეგვიძლია გამოვიყენოთ ეს რესურსი, როგორც გვინდა.
დაახლოებით ერთი დღის შემდეგ საიტმა მოულოდნელად დაიწყო მუშაობა. IIS 6.0-ზე WebDAV-დან სკამი რომ ავაშენე, აღმოვაჩინე, რომ ნაგულისხმევი პარამეტრია IIS მუშაკის პროცესების გადატვირთვა ყოველ 30 საათში. ანუ, როდესაც კონტროლი გამოვიდა shellcode-დან, IIS მუშა პროცესი დასრულდა, შემდეგ ის რამდენჯერმე გადაიტვირთა და შემდეგ დაისვენა 30 საათის განმავლობაში.

ვინაიდან tcp-თან უკან დაკავშირება პირველად ვერ მოხერხდა, ეს პრობლემა დახურულ პორტს მივაწერე. ანუ, მან ივარაუდა რაიმე სახის ბუხარის არსებობა, რომელიც არ აძლევდა გამავალ კავშირებს გარეთ გასვლის საშუალებას. დავიწყე shellcodes-ის გაშვება, რომლებიც ვეძებდი ბევრ tcp და udp პორტს, არანაირი ეფექტი. Metasploit-დან http(s)-ის მეშვეობით შებრუნებული კავშირის ჩატვირთვები არ მუშაობდა - meterpreter/reverse_http(s). უეცრად, კავშირი დამყარდა იმავე პორტ 80-თან, მაგრამ მაშინვე შეწყდა. ამას მივაწერე ჯერ კიდევ წარმოსახვითი IPS-ის მოქმედებას, რომელსაც არ მოეწონა მრიცხველის ტრაფიკი. იმის გათვალისწინებით, რომ სუფთა tcp კავშირი 80-ე პორტთან არ გავიდა, მაგრამ http კავშირი გავიდა, მე დავასკვენი, რომ http პროქსი იყო რაღაცნაირად კონფიგურირებული სისტემაში.

მე ვცადე მრიცხველი DNS-ის საშუალებით (მადლობა d00kie თქვენი ძალისხმევისთვის, დაზოგეთ მრავალი პროექტი), გაიხსენეთ პირველივე წარმატება, მაგრამ ის არც კი მუშაობდა სტენდზე - shellcode იყო ძალიან მოცულობითი ამ დაუცველობისთვის.

სინამდვილეში, ეს ასე გამოიყურებოდა: 3-4 შეტევის მცდელობა 5 წუთში, შემდეგ ელოდება 30 საათს. და ასე ზედიზედ სამი კვირა. შეხსენებაც კი დავაყენე, რომ დრო არ დავკარგო. გარდა ამისა, იყო განსხვავება სატესტო და საწარმოო გარემოს ქცევაში: ამ დაუცველობისთვის იყო ორი მსგავსი ექსპლოიტი, ერთი Metasploit-დან, მეორე ინტერნეტიდან, გადაყვანილი Shadow Brokers-ის ვერსიიდან. ასე რომ, ბრძოლაში მხოლოდ Metasploit-ის ტესტირება მოხდა, სკამზე კი მხოლოდ მეორე, რაც კიდევ უფრო ართულებდა გამართვას და ტვინს აფუჭებდა.

საბოლოოდ, shellcode, რომელიც ჩამოტვირთა exe ფაილი მოცემული სერვერიდან http-ის საშუალებით და გაუშვა სამიზნე სისტემაზე, ეფექტური აღმოჩნდა. Shellcode იყო საკმარისად პატარა, რომ მოერგოს, მაგრამ მაინც მუშაობდა. ვინაიდან სერვერს საერთოდ არ მოსწონდა TCP ტრაფიკი და http(s) შემოწმდა მრიცხველის არსებობისთვის, მე გადავწყვიტე, რომ ყველაზე სწრაფი გზა იყო exe ფაილის ჩამოტვირთვა, რომელიც შეიცავდა DNS-meterpreter-ს ამ shellcode-ით.

აქ კვლავ წარმოიშვა პრობლემა: exe ფაილის ჩამოტვირთვისას და, როგორც მცდელობებმა აჩვენა, რომელი არ უნდა იყოს, ჩამოტვირთვა შეწყდა. ისევ და ისევ, ჩემს სერვერსა და უროლოგს შორის უსაფრთხოების ზოგიერთ მოწყობილობას არ მოეწონა http ტრაფიკი შიგნით exe. როგორც ჩანს, „სწრაფი“ გამოსავალი იყო shellcode-ის შეცვლა ისე, რომ იგი გაურკვეველია http ტრაფიკი ფრენის დროს, ასე რომ exe-ის ნაცვლად აბსტრაქტული ორობითი მონაცემები გადაიცემა. საბოლოოდ, შეტევა წარმატებით დასრულდა, კონტროლი მიიღეს თხელი DNS არხით:

მაშინვე გაირკვა, რომ მე მაქვს IIS სამუშაო ნაკადის ყველაზე ძირითადი უფლებები, რაც არაფრის გაკეთების საშუალებას მაძლევს. ასე გამოიყურებოდა Metasploit კონსოლზე:

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

თუ ვივარაუდებთ, რომ ეს Windows 2003 სერვერი არ არის გარემონტებული ცნობილი MS17-010 დაუცველობისთვის, მე გვირაბის ტრაფიკს 445/TCP პორტში meterpreter DNS გვირაბის მეშვეობით ლოკალჰოსტზე (დიახ, ეს ასევე შესაძლებელია) და ვცდილობ გავატარო ადრე გადმოწერილი exe. დაუცველობა. შეტევა მუშაობს, მე ვიღებ მეორე კავშირს, მაგრამ SYSTEM უფლებებით.

საინტერესოა, რომ ისინი მაინც ცდილობდნენ სერვერის დაცვას MS17-010-ისგან - მას ჰქონდა დაუცველი ქსელის სერვისები გამორთული გარე ინტერფეისზე. ეს იცავს ქსელში შეტევებისგან, მაგრამ ლოკალჰოსტზე შიგნიდან შეტევამ იმუშავა, რადგან თქვენ არ შეგიძლიათ სწრაფად გამორთოთ SMB ლოკალჰოსტზე.

შემდეგი, ახალი საინტერესო დეტალები ვლინდება:

1. SYSTEM უფლებების გათვალისწინებით, შეგიძლიათ მარტივად დაამყაროთ უკანა კავშირი TCP-ის საშუალებით. ცხადია, პირდაპირი TCP-ის გამორთვა მკაცრად არის პრობლემა შეზღუდული IIS მომხმარებლისთვის. სპოილერი: IIS-ის მომხმარებლის ტრაფიკი ერთგვარად იყო გახვეული ადგილობრივ ISA პროქსიში ორივე მიმართულებით. ზუსტად როგორ მუშაობს, არ მაქვს გამეორებული.
2. მე ვარ გარკვეულ "DMZ"-ში (და ეს არ არის Active Directory დომენი, არამედ WORKGROUP) - ეს ლოგიკურად ჟღერს. მაგრამ მოსალოდნელი პირადი („ნაცრისფერი“) IP მისამართის ნაცვლად, მე მაქვს სრულიად „თეთრი“ IP მისამართი, ზუსტად ისეთი, როგორიც ადრე დაესხა თავს. ეს ნიშნავს, რომ კომპანია იმდენად ძველია IPv4 მისამართების სამყაროში, რომ მას შეუძლია შეინარჩუნოს DMZ ​​ზონა 128 „თეთრი“ მისამართისთვის NAT-ის გარეშე სქემის მიხედვით, როგორც ეს ასახულია Cisco-ს 2005 წლის სახელმძღვანელოებში.

ვინაიდან სერვერი ძველია, Mimikatz გარანტირებულია მუშაობა უშუალოდ მეხსიერებიდან:

მე ვიღებ ადგილობრივი ადმინისტრატორის პაროლს, გვირაბის RDP ტრაფიკს TCP-ზე და შევდივარ მყუდრო სამუშაო მაგიდაზე. იმის გამო, რომ სერვერთან რაც მინდოდა მეკეთებინა, ანტივირუსი ამოვიღე და აღმოვაჩინე, რომ სერვერზე ხელმისაწვდომი იყო ინტერნეტიდან მხოლოდ TCP 80 და 443 პორტებით, ხოლო 443 არ იყო დაკავებული. მე დავაყენე OpenVPN სერვერი 443-ზე, დავამატე NAT ფუნქციები ჩემი VPN ტრაფიკისთვის და მივიღე პირდაპირი წვდომა DMZ ქსელზე შეუზღუდავი ფორმით ჩემი OpenVPN-ის საშუალებით. აღსანიშნავია, რომ ISA-მ, რომელსაც აქვს IPS-ის რამდენიმე არაგამორთული ფუნქციები, დაბლოკა ჩემი ტრაფიკი პორტის სკანირებით, რისთვისაც იგი უნდა შეიცვალოს უფრო მარტივი და თავსებადი RRAS-ით. ასე რომ, პენტესტებს ზოგჯერ მაინც უწევთ ყველა სახის ადმინისტრირება.

ყურადღებიანი მკითხველი იკითხავს: „რაც შეეხება მეორე საიტს - ვიკი NTLM ავთენტიფიკაციით, რომლის შესახებაც ამდენი დაიწერა? ამის შესახებ უფრო მოგვიანებით.

ნაწილი 2. ჯერ კიდევ არ დაშიფვრა? მაშინ ჩვენ მოვდივართ თქვენთან უკვე აქ

ასე რომ, არსებობს წვდომა DMZ ქსელის სეგმენტზე. თქვენ უნდა მიხვიდეთ დომენის ადმინისტრატორთან. პირველი, რაც მახსენდება, არის სერვისების უსაფრთხოების ავტომატურად შემოწმება DMZ სეგმენტში, მით უმეტეს, რომ ბევრი მათგანი ახლა ღიაა კვლევისთვის. ტიპიური სურათი შეღწევადობის ტესტის დროს: გარე პერიმეტრი უკეთესად არის დაცული, ვიდრე შიდა სერვისები და დიდი ინფრასტრუქტურის შიგნით რაიმე წვდომის მოპოვებისას, დომენში გაფართოებული უფლებების მიღება ბევრად უფრო ადვილია მხოლოდ იმის გამო, რომ ეს დომენი იწყება. ხელსაწყოებისთვის ხელმისაწვდომი და მეორეც, რამდენიმე ათასი ჰოსტის მქონე ინფრასტრუქტურაში ყოველთვის იქნება რამდენიმე კრიტიკული პრობლემა.

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

იმის გამო, რომ ამ მომენტში მე არ მქონდა წვდომა სხვა სისტემებზე და არ მქონდა ერთი ანგარიში კორპორატიული სერვისებისთვის, გადაწყდა, რომ ტრაფიკიდან მინიმუმ რამდენიმე ანგარიშის ამოღება ARP Spoofing-ის გამოყენებით.

Cain&Abel ამოქმედდა უროლოგის სერვერზე. იდენტიფიცირებული ტრაფიკის ნაკადების გათვალისწინებით, შეირჩა ყველაზე პერსპექტიული წყვილები კაცის შუაგულში შეტევისთვის, შემდეგ კი გარკვეული ქსელის ტრაფიკი მიღებულ იქნა მოკლევადიანი გაშვებით 5-10 წუთის განმავლობაში, სერვერის გადატვირთვის ტაიმერით. გაყინვის შემთხვევაში. როგორც ხუმრობაში, ორი სიახლე იყო:

1. კარგი: დაიჭირეს ბევრი სერთიფიკატი და მთლიანობაში შეტევამ იმუშავა.
2. ცუდი: ყველა სერთიფიკატი იყო მომხმარებლის საკუთარი კლიენტებისგან. დამხმარე სერვისების მიწოდებისას, მომხმარებელთა სპეციალისტები დაკავშირებულია კლიენტების სერვისებთან, რომლებსაც ყოველთვის არ ჰქონდათ კონფიგურირებული ტრაფიკის დაშიფვრა.

შედეგად, მე შევიძინე ბევრი რწმუნებათა სიგელები, რომლებიც უსარგებლო იყო პროექტის კონტექსტში, მაგრამ აუცილებლად საინტერესო, როგორც თავდასხმის საშიშროების დემონსტრირება. მსხვილი კომპანიების სასაზღვრო მარშრუტიზატორები ტელნეტით, http პორტების გადაგზავნა შიდა CRM-ზე ყველა მონაცემით, პირდაპირი წვდომა RDP-ზე Windows XP-დან ლოკალურ ქსელში და სხვა ობსკურანტიზმი. ასე გამოვიდა მიწოდების ჯაჭვის კომპრომისი MITER მატრიცის მიხედვით.

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

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

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

სერვისებში მორიგი გათხრების შემდეგ, საინტერესო იდეა გამიჩნდა. არსებობს ასეთი პროგრამა სახელწოდებით Responder (ადვილია ამ სახელით გამოყენების მაგალითების პოვნა), რომელიც სამაუწყებლო მოთხოვნის „მოწამვლით“ პროვოცირებს კავშირებს სხვადასხვა პროტოკოლების საშუალებით, როგორიცაა SMB, HTTP, LDAP და ა.შ. სხვადასხვა გზით, შემდეგ სთხოვს ყველას, ვინც აკავშირებს ავტორიზაციას და აყენებს მას ისე, რომ ავტორიზაცია მოხდეს NTLM-ის საშუალებით და მსხვერპლისთვის გამჭვირვალე რეჟიმში. ყველაზე ხშირად, თავდამსხმელი ამ გზით აგროვებს NetNTLMv2 ხელის ჩამორთმევას და მათგან, ლექსიკონის გამოყენებით, სწრაფად აღადგენს მომხმარებლის დომენის პაროლებს. აქ მე მინდოდა მსგავსი რამ, მაგრამ მომხმარებლები ისხდნენ "კედელს მიღმა", უფრო სწორად, ისინი გამოეყოთ firewall-ით და შედიოდნენ WEB-ზე Blue Coat proxy კლასტერის საშუალებით.

დაიმახსოვრეთ, მე დავაზუსტე, რომ Active Directory დომენის სახელი დაემთხვა "გარე" დომენს, ანუ ეს იყო company.ru? ასე რომ, Windows, უფრო ზუსტად Internet Explorer (და Edge და Chrome), საშუალებას აძლევს მომხმარებელს გამჭვირვალე ავთენტიფიკაცია მოახდინოს HTTP-ში NTLM-ის საშუალებით, თუ მიიჩნევს, რომ საიტი მდებარეობს რომელიმე „ინტრანეტის ზონაში“. "ინტრანეტის" ერთ-ერთი ნიშანი არის "ნაცრისფერი" IP მისამართის ან მოკლე DNS სახელის წვდომა, ანუ წერტილების გარეშე. ვინაიდან მათ ჰქონდათ სერვერი "თეთრი" IP და DNS სახელით preobrazhensky.company.ru და დომენის აპარატები ჩვეულებრივ იღებენ Active Directory დომენის სუფიქსს DHCP-ის მეშვეობით სახელის გამარტივებული შესვლისთვის, მათ მხოლოდ URL-ის ჩაწერა მოუწიათ მისამართების ზოლში. პრეობრაჟენსკი, რათა მათ იპოვონ სწორი გზა კომპრომეტირებული უროლოგის სერვერისკენ, არ უნდა დაგვავიწყდეს, რომ ამას ახლა "ინტრანეტი" ჰქვია. ანუ, ამავდროულად მომცეს მომხმარებლის NTLM-ხელის ჩამორთმევა მისი ცოდნის გარეშე. რჩება მხოლოდ კლიენტის ბრაუზერების იძულება იფიქრონ ამ სერვერთან დაკავშირების გადაუდებელ აუცილებლობაზე.

მშვენიერი Intercepter-NG პროგრამა მოვიდა სამაშველოში (მადლობა ჩამჭრელი). ეს საშუალებას მოგცემთ შეცვალოთ ტრაფიკი ფრენის დროს და მშვენივრად მუშაობდა Windows 2003-ზე. მას ცალკე ფუნქციაც კი ჰქონდა ტრაფიკის ნაკადში მხოლოდ JavaScript ფაილების შესაცვლელად. დაიგეგმა ერთგვარი მასიური Cross-Site Scripting.

Blue Coat მარიონეტები, რომელთა მეშვეობითაც მომხმარებლები წვდომა გლობალურ WEB-ს, პერიოდულად ახდენდნენ სტატიკური შინაარსის ქეშირებას. ტრაფიკის დაჭერით, ცხადი იყო, რომ ისინი მუშაობდნენ მთელი საათის განმავლობაში, დაუსრულებლად ითხოვდნენ ხშირად გამოყენებულ სტატიკას, რათა დააჩქარონ შინაარსის ჩვენება პიკის საათებში. გარდა ამისა, BlueCoat-ს ჰქონდა კონკრეტული მომხმარებლის აგენტი, რომელიც აშკარად განასხვავებდა მას რეალური მომხმარებლისგან.

მომზადდა ჯავასკრიპტი, რომელიც Intercepter-NG-ის გამოყენებით განხორციელდა ღამით ერთი საათის განმავლობაში თითოეული პასუხისთვის JS ფაილებით Blue Coat-ისთვის. სკრიპტმა გააკეთა შემდეგი:

• განისაზღვრა მიმდინარე ბრაუზერი მომხმარებლის აგენტის მიერ. თუ ეს იყო Internet Explorer, Edge ან Chrome, ის განაგრძობდა მუშაობას.
• დაველოდე სანამ გვერდის DOM ჩამოყალიბდებოდა.
• ჩასმულია უხილავი სურათი DOM-ში ფორმის src ატრიბუტით პრეობრაჟენსკი:8080/NNNNNN.png, სადაც NNN არის თვითნებური რიცხვები ისე, რომ BlueCoat არ ქეშირებს მას.
• დააყენეთ გლობალური დროშის ცვლადი, რათა მიუთითოთ, რომ ინექცია დასრულდა და აღარ არის საჭირო სურათების ჩასმა.

ბრაუზერმა სცადა ამ სურათის ჩატვირთვა; გატეხილი სერვერის 8080 პორტზე მას ჩემს ლეპტოპზე ელოდა TCP გვირაბი, სადაც იგივე Responder მუშაობდა და ბრაუზერს სთხოვდა შესვლას NTLM-ით.

Responder-ის ჟურნალების მიხედვით ვიმსჯელებთ, ადამიანები დილით მოდიოდნენ სამსახურში, ჩართეს სამუშაო სადგურები, შემდეგ მასობრივად და შეუმჩნევლად დაიწყეს უროლოგის სერვერის მონახულება, არ დაივიწყეს NTLM-ის ხელის ჩამორთმევა. ხელის ჩამორთმევა წვიმდა მთელი დღე და აშკარად აგროვებდა მასალა პაროლების აღდგენის აშკარად წარმატებული შეტევისთვის. ასე გამოიყურებოდა Responder logs:

მომხმარებლების მასიური საიდუმლო ვიზიტები უროლოგის სერვერზე

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

პაროლის მუტაციის ტექნიკით, ვიდეოკარტით, სქელი ლექსიკონით მომიწია შეიარაღება და დაველოდე. დიდი ხნის შემდეგ, გამოვლინდა რამდენიმე ანგარიში პაროლით „Q11111111....1111111q“, რაც იმაზე მეტყველებს, რომ ყველა მომხმარებელი ოდესღაც იძულებული იყო შეექმნა ძალიან გრძელი პაროლი სიმბოლოების სხვადასხვა ასოებით, რაც ასევე უნდა ყოფილიყო. იყოს რთული. მაგრამ თქვენ არ შეგიძლიათ მოატყუოთ გამოცდილი მომხმარებელი და ასე გაუადვილა მან თავის დამახსოვრება. საერთო ჯამში, დაახლოებით 5 ანგარიში იყო გატეხილი და მხოლოდ ერთ მათგანს ჰქონდა რაიმე ღირებული უფლება სერვისებზე.

ნაწილი 3. როსკომნადზორი უპასუხებს

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

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

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

„მეორე ფაქტორის“ გატეხვით, მე შევძელი წვდომა Outlook Web Access ფოსტაზე და დისტანციურ წვდომაზე Citrix Netscaler Gateway-ში. Outlook-ში ფოსტაში სიურპრიზი იყო:

ამ იშვიათ კადრში ხედავთ, როგორ ეხმარება Roskomnadzor პენტესტერებს

ეს იყო პირველი თვეები Telegram-ის ცნობილი „ფანის“ დაბლოკვის შემდეგ, როდესაც მთელი ქსელები ათასობით მისამართებით განუწყვეტლივ გაქრა წვდომიდან. გაირკვა, რატომ არ მუშაობდა ბიძგი მაშინვე და რატომ არ ატეხა განგაში ჩემმა „მსხვერპლმა“, რადგან მათ დაიწყეს მისი ანგარიშის გამოყენება ღია საათებში.

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

1C ინტერფეისის ოდნავ შემოვლის შემდეგ აღმოვაჩინე, რომ იქ არის გარე დამუშავების მოდულები. მათი ჩატვირთვა შესაძლებელია ინტერფეისიდან და ისინი შესრულდება კლიენტზე ან სერვერზე, უფლებებისა და პარამეტრების მიხედვით.

მე ვთხოვე ჩემს 1C პროგრამისტ მეგობრებს შეექმნათ დამუშავება, რომელიც მიიღებდა სტრიქონს და შეასრულებდა მას. 1C ენაზე, პროცესის დაწყება დაახლოებით ასე გამოიყურება (აღებულია ინტერნეტიდან). ეთანხმებით, რომ 1C ენის სინტაქსი აოცებს რუსულენოვან ადამიანებს თავისი სპონტანურობით?

დამუშავება მშვენივრად შესრულდა; აღმოჩნდა, რასაც პენტესტერები უწოდებენ "ჭურვს" - მისი მეშვეობით დაიწყო Internet Explorer.

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

ინტერნეტში საუბრობენ, რომ მომხმარებლის ოფისში ჯერ კიდევ იყო უგემრიელესი უფასო კვება, მაგრამ მე მაინც ვამჯობინე შეტევის განვითარება დისტანციურად, ეს უფრო მშვიდია.

AppLocker გააქტიურდა აპლიკაციის სერვერზე, რომელიც მუშაობს Citrix, მაგრამ ის გვერდის ავლით მოხდა. იგივე Meterpreter ჩაიტვირთა და გაუშვა DNS-ის საშუალებით, რადგან http(s) ვერსიებს არ სურდათ დაკავშირება და მე არ ვიცოდი იმ დროს შიდა პროქსის მისამართი. სხვათა შორის, ამ მომენტიდან გარეგანი პენტესტი არსებითად მთლიანად გადაიქცა შინაგანად.

ნაწილი 4. მომხმარებლებისთვის ადმინისტრატორის უფლებები ცუდია, კარგი?

პენტესტერის პირველი ამოცანა დომენის მომხმარებლის სესიაზე კონტროლის მოპოვებისას არის დომენის უფლებების შესახებ ყველა ინფორმაციის შეგროვება. არსებობს BloodHound პროგრამა, რომელიც ავტომატურად საშუალებას გაძლევთ ჩამოტვირთოთ ინფორმაცია მომხმარებლების, კომპიუტერების, უსაფრთხოების ჯგუფების შესახებ LDAP პროტოკოლის მეშვეობით დომენის კონტროლერიდან და SMB-ის მეშვეობით - ინფორმაცია იმის შესახებ, თუ რომელი მომხმარებელი ახლახან შევიდა, სად და ვინ არის ადგილობრივი ადმინისტრატორი.

დომენის ადმინისტრატორის უფლებების ჩამორთმევის ტიპიური ტექნიკა გამარტივებულია, როგორც ერთფეროვანი მოქმედებების ციკლი:

• ჩვენ მივდივართ დომენის კომპიუტერებზე, სადაც არის ადგილობრივი ადმინისტრატორის უფლებები, უკვე დაჭერილი დომენის ანგარიშებზე დაყრდნობით.
• ჩვენ ვიწყებთ Mimikatz-ს და ვიღებთ ქეშირებულ პაროლებს, Kerberos-ის ბილეთებს და დომენის ანგარიშების NTLM ჰეშებს, რომლებიც ახლახან შესულები არიან ამ სისტემაში. ან ვაშორებთ lsass.exe პროცესის მეხსიერების სურათს და იგივეს ვაკეთებთ ჩვენს მხარეს. ეს კარგად მუშაობს Windows 2012R2/Windows 8.1-ზე უმცროსზე ნაგულისხმევი პარამეტრებით.
• ჩვენ განვსაზღვრავთ, სად აქვთ გატეხილი ანგარიშები ადგილობრივი ადმინისტრატორის უფლებები. ჩვენ ვიმეორებთ პირველ პუნქტს. რაღაც ეტაპზე ჩვენ ვიღებთ ადმინისტრატორის უფლებებს მთელი დომენისთვის.

"ციკლის დასასრული;", როგორც აქ წერდნენ 1C პროგრამისტები.

ასე რომ, ჩვენი მომხმარებელი აღმოჩნდა ადგილობრივი ადმინისტრატორი მხოლოდ ერთ ჰოსტზე Windows 7-ით, რომლის სახელიც მოიცავდა სიტყვას „VDI“ ან „ვირტუალური დესკტოპის ინფრასტრუქტურა“, პერსონალური ვირტუალური მანქანები. ალბათ, VDI სერვისის დიზაინერმა იგულისხმა, რომ ვინაიდან VDI არის მომხმარებლის პირადი ოპერაციული სისტემა, მაშინაც კი, თუ მომხმარებელი ცვლის პროგრამულ გარემოს, როგორც მას სურს, ჰოსტი მაინც შეიძლება იყოს "ხელახლა ჩატვირთვა". მეც ვფიქრობდი, რომ ზოგადად იდეა კარგი იყო, მივედი ამ პირად VDI ჰოსტთან და იქ ბუდე გავაკეთე:

• მე დავაინსტალირე OpenVPN კლიენტი იქ, რომელმაც ინტერნეტის საშუალებით გვირაბი გააკეთა ჩემს სერვერზე. კლიენტი უნდა აიძულოს გაიაროს იგივე ლურჯი ქურთუკი დომენის ავთენტიფიკაციით, მაგრამ OpenVPN-მა ეს გააკეთა, როგორც ამბობენ, „ყუთიდან“.
• დაინსტალირებული OpenSSH VDI-ზე. მართლაც, რა არის Windows 7 SSH-ის გარეშე?

ასე გამოიყურებოდა ლაივში. შეგახსენებთ, რომ ეს ყველაფერი უნდა გაკეთდეს Citrix-ისა და 1C-ის საშუალებით:

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

აი, სადაც VDI-ს ადმინისტრატორებმა ფეხში ორჯერ ესროლა:

• პირველად იყო, როდესაც VDI აპარატები არ იქნა მოყვანილი LAPS-ის ქვეშ, არსებითად ინარჩუნებდა იგივე ლოკალური ადმინისტრატორის პაროლს სურათიდან, რომელიც მასიურად იყო განლაგებული VDI-ზე.
• ნაგულისხმევი ადმინისტრატორი ერთადერთი ლოკალური ანგარიშია, რომელიც დაუცველია ჰეშ-შეტევების მიმართ. იმავე პაროლითაც კი, შესაძლებელი იქნება მასობრივი კომპრომისის თავიდან აცილება მეორე ადგილობრივი ადმინისტრატორის ანგარიშის შექმნით რთული შემთხვევითი პაროლით და ნაგულისხმევი პაროლის დაბლოკვით.

რატომ არის SSH სერვისი ამ Windows-ზე? ძალიან მარტივია: ახლა OpenSSH სერვერმა არა მხოლოდ უზრუნველყოს მოსახერხებელი ინტერაქტიული ბრძანების გარსი მომხმარებლის მუშაობაში ჩარევის გარეშე, არამედ socks5 პროქსი VDI-ზე. ამ წინდების მეშვეობით, მე დავუკავშირდი SMB-ის საშუალებით და შევაგროვე ქეშირებული ანგარიშები ამ ასობით VDI აპარატიდან, შემდეგ ვეძებდი გზას დომენის ადმინისტრატორისკენ, მათი გამოყენებით BloodHound გრაფიკებში. ჩემს განკარგულებაშია ასობით მასპინძელი, ეს გზა საკმაოდ სწრაფად ვიპოვე. მიღებულია დომენის ადმინისტრატორის უფლებები.

აქ არის სურათი ინტერნეტიდან, რომელიც აჩვენებს მსგავს ძიებას. კავშირები აჩვენებს ვინ არის სად არის ადმინისტრატორი და ვინ სად არის შესული.

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

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

• არ გამოიყენოთ მოძველებული პროგრამული უზრუნველყოფა (გახსოვთ Windows 2003 დასაწყისში?)
• არ დატოვოთ ჩართული ზედმეტი სისტემები (რატომ იყო უროლოგის ვებსაიტი?)
• თავად შეამოწმეთ მომხმარებლის პაროლები სიძლიერისთვის (თორემ ჯარისკაცები... ამას გააკეთებენ პენტესტერები)
• არ აქვს იგივე პაროლები სხვადასხვა ანგარიშებისთვის (VDI კომპრომისი)
• და სხვა

რა თქმა უნდა, ამის განხორციელება ძალიან რთულია, მაგრამ შემდეგ სტატიაში ჩვენ პრაქტიკაში გაჩვენებთ, რომ ეს სავსებით შესაძლებელია.

წყარო: www.habr.com