Japan's nationale computer emergency response team, JPCERT/CC, heeft een recente toename van webdatalekken gekoppeld aan twee hoofdoorzaken: misbruikte mobiele app-API's en bekende softwarefouten, waaronder een misbruikte SQL-injectiefout in Metabase. Het verhaal is een nuttige herinnering dat Japanse webdatalekken en zwakke mobiele API's meestal problemen zijn aan de serverzijde, in systemen die gebruikers niet kunnen zien of beheren.

Wat JPCERT/CC aantrof achter Japan's datalekken

Volgens het rapport verbindt JPCERT/CC Japan's recente toename van datalekken aan het misbruik van mobiele applicatie-API's en aan kwetsbaarheden die al publiekelijk bekend waren. Een van de genoemde voorbeelden is een SQL-injectiefout in Metabase, die aanvallers hebben misbruikt.

De rode draad is dat dit geen exotische aanvallen zijn. Bekende fouten en slecht beveiligde interfaces zijn de toegangspunten. De samenvatting van het bronmateriaal koppelt de lekken niet aan iets wat individuele gebruikers hebben gedaan, en dat is belangrijk voor hoe lezers over risico zouden moeten nadenken: de persoonsgegevens werden blootgesteld door de diensten die ze beheerden.

Hoe SQL-injectie en blootgestelde mobiele API's persoonsgegevens lekken

Twee technische termen drijven dit verhaal voort, dus het helpt om ze duidelijk te definiëren.

SQL-injectie gebeurt wanneer een applicatie door de gebruiker aangeleverde invoer doorgeeft aan een databasequery zonder deze goed te controleren. Een aanvaller kan invoer maken die de query verandert, waardoor deze gegevens kan lezen die hij nooit zou mogen zien. Metabase is een hulpmiddel voor data-analyse dat verbinding maakt met databases, dus een fout erin kan de onderliggende gegevens binnen bereik brengen.

Misbruik van mobiele API's is een andere route naar een vergelijkbaar resultaat. Een mobiele app communiceert met de servers van een bedrijf via een API. Als die API niet goed verifieert wie er vraagt, of wat die mag ophalen, kan iemand rechtstreeks verzoeken naar de API sturen, buiten de app om, en gegevens in bulk ophalen. De app op je telefoon kan er volkomen normaal uitzien terwijl de server erachter meer vrijgeeft dan zou moeten.

In beide gevallen ligt de zwakte bij de organisatie die de dienst beheert. Het patchen van bekende fouten en het aanscherpen van API-toegangscontroles zijn de oplossingen, en beide zijn de taak van de beheerder, niet van de klant.

Wat Japanse gebruikers en diensten nu moeten controleren

Voor organisaties wijst de nadruk van het rapport op bekende fouten op een basischecklist:

  • Controleer of elke Metabase-implementatie is bijgewerkt naar een versie die de misbruikte SQL-injectiefout verhelpt.
  • Controleer mobiele app-API's om er zeker van te zijn dat elk verzoek wordt geauthenticeerd en dat gebruikers alleen hun eigen gegevens kunnen ophalen.
  • Behandel openbaar gemaakte kwetsbaarheden als urgent, aangezien aanvallers ze al gebruiken.

Voor individuele gebruikers is er weinig direct te configureren, maar je kunt letten op tekenen dat een dienst die je gebruikt is getroffen: notificatie-e-mails, onverwachte berichten over het resetten van wachtwoorden, of phishing die verwijst naar details die alleen dat bedrijf zou moeten kennen.

Hoe je je blootstelling na een lek beperkt

Het is de moeite waard om één punt direct te zeggen: een VPN lost dit niet op. Een VPN versleutelt verkeer tussen je apparaat en een VPN-server en maskeert je IP-adres, wat nuttig is voor privacy op onbetrouwbare netwerken. Het doet niets aan een fout in een database of API die je gegevens opslaat. Als een dienst je gegevens lekt, is de route die de gegevens hebben afgelegd om daar te komen irrelevant voor hoe ze zijn blootgesteld.

Wat wel helpt, is de schade beperken wanneer een lek plaatsvindt:

  • Gebruik een uniek wachtwoord voor elk account. Als één dienst wordt getroffen, kunnen aanvallers dezelfde inloggegevens niet elders hergebruiken. Een wachtwoordbeheerder maakt dit praktisch.
  • Schakel lekmonitoring in. Veel browsers, wachtwoordbeheerders en onafhankelijke diensten waarschuwen je wanneer je e-mailadres in een bekend lek voorkomt.
  • Deel minder gegevens met apps. Velden die je nooit hebt verstrekt, kunnen niet worden gelekt. Sla optionele details over en gebruik een apart e-mailadres voor diensten met minder vertrouwen.
  • Schakel multi-factor authenticatie in waar dit wordt aangeboden, zodat een gelekt wachtwoord alleen niet genoeg is.
  • Wees voorzichtig met onverwachte berichten. Gelekte contactgegevens voeden vaak gerichte phishing.

Wat dit voor jou betekent

De bevindingen van JPCERT/CC bevestigen dat je blootstelling sterk afhangt van hoe goed de bedrijven die je vertrouwt hun systemen onderhouden. Je kunt hun servers niet patchen, maar je kunt beperken wat er op het spel staat. Ga ervan uit dat sommige van je gegevens uiteindelijk ergens zullen worden blootgesteld, en zorg ervoor dat die blootstelling je andere accounts niet ontgrendelt.

Voor een recent voorbeeld van hoe grootschalige blootstelling in Japan eruitziet, zie onze berichtgeving over de KDDI-datainbreuk waarbij 12,2 miljoen klant-e-mails in Japan werden blootgesteld. Alleen e-mailadressen lijken misschien gering, maar het zijn precies het soort gegevens dat phishingcampagnes aandrijft.

Belangrijkste punten

Japanse webdatalekken die verband houden met misbruik van mobiele API's en niet-gepatchte software zijn een probleem aan de dienstzijde, en een VPN lost ze niet op. Gebruik unieke wachtwoorden, schakel lekmonitoring in, zet multi-factor authenticatie aan en geef apps alleen de gegevens die ze echt nodig hebben. Die gewoonten zullen een datainbreuk niet stoppen, maar ze kunnen voorkomen dat er één een veel groter probleem voor je wordt.