Israëlische databeheerder had datalek dat onbekend aantal grote bedrijven trof

Security-onderzoekers hebben drie onbeveiligde Amazon S3-buckets van het Israëlische Attunity gevonden. Het gaat om een TB aan data, waarvan driekwart back-ups van e-mails zijn. Niet alle getroffen bedrijven worden bekendgemaakt, maar Attunity heeft grote klanten.

Op de website van Attunity meldt het bedrijf dat het diensten verleent aan 44 van de Fortune 100 en daarnaast nog meer dan 2000 klanten. Namen die het noemt zijn onder andere Philips, Ford en Mercedes. In het rapport, dat van UpGuard komt, passeert ook Netflix de revue. Attunity migreert en beheert data voor zijn klanten en doet aan analytics.

De back-ups van de e-mail maar ook de overige bestanden bevatten her en der gebruikersnamen en wachtwoorden van administratie-accounts, maar ook facturen, OneDrive-back-ups, specificaties van klantsystemen en persoonsgegevens van medewerkers, inclusief die van Attunity zelf. Waarschijnlijk waren bij die laatste de medewerkersnummers gewoon kopieën van hun social security numbers. Tot slot waren ook klantgegevens en gegevens van bedrijven die handelen met de betrokken bedrijven inbegrepen.

Het lek werd op 13 mei van dit jaar ontdekt door UpGuard en de security-specialisten zochten op 16 mei contact met Attunity. De volgende dag was het lek gedicht. Attunity heeft geen commentaar geleverd over het lek op zijn website of sociale kanalen.

Lees meer

Reacties (37)

Keeper of the Keys
30 juni 2019 14:34

@Mark_88
Kunnen jullie hier wat meer achtergrond over geven voor de niet-Amazon gebruikers onder ons?

Staan buckets standaard open voor de hele wereld of is er hier een grove fout begaan (hoe dan ook een grove fout dat het niet zou zijn veranderd maar is natuurlijk net ietsjes anders dan "het was [redelijk] goed beveiligd en we hebben het uit gezet")?

Hoe word er gezocht etc. misschien een leuk onderwerp voor een achtergrond artikel?

M.Koers
@Keeper of the Keys • 30 juni 2019 14:41

Per default staat de boel dicht: https://aws.amazon.com/pr...nter/secure-s3-resources/

localhost
@M.Koers • 30 juni 2019 15:03

Eerste gedachte onder applicatie ontwikkelaars om snel tot resultaat te komen is echter om alles open te zetten. Het veilig maken gebeurd dan vaak in een later stadium. Of niet.

MrMonkE
@localhost • 30 juni 2019 16:24

Ik denk dat vaak onkunde is.
Dat ze dingen doen die eigenlijk net buiten hun expertise ligt.

localhost
@MrMonkE • 30 juni 2019 16:58

"DevOps en Full Stack Developer" is dus inclusief Operations, Reliability, Risk Assessment en Security.

Webgnome
@localhost • 30 juni 2019 18:46

En dat is ook meteen het probleem van devops. Het gaat vaak goed maar helaas ook fout. Er is een reden dat ooit in de geschiedenis er twee verschillende takken van sport zijn gemaakt.

_eXistenZ_
@Webgnome • 1 juli 2019 08:38

Dan gaan er weer hele andere dingen fout zoals het over de schutting gooien van zaken, elkaar niet goed begrijpen, en twee hele verschillende belangen hebben (stabiliteit versus flexibiliteit) dus geef mij maar elke dag van de week devops. En dan met een team niet louter bestaand uit devvers maar een team gemixt van devvers, opsers, en T-shaped do-it-alls.

Stoelpoot
@Webgnome • 1 juli 2019 10:20

Laten we dit nou niet een probleem van Devops noemen. Als dit de schuld was van DevOps, waar waren dan de veiligheidschecks, tests en pentests die in het gehele proces worden meegenomen? Dit is gewoon een stukje onkunde door de hele ketting heen, ongeacht welke organisatorische structuur werd toegepast.

Yalopa
@Webgnome • 1 juli 2019 06:33

De fout is dan ook dat je niet de juiste mix van mensen bij elkaar zet. Een team met enkel devvers gaat dit tegenkomen.

jozuf
@localhost • 30 juni 2019 16:06

Klopt. Maar merk vaak dat het toch wat efficiënter ontwikkelen is als je het gelijk goed doet.
Zomaar een random voorbeeld is implementeren van CSP Headers. Makkelijker als je dat gelijk aan het begin goed instelt.
En daarnaast als je het gelijk goed opzet kan je het ook niet meer vergeten te veranderen.

[Reactie gewijzigd door jozuf op 30 juni 2019 16:07]

Iblies
@M.Koers • 30 juni 2019 17:07

Per default ja.
Maar ik ga er niet van uit dat ze een standaard pakket hadden gezien clientèle.

Maar aan de andere kant verwacht je ook dat ze dubbel en dwars hun eigen software in de gaten houden en periodiek door externen laat testen.

En daarnaast ben je al fortune-500 toch wel verdomd goedgelovig als je je systemen niet periodiek door externen laat testen.

Er zijn genoeg security-bedrijven die op verschillende niveaus kunnen testen of er verhoogde risico’s zijn. Die kunnen meekijken van binnen, kunnen extern je netwerk scannen, etc, etc. Helaas nog geen gebruik in veel bedrijven, die leunen te veel op de ICT.

supersnathan94
@Iblies • 30 juni 2019 17:37

Die externe bedrijven doen ook niets anders dan een bij elkaar geraapt zootje scripts draaien helaas. Ze kijken niet per se goed naar code en luisteren soms ook niet naar klantvragen voor specifieke issues die ze graag gecheckt hebben. Zo kregen wij de aanbevling om naar parameter sanitatie te kijken omdat we waarschijnlijk vulnerable waren voor SQL injection. Helaas hadden we van tevoren nog even gemeld dat we niks met SQL doen omdat we een triplestore gebruiken en we methodieken hadden ontworpen om parametersanitatie voor SPARQL queries te doen. Jammer dat er dan vervolgens vanuit het programma ineens vragen worden gesteld over die resultaten (aangezien die daar ook belegd worden) aangezien het dus nergens op slaat.

ViperXL
@Keeper of the Keys • 30 juni 2019 14:56

Het is ongelofelijk wat sommige "systeembeheerder" doen. Een klassiek voorbeeld die ik tot de dag van vandaag nog zie is een uitgeschakelde firewall op een server omdat men toch wel een edge-firewall heeft en het "te lastig" is om een specifieke service toe te laten in de firewall.

localhost
@ViperXL • 30 juni 2019 15:01

Het is Cloud - Dus de applicatie ontwikkelaar bepaald hoe hij/zij de Cloud dienst gebruikt. Als het design is dat een opslag locatie openstaat, dan staat die dus open. Daar komt geen beheerder aan te pas.

ViperXL
@localhost • 30 juni 2019 15:41

De bucket is standaard beveiligd dus hierbij hebben ze het verandert. Komt dus wel iemand aan te pas.

localhost
@ViperXL • 30 juni 2019 17:03

En omdat het Cloud is, is alles SelfService binnen het team, lees: DevOps en Full Stack. Dus waarschijnlijk dezelfde persoon of team die de bucket aangemaakt heeft. Je moet in de Cloud-wereld dus gewoon end-to-end bewust zijn wat je aan het doen bent en verantwoordelijkheid nemen. Een nieuwe Feature in een applicatie wordt dus opgeleverd inclusief Operations, Reliability, Risk Assessment en Security.

fantafriday
@localhost • 30 juni 2019 20:16

Dat je in de cloud de developer de sleutel geeft van je productie omgeving is natuurlijk puur een aannemen die gemaakt wordt. Ditzelfde kan on-premise ook gedaan worden of juist niet, niks cloud specifieks.

NBK
@ViperXL • 30 juni 2019 21:47

Ik heb persoonlijk meer vertrouwen in een hardwarematige firewall.
Software firewall's zijn vanaf het systeem te configgen en dus eventueel met malware ook aan te passen. Tuurlijk heb je extra bevestigingen nodig van de admin maar dat is in het verleden nooit zo moeilijk gebleken.
Om nog maar te zwijgen wat de impact kan zijn als er in de firewall van wereldwijd het meest gebruikte OS een lek blijkt te zitten. Hardware is wat dat betreft wat zeldzamer dus zal de impact automatisch kleiner zijn.

[Reactie gewijzigd door NBK op 30 juni 2019 21:48]

ViperXL
@NBK • 30 juni 2019 22:10

Klopt maar multi-layer beveiliging geldt ook bij firewalls, maakt niet uit of software of hardware is natuurlijk. Wat als er een config fout of exploit van regels uitgevoerd kan worden, dan is je volgende laag een extra bescherming. Het uitzetten van een firewall beveiliging op een machine is net zo slecht als het uitzetten van de beveiliging van een S3 bucket. Daar doelde ik meer op.

ctrl-tab
@ViperXL • 1 juli 2019 08:54

Ook s3 heeft meerdere lagen van security.
Eerst moet je public access aanzetten, dan nog moet je bucket policy aanpassen

De vraag is hoeveel je aan meerdere lagen hebt, als al die lagen vanuit dezelfde automation scripts wordt aangestuurd. Een vinkje heeft dan nog steeds effect op meerdere lagen.
Dat geldt ook voor de 'hardware' en 'software' firewalls (ik ga er vanuit dat het geautomatiseerd is)

Raymond Deen
@ctrl-tab • 1 juli 2019 09:50

Dat is het koord waarop die cloud aanbieders balanceren; je wilt het dmv scripts aan kunnen passen als klant zodat je het elke keer exact hetzelfde doet, maar als aanbieder heb je liever niet dat dat gedaan wordt, juist vanwege de redenen van veiligheid.

ctrl-tab
@Raymond Deen • 1 juli 2019 09:53

Ik denk dat het andersom is.

Het probleem van traditionele IT is dat dingen vaak niet geautomatiseerd zijn.
Ook al kan je met een script fouten met verstrekkende gevolgen maken, dat is nog altijd beter dan elke keer met de hand diezelfde zaken uitvoeren.

Ik denk dat cloudomgevingen je (zeker vandaag de dag) alle tools in handen geven om compliance te checken. Dit in tegenstelling tot old-school it omgeivngen waar je dat soort zaken zelf in elkaar moet klussen.

Raymond Deen
@ctrl-tab • 1 juli 2019 10:25

Zou je gelijk geven als de s3 buckets standaard open zouden staan, maar het is juist andersom. Er zijn meerdere barrières standaard aangezet om ze niet publiek toegankelijk te maken en die zijn hier stuk voor stuk uitgezet.
Kan handmatig zijn, maar wordt vaak geautomatiseerd omdat je zo snel iets vergeet te doen en dan werkt er onverwacht iets niet.

Loggedinasroot
@Keeper of the Keys • 30 juni 2019 15:09

Er wordt best vaak open buckets gevonden. Ook buckets met terabytes aan top secret info van het US leger en de NSA. Er is al wel wat over geschreven.

A security researcher revealed today he found three misconfigured Amazon S3 servers belonging to the US Department of Defense (DOD) containing 1.8 billion social media and forum posts made by users from all over the world, including many by Americans.

Link

Ten days after an Amazon S3 server exposed data from the US Army's CENTCOM and PACOM divisions, security researchers have identified another S3 server instance that leaked files from INSCOM, a joint US Army and NSA agency tasked with conducting intelligence, security, and information operations.

Link

hier nog wat meer:
https://github.com/nagwww/s3-leaks

Skywalker27
@Keeper of the Keys • 1 juli 2019 10:58

Via grayhatwarfare kan je de S3 bucket doorzoeken

S3 buckets stonden een tijdje terug standaard open en op public. Dit hebben ze kort geleden aangepast. Echter staan er dus nog heel veel open en op public.

https://threatpost.com/ex...figured-leak-data/126826/

mutley69
30 juni 2019 16:31

Ik voer momenteel een staalharde discussie met een leverancier van digitaliseersoftware. Run alles als admin en zet de firewall af - dan werkt dat prima. Dat is gewoon een bewijs van brakke software - wie verstandig is - zet het dan op een lopen.

DJMaze
@mutley69 • 1 juli 2019 07:49

Doe dat dan ook

Ach, hier is het andersom. Ben software leverancier waarbij de software credit cards verwerkt.
Zie ik opeens bij de klant OneDrive en DropBox ingesteld staan als "backup" voor de database.
Gelukkig zijn de CC's encrypted in de database, maar de klant kreeg wel een dikke vette waarschuwing.

mduijm

30 juni 2019 18:45

Als IT security specialist roep ik alweer voor een paar jaar dat dit soort problemen kunnen ontstaan en dat hiervoor tools zijn die dit proactief kunnen monitoren en zelfs automatisch de share er weer af kunnen halen. Helaas denken de meeste mensen nog steeds. Dit gebeurt me niet.

Helaas voor deze club, maar hoop dat meer mensen gaan nadenken dat security team in het bedrijf de ‘ops’ teams beter moeten gaan monitoren.

Gebruikers zelf maken ook dit soort fouten. Maar dan meer in OneDrive / Box etc. Ook daar kan je bestanden delen met de buitenwereld.

xbeam

@mduijm • 30 juni 2019 22:58

En daar zit precies het risico.

Ik betrapte me er laatst zelf op dat ik dus document gedeeld had met tijdelijke collega’s van kijk er even naar en daarna de share vergeten, maar zelf en die mensen zijn inmiddels ook weer werkzaam bij andere bedrijven.

Vergeten shares kan iedereen overkomen

[Reactie gewijzigd door xbeam op 30 juni 2019 22:59]

Raymond Deen
@xbeam • 1 juli 2019 09:56

Share die alleen werkt met bedrijfslogin is niet perse een probleem; je hoeft alleen de accounts maar uit te zetten wanneer iemand uit dienst gaat.
Zie vaak zat gebeuren dat dit niet zo goed is geregeld met gelukkig bijna nooit problemen, maar je zal er maar een wrokkig persoon tussen hebben zitten...

Slonzo
30 juni 2019 14:35

Als je veel grote bedrijven bedrijven in je portfolio hebt (én hun data), word je automatisch ook een interessant doelwit... Ben benieuwd of dit gewoon zal overwaaien, of dat de schadeclaims het eindpunt worden voor Attunity. Het nadeel aan rijke klanten hebben, is dat diezelfde bedrijven natuurlijk ook erg veel juridisch budget en kennis hebben om tegen jou te gebruiken als je de mist in gaat...

[Reactie gewijzigd door Slonzo op 30 juni 2019 14:36]

stefan70
30 juni 2019 14:48

Oorspronkelijke bericht was nog meer click bait.

De beheerder van de databases heeft serieuze fouten gemaakt. Het had even goed op Azure of GC of zelfs on-prem kunnen gebeuren.

Op zo'n grote schaal dit soort fouten maken kan/mag niet.

mae-t.net
@BikkelZ • 30 juni 2019 22:20

Logingegevens? Data van de concurrent inzien? Ik vind dat wel spannend. Wat vind jij spannend?

Trouwens, weet jij wat dat bedrijf precies doet? Toch eerst eens rondkijken.

[Reactie gewijzigd door mae-t.net op 30 juni 2019 22:22]

xbeam

@Tyrian • 30 juni 2019 23:05

Ja, maar een vpsje kost niet duur en 2min werk. Alleen al de systeembeheerder of netwerkbeheerder mailen voor een vmtje duurt langer

ctrl-tab
@xbeam • 1 juli 2019 08:57

Veel (met name grote-) bedrijven falen op dit vlak inderdaad.
Te veel proces en te veel traditionele it'ers die nog steeds denken dat ze de koning zijn.

Ondertussen ergert het hele bedrijf zich aan de arrogantie en slowness en zoekt alternatieven (shadow it als gevolg).
Een goed balans van vrijheid en compliancy is een van de belangrijkste dingen in het tijdperk dat iedereen IT boer kan spelen. Genoeg vrijheid zodat mensen kunnen doen wat ze willen, maar wel met genoeg handvaten om je veiligheid op orde te houden.

Op dit item kan niet meer gereageerd worden.

Israëlische databeheerder had datalek dat onbekend aantal grote bedrijven trof

Lees meer

Reacties (37)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden