Lek in Plesk-adminpanel maakt honderdduizenden Apache-sites kwetsbaar

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)

[_serial_]

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

[Skindred]

grep -i "scriptalias /phppath/" $(awk '$1 = /HTTPD_VHOSTS_D/{print $2}' /etc/psa/psa.conf)/*/conf/*
grep -i "scriptalias /phppath/" $(awk '$1 = /HTTPD_INCLUDE_D/{print $2}' /etc/psa/psa.conf)/php_cgi.conf
grep -ir "scriptalias /phppath/" $(awk '$1 = /HTTPD_CONF_D/{print $2}' /etc/psa/psa.conf)*

Tonen of je vatbaar bent.


Ik alvast niet..
Als ze al bestaan, gaan ze mooi naar de cgi wrappers.


Ondertussen heeft Plesk zijn feedback gegeven:

http://kb.parallels.com/en/116241


Het gaat dus om oude Plesk 9.0 - 9.2 installs.

[Reactie gewijzigd door Skindred op 22 juli 2024 16:51]

[Jaded]

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.

[kowapanga]

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.

[Scraxxy]

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.

[Squ1zZy]

"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?

[Niemand_Anders]

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..

[To_Tall]

je hoeft maar een boze klant te hebben..

[gfive]

cPanel open source? dacht het niet....

[frankwopereis]

v.a. 15 dollar per maand, of 200 dollar per jaar vind ik zeker niet opensource nee

[kramer65]

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:

• Webmin
• VHCS (website geeft een waarschuwing zie ik nu)
• ISPConfig

[Reactie gewijzigd door kramer65 op 22 juli 2024 16:51]

[ZpAz]

Een opensource product hoeft niet per definietie ook gratis te zijn.

[Niet Henk]

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.

[Verwijderd]

Klopt. Wellicht werd cPanel verward met ZPanel, welke wel opensource is.

[IkBenErOokWeer]

http://www.zpanelcp.com/

[Dimitri R]

Indeed, fixed that

[maarten_m]

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.

[Jaded]

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.

[flabber]

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.

[Jaded]

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.

[Crim]

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.

[Rawit]

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.

[dupondje]

Net getest op enkele servers, en exploit werkt gewoon niet ...

[edwardVdV]

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

[BHQ]

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/