Hackers in the criminal underground are selling an exploit that extracts the master password needed to control Parallels’ Plesk Panel, a software suite used to remotely administer hosted servers at a large number of Internet hosting firms. The attack comes amid reports from multiple sources indicating a spike in Web site compromises that appear to trace back to Plesk installations.
A hacker selling access to a Plesk exploit.
A miscreant on one very exclusive cybercrime forum has been selling the ability to hack any site running Plesk Panel version 10.4.4 and earlier. The hacker, a longtime member of the forum who has a history of selling reliable software exploits, has even developed a point-and-click tool that he claims can recover the admin password from a vulnerable Plesk installation, as well as read and write files to the Plesk Panel (see screen shot at right).
The exploit is being sold for $8,000 a pop, and according to the seller the vulnerability it targets remains unpatched. Multiple other members appear to have used it and vouched for its value.
It’s unclear whether this claimed exploit is related to a rash of recent attacks against Plesk installations. Sucuri Malware Labs, a company that tracks mass Web site compromises, told SC Magazine that some 50,000 sites have recently been compromised as part of a sustained malware injection attack, and that a majority of the hacked sites involved Plesk installations.
“What is interesting is that most of our clients always used to be using CMSs (like WordPress, Joomla, etc), but lately we are seeing such a large number of just plain HTML sites getting compromised and when we look deeper, they are always using Plesk,” Sucuri’s Daniel Cid said in a follow-up interview with KrebsOnSecurity.com.
In a detailed blog post last month about a new technological advancement in BlackHole exploit kits, malware researcher Denis Sinegubko examined more than a dozen sites that were seeded with the newer BlackHole kits. He discovered that the common link was Plesk, and said the culprit was likely a now-patched security hole in Plesk versions prior to 10.4.
But over the past few days, a number of Plesk users have been flooding the Parallels user forum, complaining of having their servers compromised even though they were running the latest versions of the software.
Question: how would a hacker know a site was running Plesk?
It appears you can find them by scanning for specific ports.
http://labs.sucuri.net/?note=2012-07-09
You can also tell sometimes by just looking at the Favicon of a website since the default favicon of a site setup on Plesk is the Plesk icon.
Some scripts have even gone as far as to telling the version based off the file size of the favicon.
“…The exploit is being sold for $8,000 a pop…”
A bit off topic but I’m curious how people like this actually get paid. I’ve got to think that mechanisms like PayPal are too easily traced to an individual.
It’s not offtopic at all. Good question. In this case, as in many others involving the sale of dodgy goods and services, the form of payment is Liberty Reserve. Another popular form of payment is another virtual currency, Webmoney.
Has BTC fallen out of style already?
Do the forum administrators help police against people reselling the exploit/tool at a cheaper rate once they’ve bought it from the initial seller?
I’ve always wondered why the people who buy the black market stuff don’t reverse engineer and sell it back to the market at a cheaper price.
I had assumed it was the time factor, the window of value closes rapidly once the exploit is made public and the original developers work to close the hole. By the time you decrypt the hack and can code it back up into your own tool, there’s probably a patch out to block the exploit it uses. But if it’s a simple point-and-click tool, that seems like something ripe for passing around at a discount.
There are also instances where Western Union has been used through cut-outs in third country
Thanks for the reporting Brian! I was wondering why there was a spate of hacked sites at my hosting provider.
I’m also wondering if they know that this is an issue. Is there any broader knowledge of this exploit vector, or is it just on a few security sites? How would providers get knowledgeable about this?
Are you going to get a new round of ddos over this?!
Many Plesk servers report it in HTTP headers.
For example:
X-Powered-By-Plesk: PleskWin
or
X-Powered-By: PleskLin
Sometimes you can even see a version
It’s a very old topic from that forum because you hided the posts.
How would you think of your self after 10 year’s ?
People making millions and you’re playing the super-hero
In the end heroes are great only In movies.
In real life they get f#cked eventually.
Keep at it Brian. You know you have them worried when they lurk on your site and talk trash.
Brian, your site has been really useful with the Plesk hacks. I first ran into it while researching the malicious javascript crap that infects customers I support and now I enjoy reading it.
On a related note, I am yet to handle a customer’s compromised Plesk that is patched. Not to downplay what you are saying, but in my experience (so far) it has been 100% Plesk 8.x that was infected.
My point of view comes entirely from linux support so it may be likely there’s windows-specific issues as the proffered 0day was windows-specific.
That we warned all our customers back in February about the exploit is a different matter. Oh well, only have to clean up one or five of these damn things a day.
We saw both Plesk 8 and 9 systems exploited when this was making the rounds a few months ago.
I really doubt that a hacker bothers to figure out what a site is running first. You run the crack. If you get control, then it was running software with that vulnerability. If not, it wasn’t.
The script might probe a few ports to save some time, but if I was in that business, I would run the crack on every address in a target range without probing for versions first. Even if I did check, “unable to determine if server is running vulnerable software” would result in trying the crack anyway.
Alan,
But hackers do bother to identify sites / hosts running Plesk
In a very simple way, it’s just a question of making a search on http://www.shodanhq.com for:
X-Powered-By-Plesk: PleskWin
or
X-Powered-By: PleskLin
(As Denis mentioned)
and then use the exploit against port 8443
That seems foolish to me. I’d assume that the clever site administrators out there would have found a way to turn the “Powered-By” headers off (or better still replace them with something misleading).
So why would I depend on a potentially false signal, when I could just run the exploit on 8443 and see if I got a hit?
Personally I’m of the opinion that unless there’s a brute force component to the vulnerability, only an amateur would trust a signature from any system. The guys who really want in would just run the crack anyway.
Alan,
Either clever administrator don’t exist you there is some difficulty on hiding the headers as http://www.shodanhq.com reports something like 115k hits for X-Powered-By-Plesk: PleskWin and X-Powered-By: PleskLin.
This seems the path of less resistance for someone to start an exploit campaign instead of scanning a certain IP range where a lot more not possible to be hacked systems (because no host is online or a host is online but does not has Plesk or the version is no compromised) would be found.
Obviously that this is only my 50 cents to the subject as my only interaction with Plesk was over 5 years ago with a website hosting it for me.
Best regards,
Alan – Hackers generally do not fire exploits around willy-nilly, as that is a GREAT way to get nailed by a honeypot or to cock up and get yourself arrested. It is much preferred to spend a second checking your target before you let loose…
Alan, that would be a very expedient way for them to waste their $8,000.
A couple of plesk sites in my country were compromised last month and one of it was a top news agency & they had no idea what was wrong. The version was plesk 10.0.0. After the access to plesk was restricted, things seem fine.
No, there is no new security problems in Plesk 10.4.4. The vulnerability is the old one.
Please refer to this article in our knowledge base:
http://kb.parallels.com/en/114330
The attack could occur on patched server if:
1) passwords were stolen previously when servers had a vulnerable version of Plesk installed. If passwords were not changed using http://kb.parallels.com/en/113391, then attackers could use them in order to hack servers.
2) passwords were changed using http://kb.parallels.com/en/113391, but some end-users changed their passwords back to old ones.
this is what parallels told us…
t4c,
You have to understand, this would be less sexy for people to read about. The security industry functions in large part due to an ominous, often made out to be “omniscient” or at least prescient “Other”.
It would be far less exciting for people to read about a bug that was patched months ago when people can read about a “0day bug” for sale(!) on an “very exclusive cybercrime forum” which was no doubt for sale months ago, judging by the patch cycle — a bug which is almost certainly being used on a wider scale now because people can read security releases and reverse patches and information found on forums.
If there is one thing one learns in this industry after a long time of working in it, it is this: People do not patch. But that’s not sexy. What’s sexy, what sells, what gets people to click, and what ultimately provides excitement in the industry, is FUD. No offense, Brian, but it’s true on almost every blog and article out there.
It’s a vicious cycle that’s not likely to end any time soon.
In the meanwhile, the user ultimately pays.
One thing I forgot to mention: Plesk needs to make its patching process MUCH more user-friendly. Have you seen their advice for patching this bug? Most people probably saw their page and decided they’d rather risk the chance of being exploited as opposed to breaking their site because they don’t know what they’re doing. Contrary to popular opinion, a good majority of (non-corporate) people with websites have little to no real expertise when it comes to programming or system administration. Patching is daunting to them, and frightening. It’s hard to blame this particular lack of patching entirely on the user. Vendors need to make patching far more user-friendly, thorough instructions or no — as in, at least as user-friendly as the exploits coded to exploit the bug(s) in question.
but Plesk is not an end-user product – it’s the hosting provider that should be keeping up with the updates. I would hope they should all have the wherewithal to do the patches.
Not necessarily. Not everyone has managed services. Plenty of people run dedis or co-lo’s. And plenty of hosting providers aren’t really that savvy. Plenty of *admins* aren’t that savvy. It is a time of point and click. Many sysadmins now don’t even know how to shell script.
This latest report got me a bit twitchy as we got hit really bad In February. What we noticed from our logs was that the original wave of attacks were doing nothing more than grabbing plesk passwords. So once patched you then needed to block 8443, patch plesk, change all passwords(domain users, clients and admin) and then ensure users didn’t revert to old passwords. This was a LOT of effort and I’m guessing many ISPs probably didn’t really have a clue what was happening and didn’t resolve the issue logically. I suspect that this ‘tool’ probably has the large pricetag because it has access to a large database of previouslt exploited servers as well as trying the original sql injection attack on agent.php…
Hi Edosan,
Can you share with us some sample logs on how they grab the plesk passwords? I guess it will be much helpful for us in term of detection.
We are seeing potential repeat attacks. In some cases, I think the issue may be related to the timing of the initial response by Parallels.
Recommendations on the full recovery and scripts to reset passwords were provided well after the community attempted to fix this on their own.
Also, I noticed that the patches for the vulnerability itself kept evolving.
I wonder if there were periods where the issue was not completely patched — allowing the attackers to obtain passwords that were already reset.
This issue is further complicated by the moronic engineering decision to store passwords in plain text.
Another attack vector we are exploring is MySQL itself. Some Plesk operators fail to block MySQL ports from public access. If the attackers setup a MySQL user to access the database, then they could just return and get the passwords again.
Since passwords are moronically stored as plain text, this would be a simple rinse and repeat operation for the attackers.
I’m surprised that more websites don’t have administrators that use 100% command line. Things like Plesk, Webmin, PHPMyAdmin etc can open up some serious holes if not kept properly up to date, let alone zero day. Hire yourself a “Linux Guy” and tell him no GUIs IMHO.
hosting providers would cut out nearly all of their business if they didn’t have a reasonable GUI front-end for their hosting services. I, for one, have relied on the Plesk interface for years for managing my websites.
Alan said:
“I’d assume that the clever site administrators out there would have found a way to turn the “Powered-By” headers off.”
I would say that a clever admin wouldn’t be using plesk in the first place. The old saying about webUIs on servers is still true: “if you know how to secure a webUI, you know how to live without it.”
Yeah, right. That’s why we never see OS and package level security patches.
The only secure server is one that’s powered off. Arguments for non-GUI interfaces are just arguments for spending more money on a specific class of sysadmin.
The fact is, that means spending more money. Not going to happen. I have no fear of shell, but for most of the mundane crap that’s server administration, I get a heck of a lot more done with a GUI.
The problem, as others have identified, is not keeping a system up to date. I’ve seen unpatched non-GUI systems that are security nightmares (and one command line “Ninja” who enabled root with “orange” for a password!)
I completely agree with what voksalna said: the problem is less with the tools and more with the people maintaining and using them.
Keeping a system up do date is paramount.
But you minimize the risks of having to manage a 0day by minimizing the number of installed softwares and solutions on your production server.
A webGUI is not mandatory and needs tons of dependencies, from my point of view it is too big a risk for the gain.
I won’t hide that i do prefer a cli UI, easier to script, esasier to maintain, easier to deploy, but that’s more a question of taste, or that it better fits my workflow. “Most of the mundane crap” should be scripted anyway …
“The fact is, that means spending more money. Not going to happen. ” … i would say that you get the security you paid for. 😀
That aside i completly agree that in the end the security of a system relies on the knowhow of the people maintaining them, but choosing to use a webUI is part of that, it is a maintainer “action”.
Well if you CLI but don’t script… you have a lot of spare time to waste. 😉
Sadly, you often don’t get the security you pay for. Everyone copies and pastes “fully managed servers, all software kept up to date” then sticks a big price on it. Then they take the money but don’t do anything, even when it starts with no more than checking the right box in that oh-so-simple GUI installer.
I guess I shouldn’t complain too much… those guys are the source of a lot of customers. I just hate seeing people who don’t know any better getting ripped off by some clueless dolt who thinks hosting is a configure-and-forget cash cow.
Benjamin droped a secret tip on the vlabs twitter account. The message from yesterday =>
[SECRET NEWS] The new Plesk 10.4.4 code execution vulnerability is located in the bound webmail service 🙂
https://twitter.com/vuln_lab
– http://kb.parallels.com/en/113321
Last Review: Jul, 12 2012 – “… it may not be plausible at this time to perform a full upgrade to the latest release of Parallels Plesk Panel 11 which is not affected, thus there was a set of Micro-Updates released for each major version affected which will resolve the security issue without the necessity of a system upgrade…”
– http://www.symantec.com/security_response/threatconlearn.jsp
“… Parallels has released a fix for its Plesk Panel application to correct a previously unknown vulnerability which allows the administrator password to be recovered by an attacker. The code to exploit the vulnerability is currently being sold on the internet and potentially allows passwords to be compromised. Customers are advised to apply the fix as soon as possible…”
.
PC Tech — I’m trying to figure out if that Parallels note is a new announcement, or just an older advisory that was updated today.
Last time I checked, Parallels was saying they had no information that there was any 0day.
http://kb.parallels.com/en/114330
Brian, it’s the same old advisory.
yes, exactly — easy to see it by ID/sequence
– http://www.securitytracker.com/id/1027243
Jul 12 2012
CVE Reference: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-1557 – 7.5 (HIGH)
Impact: Disclosure of system information, Disclosure of user information, User access via network
Version(s): prior to 10.4.x
Solution: The vendor has issued a fix.
The fix also includes a Mass Password Reset Script that must be executed to remove existing sessions and prevent a recurrence.
The vendor’s advisory is available at:
– http://kb.parallels.com/en/113321
– https://secunia.com/advisories/48262
.
Plesk Panel 10.x for Windows…
* http://download1.parallels.com/Plesk/PP10/parallels-plesk-panel-10-windows-updates-release-notes.html
15-Jul-2012 – “… Fixed critical Plesk security issues found during internal security audit. All customers are highly recommended to update…”
Plesk Panel 10.x for Linux…
– http://download1.parallels.com/Plesk/PP10/parallels-plesk-panel-10-linux-updates-release-notes.html
15-Jul-2012 – “… Fixed critical Plesk security issues found during internal security audit. All customers are highly recommended to update…”
.
I am seeing more cases of web site files having javascript injections. The entry point is via the Plesk File Manager.
I speculate that the attackers may have obtained the passwords months ago and if the password were not reset they are simply returning to get into the system.
The latest round of attacks we see are on July 6th and 9th.
Is there any update on if and how it is possible to retrieve data?
hi guys,
my friends server was also hit via plesk,
through the filemanager, and % in the urls with the client ids
untill now i only found and removed js code from my indexes, php and html
but now i found an other variant, in the index they insert an include statement, to include an other file situated and looking like a log file.
then it is decoded and executed.
it is quite advanced coding, getting ads from some server, and lots of code to detect if its a googlebot or so, and then keep quiet
i found it out nearly by chance
(no i am not going to tell how i found it, it might help the hacker)
so, try to search for files around the infection date.
this one is not detected by a virusscanner
(dowload the code and run a scanner over it doesnt work)
hope this helps someone, dj
Any insight as to why kaspersky not detecting this…
my AVGfree system regales plesk threat and presence OK