Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

OneLogin-datalek was gevolg van gestolen AWS-gegevens

Door , 28 reacties, submitter: Nees

Authenticatiedienst OneLogin heeft bekendgemaakt hoe een onbekende toegang heeft weten te krijgen tot de gegevens van klanten die gebruikmaken van zijn Amerikaanse datacenters. De aanvaller was in staat de OneLogin-infrastructuur binnen te dringen met gestolen AWS-sleutels.

Datalekken, botnets en encryptieOp zijn eigen website schrijft OneLogin dat de aanvaller daarmee toegang had tot de Amazon Web Services-api via een tussenliggende host. Dit zou om twee uur 's ochtends lokale tijd zijn gebeurd. Via de api was de aanvaller vervolgens in staat om de infrastructuur van OneLogin te verkennen. Ongeveer zeven uur later detecteerde het bedrijf dat er iets niet klopte in de database en blokkeerde het de betreffende sleutels. Hoewel OneLogin zijn gegevens versleutelt, is het niet uit te sluiten dat de aanvaller in staat is om bestanden van encryptie te ontdoen.

Donderdag meldde het bedrijf dat er onbevoegde toegang tot klantgegevens had plaatsgevonden. Tegelijkertijd was op een supportpagina, die zich achter een login bevond, te lezen dat er meer aan de hand was. Daar meldde het Amerikaanse bedrijf: "Alle klanten die gebruikmaken van onze Amerikaanse datacenters zijn getroffen. Klantgegevens zijn gestolen, inclusief de mogelijkheid om versleutelde gegevens te ontsleutelen." De mededeling was vergezeld van een groot aantal aanbevelingen aan klanten, bijvoorbeeld om opnieuw tokens aan te maken en wachtwoorden opnieuw in te stellen.

Reacties (28)

Wijzig sortering
Dat verklaart dus waarom een of ander Chinees IP op mijn account heeft ingelogd. Heb direct het wachtwoord gewijzigd en 2-stap verificatie aangezet.

Edit: Heb er dus geen gevoelige/uberhaupt geen data op staan. Die staan enkel op mijn fysieke HDD's en in iCloud :)

[Reactie gewijzigd door Nervoize op 3 juni 2017 04:39]

Met respect, als je je zeer gevoelige data aan een cloudservice toevertrouwd en dan niet two-step gebruikt maak je jezelf erg kwetsbaar.
De fout begint imo al met toevertrouwen aan een commerciële 'cloudservice'

Want heel het idee om gevoelige data te vermengen met de gevoelige data van zoveel mogelijk anderen levert schaalvoordelen.. ja, voor de hackers 8)7
Ok, dus jij heb een datacentrum dat volledig eigendom is van jou, waarvan alle medewerkers al jaren in dienst zijn en gescreent worden. En waar je continu de laatste patches op alle routers, switches, firewalls, management consoles, domotica en servers hebt draaien. In meerdere regio's.
En je hebt altijd voldoende capactiteit en bemensing. En altijd je security top-knotch en er gaan nooit dingen anders dan geplant.

Knap. Ik ben wel benieuwd hoe je dan ook zelf je backbone hebt aangegd, een eigen certificaat autboriteit hebt etc.

Geen idee waarom je van mening bent dat een gespecialieerd bedrijf met een enorm capitaal risico's minder goed kan inschatten en minder snel kan mitigeren dan dat jij dat zou kunnen.

Ik zie ik de praktijk dat als ik een update vraag aan AWS dat ze die voor alle klanten wereldwijd binnen een paar dagen doorvoeren. Bij interne IT organisaties zie ik niet vaak dat een update verzoek binnen een paar dagen geaccodeerd is en ook nog is doorgevoerd op alle servers. Wellicht is mijn ervaring anders dan die van jou en heb jij intern de mogelijkheid om binnen een uur na een update verzoek alle duizenden systemen te updaten, zonder down time en op elk moment van de dag/nacht.

[Reactie gewijzigd door djwice op 3 juni 2017 13:30]

As a matter of fact antwoord op je eerste allinea volmondig JA. Die bedrijven zijn er wel degelijk ja. Zelfs op de tweede allinea kan ik Ja zeggen. En op je laatste allinea is het antwoord: typisch een "IaaS -> heb ik nu on premise maar ik wil IaaS -> in de publieke cloud" zonder te beseffen dat dit een volledig andere architectuur vereist. Resilliancy is het toverwooord. Als je in één regio draait dan is dat onvoldoende. Als de update wordt doorgevoerd in die regio en het gaat fout dan ga je nat. Updates worden nooit in alle regios tegelijk doorgevoerd. Als je dus resilliant infrastructuren ontwerpt over verschillende regios dan kan je je daar wel tegen wapenen ... en dan ... is de publieke cloud ineens helemaal niet zo intressant meer want dat kost veel veel meer centjes. In mijn optiek is er voor een bedrijf maar één legitieme reden zijn om naar de publiekle cloud te gaan en dat is een gedegen IaaS -> PaaS -> SaaS strategie. Door kakken op IaaS is daar veel te duur.

P.S. ik snap werkelijk niet wat mensen bezielt hier een -1 op te geven. Je kan het er wellicht niet mee eens zijn maar het is minimaal on-topic zeker niet ongwenst. Kom op zeg.

[Reactie gewijzigd door toet-toet op 4 juni 2017 13:50]

Waar is FaaS in je scenario?

Het lijkt mij niet een slim scenario om lift en shift als eerste stap te doen. Is meestal niet kosten effectief. Net als 'as-is-over'.

Vaak selecteren bedrijven een SaaS die eigenlijk gewoon hosted monoliet is. Dus zelfde probleem als voorheen, alleen dan met een nog zwaardere lock-in.
Veel SaaS is zelfs statefull, dus niet gebouwd voor Cloud.

In veel gevallen heeft een SaaS geen CI/CD voor hun eigen releases.

Wil je een modulaire architectuur, dan moet SaaS moet net zo groot zijn als een feature die je zou bouwen.

[Reactie gewijzigd door djwice op 4 juni 2017 13:04]

FaaS is niet meer dan een varriant op PaaS of een onderdeel van dus die heb ik gemakshalve overgeslagen.

Ik heb heb het toch niet over lift en shift of as is over? Ik zeg alleen als je landschap on premise nog sterk op IaaS is gericht en je dit ook in de cloud gaat opzetten dat dit wel eens een heel duur verhaal kan worden. Dus zeg ik hetzelfde als wat jij zegt. Ik zeg dat je als bedrijf de ingredienten klaar moet hebben (strategie) om wellicht minimaal met IaaS in de publieke cloud te starten en goed moet kijken wat naar PaaS / SaaS kan of snel naartoe moet. En of het dan statefull of stateless moet zijn er zijn ook veel stateless initiatieven/voorbeelden te geven.

Verder had ik een opmerking over jouw verbazing van het update beleid van amazon. De hele opzet is anders. De architectuur vereist rislliancy. Als je dezelfde infrastructuur behoudt of ontwerpt zoals deze on premise was dan zijn er inderdaad zaken zoals je schetst, het doorvoeren van updates nu veel makkelijker geworden of het lijkt rigoureuzer. Niet zo verbazingwekkend als dat juist 1 van de key principes zijn van cloud namelijk "Agile" zijn. Zoals al eerder gezegd zul je je nieuwe infra daartegen moeten wapenen door slimme update policies te bepalen controles/monitoring in te bouwen en evt snapshots activeren als de functies niet meer online komen na de updates. En dat was mijn punt, al deze (extra) controles en / of / met cloud CI's die je nodig hebt zijn kosten verhogend en een nadeel in de cloud. IMO een onderschat probleem.
Wat ik zie is dat SaaS juist kosten verhogend is en CI/CD juist zorgd voor versnelling en kosten reductie.

De SaaS die niet CI/CD voorbereidt zijn zorgen voor extreme kosten.

Maar FaaS zorgd er juist voor dat we 40 keer per dag live gaan incl. automatische tests. Waar een jaar geleden het testen zelf nog 4 dagen tijd kostte.
En de hosting kosten zijn factor 10 gedaald. En time to market met factor 4.

Ik zie FaaS als een meer volwassen stap dan SaaS. PaaS in het algemeen niet (op AWS vergelijk BeanStalk +ELB met Lambda+API Gateway of met Cloudfront+Lambda@Edge).

[Reactie gewijzigd door djwice op 4 juni 2017 15:23]

'Zeer gevoelige data' is natuurlijk subjectief. Wellicht vind ik mijn medische of financiële gegevens zeer gevoelig. Jij denkt daar zo te lezen anders over. Prima, maar dat maakt jouw mening geen feit.

Het is wat anders als we het hebben over objectieve labels. Staatsgeheim, etcetera.
Mijn god, wat een vreemde aannames doe je. Ja, er zijn heel veel mensen op deze aarde en de mensen an sich zijn voor een hacker waarschijnlijk niet interessant, maar ben je werkelijk zo naïef om te geloven dat gevoelige data over die personen niets waard is?

Medische data, zou een verzekeraar dat niet interessant vinden? Bijvoorbeeld iemand uitsluiten voor een verzekering op basis van zijn medisch dossier? (In Nederland is dat streng gereguleerd, maar genoeg landen waar een verzekeraar zijn gang kan gaan.)

Of financiële gegevens? Wat dacht je van kredietbeoordelaars? De belastingdienst? Die laatste heeft wel vaker informatie uit dubieuze bronnen gebruikt om zwartspaarders op te sporen.

Los wat je hier ethisch van vindt, die data is geld waard en het is gevoelige data omdat die informatie in handen van een verkeerde partij ingrijpende gevolgen kan hebben voor iemands leven. En misschien heb jij een hekel aan Mien Kampstra uit Schubekutteveen, maar het lijkt mij wel zo aardig als ze nog gewoon een zorgverzekering en telefoonabonnement kan nemen, en niet wordt geweigerd omdat een hacker haar gegevens heeft doorverkocht.
JIJ vind jouw medische gegevens zeer gevoelig. De rest van de wereld niet. Dat maakt de gevoeligheid van die gegevens 1 gedeeld door 7 miljard.
En dat bepaal jij? Maak er maar 2 van. Van alle gevoelige gegevens staan medische gegevens erg hoog op mijn lijstje.
Er zijn gegevens die ik uit privacyoverwegingen liever geheim houdt, die voor mij gevoelig zijn, maar 'in the grand scheme of things' ben ik een zeer oninteressant stukje.
Het punt is dat je niet weet hoe interessant je bent. Daarbij ben je dat later misschien wel. Heel veel mensen beoordelen je op een label, nog voordat je ze ontmoet hebt. Ben je naar een psycholoog geweest? Dan zal er wel wat mis zijn. Een vorm van autisme? Tja die mensen kunnen niet eens voor zichzelf zorgen, allemaal rain man types. Beetje jammer als je hogerop wil komen en iemand dergelijke gegevens tegen je wilt gebruiken. Waar rook is, is vuur toch?

Er zijn heel veel situaties te bedenken waarom dergelijke gegevens wel belangrijk zijn. Leuk dat je het vergelijkt met alle gegevens van de wereld, waarin de mijne totaal niet interessant lijken. Maar dat weet je niet en ik vind mijn gegevens wel belangrijk. Ook al is het niet interessant, niemand hoeft deze gegevens te zien.
In een zeker licht ben ik het wel eens met Tronald Dump.

Er is meer dan gewoon "gevoeldige informatie". Je hebt allerhande varianten hierop. Bvb privacy, gevoelig, gevaarlijk, interessant,...

Laten we als voorbeeld dé cliche der tijden nemen. Een vrouw haar leeftijd. Dit is voor haar vaak het equivalent van een staatsgeheim.
Maar als een hacker ooit zegt: stort me 10K of ik zet het online, dan zegt de vrouw sowieso "euh, ok, doe maar...".
De firma die beschikte over de gegevens moet er alles aan doen om het geheim te houden, maar op zich is de belangrijkheid van de gegevens verwaarloosbaar. Geen hacker die er ook moeite zou voor doen in het licht van de gegevens, eerder in het licht van "kan ik de firma hacken".

Als daarentegen de lanceercodes van nucleaire raketten gestolen worden via een hacking-actie (als dat al mogelijk zou zijn, maar je snapt waar ik heen wil), dan is dat wél een issue en zal de hacker niet met een miezerige 10K beginnen. Waarom? omdat het erg gevoelige en belangrijke gegevens zijn die impact hebben op veel.

Dus het feit dat je alle gegevens over 1 kam moet scheren ben ik het niet mee eens. Maar dat een firma "security" serieus moet nemen, dat vind ik ook wel. Je zou denken dat firma's het wel leren in deze tijd...

Overigens vond ik het treffend dat de hack om 2u plaats vond en de ontdekking 7u later. Juist om 9u als de werkdag begint, dan wordt het gemerkt... hmm....
Ik ben het ook wel een beetje eens met Tronald. Mensen schreeuwen moord en brand over informatie die zij belangrijk vinden maar zetten wel vervolgens hun hebben en houden op facebook. Ik denk dat we inderdaad de informatie gedegen moeten onderwerpen aan een weging en moeten uitkijken dat we niet te ver hierin doorslaan.n En dan kom je idd uit bij de vraag wie bepaald dit?
Mag ik al je medische gegevens zien en je browser history (ook incognito)?
Stel je voor dat je de gegevens hebt. Yes, victory. Wat nu?
Het ergste wat je kan doen is het delen met het hele internet. 99.9% gaat het niet eens lezen omdat het niet interessant is. De rest zijn thrill-seekers.

Effect: eigenlijk niets...

Hij zegt ook niet dat alles publiek beschikbaar moet zijn hé, gewoon dat de ene gegevens belangrijker zijn als de andere.

Stel je nu voor dat je beschikt over zijn bank codes en logingegevens van aandeelsites etc.
Dan ga je het niet delen, maar ga je hem kaalplukken waar mogelijk.

Effect: veel zwaarder.
Medische gegevens zijn het meeste waard op darknet. Er zal wel een reden voor zijn.....

Source: CTO van ziekenhuis in Duitsland die niet lang geleden bezoek heeft gehad van hackers........
mduijm, niet dat ik je niet geloof of zo, maar een "bron" is een locatie waar je iets gevonden hebt, niet een gebeurtenis.
Kan je de url even posten waar je gelezen hebt dat medische gegevens het meeste waarde heeft op darknet?
https://www.google.nl/amp...ecords-heres-why.amp.html

En deze is beter:
https://www.brookings.edu.../Patient-Privacy504v3.pdf

Leuk stukje om te lezen hierover.

[Reactie gewijzigd door mduijm op 4 juni 2017 00:04]

Snap ik, maar ik heb liever dat iemand 100¤ van mijn rekening haalt dan dat mijn familie en vrienden mijn browsergeschiedenis hebben.
Tja, voor mij als persoon zijn mijn persoonsgegevens gevoelige data als die in verkeerde handen liggen.

Voor jou en het wereldtoneel wellicht de 0-days op 4G masten en de wormen die van telefoon naar telefoon hoppen.

Context dus. Ik vind die laatste niet zeer gevoelig, het is maar code en zegt niets over welk levend wezen dan ook, nog hoe die samen hangen of acteren. De impact die je er mee kunt op wereldschaal, die is groot.
Had geen data opgeslagen bij hun. Geen stres :P
Hoe kan deze api key en zijn secret gestolen zijn?

Dit zijn key die wij gebruiken voor sommige script binnen onze infra op AWS. Nooit maar dan ook nooit op een device buiten onze infra op AWS.

Voor het werken vanaf onze workstations, hebben wij gewoon accounts met MFA.
Nou heel simpel... Dit is een mogelijkheid eh geen bevestiging maar toch... Veel bedrijven stoten hun zogenaamde simpele taken af aan 3de partijen omdat het management geld wilt besparen. Dus waar eerst intern personeel het 'simpele' werk deed, word dat nu gedaan door externe partijen zoals uit India bv. Daardoor krijg je minder grip op je organisatie. Zeker als het bedrijf heel groot is die dit besluit heeft genomen.

Zo zijn ook gegevens van NSA via derde partijen gestolen..

[Reactie gewijzigd door innerchild op 2 juni 2017 23:20]

Maar ook externe kunnen gewoon met accounts en MFA werken.
Er is geen reden om een api key met zoveel rechten, buiten je aws platform te hebben.
Hoe achterlijk ben je als authenticatiedienst om AWS sleutels uit te laten lekken en het niet te zien via de Audit log, maar pas wanneer ze in je database zitten.

Leek er ook op dat die AWS sleutel teveel rechten had.

[Reactie gewijzigd door Cilph op 2 juni 2017 19:32]

Hoe achterlijk ben je als authenticatiedienst om AWS sleutels uit te laten lekken en het niet te zien via de Audit log, maar pas wanneer ze in je database zitten.
Je hebt geen enkel idee HOE dat is gebeurt. Als dat bijvoorbeeld door een nog onbekend lek is gebeurt valt de databasebeheerder niets aan te wrijven. Als jij kan garanderen dat dit nooit zou gebeuren als jij de databasebeheerder bent kan je een absoluut fortuin verdienen.

Of je roeptoetert zonder de feiten te kennen.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*