Säkerhetstestning och Hjärtblödning (Heartbleed)
Vad skulle hända med ert företag, verksamhet, applikation, system eller service blev utsatt för en hackerattack, t.ex. kom över inloggningsuppgifter eller privat och känslig information såsom kreditkort eller bankkontonummer?
I denna artikel försöker jag både ge er piska och morot, för att påskynda er möjlighet och vilja att säkerhetstesta eller i alla fall hjälper er att ställa rätt frågor till de ni anlitar att säkerhetstesta.
Piska
Heartbleed buggen, ref [1], som exponeras på internet är i särklass den störst säkerhetsdefekten på länge, om inte någonsin. Är du osäker på hurvida ni använder openssl bibliotek i den mjukvara ni ska testa, tycker jag inte du ska läsa denna artikel vidare utan helt enkelt undersöka det först och eventuellt i så fall börja testa ögonblickligen, ref [0]. Openssl används på de flesta platformar och OS.
En komiskt sidoeffekt är att denna defekt har gjort att polisiära myndigheter har kunnat “hacka” in i hackarnas “trygga” online forum där ljusskygga individer samlats och kunnat samlat info om vilka som är hackare. Man kan med stor säkerhet anta att nationella säkerhets avlysningsmyndigheter använt denna metod att avlyssna hackare.
Men även i vintras skedde en incident som belyser hur viktig säkerhetstestning och kunskap om säkerheten i våra system och applikationer är;
I USA kom nyligen hackare åt kontokortsuppgifter, adresser, telefonnummer i www.Target.com internetaffär, ref [2]. 70 miljoner användare ( ja, du läste rätt siffra!) fick i de flesta fall kommunikation från deras banker att byta kreditkort, åtminstone två av bankerna i USA har stämt Target på ganska betydande belopp, ref [2b]. Är man test chef och fortfarande inte tycker att säkerhetstestning kan vara värt att lägga lite pengar på så önskar jag bara er lycka till, och rekommenderar att ha CVn uppdaterad, för den kommer behövas användas inom en nära förestående framtid!
Säkerhetstestaren behöver förutom de vanliga testkunskaperna ganska mycket domänkunskap, t.ex. inom crypto, ssl och internet protokol, samt inte minst testverktyg. Hackarna har ju oftast dessutom väldigt gott om tid och ett enormt sug efter berömmelse, vilket en stressad testare med flera parallella test projekt sällan har. I vissa organisationer kan det vara en bättre idé att initialt budgetera extern konsulttid för säkerhetstestning.
En vanlig invändning man ofta får från personer som är mycket lite insatta i området är, den något romantiska bilden, att det skulle ta för lång tid för en människa att lista ut hur man bryter sig in i just deras applikation eller nätverk. Men det är just det som är poängen! Det är väldigt sällan en ensam hackare sitter och manuellt testar olika portar på ett specifikt ip nummer. Nästan uteslutande används färdiga automatiska tester där dator(er i kluster) kontinuerligt scannar stora områden av ip-nummer efter kända defekter, s.k. “exploits”, ref[4], och automatiskt söker efter kända mönster, t.ex. hur en http port eller webservice svarar om mjukvaran har en känd och definierad defekt. Alvarligare säkerhetsdefekter är de som ej ännu är publikt kända, s.k. “zero-day”, ref [18] . Lyckligtvis har väldigt få av de normalbegåvade hackarna tillräckligt kunskap att förstå, känna till eller kunna utnyttja dem.
Vill man bättre förstå hur en hackare tänker och vad som driver honom rekommenderas boken “Svenska hackare : en berättelse från nätets skuggsida”, ref[16]. Är man ändå i bokhandeln rekommenderar jag “The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws” , ref[17].
Säkerhetstest är lite olikt både funktionella och ickefunktionella tester på många sätt, men främsta skillnaden är att syftet i stort endast går ut på att hitta defekter. Syftet är sålunda varken validering eller verifiering. Om systemet kravmässigt eller funktionellt gör, eller inte gör vad det ska, är helt ointressant för en säkerhetstestare. Jag rekommenderar att säkerhetstesta efter både funktionell testning och viss prestandatestning utförts, därför att säkerhetsverktygen kommer stressa SUT med många repeterade och samtidiga förfrågningar. Det går teoretiskt att säkerhetstesta ett system som funktionellt inte är till fullo implementerat eller testat. Men det är svårt eftersom man kan få “falska postiva”, eller ännu värre , “falska negativa” resultat.
Att hitta alla möjliga säkerhetsdefekter är som vanligt inom testområdet, en utopi. Alla system och applikationer går att bryta sig in i givet tillräckligt stora resurser i form av tid och beräkningsresurser.
Inget system är helt säkert, det är det enda som är säkert.
Nyligen offentliggjorde FBI & EuroPol ett stort hackernätverk, “Blackshades”, hade sprängts, med fler än 90 personer arresterade, ref [20], efter samarbete av polismyndigheter i 19 länder.
Syftet med säkerhetstesterna kan istället sägas vara att man för sin uppdragsgivare eller organisation påvisar de alvarligaste säkerhets defekter, hål som är enkla att täppa igen. På så gör man det så svårt och arbetsamt som möjligt för en hacker att ta sig in i systemet. Hackaren fortsätter då förhoppningsvis vidare till en annat företag. Lite som att ha en “varning för hunden” skylt utanför där man bor. Din dörr kommer inte vara den första dörren inbrottstjuven vill gå igenom, troligtvis en av de sista.
Systematiskt tillvägagångsätt
En säkerhetstestare går ofta tillväga på samma sätt som en hackare skulle gjort och tillvägagångssättet kan delas in i nedan faser.
Normalt systematisk tillvägagångssätt för penetrationstestaren och hackaren:
Steg |
Namn |
Definition |
1 |
Undersökning |
Publik affärs info och data insamling, fastställa netblocks (ip-områden) tex via Iana.org, ripe.org, Nsloookup , Archive.org |
2 |
Scanna |
Fastställa samt examinera levande/online värddatorer, portar, tjänster, t.ex. med NMAP |
3 |
Enumerera |
Fastställa samt examinera Användare, webservrar, lösenord, epost, FTP , SNMP tillgänglighet |
4 |
Penetration |
(Det roliga steget för hackaren!) lösenords gissning, kända brister, |
5 |
Eskalering(rättighet) |
Använda kända brister, ref [4] , Utnyttja konfigurerings-misstag, öka rättigheter (oftast från gäst) till Adminstrator/root |
6 |
Interaktiv |
Exekvera processer på systemet med NetCat, PSExec, RDP , VNC |
7 |
Plundring |
Plundra systemen på kreditiv/id+lösenord, data, påloggade LM/NT hashar, knycka sessionsnycklar m.m. |
8 |
Uppstädning |
Manipulera loggar- ta bort spår efter inloggning. Installera Rootkits – som gör det möjligt att återansluta enkelt. Vid nästa åter-intrång kommer hackaren alltså in direkt på steg 6, utan att behöva allt förarbete. |
Beroende på testets syfte hoppas ibland vissa steg över, t.ex. om man av ett företaget blivit kontrakterad att bara säkerställa en viss applikation eller delsystem och inte hela deras intranät eller hur väl deras IT nätverk skyddar mot intrång.
Verktyg
Som med all professionell testning föredrar jag använda verktyg som är kommersiellt beprövade och där assistans kan fås via en supportavdelning . Säkerhetstestningsområdet har dock en uppsjö med opensource verktyg som är bra. Några som är speciellt värda att nämnas är NMAP, Kali . De mest omtyckta verktygen hittar ni här , ref [ 3].
Några av de mer kända kommersiella verktyg som återkommer att nämnas på de kurser jag gått och från andra källor är BurpSuite av Portswigger. Det finns andra verktyg som innehåller säkerhetstest-funktionallitet, även om dess huvudsyfte är ett annat. SoapUI av Smartbear kan nämnas som ett sådant verktyg. Oavsett vilken leverantör ni väljer så är det viktigt att undersöka och göra ett mindre pilot- projekt av vad som produkten verkligen klarar av, på ett isolerat område av er produkt. Använd helst först fel-injektering, s.k. fault injection, ref [19], för att påvisa att verktygen verkligen hittar de defekter som ni då vet finns “planterade” i systemet. Det finns nämligen verktyg som inte hittar de defekter de utlovar sig göra.
Metoder och processer för Systemsäkerhetsklassificering
Det finns en mängd olika metoder för att definiera säkerhet i system. Några som kan nämnas är tex. Microsoft SDL, ref [5], samt de från ISC2 [7]. Men rent generellt gäller för de flesta metoder att lista alla moduler och system som er mjukvara exponerar mot omvärlden. Därefter vilka kommunikationsvägar samt protokol som exponeras på varje modul eller interface samt att prioritera dem utifrån hur enkelt eller troligt den punkten är att attackera.
Nämnas kan också säkerhetscertificering för kreditkortshantering: PCI DSS , ref [6]
Även inom testning inom sjukvårdsapparatur, marin och flyg finns metoder för systemsäkerhetsklassificering.
Säkerhetscertificeringar för utvecklare och testare
Säkerhetscertificeringar och examinering för testare och ingenjörer; t.ex. CSSLP ,CISSP – genom www.isc2.org, ref [7] .
Även ISTBQ håller på att ta fram en certifiering för säkerhetstestare, ref [8]
En certificering som sägs vara väldigt praktiskt inriktad är den från Offensive Security, CTP , ref [13].
Definiera testområdet och informera alla intressenter
Innan man ens börjar fundera på att säkerhetstesta är det som vanligt bra att man informerar uppdragsgivaren, testchefen, utvecklingschefen osv. vad man gör. Fråga vilka områden(moduler) som kan tänkas vara viktigast att börja med, och om man har mandat att testa dem. Stör man produktionsmiljöer kommer man garanterat vara osams med sin organisation.
Jag rekommenderar även att man går åtminstone en ordentlig kurs, t.ex. via ref[14], innan man startar testningen så man lär sig om vanligt förekommande koncept, tillvägagångssätt och verktyg.
Dessutom är det rådigt att läsa på om mjukvaran man ska testa. För ju mer man känner till sin egen mjukvara eller system (t.ex. portar, moduler, kommunikationsprotokol m.m.) , desto bättre blir säkerhetstesterna. Testar man egen utvecklad programvara kan det ta en icke försumbar tid att konfigurera och sätta upp en miljö som möjliggör testning.
Notera att man inte ansluta till system eller datorer utan ägarens medgivande eller delge känslig information som man kommit över under testerna. I många delar av världen kan man åtalas för det.
Det finns ett antal webbsidor som man kan testa att hacka på, t.ex.: ref [ 9]. Bra funkar också en virtuell miljö, tex. vmware, så kan man sätta upp ett isolerat nät. Oftast på kurser har man ett virtuellt nät med flera hostar i där man simulerar t.ex. en attacker, en vanlig arbetsstation och en domänövervakare / unix server.
Här är också en bra steg för steg, inlärnings-guide, för nya inom säkerhetstestning; ref [13].
Det vore ett tjänstefel att inte också nämna OWASP, ref [11], som är en bra källa att lära sig mer inom området.
Morot
Som testchef eller ansvarig för säkerhetstester har du en mycket större chans att behålla jobbet om du bevisligen lagt ner stor (dokumenterad) möda att säkerhetställa att ingen olovligen kan ta sig in i ert system.
Lycka till med din säkerhetstestning!
Referenser:
[0] Ladda ner NMAP från och testa med denna sträng: nmap -sV –script=ssl-heartbleed 127.0.0.1
[1] http://heartbleed.com, http://computersweden.idg.se/2.2683/1.555928/heartbleed—det-har-behover-du-veta
[2] http://www.zdnet.com/targets-data-breach-it-gets-worse-7000025024/
[2b] http://www.cnet.com/news/security-firm-trustwave-sued-in-connection-with-target-breach-report
[3] SecTools.Org: Top 125 Network Security Tools; http://sectools.org/
[4] Exploit-DB , http://www.exploit-db.com/
[5] Microsoft SDL, http://msdn.microsoft.com/en-us/library/cc307891.aspx
[6] PCI DSS https://www.pcisecuritystandards.org/documents/information_supplement_11.3.pdf
[7] www.isc2.org
[8] ISTQB Security Testing Certification, http://www.istqb.org/certification-path-root/expert-level/security-testing.html
[9] Web Application Exploits and Defenses http://google-gruyere.appspot.com/
[10] Security testing defined http://en.wikipedia.org/wiki/Security_testing#Security_Testing_Taxonomy
[11] https://www.owasp.org
[12] Risk-Based and Functional Security Testing @ Homeland security https://buildsecurityin.us-cert.gov/articles/best-practices/security-testing/risk-based-and-functional-security-testing
[13] Offensive Security Certification
http://www.offensive-security.com/information-security-training/cracking-the-perimeter/
[14] Ett svensk företag som är bra på säkerhetstestning; www.truesec.se
[15] https://blogs.atlassian.com/2012/01/13-steps-to-learn-perfect-security-testing-in-your-org/
[16] Svenska hackare : en berättelse från nätets skuggsida av Daniel Goldberg & Linus Larsson ISBN: 9789113030449
[17] The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws, Dafydd Stuttard, ISBN 978-1118026472
[18] http://en.wikipedia.org/wiki/Zero-day_attack
[19] http://en.wikipedia.org/wiki/Fault_injection
[20] http://www.dn.se/ekonomi/globalt-hackernat-sprangt-97-greps/
Thomas, jag håller med om att inget system är helt säkert. Inte i förhållande till dagens hotbild och ännu mindre i förhållande till morgondagens. Däremot kanske jag inte drar riktigt samma slutsatser. Vi behöver bli vassare på att bygga in säkerhet från början, att tänka tillit tidigt. Som jag ser det går vägen via gedigna krav, ett riskperspektiv och ett systematiskt testande från komponent till helhet – i en process som omfattar systemets hela livscykel. Att söka och eliminera tekniska sårbarheter är viktigt och testande modell “black-hat black-box” har sin plats men den testare som inte intresserar sig för om systemet kravmässigt eller funktionellt gör, eller inte gör, vad det ska är kanske inte den jag personligen skulle anlita i första hand.
@stromsjo
Jag blev glad att Thomas K skriver sin artikel och varm i hjärtat av kommentaren från @stromsjo. Kanske följande artikel kan vara ett inlägg i frågan:
http://www.konsultbolag1.se/tank-tillit-tidigt-%E2%80%93-effektivisera-din-it-sakerhet
/Anders F
Tack för era kommentarer. Denna artikel är skriven utifrån testarens vy och mindre från utvecklarens, produktchefens eller arkitektens synvinkel.
Jag håller absolut med er att redan vid design- och implementations-fasen ska man budgetera både tid och resurser för utveckla ett säkert system. Många potentiella säkerhetsdefekter kan förhindras redan där, innan mjukvaran ens nått testavdelningen eller testkonsulten. Det finns mängder av bra information, utbildningar samt böcker som beskriver hur man utvecklar säkra system och skriver säker kod.
Givetvis ska utvecklaren samt arkitekten vara insatt i sådan information, men det är även bra om testaren tar del av ovan information för att kunna testa på en mer tekniskt insatt (lägre) nivå s.k. “gray- / white-box-test” .
Testaren har normalt sett intresse av att mjukvaran både är validerad och verifierad. Men jag vågar påstå att medans en person säkerhetstestar ska denne inte också behöva axla ytterliggare en roll som t.ex. funktions-, prestanda-, integrations-, system-, UX-testare samtidigt (om vi inte pratar om ett “garageföretag” med väldigt få anställda).
De är olika roller som kräver olika kompetens och “mindset”. Kanske inte så olika kompetens som en testare och en utvecklare, men likväl olika. Vill man genomföra en optimal säkerhetstestning, ska man sålunda inte använda en funktionstestare, även om denne kan ha nog så bra på domänkunskap om produktområdet, produkten och kunskap av funktionella tester.
Som testchef skulle det inte vara mitt först val, att vid säkerhetstestning anlita en person som säger sig bemästra alla de testområden som nämndes ovan och som kan testa detta samtidigt, eller ens efter varandra, med bra resultat.
/Thomas Klevmar
Jag tror det är olyckligt att säkerhet ofta sköts av särskilda människor med en särskild sorts hatt och som pratar sitt särskilda språk. För mig är säkerhet en form av kvalitet och kvalitet byggs aldrig av någon annan. Det är vi själva som bygger kvalitet i vårt system. Håller med om att det blir en utmaning att bemästra den här kunskapsdomänen *också* – och visst kommer det alltid att behövas expertstöd i bakgrunden – men jag tror att utvecklare och testare både kan och vill ta ett större ansvar när de får chansen.
Jättebra att du skrev artikeln, Thomas. Det här området behöver diskuteras mer och ditt inspel är nyttigt.
Intressant läsning!
En intressant artikel!
Många områden och aktiviteter tas upp, men tyvärr blandas de ihopa och det hoppas snabbt mellan dem. Den stackars testchefen kommer alltså bli sparkad om han inte ser till att testa för alla kända och okända sårbarheter i den produkt han ansvarar för? Detta ska han uppnå genom att anställa en person som inte ska bry sig om produktens funktionalitet eller kravmassa…
Naturligtvis drog jag min slutledning av artikeln till en extrem nivå här ovan, men jag ska lägga ut texten för att förklara min ståndpunkt.
Jag börjar med testledaren. Hans roll är att säkerställa en acceptabel nivå av kvalite i produkten, i det här fallet gällande säkerhet. Testchefens ansvar ligger i att hitta en nivå av säkerhetsengagemang som är anpassad efter hur mycket tid och pengar projektet är berett att investera. Har man snäva manöverytor så kanske man bara har möjlighet att investera i utbildning av utvecklare och testare. Lite mer kanske kan ge möjlighet för en dedikerad person som driver frågan. Ytterligare utrymme ger tillfälle för inhyrning av extern part för att stämma av säkerhetsläget för produkten.
Vad testchefen måste inse är att det inte går att få en 100% vattentät produkt säkerhetsmässigt. Precis som noterat i artikeln så finns 0day sårbarheter. Dessa går normalt inte att skydda sig proaktivt mot pga deras rena natur. Allt ligger i testchefens konfidens i de aktiviteter som går att driva inom det utrymme som ges av projektet. Den aktivitet som inte tas upp av artikeln är hur testchefen ska agera när (inte om) en säkerhets sårbarhet upptäcks i en släppt version av produkten.
Testaren, säkerhetstestaren, hackaren… kärt barn har många namn. Enligt artikeln har han ett tufft jobb framför sig. Han ska inte bry sig om funktioner och UI, men samtidigt vara insatt i och driva utvecklingsmodellen, testa kända och okända fel, ta certifikat som kostar multum (och har krav på erfarenhet och socialt nätverk som innefattar andra certifierade). Han ska tydligen även vara välbevandrad i PCI processen, som behandlar utvärdering och rapportering i företag som hanterar pengatransaktioner. Nu är samtliga aktiviteter ovan positiva aktiviteter att ha implementerade i sitt företag, när de är behövda. De bör dock vara utspridda dock på fler personer än bara säkerhetstestaren.
Som pricken över i’et så ska även säkerhetstestaren tydligen utföra sina tester på produktions-miljön. Jag kan tänka mig att drift-tekniker som läste den meningen i artikeln satte kaffet i halsen =)
Testaren bör vara väl införstådd i hur systemet han ska testa fungerar. Detta är speciellt viktigt för en säkerhets-testare, då sårbarheter kan finnas på så många olika ställen. Allt från ui (UI redressing attacker), nätverk (MITM attacker), krypterings-implementationer (Certifikat TLS/SSL chain of trust / hashimplementationer), databaser (lösenords sparandet/känslig data), OS (minnesdumpning/stack-exekvering/filåtkomst) kan vara påverkat. Men samtidigt bör han ha, precis som artikeln föreskriver, ett fokus på sitt område och sina verktyg.
Avslutningsvis; vart tog moroten vägen som blev utlovad i ingressen? Den avrundas mycket snabbt med att testchefen bör ha dokumenterad möda på säkerhets-testningen. Den uppmaningen leder tankarna till företag som envisas med listor av checkboxar, som ifylles utefter resultat från automatiska testsystem…
Att fånga 0days blir knepigt, det är sant.
Ett sätt att motverka dem är att eftersträva enkelhet. Ju mer komplexa lösningar vi bygger, desto större attackyta.
Ett annat sätt är att vara noggrannare med vems kod vi använder. Jag tror inte att sårbarheter är slumpmässigt utspridda i den kod som produceras. Snarare är det så att vissa producenter av mjukvara har en högre mognadsnivå och presterar kod med högre kvalitet till vilken vi kan känna större tillit. Även deras mjukvara kommer att vara befolkad av sårbarheter men inte lika många, tänker jag.