Dela via

Vägar att kompromissa

Lag nummer sju: Det säkraste nätverket är ett väl administrerat nätverk. - 10 Oföränderliga lagar för säkerhetsadministration

I organisationer som har upplevt katastrofala kompromisshändelser visar utvärderingar vanligtvis att organisationerna har begränsad insyn i det faktiska tillståndet för sina IT-infrastrukturer, vilket kan skilja sig avsevärt från deras "som dokumenterade" tillstånd. Dessa avvikelser medför sårbarheter som gör att miljön kan komprometteras, ofta med liten risk för identifiering tills kompromissen har gått vidare till den punkt då angriparna effektivt "äger" miljön.

Detaljerade utvärderingar av dessa organisationers AD DS-konfiguration, offentliga nyckelinfrastrukturer (PKIs), servrar, arbetsstationer, program, åtkomstkontrollistor (ACL) och andra tekniker avslöjar felkonfigurationer och sårbarheter som, om de har åtgärdats, kunde ha förhindrat den första kompromissen.

Analys av IT-dokumentation, processer och procedurer identifierar sårbarheter som införts av luckor i administrativa metoder som utnyttjas av angripare för att så småningom få privilegier som användes för att helt kompromettera Active Directory-skogen. En fullständigt komprometterad skog är en skog där angripare inte bara komprometterar enskilda system, program eller användarkonton, utan eskalerar sin åtkomst för att få en behörighetsnivå där de kan ändra eller förstöra alla aspekter av skogen. När en Active Directory-installation har komprometterats i den utsträckningen kan angripare göra ändringar som gör att de kan behålla en närvaro i hela miljön, eller ännu värre, för att förstöra katalogen och de system och konton som den hanterar.

Även om ett antal vanliga sårbarheter i beskrivningarna som följer inte är attacker mot Active Directory, gör de det möjligt för angripare att etablera ett fotfäste i en miljö som kan användas för att köra privilegiereskaleringsattacker (kallas även privilegieringshöjning) och så småningom rikta in sig på och kompromettera AD DS.

Det här avsnittet i det här dokumentet fokuserar på att beskriva de mekanismer som angripare vanligtvis använder för att få åtkomst till infrastrukturen och så småningom starta privilegierade utökade attacker. Se även följande avsnitt:

Anmärkning

Även om det här dokumentet fokuserar på Active Directory- och Windows-system som ingår i en AD DS-domän, fokuserar angripare sällan enbart på Active Directory och Windows. I miljöer med en blandning av operativsystem, kataloger, program och datalagringsplatser är det vanligt att upptäcka att icke-Windows-system också har komprometterats. Detta gäller särskilt om systemen tillhandahåller en "brygga" mellan Windows- och icke-Windows-miljöer, till exempel filservrar som används av Windows- och UNIX- eller Linux-klienter, kataloger som tillhandahåller autentiseringstjänster till flera operativsystem eller metakataloger som synkroniserar data mellan olika kataloger.

AD DS är mål på grund av de centraliserade funktionerna för åtkomst och konfigurationshantering som det ger inte bara till Windows-system, utan även till andra klienter. Alla andra kataloger eller program som tillhandahåller autentiserings- och konfigurationshanteringstjänster kan och kommer att riktas mot beslutsamma angripare. Även om det här dokumentet fokuserar på skydd som kan minska sannolikheten för att Active Directory-installationer komprometteras, bör alla organisationer som innehåller datorer, kataloger, program eller datalagringsplatser som inte är Windows-datorer, kataloger eller datalagringsplatser också förbereda sig för attacker mot dessa system.

Initiala mål för intrång

Ingen skapar avsiktligt en IT-infrastruktur som gör organisationen utsatt för kompromisser. När en Active Directory-skog först skapas är den vanligtvis orörd och aktuell. Allt eftersom åren går och nya operativsystem och program förvärvas läggs de till i skogen. Eftersom de hanterbarhetsfördelar som Active Directory ger identifieras läggs allt mer innehåll till i katalogen, fler integrerar sina datorer eller program med AD DS och domäner uppgraderas för att stödja nya funktioner som erbjuds av de senaste versionerna av Windows-operativsystemet. Vad som också händer med tiden är dock att även när en ny infrastruktur läggs till kanske andra delar av infrastrukturen inte underhålls lika bra som de ursprungligen var, att system och program fungerar korrekt och därför inte får uppmärksamhet, och organisationer börjar glömma att de inte har eliminerat sin äldre infrastruktur. Baserat på vad vi ser när vi utvärderar komprometterade infrastrukturer, desto äldre, större och mer komplex miljön är, desto mer sannolikt är det att det finns många instanser av vanligt utnyttjade sårbarheter.

Oavsett angriparens motivation börjar de flesta informationssäkerhetsöverträdelser med kompromettering av ett eller två system i taget. Dessa inledande händelser, eller startpunkter i nätverket, utnyttjar ofta sårbarheter som kunde ha åtgärdats, men som inte var det. 2012 Data Breach Investigations Report (DBIR), som är en årlig studie producerad av Verizon RISK Team i samarbete med ett antal nationella säkerhetsbyråer och andra företag, säger att 96 procent av attackerna var "inte mycket svåra" och att "97 procent av överträdelserna kunde undvikas genom enkla eller mellanliggande kontroller." Dessa resultat kan vara en direkt följd av de vanliga sårbarheter som följer.

Luckor i distributioner av antivirusprogram och program mot skadlig kod

Lag nummer åtta: En inaktuell skanner av skadlig kod är bara marginellt bättre än ingen skanner alls. - Tio oföränderliga säkerhetslagar (version 2.0)

Analys av organisationers distributioner av antivirusprogram och program mot skadlig kod visar ofta en miljö där de flesta arbetsstationer är konfigurerade med antivirusprogram och program mot skadlig kod som är aktiverade och aktuella. Undantagen är vanligtvis arbetsstationer som sällan ansluter till företagsmiljön eller anställdas enheter där det kan vara svårt att distribuera, konfigurera och uppdatera antivirusprogram och program mot skadlig kod.

Serverpopulationer tenderar dock att vara mindre konsekvent skyddade i många komprometterade miljöer. Som rapporterats i 2012 års dataintrångsutredningar involverade 94 procent av alla datakompromisser servrar, vilket motsvarar en ökning med 18 procent jämfört med föregående år, och 69 procent av attackerna innehöll skadlig kod. I serverpopulationer är det inte ovanligt att antivirus- och programinstallationer är inkonsekvent konfigurerade, inaktuella, felkonfigurerade eller inaktiverade. I vissa fall inaktiveras antivirus- och program mot skadlig kod av administrativ personal, men i andra fall inaktiverar angripare programvaran efter att ha komprometterat en server via andra säkerhetsrisker. När antivirus- och program mot skadlig kod inaktiveras, planterar angriparna sedan skadlig kod på servern och fokuserar på att sprida kompromisser över serverpopulationen.

Det är viktigt att inte bara se till att dina system skyddas med aktuellt, omfattande skydd mot skadlig kod, utan även att övervaka system för inaktivering eller borttagning av antivirusprogram och program mot skadlig kod och att automatiskt starta om skyddet när det inaktiveras manuellt. Även om inga antivirusprogram och program mot skadlig kod kan garantera förebyggande och identifiering av alla infektioner, kan en korrekt konfigurerad och distribuerad implementering av antivirusprogram och program mot skadlig kod minska risken för infektion.

Ofullständig patchning

"Lag nummer tre: Om du inte håller dig uppdaterad med säkerhetskorrigeringar, kommer ditt nätverk inte att vara ditt särskilt länge." - 10 Oföränderliga lagar för säkerhetsadministration

Microsoft släpper säkerhetsbulletiner den andra tisdagen i varje månad, men i sällsynta fall släpps säkerhetsuppdateringar mellan de månatliga säkerhetsuppdateringarna (dessa kallas även "out-of-band"-uppdateringar) när sårbarheten är fast besluten att utgöra en brådskande risk för kundsystem. Oavsett om ett litet företag konfigurerar sina Windows-datorer att använda Windows Update för att hantera system- och programkorrigeringar eller om en stor organisation använder hanteringsprogram som Microsoft Endpoint Configuration Manager för att distribuera korrigeringar enligt detaljerade, hierarkiska planer, korrigerar många kunder sina Windows-infrastrukturer relativt snabbt.

Få infrastrukturer omfattar dock endast Windows-datorer och Microsoft-program, och i komprometterade miljöer är det vanligt att upptäcka att organisationens strategi för korrigeringshantering innehåller luckor. Windows-systemen uppdateras inkonsekvent i dessa miljöer. Icke-Windows-operativsystem korrigeras sporadiskt, om alls. CotS-program (Commercial Off-the-Shelf) innehåller säkerhetsrisker för vilka korrigeringar finns, men som inte har tillämpats. Nätverksenheter konfigureras ofta med fabriksstandardautentiseringsuppgifter och inga uppdateringar av inbyggd programvara flera år efter installationen. Program och operativsystem som inte längre stöds av sina leverantörer fortsätter ofta att köras, trots att de inte längre kan korrigeras mot sårbarheter. Vart och ett av dessa okopplade system representerar en annan potentiell startpunkt för angripare.

Konsumentiseringen av IT har medfört ytterligare utmaningar eftersom anställdas ägda enheter används för åtkomst till företagsägda data, och organisationen kanske har liten eller ingen kontroll över korrigeringen och konfigurationen av anställdas personliga enheter. Maskinvara i företagsklass levereras vanligtvis med företagsklara konfigurationsalternativ och hanteringsfunktioner, till priset av mindre val vid individuell anpassning och val av enhet. Medarbetarfokuserad maskinvara erbjuder ett bredare utbud av tillverkare, leverantörer, maskinvarusäkerhetsfunktioner, programvarusäkerhetsfunktioner, hanteringsfunktioner och konfigurationsalternativ, och många företagsfunktioner kan vara helt frånvarande.

Programvara för korrigering och sårbarhetshantering

Om ett effektivt korrigeringshanteringssystem finns på plats för Windows-systemen och Microsoft-programmen har en del av den attackyta som okopplade säkerhetsrisker skapar åtgärdats. Men om inte icke-Windows-system, icke-Microsoft-program, nätverksinfrastruktur och anställda enheter också hålls up-todatum för korrigeringar och andra korrigeringar, förblir infrastrukturen sårbar. I vissa fall kan ett programs leverantör erbjuda automatiska uppdateringsfunktioner. i andra kan det finnas ett behov av att utforma en metod för att regelbundet hämta och tillämpa korrigeringar och andra korrigeringar.

Inaktuella program och operativsystem

"Du kan inte förvänta dig att ett sex år gammalt operativsystem ska skydda dig mot en sex månader gammal attack." - Information Security Professional med 10 års erfarenhet av att skydda företagsinstallationer

Även om "get current, stay current" kan låta som en marknadsföringsfras, skapar inaktuella operativsystem och program risker i många organisationers IT-infrastrukturer. Ett operativsystem som släpptes 2003 kan fortfarande stödjas av leverantören och tillhandahållas uppdateringar för att åtgärda säkerhetsrisker, men operativsystemet kanske inte innehåller säkerhetsfunktioner som lagts till i nyare versioner av operativsystemet. Inaktuella system kan till och med kräva försvagning av vissa AD DS-säkerhetskonfigurationer för att stödja de mindre funktionerna på dessa datorer.

Program som har skrivits för att använda äldre autentiseringsprotokoll av leverantörer som inte längre stöder programmet kan vanligtvis inte retuscheras för att stödja starkare autentiseringsmekanismer. En organisations Active Directory-domän kan dock fortfarande konfigureras för att lagra LAN Manager-hashar eller reversibelt krypterade lösenord för att stödja sådana program. Program som skrivits före introduktionen av nyare operativsystem kanske inte fungerar bra eller alls på nuvarande operativsystem, vilket kräver att organisationer underhåller äldre och äldre system och i vissa fall helt saknar stöd för maskinvara och programvara.

Även om organisationer har uppdaterat sina domänkontrollanter till Windows Server 2012, Windows Server 2008 R2 eller Windows Server 2008 är det vanligt att hitta betydande delar av medlemsserverpopulationen som kör Windows Server 2003, Windows 2000 Server eller Windows NT Server 4.0 (som inte stöds helt). Ju längre en organisation underhåller åldrande system, desto större blir skillnaden mellan funktionsuppsättningar och desto mer sannolikt blir det att produktionssystemen inte stöds. Ju längre en Active Directory-skog underhålls, desto mer observerar vi att äldre system och program missas i uppgraderingsplanerna. Det kan innebära att en enda dator som kör ett enda program kan införa säkerhetsrisker för hela domänen eller skogen eftersom Active Directory har konfigurerats för att stödja äldre protokoll och autentiseringsmekanismer.

För att eliminera äldre system och program bör du först fokusera på att identifiera och katalogisera dem och sedan på att avgöra om programmet eller värden ska uppgraderas eller ersättas. Även om det kan vara svårt att hitta ersättningar för högspecialiserade program för vilka det varken finns stöd eller en uppgraderingsväg, kan du kanske använda ett koncept som kallas "kreativ förstörelse" för att ersätta det äldre programmet med ett nytt program som tillhandahåller nödvändiga funktioner. Planering för kompromiss beskrivs mer ingående i "Planera för kompromiss" senare i det här dokumentet.

Felaktig konfiguration

Lag nummer fyra: Det gör inte mycket bra att installera säkerhetskorrigeringar på en dator som aldrig skyddades till att börja med. - 10 Oföränderliga lagar för säkerhetsadministration

Även i miljöer där system vanligtvis hålls aktuella och korrigerade identifierar vi ofta luckor eller felkonfigurationer i operativsystemet, program som körs på datorer och Active Directory. Vissa felkonfigurationer gör bara den lokala datorn komprometterad, men när en dator är "ägd" fokuserar angripare vanligtvis på att ytterligare sprida kompromissen över andra system och så småningom till Active Directory. Här följer några av de gemensamma områden där vi identifierar konfigurationer som medför risker.

I Active Directory

Kontona i Active Directory som oftast riktas mot angripare är de som är medlemmar i de mest privilegierade grupperna, till exempel medlemmar i domänadministratörer (DA), företagsadministratörer (EA) eller inbyggda administratörsgrupper (BA) i Active Directory. Medlemskapet i dessa grupper bör minskas till det minsta möjliga antalet konton så att attackytan för dessa grupper begränsas. Det går till och med att eliminera "permanent" medlemskap i dessa privilegierade grupper. Du kan alltså implementera inställningar som gör att du tillfälligt kan fylla i dessa grupper endast när deras domän- och skogsomfattande behörigheter behövs. När konton med hög behörighet används bör de endast användas på avsedda, säkra system som domänkontrollanter eller säkra administrativa värdar. Detaljerad information som hjälper dig att implementera alla dessa konfigurationer finns i Reduce the Active Directory Attack Surface (Minska Active Directory-attackytan).

När vi utvärderar medlemskapet för de högst privilegierade grupperna i Active Directory, finner vi ofta överdrivet mycket medlemskap i alla tre av de mest privilegierade grupperna. I vissa fall har organisationer dussintals, till och med hundratals konton i DA-grupper. I andra fall placerar organisationer konton direkt i inbyggda administratörsgrupper och tror att gruppen är "mindre privilegierad" än DAs-gruppen. Det är det inte. Vi hittar ofta en handfull permanenta medlemmar i EA-gruppen i skogens rotdomän, trots att EA-privilegier sällan och tillfälligt krävs. Det är också vanligt att hitta en IT-användares dagliga administrativa konto i alla tre grupperna, även om detta är en effektivt redundant konfiguration. Enligt beskrivningen i Reduce the Active Directory Attack Surface (Minska Active Directory-attackytan), oavsett om ett konto är permanent medlem i en av dessa grupper eller alla av dem, kan kontot användas för att kompromettera och till och med förstöra AD DS-miljön och de system och konton som hanteras av den. Rekommendationer för säker konfiguration och användning av privilegierade konton i Active Directory finns i Reduce the Active Directory Attack Surface (Minska Active Directory-attackytan).

På domänkontrollanter

När vi utvärderar domänkontrollanter hittar vi ofta att de är konfigurerade och hanterade på ett annat sätt än medlemsservrar. Domänkontrollanter kör ibland samma program och verktyg som är installerade på medlemsservrar, inte för att de behövs på domänkontrollanterna, utan för att programmen ingår i en standardversion. Dessa program kan ge minimala funktioner på domänkontrollanterna men avsevärt öka attackytan genom att kräva konfigurationsinställningar som öppnar portar, skapar högprivilegierade tjänstkonton eller beviljar åtkomst till systemet av användare som inte bör ansluta till en domänkontrollant för något annat syfte än autentisering och grupprincipprogram. I vissa överträdelser har angripare använt verktyg som redan har installerats på domänkontrollanter, inte bara för att få åtkomst till domänkontrollanterna, utan för att ändra eller skada AD DS-databasen.

När vi extraherar Konfigurationsinställningarna för Internet Explorer på domänkontrollanter upptäcker vi att användare har loggat in med konton som har höga behörighetsnivåer i Active Directory och har använt kontona för att komma åt Internet och intranätet från domänkontrollanterna. I vissa fall har kontona konfigurerat Internet Explorer-inställningar på domänkontrollanterna för att tillåta nedladdning av Internetinnehåll, och freeware-verktyg har laddats ned från Webbplatser och installerats på domänkontrollanterna. Internet Explorer Förbättrad säkerhetskonfiguration är aktiverad för användare och administratörer som standard, men vi observerar ofta att den har inaktiverats för administratörer. När ett konto med hög behörighet ansluter till Internet och laddar ned innehåll till alla datorer utsätts datorn för allvarlig risk. När datorn är en domänkontrollant utsätts hela AD DS-installationen för risk.

Skydda domänkontrollanter

Domänkontrollanter bör behandlas som kritiska infrastrukturkomponenter, skyddas striktare och konfigureras striktare än fil-, utskrifts- och programservrar. Domänkontrollanter ska inte köra någon programvara som inte krävs för att domänkontrollanten ska fungera eller inte skyddar domänkontrollanten mot attacker. Domänkontrollanter bör inte tillåtas att komma åt Internet, och säkerhetsinställningar bör konfigureras och tillämpas av grupprincipobjekt (GPO). Detaljerade rekommendationer för säker installation, konfiguration och hantering av domänkontrollanter finns i Skydda domänkontrollanter mot angrepp.

Inom operativsystemet

Lag nummer två: Om en skurk kan ändra operativsystemet på din dator är det inte din dator längre. - Tio oföränderliga säkerhetslagar (version 2.0)

Även om vissa organisationer skapar baslinjekonfigurationer för servrar av olika typer och tillåter begränsad anpassning av operativsystemet när det har installerats, upptäcker analys av komprometterade miljöer ofta ett stort antal servrar som distribuerats på ett ad hoc-sätt och konfigurerats manuellt och oberoende. Konfigurationer mellan två servrar som utför samma funktion kan vara helt olika, där ingen av servrarna är konfigurerade på ett säkert sätt. Omvänt kan serverkonfigurationsbaslinjer tillämpas konsekvent, men även konsekvent felkonfigureras. Servrar konfigureras alltså på ett sätt som skapar samma sårbarhet på alla servrar av en viss typ. Felkonfiguration omfattar metoder som inaktivering av säkerhetsfunktioner, beviljande av överdrivna rättigheter och behörigheter till konton (särskilt tjänstkonton), användning av identiska lokala autentiseringsuppgifter mellan system och tillåta installation av obehöriga program och verktyg som skapar egna säkerhetsrisker.

Inaktivera säkerhetsfunktioner

Organisationer inaktiverar ibland Windows-brandväggen med Avancerad säkerhet (WFAS) i tron att WFAS är svårt att konfigurera eller kräver arbetsintensiv konfiguration. Men från och med Windows Server 2008, när någon roll eller funktion är installerad på en server, konfigureras den som standard med de minsta behörigheter som krävs för att rollen eller funktionen ska fungera, och Windows-brandväggen konfigureras automatiskt för att stödja rollen eller funktionen. Genom att inaktivera WFAS (och inte använda en annan värdbaserad brandvägg i dess ställe) ökar organisationer attackytan i hela Windows-miljön. Perimeterbrandväggar ger visst skydd mot attacker som direkt riktar sig mot en miljö från Internet, men de ger inget skydd mot attacker som utnyttjar andra attackvektorer, till exempel nedladdningsattacker via enhet eller attacker som kommer från andra komprometterade system i intranätet.

UAC-inställningar (User Account Control) inaktiveras ibland på servrar eftersom administrativ personal tycker att uppmaningarna är påträngande. Även om Microsoft Support-artikeln 2526083 beskriver scenarier där UAC kan inaktiveras på Windows Server, såvida du inte kör en serverkärnig installation (där UAC är inaktiverat av design), bör du inte inaktivera UAC på servrar utan noggrant övervägande och forskning.

I andra fall är serverinställningarna konfigurerade för mindre säkra värden eftersom organisationer tillämpar inaktuella serverkonfigurationsinställningar på nya operativsystem, till exempel att använda Windows Server 2003-baslinjer på datorer som kör Windows Server 2012, Windows Server 2008 R2 eller Windows Server 2008, utan att ändra baslinjerna för att återspegla ändringarna i operativsystemet. I stället för att använda gamla serverbaslinjer till nya operativsystem kan du när du distribuerar ett nytt operativsystem granska säkerhetsändringar och konfigurationsinställningar för att säkerställa att de implementerade inställningarna är tillämpliga och lämpliga för det nya operativsystemet.

Bevilja överdriven behörighet

I nästan alla miljöer som vi har bedömt beviljas överdrivna privilegier till lokala och domänbaserade konton i Windows-system. Användare beviljas lokal administratörsbehörighet på sina arbetsstationer, medlemsservrar kör tjänster som är konfigurerade med rättigheter utöver vad de behöver för att fungera, och lokala administratörsgrupper i serverpopulationen innehåller dussintals eller till och med hundratals lokala konton och domänkonton. Genom att bara kompromettera ett privilegierat konto på en dator kan angripare kompromettera kontona för varje användare och tjänst som loggar in på datorn, samt att skörda och utnyttja autentiseringsuppgifter för att sprida kompromissen till andra system.

Även om pass-the-hash (PTH) och andra stölder av autentiseringsuppgifter är allmänt förekommande idag, beror det på att det finns fritt tillgängliga verktyg som gör det enkelt och enkelt att extrahera autentiseringsuppgifterna för andra privilegierade konton när en angripare har fått administratörs- eller systemnivååtkomst till en dator. Även utan verktyg som möjliggör insamling av autentiseringsuppgifter från inloggningssessioner kan en angripare med privilegierad åtkomst till en dator lika enkelt installera tangenttryckningsloggare som fångar tangenttryckningar, skärmbilder och Urklippsinnehåll. En angripare med privilegierad åtkomst till en dator kan inaktivera program mot skadlig kod, installera rootkits, ändra skyddade filer eller installera skadlig kod på datorn som automatiserar attacker eller förvandlar en server till en värd för nedladdning via enhet.

Taktikerna som används för att utöka ett intrång utöver en enda dator varierar, men nyckeln till att sprida intrånget är förvärvet av åtkomst med hög behörighet till ytterligare system. Genom att minska antalet konton med privilegierad åtkomst till alla system minskar du angreppsytan, inte bara på den datorn, utan sannolikheten för att en angripare skördar värdefulla autentiseringsuppgifter från datorn.

Standardisera autentiseringsuppgifter för lokal administratör

Det har länge diskuterats bland säkerhetsspecialister om huruvida det finns ett värde i att byta namn på lokala administratörskonton på Windows-datorer. Det som faktiskt är viktigt med lokala administratörskonton är om de är konfigurerade med samma användarnamn och lösenord på flera datorer.

Om det lokala administratörskontot namnges till samma värde mellan servrar och lösenordet som tilldelats kontot också har konfigurerats till samma värde, kan angripare extrahera kontots autentiseringsuppgifter på en dator där administratörs- eller systemnivååtkomst har hämtats. Angriparen behöver inte först kompromettera administratörskontot. De behöver bara kompromettera kontot för en användare som är medlem i den lokala gruppen Administratörer, eller för ett tjänstkonto som är konfigurerat att köras som LocalSystem eller med administratörsbehörighet. Angriparen kan sedan extrahera autentiseringsuppgifterna för administratörskontot och spela upp dessa autentiseringsuppgifter i nätverksinloggning till andra datorer i nätverket.

Så länge en annan dator har ett lokalt konto med samma användarnamn och lösenord (eller lösenordshash) som de kontoautentiseringsuppgifter som visas lyckas inloggningsförsöket och angriparen får privilegierad åtkomst till måldatorn. I aktuella versioner av Windows är det inbyggda administratörskontot inaktiverat som standard, men i äldre operativsystem är kontot aktiverat som standard.

Anmärkning

Vissa organisationer har avsiktligt konfigurerat lokala administratörskonton för att vara aktiverade i tron att detta ger en "säkerhetsmekanism" om alla andra privilegierade konton är låsta ute från systemet. Men även om det lokala administratörskontot är inaktiverat och det inte finns några andra konton tillgängliga som kan aktivera kontot eller logga in på systemet med administratörsbehörighet, kan systemet startas i felsäkert läge och det inbyggda lokala administratörskontot kan återaktiveras, enligt beskrivningen i Microsoft Support-artikeln 814777. Om systemet fortfarande framgångsrikt tillämpar GPO:er kan ett GPO ändras för att (tillfälligt) återaktivera administratörskontot, eller så kan begränsade grupper konfigureras för att lägga till ett domänbaserat konto i den lokala gruppen Administratörer. Reparationer kan utföras och administratörskontot kan inaktiveras igen. För att effektivt förhindra en lateral kompromiss som använder inbyggda lokala autentiseringsuppgifter för administratörskontot måste unika användarnamn och lösenord konfigureras för lokala administratörskonton. Information om hur du distribuerar unika lösenord för lokala administratörskonton via ett grupprincipobjekt finns i Lösning för hantering av det inbyggda administratörskontots lösenord via grupprincipobjekt på technet.  

Tillåta installation av otillåtna program

Lag nummer ett: Om en skurk kan övertala dig att köra sitt program på din dator, är det inte bara din dator längre. - Tio oföränderliga säkerhetslagar (version 2.0)

Om en organisation distribuerar konsekventa baslinjeinställningar mellan servrar bör installation av program som inte ingår i en servers definierade roll inte tillåtas. Genom att tillåta att programvara installeras som inte ingår i en servers avsedda funktioner, exponeras servrar för oavsiktlig eller skadlig installation av programvara som ökar serverns attackyta, introducerar programsårbarheter eller orsakar systeminstabilitet.

Ansökningar

Som tidigare beskrivits installeras och konfigureras program ofta för att använda konton som beviljas mer behörighet än vad programmet faktiskt kräver. I vissa fall anger programmets dokumentation att tjänstkonton måste vara medlemmar i en servers lokala administratörsgrupp eller vara konfigurerade att köras i kontexten för LocalSystem. Detta beror ofta inte på att programmet kräver dessa rättigheter, utan för att det krävs investeringar i ytterligare tid och ansträngning för att avgöra vilka rättigheter och behörigheter ett programs tjänstkonton behöver. Om ett program inte installeras med den minsta behörighet som krävs för programmet och dess konfigurerade funktioner för att fungera, exponeras systemet för attacker som utnyttjar programbehörigheter utan angrepp mot själva operativsystemet.

Brist på säkra metoder för programutveckling

Infrastrukturen finns för att stödja affärsarbetsbelastningar. När dessa arbetsbelastningar implementeras i anpassade program är det viktigt att säkerställa att programmen utvecklas med hjälp av säkra metodtips. Rotorsaksanalys av företagsomfattande incidenter visar ofta att en första kompromiss utförs via anpassade program, särskilt de som är Internetuppkopplade. De flesta av dessa kompromisser uppnås genom att välkända attacker som SQL-inmatning (SQLi) och XSS-attacker (cross-site scripting) komprometteras.

SQL-injektion är en applikationssårbarhet som gör att användardefinierade indata kan ändra en SQL-instruktion som skickas till databasen för körning. Dessa indata kan anges via ett fält i programmet, en parameter (till exempel frågesträngen eller en cookie) eller andra metoder. Resultatet av den här inmatningen är att SQL-instruktionen som tillhandahålls till databasen skiljer sig i grunden från vad utvecklaren avsåg. Ta till exempel en vanlig fråga som används i utvärderingen av en kombination av användarnamn/lösenord:

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

När detta tas emot av databasservern instrueras servern att titta igenom användartabellen och returnera alla userID-poster där användarnamnet och lösenordet matchar de som tillhandahålls av användaren (förmodligen via ett inloggningsformulär av något slag). Naturligtvis är utvecklarens avsikt i det här fallet att endast returnera en giltig post om användaren kan ange ett korrekt användarnamn och lösenord. Om någon av dem är felaktig kan databasservern inte hitta en matchande post och returnera ett tomt resultat.

Problemet uppstår när en angripare gör något oväntat, till exempel att tillhandahålla sin egen SQL i stället för giltiga data. Eftersom SQL tolkas direkt av databasservern bearbetas den inmatade koden som om utvecklaren hade lagt den i sig själv. Om angriparen till exempel angav administratör för användar-ID och xyz OR 1=1 som lösenord, skulle den resulterande instruktionen som bearbetas av databasen vara:

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

När den här frågan bearbetas av databasservern returneras alla rader i tabellen i frågan eftersom 1=1 alltid utvärderas till Sant, vilket innebär att det inte spelar någon roll om rätt användarnamn och lösenord är känt eller angivet. Nettoresultatet är i de flesta fall att användaren loggas in som den första användaren i användarens databas. I de flesta fall är detta den administrativa användaren.

Förutom att bara logga in kan felaktiga SQL-instruktioner som detta användas för att lägga till, ta bort eller ändra data eller till och med släppa (ta bort) hela tabeller från en databas. I de mest extrema fall där SQLi kombineras med överdriven behörighet kan operativsystemkommandon köras för att göra det möjligt att skapa nya användare, ladda ned attackverktyg eller vidta andra åtgärder som angriparna väljer.

Vid skriptkörning mellan webbplatser introduceras sårbarheten i programmets utdata. En attack börjar med att en angripare tillhandahåller felaktiga data till programmet, men i det här fallet är de felaktiga data i form av skriptkod (till exempel JavaScript) som ska köras av offrets webbläsare. Om en XSS-säkerhetsrisk utnyttjas kan en angripare köra alla funktioner i målprogrammet i kontexten för användaren som startade webbläsaren. XSS-attacker initieras vanligtvis av ett nätfiskemeddelande som uppmuntrar användaren att välja en länk som ansluter till programmet och kör attackkoden.

XSS utnyttjas ofta i onlinebank- och e-handelsscenarier där en angripare kan göra inköp eller överföra pengar i kontexten för den utnyttjade användaren. Vid en riktad attack mot ett anpassat webbaserat identitetshanteringsprogram kan en angripare skapa egna identiteter, ändra behörigheter och rättigheter och leda till en systemisk kompromiss.

Även om en fullständig diskussion om skript mellan webbplatser och SQL-inmatning ligger utanför omfånget för det här dokumentet, publicerar OWASP (Open Web Application Security Project) en topp 10-lista med djupgående diskussioner om sårbarheter och motåtgärder.

Oavsett investeringen i infrastruktursäkerhet, om dåligt utformade och skriftliga program distribueras inom infrastrukturen, blir miljön sårbar för attacker. Även väl skyddade infrastrukturer kan ofta inte ge effektiva motåtgärder till dessa programattacker. För att förvärra problemet kan dåligt utformade program kräva att tjänstkonton beviljas för höga behörigheter för att programmet ska fungera.

Microsoft Security Development Lifecycle (SDL) är en uppsättning strukturella processkontroller som fungerar för att förbättra säkerheten med början tidigt i kravinsamlingen och utökar programmets livscykel tills det har inaktiverats. Den här integreringen av effektiva säkerhetskontroller är inte bara kritisk ur ett säkerhetsperspektiv, utan det är viktigt att säkerställa att programsäkerheten är kostnadseffektiv och att schemat är effektivt. För att utvärdera ett program för säkerhetsproblem när det är effektivt kodfyllt måste organisationer fatta beslut om programsäkerhet först före eller till och med efter att programmet har distribuerats. En organisation kan välja att åtgärda programfelen innan programmet distribueras i produktion, vilket medför kostnader och fördröjningar, eller så kan programmet distribueras i produktion med kända säkerhetsbrister, vilket gör att organisationen kan komprometteras.

Vissa organisationer lägger hela kostnaden för att åtgärda ett säkerhetsproblem i produktionskoden över 10 000 USD per problem, och program som utvecklats utan en effektiv SDL kan i genomsnitt ha mer än tio problem med hög allvarlighetsgrad per 100 000 rader kod. I stora program eskalerar kostnaderna snabbt. Däremot sätter många företag ett riktmärke på mindre än ett problem per 100 000 kodrader i det slutliga kodgranskningssteget i SDL och siktar på nollproblem i högriskprogram i produktion.

Implementering av SDL förbättrar säkerheten genom att inkludera säkerhetskrav tidigt i kravinsamling och utformning av ett program ger hotmodellering för högriskprogram. kräver effektiv utbildning och övervakning av utvecklare. och kräver tydliga, konsekventa kodstandarder och metoder. Nettoeffekten av en SDL är betydande förbättringar av programsäkerheten samtidigt som kostnaden för att utveckla, distribuera, underhålla och inaktivera ett program minskar. Även om en detaljerad diskussion om design och implementering av SDL ligger utanför det här dokumentets omfång, kan du läsa mer i Microsoft Security Development Lifecycle för detaljerad vägledning och information.