En sikkerhetsproblem i PayPal med høy alvorlighet var i stand til å eksponere brukernes passord for hackere

Med over 286 millioner aktive kontoer er PayPal den desidert største og mest populære betalingsprosessoren i verden. Den har oppnådd den tittelen ikke bare fordi den gir en pålitelig, brukervennlig tjeneste, men også fordi dens utviklere og programvareingeniører har implementert en rekke sikkerhetsfunksjoner som gir brukerne tryggheten de er ute etter når de behandler online betalinger. Ironisk nok hadde en av disse sikkerhetsfunksjonene en feil i seg som var i stand til å forlate brukere utsatt for overtakelse av kontoer.

En sikkerhetsekspert oppdager en alvorlig PayPal-sårbarhet

Sårbarheten ble oppdaget av Alex Birsan, en rumensk informasjonssikkerhetskonsulent og programvareingeniør som også bruker tid på jakt på bug. Han fikk øye på PayPal-påloggingsprosessen da han la merke til en JavaScript-fil som inneholdt et CSRF-symbol (Cross-Site Request Forgery) og en økt-ID. Birsan var fascinert.

Han nevnte i sin offentliggjøring at å la denne typen data i en JS-fil kunne utsette dem for hackere. Selvfølgelig, ved å bruke en teknikk kjent som Cross-Site Script Inclusion (XSSI), satte han sammen et scenario der en angriper ville ha vært i stand til å stjele CSRF-token og økt-ID fra en bruker som hadde blitt lurt til å besøke en ondsinnet side.

Opprinnelig trodde Alex Birsan at dette var forferdelig nyheter. Han antok at tokenet og økt-IDen var nok til å etterligne en bruker. Etter mange forsøk på å ta over hans egen regning, innså han imidlertid at et vellykket angrep ville kreve mer arbeid. Likevel presset han på.

Sårbarheten skjuler seg i en sikkerhetsfunksjon designet for å stoppe brute-force-angrep

Etter mer etterforskning fant Birsan ut at CSRF-tokenet og sesjons-IDen faktisk ble brukt av PayPal CAPTCHA-mekanisme. CAPTCHA, som står for Completely Automated Public Turing-test for å fortelle Computers and Humans Apart, er en av de enkleste formene for beskyttelse mot brute-force-angrep.

I motsetning til mange andre online tjenester, har PayPal bestemt seg for å ikke inkludere en CAPTCHA-utfordring under hovedpåloggingsskjemaet. I stedet vises den på en blank side etter et forhåndsinnstilt antall mislykkede påloggingsforsøk. Når brukeren har løst CAPTCHA-utfordringen, sendes en HTTP POST-forespørsel til PayPal, som i tillegg til det nevnte CSRF-symbolet og økt-ID også inneholder brukernavnet og passordet brukeren la inn under det siste påloggingsforsøket i ren tekst. Noe mer hodeskraping senere var Alex Birsan klar med beviset for konseptet.

En angriper vil først bruke XSSI for å trekke ut CSRF-tokenet og økt-ID-en gyldig for brukerens nettleser. Deretter vil de gjøre noen få påloggingsforsøk ved å bruke tilfeldige legitimasjonsbeskrivelser, noe som ville utløse CAPTCHA-utfordringen. Når brukeren logger seg på kontoen sin med samme nettleser, vil de tilfeldige brukernavnene og passordene bli overskrevet av gyldige legitimasjonsbeskrivelser. Deretter trenger alt en angriper et annet CAPTCHA-token (som relativt enkelt kan hentes ved å bruke en CAPTCHA-løsningstjeneste) for å avsløre målets påloggingsdata i ren tekst.

PayPal beveger seg raskt for å rette opp sårbarheten

Som du ser var det knapt en tur i parken å finne en måte å utnytte feilen på. Ikke desto mindre viste angrepet-om-konsept-angrepet at hvis sårbarheten ikke ble overvåket, kan det føre til alvorlige økonomiske tap for noen mennesker, og derfor ga Birsan den høye rapporten CVSS-poengsum.

Den første rapporten ble sendt 18. november, og etter 18 dager validerte HackerOne endelig Birsans funn. PayPal erkjente problemet og var enig i at det er ganske alvorlig. 10. desember ble Birsan tildelt en dusør på drøyt 15.300 dollar (summen belønnet bare for feil med høy alvorlighetsgrad), og bare 24 timer senere var sårbarheten allerede oppdatert. Birsan beskrev hastigheten som PayPal løste problemet som "imponerende" - en ros som sjelden blir gitt ut i dag.