Once upon a pentest, eller Hur man bryter allt med hjälp av en urolog och Roskomnadzor

Den här artikeln skrevs baserat på en mycket framgångsrik pentest som Group-IB-specialister genomförde för ett par år sedan: en historia hände som kunde anpassas för film i Bollywood. Nu kommer förmodligen läsarens reaktion att följa: "Åh, ännu en PR-artikel, återigen de här porträtteras, hur bra de är, glöm inte att köpa en pentest." Jo, å ena sidan är det så. Det finns dock ett antal andra anledningar till att den här artikeln dök upp. Jag ville visa exakt vad pentesters gör, hur intressant och icke-trivialt detta arbete kan vara, vilka roliga omständigheter som kan uppstå i projekt, och viktigast av allt, visa levande material med verkliga exempel.

För att återställa balansen mellan blygsamhet i världen kommer vi efter ett tag att skriva om en pentest som inte gick bra. Vi kommer att visa hur väldesignade processer i ett företag kan skydda mot en hel rad attacker, även väl förberedda sådana, helt enkelt för att dessa processer finns och faktiskt fungerar.

För kunden i den här artikeln var allt också i allmänhet utmärkt, åtminstone bättre än 95% av marknaden i Ryska federationen, enligt våra känslor, men det fanns ett antal små nyanser som bildade en lång kedja av händelser, som först ledde till en lång rapport om arbetet, och sedan till den här artikeln.

Så, låt oss fylla på med popcorn och välkommen till deckaren. Ord - Pavel Suprunyuk, teknisk chef för "Audit and Consulting"-avdelningen i Group-IB.

Del 1. Pochkin-läkare

2018 Det finns en kund - ett högteknologiskt IT-företag, som själv servar många kunder. Vill du få svar på frågan: är det möjligt, utan någon inledande kunskap och tillgång, att arbeta via Internet, att få Active Directory-domänadministratörsrättigheter? Jag är inte intresserad av någon social ingenjörskonst (åh, men förgäves), de har inte för avsikt att störa arbetet med avsikt, men de kan av misstag - ladda om en märkligt fungerande server, till exempel. Ett ytterligare mål är att identifiera så många andra attackvektorer som möjligt mot den yttre omkretsen. Företaget genomför regelbundet sådana tester och nu har deadline för ett nytt test kommit. Förhållandena är nästan typiska, adekvata, begripliga. Låt oss börja.

Det finns ett namn på kunden - låt det vara "Företag", med huvudwebbplatsen www.company.ru. Naturligtvis kallas kunden annorlunda, men i den här artikeln kommer allt att vara opersonligt.
Jag bedriver nätverksspaning - tar reda på vilka adresser och domäner som är registrerade hos kunden, ritar ett nätverksdiagram, hur tjänster distribueras till dessa adresser. Jag får resultatet: mer än 4000 live IP-adresser. Jag tittar på domänerna i dessa nätverk: lyckligtvis är de allra flesta nätverk avsedda för kundens kunder, och vi är inte formellt intresserade av dem. Kunden tycker likadant.

Det återstår ett nätverk med 256 adresser, för vilket det vid det här laget redan finns en förståelse för fördelningen av domäner och underdomäner med IP-adresser, det finns information om de skannade portarna, vilket innebär att du kan titta på tjänsterna för intressanta. Parallellt lanseras alla typer av skannrar på tillgängliga IP-adresser och separat på webbplatser.

Det finns många tjänster. Vanligtvis är detta glädje för pentestern och förväntan på en snabb seger, eftersom ju fler tjänster det finns, desto större fält för attack och desto lättare är det att hitta en artefakt. En snabb titt på webbplatserna visade att de flesta av dem är webbgränssnitt för välkända produkter från stora globala företag, som av allt att döma säger att de inte är välkomna. De ber om ett användarnamn och lösenord, skakar ut fältet för att ange den andra faktorn, ber om ett TLS-klientcertifikat eller skickar det till Microsoft ADFS. Vissa är helt enkelt otillgängliga från Internet. För vissa behöver du uppenbarligen ha en särskild betald kund för tre löner eller veta den exakta webbadressen du ska ange. Låt oss hoppa över ytterligare en vecka av gradvis förtvivlan i processen att försöka "bryta igenom" programvaruversioner för kända sårbarheter, söka efter dolt innehåll i webbvägar och läckta konton från tredjepartstjänster som LinkedIn, och försöka gissa lösenord med hjälp av dem, liksom som att gräva ut sårbarheter i självskrivna webbplatser — förresten, enligt statistiken, är detta den mest lovande vektorn för extern attack idag. Jag kommer omedelbart att notera filmpistolen som sedan avlossades.

Så vi hittade två webbplatser som stack ut från hundratals tjänster. Dessa sajter hade en sak gemensamt: om du inte ägnar dig åt noggrann nätverksspaning per domän, utan letar rakt igenom efter öppna portar eller riktar in dig på en sårbarhetsskanner med ett känt IP-intervall, kommer dessa webbplatser att undgå skanning och kommer helt enkelt inte att bli synlig utan att känna till DNS-namnet. Kanske har de missats tidigare, åtminstone, och våra automatiska verktyg hittade inga problem med dem, även om de skickades direkt till resursen.

Förresten, om vad tidigare lanserade skannrar hittade i allmänhet. Låt mig påminna dig: för vissa människor är "pentest" likvärdigt med "automatisk skanning". Men skannrarna på det här projektet sa ingenting. Tja, det maximala visades av medelstora sårbarheter (3 av 5 när det gäller svårighetsgrad): på vissa tjänster ett dåligt TLS-certifikat eller föråldrade krypteringsalgoritmer, och på de flesta webbplatser Clickjacking. Men detta kommer inte att få dig till ditt mål. Kanske skannrar skulle vara mer användbara här, men låt mig påminna dig: kunden själv kan köpa sådana program och testa sig själv med dem, och att döma av de dystra resultaten har han redan kollat.

Låt oss återvända till de "anomala" platserna. Den första är något som en lokal Wiki på en icke-standardadress, men låt det i den här artikeln vara wiki.company[.]ru. Hon bad också omedelbart om inloggning och lösenord, men genom NTLM i webbläsaren. För användaren ser detta ut som ett asketiskt fönster som ber att ange ett användarnamn och lösenord. Och detta är dålig praxis.

En liten notis. NTLM på perimeterwebbplatser är dåligt av flera skäl. Det första skälet är att Active Directory-domännamnet avslöjas. I vårt exempel visade det sig också vara company.ru, precis som det "externa" DNS-namnet. Genom att veta detta kan du noggrant förbereda något skadligt så att det endast körs på organisationens domänmaskin och inte i någon sandlåda. För det andra går autentiseringen direkt genom domänkontrollanten via NTLM (överraskning, eller hur?), med alla funktioner i de "interna" nätverkspolicyerna, inklusive blockering av konton från att överskrida antalet lösenordsinmatningsförsök. Om en angripare får reda på inloggningarna kommer han att prova lösenord för dem. Om du är konfigurerad att blockera konton från att ange felaktiga lösenord, kommer det att fungera och kontot kommer att blockeras. För det tredje är det omöjligt att lägga till en andra faktor till sådan autentisering. Om någon av läsarna fortfarande vet hur, låt mig veta, det är verkligen intressant. För det fjärde, sårbarhet för pass-the-hash-attacker. ADFS uppfanns bland annat för att skydda mot allt detta.

Det finns en dålig egenskap hos Microsoft-produkter: även om du inte specifikt publicerade en sådan NTLM, kommer den att installeras som standard i OWA och Lync, åtminstone.

Förresten, författaren till den här artikeln blockerade en gång av misstag cirka 1000 konton för anställda i en stor bank på bara en timme med samma metod och såg sedan något blek ut. Bankens IT-tjänster var också bleka, men allt slutade bra och adekvat, vi fick till och med beröm för att vi var först med att hitta detta problem och provocera fram en snabb och beslutsam åtgärd.

Den andra platsen hade adressen "uppenbarligen något slags efternamn.company.ru." Hittade den via Google, ungefär så här på sidan 10. Designen var från början av mitten av XNUMX-talet, och en respektabel person tittade på den från huvudsidan, ungefär så här:

Här tog jag en stillbild från "Heart of a Dog", men tro mig, den var vagt lik, till och med färgdesignen var i liknande toner. Låt sajten heta preobrazhensky.company.ru.

Det var en personlig hemsida... för en urolog. Jag undrade vad en urologs webbplats gjorde på underdomänen till ett högteknologiskt företag. En snabb grävning i Google visade att den här läkaren var en av grundarna av en av våra kunders juridiska personer och till och med bidrog med cirka 1000 XNUMX rubel i det auktoriserade kapitalet. Sajten skapades förmodligen för många år sedan, och kundens serverresurser användes som värd. Sajten har länge tappat sin relevans, men av någon anledning lät den fungera länge.

När det gäller sårbarheter var själva webbplatsen säker. Framöver kommer jag att säga att det var en uppsättning statisk information - enkla html-sidor med infogade illustrationer i form av njurar och blåsor. Det är värdelöst att "bryta" en sådan sida.

Men webbservern under var mer intressant. Att döma av HTTP-serverhuvudet hade den IIS 6.0, vilket betyder att den använde Windows 2003 som operativsystem. Skannern hade tidigare identifierat att just denna urologwebbplats, till skillnad från andra virtuella värdar på samma webbserver, svarade på PROPFIND-kommandot, vilket betyder att den körde WebDAV. Förresten, skannern returnerade denna information med märket Info (på språket för skannerrapporter är detta den lägsta faran) - sådana saker hoppar man vanligtvis över. I kombination gav detta en intressant effekt, som avslöjades först efter ytterligare en grävning på Google: en sällsynt buffertöversvämningssårbarhet förknippad med Shadow Brokers-setet, nämligen CVE-2017-7269, som redan hade en färdig exploatering. Det blir med andra ord problem om du har Windows 2003 och WebDAV körs på IIS. Även om det är ett problem i sig att köra Windows 2003 i produktion 2018.

Exploateringen hamnade i Metasploit och testades omedelbart med en laddning som skickade en DNS-förfrågan till en kontrollerad tjänst – Burp Collaborator används traditionellt för att fånga DNS-förfrågningar. Till min förvåning fungerade det första gången: en DNS-knockout mottogs. Därefter gjordes ett försök att skapa en backconnection via port 80 (det vill säga en nätverksanslutning från servern till angriparen, med tillgång till cmd.exe på offervärden), men sedan inträffade ett fiasko. Anslutningen kom inte igenom, och efter det tredje försöket att använda webbplatsen, tillsammans med alla intressanta bilder, försvann för alltid.

Vanligtvis följs detta av ett brev i stil med "kund, vakna, vi tappade allt." Men vi fick höra att sajten inte har något med affärsprocesser att göra och fungerar där utan anledning alls, som hela servern, och att vi kan använda den här resursen som vi vill.
Ungefär ett dygn senare började sajten plötsligt fungera av sig själv. Efter att ha byggt en bänk från WebDAV på IIS 6.0 upptäckte jag att standardinställningen är att starta om IIS-arbetarprocesser var 30:e timme. Det vill säga när kontrollen lämnade skalkoden avslutades IIS-arbetarprocessen, sedan startade den om sig själv ett par gånger och gick sedan i vila i 30 timmar.

Eftersom återkopplingen till tcp misslyckades första gången, tillskrev jag detta problem till en stängd port. Det vill säga, han antog närvaron av någon sorts brandvägg som inte tillät utgående anslutningar att passera utanför. Jag började köra skalkoder som sökte igenom många tcp- och udp-portar, det fanns ingen effekt. Omvänd anslutningsladdning via http(s) från Metasploit fungerade inte - meterpreter/reverse_http(s). Plötsligt upprättades en anslutning till samma port 80, men avbröts omedelbart. Jag tillskrev detta till handlingen hos den fortfarande imaginära IPS, som inte gillade mätaretrafiken. I ljuset av att en ren tcp-anslutning till port 80 inte gick igenom, men en http-anslutning gjorde det, drog jag slutsatsen att en http-proxy på något sätt var konfigurerad i systemet.

Jag försökte till och med mätare via DNS (tack d00kie för dina ansträngningar, räddade många projekt), påminner om den allra första framgången, men den fungerade inte ens på montern - skalkoden var för omfattande för denna sårbarhet.

I verkligheten såg det ut så här: 3-4 försök till attacker inom 5 minuter, sedan vänta i 30 timmar. Och så vidare tre veckor i rad. Jag har till och med ställt in en påminnelse för att inte slösa tid. Dessutom fanns det en skillnad i beteendet hos test- och produktionsmiljöerna: för denna sårbarhet fanns det två liknande exploateringar, en från Metasploit, den andra från Internet, konverterad från Shadow Brokers-versionen. Så det var bara Metasploit som testades i strid, och bara den andra testades på bänken, vilket gjorde felsökningen ännu svårare och var hjärndödande.

Till slut visade sig en skalkod som laddade ner en exe-fil från en given server via http och startade den på målsystemet vara effektiv. Skalkoden var tillräckligt liten för att passa, men den fungerade åtminstone. Eftersom servern inte alls gillade TCP-trafik och http(s) inspekterades med avseende på närvaron av meterpreter, bestämde jag mig för att det snabbaste sättet var att ladda ner en exe-fil som innehöll DNS-meterpreter genom denna skalkod.

Även här uppstod ett problem: vid nedladdning av en exe-fil och, som försök visade, oavsett vilken, avbröts nedladdningen. Återigen, någon säkerhetsenhet mellan min server och urologen gillade inte http-trafik med ett exe inuti. Den "snabba" lösningen verkade vara att ändra skalkoden så att den skulle fördunkla http-trafik i farten, så att abstrakt binär data skulle överföras istället för exe. Till slut lyckades attacken, kontroll togs emot via den tunna DNS-kanalen:

Det blev direkt klart att jag har de mest grundläggande IIS-arbetsflödesrättigheterna, som gör att jag inte kan göra någonting. Så här såg det ut på Metasploit-konsolen:

Alla testmetoder tyder starkt på att du måste öka rättigheterna när du får tillgång. Jag brukar inte göra detta lokalt, eftersom den allra första åtkomsten helt enkelt ses som en nätverksingångspunkt, och att kompromissa med en annan maskin på samma nätverk är vanligtvis enklare och snabbare än att eskalera privilegier på en befintlig värd. Men detta är inte fallet här, eftersom DNS-kanalen är mycket smal och den kommer inte att tillåta trafik att rensa upp.

Förutsatt att denna Windows 2003-server inte har reparerats för den berömda MS17-010-sårbarheten, tunnlar jag trafik till port 445/TCP genom mätarens DNS-tunnel till localhost (ja, detta är också möjligt) och försöker köra den tidigare nedladdade exe-filen via sårbarheten. Attacken fungerar, jag får en andra anslutning, men med SYSTEM-rättigheter.

Det är intressant att de fortfarande försökte skydda servern från MS17-010 - den hade sårbara nätverkstjänster inaktiverade på det externa gränssnittet. Detta skyddar visserligen mot attacker över nätverket, men attacken inifrån på localhost fungerade, eftersom du inte bara snabbt kan stänga av SMB på localhost.

Därefter avslöjas nya intressanta detaljer:

1. Med SYSTEM-rättigheter kan du enkelt upprätta en backconnection via TCP. Att inaktivera direkt TCP är uppenbarligen ett problem för den begränsade IIS-användaren. Spoiler: IIS-användartrafiken var på något sätt insvept i den lokala ISA-proxyn i båda riktningarna. Hur exakt det fungerar har jag inte återgett.
2. Jag är i en viss "DMZ" (och det här är inte en Active Directory-domän, utan en WORKGROUP) - det låter logiskt. Men istället för den förväntade privata (”grå”) IP-adressen har jag en helt “vit” IP-adress, exakt samma som den jag attackerade tidigare. Det betyder att företaget är så gammalt i världen av IPv4-adressering att det har råd att upprätthålla en DMZ-zon för 128 "vita" adresser utan NAT enligt schemat, som avbildas i Ciscos manualer från 2005.

Eftersom servern är gammal fungerar Mimikatz garanterat direkt från minnet:

Jag får det lokala administratörslösenordet, tunnlar RDP-trafik över TCP och loggar in på ett mysigt skrivbord. Eftersom jag kunde göra vad jag ville med servern tog jag bort antiviruset och upptäckte att servern endast var tillgänglig från Internet via TCP-portarna 80 och 443, och 443 var inte upptagen. Jag ställer in en OpenVPN-server på 443, lägger till NAT-funktioner för min VPN-trafik och får direkt tillgång till DMZ-nätverket i obegränsad form genom min OpenVPN. Det är anmärkningsvärt att ISA, med några icke-inaktiverade IPS-funktioner, blockerade min trafik med portskanning, för vilken den måste ersättas med en enklare och mer kompatibel RRAS. Så pentestare måste ibland fortfarande administrera alla möjliga saker.

En uppmärksam läsare kommer att fråga: "Vad sägs om den andra webbplatsen - en wiki med NTLM-autentisering, som det har skrivits så mycket om?" Mer om detta senare.

Del 2. Krypterar du fortfarande inte? Då kommer vi till dig redan här

Så det finns tillgång till DMZ-nätverkssegmentet. Du måste gå till domänadministratören. Det första man tänker på är att automatiskt kontrollera säkerheten för tjänster inom DMZ-segmentet, särskilt eftersom många fler av dem nu är öppna för forskning. En typisk bild under ett penetrationstest: den externa omkretsen är bättre skyddad än interna tjänster, och när man får tillgång till en stor infrastruktur är det mycket lättare att få utökade rättigheter i en domän bara på grund av att denna domän börjar bli tillgängliga för verktyg, och för det andra, I en infrastruktur med flera tusen värdar kommer det alltid att finnas ett par kritiska problem.

Jag laddar skannrarna via DMZ via en OpenVPN-tunnel och väntar. Jag öppnar rapporten - återigen inget allvarligt, tydligen har någon gått igenom samma metod före mig. Nästa steg är att undersöka hur värdar inom DMZ-nätverket kommunicerar. För att göra detta, starta först den vanliga Wiresharken och lyssna efter sändningsförfrågningar, främst ARP. ARP-paket samlades in hela dagen lång. Det visar sig att flera gateways används i detta segment. Detta kommer väl till pass senare. Genom att kombinera data om ARP-förfrågningssvar och portskanningsdata hittade jag utgångspunkterna för användartrafik inifrån det lokala nätverket utöver de tjänster som tidigare var kända, såsom webb och e-post.

Eftersom jag för tillfället inte hade någon tillgång till andra system och inte hade ett enda konto för företagstjänster, beslutades det att fiska ut åtminstone ett konto från trafiken med hjälp av ARP Spoofing.

Cain&Abel lanserades på urologens server. Med hänsyn till de identifierade trafikflödena valdes de mest lovande paren för man-in-the-middle-attacken ut, och sedan mottogs en del nätverkstrafik genom korttidsstart i 5-10 minuter, med en timer för att starta om servern vid frysning. Som i skämtet var det två nyheter:

1. Bra: många referenser samlades in och attacken som helhet fungerade.
2. Det dåliga: alla referenser kom från kundens egna kunder. Medan de tillhandahåller supporttjänster kopplade kundspecialister till tjänsterna från kunder som inte alltid hade trafikkryptering konfigurerad.

Som ett resultat fick jag en hel del referenser som var värdelösa i projektets sammanhang, men definitivt intressanta som en demonstration av faran med attacken. Gränsroutrar för stora företag med telnet, vidarebefordrade debug http-portar till intern CRM med all data, direkt tillgång till RDP från Windows XP på det lokala nätverket och annan obskurantism. Det blev så här Supply Chain Kompromiss enligt MITER-matrisen.

Jag hittade också ett roligt tillfälle att samla brev från trafiken, ungefär så här. Detta är ett exempel på ett färdigt brev som gick från vår kund till hans klients SMTP-port, återigen, utan kryptering. En viss Andrey ber sin namne att skicka om dokumentationen, och den laddas upp till en molndisk med inloggning, lösenord och länk i ett svarsbrev:

Detta är ytterligare en påminnelse om att kryptera alla tjänster. Det är okänt vem och när som kommer att läsa och använda dina uppgifter specifikt - leverantören, systemadministratören för ett annat företag, eller en sådan pentester. Jag är tyst om det faktum att många människor helt enkelt kan avlyssna okrypterad trafik.

Trots den uppenbara framgången förde detta oss inte närmare målet. Det gick förstås att sitta länge och fiska fram värdefull information, men det är inte ett faktum att den skulle dyka upp där, och själva attacken är mycket riskabel med tanke på nätverkets integritet.

Efter ytterligare en grävning i tjänsterna dök en intressant idé upp. Det finns ett sådant verktyg som heter Responder (det är lätt att hitta exempel på användning med detta namn), som, genom att "förgifta" sändningsförfrågningar, provocerar anslutningar via en mängd olika protokoll som SMB, HTTP, LDAP, etc. på olika sätt, ber sedan alla som ansluter sig att autentisera och ställer in det så att autentisering sker via NTLM och i ett läge som är transparent för offret. Oftast samlar en angripare NetNTLMv2-handskakningar på detta sätt och från dem, med hjälp av en ordbok, återställer han snabbt domänanvändarlösenord. Här ville jag ha något liknande, men användarna satt "bakom en vägg", eller snarare, de var åtskilda av en brandvägg och fick åtkomst till WEB genom Blue Coat proxy-klustret.

Kom ihåg att jag angav att Active Directory-domännamnet sammanföll med den "externa" domänen, det vill säga att det var company.ru? Så, Windows, närmare bestämt Internet Explorer (och Edge och Chrome), tillåter användaren att transparent autentisera i HTTP via NTLM om de anser att webbplatsen är belägen i någon "intranätszon". Ett av tecknen på ett "intranät" är tillgång till en "grå" IP-adress eller ett kort DNS-namn, det vill säga utan prickar. Eftersom de hade en server med ett "vitt" IP- och DNS-namn preobrazhensky.company.ru, och domänmaskiner vanligtvis får Active Directory-domänsuffixet via DHCP för förenklad namninmatning, behövde de bara skriva URL:en i adressfältet preobrazhensky, så att de hittar den rätta vägen till den komprometterade urologens server, inte att förglömma att detta nu kallas "Intranät". Det vill säga att samtidigt ge mig användarens NTLM-handslag utan hans vetskap. Allt som återstår är att tvinga klientwebbläsare att tänka på det akuta behovet av att kontakta denna server.

Det underbara Intercepter-NG-verktyget kom till undsättning (tack interceptet). Det gjorde det möjligt för dig att ändra trafik i farten och fungerade utmärkt på Windows 2003. Den hade till och med separat funktionalitet för att endast ändra JavaScript-filer i trafikflödet. En sorts massiv Cross-Site Scripting planerades.

Blue Coat proxyservrar, genom vilka användare fick åtkomst till den globala WEB:en, cachade statiskt innehåll med jämna mellanrum. Genom att avlyssna trafik var det tydligt att de arbetade dygnet runt och begärde oändligt ofta använda statisk ström för att påskynda visningen av innehåll under rusningstid. Dessutom hade BlueCoat en specifik User-Agent, som tydligt skilde den från en riktig användare.

Javascript förbereddes, som med Intercepter-NG implementerades under en timme på natten för varje svar med JS-filer för Blue Coat. Manuset gjorde följande:

• Bestämde aktuell webbläsare av User-Agent. Om det var Internet Explorer, Edge eller Chrome fortsatte det att fungera.
• Jag väntade tills sidans DOM bildades.
• Infogade en osynlig bild i DOM med ett src-attribut för formuläret preobrazhensky:8080/NNNNNNNN.png, där NNN är godtyckliga nummer så att BlueCoat inte cachelagrar det.
• Ställ in en global flaggvariabel för att indikera att injektionen slutfördes och att det inte finns något behov av att infoga bilder längre.

Webbläsaren försökte ladda den här bilden; på port 8080 på den komprometterade servern väntade en TCP-tunnel på den till min bärbara dator, där samma svarssvarare kördes, vilket krävde att webbläsaren loggar in via NTLM.

Att döma av svarsloggarna kom folk till jobbet på morgonen, slog på sina arbetsstationer och började sedan massa och obemärkt besöka urologens server, utan att glömma att "tömma" NTLM-handskakningar. Handskakningar regnade ner hela dagen och tydligt samlat material för en uppenbart lyckad attack för att återställa lösenord. Så här såg svarsloggarna ut:

Masshemliga besök på urologservern av användare

Du har förmodligen redan märkt att hela den här historien är byggd på principen "allt var bra, men sedan blev det en bummer, sedan blev det en övervinna och sedan blev allting framgång." Så, det var en bummer här. Av de femtio unika handslagen avslöjades inte ett enda. Och detta tar hänsyn till det faktum att även på en bärbar dator med en död processor behandlas dessa NTLMv2-handskakningar med en hastighet av flera hundra miljoner försök per sekund.

Jag var tvungen att beväpna mig med tekniker för lösenordsmutation, ett grafikkort, en tjockare ordbok och vänta. Efter en lång tid avslöjades flera konton med lösenord av formen "Q11111111....1111111q", vilket tyder på att alla användare en gång tvingades komma med ett mycket långt lösenord med olika versaler, vilket också var tänkt att vara komplex. Men du kan inte lura en erfaren användare, och så här gjorde han det lättare för sig själv att komma ihåg. Totalt komprometterades cirka 5 konton, och endast ett av dem hade några värdefulla rättigheter till tjänsterna.

Del 3. Roskomnadzor slår tillbaka

Så de första domänkontona togs emot. Om du inte har somnat vid det här laget från en lång läsning, kommer du förmodligen ihåg att jag nämnde en tjänst som inte krävde en andra faktor för autentisering: det är en wiki med NTLM-autentisering. Det första man gjorde var förstås att gå in där. Att gräva i den interna kunskapsbasen gav snabbt resultat:

• Företaget har ett WiFi-nätverk med autentisering med hjälp av domänkonton med tillgång till det lokala nätverket. Med den nuvarande uppsättningen data är detta redan en fungerande attackvektor, men du måste gå till kontoret med fötterna och vara belägen någonstans på kundens kontors territorium.
• Jag hittade en instruktion enligt vilken det fanns en tjänst som gjorde det möjligt för... att oberoende registrera en "andra faktor" autentiseringsenhet om användaren är inne i ett lokalt nätverk och säkert kommer ihåg sin domäninloggning och lösenord. I det här fallet bestämdes "insidan" och "utanför" av tillgängligheten för denna tjänsts port för användaren. Porten var inte tillgänglig från Internet, men var ganska tillgänglig via DMZ.

Naturligtvis lades en "andra faktor" omedelbart till det inträngda kontot i form av en applikation på min telefon. Det fanns ett program som antingen högljutt kunde skicka en push-förfrågan till telefonen med "godkänn"/"godkänn"-knapparna för åtgärden, eller tyst visa OTP-koden på skärmen för ytterligare oberoende inmatning. Dessutom antogs den första metoden enligt instruktionerna vara den enda korrekta, men den fungerade inte, till skillnad från OTP-metoden.

Med den "andra faktorn" bruten kunde jag komma åt Outlook Web Access-e-post och fjärråtkomst i Citrix Netscaler Gateway. Det kom en överraskning i posten i Outlook:

I detta sällsynta skott kan du se hur Roskomnadzor hjälper pentesters

Detta var de första månaderna efter den berömda "fan"-blockeringen av Telegram, när hela nätverk med tusentals adresser obönhörligen försvann från åtkomst. Det blev tydligt varför pushen inte fungerade direkt och varför mitt "offer" inte slog larm eftersom de började använda hennes konto under öppettider.

Alla som är bekanta med Citrix Netscaler föreställer sig att det vanligtvis implementeras på ett sådant sätt att endast ett bildgränssnitt kan förmedlas till användaren, och försöker att inte ge honom verktygen för att starta tredjepartsapplikationer och överföra data, vilket begränsar åtgärder på alla möjliga sätt genom standardkontrollskal. Mitt "offer", på grund av sitt yrke, fick bara 1C:

Efter att ha gått runt lite i 1C-gränssnittet upptäckte jag att det finns externa bearbetningsmoduler där. De kan laddas från gränssnittet och de kommer att köras på klienten eller servern, beroende på rättigheter och inställningar.

Jag bad mina 1C programmerare vänner att skapa en bearbetning som skulle acceptera en sträng och exekvera den. I 1C-språket ser det ut ungefär så här att starta en process (tagen från Internet). Håller du med om att syntaxen i 1C-språket förvånar rysktalande människor med sin spontanitet?

Bearbetningen utfördes perfekt; det visade sig vara vad pentesters kallar ett "skal" - Internet Explorer lanserades genom det.

Tidigare hittades adressen till ett system som låter dig beställa pass till territoriet i posten. Jag beställde ett pass ifall jag skulle behöva använda en WiFi-attackvektor.

Det pratas på Internet om att det fortfarande fanns utsökt gratis catering på kundens kontor, men jag föredrog ändå att utveckla attacken på distans, det är lugnare.

AppLocker aktiverades på applikationsservern som körde Citrix, men den förbigicks. Samma Meterpreter laddades och lanserades via DNS, eftersom http(s)-versionerna inte ville ansluta, och jag visste inte den interna proxyadressen vid den tiden. Förresten, från och med detta ögonblick förvandlades den yttre pentesten i huvudsak helt till en intern.

Del 4. Adminrättigheter för användare är dåliga, okej?

Den första uppgiften för en pentester när han ska få kontroll över en domänanvändarsession är att samla in all information om rättigheter i domänen. Det finns ett BloodHound-verktyg som automatiskt låter dig ladda ner information om användare, datorer, säkerhetsgrupper via LDAP-protokollet från en domänkontrollant och via SMB - information om vilken användare som nyligen loggat in var och vem som är lokal administratör.

En typisk teknik för att beslagta domänadministratörsrättigheter ser förenklad ut som en cykel av monotona handlingar:

• Vi går till domändatorer där det finns lokala administratörsrättigheter, baserat på redan inhämtade domänkonton.
• Vi lanserar Mimikatz och får cachade lösenord, Kerberos-biljetter och NTLM-haschar för domänkonton som nyligen loggat in på det här systemet. Eller så tar vi bort minnesbilden för processen lsass.exe och gör samma sak på vår sida. Detta fungerar bra med Windows yngre än 2012R2/Windows 8.1 med standardinställningar.
• Vi avgör var de utsatta kontona har lokala administratörsrättigheter. Vi upprepar den första punkten. I något skede får vi administratörsrättigheter för hela domänen.

"End of the Cycle;", som 1C-programmerare skulle skriva här.

Så vår användare visade sig vara en lokal administratör på bara en värd med Windows 7, vars namn inkluderade ordet "VDI" eller "Virtual Desktop Infrastructure", personliga virtuella maskiner. Förmodligen menade designern av VDI-tjänsten att eftersom VDI är användarens personliga operativsystem, även om användaren ändrar mjukvarumiljön som han vill, kan värden fortfarande "laddas om". Jag tyckte också att idén generellt sett var bra, jag gick till den här personliga VDI-värden och gjorde ett bo där:

• Jag installerade en OpenVPN-klient där, som gjorde en tunnel genom Internet till min server. Klienten var tvungen att gå igenom samma Blue Coat med domänautentisering, men OpenVPN gjorde det, som de säger, "out of the box."
• Installerade OpenSSH på VDI. Tja, egentligen, vad är Windows 7 utan SSH?

Så här såg det ut live. Låt mig påminna dig om att allt detta måste göras genom Citrix och 1C:

En teknik för att främja åtkomst till angränsande datorer är att kontrollera lokala administratörslösenord för en matchning. Här väntade turen omedelbart: NTLM-hash för den lokala standardadministratören (som plötsligt kallades Administratör) kontaktades genom en pass-the-hash-attack till angränsande VDI-värdar, av vilka det fanns flera hundra. Naturligtvis drabbade attacken dem omedelbart.

Det var här VDI-administratörer sköt sig själva i foten två gånger:

• Första gången var när VDI-maskiner inte togs under LAPS, i princip behöll samma lokala administratörslösenord från bilden som distribuerades massivt till VDI.
• Standardadministratören är det enda lokala kontot som är sårbart för pass-the-hash-attacker. Även med samma lösenord skulle det vara möjligt att undvika masskomprometteringar genom att skapa ett andra lokalt administratörskonto med ett komplext slumpmässigt lösenord och blockera standardlösenordet.

Varför SSH-tjänsten på det Windows? Mycket enkelt: nu gav OpenSSH-servern inte bara ett bekvämt interaktivt kommandoskal utan att störa användarens arbete, utan också en socks5-proxy på VDI. Genom dessa strumpor kopplade jag upp mig via SMB och samlade cachade konton från alla dessa hundratals VDI-maskiner, och letade sedan efter vägen till domänadministratören som använde dem i BloodHound-graferna. Med hundratals värdar till mitt förfogande hittade jag det här sättet ganska snabbt. Domänadministratörsrättigheter har erhållits.

Här är en bild från Internet som visar en liknande sökning. Anslutningar visar vem som är där administratören är och vem som är inloggad var.

Förresten, kom ihåg villkoret från projektets början - "använd inte social ingenjörskonst." Så jag föreslår att jag tänker på hur mycket allt detta Bollywood med specialeffekter skulle skäras bort om det fortfarande var möjligt att använda banalt nätfiske. Men personligen var det väldigt intressant för mig att göra allt detta. Jag hoppas att du tyckte om att läsa detta. Naturligtvis ser inte alla projekt så spännande ut, men arbetet som helhet är väldigt utmanande och låter det inte stagnera.

Förmodligen kommer någon att ha en fråga: hur man skyddar sig själv? Även den här artikeln beskriver många tekniker, av vilka många Windows-administratörer inte ens känner till. Jag föreslår dock att man ska titta på dem ur perspektivet av hackade principer och informationssäkerhetsåtgärder:

• använd inte föråldrad programvara (minns du Windows 2003 i början?)
• låt inte onödiga system vara påslagna (varför fanns det en urologs webbplats?)
• kontrollera användarlösenord för styrka själv (annars kommer soldater... pentesters att göra detta)
• inte ha samma lösenord för olika konton (VDI-kompromiss)
• och andra

Naturligtvis är detta väldigt svårt att genomföra, men i nästa artikel kommer vi att visa i praktiken att det är fullt möjligt.

Källa: will.com