Shell erkent datalek onbeschermde klantengegevens Recharge-laadpalen - update

Een database met gebruikersgegevens van het Shell Recharge-laadpalennetwerk was zonder wachtwoord online toegankelijk. Het gaat om een interne database van bijna een terabyte aan klantengegevens. Het is niet duidelijk of er klanten uit de Benelux getroffen zijn door het datalek.

Shell Recharge

Het datalek werd ontdekt door onderzoeker Anurag Sen en onder meer TechCrunch heeft de gegevens in kunnen zien; er zouden miljoenen datapunten in de database zitten, waaronder namen, e-mailadressen, telefoonnummers en voertuigidentificatienummers van klanten van Shell Recharge. Ook data over residentiële privélaadpunten zou in de dataset te vinden zijn geweest. Het is vooralsnog niet duidelijk of het om gegevens uit een bepaalde regio gaat. Shell Recharge is wereldwijd actief, waaronder ook in Nederland en België.

Shell zegt in een statement tegenover Tweakers: "Shell heeft stappen genomen om onbevoegde toegang tot Shell Recharge Solutions-data te identificeren en begrenzen. We onderzoeken het incident en houden onze IT-systemen in de gaten. We nemen verdere stappen waar nodig."

De gegevens werden gehost in een cloudomgeving van Amazon en werden volgens de bronnen niet beveiligd met een wachtwoord. TechCrunch zegt dat de recentste gegevens in 2023 aan de database werden toegevoegd. Onderzoeker Sen meldde de mogelijkheid tot onbevoegde toegang bij Shell, maar kreeg daar geen antwoord op. Ook TechCrunch meldde dit, waarna de data al snel ontoegankelijk werd gemaakt.

Update, 17.44 uur: Statement van Shell toegevoegd.

Reacties (55)

[TheVMaster]

Blijkbaar gaat het om een database van Greenlots, welke Shell Recharge in 2019 heeft overgenomen. Althans, als ik zo het originele artikel bij TechCrunch lees.

Security researcher Anurag Sen found a database online that contained close to a terabyte of logging data relating to Shell Recharge, the company’s worldwide network of hundreds of thousands of electric vehicle charging stations, which it acquired in part from Greenlots in 2019. Greenlots provided electric vehicle (EV) charging services and technology for customers operating vehicle fleets.

[YannickSpinner]

In mijn optiek verwijst

which it acquired in part from Greenlots in 2019

naar de laadpalen, al hebben ze daar ongetwijfeld de database bij gekregen. Het is hoe dan ook Shell's verantwoordelijkheid om dergelijke gegevens te beschermen!

[TheVMaster]

Ja, ik denk dat het ook slaat op de laadpalen, maar de database zal daar ongetwijfeld bij horen. Maar het gaat dus om een Amerikaanse bedrijf, dus ik verwacht dat het dus informatie over (of van) Amerikaanse klanten zal gaan.

Maar bottomline is Shell natuurlijk verantwoordelijk.

[kimborntobewild]

Maar bottomline is Shell natuurlijk verantwoordelijk.

Het punt is dat het doen van pentests in zijn algemeenheid niet echt gangbaar zijn. Zeker als je software overneemt: zo'n beetje het eerste wat je dan moet doen, is pentests.

[Timmiejj]

Man, dit is wel heel erg een gevalletje 2008 IT issue, geen wachtwoord op een online omgeving

[RobIII]

Zelfs in 2008 was geen wachtwoord op een online omgeving dom. In 1992 ook al.

[bassekeNL]

In 92 was het nog niet gebruikelijk dat je een database aan internet had hangen. Dat kostte toen nog heel veel moeite. Zonder password was toen heel normaal, als het je al lukte.

Ter illustratie: grafische browsers bestonden nog niet, Mosaic kwam pas een jaar later, Netscape twee.

[RobIII]

Ik ben van '77 (jij bent zie ik van een nóg beter vintage ) Ik weet hoe het was in '92 en ook toen zette je wachtwoorden op publiek toegankelijke systemen. Of dat nou databases of mailservers of telex order systemen waren.

[Reactie gewijzigd door RobIII op 23 juli 2024 10:15]

[DDX]

Een terabyte, staan daar highres scans in van rijbewijzen etc want hoe kom je anders aan zoveel data ?

[mphilipp]

Lastig in te schatten. Als het gegevens van meer dan een miljoen mensen zijn, met heel veel transacties...misschien. In principe is een transactierecord maar een paar bytes ofzo. Daar staat niet een heel verhaal in. Datum, hoeveelheid, ID, klaar. Persoonsrecord is ook niet gigantisch. Databases zijn best goed geoptimaliseerd in de opslag. Maar goed, we weten niet over hoeveel personen het gaat.

Maar even over de hack zelf...dit is echt bij de wilde spinnen af. Een database die gewoon benaderbaar is via internet. Dat feit alleen al is fout met de hoofdletter F. Altijd via een API natuurlijk, database ergens anders huisvesten zonder directe internet toegang. En dan uiteraard wachtwoorden...ze zouden de mensen die dit hebben gemaakt ergens op een plein ouderwets moeten laten kastijden. Stokslagen, bekogelen met rot fruit enzo. En dan door de stad lopen met een bord om hun nek: 'Ik zal nooit meer iets online zetten zonder wachtwoord'. Dit verzin je toch niet?
En 'het moest van de baas' is een heel slecht excuus. Dan neem je maar ontslag. Aan zulke dingen moet je niet mee willen werken. Heb ik ook nooit gedaan. Junior of niet.

[Tadango]

Waar denk je dat die databases staan tegenwoordig? In Azure, dus op internet. Dat hoor je af te schermen, ZEKER met persoonsgegevens. Normaal is Shell hier nogal strict in met vele controles (IRM process edg, ik heb er dagelijks mee te maken). Wellicht uitbesteed aan een derde partij die de app bouwt? Of door een afdeling die buiten de vaste paden heeft gewandeld....

[Reactie gewijzigd door Tadango op 23 juli 2024 10:15]

[mjtdevries]

Op security.nl stond dat ze een ander bedrijf hadden overgenomen. Dus wellicht stond het bij dat andere bedrijf al verkeerd ingesteld.
Wellicht zo'n vlotte startup die alles mooi Agile in elkaar geknutseld heeft?

[Frame164]

Agile is geen reden. Bij mij op het werk wordt ook agile gewerkt, maar we doen ook security by design. Een MVP dat niet voldoet aan de security requirements wordt niet gereleased. Je moet bij ons ook niet proberen om een stuk open source code te gebruiken die niet eerst is doorgezaagd door het security team.

[tweakerbee]

Shell Recharge was NewMotion. Inderdaad een overname, maar al een lange tijd geleden.

https://aftersalesmagazin...shell-recharge-solutions/

[Chevalley]

Shell Recharge zal nog lang niet op de Shell standaarden zijn als je ziet hoe lang dat normaal gesproken duurt met de bedrijven die worden overgenomen door multinational met grote, complexe processen.

[RobIII]

En 'het moest van de baas' is een heel slecht excuus. Dan neem je maar ontslag. Aan zulke dingen moet je niet mee willen werken. Heb ik ook nooit gedaan. Junior of niet.

Makkelijk lullen, maar de realiteit is lang niet altijd zo simpel. Als je ergens anders de helft verdient of je hebt dubbel zo lange reistijd, slechtere secundaire arbeidsvoorwaarden, minder vrije dagen, lagere functie, minder leuk werk etc. etc. of, erger, een combinatie van al het voorgenoemde dan zul je niet heel gauw vertrekken. Zolang je alleen maar de uitvoerende knuppel bent die braaf z'n orders uitvoert... Natuurlijk hoef je niet alles braaf te slikken; je kunt je zorgen uiten maar doet de chef er niks mee dan zal 't voor veel mensen een /care zijn. Je moet wel héél stevig in je principes staan of in de slappe was zitten om dan meteen op te staan en te vertrekken.

[Reactie gewijzigd door RobIII op 23 juli 2024 10:15]

[mphilipp]

Nouja...je kunt kiezen om een slaaf te blijven, maar ik behoud mijn integriteit. I put my money where my mouth is. Ik heb meerdere malen mijn vinger opgestoken bij werk waar ik mijn naam en dat van mijn werkgever niet onder wilde hebben. En toen was ik echt nog geen senior, maar dat was redelijk in het begin van mijn loopbaan. Een keer ging het om het werk van een collega waar ik iets aan moest doen omdat het niet goed werkte. Toen ik zag wat er gebouwd was, heb ik contact met die collega opgenomen en daarna met de baas. Bleek dat een pief bij de opdrachtgever tegen mijn collega had gezegd dat het zo moest, en hij deed dat uiteindelijk. Ik voorzag grote problemen later, en die zouden er gegarandeerd komen. Stel dat een ander bedrijf komt en ziet dan dat bedrijf XYZ dat heeft gemaakt voor een pak geld. Het gaf wel wat gepruttel van de klant in eerste instante, maar even later trok de pief die dat had gepushed het boetekleed aan.
Een andere keer werd er druk uitgeoefend om een rapport te schrijven in de richting van werkzaamheden die verricht zouden moeten worden, wat het bedrijf van de manager (externe) zou moeten uitvoeren voor een paar ton. Dat weigerde ik, want wat hij wilde dat ik schreef klopte niet. Daar wil ik mijn naam niet onder hebben. Nouja...einde opdracht natuurlijk. Ik vond het al gek dat wij als klein ICT bedrijfje werden gevraagd voor deze klus. Ze dachten zeker makkelijk druk te kunnen uitoefenen.

Ik heb nog steeds werk. Ik buig gewoon niet zomaar voor druk. Als je er maar een goed verhaal bij hebt, kan het nooit erg zijn. Dus ja, noem het makkelijk lullen, maar de ICT is voor ervaren mensen de verkeerde branche om druk op uit te oefenen. Er is gewoon teveel vraag naar ervaren mensen. En als jij kunt beargumenteren dat jij je integriteit belangrijker vindt dan de wensen van een of andere pief lijkt het mij sterk dat je nooit meer aan de bak komt.

[RobIII]

Fijn dat 't voor jou goed uitgepakt heeft en dat je goed terecht gekomen bent, maar dat is n=1 Dus, ja, makkelijk lullen. Voor jou 10 anderen die in een minder gunstige situatie zitten. En dan kijk ik dus, bijvoorbeeld, wel globaal (waar in andere landen de vraag naar IT'ers niet altijd even hoog is als hier bijvoorbeeld). Hoe dan ook: het is makkelijk je eigen situatie op anderen te projecteren maar dat is niet altijd even realistisch zoals ik al aangaf

[mjtdevries]

Dan zal ik er n=2 van maken.
Ik heb ook een situatie meegemaakt waar ik een risico zag waar ik geen verantwoordelijkheid voor wilde nemen. Toen heb ik dat aan de CIO uitgelegd en aangegeven dat hij het mandaat had om dat risico te nemen, maar ik van hem schriftelijk bevestigd wilde zien dat ik geen verantwoordelijkheid droeg.
Dat snapte hij volledig en heeft ook op schrift aan mij bevestigd dat hij de verantwoordelijkheid voor dat besluit had.

Je hoeft niet te dreigen met ontslag. Gewoon aangeven dat je niet in een rol zit om die verantwoordelijkheid te dragen. Het moet wel heeeeeeeel raar gaan dat een leidinggevende je de opdracht geeft om iets op een bepaalde manier te doen, maar niet de verantwoordelijkheid voor die opdracht wil nemen.

[RobIII]

Dan zal ik er n=2 van maken.

Uh, je zegt precies wat ik zeg. @mphilipp zegt "gewoon opstappen" en ik zeg "dat is niet zo simpel; je kunt aangeven dat je 't er niet mee eens bent en 't dan alsnog -onder protest- (moeten) uitvoeren omdat opstappen geen (realistische) optie is".

[Reactie gewijzigd door RobIII op 23 juli 2024 10:15]

[mjtdevries]

Uh, je zegt precies wat ik zeg

Nee Ik zegt iets totaal anders dan wat jij zegt.

Als het voorstel onverantwoord is, dan zorg ik dat er zwart op wit staat dat ik daar geen verantwoording voor kan nemen en dat de leidinggevende die verantwoording neemt.

Dat heb jij nergens gezegd en dat is een cruciaal verschil.
En uitermate belangrijk op het moment dat er problemen komen. Want dan kan jij wel zeggen, "ik heb het toen tegen de leidinggevende gezegd" maar die beweert dan van niets te weten en geeft jou gewoon de schuld.
Ik heb dat meerdere keren zien gebeuren.

Reken maar dat een leidinggevende ineens beter na gaat denken als zwart op wit komt te staan dat hij dat onverantwoordelijk besluit heeft genomen terwijl de specialisten dat afraadden.

[mphilipp]

Ik zeg opstappen om een heel verhaal te voorkomen. Het mag duidelijk zijn dat meteen bij elk (mogelijk) conflict te roepen dat je opstapt niet constructief is. Maar uiteindelijk is het voor mij (ik kan onmogelijk voor anderen spreken) een laatste optie in geval men echt niet bereid is te luisteren of mee te gaan in de bezwaren.
Ja, natuurlijk zijn er altijd mensen die niet in een positie zitten dat ze een keuze hebben (hoewel je altijd een keuze hebt). Maar ik kan in principe ook alleen maar voor mijzelf spreken.

[pelt]

Heel de rij klappen!

[Zer0]

Ik buig gewoon niet zomaar voor druk

Maar wel anderen adviseren druk uit te oefenen door met ontslag te dreigen?

[magician2000]

Voor jou is dit "gewoon", voor mij ook, zo ook voor diverse mensen die ik ken. Echter, dit is zeker niet hoe de mensen er gemiddeld tegenaan kijken. De meeste mensen halen hun schouders op en doen wat "de baas" ze opdraagt.

Deze reactie puur om je dit nog even onder ogen te brengen. Voor zover je het eigenlijk al niet wist. Dus absoluut geen commentaar op wat je hebt gedaan in de genoemde situaties.

Overigens, ik ben wel degelijk een keer mijn baan (indirect) kwijtgeraakt door mijn poot stijf te houden op een punt waar ik volledig gelijk had. Maar zelfs dan is het zo dat je het voor jezelf doet. Want wil je bij een partij (blijven) werken die de kantjes er vanaf loopt c.q. de boel aan het flessen is?

[Frame164]

Als je zoveel verdiend dat je daarom niet weg kunt moet je ook de volledige aansprakelijkheid nemen (en krijgen) voor dit soort fouten. Dan zit je daar niet voor een modaal salaris.maar stukken meer.

[nullbyte]

Kom kom, even realistisch. Geen enkele "baas" zal een opdracht geven om een database onbeveiligd aan het internet te knopen. De realiteit is in dit geval wel zo simpel.

[closefuture]

Makkelijk lullen, maar de realiteit is lang niet altijd zo simpel.

Als softwareontwikkelaar word je dik betaald en liggen de banen voor het oprapen. Als zo'n beroepsgroep naar jouw idee zelfs niet eens verantwoording hoeft te nemen voor wat ie doet, wie dan wel?

[Frame164]

Stokslagen is een beetje overdreven maar met de laatste alinea ben ik het wel eens.

[Dennisb1]

Ik doe maar een gok
- NAW gegevens
- e-mail
- kaart gegevens
- saldo
- in en uitchecken
- financiën
- logging
- data de palen

[Viper1995]

Ik denk dat je daar nog verstelt over staat, op werk drukken we er ongeveer +/- 4GB per dag dag bij alleen op een data stroom aan gegevens. Dus trek dat over een jaar heen dan gaat het vlot. En hier heb je dan naast de persoonsgegevens de locaties, transacties, kaarten verzin het maar

[ocf81]

Niks kan worden uitgesloten, maar je moet niet onderschatten hoe veel data IoT-achtige zaken wel niet versturen. Dat kan echt een enorme datastroom opleveren.

[DDX]

Maar dat zijn dan toch niet allemaal klantgegevens ?

[ocf81]

Maar een database kan beide tegelijkertijd bevatten toch?

[WhiteDog]

Luie programmeurs. Trek voor de grap maar is je app store open en vraag jezelf af waarom iets basic als Bitwarden 280 MB groot is. Voor een wachtwoordmanager. Tekst.

Er passen games met 10x meer inhoud op een floppy.

[knakworst]

Ik ben benieuwd wanneer ik een email ontvang van Shell Recharge. Op grond van AVG hebben ze 48 uur geloof ik.


Edit: Binnen 72 uur bij Autoriteit Persoonsgegevens. Potentiële slachtoffers moeten adquaat worden ingelicht maar ik zie niet zo snel een specifieke termijn.

En het zou natuurlijk ook een database kunnen zijn met alleen Amerikaanse klanten. Want Amazon cloud is ook wel gek.

Veiligheid is van groot belang bij Shell Recharge Solutions en daarom nemen we verschillende maatregelen om de beveiliging van je gegevens bij al onze interacties te waarborgen. Om je gegevens veilig te kunnen verwerken, ontwerpen we onze toepassingen met het oog op veiligheid. We gebruiken de nieuwste SSL-technologie om alle persoonlijke data te coderen die op onze site wordt verwerkt, zodat deze veilig via internet kunnen worden verzonden zonder dat iemand anders er toegang toe heeft. Ook voeren we standaard beveiligingstests uit als onderdeel van ons ontwerpproces.

en

Wij maken ons sterk voor de beveiliging van je persoonsgegevens.

Wij hebben technische en organisatorische maatregelen genomen om gegevens die je betreffen te beschermen tegen onbevoegde toegang en onjuist gebruik. Meer in het bijzonder maken wij voor sommige van onze diensten gebruik van versleuteling, passen wij authenticatie- en verificatieprocessen toe voor toegang tot onze diensten en toetsen, beoordelen en evalueren wij regelmatig de effectiviteit van onze beveiligingsmaatregelen.

Als je je creditcardgegevens invoert, wees er dan van bewust dat een externe betalingsverwerker je betaling zal verwerken. Wij zullen alleen de laatste vier cijfers van je creditcardnummer, de vervaldatum en de veiligheidscode opslaan.

[Reactie gewijzigd door knakworst op 23 juli 2024 10:15]

[juiced01]

Haha, weer een bedrijf met "we value your privacy blabla" nonsense...

[litebyte]

.....'heel erg'....'dit mocht niet gebeuren' ....'heel vervelend' ....'ondanks dat we'.....'onze oprechte excuses' ......'we gaan er alles aan doen'

[meathome]

'we gaan er alles aan doen'

sorry, nu houden we je aansprakelijk, ermee wegkomen gaat over de juiste woorden:

'we streven erna om alles eraan te doen'.....'en, voor welk bedrag schikken we deze keer?'....'daar kan ik me niets van herinneren'

[Reactie gewijzigd door meathome op 23 juli 2024 10:15]

[Djerro123]

En het zou natuurlijk ook een database kunnen zijn met alleen Amerikaanse klanten. Want Amazon cloud is ook wel gek.

Ik werkte met AWS in 2013-2014 voor Shell, daar is niks vreemds aan. Ze zijn zowel Azure als AWS klant zover ik weet, misschien ook wel andere?

[BounceMeister]

Voor zo'n groot bedrijf mag je wel verwachten dat ze mensen in dienst hebben die weten wat ze doen. Uit de info van het artikel lijkt het dat ze grof nalatig zijn geweest. Volgt er dan ook een dikke boete?

[Tadango]

Dat zou je verwachten............ In de praktijk is het veel uitbesteden aan de goedkoopste (want dat moet) en daardoor is het heeeeel duur in de praktijk en erg matig in kwaliteit.

[woopdiedoo]

Je moet volgens toch wel erg je best doen om een bij een grote cloud provider een database op te zetten die publiekelijk toegankelijk is, zonder enige vorm van authenticatie.
Ik heb een beetje ervaring met Azure en je word toch wel doodgegooid met waarschuwing en security recommendations (firewalls, isolatie achter vnets, AD authenticatie, etc).
Klinkt minder als nalatigheid en meer als actieve sabotage.

[WhiteDog]

Dan nog, als ik even de verplichte https had uitgezet vanwege SSL-problemen had ik toch meteen iemand van security aan de lijn... werd actief geaudit.

Het feit dat ze niet eens op de initiële melding hebben gereageerd zegt al voldoende.

[bussie66]

Mag je toch best wel wat mensen voor ontslaan lijkt mij

Zoiets zou strafbaar moeten worden gesteld in de wet (mocht dat nog niet het geval zijn).

[litebyte]

Dit is grove nalatigheid, strafbaar is het, maar het heeft vaak persoonlijk geen concequenties in juridische zin van, zeker niet bij overheids instellingen of machtige bedrijven zoals shell. We zagen het bij de belastingdienst met de toeslagenaffaire

[Djerro123]

We zagen het bij de belastingdienst met de toeslagenaffaire

Dat is toch geen vergelijking?

[litebyte]

Het gaat erom dat machtige organisaties, of deze nu commercieel of niet commercieel zijn een status aparte posittie hebben als het gaat om (juridische) verantwoordelijkheid. S hell is daar absoluut geen uitzondering op, zal ook gaan blijken.

[Reactie gewijzigd door litebyte op 23 juli 2024 10:15]

[genosis]

Een jaar of 10 geleden een tankpas van Shell gehad. Dat administratieve pakket was een draak. Wat een aftandse oude zooi was dat. Werkte alleen in IE, gemaakt door een dure consultancy club in Nederland. Durf even geen namen te noemen maar het was een grote partij. Dat die zulke software durfden af te leveren vond ik best gek.

[DrPoncho]

Je durft geen namen te noemen?

[genosis]

Omdat ik het niet zeker meer weet haha.

[jpsch]

Shell helpt

Schijnbaar de hackers.

[Tazzios]

Juist niet!
Indien een database zonder wachtwoord toegankelijk is via het internet valt er voor een hacker niets meer te hacken. Dat zal de leren!

[vinkjb]

Ze zijn nu eenmaal beter in het vernietigen van flora en fauna he.
En daar zijn ze helaas niet alleen in.
Shell doet net als alle andere oliemaatschappijen helemaal niets, ja op papier.