Virtualization and automation software developer Parallels is investigating claims that attackers are using a previously unknown vulnerability in its Plesk Panel product to compromise Web hosting servers and infect websites with malware.
Plesk Panel is one of the most widely used administration panels for Web hosting servers. It provides users with a graphical Web-based interface that allows them to easily perform server administration and website management tasks.
Since the middle of July, thousands of websites have been infected with malicious code that uses domain name generation techniques to make attacks more persistent. The hackers behind the wave of compromises are using a new version of the Black Hole exploit toolkit.
The affected websites were built using a variety of technologies, including HTML, PHP and ASP.NET and were hosted on different types of Web servers, including Microsoft’s IIS, Apache and Litespeed, independent security researcher Denis Sinegubko said in a blog post on June 22. The only common element among them is that they are all hosted on servers that use Plesk as a management panel.
“It’s a very massive attack and it is limited to Plesk servers,” Sinegubko said Friday via email. “So it definitely has to do with some Plesk security issues.”
The attacks are ongoing and reports from Web hosting server administrators whose systems were affected have piled up in Parallels’ support forums.
The company believes that the new compromises are related to a series of earlier attacks that exploited a now-patched SQL injection vulnerability to steal Plesk administrator and customer passwords.
“I guess, hackers grabbed Plesk databases and then suspended their violent activity about 2-2.5 months ago in order to lull Plesk owners’ vigilance,” a member of the Parallels team said on the company’s support forum. “Now we are observing new round of the exploit that is based on the grabbed Plesk databases.”
However, some of the affected users believe that a new vulnerability is responsible for their servers being hacked because the new attacks occurred after they patched the old vulnerability and reset all Plesk passwords.
In addition, it’s rumored that cybercriminals are selling a previously unknown vulnerability for Plesk Panel version 10.4 and earlier on underground forums.
“We are currently investigating this new reported vulnerability on Plesk 10.4 and earlier,” the company said in a security advisory on Thursday. “At this time the claims are unsubstantiated and we are unable to confirm this vulnerability and cannot confirm that this vulnerability is limited to any specific operating system.”
There are several ways in which the older, now-patched, vulnerability might have led to the recent attacks, the company said. Either some customers did not apply the patch for it at the time, or they did, but failed to reset all passwords, or they did both, but some of users reverted back to their old, possibly stolen, password.
The company also advised customers that after patching and changing all passwords, they should delete the active session records from the Plesk database.
Plesk 11, which was released in June, is not vulnerable to the older SQL injection vulnerability and doesn’t store passwords in plain text like previous versions did. This means that even if a new vulnerability exists, attackers wouldn’t be able to use it to steal customer passwords from Plesk 11 databases.
However, a lot of people still use Plesk 10, Plesk 9 or even Plesk 8, because upgrading is not a straightforward process and might break compatibility with other software that is running on their servers.
It seems that one of the most reliable methods of stopping the current attacks is to remove access to the Plesk file manager, which is what the attackers are using to insert the malicious code, Sinegubko said. “However this approach doesn’t close the security hole, it just removes one of the attack dependencies. Attackers can still find some other way to use the passwords they have.”
The reason why the attackers might have waited a few months before starting to abuse the passwords they stole during the earlier attacks could be because they had to figure out how to automate their upcoming attacks and test that everything was working properly, Sinegubko said.