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

Door , , 72 reacties

Een inbraak op de webservers van het SquirrelMail-project in juni heeft grotere gevolgen gehad dan de beheerders in eerste instantie wilden toegeven. Enkele plug-ins blijken te zijn ge´nfecteerd met malware die wachtwoorden verzamelt.

SquirrelmailSquirrelMail is een opensourceprogramma dat onder andere door veel providers als de basis voor hun webmaildiensten wordt gebruikt. Voor uitbreiding van de applicatie kan uit ongeveer tweehonderd plug-ins worden gekozen. Aan drie daarvan blijkt bij een inbraak op de webservers, die op 16 juni plaatsvond, kwaadaardige code te zijn toegevoegd. Het gaat om sasql-3.2.0, multilogin-2.4-1.2.9 en change_pass-3.0-1.4.0.

De geïnjecteerde code steelt wachtwoorden en stuurt deze door naar een externe server. De beheerders van het SquirrelMail-project lieten na de inbraak weten niet te denken dat er met de plug-ins was geknoeid, maar op deze bewering zijn ze nu teruggekomen. Ze kunnen echter niet aangeven wanneer de aanpassing van de code heeft plaatsgevonden. De plug-in-database is enige tijd uit de lucht geweest, maar is nu weer online met versies van de betreffende plug-ins waaruit de malware verwijderd is. De Squirrelmail-beheerders raden alle gebruikers uiteraard aan om de nieuwe versies te installeren.

Moderatie-faq Wijzig weergave

Reacties (72)

Ik neem aan dat met zulke grootschalige open source projecten toch wel elke plugin wordt nagekeken? Nu geven ze aan dat de plugin's waren 'compromised', dus via directe acces op hun webserver. Hoop wel dat ze dus naast die fix van plugins ook een server nog extra hebben beveiligd.

Echter als ik het nieuws bekijk, was er op 16 juni melding van compromising, maar pas 1,5 maand later ontdekken ze de fout van de plugin. Als het onbekend is hoeveel/hoelang deze plugins hun werk hebben gedaan, lijkt me best pijnlijk.

Lijkt me in iedergeval niet gunstig voor hun reputatie :P
Ik neem aan dat met zulke grootschalige open source projecten toch wel elke plugin wordt nagekeken?
Daar zijn vaak niet de resources voor. Gesubmite nieuwe plugins worden natuurlijk wel gechecked, maar als de maker/maintainer een 'trusted' status heeft, kan dat heel oppervlakkig zijn.

Zeker als het op de download server is, omzeil je dat hele check proces, en ik denk dat er maar weinig projecten zijn die op de achtergrond monitoren welke files er aangepast worden op zo'n machine. ( database met SHA256 hashes bijhouden, etc )
Daar leg je dus wel even de vinger op een van de grootste zere plekken van opensource... wat dus ook nog steeds een hoop mensen ervan weerhoudt om opensource software of een opensource OS te gebruiken. Dergelijke plugins worden vaak binnen een community gemaakt, vaak zijn het diverse mensen die eraan hebben gewerkt. Waar de ene stopt met de ontwikkeling pakt een ander het vaak weer op en evolueert de software weer verder. Wie neemt nou de verantwoordelijkheid voor dit soort kwalijke dingen? Of beter gezegd, wie kan je er verantwoordelijk voor stellen? Je hebt nergens voor betaald, dus echte garantie oid bestaat er ook niet voor, het is geen bedrijf maar een community die dergelijke dingen maakt...

Opensource is toch zo makkelijk, zo eerlijk, zo veilig... 8)7 Ongeacht of je nou software van Apple, MS, opensource of wat dan ook gebruikt. In iedere sector zitten mensen die op meer uit zijn dan alleen een mooi stukje software releasen. Alleen is in de commerciele sector deze controle veel strenger, de opensource gemeenschap is vÚÚl kwetsbaarder voor dergelijke acties.
Trojans komen ook regelmatig in closed-software voor. Een voorbeeld:

http://www.avertlabs.com/...leaves-device-vulnerable/

En als je eens googled op 'trojan in', zul je nog duizenden andere voorbeelden vinden.
vertel me eens, hoe ga je zonder broncode controleren wat een plugin voor Outlook uitvreet? Of die handige uitbreiding op Exchange?

Niet, inderdaad. Bij opensource is het niet de vraag of, maar wanneer iemand het ontdekt, en dan wordt het probleem ook direct tot groot nieuws gemaakt zodat iedereen zijn/haar software kan controleren en fixen.

Ik gebruik nu al meer dan 10 jaar opensource, zowel prive als profesioneel, en ik ben nog nooit door zoiets getroffen.
en hoe vaak in die 10 jaar heb je de source code bekeken van de software die je hebt gedownload? Waarschijnlijk nooit..

Maar dat hoeft ook niet, want er zijn genoeg andere mensen zijn die dat doen.. Toch? Althans, dat is waar jij op vertrouwd.. Ik vertrouw er netzo op, dat er bij closed source software ook genoeg capabele mensen zijn die ervoor zorgen dat hun software naar behoren werkt en geen nare exploits bevat, natuurlijk lukt dat niet altijd.. Maar iig heb ik dan nog de zekerheid dat het zonder de source-code een stuk lastiger is om een exploit te vinden. Bij opensource loop je nou eenmaal het risico dat kwaadwillenden alle (interessante) opensource projecten aflopen en zoeken naar exploits in de code, dat vervolgens niet melden maar er gewoon grootschalig misbruik van maken...

Of zoals in het geval van squirelmail, van te voren aan een patch werken. De server hacken, de boel patchen en hun sporen uitwissen.

Bij een closed source software omgeving hangt A de source code repository niet aan het internet en B moet eerst de source code geanalyseerd worden alvoor ze een patch kunnen maken..
Persoonlijk vind ik het wel een erg makkelijke aanname dat het argument open/source weinig invloed heeft op de daadwerkelijke controle van de code. Ik weet niet hoe men achter deze keyloggers is gekomen echter bij OS bestaat tenminste nog de kans dat een externe kan zien dat er daadwerkelijk iets mis is. Sterker nog stel je merkt vreemde transfers op naar een bepaalde software en je zou de packages van bekijken die getransfered worden kun je nog steeds niet achterhalen bij closed software wat er precies aan de hand is.

Verder het vervelende van closed tov open is dat kwaadwillende nog steeds net zo goed closed projecten kunnen reverse engineeren op zoek naar fouten en deze kunnen misbruiken. Overigens net zoals kwaadwillende er misbruik van kunnen maken wordt er goed gebruik van gemaakt. Immers als je kijkt naar hoeveel bekende gaten in software bestaan van diverse projecten zul je zien dat OS beduidend minder gaten kent en dat de gaten ook beduidend sneller worden dicht gemaakt.

Een ander nadeel is dat met patches die je bv bij Windows maar ook bij OSX je maar moet hopen dat bekende gaten worden geplugged maar daarnaas kan het net zo goed voorkomen dat voor de publiek onbekende gaten worden gedicht met mogelijk grote gevolgen voor je eigen systeem. Hoevaak is het immers niet voorgekomen met Windows een patch tot gevolg had dat opeens de boel niet meer werkte?

Overigens het non-argument dat open source projecten openstaan en dat de servers voor iedereen bereikbaar zijn is eerder een positief iets. Bij closed is het een desillusie dat closed direct betekend dat de source servers veilig zijn. Dit is namelijk maar wat vaak gebleken helemaal niet zo te zijn.
Het verleden heeft inderdaad al meerdere malen aangetoond dat ook closed source software niet veilig is, maar je kan niet ontkennen dat het veel gemakkelijker is om een mogelijke exploit te vinden als je de source code bij de hand hebt.. Je hebt ook gelijk dat bij open source software iemand de moeite kan nemen om de source code te bekijken en mogelijke exploits meldt cq oplost. Wil nog niet zeggen dat dus ook gebeurd. Er zijn echter mensen die de illusie lijken te hebben dat OS per definitie veilig(er) is vanwege het feit dat ze de source code erbij krijgen. Dat is dus niet zo, beide zijn niet veilig van exploits en er valt over te twisten welke variant nu een hoger risico heeft, in ieder geval was het niet mijn bedoeling om closed source neer te zetten als veilig(er).

Het andere punt wat ik aanhaalde is dat bijna per definitie bij een open source project de code repository aan het internet gekoppeld moet zijn, anders kun je niet samen ontwikkelen.. Closed source software wordt over het algemeen niet door een community ontwikkeld maar door een (commercieel) bedrijf. Die hebben geen reden om hun repository aan het internet te koppelen.. De hack zoals die bij squirrelmail is gebeurd is in die hoedanigheid dus ook vrijwel onmogelijk. Wat overigens niet wil zeggen dat closed source repositories dus per definitie niet te hacken zijn, kan natuurlijk nog steeds als men toch de repository aan het internet heeft gekoppeld, of als men eerst een tussenliggende server hackt...
Hoe weet je zo zeker dat bij closed source software de source code niet aan het internet hangt? Dat is een veronderstelling die helemaal nergens op gebaseerd is. En ook Open Source code zul je moeten analyseren voordat je een patch kunt maken.

Graag even je huiswerk doen voordat je dit soort uitspraken doet:
http://en.wikipedia.org/wiki/Security_through_obscurity
en hoe vaak in die 10 jaar heb je de source code bekeken van de software die je hebt gedownload? Waarschijnlijk nooit..
Heel, heel, heel vaak.
Ik gebruik nu al meer dan 10 jaar opensource, zowel prive als profesioneel, en ik ben nog nooit door zoiets getroffen.
Hoewel ik het met je eens ben en deze ervaring ook zelf deel is het natuurlijk niet erg handig zoiets als argument te stellen.

Een argument gebaseerd op de ervaring van 1 persoon is namelijk niets waard.

De reactie van MicGlou is een beetje kortzichtig. Er zijn genoeg bedrijven die open source software verkopen en daarbij hun eigen garantie afgeven. Je kunt zelfs servicecontracten en alles krijgen waardoor je het hele probleem wat hij aangeeft niet hebt.

Kijk bijvoorbeeld naar bedrijven als Novell, die verkopen software grotendeels gemaakt door de community met hun eigen garantie. Perfect om te gebruiken in een zakelijke omgeving.
Opensource is toch zo makkelijk, zo eerlijk, zo veilig... 8)7 Ongeacht of je nou software van Apple, MS, opensource of wat dan ook gebruikt. In iedere sector zitten mensen die op meer uit zijn dan alleen een mooi stukje software releasen. Alleen is in de commerciele sector deze controle veel strenger, de opensource gemeenschap is vÚÚl kwetsbaarder voor dergelijke acties.
Deze aanpassing op de code is NIET door de reguliere ontwikkelaars gedaan maar door de mensen die de site gehacked hebben. Waarop de beheerders niet wel adequaat gereageerd hebben.

Download off line en onderzoek starten.
Jun 16, 2009 by Jonathan Angliss
At approximately 1700 GMT, on June 16, it was discovered that the SquirrelMail webserver had been compromised. The project administrators took immediate action to mitigate any futher compromises, locking all accounts out, and resetting critical passwords.

At this time, the SquirrelMail project administrators have shut down access to the original server, and put a temporary hold on access to the plugins. It is believed that none of the plugins have been compromised, but further investigations are still being executed.
Als je een site met closed source code hacked kan dit ook gebeuren je hacked een site en voegt een trojan to aan de originele code.

IMO ogen probeer je onterecht OSS zwart te maken.

Ik ben er van overtuigd dat als een programmeur bewust trojan of malware code in zijn code verbergt deze binnen de kotste keer geen OSS programmeur meer is.

OSS werkt heel erg op basis van vertrouwen is dit vertrouwen geschaad is. Heeft dit consequenties.

[Reactie gewijzigd door worldcitizen op 5 augustus 2009 00:22]

Je gaat er gemakshalve dan wel aan voorbij dat je bij bv Microsoft of Adobe echt wel iets meer moet doen dan een site hacken, om malware aan een stuk software toe te kunnen voegen.
Sowieso bieden closed source softwarebouwers over het algemeen geen toegang tot hun sources en/of buildomgevingen via hun websites en is het dus heel moeilijk trojans in hun sources of binaries te stoppen door een website te hacken.

Bij closed source worden trojans vaak verborgen in illegale kopieen van de software die bijvoorbeeld via p2p kanalen verspreid worden. Dan kunnen er gewoon extra binaries worden toegevoegd en kun je de install daarvan beinvloeden.
Ik heb het niet over Microsoft of Adobe maar over kleinere software bedrijven die de security niet zo goed geregeld hebben. Waar je dit redelijk ongemerkt kan doen. Als de software interessante genoeg is zullen veel mensen deze downloaden. Een trial versie van een of andere software.

Als je op de download site zou zijn en ze hebben ook een gebrekkige check op de code zou je een vergelijkbare versie als onderstaande er kunnen neerzetten of dusdanig aanpassen dat er trojan in zit.
http://techworld.nl/techn...7-rc-bevatten-trojan.html

Aan deze link zie je ook hoe onveilig het is om illegale software te downloaden. Maar daar bekommert zich het grootste deel van de mensen niet om. Je kunt er van uit gaan dat een groot deel van de gedownloade illegale software malware of trojans bevat.

En een link voor grijze Mac software met een exploit.
http://www.intego.com/news/ism0902.asp

[Reactie gewijzigd door worldcitizen op 5 augustus 2009 00:21]

Bij een closed source stuk software komen dergelijke fouten net zo vaak of vaker voor, en kun je ook helemaal niemand verantwoordelijk stellen.
Net zo vaak? Waar haal je die wijsheid vandaan?
Ik denk dat de controle op de kwaliteit en de inbreng van ontwikkelaars bij closed software beter geborgd is dan bij Open Source. Dit komt vooral omdat de controle van de mensen die code binnenbrengen beter is.

Wat ik in dit verhaal ook apart vind is dat ondanks het feit dat de code open is, het toch nog anderhalve maand heeft geduurd voordat er iemand achter het probleem is gekomen. Kennelijk zijn er toch niet zoveel gebruikers die de plugins testen of de gewijzigde code doornemen...
Geen resources voor? Het standaard OSs verhaal is altijd inclusief zoiets als dit: de hele wereld ontwikkelt mee, dus patchen en ontwikkeling gaat sneller dan bv closed source software.
In de praktijk hebben de meeste OSS projecten maar een beperkt aantal coders. Het is meer de optie dat als die ermee stoppen, iemand anders ermee door kan gaan wat OSS zo interessant maakt.
Wij wachten af. Wie doet tegenwoordig tty? Vaak sterven OSS projecten bij gebrek aan mankracht of kennis zodra de originele programmeur iets anders gaat doen. Al zal tty het wel overleven.
De hele wereld ontwikkelt mee.. ik niet? jij niet? misschien zitten er minder mensen op dit open source project als dat er aan exchange werken.

open source zegt niks over het aantal mensen dat er aan werken.
Als wat jij zegt voor alle open-source projecten zou gelden, dan zou dit een mega-probleem zijn voor dergelijke software-projecten. Nu heeft het vertrouwen in de OpenSource-community met dit geval ook een stevige deuk opgelopen, maar zijn de beheerders van dit project toch het meest schuldig.

Ik zal iig verder geen vertrouwen meer leggen in Squirrelmail en alle projecten die door deze dames en heren worden gecoordineerd. Dit is een schande voor de community en geeft eens te meer aan dat er ook naar de competentie moet worden gekeken van de deelnemers.
... maar zijn de beheerders van dit project toch het meest schuldig.
De beheerders hebben hier geen schuld aan, de gene die de keyloggers in de plugins hebben gezet zijn schuldig, niemand anders, de beheerders kunnen messchien een beetje nalatig zijn geweest van hun kant, maar als je kijkt dat ze dit alles gratis doen, en met erg beperkte resources werken verlies ik geen vertrouwen in hun...

nogmaals, hackers zijn de schuldigen, niet de gene die er het meest geschaad door is!
Dit verhaal heeft niet met het ontwikkelmodel van OSS te maken, dit is geen ontwikkel maar een beheer fout.

Hier is iets totaal anders aan de hand. De site is gehacked. De beheerders hebben waarschijnlijk niet eens cross checks gedaan op basis van hashes (md5sum etc) of een diff met de gebackupte code. Dan hadden ze in iedergeval gezien met welk pakket er geknoeit was. Deze hadden als voorzorg even niet meer downloadable gemaakt moeten hebben.

IMO is dit een blunder van de bovenste plank van de beheerders van het squirrelmail project. Hopelijk hebben ze hun lesje geleerd. En zullen ze voorzichtiger zijn.


Uit de informatie op de squirrelmail site blijkt dat ze volgens het boekje gehandeld hebben. Ze hebben de download off line gehaald en zijn een onderzoek gestart, precies zoals het hoort.
Jun 16, 2009 by Jonathan Angliss
At approximately 1700 GMT, on June 16, it was discovered that the SquirrelMail webserver had been compromised. The project administrators took immediate action to mitigate any futher compromises, locking all accounts out, and resetting critical passwords.

At this time, the SquirrelMail project administrators have shut down access to the original server, and put a temporary hold on access to the plugins. It is believed that none of the plugins have been compromised, but further investigations are still being executed.
De beheerders van het SquirrelMail-project lieten na de inbraak weten niet te denken dat er met de plug-ins was geknoeid, maar op deze bewering zijn ze nu teruggekomen. is erg suggestief tov It is believed that none of the plugins have been compromised, but further investigations are still being executed.

Dit kan ook met een closed source pakket gebeuren waar je laconieke beheerders hebt. Daar kunnen ze malware bij de code voegen.

[Reactie gewijzigd door worldcitizen op 5 augustus 2009 00:17]

Dat ben ik dus niet met je eens aangezien er voor closed source software geen reden is om hun source code repository aan het internet te koppelen. Lukt het een hacker dan toch om de source code te kunnen wijzigen dan zal ie toch eerst de code moeten analyseren om te bepalen waar en hoe een trojan toe te voegen. Bij open source kan ie dat op z'n gemakje thuis doen...

Ik vind het ook een beetje kortzichtig om het een blunder van de bovenste plank te noemen want als je gehacked bent heb je geen idee wat er precies gebeurd is tijdens die hack. Je hebt eigenlijk geen andere keuze als het terugzetten van een back-up. Stel dat je er achter komt dat je gehacked bent, wanneer ben je dan gehacked? Deze hack had de bedoeling om malefide code permament toe te voegen, ze zullen ongetwijfeld hun uiterste best hebben gedaan om de hack niet op te hebben laten vallen.
Mee eens, men had de boel tot nader orde offline moeten halen en een backup moeten terugzeggen. Dat is indertijd bij Debian ook gebeurd toen daar een van de machines gehacked bleek.
En bij Squirrelmail ook als ik de site correct interpreteer:
Jul 31, 2009 by Jonathan Angliss
We apologies for the extended downtime for the SquirrelMail plugins repository, and some of the SquirrelMail site documentation.
[...]
Plugins Availability
As of now, the plugins are available to download again. I personally apologies for the extended outage of this, as I know some of you have been eager to get these back up and running again. Once again, if you notice any issues with the site, feel free to email.
SECURITY: SquirrelMail Webserver Compromised
Jun 16, 2009 by Jonathan Angliss
At approximately 1700 GMT, on June 16, it was discovered that the SquirrelMail webserver had been compromised. The project administrators took immediate action to mitigate any futher compromises, locking all accounts out, and resetting critical passwords.
Ik kan dit niet anders interpreteren dan: 'sorry dat de plugins zo lang onbereikbaar zijn geweest, maar vanaf nu staan ze er weer beschikbaar'

[Reactie gewijzigd door aikebah op 4 augustus 2009 20:19]

Klopt, aldus Cor Bosman van XS4ALL (sponsor van de hardware van Squirrelmail):
Let wel, in die maand hebben ze de plugins niet online gezet juist omdat ze niet zeker wisten of er mee geknoeid was. De gebruikers van squirrelmail vonden dat zo irritant dat ze zelf archieven van plugins zijn gaan opzetten, maar gelukkig lieten ze zich daar niet door beinvloeden en hebben ze rustig de tijd genomen om dat uit te zoeken.

Ze wisten wel ongeveer wanneer het gebeurd moet zijn, en dan kan je dus code vergelijken en zien wat er gewijzigd is. Eigenlijk moeten ze alle plugins ook in source control zetten, dan weet je het zeker. Want sourceforge is natuurlijk uitgezonderd van hacks :)
Oftewel: zodra ze het wisten zijn de plugins offline gehaald.
Dat ben ik dus niet met je eens aangezien er voor closed source software geen reden is om hun source code repository aan het internet te koppelen. Lukt het een hacker dan toch om de source code te kunnen wijzigen dan zal ie toch eerst de code moeten analyseren om te bepalen waar en hoe een trojan toe te voegen. Bij open source kan ie dat op z'n gemakje thuis doen...
De source code repositry is niet geraakt. "Alleen" de downloadable repositry.

Zie in op de squirrelmail site.
The compromise of this server does not include a compromise of the source control, which is hosted on a separate repository managed by SourceForge.
Je hoeft echt niet de source code te hebben om kwaadaardige code toe te kunnen voegen.

Lees dit artikel maar eens.

IMO zijn te veel mensen na´ef en denken ze je alleen kwaadaardige code kunt toevoegen aan source code, niet is minder waar.

Denk hier ook over na als je grijze code binnen hengelt via p2p of news groepen. Niemand zal je garantie geven als je grijze versie van Windows een keylogger bevat, waardoor ongewild informatie van jouw op straat is gekomen.
Ik vind het ook een beetje kortzichtig om het een blunder van de bovenste plank te noemen want als je gehacked bent heb je geen idee wat er precies gebeurd is tijdens die hack. Je hebt eigenlijk geen andere keuze als het terugzetten van een back-up. Stel dat je er achter komt dat je gehacked bent, wanneer ben je dan gehacked? Deze hack had de bedoeling om malefide code permament toe te voegen, ze zullen ongetwijfeld hun uiterste best hebben gedaan om de hack niet op te hebben laten vallen.
Als ze de back-up terug gezet hadden dan zou er geen probleem geweest zijn.

Natuurlijk weet je niet precies wat er gebeurt is gedurende de hack. Maar ze wisten dat ze gehackt waren. Op dat moment is alle code die de hackers konden benaderen verdacht. Dat betekend dat je deze grondig moet checken.

Wat ze zie ik gedaan hebben, na nog een keer goed gelezen te hebben op squirrelmail:
Jun 16, 2009 by Jonathan Angliss
At approximately 1700 GMT, on June 16, it was discovered that the SquirrelMail webserver had been compromised. The project administrators took immediate action to mitigate any futher compromises, locking all accounts out, and resetting critical passwords.

At this time, the SquirrelMail project administrators have shut down access to the original server, and put a temporary hold on access to the plugins. It is believed that none of the plugins have been compromised, but further investigations are still being executed.
Ze hebben precies volgens het boekje gehandeld.
Niet om Open Source naar onderen te trappen natuurlijk, want het heeft z'n voordelen natuurlijk..... maar je ziet hier duidelijk 1 van de nadelen van Open Source. Open Source programmeurs zitten over de gehele wereld, en de schrijver van de ene plug-in kan in Japan zitten, de ander in Brazilie, en weer een ander in Oostenrijk.

Bij een commercieel bedrijf zoals Microsoft (maar ook RedHat), heb je programmeur afdelingen, en dan test-afdelingen, waarbij als in het testen e.e.a. naar voren komt, het weer terug wordt gestuurd naar de programmeur afdeling om e.e.a aan te passen. Bij Open Source programmeurs, die vaak alleen werken en alles in hun vrije tijd doen, is dat niet het geval, en kan er wel eens voorkomen dat er iets door de vingers glipt.....

Als je als "maintainer" van een bepaald pakket een bepaalde status krijgt, wordt het werk van een dergelijke programmeur vaak niet/nauwelijks getest, omdat deze de afgelopen 7 jaar altijd gewoon degelijk programmeur werk afleverde...... Het komt van "SuperDave" (verzonnen), dus het is kwaliteit. Echter, als het vriendje van het broertje van SuperDave zo slim is om zijn wachtwoord af te kijken als ie het intikt, en dat wachtwoord vervolgens ergens anders gebruikt om wat vervelende code te uploaden..... en dat dan geaccepteerd wordt (WANT SuperDave is de bomb en levert NOOIT slechte code), dan kan dat erg fout aflopen.

Om maar eens met een quote te gooien die ik ergens op het web vond: "The good thing about Open Source is that everyone can work on it. The bad thing about Open Source is that everyone can work on it."

[Reactie gewijzigd door maartena op 4 augustus 2009 22:13]

Niet om Open Source naar onderen te trappen natuurlijk, want het heeft z'n voordelen natuurlijk..... maar je ziet hier duidelijk 1 van de nadelen van Open Source. Open Source programmeurs zitten over de gehele wereld, en de schrijver van de ene plug-in kan in Japan zitten, de ander in Brazilie, en weer een ander in Oostenrijk.
Voor closed source zit de een ontwikkelaar voor een software project in de VS de andere in India. Er zijn veel bedrijven die de ontwikkeling van software gedeeltelijk uitbesteden aan India of een ander lagelonenland.
Bij een commercieel bedrijf zoals Microsoft (maar ook RedHat), heb je programmeur afdelingen, en dan test-afdelingen, waarbij als in het testen e.e.a. naar voren komt, het weer terug wordt gestuurd naar de programmeur afdeling om e.e.a aan te passen. Bij Open Source programmeurs, die vaak alleen werken en alles in hun vrije tijd doen, is dat niet het geval, en kan er wel eens voorkomen dat er iets door de vingers glipt.....
Voor de grotere projecten heeft OSS verreweg de grootste test afdeling die er bestaat. Ieder groot OSS project heeft een development en een stable status. Voordat een pakket stable is hebben honderden/duizenden mensen het pakket getest.

Deze testers maken een bugreport waar de ontwikkelaars weer naar kijken.
Als je als "maintainer" van een bepaald pakket een bepaalde status krijgt, wordt het werk van een dergelijke programmeur vaak niet/nauwelijks getest, omdat deze de afgelopen 7 jaar altijd gewoon degelijk programmeur werk afleverde...... Het komt van "SuperDave" (verzonnen), dus het is kwaliteit. Echter, als het vriendje van het broertje van SuperDave zo slim is om zijn wachtwoord af te kijken als ie het intikt, en dat wachtwoord vervolgens ergens anders gebruikt om wat vervelende code te uploaden..... en dat dan geaccepteerd wordt (WANT SuperDave is de bomb en levert NOOIT slechte code), dan kan dat erg fout aflopen.
Dit zelfde verhaal geldt ook voor commerciŰle software.

Ze gaan binnen commerciŰle bedrijven echt niet testen op kwaadaardige code. En als ze het al doen als je op iets uit bent zorg je er gewoon voor dat je kwaadaardige code niets doet tot datum x, of niet in netwerk y, of een licentie key ongelijk aan x heeft etc.

Stel dat Superdave die collega is waar een andere collega een schurft hekel aan heeft. Hij werkt er al vele jaren heeft altijd perfecte code die altijd op tijd af is. Altijd de bonus krijt en de hoogste beoordeling.Terwijl de collega maar ploetert en de code net niet op tijd af heeft. En nooit ene bonus of een goede beoordeling krijgt. Hij heeft het password van Dave weten bemachtigen, aangezien hij ook aan de zelfde pakketten werkt heeft hij inzicht in de alle code. Daarom schrijft hij een stukje kwaadaardige code die op de naam van Dave toegevoegd wordt. Aangezien Superdave vertrouwt wordt valt het niet op.
Om maar eens met een quote te gooien die ik ergens op het web vond: "The good thing about Open Source is that everyone can work on it. The bad thing about Open Source is that everyone can work on it."
Met de nadruk op can. Het is niet zo dat je zomaar ontwikkelaar van een pakket kan worden. Je zult deze rechten moeten krijgen, het is niet zo dat iedereen mee kan ontwikkelen.

IMO kijk je onterecht veel te negatief aan tegen OSS.
Dat is behoorlijk nasty. Een infectie op en server hier of daar kan natuurlijk veel meer interessante informatie opleveren dan een infectie van een enkele pc.
Dit voorval zal heel wat beheerders aan het denken zetten. Uiteindleijk moet je als beheerder die opensource en/of free software ook maar vertrouwen. Dat iedereen alles kÓn controleren betekent niet dat het gebÚurt... wellicht een krachtig argument voor "closed " software.
Ook angstaanjagend is het dat het meer dna ene maand heeft geduurd voor de besmetting is opgemerkt; dat heeft vermoedelijk voor een grote verspreidign gezorgd.
Uiteindleijk moet je als beheerder die opensource en/of free software ook maar vertrouwen. Dat iedereen alles kÓn controleren betekent niet dat het gebÚurt... wellicht een krachtig argument voor "closed " software.
En sinds wanneer kan closed source niet worden gehackt/misbruikt? Het staat mij bij dat Sony nog eens met rootkits heeft liggen klooien...

Met open source heb je nog de mogelijkheid om zelf de code te controleren op dit soort lekken, met closed source is dat vrijwel onmogelijk. Met open source heb je dus ook de mogelijkheid om een lek te fixen, weer iets wat met closed source onmogelijk is.

Dat vrijwel niemand de source induikt, is weer een ander verhaal.
Als je een binary download kan je nog zo lang de publieke source zoeken, die trojan vind je niet - je hebt degene die de binary compiled nou eenmaal vertrouwd.
Je kunt toch zelf compilen?

Moet je nog wel even de tijd zien te vinden om alle code te controleren, dat zal vaak nog wel een probleemp worden.
En eerst even een paar opleidingen volgen en wat werkervaring op doen zodat je ook snapt wat er staat.
Met open source heb je nog de mogelijkheid om zelf de code te controleren op dit soort lekken, met closed source is dat vrijwel onmogelijk
Closed source maakt het vrijwel onmogelijk, maar open source maakt het praktisch onmogelijk.

Het is simpelweg niet praktisch haalbaar om van een groot project de hele source uit te pluizen en te controleren op trojans, exploits en beveiligingslekken. Niet alleen kost het enorm veel tijd, maar ook nog eens kostbare tijd doordat degene die de taak uitvoert van goede huize moet komen so to speak.

Bij een klein tooltje gaat het wel op, maar bij grotere projecten is het vaak praktisch niet te doen.
Het is simpelweg niet praktisch haalbaar om van een groot project de hele source uit te pluizen en te controleren op trojans, exploits en beveiligingslekken.
Kortom, dit heeft weer niets te maken met open of closed source, maar alles met de omvang van de source.

Er wordt (te vaak) geroepen dat open source onveilig zou zijn, maar het kan niet onveiliger zijn dan closed source. Bij closed source heb je zelfs in theorie geen toegang tot de source, die kun je dus zelfs in theorie niet controleren. Het verhaal veilig/onveilig is eigenlijk geen issue bij de keuze tussen open of closed source en zal al helemaal niet in het voordeel van closed source uitvallen.
Er wordt (te vaak) geroepen dat open source onveilig zou zijn
Vreemd is dat, dat zie ik nou nooit iemand roepen. Ook niet vanuit het closed source kamp.

Wat ik wel te vaak geroepen zie worden, is dat open source veilig zou zijn.
Bij closed source kan dit natuurlijk net zo goed voorkomen. Het nadeel dan is dat niet iedereen het kßn controleren en dat je dus effectief aangewezen bent op een veel kleinere groep mensen die het probleem kunnen constateren en oplossen.

Dit soort voorvallen maken vooral dat beheerders beter moeten nadenken over hoe ze hun server/netwerk beveiligen. Niet alleen voor connecties naarbinnen toe, maar ook naarbuiten toe.

Schokkend is het zeker. Je zou verwachten dat de community meer doet dan domweg de software installeren en er vanuit gaan dat het goed werkt.
Als ze public key encryptie hadden gebruikt (zoals b.v. debian doet met packages), dan had *iedereen* geweten dat de ge´nstalleerde updates fout waren.
Als ze public key encryptie hadden gebruikt (zoals b.v. debian doet met packages), dan had *iedereen* geweten dat de ge´nstalleerde updates fout waren.
volgens mij moet je bij squirrelmail die plugins handmatig downloaden en updaten. Dus die vlieger gaat niet op. (de meeste projecten leveren wel een lijst van MD5/SHA256 mee, maar wees eerljjk: vrijwel niemand controlleerd die dingen)

[Reactie gewijzigd door arjankoole op 4 augustus 2009 13:04]

Klopt. En zelfs al zou je ze controleren. Die checksums staan vaak in een simpel tekstbestand. Op het moment dat een hacker in staat is zo'n plugin-script aan te passen, dan is hij/zij ook wel in staat om een nieuwe hash te plaatsen.
Een hacker kan ook een nieuwe hash plaatsen. Daarom moet je ook meerdere bronnen hebben.

Het is nog wel eens gebeurd dat ik perse de nieuwe slackware binnen 1 dag wilde hebben. Dus torrenten maar. Zit netjes een hash bij. Maar echt dat ik die eerst even in google gooi en check of betrouwbare websites die hash ook kennen.
Het gaat inderdaad om vertrouwen. Je moet de maker(s) van de software vertrouwen dat ze er niks in gemeens in stoppen, maar je moet ook kunnen garanderen dat er niet tijdens het transport van de developer naar de gebruiker gerommeld wordt met de code, en dat is wat hier aan de hand is.

MD5/SHA1 hashes, public key signatures zijn een *zeer* goed middel tegen dit soort aanvallen.
Ben ik benieuwd wat dit nieuwsbericht met de populariteit van SquirrelMail gaat doen... Het lijkt me moeilijk om jezelf van een slechte reputatie te kunnen ontdoen.
Ben ik benieuwd wat dit nieuwsbericht met de populariteit van SquirrelMail gaat doen... Het lijkt me moeilijk om jezelf van een slechte reputatie te kunnen ontdoen.
het OpenSSH project had ook korte tijd een getrojaande versie staan, dat heeft, ondanks de hogere security gevoeligheid eigelijk geen gevolgen gehad voor de populariteit.

Toegegeven, er zijn weinig alternatieven voor OpenSSH :)

Mailwachtwoorden zijn vaak geen echte accounts, maar virtuele (althans, als je slim bent), dus de impact is niet krankzinnig hoog. Maar desalnietemin zal er hier en daar wel een wachtwoord change run komen. (beter safe then sorry)
Nou ja de andere kant is natuurlijk dat minimaal 70% van de mensen exact de zelfde login/wachtwoord combo gebruikt voor het inloggen op hyves, facebook, WoW en tientallen andere sites en software programma's, dat is wel zo makelijk dan hoef je niet zo veel wachtwoorden te onthouden.

Wachtwoorden stelen heeft veel al niets te maken met de slecht beveiligde service waar ze gestolen worden of in dit geval de mailbox waar ze toegang to bieden het gaat eerder om de mails in de mailbox die andere wachtwoorden bevatten dan wel mensen die de zelfde login en wachtwoord combo gebruiken om toegang te krijgen tot andere dingen zo als online games, bank zaken en meer van dat soort dingen... dat is waar echt geld mee te verdienen valt, een mailbox kan maar zelden echt tot grote inkomsten leiden ten zij je precies weet van wie de mailbox is.
Ik heb standaard 3 wachtwoorden. 1 wachtwoord voor "high security" zaken zoals banken, credit cards etc.... die gebruik ik dan ook nergens anders en heeft een grote complexiteit, inclusief aparte tekens etc..... Een "medium security" wachtwoord, meestal voor email, bekende sites (GoT ook bijv), etc..... en een "low security" wachtwoord, die ik gebruik op sites die gevoelig zijn voor kraken, zoals PHPBB forums, PHPNuke sites, Joomla sites, etc.... dat zijn meestal sites die het eerst door "scriptkiddies" worden aangevallen als er weer eens een exploit wordt gevonden, en beheerders updaten meestal niet meteen hun software.

Ik heb ook nog een twee andere wachtwoorden "achter de hand", zo gebruik ik op mijn bedrijf twee compleet andere wachtwoorden.

Tja.... als je je online bankieren wachtwoord hetzelfde laat als een of andere Manga-fan-PHPBB board, dan is het vragen om problemen natuurlijk. ;)
Sjah ik wil wel even zeggen dat er wordt gemeld dat de plugins deze malware bevatten en niet de applicatie zelf

Al met al nog steeds geen goed nieuws voor ze idd maar het pakket zelf blijft onbesproken
Auw, da's vervelend. Daar gaat het vertrouwen. Hopelijk bouwen ze dat snel weer op. :/
Vertrouwen komt te voet en gaat te paard.
Is er dan helemaal MD5 check o.i.d. die gedaan wordt op de plugin code tijdens installatie? Of zijn de md5 hashes samen met de code aangepast?
Het lijkt me dat de checksums ook aangepast zijn ja, anders zou je genoeg hints krijgen dat er iets mis zou moeten zijn.
En men gaat natuurlijk achter die externe server aan?
Of daar wat is te achterhalen?
Of staat-ie soms in Nigeria? (want dan kun je het wel schudden)
En als alles nu eens mooi ergens op een pastebin account wordt geplaats, eigenlijk publiek zichtbaar, maar nooit door meer dan 10ip's bekeken (wegens nergens naar gelinked)?

Als de 'hacker' dan eventjes een publiek netwerk gebruik (liefsts groot en niet te heel dicht bij huis, vb een unief?) bij het binnenhalen van de data. Dan is hij toch zo goed als onvindbaar...

Zo zou ik het toch aanpakken :p
Ik neem aan dat ze dat dan wel snel na het ontdekken bekend hebben gemaakt. Dat kan anders ook niet, want zoiets laat je toch ook niet gewoon zitten met het gevaar dat er ontzettend veel wachtwoorden worden gestolen.
Populariteit zal inderdaad wel achteruit gaan.
Hmm... niet zo best dit. Maar een voorzichtige/verstandige systeem beheerder heeft dit pakket niet geupdate nadat bekend werd dat de hack geweest is. Je weet maar nooit namelijk en een maand of 2 Ó 3 wachten is in dit geval beter om even af te wachten of inderdaad alles in orde is.
Logische keuze die plugins. Ze hebben al te maken met passwords, dus het zal wat langer duren voor men merkt dat het kwaadardig is.
jammer weer dat een stel hackertjes de boel weer moeten verzieken voor een mooi initiatief als dit. Hopelijk worden ze gepakt en kan men snel de problemen verhelpen.
Het is inmiddels al een miljoenen industrie hoor waar diverse criminele organisaties ook al veelvuldig gebruik van maken. Het mag voor hun dan wel korte termijn denken zijn om zoveel mogelijk geld binnen te harken.

Op lange termijn zorgen zij er ook voor dat de 'machtswellustelingen' alleen maar meer aanleidingen krijgen om vrij internet te bestrijden. Vrij internet staat redelijk op de tocht en binnen tien jaar zullen we nog een traantje wegpinken waar het nou precies fout is gegaan.
Hackers zijn er en zullen er ook altijd blijven of het nu uit financiŰle gedrevenheid komt, kwajongensstreken of ontwrichten van een organisatie of land. Daar moet je vanuit gaan als je een site beheerd. Net als dat code altijd exploitable is.

Het is vaak genoeg aangetoond dat totale controle onmogelijk is en zal zijn.

Je moet zorgen je je eigen zaakjes zo goed mogelijk geregeld hebt. En dan kan het nog steeds fout gaan, maar doordat je het goed geregeld hebt kun je de schade zoveel mogelijk beperken.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True