Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
Loading site search ...

Millions of Website Passwords Stored in Plain Text in Plesk Panel

   26 Jun 12   Filed in General, Hosting+Security

After the theft of LinkedIn user database, there was a lot of buzz about how unthoughtful it was to store passwords as unsalted SHA-1 hashes.

What can be even worse is storing user passwords in plain text.

Brian Kreb was recently shocked when his hosting provider sent him his password in plain text. He wrote a post about it and made a conclusion that it is quite a common practice among hosting providers and that “naming and shaming may be the only way to change” it.

But why do hosting providers save passwords in plain text? Maybe because most of them don’t invent anything and just rely on web hosting automation programs?

Enter Parallels Plesk Panel.

They advertise themselves as “the most widely used hosting control panel solution. With more than 250,000 Windows and Linux servers deployed, Parallels Plesk Panel is the preferred choice for hosting service providers, web designers, and website owners.” They also advertize top-notch security that “protects personal data and websites“.

Plain text passwords

But what about the Plesk security in real world? Can we call it “top-notch” if I tell you that Plesk stores passwords in plain text?!

Update: Since version 11 Plesk doesn’t store passwords in plain text. Unfortunately, there are still many servers that use older versions of Plesk. You can still find many servers with Plesk 8.x.

Here are the proofs:

“The problem is, that every password is stored as plain text!!! I mean every password including the plesk, mail and ftp/ssh!”

“…And unfortunately all Passwords in Plesk are stored in plain text!! Take a look in database ‘psa’ at table ‘accounts’ (and better sit down before doing that!).”

And in older versions (many servers still use them) they didn’t encrypt Plesk admin passwords either

less /etc/psa/.psa.shadow
The password will be displayed in plain text.

What’s the problem?

But maybe is not such a big issue? After all, with proper permissions, only server admins have access to the passwords and server admins should have full access to every part of servers anyway.

That’s not so simple:

  1. Admins don’t need passwords to access sites of their clients. And they should not see their passwords. It’s a privacy thing. Some clients may use the same username/password combinations on other sites (Facebook, Gmail, PayPal, their banks, etc. – I know, it’s stupid to use the same passwords everywhere but still is a common practice) and server admins can easily abuse this information (especially given the amount of information they already know about their clients anyway: real names, addresses, phone numbers, etc.)
  2. Server admins can be target of spear-phishing and malware attacks that steal passwords. Once attackers obtain Plesk admin credentials they can easily get passwords of all server accounts.
  3. And don’t forget about bugs and security holes that can expose stored passwords or provide admin access to people without proper authorization.

Attacks in the wild

In case of Plesk, there are really such vulnerabilities and there are attacks in the wild that exploit those vulnerabilities.

February-March 2012: attackers gained admin access to Plesk servers and planted some backdoors. The user database seems be stolen too.

June 2012: hackers use stolen Plesk credentials to inject malicious code into legitimate websites.

Remember, Parallels bragged about 250,000 servers with installed Plesk Panel. That’s many millions of individual websites and millions of user accounts. Sounds like a good target for attacks.

Back to the Brian’s post I mentioned in the beginning — instead of naming and shaming individual hosting companies, we can name and shame software that they use. But if you are concerned about individual hosting providers, you can simply check if they use Plesk.

I have a few questions to my blog readers:

  • Do you think it’s OK that your hosting provider or your service provider stores your passwords in plain text?
  • How many of you have sites on servers with Plesk Panel? Did you know that your passwords are stored in plain text?
  • What can you say about other web hosting automation programs, e.g. CPanel? Do they store hashes or real passwords?
  • Is the latest version (11) of Plesk Panel still stores passwords in plain text? (They advertise “improved security” but who knows what this really means.) – Update: Brian (Parallels) says that Plesk 11 no loger stores passwords in plain text. Great!

Related posts:

Reader's Comments (16)

  1. |

    As of Plesk 11, no passwords are stored in plain text. Depending on the type of password, it is either one-way hashed or encrypted, each with a unique per-server salt or encryption key.

    • |

      Good to hear that, Brian. Any link to a documentation?

      By the way, do you have some estimation on the number of servers that still use older Plesk versions? <11

    • |

      We already swapped over to PLESK 11 immediately and deployed new servers – moving all clients over to them progressively and gracefully.

      This new security feature was one of the driving forces for a speedy update. Unfortunately, there is no admin feature to send out password request e-mails that I am aware of to help provide service to clients on par with simply sending them their password (as mentioned earlier in this e-mail).

  2. |

    “per-server salt or encryption key”

    So why bother? This is as good as useless – an attacker who gains access to the passwords will have access to the encryption key so can just decrypt the passwords. Passwords should always be hashed, not encrypted.

    And in the case of hashed passwords, a sitewide salt means an attacker can compute a site-wide rainbow table. Salt should be unique per password.

    Then you need to be using an appropriate hashing algo (bcrypt or scrypt), and need to enforce or at least encourage strong passwords / passphrases – you’ve done your bit at this point.

    How is it that such technical incompetents can be so successful? Right place, right time, wrong developers?

  3. |

    Plesk 11 has only just been released in the last few days.

  4. |

    During the tests I made a simple script for nmap to check the range of our PLESK servers for possible backdoors. The script is here and can be used to identify compromised systems,

    • |

      I tried to search for those “engine.php” and “ctrl.php3″ files on a dozens of servers affected by this last Plesk attack and got 404 errors.

      Maybe they were there some time ago or maybe it’s just a different attack. After all, as Axel showed, hackers used valid user credentials to log into Plesk and modify files in Plesk Editor. He believes that the passwords were stolen earlier this year (in February), and the account that has been hacked in June (on his server) are the ones that changed their passwords back to old ones after he had reset all passwords.

      • |

        Hi Denis,

        A couple months ago and doing some rough statistics I noticed around 10% of the PLESK panels to respond 200 on engine.php and/or ctrl.php3.

        The attacks that are mentioned, the ones that took place around the first days of 2012 were attacks to gather credentials from user accounts (PLESK panel user accounts). Credentials used later on to put specific attack bots in the systems from the client accounts. So yes the attackers gathered a very large number of Plesk user credentials.

        I wrote about the issue around March 2012 and also later during that month I found that some systems were even compromised on the last days of 2011 (November 2011).

        I just updated the script to cover and another possible file / request.

        Thank you for giving it a try.

  5. |

    I guess that explains a bit why I’ve had this sudden rash of Plesk hosting hack repair orders over the past couple weeks.

    I’ve never seen so many plesk server related malware removal requests in a single week before (past two years).

    Stellar info!

  6. |

    This is a general problem with web hosting automation software – I’ve not played with hsphere in a long time but that certainly used to store passwords for various things in it’s db in plain text.

    There are other offenders too (albeit in slightly different ways) Onapp’s web interface (set to http by default) returns a vm password on the vm details page each time it’s visited, hidden by javascript.

    For a good indication of what happens when this sort of issue is discussed see

  7. |

    One thing that plaintext passwords enable is authentication mechanisms such as CRAM-MD5 (where both sides need to know the plaintext, but even with a nonencrypted channel eavesdroppers cannot derive it — and if the server is impersonated, it cannot simply glean your password by you helpfully providing it).

    Admittedly that’s seldomly used (some mail clients support it) and you /should/ be using TLS/SSL instead to protect from eavesdroppers (though that has baggage of its own, it is still the better choice).

  8. |

    […] Millions of Website Passwords Stored in Plain Text in Plesk Panel […]

  9. |

    The wonderful plesk support answered to find an administrator, because there are no bug

  10. |

    […] second biggest web hosting control panel after CPanel) which exposed site passwords in plain text: Once passwords have leaked, just updating plesk doesn’t fix the problem, so there are loads […]

  11. |

    My Plesk password just got changed (2012-Sept-08), so I could not login.

    I am using Plesk 9.5.

    What to do? Is this serious? What could they do to the server? How do I check?

    I have changed back the password, so now I can log in again.


  12. |

    True – Plesk < 11 stores passwords in plain text. But what's the big deal? If the server is compromised to the extent that someone gets access to these passwords, the fact that they're in plain text doesn't matter anymore.

    The fact that passwords are in plain text is often a good thing. It allows server admins to police password complexity of user accounts.

    All public servers are major targets for spam relaying, and mail accounts are continually being threatened with brute-force attacks.

    When clients use simple passwords, they can cause a lot of problems for every client on the server, and the server admins and owners.

    Setting password complexity requirements in Plesk is only good for new accounts – it does jack sh*t for accounts that have been around for 10 years.

    I'm actually disappointed that Plesk 11 encrypts user passwords now.