Nederlander ontdekt Azure-bucket van Fujitsu die jaar lang op internet stond

De Nederlandse beveiligingsonderzoeker Jelle Ursem heeft een grootschalig datalek ontdekt bij Fujitsu. Private AWS-sleutels, data van klanten en plaintextwachtwoorden stonden een jaar lang openbaar op het internet.

De informatie was te vinden in een openbaar toegankelijke Microsoft Azure-opslagbucket, vertelt Ursem, die onder andere bij het Dutch Institute for Vulnerability Disclosure is aangesloten, aan The Stack. De bucket heette 'fjbackup' en bevatte onder meer diverse OneNote-bestanden met 'alles wat je moet weten' over klanten van het bedrijf, waaronder het Nederlandse waterleidingbedrijf PWN. PWN levert drinkwater aan ruim 800.000 gezinnen, bedrijven en instellingen in Noord-Holland.

De gevonden bucket bevatte verder een CSV-bestand met wachtwoorden die uit wachtwoordmanager LastPass zijn gehaald en in platte tekst zijn opgeslagen. Verder zat er een volledige back-up van een mailbox in, met daarin duizenden e-mails en gevoelige data. De bucket bevatte ook uitgebreide details over activiteiten van klanten en teams.

De bucket stond tussen maart 2022 tot begin 2023 open op het internet. Ursem ontdekte de bucket begin 2023 en meldde dit bij Fujitsu, wat volgens de onderzoeker enige moeite kostte. Fujitsu heeft volgens Ursem geen duidelijke plek waar securitymeldingen gemaakt kunnen worden. Via een intern contact wist Ursem uiteindelijk toch melding te maken van het datalek en in het voorjaar van 2023 werd de bucket offline gehaald. Of andere mensen of organisaties de bucket ook tegen zijn gekomen in de tijd dat deze openbaar was, is niet bekend. Ook is onduidelijk of de informatie in de bucket gebruikt is voor malafide doeleinden.

Ursem, die op Tweakers actief is als Schizoduckie, vindt regelmatig data in openbare bronnen. Tweakers sprak hem daar in 2022 over in een interview.

Update 14.38 uur - In het artikel stond dat er een AWS-bucket gelekt was. Het gaat echter om een Microsoft Azure-bucket. Het artikel is daarop aangepast.

Reacties (61)

[nzall]

Ik vind het gewoon absurd dat in 2024 er uberhaupt nog een optie is op wat voor cloud provider dan ook om een no-auth bucket te hebben. Ik zou zelf verwachten dat al die buckets al meer dan een jaar verplicht een authenticatielaag moeten hebben, en dat bedrijven dan maar hun workflow moeten aanpassen zodat die met de tools die ze gebruiken aan die buckets kunnen.

[david-v]

Je kan in een storage account (want zo heet een aws bucket in Azure ) kun je ook gebruiken voor het bewaren van statische webpagina's die openbaar zijn, of voor css bestanden, plaatjes (als je geen CDN wil gebruiken) enz. Er zijn genoeg redenen te bedenken waarom je dat niet achter een authenticatie mechanisme wil zetten.

Echter, in Azure krijg je dan te maken met een security warning. Deze moet je dus (on)bewust negeren of aanmerken als "ja, ik weet het en het klopt". Bovendien, bij het aanmaken van een storage account in azure staat deze volgens mij standaard als niet public. Je moet dan bewust toestaan dat het publiekelijk te benaderen is.

[nzall]

Kun je daarvoor niet beter een ECHTE website opzetten op Azure, dus een hosted website die effectief bedoeld is om een webpagina te hosten, in plaats van een storage account?

[david-v]

Afhankelijk van wat je nodig hebt niet. Static websites is een feature van storage accounts.

[Reactie gewijzigd door david-v op 23 juli 2024 03:26]

[Andreplusplus]

maar dan heb je zo'n storage account, bedoeld voor onnozele publieke data, en dan komt er een andere joker die de gebonden bestanden erop jongste. Geen waarschuwing op dat moment. "O, ik dacht dat al onze storage accounts private waren?"

[david-v]

Ik weet niet wat voor jokers bij jullie rondlopen , maar wij zijn als team eigenaren en verantwoordelijk voor ons deel in Azure. Er is werkelijk niemand die zomaar "even" iets op een storage account zet, al helemaal niet in productie. Bovendien gaat dat allemaal via pull requests en ci/cd pipelines en doen we niet "zomaar" content in een storage account erbij. Elke storage account heeft een specifiek doel en de bijbehorende beveiliging.

Als je je processen en beveiliging niet goed op orde hebt, ja, dan gaat het mis. Dat heb je in elk team onafhankelijk van gebruikte technologie of infrastructuur. Als het een zooitje is dan krijg je ook een zooitje in je Infra.

[n9iels]

Zelfde gaat hierbij natuurlijk ook op voor AWS. Daar is een S3 bucket standaard niet publiek en moet je flink wat waarschuwingen negeren om het publiek te krijgen.

[Hieronymuski]

Nee hoor.

No offense, maar een beetje IT partij loopt echt niet in de console hun infra in elkaar te klikken. Dit gebeurt eerder met iets als Terraform, en daar krijg je die waarschuwing niet.

Sterker nog, het is een true/false setting. That's it.

Ik praat 't niet goed dat dit gebeurt, want ook code moet je reviewen. Maar die waarschuwingen in de consoles zijn waardeloos voor de grotere IT'ers.

[Mellow Jack]

Dat is niet helemaal terecht, er zijn duizenden redenen die openbare buckets logisch maken. Dit is dr niet 1 van

[XIU]

Wij gebruiken het regelmatig om static images voor websites op te zetten, of andere download bestanden. Maar het is wel zo dat je standaard bij het aanmaken van een nieuwe storage account dit hebt afstaan (dus alle containers onder die account kunnen dan geen publieke access geven), en daarna moet je het per container dan ook nog eens aanzetten. Het is dus wel al veel veiliger dan vroeger.

[RobertMe]

Nederlander ontdekt AWS-bucket van Fujitsu die jaar lang op internet stond

Nee? Hij ontdekte een publieke "bucket" bij Azure? Dat staat zelfs in het artikel alhier.
Echter bevatte die publieke bucket bij Azure ook AWS-keys.

Dus volgens mij heeft de auteur een aantal zaken door elkaar gehaald.

[MazDaMan1970]

Ja, zo lees ik het ook. Is dus feitelijk een Azure-lek. Ik verbaas mij er altijd over hoe laks sommige bedrijven zijn & vind het ook vreemd dat dit soort zaken klaarblijkelijk niet bij security-audits naar voren komen.

[david-v]

Is dus feitelijk een Azure-lek

feitelijk is het een lek bij Fujitsu, want die beheren die bucket (lees storage account).

Ik verbaas mij er altijd over hoe laks sommige bedrijven zijn & vind het ook vreemd dat dit soort zaken klaarblijkelijk niet bij security-audits naar voren komen.

In de Microsoft Defender for Cloud komt een openstaande storage account standaard omhoog als een security risico. Dat je als bedrijf dit vervolgens negeert is een ander probleem. Ik zie regelmatig Azure subscriptions met een security score op productie die lager is dan de huidige rente (overdreven maar jullie snappen het wel ).

[Vexxon]

Is dus feitelijk een Azure-lek

Ehm nee
Als ik mijn gmail accountgegevens op een papiertje laat rondslingeren is dat toch ook geen lek bij GMail?

[Neus]

Dat staat er toch? Info voor AWS-bucket gevonden in een open Azure-opslagbucket.

[pumpidumpi]

Dat staat er niet. AWS sleutels zijn in een Azure opslagbucket gevonden (wat een Azure opslagbucket dan ook mag zijn...).

Of je met die gevonden sleutels in een AWS bucket kan staat nergens vermeld. Dus ja het is verwarrend en er worden dingen door elkaar gehaald en/of zijn niet duidelijk vermeld.

[Jerie]

Dat is data storage, maar AWS/S3 is under the hood geen filesystem (Azure's tegenhanger zou ook zo kunnen werken; weet ik niet).

[Crysania]

Alleen jammer dat op Azure niet zoiets bestaat als een "bucket". dit is een AWS term. In Azure heet zoiets een Storage Account of Azure Blob Storage.

beetje verwarrend geschreven.

De zijn lijkt ook te gaan over een AWS bucket die een jaar op internet stond maar dat lijkt niet het geval maar het lijkt te gaan over dat de keys naar deze bucket een jaar lang open op internet stonden.

[EvelineM]

Er ging inderdaad wat fout met de kop. Het gaat om Azure, niet om AWS. Het artikel is daarop aangepast.

[chemokar]

Nu de kop nog even aanpassen in een Azure-blob of Azure storage account, alleen de vraag is even waar de data gevonden is.....In ieder geval niet in een bucket want die bestaan niet op Azure.

[Saph]

Waarschijnlijk wordt een Azure Blob storage bedoeld. Azure heeft namelijk geen buckets, dat is een opslag format van AWS.

[boldg1974]

AWS-bucket....Microsoft Azure opslagbucket...wat is het nu?

[SchizoDuckie]

Beide.
Er stonden AWS keys in een CSV'tje in de public Azure Blob Container.
Ik kan het ook niet simpeler maken

[Reactie gewijzigd door SchizoDuckie op 23 juli 2024 03:26]

[loekf2]

Beetje off topic, maar de naam van Fujitsu als IT provider is mij ook recent bijgebleven door het Post Office schandaal met Toeslagen affaire achtige proporties in de UK.

[Ryen]

Het Post Office Scandal was misschien nog wel erger. Er zijn zelfs mensen onterecht in de gevangenis gezet. Fujitsu heeft heel lang volgehouden dat er niets mis was met hun systemen.

Zo te horen hebben ze nog niet veel geleerd, als het nog steeds moeilijk is om melding te maken van een misstand.

[PsiTweaker]

Off Topic.

Sommigen hebben zelfs uit wanhoop zelfmoord gepleegd ! Zie ook de 'Mr Bates vs The Post Office' mini serie.

[Reactie gewijzigd door PsiTweaker op 23 juli 2024 03:26]

[Erhnam]

Azure maakt gebruik van Storage Accounts met daarin containers. Geen buckets, zoals in het artikel staat.

[vbmot]

Het is Bouquet!

[Rudoli]

Lady of the house speaking

[duke99]

Als iemand die 10 jaar geleden met Fujitsu services gewerkt heeft....ik ben niet verbaasd.
Ze keken sowieso veel te veel of mensen hun papiertjes wel hadden ipv of deze mensen wel echt snapte waar ze mee bezig waren.

[wildhagen]

De gevonden bucket bevatte verder een CSV-bestand met wachtwoorden die uit wachtwoordmanager LastPass zijn gehaald en in platte tekst zijn opgeslagen.

Ik ben zelf ICT-beheerder, maar ik vraag me hier altijd af hoe dit in godsnaam kan. Zo'n CSV-bestand met plaintext wachtwoorden wil je al niet eens in je interne netwerk hebben staan, om het over een public-facing omgeving waar het publiek bij kan nog maar niet te hebben.

En dat (bijna) een jaar lang. Doet er daar niemand audits, worden er geen periodieke checks gedaan?

Kom op jongens, dit is toch geen rocket science, dit is Security les 1, hoofdstuk 1. Basaler dan dit ga je het niet krijgen. Dit kon je in 2000 al niet meer maken, laat staan in 2024...

Hoe kan het dat dit soort dingen dan tóch maar ad infinitum blijven gebeuren? Leert niemand van fouten (van henzelf, danwel van andere organisaties)?

Ik kan er met mijn pet echt niet meer bij dat er soms zó laks met security omgegaan wordt. Fouten maken we allemaal, ondergetekende meegerekend, maar dit is wel een buitencategorie. En léér dan een keer van de fouten, ipv ze steeds te herhalen.

[david-v]

Ooit een seminar gevolgd over security waarbij de spreker letterlijk zei: "de enige veilige plek voor je wachtwoorden is dit (toont portemonnee met een geeltje waarin de wachtwoorden staan)".

Ik heb ook van alles meegemaakt, tot aan excels met wachtwoorden die op een A3 worden uitgeprint en ergens in een open kast te vinden waren.

Blijkbaar weten mensen niet een keyvault te vinden (Azure) en zitten ze nog steeds te spelen met wachtwoord managers ergens op het netwerk. Tja....

[sys64738]

Totdat je portemonnee gestolen wordt.

Er is niks mis met een goede password manager maar tegen die soort domme dingen (plain text passwords in csv) is niets opgewassen.

[david-v]

Totdat je portemonnee gestolen wordt.

precies, nog erger vond ik dat je aan een hele zaal verteld waar jij je wachtwoorden plainttext bewaard

Ik heb vaak met passwordmanagers gewerkt. Die werden gedeeld door groepen mensen. En je raad het al, het wachtwoord van die gemeenschappelijke kluis moet je dus ook ergens bewaren....of Welkom01 (één keer meegemaakt ) .

Daarom ben ik zelf niet echt een voorstander van password managers voor applicaties die een secret nodig hebben. Voor persoonlijke doeleinden is dat uiteraard prima, als je ergens je wachtwoord op moet geven bijvoorbeeld. Maar het bewaren van een token of key of connectionstring enz in een password manager....nee, daar doe ik niet meer aan mee. Alle secrets moeten mi bewaard worden in de kluis en je geeft een proces die een bepaalde secret nodig heeft leestoegang tot die kluis en specifieke secret zodat het nergens anders bewaard wordt. Niet in een applicatie setting, niet in een password manager, CVS bestand of een plaintext excel op het netwerk. Bovendien heb ik al vaker meegemaakt dat één secret op meerdere plekken bewaard werd en dat ze niet synchroon waren, ofwel na een token reset werd maar een deel aangepast en de rest had nog de oude token

Één bron waar de secret veilig staat en daar blijft het bij. In AWS is dat volgens mij de Secrets Manager, KMS & AWS Certificate Manager (ACM).

[kuurtjes]

Wat als je van wachtwoord beheerder wilt omwisselen en je export ze om ze dan terug te importen? Maar je wordt geroepen voor een dringende meeting, of je collega vraagt je voor een koffie pauze. Je kan dat bestand vergeten of zelfs verliezen tussen je andere bestanden. Of het kan gewoon in de tijd dat je AFK bent automatisch gebackupped worden. Er zijn veel zaken waar dit soort dingen fout kunnen gaan, dus ik zie het niet direct iets dat volledige incompetentie aantoont.

Waar ik je wel in kan vinden is dat deze bucket een jaar lang publiekelijk toegankelijk was. Tijdens de "public bucket zoektocht" waar veel beveiligingsonderzoekers en hackers op sprongen zou elk bedrijf toch wel hun buckets nagekeken moeten hebben, en moeten deze processen toch goed aangescherpt geweest zijn...

[Groningerkoek]

Juist omdat er veel fout kan gaan wil je dus nooit of te nimmer een moment dat plaintext wachtwoorden in een omgeving komen die contact heeft met de buitenwereld. Dit moet je zelfs intern niet willen.

[kuurtjes]

Ik bedoel maar dat de ICT dienst daar weinig aan kan doen.

[keejoz]

Tuurlijk wel. Zij beheren toch de wachtwoord managers?!

[kuurtjes]

Daar heb je wel gelijk, normaal gezien moet de organisatie de export functie in LastPass kunnen uitschakelen.

[david-v]

Ze maken gebruik van AWS en Azure, wat is er mis met Secrets Manager , KMS & AWS Certificate Manager (ACM) en Azure Keyvault? Voor secrest, tokens, private keys van SSL's enz DE plek om het te bewaren.

[henkbiertank]

Kun je me vertellen waar je dat op baseert? Ik bedoel met name je laatste zin. Als developer ben ik zo veel mogelijk met security bezig bij elke regel code die ik schrijf. Of het nu te maken heeft met de input van een contactformulier of met mogelijk 'gevoelige' bestanden in een git repo. Maar ook met iets simpels als mijn computer vergrendelen als ik mijn werkplek verlaat. In de 15 jaar die ik nu werk als developer, zie ik vrijwel al mijn collega's hier over nadenken en de juiste stappen nemen. En anders bespreek je dit met elkaar op de juiste manier.

[Joest-J]

Mag ik vragen in welke taal je programmeert?
Ben zeker voorstander van meer aandacht voor security en het toepassen van best practices. Maar ik kies dan ook voor een taal die me daar zoveel mogelijk in ondersteund.

[henkbiertank]

Dat mag je zeker vragen (PHP, JavaScript, TypeScript), maar ik vind dat niet relevant. In elke programeertaal kunnen er fouten gemaakt worden. Daarom schrijf je testen bijvoorbeeld. Het gaat er mij om dat de programmeur weet wat hij/zij doet.

[Joest-J]

Ja, absoluut eens met het laatste. Maar gezien de talen die je gebruikt begrijp ik beter dat je extra waakzaam bent. In die zin is de taal waarin je ontwikkelt wel degelijk relevant.

[david-v]

Bij welke talen heb je twijfels of een developer wel of niet voor security en best practices gaat? ik ben toch wel benieuwd.

[BRAINLESS01]

In mijn beleving zijn het juist de ontwikkelaars die hierin verder gaan dan de rest van het bedrijf (samen met IT natuurlijk). De gemiddelde medewerker heeft geen idee wat het risico is of hoe het werkt, maar de gemiddelde ontwikkelaar wel.

[atthias]

congrats on the find @SchizoDuckie

[SchizoDuckie]

Danku danku

[kodak]

Het artikel stelt dat het contact krijgen wat moeizaam verliep. Zou het inmiddels voor anderen makkelijker zijn om zelfstandig contact met het bedrijf te krijgen?

[SchizoDuckie]

Ik heb sindsdien geen pogingen tot meldingen gedaan aldaar, maar een snelle check leidt tot nog steeds geen security.txt, public vdp of bugbounty programma of zelfs een dedacted pagina op hun site waar je vulns kan melden die niet met een specifiek product te maken hebben.

Ik vermoed het dus niet.

[michielonline]

In Azure heet dit geen bucket, maar een storage account.
Bucket is AWS terminologie.

Beetje slordig jongens.

[SchizoDuckie]

Als we dan echt gaan muggenziften over de terminologie zoals iedereen hieronder in de comments (echt pff):

Het heet een Blob Container.
Onder een Azure "Storage Account" hang je Blob Containers, File Shares, Queues en Tables.

Blob Containers kunnen public zijn, of private, maar dat maakt niet veel uit als je broncode vindt met een complete connection string (met de daarbij behorende AccountKey of SAS token)
Dan heb je ook de mogelijkheid om ook alle onderliggende data te zien, containers aan te maken, te verwijderen, fileshares te maken en te verwijderen etc.

Handige tool hiervoor is
https://azure.microsoft.c.../storage/storage-explorer

[Reactie gewijzigd door SchizoDuckie op 23 juli 2024 03:26]

[chemokar]

Buckets, Azure… volgens mij is dit artikel een beetje te snel geschreven.

[SchizoDuckie]

Azure noemt ze 'blob storage containers', maar voor mij zijn het allemaal storage buckets. Een "cloud drive" waar je meuk in kan dumpen.

[HenkEisDS]

Azure Buckets bestaan inderdaad niet. Iedereen die Bucket leest denkt direct aan Amazon. Sterker nog: als je Azure Buckets googlet is het derde resultaat dit artikel. Echter het bronartikel heeft het ook over "Microsoft Azure storage bucket", dus ik denk niet dat we het de redactie kwalijk kunnen nemen.