Introduktion
I den här fallstudien är vår kund ett internationellt företag med tusentals arbetsstationer och servrar i olika lokaler. Dessa värdar är organiserade i flera domäner och domänerna är samlade i en gemensam domänskog. Vår kund ville veta hur stort hot en illasinnad anställd med minimal tillgång skulle utgöra mot företagets system. Samtidigt ville han också testa de IDS- och IPS-lösningar som införs i praktiken.
Vad kan vi göra om vi som ansvariga beslutsfattare undrar hur våra system i sin helhet skulle reagera på en verklig attack? Det är lätt att se att den traditionella sårbarhetsbedömningen inte är det bästa valet i det här fallet, eftersom den mer liknar en säkerhetsrevision än ett riktigt hackarangrepp. Målet med testmetoden med röda team är att ge kunden en realistisk bild av hur effektiva de införda strategierna är, hur välutbildade IT-specialisterna är och vilken nivå av säkerhetsmedvetenhet de anställda har i allmänhet. Testning med röda teamet innebär följaktligen en simulering av en verklig attack som endast en liten grupp insiders hos kunden känner till. Under simuleringen är angriparens mål vanligtvis att kompromettera kundens system i största möjliga utsträckning utan att förstås orsaka avsiktlig skada.
Boltonshields team har redan många års erfarenhet av testning med röda team och har sett många intressanta fall under flera framgångsrika projekt. Det är viktigt att notera att utgångspunkten för projekten med red team testing alltid är föremål för överenskommelse. Innan vi fattar ett beslut måste vi identifiera kundens behov och även de möjliga riktningarna för de attacker som systemen är mest utsatta för.
I det fall som användes för studien pågick testningen med det röda teamet under en vecka enligt vårt avtal. Projektet avslutas i förtid om vi lyckas bevisa att systemet kan äventyras på ett avgörande sätt eller om vår verksamhet upptäcks.
Vi hoppade över vallgraven
I början av testningen av det röda teamet fick vi ett eget kontor där vi kunde arbeta utan avbrott. Med undantag för de insatta fick alla anställda information om att vi skulle genomföra en granskning i samband med företagets rutiner.
Efter inspektionen av de tillgängliga nätverksportarna stod det snabbt klart för oss att en portbaserad nätverksåtkomstkontroll (PNAC) har implementerats i vår kunds nätverk i enlighet med IEEE 802.1X-standarden. Det kan vara ett effektivt verktyg med lämpliga konfigurationsinställningar, eftersom det kan upptäcka och blockera att vem som helst får tillgång till nätverket. Men som alla protokoll har det också sina svagheter. Den kan kringgås enklast om vi letar efter enheter som är anslutna till nätverk som förmodligen inte stöder denna standard. Eftersom även dessa enheters funktion måste säkerställas på något sätt hanteras de i allmänhet som undantag. Under processens gång identifieras enheterna utifrån deras MAC-adresser, och sedan kan de lagligt ansluta till nätverket även utan korrekt autentisering.
Den överväldigande majoriteten av nätverksskrivare implementerar fortfarande inte alla NAC-standarder, så de kan vara attraktiva måltavlor. I ett av rummets avlägsna hörn hittade vi en nätverksskrivare som bara fångade damm. När den anslöts till närmaste nätverksport fick den omedelbart en IP-adress från DHCP-servern, vilket innebär att dess MAC-adress fortfarande ansågs vara ett undantag på autentiserings-servern.
Även om skrivaren inte visade MAC-adressen på kontrollpanelen lyckades vi med hjälp av en hubb ta oss in mellan skrivaren och nätverket på ett passivt sätt. På så sätt kunde vi avlyssna kommunikationen mellan dem och få fram en giltig MAC-adress på mycket kort tid. Med kännedom om denna MAC-adress kunde vi också ansluta oss till nätverket.
Så vi kunde slå den första försvarslinjen med framgång. Eftersom några av oss ville arbeta samtidigt men bara hade en giltig MAC-adress omvandlade vi en av maskinerna praktiskt taget till en router. Alla andra maskiner som deltog i utvärderingen kommunicerade med nätverket via denna enda värd.
Väggarna rasar samman
När anslutningen har lyckats kan vi börja utforska nätverket. Vi var tvungna att vara särskilt uppmärksamma på att inte agera med för mycket "brus". Om vår verksamhet upptäcktes kunde det lätt ha satt stopp för projektet. Detta innebar i praktiken att vi inte fick använda de flesta aktiva spaningstekniker. Därför försökte vi först identifiera de sårbara arbetsstationerna och servrarna genom att passivt avlyssna nätverkstrafiken.
Efter en kort tid hade vi redan några åtkomstvägar för nätverksfildelning och IP-adresser till vissa arbetsstationer, så vi började utvärdera dem. Medan vi analyserade delningarna mer ingående upptäckte vi något intressant.
Den del som heter ADBackupManager var helt annorlunda än de andra och var allmänt tillgänglig för alla. I delningen hittade vi en körbar fil, några DLL-filer och en databasfil. Baserat på namnet på delningen tyckte vi att det skulle vara värt att undersöka dessa filer mer ingående. Med hjälp av reverse engineering-tekniker lyckades vi dekryptera programmet praktiskt taget till dess källkod. Därigenom fick vi reda på att syftet med programmet var att förbereda säkerhetskopiorna för nätverksdelningen. För att programmet skall fungera korrekt behöver det också tillgång på domännivå. Denna åtkomst var lagrad i databasen i krypterad form. Eftersom dekrypteringsalgoritmen och den nödvändiga nyckeln var hårdkodade i applikationens källkod kunde vi enkelt dekryptera det krypterade lösenordet.
Vi kontrollerade snabbt tillträdet och konstaterade att det var giltigt. Nu kunde vi kommunicera med domänservern på ett autentiserat sätt, vilket var nästa viktiga milstolpe.
Slottet fångat
Med denna åtkomst kan vi fråga efter alla domänens användare, deras grupper och de giltiga ACL-åtkomstkontrollistorna (ACL). Nästa steg var att utföra den attack som kallas "kerberoasting", under vilken vi begärde tjänstebiljetter för domänens tjänstekonton med hjälp av vår giltiga åtkomst. Varje biljett är krypterad med NTLM-hashes för de givna tjänstekontona. Det ger oss möjlighet att försöka dekryptera de förvärvade biljetterna genom att testa miljontals lösenord offline. Om en biljett kan dekrypteras har vi också fått fram lösenordet för det givna tjänstekontot. Enligt vår erfarenhet kan tjänstekonton som skyddas med ett medelsvagt lösenord knäckas ganska snabbt på detta sätt.
Vi lyckades begära ett serviceärende för ett servicekonto för vilket en administratörsflagga var inställd. I allmänhet är servicekonton privilegierade domänkonton, men förekomsten av admin-flaggan tyder starkt på att den givna användaren kan ha ännu mer privilegier. Vi lyckades slutligen knäcka servicebiljetten för användaren svc_backupmgr bara inom en timme. Efter en snabb förfrågan fick vi också veta att den givna användaren tillhör gruppen "Backup Operators".
Med den här användaren kan vi logga in på en av domänkontrollanterna via tjänsten "winrm". Privilegieskaleringen var praktiskt taget uppenbar med backup-privilegiet. Under det första steget i attacken frågade vi efter SAM- och SYSTEM-hivorna i registret. I nästa steg hämtade vi NTLM-hash för den lokala administratörsanvändaren från dessa hives. Med hashen kunde vi logga in på servern även utan att känna till lösenordet genom att använda pass-the-hash-tekniken, även denna gång med administratörstillgång.
Med rätt privilegier kunde vi ta en ögonblicksbild av NTDS som innehöll lösenordshash för alla domänanvändare.
Vid denna tidpunkt kunde man konstatera att domänen var fullständigt skadad. Vi fick tillgång till hash-koder för tusentals användare, inklusive domän- och företagsadministratörer. Beväpnade med de förvärvade autentiseringsuppgifterna skulle vi ha haft rätt att utföra alla åtgärder i domänen i flera av företagets lokaler.
En fullständig överraskning
Det var följande allvarliga sårbarheter som gjorde det möjligt att genomföra en framgångsrik attack:
- bristande fysisk säkerhet (öppna nätportar)
- förekomst av NAC-undantag (lång oanvänd enhet finns fortfarande på listan över undantag)
- nätverksdelning med känsligt innehåll som är offentligt tillgängligt för alla
- offentligt tillgängligt för alla
- användning av hårdkodade autentiseringsdata
- tjänstekonto som skyddas med ett svagt lösenord för mycket privilegier för servicekontot (fjärrloggning via winrm)
Under testprojektet med det röda teamet utförde vi nästan bara åtgärder som domänanvändarna normalt har rätt att utföra. Följaktligen orsakade vi inga säkerhetsincidenter eller varningar i kundens IDS- och IPS-enheter.
När vi efter några dagar presenterade våra resultat för kundens beslutsfattare blev de mycket överraskade. Som de sa frågade de berörda specialisterna flera gånger om de hade upplevt någon misstänkt händelse, men de fick upprepade gånger ett definitivt nej som svar.
The results confirmed our client, parallel to taking the instant measures, that he should ask us to perform a full-scope internal assessment. In the course of the red team testing several critical vulnerabilities were revealed and based on the results of the multiple-round joint cooperation it can be established that the security level of our client’s system improved significantly shortly afterwards.
Du kan kontakta oss för att ta reda på exakt hur Boltonshield kan hjälpa din organisation.