Forfalskning af serveranmodninger

Hackerangreb gennem forfalskninger på serversiden kan give uautoriseret adgang til webservere og desuden forårsage store skader og forstyrrelser. Det kan dog være relativt nemt at forsvare sig mod dem.

Definition

Angreb som Server-site Request Forgery (SSRF) består af en hacker, der narrer serveren til at foretage en uautoriseret anmodning. Selve navnet antyder, at en anmodning, der ellers skulle have været fremsat af serveren, er blevet forfalsket af hackeren.

SSRF-angreb er langt farligere end angreb på anmodninger på tværs af websteder, Cross-site Request Forgery (CSRF). Det skyldes, at CSRF-angreb på en måde involverer en hacker, der kaprer en brugers webbrowser og udfører uautoriserede handlinger på brugerens vegne. Under en aktiv CSRF igangsættes den ondsindede aktivitet fra klient-side og det er typisk den enkelte bruger eller deres aktiver, der målrettes. Selvfølgelig bliver CSRF angreb farlige, når den målrettede bruger har administratorrettigheder til web-applikationen og i et sådant tilfælde hele ansøgningen kunne blive kompromitteret.

SSRF-angreb målretter på den anden side selve webserveren uden nødvendig involvering eller interaktion fra sine brugere. Bare ved at gøre en ondsindet HTTP anmodning til serveren kan angriberen instruere back end til at udføre ondsindede handlinger.

Capital One’s store brud på datasikkerheden i 2019, der ramte omkring 106 millioner brugere i hele USA og Canada, stammede fra en SSRF-sårbarhedsudnyttelse. Nogle af de kompromitterede oplysninger omfattede kundenavne, adresser, kontaktoplysninger, fødselsdatoer, amerikanske CPR-numre (SSN’er), canadiske socialforsikringsnumre (SID’er), kreditscorer, betalingshistorik og selvrapporteret indkomst.

Sådan virker et SSRF-angreb

Når du foretager en anmodning til en webserver eller klikker på et hyperlink, får besøgende filer, der er beregnet til at blive set af verden public_html, dvs. alt hvad der findes i private mapper eller databaser, er typisk begrænset til brugere med større grupper. Filer og aktiver, der er direkte tilgængelige for det generelle publikum, der surfer på internettet, kan dog være tilgængelige for selve serveren. For eksempel kan du som besøgende nemt anmode om en offentlig URL som https://www.csoonline.com/uk/events men ikke de følsomme systemfiler på CSO’s server som /etc/shadow eller /etc/passwd. Webserveren kan sandsynligvis få adgang til disse filer.

Grundlæggende SSRF

I et sårbart miljø kan et webprogram, der kører på en server, også have adgang til disse filer. Grundlaget for ethvert SSRF-angreb er, at en offentligt tilgængelig (web)server kan narres af slutbrugeren til at give adgang til følsomme filer på den pågældende server eller adgang til andre, mere privilegerede systemer eller handlinger, der ellers er begrænset for slutbrugeren.

Tag f.eks. eksemplet med et sårbart e-handelswebsted på shop.example.com, der bruger flere servere. Brugere kan besøge shop.example.com for at gennemse produkterne, men produktdetaljerne sidder på en anden server, som brugerne ikke har direkte adgang til. Lad os antage, at serveren bag shop.example.com gør. Så når du klikker på et produkt, foretager butikkens hovedserver en sekundær anmodning. For at holde det enkelt, lad os antage, at det er en simpel GET-anmodning med webadressen synlig i din browsers adresselinje: shop.example.com/?url=shop-server-2.example.com/product555/

At gå til denne komplette URL giver dig detaljerne for produkt # 555. Hvis en hacker med rimelighed kan udlede, at de ikke har direkte adgang til http://shop-server-2.example.com/product555/ men shop.example.com gør, har de nu fundet en måde at bruge butikkens hovedserver som mellemvej. De kan potentielt udnytte denne webserver til at få adgang til begrænsede aktiver og filer.

Hvis shop.example.com har slap beskyttelse og er sårbar over for SSRF, kunne en hacker blot navigere til shop.example.com/?url=file:///etc/passwd, og meget sandsynligt returnerer den sårbare server nu indholdet af den følsomme /etc/passwd-fil, hvis der ikke er nogen beskyttelse på plads.  Afhængigt af angriberens mål kan den samme URL ændres til at omfatte localhost eller en intern IP-adresse sammen med et brugerdefineret portnummer, blandt andet.

Dette er blot et af de meget grundlæggende eksempler på mange muligheder SSRF-angreb har at tilbyde. Ovenstående scenario viser en “grundlæggende” eller ikke-blind SSRF, hvor en ondsindet anmodning fra angriberen resulterer i, at synlige data returneres af serveren. Sådanne angreb er fremragende til trussel aktører søger at udfiltrere data fra hemmelige filer og aktiver eller for at kontrollere, om specifikke systemporte er åbne og kørende tjenester.

Skjult SSRF

Skjulte SSRF-angreb returnerer på den anden side ikke nødvendigvis data, men fokuserer snarere på at udføre uautoriserede handlinger på serverens backend. Med skjulte SSRF-angreb ville angriberens fokus være for eksempel at ændre noget på serveren, ændre eller slette filer, ændre tilladelser og udføre en række uautoriserede handlinger i stedet for at gå efter dataudsivning.

Antag, at ovenstående URL-adresse er en udvidelse af ovenstående eksempel, så den er blevet ændret til shop.example.com/?url=http://eksempel.com/some-very-large-file.png hvor serveren bliver ved med at forsøge at hente en unormalt stor fil fra en ekstern server. En sådan anmodning kan medføre shop.eksempel.com’s webserver til at gå ned, hvilket resulterer i Denial of Service (DoS) for alle. Denne type SSRF-angreb er “skjult”, da fokus ikke er på at hente et synligt svar eller data, men snarere udføre en skadelig handling på serverens vegne.

Sådan afhjælpes SSRF-sårbarheder

Grundlaget for at afbøde SSRF fejl er fortsat for at forhindre brugerne i at påvirke input, der når dine interne applikationer. Dine interne programmer bør aldrig blindt stole på input eller antage, at det kommer fra en autentisk kilde.

For eksempel, i ovenstående eksempel på shop.example.com, hvorfor serveren selv acceptere file:/// webadresser? Det samme ville gå til ftp:// eller applikationsspecifikke URI-skemaer som slack: eller skype:. Systemet bør ideelt set begrænses til kun nogle få udvalgte protokoller, såsom HTTP og HTTPS, afhængigt af programmets behov. Der er bedre måder at udføre den samme handling, der er beskrevet i dette eksempel, så en URL-parameter til en intern server aldrig behøver at blive overført fra klientsiden.

Hvad med bare at overføre et produktnummer – shop.example.com/?product=555 – og lade shop.eksempel.com’s back end hente oplysninger om produkt 555 fra en anden server, hvis adresse er hard-kodet på back-end? Du ville gøre dette først efter rensning af den numeriske “produkt” parameter og sikre, at det er fri for ondsindede data.

For det andet, hvis logikken i programmet ikke kan ændres, og det absolut har brug for en URL, en allowlist og benægtelist tilgang er en løsning. Nogle programmer, der implementerer OAuth-baserede logon.

Allowlist eller whitelisting tilgange er sikrere, da programmet giver adgang til kun de tilladte objekter eller i denne sammenhæng, steder, hvilket gør processen mere selektiv og sikker. Den afviser tilgang, på den anden side, nægter adgang til kun visse steder efter eget valg, såsom local-host eller 127.0.0.1, men tillader alt andet. Denylist tilgange risikerer en klog hacker at finde løsninger, f.eks. via HTTP omdirigeringer, korrumperet webadresser, DNS eller mere realistisk serveradministratoren glemmer at medtage noget på den benægtende, der derefter får opmærksomhed fra angriberen.

Som med de fleste sårbarheder kan SSRF-fejl knuses ved at vedtage en Zero Trust tankegang – at desinficere input og minimere muligheden for, at input påvirkes af slutbrugeren. Derudover er vedtagelsen af princippet om mindst privilegium, hvor systemet kun giver adgang til API’er og interne systemer, der er absolut nødvendige for operationen via en tilladelsesliste og dermed stærk begrænse SSRF-udnyttelser.

Kilde: CSOonline