Säkerhetstesting

C:\Users\Thomas\Pictures\heartbleed.png

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.

http://abcnews.go.com/images/Blotter/HT_blackshades_jtm_140519.jpg

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/

About Thomas Klevmar

Thomas Klevmar Testexpert hos OpenText/StreamServe Thomas började arbeta med kvalitetsäkring samt test år 2000 och är specialiserad på prestandatestning och testverktyg. Han har arbetat som testare, testledare och testautomatiserare. Thomas har en bakgrund inom systemutveckling och testning hos bl.a. Microsoft i England och USA.