Ez a cikk egy nagyon sikeres penteszt alapján készült, amelyet az IB-csoport szakemberei végeztek néhány éve: történt egy történet, amelyet Bollywoodban filmre is adaptálhattak. Most valószínűleg az olvasó reakciója következik: "Ó, egy újabb PR-cikk, megint ezeket ábrázolják, milyen jók, ne felejts el pentestet venni." Nos, egyrészt az. A cikk megjelenésének azonban számos egyéb oka is van. Meg akartam mutatni, hogy pontosan mit csinálnak a penteszterek, mennyire érdekes és nem triviális ez a munka, milyen vicces körülmények adódhatnak projektekben, és ami a legfontosabb, élő anyagot mutatni valós példákkal.
Hogy helyreállítsuk a szerénység egyensúlyát a világban, egy idő után írunk egy nem jól sikerült pentestről. Megmutatjuk, hogy a jól megtervezett folyamatok egy vállalatnál hogyan tudnak megvédeni egy sor támadást, még a jól előkészítetteket is, pusztán azért, mert ezek a folyamatok léteznek és valóban működnek.
A cikkben szereplő vásárló számára is általában minden kiváló volt, érzéseink szerint legalábbis jobb, mint az Orosz Föderáció piacának 95%-a, de volt néhány apró árnyalat, amelyek egy hosszú eseményláncot alkottak, amelyek először egy hosszú jelentéshez vezetett a munkáról , majd ehhez a cikkhez.
Szóval, gyűjtsünk pattogatott kukoricát, és üdvözöljük a detektívtörténetben. Szó - Pavel Suprunyuk, az IB Csoport „Audit és Tanácsadó” részlegének műszaki vezetője.
1. rész. Pochkin orvos
2018 Van egy ügyfél - egy high-tech IT-cég, amely maga is sok ügyfelet szolgál ki. Választ szeretne kapni arra a kérdésre: lehetséges-e minden kezdeti tudás és hozzáférés nélkül, az Interneten keresztül Active Directory tartományadminisztrátori jogosultságokat szerezni? Nem érdekel semmiféle social engineering (), nem szándékoznak szándékosan megzavarni a munkát, de véletlenül - például egy furcsán működő szervert újratölthetnek. További cél, hogy minél több más támadási vektort azonosítsanak a külső kerület ellen. A cég rendszeresen végez ilyen teszteket, most pedig elérkezett az új teszt határideje. A feltételek szinte tipikusak, megfelelőek, érthetőek. Kezdjük el.
Van az ügyfél neve – legyen ez „Cég”, a fő weboldallal . Természetesen az ügyfelet másképp hívják, de ebben a cikkben minden személytelen lesz.
Hálózati felderítést végzek - megtudom, mely címek és domainek vannak regisztrálva az ügyfélnél, rajzolok hálózati diagramot, hogyan oszlanak el a szolgáltatások ezekre a címekre. Megkapom az eredményt: több mint 4000 élő IP-cím. Nézem a domaineket ezekben a hálózatokban: szerencsére a túlnyomó többség az ügyfél ügyfeleinek szánt hálózat, és ezekre formálisan nem vagyunk kíváncsiak. A vásárló is így gondolja.
Marad egy hálózat 256 címmel, amelyhez ebben a pillanatban már érthető a tartományok és aldomainek IP-címek szerinti megoszlása, van információ a beolvasott portokról, ami azt jelenti, hogy a szolgáltatások között lehet érdekességeket keresni. Ezzel párhuzamosan mindenféle szkennert elindítanak a rendelkezésre álló IP-címeken és külön a weboldalakon.
Nagyon sok szolgáltatás van. Általában ez a pentester öröme és a gyors győzelem várakozása, hiszen minél több szolgáltatás van, annál nagyobb a támadási mező, és annál könnyebben talál egy műtárgyat. A weboldalak gyors áttekintése megmutatta, hogy ezek többsége nagy világcégek ismert termékeinek webes felülete, amelyekről minden jel szerint nem szívesen látják őket. Kérik a felhasználónevet és a jelszót, kirázzák a mezőt a második faktor megadásához, kérnek egy TLS-kliens tanúsítványt, vagy elküldik a Microsoft ADFS-nek. Némelyik egyszerűen elérhetetlen az internetről. Egyesek számára nyilvánvalóan szükség van egy speciális fizetett ügyfélre három fizetésért, vagy ismernie kell a pontos URL-t a beíráshoz. Ugorjunk ki egy újabb hetet a fokozatos csüggedtségből, amikor megpróbálunk „áttörni” a szoftververziókat az ismert sebezhetőségek után, rejtett tartalmat keresünk webes útvonalakon és olyan külső szolgáltatásoktól, mint a LinkedIn, kiszivárgott fiókjaiban, és megpróbáljuk kitalálni a jelszavakat ezek segítségével. mint a saját maga által írt weboldalak sebezhetőségeinek feltárása – egyébként a statisztikák szerint ma ez a legígéretesebb külső támadás vektora. Azonnal megjegyzem a filmfegyvert, amely később elsült.
Így találtunk két olyan webhelyet, amelyek kiemelkednek a több száz szolgáltatás közül. Ezeknek a webhelyeknek egy közös vonásuk volt: ha nem végez aprólékos hálózati felderítést domainenként, hanem nyitott portokat keres, vagy egy ismert IP-tartományt használó sebezhetőség-keresőt céloz meg, akkor ezek a webhelyek elkerülik a vizsgálatot, és egyszerűen nem DNS név ismerete nélkül látható. Talán korábban legalábbis kimaradtak, és automata eszközeink nem találtak náluk problémát, még akkor sem, ha közvetlenül az erőforráshoz küldték őket.
Egyébként arról, amit a korábban elindított szkennerek általában találtak. Hadd emlékeztesselek: egyesek számára a „pentest” egyenértékű az „automatizált kereséssel”. De a szkennerek ebben a projektben nem mondtak semmit. Nos, a maximumot a Közepes sérülékenységek mutatták (3-ből 5 a súlyosságot tekintve): néhány szolgáltatáson rossz TLS-tanúsítvány vagy elavult titkosítási algoritmusok, illetve a legtöbb oldalon Clickjacking. De ezzel nem fogsz elérni a célod. Itt talán a szkennerek hasznosabbak lennének, de hadd emlékeztessem Önöket: az ügyfél maga is tud ilyen programokat vásárolni és kipróbálni magát velük, és a szomorú eredményekből ítélve már ellenőrizte is.
Térjünk vissza az „anomális” oldalakra. Az első valami olyan, mint egy helyi Wiki nem szabványos címen, de ebben a cikkben legyen wiki.company[.]ru. Azonnal bejelentkezést és jelszót is kért, de a böngésző NTLM-jén keresztül. A felhasználó számára ez egy aszketikus ablaknak tűnik, amely felhasználónév és jelszó megadását kéri. És ez rossz gyakorlat.
Egy kis megjegyzés. Az NTLM a kerületi webhelyeken több okból is rossz. Az első ok az Active Directory tartománynév felfedése. Példánkban ez is company.ru-nak bizonyult, akárcsak a „külső” DNS név. Ennek ismeretében gondosan előkészíthet valami rosszindulatú programot, hogy az csak a szervezet tartományi gépén kerüljön végrehajtásra, és ne valamilyen homokozóban. Másodszor, a hitelesítés közvetlenül a tartományvezérlőn keresztül történik NTLM-en keresztül (meglepetés, ugye?), a „belső” hálózati házirendek minden funkciójával, beleértve a fiókok blokkolását, nehogy túllépjék a jelszóbeviteli kísérletek számát. Ha egy támadó megtudja a bejelentkezéseket, jelszavakat próbál beállítani. Ha úgy van beállítva, hogy blokkolja a fiókokat a helytelen jelszavak beírásától, ez működni fog, és a fiók blokkolva lesz. Harmadszor, lehetetlen egy második tényezőt hozzáadni az ilyen hitelesítéshez. Ha az olvasók közül valaki még tudja, hogyan kell, kérem, jelezze, nagyon érdekes. Negyedszer, sebezhetőség a hash támadásokkal szemben. Az ADFS-t többek között azért találták ki, hogy mindezek ellen védekezzenek.
A Microsoft-termékeknek van egy rossz tulajdonsága: még ha nem is tett közzé konkrétan ilyen NTLM-et, az alapértelmezés szerint telepítve lesz legalább az OWA-ban és a Lync-ben.
A cikk szerzője egyébként egyszer véletlenül egy nagy bank alkalmazottainak körülbelül 1000 számláját zárolta le egyetlen óra alatt ugyanazzal a módszerrel, majd kissé sápadtnak tűnt. A bank informatikai szolgáltatásai is elhalványultak, de minden jól és megfelelően végződött, még dicséretet is kaptunk, hogy elsőként találtuk meg ezt a problémát és provokáltunk gyors és határozott megoldást.
A második webhely címe „nyilvánvalóan valamilyen vezetéknév.company.ru” volt. A Google-n keresztül találtam, valami ilyesmi a 10. oldalon. A dizájn a XNUMX-es évek elejéről-közepéről készült, és egy tekintélyes ember nézte a főoldalról, valami ilyesmi:
Itt készítettem egy állóképet a „Kutyaszívből”, de higgyétek el, halványan hasonlított, még a színvilág is hasonló tónusú volt. Legyen az oldal neve preobrazhensky.company.ru.
Ez egy személyes weboldal volt... egy urológus számára. Kíváncsi voltam, mit csinál egy urológus weboldala egy high-tech cég aldomainjén. Egy gyors túra a Google-ba azt mutatta, hogy ez az orvos társalapítója volt ügyfelünk egyik jogi személyének, és még körülbelül 1000 rubelt is befizetett az alaptőkébe. Az oldal valószínűleg sok évvel ezelőtt jött létre, és az ügyfél szerver erőforrásait használták tárhelyként. Az oldal már rég elvesztette relevanciáját, de valamilyen oknál fogva sokáig nem működött.
Ami a sebezhetőséget illeti, maga a weboldal biztonságos volt. A jövőre nézve azt mondom, hogy statikus információk halmaza volt - egyszerű html oldalak, amelyeken vesék és hólyagok formájában illusztráltak. Hiába „törni” egy ilyen oldalt.
De az alatta lévő webszerver érdekesebb volt. A HTTP Server fejlécéből ítélve IIS 6.0 volt, ami azt jelenti, hogy Windows 2003-at használt operációs rendszerként. A szkenner korábban megállapította, hogy ez a bizonyos urológus webhely, eltérően ugyanazon a webszerveren lévő többi virtuális gazdagéptől, válaszolt a PROPFIND parancsra, vagyis a WebDAV-ot futtatta. A lapolvasó egyébként ezt az információt Info jelzéssel adta vissza (a szkennerjelentések nyelvén ez a legalacsonyabb veszély) - az ilyen dolgokat általában egyszerűen kihagyják. Összességében ez érdekes hatást adott, ami csak egy újabb Google-ásás után derült ki: a Shadow Brokers készlethez kapcsolódó ritka puffertúlcsordulási sérülékenység, nevezetesen a CVE-2017-7269, amelynek már volt kész exploitja. Más szóval, gondok lesznek, ha Windows 2003-at használ, és a WebDAV IIS-en fut. Bár a Windows 2003 éles futtatása 2018-ban önmagában is probléma.
Az exploit a Metasploitban kötött ki, és azonnal tesztelték egy olyan betöltéssel, amely DNS-kérést küldött egy ellenőrzött szolgáltatásnak – a Burp Colaboratorert hagyományosan a DNS-kérések elkapására használják. Meglepetésemre elsőre sikerült: DNS-kiütés érkezett. Ezt követően a 80-as porton keresztül próbáltak visszakapcsolni (vagyis hálózati kapcsolatot létesíteni a kiszolgáló és a támadó között, az áldozat hosztján lévő cmd.exe-hez való hozzáféréssel), de ekkor kudarc történt. A kapcsolat nem jött létre, és az oldal harmadik használati kísérlete után az összes érdekes képpel együtt örökre eltűnt.
Általában ezt egy levél követi „ügyfél, ébredj fel, mindent elejtettünk” stílusban. De azt mondták nekünk, hogy az oldalnak semmi köze az üzleti folyamatokhoz, és minden ok nélkül működik ott, mint az egész szerver, és ezt az erőforrást tetszés szerint használhatjuk.
Körülbelül egy nappal később az oldal hirtelen elkezdett önállóan működni. Az IIS 6.0-s WebDAV-ból egy bench-et építettem fel, és azt tapasztaltam, hogy az alapértelmezett beállítás az IIS-munkafolyamatok 30 óránkénti újraindítása. Ez azt jelenti, hogy amikor a vezérlés kilépett a shellkódból, az IIS worker folyamat befejeződött, majd néhányszor újraindult, majd 30 órára pihent.
Mivel a tcp visszakapcsolása első alkalommal meghiúsult, ezt a problémát egy zárt portnak tulajdonítottam. Vagyis feltételezte valamiféle tűzfal jelenlétét, amely nem engedi, hogy a kimenő kapcsolatok áthaladjanak kívülről. Elkezdtem futtatni shellkódokat, amelyek sok tcp és udp porton keresztül kerestek, nem volt hatás. A fordított kapcsolati betöltések a http(ek)en keresztül a Metasploitból nem működtek – meterpreter/reverse_http(s). Hirtelen létrejött a kapcsolat ugyanahhoz a 80-as porthoz, de azonnal megszakadt. Ezt a még mindig képzeletbeli IPS akciójának tulajdonítottam, ami nem szerette a méteres forgalmat. Annak fényében, hogy a tiszta tcp kapcsolat a 80-as porthoz nem ment át, de a http kapcsolat igen, arra a következtetésre jutottam, hogy a http proxy valahogy be van állítva a rendszerben.
Még a meterpretert is kipróbáltam DNS-en keresztül (köszi erőfeszítéseiért, sok projektet megmentett), felidézve a legelső sikert, de még az állványon sem működött - a shellkód túl terjedelmes volt ehhez a sérülékenységhez.
A valóságban ez így nézett ki: 3-4 támadási kísérlet 5 percen belül, majd 30 óra várakozás. És így tovább három hétig egymás után. Még egy emlékeztetőt is beállítottam, hogy ne veszítsem az időt. Ezenkívül különbség volt a tesztkörnyezet és az éles környezet viselkedésében is: ehhez a sérülékenységhez két hasonló exploit volt, az egyik a Metasploitból, a másik pedig az Internetről származó, a Shadow Brokers verzióból konvertálva. Tehát csak a Metasploitot tesztelték harcban, és csak a másodikat tesztelték a padon, ami még megnehezítette a hibakeresést és agyonverte.
Végül egy shellkód bizonyult hatékonynak, amely http-n keresztül letöltött egy exe fájlt egy adott szerverről, és elindította a célrendszeren. A shellkód elég kicsi volt ahhoz, hogy elférjen, de legalább működött. Mivel a szerver egyáltalán nem szerette a TCP forgalmat, és a http(k)en ellenőrizték a meterpreter jelenlétét, úgy döntöttem, hogy a leggyorsabb módszer egy DNS-meterpretert tartalmazó exe fájl letöltése ezen a shellkódon keresztül.
Itt ismét felmerült egy probléma: egy exe fájl letöltésekor, és ahogy a próbálkozások mutatták, mindegy melyiket, a letöltés megszakadt. Megint valami biztonsági eszköz a szerverem és az urológus között nem szerette a http forgalmat, amiben egy exe található. A „gyors” megoldásnak úgy tűnt, hogy a shellkódot úgy változtatták meg, hogy az menet közben elhomályosítsa a http forgalmat, így az exe helyett absztrakt bináris adatok kerüljenek átvitelre. Végül a támadás sikeres volt, az irányítás a vékony DNS-csatornán keresztül érkezett:
Azonnal világossá vált, hogy rendelkezem a legalapvetőbb IIS-munkafolyamat-jogokkal, amelyek lehetővé teszik, hogy semmit se tegyek. Így nézett ki a Metasploit konzolon:
Minden penteszt módszer határozottan azt sugallja, hogy a hozzáférés megszerzésekor növelni kell a jogosultságokat. Ezt általában nem csinálom helyben, mivel a legelső hozzáférést egyszerűen hálózati belépési pontnak tekintik, és egy másik gép kompromittálása ugyanazon a hálózaton általában egyszerűbb és gyorsabb, mint a jogosultságok kiterjesztése egy meglévő gazdagépen. De itt nem ez a helyzet, mivel a DNS-csatorna nagyon szűk, és nem engedi a forgalom kiürülését.
Feltételezve, hogy ezt a Windows 2003 szervert nem javították ki a híres MS17-010 sebezhetőség miatt, a forgalmat a 445/TCP portra irányítom a meterpreter DNS alagúton keresztül a localhost-on (igen, ez is lehetséges), és megpróbálom futtatni a korábban letöltött exe-t. a sebezhetőséget. A támadás működik, kapok egy második kapcsolatot, de RENDSZER jogokkal.
Érdekesség, hogy továbbra is megpróbálták megvédeni a szervert az MS17-010-től – a külső felületen letiltották a sebezhető hálózati szolgáltatásokat. Ez megvéd a hálózaton keresztüli támadásoktól, de a localhost belülről érkező támadás működött, mivel nem lehet egyszerűen csak gyorsan kikapcsolni az SMB-t a localhost-on.
Ezután újabb érdekes részletek derülnek ki:
- RENDSZERjogosultság birtokában könnyen létesíthet visszakapcsolást TCP-n keresztül. Nyilvánvaló, hogy a közvetlen TCP letiltása szigorúan a korlátozott IIS-felhasználók számára jelent problémát. Spoiler: az IIS felhasználói forgalmat valahogy mindkét irányban becsomagolták a helyi ISA Proxyba. Hogy pontosan hogyan működik, azt nem reprodukáltam.
- Egy bizonyos „DMZ”-ben vagyok (és ez nem egy Active Directory tartomány, hanem egy WORKGROUP) – logikusan hangzik. De a várt privát („szürke”) IP-cím helyett egy teljesen „fehér” IP-címem van, pontosan ugyanaz, mint amit korábban támadtam. Ez azt jelenti, hogy a cég annyira öreg az IPv4-címzés világában, hogy megengedheti magának, hogy a 128-ös Cisco kézikönyvekben bemutatott séma szerint 2005 „fehér” címhez DMZ zónát tartson fenn NAT nélkül.
Mivel a szerver régi, a Mimikatz garantáltan közvetlenül a memóriából működik:
Megkapom a helyi rendszergazdai jelszót, átvezetem az RDP-forgalmat TCP-n keresztül, és bejelentkezek egy hangulatos asztalra. Mivel bármit csinálhattam a szerverrel, eltávolítottam a víruskeresőt, és megállapítottam, hogy a szerver csak a 80-as és 443-as TCP-portokon keresztül érhető el az internetről, és a 443-as nem volt foglalt. Beállítok egy OpenVPN-kiszolgálót a 443-on, hozzáadok NAT-funkciókat a VPN-forgalmamhoz, és közvetlen hozzáférést kapok a DMZ-hálózathoz korlátlan formában az OpenVPN-en keresztül. Figyelemre méltó, hogy az ISA néhány nem letiltott IPS funkcióval portszkenneléssel blokkolta a forgalmamat, amihez le kellett cserélni egy egyszerűbb és kompatibilisebb RRAS-ra. Így a pentesztereknek néha még mindig mindenfélét kell adminisztrálniuk.
Egy figyelmes olvasó megkérdezi: "Mi a helyzet a második oldallal - egy NTLM hitelesítésű wikivel, amelyről annyit írtak?" Erről később.
2. rész. Még mindig nem titkosítja? Akkor már itt jövünk hozzád
Tehát elérhető a DMZ hálózati szegmens. A domain rendszergazdájához kell fordulnia. Az első dolog, ami eszünkbe jut, az, hogy automatikusan ellenőrizzük a DMZ szegmensen belüli szolgáltatások biztonságát, különösen azért, mert ezek közül most sokkal több van kutatásra nyitva. Tipikus kép egy penetrációs teszt során: a külső kerület jobban védett, mint a belső szolgáltatások, és egy nagy infrastruktúrán belüli hozzáférés megszerzésekor sokkal könnyebb a kiterjesztett jogok megszerzése egy tartományban, csak annak köszönhetően, hogy ez a tartomány elkezd az eszközök számára elérhető, másodszor: Egy több ezer gazdagéppel rendelkező infrastruktúrában mindig lesz néhány kritikus probléma.
A szkennereket DMZ-n keresztül OpenVPN alagúton keresztül töltöm, és várok. Megnyitom a jelentést - megint semmi komoly, láthatóan valaki előttem járt át ugyanezen a módszeren. A következő lépés annak megvizsgálása, hogyan kommunikálnak a DMZ hálózaton belüli gazdagépek. Ehhez először indítsa el a szokásos Wiresharkot, és figyelje meg a közvetítési kéréseket, elsősorban az ARP-t. Az ARP-csomagokat egész nap gyűjtötték. Kiderült, hogy ebben a szegmensben számos átjárót használnak. Ez később jól fog jönni. Az ARP-kérésekre és válaszokra vonatkozó adatok, valamint a portszkennelési adatok kombinálásával megtaláltam a helyi hálózaton belüli felhasználói forgalom kilépési pontjait a korábban ismert szolgáltatásokon kívül, mint például a web és a levelezés.
Mivel jelenleg nem fértem hozzá más rendszerekhez, és nem volt egyetlen fiókom sem a vállalati szolgáltatásokhoz, ezért úgy döntöttek, hogy legalább egy fiókot kihalászok a forgalomból az ARP Spoofing segítségével.
A Cain&Abel elindult az urológus szerverén. Az azonosított forgalmi áramlások figyelembevételével kiválasztásra kerültek a man-in-the-middle támadás legígéretesebb párjai, majd rövid távú, 5-10 perces indítással érkezett némi hálózati forgalom, a szerver újraindításához szükséges időzítővel. fagyás esetén. Mint a viccben, két hír is volt:
- Jó: sok igazolást elkaptak, és a támadás összességében működött.
- A rossz: minden hitelesítő adat az ügyfél saját ügyfeleitől származott. A támogatási szolgáltatások nyújtása közben az ügyfélspecialisták olyan ügyfelek szolgáltatásaihoz kapcsolódtak, akiknél nem volt mindig konfigurálva a forgalom titkosítása.
Ennek eredményeként sok olyan hitelesítést szereztem, amelyek a projekttel összefüggésben haszontalanok voltak, de mindenképpen érdekesek a támadás veszélyének demonstrálásaként. Nagyvállalatok határmenti útválasztói telnettel, továbbított hibakeresési http portok a belső CRM-hez az összes adattal, közvetlen hozzáférés az RDP-hez a Windows XP-ből a helyi hálózaton és egyéb homályos. Így alakult .
Találtam is egy vicces lehetőséget, hogy leveleket gyűjtsek a forgalomból, ilyesmi. Ez egy példa egy kész levélre, amely ügyfelünktől az ügyfele SMTP-portjára ment, ismét titkosítás nélkül. Egy bizonyos Andrey megkéri névrokonát, hogy küldje el újra a dokumentációt, és az egy válaszlevélben felkerül egy felhőlemezre a bejelentkezéssel, jelszóval és hivatkozással:
Ez egy újabb emlékeztető az összes szolgáltatás titkosítására. Nem ismert, hogy konkrétan ki és mikor fogja elolvasni és felhasználni az Ön adatait - a szolgáltató, egy másik cég rendszergazdája vagy egy ilyen pentester. Nem hallgatok arról, hogy sokan egyszerűen el tudják fogni a titkosítatlan forgalmat.
A látszólagos siker ellenére ez nem vitt közelebb a célhoz. Lehetett persze sokáig ülni és értékes információkat halászni, de nem tény, hogy ott megjelennének, és maga a támadás is nagyon kockázatos a hálózat integritása szempontjából.
A szolgáltatásokban való újabb ásás után egy érdekes ötlet jutott eszembe. Létezik egy Responder nevű segédprogram (könnyű példákat találni ezen a néven), amely a broadcast kérések „megmérgezésével” kapcsolatokat vált ki különféle protokollokon, például SMB, HTTP, LDAP stb. különböző módokon, majd megkér mindenkit, aki csatlakozik, hogy hitelesítsen, és úgy állítsa be, hogy a hitelesítés NTLM-en keresztül és az áldozat számára átlátható módban történjen. A támadók leggyakrabban ilyen módon gyűjtik a NetNTLMv2 kézfogásokat, és azokból egy szótár segítségével gyorsan visszaállítják a felhasználói tartomány jelszavait. Itt valami hasonlót szerettem volna, de a felhasználók „fal mögé” ültek, pontosabban tűzfallal választották el őket, és a Blue Coat proxy klaszteren keresztül jutottak el a WEB-re.
Emlékszel, megadtam, hogy az Active Directory tartományneve egybeesik a „külső” tartománynévvel, azaz company.ru? Tehát a Windows, pontosabban az Internet Explorer (és az Edge és a Chrome) lehetővé teszi a felhasználó számára, hogy transzparensen hitelesítsen HTTP-n keresztül NTLM-en keresztül, ha úgy gondolja, hogy a webhely valamilyen „intranet zónában” található. Az „intranet” egyik jele a „szürke” IP-címhez vagy egy rövid DNS-névhez való hozzáférés, azaz pontok nélkül. Mivel volt egy „fehér” IP- és DNS-nevű szerverük, preobrazhensky.company.ru, és a tartománygépek általában DHCP-n keresztül kapják meg az Active Directory tartományutótagját az egyszerűsített névbevitel érdekében, csak az URL-t kellett beírniuk a címsorba. , hogy megtalálják a megfelelő utat a kompromittált urológus szerveréhez, nem feledkezve meg arról sem, hogy ezt most „Intranet”-nek hívják. Vagyis ezzel egyidejűleg a felhasználó tudta nélkül megadom a NTLM-kézfogást. Már csak arra kell kényszeríteni a kliensböngészőket, hogy gondoljanak arra, hogy sürgősen kapcsolatba kell lépniük ezzel a szerverrel.
A csodálatos Intercepter-NG segédprogram segített (köszönjük ). Lehetővé tette a forgalom menet közbeni megváltoztatását, és kiválóan működött a Windows 2003 rendszeren. Még külön funkcióval is rendelkezett, amellyel csak JavaScript-fájlokat lehetett módosítani a forgalom áramlásában. Egyfajta hatalmas Cross-Site Scriptinget terveztek.
A Blue Coat proxy, amelyen keresztül a felhasználók hozzáfértek a globális WEB-hez, rendszeresen gyorsítótárazták a statikus tartalmat. A forgalom elfogásával egyértelmű volt, hogy éjjel-nappal dolgoznak, és vég nélkül kérték a gyakran használt statikát, hogy felgyorsítsák a tartalom megjelenítését csúcsidőben. Ezenkívül a BlueCoatnak volt egy speciális felhasználói ügynöke, amely egyértelműen megkülönböztette a valódi felhasználótól.
Elkészült a Javascript, amelyet az Intercepter-NG használatával éjszaka egy órán keresztül implementáltak minden egyes válaszhoz JS fájlokkal a Blue Coat számára. A forgatókönyv a következőket tette:
- Az aktuális böngészőt a User-Agent határozta meg. Ha Internet Explorer, Edge vagy Chrome volt, továbbra is működött.
- Megvártam míg létrejön az oldal DOM-ja.
- Egy láthatatlan képet szúrt be a DOM-ba az űrlap src attribútumával :8080/NNNNNNN.png, ahol az NNN tetszőleges számok, így a BlueCoat ne tárolja a gyorsítótárban.
- Állítson be egy globális jelző változót, amely azt jelzi, hogy a befecskendezés befejeződött, és nincs szükség többé képek beszúrására.
A böngésző megpróbálta betölteni ezt a képet, a kompromittált szerver 8080-as portján egy TCP alagút várta a laptopom felé, ahol ugyanaz a válaszadó futott, amihez a böngészőnek NTLM-en keresztül kellett bejelentkeznie.
A Responder naplóiból ítélve az emberek reggel munkába érkeztek, bekapcsolták munkaállomásaikat, majd tömegesen és észrevétlenül elkezdték látogatni az urológus szerverét, nem feledkezve meg az NTLM kézfogások „leeresztéséről”. Egész nap záporoztak a kézfogások, és egyértelműen felhalmozódott az anyag egy nyilvánvalóan sikeres jelszavak visszaszerzésére irányuló támadáshoz. Így néztek ki a válaszadó naplói:
A felhasználók tömeges titkos látogatásai az urológus szerveren
Valószínűleg Ön is észrevette már, hogy ez az egész történet a „minden rendben volt, de volt egy zűrzavar, majd egy legyőzés, aztán minden sikeres volt” elven épül fel. Szóval volt itt egy balhé. Az ötven egyedi kézfogásból egy sem derült ki. És ez figyelembe veszi azt a tényt, hogy ezek az NTLMv2 kézfogások másodpercenként több százmillió próbálkozásos sebességgel dolgoznak még egy halott processzorral rendelkező laptopon is.
Jelszómutációs technikákkal, videokártyával, vastagabb szótárral kellett felvérteznem magam és várnom. Hosszú idő után több „Q11111111....1111111q” formátumú jelszóval rendelkező fiók került napvilágra, ami arra utal, hogy egykor minden felhasználó kénytelen volt egy nagyon hosszú, különböző karaktereket tartalmazó jelszót kitalálni, aminek szintén az volt a célja, hogy legyen összetett. De egy tapasztalt felhasználót nem lehet becsapni, és így tette könnyebbé az emlékezést. Összesen körülbelül 5 fiókot sértettek fel, és ezek közül csak egynek volt értékes joga a szolgáltatásokhoz.
3. rész. A Roskomnadzor visszavág
Tehát megérkeztek az első domain fiókok. Ha eddig nem aludt el hosszas olvasás után, akkor valószínűleg emlékezni fog arra, hogy említettem egy szolgáltatást, amely nem igényel második hitelesítési tényezőt: ez egy NTLM hitelesítésű wiki. Természetesen az első dolgunk az volt, hogy belépjünk oda. A belső tudásbázisba való beleásás gyorsan meghozta az eredményeket:
- A cég Wi-Fi-hálózattal rendelkezik, a helyi hálózathoz való hozzáféréssel rendelkező domain fiókok segítségével történő hitelesítéssel. A jelenlegi adatkészlettel ez már működő támadási vektor, de lábbal kell menni az irodába, és valahol az ügyfél irodájának területén kell elhelyezkedni.
- Találtam egy utasítást, amely szerint volt egy szolgáltatás, amely lehetővé tette... egy „második faktoros” hitelesítő eszköz önálló regisztrálását, ha a felhasználó helyi hálózaton belül van, és magabiztosan emlékszik a domain bejelentkezési nevére és jelszavára. Ebben az esetben a „belül” és a „kint” a szolgáltatás portjának felhasználó számára való elérhetősége határozta meg. A port nem volt elérhető az internetről, de a DMZ-n keresztül eléggé elérhető volt.
Természetesen egy „második faktor” azonnal bekerült a feltört fiókba egy alkalmazás formájában a telefonomon. Volt olyan program, ami vagy hangosan küldhetett push kérést a telefonra „jóváhagy”/„elutasítás” gombokkal az akcióhoz, vagy hangtalanul megmutatta a képernyőn az OTP kódot a további önálló belépéshez. Ráadásul az első módszert az utasítások szerint az egyetlen helyesnek tartották, de az OTP módszerrel ellentétben nem működött.
A „második tényező” megszakadásával elérhettem az Outlook Web Access leveleit és távoli hozzáférést a Citrix Netscaler Gateway-ben. Meglepetés érkezett az Outlook levélben:
Ezen a ritka felvételen láthatja, hogyan segíti a Roszkomnadzor a behatolókat
Ezek voltak az első hónapok a Telegram híres „rajongói” blokkolása után, amikor több ezer címet tartalmazó teljes hálózatok menthetetlenül eltűntek a hozzáférésből. Világossá vált, hogy miért nem működött azonnal a lökés, és miért nem riaszt az „áldozatom”, mert nyitott időben kezdték használni a fiókját.
Bárki, aki ismeri a Citrix Netscalert, azt képzeli, hogy általában úgy valósítják meg, hogy csak egy képi felületet tudjon eljuttatni a felhasználóhoz, igyekszik nem adni neki eszközöket harmadik féltől származó alkalmazások indításához és adatátvitelhez, minden lehetséges módon korlátozva a műveleteket. szabványos vezérlőhéjakon keresztül. Az „áldozatom” foglalkozása miatt csak 1C-t kapott:
Miután egy kicsit körbejártam az 1C felületet, rájöttem, hogy vannak ott külső feldolgozó modulok. A felületről tölthetők be, és a jogosultságoktól és beállításoktól függően a kliensen vagy a szerveren futnak le.
Megkértem az 1C programozó barátaimat, hogy hozzanak létre egy feldolgozást, amely elfogad egy karakterláncot és végrehajtja azt. 1C nyelven egy folyamat elindítása valahogy így néz ki (az internetről vettük). Egyetért azzal, hogy az 1C nyelv szintaxisa lenyűgözi az oroszul beszélő embereket a spontaneitásával?
A feldolgozás tökéletesen lezajlott, kiderült, hogy a penteszterek „shellnek” hívják – ezen keresztül indult el az Internet Explorer.
Korábban egy olyan rendszer címét találták meg a levélben, amely lehetővé teszi a területre szóló bérletek rendelését. Rendeltem egy bérletet arra az esetre, ha WiFi támadási vektort kell használnom.
A neten arról beszélnek, hogy a vevő irodájában még volt finom ingyenes vendéglátás, de én mégis inkább távolról fejlesztem a támadást, az nyugodtabb.
Az AppLocker aktiválva volt a Citrixet futtató alkalmazáskiszolgálón, de megkerülte. Ugyanaz a Meterpreter lett betöltve és elindítva DNS-en keresztül, mivel a http(s) verziók nem akartak kapcsolódni, és a belső proxy címét sem tudtam akkor. Egyébként ettől a pillanattól kezdve a külső pentest lényegében teljesen belsővé változott.
4. rész. A felhasználók rendszergazdai jogai rosszak, oké?
A tartományfelhasználói munkamenet irányításának átvételekor a pentester első feladata az, hogy összegyűjtse a tartomány jogaira vonatkozó összes információt. Létezik egy BloodHound segédprogram, amely automatikusan lehetővé teszi a felhasználókról, számítógépekről, biztonsági csoportokról szóló információk letöltését az LDAP protokollon keresztül egy tartományvezérlőről, illetve az SMB-n keresztül - információkat arról, hogy melyik felhasználó hova jelentkezett be nemrég, és ki a helyi rendszergazda.
A tartományadminisztrátori jogok lefoglalásának tipikus technikája monoton műveletek ciklusának tűnik leegyszerűsítve:
- Olyan tartományi számítógépekre megyünk, ahol helyi rendszergazdai jogosultságok vannak, a már rögzített tartományfiókok alapján.
- Elindítjuk a Mimikatz-ot, és megkapjuk a gyorsítótárazott jelszavakat, Kerberos-jegyeket és az ebbe a rendszerbe nemrég bejelentkezett tartományfiókok NTLM-kivonatait. Vagy eltávolítjuk az lsass.exe folyamat memóriaképét, és ugyanezt megtesszük a mi oldalunkon. Ez jól működik a 2012R2-nél fiatalabb/Windows 8.1-nél, alapértelmezett beállításokkal.
- Meghatározzuk, hogy a feltört fiókok hol rendelkeznek helyi rendszergazdai jogokkal. Megismételjük az első pontot. Egy bizonyos szakaszban rendszergazdai jogosultságokat szerezünk a teljes domainhez.
„End of the Cycle;”, ahogy az 1C programozók írnák itt.
Így a felhasználónk helyi rendszergazdának bizonyult egyetlen Windows 7-es gépen, amelynek neve a „VDI” szót vagy a „Virtual Desktop Infrastructure” szót tartalmazza, személyes virtuális gépeken. Valószínűleg a VDI szolgáltatás tervezője arra gondolt, hogy mivel a VDI a felhasználó személyes operációs rendszere, hiába változtatja a felhasználó tetszés szerint a szoftverkörnyezetet, a gazdagépet akkor is „újra lehet tölteni”. Én is úgy gondoltam, hogy az ötlet általánosságban jó, elmentem ehhez a személyes VDI-házhoz, és ott fészkeltem:
- Ott telepítettem egy OpenVPN klienst, amely az interneten keresztül alagutat vezetett a szerveremhez. Az ügyfelet arra kellett kényszeríteni, hogy ugyanazon a Blue Coat-on menjen át domain-hitelesítéssel, de az OpenVPN megtette, ahogy mondani szokták, „a dobozból”.
- OpenSSH telepítve VDI-re. Nos, valójában mi a Windows 7 SSH nélkül?
Így nézett ki élőben. Hadd emlékeztesselek arra, hogy mindezt a Citrixen és az 1C-n keresztül kell megtenni:
A szomszédos számítógépekhez való hozzáférés elősegítésének egyik módja a helyi rendszergazdai jelszavak egyezésének ellenőrzése. Itt a szerencse azonnal várt: az alapértelmezett helyi adminisztrátor NTLM-kivonatát (akit hirtelen Adminisztrátornak hívtak) egy pass-the-hash támadáson keresztül eljuttatták a szomszédos VDI-állomásokhoz, amelyekből több száz volt. A támadás természetesen azonnal érte őket.
Itt a VDI rendszergazdái kétszer lábon lőtték magukat:
- Az első alkalom az volt, amikor a VDI-gépeket nem helyezték át a LAPS alá, lényegében ugyanazt a helyi rendszergazdai jelszót tartották meg a lemezképből, amelyet tömegesen telepítettek a VDI-re.
- Az alapértelmezett adminisztrátor az egyetlen olyan helyi fiók, amely sebezhető a hash átadási támadásokkal szemben. Még ugyanazzal a jelszóval is elkerülhető lenne a tömeges kompromisszum, ha létrehozunk egy második helyi rendszergazdai fiókot egy összetett véletlenszerű jelszóval, és blokkoljuk az alapértelmezettet.
Miért van SSH szolgáltatás azon a Windowson? Nagyon egyszerű: most az OpenSSH szerver nemcsak kényelmes interaktív parancshéjat biztosított a felhasználó munkájának megzavarása nélkül, hanem egy socks5 proxyt is a VDI-n. Ezen zoknikon keresztül SMB-n keresztül csatlakoztam, és összegyűjtöttem a gyorsítótárazott fiókokat több száz VDI-gépről, majd a BloodHound grafikonokon kerestem a domain rendszergazdához vezető utat. Több száz házigazdával a rendelkezésemre állva elég hamar rátaláltam erre az útra. A domain rendszergazdai jogosultságait megszereztük.
Itt van egy kép az internetről, amely hasonló keresést mutat. A kapcsolatok megmutatják, hogy ki hol van az adminisztrátor, és ki hol van bejelentkezve.
Mellesleg, emlékezzen a projekt kezdetétől fogva a feltételre - „ne használjon social engineering”. Tehát azt javaslom, hogy gondolkodjunk el azon, hogy ez a speciális effektusokkal ellátott Bollywood mennyire lenne elvágva, ha továbbra is lehetséges lenne a banális adathalászat. De személy szerint számomra nagyon érdekes volt mindezt csinálni. Remélem, örömmel olvastad ezt. Természetesen nem minden projekt tűnik ennyire érdekfeszítőnek, de a munka egésze nagyon nagy kihívást jelent, és nem engedi, hogy stagnáljon.
Valószínűleg valakinek lesz kérdése: hogyan védheti meg magát? Még ez a cikk is számos technikát ír le, amelyek közül sok a Windows rendszergazdák nem is tudnak. Azt javaslom azonban, hogy ezeket az elcsépelt elvek és információbiztonsági intézkedések szemszögéből nézzük:
- ne használjon elavult szoftvert (emlékszik a Windows 2003-ra az elején?)
- ne tartsa bekapcsolva a felesleges rendszereket (miért volt az urológus honlapja?)
- ellenőrizze saját maga a felhasználói jelszavakat (különben a katonák... a pentesterek ezt teszik)
- nem ugyanaz a jelszava a különböző fiókokhoz (VDI-kompromisszum)
- és egyéb
Természetesen ezt nagyon nehéz megvalósítani, de a következő cikkben megmutatjuk a gyakorlatban, hogy ez teljesen lehetséges.
Forrás: will.com