Datalek in Scrum.org-website legt gebruikersgegevens bloot - update

Via een lek in het systeem van Scrum.org zijn mogelijk de namen, e-mailadressen, versleutelde wachtwoorden, de decryptiesleutel, certificeringen en de bijbehorende testscores buitgemaakt. Dat meldt de organisatie in een e-mail aan gebruikers.

In de e-mail meldt de organisatie dat er op 26 mei 2016 problemen met de uitgaande mailserver werden ontdekt. Na onderzoek bleek dat e-mails die normaal verstuurd moeten worden met tijdelijke wachtwoorden, niet verstuurd werden, wat veroorzaakt werd door gewijzigde instellingen. Daarnaast werd er een nieuw administrator-account ontdekt.

Vervolgens liet een softwarebedrijf waarmee Scrum.org samenwerkt weten dat zijn software een nieuw ontdekte kwetsbaarheid bij zich droeg die vergelijkbare problemen veroorzaakte als die op de servers van Scrum.org, wat tot het direct oplossen van de kwetsbaarheid leidde.

Ondanks dat is de kans groot dat een grote hoeveelheid persoonlijke data is gestolen, inclusief een eventueel geüploade profielfoto. Het is nog niet duidelijk of de informatie inderdaad buitgemaakt is. Ook heeft de organisatie nog geen aanwijzingen gekregen waaruit blijkt dat de informatie is gebruikt door anderen. Scrum.org zegt dat het geen informatie rond financiële transacties opslaat op zijn eigen servers, waardoor dergelijke informatie niet gecompromitteerd kan zijn.

Scrum.org heeft alle gebruikerswachtwoorden gereset en adviseert gebruikers die hetzelfde wachtwoord elders gebruiken, dit ook te veranderen.

Update 2 juni: via een gebruiker van Scrum.org kregen we het antwoord dat Scrum.org geeft op de vraag om meer informatie. Er wordt weinig nieuwe informatie gegeven, behalve dat de decryptiesleutel van de wachtwoorden ook bemachtigd is en dat de wachtwoorden wel gesalt waren, maar niet gehasht. Een hashfunctie implementeren zou nog niet direct kunnen omdat dit wijzigingen in bepaalde interfaces zou vereisen. De hele reactie is te vinden op het The daily wtf-forum.

Reacties (67)

[MoBi]

Er is gebruik gemaakt van het lek wat op deze website word besproken.

[bartje]

ben ik de enige die het opvallend vind dat ze gebruik maken van een decryptiesleutel voor wachtwoorden?
Wachtwoorden dienen altijd opgeslagen te worden met one way encryption.

[mpkossen]

Nee, dat ben je niet.

Maar ik weet niet precies wat er bedoeld wordt met 'decryptiesleutel'. Ik ken tal van voorbeelden waar bij voorbeeld de username dient als salt voor het hashen van wachtwoorden. In dat geval moeten wachtwoorden alsnog gedecrypt worden. Mocht het echt daadwerkelijk de decryptiesleutel zijn dan zou ik bijna willen zeggen dat het grove nalatigheid danwel incompetentie is van de software-leverancier.

[pizzafried]

Euh... Hashen is one way. Zelfs met salt niet te "decrypten". wel makkelijker misschien als je gericht 1 account wil hacken, maar onmogelijk op grootschalig niveau. Je moet een ingegeven wachtwoord hashen met de salt die je al hebt en dan de uitkomst vergelijken met de opgeslagen hash.

[mpkossen]

Ik doelde op de mogelijkheid van spraakverwarring, dat decryption key verward werd met een hash salt.

[anargeek]

Wordt er niet met "decryptiesleutel" bedoeld hoe er gehasht wordt? Dus stel je hasht als volgt: md5(useremail+userpassword) dan is ieder wachtwoord uniek gesalt met het gebruikersemailadres.
Maar password-crackers bieden vaak de optie om een hash te bruteforcen door op te geven hoe de hash is opgebouwd (dit is vaak in broncode terug te vinden, als je die kan inzien). Heb je dus een lijst van emails en gehashte wachtwoorden, dan kan je de cracker instellen dat deze bruteforced op de manier md5(veld1+<hier de bruteforce gokken>). Op die manier kost het wat meer tijd om te kraken (want rainbowtables zijn nutteloos) maar uiteindelijk is het nog steeds vrij simpel

[Reactie gewijzigd door anargeek op 24 juli 2024 00:39]

[EngineerCoding]

Trouwens een slechte zaak als ze werkelijk het mail adres gebruiken voor de salt. Normaliter moet de salt een random string die niet af te leiden valt uit de data waarmee iemand zich registreert.

[Firefly III]

Daar stond ik ook erg van te kijken. Uit het oorspronkelijke mailtje:

While we continue to investigate the matter, we have determined that user’s names, email addresses, encrypted passwords, the password decryption key, and completed certifications and their associated test scores may have been compromised, but at this time we are not able to confirm that any of these items were actually taken, nor is there any evidence that any of this information was used by an unauthorized individual.

Dikgedrukt door mij.

Ik hoop en vrees dat hier iemand in de war is met de "salt".

[Verwijderd]

Nope, ik had het ook al opgemerkt. De mensen die het portal geschreven hadden hebben geen benul van security of cryptologie.

Daarom is het ook niet zo verwonderlijk dat de site gehackt is. De rest van de programmering zal ook wel kul zijn.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 00:39]

[Willaaam]

Mijn gegevens wat doen ze?! Stelletje scrumbags! Zo zie je maar weer, zelfs een platform voor coders bevat bugs.

Laat het een wederom een les zijn, gebruik KeePass en vul overal random wachtwoorden in, dan is je persoonlijke data nog steeds op straat, maar hoef je niet het halve web af om al je andere wachtwoorden te veranderen.

[armageddon_2k1]

Scrum is een projectmanagement stijl en geen coder platform zover ik weet.

[Wolfos]

Op scrum.org staat heel groot op de voorpagina "Improving the Profession of Software Development", dus het is wel de primaire focus.

[CEx]

Het beroep is meer dan alleen coden.
Scrum.org is een organisatie die zich inzet voor de Scrum methode, inclusief opleidingen, trainingen en certificeringen. Hieronder vallen ook de rollen die geen letter hoeven te kunnen coderen.

Probeer maar wat source code terug te vinden op de site...

[Willaaam]

True, maar scrum is als eerste associatie bij mij in ieder geval verbonden met het managen van softwareprojecten

[Verwijderd]

Scrum gaat om het opleveren van software, niet over security, wat vaak een ondergeschoven kindje is.

[moozzuzz]

Maar het is dus geen koekjesbakker, waarvan het vergefelijk is dat ze geen jota van IT-beveiliging kennen. Dat professionals in de software-wereld security fouten maken vind ik wel een zware professionele fout.

[Verwijderd]

Cryptografie en software ontwikkeling zijn twee heel verschillende disciplines. Niet iedere doorsnee sofrtware ontwikkelaar weet daar wat van af.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 00:39]

[moozzuzz]

Maar elke doorsnee software ontwikkelaar weet wél dat security belangrijk is (en zou daarom ook makkelijk de nodige specialisten kunnen aantrekken).

[Carda]

Ahum, doorsnee ontwikkelaar weet vrij weinig van security. Dat is maar een klein deel van waar ze mee te maken hebben.

Hoe vaak ik wel niet tegen kom dat partijen bijvoorbeeld zonder SSL/SSH verbindingen opzetten en niet eens weten wat een private key is dan vraag ik mij af hoe het gesteld is met andere organisaties

[nils83]

Scrum gaat om het opleveren van software, niet over security, wat vaak een ondergeschoven kindje is.

Scrum wordt vaak gebruikt voor het opleveren van software projecten, maar het is fout om te zeggen dat Scrum gaat om het opleveren van software.

De Scrum Alliance omschrijft het zo:

Agile methods like Scrum can be applied to any project effort to deliver improved results in ever evolving business environments, and do so in a manner that demonstrates visible, predictable progress toward today’s most important business priorities.

Ik ben zelf betrokken geweest bij een project waar het succesvol gebruikt werd voor hoog technologische elektronische toestellen.

[Miss_80]

Kreeg de mail gisteren ook binnen. Bij het bezoeken van de website wordt je gedwongen om je wachtwoord te wijzigen. Ik kon in ieder geval niet meer aanloggen met mijn oude gegevens en moest deze laten resetten. Ik heb even snel gekeken naar mijn account, het diploma voor scrummaster en de score (had het certificaat destijds al gedownload) en kan vooralsnog geen verschillen ontdekken. Denk dat er met mijn account in ieder geval niets is gebeurd.

Vond het wel een nette mail. Goed uitgelegd wat er was gebeurd. Tevens netjes toegelicht wat de mogelijke consequenties waren, wat er mogelijk allemaal aangepast kan / is maar ook dat ze niet duidelijk hebben of er daadwerkelijk wijzigingen hebben plaatsgevonden. Better save then sorry.... iedereen MOET zijn inloggegevens aanpassen. Prima, kleine moeite

[Verwijderd]

Volgens mij kunnen ze ook niet zoveel met de gegevens. Er staat geen privacy gevoelige informatie in zoals je credit card of BSN. Ik vraag me dan ook af wat ze met de informatie moeten, behalve dan misschien af en toe een diplomaatje aanpassen op de site.

[Stoelpoot]

emailadres + wachtwoord (encrypted + key ipv hashed + salt zoals zou moeten). Je emailadres gebruik je waarschijnlijk op minstens 1 extra site om in te loggen. Misschien je wachtwoord ook wel. IT professional? Dan zal je ook bijvoorbeeld accounts hebben op Stackoverflow, misschien op LinkedIn. Vaak ook wel een Microsoft / Google account. Paypal misschien ook.

Met een emailadres + wachtwoord kan je al erg ver komen. Zoveel mensen gebruiken geen 50 unieke wachtwoorden, tenzij ze een utility als Lastpass of Keepass gebruiken.

[de Koning]

Zojuist ontving ik ook de email van [e-mail]. Ik heb mijn reactie aangepast, omdat ik nu zie dat de email is toegevoegd aan het artikel.

Ik kan een wachtwoordreset aanvragen en daarbij het nieuwe wachtwoord invoeren, maar een 'save' knop ontbreekt. Zowel geprobeerd op Firefox alsof Chrome. Andere die tegen het zelfde probleem aanlopen?

[Reactie gewijzigd door de Koning op 24 juli 2024 00:39]

[Miss_80]

Je moet op 'reset' drukken (ja, best vreemd) en dan wordt de boel onder water aangepast want je blijft op het scherm voor wijzigingen wachtwoord. Er staat wel een melding boven dat je nu met je nieuwe gegevens kunt aanloggen

[de Koning]

Bedankt Miss_80, het heeft inderdaad geholpen

[vanaalten]

Daarnaast werd er een nieuw administrator-account ontdekt.

... klinkt als meer dan alleen een datalek. Dit lijkt mij al meer op een systeemhack, want met alle gebruikersnamen/wachtwoorden alleen zou je niet zomaar een admin account er bij moeten kunnen maken.

Tenzij er bij die gebruikersnamen die gelekt zijn ook de gegevens van een admin-account zitten EN je met dat admin-account ook een nieuw account kan aanmaken. En dan klinkt het voor mij als een flink ondermaatse beveiliging, als dat zo makkelijk kan.

[CEx]

Het is ook een systeemhack, daardoor is gevoelige data bereikbaar geweest. Of deze data ook daadwerkelijk benaderd en gekopieerd is weet men niet.

[Verwijderd]

De site draait ASP.NET. Opmerkelijk, want dat zie je niet vaak dat een ASP.NET site gehackt wordt.

[himlims_]

komt omdat meer dan 80% vd sites draaien op php/linux dus zie je aps/net 'hacks' minder, is ook minder beschikbaar.

[Reactie gewijzigd door himlims_ op 24 juli 2024 00:39]

[[Shadow]]

Uit onderzoek blijkt dat meer dan 80% van de percentages die mensen noemen verzonnen zijn en niet op waarheid berusten.

[Iusedto]

Ik denk dat je 100% gelijk hebt

[LopendeVogel]

Haha dan is het aan himlims_ om met een bron te komen

[Frozenstorm]

Dat heeft niets met PHP of Linux te maken maar hoe de omgeving ingericht is.
Ik snap dan ook niet dat met alle lekken welke de laatste tijd in het nieuws zijn gekomen men niet naar de beveiliging en encryptie van eigen systemen gaat kijken...

[Reactie gewijzigd door Frozenstorm op 24 juli 2024 00:39]

[xiphoid]

Tja, als er 10,000 sites op banaan draaien en 10 op aardappel, en 1% wordt gehackt van beide, dan lijkt het me duidelijk dat je meer van die banaan hoort. Maakt het die aardappel niet beter van.

[DevWouter]

Misschien dat je dan je een verwijzing hebt hoe je tot die conclusie komt?

Wat himlims_ zegt is wel aannemelijk. Er zijn namelijk meer php installaties die op linux draaien dan dat er Asp.Net op windows draait. Gezien het marktaandeel van PHP kan het dus intressanter zijn om je daar op te richten gezien er meer potentieele slachtoffers zijn.

PHP kan net zo goed beveiligd worden als ASP.NET en andersom. Puur op basis van technologie alleen (en dus los van het marktaandeel) is er geen duidelijke reden waarom dat het "opmerkelijk" zou zijn dat de één vaker gehackt wordt dan de ander.

Jouw argument, als het goed onderbouwt is, zou dus voor veel mensen intressant kunnen zijn.

[Rub3s]

Misschien dat .NET MVC je wat meer dwingt/de goede kant op stuurt als het gaat om beveiliging. Bij PHP kan je doen en laten wat je wil.

[mrdemc]

ASP.NET MVC is dan ook een raamwerk zoals bijv. het Zend Framework. De vergelijking gaat in dat geval dus niet helemaal op

[kvdveer]

Dit is niet echt framework-afhankelijk, hoewel de gedachte van de basistaal natuurlijk wel het karakter van het framework bepaalt.

Als je bij PHP iets ondoordachts doet, dan heb je 80% kans dat het werkt, en 30% kans dat het een security lek is.

Als je in dotnet (VB/C#/etc) iets ondoorddachts doet, heb je 5% kans dat het werkt, en 15% kans dat het een securitylek is.

PHP probeert behulpzaam te zijn en te gokken wat je bedoelt. Een deel van die gokken zijn mis. De Dotnet omgeving probeert veel minder te gokken, en heeft het dus veel minder vaak mis. Dat is een deel van waarom PHP zo populair is geworden: je hebt met weinig kennis van zaken al heel wat website draaiend. Helaas leidt weinig kennis van zaken vaak ook tot wat exploitable bijwerkingen.

[Reactie gewijzigd door kvdveer op 24 juli 2024 00:39]

[:murb:]

Voor wat het waard is, de claim van @himlims_ lijkt me nog niet zo onredelijk: https://w3techs.com/techn...view/programming_language

82.1% van de websites draait op PHP. Het zal wel zo zijn dat het voornamelijk de kleinere sites zijn, terwijl ASP.NET draait bij de grotere; PHP is net wat toegankelijker. Ik ben zelf overigens verbaast over het hoge aandeel ASP.NET, kom het zelf bijna niet tegen (misschien door explosie van stackoverflow-branches?). Er zijn blijkbaar parallelle werelden waar ontwikkelaars wél ontwikkelen op een niet-unix-achtig systeem

[:murb:]

ASP.NET zit technisch vast beter in elkaar dan PHP, wat een allegaartje is (of was, probeer er zelf zo min mogelijk mee te doen, maar kom het tegen). Daarnaast wordt ASP.NET meer toegepast in 'enterprise' omgevingen, waar wél geld wordt uitgegeven aan testen. Maar ook met ASP.NET kun je ook gewoon paswoorden niet hashen, sql queries 'met de hand' schrijven en samenvoegen met rauwe input van het internet, etc.. Iedere ontwikkelaar kan zijn eigen systemen onveilig maken; ASP.NET alleen is geen garantie voor kwaliteit.

[Verwijderd]

Klopt, maar bij ASP.NET hebben ze daar een oplossing voor namelijk de zogenaamde Membership database. Dat is een component geschreven door experts van Microsoft JUIST omdat mensen eerst hun eigen implementatie voor authentication en authorization bouwden en daarin zaten vaak fouten wat de security van de sites lek maakte.

Zover ik weet is er in PHP niet zoiets (maar ik weet weinig van PHP dus dit zegt niet veel).

[Brummetje]

Denk dat het weinig met de taal te maken heeft, dit ligt allemaal aan hoe het geprogrammeerd is natuurlijk.

[Stoelpoot]

Mja, ASP.NET heeft een aantal goede standaarden voor gebruikersbeheer standaard en gratis te krijgen. Hier is een andere user-library gebruikt, wat dus de kwetsbaarheid bevatte, maar is ASP.NET zijn dat soort libraries toch iets minder bekend dan in PHP, Python etc. omdat ASP.NET dus libraries standaard in het .NET framework heeft zitten.

[mrborrie]

Ik had de mail ook al ontvangen, gevalletje Fast lane, en ik kan al raden wat de Kaizen van de volgende sprint gaat worden.

[Zebby]

Denk dat ze in hun volgende sprints meer aandacht moeten besteden aan security

Ben blij dat mijn account is gekoppeld aan mijn werkmail, verlaagd toch het risico van problemen bij andere accounts ietwat.

[Verwijderd]

Apart dat zowel de encrypted wachtwoorden als de decryption key hiervoor zijn gestolen. Meestal zijn de wachtwoorden gehashed. Die ontwikkelaars weten absoluut niet waar ze mee bezig zijn.

[SilentF0rce]

Een sprint van 8 weken is belachelijk. 2 of 4 weken zijn veel gangbaarder. Daarnaast kan een sprint opengebroken worden voor noodsituaties, zoals een veiligheidslek wat snel opgelost moet worden.

Inderdaad een fantastisch systeem. Niet perfect, maar wel beter voor de klant vanwege de snellere return on investment en beter voor het ontwikkelteam omdat ze meer met de klant praten en sneller feedback krijgen.

[Aaargh!]

Een sprint van 8 weken is belachelijk. 2 of 4 weken zijn veel gangbaarder

Ja, ik ging uit van 4 weken. Als je net begonnen bent aan de huidige sprint duurt het ~4 weken voor de volgende begint waarin je dit kan meenemen en dus pas over 8 weken is de fix er.

[SilentF0rce]

Misschien moet je nog maar een cursusje scrum doen.

Je hoeft niet tot na een sprint te wachten om een User Story op te leveren. Het hangt er helemaal vanaf hoe je de Definition of Done hebt afgesproken. En dan nog kan je een uitzondering maken.

Daarnaast, wat ik al eerder zei, is scrum best flexibel. Sprint openbreken voor een security-patch van deze schaal lijkt me een goede reden en het lijkt me niet dat er één PO in de wereld is die het daar niet mee eens is.

[Bacchus]

De backlog voor deze sprint is al vastgesteld, dus de fix komt pas na volgende sprint, over 8 weken
Ja, fantastisch systeem dat Scrum

Naast wat the_shadow en Brummetje zeggen:
Een "sprint" van acht weken klinkt mij meer als een marathon, twee weken is eerder de standaard en ervaren teams gaan eerder richting korter dan langer.

[Aaargh!]

Je moet eerst je huidige sprint afmaken voordat je dit op de backlog van de volgende sprint kan zetten. 4 wkn huidige sprint + 4wkn volgende sprint = 8 weken voor oplevering.

Sprints van twee weken is totaal achterlijk. Aan het begin ben je een halve dag kwijt aan sprint planning, aan het eind een halve dag aan retrospective. Op 10 werkdagen ben je dus al 1 dag, m.a.w. 10% van de tijd, kwijt aan praten, praten en nog meer praten.

[the_shadow]

Aan het begin ben je een halve dag kwijt aan sprint planning,

Max 8 uur voor een sprint van een maand.

aan het eind een halve dag aan retrospective.

Max 3 uur voor een sprint van een maand.

Als je sprints doet van 2 weken, dan zouden beiden dus een stuk korter kunnen.

[mpkossen]

Ik constanteer wat misconcepties over hoe Scrum werkt/kan werken. Mocht het je leuk lijken het hier eens over te hebben stuur me dan gerust een DM.

[Bacchus]

Dan heb je Scrum niet begrepen. Als je zoveel tijd aan planning en retrospective kwijt bent, moet je misschien je product owner beter africhten. Met langere sprints ga je ook meer moeten bespreken in je events.

[Verwijderd]

Ik zou 2 weken niet achterlijk noemen, het is in sommige bedrijven de norm en het is de standaard aanbeveling van scrum: 2 a 3 weken.

[rvankruistum]

Sprints van 2 weken worden steeds vaker gebruikt. Je planning meeting en Sprint review/retrospective zijn in dit geval ook 2 keer zo kort (in principe 1 uur per sprint week).

Als ik het zo hoor heb je vaak te maken gehad met waterval projecten die door managers in een "scrum" formaat gegoten zijn zonder de onderliggende ideeën over planning etc. aan te passen. Dat soort projecten hebben niets met Agile werken te maken.

[rkootstra]

Zoals ik al zei staan een sprint en release cycle totaal los van elkaar. Wie zegt dat na 4 weken het development team moet releasen?

Uiteraard is dit vaak in de praktijk wel vaak het Development team. Je comments betreft de 10% tijd kwijt is een erg bekend probleem. Wij hebben het zelfde. Backlog wordt 100% ingezet maar waar haal je de overige sprint events kwa tijd vandaan.

[rkootstra]

Sterker nog als je de scrum guide hebt gelezen en daadwerkelijk hebt gelezen wat scrum inhoud zul je lezen dat een sprint nooit langer dan een maand mag duren.

Tevens staan een sprint en een release cycle totaal los van elkaar.

[Reactie gewijzigd door rkootstra op 24 juli 2024 00:39]

[Brummetje]

Nu heb ik Scrum niet super vaak gebruikt, maar volgens mij wijk je met security updates die direct gedaan moeten worden gewoon af van Scrum.

[mpkossen]

Sterker nog, je wijkt niet eens af van Scrum als je dat doet. Scrum laat je vrij om zoiets op te pakken in een sprint.

[the_shadow]

Binnen een sprint kan je prima critische patches z.s.m. gebouwen. Natuurlijk wel in overleg met de Product Owner, om zo de scope voor de sprint bij te stellen.

[rvankruistum]

"Welcoming change" is nog steeds een belangrijk principe binnen scrum. Zoiets als dit zou reden genoeg kunnen zijn om de huidige sprint te stoppen en direct een nieuwe planning meeting in te gaan.

[Yggdrasil]

Ik weet al wat de volgende iteratie gaan inhouden...