GitHub-pagina Gentoo Linux gehackt via wachtwoord beheerder
De GitHub-pagina van Gentoo Linux kon vorige week worden gehackt omdat één van de beheerders een voorspelbaar wachtwoordschema gebruikte. De aanvaller had een wachtwoord van de beheerder op een andere website buitgemaakt.
Dit wachtwoord was via een bepaald schema opgesteld en zorgde er naar alle waarschijnlijkheid voor dat ook het wachtwoord voor de GitHub-pagina kon worden geraden. Sommige mensen maken gebruik van bepaalde schema's om hun wachtwoorden te onthouden. Het kan dan bijvoorbeeld gaan om "Wachtvoord voor website A", "Wachtwoord voor website B" en "Wachtwoord voor website C". Zodra een aanvaller één van deze wachtwoorden bemachtigt is het eenvoudig om ook de andere wachtwoorden te raden. Beveiligingsexperts raden daarom het gebruik van dergelijke schema's af.
Nadat er toegang was verkregen plaatste de aanvaller kwaadaardige code op de GitHub-pagina. Het ging om gentoo/gentoo, gentoo/musl en gentoo/systemd. Deze code was alleen aanwezig op de GitHub-pagina en niet op de repositories die Gentoo zelf host. De kwaadaardige code probeerde via "rm -rf" data van gebruikers te verwijderen. Volgens de Gentoo-ontwikkelaars is deze code vanwege verschillende technische maatregelen waarschijnlijk niet door eindgebruikers uitgevoerd.
Vanwege het incident was de GitHub-pagina vijf dagen onbereikbaar. Inmiddels is de pagina weer hersteld. De Gentoo-ontwikkelaars hebben nu een analyse en tijdslijn van het incident online gezet, alsmede wat er goed en verkeerd ging. Volgens de ontwikkelaars gingen er verschillende dingen verkeerd. Zo was de eerste communicatie onduidelijk en werd er niet goed gecommuniceerd hoe gebruikers konden controleren dat ze waren getroffen. Daarnaast was er geen back-up van de Gentoo GitHub Organization detail en was de systemd-repository niet gemirrord van Gentoo, maar direct op GitHub opgeslagen. Wat wel goed ging was de aanwezigheid van audit-logs, het verwijderen van het gehackte account en het snel reageren op het incident.
Maar voor iets als GitHub, je bank en DigID natuurlijk niet.
Maar voor iets als GitHub, je bank en DigID natuurlijk niet.
Er is van alles mis mee. Dat weet je zelf best.
Maar voor iets als GitHub, je bank en DigID natuurlijk niet.
Er is van alles mis mee. Dat weet je zelf best.
Ach weet je wat het is, "security experts" weten voor iedere keuze van een wachtwoord wel aan te geven dat het
slecht is. Ze kunnen beter stoppen met die tijdverspilling en een nieuw systeem verzinnen wat niet zo inherent
slecht is als een wachtwoord kennelijk is.
ha maar gentoo heeft nog nooit zo snel gecompileerd na deze update :P.
Met iets anders zal je bij Linux in de regel weinig succes hebben.
Maar voor iets als GitHub, je bank en DigID natuurlijk niet.
Er is van alles mis mee. Dat weet je zelf best.
Ach weet je wat het is, "security experts" weten voor iedere keuze van een wachtwoord wel aan te geven dat het
slecht is. Ze kunnen beter stoppen met die tijdverspilling en een nieuw systeem verzinnen wat niet zo inherent
slecht is als een wachtwoord kennelijk is.
Mee eens. Maar de meeste experts zijn het er wel over eens dat dit echt geen veilige keuze is. Het verbaast mij dan ook dat er bij Gentoo nog zo met wachtwoorden wordt om gegaan. Jammer, dat mensen van dit niveau zich zo lui opstellen. Ik mag er toch vanuit gaan dat deze beheerder wist dat hij een risico liep. Als dit niet zo is, dan zakt mijn broek echt af.
Ik vind dat Gentoo zich goed onderscheid in het oerwoud aan Distributies. Maar hiermee doet deze beheerder wel flink afbreuk aan mijn vertrouwen in Gentoo als organisatie en in mijn vertrouwen van Gentoo als distributie.
Maar voor iets als GitHub, je bank en DigID natuurlijk niet.
Er is van alles mis mee. Dat weet je zelf best.
Ach weet je wat het is, "security experts" weten voor iedere keuze van een wachtwoord wel aan te geven dat het
slecht is. Ze kunnen beter stoppen met die tijdverspilling en een nieuw systeem verzinnen wat niet zo inherent
slecht is als een wachtwoord kennelijk is.
Misschien heeft dat echt geen K L O T E te maken met security experts maar meer met software ontwikkelaars die apps door mensen - business hun strot dauwen.
Wat denk jij wat leading is in het echte bedrijfsleven; business of security.. *ruffles* Wie denk je dus dat praktisch uitmaakt hoe identificatie en authenticatie wordt geregeld. ding, ding.. we have a winner; de business omdat 'hun' applicaties anders niet meer werken. Weinigen bedrijfstakken zijn ingericht waarbij security werkelijk een blocking factor kan zijn in een project.
En nee ik bedoel het niet op laag operationeel niveau als een operating system logon.
het enige wat wij (security) kan is .. bijsturen
groeten,
Eminus
Maar voor iets als GitHub, je bank en DigID natuurlijk niet.
Er is van alles mis mee. Dat weet je zelf best.
Ach weet je wat het is, "security experts" weten voor iedere keuze van een wachtwoord wel aan te geven dat het
slecht is. Ze kunnen beter stoppen met die tijdverspilling en een nieuw systeem verzinnen wat niet zo inherent
slecht is als een wachtwoord kennelijk is.
Misschien heeft dat echt geen K L O T E te maken met security experts maar meer met software ontwikkelaars die apps door mensen - business hun strot dauwen.
Wat denk jij wat leading is in het echte bedrijfsleven; business of security.. *ruffles* Wie denk je dus dat praktisch uitmaakt hoe identificatie en authenticatie wordt geregeld. ding, ding.. we have a winner; de business omdat 'hun' applicaties anders niet meer werken. Weinigen bedrijfstakken zijn ingericht waarbij security werkelijk een blocking factor kan zijn in een project.
En nee ik bedoel het niet op laag operationeel niveau als een operating system logon.
het enige wat wij (security) kan is .. bijsturen
groeten,
Eminus
Dan doe je toch iets niet goed want als je de security zo inricht dat het een business enabler wordt i.p.v. een disabler (helaas zitten nog veel te veel security mensen op het niveau'tje mag niet) dan zit je als security expert echt wel aan tafel vanaf de start van een project. Hoe serieus wil je genomen worden als security? Misschien moet je eens een excercitie doen naar wie je werkelijke klanten zijn en wat voor toegevoegde waarde je voor hen genereert. Als je alleen maar met blokkerende zaken aankomt, die geen rekening houden met de business wensen, dan is het wel duidelijk dat je dan eerder een last wordt ervaren dan iemand die de business serieus een voordeel kan leveren. Invloed kun je ook generen door goede en bruikbare adviezen te geven..
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.