Onderwerp: Kwetsbaarheid in Plesk

Ter info:

Parallels' Plesk Panel software bevat een SQL injection kwetsbaarheid die actief wordt misbruikt.

Zie onderstaande URL's:
http://kb.parallels.com/en/113321
http://arstechnica.com/business/news...=related_right
http://www.thewhir.com/web-hosting-n...urity-breaches

Groet,

--
Marco Davids

Is er ergens te zien of die api is aangeroepen en door wie?

jep, dat kan via:

# grep agent.php /usr/local/psa/admin/logs/httpsd_access_log

# zgrep agent.php /usr/local/psa/admin/logs/httpsd_access_log*

Houdt rekening met de hoofdletter A.

Redbeennl heeft het over agent.php, terwijl Plesk het heeft over Agent.php.
Wanneer je zoekt naar agent.php zul je dus ook andere resultaten krijgen dan dat je zoekt naar Agent.php

Hier was het geval dat agent.php wel in de logs gevonden werd, maar in een htdocs directory stond.
Agent.php werd hier niet in de logs gevonden.

Just my 2 cents

Oorspronkelijk geplaatst door gamer17nl

Houdt rekening met de hoofdletter A.

Volgens mij is het inderdaad zonder hoofdletter, maar voor de zekerheid:

# grep -i agent.php /usr/local/psa/admin/logs/httpsd_access_log

# zgrep -i agent.php /usr/local/psa/admin/logs/httpsd_access_log*

Het lijkt er op dat er meerdere issues zijn geweest die inmiddels zouden moeten zijn gefixt. Op 10 februari werd ik door de leverancier van mijn Plesk licentie op de hoogte gebracht van dit lek, en werd verteld dat het verplaatsen van Agent.php het probleem zou moeten voorkomen volgens Parallels. Daarnaast direct voor de zekerheid maar even de wachtwoorden aangepast.
Helaas bleek dat ijdele hoop en zijn er zelfs na die move nog gegevens buitgemaakt (o.a. de nieuwe FTP wachtwoorden) en zijn er dan helaas ook bestanden naar mijn website geupload met kwaadaardige rommel.
De daadwerkelijke patch bevatte dan ook niet enkel een nieuwe Agent.php file, maar ook enkele andere bestanden (zo uit m'n hoofd een class.Session.php, en werden er ook nog dingen gefixt in een paar andere files).
Wat mij betreft afwachten of het daadwerkelijk het probleem heeft verholpen, Parallels weigert verder iets te zeggen over hoe ik het eventueel zou kunnen reproduceren om te kijken of het echt opgelost is nu, dus ik kan niets anders doen dan wachten en monitoren of het goed gaat (naast dat uiteraard nogmaals alle wachtwoorden gewijzigd zijn).
Ik weet in ieder geval wel dat ik uit ga kijken naar een ander CP. Bah.

Wij zijn zojuist ook slachtoffer geworden van een hack in plesk 9.5.4 via de Agent.
Men kreeg het voor elkaar om remote een cronjob in te voegen, welke weer een rootkit installeerde. Dit lijkt me weer een nieuwe variant...

Op dit moment zijn er duizenden hack wereldwijd met de diverse Plesk omgevingen....niet om echt vrolijk van te worden. Wel vreemd is dat je relatief weinig/niets er over leest. Waarschijnlijk omdat de "hack"relatief nog niet is gebruikt voor diverse doeleinden.

Wat mij inderdaad verbaasd is dat het lijkt alsof Parallels dit al sinds september 2011 wist en dit pas deze maand naar buiten bracht. Er zijn inderdaad al erg veel hacks geweest. Mijn ervaring met Plesk op het gebied van security en stabiliteit is helemaal niet zo goed. Ik heb betere ervaringen met Cpanel, als je dan toch een controlpanel moet gebruiken.

Cpanel, Directadmin, etc. allemaal hebben ze wel iets, met Parallels Plesk gaat het wel goed zolang je niet altijd de allernieuwste versies gebruikt en de microupdates autom. installeerd.

Echter deze keer waren ze wel aan de late kant en je kunt het niet (zoals nu) simpel afdoen met: de patches waren al beschikbaar in 09-2011 als je die had geinstalleerd was er niets aan de hand geweest! Zonder verdere melding ......

niet helemaal mee eens, ik heb hier een volledige up2date 9.5.4 (de vorige branch inderdaad, maar volledig ondersteund) met de laatste microupdates en toch gisteren via de remote xml een cronjob geinstalleerd welke een rootkit download. Parallels gemaild, fora gepost... Maar men lijkt het niet serieus (genoeg) te nemen.

Wij hebben ze ook allemaal gepatched en tot nu toe geen last meer (2 dagen geleden) ook op plesk 9.5.4) stond nog wel een hele hoop oude hack meuk van voor die tijd.

Hmm ik zie ook wat staan, maar voorzover ik nu kan zien (ben nog aan het rondkijken) is er niets fouts geupload. Voorbeelden uit de log:

/usr/local/psa/admin/logs/httpsd_access_log.processed.2.gz:109.206.185.155 xxx:8443 - [09/Feb/2012:13:53:37 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 2390 "-" "-"
/usr/local/psa/admin/logs/httpsd_access_log.processed.2.gz:109.206.185.155 xxxx:8443 - [10/Feb/2012:15:40:27 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 76216 "-" "-"

/usr/local/psa/admin/logs/httpsd_access_log.processed.4.gz:41.130.58.239 xxxxx.com:8443 - [28/Jan/2012:00:05:16 +0100] "GET /enterprise/control/agent.php HTTP/1.1" 200 182 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Dat is allemaal agent.php en niet Agent.php. Ik ben helemaal niet op de hoogte gebracht. Ik zag het pas via de post op WHT. Ik heb wel het poortnummer van plesk aangepast. Wie weet houdt dat wat automatische scanners tegen.

Oorspronkelijk geplaatst door drex

Cpanel, Directadmin, etc. allemaal hebben ze wel iets, met Parallels Plesk gaat het wel goed zolang je niet altijd de allernieuwste versies gebruikt en de microupdates autom. installeerd.

Echter deze keer waren ze wel aan de late kant en je kunt het niet (zoals nu) simpel afdoen met: de patches waren al beschikbaar in 09-2011 als je die had geinstalleerd was er niets aan de hand geweest! Zonder verdere melding ......

Ik had inderdaad een iets oudere Plesk versie (9) nog draaien, echter werd deze nog wel gewoon van updates voorzien en was naar ik dacht ook up-to-date in die branch dan. Inderdaad heb ik niet geüpgrade naar Plesk 10, omdat ik hele slechte ervaringen heb met het upgraden van major release met Plesk. Micro-updates zijn wel altijd geïnstalleerd, en de updater wist dan ook vrolijk te melden dat deze geheel up-to-date was.
Heb dus handmatig de bestanden moeten updaten, aangezien die updater daar blijkbaar niet aan wilde. Erg praktisch zo'n ding...

Ik ben een paar uur verder en heb inderdaad een hoop aangepaste files gevonden in een aantal website accounts, zoals gif/png files die vervangen waren door php files met dezelfde naam, .htaccess files om die gif/png files uit te voeren en gewijzigde js files. Een aantal van die accounts waren van mijzelf, dus ik dacht dat misschien mijn ftp cache van mij pc was doorgestuurd, maar er zat ook een account van een ander tussen die dus niet in die cache staat. Het is dus goed mogelijk dat die agent hack wat passwords heeft doorgestuurd. Hack uitgevoerd op 21 Feb vanaf IP 195.16.88.195.

Ik heb nu zowel agent.php als Agent.php gerenamed en kan nog gewoon overal op inloggen.