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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
