Hackers maken wachtwoorden buit bij Proserve via Plesk-lek
Inloggegevens van Proserve-hostingklanten blijken in de afgelopen weken te zijn gestolen via een lek in serverbeheertool Plesk. Het lijkt aanvallers te zijn gelukt om op sommige servers van het Nederlandse hostingbedrijf ddos-tools te installeren.
Proserve levert hostingdiensten aan particulieren, bedrijven en andere hostingbedrijven, en heeft naar eigen zeggen ruim 4500 servers in beheer. Het bedrijf, dat sinds 2000 actief is en zichzelf 'een van de grotere spelers' op de Nederlandse markt noemt, is in de afgelopen weken het slachtoffer geworden van hackers, waarbij alle wachtwoorden uit de Plesk-database van diverse servers zijn gestolen.
Plesk is een beheertool voor servers en maakt het mogelijk om een domein via een webinterface te beheren. Volgens Proserve hebben de aanvallers alle klantgegevens uit de getroffen databases ontvreemd. Het zou hierbij gaan om reseller-, client- en domeingegevens, ftp-wachtwoorden, databaselogins en maillogins van alle bijbehorende domeinnamen.
De aanvallers zijn het systeem binnengekomen via een ernstig lek in Plesk, waarvoor Proserve zijn klanten enkele weken geleden al had gewaarschuwd. Hoewel het hostingbedrijf voor diverse klanten de beschikbare updates heeft geïnstalleerd, lijkt het erop dat niet alle klanten die geen serviceovereenkomst met het bedrijf hebben dat zelf hebben gedaan. "Helaas moeten wij concluderen dat voor een aantal klanten het lek al is misbruikt voordat de servers zijn geüpdatet", aldus Proserve.
Het is niet bekend bij hoeveel servers de aanvallers er in zijn geslaagd inlogggevens te bemachtigen. Omdat het Plesk-lek al langer bekend was, kan Proserve niet uitsluiten dat het eerder is gebeurd. De aanvallers hebben de buitgemaakte gegevens misbruikt door ddos-tools op enkele servers te installeren. Hiertoe zijn Perl-bestanden op de servers geplaatst en cronjobs aangemaakt die de servers met grote regelmaat misbruiken om Facebook via poort 53 te ddos'en. Het hostingbedrijf kan niet uitsluiten dat ook op andere manieren misbruik is gemaakt van de inloggegevens.
Overigens had Proserve eerder deze maand ook al te maken met een inkomende ddos-aanval. Het is niet duidelijk of deze twee aanvallen verband houden met elkaar. Deze eerste golf van ddos-aanvallen blijkt bijzonder krachtig te zijn geweest. In totaal werd meer dan 10Gbps op het netwerk van Proserve afgevuurd; de zwaarste aanval die Tweakers.net ooit te verduren heeft gekregen was ongeveer 7Gbps.
De eerste ddos-aanvallen lijken gericht te zijn geweest tegen hostingbedrijf KnownSRV, dat via een reseller diensten afneemt bij Proserve. Om de aanval uiteindelijk te stoppen, heeft Proserve besloten zijn dienstverlening aan deze reseller te staken en al het netwerkverkeer naar de servers van dat bedrijf te blokkeren, zo blijkt uit een verslag dat Proserve naar zijn klanten heeft gestuurd.
KnownSRV heeft zijn klanten inmiddels van de problemen op de hoogte gebracht. Het bedrijf heeft een nieuw datacenter gevonden om zijn servers onder te brengen. Dit datacenter is op de hoogte gesteld van de problemen en zegt genoeg capaciteit te hebben. Shared hostingaccounts van KnownSRV worden ondergebracht bij Evoswitch.
Reacties (71)
Ik vind dat wel heel kwalijk, je was dus op de hoogte van de exploit, maar vervolgens niet patchen. Beetje vergelijkbaar met je weet dat je deur kapot is, maar geen nieuwe willen kopen.De aanvallers zijn het systeem binnengekomen via een ernstig lek in Plesk, waarover Proserve zijn klanten enkele weken geleden al had gewaarschuwd.
In dat geval, ook gewoon de kosten die er gemaakt zijn/schade die geleden is, op de klanten gaan verhalen die geen gehoor gaven aan het bericht.
[Reactie gewijzigd door Hatsjoe op dinsdag 6 maart 2012 09:02]
Paar regels extra lezen:[...]
Ik vind dat wel heel kwalijk, je was dus op de hoogte van de exploit, maar vervolgens niet patchen. Beetje vergelijkbaar met je weet dat je deur kapot is, maar geen nieuwe willen kopen.
In dat geval, ook gewoon de kosten die er gemaakt zijn/schade die geleden is, op de klanten gaan verhalen die geen gehoor gaven aan het bericht.
"Helaas moeten wij concluderen dat voor een aantal klanten het lek al is misbruikt voordat de servers zijn geüpdatet", aldus Proserve.
Met andere woorden: "Helaas moeten wij concluderen dat een aantal klanten het lek niet dichtte, en daardoor de servers misbruikt zijn."
Tsja, maar waarom is een klant aansprakelijk voor software die Proserve levert. En mocht je dat zo nodig willen, waarom kun je daarmee bij alle gegevens van alle klanten.
Het lijkt me dat Proserve hier nogal wat steken heeft laten vallen en niet de klanten.
Het lijkt me dat Proserve hier nogal wat steken heeft laten vallen en niet de klanten.
Als jij een Windows licentie ergens koopt, gaat jouw leverancier toch ook niet alle updates installeren? Dat moet je zelf doen, de updates worden aangeboden en jij kunt die installeren op een moment dat het jou uitkomt.
Tenzij er een servicecontract is afgesloten voor het installeren van updates vind ik niet dat ProServe verantwoordelijk is voor het installeren van updates.
Tenzij er een servicecontract is afgesloten voor het installeren van updates vind ik niet dat ProServe verantwoordelijk is voor het installeren van updates.
??Parralell's Plesk is niet van proserve, ik zie het meer als een auto lease bedrijf, die hun klanten waarschuwen dat ze naar de garage een band moeten verwisselen , en sommige klanten dat negeren, nu hebben die een lekke band.. is t de bandenfabrikant of de leasemaatschappij die verantwoordelijk is ?
Ps plesk zuigt enorm, ben blij da'k ze inmiddels uitgefaseerd heb.... klanten die zefstandig plesk probeerden te updaten.. en boem server plat... gewoon terminal werk is beter, geen dependencies en geen klanten die zelf aan de slag denken te kunnen gaan
Ps plesk zuigt enorm, ben blij da'k ze inmiddels uitgefaseerd heb.... klanten die zefstandig plesk probeerden te updaten.. en boem server plat... gewoon terminal werk is beter, geen dependencies en geen klanten die zelf aan de slag denken te kunnen gaan
Dat hangt geheel af van de overeenkomst die jij met je provider hebt. als jij een colo-overeenkomst hebt, en daarbij de deal hebt gemaakt dat je provider (prosurf in dit geval) een draaiende server oplevert (met de software er op), dan is de provider geenzins verplicht om iets te doen op die server. Dat is jouw verantwoordelijkheid. Het is al fijn genoeg als ze uberhaupt aangeven dat er een lek is, en dat je moet updaten. Als je dat zelf niet doet vervolgens, of te laat, dan is dat jouw verantwoordelijkheid, en jouw probleem.Het lijkt me dat Proserve hier nogal wat steken heeft laten vallen en niet de klanten
Als je een full-managed overeenkomst hebt, dan worden de zaken compleet anders, en is de provider verantwoordelijk voor alles. Maar aangezien dat soort contracten veelal een heel stuk duurder zijn, worden die door kleinere bedrijven vaak niet afgenomen.
Ik denk dat er gedoeld wordt op de schade aan andere klanten/eigen administratieve infrastructuur, en mogelijk op het compleet afsluiten van een klant omdat die toevallig het slachtoffer (dus niet de dader) is van een DDOS. Komt allemaal niet heel erg professioneel over, moet ik zeggen.
Nee dat hebben ze niet (wij zijn Proserve klant). Je doet verkeerde aannames.
Wat je nou roept is hetzelfde als dat MS jou op de hoogte brengt dat je Exchange server zo lek als een mandje is. Ze melden welke patches je moet installeren en je hebt hier persoonlijk bericht van gehad (niet via e.e.a. website die je zelf moet controleren). En vervolgens doe je dat niet.
Proserve levert contracten waarbij zij het beheer doen voor je of ze leveren je software en je doet het zelf. Daar kies je dus voor. Deze klanten hebben er voor gekozen het zelf te doen, krijgen een mailtje dat er een lek is en denken vervolgens iets in de trend van boeiuh en doen d'r niks mee.
Vind de titel van dit artikel dan oor redelijk misselijk gekozen. Dit is geen fout van Proserve en de titel doet je iets heel anders vermoeden.
Wat je nou roept is hetzelfde als dat MS jou op de hoogte brengt dat je Exchange server zo lek als een mandje is. Ze melden welke patches je moet installeren en je hebt hier persoonlijk bericht van gehad (niet via e.e.a. website die je zelf moet controleren). En vervolgens doe je dat niet.
Proserve levert contracten waarbij zij het beheer doen voor je of ze leveren je software en je doet het zelf. Daar kies je dus voor. Deze klanten hebben er voor gekozen het zelf te doen, krijgen een mailtje dat er een lek is en denken vervolgens iets in de trend van boeiuh en doen d'r niks mee.
Vind de titel van dit artikel dan oor redelijk misselijk gekozen. Dit is geen fout van Proserve en de titel doet je iets heel anders vermoeden.
Helemaal eens met freaky in deze.
Altijd leuk die 'tweakertjes' hier die meteen al klaar zitten met de beschuldigende vinger. Bah.
Altijd leuk die 'tweakertjes' hier die meteen al klaar zitten met de beschuldigende vinger. Bah.
Sluit me helemaal bij je aan, wij zitten dan niet bij Proserve, maar wij moeten echt zelf onze updates uitrollen. Ik zou niet eens willen dat onze hoster dit voor ons zou doen: Wij hebben koppelingen met een de Api van Plesk en mochten die veranderen willen we daar toch wel eerst even mee testen voordat we zomaar gaan updaten.
Er zijn rapporten van plesk hacks rond december, ver voor het Plesk lek in bredere kringen bekend werd.
Tja, particulieren vragen software updates te doen is vragen om moeilijkheden. Dit had proserve natuurlijk gewoon zelf moeten doen, ongeacht serviceovereenkomst of niet.
Onderhoud gaan plegen bij klanten die misschien er niet van gedient zijn is natuurlijk niet de bedoeling. Ik zie de nieuwsberichten al langs komen als Microsoft PCs gaat updaten terwijl mensen de Windows Update uit hebben staan. Nee, in dit geval denk ik dat (een deel van) de kosten op deze klanten verhaald kan worden, er is immers sprake van nalatigheid. Er zal vast wel een dergelijke clausule in de contracten staan.
Zo ver ik weet doet Proserve aan Dedicated Server hosting, VPSes e.d. Iedereen die graag zelf een server wilt beheren, moet dan ook makkelijk een scripje kunnen draaien om een beveiligingslek te dichten. Zo niet, dan moeten gewoon die kosten die gemaakt zijn verhaald worden op die incompetente prutsertjes met servers.
Trouwens, als ik het zo lees, hoste het bedrijf 4500 servers voor klanten, en als ze allemaal een overeenkomst hadden met het bedrijf, was het alsnog een drama geweest op iedere server die patch uit te voeren, je moet tenslotte van iedereen het root wachtwoord opvragen.
Trouwens, als ik het zo lees, hoste het bedrijf 4500 servers voor klanten, en als ze allemaal een overeenkomst hadden met het bedrijf, was het alsnog een drama geweest op iedere server die patch uit te voeren, je moet tenslotte van iedereen het root wachtwoord opvragen.
Als jij een managed overeenkomst hebt met een degelijke hosting parij, heeft de hosting partij al dat soort gegevens netjes in hun documentatie staan.
De vraag is of ze genoeg mankracht hebben om 4500 servers in korte tijd te updaten, er zit altijd een mate van overboeking op aangezien niet elke server elke dag onderhoud vereist (bij een normale gang van zaken).
De vraag is of ze genoeg mankracht hebben om 4500 servers in korte tijd te updaten, er zit altijd een mate van overboeking op aangezien niet elke server elke dag onderhoud vereist (bij een normale gang van zaken).
Wachtwoord? Wat was dat ook al weer? Gebruik al 10 jaar ssh met RSA Authentication.
Anyway, grootste deel van wat proserve heeft staan is niet managed. Verantwoording van klant zelf dus.
Anyway, grootste deel van wat proserve heeft staan is niet managed. Verantwoording van klant zelf dus.
Op het moment dat mijn hoster zich toegang verschaft tot mijn servers krijgt 'ie een aangifte aan zijn broek en zijn mijn servers er binnen een week weg. Een hackende hostinboer, kom nou. 
Ze hebben totaal geen logingegevens van mijn machines, ze kunnen er dus normaal gesproken niet eens bij. Dat zal in het geval van Proserve ook het geval geweest zijn. Dan kan je als bedrijf niets anders dan je klanten dringend verzoeken om ASAP hun server(s) te updaten.
Ze hebben totaal geen logingegevens van mijn machines, ze kunnen er dus normaal gesproken niet eens bij. Dat zal in het geval van Proserve ook het geval geweest zijn. Dan kan je als bedrijf niets anders dan je klanten dringend verzoeken om ASAP hun server(s) te updaten.jij draait dus ook geen plesk op je machines, en je blijft op de hoogte van security advisories.
veel klanten doen dat niet, die huren gewoon een standaard servertje en vinden een servicecontract net te duur (want die paar tientjes kun je ook aan bier uitgeven) en kijken dan de volgende 3 jaar niet meer naar de server software om
veel klanten doen dat niet, die huren gewoon een standaard servertje en vinden een servicecontract net te duur (want die paar tientjes kun je ook aan bier uitgeven) en kijken dan de volgende 3 jaar niet meer naar de server software om
Helemaal niet. Als je dat wilt dan neem je een serviceovereenkomst af. Ik host verschillende websites en moet er niet aan denken dat de hoster eventjes op mijn server inlogt en wat dingen bijwerkt. Draai maar eens "pacman -Syu plesk" op een arch linux server die een tijdje niet ge-update is. Vervolgens krijg je een melding over conflicten, verwijder je mtab, en daarna kun je het systeem niet meer bijwerken. Heeft mijn hoster genoeg kennis van arch linux hiervoor? Ik betwijfel het. Voorbeeld: http://www.archlinux.org/...al-intervention-required/
Daarnaast komt er ook een bepaalde verantwoordelijkheid kijken op het moment dat jij jezelf toegang verschaft op servers van klanten. Als je dit kan en Brein verdenkt jouw klanten van auteursrechteninbreuk dan kun jij dit stoppen door op de servers het materiaal te verwijderen. Doe je dit niet dan ben je dus mede verantwoordelijk en aansprakelijkheid want je weet dat de wet wordt overtreden en je kan het stoppen maar je doet het niet. Als je geen toegang hebt tot servers van klanten dan kun je dit niet tegengaan en heb je ook niet de verantwoordelijkheid. Mijn hosters zijn doorgeefluiken en verhuren hardware, het geen veredelde systeembeheerders. Tenzij ik dat wil.
Daarnaast komt er ook een bepaalde verantwoordelijkheid kijken op het moment dat jij jezelf toegang verschaft op servers van klanten. Als je dit kan en Brein verdenkt jouw klanten van auteursrechteninbreuk dan kun jij dit stoppen door op de servers het materiaal te verwijderen. Doe je dit niet dan ben je dus mede verantwoordelijk en aansprakelijkheid want je weet dat de wet wordt overtreden en je kan het stoppen maar je doet het niet. Als je geen toegang hebt tot servers van klanten dan kun je dit niet tegengaan en heb je ook niet de verantwoordelijkheid. Mijn hosters zijn doorgeefluiken en verhuren hardware, het geen veredelde systeembeheerders. Tenzij ik dat wil.
Dat lijkt me zeker niet verstandig, want waar ligt het einde? Dan wordt de hoster alsnog aansprakelijk voor alles ondanks de overeenkomst.
Wellicht zit de klant om wat voor reden dan ook er niet op te wachten dat Proserve op de server zit.
Sterker nog, ws heeft Proserve zelf niet eens toegang want de klant heeft in dat soort gevallen het root wachtwoord.
Wellicht zit de klant om wat voor reden dan ook er niet op te wachten dat Proserve op de server zit.
Sterker nog, ws heeft Proserve zelf niet eens toegang want de klant heeft in dat soort gevallen het root wachtwoord.
Dat is gewoon inbraak en dus crimineel. Als een hoster besluit om zelfstandig op mijn servers in te loggen dan is ie dat contract direct kwijt.
Je kan natuurlijk in je contract laten opnemen dat je dit soort maatregelen mag nemen, maar ik denk dat veel bedrijven niet op zo'n contract zitten te wachten, ze hebben niet voor niets een unmanaged server genomen.
Je kan natuurlijk in je contract laten opnemen dat je dit soort maatregelen mag nemen, maar ik denk dat veel bedrijven niet op zo'n contract zitten te wachten, ze hebben niet voor niets een unmanaged server genomen.
Dat klanten die het bedrijf niet voor updates betalen en dat kennelijk zelf willen doen het niet doen, lijkt me het bedrijf niet te verwijten. Wel vreemd dat via die servers van klanten dan de wachtwoorden van andere klanten kunnen worden achterhaald - dat zou afgeschermd moeten zijn.
Makkelijk gedachte gang weer:
Om de aanval uiteindelijk te stoppen, heeft Proserve besloten zijn dienstverlening aan dit bedrijf te staken en al het netwerkverkeer naar de servers van dat bedrijf te blokkeren
Dus als je als reseller aangevallen wordt en proserve kan het niet aan sluiten ze je verbinding af...
ontopic:
dit zal wel weer aardig wat ddos power opleveren voor de hackers
Om de aanval uiteindelijk te stoppen, heeft Proserve besloten zijn dienstverlening aan dit bedrijf te staken en al het netwerkverkeer naar de servers van dat bedrijf te blokkeren
Dus als je als reseller aangevallen wordt en proserve kan het niet aan sluiten ze je verbinding af...
ontopic:
dit zal wel weer aardig wat ddos power opleveren voor de hackers
Juridisch gezien veroorzaak jij als klant overlast door de ddos aanval, dat je daar niet om gevraagd hebt doet er niet toe. De ISP kan je helpen de ddos te bestrijden maar prioriteit 1 is het overeind houden van het netwerk voor de overige klanten.
Als het een goede ddoss is kan je niet veel meer doen dan nullrouten van het doel, dus effectief de stekker er uit trekken.
Als het een goede ddoss is kan je niet veel meer doen dan nullrouten van het doel, dus effectief de stekker er uit trekken.
De laatste paar weken heb ik bijna alle wachtwoorden aangepast en ondergebracht bij LastPass.
ik betrapte me erop dat mij ook vele wachtwoorden hetzelfde waren of heel simpel.
maar als dit, aan de server zijde gebeurd, wat kan ik dan nog doen om mijn gegevens af te schermen? Het is echt dweilen met de kraan open.
ik betrapte me erop dat mij ook vele wachtwoorden hetzelfde waren of heel simpel.
maar als dit, aan de server zijde gebeurd, wat kan ik dan nog doen om mijn gegevens af te schermen? Het is echt dweilen met de kraan open.
Nu hopen dat LastPass niet gehacked wordt 
Een centraal opslagsysteem voor wachtwoorden is leuk bedacht, maar online bij een ander systeem is dit toch risicovol. Vooral als je bekijkt dat zelfs certificateauthorities worden gehacked en grote bedrijven als KPN, kun je je afvragen of LastPass zijn infrastructuur wel goed heeft beveiligd en de wachtwoorden ook dermate goed heeft beveiligd dat ze ook echt niet terug te voeren zijn zonder de benodigde sleutel. Ook deze sleutel is ergens opgeslagen op hun netwerk dus denk niet dat ze deze garantie kunnen leveren.
Een centraal opslagsysteem voor wachtwoorden is leuk bedacht, maar online bij een ander systeem is dit toch risicovol. Vooral als je bekijkt dat zelfs certificateauthorities worden gehacked en grote bedrijven als KPN, kun je je afvragen of LastPass zijn infrastructuur wel goed heeft beveiligd en de wachtwoorden ook dermate goed heeft beveiligd dat ze ook echt niet terug te voeren zijn zonder de benodigde sleutel. Ook deze sleutel is ergens opgeslagen op hun netwerk dus denk niet dat ze deze garantie kunnen leveren.
[Reactie gewijzigd door mrdemc op dinsdag 6 maart 2012 11:36]
een ding valt me op:
scada ook web interface.
plesk ook web interface .
zullen er waarschijnlijk wel meer zijn.
scada ook web interface.
plesk ook web interface .
zullen er waarschijnlijk wel meer zijn.
Als iets geen webinterface heeft, dan is het natuurlijk lastig te benaderen, dus lastig te hacken. Het veiligste blijft toch nog steeds een systeem wat niet verbonden is met een netwerk, maar webservers zonder netwerkconnectie zijn dan weer enigzins overbodig
Ook systemen zonder webinterface zijn te gebruiken zonder dat het lastig wordt. Elk systeem wat een netwerkverbinding heeft is te hacken, met of zonder webinterface. Iets dat je zelf ook al zegt. Een webinterface is een schil die op meerdere manieren kan worden gemaakt. Je kunt ook een standalone applicatie maken die verbinding maakt met een bepaald systeem. Ook dit is te hacken doordat er gebruik wordt gemaakt van een API oid.
Maar zulke interfaces zul je moeten beveiligen door bijv. een ip-restrictie op te leggen en gebruik te maken van certificatenlogin + pass en username.
Maar zulke interfaces zul je moeten beveiligen door bijv. een ip-restrictie op te leggen en gebruik te maken van certificatenlogin + pass en username.
Vooral met onderstaande URL wordt het vrij makkelijk om dergelijke hosts te vinden:
http://www.shodanhq.com
http://www.shodanhq.com
Zijn mijn gegevens nu op bekend? Ik beheer een domein via Plesk maar ik weet niet of die direkt met Proserve te maken heeft.
Kent iemand de hoster Webreus?
Kent iemand de hoster Webreus?
Plesk is een pakket van Parallels om servers mee te beheren. Als jij je server niet bij Proserve hebt hangen, dan denk ik niet dat je je direct zorgen moet maken. Wel is het natuurlijk aan te raden om de boel te updaten.
Ik denk dat je het beste hierover je eigen hoster even moet mailen om het zeker te weten.
@jozet
Ik heb bij de hoster Webreus gezeten.
Nu ben ik persoonlijk overgestapt naar Versio, maar als ik moet / mag kiezen tussen Plesk of Directadmin, kies ik persoonlijk Plesk. Webreus heb ik altijd als fijne ISP ervaren, en als ik vragen had over Plesk of over update's werd in mijn geval altijd netjes geluisterd en geholpen.
Als jij bij webreus zit, dan mag ik aannemen dat hun Plesk wel hebben geupdate, en zijn jou gegevens niet bekend.
Ik heb bij de hoster Webreus gezeten.
Nu ben ik persoonlijk overgestapt naar Versio, maar als ik moet / mag kiezen tussen Plesk of Directadmin, kies ik persoonlijk Plesk. Webreus heb ik altijd als fijne ISP ervaren, en als ik vragen had over Plesk of over update's werd in mijn geval altijd netjes geluisterd en geholpen.
Als jij bij webreus zit, dan mag ik aannemen dat hun Plesk wel hebben geupdate, en zijn jou gegevens niet bekend.
Het lek zit in Parallels Plesk Panel, als je de laatste versie hiervan hebt is er niets aan de hand:Zijn mijn gegevens nu op bekend? Ik beheer een domein via Plesk maar ik weet niet of die direkt met Proserve te maken heeft.
Alle versies van Plesk 10.0.0 t/m 10.3.0 zijn kwetsbaar, versie 10.3.1 en hoger zijn veilig als de laatste MicroUpdates zijn geïnstalleerd.
Alle versies van Plesk 9.0.0 t/m 9.5.3 zijn kwetsbaar, versie 9.5.4 is veilig als de laatste MicroUpdates zijn geïnstalleerd.
Alle versies van Plesk ouder dan 8.6.0 zijn kwetsbaar, versie 8.6.0 is veilig als de laatste MicroUpdates zijn geïnstalleerd.
Wat dat betreft is het bericht onduidelijk.
Aan de ene kant gaat het over Plesk, gaten in Plesk, gaten die gedicht zouden zijn en mensen met een service contract al hebben, andere mensen hebben die nog niet ge-update en zijn de bok, etc. etc. etc.
Aan de andere kant...
Dus moeten mensen nu, ongeacht het gebruik van Plesk, zorgen dat ze hun inloggegevens veranderen, of niet?
Aan de ene kant gaat het over Plesk, gaten in Plesk, gaten die gedicht zouden zijn en mensen met een service contract al hebben, andere mensen hebben die nog niet ge-update en zijn de bok, etc. etc. etc.
Aan de andere kant...
...wat in zou houden dat zelfs als jij helemaal geen Plesk gebruikt, je gegevens nog steeds gepakt kunnen zijn.Volgens Proserve hebben de aanvallers alle klantgegevens uit de database ontvreemd. Het zou hierbij gaan om reseller-, client- en domeingegevens, ftp-wachtwoorden, databaselogins en maillogins van alle domeinnamen.
Dus moeten mensen nu, ongeacht het gebruik van Plesk, zorgen dat ze hun inloggegevens veranderen, of niet?
Webreus staat niet bij proserve, of webreus de patches heeft geïnstalleerd moet je hen vragen.
Webreus gebruikt zo te zien Plesk 8.2, welke dus ook getroffen is door dit lek. Tenzij ze handmatig de update hebben geïnstalleerd (Plesk 8.2 heeft geen automatische update ontvangen) zijn deze servers inderdaad kwetsbaar en zijn je gegevens niet veilig (zelfs niet als je nu je wachtwoorden aanpast).
Het beste kun je even hierover contact opnemen met Webreus.
Het beste kun je even hierover contact opnemen met Webreus.
[Reactie gewijzigd door EDIT op dinsdag 6 maart 2012 09:56]
Bedankt voor alle reacties
jammer dat door de stommiteit van je klanten je bedrijf een slechte naam krijgtHoewel het hostingbedrijf voor diverse klanten de beschikbare updates heeft geïnstalleerd, lijkt het erop dat niet alle klanten die geen serviceovereenkomst met het bedrijf hebben dat zelf hebben gedaan.
Jammer dat je je als bedrijf jezelf zo afhankelijk gemaakt hebt van klanten. Met duizenden klanten hoeft er tenslotte maar eentje tussen te zitten die de upgrade niet doorvoert. En iedereen weet dat veel klanten hun systemen niet goed bijhouden.
Het staat niet helemaal duidelijk in het artikeltje maar in de titel wordt gesuggereerd dat er dus weer onversleutelde wachtwoorden zijn gebruikt. Als je dat anno nu nog steeds zo doet moet je je diep schamen als bedrijf.
Toch vermoed ik dat er niet direct logins + wachtwoorden buit zijn gemaakt want je kunt via andere exploits ook wel zonder wachtwoord binnendringen, en dat is wat de rest van het artikel eigenlijk beschrijft...
Toch vermoed ik dat er niet direct logins + wachtwoorden buit zijn gemaakt want je kunt via andere exploits ook wel zonder wachtwoord binnendringen, en dat is wat de rest van het artikel eigenlijk beschrijft...
Plesk slaat al jaren gegevens onversleuteld op. Is al jaren bekend, en pas in de allerlaatste versie hebben ze eindelijk de gegevens versleuteld (maar ja, je kunt weer niet zomaar upgraden).
Alle logingegevens en wachtwoorden van e-mail, Plesk login, databases, webusers, domainusers, FTP hebben de hackers buit kunnen maken. Dit geldt voor alle servers met Plesk in versies 7.6 t/m 10.3. Zie ook http://kb.parallels.com/en/113321
Alle logingegevens en wachtwoorden van e-mail, Plesk login, databases, webusers, domainusers, FTP hebben de hackers buit kunnen maken. Dit geldt voor alle servers met Plesk in versies 7.6 t/m 10.3. Zie ook http://kb.parallels.com/en/113321
idd, was altijd handig om vergeten wachtwoorden voor mail accountjes te achterhalen, ipv te resetten... wat een bloated rotzooi was dat... 
enneh een fail2ban is te lastig voor t gros? ( houdt iig de meeste attacks tegen, vooral geautomatiseerde.. )
enneh een fail2ban is te lastig voor t gros? ( houdt iig de meeste attacks tegen, vooral geautomatiseerde.. )
Bij deze attack was het niet eens nodig om in te loggen
Men kon zo direct de API aanspreken en alle info (incl. plaintext wachtwoorden) er uit trekken. Aan zoiets heb je dus niets.
Vervolgens worden die gegevens gebruikt om scriptjes te uploaden en cronjobs aan te maken. Effect: een server die meedoet in een DDOS aanval of spam aan het versturen is.
Men kon zo direct de API aanspreken en alle info (incl. plaintext wachtwoorden) er uit trekken. Aan zoiets heb je dus niets.
Vervolgens worden die gegevens gebruikt om scriptjes te uploaden en cronjobs aan te maken. Effect: een server die meedoet in een DDOS aanval of spam aan het versturen is.
Ik denk dat er in dit artikel twee dingen door elkaar lopen.
De servers van klanten zijn namelijk apart, ondanks dat ze Plesk draaien, en zolang de servers van die klanten zijn, zijn ze niet direct gekoppeld als een geheel met de servers van ProServe. Daarom zouden de servers van de klanten nooit toegang moeten kunnen hebben naar de gegevens van de klanten van ProServe. Ik heb het idee dat het in dit artikel niet om klantgegevens van ProServe gaat, maar om de klantgegevens van de klanten van ProServe... Wordt een ingewikkeld verhaal zo :x
Maar wachtwoorden in Plesk worden niet plaintext opgeslagen, om je angsten weg te werken, ze zijn echter wel om te zetten via dictonairy, brute-force of rainbow.
De servers van klanten zijn namelijk apart, ondanks dat ze Plesk draaien, en zolang de servers van die klanten zijn, zijn ze niet direct gekoppeld als een geheel met de servers van ProServe. Daarom zouden de servers van de klanten nooit toegang moeten kunnen hebben naar de gegevens van de klanten van ProServe. Ik heb het idee dat het in dit artikel niet om klantgegevens van ProServe gaat, maar om de klantgegevens van de klanten van ProServe... Wordt een ingewikkeld verhaal zo :x
Maar wachtwoorden in Plesk worden niet plaintext opgeslagen, om je angsten weg te werken, ze zijn echter wel om te zetten via dictonairy, brute-force of rainbow.
Misschien hadden ze best de sql injectie tegengehouden met een reverse proxy. Dat zou hen tijd hebben gegeven om de servers te patchen en had de hackers misschien wel kunnen tegenhouden.
Ik vrees dat die grote server farms te groot zijn om nog even snel te patchen.
Ik vrees dat die grote server farms te groot zijn om nog even snel te patchen.
Niet alle servers waren onder eigen beheer van Proserve, maar werden wel door hen gehost. Door nalatigheid van sommige klanten heeft dit dus kunnen gebeuren. Het heeft dus weinig te maken met de grootte van de server farm. De servers waar een service contract voor was waren wel door Proserve gepatcht.
In de offciele reactie van Proserve staat niet dat het gaat om servers die niet onder contract zitten. Het komt Proserve beter uit om te laten verstaan dat het gaat om servers die niet onder hun beheer zitten natuurlijk.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
