Penetrationstestning (ofta kallat pen-test) utförs av en professionell säkerhetsexpert som försöker attackera ett datorsystem. Experten letar efter säkerhetsbrister som en riktig hackare skulle kunna utnyttja för att få tillgång till funktioner och data som är otillgängliga för användaren.
Penetrationstestning utförs vanligtvis som en black box-attack, där säkerhetsexperten inte får tillgång till koden eller detaljerna om servern. Ofta får hen några användaruppgifter för att kontrollera om hen kan gå längre än vad dessa användare har behörighet att göra. En alternativ strategi är dock white box-penetrationstestning, där hackaren kontrollerar konfigurationen och källkoden. Den senare används vanligtvis för militära eller mycket säkerhetsklassade installationer.
Målen med alla penetrationstester är:
- Fastställa genomförbarheten av alla angreppssätt för attacker som ett sätt att få obehörig eller utökad åtkomst till funktioner eller data
- Identifiera högrisk-sårbarheter från en kombination av lågrisk-sårbarheter som utnyttjas i en viss sekvens
- Identifiera sårbarheter som kan vara svåra eller omöjliga att upptäcka med automatiserad programvara för skanning av sårbarheter i nätverk eller applikationer.
- Bedöm omfattningen av potentiella affärs- och driftspåverkan av framgångsrika attacker.
- Testa nätverksförsvararnas förmåga att upptäcka och reagera på attacker
- Tillhandahålla bevis som stöd för ökade investeringar i säkerhetspersonal och teknik
Attackvektorer / OWASP 10
OWASP är en ideell säkerhetsorganisation som regelbundet identifierar de vanligaste attackvektorerna och beskriver penetrationstestmetoder för att minska dessa sårbarheter. De tio vanligaste attackvektorerna kallas OWASP-10, och den senaste listan fastställdes 2013
| Nr | Sårbarhet | Beskrivning/tester som skall utföras |
| 1 | Injection Injektion | Injektionsfel, såsom SQL-, OS- och LDAP-injektion, uppstår när opålitliga data skickas till en tolk som en del av ett kommando eller en fråga. Angriparens fientliga data kan lura tolken att utföra oavsiktliga kommandon eller få åtkomst till data utan behörighet. Testa för:
|
| 2 | Bruten autentisering och sessionshantering | Bruten autentisering och sessionshantering Applikationsfunktioner relaterade till autentisering och sessionshantering är ofta inte korrekt implementerade, vilket gör det möjligt för angripare att kompromettera lösenord, nycklar eller sessionstoken eller att utnyttja andra implementeringsfel för att ta över andra användares identiteter. Testa för:
|
| 3 | Cross-site scripting | XSS-fel uppstår när en applikation tar emot opålitliga data och skickar dem till en webbläsare utan korrekt validering eller eskapning. XSS gör det möjligt för angripare att köra skript i offrets webbläsare, vilket kan kapa användarsessioner, förstöra webbplatser eller omdirigera användaren till skadliga webbplatser. Testa för:
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface websites, or redirect the user to malicious sites. Test for:
|
| 4 | Osäker direkt objektreferens | En direkt objektreferens uppstår när en utvecklare exponerar en referens till ett internt implementeringsobjekt, till exempel en fil, katalog eller databasnyckel. Advokater kan manipulera dessa referenser för att få åtkomst till obehöriga data utan åtkomstkontroll eller annat skydd. Testa för:
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Attorneys can manipulate these references to access unauthorised data without an access control check or other protection. Test for:
|
| 5 | Felaktig säkerhetskonfiguration | God säkerhet kräver att en säker konfiguration definieras och implementeras för applikationen, ramverk, applikationsserver, webbserver, databasserver och plattform. Säkerhetsinställningar bör definieras, implementeras och underhållas, eftersom standardinställningarna ofta är osäkra. Dessutom bör programvaran hållas uppdaterad. Testa för:
|
| 6 | Exponering av känslig data | Många webbapplikationer skyddar inte känslig data, såsom kreditkort, skatte-ID och autentiseringsuppgifter, på ett adekvat sätt. Angripare kan stjäla eller ändra sådana svagt skyddade uppgifter för att begå kreditkortsbedrägerier, identitetsstöld eller andra brott. Känsliga uppgifter förtjänar extra skydd, såsom kryptering vid lagring eller överföring, och särskilda försiktighetsåtgärder vid utbyte med webbläsaren. Testa för:
Many web applications do not adequately protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection, such as encryption at rest or in transit, and special precautions when exchanged with the browser. Test for:
|
| 7 | Saknad åtkomstkontroll på funktionsnivå
| De flesta webbapplikationer verifierar åtkomsträttigheter på funktionsnivå innan funktionen visas i användargränssnittet. Applikationer måste dock utföra samma åtkomstkontroller på servern när varje funktion används. Angripare kan förfalska förfrågningar om åtkomst till funktioner utan behörighet om förfrågningarna inte verifieras. Testa följande:
Most web applications verify function-level access rights before making that functionality visible in the UI. However, applications must perform the same access control checks on the server when each function is accessed. Attackers can forge requests to access functionality without proper authorisation if requests are not verified. Test for:
|
| 8 | Cross-site request forgery | En CSRF-attack tvingar en inloggad offers webbläsare att skicka en förfalskad HTTP-begäran till en sårbar webbapplikation, inklusive offrets sessionscookie och all annan automatiskt inkluderad autentiseringsinformation. Detta gör det möjligt för angriparen att tvinga offrets webbläsare att generera begäranden som den sårbara applikationen tror är legitima begäranden från offret. Testa för:
|
| 9 | Använda komponenter med kända sårbarheter | Komponenter, såsom bibliotek, ramverk och andra programvarumoduler, körs nästan alltid med fullständiga behörigheter. En sådan attack kan underlätta allvarlig dataförlust eller serverövertagande om en sårbar komponent utnyttjas. Applikationer som använder komponenter med kända sårbarheter kan undergräva applikationens försvar och möjliggöra en rad möjliga attacker och konsekvenser. (Heartbleed och Shellshock är exempel). Testa för:
|
| 10 | Omdirigeringar och vidarebefordringar som inte är validerade | Webbapplikationer omdirigerar och vidarebefordrar ofta användare till andra sidor och webbplatser och använder opålitliga data för att bestämma målsidorna. Utan korrekt validering kan angripare omdirigera offren till phishing- eller malware-webbplatser eller använda vidarebefordringar för att få åtkomst till obehöriga sidor. Testa för:
|
Vår strategi
På Gislen Software använder vi olika åtgärder för att minska risken för hackning i mjukvaruutvecklingen. Vissa filter eller specifika metoder kan helt eliminera vissa risker. Genom att hålla all mjukvara uppdaterad kan andra risker minskas. De betydande risker som återstår uppstår genom användning av sårbara komponenter från tredje part. Vanliga, välkända komponenter från tredje part uppdateras ofta, men mindre vanliga komponenter kanske inte uppdateras lika ofta.
Indirekta sårbarheter
Ibland kan sårbarheter vara indirekta. Det vill säga att samma webbserver, domän eller företag kör någon annan osäker applikation. Även om det är omöjligt att hacka applikationen direkt från utsidan, kan det vara möjligt att hacka en annan applikation och få tillgång till nätverket där filerna för den aktuella applikationen lagras. Ett exempel på detta är en hackerhistoria om en person som lyckades hacka Facebook (han gjorde detta för att få en belöning från Facebook, så detta är lagligt och etiskt hacking) –
Verifiera och förstärka applikationer före penetrationstestning
Kunder har ofta bett oss att verifiera applikationer före penetrationstestning. Vi har huvudsakligen gjort detta med hjälp av vitlådsverifiering mot listan ovan. Fördelen med att förbereda en [black-box] penetrationstest med en vitlådestest är att vitlådestestaren har en fördel genom att kunna kontrollera koden eller serverkonfigurationen för sårbarheter. [Black-box]-penetrationstestaren har inte den fördelen, och det har inte heller en riktig hackare. Genom att ha denna fördel kan vi ofta minska risken till en nivå där risken är låg. Penetrationstestet verifierar endast att vi inte har missat något.
Eftersom vi dock ofta endast har tillgång till en testmiljö finns det alltid en risk att den faktiska servern är sårbar för installation eller konfiguration. Om vi inte får full tillgång till den live-servern kan det vara svårt att säkra live-miljön fullt ut.
Vissa typer av risker är inte applikationsbaserade. Annan infrastruktur, såsom brandväggar, operativsystem, webbservrar etc., utvärderas också under penetrationstestningen. Om vi ombeds att förstärka en applikation för ett penetrationstest kan det därför inte vara tillräckligt för att säkerställa att penetrationstestningen inte hittar några sårbarheter, eftersom infrastrukturen i sig kan vara sårbar. Detta kan inkludera risker för DDOS-attacker.
Applikationsbrandväggar
Att lägga till en applikationsbrandvägg (särskilt för injektioner) kan också minska vissa risker, men många av OWASP 10-riskerna kan också minskas.
Slutsats
Detta dokument beskriver den typiska processen för penetrationstestning, identifierar viktiga risker och förklarar de verktyg som finns tillgängliga. Dessutom förklarar det hur Gislen Software utvecklar och hjälper kunder att säkra sina programvaruapplikationer, och därmed förbereder dem för framgångsrik penetrationstestning.
Referenser
Tabellen OWASP 10 ovan är en sammanställning av informationen på följande sidor med några ytterligare kommentarer från oss:
Vilka verktyg används för penetrationstestning?
Tester utförs ofta med hjälp av specifika säkerhetsverktyg; Wikipedia listar flera av dessa.
Utöver white-box-testning inför penetrationstestning har vi ibland använt verktyg som:
- NMAP (gratis), som används för att hitta öppna portar
- Nessus
- Metasploit
- Wireshark
- OpenSSL
- Cain & Abel – URL:en för verktyget är för närvarande länkad som osäker, och vissa virusskannrar blockerar den som osäker. Verktyget i sig är dock användbart.
- THC Hydra
- w3af
Kommersiella verktyg/tjänster:
- Acunetix (kommersiellt) – Kostnaden för att använda Acunetix är 810 dollar per år.
- Pure Hacking
- Torrid Networks
- SecPoint
- Veracode
Hur genomförs penetrationstestning?
Det finns gott om material om hur en penetrationstest kan genomföras:
- Genomföra penetrationstestorganisation
- Automatiserad penetrationstest
- Guide för penetrationstest
- Vägledning för penetrationstest mars 2015
- 5 tips för ett framgångsrikt penetrationstestprogram
Applikationsbrandväggar som kan användas för att minska riskerna:
Även om applikationer kan och bör förstärkas före penetrationstestning, kan applikationsbrandväggar också användas för att minska vissa risker. OWASP-webbplatsen listar flera sådana applikationsbrandväggar.
Det finns en lång lista över applikationsbrandväggar eller apparater. Här är några som finns på Wikipedia
Nedan finns en lista över olika applikationsbrandväggar och apparater som körs som plugins, boxar och lastbalanserare eller till och med i molnet (som proxyservrar)
OWASP:s webbplats innehåller en konfigurationsguide för applikationsbrandväggar:
- AQTRONIX WebKnight (öppen källkod),
- Qbik WinGate (kommersiell),
- Navilin
- Untangle (Kommersiell)
- Check Point (Kommersiell)
- Smoothwall (Öppen källkod)
- Barracuda Networks Web Application Firewall/Load Balancer ADC (Kommersiell)
- A10 Networks Web Application Firewall (Kommersiell)
- Citrix Netscaler (Kommersiell)
- F5 ASM, Fortinet FortiWeb (Kommersiell)
- WatchGuard (kommersiell)
- Imperva (kommersiell)
- KEMP Technologies (kommersiell)
- Penta Security (kommersiell)
- Cloudbric (kommersiell, men debiteras endast baserat på trafik och endast över 4 GB/månad)
- PIOLINK (kommersiell)
- ProxyServerModSecurity-paket (plugin för PFSense öppen källkodsbrandvägg/Linux-baserad)
Behöver du hjälp med att utveckla säker programvara eller förbereda en penetrationstest?
Behöver du hjälp med säkerhetstestning, förberedelser för penetrationstestning eller utveckling av säker programvara? Tveka inte att kontakta oss på Gislen Software. Vi har experter med nödvändig kompetens och erfarenhet. Oavsett om du står inför tekniska utmaningar eller behöver strategisk vägledning är vi här för att hjälpa dig att nå dina mål. Kontakta oss idag för att diskutera hur vi kan stödja dina behov.