Imorgon blir det poddavsnitt, men idag tänkte jag berätta om hur man kan jaga spammare/phishers via nätet. Allt är på riktigt och allt händer nu!

Läs här:
https://erik.zalitis.se/it-security/the-anatomy-of-an-attack/

Inlägget Hur en attack kan se ut… dök först upp på IT-säkerhetspodden.

Några tankar
Avsnittet är i någon form en fristående fortsättning på våra avsnitt om Etisk hackning och Cyber Kill chain. En del av ämnena togs upp redan där, men i detta avsnitt fördjupar vi diskussionen om svårigheterna man möte när man testar system.

Denna gång försöker vi också fundera på vad som bör ingå i en bra rapport:

• Ska ha en sammanfattning (Executive summary) med övergripande risk.
• Lista alla mål som man kommit överens om.
• Lista alla sätt det gick att ta sig in.
• Ranka sårbarheter enligt något system som är enkelt att överblicka.
• Föreslå förbättringar och lösningar.
• Rapporten anpassas i omfång och detaljnivå efter uppdragets storlek och karaktär.

Allmänt om pentester, SDLC och när man gör tester

Pentester sker normalt i samband utrullningen av ett nytt system eller i samband med utrullningen av en ny version av ett system.

Testerna simulerar attacker och dokumenterar allting som upptäckts “på vägen”.

Pentester utföres alltid av en oberoende granskare.

Vår lista på de nio vanligaste felen som görs vid pentester:

1 – Att inte förstå avgränsningarna I uppdraget
2 – Att inte prioritera riskerna
3 – Att använda fel verktyg
4 – Att göra en dålig rapport
5 – Att bara ”kryssa för boxar” istället för att ge kreativiteten en chans.
6 – Att skada produktionssytem
7 – Att använda gammal teknik och ha gammal kunskap
8 – Att inte göra återkommande tester
9 – Att kunden inte genomför förbättringarna som föreslås.

Inlägget Show notes för #72 – Nio fel dök först upp på IT-säkerhetspodden.

Session fixation

När man bygger en webbapplikation är det ganska vanligt att man använder sessions-id. Dessa är till för att man ska kunna hålla en användare inloggad. Det är en mycket känslig del av det hela rent säkerhetsmässigt. Den korrekta metoden är att logga in en användare och sedan sätta ett sessions-id därefter. Detta ska leva tills användaren loggar ur eller tills en viss tid uppnåtts. När jag utför pentester, stöter jag ofta på webbapplikationer som sätter sessions-id INNAN användaren loggar in och sedan använder samma sessions-id EFTER att du loggat in. I ett sådant scenario går det ofta att ta över användarens hela session med ett mail och lite social engineering.

Man skriver ett mail med en länk till applikationen som man ska hacka. Detta mail anger ett sessions-id som man själv hittat på. Användaren klickar på länken och loggar in som vanligt. Nu vet du denna användares sessions-id efter du själv bestämt det. Då kan du på din egen webbläsare ange samma sessions-id och gå in som användaren utan att behöva logga in.

cookies utan secure-flaggan

Ofta realiseras sessions-ids med cookies. Om man inte sätter flaggan ”secure” på dessa, kan man övertala applikationen att skicka dem över en klartextförbindelse. Genom att använda ett verktyg som sslstrip, kan en attackerare på det lokala nätverket få tag i giltiga sessionscookies.

sessions-id i get-metoden

Om man tillåter sessions-ids i address, som tillexempel www.sårbarsite.se/app?SESSION=235234532556768, kan en användare av misstag råka ge bort sin session via mail. Man bör också undvika att ta in variabeln via både get och post.

Sessionen tar aldrig slut

En session måste ha en klocka som räknar ner och avslutar sessionen när användaren varit inaktiv en viss tid. En del webbapplikationer byter även sessions-id när sessionen varit igång en viss tid. Men många webbapplikationer låter sessionerna lever i all evighet, eller har extrema värden som gör att en session kan vara inaktiv i veckor och fortfarande vara aktiv.
cookie utan httponly-flaggan

Mindre allvarligt, men ändå. En sessionscookie bör vara satt httponly, för att hindra att man på klientsidan kan manipulera den med javaskript-kod.

Ingen webcookie

En webcookie är ett värde som läggs till jämte session-id. Den måste finnas i anropen för att användaren ska kunna göra ändringar i webbapplikationen. En session är nämligen giltig i alla flikar i en webbläsare (Om man inte köra i inprivate mode). Detta gör att elak kod som körs i en annan flik kan göra ändringar i den webbapplikation du använder. Ofta saknas denna webbcookie, vilket gör webbapplikationen sårbar för en cross site request forgery-attack. Med en webcookie kan du bara göra ändringar i webbapplikation från den fliken du loggade in i webbapplikationen med. Detta kan skydda dig om du är inne och ändrar inställningarna i en routers webbinterface medan du surfar i en annan flik (Inte att rekommendera, dock!)

Ingen HSTS (HTTP Strict Transport Security)

HSTS är en HTTP Header som säger åt en webbläsare att ALLTID använda HTTPS mot en sida. Denna enkla mekanism gör verktyg som sslstrip verkningslösa. Tillsammans med secure-flaggan på sessionscookie, ökar de säkerheten enormt.
Ingen HTTPS

Detta borde inte vara ett problem idag, men det är det. Siter som hanterar inloggningar men inte har HTTPS finns fortfarande. Detta är ganska självklart ett problem. Men det finns fortfarande de som lever i det förgågna.
Så för att sammanfatta: det finns ett antal metoder man kan använda för att se till att användaren kan lita på att deras interaktioner mot din webbsida är säker. Använd dessa!

Inlägget Misstag med sessionshanteringen i webbapplikationer dök först upp på IT-säkerhetspodden.