Säkerhetshål i Exchange Server – fool me once…

Ett stort antal organisationer stod också med byxorna nere då deras Exchange exponerats med webbgränssnitt mot internet. Automatiserade skript kördes igång för att utnyttja sårbarheten och plantera t.ex. bakdörrar för framtida åtkomst.

Allvarligt med andra ord. Microsoft hissade röd flagg och skickade ut instruktioner om hur sårbarheten kan korrigeras och hur man kan leta rätt på eventuella bakdörrar. Vi på Atea har jobbat mer eller mindre dag och natt med att hjälpa våra kunder (100+) sen dess.

Jag gissar att många fortfarande arbetar med att uppdatera sina servrar och utreda om man har råkat ut för intrång. Sannolikt har många fått installera om sin Exchange-servrar.

Nog om detta. Detta kommer hända igen i någon mjukvara vi använder. Hur ska vi förebygga och minska påverkan nästa gång detta händer? Det är som sagt inte första eller sista gången vi kommer drabbas av en sån här ”chocksårbarhet”.

Do's and don'ts

Det finns några ”do's and don’ts” och detta dokument gör inte anspråk på att vara uttömmande men det innehåller ett antal konkreta och bra tips.

• Först och främst, glöm inte bort klassisk nätverkssäkerhet med DMZ-segmentering, brandväggsfiltrering och intrångsskydd. Att se till att endast det som ska exponeras mot omvärlden gör det, Exchange-servern i detta fall, och om någon tar sig in i det som exponeras så se till att det är svårt att ta sig vidare.
  
  
• Använd robusta säkerhetsprodukter för applikationslagret, proxys, som tar emot och autentiserar anslutningarna innan de slussas vidare till målsystemet, helst med två-faktorsautentisering. I proxyn bör trafiken också dekrypteras, kontrolleras och kan dessutom lastbalanseras mot fler servrar på insidan.
  
  Släpp alltså inte in trafik från hela internet rakt in till en server på det vanliga interna nätverket. Punkt.
  
  
• Tänk lager-på-lager. Använd bra skydd på de enheter som till sist tar emot trafiken, Exchangeservern i detta fall. Antivirus hette det förr och letade efter filer med en viss signatur. Nu gör klient/serverskydd mer och analyserar beteendet hos potentiellt skadlig kod, till exempel håller koll på att viktiga systemfiler inte förändas och att något inte petar i arbetsminnet för att putta in något elakt och oönskat.
  
  Det fanns en tid när man ”inte hade antivirus på servrar”. Den tiden är förbi och skyddet behöver vara bättre än ett traditionellt antivirus. Punkt.
  
  
• Sist men inte minst. Uppdatera. Uppdatera. Uppdatera. Med automatik. Har ni höga krav på tillgänglighet, se till att ha täta backuper och testmiljöer för att verifiera att uppdateringen fungerar innan den släpps på i produktionsmiljön. Använd gärna sårbarhetsscanners för att verifiera att allt verkligen är uppdaterat och även för att upptäcka felkonfigureringar.

Sammanfattningsvis, förebygg att ni är sårbara och exponerade nästa gång en kritisk sårbarhet upptäcks och utnyttjas. Det finns bra tänk och teknik. Det är billigare i kronor räknat att förebygga än att agera reaktivt. Addera sen kostnaden för konsekvensen av data som hamnar i orätta händer, inte är tillförlitligt eller är otillgängligt.

Fool me once - shame on you, fool me twice - shame on me.

Ta till er av dessa råd så är ni bättre rustade nästa gång.Jag, som infosäkare, får ofta frågan ”På vilket sätt är molnet säkrare?”. Detta scenario, med en sårbar tjänst exponerad mot internet, är ett bra exempel på där leverantören ska ha ansvar för övervakning, åtgärd och säkring av miljön när kunden sover gott. Molnet är fortfarande bara "någon annans dator" men den tas om hand av specialister för just den tillämpningen och det har ni svart på vitt.