Er was eens een pentest, of hoe je alles kunt breken met de hulp van een uroloog en Roskomnadzor

Dit artikel is geschreven op basis van een zeer succesvolle pentest die specialisten van Group-IB een paar jaar geleden uitvoerden: er gebeurde een verhaal dat verfilmd kon worden in Bollywood. Nu volgt waarschijnlijk de reactie van de lezer: “Oh, nog een PR-artikel, deze worden weer in beeld gebracht, wat zijn ze goed, vergeet niet een pentest te kopen.” Nou, aan de ene kant is dat wel zo. Er zijn echter nog een aantal andere redenen waarom dit artikel verscheen. Ik wilde laten zien wat pentesters precies doen, hoe interessant en niet-triviaal dit werk kan zijn, welke grappige omstandigheden zich kunnen voordoen in projecten, en vooral: live materiaal laten zien met echte voorbeelden.

Om het evenwicht van bescheidenheid in de wereld te herstellen, zullen we na een tijdje schrijven over een pentest die niet goed is verlopen. We zullen laten zien hoe goed ontworpen processen in een bedrijf bescherming kunnen bieden tegen een hele reeks aanvallen, zelfs goed voorbereide, simpelweg omdat deze processen bestaan ​​en daadwerkelijk werken.

Voor de klant in dit artikel was alles over het algemeen ook uitstekend, in ieder geval beter dan 95% van de markt in de Russische Federatie, volgens onze gevoelens, maar er waren een aantal kleine nuances die een lange reeks gebeurtenissen vormden, die eerst leidde tot een lang verslag over het werk, en vervolgens tot dit artikel.

Dus laten we popcorn inslaan, en welkom bij het detectiveverhaal. Woord - Pavel Suprunyuk, technisch manager van de afdeling “Audit en Consulting” van Group-IB.

Deel 1. Pochkin-arts

2018 Er is een klant: een hightech IT-bedrijf, dat zelf veel klanten bedient. Wil antwoord krijgen op de vraag: is het mogelijk, zonder enige initiële kennis en toegang, werkend via internet, Active Directory domeinbeheerdersrechten te verkrijgen? Ik ben niet geïnteresseerd in social engineering (O, maar tevergeefs), het is niet de bedoeling dat ze het werk expres verstoren, maar ze kunnen per ongeluk een vreemd werkende server herladen, bijvoorbeeld. Een bijkomend doel is om zoveel mogelijk andere aanvalsvectoren tegen de buitenste perimeter te identificeren. Het bedrijf voert regelmatig dergelijke tests uit en nu is de deadline voor een nieuwe test aangebroken. De omstandigheden zijn bijna typisch, adequaat en begrijpelijk. Laten we beginnen.

Er is een naam van de klant - laat deze 'Bedrijf' zijn, met de hoofdwebsite www.bedrijf.ru. Natuurlijk wordt de klant anders genoemd, maar in dit artikel zal alles onpersoonlijk zijn.
Ik voer netwerkverkenning uit - ontdek welke adressen en domeinen bij de klant zijn geregistreerd, teken een netwerkdiagram, hoe diensten naar deze adressen worden gedistribueerd. Ik krijg het resultaat: meer dan 4000 live IP-adressen. Ik kijk naar de domeinen in deze netwerken: gelukkig zijn het voor het overgrote deel netwerken die bedoeld zijn voor de klanten van de klant, en daar zijn wij formeel niet in geïnteresseerd. De klant denkt er hetzelfde over.

Er blijft één netwerk over met 256 adressen, waarvoor er op dit moment al inzicht is in de verdeling van domeinen en subdomeinen via IP-adressen, er is informatie over de gescande poorten, wat betekent dat je naar de services kunt kijken voor interessante. Tegelijkertijd worden allerlei scanners gelanceerd op beschikbare IP-adressen en afzonderlijk op websites.

Er zijn veel diensten. Meestal is dit vreugde voor de pentester en het vooruitzicht op een snelle overwinning, want hoe meer diensten er zijn, hoe groter het aanvalsveld en hoe gemakkelijker het is om een ​​artefact te vinden. Een snelle blik op de websites leerde dat het merendeel webinterfaces zijn van bekende producten van grote mondiale bedrijven, die je duidelijk vertellen dat ze niet welkom zijn. Ze vragen om een ​​gebruikersnaam en wachtwoord, schudden het veld leeg voor het invoeren van de tweede factor, vragen om een ​​TLS-clientcertificaat of sturen dit naar Microsoft ADFS. Sommige zijn eenvoudigweg niet toegankelijk via internet. Voor sommigen moet je uiteraard een speciaal betaalde klant hebben voor drie salarissen of de exacte URL weten die je moet invoeren. Laten we nog een week van geleidelijke moedeloosheid overslaan in het proces van het proberen softwareversies te ‘doorbreken’ op bekende kwetsbaarheden, het zoeken naar verborgen inhoud in webpaden en gelekte accounts van diensten van derden zoals LinkedIn, en het proberen wachtwoorden te raden door ze te gebruiken. zoals het opgraven van kwetsbaarheden in zelfgeschreven websites – volgens de statistieken is dit tegenwoordig trouwens de meest veelbelovende vector van externe aanvallen. Ik zal onmiddellijk het filmgeweer opmerken dat vervolgens afvuurde.

We hebben dus twee sites gevonden die zich onderscheidden van honderden services. Deze sites hadden één ding gemeen: als je je netwerk niet nauwgezet per domein onderzoekt, maar frontaal op zoek gaat naar open poorten of een kwetsbaarheidsscanner target met een bekend IP-bereik, dan zullen deze sites aan het scannen ontsnappen en eenvoudigweg niet worden gescand. zichtbaar zonder de DNS-naam te kennen. Misschien zijn ze in ieder geval eerder gemist en hebben onze automatische tools er geen problemen mee gevonden, ook al werden ze rechtstreeks naar de bron gestuurd.

Trouwens, over wat eerder gelanceerde scanners in het algemeen vonden. Laat me je eraan herinneren: voor sommige mensen is “pentest” gelijk aan “geautomatiseerde scan”. Maar de scanners van dit project zeiden niets. Welnu, het maximum werd aangetoond door middelmatige kwetsbaarheden (3 van de 5 in termen van ernst): op sommige diensten een slecht TLS-certificaat of verouderde encryptie-algoritmen, en op de meeste sites Clickjacking. Maar hiermee bereik je je doel niet. Misschien zouden scanners hier nuttiger zijn, maar laat me je eraan herinneren: de klant kan zelf dergelijke programma's kopen en zichzelf ermee testen, en, afgaande op de sombere resultaten, heeft hij het al gecontroleerd.

Laten we terugkeren naar de “afwijkende” sites. De eerste is zoiets als een lokale Wiki op een niet-standaard adres, maar in dit artikel is het wiki.company[.]ru. Ze vroeg ook meteen om een ​​login en wachtwoord, maar dan via NTLM in de browser. Voor de gebruiker lijkt dit op een ascetisch venster waarin wordt gevraagd een gebruikersnaam en wachtwoord in te voeren. En dit is een slechte gewoonte.

Een kleine opmerking. NTLM op perimeterwebsites is om een ​​aantal redenen slecht. De eerste reden is dat de Active Directory-domeinnaam wordt onthuld. In ons voorbeeld bleek het ook company.ru te zijn, net als de “externe” DNS-naam. Als u dit weet, kunt u zorgvuldig iets kwaadaardigs voorbereiden, zodat het alleen op de domeinmachine van de organisatie wordt uitgevoerd, en niet in een of andere sandbox. Ten tweede verloopt de authenticatie rechtstreeks via de domeincontroller via NTLM (verrassing, toch?), met alle kenmerken van het “interne” netwerkbeleid, inclusief het blokkeren van accounts tegen het overschrijden van het aantal wachtwoordinvoerpogingen. Als een aanvaller de logins ontdekt, zal hij er wachtwoorden voor proberen. Als u bent geconfigureerd om te voorkomen dat accounts onjuiste wachtwoorden invoeren, werkt dit en wordt het account geblokkeerd. Ten derde is het onmogelijk om een ​​tweede factor aan een dergelijke authenticatie toe te voegen. Als een van de lezers nog steeds weet hoe, laat het me dan weten, het is echt interessant. Ten vierde de kwetsbaarheid voor pass-the-hash-aanvallen. ADFS is onder meer uitgevonden om hiertegen te beschermen.

Er is één slechte eigenschap van Microsoft-producten: zelfs als u dergelijke NTLM niet specifiek heeft gepubliceerd, wordt deze in ieder geval standaard geïnstalleerd in OWA en Lync.

Overigens heeft de auteur van dit artikel ooit op dezelfde manier in één uur per ongeluk ongeveer 1000 rekeningen van medewerkers van één grote bank geblokkeerd en keek toen wat bleekjes. Ook de IT-diensten van de bank waren bleek, maar alles liep goed en adequaat af, we werden zelfs geprezen omdat we de eerste waren die dit probleem ontdekten en een snelle en beslissende oplossing uitlokten.

De tweede site had het adres “duidelijk een soort achternaam.bedrijf.ru.” Vond het via Google, zoiets als dit op pagina 10. Het ontwerp stamde uit het begin van de jaren XNUMX en een respectabel persoon bekeek het vanaf de hoofdpagina, ongeveer zo:

Hier heb ik een still genomen uit "Heart of a Dog", maar geloof me, het leek vaag op elkaar, zelfs het kleurontwerp had dezelfde tinten. Laat de site gebeld worden preobrazhensky.company.ru.

Het was een persoonlijke website... voor een uroloog. Ik vroeg me af wat de website van een uroloog deed op het subdomein van een hightechbedrijf. Een snelle zoektocht op Google toonde aan dat deze arts mede-oprichter was van een van de juridische entiteiten van onze klant en zelfs ongeveer 1000 roebel aan het toegestane kapitaal had bijgedragen. De site is waarschijnlijk vele jaren geleden gemaakt en de serverbronnen van de klant werden gebruikt als hosting. De site heeft zijn relevantie al lang verloren, maar om de een of andere reden bleef hij lange tijd actief.

Wat betreft kwetsbaarheden was de website zelf veilig. Vooruitkijkend zal ik zeggen dat het een reeks statische informatie was: eenvoudige HTML-pagina's met ingevoegde illustraties in de vorm van nieren en blazen. Het heeft geen zin om zo’n site te ‘breken’.

Maar de webserver eronder was interessanter. Afgaande op de HTTP Server-header had het IIS 6.0, wat betekent dat het Windows 2003 als besturingssysteem gebruikte. De scanner had eerder vastgesteld dat deze specifieke urologenwebsite, in tegenstelling tot andere virtuele hosts op dezelfde webserver, reageerde op het PROPFIND-commando, wat betekende dat er WebDAV op draaide. Overigens heeft de scanner deze informatie geretourneerd met de markering Info (in de taal van scannerrapporten is dit het laagste gevaar) - zulke dingen worden meestal gewoon overgeslagen. In combinatie gaf dit een interessant effect, dat pas na een nieuwe zoektocht op Google aan het licht kwam: een zeldzame bufferoverflow-kwetsbaarheid geassocieerd met de Shadow Brokers-set, namelijk CVE-2017-7269, die al een kant-en-klare exploit had. Met andere woorden: er zullen problemen optreden als u Windows 2003 gebruikt en WebDAV op IIS draait. Hoewel het in 2003 in productie nemen van Windows 2018 een probleem op zich is.

De exploit kwam terecht in Metasploit en werd meteen getest met een load die een DNS-verzoek naar een gecontroleerde dienst stuurde - Burp Collaborator wordt traditioneel gebruikt om DNS-verzoeken op te vangen. Tot mijn verbazing werkte het de eerste keer: er werd een DNS-knock-out ontvangen. Vervolgens werd geprobeerd een backconnect te maken via poort 80 (dat wil zeggen een netwerkverbinding van de server naar de aanvaller, met toegang tot cmd.exe op de host van het slachtoffer), maar toen gebeurde er een fiasco. De verbinding kwam niet tot stand en na de derde poging om de site te gebruiken, samen met alle interessante foto's, verdween deze voor altijd.

Meestal wordt dit gevolgd door een brief in de stijl van “klant, word wakker, we hebben alles laten vallen.” Maar ons werd verteld dat de site niets met bedrijfsprocessen te maken heeft en daar zonder enige reden werkt, zoals de hele server, en dat we deze bron kunnen gebruiken zoals we willen.
Ongeveer een dag later begon de site plotseling zelfstandig te werken. Nadat ik een bench van WebDAV op IIS 6.0 had gebouwd, ontdekte ik dat de standaardinstelling is om IIS-werkprocessen elke 30 uur opnieuw te starten. Dat wil zeggen, toen de besturing de shellcode verliet, eindigde het IIS-werkproces, waarna het zichzelf een paar keer opnieuw opstartte en vervolgens 30 uur bleef rusten.

Omdat de backconnect met TCP de eerste keer mislukte, schreef ik dit probleem toe aan een gesloten poort. Dat wil zeggen, hij ging uit van de aanwezigheid van een soort firewall waardoor uitgaande verbindingen niet naar buiten konden gaan. Ik begon shellcodes uit te voeren die door vele TCP- en UDP-poorten zochten, maar er was geen effect. Omgekeerde verbindingsbelastingen via http(s) van Metasploit werkten niet - meterpreter/reverse_http(s). Plotseling werd er een verbinding met dezelfde poort 80 tot stand gebracht, maar deze werd onmiddellijk verbroken. Ik schreef dit toe aan de actie van de nog denkbeeldige IPS, die het meterpreterverkeer niet leuk vond. In het licht van het feit dat een pure TCP-verbinding met poort 80 niet doorkwam, maar een http-verbinding wel, concludeerde ik dat er op de een of andere manier een http-proxy in het systeem was geconfigureerd.

Ik heb zelfs meterpreter via DNS geprobeerd (bedankt d00kie voor je inspanningen, heb veel projecten gered), herinnerend aan het allereerste succes, maar het werkte niet eens op de stand - de shellcode was te omvangrijk voor deze kwetsbaarheid.

In werkelijkheid zag het er zo uit: 3-4 aanvalspogingen binnen 5 minuten, daarna 30 uur wachten. En zo gaat het drie weken achter elkaar door. Ik heb zelfs een herinnering ingesteld om geen tijd te verspillen. Bovendien was er een verschil in het gedrag van de test- en productieomgeving: voor dit beveiligingslek waren er twee vergelijkbare exploits, één van Metasploit, de tweede van internet, omgezet van de Shadow Brokers-versie. Dus alleen Metasploit werd getest in de strijd, en alleen de tweede werd getest op de bank, wat het debuggen nog moeilijker maakte en hersenkrakend was.

Uiteindelijk bleek een shellcode die een exe-bestand van een bepaalde server via http downloadde en op het doelsysteem lanceerde, effectief te zijn. De shellcode was klein genoeg om erin te passen, maar hij werkte tenminste. Omdat de server helemaal niet van TCP-verkeer hield en http(s) werd geïnspecteerd op de aanwezigheid van meterpreter, besloot ik dat de snelste manier was om via deze shellcode een exe-bestand te downloaden dat DNS-meterpreter bevatte.

Ook hier deed zich een probleem voor: bij het downloaden van een exe-bestand en, zoals bij pogingen bleek, ongeacht welk bestand, werd de download onderbroken. Nogmaals, een beveiligingsapparaat tussen mijn server en de uroloog hield niet van http-verkeer met een exe erin. De “snelle” oplossing leek te zijn om de shellcode zo te veranderen dat het http-verkeer on-the-fly zou vertroebelen, zodat abstracte binaire gegevens zouden worden overgedragen in plaats van exe. Uiteindelijk was de aanval succesvol, de controle werd ontvangen via het dunne DNS-kanaal:

Het werd meteen duidelijk dat ik over de meest elementaire IIS-workflowrechten beschikt, waardoor ik niets kan doen. Zo zag het eruit op de Metasploit-console:

Alle pentest-methodologieën suggereren sterk dat u de rechten moet verhogen bij het verkrijgen van toegang. Meestal doe ik dit niet lokaal, omdat de allereerste toegang eenvoudigweg wordt gezien als een netwerktoegangspunt, en het compromitteren van een andere machine op hetzelfde netwerk meestal gemakkelijker en sneller is dan het escaleren van rechten op een bestaande host. Maar dit is hier niet het geval, omdat het DNS-kanaal erg smal is en het verkeer niet kan worden opgeruimd.

Ervan uitgaande dat deze Windows 2003-server niet is gerepareerd vanwege de beroemde MS17-010-kwetsbaarheid, tunnel ik het verkeer naar poort 445/TCP via de meterpreter DNS-tunnel op localhost (ja, dit is ook mogelijk) en probeer ik de eerder gedownloade exe door te voeren de kwetsbaarheid. De aanval werkt, ik ontvang een tweede verbinding, maar met SYSTEEMrechten.

Het is interessant dat ze nog steeds probeerden de server te beschermen tegen MS17-010 - kwetsbare netwerkservices waren uitgeschakeld op de externe interface. Dit beschermt wel tegen aanvallen via het netwerk, maar de aanval van binnenuit op localhost werkte, aangezien je SMB op localhost niet zomaar snel kunt uitschakelen.

Vervolgens worden nieuwe interessante details onthuld:

1. Als u SYSTEEMrechten heeft, kunt u eenvoudig een backconnectie tot stand brengen via TCP. Het is duidelijk dat het uitschakelen van directe TCP uitsluitend een probleem is voor de beperkte IIS-gebruiker. Spoiler: het IIS-gebruikersverkeer werd op de een of andere manier in beide richtingen in de lokale ISA-proxy gewikkeld. Hoe het precies werkt, heb ik niet weergegeven.
2. Ik zit in een bepaalde “DMZ” (en dit is geen Active Directory-domein, maar een WERKGROEP) - het klinkt logisch. Maar in plaats van het verwachte privé (“grijze”) IP-adres, heb ik een volledig “wit” IP-adres, precies hetzelfde als het adres dat ik eerder heb aangevallen. Dit betekent dat het bedrijf zo oud is in de wereld van IPv4-adressering dat het het zich kan veroorloven om een ​​DMZ-zone aan te houden voor 128 ‘witte’ adressen zonder NAT volgens het schema, zoals weergegeven in Cisco-handleidingen uit 2005.

Omdat de server oud is, werkt Mimikatz gegarandeerd rechtstreeks vanuit het geheugen:

Ik krijg het lokale beheerderswachtwoord, tunnel RDP-verkeer over TCP en log in op een gezellige desktop. Omdat ik met de server kon doen wat ik wilde, verwijderde ik de antivirus en ontdekte dat de server alleen via internet toegankelijk was via TCP-poorten 80 en 443, en dat 443 niet bezet was. Ik zet een OpenVPN-server op 443, voeg NAT-functies toe voor mijn VPN-verkeer en krijg via mijn OpenVPN in onbeperkte vorm directe toegang tot het DMZ-netwerk. Het is opmerkelijk dat ISA, met een aantal niet-uitgeschakelde IPS-functies, mijn verkeer blokkeerde met poortscans, waarvoor het moest worden vervangen door een eenvoudiger en meer compatibel RRAS. Pentesters moeten dus soms nog van alles administreren.

Een oplettende lezer zal vragen: "Hoe zit het met de tweede site - een wiki met NTLM-authenticatie, waarover zoveel is geschreven?" Hierover later meer.

Deel 2. Nog steeds niet versleuteld? Dan komen wij hier al naar je toe

Er is dus toegang tot het DMZ-netwerksegment. U moet naar de domeinbeheerder gaan. Het eerste dat in je opkomt is het automatisch controleren van de veiligheid van diensten binnen het DMZ-segment, vooral omdat veel meer daarvan nu openstaan ​​voor onderzoek. Een typisch beeld tijdens een penetratietest: de externe perimeter is beter beschermd dan interne diensten, en bij het verkrijgen van enige toegang binnen een grote infrastructuur is het veel gemakkelijker om uitgebreide rechten in een domein te verkrijgen, alleen maar omdat dit domein begint te worden beschermd. toegankelijk voor tools, en ten tweede: in een infrastructuur met enkele duizenden hosts zullen er altijd een paar kritieke problemen zijn.

Ik laad de scanners op via DMZ via een OpenVPN-tunnel en wacht. Ik open het rapport - opnieuw niets ernstigs, blijkbaar heeft iemand vóór mij dezelfde methode gevolgd. De volgende stap is om te onderzoeken hoe hosts binnen het DMZ-netwerk communiceren. Om dit te doen, start u eerst de gebruikelijke Wireshark en luistert u naar uitzendverzoeken, voornamelijk ARP. De hele dag werden ARP-pakketten verzameld. Het blijkt dat er in dit segment meerdere gateways worden gebruikt. Dit zal later van pas komen. Door gegevens over ARP-verzoeken en -antwoorden en poortscangegevens te combineren, vond ik de uitgangspunten van gebruikersverkeer vanuit het lokale netwerk, naast de diensten die voorheen bekend waren, zoals internet en mail.

Omdat ik op dit moment geen toegang had tot andere systemen en geen enkel account voor bedrijfsdiensten had, werd besloten om met behulp van ARP-spoofing in ieder geval een deel van het verkeer uit het verkeer te halen.

Cain&Abel werd gelanceerd op de server van de uroloog. Rekening houdend met de geïdentificeerde verkeersstromen werden de meest veelbelovende paren voor de man-in-the-middle-aanval geselecteerd, en vervolgens werd wat netwerkverkeer ontvangen door een kortetermijnlancering gedurende 5-10 minuten, met een timer om de server opnieuw op te starten. in geval van bevriezing. Net als in de grap waren er twee nieuwtjes:

1. Goed: er zijn veel inloggegevens gepakt en de aanval als geheel heeft gewerkt.
2. Het slechte: alle inloggegevens waren afkomstig van de eigen klanten van de klant. Tijdens het leveren van ondersteunende diensten maakten klantspecialisten verbinding met de diensten van klanten die niet altijd verkeersversleuteling hadden geconfigureerd.

Als gevolg hiervan verwierf ik veel referenties die nutteloos waren in de context van het project, maar zeker interessant als demonstratie van het gevaar van de aanval. Borderrouters van grote bedrijven met telnet, sturen debug-http-poorten door naar interne CRM met alle gegevens, directe toegang tot RDP vanuit Windows XP op het lokale netwerk en ander obscurantisme. Het bleek zo Supply Chain Compromis volgens de MITRE-matrix.

Ik vond ook een grappige mogelijkheid om brieven uit het verkeer te verzamelen, zoiets als dit. Dit is een voorbeeld van een kant-en-klare brief die van onze klant naar de SMTP-poort van zijn klant ging, opnieuw zonder encryptie. Een zekere Andrey vraagt ​​zijn naamgenoot om de documentatie opnieuw te verzenden, en deze wordt geüpload naar een cloudschijf met een login, wachtwoord en link in één antwoordbrief:

Dit is nog een herinnering om alle services te coderen. Het is niet bekend wie en wanneer specifiek uw gegevens zal lezen en gebruiken: de provider, de systeembeheerder van een ander bedrijf of zo'n pentester. Ik zwijg over het feit dat veel mensen eenvoudigweg ongecodeerd verkeer kunnen onderscheppen.

Ondanks het ogenschijnlijke succes bracht dit ons niet dichter bij het doel. Het was natuurlijk mogelijk om lange tijd te blijven zitten en waardevolle informatie op te vissen, maar het is geen feit dat deze daar zou verschijnen, en de aanval zelf is zeer riskant in termen van de integriteit van het netwerk.

Na nog een keer in de diensten te hebben gegraven, kwam er een interessant idee in me op. Er bestaat zo'n hulpprogramma genaamd Responder (het is gemakkelijk om gebruiksvoorbeelden onder deze naam te vinden), dat, door uitzendingsverzoeken te "vergiftigen", verbindingen tot stand brengt via een verscheidenheid aan protocollen zoals SMB, HTTP, LDAP, enz. op verschillende manieren, vraagt ​​vervolgens iedereen die verbinding maakt om zich te authenticeren en stelt dit zo in dat authenticatie plaatsvindt via NTLM en in een modus die transparant is voor het slachtoffer. Meestal verzamelt een aanvaller op deze manier NetNTLMv2-handshakes en haalt daaruit, met behulp van een woordenboek, snel de wachtwoorden van het gebruikersdomein terug. Hier wilde ik iets soortgelijks, maar de gebruikers zaten “achter een muur”, of beter gezegd, ze werden gescheiden door een firewall, en hadden toegang tot het WEB via het Blue Coat-proxycluster.

Weet je nog dat ik heb gespecificeerd dat de Active Directory-domeinnaam samenviel met het "externe" domein, dat wil zeggen dat het bedrijf.ru was? Met Windows, meer bepaald Internet Explorer (en Edge en Chrome), kan de gebruiker zich dus op transparante wijze authenticeren in HTTP via NTLM als hij van mening is dat de site zich in een of andere “intranetzone” bevindt. Een van de tekenen van een ‘intranet’ is toegang tot een ‘grijs’ IP-adres of een korte DNS-naam, dat wil zeggen zonder punten. Omdat ze een server hadden met een ‘witte’ IP- en DNS-naam preobrazhensky.company.ru, en domeinmachines meestal het Active Directory-domeinachtervoegsel via DHCP ontvangen voor vereenvoudigde naaminvoer, hoefden ze alleen de URL in de adresbalk te schrijven preobrazjenski, zodat ze het juiste pad vinden naar de server van de gecompromitteerde uroloog, en niet te vergeten dat deze nu “Intranet” heet. Dat wil zeggen dat ik tegelijkertijd de NTLM-handshake van de gebruiker krijg zonder dat hij het weet. Het enige dat overblijft is om clientbrowsers te dwingen na te denken over de dringende noodzaak om contact op te nemen met deze server.

Het geweldige hulpprogramma Intercepter-NG kwam te hulp (bedankt Onderschepper). Hiermee kon je het verkeer direct wijzigen en werkte het uitstekend onder Windows 2003. Het had zelfs een aparte functionaliteit om alleen JavaScript-bestanden in de verkeersstroom aan te passen. Er was een soort grootschalige Cross-Site Scripting gepland.

Blue Coat-proxy's, waarmee gebruikers toegang kregen tot het wereldwijde WEB, sloegen periodiek statische inhoud op in de cache. Door het verkeer te onderscheppen, werd het duidelijk dat ze de klok rond aan het werk waren en eindeloos veelgebruikte statische gegevens opvroegen om de weergave van inhoud tijdens piekuren te versnellen. Bovendien beschikte BlueCoat over een specifieke User-Agent, die het duidelijk onderscheidde van een echte gebruiker.

Er werd Javascript voorbereid, dat met behulp van Intercepter-NG voor elke respons een uur 's nachts werd geïmplementeerd met JS-bestanden voor Blue Coat. Het script deed het volgende:

• Bepaal de huidige browser door User-Agent. Als het Internet Explorer, Edge of Chrome was, bleef het werken.
• Ik wachtte tot de DOM van de pagina was gevormd.
• Een onzichtbare afbeelding in de DOM ingevoegd met een src-attribuut van het formulier preobrazjenski:8080/NNNNNNN.png, waarbij NNN willekeurige getallen zijn, zodat BlueCoat het niet in de cache opslaat.
• Stel een globale vlagvariabele in om aan te geven dat de injectie is voltooid en dat het niet meer nodig is om afbeeldingen in te voegen.

De browser probeerde deze afbeelding te laden; op poort 8080 van de gecompromitteerde server wachtte een TCP-tunnel naar mijn laptop, waar dezelfde Responder draaide, waardoor de browser moest inloggen via NTLM.

Afgaande op de logbestanden van de Responder kwamen mensen 's ochtends naar hun werk, zetten hun werkstations aan en begonnen vervolgens massaal en onopgemerkt de server van de uroloog te bezoeken, en niet te vergeten NTLM-handdrukken te 'afvoeren'. Handdrukken regenden de hele dag en verzamelden duidelijk materiaal voor een duidelijk succesvolle aanval om wachtwoorden te achterhalen. Zo zagen de Responder-logboeken eruit:

Massageheime bezoeken aan de uroloogserver door gebruikers

Je hebt waarschijnlijk al gemerkt dat dit hele verhaal gebaseerd is op het principe “alles was in orde, maar toen was er een tegenvaller, toen was er een overwinning, en toen kwam alles tot een succes.” Er was hier dus sprake van een spelbreker. Van de vijftig unieke handdrukken werd er niet één onthuld. En hierbij wordt rekening gehouden met het feit dat zelfs op een laptop met een dode processor deze NTLMv2-handshakes worden verwerkt met een snelheid van enkele honderden miljoenen pogingen per seconde.

Ik moest mezelf bewapenen met technieken voor wachtwoordmutatie, een videokaart, een dikker woordenboek en wachten. Na een lange tijd werden verschillende accounts met wachtwoorden in de vorm “Q11111111....1111111q” onthuld, wat suggereert dat alle gebruikers ooit gedwongen werden een zeer lang wachtwoord te bedenken met verschillende hoofdletters en kleine letters, wat ook bedoeld was om complex zijn. Maar je kunt een doorgewinterde gebruiker niet voor de gek houden, en zo heeft hij het zichzelf gemakkelijker gemaakt om te onthouden. In totaal werden ongeveer vijf accounts gecompromitteerd, en slechts één daarvan had waardevolle rechten op de services.

Deel 3. Roskomnadzor slaat terug

Zo werden de eerste domeinaccounts ontvangen. Als je na lang lezen nog niet in slaap bent gevallen, zul je je waarschijnlijk herinneren dat ik een dienst noemde die geen tweede authenticatiefactor vereiste: het is een wiki met NTLM-authenticatie. Het eerste wat je moest doen was natuurlijk naar binnen gaan. Het graven in de interne kennisbank leverde al snel resultaten op:

• Het bedrijf beschikt over een WiFi-netwerk met authenticatie via domeinaccounts met toegang tot het lokale netwerk. Met de huidige set gegevens is dit al een werkende aanvalsvector, maar je moet met je voeten naar kantoor gaan en je ergens op het grondgebied van het kantoor van de klant bevinden.
• Ik vond een instructie volgens welke er een dienst was die het mogelijk maakte... om onafhankelijk een "tweedefactor"-authenticatieapparaat te registreren als de gebruiker zich in een lokaal netwerk bevindt en met vertrouwen zijn domeinaanmelding en wachtwoord onthoudt. In dit geval werden “binnen” en “buiten” bepaald door de toegankelijkheid van de poort van deze dienst voor de gebruiker. De poort was niet toegankelijk via internet, maar wel via de DMZ.

Uiteraard werd er meteen een ‘tweede factor’ aan het gecompromitteerde account toegevoegd in de vorm van een applicatie op mijn telefoon. Er was een programma dat luid een push-verzoek naar de telefoon kon sturen met de knoppen "goedkeuren"/"afkeuren" voor de actie, of stilletjes de OTP-code op het scherm kon weergeven voor verdere onafhankelijke invoer. Bovendien werd volgens de instructies aangenomen dat de eerste methode de enige juiste was, maar deze werkte niet, in tegenstelling tot de OTP-methode.

Toen de ‘tweede factor’ was verbroken, had ik toegang tot Outlook Web Access-mail en externe toegang in Citrix Netscaler Gateway. Er zat een verrassing in de mail in Outlook:

In deze zeldzame opname kun je zien hoe Roskomnadzor pentesters helpt

Dit waren de eerste maanden na de beroemde ‘fan’-blokkering van Telegram, toen hele netwerken met duizenden adressen onverbiddelijk uit de toegang verdwenen. Het werd duidelijk waarom de push niet meteen werkte en waarom mijn ‘slachtoffer’ niet aan de bel trok omdat ze tijdens openingstijden haar account gingen gebruiken.

Iedereen die bekend is met Citrix Netscaler stelt zich voor dat het meestal zo wordt geïmplementeerd dat alleen een beeldinterface naar de gebruiker kan worden overgebracht, in een poging hem niet de tools te geven om applicaties van derden te starten en gegevens over te dragen, waardoor acties op alle mogelijke manieren worden beperkt. via standaard besturingsshells. Mijn “slachtoffer” kreeg vanwege zijn beroep slechts 1C:

Nadat ik een beetje rond de 1C-interface had gelopen, ontdekte ik dat daar externe verwerkingsmodules zijn. Ze kunnen vanuit de interface worden geladen en worden uitgevoerd op de client of server, afhankelijk van de rechten en instellingen.

Ik vroeg mijn 1C-programmeursvrienden om een ​​verwerking te maken die een string zou accepteren en deze zou uitvoeren. In 1C-taal ziet het starten van een proces er ongeveer zo uit (overgenomen van internet). Bent u het ermee eens dat de syntaxis van de 1C-taal Russischsprekende mensen verbaast met zijn spontaniteit?

De verwerking werd perfect uitgevoerd; het bleek wat pentesters een "shell" noemen - Internet Explorer werd erdoor gelanceerd.

Eerder werd in de mail het adres gevonden van een systeem waarmee u passen voor het gebied kunt bestellen. Ik bestelde een pas voor het geval ik een WiFi-aanvalsvector moest gebruiken.

Er wordt op internet gesproken dat er nog steeds heerlijke gratis catering was bij de klant op kantoor, maar ik gaf er toch de voorkeur aan om de aanval op afstand te ontwikkelen, het is rustiger.

AppLocker was geactiveerd op de applicatieserver waarop Citrix draaide, maar werd omzeild. Dezelfde Meterpreter werd geladen en gelanceerd via DNS, omdat de http(s)-versies geen verbinding wilden maken en ik het interne proxy-adres op dat moment niet kende. Trouwens, vanaf dit moment is de externe pentest in wezen volledig veranderd in een interne.

Deel 4. Beheerdersrechten voor gebruikers zijn slecht, oké?

De eerste taak van een pentester bij het verkrijgen van controle over een domeingebruikerssessie is het verzamelen van alle informatie over rechten in het domein. Er is een BloodHound-hulpprogramma waarmee u automatisch informatie over gebruikers, computers en beveiligingsgroepen kunt downloaden via het LDAP-protocol van een domeincontroller, en via SMB - informatie over welke gebruiker waar onlangs heeft ingelogd en wie de lokale beheerder is.

Een typische techniek voor het overnemen van domeinbeheerdersrechten ziet er vereenvoudigd uit als een cyclus van monotone acties:

• We gaan naar domeincomputers waar lokale beheerdersrechten zijn, gebaseerd op reeds vastgelegde domeinaccounts.
• We starten Mimikatz en krijgen in de cache opgeslagen wachtwoorden, Kerberos-tickets en NTLM-hashes van domeinaccounts die onlangs op dit systeem zijn ingelogd. Of we verwijderen de geheugenimage van het proces lsass.exe en doen hetzelfde aan onze kant. Dit werkt goed met Windows jonger dan 2012R2/Windows 8.1 met standaardinstellingen.
• We bepalen waar de gecompromitteerde accounts lokale beheerdersrechten hebben. We herhalen het eerste punt. Op een gegeven moment krijgen we beheerdersrechten voor het hele domein.

“End of the Cycle;”, zoals 1C-programmeurs hier zouden schrijven.

Onze gebruiker bleek dus een lokale beheerder te zijn op slechts één host met Windows 7, waarvan de naam het woord "VDI" of "Virtual Desktop Infrastructure", persoonlijke virtuele machines, bevatte. Waarschijnlijk bedoelde de ontwerper van de VDI-service dat, aangezien VDI het persoonlijke besturingssysteem van de gebruiker is, de host nog steeds kan worden “opnieuw geladen”, zelfs als de gebruiker de softwareomgeving naar eigen inzicht wijzigt. Ik dacht ook dat het idee over het algemeen goed was, ik ging naar deze persoonlijke VDI-host en maakte daar een nest:

• Ik installeerde daar een OpenVPN-client, die een tunnel door het internet naar mijn server maakte. De klant moest gedwongen worden om dezelfde Blue Coat met domeinauthenticatie te doorlopen, maar OpenVPN deed het, zoals ze zeggen, ‘out of the box’.
• OpenSSH op VDI geïnstalleerd. Nou ja, echt, wat is Windows 7 zonder SSH?

Zo zag het er live uit. Laat me je eraan herinneren dat dit allemaal via Citrix en 1C moet gebeuren:

Eén techniek om de toegang tot naburige computers te bevorderen, is door de lokale beheerderswachtwoorden te controleren op een overeenkomst. Hier wachtte onmiddellijk het geluk: de NTLM-hash van de standaard lokale beheerder (die plotseling Administrator heette) werd benaderd via een pass-the-hash-aanval op naburige VDI-hosts, waarvan er enkele honderden waren. Natuurlijk raakte de aanval hen onmiddellijk.

Dit is waar VDI-beheerders zichzelf twee keer in de voet schoten:

• De eerste keer was toen VDI-machines niet onder LAPS werden gebracht, waarbij in wezen hetzelfde lokale beheerderswachtwoord werd behouden van de image die massaal werd geïmplementeerd op VDI.
• De standaardbeheerder is het enige lokale account dat kwetsbaar is voor pass-the-hash-aanvallen. Zelfs met hetzelfde wachtwoord zou het mogelijk zijn massale compromissen te voorkomen door een tweede lokaal beheerdersaccount aan te maken met een complex willekeurig wachtwoord en het standaardwachtwoord te blokkeren.

Waarom is er een SSH-service op Windows? Heel eenvoudig: nu bood de OpenSSH-server niet alleen een handige interactieve opdrachtshell zonder het werk van de gebruiker te verstoren, maar ook een sokken5-proxy op VDI. Via deze sokken maakte ik verbinding via SMB en verzamelde in de cache opgeslagen accounts van al deze honderden VDI-machines, en zocht vervolgens naar het pad naar de domeinbeheerder met behulp van deze in de BloodHound-grafieken. Met honderden hosts tot mijn beschikking, vond ik deze weg vrij snel. Domeinbeheerderrechten zijn verkregen.

Hier is een afbeelding van internet waarop een soortgelijke zoekopdracht te zien is. Verbindingen laten zien wie waar de beheerder is en wie waar ingelogd is.

Onthoud trouwens de voorwaarde vanaf het begin van het project: "gebruik geen social engineering." Ik stel dus voor om na te denken over hoeveel van al dat Bollywood met speciale effecten zou worden afgesneden als het nog steeds mogelijk zou zijn om banale phishing te gebruiken. Maar persoonlijk vond ik het erg interessant om dit allemaal te doen. Ik hoop dat je het leuk vond om dit te lezen. Natuurlijk ziet niet elk project er zo intrigerend uit, maar het werk als geheel is zeer uitdagend en laat het niet stagneren.

Waarschijnlijk zal iemand een vraag hebben: hoe kun je jezelf beschermen? Zelfs dit artikel beschrijft veel technieken, waarvan veel Windows-beheerders niet eens op de hoogte zijn. Ik stel echter voor om ze te bekijken vanuit het perspectief van afgezaagde principes en informatiebeveiligingsmaatregelen:

• gebruik geen verouderde software (herinner je Windows 2003 in het begin?)
• laat geen onnodige systemen ingeschakeld staan ​​(waarom was er een website van een uroloog?)
• controleer zelf de gebruikerswachtwoorden op sterkte (anders zullen soldaten... pentesters dit doen)
• niet dezelfde wachtwoorden hebben voor verschillende accounts (VDI-compromis)
• en andere

Dit is natuurlijk heel moeilijk te implementeren, maar in het volgende artikel zullen we in de praktijk laten zien dat het heel goed mogelijk is.

Bron: www.habr.com