It-säkerhet enligt HPS

Stefan Pettersson på High Performance Systems skriver om säkerhet på svenska

Tagg: förberedelser

Förberedelser i bild

Det här fotot har cirkulerat i mer än en vecka nu men det förtjänar det. Fotot är taget av en fotograf på Reuters medan stormen Sandy låg över New York och New Jersey. Lägre Manhattan i mörker med hotfulla moln över, en fastighet lyser som om inget har hänt. 200 West St, Goldman Sachs huvudkontor.

Det här handlar förstås uteslutande om att Goldman Sachs var mer förberedda än sina grannar, vilket de var medvetna om:

We wanted to take this opportunity to let you know that we have strong business continuity plans in place at Goldman Sachs Asset Management and are open for business. Most NY-based employees are working from home or are partnering with their global and US counterparts to cover important items.  Our portfolio management teams are actively engaged and are closely monitoring our client portfolios.

Anledningen är att de har räknat på hur mycket pengar de förlorar (läs: inte tjänar) om de måste avbryta handeln. (Enligt en bekant med god insyn i detta så handlade Goldman ”som fan” under hela Sandy.)

Jag återberättade för några år sen historien om Morgan Stanleys säkerhetschef Rick Rescorla och den 11 september. En fantastisk historia som förmodligen inte är helt sann men ändå är bra och framförallt illustrativ.

Trevlig helg!

Sophos: security features != secure features

The paper includes a working pre-authentication remote root exploit that requires zero-intera[c]tion, and could be wormed within the next few days. I would suggest administrators deploying Sophos products study my results urgently, and implement the recommendations.

Så inleds den andra delen av Tavis Ormandys Sophail-rapport som släpptes på Full-Disclosure i måndags. Det är en kuslig påminnelse att det är skillnad på säkerhetskomponenter och säkra komponenter.

Mitt examensarbete på skolan behandlade i viss utsträckning generiska skydd mot buffer overflows: till exempel stack canaries, NX/XD och ASLR. CJ, som var min handledare, och jag var då och träffade en återförsäljare av just Sophos i hopp om att få lite mer information om hur deras BOPS-teknik fungerade. BOPS, eller Buffer Overflow Protection System, skulle alltså vara ytterligare ett sådant generiskt skydd.

Lång historia kort, vi blev besvikna. Den ”expert” som vi fick prata med förklarade att man kunde sätta på BOPS för enskilda binärer eller globalt och sedan vitlista vissa binärer. Hur BOPS verkligen gjorde för att stoppa attacker hade han ingen aning om. Wow.

Överraskande nog har BOPS precis motsatt(!) effekt, avsikten är att införa något som liknar ASLR men istället ser den till att det alltid finns en statisk (istället för en slumpmässig) adress i minnet att gå mot. Från Ormandys rapport (min fetstil):

The purpose of BOPS (although it does not work) is to provide a faux-ASLR implementation for Windows XP. Sophos ship the product on other platforms but it is essentially a no-op. Sophos uses AppInit_DLLs to force load this nondynamicbase module into every process, disabling ASLR on platforms that do have it enabled.

This effectively disables ASLR on all Microsoft Windows platforms that have Sophos installed, allowing attackers to develop reliable exploits for what might otherwise have been safe systems

Christoffer var snabbare att dra parallellen till Kerckhoff och hans hundra år gamla princip.

Ormandy ger tre råd till de drabbade:

  1. Förbered er på att stänga av Sophos AV på alla system (om en mask skulle dyka upp).
  2. Installera inte Sophos-produkter på kritiska system, det finns helt enkelt för många sårbarheter.
  3. Installera inte Sophos-produkter på system som är svåra att uppdatera, det finns helt enkelt för stort behov att hålla produkten uppdaterad.

Det är ett obehagligt problem att programvara som utvecklas och distribueras brett ibland är i dåligt skick. Det är sånt som gör skadeansvar till ett intressant ämne.

Incidenthantering

I slutet på 80-talet, när internet fortfarande använde pottan, fanns en ung man som hette Robert Morris. Han är känd för att vara skapare av en av de första datormaskarna, program som autonomt sprider sig från dator till dator. Masken i fråga, the Morris Worm eller ibland the Internet Worm, släpptes lös den 2 november 1988 och infekterade UNIX-maskiner genom att utnyttja säkerhetsbuggar i sendmail och fingerd samt trust-förhållanden (rsh) och svaga lösenord.

En betydande del av internet infekterades. På grund av en blunder i designen kunde masken infektera samma dator flera gånger, efter tillräckligt många infektioner kunde inte datorerna klara antalet processer längre och lade av.

Det finns massor av text att plöja om den här erfarenheten: Gene Spaffords analys och RFC 1135 är bra. Det är förresten tråkigt att begreppet helmintiasis som RFC:n använder inte fick fäste. Helmintiasis är nämligen benämningen på ”[i]nfektioner orsakade av rundmaskar (nematodinfektioner) och bandmaskar (cestodinfektioner)”.

Internet var designat för att klara av fysiska angrepp, om en central router slogs ut skulle trafiken routas om automatiskt. Internet var inte bara ett sätt att koppla ihop forskare, internet var själv ett forskningsprojekt inom survivability. Internet var dock inte rustat för masken.

Vad gjorde då DARPA som var ansvarig för internet när det begav sig? Installerade de antivirus-program på alla servrar? Utvecklade de och sålde brandväggar med unified threat management? Startade de ett regulatoriskt organ som gav ut pärmar med obligatoriska säkerhetskrav?

Nej.

När man insåg att man var dåligt förberedd startades Computer Emergency Response Team Coordination Center vanligtvis känt som CERT® Coordination Center.

Man förberedde sig på incidenthantering.

Vad är det fina med den åtgärden? Jo, CERT kunde agera på allt. Det spelade ingen roll om det var en mask eller hackerintrång eller vilken metod masken eller hackern använde. Det var ett generellt skydd, inte heltäckande men generellt.

Varje gång det händer något så är de värdefulla. Det är enkelt att räkna upp hundra situationer då en UTM-brandvägg är fullständigt värdelös men det är svårt att komma på särskilt många relevanta situationer där förberedd incidenthantering är det.

På sätt och vis är en förberedd incidenthanteringsgrupp den ultimata säkerhetsåtgärden. Varför är då min upplevelse att företag investerar tvärt om?

Slutsatser av intrånget hos Formspring

Det sociala nätverket Formspring gick här om dagen ut med att de har haft intrång. Nätverket har flera miljoner användare men ”bara” omkring 420 000 hashar har gjorts publikt tillgängliga. Den publicerade listan innehåller enligt utsago bara hasharna och inte användarnamn eller mailadress. Hasharna, för övrigt, var saltade SHA256. Det finns några intressanta punkter i Formsprings blogginlägg.

Screenshot from Formspring's blog post on the breach.

(1) Det var inte offret själv som upptäckte intrånget, det var en användare som hittade dumpen på ett hackerforum och hörde av sig till Formspring. Vi har redan lärt oss av Verizons Data Breach Investigations Report att det är så i majoriteten av fallen (92 % under 2011): någon annan än offret upptäcker intrånget.

(2) Man hade förberett sig med möjligheten att tvinga till lösenordsbyte vid inloggning. Mycket effektivare än att be snällt. Om ett system inte har särskilda säkerhetsbehov så är sådan funktionalitet, att kunna tvinga byten efter t ex intrång, viktigare än att tvinga regelbundna byten.

(3) De är rätt förtegna om hur intrånget gick till tyvärr men som de skriver: någon bröt sig in i en utvecklinggsserver och lyckades använda den åtkomsten för att komma åt produktionsdatabasen. Det är så dataintrång går till; ofta krävs bara en, tillräckligt stor maska någonstans för att kunna riva upp hela mattan.

(4) Man är i begrepp att gå över till kraftiga lösenordshashar, OpenBSD-projektets Blowfish-baserade bcrypt (PostScript) med salt och stretching närmare bestämt. Bra val! För lösenordshashar gäller samma sak som för kryptering: designa inte dina egna algoritmer eller implementeringar.

(5) Formsprings snabba och relativt öppna hantering av intrånget leder också till att deras PR inte lider allt för svårt. Samma sak som gällde när WordPress hackades för något år sedan. Det här är en jätteviktig punkt, en läsvärd artikel på FastCompany diskuterade det här för någon månad sedan, The Top Mistakes Companies Make In Data Breaches:

  1. Failing to use peacetime wisely.
  2. Failing to respond with the speed stakeholders expect.
  3. Falling short of full transparency.
  4. Providing details before all the facts are known.

Jag är naturligtvis ett fan av att utnyttja fredstiden, eller, som en kapten sa under min GU: det tillfälliga läget av okrig.

Förberedelser

Scout som gör hälsning med USA:s flagga i bakgrunden.

Scouternas motto må vara lite obehagligt pretentiöst men det är ändå synnerligen viktigt i säkerhetssammanhang. Jag vet inte hur scoutkåren definerar det men jag skulle säga att huruvida man är redo eller inte beror på förberedelser.

Jag illustrerar med en kort historia:

Kommer tillbaka från lunchen, sätter mig ner, Adam sticker in huvudet genom dörren och frågar om det är något problem med mailservern. Tittar på skärmarna på väggen; Nagios visar att både mailservrar och namnservrar är gröna, MRTG visar att trafiken har kickat igång igen efter lunchnedgången. ”Nä, inte vad jag vet, hurså?”, frågar jag. Adam förklarar att varken han eller Bertil kan skicka mail till kund X eller Y.

Kund X och Y har inget med varandra att göra. Skickar ett mail till min privata adress, inga problem. Kontrollerar mailserverns utgående ip-adress i diverse blacklists på mxtoolbox.com. Hoppsan, blacklistad på två olika listor. Har vi skickat spam?

Just fan, Caesar höll ju på med den där Java-Tomcat-ärendehanterings-tjofset som behövde komma ut på internet över smtp. Snabb sökning i brandväggens regelfil visar att han lade till ”/24” efter sourceadressen av bara farten när han lade in regeln. Hela utvecklingsnätet får skicka mail förbi mailservern. Inte bra.

Ändrar regeln på brandväggen och laddar om. Kopierar de föregående dagarnas NetFlow-loggar från brandväggen och söker på flöden utgående från utvecklingsnätet mot 25/tcp. Shite, tusentals långa mailflöden, förmodligen reklam för diverse apoteksvaror, har runnit ut sedan gårdagen. En ip-adress är ansvarig för samtliga.

Loggar in på dhcp-servern, söker loggarna och hittar vilken hårdvaruadress som hade ip-adressen tilldelad vid tillfället. Söker på hårdvaran i inventeringslistan, naturligtvis är det arkitekt-Davids laptop… Går upp till våning fem, hyvlar av honom och blåser om hans dator.

Även om vår systemadministratör hittade felet lite onaturligt snabbt så är det överlag en verklighetstrogen berättelse. I den finns flera exempel på förberedelser som kraftigt underlättade problemlösningen:

  • Nagios och MRTG kunde direkt visa att det inte rörde sig om någon nertid eller funktionsfel på mailservern eller någon av dess beroenden. Om det hade rört sig om nertid hade det varit tydligt från vilken tidpunkt det hade skett. Kanske hade till och med vår administratör sett det redan när hon kom in genom dörren så att Adam kunde lugnas på en gång?
  • Möjlighet att söka bland reglerna i brandväggen; med Netfilter eller PF är det den naturligaste saken i världen, hur är det med din vägg? Det kanske måste lösas på något särskilt sätt?
  • NetFlow på brandväggen möjliggör trafikanalys i efterhand, det bästa som går att uppbringa näst efter full packet captures; vem har pratat med vem vid vilken tid, ungefär. Oavsett hur mailen hade lämnat företaget så hade det framgått i NetFlow.
  • Loggar från dhcp-servern är så viktigt att t o m EU skriver lagar om det. Eftersom ip-adresser ibland är väldigt lösaktiga och hänger med vem som helst så är det minsta man kan göra att åtminstone hålla reda på vilka de varit med. Oaktat att s k hårdvaruadresser går att spoofa så är dhcp-loggen klistret som håller ihop det logiska nätverket med de fysiska maskinerna.
  • En uppdaterad inventeringslista är betydligt bekvämare än att kontrollera undersidan på varje laptop på ett helt våningsplan. (Hörde jag någon nätverksadmin mumla något om switchportar och en dokumenterad patchpanel?)

Givetvis finns det andra förberedelser som kunde ha varit ännu bättre, så fort du börjar fundera på det så kommer du på flera stycken. Om du var vår hjältinna, vad hade du önskat att du gjort för förberedelser?

Rick Rescorla

Det tråkiga med att arbeta med säkerhet är att det är lite action på riktigt. Även om intrång är vanligare än de flesta tror så är det forfarande relativt ovanligt. Det handlar huvudsakligen (förhoppningsvis) om rutiner och förberedelser. Dessutom, ju hårdare du jobbar i den gråa vardagen, desto mindre chans är det att det blir ”allvar”.

Soldater har en liknande situation. Boken Bravo Two Zero, om en grupp från brittiska specialförbandet SAS som ska sabotera kommunikationsledningar i Irak under Gulfkriget,  inleds med ”Every soldier hopes for a major war in his lifetime. This one was mine.”

Som bekant förespråkar jag övning.

Rick Rescorla var sedan i början av 90-talet säkerhetschef på Morgan Stanley. Morgan Stanley har länge varit en av de största hyresgästerna i World Trade Center och Rescorla hade under 1992 påpekat för WTC-ägarna att säkerheten i garaget borde skärpas. Ett exempel på en attack som Rescorla föreslog var att köra in och detonera en bil med sprängämnen. Den 26 februari 1993 hände just detta. Sex personer omkom och något tusental skadades.

Vid evakueringen 1993 tyckte Rescorla att det gick för långsamt och efter att förslag om att byta kontorsbyggnad hade nekats från ledningen införde han regelbundna, oförberedda utrymningsövningar. Man kan enkelt tänka sig att det knorrades en hel del varje gång 3 000 personer fick släppa allt, ställa upp i korridoren och gå ner för trapporna två och två, påhejade av en säkerhetschef med tidtagarur och megafon.

Många av de anställda på Morgan Stanley slussar en hel del pengar under en arbetsdag så det handlar inte om några billiga övningar. IT-avdelningen var nog inte heller särskilt förtjusta över att backupbanden skulle förvaras i en annan byggnad på andra sidan bukten.

Rescorla såg det första planet träffa det andra tornet från sitt kontor på morgonen den 11 september 2001. Morgan Stanleys anställda var alltjämt informerade om att de inte skulle lyssna till vad hyresvärden sade åt dem i sådana här situationer (de uppmanade alla att stanna) och började på Rescorlas initiativ utrymma byggnaden. Precis som vanligt. Den här gången ljöd nationalsången och gamla, brittiska soldatvisor från säkerhetschefens megafon under evakueringen.

Omkring 15 minuter senare, när det andra planet träffade den byggnad som Morgan Stanley fanns i, var majoriteten av deras 2 700 anställda, och några hundra besökare som råkade vara där, ute ur byggnaden. Recorla och tre av hans assistenter gick åter in i byggnaden för att fortsätta evakueringsarbetet.

Beroende på vilken källa man väljer att lita på så förlorade Morgan Stanley sex eller tretton av sina medarbetare den 11 september. Fyra av dem var Rescorla och hans tre assistenter.

Från artikeln A Survival Guide to Catastrophe i Time:

Between songs, Rescorla called his wife. ”Stop crying,” he said. ”I have to get these people out safely. If something should happen to me, I want you to know I’ve never been happier. You made my life.” Moments later, he had successfully evacuated the vast majority of Morgan Stanley employees. Then he turned around. He was last seen on the 10th floor, heading upward, shortly before the tower collapsed. His remains have never been found.

Hollywood-aktigt? Ja, definitivt. Rescorla lämnade två barn efter sig och var dessutom dekorerad veteran från Vietnamkriget. Det är sånt här det görs filmer om. Riktigheten i informationen om sådana här sensationella historier ofta väldigt skakig så man ska ta det med en nypa salt.

Faktum kvarstår, i säkerhetsbranschen är det sällan allvar men det kan vända väldigt snabbt. Kommer man att ha kontrollen och rutinen som krävs för att hantera det? Det är en viktig fråga oavsett om ett flygplan plötsligt krashar in i byggnaden bredvid dig eller om en kollega kommer in och frågar om du har skapat ett konto med namnet x_marty på den viktiga servern.


Stefan Pettersson

Drift

Idag var en av de där läskiga dagarna när man jobbar på drift, disaster recovery-övningar. Idag provade vi hur de viktiga servrarna klarade av ett plötsligt strömavbrott. Oavsett hur bra koll man (tror att man) har på hur tjänsterna på en server fungerar är det rätt nervöst att dra ut sladdarna när den är uppe i nästan två hundra dagar uptime… Naturligtvis gick det inte som planerat (det gör det aldrig):

  • 07:00-08:00 klipp strömmen till servrar, håll tummar
  • 08:00-10:00 få tjänster att fungera igen innan någon märker något, tandgnisslan
  • 10:00-12:00 lura ut hur man undviker problemen nästa gång, ljus i tunneln
  • 12:00-18:00 ändra configs och uppdatera dokumentation, lite bättre än igår

Drift
Server- och nätverksdrift är relativt osexigt, vissa kallar det till och med ”förvaltning” för att göra det ännu värre. Jag skulle dock argumentera för att det är under driftfasen som säkerhetsarbetet har störst betydelse. Tyvärr har det blivit modernt att, nästan uteslutande, problematisera applikationsutvecklingen och säga att det är där slagen kan vinnas i framtiden. Undertecknad inkluderad. Vi har nog rätt. På sikt. Men inte riktigt än.

Men egentligen är det ganska enkelt. Brandväggar, patchar, långa lösenord, övervakning, åtkomstkontroll, logghantering och alla andra grejer är det som håller oss flytande medan vi fortfarande lever med dåligt utvecklade system. Det är inte utvecklare som håller våra nätverk säkra. Inte än. Det är fortfarande driften som kan bära största vikten.

(Med reservation för dålig drift… naturligtvis.)