Japans nationale computerberedskabsteam, JPCERT/CC, har forbundet en nylig stigning i webdatalækager med to hovedårsager: misbrugte mobile app-API'er og kendte softwarefejl, herunder en udnyttet SQL-injektionsfejl i Metabase. Historien er en nyttig påmindelse om, at japanske webdatalækager og svagheder i mobile API'er normalt er problemer på serversiden, i systemer som brugerne ikke kan se eller kontrollere.

Hvad JPCERT/CC fandt bag Japans datalækager

Ifølge rapporten forbinder JPCERT/CC Japans nylige stigning i datalækager med misbrug af API'er til mobilapplikationer og med sårbarheder, der allerede var offentligt kendte. Et af de nævnte eksempler er en SQL-injektionsfejl i Metabase, som angribere har udnyttet.

Den fælles tråd er, at der ikke er tale om eksotiske angreb. Kendte fejl og dårligt beskyttede grænseflader er indgangspunkterne. Resuméet af kildematerialet knytter ikke lækagerne til noget, individuelle brugere gjorde, og det er vigtigt for, hvordan læsere bør tænke om risiko: de personlige data blev eksponeret af de tjenester, der opbevarede dem.

Hvordan SQL-injektion og eksponerede mobile API'er lækker personlige data

To tekniske termer driver denne historie, så det hjælper at definere dem klart.

SQL-injektion sker, når en applikation sender brugerleveret input ind i en databaseforespørgsel uden at kontrollere det ordentligt. En angriber kan konstruere input, der ændrer forespørgslen, hvilket kan lade dem læse data, de aldrig burde se. Metabase er et dataanalyseværktøj, der forbinder til databaser, så en fejl i det kan bringe de underliggende poster inden for rækkevidde.

Misbrug af mobile API'er er en anden vej til et lignende resultat. En mobilapp kommunikerer med en virksomheds servere gennem en API. Hvis den API ikke ordentligt verificerer, hvem der spørger, eller hvad de har tilladelse til at hente, kan nogen sende forespørgsler direkte til den, uden om appen, og trække data ud i bulk. Appen på din telefon kan se helt normal ud, mens serveren bag den udleverer mere, end den burde.

I begge tilfælde ligger svagheden hos organisationen, der driver tjenesten. At patche kendte fejl og stramme API-adgangskontroller er løsningerne, og begge er operatørens ansvar, ikke kundens.

Hvad japanske brugere og tjenester bør tjekke nu

For organisationer peger rapportens vægt på kendte fejl på en grundlæggende tjekliste:

  • Bekræft, at enhver Metabase-installation er opdateret til en version, der løser den udnyttede SQL-injektionsfejl.
  • Gennemgå mobile app-API'er for at sikre, at hver forespørgsel autentificeres, og at brugere kun kan hente deres egne poster.
  • Behandl offentligt offentliggjorte sårbarheder som akutte, da angribere allerede bruger dem.

For individuelle brugere er der lidt at konfigurere direkte, men du kan holde øje med tegn på, at en tjeneste, du bruger, er blevet påvirket: notifikationsemails, uventede beskeder om nulstilling af adgangskode eller phishing, der refererer til detaljer, som kun den virksomhed burde kende.

Sådan begrænser du din eksponering efter en lækage

Det er værd at være direkte om ét punkt: en VPN løser ikke dette. En VPN krypterer trafik mellem din enhed og en VPN-server og maskerer din IP-adresse, hvilket er nyttigt for privatliv på utrygge netværk. Det gør intet ved en fejl i en database eller API, der opbevarer dine oplysninger. Hvis en tjeneste lækker dine poster, er den rute, dataene tog for at komme dertil, irrelevant for, hvordan de blev eksponeret.

Hvad der hjælper, er at begrænse skaden, når en lækage sker:

  • Brug en unik adgangskode til hver konto. Hvis én tjeneste kompromitteres, kan angribere ikke genbruge de samme legitimationsoplysninger andre steder. En adgangskodeordbog gør dette praktisk.
  • Slå lækageovervågning til. Mange browsere, adgangskodeordbøger og uafhængige tjenester advarer dig, når din email dukker op i en kendt lækage.
  • Del færre data med apps. Felter, du aldrig har udfyldt, kan ikke lækkes. Spring valgfrie detaljer over, og brug en separat emailadresse til tjenester med lavere tillid.
  • Aktivér multifaktorautentificering, hvor det tilbydes, så en lækket adgangskode alene ikke er nok.
  • Vær forsigtig med uventede beskeder. Lækkede kontaktoplysninger driver ofte målrettet phishing.

Hvad dette betyder for dig

JPCERT/CC's fund understreger, at din eksponering i høj grad afhænger af, hvor godt de virksomheder, du stoler på, vedligeholder deres systemer. Du kan ikke patche deres servere, men du kan reducere, hvad der står på spil. Antag, at nogle af dine data til sidst vil blive eksponeret et sted, og sørg for, at den eksponering ikke låser op for dine andre konti.

For et nyligt eksempel på, hvordan eksponering i stor skala i Japan ser ud, se vores dækning af KDDI-lækagen, der eksponerede 12,2 mio. kundeemails i Japan. Emailadresser alene kan virke ubetydelige, men de er præcis den slags data, der driver phishing-kampagner.

Vigtige pointer

Japanske webdatalækager forbundet med misbrug af mobile API'er og uopdateret software er et problem på tjenestesiden, og en VPN løser dem ikke. Brug unikke adgangskoder, aktivér lækageovervågning, slå multifaktorautentificering til, og giv kun apps de data, de virkelig har brug for. Disse vaner stopper ikke et brud, men de kan forhindre, at ét bliver et meget større problem for dig.