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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 31, views: 12.257 •

Een beveiligingsonderzoeker heeft een exploit voor meerdere Plesk-versies voor Linux- en FreeBSD-servers gepubliceerd. Potentieel zou meer dan 360.000 websites kwetsbaar zijn voor de kwetsbaarheid in het Plesk-adminpanel.

Op de Full-Disclosure mailinglijst werd woensdag door een beveiligingsonderzoeker, die zich verschuilt achter de nick Kingcope, exploitcode voor Plesk gepubliceerd. Kingcope zou al vaker werkende exploitcode hebben gepubliceerd. De code zou werken op Plesk 8.6, 9.0, 9.2, 9.3 en 9.5.4 op Linux- en FreeBSD-servers; Windows- en Unix-servers zouden niet gevoelig zijn.

Via de exploit, waardoor php kan worden aangeroepen via de '/usr/bin'-directory, zou een aanvaller toegang kunnen krijgen tot de commandline op het gebruikersniveau van de Apache-server. De beveiligingsonderzoeker kwalificeert de kwetsbaarheid dan ook als zeer ernstig. Potentieel zijn meer dan 360.000 websites die Apache op Linux of FreeBSD draaien en de betreffende Plesk-versies aanbieden potentieel kwetsbaar. Parallels, ontwikkelaar van het commercieel aangeboden Plesk-adminpanel, zou nog niet hebben gereageerd op de zaak. Wel stelt een developer aan Ars Technica een work-around voor door een configuratiebestand aan te passen.

Het is niet de eerste maal dat Plesk gevaarlijke lekken bevat; in maart 2012 werden gegevens gestolen bij een hostingbedrijf door een kwetsbaarheid in Plesk, terwijl in april ook Plesk werd verdacht bij een grote hoeveelheid infecties op Apache-servers. Overigens zijn er de afgelopen jaren ook diverse kwetsbaarheden ontdekt in alternatieven voor Plesk, zoals cPanel.

Reacties (31)

cPanel open source? dacht het niet....
v.a. 15 dollar per maand, of 200 dollar per jaar vind ik zeker niet opensource nee ;)
Op zich heeft het feit of je geld voor je software vraagt of niet, vrij weinig met open source te maken. Als je de bron ook levert en daarbij een open licentie geeft, dan is het alsnog open source. Een voorbeeld hiervan is Red Hat Enterprise Linux.
Hetgeen cPanel geen open source maakt is het feit dat het een propriëtaire licentie heeft. Zie ook onder "License" op de wiki over cPanel: http://en.wikipedia.org/wiki/CPanel

[edit]
Alternatieven die wčl open bron zijn:

[Reactie gewijzigd door kramer65 op 6 juni 2013 15:41]

Een opensource product hoeft niet per definietie ook gratis te zijn.
Maar de source code moet wel vrij verkrijgbaar zijn (of voor slechts administratieve kosten). Daarmee is er vrijwel altijd een gratis community edition, gemaakt door de oorspronkelijke maker of niet.
Klopt. Wellicht werd cPanel verward met ZPanel, welke wel opensource is.
Indeed, fixed that :)
"Via de exploit, waardoor php kan worden aangeroepen via de '/usr/bin'-directory, zou een aanvaller toegang kunnen krijgen tot de commandline op het gebruikersniveau van de Apache-server."

Hiervoor heeft de 'aanvaller' toch al rechten nodig op de server zelf?
je hoeft maar een boze klant te hebben..
Het probleem zit hem vooral in de apache config line:
scrptAlias /phppath/"/usr/bin/"

welke de GEHELE /usr/bin beschikbaar maakt via de http://www.website.com/phppath en daardoor alle programma's benaderen welke in /usr/bin staan uitgevoerd worden.

Voor plesk/webmin/etc is het veel beter om een jailroot achtige installatie. Binnen je /var/www maak je een nieuwe directory aan 'systools' en vervolgens plaats je symlinks vanaf /usr/bin/php naar je systools directory.

Vervolgens gebruikt je voor de scrptAlias de systools directory. Mocht je systeem ooit vatbaar raken door een exploit, dan kunnen alleen de progs worden gebruikt waarvan je zelf symlinks hebt aangemaakt.

Ook is het verstandig om binnen /var/www een specifieke php include path aan te maken. Hierin plaats je alleen de include bestanden welke plesk nodig heeft. Met PHP komen vaak nogal wat library scripts mee welke niet worden gebruikt, maar wel via het include path beschikbaar zijn..

Dit vergt inderdaad meer (on-going) configuratie dan een standaard installatie, maar de meeste exploits gaan ook uit van een standaard installaties. Je server blijft in theorie nog steeds te hacken, alleen zal de hacker meer moeten kunnen dan een kant-en-klaar tooltje aanroepen..
Net getest op enkele servers, en exploit werkt gewoon niet ...
Nee, klopt, heb het getest en het lijkt onzin te zijn in elk geval voor Plesk 9.5.4 op CentOS, zie ook deze posts:

http://seclists.org/fulldisclosure/2013/Jun/25
en
http://seclists.org/fulldisclosure/2013/Jun/33
Check de mailing list ook voor de discussie:
http://seclists.org/fulldisclosure/2013/Jun/25

Ik denk niet dat we al te bang hoeven te zijn, voorlopig.
Volgens mij heeft kingscope het hier mis betreffende kwestbare versies.
Deze exploit is gebaseerd op een oude php-cgi bug (cve-2012-1823)
Hier had de aanvaller geen rechten voor nodig aangezien je rechtstreeks via webserver rechten PHP code kon uitvoeren

Ik heb zelf al een paar testjes uitgevoerd en bij allemaal kreeg ik als resultaat dat "/phppath/php" niet bestaat.
De ScriptAlias die deze exploit nodig heeft is naar mijn weten allang verdwenen in Plesk 9 en hoger.
Deze exploit is voor een oude versie, ik ga er vanuit dat Plesk 10 en 11 dit issue niet hebben.

Plesk 9 is zelfs al bijna EOL: http://www.parallels.com/products/plesk/lifecycle/
Tweakers zou er goed aan doen zelf eerst eens de reacties op artikelen op full disclosure te lezen voor er klakkeloos gecopy-paste wordt :

http://seclists.org/fulldisclosure/2013/Jun/33
Waarom word er gesproken over lekken in alternatieve software als cPanel en word er gelinked naar een hack bij cPanel support? Die hack heeft niets met de software te maken.
Ik bedoel dit niet negatief, maar wanneer gaan we toegeven dat we het digitale tijdperk gewoon niet beheersen, laat staan beveiligen?

Kijk maar op tweakers.net. Vandaag: dit bericht. Gisteren: kwetsbaarheden in hbbtv en gegevens duizenden burgers op straat.

Sommige zaken zijn minder ernstig, maar bv het bericht van de usb stick met gegevens vind ik zorgwekkend.

Serieus. Ik denk dat we niet klaar zijn voor digitalisering.

Op deze site zijn, naast hobbyisten zoals mij, ook echte experts aanwezig zijn en die zie ik ook berichten schrijven die zorgwekkend zijn.

Wat ik mis is een kader, een set van handvatten, waar software of een IT afdeling aan dient te voldoen. Misschien een soort van checklist. Ik weet het niet. Maar ik weet wel dat we te veel op onze bek gaan.

Ik ben erg gedreven in programmeren als hobby (vooral in Go), maar ik moet zeggen dat naarmate ik meer leer over wat er allemaal speelt, ik tot de conclusie kom dat we nog verdomde ver weg zijn van een samenleving waarin IT een veilig iets is. Dit vind ik zeer zorgwekkend want we vertrouwen wel zoveel op deze technologie.

Er moet iets gebeuren. Niet snel, maar wel goed doordacht.
Ik bedoel dit niet negatief, maar wanneer gaan we toegeven dat we het digitale tijdperk gewoon niet beheersen, laat staan beveiligen?
Het digitale tijdperk is niet anders dan de analoge wereld: afwegingen maken. Wat sla ik waar op, en hoe, op welke manier kan ik informatie opvragen, hoe ben ik wel klantvriendelijk, maar toch ook veilig. Alles is gebaseerd op afwegingen.
Wat ik mis is een kader, een set van handvatten, waar software of een IT afdeling aan dient te voldoen. Misschien een soort van checklist. Ik weet het niet. Maar ik weet wel dat we te veel op onze bek gaan.
Een vast kader stellen is onmogelijk. Geen enkel project is hetzelfde: ander platform, andere gebruikers, andere database backend, andere beheerders. Iedere keer zal er weer een afweging gemaakt moeten worden.

Het probleem waar we op het moment met z'n allen tegenaan lopen is dat dingen eigenlijk zo snel mogelijk moeten kunnen, en zo gebruiksvriendelijk mogelijk. Men vergeet nog wel eens dat ook het kraken van beveiligingen sneller en makkelijker kan. De digitale wereld geeft niet alleen "de goeierikken" de tools om een mooie omgeving te maken voor de klanten, maar "de slechterikken" ook de mogelijkheid om de boel sneller onderuit te halen dan ooit tevoren.
Daar ben ik het deels mee eens. Echter, ik geloof niet dat dingen "kraken" echt het probleem is. Als iets eenmaal ge-encrypt is, dan is het meestal wel veilig. Het gaat mij meer om de data die NIET ge-encrypt is.

Bv gisteren is een usb stick geleverd bij Omroep Brabant. Op die stick staan duizenden persoonsgegevens (handtekening, naw, bankrekeningnummer en misschien zelfs bsn en wat nog meer). Als dit op papier stond, dan had je een grote stevige tas nodig. Nu staat het op een usb stick.

Het gaat dus niet om encryptie of zoiets, maar om hoe we met IT in het algemeen omgaan. Ik moet bv voor de waterschappen wel alles invullen (zie bovenstaande gegevens), maar vervolgens geef ik dat geheel uit handen. Ik weet absoluut niet wie er naar kijkt en wat diegene ermee doet. Hetzelfde geldt voor digid, de banken enz.

Ik mis transparantie, duidelijkheid.

We zijn erg goed om dingen enorm complex te maken, maar zijn IMO gebaat bij simpelheid en eenvoud.

Lukt dit niet, dan denk ik dat het vroeg of laat mis moet gaan. Serieus mis. Dit lijkt me niet afkoombaar.

Edit: typo

[Reactie gewijzigd door 505261 op 6 juni 2013 16:44]

Mijn reactie was om even de Plesk versie op mijn server te testen, dat bleek versie 11 te zijn, en ik ben geen early-adapter.

Hoe relevant is het vinden van bugs in verouderde software? Wat ik mij afvraag is of er inderdaad ~360.000 verouderde Plesk installaties (Plesk 10 is namelijk al van 2010) bestaan. Het lijkt me dat je dan security op je webserver niet serieus neemt.
Geloof me, veel hosting partijen bieden dit nog aan, totdat het EOL is, dan pas wordt het vervangen. Plesk 9 en 10 worden nog ondersteund.
Een Plesk server met 500+ domeinen wil je echt niet upgraden naar een nieuwe major release.
Dat gaat gegarandeerd mis en dan hoef je niet te verwachten dat support het binnen een dag gaat fixen.

Ik moet wel zeggen dat de upgrades steeds beter gaan, maar nog steeds verre van vlekkeloos.
Inderdaad en dan is Plesk nog een makkelijk controlpanel als het om backup, updates en migraties gaat. Hostingproviders blijven het liefst zo lang mogelijk bij de versie die ze gebruiken zodat ze niet onnodig downtime veroorzaken.
Ik zou het omdraaien: een applicatie die risico's draagt voor 500 domeinen moet je wel updaten.
Zeker gaat er vast bij een of meer sites iets mis, maar een probleem in een gedeelde resource, in dit geval Plesk, geldt direct voor alle 500 klanten!

Ik leg liever aan een woedende klant uit waarom zijn website tijdelijk hinder ondervond door een probleem in software van derden, dan dat ik 499 klanten uit moet leggen dat hun website eruit lag omdat ik software die zij gebruiken niet geupdate heb om die ene klant tevreden te houden.
Updaten zeker, minor updates gaan prima.
Parallels blijft oude versies ook onderhouden, gelukkig.
Zodra de EOL-datum dichterbij komt is het dan ook migreren geblazen.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBGrand Theft Auto V

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013