Tweaker ontdekte admingegevens Azure-ontwikkelomgeving Belastingdienst op GitHub

Een medewerker van de Belastingdienst bewaarde admincredentials van een server van de ontwikkelomgeving in een openbare Git-repository. Dat werd door tweaker SchizoDuckie ontdekt, die dat vervolgens via responsible disclosure bekendmaakte bij de instantie.

Op 15 november trof whitehat-hacker SchizoDuckie een publieke repository aan op GitHub van iemand die bij de Belastingdienst werkt. Daar vond hij onder andere Continuous Integration-scripts gerelateerd aan de ontwikkelomgeving van de instantie. Hier werd zowel de gebruikersnaam als het wachtwoord aan een curl-commando gegeven om zo een andere Git-repository te clonen. Toen hij dat spoor volgde, kwam hij terecht bij meer hardcoded wachtwoorden in de privé-GitLab-repository van de desbetreffende Belastingdienst-medewerker.

SchizoDuckie toont op Twitter een chatgesprek waarin hij uitlegt wat er vervolgens gebeurde. Hij besloot de relevante repositories te clonen voor verder onderzoek en meteen de Belastingdienst in te lichten. Tijdens het opstellen van een e-mail naar de securityafdeling van de instantie besloot hij nog even naar 'password' te zoeken in de privéomgeving van de medewerker om daar screenshots te maken voor de e-mail. Zo stuitte hij op de admincredentials voor de Microsoft Azure-testomgeving waar deze infrastructuur gehost werd.

Een inlogpoging leerde SchizoDuckie dat het geldige gegevens waren, maar het account was beveiligd met meerfactorauthenticatie. Tot zijn verbazing werd de inlogpoging echter bevestigd door de eigenaar van het account. Omdat hij niet van plan was daadwerkelijk de server binnen te komen, sloot hij het venster en lichtte hij de Belastingdienst in.

In de repositories trof SchizoDuckie ook een telefoonnummer aan dat de Belastingdienst-medewerker gebruikte voor authenticatie op een iCloud-account. Na enige tijd besloot de tweaker de medewerker zelf op te bellen, om hem te helpen alle veiligheidsproblemen op te lossen. Daarna bevestigde het Security Operations Center van de Belastingdienst dat de melding was ontvangen en de problemen waren opgelost.

SchizoDuckie zegt tegen Tweakers dat hij rond 17.00 uur 's middags de eerste e-mail stuurde en dat hij rond 22.30 uur 's avonds de eerste melding van het SOC kreeg dat er zaken opgeruimd waren. De betreffende medewerker heeft SchizoDuckie nog teruggebeld en bedankt voor zijn hulp. De medewerker heeft geen adminprivileges meer, kon fluiten naar een salarisverhoging, maar heeft zijn baan behouden. Voor zijn melding kreeg SchizoDuckie een 'I hacked the Dutch Tax Administration and never got a refund'-bokaal.

De Belastingdienst bevestigt tegenover Tweakers dat SchizoDuckie toegang had tot een ontwikkelomgeving van de instantie: "Er is intensief contact geweest tussen het Security Operations Center van de Belastingdienst en SchizoDuckie over de melding die door hem is gedaan. Door een menselijke fout kon SchizoDuckie toegang krijgen tot deze ontwikkelomgeving. De Belastingdienst heeft SchizoDuckie de ruimte gegeven om hierover te publiceren. De Belastingdienst wil namelijk bewustzijn creëren voor het feit dat zelfs met multifactorbeveiliging, de mens een zwakke schakel kan zijn."

SchizoDuckie is positief over de toestemming van de Belastingdienst om zijn verhaal naar buiten te brengen: "Veel van wat ik doe breng ik überhaupt niet naar buiten, maar zonder af en toe de publiciteit te zoeken, verandert er nooit iets aan de bewustwording van nerds over de hele wereld. Het is niet eens zeldzaam om Azure-admincredentials tegen te komen als je eenmaal weet hoe je de GitHub search engine moet gebruiken. Alsjeblieft, stop met het uploaden van je wachtwoorden naar GitHub, en probeer ook zelf eens je eigen bedrijfsnamen en domeinnamen op te zoeken om te kijken wat er allemaal over jouw organisatie te vinden is."

Volgens de Belastingdienst heeft SchizoDuckie geen toegang tot persoonsgegevens of fiscale informatie van burgers gehad: "De omgeving waar SchizoDuckie toegang toe had verkregen, is een ontwikkelomgeving waarin geen persoons- en fiscale gegevens aanwezig zijn. Er is dus ook geen sprake van een datalek voor de AVG", aldus de woordvoerder. De woordvoerder benadrukt ook dat de melder zich keurig aan de afspraken over het melden van beveiligingslekken heeft gehouden.

Door Julian Huijbregts

Nieuwsredacteur

29-12-2021 • 17:24

132 Linkedin

Reacties (132)

132
130
57
6
0
49
Wijzig sortering
Ik vraag mij af, wanneer Nederlandse organisaties eens serieus gaan betalen voor dit soort zaken en andere ontdekte kwetsbaarheden.

Een bokaal of T-shirt is leuk, maar er is een markt die wel wilt betalen.
Er zijn genoeg public bug bounty programma's op zich, maar soms steekt het inderdaad wel als je bijvoorbeeld een Philips redt van al hun code public op het internet gesmeten krijgen en je krijgt als "dank" een vermelding op hun website... of een Signify van die mooie Hue lampen die beloftes doen om iets op te sturen en vervolgens blijft het stil..

Het gaat mij ook niet eens om het geld eigenlijk. Ik ben ook heel dankbaar voor de goeie karma en wat toffe swag, maar als ik bij je aanklop heb ik niet een lullig XSS lekje ontdekt maar kan ik meestal precies hetzelfde als een van je medewerkers.

Dit soort ervaringen als met de Belastingdienst SoC zorgt er dan wel weer voor dat je er weer tegen kan qua spirit :)
Mijn dank heb je, hulde _/-\o_ Nogal jammer dat het juist bij de Belastingdienst moet gebeuren.
Thx :)
Het gebeurt juist niet alleen specifiek bij de belastingdienst maar echt overal. Ik heb al meer grote internationale bedrijven van binnen gezien dan ik ooit had kunnen dromen. Ik ben inmiddels de exacte tel kwijt na 500+ disclosures over heel de wereld in de afgelopen 3 jaar. Ik denk dat je van zeker de helft de logo's zo zou herkennen. Hoe groter het bedrijf, hoe groter de kans dat ik iets ga vinden lijkt het wel, ondanks alle andere mensen op het internet die precies hetzelfde doen
Dit klinkt waarschijnlijk echt als een domme vraag - maar hoe begin je in doen wat jij doet? Ik ben een middelmatig netwerkbeheerder maar ik zou in mijn vrije tijd ook dit soort dingen willen ondernemen. Ik heb oprecht geen flauw idee hoe je daar nou eenmaal aan begint.

Heb je aanraders voor literatuur, blogs en/of courses?
https://www.hackthebox.com/

Vanuit school worden we vaak op dit platform losgelaten.
Er zijn een aantal "free" challenges te doen elke maand.
Mwoa, ik vind dat er wel een proportionele tegenprestatie mag zijn. De geest achter de vindersloon-wet vind ik dan ook een goede inspiratie voor deze situaties. Leuk dat je het niet voor het geld doet (en dat meen ik echt), maar bedrijven luisteren nou eenmaal beter wanneer het hun bottom line raakt. Een beeldje en een vermelding is leuk om te laten zien maar staan, vind ik, niet in verhouding tot de potentiële schade die hiermee gemoeid was.

Bescheidenheid is leuk bij intermenselijk contact. Zodra het gaat om ondernemingen en overheden zou ik de bescheidenheid verruilen voor harde knaken.
Want de belastingdienst is een bedrijf? Ik kan mij ergens wel voorstellen dat je als white hacker publieke instellingen doorlicht juist omdat het een publiek belang dient. De belastingdienst is geen kapitalistische onderneming die gruwelijk veel geld wil verdienen maar een organisatie waar we allemaal mee te maken hebben. Ook SchizoDuckie zal er belang bij hebben dat zo'n organisatie goed en veilig werkt. Het hoeft dan niet altijd om de centen te gaan.
Ik zelf heb een aantal T-shirts in mijn kast liggen. Ik denk dat het ons ethisch besef is, dat het weerhoud om te verkopen aan de hoogste bieder. Ik zal ook altijd een probleem bij een bedrijf melden, ongeacht de beloning.

Maar een ander persoon, kan exact het zelfde probleem vinden en er minder goede bedoelingen mee hebben.Ik denk dat bedrijven en overheid zich niet voldoende bewust hiervan zijn, wat voor schade je eventueel voorkomen hebt.

Op dat punt, ben ik het met @Kuusje helemaal eens. Ik zag dit bericht een paar dagen geleden al op Twitter voorbij komen en om eerlijk te zijn. Vond ik de beloning best wel triest.

Des ondanks, dank je voor je goede werk :)

/edit
Ops, was als reactie op @SchizoDuckie bedoelt.

[Reactie gewijzigd door wica op 29 december 2021 22:06]

Hoe reageerde medewerker in kwestie? In het artikel lijkt hij meegaand en vriendelijk te zijn, en je nadien ook te bedanken. Was dat je ervaring ook? Niet iedereen reageert even vrolijk als ze op hun fouten worden gewezen!
Jazeker. Gewoon een normale gozer waar ik goed mee kon schakelen, heel vriendelijk en was dankbaar voor de hulp bij wat ik me kan voorstellen echt een worst nightmare is.
Nou, toffe gast dan, nadat je hem moron genoemd had.
Ach, met zulke acties van jouw kant hadden ze van mij je belastingaangifte er wel even uit mogen pikken om er wat extra korting op te geven, meer dan verdiend!
100.000 Karma punten ? O-)
Had een 50k vindingsbonus je niet meer spirit gegeven?
Een bokaal of T-shirt is leuk, maar er is een markt die wel wilt betalen.
Volgens mij krijgen whitehats er drie dingen voor terug:
  • Een bokaal of T-shirt
  • Géén klopjacht van de politie
  • Naamsbekendheid / geloofwaardigheid
Het probleem bij beveiliging (zowel aan de kant van de beveiligers als aan de kant van de pentesters) is dat het lastig is om de kwaliteit van het werk vast te stellen. Of nou ja, als het compleet hopeloos is dan merk je dat snel genoeg, maar hoe bepaal je het verschil tussen "best redelijk, maar verre van perfect" en "uitmuntend"? Hoeveel geld ben jij bereid om iemand te betalen voor een audit als je nog nooit van hem gehoord hebt? En, gaat dat bedrag omhoog als het is van iemand waar je wel van gehoord hebt, "die gast die bij de Belastingdienst binnen was gekomen"? Ook het laatste regeltje van het artikel "De woordvoerder benadrukt ook dat de melder zich keurig aan de afspraken over het melden van beveiligingslekken heeft gehouden." (lees: dit is een betrouwbare professional) is in die zin veel geld waard voor de whitehat, zelfs al kost het de Belastingdienst geen cent.

Voor de duidelijkheid: ik zeg dus niet dat het goed is dat er geen cash wordt betaald (een vierde beloning is altijd leuk, bovenop de huidige drie). Mijn punt is alleen dat jouw weergave van de beloning onvolledig is.
Een klopjacht voor het clonen van een public GitHub repo? Lijkt me heel lastig hard te maken voor de rechter. ;)
Die eventuele nadruk zit natuurlijk niet op het clonen van die publieke repo maar op het testen, uitvoeren en gebruiken van code/data op live omgevingen waarvan je (1) weet dat je daarmee aan de servers zit van een organisatie, en (2) bewust bent dat wat je doet eigenlijk niet de bedoeling is. Het proberen in te loggen is fout genoeg - ook al zet je niet door. De politie zou het alleen maar interessanter vinden als die organisatie een vooraanstaand regeringsinstrument als de Belastingdienst is.
Dan moet er dus óók bewezen worden dat je op het moment van het doen van de inlogpoging je bewust was van het feit dat het een live-omgeving van een vooraanstaand regeringsinstrument was. Denk dat wanneer je na inloggen direct weer (van schrik?) uitlogt, en vervolgens ongeloof claimt omdat er zó onzorgvuldig met adminaccounts omgesprongen wordt je al redelijk sterk staat. Tenzij er driedubbeldik "live.belastingdienst.nl" in de URL zat misschien.

[Reactie gewijzigd door kakanox op 30 december 2021 11:56]

Ik ben geen jurist maar ik persoonlijk meen dat gezond verstand al genoeg is om iemand te overtuigen van het feit dat hij niet op z'n eigen spullen aan het werk is. Los daarvan, dat de persoon in kwestie op GitHub beweegt, een white hat hacker wordt genoemd, én de activiteiten uitvoert die bij een dergelijke titel horen maken het alleen maar aannemelijker dat hij de kennis en het bewustzijn had om te kunnen zien dat hij met andermans spullen bezig was. Verder zei ik niet dat het per se relevant voor de beoordeling van de acties is dat het een vooraanstaand regeringsinstrument betrof, maar dat maakt de situatie wel eventueel nóg vervelender.
Kan je me uitleggen wat er dan mis is met inloggen op andermans spullen?
Ik doe dat heel regelmatig. Diverse projecten waar je niet alleen pulls en push requests van de code mag doen, maar ook gewoon in mag loggen op een ontwikkel of testserver. Vermoed dat die dingen periodiek opnieuw gebuild worden (zal wel Docker/Kubernetes ofzo zijn), want ik tref nooit de situatie dat er geen één werkt.

Er staat dan niet expliciet bij dat het mag, de eerste keer was ik er dus ook wel een tikkeltje onzeker over. Inmiddels ben ik het gewend en doe ik gewoon m'n ding als ik wat toe te voegen heb, of als ik even wil snuffelen hoe anderen iets opgelost hebben.

[Reactie gewijzigd door kakanox op 3 januari 2022 01:14]

Het is verboden om in te loggen met iemands credentials zonder diens toestemming. En dus ook als je deze credentials op een 'publieke plek' hebt gevonden.

Kijk maar in het wetsartikel:
https://www.om.nl/onderwe...rtikel-computervredebreuk

Door het inloggen met iemand anders zijn credentials, neem je een valse hoedanigheid aan (want je bent niet de persoon die de rechtmatig eigenaar is van de credentials).

Zoals je ook kunt lezen, is daarvoor niet persé nodig dat je 'enige' beveiliging doorbreekt.
En het is juist die toestemming die dan ter discussie staat. Waarom zou iemand credentials publiceren zonder toestemming om in te loggen? Je zou kunnen stellen dat publiceren op een public GitHub per definitie toestemming verlenen is.
quote: GitHub, first thing you read
Public repositories are accessible to everyone on the internet. Private repositories are only accessible to you, people you explicitly share access with, and, for organization repositories, certain organization members.

[Reactie gewijzigd door kakanox op 5 januari 2022 11:36]

Ben bang dat je daar niet mee weg komt... Als je geen expliciete toestemming hebt van de eigenaar van de credentials, mag je er niet vanuit gaan dat je het zomaar mag gebruiken. Daar zal de rechter ook vanuit gaan. Dus helaas...

Gevonden credentials moet je gewoon melden bij de politie of bij de betreffende organisatie, net zoals alle andere 'gevonden voorwerpen'. Je mag er niets zelf mee doen.
Het gaat natuurlijk niet enkel om het clonen van die repo, maar om gebruik van wachtwoorden, waarvan je weet dat er meer mee gemoeid is dan enkel een "open source" github projectje. Zo werkt het. Een inbreker mag ook niet inbreken in een huis wat niet op slot zit.

Ja de verzekering zal tegen de slachtoffers zeggen "dikke pech had je de deur maar op slot moeten doen", maar de rechter gaat de inbreker zeker alsnog vervolgen.

En om de analogie door te trekken naar enkel "snuffelen" wat de white hat hackers doen: Stel dat de inbreker niks mee nam is dat alsnog een zwak verweer voor huisvredebreuk.

Maw; ergens binnentreden brengt altijd bepaalde verplichtingen met zich mee, ook al zijn je intenties goed. Dus niet vervolgd worden is wel een heel fijne zekerheid om dit te blijven doen.

[Reactie gewijzigd door A Lurker op 30 december 2021 15:38]

Het gaat natuurlijk niet enkel om het clonen van die repo, maar om gebruik van wachtwoorden, waarvan je weet dat er meer mee gemoeid is dan enkel een "open source" github projectje.
Dat zeg ik dus: Hoe weet je dat? Het kan goed zijn dat je daar pas achter komt als je ingelogd bent; van een open source github projectje waarmee ik URLs en wachtwoorden binnen hengel verwacht ik niet dat daar grote geheimen achter verborgen staan.
We zijn in Nederland niet schuldig tot het tegendeel bewezen is.
En om de analogie door te trekken naar enkel "snuffelen" wat de white hat hackers doen: Stel dat de inbreker niks mee nam is dat alsnog een zwak verweer voor huisvredebreuk.
Metaforen en analogieën zijn zelden écht van toepassing, en dienen meestal enkel de invalshoek van de gebruiker.

In dit geval kan je het mijns inziens eigenlijk nog beter vergelijken met de Woo. Ik besef me dat het evenmin een perfecte analogie is, maar je doet met een Woo-verzoek wel een bindende aanvraag. De overheid is namelijk verplicht documenten te geven op basis van deze wet.

Wat jij schrijft, lees ik als dat het doen van een Woo-verzoek strafbaar zou moeten zijn, want daarmee zou je in theorie achter informatie kunnen komen die mensen kan schaden.

De Woo zelf is overigens niet afdoende op het gebied van informatiebeveiliging, omdat je daarmee alleen documenten op kan vragen over zaken die wél gedaan zijn. En dat die controle niet afdoende is, dat is door dit nieuwsbericht opnieuw aangetoond.

[Reactie gewijzigd door kakanox op 30 december 2021 18:04]

Ik begin mijn post nog wel met het gedeelte waar ik op reageerde:
Een bokaal of T-shirt is leuk, maar er is een markt die wel wilt betalen.
Die "markt die wel wilt betalen" is uiteraard een verwijzing naar criminelen. En ja, als criminelen erin slagen om de hele Belastingdienst te cryptolocken, dan hebben niet alleen zijzelf een probleem; degene die ze heeft geholpen om binnen te komen (zelfs als dat alleen maar is door ze te wijzen op openbare informatie) kan ook een bezoekje van oom agent verwachten. Het magische woord is "medeplichtigheid".
Als je weet dat het de Belastingdienst betreft en vervolgens gewoon de boel online publiceert, uiteraard ben je dan medeplichtig (en op z'n hoogst grey hat).

Het aantal "I hacked the Dutch government ..."-T-shirts dat echter in mijn LinkedIn voorbij komt wijst erop dat white hat hacking simpelweg nodig is om te zorgen dat de overheid z'n zaakjes op orde heeft. Om een geloofwaardig verhaal te hebben zal je moeten verifiëren of je stelling klopt, dus proberen of credentials überhaupt werken. Dat je dan verder geen illegale handelingen moet plegen staat buiten kijf.

Ik vrees dat de Belastingdienst nog niet zo'n sterke zaak heeft als ze dit aanhangig zouden maken. Maar misschien is het een kwestie van tijd voor we daar achter komen :)
Hoe vaak kun je over de kern van het verhaal heen lezen!? Wat wica zich afvroeg en waar ik op reageerde is waarom er geen dikke bug bounties worden uitbetaald:
wanneer Nederlandse organisaties eens serieus gaan betalen [..] er is een markt die wel wilt betalen.
Wat mij betreft was die verwoording volkomen duidelijk, maar om het even helemaal uit te spellen:

Als je een kwetsbaarheid vindt, dan moet je kiezen of je die gewoon netjes meldt of dat je gaat proberen om het aan een crimineel te verkopen. Voor een heleboel mensen is dat een makkelijke keuze (om allerlei mogelijke redenen: ze kennen geen criminelen, criminelen kennen hen niet (en dat willen ze graag zo houden), ze willen criminelen geen toegang geven tot een systeem waar hun eigen gegevens ook in staan... of simpelweg omdat ze enig moreel besef hebben). Voor een, hopelijk, heel klein groepje is de keuze ook makkelijk ("schijt aan alles en iedereen, ik wil geld"). En daar tussenin zit een groepje die op zich wel de juiste keuze wil maken, maar die het idee van een heleboel geld stiekem toch wel verleidelijk vindt.
Over die laatste groep hebben we het. Die mensen moeten momenteel een keuze maken tussen "geen cash" en "veel cash". (Tenminste, zo stelde wica het voor, volgens mij ligt het iets anders.) Dat klinkt inderdaad alsof het erg verleidelijk is om de verkeerde keuze te maken, vandaar het voorstel dat "Nederlandse organisaties eens serieus gaan betalen", zodat mensen moeten gaan kiezen tussen "leuke hoeveelheid cash" en "nog meer cash". Dan zullen sommige mensen nog steeds de verkeerde keuze maken, maar dan is het in elk geval al een stuk minder verleidelijk.
maar er is een markt die wel wilt betalen.
En die markt zal altijd meer blijven betalen dan zo een overheidsorganisatie of commercieel bedrijf. Mensen die daar 'vatbaar' voor zijn zullen altijd gaan voor het significant meer geld vanuit het criminele circuit. Ik verwacht dat mensen zoals SchizoDuckie daar niet snel door worden verleid, anders hadden we dit nooit hier gezien...
Maar, tegen gelijke betaling, zal bijna iedereen de legale optie kiezen. Dus een crimineel moet significant meer bieder. Hoeveel meer? Wie weet. Dat hangt ook erg af van de geest van de verkopende hacker.

Je hoeft dus niet even veel te bieden als een crimineel om toch een deel van dit soort hacks uit de criminaliteit te houden.
Juist, een beloning. Die het niet de moeite waard maakt, om alle risico's te lopen, als crimineel is meer dan voldoen.
Daarnaast een pentest/hacktest is ook niet goedkoop :)
Precies. En je kunt het ook zo zien: veel mensen willen op zich het goede doen, maar kunnen worden verleid met veel geld. Als de legale weg ook flink geld oplevert, is het makkelijker om het goede te doen. Hoeft niet even veel te zijn.

[Reactie gewijzigd door Cerberus_tm op 30 december 2021 01:55]

Dus jij geeft de buurman direct een bonus als hij jou ergens op wijst wat het inbrekers makkelijker maakt om bij jou binnen te komen? Een vermelding op de website o.i.d. heb je langer profijt van dan een zakje geld.
Wanneer gaat de Belastingdienst eens serieus betalen voor gekwalificeerd personeel. Ik zie vaak de mails van hun preferred supplier langs komen voor azure gerelateerde freelance functies bij de belastingdienst in Apeldoorn. Dit omdat dit mijn eigen werkgebied is.

Je moet eerst een boekwerk van 5 pagina’s in word gaan typen en uur tarief is 80.55, ver onder markt conform. De belastingdienst betaald dus de pinda’s.

Btw sneu voor die medewerker, maar waar waren zijn collega’s die ooit die PR goed gekeurd hebben met credentials er in. Dit is dus niet alleen de mayor fuck up van een medewerker. Er bestaat zoiets als azure keyvaults, gebruik die in godsnaam. Je kan prima passwords vanuit keyvaults referren met je service principal account.

Waarom zijn meerdere mensen bezig met een admin account? Is er niemand daar die weet hoe je in AD gebruikers kan aanmaken?

Deze fuck up geeft dus weer dat het personeel bij de belastingdienst niet op de hoogte is van de functionaliteiten in Azure zelf. En dat is behoorlijk verontrustend te noemen.

[Reactie gewijzigd door mannowlahn op 30 december 2021 13:47]

Op freelancers moet je bij de overheid sowieso niet bouwen. Na 2 jaar, met hoge uitzondering 3 jaar.
Moeten ze weer opdonderen, volgens de regels van de overheid.

Of je moet een ambtenaar worden.

Kennis uitstroom bij de overheid is best hoog.
Niet alleen Nederlandse bedrijven toch? Red Bull is notoir voor betalen in energiedrank, bijvoorbeeld.
Deze medewerker maakt deze fout NOOIT meer. Die heeft z'n straf gehad en zal in de toekomst een van je grotere assets worden. Hij heeft echt wel skills anders kun je niet een hele CI omgeving optuigen.

Als ze hem er bij de belastingdienst uit zouden gooien zou ik mijn werkgever hem zo een baan laten aanbieden.
Dat vind ik wel mooi.

In Amerika, overigens een vreselijk land, hebben ze geloof ik vaak een regel dat iemand die eens failliet is gegaan, later juist makkelijker bepaalde leningen kan krijgen, omdat hij statistisch gezien minder kans heeft om in de toekomst (nog eens) failliet te gaan. Hij heeft zijn lesje meestal geleerd.

[Reactie gewijzigd door Cerberus_tm op 29 december 2021 19:38]

Anoniem: 100047
@bbob29 december 2021 18:30
Ik verpruts alles de hele dag door, maar dat wegpromoveren werkt maar niet :( 8-)
Zoals je gezegd je moet het echt goed verprutsen, als je het nieuws haalt zie die promoties er vast in. 8)7
De medewerker heeft geen adminprivileges meer, kon fluiten naar een salarisverhoging, maar heeft zijn baan behouden.
Wat zou de bron hiervan zijn? Het lijkt me vreemd dat een werkgever zulke interne informatie (oa. persoonlijke sancties) over een werknemer verspreidt.

[Reactie gewijzigd door biglia op 30 december 2021 12:11]

De omgeving waar SchizoDuckie toegang tot had verkregen is een ontwikkelomgeving waarin geen persoons- en fiscale gegevens aanwezig zijn. Er is dus ook geen sprake van een datalek voor de AVG
Ik heb door de reactie van de belastingdienst niet echt het idee dat men de omvang van het risico begrijpt (naast enkel de eenvoudigste AVG niet gelukt boodschap). Er is dus (mogelijk) langdurig toegang geweest tot de source code (en ontwikkelingsomgeving) van de belastingdienst. Het eenvoudig dichten van het lek is daarmee nog niet eens 0.1% van de oplossing.

a) Hoe lang zijn deze gegevens online?
b) Welke commits / aanpassingen zijn er ná en vóór deze periode doorgevoerd, zijn hier logs van?
c) Is er een security audit op de 'gelekte' codebase losgelaten? Zijn er andere kwetsbaarheden?
d) .. zo kan ik nog wel even doorgaan.

Conclusie van de Belastingdienst is m.i. extreem kortzichtig.

Edit @SchizoDuckie ik zie dat je ook reageert in dit draadje, maar wat is je visie hierop?

[Reactie gewijzigd door m4ikel op 29 december 2021 21:23]

Ik heb het volste vertrouwen in de SoC van De Belastingdienst.Misschien wel de enige afdeling met publiekelijk verifieerbaar competente mensen aldaar. De hele omgeving en alles wat daar aan hing is compleet naar /dev/null verbannen en het stond los van de rest van de infrastructuur.

Reken maar alles wat dit ooit aangeraakt heeft ondersteboven gekeerd is, doorgelicht is en van voor tot achter gescrubbed is. Ik heb nog een call met de redteamers en de SoC leads gehad ook om ze mijn inzichten te geven over hoe je je hier tegen kunt beschermen (m.i. momenteel alleen door proactief te scannen)

Dit kan *elk* bedrijf gebeuren, BD is alleen het laatste voorbeeld.
Dank voor je toelichting, geen onbelangrijk detail.
@SchizoDuckie Hoe loop je hier tegenaan? Je beschrijft dat je het tegenkwam, zit je dan willekeurig te browser op github? Scanscript? Anders? Geheim? :P
Mijn zoektocht begint altijd gewoon heel stupid met GitHub search engine erbij pakken en dan "$bedrijfsnaam password" intypen.

Daarna ga je de resultaten filteren en refinen en linkjes naar domeinnamen verder uitpluizen met meer zoekopdrachten.
Met admin rechten op Azure, mag je nog blij zijn dat bots dit niet hebben gebruikt en een bitcoin mining cluster hebben gestart.

Volgens mij zoekt AWS actief naar private keys op github. Doet Azure dan niet iets soortgelijks? Of is die controle maar beperkt?
De snelste bot die ik ooit tegengekomen ben had al 8 minuten nadat de code geupload werd een eerste test spam mailtje eruit gestuurd. Bitcoin mining ben ik niet tegengekomen op Azure, wel berichten over het massaal inkopen van office licenties.

Ik heb als het meezit binnenkort een gesprekje met een van de leads bij Github om eens te bespreken waarom ik in mn eendje nog zoveel vind.

Het meest hilarische is nog dat GitHub van Microsoft is en ze 99% zo dicht kunnen timmeren

Vertrouw nooit en te nimmer op dit soort diensten. Zorg dat je er bij voorbaat niet vatbaar voor bent!

[Reactie gewijzigd door SchizoDuckie op 29 december 2021 19:54]

Volgens mij staat er in het gesprek Gitlab en niet Github. Github is van Microsoft en biedt eigenlijk best veel mooie security features. Ook credential scanning idd. Ik heb geen idee van de Gitlab features.
Credential scanning op GitHub? Volgens mij detecteren ze nog net een AWS key maar that's it
Poe poe nounou, da's al een hele lijst sinds ik dat voor het laast zag.

Jammer dat het blijkbaar in de praktijk geen snars uitmaakt.
Zodra er een secret gevonden wordt moet gewoon de repo automatisch op private geknald worden totdat iemand hem impliciet op public zet en in zo'n zelfde confirm box als bij repo verwijderen in typt "IK WEET ZEKER DAT IK DIT WACHTWOORD AAN DE HELE WERELD WIL VERTELLEN"
Poe poe nounou, da's al een hele lijst sinds ik dat voor het laast zag.

Jammer dat het blijkbaar in de praktijk geen snars uitmaakt.
Zodra er een secret gevonden wordt moet gewoon de repo automatisch op private geknald worden totdat iemand hem imexpliciet op public zet en in zo'n zelfde confirm box als bij repo verwijderen in typt "IK WEET ZEKER DAT IK DIT WACHTWOORD AAN DE HELE WERELD WIL VERTELLEN"
Kleine correctie.

[Reactie gewijzigd door Freee!! op 31 december 2021 14:41]

waarom ik in mn eendje nog zoveel vind.
I see what you did there... 8-)
Vertrouw nooit en te nimmer op dit soort diensten.
ik heb nooit gesnapt waarom bedrijven zo veel gebruik maken van een publiek plafform voor interne projecten, zeker megalomane overheidsbedrijven/diensten zouden imho moeten wegblijven van public clouds en dergelijke, die hebben genoeg resources en incentives om desnoods een private cloud op te zetten.
Uiteraard hoort men in een CI/CD omgeving ervoor te zorgen dat er checks worden uitgevoerd zodat dergelijke gegevens nooit in master belanden. Een goede developer opvoeding moet erin gedramd worden. En al helemaal geen admin-rechten voor onervaren medewerkers.

P.S. Trouwens, hoe rijdt je eendje? :P
De credentials stonden in een private repo
Zo private was die repo dus helemaal niet...
Waarschijnlijk een copy paste van de originele repo.

Als dat niet het geval is en in de originele repo het wel zonder wachtwoorden ingesteld stond, dan is de medewerker nog kwalijker bezig geweest door achteraf al die wachtwoorden in te vullen.
Hier werd zowel de gebruikersnaam als het wachtwoord aan een curl commando gegeven om zo een een andere Git-repository te clonen.
Dit moet wel een self-hosted vanilla git server zijn oid.
edit:
Update: Blijkbaar is het de gebruikersnaam en wachtwoord van een private gitlab.com account.

Bij GitHub, GitLab en zelfs bij een self-hosted Gitea server kun je API-keys genereren waardoor gebruikersnaam en wachtwoord niet nodig zijn en die API-key bepaalde permissies kan toekennen.
-----
De medewerker (...) kon fluiten naar een salarisverhoging, maar heeft zijn baan behouden.
Aangezien de bedragen van de vaste lasten nu en komend jaar flink gaan stijgen en er genoeg vraag in de markt is, zal het niet verbazend zijn dat hij binnenkort bij de Belastingdienst weg is.

[Reactie gewijzigd door RoestVrijStaal op 29 december 2021 19:04]

Het was een gitlab.com account kan ik je verklappen.

Dat iets technisch mogelijk is en een best practice is wil niet zeggen dat mensen het niet gaan proberen zo lui mogelijk te doen. HTTP basic auth op dit soort URLs moet gewoon snel uitgefaseerd worden.

Maar dan nog had ik ook zn private en public key en known hosts gevonden...
Maar dan nog had ik ook zn private en public key en known hosts gevonden...
Huh? Die opmerking snap ik niet, omdat het tot dusver enkel over loginnaam+wachtwoord ging.

Had je dan ook toegang tot een van zijn machines of zo? Of had hij ook zijn keys op die private gitlab.com repo staan? :F

[Reactie gewijzigd door RoestVrijStaal op 29 december 2021 19:13]

Lees even het verhaal van de screenshots zelf misschien. Ik vond op GitHub zijn Gitlab credentials (en een aantal andere) en op Gitlab stond ook als toetje de hele setup log van zijn mac mini die geautoriseerd stond op weer andere repositories en hosts.
Big yikes.
Lees even het verhaal van de screenshots zelf misschien.
Het artikel leek in eerste instantie 1:1 met wat er gechat werd.
Jammer, dat er in het artikel zelf, de ssh auth reutemeteut benoemd wordt onder het verzamelnaam "credentials". Want nu is mij duidelijk dat er dus sprake van zowel gelekte loginnaam + wachtwoord en public + private keys + known_hosts.
Inderdaad tenenkrommend.
Aangezien de bedragen van de vaste lasten nu en komend jaar flink gaan stijgen en er genoeg vraag in de markt is, zal het niet verbazend zijn dat hij binnenkort bij de Belastingdienst weg is.
Als hij het zo verneukt, toch genade krijgt en mag blijven en dan gaat klagen over geen loonsverhoging dan ben je zo iemand liever kwijt dan rijk.
Nee, hij zou juist niet moeten klagen. Maar de situatie accepteren en zijn opties moeten bekijken.

We weten niet zo goed wat zijn secundaire arbeidsvoorwaarden zijn, waardoor het aanlokkelijk is om te blijven. Maar zoals het nu voor hem eruit ziet, is blijven op zijn huidige werkplek op zijn minst financieel ongunstig. En als zijn collega's hem (met plagerij) dit incident blijven confronteren, is het ook mentaal ongunstig. Promotie in de toekomst is ook een groot vraagteken.

Bij dit soort situaties moet je goed voor jezelf zorgen en stilletjes rondkijken voor een andere werkgever.
Als de plagerij pesten wordt dan moet dat ofwel opgelost worden of inderdaad toch vertrekken want het moet niet (langdurig/structureel) ten koste gaan van je mentale gezondheid. Promotie is wellicht een vraagteken, het is natuurlijk ook een vraagteken of de betreffende werknemer daar op zit te wachten. Ik weet dat bij sommige andere overheidsinstanties je opleidingsniveau een drempel kan worden. Dan kun je verder groeien door een opleiding te doen maar sommigen kiezen ervoor dat niet te doen en gewoon lekker langdurig op hun plek te blijven zitten. Dus geen idee of dat relevant is.

Financieel ongunstig klopt, maar imho is hij de bd moreel gezien wel íets verschuldigd voor de genade die hij krijgt. Het zou hem sieren om áls hij overweegt weg te gaan en pesterij niet een probleem vormt, nog enige tijd te blijven (dat hoeft geen jaren te zijn) om wat goed te maken.
Totdat nieuwe werkgever vraagt om een GitHub link om wat werk van hem of haar te zien :)
Hoezo? Een nieuwe GitHub/GitLab account is zo aangemaakt.
Ging het nu om een GitLab of GitHub repo? In de screenshots staat er namelijk GitLab, in het artikel dan weer GitHub...

Indien het om een publiek GitHub repo ging zou er toch al secret scanning moeten gebeurd zijn?

EDIT: in het artikel is er sprake van een privaat GitLab repo, maar dus ook een publiek GitHub repo? :?

[Reactie gewijzigd door SanderH_ op 29 december 2021 18:12]

Correct. De GitHub repo clonede een repo vanaf zijn private gitlab.com account.
Dus intern gebruiken ze bij de belastingsdienst (uiteraard) private GitLab repo's, die hij voor 1 of andere reden gemirrored had naar een publiek GH repo? :+
Het scenario wat ik elke keer weer tegenkom is dat er *een* developer van een organisatie een repo niet naar de company namespace cloned maar om wat voor reden dan ook naar privé account pushed of dus naar een private Gitlab zoals in dit geval.
Erg dat er nog credentials in openbare repositories worden gezet. 8)7 Maar netjes afgehandeld, en leuk dat ze ook een bokaal hebben opgestuurd :P
Echt, ik kan hier een dagtaak van maken. Het gebeurt wereldwijd dagelijks.
Tijd voor een blog voor de bijzondere gevallen?

Edit: @SchizoDuckie zat een typo in m'n reply ;)

[Reactie gewijzigd door JT op 30 december 2021 10:07]

Tijd om eens met een persoon hoog in de boom bij GitHub te praten. :)
Hardcoded credentials is sowieso nogal een dingetje..
Het accepteren van die MFA request 8)7
Enable number matching in Azure MFA. Nu beschikbaar in preview.
Of gewoon forceren naar het handmatig invoeren van het nummer code. Op een verkeerd moment op het verkeerde knopje drukken kan immers grote gevolgen hebben.
Die moet op default bij MFA!
Dat zit wel in preview nog, dus snap heel goed dat men daar nog niet bedrijfsbreed mee aan de gang gaat. Hoewel het voor dev is dat een prima speeltuin.
Alles is zo dichtgespijkerd dat er vast wel meer shadow IT is dan alleen dit incident.
Dat vrees ik ook. Shadow IT is denk ik de nachtmerrie van elke CISO en als je dat voor de overheid aan het optuigen bent moet je je wel ernstig afvragen of je wel door moet gaan met wat je doet
Één ding wat ik niet snap. Waarom accepteerde de medewerker een MFA op zijn telefoon?
Mogelijk was het automatische reactie. Zoiets als: ik dit zie dus dan moet ik hier drukken. Als ik zie hoeveel dingen soms bij mij automatisch gebeuren zou het me ieder geval niet verbazen. Ik wilde bijvoorbeeld weleens gewoon me telefoon pakken omdat ik weg ging maar het eerste wat ik deed toen ik me telefoon vast had was me vinger op de vingerscanner leggen om in te loggen.
MFA Blindness is echt een ding.

Ik hoop echt dat de apps verbeterd worden. Microsoft is goeie dingen aan het doen met het toevoegen van de een kaartje met IP lookup als de origin niet herkend wordt in de beta van de authenticator, maar dan nog is er ook nog zoiets als "telefonische MFA" en dat mag van mij Z.S.M. kapot.
Die authenticator is niet veilig als je daarmee een inlog van een ander kan bevestigen. Dat gebeurde blijkbaar op de automatische piloot. Als je een code op de site moet invullen waar je inlogt kan zoiets niet gebeuren.
Maar is ook weer irritant, beveiliging is vaak een afweging tussen wat daadwerkelijk veilig is en wat nog praktisch is. Je kan een deur heus wel volhangen met sloten, irisscanners, vingerscanners, mfa's, captcha's noem maar op, maar als je er een kwartier mee bezig bent die deur te openen terwijl je er meerdere keren per dag doorheen moet, wordt het al snel vervelend.

Op zich zou die authenticator genoeg moeten zijn als hij maar duidelijk vermeld waar het verzoek voor is (en met name, waarvandaan het komt) en daarnaast nog het allerbelangrijkste: oplettendheid van de gebruiker wanneer dit geaccepteerd wordt.

Want tegen human failure valt niet op te beveiligen.
Wellicht omdat hij het net al voor zichzelf had gedaan, dan is een opvolgend berichtje nog steeds onverwacht maar het haalt het "raar" niveau niet meer. Authenticatiesystemen zijn nou eenmaal niet perfect, het komt met regelmaat voor dat ik ergens inlog en dan 5 minuten later weer opnieuw moet inloggen omdat om een of andere reden de sessie vroegtijdig is verlopen.
Ja, en de MFA-client zegt niet waarvoor het verzoek is. Dat vind ik het meest zwakke.
Hoe vaak heb je wel niet dat je Outlook app opnieuw moet verbinden omdat de policy van je organisatie zo stomzinnig streng staat dat je dit soort gedrag krijgt. Dan denk je bij jezelf welke app zit nu weer te zeiken om opnieuw in te loggen. Is het Outlook, MS Teams op de telefoon of iets anders? En als je dan niet goed kijkt is een foutje zo gemaakt. Doet niets af van de domheid van zijn actie though.
Als dit het enige admin account op dev is, wordt het misschien door meerdere mensen gebruikt?

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee