Гэты артыкул напісаны па матывах вельмі ўдалага пентэста, які пару гадоў таму правялі спецыялісты Group-IB: здарылася гісторыя, якая прэтэндуе на экранізацыю ў Балівудзе. Зараз, мусіць, рушыць услед рэакцыя чытача: «О, чарговы піяр-артыкул, ізноў гэтыя малююцца, якія яны добрыя, яшчэ не забудзьцеся купіць пентэст». Ну, з аднаго боку, так і ёсць. Аднак ёсць яшчэ шэраг матываў, чаму з'явіўся гэты артыкул. Жадалася паказаць, чым менавіта займаюцца пентэстэры, наколькі гэтая праца можа быць цікавай і нетрывіяльнай, якія пацешныя акалічнасці могуць складацца на праектах і самае галоўнае - паказаць жывы матэрыял з рэальнымі прыкладамі.
Каб аднавіць баланс сціпласці ў свеце, праз некаторы час напішам пра пентэст, які не пайшоў. Пакажам, як добра пастаўленыя працэсы ў кампаніі могуць абараніць ад цэлага спектру нападаў, нават добра падрыхтаваных, проста таму што гэтыя працэсы ёсць і рэальна працуюць.
У заказчыка з гэтага артыкула таксама ўсё ў цэлым было выдатна, прынамсі лепш, чым у 95% рынка ў РФ па нашых адчуваннях, але быў шэраг дробных нюансаў, якія склаліся ў доўгі ланцужок падзей, што і прывяло спачатку да доўгай справаздачы па працах. , а потым да гэтага артыкула.
Такім чынам, запасімся папкорнам, і сардэчна запрашаем у дэтэктыў. Слова Паўлу Супрунюку, тэхнічнаму кіраўніку напрамку "Аўдыт і Кансалтынг" Group-IB.
Частка 1. Почкін доктар
2018 год. Ёсць заказчык – высокатэхналагічная ІТ-кампанія, сама абслугоўвае мноства кліентаў. Хоча атрымаць адказ на пытанне: ці можна без якіх-небудзь першапачатковых ведаў і доступаў, працуючы праз інтэрнет, атрымаць правы адміністратара дамена Active Directory? Ніякая сацыяльная інжынерыя не цікавіць (), перашкаджаць працам спецыяльна не збіраюцца, але могуць выпадкова - перазаліць дзіўна які працуе сервер, напрыклад. Дадатковая задача - выявіць як мага больш іншых вектараў нападаў у дачыненні да знешняга перыметра. Кампанія рэгулярна праводзіць падобныя тэставанні, і вось падышоў тэрмін новага тэсту. Умовы амаль тыповыя, адэкватныя, зразумелыя. Прыступаем.
Маецца назва заказчыка - хай будзе "Company", з асноўным сайтам . Вядома, называецца заказчык па-іншаму, але ў дадзеным артыкуле ўсё будзе абязлічана.
Праводжу сеткавую разведку – высвятляю, якія адрасы і дамены лічацца за заказчыкам, малюю схему сеткі, як размяркоўваюцца сэрвісы па гэтых адрасах. Атрымліваю вынік: больш за 4000 жывых IP-адрасоў. Праглядаю дамены ў гэтых сетках: на шчасце, пераважная большасць – сеткі, прызначаныя для кліентаў замоўца, і яны нас фармальна не цікавяць. Заказчык лічыць гэтак жа.
Застаецца адна сетка на 256 адрасоў, для якой да гэтага моманту ўжо маецца разуменне размеркавання даменаў і паддаменаў па IP-адрасах, ёсць інфармацыя пра прасканаваныя парты, значыць – можна вачыма глядзець сэрвісы на прадмет цікавых. Паралельна запускаюцца разнастайныя сканары па даступных IP-адрасах і асобна – па вэб-сайтах.
Сэрвісаў знаходзіцца вельмі шмат. Звычайна гэта радасць для пентэстэра і прадчуванне хуткай перамогі, бо чым больш сэрвісаў, тым больш поле для нападу і тым прасцей знайсці артэфакт. Збеглы прагляд вэб-сайтаў паказаў, што большасць з іх - гэта вэб-інтэрфейсы вядомых прадуктаў буйных сусветных кампаній, якія ўсім выглядам кажуць, што яны вам не рады. Просяць лагін-пароль, з парога трасуць полем для ўводу другога фактару, просяць кліенцкі сертыфікат TLS або пасылаюць далей у Microsoft ADFS. Некаторыя проста недаступныя з інтэрнэта. Да некаторых відавочна трэба мець спецыяльны платны кліент за тры заробкі або ведаць дакладны URL на ўваход. Апусцім яшчэ тыдзень паступовага приунывания падчас спроб «прабіць» софт па версіях на прадмет вядомых уразлівасцяў, пошуку ўтоенага кантэнту ў вэб-шляхах і якія ўцяклі ўлікаў са іншых сэрвісаў тыпу LinkedIn, спроб падбору пароляў па іх, а таксама раскопак уразлівасцяў у самапісаных вэб-сайтах - дарэчы, па статыстыцы гэта самы перспектыўны вектар вонкавага нападу на сённяшні дзень. Адразу адзначу тую кіношную стрэльбу, якая пасля стрэліла.
Такім чынам, знайшлося два сайты, якія выбіваюцца з сотні сэрвісаў. У гэтых сайтах было агульнае: калі не займацца скурпулёзнай сеткавай выведкай па даменах, а "у ілоб" шукаць адчыненыя парты ці труціць сканер уразлівасцяў па вядомым дыяпазоне IP, то гэтыя сайты сыдуць ад праверкі, іх проста не будзе відаць без ведання DNS-імя. Магчыма, іх так і прапусцілі раней, прынамсі, і нашы аўтаматычныя прылады праблем у іх не знайшлі, нават калі іх нацкоўвалі прама на рэсурс.
Дарэчы, аб тым, што ў цэлым знайшлі раней запушчаныя сканары. Нагадаю: для некаторых людзей "пентэст" раўнасільна "аўтаматызаванаму сканіраванню". А сканары на гэтым праекце нічога не сказалі. Ну, максімум паказалі Medium-уразлівасці (3 з 5 па ўзроўні небяспекі): на нейкім сэрвісе дрэнны сертыфікат TLS ці састарэлыя алгарытмы шыфравання, а на большасці сайтаў Clickjacking. Але на гэтым да мэты не прыедзеш. Магчыма, сканары былі б тут больш карысныя, але нагадаю: заказчык сам у стане закупіць такія праграмы і праверыць імі сябе, і, судзячы па маркотных выніках, ужо праверыў.
Вернемся да «анамальных» сайтаў. Першы - нешта тыпу мясцовай Wiki па нестандартным адрасе, але ў гэтым артыкуле хай будзе wiki.company[.]ru. Яна таксама адразу прасіла лагін і пароль, але ўжо праз NTLM у браўзэры. Для карыстальніка такое выглядае як аскетычнае акно з просьбай увесці лагін і пароль. І гэта дрэнная практыка.
Невялікая ремарочка. NTLM у вэб-сайтах на перыметры дрэнная па шэрагу прычын. Першая прычына – раскрываецца імя дамена Active Directory. У нашым прыкладзе яно таксама аказалася company.ru, як і "вонкавае" DNS-імя. Ведаючы гэта, можна якасна падрыхтаваць што-небудзь шкоднаснае, каб яно выканалася толькі на даменнай машыне арганізацыі, а не ў якой-небудзь пясочніцы. Другое – аўтэнтыфікацыя ідзе напрамую праз кантролер дамена па NTLM (сюрпрыз, так?), з усімі асаблівасцямі палітык «ўнутранай» сеткі, уключаючы блакіроўкі ўлікаў ад перавышэння колькасці спроб уводу пароля. Калі зламыснік даведаецца лагіны, ён будзе перабіраць да іх паролі. Калі настроена блакіроўка улікаў ад няправільнага ўводу пароляў - яна спрацуе, і ўлікоўка будзе заблакаваная. Трэцяе - да такой аўтэнтыфікацыі немагчыма дадаць другі фактар. Калі хто з чытачоў усё ж ведае як - паведаміце, калі ласка, рэальна цікава. Чацвёртае - уразлівасць да pass-the-hash-атакам. ADFS прыдумалі нават для абароны ад гэтага ўсяго.
Ёсць адна нядобрая ўласцівасць у прадуктаў Microsoft: нават калі вы адмыслова не публікавалі такі NTLM, ён апынецца ва ўсталёўцы па змаўчанні ў OWA і Lync, прынамсі.
Дарэчы, аўтар гэтага артыкула аднойчы такім жа спосабам выпадкова заблакаваў прыкладна 1000 улікаў працаўнікоў аднаго буйнага банка літаральна за адну гадзіну і меў потым некалькі бледны выгляд. ІТ-службы банка таксама былі бледнымі, але ўсё скончылася добра і адэкватна, нас нават пахвалілі, што мы першымі знайшлі гэтую праблему і справакавалі хуткае і рашучае выпраўленне.
Другі сайт меў адрас «яўна-нейкае-прозвішча.company.ru». Знайшоўся праз Google, прыкладна так на 10-й старонцы. Дызайн пачатку-сярэдзіны двухтысячных, і з галоўнай старонкі глядзеў самавіты чалавек, прыкладна вось так:
Тут узяў кадр з "Сабачага сэрца", але паверце, тамака было падалена-падобна, нават каляровае афармленне ў падобных танах. Няхай сайт завецца preobrazhensky.company.ru.
Гэта быў персанальны сайт… уролага. Стала цікава, што робіць сайт уролага на паддамене высокатэхналагічнай кампаніі. Беглае капанне ў Google паказала, што гэты доктар быў сузаснавальнікам адной з юрыдычных асоб нашага замоўца і нават унёс каля 1000 рублёў статутнага капіталу. Верагодна, сайт быў створаны шмат гадоў таму, а серверныя рэсурсы замоўцы былі выкарыстаныя як хостынг. Сайт даўно страціў актуальнасць, але навошта-то быў пакінуты працуючым на доўгі час.
З пункту гледжання ўразлівасцяў сам вэб-сайт быў у бясьпецы. Забягаючы наперад, скажу, што ён уяўляў з сябе набор статыкі - простыя html-старонкі са ўстаўкамі ілюстрацый у выглядзе нырак і мачавых бурбалак. "Ломаць" такі сайт бескарысна.
А вось вэб-сервер пад ім быў цікавейшым. Мяркуючы па загалоўку HTTP Server, там быў IIS 6.0, а значыць, ужываўся Windows 2003 як аперацыйная сістэма. Сканар раней выявіў, што гэты пэўны вэб-сайт уролага, у адрозненне ад іншых віртуальных хастоў на гэтым жа вэб-серверы, адказваў на каманду PROPFIND, гэта значыць тамака працаваў WebDAV. Дарэчы, сканер выдаў дадзеную інфармацыю з паметкай Info (на мове справаздач сканараў гэта найнізкая небяспека) - такія рэчы звычайна проста прапускаюцца. У спалучэнні гэта давала цікавы эфект, які атрымалася выявіць толькі пасля чарговага капання ў Google: рэдкая ўразлівасць перапаўнення буфера, злучаная з наборам Shadow Brokers, а менавіта CVE-2017-7269, якая ўжо мела гатовы эксплоіт. Інакш кажучы, будзе бяда, калі ў вас Windows 2003 і на IIS запушчаны WebDAV. Хоць які працуе ў прадакшэне Windows 2003 у 2018 году – гэта ўжо сама па сабе бяда.
Эксплойт апынуўся ў Metasploit і тут жа быў апрабаваны з нагрузкай, якая пасылала DNS-запыт на падкантрольны сэрвіс - традыцыйна выкарыстоўваецца Burp Collaborator для адлову DNS-запытаў. На дзіва, спрацавала з першага разу: быў атрыманы адстук у DNS. Далей была спроба стварыць бэкканэкт праз 80 порт (гэта значыць сеткавае злучэнне ад сервера да атакавалага, з доступам да cmd.exe на хасце-ахвяры), але тут здарылася фіяска. Злучэнне не прыйшло, а пасля трэцяй спробы эксплуатацыі сайт разам з усімі займальнымі карцінкамі знік назусім.
Звычайна пасля гэтага ідзе ліст у стылі «заказчык, прачніся, мы ўсё выпусцілі». Але нам адказалі, што сайт ніякага дачынення да бізнес-працэсаў не мае і працуе там увогуле незразумела навошта, як і ўвесь сервер, і што можна выкарыстоўваць гэты рэсурс як нам заўгодна.
Прыкладна праз суткі сайт раптоўна зарабіў сам. Збудаваўшы стэнд з WebDAV на IIS 6.0, я знайшоў, што па змаўчанні варта налада на перазапуск працоўных працэсаў IIS кожныя 30 гадзін. Гэта значыць пры выхадзе кіравання з шелл-кода завяршаўся працоўны працэс IIS, затым ён пару разоў перазапускаўся сам і далей сыходзіў адпачываць на 30 гадзін.
Так як першы раз бэкканект на tcp не атрымаўся, я спісаў гэтую праблему на зачынены порт. Гэта значыць выказаў здагадку наяўнасць некаторага міжсеткавага экрана, які не прапускаў выходныя злучэнні вонкі. Пачаў запускаць шелл-коды, якія перабіраюць мноства tcp-і udp-партоў, эфекту не было. Не працавалі нагрузкі зваротнага злучэння праз http(s) з Metasploit - meterpreter/reverse_http(s). Раптам злучэнне на той жа 80 порт устанавілася, але тут жа абарвалася. Спісаў гэта на дзеянне пакуль яшчэ ўяўнай IPS, якой не падабаўся трафік meterpreter. У святле таго, што злучэнне чыстага tcp на 80 порт не прайшло, а http - прайшло, заключыў, у сістэме была неяк настроена http-проксі.
Спрабаваў нават meterpreter праз DNS (дзякуй за працы, выратавала шмат праектаў), успамінаючы самы першы поспех, але ён не адпрацаваў нават на стэндзе - шелл-код быў занадта аб'ёмны для гэтай уразлівасці.
У рэальнасці гэта выглядала так: 3-4 спробы нападаў на працягу 5 хвілін, потым чаканне на 30 гадзін. І так тры тыдні запар. Я нават заводзіў напамін, каб не губляць час. Дадаткова назіралася розніца ў паводзінах тэставых і баявых асяроддзяў: для гэтай уразлівасці было два падобных эксплойта, адзін са складу Metasploit, другі з прастораў інтэрнэту, перароблены ад версіі Shadow Brokers. Дык вось, на баявым адпрацоўваў толькі Metasploit, на стэндзе - толькі другі, што яшчэ больш ускладняла адладку і ламала мозг.
У выніку эфектыўным сябе паказаў шелл-код, які пампаваў з зададзенага сервера па http exe-файл і запускаў яго на мэтавай сістэме. Шэл-код быў досыць маленькі, каб пралезці па памеры, ну і ён хаця б працаваў. Раз трафік TCP серверу наогул не падабаўся і http(s) інспектаваўся на прадмет наяўнасці meterpreter, я вырашыў, што найболей хуткі спосаб - запампаваць праз гэты шелл-код exe-файл, які ўтрымоўваў DNS-meterpreter.
Тут ізноў паўстала праблема: пры запампоўцы exe-файла і, як паказалі спробы, усё роўна якога, запампоўка абрывалася. Ізноў нейкай прыладзе абароны паміж маім серверам і ўролагам не падабаўся трафік http з exe усярэдзіне. "Хуткім" рашэннем падалося змяніць шелл-код так, каб ён абфусцыраваў трафік http налёту, каб замест exe перадаваліся абстрактныя двайковыя дадзеныя. Нарэшце атака прайшла паспяхова, праз тонкі DNS-канал паступіла кіраванне:
Адразу высветлілася, што ў мяне самыя простыя правы працоўнага працэсу IIS, якія дазваляюць рабіць нічога. Вось так гэта выглядала на кансолі Metasploit:
Усякія пентэст-метадалогіі настойліва кажуць аб тым, што трэба падвышаць правы пры атрыманні доступу. Звычайна я гэта не раблю лакальна, бо самы першы доступ разглядаецца проста як кропка сеткавага ўваходу, а скампраметаваць іншую машыну ў гэтай жа сетцы звычайна прасцей і хутчэй, чым павялічваць прывілеі на наяўным хасце. Але тут не той выпадак, бо канал DNS вельмі вузкі і ён не дасць разгуляцца трафіку.
Мяркуючы, што гэты сервер з Windows 2003 не рамантавалі ад знакамітай уразлівасці MS17-010, тунэлюю трафік на порт 445/TCP праз DNS-тунэль meterpreter на localhost (так, так таксама можна) і спрабую запусціць праз уразлівасць раней закачаны exe. Атака спрацоўвае, мне прыходзіць другое злучэнне, але ўжо з правамі SYSTEM.
Цікава тое, што сервер усё ж спрабавалі абараніць ад MS17-010 – у яго былі адключаныя ўразлівыя сеткавыя службы на вонкавым інтэрфейсе. Гэта сапраўды абараняе ад нападаў праз сетку, але напад "знутры" на localhost спрацавала, бо нельга проста ўзяць і хутка выключыць SMB на localhost.
Далей высвятляюцца новыя цікавыя дэталі:
- Маючы правы SYSTEM, можна без праблем усталяваць бэкканэкт праз TCP. Відавочна, забарона на прамой TCP – выключна праблема абмежаванага карыстальніка IIS. Спойлер: трафік карыстальніка IIS як-то быў загорнуты ў лакальны ISA Proxy у абодва бакі. Як менавіта гэта працуе, не прайграваў.
- Я ў нейкай "DMZ" (і гэта не дамен Active Directory, а WORKGROUP) – гучыць лагічна. Але замест чаканага прыватнага («шэрага») IP-адрасы ў мяне цалкам сабе «белы», сапраўды такі ж, што я атакаваў раней. Значыць, кампанія настолькі старая для свету адрасацыі IPv4, што можа дазволіць сабе трымаць зону DMZ на 128 "белых" адрасоў без NAT па схеме, як малявалі ў дапаможніках па Cisco узору 2005 гады.
Бо сервер стары, гарантавана зарабіў Mimikatz прама з памяці:
Атрымліваю пароль лакальнага адміністратара, тунэлюю трафік RDP праз TCP і заходжу ва ўтульны працоўны стол. Бо з серверам можна было рабіць усё, што заўгодна, – выдаляю антывірус, знаходжу, што сервер даступны з інтэрнэту толькі па партах TCP 80 і 443, прычым 443 не быў заняты. Паднімаю на 443 сервер OpenVPN, дадаю функцыі NAT для майго VPN-трафіку і атрымліваю прамы доступ у сетку DMZ у неабмежаваным выглядзе праз свой OpenVPN. Характэрна, што ISA, маючы некаторыя неадключаныя функцыі IPS, блакавала мой жа трафік са сканаваннем портаў, завошта яе прыйшлося замяніць на прасцейшы і згаворлівы RRAS. Так што пентэстэрам яшчэ часам даводзіцца адміністраваць усялякае.
Уважлівы чытач спытае: "А што другі сайт - wiki з NTLM-аўтэнтыфікацыяй, пра якую столькі напісана?" Пра гэта далей.
Частка 2. Вы ўсё яшчэ не шыфруеце? Тады мы ідзем да вас ужо тут
Такім чынам, ёсць доступ у сеткавы сегмент DMZ. Трэба ісці да адміністратара дамена. Першае ж, што прыходзіць у галаву, - аўтаматызавана праверыць на бяспеку сэрвісы ўнутры сегмента DMZ, тым больш што іх зараз адкрылася для даследавання значна больш. Тыповая карціна пры тэсце на пранікненне: знешні перыметр абаронены лепш, чым унутраныя сэрвісы, і пры атрыманні любога доступу ўнутр вялікай інфраструктуры здабыць пашыраныя правы ў дамене значна прасцей толькі за кошт таго, што гэты дамен пачынае быць даступным для інструментара, а па-другое, у інфраструктуры на некалькі тысяч хастоў заўсёды знойдзецца пара крытычных праблем.
Зараджаю сканары па DMZ праз OpenVPN-тунэль, чакаю. Адкрываю справаздачу - ізноў нічога сур'ёзнага, мабыць хтосьці прайшоўся такім жа спосабам да мяне. Наступнае дзеянне - даследаванне таго, як абменьваюцца інфармацыяй хасты ўнутры сеткі DMZ. Для гэтага для пачатку запускаецца звычайны Wireshark з праслухоўваннем шырокавяшчальных запытаў, у першую чаргу ARP. ARP-пакеты калекцыянаваліся цэлыя суткі. Высвятляецца, што ў гэтым сегменце прымяняецца некалькі шлюзаў. Гэта спатрэбіцца далей. Склейваючы дадзеныя па запытах-адказам ARP і дадзеныя сканавання партоў, знайшоў выходныя кропкі карыстацкага трафіку знутры лакальнай сеткі ў дадатак да тых сэрвісаў, пра якія раней было вядома, тыпу web і пошты.
Так як на бягучы момант у мяне не было ніякага доступу ў іншыя сістэмы і не было ніводнага ўліку для карпаратыўных сэрвісаў, было вырашана вывудзіць хоць якую-небудзь уліку з трафіку пры дапамозе ARP Spoofing.
На серверы ўролага быў запушчаны Cain \u5 Abel. З улікам выяўленых патокаў трафіку былі выбраны найбольш перспектыўныя пары для атакі "чалавек пасярэдзіне", далей шляхам кароткатэрміновага запуску на 10-XNUMX хвілін, з таймерам на перазагрузку сервера на выпадак "завісання", быў атрыманы некаторы сеткавы трафік. Як у анекдоце, было дзве навіны:
- Добрая: уліковых дадзеных налавілася вельмі шмат і напад у цэлым працавала.
- Дрэнная: усе уліковыя дадзеныя былі ад кліентаў самога заказчыка. Аказваючы паслугі па падтрымцы, спецыялісты заказчыка падключаліся да сэрвісаў кліентаў, у якіх не заўсёды было настроена шыфраванне трафіку.
У выніку я разжыўся мноствам бескарысных у кантэксце праекту уліковых дадзеных, але адназначна цікавых у якасці дэманстрацыі небяспекі нападу. Памежныя роўтэры буйных кампаній з telnet, пракінутыя адладкавыя http-парты на ўнутраныя CRM са ўсімі дадзенымі, прамы доступ на RDP ад Windows XP у лакальнай сетцы і іншае цемрашальства. Атрымаўся гэтакі .
Таксама знайшоў пацешную магчымасць збіраць лісты з трафіку прыкладна вось так. Гэта прыклад гатовага ліста, які ішоў ад нашага заказчыка на порт SMTP яго кліента, зноў жа, без шыфравання. Нейкі Андрэй просіць свайго цёзку зноўку выслаць дакументацыю, і яна выкладваецца на воблачны дыск з лагінам, паролем і спасылкай у адным лісце ў адказ:
Гэта яшчэ адзін напамін пра тое, што трэба шыфраваць усе сэрвісы. Невядома, хто і калі прачытае і прыменіць канкрэтна вашыя дадзеныя - правайдэр, сістэмны адміністратар іншай фірмы ці вось такі пентыстар. Маўчу аб тым, што проста перахапіць нешыфраваны трафік можа шмат хто.
Нягледзячы на ўяўны поспех, да мэты гэта не наблізіла. Можна было, вядома, доўга сядзець і вывуджваць каштоўную інфармацыю, але не факт, што яна бы тамака з'явілася, ды і сама напад вельмі рызыкоўная ў плане цэласнасці працы сеткі.
Пасля чарговага капання ў сэрвісах у галаву прыйшла цікавая ідэя. Ёсць такая ўтыліта, завецца Responder (лёгка знайсці прыклады ўжывання па гэтым імі), якая шляхам «атручвання» шырокавяшчальных запытаў правакуе на сябе падлучэння па мностве пратаколаў тыпу SMB, HTTP, LDAP і т.д. рознымі спосабамі, затым кожнага які падлучыўся просіць аўтэнтыфікавацца і падладжвае гэта так, што аўтэнтыфікацыя праходзіць праз NTLM і ў празрыстым для ахвяры рэжыме. Часцей за ўсё атакавалы такім чынам збірае NetNTLMv2-хендшэйкі і з іх па слоўніку хутка аднаўляе даменныя паролі карыстачоў. Тут жадалася нешта падобнае, але карыстачы сядзелі «за сценачкай», а дакладней, былі аддзеленыя міжсеткавым экранам, а ў WEB выходзілі праз кластар проксі Blue Coat.
Памятаеце, я ўдакладняў, што імя дамена Active Directory супадала з "вонкавым" даменам, гэта значыць было company.ru? Дык вось, Windows, дакладней Internet Explorer (і Edge, і Chrome), дазваляюць карыстачу празрыста аўтэнтыфікавацца ў HTTP праз NTLM, калі палічаць, што сайт знаходзіцца ў некаторай "Intranet Zone". Адзін з прыкмет «Intranet» - зварот па «шэрым» IP-адрасу або па кароткім DNS-імя, гэта значыць без кропак. Так як у распараджэнні быў сервер з "белым" IP і DNS-імем preobrazhensky.company.ru, а даменныя машыны звычайна атрымліваюць суфікс Active Directory дамена праз DHCP для спрошчанага ўводу імёнаў, то ім дастаткова было напісаць у адрасным радку URL , Каб яны знайшлі правільны шлях да скампраметаванага сервера ўролага, не забываючы, што гэта зараз называецца «Intranet». Гэта значыць, заадно аддаўшы мне NTLM-handshake карыстальніка без яго ведама. Засталося прымусіць кліенцкія браўзэры падумаць аб тэрміновай неабходнасці звяртацца на гэты сервер.
На дапамогу прыйшла выдатная ўтыліта Intercepter-NG (дзякуй) ). Яна дазваляла мяняць трафік на хаду і выдатна працавала на Windows 2003. Там нават быў асобны функцыянал па мадыфікацыі толькі JavaScript-файлаў у струмені трафіку. Планаваўся гэтакі масавы Cross-Site Scripting.
Проксі Blue Coat, праз якія карыстачы выходзілі ў глабальны WEB, перыядычна займаліся кэшаваннем статычнага кантэнту. Шляхам перахопу трафіку было відаць, што яны працуюць кругласутачна, бясконца запытваючы часта выкарыстоўваную статыку для паскарэння паказу кантэнту ў пікавыя гадзіны. Да таго ж у BlueCoat быў спецыфічны User-Agent, што адназначна адрознівала яго ад жывога карыстача.
Быў падрыхтаваны Javascript, які пры дапамозе Intercepter-NG уначы цэлую гадзіну ўкараняўся на кожны адказ з JS-файламі для Blue Coat. Скрыпт рабіў наступнае:
- Вызначаў па User-Agent бягучы браўзэр. Калі гэта быў Internet Explorer, Edge ці Chrome – працаваў далей.
- Чакаў, пакуль сфарміруецца DOM старонкі.
- Устаўляў у DOM нябачную карцінку з атрыбутам src выгляду :8080/NNNNNNN.png, дзе NNN - адвольныя лічбы, каб BlueCoat не закэшыраваў.
- Выстаўляў глабальную зменную-сцяг, што ін'екцыя была праведзена і больш не трэба ўстаўляць карцінкі.
Браўзэр спрабаваў падгрузіць гэтую карцінку, на порце 8080 скампраметаванага сервера яго чакаў TCP-тунэль да майго наўтбука, дзе быў запушчаны той самы Responder, які патрабуе ад браўзэра ўваходу па NTLM.
Судзячы па логах Responder, раніцай людзі дашлі на працу, улучылі свае працоўныя станцыі, затым масава і неўзаметку для сябе пачалі наведваць сервер уролага, не забываючы «зліваць» NTLM-хендшейки. Хендшэйкі сыпаліся цэлы дзень і відавочна назапасілі матэрыял для заведама паспяховага нападу па аднаўленні пароляў. Прыкладна вось так выглядалі логі Responder:
Масавыя таемныя наведванні сервера ўролага карыстальнікамі
Вы, мусіць, ужо заўважылі, што гэтая ўся гісторыя будуецца па прынцыпе "ўсё было добра, але тут чакаў аблом, далей здарылася пераадоленне, а затым усё прыйшло да поспеху". Дык вось, тут чакаў аблом. З паўтысячы ўнікальных хэндшэйкаў не было раскрыта ніводнага. І гэта з улікам таго, што нават на наўтбуку з дохлым працэсарам гэтыя NTLMv2-хендшейкі перабіраюцца са хуткасцю некалькі сотняў мільёнаў спроб у секунду.
Прыйшлося ўзбройвацца тэхнікамі мутацый пароляў, відэакартай, слоўнікам патаўсцей і чакаць. Праз працяглы час расчынілася некалькі ўлікаў з паролямі выгляду «Q11111111….1111111q», што кажа аб тым, што ўсіх карыстачоў калісьці прымусілі прыдумаць вельмі доўгі пароль з розным рэгістрам знакаў, які меркаваўся быць яшчэ і складаным. Але мацёрага карыстальніка проста так не правядзеш, і ён вось такім чынам палегчыў сабе запамінанне. Усяго ўлікаў выявілася каля 5 штук, і толькі адна з іх валодала нейкімі каштоўнымі правамі на сэрвісах.
Частка 3. Раскамнагляд наносіць зваротны ўдар
Такім чынам, былі атрыманы першыя даменныя ўлікі. Калі вы да гэтага моманту не заснулі ад доўгага чытання - вы, мусіць, успомніце, што я згадваў сэрвіс, які не патрабаваў другога фактару аўтэнтыфікацыі: гэта wiki c NTLM-аўтэнтыфікацыяй. Зразумела, туды перш за ўсё быў здзейснены ўваход. Капанне ва ўнутранай базе ведаў хутка прынесла вынікі:
- У кампаніі ёсць WiFi-сетка з аўтэнтыфікацыяй па даменных уліках з доступам у лакальную сетку. З бягучым наборам дадзеных гэта ўжо працоўны вектар нападу, але трэба ісці ў офіс нагамі і дзесьці размяшчацца на тэрыторыі офіса замоўца.
- Знайшлася інструкцыя, паводле якой быў сэрвіс, які дазваляў… самастойна зарэгістраваць прыладу «другога фактару» аўтэнтыфікацыі, калі карыстач знаходзіцца ўсярэдзіне лакальнай сеткі і ўпэўнена памятае свае даменныя лагін і пароль. У дадзеным выпадку "ўнутры" і "звонку" вызначалася шляхам даступнасці порта гэтага сэрвісу для карыстальніка. Порт не быў даступны з інтэрнэту, але цалкам сабе быў даступны праз DMZ.
Зразумела, да скампраметаванай уліку быў тут жа дададзены "другі фактар" у выглядзе прыкладання на маім тэлефоне. Там была праграма, якая можа або гучна паслаць на тэлефон push-запыт з кнопкамі "ўхваліць"/"не адобрыць" дзеянне, або моўчкі паказаць код OTP на экране для далейшага самастойнага ўводу. Прычым першы спосаб меркаваўся інструкцыяй адзіна правільным, але не працаваў, у адрозненне ад спосабу з OTP.
З паламаным другім фактарам атрымалася зайсці ў пошту Outlook Web Access і на выдалены доступ у Citrix Netscaler Gateway. У Outlook на пошце чакаў сюрпрыз:
На гэтым рэдкім кадры вы можаце заўважыць, як Раскамнагляд дапамагае пентэстэрам
Гэта былі першыя месяцы пасля знакамітай "веернай" блакіроўкі Telegram, калі няўмольна знікалі з доступу цэлыя сеткі на тысячы адрасоў. Стала зразумела, чаму адразу не спрацаваў push і чаму мая "ахвяра" не забіла трывогу таму, што яе улікам пачалі карыстацца ў адкрыта непрацоўны час.
Хто знаёмы з Citrix Netscaler, той уяўляе, што яго звычайна ўкараняюць такім чынам, каб можна было данесці да карыстача толькі малюначак-інтэрфейс, імкнучыся не даваць яму ў рукі прылад для запуску іншых прыкладанняў і перадачы дадзеных, усяляк абмяжоўваючы дзеянні праз стандартныя абалонкі кіравання. Маёй "ахвяры" па родзе дзейнасці дасталася толькі 1С:
Трохі пагуляўшы па інтэрфейсе 1С, знайшоў, што тамака ёсць вонкавыя модулі апрацоўкі. Іх можна падгружаць з інтэрфейсу, і яны будуць выконвацца на кліенце ці серверы, у залежнасці ад правоў і налад.
Папрасіў сяброў-праграмістаў 1С стварыць такую апрацоўку, якая б прымала радок і выконвала яго. На мове 1С запуск працэсу выглядае прыкладна так (узята з абшараў інтэрнэту). Пагадзіцеся ж, сінтаксіс мовы 1С уражвае рускамоўнага чалавека сваёй непасрэднасцю?
Апрацоўка выдатна выканалася, атрымалася тое, што пентэстары завуць «шеллом» - праз яе быў запушчаны Internet Explorer.
Раней у пошце быў знойдзены адрас сістэмы, якая дазваляе замаўляць пропускі на тэрыторыю. Я замовіў пропуск на выпадак, калі давядзецца выкарыстоўваць вектар атакі праз WiFi.
У інтэрнэтах пагаворваюць, што ў офісе заказчыка было яшчэ смачнае бясплатнае грамадскае харчаванне, але я палічыў за лепшае ўсё ж развіваць атаку праз выдаленне, так спакайней.
На серверы прыкладанняў з Citrix быў актываваны AppLocker, але яго ўдалося абыйсці. Быў падгружаны і запушчаны ўсё той жа Meterpreter праз DNS, бо http(s)-версіі падлучацца не жадалі, а ўнутраны адрас проксі я тады не ведаў. Дарэчы, з гэтага моманту знешні пентэст па сутнасці канчаткова перайшоў ва ўнутраны.
Частка 4. Адмінскія правы ў карыстачоў – гэта дрэнна, п-нятненько?
Першая справа пентэстэра пры атрыманні кантролю над сесіяй даменнага карыстальніка - гэта сабраць усю інфармацыю аб правах у дамене. Ёсць такая ўтыліта BloodHound, якая аўтаматычна дазваляе выгрузіць праз пратакол LDAP з кантролера дамена інфармацыю аб карыстачах, кампутарах, групах бяспекі, а праз SMB – інфармацыю аб тым, які карыстач дзе нядаўна здзяйсняў уваход і хто дзе лакальны адміністратар.
Тыповая тэхніка захопу правоў адміністратара дамена спрошчана выглядае як цыкл манатонных дзеянняў:
- Ідзем на даменныя кампутары, дзе ёсць правы лакальнага адміністратара, зыходзячы з ужо захопленых даменных улікаў.
- Запускаем Mimikatz і атрымліваем кэшаваныя паролі, квіткі Kerberos і хэшы NTLM даменных улікаў, якія нядаўна здзяйснялі ўваход у гэтую сістэму. Альбо здымаем выяву памяці працэсу lsass.exe і які робіцца тое ж самае на сваім боку. Гэта добра працуе з Windows маладзей 2012R2/Windows 8.1 з наладамі па змаўчанні.
- Вызначаем, дзе скампраметаваныя ўлікі маюць правы лакальнага адміністратара. Паўтараем першы пункт. На нейкім этапе атрымліваем правы адміністратара за ўсё дамена.
"КанецЦыкла;", як напісалі б тут праграмісты 1С.
Дык вось, наш карыстач апынуўся лакальным адміністратарам усяго на адным хасце з Windows 7, у імі якога было слова "VDI", або "Virtual Desktop Infrastructure", асабістыя віртуальныя машыны. Верагодна, праекціроўшчык сэрвісу VDI меркаваў, што раз VDI – асабістая аперацыйная сістэма карыстача, хай тады карыстач змяняе праграмнае асяроддзе, як заўгодна, усё роўна хост можна «перазаліць». Я таксама падумаў, што ў цэлым ідэя добрая, зайшоў на гэты асабісты хост VDI і звіў сабе тамака гняздо:
- устанавіў туды OpenVPN-кліент, які рабіў тунэль праз інтэрнэт да майго сервера. Кліент прыйшлося прымусіць праходзіць праз тыя самыя Blue Coat з даменнай аўтэнтыфікацыяй, але OpenVPN справіўся, што называецца, "са скрынкі".
- Усталяваў на VDI OpenSSH. Ну ці праўда, што гэта за Windows 7 без SSH?
Вось так гэта выглядала жыўцом. Нагадваю, што гэта ўсё даводзіцца рабіць праз Citrix і 1С:
Адна з тэхнік па прасоўванні доступу на суседнія кампутары - праверка пароляў лакальных адміністратараў на супадзенне. Тут адразу чакала поспех: хэш NTLM лакальнага адміністратара па змаўчанні (які раптам зваўся Administrator) падыходзіў праз напад pass-the-hash да суседніх VDI-хастаў, якіх было некалькі сотняў. Само сабой, напад тут жа прайшлася па іх.
Тут адміністратары VDI стрэлілі сабе ў нагу двойчы:
- Першы раз, калі не ўвялі машыны VDI пад дзеянне LAPS, у сутнасці захаваўшы аднолькавы пароль лакальнага адміністратара з выявы, які масава разгортвалі на VDI.
- Адміністратар па змаўчанні - адзіная лакальная ўлікоўка, якая ўразлівая да pass-the-hash нападам. Нават пры аднолькавым паролі можна было б пазбегнуць масавай кампраметацыі, зрабіўшы другі ўлік лакальнага адміністратара са складаным выпадковым паролем, а дэфолтнага - заблакаваць.
Навошта служба SSH на той Windows? Вельмі проста: зараз OpenSSH-сервер не толькі падаваў зручную інтэрактыўную камандную абалонку без перашкод працы карыстача, але і socks5-проксі на VDI. Праз гэты socks я падключаўся па SMB і збіраў з усіх гэтых сотняў машын VDI кэшаваныя ўлікі, затым шукаў па іх у графах BloodHound шлях да даменнага адміністратара. Маючы ў распараджэнні сотні хастоў, я знайшоў такі шлях даволі хутка. Правы адміністратара дамена былі атрыманы.
Вось карцінка з прастораў інтэрнэту, якая паказвае падобны пошук. Сувязі паказваюць, хто дзе адміністратар і хто куды зайшоў.
Дарэчы, памятаеце ўмову са старту праекта - "не прымяняць сацыяльную інжынерыю". Дык вось, прапаную паразважаць, наколькі б зразаўся б увесь гэты Балівуда са спецэфектамі, калі ўсёткі можна было б ужыць банальны фішынг. Але мне асабіста было вельмі цікава ўсё гэта рабіць. Спадзяюся, што вам цікава было гэта чытаць. Вядома, не кожны праект выглядае вось так інтрыгуюча, але праца ў цэлым вельмі галаваломная і не дае застойвацца.
Мусіць, у кагосьці паўстане пытанне: а як абараніцца? Нават у гэтым артыкуле апісана шмат тэхнік, пра шматлікія з іх адміністратары Windows нават не ведаюць. Аднак прапаную паглядзець на іх з пазіцыі збітых прынцыпаў і захадаў інфармацыйнай бяспекі:
- не прымяняць састарэлае праграмнае забеспячэнне (памятаеце Windows 2003 у пачатку?)
- не трымаць уключанымі непатрэбныя сістэмы (навошта быў сайт уролага?)
- правяраць паролі карыстальнікаў на трываласць самастойна (інакш гэта зробяць салдаты… пентэстары)
- не мець аднолькавых пароляў да розных акаўнтаў (кампраметацыя VDI)
- і другое
Канешне, рэалізаваць гэта вельмі цяжка, але ў наступным артыкуле мы пакажам на практыцы, што гэта цалкам магчыма.
Крыніца: habr.com