Zoombombing’ eller ‘Zoom raiding’, som er når ubudne deltakere bryter inn og forstyrrer videokonferansemøtet ditt på Zoom eller andre videokonferanseplattformer. ‘Zoombombing’ har forårsaket en rekke problemer blant annet for skoler og lærere, med uønskede deltakere som legger ut grovt innhold for å avbryte læringsøktene. ‘Zoombombing’ er et eksempel på Broken Authentication. I denne artikkelen ser vi på hva Broken Authentication er, hvordan det fungerer og hvordan forhindre slike angrep. Open Web Application Security Project (OWASP) lister det opp på nummer to i sin «Topp 10» -liste over de største sikkerhetsrisikoene for webapplikasjoner.
Hva er Broken Authentication?
Broken authentication er en referanse til svakheter på to områder: session management og credential management.
Du har et nettsted som krever at du logger inn med et brukernavn og passord. Når du logger inn, sendes legitimasjonen til databasen. Hvis brukernavnet og passordet samsvarer med det som er i databasen, vil du bli autentisert for en ‘session’. Det betyr at nettstedet vil tildele og sende deg en unik session-ID som fungerer som en nøkkel til brukerens identitet på serveren. Din enhet bruker session-ID’en som en nøkkel til identiteten din for resten av påloggingssession. All denne informasjonen må sendes frem og tilbake mellom enheten din og serveren. Disse session-ID’ene kommer ofte i form av ‘cookies’ og URL-parametere.
En ‘session’ er en spesifisert tid som en autentisert bruker vil ha tilgang til bestemte sider og aktiviteter i applikasjonen. En ‘session’ kan omfatte personopplysninger, økonomiske data og tilgang til beskyttet informasjon eller forretningshemmeligheter.
Når som helst i godkjenningsprosessen kan en ondsinnet bruker få uautorisert tilgang til en session. Vi gjennomgår noen eksempler på ulike session-angrep nedenfor.
3. Session Managementsangrep
3.1. Session ID URL -omskriving
Slik skjer Zoombombing: Session-IDen vises på URL-en til Zoom. Eksempel: https://zoom.us/j/55555523222.
Alle som kan se den nettadressen (for eksempel via en usikret Wi-Fi-tilkobling) kan fortsette med den session’en. Eller noen som bare leker med tall, kan lande på riktig session-ID og få tilgang til en session.
3.2. Session Hijacking
Et enkelt eksempel på session hijacking er en bruker som glemmer å logge av et program og deretter går bort fra PC’en. En hacker kan deretter fortsette med den session.
3.3. Session Fixation
En mønsterpraksis som vanligvis blir glemt er å rotere session-ID etter at en bruker logger på i stedet for å gi en bruker samme ID før og etter autentisering. Nettapplikasjoner som ikke klarer å gjøre dette, er sårbare for et session fixation angrep, som er en variant av session hijacking.
Hovedpoenget bak et session fixation angrep er at angriperen forhåndsbestemmer session-ID’en som ‘victim’ skal bruke. Angriperen kan da sende ‘victim’ en lenke som inneholder den forhåndsbestemte session-ID-en. Koblingen vil peke på en ressurs som krever at ‘victim’ logger på.
Om webapplikasjonen holder ved autentiseringstilstanden til ‘victim’ i session, kan angriperen bruke den forhåndsbestemte session-ID-en til å utgi seg for å være ‘victim’ etter at ‘victim’ logger på. Uansett om det er angriperen eller ‘victim’ som presenterer denne session-ID-en for serveren, vil serveren fastslå at session-ID-en tilsvarer en autentisert session og gi tilgang til beskyttede ressurser.
Utviklere kan forhindre angriperen i å følge ‘victim’ ved å få webapplikasjonen til å gi den legitime brukeren en ny session-ID etter innlogging. Når webapplikasjonen roterer session-ID-en, blir den forhåndsbestemte session-ID-en ubrukelig.
4. Angripere utnytter svake og kompromitterte ‘Credentials’
Hackere bruker forskjellige metoder for å stjele, gjette eller lure brukere til å avsløre passordene sine.
4.1. Credential Stuffing
Når angripere får tilgang til en database fylt med ukrypterte e-poster og passord, selger de ofte eller gir bort dataene, som deretter andre angripere kan bruke. Disse angriperne bruker deretter botnet for brute-force-angrep på forskjellige kontoer, som tester legitimasjon stjålet fra et nettsted.
Denne taktikken fungerer ofte fordi folk ofte bruker det samme passordet på tvers av applikasjoner. Det er nå milliarder av kompromitterte ‘credentials’ tilgjengelig for angripere. Brukerne vet ikke en gang at passordet de har brukt siden videregående nettopp ble en skjelettnøkkel for alle kontoene deres.
4.2. Passord Spraying
‘Password spraying’ er litt som credential stuffing, men i stedet for å bearbeide en database med stjålne passord, bruker den et sett med svake eller vanlige passord for å bryte inn på brukerens konto. I dag bruker millioner av kontoer passord som ‘123456’, sportsnavn, forbannelsesord og selve ordet ‘passord’.
Sjekk ut CNNs oversikt over mest brukte passord.
Password spraying er en type brute-force-angrep, men de glir ofte av automatiske lockouts som blokkerer IP-adresser etter for mange mislykkede påloggingsforsøk. Det gjøres ved å prøve det samme passordet, en bruker om gangen, i stedet for å prøve passord etter passord på hver enkelt bruker.
4.3. Phishing-angrep
Angripere bruker typisk phishing ved å sende brukerne en e-post som later til å være fra en pålitelig kilde og deretter lure brukere til å dele legitimasjon eller annen relatert informasjon. Det kan være et bredt forsøk som treffer alle i en organisasjon med samme falske e-post, eller det kan ta form av et «spear phishing»-angrep skreddersydd til et bestemt mål.
Spear phishing kan være spesielt nyttig for angripere. De kan bruke angrepsteknikken til å manipulere andres følelser basert på deres personlige informasjon.
Les mer: Hva er phishing?
5. Hvordan forhindre Broken Authentication?
OWASP nevner noen praksiser som man bør ha på plass for å forhindre slike angrep:
- Implementer multifaktorautentisering der det er mulig for å forhindre automatisert, credential stuffing, brute force og stjålet legitimasjonsgjenbruksangrep.
- Ikke send eller distribuer standard legitimasjon, spesielt for adminbrukere.
- Implementer svake passordkontroller, for eksempel ved å teste nye eller endrede passord mot en liste over de 10000 verste passordene.
- Juster passordlengden, kompleksiteten og rotasjonsretningslinjene med retningslinjene for NIST 800-63 B.
- Sørg for at registrering, legitimasjonsgjenoppretting og API pathways blir ‘hardened’ mot angrep av kontotall ved å bruke de samme meldingene for alle utfall.
- Begrens eller øk forsinket mislykkede påloggingsforsøk. Logg alle feil og varsle administratorer når credential stuffing, brute force eller andre angrep oppdages.
- Bruk en sikker, innebygd session manager på serversiden som genererer en ny tilfeldig session-ID med høy entropi etter pålogging. Sessions-ID’er skal ikke være i URL-en, de må lagres sikkert og ugyldiggjøres etter utlogging, inaktivitet og absolutt tidsavbrudd.
Guide: Slik utfører du sikkerhetstesting gjennom utviklingsløpet
Vil du lære mer om sikkerhet og sikkerhetstesting? I denne guiden gjennomgår sikkerhetsekspert Even Lysen hvordan du kan utføre sikkerhetstesting gjennom hele utviklingsløpet.