In dit artikel volgt een uitleg over een fenomeen gerelateerd aan onze dienstverlening ter voorkoming van
phishing, spam en
malwareverspreiding, namelijk de Cross Site Request Forgery (
CSRF).
Hoewel e-mail in de afgelopen jaren door diverse
technieken en filters een stuk veiliger is geworden gaan kwaadwillenden onverminderd door met het proberen mensen te misleiden en systemen te misbruiken.
In ons awareness platform
StackAware besteden we dan ook ruim aandacht aan het herkennen van dit soort berichten en aan veilig e-mailgedrag in zijn totaliteit. Een techniek die wel eens gebruikt wordt door kwaadwillenden in e-mailberichten (en elders) is het gebruik van een kwetsbaarheid genaamd CSRF, de Cross Site Request Forgery.
Het onderstaande relaas is een technisch verhaal, maar middels een gesimplificeerd voorbeeld wordt geprobeerd duidelijk te maken wat er gebeurt tijdens een CSRF-aanval.
Kort gezegd wordt er bij een CSRF-aanval misbruik gemaakt van de vertrouwensrelatie tussen enerzijds de webapplicatie/website en anderzijds de legitieme gebruiker.
Een dergelijke aanval geschiedt door de legitieme gebruiker bewust (bijvoorbeeld door deze op een valse link te laten klikken) of onbewust (bijvoorbeeld door een kwetsbaarheid die zonder medeweten van de gebruiker code uitvoert) een actie te laten uitvoeren, op een vertrouwende website, die de gebruiker niet zelf gewenst heeft.
Een voorbeeld om dit iets wat droge stukje tekst wat te verduidelijken:
Een succesvol ondernemer genaamd Geert wil graag een betaling uitvoeren via zijn bank aan de belastingdienst die ook graag onderdeel is van zijn succes.
Geert logt in met zijn veilige wachtwoord en na zijn verificatie met MFA voert de bank nog wat controles uit, constateert dat Geert daadwerkelijk Geert is, en verleent toegang. Er is nu vertrouwen ontstaan tussen de webapplicatie van de bank en de browser van Geert.
Stel nu dat Geert een bedrag van € 1.000 overmaakt aan de belastingdienst. Onderhuids zou dat verzoek aan de bank er als volgt uit kunnen zien:
https://banknaam.url/transactie?type=OVERMAKEN&ontvanger=BELASTINGDIENST&bedrag=1000
Als de link aangepast zou worden met een ander bedrag en een andere ontvanger dan zou het resulteren in een heel andere transactie:
https://banknaam.url/transactie?type=OVERMAKEN&ontvanger=DEBOEF&bedrag=1000000
Het enige wat er nu moet gebeuren is dat Geert tijdens zijn sessie bij de bank op een link klikt die een dergelijke transactie via zijn browser verstuurd of dat deze automatisch wordt verstuurd middels een kwetsbaarheid in bepaalde applicaties op de computer van Geert.
Nu is het bovenstaande voorbeeld niet heel realistisch in die zin dat het doorvoeren van een dergelijke transactie niet via een simpele GET request zal plaatsvinden en er aannemelijk meer controles zouden plaatsvinden bij dergelijke bedragen, maar het geeft hopelijk een idee van wat er bedoeld wordt met een CSRF kwetsbaarheid.
Goed om nog op te merken is ook dat als het op websites/webapplicaties met kwetsbaarheden aankomt banken over het algemeen vele malen beter beveiligd en getest zijn dan de gemiddelde website. Niet het meest makkelijke doelwit dus.
Een andere moeilijkheid in deze zou zijn dat de aanval plaats moet vinden tijdens een sessie met de bank, hetgeen ook zorgt voor uitdagingen voor het lanceren van de aanval. Sommige websites zijn echter wat makkelijker te manipuleren omdat eenmaal ingelogd de browser van de gebruiker voor lange tijd vertrouwd blijft en er dus geen extra authenticatie hoeft plaats te vinden.
Wat bij een CSRF-aanval ook speelt is dat de kwaadwillende in principe alleen handelingen kan uitvoeren waar de legitieme gebruiker toe gemachtigd is. De schade blijft dan ook beperkt tot de gebruiker in kwestie. Indien de legitieme gebruikers beheerdersrechten heeft of de rechten van andere gebruikers kan aanpassen dan wordt het een ander verhaal.
Het is ook niet ondenkbaar dat een kwaadwillende die beperkt toegang heeft tot een systeem nu meer middelen heeft om tot een
escalatie van bevoegdheden te komen dan een kwaadwillende die in zijn geheel geen toegang had tot het systeem.
Dit principe zien we terug tijdens onze veiligheidsonderzoeken, wanneer we een webapplicatie zonder account testen zijn er vaak minder kwetsbaarheden te vinden dan wanneer we inloggen met een regulier account. Het is dus verstandig om vanuit meerdere scenario’s te testen.
Al met al een heel verhaal en slechts één van de gevaren die mogelijk spelen tijdens een phishing-aanval. Voor meer informatie over phishing, security
awareness training en kwetsbaarheden scans kunt u altijd
contact met ons opnemen.
